Crack prevention

From iPhone Development Wiki
Revision as of 10:21, 9 June 2014 by Ninji (talk | contribs) (Updated some information, added more modern descriptions, probably needs cleaning.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Crack Prevention is a series of steps taken by some developers to prevent 'cracked' applications executing. Many developers and businesses see DRM as a malicious feature that only hurts legitimate users, as once broken it serves no purpose in defeating illegitmate use, but does use up developer time and can effect user's stability. All methods detailed here are easy to bypass - do not use them as protection.

App Store

App Store binaries are signed by both their developer and Apple. This encrypts the binary so that decryption keys are needed in order to make the binary readable. When iOS executes the binary, the decryption keys are used to decrypt the binary into a readable state where it is then loaded into memory and executed. iOS can tell the encryption status of a binary via the cryptid struture member of LC_ENCRYPTION_INFO MachO load command. If cryptid is a non-zero value then the binary in encrypted.

'Cracking' works by letting the kernel decrypt the binary then siphoning the decrypted data into a new binary file, resigning, and repackaging. This will only work on jailbroken devices as codesignature validation has been removed. Resigning takes place because while the codesignature doesn't have to be valid thanks to the jailbreak, it does have to be in place unless you have AppSync or similar to disable codesignature checks.

/* Declared in mach-o/loader.h */
struct encryption_info_command {
   uint32_t cmd;    /* LC_ENCRYPTION_INFO */
   uint32_t cmdsize;  /* sizeof(struct encryption_info_command) */
   uint32_t cryptoff; /* file offset of encrypted range */
   uint32_t cryptsize;  /* file size of encrypted range */
   uint32_t cryptid;  /* which enryption system,
           0 means not-encrypted yet */

Cracking has legitimate uses in the Application Security industry, as well as for user's who wish to back up DRM-free copies of software they own, however the act of stripping DRM does allow the binary to be easily shared.


The majority of cracking tools started out as bash scripts that used gdb to dump the decrypted data; xCrack, CrackTM, PCM etc. Methods have now moved away from bash and gdb to manually forking the binary, dumping and patching as needed. The most popular tool at the moment is Clutch.


Cydia in a nutshell is just repositories with a secure, authenticated connection on top of the usual APT/DPKG system. Unlike the App Store there isn't additional encryption/DRM. Therefore all the crackers need is to obtain the download .deb file. Some developers have attempted to write their own DRM - for example CoolStarDRM, although this was soon broken.

General Crack Protection

All Crack Protections are generally rendered useless by either Clutch or Overdrive, these methods remain purely as interesting tidbits. They will not stop your application from being cracked. All anti-piracy checking is fairly useless as attackers have complete access to your binary and can patch them with relative ease.

Multi-pass check

This method only works as a delay - it is easy to patch.

A simple method is to have multitudes of checks at different locations. A convenient method is to define an always inline function. The key point here is always_inline. Without inlining, the cracker could simply patch the check_crack() function to do nothing and your anti-crack will fail immediately. Do not make the check computationally too expensive, otherwise legitimate users will be affected too.

__attribute__((always_inline)) void check_crack(symbol, length, result) {
  if (checksum(symbol, length) != result)
check_crack(my_inline_uuid_check, 0x200, 0x12345678);
register int res = my_inline_uuid_check();
check_crack(my_inline_serial_number_check, 0x200, 0x87654321);

Malformed Mach-O Binaries

Many reverse engineering tools, including otool, gdb, class-dump, etc. will blindly trust the Mach-O file to be well-formed. If a Mach-O file is malformed these tools will fail to work. On the other hand, the kernel is more resistant to these corruptions, making it viable to be run.

One proved method is to set a wrong value to the number of sections in a segment command. Unfortunately, both ldid and dyld cannot recover from this kind of error, making such binaries not runnable nor linkable. But you can do the following to get your dylib/executable working: ldid -S the binary, modify nsects and then recreate the SHA with ldid -s. After that the binary is fully usable on an iOS device.

Crackers can simply fix the count to perform their analysis.


Obfusification is the method of making code or instructions harder to read - this makes it slightly harder for a patcher to figure out what is happening in a routine but is in no way a bullet-proof solution.

Strip symbols

Stripping symbols makes it hard to guess the purpose of a routine.

Minimize use of Objective-C

To support the runtime features, Objective-C-based binaries need to retain a lot of class information, which is enough to rebuild the class interface. This information cannot be stripped away, therefore, all essential implementations should be done using C or C++.

Generate strings dynamically

Even if you have stripped the binary, chances are there still is a constant string pool. If you use some visual technique to inform the user they're using a cracked version, the crackers can quickly track down where the view is generated with strings and disable your check.

Deprecated or not working methods

Kali Anti-Piracy

Kali Anti-Piracy, developed by RiP-Dev, was the first generic AppStore crack prevention mechanism announced. Since RiP-Dev has been closed down, Kali's status is doubtful enough to be considered obsoleted.

Kali has 3 levels of protection[1]:

  • Anti-debugging
  • Anti-dumping
  • Integrity check and dynamic code generation.


This method is now bypassed by tools automatically

PT_DENY_ATTACH[2] is an Apple-specific constant that can prevent debuggers (gdb, DTrace, etc.) from debugging your binary in kernel-level. Calling

ptrace(PT_DENY_ATTACH, 0, 0, 0);

will send a SEGFAULT to its tracing parent. Nevertheless, since ptrace has a well-defined address, a simple GDB macro is enough to break this[3]:

break ptrace
commands 1

Nevertheless, since the ptrace is built inside the kernel, which the userspace interface only performs syscall 26[4], as long as your assembly code resembles

mov r0, #31
mov r1, #0
mov r2, #0
mov r3, #0
mov ip, #26
svc #0x80

the PT_DENY_ATTACH will be installed and there is no way GDB can workaround it. The cracker can still use patching techniques to nop out the svc #0x80 instructions, but checksumming would help in these cases. Also make sure you don't compile your binary in thumb, cause the compiler will fail due to limited availability of registers in thumb mode.

Check if encryption is intact

This is automatically patched by most tools

This is only meaningful for AppStore apps. If the binary is not yet decrypted, the LC_ENCRYPTION_INFO load command should still exist and all its fields are nonzero. There is a sample code in showing how to check this.