You are on page 1of 5

How to Crack Just About Any Mac App (and How to Prevent It

)

http://gizmodo.com/5736871/how-to-crack-just-about-any-ma...

Gizmodo

1 of 5

1/19/11 1:30 PM

. Some will view this article as an endorsement of piracy.. I do not believe that obscurity and ignoring the problem is an acceptable solution. $ otx Exces -arch i386 Note that Exces is a universal binary. I hope to shed some light on how this is most commonly done.] . and find the following gem: @interface SSExcesAppController : NSObject { [.%eax +41 00005225 0f84e2000000 je 0x0000530d [. I chose Exces. but rather assembly-what C compiles into. calll 0x000170e5 is the instruction in assembly language..(id)verifyPath:(id)arg1.1) verifyPath:] is what otx could gather the instruction to represent in Obj-C from the symbols left within the binary.. feel free to use your code editor of choice.. However. .. but rest assured that it is not.. We can now focus our efforts around these symbols. Way too easy.] BOOL registred. e8c21e0100 is the instruction in byte code.0x2c(%edi) (BOOL)registred [. I like to use Homebrew as my package manager of choice. By walking through how I can hack your app with only one Terminal shell.] This is not straight Objective-C code. a shareware App I wrote a long time ago. the offset.app/Contents/MacOS $ class-dump Exces | vim Browse around. and that we need to ensure we only deal with the active architecture. Note that I will use command line utilities only. Intel's i386. Let's start by making sure we have the two utilities we need: otx and class-dump. it's no stranger to software piracy —likely because Mac apps are pretty easy to crack. and I do not participate in piracy. Here's how it can be done and how to prevent it. How I'd Crack Your Mac App Well.1) verifyPath:] +39 00005223 85c0 testl %eax. gentlemanly left intact by the unwitting developer. including vim. I'll be ending this article with some tips to prevent this kind of hack. If you prefer GUIs. . and hopefully convince you to protect yourself against me.(void)verifyLicenseFile:(id)arg1. $ sudo brew install otx $ sudo brew install class-dump The first step is to poke into the target app's headers. The first part of each line.(BOOL)registred. shows how many bytes into the method the instruction is. [.. HexFiend and otx's GUI app.How to Crack Just About Any Mac App (and How to Prevent It) http://gizmodo. Let's continue poking by disassembling the source code for these methods. What do we have here?! A (badly spelt) variable and what looks like three methods related to registration.. -(void)[SSExcesAppController verifyLicenseFile:] [. but by you I mean the average Mac developer. $ cd Exces.com/5736871/how-to-crack-just-about-any-ma. By Kenneth Ballenegger 2 of 5 1/19/11 1:30 PM . you're going to need an app to operate on. not you specifically. Disclaimer: I am fervently against software piracy. +34. In order to follow along you're going to need a few command line utilities.. lastly. In this case.. It's too easy to crack Mac apps. You're going to need the Xcode tools installed.. And. 0000521e is the address of the instruction within the program. How to Crack Just About Any Mac App (and How to Prevent It) While the Mac is rarely targeted for security exploits and viruses.] +34 0000521e e8c21e0100 calll 0x000170e5 -[(%esp.] +226 000052de c6472c01 movb $0x01. Let us find out what verifyLicenseFile: does. -[(%esp.

