JPEXS Free Flash Decompiler Issue Tracker

If you are looking for the decompiler itself, visit https://github.com/jindrapetrik/jpexs-decompiler

NEW : We have got a new blog where we post some interesting SWF internals info.

List of issuesList of issues

#2047 incorporate doswf decryption/deobfuscation
Author: user jhill
Date created:
Type: feature
Visibility: Everybody
Assigned to:
State: new Help

Would it be possible to incorporate decryption/de-obfuscation elements to allow decompiling of protected flash files? A specific example I'm thinking of is doswf de-obfuscation. There are several versions of this on github, but they are all for windows or linux and I am unfortunately on a mac :/ Thanks! DoSWFUnpacker example on GitHub (there are others, this was just the first that came up in a search): https://gist.github.com/instcode/1509527/d3dca7ed75d090b68e4a3d84d1129923a9800390
user
DoSWF is not a simple protection that can be machine decrypted like that. At the moment of encryption different options can be used, that lead to different layers of protection with slight variations too, and they require their own approach to defuse. The unpacker that you linked can do no more than remove the first layer (idk if it even works). You can get better result by running the flash in projector and using FFDec's memory search tool. Probably if someone put a lot of effort, fully automated DoSWF decryptor can be made. But it would take year(s) to cover all possibilities and iron all the bugs.
admin
DoSWF obfuscation usually contains a loader, which heavily obfuscated, but it decrypts BinaryData tag and then loads SWF inside (might be two layers). That SWF inside often contains injected scripts which check whether they are loaded from inside the doswf file (like if domain.containsClass("@doswf...")) and if not, then it does not execute code in some critical branch, like calling parent constructor. Thus opening that swf file alone will make that code wrong. That's at least for the SWF files I have seen. They may be other variants of doSWF encryption. With FFDec you can bypass loader either by memory search, or by feature called "Open loaded SWFs while playing" by playing SWF inside projector using Run button (may not work when swf is domain-locked) This reveals a SWF inside. The second step is to remove the checks for doSWF classes. These can be removed manually - you can look in FFDec for such parts and remove them using p-code editor. This part cannot be automated, as the if checks may look different on every doSWF version and/or encrypted file. I have seen checks that have "doSwf" as prefix, but that does not need to be a rule. There can be also same kind of checks for class existence in the regular - nonecrypted - file, so that's why there's no kind of deobfuscation for this in FFDec.