+ update 2020: WARNING - support of the decompiler is now VERY LIMITED. There are no active developers. This means we will NOT develop new features and/or fix most of bugs. We left the tracker running in case somebody from community would like to work on it. Sorry for the inconvenience.
State: upgraded new: Initial state. As long as issue is in this state, the work on the issue has not yet begun. opened: Opened state means developer started working on the issue. Feature/Fix will probably be in the next release. postponed: This means developer is not working on it now, for some reason it cannot be implemented now. Issue may be opened again in the future. upgraded: Issue is in upgraded state when developer made changes to the program and new version was released. closed: This means the user is satisfied with issue results and no more changes are needed. invalid: These issues cannot be solved. ignored: Developer decided to take no action on this issue. returned: Program changes were made but user is not satisfied and returned the issue.
> What steps will reproduce the problem?
Open specific .swf file in FFD, check view HEX with instructions in P-code source,
; 9d 02 00 44 00
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.
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
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
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
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
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)
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?
Please try it now, I added a setting next to the "resolve constants" button, you should
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)
But should it really show duplicate date if original is the same as rebuilt?
; 49 (49 @000101ed)
; 12 (12 @000101ee)
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
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)
Settings added (only to the source control, not relased yet)
JPEXS: please draw nice icons for the settings:) Check the attached image.