Deobfuscation search engine

[Sputuks3]

Congrats in implementing the deob feature, but I have an idea that I like to propose to JADX first. Some sort of java search engine. or signature recognition to identify obfuscated opensource libraries online on either Github or Google code. For example, a quick search revealed the Google gson library was used. If we could automate this thing, wouldn't it be better?

[skylot]

This is very interesting feature and I saw something similar in JEB decompiler (Sign and Match Third-Party Library Code) and maybe I will implement it in future, but for now there are a lot of questions how to implement it.

[Sputuks3]

Perhaps in the de-obfuscation toggle button, rename all detected signatures with a comment

/renamed from com.myapp.a.a/

[xseregax]

Sometimes there are names such as IlIIIIIlllIIIIlIllIIIIlllII, IlIIIIIlllIIIIlIllIIllllIII (all printable), can you add regex field in the settings that i could manually add my own patterns of bad names, or dump all the names in the file jobf for possible external processing aliases or some other option if someone is needed. until i editing source code on each case.

[nitram84]

One of the open questions of this issue is, how can we find the corresponding sources. If jadx knows the dependencies and their exact versions, this would be much easier to implement.

There are different approaches to achieve this e.g.

• https://github.com/LibChecker/LibChecker (rule based)
• https://github.com/reddr/LibScout (static analysis)

None of these tools can be used directly in jadx and the results are not good enough.

But during decompilation jadx gains a lot of data, that be used to detect dependencies.

My proposition is a public api in jadx to aggregate dependency data with version ranges, so plugins and script can read, provide detected dependencies or narrow versions.

Some examples

• apps with multiple dex files and minsdk<21 probably use 'androidx.multidex:multidex'. A script or a jadx-dependency-plugin may implement a multidex rule, read 'androidmultidexsupportversion.txt' and get the version
• if kotlin metadata is decoded, there is probably a kotlin stdlib dependency
• it should be possible to write a regex that detects the exact gson version - version strings can be found in the decompiled source code
• many obfuscated apps are leaking dependency data with version info in property files

If we have enough dependency data aggregated, it should be possible to fetch the source jars from maven central or google and use javaparser to map clases and method signatures. A complete mapping might be very complex or impossible, but I am sure a lot of classes, methods, annotations and some members can be mapped directly.