Deobfucate java code by running it

Question

Can I deobfuscate java code (apk, that contains obfuscated code, or java bytecode), when running it? If android gets able to run code, so he must get those keys, and get access to code which to run.

How I can intercept (read), code android is executing, but not to be assembler, where it's still obfuscated. I have rooted android, and want to pentest my app, to check if someone can access my server credentials which are obfuscated with proguard and other obfuscators.

Or another way around is it possible to obtain keys from apk itself.

EDIT I use TCP/IP socket to communicate with my server from the app (which has SSL, SSL works as intended when I check via Wireshark). The server I use is used as a download for the app (it downloads modules needed for app to function), so the server is used as a database for app, when the app downloads data (modules) from the server, app can function offline (so, only internet connection it uses is through the server to get data, modules).

Server credentials are hardcoded in only one place, one method, and I obfuscated it (from standard decompilers (dex2jar, enjarify, cfr, procyon), it doesn't decompile that method, even if all other code can be decompiled, it just shows throwOnError from the decompiler and show assembler, but, it's obfuscated, and assembler code don't show any sensitive code (like hardcoded credentials). That method is responsible for downloading modules from a server, so it contains credentials, which can be used in a method to download (as the server is only needed for app for the internet) I didn't store credentials in any sort of file, or anything that would suggest it, it's only in that one method that I obfuscated. But would like to know, if it's possible to extract from RAM, even if it uses SSL, how I can do it.

And I want to test this, because I don't want someone to crack into, and take over my server because app has credentials for server access, I want my app secure = peace of mind for my server.

Answer 1

We don't know where your server credential are stored.

But obfuscation is about the code, not the data of various non-code file or memory. And even if your credentials are hardcoded, they won't be changed by an obsfucator.

Whatever the way your credential are handled at some point those credential will be load up into memory before being sent to your server for authentication. Which mean as long as someone can have access to the full memory (running a android simulator for instance) they could get those credentials.

Also if you're not using SSL to communicate with your server, simply listening the network will permit to catch those credential.

The main question is, why are you using those server credentials ? To limit the access of your API to your server against simple bot or against the FBI ? As long someone is motivated enough, he will be able to figure out your API. But do you really need to protect let's say against a state agent trying to crack you ? You will lose.

Security is about risk management, so first determine what reasonable risk you want to handle.

Edit : about the TCP/IP connexion

There isn't much I can answer from this, however if you want to protect the privacy of your users, then your server credentials aren't enough. To me the only point of your server credentials is to disallow an easy access to your server API.

Now if you want to protect the data of your user from another user (from the point of view of your server), then your user should have their own login/password that grant them access to their data from your app. And your server code must make it not possible to access user datas if not authenticated as the correct user when using the public API.

Of course as an administrator you might need access for administration purpose (debug, check backups, stats,...). But then it would be preferable that those aren't part of the publicily exposed API, instead you could setup a protected SSH connexion and do your stuff when directly connected to your server.

I don't think there is much more I can say.