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 issues#1241 File content is different to what FFDEC shows in HEX view near instructions
Author: 
Owyn
OwynDate created:
Type: bug
Visibility: Everybody
Assigned to:
State: closed 
> 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)State: new→upgraded
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)State: upgraded→closed