Reading iOS app binary files
blog.smartdec.net
Reading iOS app binary files
1–10 of 20 posts
Re: Reading iOS app binary files
#2[deleted]
Re: Reading iOS app binary files
#3"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!
Re: Reading iOS app binary files
#4Objective-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.
Re: Reading iOS app binary files
#5Another 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/
Re: Reading iOS app binary files
#6"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.
Re: Reading iOS app binary files
#7"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!
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.
Re: Reading iOS app binary files
#8Objective-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 i…
> The only tricky part is the message-sending routines, since they have to be written in assembly
Why? (context: never touched Objective-C)
Re: Reading iOS app binary files
#9Objective-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 i…
> (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.
Re: Reading iOS app binary files
#10Objective-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 i…
> 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.