On Jul 31, 11:21 pm, keyeslabs <keyes...@gmail.com> wrote: > Speaking as someone who has traveled this road before with my own > implementation of basically the same approach, obfuscation will be > critical. With AAL, it took about three days for someone to crack the > app.
There are various ways to make this harder. I suggest reading Nate Lawsons blog entries on the topic for an introduction: http://rdist.root.org/2007/03/26/building-a-mesh-versus-a-chain/ http://rdist.root.org/2007/04/09/mesh-design-pattern-hash-and-decrypt/ http://rdist.root.org/2007/04/24/anti-debugging-techniques-of-the-past/ http://rdist.root.org/2007/04/19/anti-debugger-techniques-are-overrated/ http://rdist.root.org/2007/08/21/mesh-design-pattern-error-correction/ http://rdist.root.org/2007/10/05/c64-screen-memory-and-anti-debugging/ http://rdist.root.org/2008/04/11/designing-and-attacking-drm-talk-slides/ Android is a slightly different environment than traditional operating systems in which obfuscation and anti-debugging techniques are highly evolved, but then again, the monetary value of the apps are lower, so you don't necessarily have to be as good as some of the really professional copy protection schemes. On the other hand, naive straightforward usage of the LVL won't prove much of a barrier to attackers who want to pirate your app either. The suggestion to use ProGuard is a good first step, but ProGuard is ultimately just an optimizing compiler, not a professional obfuscator. If you wish to go beyond ProGuard, you might want to check out commercial obfuscators like Allatori. I've used it - it was easy to set up and produced pretty reasonable output. However, pure Java level obfuscators will never prove a big challenge to a skilled adversary - Java bytecode is just too limited to make obfuscation easy. A common technique in the PC world is to set up an interpreted environment that runs encrypted machine code, and then do part of your protection logic in this environment. It works well for a variety of reasons. If time, energy etc wasn't an issue and I decided to build a better general purpose LVL/copy protect framework, I'd probably reimplement the LVL checking code in C++, compile it to MIPS and then ship a modified MIPS interpreter with the app that runs the protection logic there. Other than confusing attackers by breaking decompilers/ disassemblers, the interpreter can use in-loop decryption so only the currently executing opcode is in the clear, in memory. Ideally the key would be a function of the licensing server responses, ie, not available in the source code, but rather derived from the expected environment. There are lots more techniques that can be used with such a design to make cracking the app harder. Nates blog entries discuss some, like turbo codes. Sufficiently strong obfuscation on the apps will push attackers towards scamming the licensing servers rather than cracking each app individually, eg by making them think you're authenticating from the original device. However that's Googles problem to solve, not yours. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
