Thursday, February 16, 2006

The Dangers of Static initialization

As I have mentioned before C++ has a rich set of ways for you too shoot yourself in the foot. And that is what I did today. This time it was because of static initialization. For those familiar with C++, you should know that one can declear variables like this:
static MyClass myVariable;
I am writing a raytracer and this raytracer has a color class. For convenience I added some static variables for commonly used colors.
Color Color::Red(1.0f, 0.0f, 0.0f); Color Color::Green(0.0f, 1.0f, 0.0f); Color Color::Blue(0.0f, 0.0f, 1.0f);
In my code I have a singleton class, AppSettings used to access and store and access settings in the class. I used to create a default scene in my application, so a scene could be rendered when starting the app instead of having to read from file. This scene I was creating in constructor for my main window. For various reasons I decided to move the creation of the default scene to AppSettings. Now suddenly nothing was rendered anymore. I spent a lot of time figuring out what was wrong. Until it hit me that the AppSettings singleton was allocated statically. Using the debugger I discovered the problem: The AppSettings object was constructed before the static color objects. Since my static color objects were used to create the scene they were set to 0.0f, 0.0f, 0.0f when being used by AppSettings. It also occurred to me that I have had this problem before. But I had forgotten about the dangers of static initialization. So my own advice on this is. Avoid using static initialization for complex objects because you never know when the initialization code will actually be executed and in which sequence.

Tuesday, February 07, 2006

Cracking Software on OS X

You might be curious on how people actually do it, or you work with securing software and want to know what methods the other side use so you can better figure out how to protect you software. If so, read on.

I am by now means an expert in the area, but I recently did crack a piece of software to learn about it.

To learn about this I suggest you find a small shareware application or similar to practice on. They usually have copy protection that is weak enough to be cracked by a novice.

To be able to crack you need a number of different tools. Most of them will already be installed if you have installed Apple’s development tools.

  • Interface Builder. You will use this application to poke around in the user interface of the program you wish to crack.

  • otool. With this command line tool you can disassemble a file, or print
    out other useful information about the executable. For instance you can use it to find out where in memory your program will be loaded.

  • class-dump. Command line utility you have to download. It has some of the same functionality as otool, but allows you to see Objective-C class definitions as they normally appear in the header file.

  • gdb. This is our most important tool. The GNU Debugger. You will use it to trace through the program you wish to crack to find where int he code the copy protection resides

  • HexEditor. To be able to patch your changes into an executable you need an editor that can edit the raw data on a file.

Before you can learn and do cracking you have to know some basics first.

  • Objective-C. You do not need to be a wiz, but some basic knowledge of Objective-C is needed to crack a OS X program since most are written using it. At least most of the little shareware programs you find
  • Interface Builder. You should have basic knowledge about how to work with interface builder.
  • Assembly programming. Again no need to be great at it, or know PowerPC assembly. But you will need to get a reference over the instruction set. IBM also has a nice intro about PPC assembly.
  • Know about the Mac OS X binary application interface (ABI). This you can read about in the Apple developer documentation. Info about the format of OS X executable can be found here and here.
  • Most important though is to make yourself familiar with calling conventions for functions on OS X. This will tell you what the different registers are typically used for, which helps reading and understanding assembly code.

GDB crash course
To run a program through the gdb debugger. write:
The program has now been loaded into memory.

Commands in GDB
gdb has a lot of commands and they all have long descriptive names. You can get help about a command by writing help commandname. However to save you typing, gdb allows you to write abbrivations for the names. You can write the first letter and gdb will choose the first command that match these letters. E.g. instead of writing print you can write p.

A lot of the commands will take a line number, function name, or address in memory as argument. Usually you just write the function name as it is. gdb supports command completion with tab if you don’t remember exact name. Line number can also be written directly. If you write an address you have to prefix it with *. Example *0x00fbc.

