SWF Encrypt (Flash 'obfuscator') hacking

[Inopia]

Hello everybody,

while playing with some encrypted swf files I stumbled upon this thread: http://www.woodmann.com/forum/showthread.php?t=9572&highlight=flash+swf.

I know it's from a while back but people might still be interested. I am using the excellent JSwiff Java SWF manipulation library to toy with the 'encrypted' files and I've been able to at least extract the unencrypted actionscript code (although some variable names are mangled).

SWF Encrypt 1.0 places the missing actionscript behind an <end> instruction. Flasm doesn't disassemble beyond <end> so that's why it's 'hidden'.

I've also found a more interesting mangled SWF in the wild that actually places code in unknown tags (id=253). These tags contain some unknown data and a series of instructions. It looks like this:

[unknown data][action block][<end>][branch]

the branch instruction at the end is the entrypoint for the tag, and it holds the (local) adress of the start of the actionblock, counted from the end of the tag.

There was also mention about overlapping bytecode. As far as my efforts show, this is always a jump to the second label found (the one flasm reports as being halfway an opcode), and offset by one byte. The resulting opcodes are always 0x03 0x00 (0x00 = end). Afaik 0x03 is not a known instruction, so I'm not sure what it does.

I'm still looking for the easiest technique to de-obfuscate these files, and insights are appreciated.

[LLXX]

I've been able to at least extract the unencrypted actionscript code (although some variable names are mangled).

Who cares about the variable names? Remember, we're used to reading memory addresses so anything partially symbolic is already a long way in terms of progress!

I've also found a more interesting mangled SWF in the wild that actually places code in unknown tags (id=253). These tags contain some unknown data and a series of instructions. It looks like this:

[unknown data][action block][<end>][branch]

the branch instruction at the end is the entrypoint for the tag, and it holds the (local) adress of the start of the actionblock, counted from the end of the tag.

From my experience, the player skips over tag types that it does not recognise (reasons of forward compatibility etc.) but you may want to check the latest (8?) specification to make sure...

There was also mention about overlapping bytecode. As far as my efforts show, this is always a jump to the second label found (the one flasm reports as being halfway an opcode), and offset by one byte. The resulting opcodes are always 0x03 0x00 (0x00 = end). Afaik 0x03 is not a known instruction, so I'm not sure what it does.

Based on the fact that bytecodes above 127 are supposed to have trailing parameters, and that 0x83 is ActionGetURL, I can think of these possibilities:

1. Treated like a normal ActionGetURL op (following 0 byte is part of the length of data to follow).
2. Treated like ActionGetURL without parameters, so it executes as a nop and following 00 -> end. (Unlikely)
3. Treated like ActionGetURL without parameters, but the URL to get may have been loaded via some undocumented "last-string" feature earlier.
4. Something completely different.

The best way to learn is to pack a few trivial SWFs you've manually assembled, and note what happens to the resulting opcodes.

[dELTA]

Thanks for sharing your findings Inopia, please stick around, and let us know of your further results.

[LLXX]

I've traced through the whole "obfuscated" part, in fact it's just a giant state machine. If you trace correctly, it ends with a jump out of the record. Also, this may be a contestant for the most non-protecting protection -- the original bytecode is there, intact. All it's doing is changing the original record type to 253, appending two jumps to the end, then adding the new record with the obfuscator code which merely jumps to five bytes from the end of the previous record (which holds the jump to the "OEP"). Expect an unprotector for this soon (going to write my own SWF manipulation library first).

tl;dr: obfuscator FSM --> jump to 5th-from-last byte of previous record --> jump to OEP.

[dELTA]

Very nice work as usual LLXX, looking forward to seeing and hearing more of your SWF reversing tools!

Regarding the original code still being there, I guess the goals of SWF protection are a little different from the ones of PE protection at this point, sufficing to "hide" the original code from automatic decompilers and script rippers, but not from the able binary reverser. But it seems we (you) are well on the way to force them to the next level... Keep it up!

[LLXX]

