Cracking Software on OS X

Many years ago I was very interested in Hacking, Cracking and Computer viruses. Not because I wanted mess up peoples computers or had any programs that I needed to crack (Usually somebody else has already done it ;-)). Rather it was because it is a sort of esoteric knowledge. It proves a great challenge to hack, crack or write computer viruses and one can not readily pick up a book about the subject. Well that has changed somewhat the last couple of years.

I did manage to write a virus that hijacks an executable file back in High School after a lot of dabbling with assembly language programming. I was quite proud of myself then. It didn't actually do any harm. It only contained the code to duplicate (by piggy backing on executable files). When I got it working, I basically threw it in the dustbin and moved on to other things. I had proved I could do it and that was what mattered, it didn't have any practical application anyway.

I was still in DOS world at that time. I tried to learn how to crack, for basically the same reason: Prove that I could do it. Unfortunately I did not have any internet access at the time. Most didn't, so it was hard to come by information. Usually one would order floppy disks from Computer magazines. DOS was also horrible to work with since when you ran a program it basically took over your whole computer. So when the program I tried to crack switched screen mode from text mode to graphics I could not longer see what I was doing. To make a long story short, I gave up on hacking and cracking.

However several years later I would end up working for a software company were I got in charge of the copy protection for the software. We used software from third party like FLEXlm and Sentinel to protect our software. I got a lot of tips and advice from respective companies on how to code the software protection. They also gave information about exploits used by crackers.

The feeling that couldn't escape me though was that I really didn't know how well the protection work. It seemed like all theory to me. The only real way of knowing I thought was to try to crack our software myself. Unfortunately I was too pressed for time to learn anything about cracking.

But it was a sort of irony in this. The endeavor that I had just pursued for the challenge before had actually proved useful to know.

Which brings me to the topic of today. I came across a small piece of software that seemed very handy. There was one thing that bugged me though. I had to pay a lot more for it than I felt it was worth. The reason being that it was so simple I was convinced I could make the same program within a couple of days. So I somehow got into my head, why not crack it? Being such a utterly simple program how hard could it be?

Okay, so this is what got me thinking, but of course I am doing this for the challenge not to save a few euros (I will make my own version of this program instead). And also because I think it is good to know about this sort of thing. I might work with copy and license protection again in the future.

Anyway it took me quite a lot more time than expected, but not more than two days. I had to spend a lot of time reading up about Assembly coding, file formats, find the right tools etc.

Having a little bit of knowledge about how these things were done on Windows and DOS too, I must say that I was surprised by how much easier it seemed to be to be able to crack on Mac OS X.

First of all the fact that the applications store all their resources and user interface in separate files that can easily be inspected made things a lot easier. E.g. I could use the free developer tool (provided by Apple) Interface Builder to inspect resource files for the user interface of the program. Here I could easily find out which methods got called when e.g. buttons or menu items were selected.

A lot of the simplicity of cracking OS X programs also stems from the fact the dynamic nature of Objective-C which is used to create most programs. I was suprised to find that using a tool called class-dump. I could output all the class definitions (as seen in a header file). Apples otool let me disassemble files or show the organization of the code and data segments.

Another surprise was that I could easily see the name of methods being called in the code when tracing through the assembly code using the GNU Debugger (gdb, supplied with Apple development tools). Before a method call is performed one of the CPU registers are set to point to the name of the method. This can easily be printed out as one steps through a program using gdb. phrack.org proved to be a valuable source to learn about cracking.

Anyway I am digressing, I will write a post on my other blog about how one does cracking more in detail. The end of this story is that I eventually managed to crack the program as follows:

1. I located the method that got called when the register button was clicked by using interface builder.
   
2. Then using gdb tracing through this method I found the method that was used to generate and compare serial numbers.
   
3. I put a breakpoint it this method at program start so that I could find out where it was called from when the program started by doing a backtrace.
   
4. Then I found the code that checked the returned result. I figured out what I needed to replace this code with and the generated the corresponding hex values for those changes.
   
5. Using HexEditor I patched the code changes into the program.
   
6. wholla it worked at first try!!
   

Shit what am I doing?! This stuff can't not make any sense to anybody. Well now I wrote it so I might as well post it. For those who care about a more detailed explanation on how the cracking was done, have a look at loadcode later.

Disclaimer: I write this with the intention that it might be useful to those of you who need to protect your software against cracking. And those who are just curious about how cracking works. I am not writing this for those of you who want to avoid paying for your software.