Useful commands:

  • run Starts running the loaded program

  • info fun Gets information about a given function. Address it is located at etc.

  • info sym Dumps information about which segment and function the address or symbol is in. Example:
    | (gdb) info sym 0x50fd0 | [StateController validState] in section LC_SEGMENT.__TEXT.__text
    Says that address 0×50fd0 is in segment __TEXT and section __text.

  • break Set a breakpoint at given function, line number or address.Short hand b

  • rbreak Set breakpoint at all functions with matching regular expression

  • delete Delete all breakpoints or breakpoint given by an index number

  • disassemble Disassemble code in current function

  • backtrace Show a stack backtrace of all functions that were called up to current function.

  • stepi Step one instruction at a time in code. Short hand si

  • where Print out current location in code. Where the program counter is.

  • print Print the value of a memory location, expression or register. Short hand p

  • po Interpret expression as the address of a Objective-C object and print out result one would get from asString. This is used to e.g. print Objective-C strings. Since print does not allow you to do that.

  • x Examine memory by giving and address or register.

  • disp Set expression to display each time program is stopped. For instance after each break or step instruction. Use it to display registers or memory you want to follow the changes in.

You can look up more detailed explanation of each command in the gdb online help. One thing that is useful to know though is that most command that give information about memory or registers let you choose format. E.g. x/x *0x00fb dumps content of address 0x00fb as hexadecimal number. x/s *0x00fb dumps contents as a c string.

Supported format types:

  • o octal
  • x hex
  • d decimal
  • u unsigned
  • t binary
  • a address
  • i instruction. Lets you interpret location in memory as PowerPC assembly instructions

  • o octal
  • c char
  • s string
  • T OSType

Showing contenst of registers:
The PowerPC CPU has a lot of register. The most used general purpose registers are numbered from 0 to 31. To show contents of register you specify a register by writing $ and then its name. E.g. $r1 denotes the second general purpose register. $pc is the program counter.

info register $r3 Dumps contents of register 3 and contents of memory it points to.
p $r3 Dump contents of memory pointed to by register 3.
x/x $r3 Dump contents of memory pointed to by register 3. as hexadecimal format.

Setting value of register:
You can set the value of a register using set command. E.g. set $r3=0x44

As with gdb you have to specify the path to the executable. E.g. otool -l otool has several options, you can read about them all by writing man otool in However there are a few options that are of most use to us.

  • -l Display load commands. This will give you information about where the different segments in the code get loaded into memory. And at which offset in your executable this segment can be found. E.g. if you look at the output you will see e.g.:
    Section sectname __text segname __TEXT addr 0x00002884 size 0x0009149c offset 6276 align 2^2 (4) reloff 0 nreloc 0 flags 0x80000400 reserved1 0 reserved2 0
    This tells us that this section can be found at offset (decimal) 6276 in executable. When this program is loaded into memory that section is placed at address (in hex) 0×00002884.

  • -tVv Disassembles the give executable and dumps to standard output.

This is easy to use just type class-dump to dump out definition of Objective-C classes in executable. When you download the file though it doesn’t come with an installer so you need to put it in your search path. E.g. I copied it directly to /usr/bin but you have to be root user to do that. So do a sudo cp class-dump /usr/bin e.g.

Lets get started
First thing to do is to go into the application bundle by right clicking and select Show Package Contents. Then you navigate to e.g Contens/Resources/English.lproj. Here there will be .nib files for the user interface. I opened MainMenu.nib. Here I found the registration sheet. I selected the register… button. Pressing shift+apple+i brings up the inspector panel. Here I looked at the target attribute. It shows which method the button click is connected to. Say it is called registerAction: and exist in the AppController. Try looking for something similar. Then you will have a starting point to start looking for the registration code.

An alternative is to use class-dump on the executable and search for method names called something with register, serial number etc or a class nammed RegHandler, Reg or something similar. E.g. class-dump executable | grep register.

Now that we found a method to inspect, load the executable in gdb. Type
break registerA and hit tab to complete our method. Then we have set a break point. Type run and out application should start running and then stop executing when it reaches our breakpoint.

When you trace through the code using stepi you will often see lines like this:
00010070 bl 0x12e10 ; symbol stub for: _objc_msgSend

What this is a dispatching of a message to an Objective-C object. This is how methods are called in Objective-C. r3 contains pointer to object that will receive message. You can find out what kind of object it is by typing po $r3, this will give a description of object. If object is a NSString it will display the string. r4 contains the message selector. This basically says which method to call. The good thing about this is that the message selector also happens to be a pointer to the c string name of the method. So by typing x/s $r4 you can find out what the name is of the objective-c method being called. r5, r6.. contains the first, second… arguments of the method call. The result of the method call is returned in r3.

