You could obfuscate these strings you're using in the reflection calls. This makes it a bit harder to find them literally. However someone still could look for occurrences of uses of reflection and figure out these things.
A great source of information about protecting your app is this Google IO session talk<http://www.google.com/events/io/2011/sessions/evading-pirates-and-stopping-vampires-using-license-verification-library-in-app-billing-and-app-engine.html>. I implemented almost all of these suggestions in one of my apps and just got after 5 months of being out on the market a crash report that showed me that somebody tried to crack it. The crash occurred within one of my "hidden" anti-piracy handling code blocks and the cracker apparently changed some bytes of one of my obfuscated strings and that finally caused the crash. So the bad news is: they will try to crack it. The good news is: they don't necessarily do a good job at it. And you can actively make it harder and basically postpone the date when your app is properly cracked. I think there are the following key elements that make it harder for a cracker to crack your app: - Code obfuscation of course - Using several different self-integrity checks: - package signature - package name (avoid re-packaging) - check for set debug flag and randomly crash in a background thread with random delay while your app is being debugged - check for integrity of files in your APK (CRC) - Redundancy of your anti-piracy code. Don't perform these self-checks at just one location of your app. Spread it all over the place in background threads - Regular updates of your app And also another great advice from that Google session talk: use the NDK. Compiled native code is harder to reverse-engineer and you have more possibilities for obfuscating your code. Java is pretty straightforward to decompile up to the point were you almost get the original code back (minus comments). This looks a bit different for native code. Create a native library that does all these self-checks in addition to your Java self-checks. But also make that library indispensable for your app. You need to migrate some vital business logic of your app into that library so a cracker cannot just remove it and all calls from your Java code to it. However, it is also important to understand what kind of battle you are fighting by protecting your app to that extent. I read some statistics about game apps, that half of their total sales occur within the first six months or so. So you could say it's about buying some time when it comes to piracy. But I think that's debatable unless you have a triple-A game on your hands everybody wants to play, most people who pirate stuff don't care about getting the original. They can wait. The biggest problem in my opinion are people who try to steal your hard work and sell it as their own. The only way to make your app more or less bullet-proof is by letting the bulk of its business logic run on your own server. The server checks the app for a valid purchase license and unless somebody hacks into your server or your server code has exploits, there is little purpose in trying to crack the app. On Friday, March 1, 2013 9:22:39 AM UTC-6, dashman wrote: > > So I'm trying to obfuscate my code > > I'm using reflection to get the package name. > > i also plan to use proguard. > > i understand variables xxx and yyy will be abfuscated by proguard. > > > android.content.pm.PackageManager xxx= > (android.content.pm.PackageManager)yyy.invoke( context ); > > but if the code is decompiled, will the decompiler be able to assign xxx to > a PackageManager variable. > > also > > packageInfo.signatures; > > i understand packageInfo will be modified by proguard - what about > signatures property. > > if nothing is done about that - the user could just search for that > keyword. > > Help appreciated - I think this is an important issue for Android > developers. > > > > -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
