We Reverse Engineered 16K Apps

Re:We Reverse Engineered 16K Apps by shade23 on Monday January 16, 2017 @08:08AM (#13409722)

This is a problem I've regularly faced with it android apps . Possible solutions since many people seem to be asking that.

- Fetch credentials and keys on login and then save them in an encrypted manner in

- SQLite Encrypted DB

- Android Services like KeyStore[1]

- AccountManager lets you save metadata[2]

But the way I mostly end up using which provides protection from a lot of Reverse Engineering Tools(JADX,dex2jar,smali) is:

Use Enums instead of String constants. Using

``` public enum Key {

     Key1("keyValue");
 
     String keyVal;
 
     private Key(String keyVal) {
         this.keyVal = keyVal;
     }
 }

``` obfuscates the `keyVal` from many class decompilers.

I'd love better ways to do this. But when you do Android development (like when you do Front End web dev), its easier to just assume that everything you wish to keep private will be visible and avoid keeping/saving critical information on the client app.

[1]:https://developer.android.com/training/articles/keystore.htm...

[2]:https://developer.android.com/reference/android/accounts/Acc..., java.lang.String)

[ Parent | on HN ]

Re:We Reverse Engineered 16K Apps by skybrian on Monday January 16, 2017 @02:01PM (#13412039)

How does using an enum help? You still have a string literal in your code. Shouldn't that be easy to find?

[ Parent | on HN ]

Re:We Reverse Engineered 16K Apps by BoorishBears on Monday January 16, 2017 @10:34AM (#13410497)

Stuff in native code (for example, XOR'd keys) is also marginally more difficult to access. It won't protect you from someone actively attacking your app, but it makes you less likely to get hit by people running automated scraping on apps for keys.

At the end of the day it's all security by obscurity and the real answer is proxying calls or TVMs to limit what individual keys can do, but it doesn't hurt not to be the lowest hanging fruit either.

[ Parent | on HN ]

Re:We Reverse Engineered 16K Apps by saurik on Monday January 16, 2017 @08:03PM (#13414410)

All of your "solutions" still involve having the keys on an untrusted computer: the one in my hand; it isn't correct enough to say it is "easier to just assume that everything you wish to keep private will be visible"... it absolutely fundamentally doesn't work to put something sensitive in the hands of the attacker, even momentarily. For people who just can't grok this, imagine some incredibly trivial to pull off scenarios: your app is modified, the Java virtual machine is modified, the Linux kernel is modified, the phone is actually an emulator and the "hardware" is modified... you can't trust anything in the hands of an attacker, and trying to hide things from them using slieght of hand is foolish: I'll just log the final network traffic and work backwards (which for many or even most kinds of credentials is something that can be trivially automated) instead of trying to slog forward from the output of a static analyer.

[ Parent | on HN ]