Way to protect from Lucky Patcher / play licensing [closed]

Question

I'm about to release an application and don't want it pirated... There are apps like luckypatcher which crack the application for you even if you have licensing...

Anyone knows how to protect from this?

Answer 1

To stop your app from being distributed and repackaged in cracked form, see the below for a signature check. Then at least the only people who can make your app work are those who have got LuckyPatcher installed. Once LuckyPatcher creates a modified APK, the signature is changed.

You need to find out what your signature is when you have run a release version. In the example below it's -343553346 .

String sigChk = MySigCheck.MySigCheck(context);
if (sigChk.equalsIgnoreCase("Y")){
    handle signature pass
}

Create a class

public class MySigCheck {
public static String MySigCheck(Context context) {
    String sigChk = "B";

    Signature[] signature = new Signature[0];

    try {
        signature = context.getPackageManager().getPackageInfo(context.getPackageName(), PackageManager.GET_SIGNATURES).signatures;

        Log.d("yourapp", Integer.toString(signature[0].hashCode())); << Prints your signature. Remove once you know this and have changed it below.

    } catch (PackageManager.NameNotFoundException e) {
        e.printStackTrace();
    }

    if (signature[0].hashCode() == -343553346){
        sigChk = "Y";
    }

        return sigChk;
    }
}

Answer 2

The short answer is not really.

You can watch a google IO chat about some best practices for using licensing API's etc Google IO Anti Pirate

I know there is another talk about general patterns to thwart lazy pirates as well but can't seem to find the URL.

In general if your protection is dependent on if/then logic all someone has to do is patch the code and invert that logic or bypass it all together which is pretty easy in Java.

You can make it harder by obfuscating where you are doing this, doing it in many places, doing it randomly, and adding pro-guard obfuscation etc. to dissuade casual hackers.

Even server side logic is simple to bypass unless the return package is used in some way (like an encryption token that is synced with the user or phone information to unlock content, or a user id verification scheme that is required to access online community content etc.)

In the end if someone is determined and has skills they can get around all of it and unless you are losing serious revenue it's hardly worth losing sleep over in my opinion, which is a problem we ALL need to have!

After doing this for 20 years (commercial development) my approach is to make it difficult by using the above patterns, and change it occasionally. That weeds out the lazy pirates.

Then forget about it and concentrate on making an application that is worth stealing by the pro-pirates.

MY APPROACH

My app's are mostly content driven.

In general if someone buys content it gets encrypted using tokens server side and un-encrypted using the same (which are not stored but generated each session using device and user tokens, which only makes it a bit harder to spoof honestly)

I can then track access by user/device pairings. The downside for the hacker is that they have to pay once, and if their tokens are suddenly getting used beyond reasonable limits it alerts me to the fact, and I can turn off that account if I want to ( and I have )

I have found that socially people are far less likely to let someone use information to cheat if it's associated with them (though it has happened) and it will come back on them.

I still follow all of the advice from IO/Dev Blog etc. and if I detect tampering then I inform the user and then let it go for N period of time so they can contact me or self correct.

I also never kill an app, but I do tell the user they are using malware, and ask them if they really trust the person that stole it with their data etc. those kind of pop up's have bit'd messages so simple string searches won't work etc. and throw a scare into people

I also have a way to send a poison token set to the device that will in essence lock out any data they have accumulated with the device unless I unlock it BUT you better be really sure they are thieves before you go nuclear on them.

Also don't discount analytic's as a way to detect, and determine the proper action to take when a pirated copy is detected.

Follow the guidelines the blog post and IO mentioned, then be creative in applying them, and mixing a some what unique solution, then change it every so often to give the pirates fits.

Answer 3

Base on the fact that LuckyPatcher uses odex replacement for its hacking purpose. I think the modest way to defeat its current implmentation is to compile your important piece of code in separate dex, and load it via DexClassLoader.

Ref: http://android-developers.blogspot.pt/2011/07/custom-class-loading-in-dalvik.html

Answer 4

The way I do it, is to keep an eye in the package name of lucky patcher, in case they change it. So at runtime I check if it is installed, and I simply do not allow to use my app if this one is actually installed on the phone, even if they purchased the app. I warn the user and kill my app. So he will have to find another way to crack it. The worse I can get is that he has to buy my app and will sure put 1 bad review. But honestly, I prefer 1 bad review from a hacker than 1000 pirated copies a day.