r1 and r30 typically points to the start of the stack. So stw and lwz using these registers usually access local variables in the method.

How copy protection works
Copy protection can work in many ways. But the way it worked in my case is that I register the product with a name. I then get back a serial number for that registration name from the application maker. So say I register the application on “Erik” then there will be a unique serial number associated with that name.

When the program loads it reads my registered name from a file and then performs a calculation on it. This will produce a serial number or seed that is compared with the serial number I have put into my application.

What I managed to do was to eventually locate the method that did generation of serial number or seed. I then put a break at that method and rerun the application. Then I did a backtrace to find out which method called the serial number generator at startup.

From there on I was able to find the place where the serial number method was called and the code that compared the results afterwards.

What the code did was doing a comparison with a fixed number against the returned seed (the registered code and provided serial number are used together to produce some unique seed numbers).

In the debugger I used set to set the registered that were compared to the exact same number they were compared against. Then I typed continue to continue execution of code. The program now ran as registered. So it worked.

The last step to do when you have found out how to circumvent the copy protection is to change the executable (patch it). This you can do with HexEdit. The problem is to find out where in the file to make changes.

There are a number of things that are handy to know when doing this:

  • Since PowerPC is a RISC processor every instruction has the same length, which is 32 bits (4 bytes). Thus you can easily calculate the number of bytes a chunk of code takes. Just multiply number of instructions with 4. This also means you can easily jump over an instruction when tracing by writing jump *($pc+4)
  • As described before you can use otool -l to get information about code or data segments. Using this information you can find the location of an address in memory in the file as follows: location_in_file = location_in_memory - segment_address - segment_offset

So to find the location in the executable to change, you use info sym as mentioned before to figure out in which segment and section it is in. Then use otool -l to find the coresponding segment and section. Then read of the offset and address to calculate location of code in the executable.

To find out what hex codes corresponds to instructions you can write a simple assembly program as below. You can just fill in the instructions you need the hex codes for.
.text .globl _main _main: li r0,3241 stw r0,84(r30) lwz r0,84(r30)

Name the file with the filename extension .s. The file can then be compiled with e.g.: gcc newfunc.s -o temp if your file is named newfunc.s.

You can now load your app into gdb and look at the hex code for your application by writing x/24xb main. Which will list the 24 first bytes starting from main as hex values. 24 bytes corresponds to 24/4 = 6 instructions.

If you have any questions or comments please let me know. I will update this post later.

Here you can find more information:
PowerPC cracking with GDB

Saturday, February 04, 2006

Object Oriented programming in C

