How To Crack Just About Any Mac App (And How To Prevent It)

While the Mac is rarely targeted for security exploits and viruses, it's no stranger to software piracy - likely because Mac apps are pretty easy to crack. Here's how it can be done and how to prevent it.

How I'd Crack Your Mac App

Disclaimer: I am fervently against software piracy, and I do not participate in piracy. Some will view this article as an endorsement of piracy, but rest assured that it is not. However, I do not believe that obscurity and ignoring the problem is an acceptable solution.

Well, not you specifically, but by you I mean the average Mac developer. It's too easy to crack Mac apps. Way too easy. 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 Exces, 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 Homebrew 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.

$ sudo brew install otx

$ sudo brew install class-dump

The first step is to poke into the target app's headers, gentlemanly left intact by the unwitting developer.

$ cd

$ class-dump Exces | vim

Browse around, and find the following gem:

@interface SSExcesAppController : NSObject



BOOL registred;


- (void)verifyLicenseFile:(id)arg1;

- (id)verifyPath:(id)arg1;

- (BOOL)registred;

What do we have here?! 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.

$ otx Exces -arch i386

Note that Exces is a universal binary, and that we need to ensure we only deal with the active architecture. In this case, Intel's i386. Let us find out what verifyLicenseFile: does.

-(void)[SSExcesAppController verifyLicenseFile:]


+34 0000521e e8c21e0100 calll 0x000170e5 -[(%esp,1) verifyPath:]

+39 00005223 85c0 testl %eax,%eax

+41 00005225 0f84e2000000 je 0x0000530d


+226 000052de c6472c01 movb $US0x01,0x2c(%edi) (BOOL)registred


This is not straight Objective-C code, but rather assembly-what C compiles into. The first part of each line, the offset, +34, shows how many bytes into the method the instruction is. 0000521e is the address of the instruction within the program. e8c21e0100 is the instruction in byte code. calll 0x000170e5 is the instruction in assembly language. -[(%esp,1) verifyPath:]is what otx could gather the instruction to represent in Obj-C from the symbols left within the binary.

With this in mind, we can realise 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 licence 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.

$ gdb Exces

(gdb) break [SSExcesAppController verifyLicenseFile:]

Breakpoint 1 at 0x5205

(gdb) run

No bite. 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 licence files entered by the user. Quit gdb and let's instead search for another piece of code that calls verifyPath:. In the otx dump, find the following in awakeFromNib:

-(void)[SSExcesAppController awakeFromNib]


+885 00004c8c a1a0410100 movl 0x000141a0,%eax verifyPath:

+890 00004c91 89442404 movl %eax,0x04(%esp)

+894 00004c95 e84b240100 calll 0x000170e5 -[(%esp,1) verifyPath:]

+899 00004c9a 85c0 testl %eax,%eax

+901 00004c9c 7409 je 0x00004ca7

+903 00004c9e 8b4508 movl 0x08(%ebp),%eax

+906 00004ca1 c6402c01 movb $US0x01,0x2c(%eax) (BOOL)registred

+910 00004ca5 eb7d jmp 0x00004d24 return;


The code is almost identical to verifyLicenseFile:. Here's what happens:

  • verifyPath: is called. (+894 calll)
  • A test happens based on the result of the call. (+899 testl)
  • Based on the result of the text, jump if equal. (+901 je) A test followed by a je or jne (jump if not equal) is assembly-speak for an if statement.
  • The registred ivar is set, if we have not jumped away.

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. 7534 is a similar binary code. 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.

$ gdb Exces

(gdb) break [SSExcesAppController awakeFromNib]

Breakpoint 1 at 0x4920

(gdb) r

(gdb) x/x 0x00004c9c

0x4c9c <-[SSExcesAppController awakeFromNib] +901>: 0x458b0974

We break on awakeFromNib so we're able to fiddle around while the app is frozen. x/x reads the code in memory at the given address.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. so while the code at address 0x4c9c is printed as 0x458b0974, it's actually 0x74098b45. We recognise 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 <-[SSExcesAppController awakeFromNib] +901>: je 0x4ca7 <-[SSExcesAppController awakeFromNib] +912>

Now let's edit code in memory.

(gdb) set {char}0x00004c9c=0x75

(gdb) x/x 0x00004c9c

0x4c9c <-[SSExcesAppController awakeFromNib] +901>: 0x458b0975

(gdb) set {char}0x00004c9d=0x34

(gdb) x/x 0x00004c9c

0x4c9c <-[SSExcesAppController awakeFromNib] +901>: 0x458b3475

Here we set the first byte at 0x00004c9c. 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.

(gdb) disas

0x00004c9c <-[SSExcesAppController awakeFromNib] +901>: jne 0x4cd2 <-[SSExcesAppController awakeFromNib] +955>

Whoops, we made a mistake and changed the destination of the jump from +912 to +955. We realise that the first byte (74) of the byte code stands for the je/jne and the second byte is the offset, or how many bytes to jump by. We should only have changed 74 to 75, and not 09 to 34. Let's fix our mistake.

(gdb) set {char}0x00004c9c=0x75

(gdb) set {char}0x00004c9d=0x09

And check again…

0x00004c9c <-[SSExcesAppController awakeFromNib] +901>: jne 0x4ca7 <-[SSExcesAppController awakeFromNib] +912>

Hooray! This looks good! Let's execute the app to admire our crack.

(gdb) continue

Woot! Victory! 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.) Well, not quite. 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.

(gdb) x/8x 0x00004c9c

0x4c9c <-[SSExcesAppController awakeFromNib] +901>: 0x458b0975 0x2c40c608 0x8b7deb01 0xa4a10855 0x4cac <-[SSExcesAppController awakeFromNib] +917>: 0x89000141 0x89082454 0x89042444 0x26e82414

That's the memory representation of the code, a whole eight blocks of four bytes starting at 0x00004c9c. 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.

(gdb) quit

$ vim Exces

This loads up the binary as ascii text, which is of little help. Convert it to hex thusly:


vim formats hex like this:

0000000: cafe babe 0000 0002 0000 0012 0000 0000 ................

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. Now that we have our beautiful hex code loaded up, let's search for the first two bytes of our code to replace:


Shit. Too many results to make sense of. Let's add another two bytes. Search for "7409 8b45" instead and boom, only one result:

001fc90: 0089 4424 04e8 4b24 0100 85c0 7409 8b45 ..D$..K$....t..E

Edit it to the following:

001fc90: 0089 4424 04e8 4b24 0100 85c0 7509 8b45 ..D$..K$....t..E

Convert it back to binary form, then save and quit:

:%!xxd -r


And… We're done! To check our work, launch the app in gdb, break to [SSExcesAppController awakeFromNib]and disassemble.

$ gdb Exces

(gdb) break [SSExcesAppController awakeFromNib]

Breakpoint 1 at 0x4c90

(gdb) r

(gdb) disas

Admire our work:

0x00004c9c <-[SSExcesAppController awakeFromNib] +901>: jne 0x4ca7 <-[SSExcesAppController awakeFromNib] +912>

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. Also read this older article of mine on three easy tips-stripping debug symbols, using PT_DENY_ATTACH, and doing a checksum of your binary-you can implement to make it a whole lot harder for your app to be cracked.

A truly skilled hacker will always find his way around your protection, but implementing a bare minimum of security will weed out 99 per cent 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 personal blog for more writing on the world of design, software, and life. You can contact him at [email protected].