Dev:Crack prevention

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.

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.

Tools
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
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.

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.

Obfuscation
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.

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 :
 * Anti-debugging
 * Anti-dumping
 * Integrity check and dynamic code generation.

PT_DENY_ATTACH
This method is now bypassed by tools automatically

PT_DENY_ATTACH is an Apple-specific constant that can prevent debuggers (gdb, DTrace, etc.) from debugging your binary in kernel-level. Calling 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 : break ptrace commands 1 return continue end

Nevertheless, since the ptrace</tt> is built inside the kernel, which the userspace interface only performs syscall 26, 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</tt> out the svc #0x80</tt> 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 http://landonf.bikemonkey.org/2009/02/index.html showing how to check this.