Well, not you specifically, but by you I mean the average Mac developer. It's too easy to crack Mac apps. By walking through how I can hack your app with only one Terminal shell, I hope to shed some light on how this is most commonly done, and hopefully convince you to protect yourself against me. I'll be ending this article with some tips to prevent this kind of hack. In order to follow along you're going to need a few command line utilities. You're going to need the Xcode tools installed. And, lastly, you're going to need an app to operate on. I chose , a shareware App I wrote a long time ago. Let's start by making sure we have the two utilities we need: otx and class-dump. I like to use as my package manager of choice. Note that I will use command line utilities only, including vim. If you prefer GUIs, feel free to use your code editor of choice, HexFiend and otx's GUI app. A badly spelt variable and what looks like three methods related to registration. We can now focus our efforts around these symbols. Let's continue poking by disassembling the source code for these methods. In this case, Intel's i386. Let us find out what verifyLicenseFile: does. The first part of each line, the offset, +34, shows how many bytes into the method the instruction is. With this in mind, we can realize that verifyLicenseFile: calls the method verifyPath: and later sets the boolean instance variable registred. We can guess that verifyPath: is probably the method that checks the validity of a license file. We can see from the header that verifyPath: returns an object and thus would be way too complex to patch. We need something that deals in booleans. Let's launch Exces in the gdb debugger and check when verifyLicenseFile: is called. The breakpoint is not hit on startup. We can assume that there's a good reason why verifyLicenseFile: and verifyPath: are two separate methods. While we could patch verifyLicenseFile: to always set registred to true, verifyLicenseFile: is probably called only to check license files entered by the user. Quit gdb and let's instead search for another piece of code that calls verifyPath:. Since awakeFromNib is executed at launch, we can safely assume that if we override this check, we can fool the app into thinking it's registered. The easiest way to do that is to change the je into a jne, essentially reversing its meaning. Search the dump for any jne statement, and compare it to the je: +901 00004c9c 7409 je 0x00004ca7 +14 00004d9f 7534 jne 0x00004dd5 return; 7409 is the binary code for je 0x00004ca7. If we simply switch the binary code for the je to 7534, at address 00004c9c, we should have our crack. Let's test it out in gdb. Now here's the confusing thing to be aware of: endianness. While on disk, the binary code is normal, intel is a little-endian system which puts the most significant byte last, and thus reverses every four-byte block in memory. We recognize the first two bytes 7409 from earlier. We need to switch the first two bytes to 7534. Let's start by disassembling the method so we can better see our way around. Find the relevant statement: 0x00004c9c : je 0x4ca7 Now let's edit code in memory. By simply counting in hexadecimal, we know that the next byte goes at address 0x00004c9d, and set it as such. Let's disassemble again to check if the change was done right. We should only have changed 74 to 75, and not 09 to 34. Let's fix our mistake. Let's execute the app to admire our crack. We're in, and the app thinks we're a legitimate customer. Time to get wasted and party! I recommend Vessel nightclub in downtown San Francisco. We still need to make our change permanent. As it currently stands, everything will be erased as soon as we quit gdb. We need to edit the code on disk, in the actual binary file. Let's find a chunk of our edited binary big enough that it likely won't be repeated in the whole binary. Taking endianness into account, we must reverse them and we get the following: 0x75098b45 0x08c6402c 0x01eb7d8b 0x5508a1a4 0x41010089 0x54240889 0x44240489 0x1424e826 The very first byte of the series is the 74 that we switched into 75. By changing it back, we can deduce the original binary code to be: 0x74098b45 0x08c6402c 0x01eb7d8b 0x5508a1a4 0x41010089 0x54240889 0x44240489 0x1424e826 Let's open the binary in a hex editor. I used vim, but feel free to use any hex editor at this point. HexFiend has a great GUI. Convert it to hex thusly: :%! The first part, before the colon, is the address of block. Following it are 16 bytes, broken off in two-byte segments. Incidentally, every Mach-O binary starts with the hex bytes cafebabe. Drunk Kernel programmers probably thought it'd be funny. Too many results to make sense of. Let's add another two bytes. E Edit it to the following: 001fc90: 0089 4424 04e8 4b24 0100 85c0 7509 8b45.. E Convert it back to binary form, then save and quit: :%! Quit gdb and relaunch the app from the Finder, and bask in your leet glory. How to Prevent This Objective-C makes it really easy to mess with an app's internals. Try to program the licensing mechanism for your app in pure C, that will already make it harder for me to find my way around your binary. A truly skilled hacker will always find his way around your protection, but implementing a bare minimum of security will weed out 99% of amateurs. I am not a skilled hacker-yet with some very basic knowledge I tore this apart in no time. Implementing the various easy tips above takes very little time, yet would have made it enough of a pain for me that I would have given up. Kenneth Ballenegger develops cool Mac and iPhone software. Visit his for more writing on the world of design, software, and life. You can contact him at.