Recover full method path about cfr

[leibnitz27]

It's possible (with a little hacking) - out of interest what's the reason you want to do this?

You can get the behaviour you want by always returning type.getRawName() from

cfr/src/org/benf/cfr/reader/state/TypeUsageInformationImpl.java

Line 192 in 3321627

String res = displayName.get(type);

As an option ("don't explicitly import anything") it would lead to hideous code, so I'm not keen to do it unless I can think of a good reason! :)

[lab313ru]

The reason is:
jar-file is obfuscated, some classes in subfolders have the same names (it may remember the duplicate field names problem), and there are strings-deobfuscation methods, all of them have different variation for every class.

Then imagine situation like this:

• MsgBox(o.decode("\xab\xcd")) (com.sub1.o)
• MsgBox(o.decode("\xcc\xdd")) (com.sub2.o)

I want to write some deobfuscator (in Python), but to understand which deobfuscator was used I need to restore full type path.

[leibnitz27]

Handled with a general 'don't import this' filter, using the same regex filter as elsewhere in options.

--importfilter "util" <-- only generate imports for classes that match 'util'.
--importfilter "!util" <-- only generate imports for classes that don't match 'util'.
--importfilter "!(util|lang|^com.sun)" <--- etc etc.

[lab313ru]

Thank you! Lee Benfield <[email protected]> 31 июля 2019 г. 9:39:44 написал:

…

Handled with a general 'don't import this' filter, using the same regex filter as elsewhere in options. --importfilter "util" <-- only generate imports for classes that match 'util'. --importfilter "!util" <-- only generate imports for classes that don't match 'util'. --importfilter "!(util|lang|^com.sun)" <--- etc etc.— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.