Object Oriented programming in C has been covered by many other before and actually whole frameworks are based on it. E.g. the Gtk (API on Gnome) and Core Foundation (API on OS X). So I am not going to show how all aspects of Object Oriented Programming (OOP) can be done. Just a few to demonstrate that it is in fact possible to do OOP in C. Perhaps then it will be clearer what the benefits of OOP is and that it is more a matter of style and a way of thinking than language syntax. Of course C++ and Java wasn't created for no reason. They have syntax that assist one in thinking and designing programs around Object Oriented (OO) principles. But that is all they do, assist. They do not magically make your program OO. Procedural example To understand the benfits of OOP lets take an example of one piece of code written in a procedural way, and then later in a OOP way. Our task is simple. We want to display a button on the screen that the user can click. When he/she clicks the button the program exits. We here assume we have the needed functions and skip initialing graphics hardware etc.
void draw_box(int x, int y, int width, int height); void draw_string(int x, int y, char *text); int is_mouse_button_down(int* x, int* y); int is_inside(int x, int y, int x1, int y2, int width, int height); int main (int argc, char const* argv[]) { draw_box(10, 10, 60, 30); draw_string(12, 12, "Quit"); int done = 0; while (!done) { int x, y; if (!is_mouse_button_down(x, y)) continue; if (is_inside(x, y, 10, 10, 60, 30)) done = 1; } return 0; }
We assume here that the functions listed above main() exists and do as their name implies. The simple program just draws a box that represent our button on screen and then draws a string on top of that so the button gets a label/caption. It is obvious that if we want to create more than one button we it is tedious to keep passing almost to same coordinates to draw the string on the button. So we create a new function draw_button(), which gives us the following code:
int main (int argc, char const* argv[]) { draw_button(10, 10, 30, 60, "Quit"); draw_button(50, 10, 30, 60, "Button1"); int done = 0; while (!done) { int x, y; if (!is_mouse_button_down(x, y)) continue; if (is_inside(x, y, 10, 10, 60, 30)) done = 1; if (is_inside(x, y, 50, 10, 60, 30)) printf("Clicked Button1"); } return 0; }
However let us say that each time one clicks Button1 we want it to move 5 pixels to down and to the right. We can change as follows:
int main (int argc, char const* argv[]) { int bx = 50, by = 10; draw_button(10, 10, 30, 60, "Quit"); draw_button(bx, by, 30, 60, "Button1"); int done = 0; while (!done) { int x, y; if (!is_mouse_button_down(x, y)) continue; if (is_inside(x, y, 10, 10, 60, 30)) done = 1; if (is_inside(x, y, bx, by, 60, 30)) { bx += 5; by += 5; button_draw(bx, by 60, 30, "Button1"); printf("Clicked Button1"); } } return 0; }
Now there is a number of problems with this code.
  1. There is no forced relationship between the drawing of the button and checking for clicks in it. It is possible to change drawing position of button and forget to update the mouse code check code as well.
  2. If we start making more buttons, say 20 more buttons, which each will move in different direction when clicked, it becomes a nightmare to keep track of where each button is.
