Flash security: Protecting against PreloadSWF (SWF Hijacking)

Finally! here is a half-answer.

If you have read my last posts, you now know the power of Flash hijacking via preloadSWF.
I never given a lot of feedback about how to block this attack because I didn’t know any.

I’ll skip some step on how preloasSWF work, if you want to know please read my previous articles: One SWF to rule them all! and FlashPreloadProfiler
And for those who didn’t knew yet, the last version of FlashDevlelop now support PreloadSWF easy integration for profiling your application with FlashPreloadProfiler!

Case study

The only thing happening before a SWF loaded (allComplete) callback is the constructor of that loaded SWF.
This means it’s the only moment you have to “do something”

Let’s suppose you have a project you want to keep the code from being: viewed, modified, copied.
And let’s suppose you have some kind of classic setup:
A obfuscated launcher, embedding an encrypted SWF containing the whole code base.
In its constructor, the launcher create a key, that decrypt the embedded SWF and use loadBytes to instantiate it before adding it to the stage.

The Basics

The whole protection reside around one very simple flash behavior.
When a SWF gets loaded, FP give a (incremental) name to the root object.
The first one being loaded is called “root1” and then “root2” etc.
This also applies to the preloaded SWF which is loaded first, hence is being named “root1”

The one who identified this behavior was one of my new friend Josh
We also exchanged a lot recently on what could be done to prevent preloadSWF hacking. In fact, he challenged me!

Knowing the root1 trick help a lot because it is a native behavior on a read-only property.
So when you start an app you can always detect if there is some other app spying on it by adding this to your code:

if (root.name != "root1") { while(true) { /* do nothing*/ } }

and it will freeze the whole app indefinitely.

No more app hijacking using PreloadSWF!

The fight still goes on

You only solved half the problem. Now an attacker could not run your app with a preloader, but it would still be able to retrieve your decrypted codebase because you have a nice feature in flash preventing the process to hold the CPU for too long (15 sec.). After a few secs, the player is going to throw an error. If you choose to cancel, or continue, it won’t change a thing. The preloadSWF is going to be called anyway.

You MUST not start processing (decryption, loadBytes, etc) the main file before bugging the process with root.name!=”root1″ and here is why:
If you have started loading your main SWF in the constructor or the init function, you’re about to get hacked.
When the preloadSWF is hooked, it can access the loader used to download the main SWF and read the whole unencrypted SWF by using the loader.loaderInfo property “bytes”. When the attacker have access to the unencrypted files data. He still have to save that data somewhere from the preloader in order to reverse engineer it. Using clipboard copy of bytes would not work because it would required a mouseEvent (which you don’t have).
Still, a simple encoding before outputting it in flash traces would do the trick:

trace(Base64.encode(loaderinfo.bytes)) 

You can now post-process the file. easy!

ping-pong

One might think “I’ll hide the loader in a private var, or lose the pointer until the loading is done so that the preloader would not have access to it.
Retrieving the loader pointer is simple enought: Use SamplerAPI object instantiation to get that object pointer without even searching for it in the code.
So if you want to protect against samplerAPI object discovery attack, make sure you call clearSampling() and stopSampling() at the end of your constructor or initialization function.

PreloadSWF user Identification

you don’t have access to a lot of thing in flash that might help you identify who’s profiling your app. You have access to the IP and a few params, but not much!
Here is how to get “the local path” of the preloader SWF of the client machine:
First, in your application constructor, add a “allComplete” event listener just like the preloadSWF does.
Also in the constructor, use the samplerAPI and start cumulating samples using startSampling();
Then when you receive the allComplete callback, read all samples, there will be some undefined
object in there due to SecurityDomain mismatch, but you’ll have the actual StackTrace of the activation-object created. It looks like this:

new undefined [activation-object](),root1/allCompleteHandler()[C:\Dev\jpauclair\FlashPreloadProfiler\trunk\src;;root1.as:73],[all-complete]()

As you can see, the root1 is being used in the preloadSWF. And … here is my name!

ping-pong again

The preloader only have to clearSampling manually to counter this technique. Preloader win again…

Loading a SWF in “stealth mode”

As soon as you use loader.load or loader.loadBytes, a allComplete event will be dispatched giving the bytearray data to the preloader.
I found only one way to “merge” a main file or a library into the current applicationDomain code without having the preloader “seeing it”. Sadly, it’s not a good technique for production.
The trick is to add a parameter in you SWF main class constructor. This is going to throw an error as soon as the SWF is loaded and the allComplete event will not be dispatched at all!
Still, the loaded code is already merged with the current applicationDomain and you can use “hasDefinition” and “getDefinition” to instantiate the classes you want.

Summarizing

-PreloadSWF can hook on any SWF
-crash the app as soon as your app root.name != root1 (there was a preloadSWF loaded first)
-Do no start loading your main code base (engine, library, etc) before checking for preloader first.
-There are way to identify preloadSWF file path by using SamplerAPI

References

Josh
AS3 hidden treasure in the mm.cfg file. Revealing and documenting many Flash secrets!
FlashPreloadProfiler
One SWF to rule them all : The Almighty PreloadSWF
FlashDevelop 3.3.0 RTM supporting preloadSWF
AS3 – Hacking PreloadSwf for fun and profit