Analyzing Malicious .

SWF Files
The Macromedia Flash File Format (SWF) was designed as a very efficient delivery format for graphics and animations over the
internet through web browsers and not as a format for exchanging graphics between graphics editors. It was designed to
meet the following goals:

• On-screen Display: The format is primarily intended for on-screen display and so it supports anti-aliasing, fast
rendering to a bitmap of any color format, animation and interactive buttons.
• Extensibility: The format is a tagged format, so the format can be evolved with new features while maintaining
backward compatibility with older players.
• Network Delivery: The files can be delivered over a network with limited and unpredictable bandwidth. The files are
compressed to be small and support incremental rendering through streaming. SWF is a binary format and is not human
readable like HTML. Macromedia Flash (SWF) uses techniques such as bit-packing and structures with optional fields, to
minimize file size.
• Simplicity: The format is simple so that the player is small and portable enough over the low bandwidth internet
connections as well. Also, the player depends upon only a very limited set of operating system functionality.
• File Independence: Files can be displayed without any dependence on external resources such as fonts.
• Scalability: Different computers have different resolutions and bit depths. Files work well on limited hardware, while
taking advantage of more expensive hardware when it is available.
• Speed: The files are designed to be rendered at a high quality very quickly.

Macromedia Flash (SWF) files have the extension .swf and currently the MIME type is application/x-shockwave-flash.

These SWF files can be played on virtually any platform's browser nowadays, which makes it a perfect environment for cross-
platform applications. This freedom has also brough the attension of the malware authors to use this file format to achieve
their goal. However, before getting into further details of how to this file format is exploited, let's just get a brief insight into
the binary structure of SWF.

Binary Structure:

A Macromedia Flash (SWF) file is made up of a header, followed by a number of Tags. There are two types of tags, Definition
Tags and Control Tags. The Definition Tags define the objects known as Characters, which are stored in the Dictionary.
The Control Tags manipulate characters, and control the flow of the graphics media.

The file starts with the string FWS or CWS, followed by an 8-bit version number and 32-bit file length field. In case of CWS all
the remaining file contents are zlib compressed:

[FWS] [Version] [Length] [Data] or [CWS] [Version] [Length] [Zlib Data]

The complete SWF specification can be found in the below link:

http://sswf.sourceforge.net/SWFalexref.html

An uncompressed data part of a SWF file starts with a header followed by a list of tags.
[Header] [Tag] [Tag] ...

Each tag acts as a container for a datatype, e.g. for a jpeg image, rgb color or an actionscript bytecode. A tag starts with a
tag type identifier and the tag's length, followed by arbitrary data.

[tag code and length (16 bits)] [data (length bytes)]

The complete SWF looks like this:

[FWS/CWS] [Version] [Length] [ [Header] [[Tag Code + Length] [Tag Contens]] ... [0] ]

As indicated, the last tag is a tag with tag type 0 and length 0 hence resulting in a 16 bit representation of 0.

File Compression Strategy

Since Macromedia Flash (SWF) files are frequently delivered over a network connection, it is important that they be as
compact as possible. There are several techniques that are used to accomplish this. Here are some things to look out for:

• Reuse: The structure of the character dictionary makes it very easy to reuse elements in a Macromedia Flash (SWF) file.
For example, a shape, button, sound, font, or bitmap can be stored in a file once and referenced many times.
• Compression: Shapes are compressed using a very efficient delta encoding scheme, often the first coordinate of a line is
assumed to be the last coordinate of the previous one. Distances are also often expressed relative to the last position.
• Default values: Some structures like matrices and color transforms have common fields that are used more often than
others. For example, for a matrix, the most common field is the translation field. Scaling and rotation are less common.
Therefore if the scaling field is not present, it is assumed to be 100%. If the rotation field is not present, it is assumed
that there is no rotation. This use of default values helps to minimize file sizes.
• Change Encoding: As a rule, Macromedia Flash (SWF) files only store the changes between states. This is reflected in
shape data structures and in the place/move/remove model used by the display list.
• Shape Data Structure: The shape data structure uses a unique structure to minimize the size of shapes and to render
anti-aliased shapes very efficiently on the screen.

Analysis of SWF Files:

