JPEXS Free Flash Decompiler Issue Tracker

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.

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.