The best way at the moment to beat the crackers it to use native code to do things like checking the signature matches an expected hash. You have to do other fancy stuff like encrypting some of that to further hide the logic. But don't be under any illusion - native code is tougher than java and requires a lot more time to get it right. You also need to plumb it into lots of places in your app and make it something essential otherwise it's just as easy for a hacker to stub it out quickly.
Unfortuntely there's a new app in town called LuckyPatcher. I haven't looked at it in any detail, but I think it patches the dalvik cache so the app still has the same signature according to the packagemanager, but different code is executed including a few crafty "return true" statements stuck in certain places in your app. But I think they still have to use similar logic to antilvl to patch your app in the first place. I'd suggest you make your lvl code a lot more tricker to subvert - antilvl uses scripts and easy to see logic. If you do something different, the scripts backfire and someone has to manually read all the smali wich takes a lot of time and is easy to miss some crafty code. So add dummy parameters in most of the methods in the lvl so the signatures don't match. Add extra logic to some of the important methods so you can easily spot if the whole method isn't executed. Change the spelling of some of the enums by adding an extra charcter here or there. It all makes things a lot harder. Ensure you use proguard! On Apr 12, 8:42 pm, Kristopher Micinski <[email protected]> wrote: > This blog looks more script kiddie-ish than you'd want... the posts > are mostly about using smali to do things with apps and inspect your > bytecode... In general the people you should be afraid of probably > won't have blogs :-P > > kris > > 2012/4/12 Kostya Vasilyev <[email protected]>: > > > > > > > > > This is the top result when Googling for "android application cracking": > > >http://androidcracking.blogspot.com/ > > > for educational purposes only, of course. > > > It should give you an idea of what kinds of attacks your application might > > be subjected to. > > > There might be even be a script or two to test your own protection scheme. > > > -- K > > > 12 ÁÐÒÅÌÑ 2012šÇ. 23:17 ÐÏÌØÚÏ×ÁÔÅÌØ Latimerius <[email protected]> > > ÎÁÐÉÓÁÌ: > > >> 2012/4/12 Kostya Vasilyev <[email protected]>: > >> > Class.forName is just as easy to identify > >> > asšgetPackageManager.getPackageInfo... > > >> > IIRC, the script I was referring to earlier could handle reflection... > > >> So I assume reflection could only be of significant help if you a) use > >> it a lot, not just to hide your security-related calls, and b) > >> obfuscate your strings properly. šPoint a) would be hard to achieve in > >> my case. > > >> -- > >> 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 > > > -- > > 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 -- 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
