FlashInCrypt

A very cool tool was found recently and it went away with a thumbs up on all tested counts. Even ASV and Flasm were left bewildered and they cannot open the file obfuscated with FlashInCrypt. No obfuscater was able to escape ASV or Flasm before but this one is proving to be a must-have, real obfuscater.

But then, there was one worry before we embark on the test, “What if it could not read and interact with the external configuration xml file” that usually happen on all projects here. Fortunately, the swfs obfuscated with FlashInCrypt was able to work very well with the external config xml. So, it proved successful in this scenario too where the internal ActionScript interact with the external raw config data (settings, defaults).

In our lab tests, we were unable to see the source code in any format, probably once ASV comes out with a patch/fix to account for this obfuscation then things might be different (Burak should stand up a bit and take notice of this!). Flasm was confused by this obfuscater, so there isn’t any means of see the DMM (Dynamic Memory Modification) in action. Well, the best bet here is that, it might be doing some code wrapping to confuse ASV.

A minor hiccup with the app was their English on the Dialogs, Confirmations, etcetera. On the overall, this is a real cool tool at such cheap rate.

Brajeshwar posted this article on Wed, Nov 3rd, 2004 at 7:20 pm
Categorized under Reviews

Suggest 1 or more tags for this article

Use a comma (,) to separate 2 or more tags.

[?]

Type in a relevant tag, and click the button, and help organize this blog's information.
[More Help]

Comments Post Yours

There are 8 responses so far. You can follow any responses to this entry through the RSS feed. You can skip to the end and leave a response. Pinging is currently not allowed.

Burak KALAYCI November 3rd, 2004 at 8:34 pm 1

Hi,

As I’ve stated in the comments at my blog at http://www.asvguy.com/2004/01/the_swf_flash_d.html we will not be jumping on bypassing this one - in line with our policy change.

Nevertheless, we will bypass it as much as we can once another decompiler does this - or in case we find it necessary.

Removing an action or changing variable function names is not reversible. But anything that crashes ASV (this one doesn’t), or makes ASV not show the correct bytecode (p-code), can be reversed, and quite easily.

So, nobody should think this kind of a protection will last forever (They state this on their site as well).

Also, there might be problems with future Flash players.

And yes, introducing itself as ‘a professional grogram’ (with a ‘g’) doesn’t make a very good first impression. (There’s no clue on where these guys are from on the site).

In any case, we will continue supporting our customers promptly, on case by case basis, with their SWF files whether protected or not.

Best regards,
Burak
IgorKogan November 4th, 2004 at 4:19 am 2
Hi there,

I’ve looked at the example file provided by the firma. I’m not sure what their actual protection is supposed to be, but the trick they use to disable disassembly isn’t a very good one. They simply jump into the middle of the swf action, which happens to work in the Flash Player right now. However, there is no guarantee it will continue to work.

The topic was discussed often enough:
security through obscurity. It would take half a day to teach Flasm this particular trick. And even without that, it took me 10 minutes wiath a hex editor to reveal the code. The function in question (decompiled with Flare):
```
_root.onEnterFrame = function () {
  myDate = new Date();
  hourHand._rotation = myDate.getHours() * 30 + myDate.getMinutes() / 2;
  hourHandShadow._rotation = myDate.getHours() * 30 + myDate.getMinutes() / 2;
  minuteHand._rotation = myDate.getMinutes() * 6 + myDate.getSeconds() / 10;
  minuteHandShadow._rotation = myDate.getMinutes() * 6 + myDate.getSeconds() / 10;
  secondHand._rotation = myDate.getSeconds() * 6;
  secondHandShadow._rotation = myDate.getSeconds() * 6;
};
```
Igor
P.S. Don’t know how to preserve the formatting in your comments, sorry.
zhen November 7th, 2004 at 8:08 am 3

I agree with Burak and Igor that injecting unaligned code into swf may not work with future Flash players. And it’s extremely easy to remove. It took me about 20 minutes to write a small program “FINI” that automatically strips non-standard bytecode and tags off an “incrypted” swf file.

Here is the link:
http://genable.com/aso/fini.html
Burak KALAYCI November 7th, 2004 at 8:12 am 4

Genable released http://genable.com/aso/fini.html, and we will be bypassing
the protection with ASV (and our other tools). It took us about 10 minutes
to do that, we will be releasing updates in a day or two…
Tony November 7th, 2004 at 9:24 am 5

The Fini was published by Wang Zhen, he posted the thread here. I do not know what the relationship between ASO and ASV is. Burak said that “we will bypass it as much as we can once another decompiler does this “. ASO help Burak to carry his point. It is so interesting thing.
I do not know what Flashincrypt will do. And I do not know what the as-protect will do. Maybe the winter of protection tools comes.
Dani?¥l T. November 11th, 2004 at 1:56 pm 6

Sorry, just found out that FlashInCrypt is a ‘fake’ obfuscator!
http://www.genable.com/aso/fini.html
Too bad.
greetz D.T.
Steven December 9th, 2004 at 3:12 am 7

Genable released the new version of ASO. They updated it four times in one day. But the result seems the same as the original version.

I try to reveal the code with a hex editor, it cost me less than 3 minutes. The current version is too simple. Maybe the next version will be stronger than old one.

How about ASV?

Best regards.
Steven December 9th, 2004 at 3:13 am 8

The aso link here:
http://www.genable.com/aso/asolite.html