Biglopedia | Appel | Intel | Google | Microsoft | Web

Thought it might be interesting for people to take a peek at how we work.

As I stated in the previous blog post, it's necessary for us to figure out the WM8991 audio codec before we can call from the baseband (or listen to music). This is an interesting task because while there are datasheets for the WM8991 codec, and a Linux driver for it, those cannot be used immediately since it doesn't tell us where the inputs and outputs of the chip are connected to, and what protocol and clock divider settings the iPhone uses to talk to the chip (and must be configured on the chip). Those things are purely implementation specific.

In order to extract those settings, we need to be able to see those settings while the iPhone OS kernel is up and running and sound is playing. The chip does not use MMIO, so the register settings cannot be directly peeked at through /dev/kmem... but we're on the right track. Instead, I2C is used to communicate with the codec for setting those registers. It turns out that since some Wolfson codecs do not allow reading from the codec registers (only writing), the operating system has to "remember" what values registers are currently set to. That is, they are cached by operating system?

Where are they cached? Well, a quick look at the disassembly shows us some code that does the following (in pseudo-C)


if register > *(this + 0xA0)
return 0

return *((uint16_t*)(*(this + 0xA8) + register * 2))


Basically, we see that the class member at offset 0xA0 contains the total number of registers accessible on the Wolfson codec, while member 0xA8 is a pointer to an array of 16-bit values that represent the current values of those registers!

Now we seem to be home free... except for the fact that IO Kit C++ objects are dynamically allocated on the heap at runtime and there is no way to tell using static analysis where they will be during a particular boot of an operating system. How will we find the location of this C++ class (AppleWM8991Audio) so that we can peek at those values?

The answer is that every object in the IOKit subsystem is anchored to the IORegistry tree. You can actually take a peek at the tree from userland with the ioreg -l command. Every single node you see corresponds to a C++ object. However, the trouble is that there is no userland call to extract the in-kernel addresses of those objects... and that's what we need to be able to use /dev/kmem to peek at the right places.

Fortunately, the root of the IORegistry is pointed to by a constant, and it is possible to traverse the IORegistry manually from the root (provided you know the layout of all the C++ classes!). This is exactly what I wrote a utility called spelunk to perform: use /dev/kmem to manually traverse the IORegistry and find the in-memory instance, instance size, and vtable location of all of the objects in the IORegistry. Armed with this information, one can use dd and /dev/kmem to peek at the state of any of the objects inside kernel memory.