Copy Protection Overview

Landscape and Motivation

Applications downloaded from the iTunes App Store are protected by FairPlay DRM. The FairPlay copy protection has been cracked some time ago [1]. What's worse, the copy removal method has been automated by the infamous Crackulous application [2]. The silver lining is that removing the copy protection from applicatins invalidates Apple's signature, so these applications cannot be run on phones without the jailbreak.

iPhone application piracy is significant [3][4][5], so relying on Apple's protection scheme is not a solution for most developers. RIPdev offers a protection scheme that they claim has not been broken so far, but they charge both a setup fee and royalties on an application's sales [6].

Fighting one particular automated process for removing copy protection is easy [7], but curving iPhone application cracking is difficult, because of the many undocumented moving pieces (Apple's signatures, protection mechanism, application approval process, and iTunes distribution). Learning all this is a lot of work, which is currently duplicated by all independent developers who don't want to pay RIPdev. If developers pool their knowledge into the iPhone Wiki, the learning effort will not be duplicated anymore, and applications will have higher overall quality. Ideally, developers will produce an open-source obfuscation mechanism that is trivial to apply to applications, but takes a non-trivial amount of time to reverse.

Copy Protection Removal Overview

Developers that want to guard against copy protection removal must understand how it works. [8] documents the process in a tutorial fashion. A summary follows.

The only encrypted part in an iPhone application is the executable file. The cracking process starts the victim application, then uses a debugger to suspend it. The application's executable code lies unprotected in RAM, and the debugger dumps it on disk. Then, the encrypted part of the executable file is replaced with the unencrypted code dumped from memory.

The application's Info.plist is modified so that the jailbroken iPhone kernel does not check the application's signature, which is invalidated by the modification of the executable file. A more rigurous cracking process could remove Apple's signatures and certificates, and replace them with a self-signed certificate, as is done when developing with the jailbroken toolchain.

Defeating Copy Protection Removal

RIPdev's blog post on Kali Anti-Piracy [9] suggests the following methods to counter copy protection removal.

• preventing debuggers from attaching to the application
• loading the executable code in stages, such that it's never completely present in RAM, unprotected
• integrity checks throughout the application

Methods

Debugger Detection

this should prevent the standard script kiddie + gdb:

ptrace(PT_DENY_ATTACH,0,0,0);

Covert Exit

You can use:

  __asm__ volatile("swi 0x11");

instead of calling exit(); since that it more obvious, but you may want to have the "swi 0x11" part be a NOP then use STRB to reconstruct it opcode by opcode. The reason I did not include an example of "reconstructing" it in the above snippet is simple. If everyone uses it, then it would be reduced to a simple byte search by crackers. If everyone does it in a different way, then it would be much tougher.

Integrity Checks

An increasing trend among application developers is to use inexpensive integrity checks, and revert into a trial mode or shut down the application, some time after the integrity checks fail. An essential step is making sure the application does not act too soon, so that "crackers" do not notice the integrity checking process, and release the application as cracked immediately after removing the FairPlay encryption.

[10] suggests examining the Info.plist file, and checking for the existence of the SignerIdentity key that is added in the cracking process, and would not exist on any applications originating from the App Store. However, this is not advisible, as it can be patched simply by the cracker searching for either the "SignerIdentity" string in your code, or a bunch of MOVs if you used stringWithFormat to construct the string character by character. Anyway, it would probably be more beneficial if you checked the size and sha1 of the Info.plist, as although people will find this, it just makes it a bit harder than it would have been. Hell, with the check for the existence of SignerIdentity Check, someone could put together a program to automatically search for that string and then put patch it to be "SignerIdentitx" or something, so that your program obviously won't find it in the Info.plist. [11] suggests reading the executable file, and checking for the Mach-O directives for an encrypted section, as FairPlay introduces an encrypted section which is removed by cracked applications.

These methods are cheap to implement. They are also easy to break, once the cracker is aware of them. This explains the need for introducing a delay between the crack detection and the delivery of the punishment, which can be as mild as popping a dialog box appealing to the user to purchase the application [12].