Forked from 0x36 on github who then rewrote the ida_kernelcache python framework. Sadly 0x36 doesn't seem to have push updates to the project and it took me a very long time to figure out why this wasn't working with ghidra i finally found the ghidra api html source and saw that in 10.1 some of the functions used was either entirely removed or just plain depricated.

Works as of Ghidra 10.1!

Firstly Download the iometa-master.zip and unzip it. Open your terminal inside of the unzipped folder and run the command "make". after that drag and drop the contents of everything else in this repository inside this iometa folder. After that decompress the Kernelache by dragging a raw kernelcache in a hex viewer or either ghidra itself and find the magic of the macho header which should be either 0xfeedface note the offset and decompress it by running ./lzssdec -o "offset" < kernel > kernel.decrypted load the decrypted kernelcache into ghidra

ghidra_kernelcache: a Ghidra iOS kernelcache framework for reverse engineering

This framework is the end product of my experience in reverse engineering iOS kernelcache,I do manually look for vulnerabilities in the kernel and have automated most of the things I really wanted to see in Ghidra to speed up the process of reversing, and this proven to be effective and saves a lot of time. The framework works on iOS 12/13/14 and has been made to the public with the intention to help people to start VR in iOS kernel without the struggle of preparing their own environment, as I believe, this framework ( including the toolset it provides and with some basic knowledge in IOKit) is sufficient to start dealing with the Kernelcache. Then proceed down to loader steps.

The whole framework is written in Python,and can be extended to build tools upon, it provides some basic APIs which you can use in almost any project and save time from reading the verbose manual, you can just read the code in utils/ directory.

Ghidra is good when it comes to analyzing the kernelcache, but like other RE tools, it needs some manual work, ghidra_kernelcache provides a good entry point to fix things at the start and even while doing reverse engineering thus providing a good-looking decompiler output.

There is a similar project done by @_bazad in IDAPro called ida_kernelcache which provides a good entry point for researchers wanting to work with the kernel image in IDA, my framework looks a bit similar to Brandon's work, and goes beyond by providing much more features to make the process of working with the kernelcache a lot easier.

Here are some of the features provided by the framework :

• iOS kernelcache symbolication.
• Resolving virtual call references.
• Auto fixing external method array for both ::externalMethod() and ::getTargetAndMethodForIndex().
• Applying namespaces to class methods.
• Symbol name and type propagation over function arguments.
• Applying function signatures for known kernel functions.
• Import old structures and classes from old project to a new project.
• Auto type-casting safeMetacast() return value to the appropriate class object type.

These features are made as a separated tools which can be executed either by key shortcuts or by clicking on their icons in the toolbar.

Installation

Clone the repository :

git clone https://github.com/0x36/ghidra_kernelcache.git $APATH

Go to Windows → Script Manager, click on script Directory , then add $APATH/ghidra_kernelcache to the directory path list. LOADER STEPS**** Go to Windows → Script Manager, in scripts listing, go to iOS→kernel category and check the plugins seen there, they will appear in GHIDRA Toolbar .

in logos/ directory, you can put you own logos for each tool.

iOS kernelcache symbolication

ghidra_kernelcache requires at the first stage iometa (made by @s1guza), a powerful tool providing C++ class information in the kernel binary, the great thing is that it works as a standalone binary, so the output can be imported to your favorite RE framework by just parsing it. My framework takes iometa's output and parses it to symbolicate and fix virtual tables.

Usage

After decompressing the kernel, run the following command :

$ iometa -n -A /tmp/kernel A10-legacy.txt > /tmp/kernel.txt
# if you want also to symbolicate using jtool2
$ jtool2 --analyze /tmp/kernel

Load the kernelcache in Ghidra, DO NOT USE BATCH import , load it as Mach-O image. After the Kernelcache being loaded and auto-analyzed, click on the icon shown in the toolbar or just press Meta-Shift-K, then put the full path of iometa output which is /tmp/kernel.txt in our case.

if you want to use jtool2 symbols, you can run jsymbol.py located iOS→kernel category as well.

