News for hackers. Stuff that matters.

A comment on Reverse-engineering the Starbucks ordering API. Parent comment

Re:Reverse-engineering the Starbucks ordering API by saghm on Wednesday July 12, 2017 @10:49PM (#14758381)
> 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.

[ Parent | on HN ]
Re:Reverse-engineering the Starbucks ordering API by micaksica on Wednesday July 12, 2017 @11:14PM (#14758465)
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

[ Parent | on HN ]
Re:Reverse-engineering the Starbucks ordering API by djmips on Friday July 14, 2017 @07:48AM (#14769057)
One reason is they have to test and potentially debug the obsfucated build which is a lot of extra work!
[ Parent | on HN ]
Re:Reverse-engineering the Starbucks ordering API by jfolkins on Wednesday July 12, 2017 @11:19PM (#14758475)
Here is an old series of mine that steps you through reversing Java.

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

[ Parent | on HN ]
Re:Reverse-engineering the Starbucks ordering API by mintplant on Wednesday July 12, 2017 @11:46PM (#14758552)
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.
[ Parent | on HN ]
Re:Reverse-engineering the Starbucks ordering API by jsight on Wednesday July 12, 2017 @11:39PM (#14758533)
Neither of those limitations apply to modern Java decompilers (eg, Fernfl0wer).
[ Parent | on HN ]
Re:Reverse-engineering the Starbucks ordering API by jdmichal on Thursday July 13, 2017 @08:26AM (#14760675)
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.

[ Parent | on HN ]
Re:Reverse-engineering the Starbucks ordering API by ghayes on Wednesday July 12, 2017 @11:02PM (#14758422)
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.
[ Parent | on HN ]
Re:Reverse-engineering the Starbucks ordering API by hueving on Thursday July 13, 2017 @02:23AM (#14759151)
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.
[ Parent | on HN ]