http://www.woodmann.com/forum/showthread.php?p=67428

There we go.

[YesItsMe]

great work, it's not really the first tool, there were many before, here's a quick historical briefing:

Back in the days of flash 5, when actionscript started looking like a serious scripting engine and offered developpers wide opportunities, the first actionscript viewer appeared, it was just a viewer, it did not give you the possibility to build the source file, it just allowed you to see the actionscript. You could not change the script using this ASV in any way back then.

Shortly after that, the first obfuscator was released, ASO (actionscript obfuscator), what it did is renaming the variables and function names using non printable chars or the so called illegal characters.
This rendered the actionscript unreadable and thus non-reusable witout some deep analysis and renaming by the developper.

This clearely was not a hack proof solution so other protectors arised, the first protector claiming to provide "encryption" capabilities was "flash empire last defence", soon after its release a reverser defeated it and released "flash empire last straw" lol, its deprotector.

The author of flash empire last defence updated his tool and so did the reverser, but this time he called his deprotector "fini".

Again, last defence was updated, this time it was buraks play, he updated his ASV and defeated last defence for good, I never heard of this protector afterwards.


flash MX was then released, actionscript was once again enriched with more features and API, again new protectors arised, the first was as-protect, it was an online protector, it worked in a very strange way...You had to decompile your swf with a decompiler, copy the byte code and send it to them via an online form, they would then send you back the obfuscated byte code so basically in order to protect your byte code you should own a decompiler !

as-protect was not widely used and it died as a project soon after, no reports were made about it being defeated, i did defeat it however but never released any tool publically.

Other protectors bloomed, flashIncrypt was one of them, it was defeated by un update of the oldest decompiler ASV, the authors of flashIncrypt rebranded to swfEncrypt claiming to be the best and most sophisticated protection providers, there protector was repeatedly dfeated by subsequent updates of ASV...

A lame protector I ran into lately is swfProtect, not very popular (and for a good reason), it offers the same protection mechanism as others with out of tag jumps and dead code codenamed code pollution. The latest version (1.6 I think?) took me not more than 5 minutes to bypass, very lame protection indeed.

Another less known protector is secureSWF, the latest beta provided good protection but the final version was never released, it's been 8 months now since the beta was first made public...

The best deprotector you could ever use is your brain and a copy of swf file format specs (version 9 was released two or three days ago).

Regards.

[LLXX]

The author of flash empire last defence updated his tool and so did the reverser, but this time he called his deprotector "fini".

Unfortunately, as evidenced by a quick Googling, fini est fini.

Other protectors bloomed, flashIncrypt was one of them, it was defeated by un update of the oldest decompiler ASV, the authors of flashIncrypt rebranded to swfEncrypt claiming to be the best and most sophisticated protection providers, there protector was repeatedly dfeated by subsequent updates of ASV...

A lame protector I ran into lately is swfProtect, not very popular (and for a good reason), it offers the same protection mechanism as others with out of tag jumps and dead code codenamed code pollution. The latest version (1.6 I think?) took me not more than 5 minutes to bypass, very lame protection indeed.

Another less known protector is secureSWF, the latest beta provided good protection but the final version was never released, it's been 8 months now since the beta was first made public...

Did they all happen to "protect" using a state machine and a jump into an unknown record that contained the hidden code? If you PM me various SWFs, I'll probably update FREN to handle all of them perfectly.

The best deprotector you could ever use is your brain and a copy of swf file format specs (version 9 was released two or three days ago).

...and I subsequently had to download the PDF, only to find that it uses some stupid Javascript shit that requies their latest bloatware to read. After 20 minutes of PDF reversing I've produced a "cleaned" version (PM me if you want it).

[YesItsMe]

