Flash File Protection

[BACKSHOT]

Hi Guys,

I'm hoping someone will be able to help out their in the Flash world!!

I am doing content for an eLearning site and the company I'm working for are concerned that the flash files arrive in the temp internet files that can be saved and kept on the machine for others to view or passed on to non paying others.

Is their a way without having to fill in username and password eveytime they view a flash file to stop the users from saving the temp files and running the files offline?

Any suggestions guys??

Regards

Davo

[Musicman]

Hi,

You could use anti-cache headers, but if you send hints to the browser to not cache those movies, a legitimate user who wishes to repeat or restart a lesson will have to download it again.
Using username and password is a good idea; you could use a cookie so that the computer remembers the data. Now what about "branding" the movies with a "welcome Mrs. Doubtfire" greeting that is built into the movie - few viewers would know how to remove or change that name ... and those probably would know how to leech the swf, too

Musicman

[NCD]

If you're worried about people trying to use the files offline you can always code a check within the movie using the loadVars object that checks the company's server for a variable located in a text file. If it can't call up the server then it should error.

Unless the file finds the enabling variable on the remote server, the whole things doesn't do anything. It's what I use in all my samples so that if a client won't pay I can shut them down by removing the file from my server.

You can set it up to do 2 things:

1) gotoAndPlay() whatever frame label you tell it to (enabling or disabling the swf). If you disable it then you can have a text message in the remote file that gets displayed in a dynamic text box. Very easy to do and you can customize your message to whomever tries to view the file, depending on how obnoxious the non-paying client is. NOTE: Use a diferent text file for each individual sample and name it so it's descriptive of which sample and which client the file is keyed to. This way you can shut down individual samples and/or deadbeats without shuting them all down.

2) If it can't find the file then it shuts down and apologizes for a server error. Be nice with this one... if it's an honest server issue, then you don't want the client to see a message claiming that they haven't paid.

NCD

[BACKSHOT]

First, Thankyou for you help!!

How do you do anti-cache headers? I've never heard of them? Is there a tutorial or anywhere I can look to see how this works?

I might try both of these methods together for extra security. Thankyou both for your flash guidance!

Regards,

Davo

[NCD]

Well, good news and bad news....

The good news is that I've learned a lot more about this subject since I posted.

The bad news is that there seems to be no sure-fire way to protect an swf. This is due to swf can-opener applications that can get at and alter the script inside a published file. So, any protective action we take could theoretically be circumvented by someone who was relly determined.

Anti-cash headers can be used when delaing with the loadVars object and loadVariables to ensure that the browser checks the web for the latest version of a file rather than re-using the same old cache file over and over again. Problem is, it doesn't always work because it relies on browsers to do what they're supposed to and we all know that's like spitting into the wind... maybe you'll stay dry, maybe not.

Another sneaky method takes advantage of the fact that the flash player doesn't care what file extension is attatched to a file as long as it can read the contents. This is useful because you can then purposely over-cash a file in order to ensure that the browser is always checking the web rather than re-using a cache file. It's useful in this way because what you're doing is creating many copies of your file in the browser cache that are named differently but if you cheat by naming them with a gif or jpg extension rather than swf then all but the sneakiest of hackers won't realize where you hid the code.

EG:
Name your real swf file "logo.jpg" (yea but just follow this)...

Now when you want to load the file you use an empty movie clip for your embedded swf and that empty clip uses loadMovieNum to import your real swf and place it on _level1 this way:

//Create a random number
smokeScreenNumber=Math.round(Math.random()*100);
//Append the number to the end of the file name when calling
loadMovieNum("logo.jpg?V"+smokeScreenNumber, 1);

This will place a query string after the file name (EG: logo.jpg?049) but it won't affect the operation of your real swf one bit! The schmuck who is looking to steal your code sees only one swf in the cache and that one is useless to him. Most people totally will overlook jpg and gif files in the cache, thinking that they're just more of thousands of image files stashed in there already. THe fact that IE names cache files with cryptic numerical names makes it harder on the thief who is looking for your code, and helps you hide it by not showing him the name "logo.jpg" at all.

And flash won't care if you name the extension .googlyMoogly as long as it can read the contents. It'll run it as normal no matter what the file's named.

The browser wants an exact match to the file name before it uses the cached version... so odds are 1:99 against that happening. If you use a higher number then you make a match nearly impossible but who makes 1,845,934,534 versions of a logo jpg? The theif will know that something is up if he does somehow manage to see the file's real name.

Someone using a can operner application will see your code that loads the jpg but if they're not good at scripting then they won't figure out that this one jpg they see being loaded isn't really a jpg at all... and if they could code worth a darn in the first place then they probably wouldn't be trying to steal you code.

NCD

[ilya_cat]

I can protect your ActionScript. Now nor ASV4, nor Flasm, nor Flare couldn't deprotect my code - only one way is reading flash bytecodes for manual decoding.

Mail me to ilya_cat@mail.ru , if you want to consult with me.

Excuse for my bad English.

[Musicman]

Hi Ilya,

current decompilers all do some sort of pattern recognition on the bytecode, to find the original AS
Now, of course they attempt to recognise the nost common compiler, flash. They probably recognize patterns produced by other common software, e.g. the Genable obfuscator.
Be assured that, once your method becomes widespread, the decompilers will look for code protected by your system

Musicman

[ilya_cat]

I use a randomly mixed selfmade techniques, so hard to make decompiling algorithm.
Excuse me for my bad English

[Musicman]

Hi Ilya,

did you follow the ASO "winning award" thing a while ago?
The technique they used is a branch around a piece of bad code - actually a variable pool. The pool command is never executed but decompilers will use its incorrect length and so miss the next real statement. You say you are mixing several tricks - that is really better than just repeating one over and over again

Now to introduce their new product Genable made a contest which was actually about reversing a md5 written in actionscript - and even if decompiler ran mad, it was possible to see from the bytecodes what the real riddle was. Of course nobody won the prize...
but within one week after the contest was launched, Buraks could handle this particular code


Musicman

[moh_design]

hi all

just to let u know i test Action Script OBFuscator v1.32(aso) with action script viewer v3.1 and the result that asv can't decompiler the code for flash movie

but with action script viewer v4 u can decompiler the flash movie protected by aso v.1.32


maybe u can help us ilya

Buraks want to kill us by his program
also the new app from Buraks Action Script Replacer the big problem

the swf is not secure anymore with Buraks softwares
thanx

[Musicman]

Hi,

dont blame Buraks - all he has done was creating a program from knowledge that is public.
Some people always were able to read the code of your swf's, and could probably have abused it (e.g. to win prizes in games they never played) and nobody was really aware of it.
Now that there are many more, developers get concerned. However, keep this in mind: no decompiler will turn your code into a commented listing, let alone a complete tutorial - if you developed a really complex piece of code chances are that the thieves do not understand it. You can "help" on that greatly by doing, erm... manual obfuscation: before finally publishing the movie, replace all vriable, instance etc. names either with random garbage, or, even better, with completely misleading names

Musicman