Piracy, piracy, piracy. What can I do?

Question

I've just released an app, a paid app, 4 days later a user told me there's another web site in China hosts my app. I downloaded it from there, and it does run fine on my device!

There are posts here saying people can change the package name and republish an apk. But this is not my case, the cracked version still uses the same package name. I used Android Vending Licensing in the program, but the cracked version does not do licensing check at all. I used ProGuard to obfuscate it, but that doesn't discourage the hackers.

Question #1: I signed the apk file according to Google's instructions. But still, they modified the code and took out the licensing check part. Am I wrong that signing an apk file is designed to keep people from tampering with the file content?

Question #2: For Win32 .exe programs, I used to use a checksum to determine if the file has been altered. This is how it works: When a .exe is created, I used a tool to calculate the sum of byte contents of the file, then stuff it into somewhere in the file, for example, 4 bytes after a text pattern "MY SIGNATURE". Then at run time, the program opens the .exe file and calculates the byte sum, compares it with the integer after the signature.

Has anybody tried this approach on apk files? Care to share your experiences?

Answer 1

Ultimately the built in protection of apps in Android is very poor. Here are your best practices.

1) Yes Google's recommendation to use code obfuscation, signed coded, and their license verification server is designed to prevent software theft. Their implementation however is highly flawed. The only requirement that an APK has to run is that it be signed. It doesn't matter who signed it though. There are no checks that your signature is the one it's signed with. So to crack it you just remove the license check and re-sign with whatever cert you want. Then a user can load it on their phone with "allow non market apps" checked.

Don't use Google licensing as is. Modify the code heavily. Add some new parameters to use when generating the keys. Move the code around / re-architect it. Don't include the Google licensing library as a library project. Put it directly in your code. Make the code as spindly and kludgy as possible. Add functions that do nothing, but modify the values on the fly. Make other functions later that convert them back. Spread license verification throughout your entire code base.

If you don't do those steps then the code can be cracked automatically. By doing those steps at least the cracker needs to take the time to hand crack it. That would probably only take a few hours at most. But a few hours is much much more time than instantly cracking the standard Google licensing layer. There are cracker tools that will actually just auto-download newly released android packages and, if they use the standard android licensing, crack them and upload the cracked APKs to these types of web sites. By making your implementation not the vanilla implementation you make things much harder, with only a few hours effort on your end.

2) This is a common anti-crack technique. You can do this on Android if you want. But it can be cracked in about 5 minutes. If you Google there are tutorials on how to crack this specific technique. Basically you just look for the CRC call in the code and remove the check after the CRC comes back.

Android has no inherent security. You can root any phone and download the APK. You can easily hack an APK to enable debugging and simply step the code to see any keys you have stored in the code. So in the end I wouldn't spend too much time on this. It's impossible to secure an Android App. I would just do the common sense stuff in the list above and move on.

3) If you're really paranoid you can implement your own licensing on your own licensing server. This is the approach I took, but not as much for protecting the app for theft, as it was to give me a mechanism to sell apps directly from my website so users that don't have Google Play could still purchase my apps.

Answer 2

Passive/Aggressive Scuttling

I agree with @metalideath that obfuscating and cludging the licensing code is not foolproof.

Here is an easily hidden technique I call 'scuttling' that works for apps deployed to Google AND Amazon. Scuttling is front-end piracy detection by the app. What to do once detected is in the purvey of the app creator.

• Aggressive Scuttling: Eg. Termination and/or alarms on pirated app. Network communication not necessarily required.
• Passive Scuttling: No app modification. Eg. enable tracking.
• Passive/Agressive Scuttling: subtle app modification. Eg. silently disable key features. Lead pirate into thinking they bungled, and into unpublishing the pirated app.

If your app was renamed and/or installed from any source other than Google or Amazon, scuttle() returns true.

// Dont just copy/paste this code - that is what automated crackers look for - cludge it!
// No network communication is required at runtime.
// myPackageName should decode at runtime to "com.yourpackagename"
// google        should decode at runtime to "com.android.vending";
// amazon        should decode at runtime to "com.amazon.venezia"; 

public boolean scuttle(Context context, String myPackageName, String google, String amazon)
{
  //Scallywags renamed your app?

  if (context.getPackageName().compareTo(myPackageName != 0)
    return true; // BOOM!

  //Rogues relocated your app?

  String installer = context.getPackageManager().getInstallerPackageName(myPackageName);

  if (installer == null)
    return true; // BOOM!

  if (installer.compareTo(google) != 0 && installer.compareTo(amazon) != 0)
    return true; // BOOM!

  return false; 
}

RESULTS

The following screenshot was taken from google analytics showing a pirated tracked free app from playstore (com.android.vending) that was redeployed with aggressive scuttling (non-playstore installs detected and terminated). Non-playstore (not-set) tracking drops. Tracking was not required, but enabled for these measurements.

DISCUSSION

Note service signing plays a role in scuttling: The package manager enforces unique package names with unique signatures.

This presents the question of what to do when the app is scuttled (pirate detected by the app). Piracy is a form of viralization (uncontrolled distribution) of your app. It is already detectable by enabling the analytics tracking back-end. Scuttling allows the app creator to customize a front-end response with or without tracking.

Aggressive scuttling is obviously detectable by pirates (BOOM!). This encourages further cracking. Passive scuttling is far less obvious, but may involve tracking.

Piracy may not be preventable but it is predictable, detectable, and trackable.

Tracking can present insurmountable problems to pirates, but also presents it's own ethical issues.

Passive/aggressive scuttling requiring no network communication as outlined above is perhaps the best solution. It is easily hidden (unlike licensing) and can be tailored to be as unobvious as possible.

Answer 3

The best thing to do is not worry about it. The people pirating it in China are not your customers, and never will be. If there was no pirate version available they still wouldn't pay you for a copy, in all probability. Besides which if your app becomes popular it will be cloned anyway, just like iOS apps are. The security systems you have already implemented are all that you need as they prevent most users from pirating the app.

Trying to make your app piracy proof will just harm the code base and make it harder to maintain, as well as potentially introducing problems for your genuine paying customers. Instead focus on promoting your app and making it easy for customers to pay for and use. By being responsive to feature requests and bug reports you add value that people are willing to pay for, rather than seeking out some dodgy cracked copy from a Chinese web site that is probably a trojan anyway.

Finally, report the pirate copies to anti-virus vendors. Supply copies of the APK. They will add signatures to their databases so that it gets flagged up as potentially dangerous.

Answer 4

My understanding from reviewing the Google market terms is that you cannot sell your app directly from your own site as it violates the Google app market terms. I think that implementating custom protections in your code is the best way to go. Standard methods just are not effective since code can be easily dissassembled