I don’t know much about Objective-C and decided to get my learn on. Here are some discoveries I made.

Objective-C is dynamic. Objects and classes support some degree of introspection at runtime. Methods / messages are routed and dispatched. They are not hardcoded addresses as in C++.

Objective-C is message oriented. All those fancy Object Oriented / Message passing calls end up going through one of a few functions. When you compile

[self printMessageWithString:@"Hello World!"];

it is translated to something like

objc_msgSend(self,@selector(printMessageWithString:),@"Hello World!");

I borrowed those snippets from http://cocoasamurai.blogspot.com/2010/01/understanding-objective-c-runtime.html without permission.

This is good news. It means just about every OO operation in ObjC will pass through this function. Way to make hooking/tracing easy. I then asked Google if anyone else has been talking about this sort of thing. It looks like I am late to the game – http://www.dribin.org/dave/blog/archives/2006/04/22/tracing_objc/.

Specifically:

If you set the NSObjCMessageLoggingEnabled environment variable to “YES”, the Objective-C runtime will log all dispatched Objective-C messages to a file named /tmp/msgSends-.

You can even enable message logging from within a debugging session using:

(gdb) call (void)instrumentObjcMessageSends(YES)

It gets better. The Apple objc runtime also includes support for a custom logger. This might be useful logging the parameters of certain messages of interest.

I also found good general information on reversing objc here: http://culater.net/wiki/moin.cgi/CocoaReverseEngineering. New bits here are class-dump and FScript. The former will dump a header file close enough for use, the latter (through FScriptAnywhere) allows you to introspect and modify apps at runtime.

*** This is a Security Bloggers Network syndicated blog from Armchair Stratosphere authored by Jason. Read the original post at: http://maliciousattacker.blogspot.com/2011/02/tracing-objective-c.html