Securing Your Android App
Why LVL (Licensing Verification Library) isn't enough
https://docs.google.com/present/view?id=dfq4rkbs_262vrg7gbgj
In summary, LVL is definitely better than the previous copy protection (now deprecated), however there's a checklist of caveats that one has to be aware of.
LVL was "cracked" shortly after it's release in late July 2010, due to the fact that if one implements it by simply using the sample code verbatim, it's trivial to reverse engineer the app's code and remove the license verification protection.
In Google's reponse they mentiont that "100% piracy protection is never possible in any system that runs third-party code" which I totally agree with, my point is to buy some time by adding enough hurdles to not only delay piracy but prevent your apps from being hijacked with trojans. Although LVL doesn't apply to free (or ad supported) apps, it's still a good idea to implement your own licensing scheme. Basically it shouldn't be easy to design one-click tools that remove protection (including LVL) from applications.
The problem with providing a library with a sample app for developers to use with a list of caveats (or rather a todo list) is that it will never be a sufficient solution to address the more fundamental problem of hiding your verification code in your application.
A case in point is that even if you obfuscate there's the following exception added to your proguard.cfg file:
-keep public class com.android.vending.licensing.ILicensingService
Btw the LVL sample code lacks the proguard.cfg file so either copy it from another project or generate one from the command line:
android update project --subprojects -p .
So when you reverse engineer (even without using JD) it's easy to find the references to this package name which is required by the aidl interface to the licensing service provided with the Market app (a contract available since 1.5).
I suspect that Google may update LVL very soon (it's not working with the emulator+2.3 AVD anyway), and I'm hoping they will address some of these issues, even if it means a major reworking. And as I pointed out in a slide, a similar single point of failure issue may also exist in the new In-Apps Billing API (still in preview). In both cases, I'd recommend considering implementing your own complimentary backend server verfication solution as a backup.
The issue tracker for the market licensing (LVL) API is unfortunately not part of the main android issue tracker over at http://b.android.com but it has it's own google code project just for issues:
http://http://code.google.com/p/marketlicensing/issues/list
I'd suggest going there and voting for issue #13:
If you do depend on obfscation I also recommend the following resource (a bit dated but with excellent links to whte papers):
http://www.excelsior-usa.com/articles/java-obfuscators.html
If you look at general decompilation deficiencies (or the bug list for specific decompilers) you can buy additional time against reverse engineering. Another area to look at which I failed to mention was using native code to hide critical licensing code, but now we're talking about how much resources to spend on anti-piracy efforts vs how much revenue you can potentially lose.
In the future, I suspect other mechanisms could be considered like software watermarking, which doesn't defeat piracy immediately but can serve as a serious deterrent.