End-User Piracy

Without any modification to your app, an end-user is able to freely copy it to another device and execute it there. Most copy-protection schemes offered at online stores protect against this. For example, with DRM Separate Delivery, or other in-app purchase mechanisms, users are prevented from getting full-features of an app unless they purchase legitimately from the app store. The license for the app is linked to the device ID (IMEI or PIN), or the file system itself prohibits copying of content stamped with a copy-restricted attribute (eg. DRM Forward Lock). Without tampering at the next level, end-users aren't able to copy and run apps between devices.

Install Package Tampering

Some anti-piracy schemes can be subverted by tampering the installation or install package. For example, some schemes store the license in a hidden location on the filesystem of the device, or in the system registry, or as an appendage of the installation package. In some cases copying it as well as the app enables it to run on another device, but getting to such file may require a little more effort than a regular user is inclined. Sometimes, eliminating the license altogether enables the app to be pirated (eg. Crackulous). This technique won't work if the app (or system) performs some runtime verification and the license is linked to the IMEI or PIN of the device. If that is the case, cracking proceeds to the next level.

Library Hijacking

If an anti-piracy scheme makes use of a client library (eg. jar or dll), a pirate with development skills can write their own version of a .class file or .dll and replace the one in the installation. Their .class file or .dll would work to always return validation of the license. Unfortunately, for the anti-piracy provider, this means all apps which use their client library can be cracked with the same pirate's stub code.

Server Spoofing

If the anti-piracy scheme involves online verification whereby it connects to a server, a pirate my be able to supplant the IP address used with his or her own. For such an anti-piracy scheme, there is a probability the IP address of the verification server is hard-coded somewhere in the binary image of the app itself. Changing that could enable the protection scheme to be circumvented. Albeit, this is a more tedious way to pirate, compared to other more effective techniques.

License Cracking

While on the subject of tedium, a hacker may try some brute-force approach to break the license key itself. For example, if the key is a hash digest, they may try to crack it to devise some inputs which can produce the same digest all the time. This approach ought to be rare it would seem, as it is difficult, time-consuming, and most importantly, employing such devised inputs would imply access to the system or binary where easier cracking methods could be used.

Binary Tampering

For apps which do license verification at runtime a developer with a debugger may be able to crack the app fairly quickly. Be the app java or native code, they can examine the binary at runtime in the debugger, and identify a location in the decompilation or disassembly where license verification occurs. They may be able to do this in a number of ways:

• Single function which encapsulates license verification - Hopefully, the app owner hasn't made the hacker's job this easy. Unfortunately, many apps are written this way, and therefore are easy to crack at this level.
• System APIs which are typically used for license verification - If the hacker knows the license verification scheme uses a particular system API, they can set a breakpoint on that API or even just look for where it is called within the code segment.
• Exceptions thrown when license verification fails - If the app throws exceptions when license verification fails, the hacker can execute the app in the debugger, and ultimately identify all locations in the code where verification occurs.
• Repeatable sequence of opcodes/instructions - If the hacker can identify using the above means just one location where license verification occurs within the binary image, they will look for a pattern for the sequence of instructions in the decompilation or disassembly. There is a good chance the same pattern appears every other place license verification happens in the binary image. This would help them to identify all the locations.
• Constant data storing the license key - If the hacker can identify just one location where license verification occurs they may look if some constant data is used therein. They may be able to identify that constant data as the license key or some other key used for verification. If so, all they need to next is search where that constant data's address is referenced throughout the image. Then there is a good probability those locations are where verification occurs.

Once those locations are identified, the decompilation or disassembly can be modified and recompiled, or the bytes in the binary image may be modified directly to circumvent the license validity test. It may be a matter of only one instruction in many cases - just the one which checks if the license is valid.