I have a paid android application which uses the google LVL code to authenticate users.
A company would like to pay me so that their application can include a free version of my application. However, I'm not sure how to accomplish this in a way that won't result in an easily pirated version of my app. Below are some implementation options I am considering, but none of them seem like particularly good ideas. Any suggestions?
I deliver them an apk which does not use the LVL code. They could then package my apk with their app, and install it using the ACTION_VIEW intent. This seems like a bad idea because I think it wouldn't be particularly hard for some rouge user to extract my unsecured apk and distribute it.
Maybe I could build a version that checks to see if their app is installed, and if it is it queries their app for some sort of unlock code. And app will only run if this unlock code succeeds. My main concern about this is that I have no idea if "querying another app" for an unlock code is accomplishable.
This is definitely accomplishable. As already said one way to query the app is by using a content provider. If you are concerned about security you can introduce additional permission that both apps must hold to access the provider. Although since it doubtfull that both apps have the same signature it won't be as effective.
Another way would be if they had a service that you could bind to and request a code or any other authentication. In this case their service can as well validate your apps validity by querying your apps userId and checking a signature via PackageManager.
Sad news is it's alomost impossible to prevent pirating your app anyway. Even with LVL... Since all this can be decompiled and eventually broken. But at least you can make attackers life harder.
For what you are looking to do I would create a jar out of your project and mark it as a library project. That way you can give your application out to your client but they wont be able to see the actual code you have written. Using this method they will be able to call any method directly which would be easier than having to interact with an apk.
Related
My company is letting an external provider manage its internal Android "app store" for it. For this, the provider wants a p12 and the APK.
My question is: would there still be an "emergency" way for us to disable an app?
I know that on iOS there is always the possibility of disabling a provisioning profile; is there something similar with this Android setup?
Thanks
If I understand correctly your question, you want to be able to disable your application remotely ?
If so, there is no built-in way to do it, with or without using the signing certificate. Even removing it from the Play Store would not prevent existing users to use it, since you can't uninstall an app for users.
The only solution I see would be to introduce a custom check when the app is launched, which would call a webservice and depending of the "status" returned, start a blocking behavior in your app. However, this requires network, and it's not a very good usability best practice, since your users could see their service interrupted without warning.
Is there any way, to check on server if this is my application sending data or it's someone's who decompiled my app? Note that both my and fake apps may be downloaded by user from Google Play. I have only one idea - in Google Play you cant post two applications with the same package names, so maybe I can send package name to server or something like this.
It can't be done without some help from OS - because an app would not know whether it was modified (the modification check itself can be hacked).
The ways I'd go would be the following:
Excercise the options Google Play Store gives you - license check and app encryption
Add some auth data to the application itself and verify it on the server (some encryption key). The data should change with each version
Accept only 2-5 last versions (for people who haven't yet updated)
This way, any pirated version will be valid for only a week or so... And for someone wanting to use the app constantly it will be easier to buy it, than re-download it every 1-2 weeks.
It won't protect you completely, but will make thievery time-consuming and hardly worth it given the option to buy the app. Enough to convince the users who would have bought the app to buy it. Those who pirate things out of principle can not be converted in any case...
there are some points which can make your code and application more safer.
use proguard(see on android devlopment site) it offuscates(other words makes it messy at compile time) your code.
secondly you could use encryption and decryption send some secret key encrypted
Here's my scenario:
Currently, my app does NOT require the INTERNET permission and I would love to keep it that way. My app is a financial app where a lot of users don't want to take a chance on an app that can send their data out.
Now, I would like to have some kind of add-on that enables some on-line features, such as DropBox sync and some others which will require the INTERNET permission.
Can an app's add-on request additional permissions, and if not, can anybody suggest a reasonable way to accomplish this?
Thank you!
The suggested answer is to use a sharedUserId in the AndroidManifest and then create a new app with the added permission and this same user ID. This works great for apps where the developer had foreseen this need, but for other apps, adding or changing the sharedUserId causes it to misbehave.
Here's the corresponding Google bug, please star it if you feel this should be addressed:
http://code.google.com/p/android/issues/detail?id=14074
I had a different problem I was trying to solve and decided on add-ons also. The solution I used was to implement the Shared User Id paradigm. My add-on has the same signature, no launcher intent (which means there will be no separate icon on the users device) and a signature based security on the activity calls. This will allow you to implement the above functionality.
The issue you may have is I doubt you can get another application installed using in app purchases. You may need to sell the add-on as a separate app.
Hope this helps...
I seem to have reached dead-end as to how may i create a proper model which plays well under a scenario that i have in mind.
The scenario is as follows; User purchases an application from Google play. At run-time i request user credentials (Google account associated with current device) which i then transfer to a web-service. At that point the back-end service tries to Auth user and identify if they have actually purchased the application in question and only then return any data relative to the request. (keep in mind that any request in general, as we are talking about a content based application, to the web-service at any point of the run-time life-cycle must always pass through the above pipe).
Now the reason for the above scenario being so specific is for the following reason;
-I would like everything to be managed by the end service rather than having any Auth process running natively as it may easily get bypassed. What i mean is that as long as anyone can decompile the application on their device, inspect the code, recompile it to their needs, have full access to any file if the device is rooted or even be allowed to clear any data related to the application by simply pressing the "clear data" option from android's application settings..... i do not see any other viable scenario other than the one i described above.
Now having said all of the above my problem is that it seems that Google does not like this specific scenario with both Google play developer api and Google+ api.
So i would really appreciate your comments, thoughts and any related materials you may have to offer in regards to the scenario i mentioned and ways to tackle down this problem.
I don't know of any such API that you can use. Why not try LVL, which would make sure that it's actually downloaded from the Android market? And if it's a paid app, the user must have definitely paid for it.
As far as decompiling is concerned, try Proguard. It's not 100% perfect solution, but it's pretty hard to break it.
Now, coming to the content. If you don't want anyone else to steal your content, then encrypt and save it. You can have a pretty good encryption mechanism that works with your web services, which would ensure that it's very very difficult to break.
What's wrong with using LVL and ProGuard? These tools were designed specifically to address your concerns with license verification and reverse engineering, respectively.
And, really don't worry too much about the one in a thousand people who might try to get your paid app for free. If your app is any good, then you'll be making plenty of sales anyway.
If I've read your proposal correctly, that sounds like a gross violation of your users' privacy and would definitely be a violation of Google's ToS. Why would your users give you their private credentials? They aren't supposed to be given to anyone, so why should they trust you or your systems with them? You would also be liable if you got hacked and credentials were stolen.
As Google stores your purchases of Android apps, I was wondering if they are somehow offering a webservice that can be used to check if a certain app has been purchased. To me this seems the most secure way of distinguishing free and paid users from within my app.
It would not only defeat piracy, but would also allow for managing a database of legally registered users, by a one-time check through this service.
What are your solutions to this matter?
Google provides a library for you. See here.
Note that this has been compromised in unprotected apps, so you should use something like ProGuard. The link above contains more information.
Finally, keep in mind that the Android Market is not the only app market for Android out there. Amazon has their own DRM.
At this particular moment there is one way to check.
The Android Market authenticates purchases through Google Checkout, but Google has not implemented the Checkout API to synchronize Market purchases. So calls like that check the status of an order do not work. Maybe Google doesn't want dev's to get a hold of customer emails? Either way, I do not know why it does not exist, it seems to me that if Google simply made this service available we could implement a far more superior security system that would better utilize the methods of obfuscation. As it is at the moment, a hacker can simply look for a specific class like the ILicenceService and hook it.
The only way at the current moment is to download a list of current purchases. You can do this using an authenticated http call. The drawbacks to doing this are pretty large though. First, the list it provides only extends back 31 days (so you've got to make sure you keep everything). Second, you would have to call and parse at least every ten minutes. Actually faster than that, most users want to play their games when they buy them. Third, if your service, or server goes down, that is precious information that is being requested almost instantly by your users.
I don't know how many dev's are currently utilizing this process, I considered it, but am just going to keep complaining to Google for a better method.
You could piggy back off of the LVL. I have just implemented a similar system.
Perform Check via LVL.
On success make a post to your own web server and store whatever details you need, i.e. DeviceID etc.
You could also perform checks to your own server even when the LVL check fails and allow things like trial periods etc.