I've just released an app, a paid app, 4 days later a user told me there's another web site in China hosts my app. I downloaded it from there, and it does run fine on my device!
There are posts here saying people can change the package name and republish an apk. But this is not my case, the cracked version still uses the same package name. I used Android Vending Licensing in the program, but the cracked version does not do licensing check at all. I used ProGuard to obfuscate it, but that doesn't discourage the hackers.
Question #1: I signed the apk file according to Google's instructions. But still, they modified the code and took out the licensing check part. Am I wrong that signing an apk file is designed to keep people from tampering with the file content?
Question #2: For Win32 .exe programs, I used to use a checksum to determine if the file has been altered. This is how it works: When a .exe is created, I used a tool to calculate the sum of byte contents of the file, then stuff it into somewhere in the file, for example, 4 bytes after a text pattern "MY SIGNATURE". Then at run time, the program opens the .exe file and calculates the byte sum, compares it with the integer after the signature.
Has anybody tried this approach on apk files? Care to share your experiences?
Ultimately the built in protection of apps in Android is very poor. Here are your best practices.
1) Yes Google's recommendation to use code obfuscation, signed coded, and their license verification server is designed to prevent software theft. Their implementation however is highly flawed. The only requirement that an APK has to run is that it be signed. It doesn't matter who signed it though. There are no checks that your signature is the one it's signed with. So to crack it you just remove the license check and re-sign with whatever cert you want. Then a user can load it on their phone with "allow non market apps" checked.
Don't use Google licensing as is. Modify the code heavily. Add some new parameters to use when generating the keys. Move the code around / re-architect it. Don't include the Google licensing library as a library project. Put it directly in your code. Make the code as spindly and kludgy as possible. Add functions that do nothing, but modify the values on the fly. Make other functions later that convert them back. Spread license verification throughout your entire code base.
If you don't do those steps then the code can be cracked automatically. By doing those steps at least the cracker needs to take the time to hand crack it. That would probably only take a few hours at most. But a few hours is much much more time than instantly cracking the standard Google licensing layer. There are cracker tools that will actually just auto-download newly released android packages and, if they use the standard android licensing, crack them and upload the cracked APKs to these types of web sites. By making your implementation not the vanilla implementation you make things much harder, with only a few hours effort on your end.
2) This is a common anti-crack technique. You can do this on Android if you want. But it can be cracked in about 5 minutes. If you Google there are tutorials on how to crack this specific technique. Basically you just look for the CRC call in the code and remove the check after the CRC comes back.
Android has no inherent security. You can root any phone and download the APK. You can easily hack an APK to enable debugging and simply step the code to see any keys you have stored in the code. So in the end I wouldn't spend too much time on this. It's impossible to secure an Android App. I would just do the common sense stuff in the list above and move on.
3) If you're really paranoid you can implement your own licensing on your own licensing server. This is the approach I took, but not as much for protecting the app for theft, as it was to give me a mechanism to sell apps directly from my website so users that don't have Google Play could still purchase my apps.
Passive/Aggressive Scuttling
I agree with #metalideath that obfuscating and cludging the licensing code is not foolproof.
Here is an easily hidden technique I call 'scuttling' that works for apps deployed to Google AND Amazon. Scuttling is front-end piracy detection by the app. What to do once detected is in the purvey of the app creator.
Aggressive Scuttling: Eg. Termination and/or alarms on pirated app. Network communication not necessarily required.
Passive Scuttling: No app modification. Eg. enable tracking.
Passive/Agressive Scuttling: subtle app modification. Eg. silently disable key features. Lead pirate into thinking they bungled, and into unpublishing the pirated app.
If your app was renamed and/or installed from any source other than Google or Amazon, scuttle() returns true.
// Dont just copy/paste this code - that is what automated crackers look for - cludge it!
// No network communication is required at runtime.
// myPackageName should decode at runtime to "com.yourpackagename"
// google should decode at runtime to "com.android.vending";
// amazon should decode at runtime to "com.amazon.venezia";
public boolean scuttle(Context context, String myPackageName, String google, String amazon)
{
//Scallywags renamed your app?
if (context.getPackageName().compareTo(myPackageName != 0)
return true; // BOOM!
//Rogues relocated your app?
String installer = context.getPackageManager().getInstallerPackageName(myPackageName);
if (installer == null)
return true; // BOOM!
if (installer.compareTo(google) != 0 && installer.compareTo(amazon) != 0)
return true; // BOOM!
return false;
}
RESULTS
The following screenshot was taken from google analytics showing a pirated tracked free app from playstore (com.android.vending) that was redeployed with aggressive scuttling (non-playstore installs detected and terminated). Non-playstore (not-set) tracking drops. Tracking was not required, but enabled for these measurements.
DISCUSSION
Note service signing plays a role in scuttling: The package manager enforces unique package names with unique signatures.
This presents the question of what to do when the app is scuttled (pirate detected by the app). Piracy is a form of viralization (uncontrolled distribution) of your app. It is already detectable by enabling the analytics tracking back-end. Scuttling allows the app creator to customize a front-end response with or without tracking.
Aggressive scuttling is obviously detectable by pirates (BOOM!). This encourages further cracking. Passive scuttling is far less obvious, but may involve tracking.
Piracy may not be preventable but it is predictable, detectable, and trackable.
Tracking can present insurmountable problems to pirates, but also presents it's own ethical issues.
Passive/aggressive scuttling requiring no network communication as outlined above is perhaps the best solution. It is easily hidden (unlike licensing) and can be tailored to be as unobvious as possible.
The best thing to do is not worry about it. The people pirating it in China are not your customers, and never will be. If there was no pirate version available they still wouldn't pay you for a copy, in all probability. Besides which if your app becomes popular it will be cloned anyway, just like iOS apps are. The security systems you have already implemented are all that you need as they prevent most users from pirating the app.
Trying to make your app piracy proof will just harm the code base and make it harder to maintain, as well as potentially introducing problems for your genuine paying customers. Instead focus on promoting your app and making it easy for customers to pay for and use. By being responsive to feature requests and bug reports you add value that people are willing to pay for, rather than seeking out some dodgy cracked copy from a Chinese web site that is probably a trojan anyway.
Finally, report the pirate copies to anti-virus vendors. Supply copies of the APK. They will add signatures to their databases so that it gets flagged up as potentially dangerous.
My understanding from reviewing the Google market terms is that you cannot sell your app directly from your own site as it violates the Google app market terms. I think that implementating custom protections in your code is the best way to go. Standard methods just are not effective since code can be easily dissassembled
Related
As a follow-up to this question, I am trying to figure out what stops Google from modifying our apps that it signs and distributes. Regardless of whether we distribute an APK or an App Bundle, the App Signing service strips away whatever signature that we have and Google signs the APKs that it distributes. In the case of the App Bundle, this will result in several APKs, akin to what bundletool generates.
But since an APK is just a ZIP archive with compiled code and resources, it seems as though Google could modify that as they see fit before signing, including adding or replacing code.
Google has stated:
we don’t modify and distribute your application code without your knowledge and approval
and:
As stated before, Play will not modify the functionality of your application without your knowledge and approval.
Notably, Google used "don't" and "will not"... as opposed to "can't" and "cannot". In fact, in the same post, we see:
For apps uploaded as app bundles, we will improve this security by introducing what is called a source stamp. This source metadata is inserted into the app’s manifest by bundletool.
So, we know of at least one modification, albeit to metadata.
Plus,
the Amazon AppStore for Android modifies APKs before re-signing them:
Regardless of whether you choose to apply Amazon DRM, Amazon wraps your app with code that enables the app to communicate with the Amazon Appstore client to collect analytics, evaluate and enforce program policies, and share aggregated information with you. Your app will always communicate with the Amazon Appstore client when it starts, even if you choose not to apply DRM.
Amazon removes your signature and re-signs your app with an Amazon signature that is unique to you, does not change, and is the same for all apps in your account.
Amazon has been doing this sort of thing for a decade.
It seems as though Google should have the same technical capability as does Amazon.
So, is there anything that I am missing that prevents Google from adding to or modifying the code in APKs that it re-signs and distributes?
Google doesn't just have the capability to modify .apk files uploaded to it's Google Play signing program- they already are.
Granted, this is at the moment a minor change and certainly a non-malicious one; but it remains an actual change of your .apk. They add
<meta-data
android:name="com.android.vending.derived.apk.id"
android:value="1" />
to the AndroidManifest.xml
Below is a comparison that I made in 2018 while researching this topic. It has the apk before upload (signed with upload key), and the apk as downloaded from Google Play with Google play signing enabled.
As you can see from this graphic; there's only two changes- the old signing (upload key) was removed, and replaced with Google signing. And also the AndroidManifest.xml was slightly appended (with the meta-data mentioned above)
I'll also point out this Google IO video from 2017 where they're introducing Google Play signing: https://www.youtube.com/watch?v=5tdGAP927dk&feature=youtu.be. From 11:25 in they're talking about something called "App signing + optimizations". The idea was that they could optimize apks for you, and generate sub-apks.
This was something that you could enable on a per-apk basis within Google Play. Today of course, you'll find no mention of any of this in any documentation, other than in this video- That's because they later came up with app bundles and essentially moved all this work into that. So, this is mostly relevant because the question was "What Stops Google From Modifying Our APKs That It Signs Via the App Signing Service?", and this shows that even specifically for .apk files they can; they intended to; and they were.
As others have pointed out; whoever has the signing keys and access to the Google Play account for the given app- can upload any .apk or .aab containing anything; as long as the packageName remains the same, and versionCode is incremented by one. The same applies of course to Google when Google Play signing is enabled. If they wanted, they could change, remove or add to any and all parts of the application.
It's worth keeping in mind that while yes; Google could modify everything and anything within the Google Play signed .apk file(s), those modifications aren't necessarily evil or with a bad intent. Whether for optimization purposes, compatibility or hot-fixing; there are plenty of reasons Google could or would modify the uploaded apk and justify those modifications. And they wouldn't necessarily warn the developers about this; nor would developers necessarily react to a discovery of this with an outcry.
I do believe that we're very unlikely to see Google perform purposely malicious content changes to uploaded apps, mostly for business, reputation and ethical risks outlined well in the other answers here already. I just can't picture this being a valuable attack vector for Google that outweighs the rather heavy cost-risk, and considering the other, often stronger vectors available to them.
Lastly, I'll mention integrity checks as one way this would be discovered. There are several solutions in this space that goes further than signature checks to verify the integrity of the app. Whether app developers roll their own, or use an off-the-shelves solution- these checks typically run during runtime on device to verify the integrity of the apk; comparing against records taken during compile-time or near compile-time. Modifications performed to the apk during transit does get picked up by this, including whatever change Google Play might do.
Disclaimer: I work for a app-security company that performs such integrity checks (any many other checks and verifications) on the apps that we protect. We've had to map out and account for all changes Google Play might do to an app both for regular apk files and app bundles- so we can distinguish between Google Play doing optimizations and a malicious actor repackaging the app.
At some point, the processor needs to be able to read the instructions in your app to know what it’s supposed to do. The operating system itself needs to know what to do with your app.
Ignoring how an app is packaged for a moment, for the aforementioned reasons, it seems to me there is no technical reason why your app cannot be modified by Google or any technical entity that has the knowledge and resources to do so. Let me explain further why:
It doesn’t matter how the app is packaged - the moment the operating system loads the app, you know what the app does. If the operating system did not know how to handle an app, the app would be useless.
You can try to obfuscate it, the way some popular worms tried to hide their purpose, but it really just delays the inevitable. People have been disassembling and decompiling software right from the beginning, that’s why many licenses used to explicitly prohibit disassembly.
Knowing this, it should be apparent that if “Google” wanted to modify your app they could, because even if the package is obfuscated, when the app is ultimately executing you could see what its doing then, document it, and then modify the app as required. They also have all the technical skills and resources to do so.
Let’s step back for a moment:
The purpose of signing something with a signature, is so that one can determine if the copy of the app they have received is authentic - in this case, if the app that an end user has received matches what is on the play store. The purpose being to ensure the copy you have is the same as the one distributed to other users.
You’re asking if there is a technical reason why Google cannot modify the app - no there isn’t. You’ve mentioned yourself that an apk is just a zip file. If your app was signed by yourself, and that same signature was included in the copy of the app that the end user received, then the end user could verify if Google had tampered with your app. But if your signature is stripped, then the user is left with having to trust Google.
Your question is interesting, because it made me think of something else : I guess the context in which you asked your question was “would Google be able to modify the app before distribution”. With modern devices becoming increasingly powerful, what’s to stop the operating system (since a manufacturer can customise their version of android), from modifying the app after distribution, or in future, on the fly while it executes?
I’m leaving this paper here below:
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf
The reason being it seems this will always be a perennial question, as it’s impossible for human beings to single handedly verify every piece of software in the kind of systems we use today.
I also find it a bit funny that people think that just because source code is available for an app, that it means they can trust the app which is actually running on their device - unless they’ve gone through the trouble of actually examining the app on their device, it technically is possible that the app running on their device is not the same as the source code describes - it could have been modified by both the developer themselves, or the store distributing the app for malicious or accidental reasons.
But trust has to begin somewhere 🤷♂️. In future, with Quantum Computing, maybe the way we do things will change. But again, there are so few of us who actually understand how every piece of a system works, we will still have to place our trust somewhere. Even if we understand something, having the resources to verify it is another matter as well...
so what stops Google from modifying it?
Do they really need to? It’s the developers which create value for Google Play by creating and submitting their apps.
Would you trust Google if they modified your app without your permission? How would it affect your perception of them as a company, since privacy is already a major issue.
In the event that a modification of theirs causes your app to behave incorrectly and cause damage to a customer, yourself or some third party entity, who will be held liable?
The above are just some of the reasons to think about when considering if Google will modify your app. It’s a can of worms. In the end, it boils down to cost-benefit & risk-reward analysis. What would they modify your app for, and is it worth any risk of repercussions?
In summation, there is no technical reason why they can’t. Why they don’t / won’t boils down to their business motivations and model. There is nothing to say why they will or won’t in future. But there is no reason to arbitrarily modify an app - there has to be a valid business reason which results in some kind of gain.
Simple answer: Google can, if they want to. In a digital signature scheme the signer has complete capability of modifying the document prior to signing.
Why they won't: Because developer can easily detect it, and the payload which is of most importance - the classes*.dex, actually containing the code - can easily be decompiled by interested third parties (or the app creator) to figure out any added code. (Adding code into JNI libraries is even less likely). To clarify, the detection by the developer is as easy as unzipping the APK and comparing its contents to what the developer submitted.
The impact of adding code to an app without notifying the developer would likely cause quite a backlash if discovered. Of course, at any further date Google could decide to change their terms of use, migrate from DEX to LLVM bitcode, or do something else, which might change this behavior.
Clarification: It is true, that Google could in theory ship modified apps only to certain targets, but once again it suffices that one such incident be detected (maybe by a concerned app-user mailing his or her APK to the developer?) for the implications to be far reaching for Google.
This, btw, holds true for Apple as well, being the signer of all App-Store apps. In the Apple case it's even more of a question, since apps may get recompiled by Apple (from BitCode to to the underlying ARMv8 variant), and apps deploy encrypted by FairPlay, which makes it virtually impossible to decrypt the app outside a jailbroken device.
As an anecdote, you could wonder if a malicious device vendor couldn't change dex2oat (the on-device compiler) to inject arbitrary code when the app is installed and compiled on the device itself. This would be much harder to detect, since on a non rooted device there would not be an easy way to access the compiled art/oat files of the app. But then, malicious vendors can also directly modify the Android frameworks, as well.
Apologies for potential anachronism here.
When you say
the App Signing service strips away whatever signature that we have
are you sure this is what it does? One could imagine an alternative scheme, which could achieve everything noted in other answers / comments as actually occurring:
Assume that the dev has uploaded their artefacts (let's say as an .obb) and signed it using their upload key. Google appends its additional metadata (think of it as a kind of diff file) and re-signs the resulting expanded payload. On receipt at the device, android checks that the payload it has received was correctly signed by Google (which it was), removes (but keeps) the metadata Google added, then checks the remaining payload (the dev's .obb) against the dev's signature. If that checks out, which it presumably will, it applies the change implicit in the added metadata to the original .obb
That .obb becomes the artifact which android installs. It isn't what the dev uploaded.
Google hasn't stripped the dev's upload signature, they've just added extra payload in a way which doesn't invalidate the original signature, then added some more payload and a signature of their own.
I'm not saying this is what they are doing, just that this is what they might be doing. You would be able to detect this once you had downloaded the payload and installed it on a device. Could it be made to happen or not according to which device the download was sent to? I expect that wouldn't be hard. And in that case, you wouldn't be able to detect it unless you had access to a device which had been targetted for the modification. It would be very difficult to detect the modification process while it was occurring. You could tell the difference between a modified payload and an unmodified payload immediately on receipt at the device because the presence or absence of the metadata "diff" would change the file size.
I don't know whether bundletool could support such a scheme. I guess that's where you could look for clues.
They may just be stripping the dev's upload signature and replacing it with their own. The only protection against signature stripping comes from checks done by the receiver.
When it comes down to it, you cannot trust any crypto scheme if you might consider the receiving endpoint to be compromised. Whether the payload is encrypted (which in this case it isn't) or merely signed, if the endpoint is not going to enforce the scheme, the sender and the user are both potentially exposed.
Technically, in this case, the crypto on the endpoint is in the control of the device manufacturer, although it is questionable whether they would actually exercise that control against the will or interests of the OS provider - Google - assuming that manufacturers even check these things.
I realise this is a loaded question but I'm hoping someone with a deeper understanding of obfuscation and public key security etc. will be able to help - and the issues are wider than just Apps with In App Purchases too, of course, but that's my personal interest at this point.
I once made the mistake of using ProGuard on one of my (free) Android Apps - I say mistake because tracing problems reported by users became and utter and total NIGHTMARE and I soon realised I was gaining nothing and so I dropped it.
I now have paid Apps and apps with In-App Purchases (using both Amazon and Google Billing Systems) ready for launch and it seems that using Proguard (or a similar alternative) is strongly recommended - but before I step back into that nightmare, is it REALLY essential?
If people want to reverse-engineer my code to remove ads or get Apps 'for free' then they'll do it somehow I'm sure - but I obviously don't want to make things like Billing Systems and people's personal credentials less secure!
The Google Play In-App Billing talks about obfuscating things like the In-App product Public Keys (by storing them in separate bits to make changing them harder) - I guess not Proguarding weakens that further - but is this just my Apps or does it have a wider effect on other people's Apps/customers own personal security?
Basically - I care not 1 jot about pirates because they will do what they do regardless, I certainly don't want to give myself work for just that purpose, but neither do I want to weaken security for other users either!
Anyone clued-up enough on this to comment??
ProGuard only helps prevent piracy; it does not affect the safety of personal information.
Well-designed payment processing systems (for the public) remain secure even if someone hacks their client (a.k.a. your app). The most someone could do is access paid content without paying, but there's no way for a hacker to compromise other people's apps through the Google or Amazon payment systems.
So, adding Google or Amazon payment processing to an app does not affect the security of the app.
However, if a hacker manages to hack someone else's phone through regular means, they might be able to access the payment information stored in your app. But ProGuard only protects code, not personal information, so it would not prevent this sort of hack either.
I am developing an android app and I am planning to publish it (paid app). I have heard that it is very easy to pirate Android apps (much easier than iphone). I was wondering from your experience or what you know, how can increase the security of my app? I know that I can never get it 100% secured but I want to make it harder for people to pirate it or distribute it illegally
Any ideas, experiences, comments you can share?
I released a free anti-malware app for Android, and making sure nobody hacked it was essential to its success. The biggest threats agains an app on the Android Market include leaked source code, copied/distributed paid apps, and re-keying. I explain each below and way to solve them.
Firstly, this paper describes how to reverse-engineer an Android application by unpacking the compiled code and viewing the source code. You will not be able to block this from happening to your app. Period. Someone with a will can always view your sourcecode if they get a copy of your apk (easily available on a rooted phone). The good news is that you can obfuscate the important pieces of your code making it harder to reverse engineer. Proguard is a tool provided by Android that lets you obfuscate (make harder to read) your code during packaging. In order to prevent your important code from being read, however, you will need to move all vulnerable methods or variables to a file that is not an Activity, Service, or BroadcastReceiver. For full facts, read the documentation.
To protect agains illegally copy and distribution of your application, Google Play provides some licensing options. Unfortunately, LVL is also not entirely secure. A detailed HOW-TO for how to crack it (pre-Google Play) is available here.
Lastly, the paper linked above, as well as numerous scholarly articles and online blogs describe how, once the source code (or even obfuscated source code) is leaked, once can merely add some of their own, malicious code, resign the app, and publish it on the Android Market. The good news here is that, unless your android license key password is easily guessable, or if you give it out to someone else, the attacker will not be able to publish an application with the same license key. This not only protects you from blame, but it will also make it so that malicious application cannot access data available through your original application (such as SharedPreferences).
All in all, the best way to really secure your application from piracy is to correctly configure and use Proguard, Google Play Licensure, and to sign you final apk with a very secure license key.
You could add tamper checks combined with obfuscation to alert user/disable functionality /report to server if the app has been pirated. I use DexGuard for hardened obfuscation.
Tamper checks
Installer app - Use package manager to ensure the installing app is the play/amazon app store
Emulator check - Check system properties for telltale signs the app is being run on emulator which outside of dev could indicate attack/tampering
Debuggable check - Use package manager to check the debuggable flag, this should be off in product so could indicate attack/tampering
Signing certificate check - Use package manager to verify the app is signed with your developer certificate (this would be broken if someone unpacked and repacked/resigned the app)
update: Since answering this question, I've written a more detailed article on tamper detection.
Have a look at the Google Play licensing framework.
http://developer.android.com/guide/market/licensing/index.html
This is your best choice.
Google Play Licensing is a network-based service that lets an
application query a trusted Google Play licensing server to determine
whether the application is licensed to the current device user. The
licensing service is based on the capability of the Google Play
licensing server to determine whether a given user is licensed to use
a given application. Google Play considers a user to be licensed if
the user is a recorded purchaser of the application.
If I want to deploy to the Android Market it looks like I have two options:
Create my own keystore and upload. When I update my app use that keystore on my APK to ensure that users are given the option to update.
Do step 1, but also implement Application Licensing which will put controls on how the app is used.
Am I correct to assume that step 1 means that anyone could copy my APK once it is purchased from the Android Market and install it anywhere they wish?
How common is it for people to use Application Licensing and is it the defacto approach?
My app will be paid and I want to ensure I am taking the best approach.
Am I correct to assume that step 1 means that anyone could copy my APK once it is purchased from the Android Market and install it anywhere they wish?
Yes you are correct, it would be extremely easy to copy your application.
How common is it for people to use Application Licensing and is it the defacto approach?
I would say it's very common since it's the only way to verify the licence against the Android Market, though I don't have any stats on this. Otherwise you would need to implement your own "Market" and verify purchases in your own.
My app will be paid and I want to ensure I am taking the best approach.
Use LVL, DO NOT use the default implementation. Watch the LVL session from the 2011 IO for a how to.
Often times, people will not simply download an app and copy it anywhere they would like. However, it is possible through some apps and other software for users to copy off APKs from their phones (even though they aren't suppose to). In my opinion, if you app is paid, you should implement Applicant Licensing. It is a very useful tool to help in preventing people from stealing your APKs (in other words, downloading it and then trying to install it some where else) as it checks on start up to ensure that the app is on the phone that purchased it. Otherwise, for free apps, I don't really see the neccessity because it's free and anyone could have downloaded it.
I was wondering what the most effective way of preventing people from stealing my application (downloading a copy of the .apk online rather than buying it).
I've spent a lot of time on one in particular (Droidbox) and won't be releasing Sync until I can guarantee that the people who are providing illegal copies of the pro version aren't able to.
Anyone implemented this? I've tried checking my package signature verses an the signature of an unsigned copy but it appears to be the same - perhaps I'm doing something incorrectly here. I'm unsure whether people actually distribute the signed .apk in which case I don't think signature validation would work to begin with...
Please note, this question is specific to Android Marketplace Applications - the difference being, application delivery is out of my hands and I have no way of linking between a legitimate purchase and an illegal download.
Now there is the new Google App Licensing available. For deeper information read about it in the android developer blog.
A short summary: Google provides a library that makes a inter process call to the market client on the phone. The market client will then ask the google servers if the signed in user has purchased the app and forward this answer to you. There should be a public key in you developer profile that you need to encrypt the connection to the google server to prevent spoofing of answers. You also provide a application and device unique id with the query to make it impossible to forward approved queries to another device and build something like an licensing proxy with one bought copy forwarding the IS LICENSED answers to other devices.
At the moment this service looks secure enough to protect even the more valuable apps in the market. I will give it a try and maybe come back and leave some more informations after I used it a little bit.
If your app is really popular like an EA game or something this wan't stop users from hacking it. To hack the app somebody has to buy it, then unzip the apk, and edit the bytecode of your app to think that the market send a correct answer. The new byte code can be packed into another apk and can be installed on every phone that allows side loading.
To make this harder you can always try to obfuscate your apk and make your bytecode hard to understand.
There is a single, useful connection between an application buyer and the developer through the marketplace, the forwarding email address provided by google to contact the buyer.
Utilizing the integration callback setting to send buy information to your own server, you can use PHP to send a unique identifier (registration code) to the buy via email (real time as the callback is shipped from google during a purchase. The user then uses this email to register their software using the unique identifier that is then linked to their android ID (or google account username) and the software is "activated" and guaranteed to be legitimate.
Obvious Questions
Why is this a suitable solution when it requires the user to read email? Our market are those people who are capable of buying an application using an android device. By using an android device, it is implied that the user has a google account which implies they know how to use email.
How do I use the email with the unique identifier with my application? Create a content handler in your application that handles something like "myactivator://uniqueid-or-something" which causes your application to communicate to your internal server that keeps tabs on activations. Embed this as a link in the email that the user can click on.
How should I generate the unique identifer? I'm going to use the email somehow - I'm fairly confident google has already made it unique enough to disallow any feasible method of contact information selling.
What about people who have already purchased the software? A lot of options here - none ideal or terrible.
Send emails to all previous buyers
Allow users to activate by typing in their order number (can be obtained by logging into checkout.google.com.
Why bother?
Because some of us put a lot of time into applications and saying "you should just accept pirating" is a slap in the face.
The people that are lax enough to use pirated copies of your application to access their DropBox are probably using their DropBox for piracy anyway. Forget those people. Let them go. Yes, it's a huge number of people I bet, but let's face it, those people were never going to pay you anything anyway. Focus on the parts that you can control, and forget the rest.
Focus on the Android users that use DropBox for their work, for their businesses, for their own code, for their finance, for their thesis, and/or for their private family pictures. 95% of those people, that have something of value in their DropBox, and that want it kept private, are going to want to buy your application (assuming it's good enough for them).
Let me use this analogy:
When it comes to hiring a locksmith to put a lock on your home, do you hire the guy that looks the part and takes $150 an hour, or do you hire the shady guy that is willing to sell you a stolen lock to put on your front door?
Release your own illegal copy in the best known forums and have it disable itself after a week and showing a message like
Thanks for stealing... I make my living with programming this app. The x Dollar won't hurt you and I could by my next meal and go on making great updates for you.
I think this is the only thing that you can do about it. People will always find a way to copy your app and all countermeasures will only disturb the users that paid for the app.
The people copying your app aren't your customers and they never will be. Just see their use of the program as a kind of viral marketing. At least they are talking about your app and maybe some of their friends will then buy the app.
General shareware advice here - license the software to the individual. i.e. provide a license key that is personalized to their username. They'll be much less likely to distribute a key if it's got their name on it. You can probably automate the backend fulfillment of the order, to provide custom keys. Have your "Pro" version operate in trial mode until the name/key are entered.
Don't leave your computers so that someone can steal your applications from there.
Or wait.. Did you meant you don't want others to copy your software? Then.. not publishing it in the first place is likely your best option.
A bit related link: http://news.cnet.com/8301-27076_3-20003120-248.html
You neither have any mechanism to estimate amount of illegally copied software. Enjoy your attempts from stopping the rain even though entities bigger than you have attempted and failed.
There is a new tool in the wild that seems to good to be true:
Automatic Application Licensing from Keyes Lab.
I haven't tried it yet but if this works it sound like something you want to use in your high priced android apps.
If anybody tested it leave a comment or edit my answer with personal feedback.
I have the same issue. I recently found a number of my paid apps available for free download on this site: https://dlandroid.com/
I asked them to remove my app APKs, but I'm sure there are many other similar sites. Presumably they have a rooted phone which gets one valid copy of the app from Google Play, then uploads it onto their web site to distribute to all and sundry for free.
You could spend endless amounts of time ensuring that there are no pirated copies of your apps on the web, or implementing complex piracy protection measures, which would most likely make things less convenient for your genuine paid users. But I guess in the end, you have to be prepared to make a trade-off and accept that a certain level of loss is inevitable, and hope that most people are honest and get your app through the proper channels rather than risk malware infection by going to dodgy sites like this.