Security recommendation for Android in the application - what does it mean?

The Android developer says the following about saving the public key of your application in your project:

Safety recommendation. It is highly recommended that you do not hard-code the exact value of the key string of the public license key, as indicated in the Google game. Instead, you can create an entire public license key string at runtime from substrings, or get it from an encrypted string before passing it to the constructor. This approach makes it more difficult for malicious third parties to modify the public license key string in your APK file.

Should it be self-evident? I don’t understand what they want from me.

They say the same thing in comments for example, but that they don’t really demonstrate what they mean by their instructions. Here is what he says:

Instead of just storing the entire literal string embedded in *, create a key at runtime from fragments or * use bit manipulation (e.g. XOR with some other string) to hide * the actual key. The key itself is not secret information, but we do not * want the attacker to replace the public key with one *, and then fake messages from the server.

So how exactly can a person do this?

+8
android security public-key-encryption
source share
3 answers

The Android developer wants to say "public key", which you need to synchronize with the Google game for any payment that you want to use using your application. It cannot be used directly in the application source code, because it can be easily cracked by anyone. Thus, one way is to save your public key on the server side, and as soon as you get a response from the Google game to check that the key sends this response to the server and performs your operation there on the server.

/** * String transformation by XOR-ing all characters by value. */ static String stringTransform(String s, int i) { char[] chars = s.toCharArray(); for(int j = 0; j<chars.length; j++) chars[j] = (char)(chars[j] ^ i); return String.valueOf(chars); } 
+2
source share

This is very simple information that they are trying to say. Let's look at this example:

Some developers may store the license there as a string itself:

 private static final String LICENSE_1="xxx-yyy-zzz" private static final String LICENSE_2="xxz-yyz-zzz" private static final String LICENSE_N="xxz-yyz-zzz" private ArrayList<String> licenseList=new ArrayList<String>(); licenseList.add(LICENSE_N); 

And they may want the user to enter their license number, so they will do something like this:

 if(licenseList.contains(ExitText.getText().toString()) //allow else //disallow 

Now I can decompile this application and get the whole license: D

If you did not have anything like the above in the code, the only way I could get around your licensing is to do it locally, it can be hacked into memory like GameCIH does. Hacking memory is just one example; there are various things that attackers can do. You cannot stop them, but you can make your life harder.

+1
source share

As already noted, security through the unknown does not work, so you can ignore the documentation.

+1
source share

All Articles