Reading iOS app binary files | Hacker News Reader

Reading iOS app binary files

blog.smartdec.net

62 pointsmsbenighted18 comments

Objective-C was the first language I used where I looked under the covers and tried to understand the machinery of the language, and its extremely dynamic nature makes it a great place to start to understand language runtimes.

It's so conceptually simple, and (aside from objc_msgSend) you can implement the whole thing in C. libobjc2 has (if I'm counting correctly) 23 .c files, and it includes things you can totally ignore as you're learning, like an ObjC garbage collection implementation that no one uses anymore.

The only tricky part is the message-sending routines, since they have to be written in assembly. But as long as you understand what they're doing (rather than how they're doing it), you don't even need to look at those if you don't want to.

> (aside from objc_msgSend) you can implement the whole thing in C

And if you're willing to impose some limitations (maximum number of arguments, no floating-point arguments or return value), it's quite easy to implement a "toy" version of objc_msgSend in pure C.

I remembered after writing this that there's an implementation[0] that boxes up method arguments, giving everything a signature of `void objc_msgSend(void self, SEL _cmd, void *_param)`.

[0]https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_meta...

Objective-C is two parts, a compiler and a runtime. Both are reasonably simple but there are many details that are important.

Check out Mike Ashes excellent blog about Objective-C, the runtime and many other things:

https://mikeash.com/pyblog/

> The only tricky part is the message-sending routines, since they have to be written in assembly

Why? (context: never touched Objective-C)

Disclaimer: I may be completely wrong, but I don't think OP is saying that while writing normal ObjC that you need to write the message passing in assembly. Instead, that you could recreate ObjC in regular C but you would have to use assembly to construct the message passing portion of the language.

Sure, but what's the property of ObjC-style message passing that makes it hard to implement in C?

Like when you implement coroutines/threads in your language runtime, you're going to implement the context switching part in assembly because you just don't have access to the relevant information (registers/stack/...) from portable C (aside from using setjmp/longjmp maybe).

It's really the functionality of a method taking an unspecified number of arguments and jumping directly to the implementation's function pointer. Though, now that you mention it, there's really no reason you need to do that.

You could have your own calling convention where arguments aren't passed in registers or on the stack, but are boxed into some container. That way every method's implementation function could have the same signature, taking a pointer to the receiver ("self"), the method name, a box of arguments, and a place to pass the return value back out:

    typedef void (*IMP)(id, SEL, struct context *, void **); // arguments are `self`, the method name (`const char *`), a pointer to a structure containing the arguments, and a place to put your return value

I know of at least one Objective-C runtime implementation that does this. It won't be nearly as efficient – you have to pack/unpack the arguments, it pushes a stack frame instead of just jumping to the implementation, etc. – but it would certainly be portable.

A parent comment says it's due to variable number of arguments.

I thought it was about speed, heh.

To be honest, it's probably both. The runtime gurus at Apple do a great job hand-optimizing objc_msgSend for each platform since it's such an important factor in the overall speed of an Objective-C program.

It's (if not mostly, these days) about speed, but it is also to retain the notion that Objective-C methods are just C functions with 2 extra parameters, `self` and `_cmd`.

But yes – when objc_msgSend is invoked tens of thousands of times/second, you'll write it in ASM to get the performance boost anyway. When you're a compiler or runtime engineer working in a language with as few opportunities for static optimization as Objective-C, you bet your ass you'll squeeze every drop possible from message dispatch.

objc_msgSend accepts a variable number of arguments, and it needs to forward those to the method implementation. This is not possible to do in pure C.

What about just forwarding the var_args variable?

You'd have to pass around a va_list everywhere and parse it at the call site. This adds overhead that you probably don't want to deal with, especially since objc_msgSend is probably the hottest code path in any Objective-C program.

"Therefore, except for the lost data on exact types of Objective-C objects in arguments, it’s possible to get the complete reconstruction of an interface."

That's more than I expected. Great work!

Well, you lose the return type as well. Generally in these cases the app is fired up in the debugger and stopped on one of these methods, then dynamically introspected to figure out what it is. Since all Objective-C objects carry around a representation of their class, it's possible for the runtime to provide this to us.

That is one of the key things which empowered the jailbreak/tweak community. It becomes quite simple to understand (as well as manipulate) interfaces between software components.

Another interesting resource is class-dump, which will do much of this work for you and give you a "header" from an Objective-C binary: http://stevenygard.com/projects/class-dump/

Reply on news.ycombinator.com