Dev:Crack prevention

= How cracking works =

Redistribution
The first step of crackers is to get the redistributable files. Crackulous and AppCrack are the notorious examples of cracking the DRMs and get the redistributable IPAs for installation on unauthorized devices.

AppStore
AppStore apps are all encrypted when downloaded, to prevent reverse engineering, and ensure every account can only run their own copy. The CPU, however, is unable to run encrypted instructions. Everything must be decrypted by the time it is loaded into the RAM. Crackers exploit this fact, and uses GDB to dump the decrypted data, so that these apps can be run anywhere.

In detail, every protected app has an LC_ENCRYPTION_INFO load command. This load command looks like: when the binary is encrypted, this load command must exist, and all the 3 crypt*** fields are nonzero. For deCrypt, xCrack and alike, the GDB command to get the dump is like this: set sharedlibrary load-rules ".*" ".*" none # Don't load any symbols and libraries automatically set inferior-auto-start-dyld off set sharedlibrary preload-libraries off set sharedlibrary load-dyld-symbols off handle all nostop                          # Ignore all terminating signals. rb doModInitFunctions                      # Breaks when dyld starts. command 1                                  # When the breakpoint is reached, dump the encrypted content and quit. dump memory output.bin 0x2000 (cryptsize + 0x2000) kill quit end start This script will execute before the app's user code comes into play, and therefore you have no chance to deploy a working prevention against it (PT_DENY_ATTACH won't work).

CydiaStore and RockApp
CydiaStore and RockApp, in a nutshell, are just repositories with a secure, authenticated connection on top of the usual APT/DPKG system. Unlike AppStore there isn't additional encryption/DRM. Therefore all the crackers need is to obtain the download .deb file.

= Crack prevention =

General techniques
All anti-piracy checking won't 100% prevent crackers because they have total access to your code. But they can delay the cracks from appearing early and hurt legitimate sales.

Multi-pass check
To make crackers a hard day a simple method is to have multitudes of checks at different locations. A convenient method is to define an always inline function, e.g. 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.

Anti-redistribution
These are methods which can delay the time the first redistributable copy appear.

Anti-analysis
Avoids your binary being analyzed.

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</tt>. After that the binary is fully usable on the iDevice.

Crackers can simply fix the count to perform their analysis.

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

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. These information cannot be stripped away. Therefore, all essential stuff should be done using C or C++.

Generate strings dynamically
Even if you have stripped the binary, there is must still be 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</tt> and disable your check.

Check if encryption is intact
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.

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.