How much effort do I put in my security for Android In App Billing?

Question

I implemented In app Billing in my Android application. I pretty much followed the sample (Dungeon) application to get it working. It seems to be functioning fine as of now. I now need to decide how much effort I should put into the Security portion.

I do have a server that I could use to implement the Security.java stuff. I also am currently using the standard PurchaseDatabase implementation.

As of right now I am thinking of just encrypting the .db file with a device specific key, and leaving Security.java alone.

My thinking is that my app is a pretty niche app, and I am not expecting a lot of hacking on it. If there are some people that put in the effort to save a couple bucks (each item to be purchased will only be $1), so be it.

I guess I am looking for opinions on what other people think about this...it seems there is no 100% secure implementation...just implementations that make the hacking not worth the effort. Have other people seen a lot of hacking of In App Purchases?

Answer 1

You got it right: you don't need to implement very complex protection features, you need to implement protection features that take too much time to be found and removed Here's a video from Google I/O 2011 about techniques to reduce "leechers": http://www.youtube.com/watch?v=TnSNCXR9fbY, I thoroughly recommend it. Some techniques you may want to try are:

• use LVL;
• obfuscate code;
• call LVL at random times from a background thread;
• insert license checks mixed with normal code;;
• CRC code files;
• be industrious: use reflection in JNI to check signatures;
• encrypt core libraries/resources and load them on the fly.

Some of these techniques are very simple, other require a non negligible effort. The best recommendation is to be creative, hide checks where crackers do not expect them.

Another important point is to make your application degrade gracefully if you suspect piracy. For example, don't throw an "invalid license" because your license check needs network access on application start; instead, store somewhere a "valid for two months" token and randomly update it. Check it after a random number of days (say, a random integer in the 30-60 days range). Customers won't notice this check and it is hard to crack because it will not be apparent after a lot of time, much more time than crackers are willing to spend on a single application.