6

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?

Marco
  • 368
  • 1
  • 4
  • 16

8 Answers8

12

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;
    }
}
zeroprobe
  • 580
  • 1
  • 8
  • 19
11

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.

Idistic
  • 6,281
  • 2
  • 28
  • 38
  • 2
    u mean: http://android-developers.blogspot.com/2010/09/securing-android-lvl-applications.html ? and you are DAMN right! "concentrate on making an application that is worth stealing by the pro-pirates." but still it isn't cool :( Are your applications protected against this lucky patcher? – Marco May 14 '12 at 16:58
  • 1
    Yes that's basically it. The key is don't use a well known solution (hackers have those and pattern them) make sure you don't help them find your check points by tipping them off as to where and when things happen. I will modify my answer to tell you what I do, but it may not work for you. – Idistic May 14 '12 at 17:30
  • 1
    Obfuscation techniques for Android APKs http://stackoverflow.com/a/17464629/319204 – TheCodeArtist Jul 22 '13 at 03:30
6

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

Oasis Feng
  • 7,490
  • 3
  • 31
  • 44
3

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.

PerracoLabs
  • 16,449
  • 15
  • 74
  • 127
2

Only way I have heard of is to do server verification... have your app contact a server and verify they purchased your app.

This is about in-app billing through Google, Why is signature verification on remote server more secure than on device?

Some good info on the dev site about Google Play in general here and in-app billing specifically here

Unfortunately I'm not finding much else...

Community
  • 1
  • 1
Barak
  • 16,318
  • 9
  • 52
  • 84
  • do we receive any information about the buyer? Like a serial no. so we can say: askserverifserialnoisknown == true then okay :D – Marco May 14 '12 at 15:24
  • As I have not joined Google Play (I mostly make apps for my own use) I really don't know, but in all the discussions I've seen about this topic, the consensus is that if you want to combat piracy of your app, doing a server check is the way, so I must assume that some sort of thing exists. I'll dig around and see if I can find some info and post links in my answer. – Barak May 14 '12 at 15:29
  • We do this extra server check and it shuts down most of the patching tools that bypass the stores. It can get complicated if you maintain a 100% unique developer payload (recommended) and we pay for the storage of all the receipts as well. It doesn't solve our multiplayer cheating problem so it is of way less value. But we do use it to gate access to server features (stuff that costs us money month after to month to continue hosting) – Hunter-Orionnoir Apr 04 '16 at 19:35
1

As a professional IT engineer and general power user (Linux, Windows, Android, OS X, iOS) as comfortable in command line interfaces as graphical, I use the tools at my disposal to achieve my ends. I could not imagine using an Android device that isn't rooted, and I'm normally loaded with a plethora of utilities that require it. At the very least, I enjoy the freedom of controlling the obligatory bloatware that normally comes with my favourite device, inserting my own system apps, and making legitimate modifications for aesthetics, comfort, and convenience.

I have been forced down some dodgy avenues just to achieve proper functionality in apps whose authors choose to cripple rooted users. Being told that my device has 'unauthorised modifications' by (for instance) Virgin TV Anywhere makes my blood boil, and I'll happily break their code and contravene some license agreements if it's the only option available to me in pursuit of expected functionality.

In this regard, I agree that you're inviting a lot of users, whether through indignant spite or mere utility, to foil your efforts should you choose such a draconian path as the aforementioned media application. This might even encourage piracy of your app altogether when 'fixed' versions of your code become more prevalent as torrents than your legitimate sales.

Personally, I always go for the paid option, even when I'm forced to swallow my sense of security and break it with tools I scarcely trust in order to make it work. For many, though, the initial exposure they'll have to your product is through nefarious channels, and they're hardly going to go paying for the legitimate and hopelessly crippled version.

I understand why some coders are forced to make these choices, and its good to see sensible questions asked about the right way to protect intellectual property.

It is even more reassuring to see sense in the answers.

Just my tuppence.

Gwalchgwyn
  • 27
  • 1
0

If they have a rooted device the can hide the su binary to use the app too checking root is the best method unless your can be used with the non rooted version of freedom and then you will need to fix that. Putting a check for hacking tool like game killer is going to stop lazy people but not one that can decompile an change the string to another.

Josh
  • 1
  • 1
-5

Lucky Patcher work in rooted device. i check the phone is rooted or not.in my first activity i check if phone is root, my app locked Otherwise my app opening.

check is root with bellow method :

    private static boolean isRooted() {
    return findBinary("su");
}



public static boolean findBinary(String binaryName) {
    boolean found = false;
    if (!found) {
        String[] places = {"/sbin/", "/system/bin/", "/system/xbin/", "/data/local/xbin/",
                "/data/local/bin/", "/system/sd/xbin/", "/system/bin/failsafe/", "/data/local/"};
        for (String where : places) {
            if ( new File( where + binaryName ).exists() ) {
                found = true;
                break;
            }
        }
    }
    return found;
}
esideli
  • 5
  • 2
  • 9
    No. Don't do that. Lots of legitimate users have rooted devices, and that's a surefire way to piss them off and prevent them from buying your app. Even if they don't then end up pirating it as a result (which I wouldn't blame them for if you do this) a lost sale is still a lost sale. – flarn2006 Apr 06 '15 at 10:35