Open enovella opened 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~
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
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
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
JEB1
Feel free to try it out yourself.
Cheers