Question

I am currently developing an application which interacts with Google Drive. When you register the app with Drive it asks for the SHA1 of the key used to sign it. In my previous applications I haven't implemented the licensing library as it seemed like more work then it was worth as it can and will always be patched, my theory is if people don't want to pay they won't pay and I could be using my time more constructively elsewhere.

However the fact Drive asks for the SHA1 of the key makes me wonder if it validates against this when a request is made to ensure it is coming from the app signed with the right key?

And if so, do patching apps like lucky patcher resign the app, which would essentially invalidate any requests made by the app making it unusable with Drive?

Thanks.

Was it helpful?

Solution

If anyones interested I found the answer in the end from the author of Lucky Patcher. He said LP doesn't resign the APK. It patches the odex files or it patches the app within the Dalvik cache therefore no signatures are changed and the APK remains untouched.

He also offered some advice to prevent lucky patcher working in this way which is to put the LVL code in a jar file somewhere else such as in the assets folder or the resources folder and call the code from there. This just means that to crack the LVL code the cracker will have to patch the jar and then resign the code.

So for those of us using Google API in your code which verifies the signature of the app we have what seems like a fairly solid method of copy protection. Until they find a way around this of course. Which no doubt they will.

OTHER TIPS

I don't know about patching apps like Lucky Patcher but the reason for the APIs Console to require the SHA1 of the key is exactly what you said: being able to ensure API requests are coming from a specific app.

This is a new requirement introduced with the Google Play Services: https://developers.google.com/android/google-play-services/authentication

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top