I'm hoping for Eclipse integration of Proguard. On Aug 24, 12:38 am, Trevor Johns <[email protected]> wrote: > So far, in all the cases of cracked apps we've seen, it's been because of > the following: > > 1. The developer did not run a code obfuscating tool (such as ProGuard) on > their application; and, > 2. The developer implemented the LVL as a drop-in library, without making > any modifications to the library code or API. > > Let be clear here: the LVL is not a panacea. As shipped, it will protect > against casual copying. However, if somebody is determined enough to take a > decompiler to your APK, you have to be a bit more diligent about how you > integrate it. > > There's a reason that we ship the LVL as source code rather than as a JAR > file. We encourage you to do things like change the entry/exit points, > subtly tweak the logic in LicenseChecker and LicenseValidator, and even move > all the entire library into your project's package. Think of the LVL as a > framework for a license check mechanism: it's an excellent starting point, > and all the tools (or rather, APIs) you need are there, but don't treat it > as a black box. > > And I *strongly* encourage you to run a code obfuscater, such as ProGuard. > If you decompile an application and see symbols like allow(), dontAllow(), > LICENSED, NOT_LICENSED, etc., it gives crackers a pretty good hint what they > need to modify. > > On top of that, pay attention to how you integrate the LVL in your > application. For example, if your application displays a dialog on license > failure, imagine what would happen if a cracker disabled the call to display > your dialog (invoking a method is a single line of bytecode, not difficult > to comment out). Will your application still terminate if the "Exit" button > in that dialog never gets pressed? > > And even with all of this, I need to be clear: This is a client-side license > check. It's not bulletproof -- this is the nature of client-side code. > However, implemented properly, it will make your application *difficult* to > crack. > > And as long as it's not possible to create an auto-crack that works on your > application (which, if you follow the rules above, shouldn't be possible), > then it's still an improvement over the old copy protection model, which > only required a rooted phone to bypass. > > And if you feel this still isn't enough protection: If your application has > an online component to it (for example, a multiplayer game), it's entirely > possible to upload the license response to your server and perform a > server-side validation there. (Remember: License responses are > cryptographically signed. Even if the application has been cracked, the > actual license response data cannot be tampered with.) You could then refuse > to serve the online component of your application. Since this is all > happening on the server-side (read: trusted code), this would be absolutely > secure against attack. > > And yes, we'll be publishing some articles soon on how to use ProGuard and > other techniques for securing your code against attack -- we do mention > ProGuard in our documentation, but we should probably be more explicit about > how to use it. > > -- > Trevor Johns > Google Developer Programs, Androidhttp://developer.android.com > > > > On Mon, Aug 23, 2010 at 4:31 PM, Jonas Larsson <[email protected]> wrote: > > An official response would great. > > > As I (and many others) see it the main reason for Android app > > piracy is paid app unavailability in most countries. When most > > users have the option of being honest and pay, most would. > > Until Google enables the full Market in all countries the > > incitement to crack and distribute apps remains. > > > When LVL was announced I played with it a bit to see how > > easy it was to crack. The fact is; it's much easier than the > > article on AndroidPolice shows. No need to analyze switch > > statements etc. There is a much better place to modify the > > disassembled code that makes it trivial to implement a generic > > patcher using available open source tools and shell scripts. > > As to where in the (potentially obfuscated code) I refer to > > I leave that as an exercise for the crackers. Google surely knew > > all this even before LVL was announced... > > > The official response, or lack thereof, will be interesting. > > > On Aug 23, 11:50 pm, Brad <[email protected]> wrote: > > > Well, just as I was finishing adding LVL support to my apps, I come > > > across this article: > > > >http://www.androidpolice.com/2010/08/23/exclusive-report-googles-andr... > > > > Of course we all knew that this new copy protection could be broken > > > (as is the case for all DRM), but I guess I had hoped that it would > > > take a little more effort. Looks like this will turn out to be a > > > "one-click" crack. > > > > Will Google up the ante? Is it a lost cause on such an open platform? > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected]<android-developers%[email protected]> > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en > > -- > Trevor Johns
-- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