Object Oriented Approach What needs to be done is instead of thinking of the problem as that of actions. That is what needs to be drawn, where etc. One should focus on the button as an entity or unit in the program. That is we should move to a more data centric way of thinking. Instead of thinking about drawing, checking for mouse clicks, etc, we think about creating, placing and moving button objects.
typedef struct { int x, y; int width, height; char *caption; } Button; Button* button_create(int x, int y, int width, int height) { Button* b = malloc(sizeof(Button)); b.x = x; b.y = y; b.width = width; b.height = height; button_draw(b); } void button_draw(Button* this) { draw_button(this->x, this->y, this->width, this->height, this->caption); } int button_is_inside(Button* this, x, y) { return is_inside(x, y, this->x, this->y, this->width, this->height); } void button_move(Button* this, int dx, int dy) { this->x += dx; this->y += dy; button_draw(this); } int main (int argc, char const* argv[]) { Button* quit = button_create(10, 10, 60, 20, "Quit"); Button* b1 = button_create(50, 10, 60, 20, "Button1"); int done = 0; while (!done) { int x, y; if (!is_mouse_button_down(x, y)) continue; if (button_is_inside(quit, x, y)) done = 1; if (button_is_inside(b1, x, y)) { button_move(5, 5) printf("Clicked Button1"); } } return 0; }
As one can see, we can now easily create lots of buttons and move them around without loosing track. But this is not all there is to OOP. So far I have made it look like it is just about collecting all variables in a struct so it is easier to see which variables that belong to each other. To show another important aspect of OOP I will give another code example. Here we are creating an Array object. The point of this object is that unlike regular C arrays it keeps track of its size, so we can query it in the rest of the program.
typedef struct { int *data; int size; } Array; Array* array_create(int size) { int* a = malloc(size*sizeof(int)); Array* array = malloc(sizeof(Array)); array->data = a; array->size = size; } int main (int argc, char const* argv[]) { Array* a = array_create(10); /* Fill array with values */ for (int i=0; a->size; i++) { a->data[i] = i; } return 0; }
Now this is all fine. But lets consider that we want to iterate over the whole array using pointers. So we decide that in order to do this it would be better to change the data structure for the Array. Instead of storing size of array we will store a pointer to the end of the array. So we change the data structure to the following:
typedef struct { int *begin; int *end; } Array;
Except there is one problem with this. Suddenly our code in main() is broken. We have to change a->size to a->end - a->begin. That is of course quick for us to do in this example. But what if we had written 10000 lines of code and iterated over the array loads of places? We would have to go through all that source code and made changes! Data encapsulation Data encapsulation is the solution to this problem. And this is one of the cornerstones of OOP. Instead of letting users of our Array object access its data directly we hide the internal representation of the object by requiring the users of it to access its properties through function calls. The code below shows this approach:
Array* array_create(int size) { int* a = malloc((size+1)*sizeof(int)); Array* array = malloc(sizeof(Array)); array->begin = a; array->end = a+size; } int array_size(Array* this) { return this->end - this->begin; } int* array_begin(Array* this) { return this->begin; } int* array_end(Array* this) { return this->end; } void array_set_at(Array* this, int index, int value) { this->begin[index] = value; } int main (int argc, char const* argv[]) { Array* a = array_create(10); /* Fill array with values */ for (int i=0; array_size(a); i++) { array_set_at(a, i, i); } /* Print values to screen */ for (int* it = array_begin(a); it != array_end(a); it++) { printf("%d", *it); } return 0; }
Inheritance Another important aspect of OOP in inheritance. This is a mechanism of style of programming that allows one to reuse a lot of code. Of course the code examples I show here are rather small so they don't show fully how much code there is to save having to rewrite. But it doesn't require too much imagination to see that this can be a big benefit when writing larger programs. To illustrate the usage of inheritance I will use geometric primitives. E.g. a point has a location is space. We can imagine functions to move the point in space relative to current position or set it at an absolute position.
typedef struct { int x, y; } Point; Point* point_alloc() { return malloc(sizeof(Point)); } Point* point_init(Point* this, int x, int y) { this->x = x; this->y = y; } void point_move(Point* this, int dx, int dy) { this->x += dx; this->y += dy; } float point_distance_to_origo(Point* this) { return sqrt(this->x*this->x + this->y*this->y); } int main (int argc, char const* argv[]) { Point* p = point_init(point_alloc(), 10, 10); printf("Distance to origo: %f", point_distance_to_origo(p)); return 0; }
Now we want to define a Circle object but we do not want to have to rewrite the code for moving the center of the circle since it is basically the same as moving a point. How can we reuse the point_move() function with Circle? All we need to do is to make it look like for the point_move() function as if it is dealing with a Point data structure as its first argument. This is actually not as hard as is seems:
typedef struct { Point position; int radius } Circle;
If we have a pointer to a circle structure we can now access the x and y coordinates like this:
Circle *c; int x = c->position->x;
However this is not very interesting for us since it does not allow us to treat a Circle as a point. What is interesting is that we can do the following:
Circle *c; Point* p = (Point*)c; int x = p->x;
How is this possible!? The reason why this works has to do with how C deals with structs. When you define a struct, the C compiler will store offset values for each variable in the struct. Here is how it works. When you write int x = p->x the C compiler will compile this into machine code that takes the start address of the struct pointed to by p and add a offset value representing the x to this address. This will create a new address which is used to locate the x member variable. Addresses are typically given on int boundaries (32 bit). So in the case of the Point data structure. Let us say that p is located in memory location 11. Then since x is the first variable defined it is located at offest 0, which means it is at 11 too. y on the other hand is the second variable so it has offset 1. Meaning it is on location 11+1=12. p->y would thus be converted to address 12. Bottom line is that offsets are given relative to top of struct definition. Thus if we put Point at the top of the Circle definition, the offset values x and y will still be valid for the Circle struct. Of course the C compiler doesn't know that, so we must trick it by doing a cast to Point*. Otherwise it will complain that Circle does not have any members named x and y. So to demonstrate inheritance, here is a short program again:
Circle* circle_alloc() { return malloc(sizeof(Circle)); } Circle* circle_init(Circle* this, int x, int y, int radius) { point_init((Point*)this, x, y); this->radius = radius; } float circle_area(Circle* this) { return this->radius*this->radius*M_PI; } int main (int argc, char const* argv[]) { Cricle* c = cricle_init(circle_alloc(), 10, 10, 5); printf("Distance to origo: %f", point_distance_to_origo((Point*)c)); printf("Area of circle: %f", circle_area(c)); return 0; }
There is of course a lot more to OOP, but several other people on the web have written much more extensive explanations, even books on doing OOP in C. My intention here was just to give an introduction. So you might wonder what is the point of using a dedicated OOP language like C++ or Java? First of all is the syntax sugar. Instead of writing point_move(p, x, y) you can write p->move(x, y) in C++. C++ makes p the first argument to move but by putting it in front it makes it clear that p is the object of focus. The other important aspect is that one is not required to prefix the function names with say point_ to avoid clutter in the namespace. C++ makes sure that each function called move() is associated with a type. And then there is the case of e.g. polymorphism that would just get very ugly looking in C. I do of course not advice anybody to do OO in C. There is no need for that when we have so many nice OOP language to choose from. Doing OOP in C however does make it clear that OOP is a paradigm and not a language feature. To look at it from the other side: One could choose to program procedure oriented in Java or C++ for instance by:
  1. Declaring member variables public and not use accessor methods (thus breaking the OO principle of data encapsulation and abstraction).
  2. One could use switch case statements instead of polymorphism.
  3. Don't do code reuse by using inheritance. Make all methods static
