References

Drivers on macOS | by Karol Mazurek - Freedium

Introduction to IOKit and BSD drivers on macOS

freedium.cfd

Intro

This is meant to get you up and running and cracking Apples ASAP

We ❤️ Symbols 🤑

The first thing you need to crack iPhones at the OS level is a kernel cache. Most of the time these are going to be stripped of symbols, but that will be covered in the next post. For this part, I will only go over kernel caches that still have their symbols, as it will make it a bit easier. I am writing this as I complete Xintra’s iOS hacking course so we can use the same kernel cache used in the course to explain some of the concepts. Here is the kernel cache you can use:

This is going to download a .ipsw file. This is the same as a zip file, so you can rename the extension and then unzip it. Inside you should find some kernelcache.r*.iphone* files. Open up the one with kernelcache.research* into your disassembler of choice, I am using Binary Ninja 🥷🏾. Once it finishes analysis and all dat, you should have a list of nicely named symbols.

Attack Surface

Apple uses the following class:

class IOUserClient : IOService

to allow user space applications to interact with lower level code and hardware. This is done via the class method ExternalMethod:

virtual kern_return_t ExternalMethod(
	uint64_t selector,
	IOUserClientMethodArguments *arguments,
	const IOUserClientMethodDispatch *dispatch,
	OSObject *target,
	void *reference);

The selector parameter is an index to what I believe is a vtable, and this allows it to select which lower level function to call. In case you are not familiar with C++, virtual functions are similar to interfaces in things like Java. You can define a virtual method, and then the class that inherits it the parent class will override it with their own definition. Here’s a good stack overflow post that details why they exist:

Why do we need virtual functions in C++?

From what I've read, virtual functions are functions in the base class that you can override in its derived classes. But earlier, when learning about basic inheritance, I was able to override base

stackoverflow.com

So different objects in our kernel cache will have different ways that they implement ExternalMethod , but all have the end goal of allowing a user space application of interacting with the iOS kernel. Implementations that are not done right will introduce vulnerabilities for us to exploit. Now with that being said, it should be somewhat clear at this point that classes derived from IOUserClient that have the ExternalMethod implemented will be our targets. Perform the search:

Exploring Functions

For this next part, we will be using the vulnerability from this post to understand how to explore these functions:

So now lets assume, that we performed our little search, and for whatever reason we decided to begin by looking at IOMobileFramebufferUserClient::ExternalMethod.

Now the important thing to note here are the references to g_MethodDescs. These correspond to parameter 4, which should be a pointer to an OSObject object. If we click on the variable, it takes us to what looks like a list of function pointers to methods within the IOMobileFramebufferUserClient class:

Now, this decompilation doesn’t entirely make sense based on Apple’s documentation. Mainly because this 4th parameter more closely resembles the dispatchArray from dispatchExternalMethod:

Once I figure out why this is, I will come back and edit this page, but we can deduce enough to continue. We can also use deduction to assume that this class only has 0x53 (83) methods available for us to call from userspace. Anyways, from the post linked above we know the vulnerable function is at index 83, so lets walk through these function pointers and figure out which one it is (the last one duh). The post linked above picks up from here about the vulnerability and how to exploit it, so I won’t go over that.

Conclusion

Now you should have enough knowledge to find a symbolized kernel cache and:

1. Figure out which classes can be interacted with
2. Figure out which methods for these classes you are allowed to interact with
3. Begin reverse engineering the functions to look for vulnerabilities.