Android App Security

• Android app runs under their own sandbox under separate process. So one app can not access the resources, data and component of another without permission.
• Two apps can run under same sandbox using shared user id in manifest.xml.
• Avoid asking unnecessary permissions. There are mainly 4 types of permissions Normal (resources under same sandbox), System level (very danger), Signature (requires certificate), Signature or System.
• It is best practice to use Signature level permission because it is secure. System level permissions only use when it is required.
• Sign your release build certificate with strong password and keep it secrete. If anyone knows the password and have keystore file (can generate new) they can release new app using the same certificate and that app can access information from your app.

App Hardening (Obfuscation)

• It won't allow reverse engineer the apk code so that person can not analyze the code
• It is possible with the use of Proguard.
• We can enable proguard using minifyEnable true in build.gradle of our app release config
• Also debuggable false so that release build can not debugged.
• It will convert all the java files, classes, methods and variables to a, b, c, d, e, f and so that no one can understand what is for what!
• Remove all the logs using following code in proguard-rules.pro

-assumenosideeffects class android.util.Log {
    public static boolean isLoggable(java.lang.String, int);
    public static int v(...);
    public static int i(...);
    public static int w(...);
    public static int d(...);
    public static int e(...);
}

• Add following to your build.gradle

release {
    minifyEnabled true
    proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
    debuggable false
    jniDebuggable false
    signingConfig signingConfigs.configRelease
    renderscriptDebuggable false
    renderscriptOptimLevel 3
    pseudoLocalesEnabled false
    zipAlignEnabled true
}

• Now some code will be converted to unreadable form.
• Still your code is not completely unreadable. Lets have a look at the problem

public void setName(String name) {

   Log.d(TAG, "Secrete name=" + name);
   this.name = name;

}

• We have enabled the proguard and also stopped all the log statements to print but now if the code is reverse engineered than code will looks something like following

public void a(String s) {

   String _temp = a;
   b=s; 
   (new StringBulder("Secrete name=")).append(s).toString(); 

}

• Now person can identify that here some app Secrete is used or may be here there is a password like this "Password =" than this will be the entry point for the Hacker.
• Solution
• We should make our own Log class for using logs in app for debug build or testing app

public class LogWrapper{

   public static void d(String tag, String str1){
     Log.d(tag, str1);
   }
   public static void d(String tag, String str1, String str2){
     Log.d(tag, str1 + str2);
   }
   public static void d(String tag, String str1, String str2, String str3){
     Log.d(tag, str1 + str2 + str3);
   }
}

Now if we reverse engineer the code than it will looks like following

public void a(String s) {

   String _temp = a;
   b=s;  

}

Now you can not see the line with StringBuilder. Do not hard code any key, secrete or password

• Before releasing app we should reverse engineer our own code using following tools

1. ApkTool
2. Dex2Java
3. Apk2Java

• It will generate .smali files. Smali files are having readable names for all files, class, methods and variables if we did not used proguard.
• If you used proguard, still you can see your hard coded keys, secretes, passwords and strings
• Now you can rewrite your code again so that nothing is visible in code, only a, b, c, d.........
• Use proguard from the beginning of the application coding latter on it is very hard to use, You may get many errors.