If we wanted to analyze an SWF file, it would be best to uncompress where needed, parse the header and then break down
each tag by its code first. When doing so, we may encounter undocumented or unknown codes. There can be several reasons
for these mysterious tag codes, for example the file could be corrupted or our parser could be incomplete. However, it is more
likely that either a commonly used - yet undocumented - tag was used correctly according to the programmer's point of view
(tag type IDs 16, 29, 31, 38, 40, 42, 47, 49, 50, 51,52, 63, 72), OR the tag was deliberately marked with an unknown code in
order to hide bytecode or other data.

Intensional Deviation:

Keeping the above things in mind, we'll proceed along with the latter case. Let's assume that we are programming a malware
flash file. For that our code needs to avoid detection and should be obfuscated as well. The actionscript2 bytecode as located
inside doAction tags can issue a branch action (jump or goto) which is ordinarily being used for loops and conditions. Each
branch action comes with a relative address of the next action. Example:

0x00: action 1
…
0x01: some actions...
…
0x10: jump -0x10

Unfortunately the branch offset is not restricted to the current code block, but could jump to an entirely different tag instead,
where the code is being executed as if it were a code block. Example:

0x100: tag1 <--- header with unknown code

…
0x104: code in tag 1
…
0x200: doAction tag
…
0x204: jump -0x100

This way the code inside tag1 is hidden from ordinary SWF analyzer tools and can still be executed. In order to make it even
harder to find the hidden code, random bytecode could be inserted in between actual bytecode, or dormant bytecode (which is
never executed) could be used as distraction. Fortunately this technique is also really easy to detect since a checker only
needs to be able to check for uncommon branch offsets, however most disassemblers (such as flare) can be fooled. Another
interesting way to hide code, which is by far not the last one, would be a base64 encoded SWF file ebmedded in an image of
another swf file, such as

<img src="data:application/x-shockwave-flash;base64,..."/>

In the end it does not really matter, which way your code is protected or even if it is hidden at all, because there is no security
or malware check anywhere within a flash advertising deployment process. An evil attacker could simply buy ad space and
deliver ad.

Possibilities:

At times advertisers can use an ad system that require a pages to load JavaScript from another domain. This means
redirecting turn good.com to bad.com. This can happen for he below mentioned three reasons:
1: The advertiser's domain lapsed,
2: The bad company bought it
3: The JavaScript that was getting loading has a small chunk within it that redirected to the bad.com site.

In the first two cases, there is nothing you can do because it’s related with the other party (although you should not let this
happen). However, in the third case, it can be pointed out that Malware authors can intentionally hitch a ride into the users
computers through some trusted sources. Once an attacker can run JavaScript on your browser, very bad things can happen.
Decentralized content of a website increases the chances of security breach.

There are web pages that, when viewed, somehow redirected his browser to another, phishing web site. Initially you may
thing that the original web page just uses simple redirection (with or without help from JavaScript), but after analyzing the
original site you will f ind that phishers used something different and something more gruesome.

There can be web sites that can actually load a SWF (Macromedia Adobe Flash) file which will do the redirecting. It also means
that this method will work only if you have Flash installed. In todays context, keeping in mind the popularity and availability of
flash, SWF files can be played on virtually any platform's browser nowadays, which makes it a perfect environment for cross-
platform applications.

Tools for Analysis:

That was how I got interested into how to analyze actions embedded in SWF files so I found a few wonderful utilities that you
might want to add in your toolkit, in case you need to do the same thing in the future.

Jswiff
http://www.jswiff.com

JSwiff is a Java framework for SWF file creation and manipulation. As it’s completely written in Java, you can start JSwiff on
any platform. JSwiff is a very simple GUI based utility that will immediately show all SWF headers and tags.

Flare
http://www.nowrap.de/flare.html

This is a nice command line utility that can be used for quick analysis of actions in SWF files. Flare processes an SWF and
extracts all scripts from it. The output is written to a single text file. Only ActionScript is extracted, no text or images. It has
an accompanying utility called Flasm (http://www.nowrap.de/flasm.html) which you can use to even edit actions in SWF
files.

For Firefox Users:

There is an addon for Mozilla Firefox called Flashblock. It basically prevents all Flash content on a web page from loading and
lets you easily enable just the Flash content you want to see.

The addon is available at http://addons.mozilla.org/en-US/firefox/addon/433

Written By:
Rajdeep Chakraborty
Aka. MaliciousBrains
Site : http://www.malwareinfo.org
Blog : http://blog.malwareinfo.org
Forum: http://forum.malwareinfo.org
Email: maliciousbrains@malwareinfo.org
-------------------------------------------------
There are no patches or service packs for ignorance!