Now that you know how iPhone piracy works, (if not, click here to read previous article), you probably want to know how you can prevent it. This article will tell you that, but please note this. This is getting published for all to see, including the people that want to crack your application. If I provide you with code or a method to do a certain check in here, do not just copy it verbatim, tweak it a little so that the crackers don’t know exactly what to look for.

Since we know that crackers are going to crack your app anyway, we do not want to look at this in a “we need to stop them” way. You must know that it will happen. We need to think of this in a “hold them off as long as possible” way. The first step would be obfuscation, to confuse them. Save the code attached to the end of this post and save it In a file called “iPhoneOS_swi.S”. Include it in one of your projects and, for example, you want a discrete exit(), simply call swi_exit(); from your code. Crackers will soon catch on to this, but it is at least better then flat out and obviously calling exit(). This will at least cause some confusion. If you want to try further obfuscation, use swi_exit_obfuscated(), but change it around a bit so people can’t do a simple byte search to patch it. I have not tested that one yet, but in theory it should change the “NOP” to “SWI 0×11” in memory. Usually, kernel restrictions block this type of obfuscation, but funnily enough the patch that is needed for WinterBoard and such to work, is what allows this trick to work, in theory. Another less obvious thing you can check is if the app is running as root, which it normally should not be unless a cracker was running it in GDB via SSH like they normally do. So use something like the swi_getgid() to check if it is running as 0, which is root, and if so swi_exit(). Again, I must stress to play with this a bit, because if you do it exactly then it will be obvious for the crackers, as I can safely say they will read this article.

Now, above I am talking about how to exit the app without the cracker seeing the call directly in IDA, but you are probably thinking, “But chronic, in what cases would I actually need to exit the application? What kind of checks can I do?”. This is where things get a little shady. If I specifically give out checks to use, they are useless since they are public and they will be looked for. Instead, I will give you some tips…

1. stringWithFormat: is your friend. Use it to construct a string in a buffer letter by letter instead of having the whole string there in your code, easily searchable in IDA Pro. It is comparable to the sprintf(); of Objective-C, you could almost say.
2. Excessively use stringWithFormat: to “obfuscate” strings that do other things in your application, even the text of an AlertView or something. The goal would be to annoy the cracker when looking for all of the calls to stringWithFormat:, maybe even to the point where he would not try to take that shortcut if you use it enough times for legitimate strings.
3. Keep in mind that Info.plist is modified. You can check the size, the existence of the “SignerIdentity” key…use your imagination. The crackers /need/ to modify this file, so use that to your advantage.

/*
* iPhoneOS_swi.S
*
* Created by Will Strafach on 5/23/09
* Copyright 2009 Chronic Dev. All rights reserved.
*
* Mini-License: Keep this header here, do not modify it or anything,
* and you can use this in your projects. Also, I grant MrCracker.com
* permission to use this in their "iPhone Piracy 101" article.
*/

.global _swi_exit
.global _swi_exit_obfuscated
.global _syscall_exit
.global _syscall_chmod
.global _syscall_chown
.global _syscall_getpid
.global _syscall_getuid
.global _syscall_geteuid
.global _syscall_access
.global _syscall_getegid
.global _syscall_getgid

_swi_exit:
SWI 0x11
BX LR

_swi_exit_obfuscated:
MOV R0, #0x11
STRB R0, [PC,#0x10]
MOV R0, #0x00
STRB R0, [PC,#0x8]
STRB R0, [PC,#0x4]
MOV R0, #0xEF
STRB R0, [PC,#-0x4]
NOP
BX LR

_syscall_exit:
MOV R12, #1
SWI 0x80
BX LR

_syscall_chmod:
MOV R12, #15
SWI 0x80
BX LR

_syscall_chown:
MOV R12, #16
SWI 0x80
BX LR

_syscall_getpid:
MOV R12, #20
SWI 0x80
BX LR

_syscall_getuid:
MOV R12, #24
SWI 0x80
BX LR

_syscall_geteuid:
MOV R12, #25
SWI 0x80
BX LR

_syscall_access:
MOV R12, #33
SWI 0x80
BX LR

_syscall_getegid:
MOV R12, #43
SWI 0x80
BX LR

_syscall_getgid:
MOV R12, #47
SWI 0x80
BX LR

Developing iPhone applications is all the rage now. From the mutli-million dollar software company, to the teenager in his bedroom, it has become a new phenomenon. There are now over one billion application downloads from the Apple App Store, and even more in the unofficial homebrew Cydia Store, which is an application that allows developers to make available, for free or for pay, applications that utilize private calls and libraries. For both though, there is a rising problem for developers. This problem is piracy of their applications, which means people buy the application and patch it to work on the device’s of other people for free. In this article, I will tell you how exactly people pirate the applications, and how you can fight back. Keep in mind that eventually, one way or another, the application will get cracked. Instead of thinking with the mindset, “How can I not let this get cracked?”, it is easier to think like, “How can I prevent this from getting cracked as long as possible?”.

First, someone must buy the application. Normally, applications are encrypted with Apple’s FairPlay DRM software, but crackers have found a way around this. They then use “GNU Debugger”, or “gdb” for short, to run it. This program is available in Cydia. When the application is running, since they are controlling it via gdb, the cracker can dump the decrypted application from memory as it is running. Normally, after this, they stick the decrypted binary in the encrypted file, where the encrypted binary used to be, and then set a value called the “crypt id” from 1 to 0, to allow it to run decrypted. At this point, the application is fully decrypted, despite the intentions of Apple’s Fairplay DRM. Finally, inside of the “.app’ file, the key “SignerIdentity” with the value “Apple iPhone OS Application Signing” is added, to make the system think “It’s decrypted, it’s in the place that AppStore apps go, but it’s OK because this key means it is from Apple”. At this point, if you have added no protections to your application, the cracker is done. They simply upload their crack to a website like rapidshare.com and then distribute it as if they were super cool hackers that knew what they were doing. That’s it. Many applications have now employed additional protections though, like checking if the value “SignerIdentity” is in the Info.plist file, and although this does help, it can still be defeated. All the cracker has to do is search for the “SignerIdentity” string in IDA Pro, and then they can see what refers to it, then allowing them to see your check. The easiest thing they can do is simply patch the string to be “BLAHBLAHBLAH”, because then “SignerIdentity” can be in the plist undisturbed, and I do not think that there is any legit reason for “BLAHBLAHBLAH” to be there anyway.

All in all, most crackers are script kiddies that simply try using GDB to decrypt it, and then give up with anything more complicated than the standard “SignerIdentity” check. Read my upcoming article, “iPhone Piracy 101: Steps to Prevent it” for more advanced techniques you can use to prevent piracy of your application.