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 crossplatform 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: … 0x104: … 0x200: … 0x204: tag1 <--- header with unknown code

code in tag 1 doAction tag 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 crossplatform 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!