Inferior call to class_getName() in gdb – Part 1: crash

Over the last couple of days, I got the chance to dive into iOS again and decided to do some basic things I could use at a later time for an app analysis. What I wanted to do was simply to log class and method names called by apps in runtime. However, as always, I was confronted with an unexpected problem. Although I was not able to analyze/fix this problem thoroughly, I decided to post my findings, as I should get back to my normal work and I know I will not be able to remember many things regarding this when I revisit the iOS world.

Basic steps to log class and method names

In Objective-C, all method calls go to objc_msgSend().

This function has two parameters. The first one will be used to get a class name and the second one will be used for a method name.

Let’s set a breakpoint at objc_msgSend() in gdb. If an app under test stops at objc_msgSend(), call class_getName() to get a class name, and call printf() to output both the class name and the method name the app is calling.

See the following example with the app, yelp.

This seems to work. Let’s try other app, Safari.

This time, it crashes. Let’s confirm that we can get a method name using the second parameter in order to narrow down the possible causes of this crash.

Ok, now we know where to start. “call class_getName()” is our target. Exit gdb and load Safari again.

Crash analysis

Backtrace with the command, “bt”.

Please note that the app has not crashed yet. We still need to find out where it crashes.

Step into until the app crashes.

The app crashes at the address, 0x39b36914, at which we need to set a breakpoint. Exit gdb and load Safari.

Check the registers.

Ok, we found the reason why it crashes when the return opcode, “bx lr” is executed. Let’s see if lr is 0, at the entry point of class_getName().

You can confirm lr is 0 when class_getName() is called. If we check more on stack, we can find the previous stack frame (frame 1 which is from gdb) has 0 for pc and lr. See the following two captured shots.

It seems the inferior call of gdb has somehow set the value of zero for lr. Let the app crash again after turning on “debug inferior” and “debug infrun” to see what gdb says.

gdb shows some of its symbols such as “proceed()”, “resume()”, “macosx_child_resume()”. These should be some good starting points to find out the root cause.

Continued on Part 2

Testing environment

• OS: iOS 6.01
  
• Device: jailbroken iPod 4G
  
• tools: gdb
  

Reference

Hacking and securing iOS Applications – O’REILLY