12

The app I am working on is automatically cracked by antiLVL (although I am not using the LVL in my app).

In order of protecting my app from "one-click piracy", I am implementing tampering detection techniques explained at Google IO.

I have tried checking the signature both with getPackageInfo() and reflection (invoke()), but AntiLVL was able to crack the app automatically in both cases.

How can I write code that will not be automatically cracked by the current version of antiLVL (1.4.0)? I mean, apart from using JNI.

PS: I am not talking about preventing piracy in general. I just want the pirate to dig into the code by hand rather than using an automatic cracker.

Mike Samuel
  • 118,113
  • 30
  • 216
  • 245
tos
  • 996
  • 1
  • 10
  • 20

2 Answers2

1

The problem is, any API that only serves to check the validity of your application can be subverted and replaced with a version that always returns the result you expect. I haven't looked at Anti-LVL in detail, but I would imagine it is doing this, which is why your attempts to verify your code using Dalvik's built-in APIs for this purpose are failing.

In order to make it work, you'll have to do the work yourself, using only APIs that have multiple purposes and cannot be so easily subverted.

One way of doing it is to calculate a checksum of either your .apk file or just the classes.dex file inside it, and verify it against some external resource (online server with list of known correct versions, file downloaded to SD card on first execution, etc, resource in the .apk file that isn't included in classes.dex). This prevents code modification, which I believe is how anti-LVL works. I haven't tried this myself, but suspect it should work.

Jules
  • 14,841
  • 9
  • 83
  • 130
  • Thanks for answering. AntiLVL is a beautiful software. Clean, powerful, well-thought and customizable. It is "easy" to circumvent it in that you "just" need to write code that will not be caught by the grep-and-replace rules (provided in a separate xml file). However, I just don't have enough time to spend learning how to generate unusual smali. In my code, AntiLVL was able to unhook and neuter all my checksum attempts. – tos Mar 04 '12 at 00:09
  • I don't know enough smali to understand the "replace" part of the rules (it would be useful to know what happens behind the scenes). I did think about your point about multiple purpose APIs. I thought about laying a minefield in the software: the cracking program would remove an important part of the program, which would either crash it or make it useless. Until now I didn't find anything. – tos Mar 04 '12 at 00:29
0

The Presentation Notes from Evading Pirates and Stopping Vampires

Some basic keypoints

Please note, the #:r.page.X at the end of the links I've provided will not always bring you to that specific slide page number for whatever reason. If it doesn't, take note and browse manually.

TryTryAgain
  • 7,632
  • 11
  • 46
  • 82