BlitzableiterBasics¶
The general idea behind Blitzableiter is a method called normalization through recreation. The potentially malicious input file is read, parsed and interpreted as completely as possible, applying very strict rules of specification compliance in the process. If the input file is violating those rules, it is rejected as invalid. After the initial parsing, the original input file is discarded completely and a new file is created, based on the information obtained from the original input file.
Optionally, Blitzableiter can modify Adobe Flash Bytecode before creating the output file. This allows to modify code logic within Flash files for additional security checks, which may not be available or functioning properly in the native runtime environment. Currently, only Bytecode for the Adobe Virtual Machine 1 is supported.
Blitzableiter itself is entirely managed code for the .NET runtime environment. This prevents malicious Flash files from targeting the Blitzableiter parser instead of the Flash runtime parser for exploitation of memory corruptions, as .NET provides superior protection against those. The library also uses the arithmetic overflow checks available in the Common Language Runtime to detect integer overflow attacks against the Flash runtime.
The goal of Blitzableiter is to be able to parse any part of a Flash file eventually and hereby to provide complete protection coverage of the format. Currently, only a subset (although a growing one) of the format's different sub-types is validated.
The Adobe Flash File Format¶
The file format for Flash applications is generally referred to as SWF format (pronounced "swif"). It is a collection of media data, layout information, temporal information and Bytecode for one or both of the Adobe Virtual Machines, version 1 and version 2. The current specification is for the file format version 10.
SWF files can be compressed. The compression is applied to the entire file, except for the very first header, and uses standard compression algorithms known as ZLIB.
An SWF file is generally a collection of so-called tags. A tag is a typed data record. Every tag type follows a different format, as detailed in the specification. The order of the tags partially conveys temporal information about the Flash movie, as some tags control the displaying and rendering of previously defined graphic elements. Other tag types are position independent.
There are 210 possible tag types, but only 64 types are defined in the whitepaper. Adobe and third party products use additional, not documented tag types with unknown contents.
Since the file format evolved over time, almost all elements are version dependent. This means the follow different rules and formats, depending on which version of the SWF format the file uses. This also applies to AVM1 Bytecodes.
AVM Bytecode can be contained within the following tag types:
DoAction
DoInitAction
DefineButton
DefineButton2
PlaceObject2
PlaceObject3
The Bytecode is not stored consecutively, but dispersed over different tags and connected to other elements, like graphic objects. Bytecode blocks are self-contained, meaning that code shall only reference other code within the same code block. The AVM1 allows arbitrary branch destinations, which are illegal according to the format specifications.
AVM1 Bytecode instructions are variable length. There are 99 documented instructions, but Adobe and third party vendors use additional, undocumented Bytecodes. An instruction without additional arguments is one byte long. The most significant Bit of the instruction byte signals a following length field when set. The length field is 16 Bit and is always present if the instruction has arguments, even when the arguments are defined as fixed size. Therefore, the length field can specify a different size than the real instruction has.