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.

#193 Rename all identifiers
Author:
focus

Date created:
Type: feature
Visibility: Everybody
Assigned to:
Labels: DeobfuscationRename identifiers
State: new 

Would be nice to have this to force names deobfuscation when Rename invalid identifiers
fails at obfuscated names detection.
Maybe rename "Rename invalid identifiers" to "Rename identifiers" and new checkbox "Rename
invalid only" enabled-by-default in the Rename identifiers dialog would be more
user-friendly?
"when Rename invalid identifiers fails"
I think rename invalid identifiers should not fail at all.
If it fails, that means there is a bug or it is not implemented very well.
I don't think it is good idea to rename all, why would user need that?
If there are some valid identifiers, it is good to leave them as is.
Actually, my goal is to make renaming invalid identifiers feature working in 100% of
cases.
State: new→postponed
Well, how would you determine such obfuscated names:
"potato", "parrot", "car", etc.?
I know obfuscators renaming identifiers in such manner - so the full rename could help
here since "package_1" and "Class_1" is much better than abstract "parrot" and "car".
hmm, okay, I will consider adding "rename all by type" feature. But personally I will
rather have parrot and car classes, than 100 classes named class_1,class_2...class_255,
because they are easy to distinguish and remember even if they do not have names
suggesting their functionality.
yeah, in my example it could be so, but there could be much more hard to remember
combinations, like sunMoonLightDark, sunLightMoonDark, sunMoonDarkLight. darkMoonSunLight,
lightMoonDarkSun, etc.
I'll be glad to have an option for converting all this names into var_1, var_2, etc.!
I was thinking a little...
There is a problem.
It won't be so easy as it looked like for the first time.
If I rename all identifiers, then all flash built-in packages/classes
(ByteArray,SpriteAsset,...) will be renamed too. I need to somehow detect that name is
built-in and then not rename it.
That is probably easy for class names which have always "flash.*" package,
but what about inherited methods? I have to decide whether a method comes from this class
or is an overriden version of built-in class?
Overriden methods have override flag so I can see that it comes from parent class... but
then I must traverse all ancestors of the class ...
This one is hard so please be patient. I am setting state to "new", but it has low
priority, sorry.
State: postponed→new
Thanks for your explanation and no worries - take your time, there is no any urgency for
this issue and I completely understand you have other issues with higher priority for now.
Hope, you'll have some good solution for this built-in names detection, will wait for any
news on this issue!
Any news on it?