Total code transparency: "allComplete" and PreloadSwf (mm.cfg)

[joshstrike]

I don't know how many of you are hip to this; there's no way to describe it other than a well-known, massive security flaw that Adobe tried to hide through obscurity, that's basically now the pathway of choice into the guts of any and every .swf out there. Forget decompilation; even after you obfuscate and encrypt, we're talking about an easy way to hijack your scripts on the fly without even needing to read the bytecode. There's a secret event triggered by every swf upon init (and after INIT) that gives the swf as a useful target to any local swf running that's listed in the mm.cfg file, regardless of security domain or crossdomain restrictions.

Here's the link to the manual on the subject:
http://jpauclair.net/2010/02/17/one-...ty-preloadswf/

But what's interesting is that in perusing the Russian-speaking web, this has already been well known and blacker hats are angry it's been let out.

There are few ways to defend against this type of attack. The targeted SWF has virtually no way of knowing that it's been loaded with this preloader; there are a couple of giveaways that I'll let you figure out for yourselves, but they're dependent on the structure of the SWF doing the preloading. Your best bet is to try and find a way to trigger a call to the preloader itself, because that will throw a security sandbox error (but will only do so within the preloader, so it won't be catchable...keep looking). Given the need for analytic tools, it's likely that Adobe will allow this to ride. In one sense, it's just a kind of local reader. On the other hand, it means that any form of encryption or obfuscation you put on your code is a complete waste of time; this exposes everything instantly and makes it very easy to write classes that directly override your own.

[jAQUAN]

Thanks for the heads up Josh. I'm going to discuss this with my team.

[jpauclair]

I don't know how many of you are hip to this; there's no way to describe it other than a well-known, massive security flaw that Adobe tried to hide through obscurity, that's basically now the pathway of choice into the guts of any and every .swf out there. Forget decompilation; even after you obfuscate and encrypt, we're talking about an easy way to hijack your scripts on the fly without even needing to read the bytecode. There's a secret event triggered by every swf upon init (and after INIT) that gives the swf as a useful target to any local swf running that's listed in the mm.cfg file, regardless of security domain or crossdomain restrictions.

Here's the link to the manual on the subject:
http://jpauclair.net/2010/02/17/one-...ty-preloadswf/

But what's interesting is that in perusing the Russian-speaking web, this has already been well known and blacker hats are angry it's been let out.

There are few ways to defend against this type of attack. The targeted SWF has virtually no way of knowing that it's been loaded with this preloader; there are a couple of giveaways that I'll let you figure out for yourselves, but they're dependent on the structure of the SWF doing the preloading. Your best bet is to try and find a way to trigger a call to the preloader itself, because that will throw a security sandbox error (but will only do so within the preloader, so it won't be catchable...keep looking). Given the need for analytic tools, it's likely that Adobe will allow this to ride. In one sense, it's just a kind of local reader. On the other hand, it means that any form of encryption or obfuscation you put on your code is a complete waste of time; this exposes everything instantly and makes it very easy to write classes that directly override your own.

It is true that it gives a lot of power to the one that "hook" onto the swf using the preloader, but you can't do everything. For instance, you can't override classes, you are in a separate security domain hence you don't have access to all events and there is a lot you can't do.

you can read almost everything tho.

Still, encyption is useless, but obfuscation still is the one and only way to "protect" your code.

Take a look at an article I made after discovering that feature:
http://jpauclair.net/2010/09/12/flas...adprofilerbet/

[joshstrike]

Hi Jean-Philippe, it's great that you found this post and wrote in so quickly. I actually tried to contact you yesterday on LinkedIn to get your opinion on something, before I posted it.

