List of issues
: WARNING - support of the decompiler is now VERY LIMITED. There are no active developers. This means waiting times in the issue tracker are very long and mostly depend on community. Sorry for the inconvenience.
#1241 File content is different to what FFDEC shows in HEX view near instructions
> What steps will reproduce the problem? Open specific .swf file in FFD, check view HEX with instructions in P-code source, find ; 9d 02 00 44 00 If loc9b8d at line 14681 (line 1813 of decompiled code) make a search for this place in external HEX editor (use 0206000000000000000049129D0200??00960B pattern where '??' is a byte wildcard) - YOU WON'T FIND IT, because it's ; 9d 02 00 49 00 there, so you would only find it > What is the expected output? What do you see instead? Same file content in the actual file and in the p-Code with HEX shown But it's not the same > What version of the product are you using? Is it "nightly build"? Which operating system do you have? v8.0.1 on Win10 > Please provide any additional information below. If the problem is related to a SWF file, attach it here, otherwise we can't help you. attached original swf file.
ORG_S1UI_CharacterWindow.swf (311 KiB)
This is not a bug. FFDec fixes the pcode, removes the invalid instructions, implicitly removes the unreachable actions (because the actions not linearly read, because they can jump anywhere, sometimes out of the tag...), etc 9D is an "If" action as you also said. 49 is the jump offset. There is a 5 byte length instruction which is unreachable check attached screenshot), this is why 49 becomes 44. In your case the skipped 5 bytes is a valid jump instruction, but it could be anything. If you want to check the original bytes, use FFDec's Hex view feature, which is on the screenshot.
pcode.png (66 KiB)
I don't use FFDec's Hex view feature because it's fully unusable to me as it's not anyhow connected to decompiled code (and there is no easy way to see bytes of specific code line for example), that's why I always enable "view hex along with instructions" I thought that hex view along with instructions actually show file contents and not the rebuilt copy of it, but most of the time it actually does so I'll continue to use it that way. Is there a way to disable the rebuilding and just show decompilation of the file? The file I attached is the original version of the file provided by its developers with all the original bytes
FFDEC HEX screenshot.png (170 KiB)
For AS3 if you disable deobfuscation the code should match the hex pretty well. For AS1/2 it is nearly impossible since in obfuscated code many instructions overlap and there is no way to display it somehow intuitively. I think you have a good point, I totally understand you, but those obfuscators do very nasty things with the code, you just don't want to see original crippled code they produce. Some FFDec users copy those hex values and create hacks from them in some memory editor or hex editor. I think there is much easier way to edit something in FFDec. P-code editing is pretty stable I think. You can replace one value for another without any harm on pretty much any SWF file.
Making a new file is ok, but some people would want to only make a byte pattern to search out of it and to replace it, for easier sharing and combining with works of other people and their search+replace byte patterns. + In this case, there is only a tool to extract SWF files out of gamefiles, but not to put it back safely modified, but because it's not compressed - it's possible to hex-edit it directly inside game files.
Please try the next nightly, now it shows: ; 9d 02 00 44 00 (9d 02 00 49 00 @000101ef) If loc9a21 First 5 bytes are the same as before, the rebuilt action bytes, in parenthesis you can see the original bytes from the file and the original position in the file Now this new part is always visible when you select pcode + hex view, but I'll add a setting (maybe new icon next to the "View pcode with hex" icon) to turn on-off the original bytes + address) Is this enough for you? May I close this issue?
I forgot to mention that if you edit the pcodes in FFDec (press edit and save button) this information will be lost, and will show the rebuilt bytes.
+"original position in the file" is of course the original position in the decompressed file
Tried latest nightly 1447, result: ; 9d 02 00 44 00 If loc9a21 no parenthesises
But yes, this would be enough I think, even if I wouldn't get to know what code developers made unreachable and was it a mistake or not (they just love to mess things up)
Please try it now, I added a setting next to the "resolve constants" button, you should press it. JPEXS, could you please draw an icon for this feature before releasing the next stable build? It is called src/com/jpexs/decompiler/flash/gui/graphics/originalbytes16.png
Yes, now after pressing it - it works: ; 9d 02 00 44 00 (9d 02 00 49 00 @000101ef) If loc9a21 But should it really show duplicate date if original is the same as rebuilt? ; 49 (49 @000101ed) Equals2 ; 12 (12 @000101ee) Not This makes it hard to notice changed bytes - they'r all in the green color and all 99% just duplicating what's on the left exactly
Now it is: ; 12 (@0000dcfa) Not ; 9d 02 00 39 00 (9d 02 00 3e 00 @0000dcfb) If loc7527 ok?
can we have it without @ addresses at right please? (at least of unchanged parts) - we already can have address showing buy clicking the corresponding icon ( I don't click it usually )
Which icon do you mean? I think it is useful, i did not find any other way to get the address.
Or you mean the hex view? It is very hard to find the action there, first you have to find the action tag, then the action in that tag, which is quite complicated if the tag has some 1000 action, and you need to find for example the 2367th action
> i did not find any other way to get the address. Oh, I meant not icon but setting (show addresses) - I enabled it to see what it does and it starte showing @ addresses at the very left of each string - that's what you're duplicating with those (@0000dcfa)
But they are not the same. (@0000dcfa) is the position in the swf file. The other one is only the relative position from the first action.
Oh, then can we have @ address at left where position from the first action was? via option or somehow, because addresses are usually there at left
Ok, and I'll aslo add a setting to turn it on/off. So you can ide it if you don't want to see them.
Settings added (only to the source control, not relased yet) JPEXS: please draw nice icons for the settings:) Check the attached image. src\com\jpexs\decompiler\flash\gui\graphics\fileoffset16.png and src\com\jpexs\decompiler\flash\gui\graphics\originalbytes16.png
actionpanel.png (25 KiB)