Automated License Generator, Manager and Verifier System for Mobile and Desktop Applications

Piracy Techniques

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.