skylot / jadx

Dex to Java decompiler
Apache License 2.0
40.98k stars 4.81k forks source link

Jadx fails when handling obfuscated code #199

Open enovella opened 6 years ago

enovella commented 6 years ago

Hi,

It is known that some obfuscators try to use anti-decompilation & -disassembly tricks to thwart reversers and break decompilers and RE tools.

The decompilation seen in this post (https://github.com/CalebFenton/simplify/issues/94) is done with JEB1. There you can obtain the obfuscated dex to reproduce. The sample contains string encryption, reflection and some opaque predicates.

JADX

jadx

JEB1

34448564-db5e4052-ecee-11e7-8340-ca582905e56f

Feel free to try it out yourself.

Cheers

mingyuan-xia commented 6 years ago

This would be an endless battle (an unfair one for a decompiler). Actually what you saw should come from protectors (DexGuard, and dozens of Chinese protectors) instead of an obfuscator (Proguard). I've noticed the jump-to-nowhere bytecode trick too and noop-ing it would be fine. But exhausting all the anti- cases could be tedious~

enovella commented 6 years ago

Hi @mingyuan-xia,

If you know the basic anti-deccompilation tricks, why not adding them?

Can you point us where in the sample added contains the jump-to-nowhere?

Cheers

mingyuan-xia commented 6 years ago

Sorry, this issue misses my radar for a while. Recall a quite old discussion with JesusFreke. The best workaround for now is to no-op such invalid instructions at instruction parsing stage and try decompiling the revised instruction stream. This avoids the Exception here and might get back some useful (best-effort) code. Anyhow such instruction will never be executed. @skylot