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#2175 Issue with Decompiling a Modified Flash 8 SWF
Author: 
Crazyfs
CrazyfsDate created:
Type: bug
Visibility: Everybody
Assigned to:
Labels: ButtonsFLA exportObfuscatedSound
State: upgraded 
> What steps will reproduce the problem?
Attempted to decompile a large, modified Flash 8 SWF file using FFDec 20.0.
Encountered persistent StackOverFlowError.
Resolved this by increasing thread count from 16 to 32.
Used FFDec 20.1, error ceased, but resulting FLA file is corrupted in Flash CS6.
> What is the expected output? What do you see instead?
Expected: Successful decompilation into a usable FLA file.
Actual: FLA file appears corrupted when opened in Flash CS6.
> What version of the product are you using? Is it "nightly build"? Which operating system
do you have?
FFDec Version: 20.0 and 20.1 (not nightly builds).
Operating Systems:
Machine 1: Windows 10 Home Edition, AMD R7 5700U processor, 16GB RAM.
Machine 2: Windows 10 Ultimate Edition, Intel i7 9750H processor, 32GB RAM.
> Please provide any additional information below. If the problem is related to a SWF
file, attach it here, otherwise we can't help you.
Issue only with the heavily modified game mod SWF, not with the original version.
Original SWF decompiles without issues.
Additional Question:
I would also like to inquire about an issue with FFDec's decompilation process.
Specifically, when modifying code, why does the 'for...in' syntax not decompile correctly,
requiring replacement with equivalent 'while' statements to function properly? This
behavior has been consistent and is puzzling. Could you please provide some insights or
solutions regarding this?
Finally, I'd like to express my gratitude and respect for your continuous efforts in
developing FFDec. Your dedication has enabled my team to fulfill a cherished dream from
our childhood. Your work is not only technically impressive but also carries a significant
emotional value for us. Thank you for making this possible.
CRAZYFLASHER7.swf (18,346 KiB)Original SWF.exe (17,887 KiB)
1) I released new nightly version - 2754, try it.
2) In CRAZYFLASHER7.swf file,
there are some incorrect character ids assigned to DefineButtonSound tag
- In the new nightly, I show this as warning on FLA export - you can determine exactly
which tags are affected so you can fix it. But the new FLA export ignores them anyway so
it will export correctly.
3) Some of newly added sounds use 320kbps bit rate which is not supported in CS6,
but I modified the export to convert it so it will work.
4) 'for (var a in obj)' statements should be properly decompiled without a 'while' - if
not, then there is a bug. Please provide sample code if you think this is a bug.
5) The regular 'for (var a=0; a < 10; a++)' will decompile as 'while' because in the
bytecode, there is no difference between 'a=0; while(a<10) {a++;}' and a for loop. FFDec
cannot distinguish it and thus always shows it as while which is more general.
6)
Thank you for your gratitude, it's good to hear that.
State: new→upgraded
I wanted to extend my heartfelt thanks for the updated version you provided. We have
successfully exported the file and are currently in the midst of testing the new FLA. Your
prompt and effective solution has been crucial for our project. Knowing that we have the
ability to manually fix potential issues gives us great reassurance. Your dedication and
support have made a significant difference to our team.
Regarding Point 4: The decompiled code shows an unusual syntax with §each§ and
eval("each") in loops. This pattern is also found in the provided game swf file:
for(§each§ in this) {
this[eval("each")].removeMovieClip();
}
Is this an artifact of decompilation or part of the original code?
About Point 5: In previous versions (prior to version 19), writing complex loops in SWF
through FFDec necessitated using 'while' loops instead of 'for' loops for
iterations,seemed unable to correctly recompile 'for' loops into executable code.
However, in the current version, FFDec automatically converts 'for' loops into 'while'
loops. While this approach is stylistically different from what I'm accustomed to, it has
notably improved usability and convenience in the coding process.
Thank you for these powerful updates.
Ad 4)
The §name§ syntax in FFDec means that "name" should be considered as identifier
(variable or member name).
Original SWF file is obfuscated and some of variable names were replaced with invalid
identifiers.
In flash you cannot use 'each' as variable name because it is reserved keyword.
In ffdec this is displayed as §each§ or setproperty('each', val) or eval('each') when
appropriate.
To properly compile it from FLA file, you will need to replace all §names§ with other
valid identifiers
(+ also matching evals, etc.)
I'd like to express my sincere gratitude for your team's continuous work and the recent
answers to our queries. The progress in our project is largely due to the advancements
you've made with FFDec. It's truly invaluable.
However, I 've noticed an issue in the exported FLA files: the 'import assets' feature
seems to be malfunctioning, requiring manual reconfiguration of libraries. This might be
due to incomplete loading of resources from other imported SWF files during the
decompilation process.
Given our game's extensive size, even after increasing the setting limits, we still
encounter StackOverFlowError issues. While this bug isn't critical due to our need to
thoroughly restructure the game's file system, I thought it important to bring to your
attention.
Thank you once again for your exceptional support and dedication.
Best regards