5 ms·

Reading iOS app binary files

62 points by msbenighted 9y ago

swolchok 9y ago
see also https://swolchok.github.io/objcperf/ https://swolchok.github.io/objcperf/
ericand 9y ago
"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!
- saagarjha 9y ago
  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.
- phoenix3200 9y ago
  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.
favorited 9y ago
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.
- hypervis0r 9y ago
  > The only tricky part is the message-sending routines, since they have to be written in assembly Why? (context: never touched Objective-C)
  - _red 9y ago
    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.
    - slrz 9y ago
      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).
      - exikyut 9y ago
        A parent comment says it's due to variable number of arguments. I thought it was about speed, heh.
        saagarjha 9y ago
        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.
        favorited 9y ago
        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.
saagarjha 9y ago
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/ http://stevenygard.com/projects/class-dump/

62 points by msbenighted 9y ago

see also https://swolchok.github.io/objcperf/ https://swolchok.github.io/objcperf/

"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!

saagarjha 9y ago
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.
phoenix3200 9y ago
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.

favorited 9y ago

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.

hypervis0r 9y ago
> The only tricky part is the message-sending routines, since they have to be written in assembly Why? (context: never touched Objective-C)
- _red 9y ago
  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.
  - slrz 9y ago
    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).
    - exikyut 9y ago
      A parent comment says it's due to variable number of arguments. I thought it was about speed, heh.
      - saagarjha 9y ago
        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.
      - favorited 9y ago
        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.

saagarjha 9y ago

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/ http://stevenygard.com/projects/class-dump/