Hiding Strings In Obfuscated Code

I just Obfuscated my Android code using proguard and then decompiled it. There are a number of strings I would really like to hide from prying eyes. When I decompiled my code the

Solution 1:

Assuming you are happy with obscure rather than secure, there a number of mechanisms you could use, but obfuscaters like proguard are not going to be able to help you.

To achieve this you will need to do encoding or encryption of the string yourself, the approach you use depends on what you are trying to defend against, if it you are just trying to hide from obvious inspection, than encoding may be sufficient (see android.util.Base64, http://developer.android.com/reference/android/util/Base64.html). Note that encoding is in NO WAY SECURE and all it will to is remove the obvious reference to your site.

If you are trying to defend against something more, then you could move to actually encrypting the string, to do this you would use a symmetric cipher like AES via javax.crypto.Cipher, http://www.androidsnippets.org/snippets/39/index.html provides a decent usage example. Again this is more annoying then secure to would be hackers, as you will need to store the key somewhere in your jar thus negating any cryptographic security.

To make this clearer, the basic steps would be:

1. Manually create an encrypt your string using a known key.
2. Convert your code to use a decrypted version of this string, example:

Before:

publicclassFoo {
    privateStringmySecret="http://example.com";

    ...
}

Becomes:

publicclassFoo {
    privateStringencrypted="<manually created encrypted string>";
    privateStringkey="<key used for encryption";
    privateStringmySecret= MyDecryptUtil.decrypt(encrypted, key);

    ...
}

A (good) alternative to all of this is considering using a third party drm solution such as the licensing server google provides http://android-developers.blogspot.com/2010/07/licensing-service-for-android.html. This may be more secure than something you roll your self, but is subject to very similar limitations to what I described above.

Solution 2:

Hi all.

1. Let secret be the text you want to hide

2. Find the keyhash of your debug/release.keystore. Let k1 be this key.

(use tools keytool+openssl: keytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore | openssl sha1 -binary | openssl base64 )

3. Use a tool (external to the android code) to encrypt secret with k1

   encrypted = encode (secret, k1)

(For instance: https://jwt.io, for java: https://github.com/jwtk/jjwt).

4. In your android java code write down encrypted. When you need the decoded version of encrypted (this is, the original secret) write

original = decode(encrypted, get_my_keyhash_programmatically() )

That's all. This works because the original secret is not shown on java source code, neither the k1 to decode it. And, if a hacker wants to print your decoded secret, he must change code and recompile, signing his .apk with his own keystore not yours, and thus not getting the right original secret. (The "only" point is whether k1 can be figured out from your original .apk).

Note: get_my_keyhash_programmatically():

try {
    PackageInfoinfo= getPackageManager().getPackageInfo(
            "el nombre de su paquete por ejemplo com.tarea.u8",
            PackageManager.GET_SIGNATURES);
    for (Signature signature : info.signatures) {
        MessageDigestmd= MessageDigest.getInstance("SHA");
        md.update(signature.toByteArray());
        Log.d("KeyHash:", Base64.encodeToString(md.digest(), Base64.DEFAULT));
    }
} catch (PackageManager.NameNotFoundException e) {

} catch (NoSuchAlgorithmException e) {

}

Solution 3:

what I did was create a long list of static strings in my global utility class. Someplace within the long list of strings I put my passkey in multiple chunks.

with my code it's easy to see what the real passkeys are - but once the obfuscator gets to work all the statics will have name like A, B, C, etc. and it won't be easy to spot any more.

Solution 4:

I used ROT47. It's not very secure, but easy to use and implement, because it's a symetric encoder/decoder

Solution 5:

You should google for "Just another Perl hacker". These are programms that print out a string with obfuscated code. There are also lots of examples in other languages then Perl on the net.

Wikipedia entry