- I still have fini.exe, no source was released back then just the executable. It is not packed or protected in any way and thus analyzing it would be somewhat easy. (I can send it if you're interested).

I also have flash empire last defence (both versions) and last straw as well (could send these too).

Yes I am aware of the javascript shit embedded in the pdf, its just to display a license agreement the first time you open the file. Works with Adobe reader v7 and above I think.

I also have a library of swf files protected with the various protectors (all of them) and yes, ,they all use the same technique.

Btw, future versions of the flash player are not guaranteed to tolerate the so called protected swf as they use non-standard structure. According to the swf file format specs, each tag can contain references to itself or to tags before it (to guarantee streaming behavior) which is obviously not the case for these swf files.

[jecti]

Terms:
AS3 - ActionScript 3, the SWF high level language
ABC - ActionScript Byte Code, the SWF low level language
ASVM - ActionScript Virtual Machine
Tamarin - Code name of ASVM2


As has been noted there are two fundamental problems here which consist of "unpacking" and then "decompiling". However the flash world is divided between the old AS2 language (and virtual machine) and the newer AS3 language (and ASVM2 - Tamarin). This divide means that each language requires a dedicated unpacker and decompiler solution.


The state of flash reverse engineering will be explored in both languages.

State of Flash RE - ActionScript 2 - Flash 8 and below
There are Five commercial tools of interest when considering an AS2 SWF.
1. Action Script Viewer (http://www.buraks.com/asv) last updated May 2007
2. URL Action Editor (http://www.buraks.com/uae) last updated May 2007
3. Flash Decompiler 2.99 (http://www.eltima.com/products/flashdecompiler/) last updated December 2006
4. Sothink SWF Decompiler 3.7 70607 (http://www.sothink.com/product/flashdecompiler/) last updated June 2007
5. Sothink SWF Quicker 3.0 70524 (http://www.sothink.com/product/swfquicker/index.htm) last updated May 2007

The most technically capable programs for manipulating and decompiling AS2 SWF files are made by buraks.com

Historically both unpacking and decompiling were done by the commercial flash decompiler ASV. However, with regard to ASV they have a policy of not breaking "protection" techniques until a certain amount of months have passed unless another decompiler breaks it first. [1] Other decompiler vendors have stated on their forum that they are working on solutions but have not solved the problem yet (in regards to SWF Encrypt).[2]

With open source tools (such as FLASM and MTASC) the bytecode of AS2 SWF files can be manipulated. However the decompiling step still requires proprietary software which, to this day, has had great difficulty with even unprotected AS2 SWF files in getting the correct AS from the bytecode. In general they work well on most swf files but very rarely to the point of accurate FLA generation. If the file is protected or decompiled slightly incorrectly then you are at the mercy of the slow software vendor, and a brief look at the support forums for each of the three companies reveals that this is not a viable option.

State of the Art - ActionScript 3 - Flash 9

ActionScript 3 represents a new frontier for the flash technology because there are no tools yet in exitance that can handle the language, although that won't be true for long.

Buraks has delayed releasing version six of ASV which will handle ActionScript 3. The new release date is "around August 6" [3]
Eltima has a beta for version three of their decompiler which will decompile AS3. There is no set release date. [4]
Sothink is also working on an AS3 version of their software, there is no date. [5]

There is work on AS3 protectors but details are scarce. http://www.fenixstudio.org/swcencrypt/faq.htm#6

There are no available commercial tools to decompile AS3 and there are also no tools that "protect" AS3 SWF files.

Rather than wait for the commercial vendors to offer proprietary solutions, we have the unique opportunity to collaborate on an open source unpacker and decompiler that is technically superior.

The speed improvements of AS3 enable powerful 3D in SWF for the first time (there are AS2 engines but they lack the FPS & functionality of their AS3 counterparts). Consider all of the knowledge that would be made accessible, this link is to a show reel of one of the more popular open source AS3 3D projects. http://www.papervision3d.org/showreel/publicbeta/
Example of a commercial project using PaperVision3D. http://www.rhythmoflines.co.uk/

The AS3 VM has been open sourced under the name Tamarin which includes an excellent AS3 bytecode decompiler.

http://www.5etdemi.com/blog/archives/2007/01/as3-decompiler/

There is a lot of interest around Flash technology but it would seem to be happening in other languages (such as French in the above link or Chinese as another poster pointed out).

The most pragmatic approach, in my view, would be the development of three key open source software solutions.
1. an AS2 "unpacker" (thus enabling the user to select their AS2 decompiler of choice)
2. an AS3 "unpacker"
3. an AS3 decompiler based upon the Tamarin AS3 bytecode decompiler. (see above link)

The haXe project also supports Flash 9 and has recently released hxasm which enables coding in AS3 bytecode directly. http://haxe.org/hxasm

I remember there being a lot of support on osflash.org for an open source solution to these problems but I have not read any new information on developments. My hope is that this is useful in inspiring the creation of open source unpackers and decompilers for ActionScript 3. The AS3 language is used in AIR (onair.adobe.com), Flex (http://www.adobe.com/products/flex/), and Flash so the utility of an open source solution will be immense.

I look forward to discovering more. The FREN 1.0 SWF Encrypt "unprotector" is a wonderful first step!

Sources:
[1] http://www.flashdecompiler.com/index.php?s=&showtopic=258
[2] http://www.sothink.com/phpBB2/viewtopic.php?t=28368&highlight=encrypt
[3] http://www.buraks.com/asv/
[4] http://blog.eltima.com/2007/03/beta-testers-wanted.html
[5] http://www.sothink.com/phpBB2/viewtopic.php?t=29417

Resources
"How to create a simple SWF decompiler" http://www.codeproject.com/cs/media/swfdotnet-decompiler.asp (note: AS2)

[dELTA]

Great info jecti and YesItsMe! And of course a great thanks to LLXX for creating and sharing FREN, I'm looking forward to future updates of it!

[LLXX]

http://www.securityfocus.com/bid/15334/exploit

One protected SWF I'm currently studying appears to make use of this exploit, by embedding a DefineFunction action attempting to define a function with 513 parameters:

3F 03 --> DoAction
CD 03 00 00 --> length = 03cd = 973 bytes

9B ; ActionDefineFunction
07 00 ; name = "\x07"
01 02 ; 0x0201 = 513, # of parameters
00 ; param 1's name (null)
00 ; param 2's name (null)
00 ; param 3's name (null
09 00 ; ...but the parameter names are beginning to look like ActionScript bytecode!
96 05 00
07 7C 05 00-00 3E 96 03 00 00 01 00-96 05 00 07
8D FC FF FF-96 0D 00 06 00 00 00 00-00 00 00 00
00 01 02 00-3D 47 3C 96 03 00 00 01-00 1C 96 05
00 07 09 02-00 00 0E 12 9D 02 00 21-00 96 03 00
00 01 00 96-03 00 00 01 00 1C 96 05-00 07 8D 01
00 00 0B 1D-96 02 00 05 01 99 02 00-C9 FF 96 03
00 00 01 00-1C 96 05 00 07 EF 01 00-00 0E 12 9D
02 00 1D 00-96 03 00 00 01 00 96 03-00 00 01 00
1C 96 05 00-07 56 01 00 00 0A 1D 3C-99 02 00 96
FF 96 03 00-00 01 00 1C 96 05 00 07-0E 02 00 00
0E 12 9D 02-00 1C 00 96 03 00 00 01-00 96 03 00
00 01 00 1C-96 05 00 07 D9 01 00 00-0A 1D 99 02
...

[dELTA]

Cool!
Does this mean we may have a contestant that might be able to snatch the first place in the "most unstable packer" category from Xtreme Protector?

[monpoulet]

Hey guys.

I'm a newbie. I just want to know what is the best way to encrypt from decompiler my code in a lash file or the swf directly? Because you talk abvout breaking the encoding method, but what is the best way to encode it?

Please help !

[YesItsMe]

If you're flash application is very popular, chances are it will get hacked whatever you do.

You can make the job harder by using any obfuscator that renames identifiers, if your code is complex enough this will make reading through the code very hard and time consuming.

I don't think a so called encryptor is a better choice.