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 ("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.

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!
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...
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.

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

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.

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!

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

There we go.

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.

Unfortunately, as evidenced by a quick Googling, fini est fini.
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.
...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).

- 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.

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/?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)

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!

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:

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?

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 !

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.

It is impossible to protect SWF.

SWF is open file format, stack machine code is easily decompiled, etc.

Consider we normally crack applications running on machine architectures and OSs several orders of magnitude more complex, SWF is trivial once one understands the file format and ASVM.

If you want more "security" (through obscurity) you can go with Macromedia Director which is NOT an open format, but I already have some initial guesses on the file format and I'm sure we'll get there some time too.

Wow, I haven't been playing with those protected SWF's for a while so it's nice to see things taking off.

I've been writing my own de-obfuscator, although the project was put on ice a couple of weeks ago due to university and such.

There are a couple of different versions that I'm dealing with, using basically the same tricks but differing slightly. It seems the situation is a bit more complex than LLXX's description, depending on the tool.

What I've been able to find out so far is that

1) Actionscript is replaced by spaghetti that at some point branches out of the actionblock into a tag with 'unknown' id 253. These tags are made up out of some unknown data, follow by a series of opcodes (the 'real' code). The last opcode (offset = tag.offset + tag.size - 5) is a branch that branches to the first opcode in the opcode list (hence allowing you to skip the unknown/garbage/padding data in front of it).
2) Some actionblocks have a 'wild' END (0) opcode, followed by more code. This can throw off your SWF parser if you make it stop reading opcodes when it encounters an END opcode. I've also found files where the same sphaghetti method was used as in (1), but instead of branching to a 253 tag, the branch went beyond the END instruction where the original code was located.
3) In none of the files I've played around with did the 253 tags have constant pool definitions. It turns out these appear in the sphaghetti blocks, and since there are a couple and only one of them is the right one, you have to find a method to select the correct one. I do this by looking at the 'real' code in the 253 tag and looking at how many constants are used. I then use the constant pool from the sphaghetti block that has at least this many constants. This works for me in all cases so far.

Right now I can recover most of the actionscript from the files I've tried. The goal is to reconstruct the original SWF - ready for decompilation/patching etc.

If anyone else wants to join the hacking, there's a shitload of open source SWF libraries out there, so no need to roll your own.

Hello,
I have a small problem with SWF (flash)
My jump: 99 02 00 F3 CC -> so it is a jump -13069 bytes but my file is size 1805 bytes

so this jump is out of file, so where it will jump ?

this code is from encrypt swf and i try to hack it :] someone help me ?
thanks

FIRST: Tell us what YOU have done to try to understand the code and what it might mean when the code "jumps" to a location which YOU think is "farther" than the the size of the .exe

Regards,

Hi,

It's an old trick, jump (or branch) across actions block to trick decompilers, you're looking at trash code added by the obfuscator.

Send me the file and i will send you the source code. amayeta shit protection is trivial...
killor@thegame.com

I'm a moron.

parker is obviously unaware that backlinks (live links) are disabled in the forum lol, he's probably trying to promote this shitty protector by adding some backlinks in this thread (btw this thread does rank well in google for the term swf protection)

having that said, I will be glad to decompile any swf protected by his protector to promote this protector even more in my own special way :P

hi i wanna ask a question
how to " through the whole "obfuscated" part " and find the jump
do you load the swf play in OD?
or just read the pcode of swf file?

please give me a help!
thx!

You read the Flash opcodes, yes.

thx
well
the obfuscated opcodes are really hard to read for me

anther question
0x99 means jump in opcode
what's the format of 0x99 which means an upline jump(or backwards jump)?

I realize this thread is old but can anyone please help me deobfuscate my amayeta swf encrypted actionscript? I have attached the .swf and .fla Thanks to anyone who can help!

No no no...
This is not a McDrive here, show us what you tried to do before begging for help and waiting for an already cooked answer.

Thanks, but I'm sure you don't know how to deobfuscate amayeta encryption anyways. Anyone else?

That wasn't the point. Our moderator was applying the rules of our board, which asks that you "Do not ask for help without showing you made an effort". He could have just as easily turfed your post. Don't fight us on this one, and don't start 'dissing' people in your first postings, you will lose.

Really, it's not a big deal. Just give some background on what you've already tried or where you're stuck, or that you have some idea of what it's all about and that you could understand the answers. If you show a bit of effort and are willing to work on it yourself, people will be more inclined to help

It's not an unreasonable way to ask any question, here on the internet or in real life. You get one more chance.

And you are too lazy to search and do your own effort, which is worse. It's like the difference between ignorance and stupidity.

There is another (old) thread about SWF Encrypt on this forum which you could've easily found. The workings of 4.0 are explained there. New versions of SWF Encrypt have been released since then, but considering a version number as high as 4.0 barely did anything at all, I don't think the new versions are much better .