so while the code at address 0x4c9c is printed as 0x458b0974. We can see from the header that verifyPath: returns an object and thus would be way too complex to patch. 7409 is the binary code for je 0x00004ca7. While we could patch verifyLicenseFile: to always set registred to true. Quit gdb and let's instead search for another piece of code that calls verifyPath:. Search the dump for any jne statement. Let's launch Exces in the gdb debugger and check when verifyLicenseFile: is called. 3 of 5 1/19/11 1:30 PM . intel is a little-endian system which puts the most significant byte last.Now here's the confusing thing to be aware of: endianness. We need to switch the first two bytes to 7534. With this in mind. The registred ivar is set. $ gdb Exces (gdb) break [SSExcesAppController verifyLicenseFile:] Breakpoint 1 at 0x5205 (gdb) run No bite. and thus reverses every four-byte block in memory. we can realize that verifyLicenseFile: calls the method verifyPath: and later sets the boolean instance variable registred. If we simply switch the binary code for the je to 7534.] +885 00004c8c a1a0410100 movl 0x000141a0.. $ 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.1) verifyPath:] +899 00004c9a 85c0 testl %eax.. (+901 je) A test followed by a je or jne (jump if not equal) is assembly-speak for an if statement.com/5736871/how-to-crack-just-about-any-ma..0x04(%esp) +894 00004c95 e84b240100 calll 0x000170e5 -[(%esp. Find the relevant statement: 0x00004c9c <-[SSExcesAppController awakeFromNib]+901>: je 0x4ca7 <-[SSExcesAppController awakeF Now let's edit code in memory. we can safely assume that if we override this check. we should have our crack. it's actually 0x74098b45.%eax verifyPath: +890 00004c91 89442404 movl %eax. at address 00004c9c. the binary code is normal. x/x reads the code in memory at the given address. Let's test it out in gdb. [.] The code is almost identical to verifyLicenseFile:.%eax +901 00004c9c 7409 je 0x00004ca7 +903 00004c9e 8b4508 movl 0x08(%ebp). The breakpoint is not hit on startup.. essentially reversing its meaning. Here's what happens: verifyPath: is called.. We can assume that there's a good reason why verifyLicenseFile: and verifyPath: are two separate methods. if we have not jumped away. We recognize the first two bytes 7409 from earlier. and compare it to the je: +901 00004c9c 7409 je 0x00004ca7 +14 00004d9f 7534 jne 0x00004dd5 return. While on disk. The easiest way to do that is to change the je into a jne. Let's start by disassembling the method so we can better see our way around. Since awakeFromNib is executed at launch. we can fool the app into thinking it's registered. We need something that deals in booleans. In the otx dump.%eax +906 00004ca1 c6402c01 movb $0x01. find the following in awakeFromNib: -(void)[SSExcesAppController awakeFromNib] [. (+899 testl) Based on the result of the text.. We can guess that verifyPath: is probably the method that checks the validity of a license file. verifyLicenseFile: is probably called only to check license files entered by the user. (+894 calll) A test happens based on the result of the call. 7534 is a similar binary code. jump if equal.How to Crack Just About Any Mac App (and How to Prevent It) http://gizmodo.0x2c(%eax) (BOOL)registred +910 00004ca5 eb7d jmp 0x00004d24 return.

. not quite. broken off in two-byte segments.. Convert it to hex thusly: :%!xxd vim formats hex like this: 0000000: cafe babe 0000 0002 0000 0012 0000 0000 . a whole 8 blocks of four bytes starting at 0x00004c9c. Time to get wasted and party! (I recommend Vessel nightclub in downtown San Francisco.com/5736871/how-to-crack-just-about-any-ma. Let's add another two bytes.E Convert it back to binary form.. By simply counting in hexadecimal.t. then save and quit: 4 of 5 1/19/11 1:30 PM .D$.. we made a mistake and changed the destination of the jump from +912 to +955. We should only have changed 74 to 75.. we know that the next byte goes at address 0x00004c9d... before the colon.D$. 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.. We need to edit the code on disk. every Mach-O binary starts with the hex bytes cafebabe. (gdb) set {char}0x00004c9c=0x75 (gdb) set {char}0x00004c9d=0x09 And check again… 0x00004c9c <-[SSExcesAppController awakeFromNib]+901>: jne 0x4ca7 <-[SSExcesAppController awake Hooray! This looks good! Let's execute the app to admire our crack. Following it are 16 bytes. everything will be erased as soon as we quit gdb. and the app thinks we're a legitimate customer.... (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. By changing it back. We realize that the first byte (74) of the byte code stands for the je/jne and the second byte is the offset.. which is of little help. I used vim.. Now that we have our beautiful hex code loaded up.K$..How to Crack Just About Any Mac App (and How to Prevent It) http://gizmodo.E Edit it to the following: 001fc90: 0089 4424 04e8 4b24 0100 85c0 7509 8b45 . (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.K$. (gdb) disas 0x00004c9c <-[SSExcesAppController awakeFromNib]+901>: jne 0x4cd2 <-[SSExcesAppController awake Whoops. but feel free to use any hex editor at this point. 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. Let's fix our mistake. Too many results to make sense of.. in the actual binary file. We still need to make our change permanent. only one result: 001fc90: 0089 4424 04e8 4b24 0100 85c0 7409 8b45 .. HexFiend has a great GUI. Drunk Kernel programmers probably thought it'd be funny..... and not 09 to 34. (gdb) quit $ vim Exces This loads up the binary as ascii text...) Well. Search for "7409 8b45" instead and boom. is the address of block. or how many bytes to jump by.t. Incidentally. let's search for the first two bytes of our code to replace: /7409 Shit.. (gdb) continue Woot! Victory! We're in. Let's disassemble again to check if the change was done right. 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. The first part. As it currently stands..... and set it as such.

but implementing a bare minimum of security will weed out 99% of amateurs. break to [SSExcesAppController awakeFromNib] and disassemble. 5 of 5 1/19/11 1:30 PM . I am not a skilled hacker-yet with some very basic knowledge I tore this apart in no time.. Try to program the licensing mechanism for your app in pure C. yet would have made it enough of a pain for me that I would have given up. Visit his personal blog for more writing on the world of design. and doing a checksum of your binary-you can implement to make it a whole lot harder for your app to be cracked. Follow Gizmodo on Facebook Like 161K Get Gizmodo in your inbox: email address Join Archives About Advertising Legal Report an Issue FAQ Original material is licensed under a Creative Commons License permitting non-commercial sharing with attribution.com/5736871/how-to-crack-just-about-any-ma. using PT_DENY_ATTACH.. :%!xxd -r :wq And… We're done! To check our work.com. and bask in your leet glory. You can contact him at kenneth@ballenegger. software. Also read this older article of mine on three easy tips-stripping debug symbols. and life.How to Crack Just About Any Mac App (and How to Prevent It) http://gizmodo. How to Prevent This Objective-C makes it really easy to mess with an app's internals. Implementing the various easy tips above takes very little time. A truly skilled hacker will always find his way around your protection. Kenneth Ballenegger develops cool Mac and iPhone software. that will already make it harder for me to find my way around your binary. launch the app in gdb. $ gdb Exces (gdb) break [SSExcesAppController awakeFromNib] Breakpoint 1 at 0x4c90 (gdb) r (gdb) disas Admire our work: 0x00004c9c <-[SSExcesAppController awakeFromNib]+901>: jne 0x4ca7 <-[SSExcesAppController awake Quit gdb and relaunch the app from the Finder.