Application billing protection - what’s the problem with a confusing key?

Question

I am implementing Google Play In-app billing in the Xamarin app, so I am looking at both the android and xamarin documentation. Both of them recommend obscure ways to trick the public key inside the application:

http://developer.android.com/training/in-app-billing/preparing-iab-app.html

Safety recommendation. It is highly recommended that you do not hardcode the exact value of the public license key string, as indicated on Google Play. Instead, you can build a whole row of the public license key at run time from substrings or retrieve it from encrypted storage before passing it to the constructor. This approach makes it difficult for malicious third parties to modify the public license key string in your APK file.

http://components.xamarin.com/gettingstarted/xamarin.inappbilling/true

Although it is best practice to perform signature verification on a remote server rather than on a device, this may not always be possible. Another way is to trick your Google Play public key and never store the collected key in memory. Xamarin.InAppBilling provides a Unify routine that can be used to break a Google Play public key into two or more parts and to obfuscate these fragments using one or more key / value pairs. In addition, Xamarin.InAppBilling always encrypts your private key while it is in memory. The following is an example of using Unify to obfuscate a private key:

string value = Security.Unify ( new string[] { "X0X0-1c...", "+123+Jq...", "//w/2jANB...", "...Kl+/ID43" }, new int[] { 2, 3, 1, 0 }, new string[] { "X0X0-1", "9V4XD", "+123+", "R9eGv", "//w/2", "MIIBI", "+/ID43", "9alu4" }) 

But nowhere is it explained what the deal is made. Why does anyone want to see this key? How would anyone benefit from viewing / replacing a key in my APK? What are the possible “attacks” here? Thanks.

Answer 1

I understand that your public key is not necessarily a secret, but it is another way to help someone easily replace your key with your own key. It basically keeps the key confused while it is in memory, making it difficult to retrieve.

Say your application uses this to download additional content. If a user replaces your publication with those who know the private key, they can generate purchase receipts without even contacting the server, and your application will consider them to be real.

The best way to avoid this is to do a check on their own server, where they cannot get the code. If the server checks it, it boots.

No matter what you do, it is a fact that your application can be hacked if they want to spend time doing it. Even after all key checks are done, it may be necessary to flip one bit to change the result of the key check. The goal is to give them another hurdle to overcome.