|MySQL Conference and Expo April 14-17, 2008, Santa Clara, CA|
Hacking Flash, Part 2
Protect and Obfuscate Your Flash Files
Make it difficult for others to steal or reverse-engineer your online Flash content
Your carefully honed Flash designs may not be as safe from theft as you'd like to believe. For example, the URL Action Editor (http://buraks.com/uae) allows someone to change the arguments of any URL-based actions that a SWF uses. Someone could take a SWF that loads in your content and rework it to load in his content, or worse yet, pass of your content as being his own.
In at least one clear-cut case, a well-known designer decompiled the code of another well-known designer and passed it off as his own on a resource site. (Hint to the thief: next time, change the variable names to avoid suspicion!)
Protect the SWF
The Flash authoring tool allows anyone to load an unprotected SWF directly. You can protect your SWFs from import into Flash by checking the Protect From Import checkbox (under File→Publish Settings→Flash tab). However, other applications (such as a text editor) can still open your file, and decompilers such as ActionScript Viewer (http://buraks.com/asv) can unset the protected flag so that it can be imported back into Flash. Compressing the SWF (File→Publish Settings→Flash→Compress Movie checkbox) helps obfuscate your work because the compressed data is harder to decode than the raw SWF.
Technological protection is never foolproof. A clever cracker—we reserve the term "hacker" for innocent tinkerers such as ourselves—can break any protection scheme given enough time. The trick, therefore, is to present the cracker with sufficient obstacles—each one making the solution more obscure and time-consuming—so that he simply gives up.
Games and commercial applications often use a single protection scheme they consider unbreakable, but crackers seem to enjoy the challenge. And the Flash Player browser plugin must ultimately display the SWF content. So if you are going to publish your SWFs, they are unencrypted on the user's machine, even if you serve them from an HTTPS server. Even if browsers supported encrypted playback, a resourceful cracker could capture the images as they are sent to the video card or the audio as it is sent to the sound card.
So our first technique is obfuscation. The aim is to dissuade or delay the cracker by hiding the nature of the protection scheme rather than using an obvious mechanism that seeks to be 100% secure.
Obfuscate ("Dummy") the File Types
We know that all the files for our site will end up in the cracker's browser cache. To find a SWF file or MP3 file, the cracker simply has to look for the right filenames. To make life difficult for the cracker, even at this initial stage, change the file extensions and filenames of crucial files.
For example, consider a streaming MP3 file asset loaded at runtime:
my_sound = new Sound (this); my_sound.loadSound ("song.mp3", true);
Suppose you are writing a Flash-based music jukebox for a recording artist. To avoid a cracker finding your MP3 file and immediately putting it in his Napster/WinMX file-sharing folder, simply change the MP3's filename to an obfuscated name such as top_header_02.gif and modify the code to read:
my_sound = new Sound (this); my_sound.loadSound ("top_header_02.gif", true);
Flash ignores file extensions when loading external files (it assumes that you are loading a sound file regardless of the filename and file extension passed to the Sound.loadSound( ) method). Unless the cracker's operating system looks at the files' contents to confirm file extensions are as advertised (and the last computer I used able to do this was the Commodore Amiga!), he cannot easily determine the file's type.
Readers who have done traditional web design probably already have a big wide smirks thinking about the downright dirtiness of this hack, but here's a rundown for everyone else.
When the cracker looks in his browser cache for any useful media goodies, he will see top_header_02.gif and:
If the cracker starts looking at the domain and time properties of each file in the browser cache or has specifically saved the whole web page and its embedded media (in IE this can be done using File→Save As), he may smell something fishy. Even once he is onto the trick, it may take a long time for him to realize the so-called GIF is in reality an MP3 file. The altered file extension will wrong-foot both the cracker and his operating system. He has to be prepared to open every file in the site to find a file to steal, or he has to decompile the SWF and look for, say, loadSound( ) commands.
If you are feeling particularly evil (and this is a real hack from the dark side), you can rename the filenames using system file types that would tend to crash the cracker's operating system if he double-clicked them. Windows actually warns users who try to fish around in the browser cache that double-clicking on anything there could have dire consequences, so consider your victim to have had fair warning. Naturally, some of these techniques don't apply directly to the Mac OS, but changing the file extensions will confuse crackers on both platforms.
WARNING: If you use this hack, keep a record of each file's true type. Keep your "dummied file versions for upload" separate from your development files. Make sure you have a backup policy because the protection may backfire on you one day when you're the one who needs to decompile the SWF.
The designer who takes inspiration from your work is doing nothing wrong. Even if you do not take this as a compliment, there is little in law and reality you can do about it. You can copyright your expression of an idea but not the idea itself. Although a utility patent can protect an idea, most ideas are not unique enough to be patented, and applying for patents is too expensive and time-consuming to be of practical use. In many cases, even patents offer little protection. A little-known class of patents called design patents can protect designs such as the shape and translucent color case of the original iMacs. But even Apple's legal department couldn't prevent PC manufacturers from quickly imitating the product design.
Although your content theoretically enjoys copyright protection the moment you put it in tangible form, and you can register your copyright for marginal extra benefit, it is next to impossible to enforce copyrights in an international medium such as the Web. And in most cases of misappropriated Flash designs, there is no provable economic damage from copyright infringement, so there is little restitution to be recovered and little use in crying foul.
A better route is the technical one, mixed with a little social engineering. If a cracker wants to save time by using your assets, the trick is to make stealing your content take so long as to not be cost effective.
View catalog information for Flash Hacks
Return to the Web DevCenter
Comments on this article
1 to 2 of 2
Hacking Flash, Part 2
2004-08-08 17:27:51 [View]
1 to 2 of 2