Protect string constant against reverse-engineering
Asked Answered
C

10

27

I have android application that has hard coded (static string constants) credentials (user/pass) for sending emails via SMTP.

The problem is that .dex file in .apk can be easily reverse-engineered and everybody can see my password.

Is there a way how to secure these credentials, while i will still be able to use them in my classes?

Centric answered 15/9, 2011 at 18:57 Comment(4)
Why don't you hash them?Chicoine
@Richard H, I think if he has to reuse the credential, hashing is no possible?Jamie
If he hash them how can he unhash login/pass to send it to SMTP server? If it would be two-way function it would be easily decrypt. If it would be hash that reqire salt/key he would need to hash it too. THERE's even thread about decompiling DEX to sourcecode.Printmaking
@Y.A.P - yeah sorry I didn't appreciate that two-way encryption was required.Chicoine
H
7

We can use "jni module" to keep 'Sensitive Hardcoded Strings' in the app. when we try to reverse engineer APK file we get lib folder and .so files in respective process-folders. which can not decrypt.

Harry answered 27/6, 2016 at 10:0 Comment(2)
i can still see strings in .so files.Moreno
string are visible in .so file it 's not secure.Trichiasis
S
5

You can save your string obfuscated by AES.

In Licensing Verification Library you can find AESObfuscator. In LVL it is used to obfuscate cached license info that is read instead of asking Android Market to find out application is licensed or not. LVL can be downloaded as component of SDK.

Sakai answered 15/9, 2011 at 19:26 Comment(0)
C
4

I guess you can try a code obfuscator, but really that won't make your password 100% secure and I don't know how well it goes along with the android compiler. Why not use a secured web authentication , like that of Google?

Corse answered 15/9, 2011 at 19:1 Comment(2)
I think obfuscator won't change the content (the credentials) of the String. The content needed to be encrypted first. But as you said, better web auth.Jamie
ProGuard (the obfuscation tool provided by default by the Android SDK) doesn't encrypt nor obfuscate strings. DexGuard does encrypt strings, but it's a bit expensive.Neat
G
3
  1. Hashing is not possible since it is not two way.
  2. Any encryption such as AES, DES, blowfish, etch is not a viable solution as you have to include the decryption part within your app and that can be decompiled with a combination of apktool, dex2jar and JD (java decompiler) which is a very powerful combo while decompiling any apk.
  3. Even code obfuscators don't do anything except make life a little more difficult for the decompiling guy, who'll eventually get it anyways.

The only way which I think would work to an extent would be to host the credentials on a server which only your application can access via a web-service call through a separate authentication of some kind - similar to FB's hash key thing. If it works for them, it should work for us.

Gladygladys answered 15/9, 2011 at 19:35 Comment(3)
...which brings the question if how the server will distinguish "only your application" access from hacker's access.Genital
Right, you are stuck again - this way.Obscurant
@EugeneMayevski'EldoSCorp Any improvement?Prussian
R
2

I was looking into a similar problem and came across this useful thread: http://www.dreamincode.net/forums/topic/208159-protect-plain-string-from-decompilers/

I'm not too familiar with Android development, but the same ideas should apply.

Romance answered 19/9, 2011 at 15:26 Comment(1)
Great lnik! That is a very interesting ideaRonnieronny
B
2

doing these would be useful:

1- you can encrypt them and obfuscate the encrypting algorithm. any encryption along with obfuscation (progaurd in Adnroid) is useful.

2- you better to hardcode your strings as byte array in your code. many reverse engineering applications can get a list of your hardcoded strings and guess what they are. but when they are in form of byte array they are not readable. but again Proguard is necessary. (it only hides from RAM string constant searching and they are still searchable from .class file)

3- using C++ code to host your constant is not a bad idea if you encrypt them before hardcoding and decrypt them using C++ code.

there is also a great article here :

https://rammic.github.io/2015/07/28/hiding-secrets-in-android-apps/

Briefcase answered 5/9, 2018 at 14:17 Comment(0)
T
1

If you do not have the means to do a web authorization you will need to include the third party decryption with you application.

This is what you could try 1) Write a standalone program only to create a password hash one time. (This program should not be a part of your app). Make a note of the hash that was generated. http://www.mindrot.org/projects/jBCrypt/

 // Hash a password for the first time.
    String hashed = BCrypt.hashpw(password, BCrypt.gensalt(12));

2) Store this password hash as a String constant in you APK.

3) Then every time you need to check the password, compare with the hashed password, using bcrypt.

// Check that an unencrypted password matches one that has
// previously been hashed
if (BCrypt.checkpw(candidate, hashed))
    System.out.println("It matches");
else
    System.out.println("It does not match");

jBCrypt is a single java file and it can be directly included in your application. It is considered one of the strongest encryption algorithms for passwords. Even through the decryption algorithm is present in you APK, trying to break this is very time consuming details of which can be read in the article below.

Read this article for details and security of bcrypt.
http://codahale.com/how-to-safely-store-a-password/

Again, use this only if you do not have the means to do web based authentication.

Thickening answered 15/9, 2011 at 19:59 Comment(2)
But he seems to need the original pwd instead of the hashed pwd for the smtp authentication. How can we reverse that?Gladygladys
What about the candidate string? Or I'm missing something or this answer is useless.Neat
A
0

Use some kind of trivial encryption or cipher that only you (and your code) understand. Reverse the string, store it as array of integers where you need to take the mod of 217 or something silly to find the real password.

Adown answered 16/9, 2011 at 6:21 Comment(0)
S
0

One way you can 100% secure you hard-coded string. Firstly don't use pro-guard use allatori Link: http://www.allatori.com/

And secondly don't take you hard coded string in any variable just use that string like this:

if(var=="abc"){}

"abc" is exampled hard coded string.

Allatori fully obfuscate all string that are used in code like above.

Hope it will help for you.

Subpoena answered 5/9, 2016 at 12:34 Comment(0)
B
0

Even if you use "jni module" to keep 'Sensitive Hardcoded Strings' in the app, the .so file generated from the decompiler cannot be readbale directly but using [https://dogbolt.org/][1] we can decompile the .so file and can get the 'Sensitive Hardcoded Strings'.

Belier answered 12/2, 2024 at 8:47 Comment(0)

© 2022 - 2025 — McMap. All rights reserved.