9

For the paid version of my app I'm opting for the unlocker app route because it's easy to implement, allows for individual stats in the Developer Console but mostly because I wouldn't need to maintain 2 code bases (one for the free version and another for the paid version). Even If I used a CVS (which I do) it would still be a pain in the neck to keep merging features and bug fixes. The unlocker app is much easier to implement overall...

But this comes with a serious disadvantage, it's really easy to overrun the security check; unless I'm missing something here.

No matter what I do, such implementation will always lead to a simple if, like this:

if(Program.isPremiumVersion()) {
    // Remove ads...
}

The isPremiumVersion() method is the one responsible for all the work in checking for the paid unlocker app installation, if the certificates match and all that stuff. Yes, the unlocker app is protected by the LVL (although I've read a few articles mentioning how insecure LVL is, but that's not the point right now). But in the end, no matter how complex the code inside isPremiumVersion() gets, it always results in returning a true or false value.

Overriding such security feature is just a matter of reverse engineering the code and get it to always return true. Is it not? How can we protect our Android apps against this? And yes, the code is obfuscated with ProGuard. Still, shouldn't be too hard for someone skilled enough.

Please note that I'm not trying to fight the crackers, we simply cannot win. I'm not going to lose sleep over this, wasting countless hours on the "perfect solution". I'm just looking for a way to make it a little more secure. This just seems so simple to crack, in theory at least. Am I wrong though?

Any ideas to improve the security of such feature?

rfgamaral
  • 16,546
  • 57
  • 163
  • 275
  • Just use the java equivalent if `IFDEF`, or make `isPremiumVersion` a constant, and rely on the compiler optimizing it out. – CodesInChaos May 10 '12 at 17:54
  • 3
    Not a solution for your cracking issue, but the issue of duplicating code should be mitigated if you use a android library project (not launchable). It's more or less a shared library of classes/layouts/drawables that can be called from launchable applications. Create two versions of your app (Free, Paid) and create a library with all the common code. In your free/paid versions, you can override layouts/strings/drawables/etc if they need to be different than what's in the shared library. Should serve your needs: http://developer.android.com/guide/developing/projects/projects-eclipse.html – Gophermofur May 10 '12 at 18:03
  • @Gophermofur Yes, I'm aware of the library approach but I don't like it and it comes with other "issues". No need to go deeper though, it's not relevant to the question. I've decided long ago that I'm going with the "unlocker" method and there's no discussion there. I appreciate your suggestion though :) – rfgamaral May 10 '12 at 20:31
  • You can only prevent it from script Kiddo. Make a webservice and hide the premium functionality behind it. – Lukasz Madon May 10 '12 at 22:08
  • @lukas Won't that lead to the same problem? I mean, whatever I do, the server check will always return "licensed" or "not licensed" and then I either enable or not the premium functionality. It's all the same in the end... Or am I missing something? – rfgamaral May 16 '12 at 16:37
  • @Ricardo no, it won't cause the cracker can block your service and fake it. For example, Adobe Photoshop check the servers for the license. The crack for it add the IPs in windows host file to block it. – Lukasz Madon May 16 '12 at 17:45
  • @lukas I don't get it... I can't understand how a server check is safer... – rfgamaral May 16 '12 at 21:15

2 Answers2

7

There is no easy way around this.

You have to try to mask it. Here are a few tips:

Tip 1: Returning boolean is too obvious. Try returning a value (int, for example). Then, use a comparison to see if that is a valid known return value.

For example: get the md5 of a string that contains something from which you can tell if it's premium or not. Say that you've got a static final string on each app. Maybe the md5 of one starts with a 9 and the other starts with a 1. In this case, calculate the md5 and see if it's greater than a "random" number that you know it's in between the other two numbers. Say that the md5 of "premium" is 987 and the md5 of "free" is 123. You can calculate the md5 and compare it to 456.

Tip 2 - Even better: duplicate some code and use different values every time (instead of 456)! Hopefully this will make it more difficult to decode the obfuscated code.

I know that all these checks will eventually be mapped to a boolean (if(1 > 2) will be evaluated to if(true) ) but it should be more difficult to reverse engineer your app.

Tip 3: don't run the checks for "isPremium" in the most obvious places. For example, don't do the check when you start your app as this is the most obvious place to do it. It might be difficult to avoid certain obvious spots if you want to have conditional logic depending on the version of the app, but do your best here!

Tip 4: build and obfuscate your app. Run reverse engineering tools against your apk. Read it and see how it looks.

Finally, watch this Google IO presentation everyday at breakfast: Evading Pirates and Stopping Vampires using License Verification Library, In-App Billing, and App Engine

[EDIT - a few more tips]

Tip 6: try to use the code you use to check in perfectly valid places. This might disguise what you are really doing in there. This might include calling the code to check which version of the app this is, but doing nothing meaningful with it. Or, in my previous example, comparing the md5 with 012 or 999, just for the sake of diluting the real use of these variables.

Tip 7: instead of relying in a single string, you might considerer constructing the string at run time. Finals and statics might draw too much attention too, so avoiding those could be a good thing.

Tip 8: don't ever use the LVL code as provided in google tutorials. Modify it. A lot!

Note: I'm not sure if any of these tips will actually make a big difference, but you should have good chances of at least making crackers' life a bit harder.

Community
  • 1
  • 1
Pedro Loureiro
  • 11,436
  • 2
  • 31
  • 37
1

You may have already seen this, but here is some code for implementing what you are talking about:

http://groups.google.com/group/android-developers/browse_thread/thread/4ad3d67f735f16d7/948b4f9eee2490a3?pli=1

It checks that the signatures on the free and unlocker app are the same. So it is not possible for someone to artifically create an app with the correct name as the signitures will be different. However, it is still possible for people to rip the apk off the phone and distribute that. The only way to combat that would be to use some sort of server authentication but this adds cost and complexity.

James Cross
  • 7,799
  • 8
  • 24
  • 30