I have been decompiling Android apps recently. In a sample of 37 apps, 12 of these use some form of custom encryption/obfuscation to store settings and credentials on the device.

By necessity, the app itself has the key to encrypt and decrypt. For 11 of these apps, the key/method is entirely hardcoded. One of the apps generates and stores the key at first run alongside the encrypted data.

My understanding of the Android system is that no app should be able to access another app's data. This would prevent other apps reading the data.

For all of these, recovering the encryption/decryption method is trivial.

What threats does encrypting like this protect against?

  • 2
    "What threats does encrypting like this protect against?" - "None." It's that simple. Commented Jul 24, 2015 at 15:08

1 Answer 1


The problem with hardcoded keys is that you can find them (as you did). As you've stated encryption and decryption of the data is trivial. Android's process isolation is solid (not perfect), but does provide a good degree of separation between applications.

There are three scenarios that I can think of that a threat could take advantage.

  1. Malicious Android App w/ Root
  2. Physical compromise of the phone
  3. App Has Full Access to its data

There are lot of apps and 3rd party apps out there that require root to perform all of its functionality. If your phone is rooted and you download a malicious app then the process isolation won't make a difference. The private data can be read, decrypted, and ex-filtrated.

If your phone is stolen the same thing can occur. An exploit can be used to root the phone, and download the private app data. With the hardcoded keys the data can be decrypted.

This is not to say that this is trivial to perform. The lock on your phone will (hopefully) force the attacker root the phone over USB. I don't know the specifics of all methods to reset a phone, but I believe most of them will remove any useful data from the phone. As an paranoid Android user I would avoid using the apps that I know have hardcoded keys, but if I wasn't paranoid I might not care as much. The level of effort to perform the exploitation is pretty high. They want to go through all that trouble to see my Candy Crush score... go for it1.

The third scenario is probably more concerning. If they use hardcoded keys what's stopping the App owner themselves from sending the sensitive information (could be encrypted) to their own private server. They know the hardcoded key, so they can just decrypt at will your data.

The threat model here really depends on what type of data these apps are protecting. If it's your preference to receive notifications... then maybe you don't care. If it's private conversations, contacts, messages, pictures, etc then this would be a larger threat.

By necessity, the app itself has the key to encrypt and decrypt.

Not necessarily. There are multiple ways that the app could encrypt private data securely without needing a hardcoded key. The app could require a user password that generates the encryption key or decrypts a private key that's then used to decrypt data. Or the apps could just use Android's secure storage since you know... it's provided, documented, and easy.

1 I'm not trying to say that hardcoded keys are a good idea or don't affect security. I'm just trying to point out that the level of difficulty of exploiting it would be high.

  • At runtime, the app has the key to encrypt and decrypt. (Or else it has a token that lets it make use of the key, I believe that's possible in Lollipop, but the token can be used by another app if app isolation is broken.) Commented Jul 24, 2015 at 20:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .