Hacker News Reader

Comment by saghm | Hacker News Reader

> That said, instead of installing an entire framework like Xposed that hooks the process to bypass certificate pinning, you can usually just decompile the APK

I remember reading something years back about Java decompiling, and I believe it said that all Java code is decompileable except for inner classes and nested try-catch. Assuming my memory and the source are correct (which might not be the case), why hasn't it become standard practice for developers who don't want their app reverse-engineered to just put every class inside a wrapper class? I can imagine there could even be tools for doing this at compile time so that you wouldn't need to manually deal with the indirection when writing the code.

View on HN

The standard way of frustrating decompilers for Android applications is with heavy obfuscation using ProGuard [1] or DexGuard. [2] IMO, DexGuard is a real pain in the ass to reverse around. If you aren't dealing with heavy obfuscation, decompiling APKs is trivial using jadx. [3]

In general I have found that most smaller app developers don't obfuscate at all, and often you can find hardcoded keys/secrets in these smaller applications.

[1] https://developer.android.com/studio/build/shrink-code.html

[2] https://www.guardsquare.com/en/dexguard

[3] https://github.com/skylot/jadx

One reason is they have to test and potentially debug the obsfucated build which is a lot of extra work!

Here is an old series of mine that steps you through reversing Java.

https://www.acloudtree.com/hacking-java-bytecode-for-program...

Modern Java decompilers (fernflower, cfr, procyon) are very flexible in what they can handle. They're best used in combination, though, as they all tend to choke on different things.

Neither of those limitations apply to modern Java decompilers (eg, Fernfl0wer).

One can easily reverse inner classes. They have a unique naming pattern that tells you exactly where they live: OuterClass$InnerClass. Anonymous inner classes just get numbers instead of names after the $, so you can even tell normal inner classes from anonymous ones and decompile them appropriately.

As for nested try-catch... I don't see how that would be an issue unless the compiler somehow merges them into a single block. Which, as long as it's semantically equivalent, doesn't matter at all.

I mean, Java compiles down to a byte-code, which can be decompiled. If that were a limitation of decompilers at a time, it's likely not now. There's no way to "hide" instructions.

You can hide them in the sense that it's very difficult to find the 100 instructions and correct state machine out of the millions of instructions and possible states.

Reply on news.ycombinator.com