I agree and I don't see how people are missing this valuable point you make Mark.
Currently we are at: crackers must modify the program code to allow piracy >From here there are two ways to make piracy more difficult: A) Make secure, non-rooted phones reject apps so that even a cracked app won't run on a stock phone B) Make crackers actually have to write code instead of just flip a dalvik op somewhere The problem with A is that for every app name SuperCoolWidget, there could exist an app called SuperAwesomeWidget that has the same code minus the call to LVL, so Google would have to disallow all non-market apps to really make this work. Also, say for example they *did* want to pursue this route. Obviously disabling side-loading isn't on the table. But if say you wanted to check an applications full name com.appdev.android.supercoolwidget etc to make sure that it isn't on the market and doesn't have a checkmark that says "prevent sideloading". Then at the very least now phones need a valid internet connection to side load an app. So it's not going to be just a war against pirates it's also to some extend degrading honest customers' experiences. I think the reliance on binder -> Market probably is going to make automated cracks a little easier for pirates since I feel like these kinds of calls will be easy to automatically find in apps. So the final security measure B) is to simply make the hackers have to write code. Granted I'm no security expert, but it seems to me that the only thing that can be done is on the google LVL server. You can upload a simple java class with a function that takes in: Some basic information about the device the app is supposedly installed on, possibly something time based like an integer that is based on the date that the security policy of the app would determine as the expiration date of the last LVL authentication. And returns an array of bytes. The function wouldn't have access to any java threading etc, and would be limited to a short runtime or something. Then developers would have to make a call to LVL, then do something like getSettings().setImportantSetting(lvlResponseData[5] + lvlResponseData[1] - phone.DeviceSpecificInformation + lvlAuthExpirationDateInt) Where the online service feeds it data that will balance out with the code in the apk to actually result in the value the setting is supposed to have. really it becomes like a complex captcha for crackers. They can still crack an app. But more importantly is the actual obfuscation, like say you need a 5 in your code, you could use an LVL web service which knows the specifics of your app to generate a 5 as well as generate the server side function that outputs the data necessary. So that hackers would have to figure out each time you update your app how to crack it manually. That is what will actually stop the value of piracy. Updates. If your app receives constant updates but people pirating your app have to stick with an old one because the hackers can't be bothered to keep cracking your app over and over again that is the only way. Of course I don't really see it being worth it, but I don't see any other way to make the system more secure without moving a piece of your code into the cloud. -E On Aug 25, 10:55 am, Mark Carter <mjc1...@googlemail.com> wrote: > How about allowing the dev to specify response int values in the Dev > Console? > > The recent "crack" script would (probably) not be able to work out which > code means what. Therefore, a pirate would have to crack each app > individually. > > That's right isn't it? The automation only works because LICENSED is always > the same int value... > > On 25 August 2010 19:31, strazzere <str...@gmail.com> wrote: > > > > > > > > > I'm not sure how this would make code modification impossible? > > > You patch the application, make it always return a "yes, it was ok" to > > the licensing service inside the apk. Application then requests > > authentication, it fails, failure comes to application which still > > continues to say "yes, it was ok". > > > So yes, your going to have the market return a fail always, but if > > you've patched the application to *not* care, how is that actually > > helping? > > > -Tim > > > On Aug 25, 10:13 am, Kostya Vasilyev <kmans...@gmail.com> wrote: > > > 25.08.2010 21:04, Dianne Hackborn пишет:> If there are other > > suggestions that will actually make things harder > > > > without doing that, I would certainly like to hear them. > > > > Um, make the Market App side of LVL check that the application making > > > LVL calls is signed with the same key as the .apk uploaded to Developer > > > Home? > > > > Seems this would make attacks based on code modifications pretty much > > > impossible, since a modified .apk is signed with a different key from > > > the developer's. > > > > -- > > > Kostya Vasilev -- WiFi Manager + pretty widget -- > >http://kmansoft.wordpress.com > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to android-developers@googlegroups.com > > To unsubscribe from this group, send email to > > android-developers+unsubscr...@googlegroups.com<android-developers%2Bunsubs > > cr...@googlegroups.com> > > 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
