Hack 98 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 [Hack #97] 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 SettingsFlash 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 [Hack #97] so that
it can be imported back into Flash. Compressing the SWF
(FilePublish SettingsFlashCompress
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:
He will most likely not even look at it further, because its name implies a rather mundane GIF slice for an HTML table.
If he decides to open it, his GIF-reading software will tell him it is a corrupt GIF file, and he will most likely give up.
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
FileSave 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.
|
Final Thoughts
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.
