Not if you use this correctly -- you keep the result you got back from the server, which is signed with the private key. If you don't have that (verifying the cert) then the app isn't licensed. That result contains time, device id, and other information that is needed to verify it.
Sorry I missed that your question was about licensing, because I saw the part about encrypting stuff which is nothing you need to do for licensing. As I said, the license result is signed and you can verify that it is a valid result. There is absolutely no need to encrypt it. On Tue, Feb 15, 2011 at 9:46 AM, rajorshi <[email protected]> wrote: > But, if someone can edit my preferences file to modify the stored > validity time stamp, grace period and max. retry count to very > reasonably values, he can prevent my app from ever contacting the > server after the first attempts or make it retry all the time. This > effectively removes LVL checks. Also, if bypassing the licensing is > indeed as easy on rooted phones as I mentioned, doesn't that > practically negate the advantage of having a licensing scheme which > works independent of device configuration. After all, that is what > attracted me to the licensing service in the first place - the thought > that I would be able to get additional revenue if my apps could be > legitimately installed on rooted phones. > > ~rajorshi > > On Feb 15, 10:21 pm, Dianne Hackborn <[email protected]> wrote: > > Oh and the documentation on LVL obfuscation is to prevent people from > easily > > *modifying* the app to *remove* its LVL checks. This is in many ways a > very > > different issue than trying to protect data that is being stored on the > > device. The LVL design has the server holding the private key that it > uses > > to sign its results, and the app has a public key it uses to verify > results > > from the server. That way you can't spoof the result without knowing the > > private key (which is only on the server), so LVL will work without > needing > > to trust the local device or Market app. > > > > On Tue, Feb 15, 2011 at 9:18 AM, Dianne Hackborn <[email protected] > >wrote: > > > > > > > > > If someone has root, there is little you can do to really protect > yourself > > > from them. > > > > > On Tue, Feb 15, 2011 at 9:10 AM, rajorshi <[email protected] > >wrote: > > > > >> I have no experience in cryptography, hence this basic question about > > >> the AESObfuscator in Android LVL. The AESObfuscator uses app specific > > >> info (say package id), device specific info (say > > >> android.provider.Settings.Secure.ANDROID_ID) and a salt to generate a > > >> key to encrypt the SharedPreference file where the ServerManagedPolicy > > >> stores my license information. Now, the app id and the device id are > > >> well known. It will be a simple matter to decompile my app to obtain > > >> the salt even if I obfuscate my code. Won't somebody be able to > > >> generate the key using the three values and edit the SharedPreferences > > >> file easily on a rooted phone? On a non-rooted phone I guess I can > > >> just make the file private and nobody else will be able to access it, > > >> but, what do I do on rooted phones? I can't help feeling I am missing > > >> something here. Why else would the documentation on LVL put so much > > >> emphasis on refactoring and obfuscating LVL to prevent others from > > >> patching the library when a much simpler way would be to just get the > > >> salt and edit the preferences file? Can someone enlighten me on > > >> this? > > > > >> ~rajorshi > > > > >> -- > > >> 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 > > > > > -- > > > Dianne Hackborn > > > Android framework engineer > > > [email protected] > > > > > Note: please don't send private questions to me, as I don't have time > to > > > provide private support, and so won't reply to such e-mails. All such > > > questions should be posted on public forums, where I and others can see > and > > > answer them. > > > > -- > > Dianne Hackborn > > Android framework engineer > > [email protected] > > > > Note: please don't send private questions to me, as I don't have time to > > provide private support, and so won't reply to such e-mails. All such > > questions should be posted on public forums, where I and others can see > and > > answer them. > > -- > 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 > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