I've been aware of the method you brought out with this and I've been following your blog for a few months, since around the time I got interested in ways to improve Nikita Leshenko's encryption method here:
http://active.tutsplus.com/tutorials...ng-encryption/
... also you might be interested in the response from people here to the allComplete event being exposed (you'll need to translate it from Russian): http://m.habrahabr.ru/post/84736/

Anyway, it's a back door by any definition...it makes it very easy to hijack code without having to decompile or de-obfuscate...it makes it easier to expose tokens and data sent in over a socket in realtime while the tokens are still good, without recompiling anything, and easier to inject bad data on the fly.

There's a manual encryption solution with an obfuscated decryptor that can make an swf very hard to decompile except by reading and editing large parts of the bytecode directly, but this does an end run around it.

Luckily, though, there turns out to be a nice way to stop PreloadSwf in its tracks I hit it by accident yesterday when I noticed something funny happening with a checkbox control.

Anyway, I hope you'll stick around Flashkit, it's a good place to give advice, keep skills sharp when you're bored. Let me know if you try to break the site I sent you via LinkedIn.

[joshstrike]

Oh, and your profiler does look awesome, btw. Very nice piece of work.

[jpauclair]

Hi Jean-Philippe, it's great that you found this post and wrote in so quickly. I actually tried to contact you yesterday on LinkedIn to get your opinion on something, before I posted it.

I've been aware of the method you brought out with this and I've been following your blog for a few months, since around the time I got interested in ways to improve Nikita Leshenko's encryption method here:
http://active.tutsplus.com/tutorials...ng-encryption/
... also you might be interested in the response from people here to the allComplete event being exposed (you'll need to translate it from Russian): http://m.habrahabr.ru/post/84736/

Anyway, it's a back door by any definition...it makes it very easy to hijack code without having to decompile or de-obfuscate...it makes it easier to expose tokens and data sent in over a socket in realtime while the tokens are still good, without recompiling anything, and easier to inject bad data on the fly.

There's a manual encryption solution with an obfuscated decryptor that can make an swf very hard to decompile except by reading and editing large parts of the bytecode directly, but this does an end run around it.

Luckily, though, there turns out to be a nice way to stop PreloadSwf in its tracks I hit it by accident yesterday when I noticed something funny happening with a checkbox control.

Anyway, I hope you'll stick around Flashkit, it's a good place to give advice, keep skills sharp when you're bored. Let me know if you try to break the site I sent you via LinkedIn.

Can you tell me a bit more about the solutions you are talking about? the encryption one and the checkbox one?

Do you know any hacker that were using this technique?

Btw, I don't consider it as a security hole because you "should never trust the client". You also have other software like Pix, or PerfHud or jRat or things like that that get many info like this preloader does.

The thing is, you should have a flag in you SWF preventing preloading. or managing right like "read/write access"

Anyway... since I found that thing, I use it so often I really wouln't want them to remove it!! haha

[joshstrike]

Anyway... since I found that thing, I use it so often I really wouln't want them to remove it!! haha

Yeah, I figured that was probably a motivation for you. As a tool for code analysis it's great, and fast, although analyzing your own code could also be accomplished by adding analytics classes to your root when you compile, turn them on by uncommenting when you want to debug, it doesn't take any longer than changing mm.cfg and relaunching firefox.
But as long as Adobe want to sell analysis tools for $500 a piece, they're going to have to have something like this method.

I know you should never trust the client, but if you obfuscate manually at the bytecode level, you can make code that can't be re-compiled from decompiled output without a long and patient process of reading the raw bytecode. Even I wouldn't want to try to put my own code back together after doing this to it. From what I can tell, and I could be wrong about this, any decompiler that tries to run the code is doing its own sort of preloading, and a hack like GuardBunny or something that looks for loadvars can be enough to bring it down. If it doesn't run the code, like SWFScan, then it also can't evaluate certain things, making it virtually impossible to piece the bytecode back together. Take a look at the link I sent you...you'll see what I mean.

Anyway, there is a statistical advantage to a developer in eliminating 99.9% of people trying to sniff through the client. To me, the point of good obfuscation + encryption is to protect original methods and algorithms, making it harder for someone to read the source than to just rewrite it from scratch. allComplete does an end run around all of that careful obfuscation.