[펌]Wiki Crack prevention

Crack prevention

From iPhone Development Wiki

Jump to: navigation, search

Contents [hide] 1 How cracking works 1.1 Redistribution 1.1.1 AppStore 1.1.2 CydiaStore and RockApp 2 Crack prevention 2.1 General techniques 2.1.1 Multi-pass check 2.2 Anti-redistribution 2.3 Anti-analysis 2.3.1 Malformed Mach-O Binaries 2.3.2 PT_DENY_ATTACH 2.4 Obfuscation 2.4.1 Strip symbols 2.4.2 Minimize use of Objective-C 2.4.3 Generate strings dynamically 2.5 Legitimacy check 2.5.1 Check if encryption is intact 2.6 Deprecated or not working methods 2.6.1 Kali Anti-Piracy 2.7 References

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:

#define LC_ENCRYPTION_INFO 0x21
struct encryption_info_command {
  uint32_t cmd;
  uint32_t cmdsize;
  uint32_t cryptoff;   // file offset of first encrypted byte
  uint32_t cryptsize;  // file size of encrypted data
  uint32_t cryptid;    // method of encryption
};

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.

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

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. 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^[1] 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^[2]:

break ptrace
commands 1
   return
   continue
end

Nevertheless, since the ptrace is built inside the kernel, which the userspace interface only performs syscall 26^[3], 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 svn #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.

Obfuscation

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 and disable your check.

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

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^[4]:

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

References

1. ↑ http://developer.apple.com/Mac/library/documentation/Darwin/Reference/ManPages/man2/ptrace.2.html
2. ↑ http://steike.com/code/debugging-itunes-with-gdb/
3. ↑ http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/kern/syscalls.master
4. ↑ http://www.iclarified.com/entry/index.php?enid=3058 

원문 : http://iphonedevwiki.net/index.php/Crack_prevention