Scenario:
Someone buys/downloads my apps from the play store.
They then do an adb pull /data/app/com.example.myapp.apk on my apps
They then sideload it on another device/distribute it online
Can I:
Via my app identify it was not legitimately purchased/downloaded?
Download my apps from said website and verify the same person downloaded them?
Find any identifying information/user data inside the apk?
I can only answer number 3:
Reading: https://android.stackexchange.com/a/28138
It seems no user data will be in the APK, I don't know about the play store data though.
Can I:
Via my app identify it was not legitimately purchased/downloaded?
It depends how your app can be purchased. But even then that will be pretty hard to do that, especially this will be prone to spoofing on rooted devices, so if your app is a standalone product and does not require any account on your servers to be used, then it may be really painful and at some point not worth the efforts maybe.
Download my apps from said website and verify the same person downloaded them?
No.
Find any identifying information/user data inside the apk?
No. There's none.
Via my app identify it was not legitimately purchased/downloaded?
Aside from the security key which guarantees that the contents of the apk are not tampered with, the apk on it's own does not identify where it came from. If you need extra security measures against pirating, you have to look for other solutions, e.g. account checking, web-based identification, etc
Download my apps from said website and verify the same person downloaded them?
If you mean that whether Google Play will identify you as the person that originally purchased the app, the answer is no. If the app is paid Google Play will realize that you have not paid for it. If the app is not paid then Google Play will simply add that to the library of apps that you have and/or installed
Find any identifying information/user data inside the apk?
There is no user data in the apk since the apk is the same file for any device that installs it. However, some apps might store data locally which means that through adb pull an untrusted party might be able to pull your user data from your phone. Most apps don't store anything locally because of this.
Related
I have this app developed and issued to users via USB. But I want to prevent them from extract the APK and install it on other phones.
Currently, I have a APK signing signature check when the app launches and prevent it from running if it doesn't match mine. But it doesn't to stop those APK extractor apps, this one for example.
https://play.google.com/store/apps/details?id=com.ext.ui&hl=en
I checked the extracted APK and it has the same signature as my original! Is there any other ways to stop it?
My app is a standalone app so it doesn't have a server to talk to...Thanks!
Disclaimer! There's no way you can protect your app 100% but you can try the following ways:
Google Play Licensing and the License Verification Library (LVL)
This service allows your app query a Google Play Licensing server to determine if currently running device is recorded as a purchaser.
More info
OBFUSCATION
Eliminate all chances of reverse engineering which is a way of generating an apk from your app.
More info
COPY PROTECTION
Although superseded by licensing on some platforms (most notably Android), copy protection is a simple way of fending off more perfunctory attempts at piracy.
Digital rights management (DRM) can be built into the app itself, be part of the app store to which it is uploaded (such as Amazon DRM), or purchased as part of a third-party paid DRM service.
In general you can not prevent your app from being extracted from a device. Furthermore any of your user could simple upload the retrieved APK file somewhere on the net.
Therefore you can only protect your app from being used by "the wrong people". I see two possible solutions for doing so:
Dongle the version to a specific device
You know the principle by many shareware software: After installing the app requires to enter a license code that activates it. The license code is generated by you after receiving some sort of device fingerprint and the app checks if the license is valid for this specific device.
Embed a water-mark that allows you to identify who has leaked the APK
This would require to create unique APK files for each of your legitimate user.
There's a developer interested in purchasing one of my apps (the only one that actually have users), meaning I would need to send him the original source code, the keystore and request Google for a transfer following this link: https://support.google.com/googleplay/android-developer/answer/6230247?hl=en
The issue is: all my apps use the same certificate from the same keystore.
So my question is: Would it be possible for the new developer to hijack any of my other apps?
I believe that the answer is "No. A device would allow another apk signed with the same certificate and with the same package name to update on the device, but Google Play wouldn't allow the developer to upload another app with the same package name as any of my other apps".
But I'm not sure on that and I would like further tech details on it.
As I said, the other apps I have are not important and I could just as well unpublish them. But I rather not, and even if I do, the question is still valid.
ps.: yeah, now I've learned that I should have 1-certificate per app.
The package name of your application is unique in the Play Store. It is how devices (and the Play Store) identify your application, and thus must be unique and cannot be changed. Android will not allow your users to install two applications with the same package name.
However, giving your keystore to another developer is still risky. The Play Store employs two gates when updating an application:
First, you must have access to the account that owns the application.
Second, you must have an APK signed with the correct keystore
By giving someone access to your keystore, you remove one of the two security checks. If the new owner of the application where to gain access to your developer account, they could re-publish the other applications as well. There's also the risk of this new owner selling the keystore and application to someone else in the future who might do the same thing.
Theoretically if your account is secure, then your other applications are also safe from hijacking.
Whether this risk is acceptable is up to you.
They could sign an APK and encourage your existing users to sideload it. When sideloading, the app isn't going to be able to know if it came from you or them. But the Play store itself won't let them upload an app that you haven't transferred to them.
Normally, part of the agreement when the buyer buys and app that using a key used by other apps would include a small snippet that the buyer must protect the key. This agreement would be bilateral anyways, since you could in theory hijack their users by sideloading a signed APK.
Would it be possible for the new developer to hijack any of my other
apps?
No way in the world its possible for him to do anything to any other of your apps unless you give him your keystore.
Your keystore is the key to all your applications and you should never share it with anyone. Having an app signed with your keystore in my developer account would never ever let me do anything to your own apps.
Anybody can have apps publish in plays store with different keystores.
I have a simple question as to how can we prevent the user to share an apk file from his/her device to others.Like if i put a paid application in the market and a user downloads it . If its downloaded how can i be sure that he doesn't transfer the application to other or puts it in some third party market . I need to find some security measure to do it for my application.Is there any permissions that needs to be added or any third party security .
All the answers are appreciated.
As I came across this link. How can i prevent LVL
The Google Licensing Manager is what you should use which can be found at http://developer.android.com/google/play/licensing/index.html.
This uses some code that you can put at the start of your application that uses the licensing API to check that your app is licensed. This is done by checking that the account that the user is using on their device has paid for the app via Google Wallet and that a refund has not provided. If it is found to have been paid, then you can let the app run, otherwise you can display an error to the user informing them that it is not licensed. Most apps that do this provide a button that will launch the play store at your app to let them download the legit version.
This doesn't directly stop users copying the APK or publishing it on other markets but it ensures that app cannot be used unless has been purchased by the current user on the Google account they are using.
Although there may be ways to circumvent this check but this is probably the best and most reliable way.
Hope this helps.
You can do something like verify user on your server when app launched, but you cannot force user not to share .apk by technical means. Apk can be easily copied from non-rooted device, and there's absolutely impossible to prohibit user to copy .apk from rooted device even if Google adds some copy protection in future.
I'm thinking about buying an existing android app from another developer. He has signed other apps not included in the sale with the same signing key as those included in the sale. What if any are the implications of sharing or duplicating the key and us both having a copy so we can update our owned apps? My main concern is can he update my newly purchased app without my permission or access to my developer account or vice versa?
There's a great article/video on how to do an acquisition at Phandroid. It does briefly address the idea of the signing key, but more from the seller's perspective. Regardless, I don't think it will be the worst thing in the world as while he could make a new signed APK of "your" app, he should not be able to publish it to Google Play after it's been transferred to your Google Account. He could try to distribute it through other means, but I wouldn't sweat it too much, especially if you're getting the conditions of the sale in a good contract.
Besides releasing a 'rogue' version of the app, another thing to note is that if the app is using signature permissions or sharedUserId, they could make another app that could potentially access and change data in the original app (via content providers, remote services, etc.) Even if the app is using neither of those, you might decide to add something in the future.
I'm totally new to the Android Play store. I'm working on an app that is almost finished and ready to publish.
But I notice that you can copy the apk file (after purchase) to another location (sd card for example) and install it on another device. That is something I want to avoid.
My questions are:
Does the Google Play store sign the apk file with some unique id before downloading? If is true, can I read/get this code from the
apk?
Is it possible to know the email-address of the user that purchase the app or can I access some other details of the user?
Is it possible to get an unique detail of the device?
Is there another solution available to protect the copy of the apk?
I want to create a registration method that binds the device to the app, so when the user tried to copy the app, it is not possible to use it. Is this all possible?
If you have any questions, let me know.
PS: I used Adobe Flash Builder to build the app.
Your best bet is a combination of LVL (Android License Verification Library) and tracking device installations.
LVL
http://developer.android.com/guide/market/licensing/index.html
Tracking Device installations
http://android-developers.blogspot.in/2011/03/identifying-app-installations.html
To verify that the user has paid there is a Google Play Licensing service, you can use it. There are copy protection mechanisms on Google Play if you choose to use them, but they are deprecated now since you are supposed to use the service I just mentioned. You can gather some unique device details, there are APIs to do that, but this is not really needed.