Personally I believe OOP thinking is best understood by either learning it through a procedure oriented language or a OOP language that takes OO to the extreme like Smalltalk. E.g. Smalltalk just force the user to think more about OO than C++ or Java does. Java and C++ lets programmers easily slip into procedure oriented ways of thinking. And I believe the reason for this is that both C++ and Java are procedure oriented at the low level. Instances of primitive types like int, float and char are not objects. if, while and for statements have procedure like semantics. And these are the statements and objects the newbie programmers are exposed to first, thus locking them into a procedure oriented way of thinking early on.

Teaching Object Oriented programming

Today I decided I want to talk about one of the topics that constantly bug me: Object Oriented programming and people's conception of what it is about. Basically what I wish is that Universities and tech school started teaching Object Oriented programming in a different way. Why? Because I believe that most students today totally miss the point about Object Oriented programming. Even at Master level they still don't understand what it is about. And I blame the universities for this. Take my University College. I think it is the prime example of how to teach students Object Oriented programming in such a way that they just don't get it. I know that they didn't get it because I was the TA in the programming class and I helped the students with their programming assignments and corrected their hand inns. The first half of the year the University College taught C and the second half they taught Java. In the C classes they learned procedure oriented programming. In the Java classes they learned object oriented programming and GUI programming. Or so was the intention at least. Most of the hand ins I got were still procedure oriented. And that is my issue with Universities teaching object oriented programming to students using object oriented languages like Java. Students think that because they use an object oriented language their program automatically becomes object oriented! I remember having a discussion this year with a fellow student at the University of Utrecht. Unlike me he had been taught Java as the main programming language in University. My main programming language was C++. Now he was forced to learn C++, because of the project he was doing. He was going on about how much more powerful and modern java was than C++. I think it goes without saying that I think that is rubbish, but I am going to address that some other time. One thing he complained about in C++ was that it was not fully object oriented. As if being fully object oriented is some sort of quality stamp. The reason he gave was that not everything was classes. One could write functions that were not part of a class. Very sure of himself he said that in Java everything was object oriented. I said no, and that one can very well write programs in Java that are not object oriented. He protested loudly saying that was simply not possible, since everything had to belong to a class, there was no way you could write a program that was not object oriented. Which made it clear to me once again that even at Master level in Computer Science students don't understand that object oriented programming and procedure oriented programming are not programming language features but paradigms. Some languages have special support for certain paradigms but they do not force you to use that paradigm. All Java does by forcing you to declare your functions as methods in a class is to force your methods to reside in a namespace. It does not force you to follow the object oriented paradigm. To deal with these broad misconceptions I suggest that one starts teaching object oriented programming in a procedure oriented language like C. So that students will see clearly that Object Oriented programming is not a language feature but a style of programming and a way of thinking about programming problems. Then after students are familiar with object oriented programming in a procedure oriented language they should be taught a object oriented language so that it is made clear that these languages are merely there to make it easier to do object oriented programming because they have special language constructs that support the paradigm, not because they force you to think object oriented. Now you might already have been shaking your head for a long time, wondering what I am talking about. What is this guy talking about you might think. Object oriented programming in C!? That is not possible! Well I used to think that myself. Not at least owing to the fact that I wasn't taught what object oriented programming is properly at University either. But in the next post I will show how object oriented programming can be done in C.