OK, I see your point, that could slow them down, but it would slow me down for sure, maintaining a native and a Java project. Not the mention the bugs you can get from native code... But agreed, it's an option.
Hugo On Aug 24, 5:23 pm, a1 <[email protected]> wrote: > On 24 Sie, 16:15, Hugo Visser <[email protected]> wrote: > > > No, that won't do it, since the entry point is always Java / Dalvik > > byte code. Since you can decompile and patch that with relative ease, > > you can just make the native calls to the crc check library no-ops or > > whatever and you're done without patching any native lib. > > No, if the native call do something else((and viable) you'll have to > patch native. > Consider following scenario: > > JAVA: > void onCreate() { > ... > boolean isValid = nativeInit(); > > } > > NATIVE: > jboolean nativeInit() { > // initialize internal structures here, eg. alloc some object etc > > return performValidityCheck() > > } > > sure entry point is in bytecode but removing entire call will cause > crash. > > -- > Bart Janusz (Beepstreet) > > > > > > > Only obfuscation will help to some extend, making it harder to find > > what to patch, IMHO of course :) > > > Hugo > > > On Aug 24, 10:39 am, a1 <[email protected]> wrote: > > > > If you put antipiracy check (eg. CRC checking to detect package > > > modification) in native code along with some other vital routines, one > > > will have to patch native implementation, it's of course doable, but > > > will take more time. > > > > -- > > > Bart Janusz (Beepstreet) > > > > On 24 Sie, 08:34, Hugo Visser <[email protected]> wrote:> Even native > > > code doesn't help you, the call to the native method can > > > > also be decompiled and patched, without bothering with the native code > > > > at all. Like John says, it's an inherit problem of a language that > > > > runs on the vm: you can decompile the byte code. You can just make it > > > > harder to find the point to patch in the decompiled code. > > > > They will always be able to pirate your app, but it's not as easy as > > > > copying the apk and putting it up on a website anymore. So in that > > > > sense it helps. > > > > > Hugo > > > > > On Aug 24, 6:48 am, a1 <[email protected]> wrote: > > > > > > It's really simple, if you use stock implementation of LVL your app > > > > > will be cracked in no time, otherwise (if you make the code > > > > > complicated enough and then obfuscate) it will take at least week or > > > > > two to crack it. If you use native code and put most of the antypiracy > > > > > code there you will be good for long time. > > > > > > -- > > > > > Regards, > > > > > Bart Janusz (Beepstreet) > > > > > > On 23 Sie, 23:50, Brad <[email protected]> wrote: > > > > > > > Well, just as I was finishing adding LVL support to my apps, I come > > > > > > across this article: > > > > > > >http://www.androidpolice.com/2010/08/23/exclusive-report-googles-andr... > > > > > > > Of course we all knew that this new copy protection could be broken > > > > > > (as is the case for all DRM), but I guess I had hoped that it would > > > > > > take a little more effort. Looks like this will turn out to be a > > > > > > "one-click" crack. > > > > > > > Will Google up the ante? Is it a lost cause on such an open > > > > > > platform? -- 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