Using APIs

Full API examples are in ghidra_kernelcache/kc.py

→ Here are some examples of manipulating class objects :

from utils.helpers import *
from utils.class import *
from utils.iometa import ParseIOMeta

ff = "/Users/mg/ghidra_ios/kernel.txt"
iom = ParseIOMeta(ff)
Obj = iom.getObjects()
kc = kernelCache(Obj)

# symbolicate the kernel 
kc.process_all_classes()

# symbolicate the classes under com.apple.iokit.IOSurface bundle
kc.process_classes_for_bundle("com.apple.iokit.IOSurface")

# symbolicate the classes under __kernel__ bundle
kc.process_classes_for_bundle("__kernel__")

# update symbolication, this will not override the class structure, it will only update the virtual table symbol map.
kc.update_classes()

# symbolicate one class: this will also automatically symbolicate all parent classes.
kc.process_class("IOGraphicsAccelerator2")

If you run the script against the whole kernelcache, it may take several minutes to finish, once finished, Ghidra will provide the following :

→ a new category has been added in Bookmark Filter called "iOS":

<img src="https://github.com/0x36/ghidra_kernelcache/blob/master/screenshots/image1.png" alt="image1" width="200"/>

→ IOKit class virtual tables are added to 'iOS' Bookmark for better and faster class vtable lookup, you can just look for a kext or a class by typing letters,word or kext bundle in the search bar.

<img src="https://github.com/0x36/ghidra_kernelcache/blob/master/screenshots/image2.png" alt="image2"/>

→ Fixing the virtual table : disassembles/compiles unknown code, fixes namespaces, re-symbolicates the class methods and applies function definition to each method.

<img src="https://github.com/0x36/ghidra_kernelcache/blob/master/screenshots/image3.png" alt="image3"/>

→ Creating class namespace and make class methods adhere to it:

<img src="https://github.com/0x36/ghidra_kernelcache/blob/master/screenshots/image4.png" alt="image4"/>

→ Creating class structure with the respect of class hierarchy :

<img src="https://github.com/0x36/ghidra_kernelcache/blob/master/screenshots/image5.png" alt="image5"/>

→ Creating class vtables, and each method has its own method definition for better decompilation output:

<img src="https://github.com/0x36/ghidra_kernelcache/blob/master/screenshots/image6.png" alt="image6"/>

Full implementation can be found in utils/class.py.

Here are some screenshots of before/after using the scripts to just give a clear picture :

<img src="https://github.com/0x36/ghidra_kernelcache/blob/master/screenshots/image7.png" alt="image7"/> <img src="https://github.com/0x36/ghidra_kernelcache/blob/master/screenshots/image8.png" alt="image8"/>

extra_refs.py: Fixing references

extra_refs.py is based on data flow analysis to find all virtual call methods and resolving their implementations automatically, it has the ability to recognize the source data type from the decompiler output and resolve all virtual call references, so the user is able to jump forward/backward directly to/from the implementation without manually looking for it.

The most useful feature provided by extra_refs.py is that it keeps the references updated on each execution, for example, let's say you've changed a variable data type to a class data type, extra_refs.py will automatically recognize the change, and will go recursively on all call sites to resolve their references, and it finishes only when the call site queue is empty.

There are other features provided by extra_refs.py like:

• It automatically identifies _ptmf2ptf() calls and resolves their call method for both offsets and full function address
• It identifies the namespace of an unresolved function name (functions which start with "FUN_"), and resolve it by putting the target function into its own namespace.

Implementation

You can find the implementation in utils/references.py, fix_extra_refs() parses the pcode operations and looks for CALLIND and CALL opcodes, then gets all involved varnodes on the operation, once a varnode definition is identified, it gets its HighVariable then identifies the class object type of that variable, if the type is unknown it ignores it,otherwise, it takes the class name, looks up its virtual call table,using the offset provided by the varnode, it gets the right virtual call and puts a reference on the call instruction.

Exposed API:

# The 'address' type is ghidra.program.model.address.