JPEXS Free Flash Decompiler Issue Tracker

This is fixed in nightly 3286.

It is decompiling correctly now. On trying to edit ActionScript of frame 3 DoAction [2], it fails to save due to byte limit. From looking at other issues, it seems this may not be feasible to fix. However, P-Code edit is also failing in this case, with "SEVERE Jump offset is too large:39246 addr: ofs10607". Full log attached.

Okay, in nightly 3288, for P-code, I now display standard error message when this happens, highlighting actual problematic line. You may wonder why P-code has too large offsets when it is just read from the SWF, but in this case it is caused by the process how FFDec reads and deobfuscates the Action list. It should not happen in not-obfuscated SWFs. What you can do with the error message: In this file there are large jumps. You can split them into smaller jumps, for example inserting code like ``` jump loc_shorter ... jump loc_split loc_shorter: jump loc_shorter2 loc_split: ... loc_shorter2: target ``` I was wondering if these long to short jump conversions could be done automatically by FFDec, but I think it might be impossible in some cases, like when there is a function which cannot be split, or something.... I will think about it in the future... For the ActionScript editor (not the p-code), the situation is very different as it would be very hard to tell on which line the error happened due to the way the bytecode is generated. It would need a total rewrite of the process of compilation to get actual line when it is "too large". I gave it a low priority in the past as I am not sure it is worth it.

Thanks for the addition and the information > It should not happen in not-obfuscated SWFs. The same error occurs in 381115_NGRfinal.swf (which I think is not obfuscated) when Deobfuscate code is turned on, however this can be fixed by simply turning it off. In these SWFs it looks like the massive loadCharacter function is the culprit. Reading the docs at https://flasm.sourceforge.net/#hugescripts would suggest that these oversized scripts are not stable at all: > Function length (ActionScript 1), for example, isn't verified and will be broken for very big functions. > If you try to execute this kind of SWF, Flash player crashes or actions are omitted. Disassembly will be incomplete and/or wrong. In most cases, Flasm will show an error message. So I'm surprised games like this can be made without any apparent problems. I suppose it is not as simple as just ignoring the size limits as Flash compiler appears to do. Personally I've encountered these huge scripts with some frequency, such as the shell.swf in #2517. In that case, P-Code editing is fine but AS editing is not.

I released nightly 3290, where I fixed storing large Constant Pools, it fixed the case of shell.swf in #2517. So it should be directly editable now. This does not affect other kinds of Large values that cannot be saved, like large jumps, ifs, functions, etc.

In nightly 3291, I updated the direct AS editor, it should mark the line with problematic long structure (function/if/while/...).