Hack 97 Recover Content from a SWF

SWF decompilers can be used to "crack" a SWF file. Use them to recover your own content if you lose the source FLA.

Picture the scene. You have been given the job to update a Flash site. If you are fortunate enough to be the original developer and have a robust backup system in place, you should have all the source files you need. In reality, that is rarely the case.

Before we look at protecting your SWFs from content thieves [Hack #98], let's review situations in which decompiling SWFs has a legitimate purpose.

You might not have the latest source files because:

• The client made changes to the version you provided, so you need to obtain the latest version as a starting point.

• You weren't the original developer and the previous developer has left multimedia development to pursue a career in Hollywood.

• The client had the foresight to request the FLA files as part of the original contract, but the sys admin assumed the source files were on the server, so he deleted all files that don't do anything cool when you double-click them. Anyway, he says, "You should be able to download and update the online files like you can with HTML and Notepad, right?" Ummm, no.

• You are the original developer, but you have changed offices twice since the original site design, and the last backup CD-ROM you can find has an incomplete/older version of the site on it. You archived all the files, including JPEGs and MP3 files, as a ZIP file and the whole archive is corrupted and its contents irretrievable. Or you backed it up on a DAT tape and can't retrieve the files successfully.

So, often, you'll have only the SWF and HTML files on the server from which to work. Although there is no way you can get back the complete FLA file-Flash eliminates significant portions of the information in the FLA when it compiles down to the SWF-you can get enough of it back to make rebuilding the FLA via a decompiler far easier than starting again from scratch.

If the SWF hasn't been saved with the Protect From Import checkbox selected (under FilePublish SettingsFlash), it can be opened directly in the Flash authoring tool. This is good news for you if you're trying to recover content and bad news if you are trying to hide your content from others [Hack #98] .

Although you could roll your own based on the publicly documented SWF format, a number of SWF decompilers are publicly or commercially available. They include:

• ActionScript Viewer (http://buraks.com/asv) was the first to hit the market and is well-respected.

• Flash Decompiler (http://www.flash-decompiler.com) claims to be fast and easy to use.

• Sothink Decompiler (http://www.srctec.com/flashdecompiler) offers support for ActionScript 2.0 and a SWF Catcher feature to retrieve files from the browser cache.

• Flare (http://www.nowrap.de/flare.html) is free (as in beer), runs on Windows, Linux, and Mac OS X (command-line versions available), and the Windows version supports decompiling from the context menu (right-click).

A decompiler uncompiles the SWF bytecode and extracts parts of the compiled SWF back to the original source files (a.k.a. reverse compilation) or to a form that allows you to make them editable again.

We will look at using ActionScript Viewer (ASV). You can download a free trial of ASV 3.0 from http://buraks.com/asv. Although the trial version is feature-limited (it decompiles only the first 5 frames in each timeline and the first 25 lines in any script) and it does not support Flash 7 (the latest full version, ASV 4.0, does), it is enough to give a flavor of the decompilation workflow and what you can (and cannot) do. Even if the SWF has been protected from import, ActionScript Viewer allows you to unset the "protected" flag in a SWF (under the Special Tags tab), making it possible to import the file into Flash.

The ASV 3.0 Interface

When you open a SWF in ASV, you will see a window similar to Figure 12-2, although you may see fewer tabs because some tabs may not be appropriate for the current SWF.

Figure 12-2. The ActionScript Viewer 3.0 interface

Although a large number of options are available, you need to do only three things to get back to the FLA:

• Extract the ActionScript listings.

• View what the original timeline looked like, including the contents of each keyframe. You also need to know all instance names.

• Extract the Library, complete with any linkage identifiers.

We will look at how to do all of these quickly in the following sections.

Extract ActionScript

To view all ActionScript contained within a SWF, select ASV's ActionScripts tab, as shown in Figure 12-3, and select any of the scripts listed in the top pane. The code appears in the bottom-left pane. To save this script as a text file, you can choose UtilitySave ActionScript (as Text). Or, if you also have Flash open, you can copy and paste the ActionScript from ASV into an open FLA document.

Figure 12-3. ActionScript Viewer 3.0's ActionScripts tab

View the Original Timeline

Click on ASV's Timeline tab to view the reconstructed timeline, as shown in Figure 12-4.

Figure 12-4. ActionScript Viewer 3.0's Timeline tab

The first layer of the timeline shows all frame labels and ActionScript attached to frames. The remaining layers constitute ASV's best guess as to what the content-holding layers need to look like to reconstruct the working FLA. You can export the timeline as a series of SWFs (one per reconstructed layer). For simple layers containing no tweens or numerous keyframes, you are better advised to simply replicate the layers in a new FLA. If you prefer to replicate the timeline manually, you also need to know each instance name on the timeline. You can review a list of instance names via the Instance Names tab (if this does not appear, it is because no instance names were used, as is typical in a SWF that contains no scripting).

ASV cannot retrieve the original timeline layers and the Library symbol names, which exist in the FLA as authoring aids only. The decompiler makes best guesses to reconstruct the missing information (such as to assume one layer per symbol or graphic and use default names such as Symbol 23 and Layer 6). Layers that held no content in the original FLA (including guide layers and layer folders) are not exported into the SWF, so the decompiler cannot reconstruct them.

Extract the Library

To export the Library, select ASV's Library tab, as shown in Figure 12-5, then right-click (Windows) or -click (Mac) on any symbol and select Save All Library Symbols as SWF.

Figure 12-5. ActionScript Viewer 3.0's Library tab

You can import the SWF symbols back into Flash using FileImportImport to Library. After importing them, you must rename the symbols into something meaningful and manually define the linkage identifiers for each symbol (linkage identifiers are not exported from ASV even though they appear within square brackets in the ASV Library tab adjacent to each symbol name).

Final Thoughts

Although the decompilation process can be time-consuming for large or complex SWFs, it is still much faster than starting from scratch. You are able to retrieve the two most important assets from the SWF: the ActionScript and the Library symbols. Even if they are the only assets you extract, this will save considerable time.

Another use of SWF decompilation is to see exactly what your SWF contains and whether you are making the best use of the filesize. Furthermore, decompilation is useful if you want to get a better understanding of how Flash content works in general and exactly what the Flash Player sees.

Of course, decompilation can also allow others to steal your content or (more likely) to deconstruct your ideas without permission.

Once a content thief has your SWF open via a decompiler or code changer (such as URL Action Editor, http://buraks.com/uae), the potential for stealing your work (and reasons for doing so) are possibly even greater than that offered by HTML because:

• A Flash SWF can contain a major portion of your site's contents in very few files, making them easy to locate.

• Media assets are more costly to develop than static web pages. The media, graphics, and scripts contained in your Flash masterpiece require a broader set of skills (musical, animation, scripting, video) to create than would an HTML page consisting of images and text.

• A Flash site is usually more configurable than a standard HTML page. By tweaking the code contained within a SWF, a content thief can quickly repurpose a stolen Flash web site to look and feel different. I have seen a number of sites that look suspiciously as if the designer had copied symbols and scripts from two or three other well-known Flash sites and just combined them to create something "new"!

When presented with the tools and opportunity to decompile SWF files, you often have a moral decision to make. If the developer did not provide publicly available FLA files, she probably doesn't want you reverse-engineering her code, although doing so for research purposes isn't necessarily illegal. If you are going to look to other developers for inspiration (as many hacks in this book do!), you can get that by simply running the SWF in the Flash Player. Take the high road and do original work rather than misappropriating the work of others without their permission. If you want to learn how to program in ActionScript, read a good book like ActionScript for Flash MX: The Definitive Guide or Essential ActionScript 2.0, both by Colin Moock (O'Reilly).

Remember that if a client sends you SWF files and says he couldn't get the FLA files from the original developer, you are right to ask questions. The original developer's contract might indicate that the source FLA files were not part of the deliverables. You could be liable for copyright infringement if you misappropriate the original developer's work. At a minimum, make a good faith effort to verify the client has the rights to the FLA files, especially if he doesn't possess copies of them. And make sure the client indemnifies you in your software development contract so that any materials he provides improperly are his liability and not yours.