This is one of those things that can be easily circumvented by a script. getPackageManager and checkSignature are easy to identify, and making the latter return SIGNATURE_MATCH should be really easy.
Don't know if there is one now, but last year there was a script floating around that did something similar - replacing PackageManager#getPackageInfo (GET_SIGNATURES). -- K 12 апреля 2012 г. 19:55 пользователь Justin Anderson <[email protected]>написал: > One thing that I do that does help a little with the protection is check > that the paid app that runs my LVL check is signed with the same signature > as my free app... Still not foolproof, but it is a nice little measure that > helps prevent the more simple-minded hackers from cracking the app: > > PackageManager mgr = context.getPackageManager(); int sigMatch = > mgr.checkSignatures(context.getPackageName(), AppConstants.APP_UNLOCK_PKG); > //The unlock key MUST be installed or the license service will fail... if > (sigMatch != PackageManager.SIGNATURE_MATCH) return false; > > > Thanks, > Justin Anderson > MagouyaWare Developer > http://sites.google.com/site/magouyaware > > > On Thu, Apr 12, 2012 at 9:32 AM, Iain King <[email protected]> wrote: > >> >> >> On Thursday, 12 April 2012 16:26:37 UTC+1, latimerius wrote: >> >>> I too consider not protecting the app at all a valid option. However, >>> ideally I would like to have something to deter the more simple-minded >>> cracking attacks. Anti-copying protection seems to follow the 80/20 >>> rule quite often - confusing and annoying the army of script kiddies >>> or attackers who are not very knowledgeable or motivated doesn't cost >>> you all that much. The rest you'll have to bow to anyway. >>> >>> And I too agree that user convenience weighs more than good >>> anti-copying measures. Which is why I'm considering, if I can't do >>> LVL under the free/paid app scheme properly, it might be better to >>> avoid it altogether. Because pretty much anytime you use a protection >>> scheme, you run a risk of annoying legitimate users - and running that >>> risk doesn't seem to be worth it for a protection that doesn't even >>> protect very much. >>> >>> Not being able to obfuscate and hide LVL code in other code is quite a >>> big deal here - under the particular circumstances (all of your code >>> and assets live in untrusted environment) obfuscation is your >>> front-line security measure. Without it, your security core (the LVL >>> check itself) becomes exposed and vulnerable. >>> >>> I'll have to think about this some more and weigh carefully pros and >>> cons. >>> >>> >>> >> You've pretty much summed up what I was thinking. >> >> Iain >> >> -- >> 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
