I think you took my answer to be dismissive of yours, or to try to discourage people trying to learn about piracy. I find it kind of strange you took it that way, since I was trying to say you were right :-)
To clarify, the whole point of my post is that piracy is a cost / benefit trade off. It's disingenuous to tell people that their app will be safe just by using LVL, etc... There are real static analysis problems that you didn't mention. While I agree with your post, I wish you'd stop to think that I was indeed supporting you before you try to imply I'm derailing people from learning about piracy: that's explicitly not my point. Kris On Fri, Mar 1, 2013 at 1:19 PM, Nobu Games <[email protected]> wrote: > Here we go again. Senior Android developers being irritated about people > discussing anti-piracy. As if it were totally insane and offensive to even > try. My suggestions are the possibilities given the circumstances. I do know > that they do not make your app bullet-proof and I also mentioned that > multiple times in previous posts. > > I also never said that I think NDK self-checks cannot be circumvented. Read > again what I was talking about. It is only about buying some time and you > certainly put off a huge bulk of script kiddies from even trying to crack > your app or using 1-click tools if you put some thought and effort into > obfuscation and self-integrity checks. > > We both are on the same page here: it is made harder. That's the whole > point. And that's not good enough? I also said that the one and only > solution to that problem is using your own server. > > About your code analysis argument: that's why you have to change the code > flow of the license check to make it harder to find. That's also what Google > has to say about the LVL. > > Seriously, there are people out there who are looking for answers to > specific problems. These solutions are certainly not perfect and may lull > you into a false sense of security. But they are still better than doing > nothing about protecting your app. > > > > On Friday, March 1, 2013 11:42:24 AM UTC-6, Kristopher Micinski wrote: >> >> Really the *only* way to really protect against anti piracy is to >> perform mission critical operations on a server, at least some of the >> time, and enforce a good strategy to make sure that can't be cracked. >> >> Doing checks in native code can be circumvented, what makes you think >> they can't? >> >> Albeit, it's harder to crack your app. >> >> In reality, there is not really anything you can do to "crack proof" >> your app unless you have a pretty significant security background. >> Even then, your app can probably be cracked by a skilled adversary. >> But of course, anti piracy is a cost / benefit analysis. >> >> By the way, putting in that number of days requirement doesn't >> fundamentally change things, the cracker can just remove that check. >> To have a server help, you need to perform critical operations *on* >> the server. >> >> kris >> >> On Fri, Mar 1, 2013 at 11:41 AM, dashman <[email protected]> wrote: >> > Thank you for some excellent suggestions. >> > >> > I've watched that google i/o a few times. >> > >> > i problem is actually doing it. e.g. just looking at the NDK and wish >> > they >> > had a sample to read the package info etc. >> > >> > offloading app logic to server is a great idea - but my app is designed >> > to >> > work while off-line - so that will not help me. >> > >> > i think my thinking is: >> > - doing some checks in native code >> > - also including some critical app functions in navtive code (thanks >> > for >> > that suggestion) >> > - check license with my server (if online) - and make it a >> > requirement >> > that it >> > needs to pass the test within a set # of days (e.g. 30). >> > >> > the problem now is that - all the user has to do is uninstall the app >> > and >> > re-install it >> > and then they can use the app for another fixed amount of days. >> > >> > >> > >> >> >> > >> > -- >> > -- >> > 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. >> > >> > > > -- > -- > 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. > > -- -- 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.
