**Важное примечание**: Проект протестирован на Ghidra 10.1_PUBLIC и 10.2_DEV и не является обратно совместимым.

Перейдите в *`Windows → Script Manager`*, нажмите на *`script Directory`*, затем добавьте *`ghidra_kernelcache`* в список путей к каталогам.
Перейдите в *`Windows → Script Manager`*, в списке *scripts* перейдите в категорию *`iOS→kernel`* и отметьте плагины, которые там видны, они появятся на панели инструментов GHIDRA.

В каталоге [logos/](https://github.com/0x36/ghidra_kernelcache/tree/master/logos) вы можете разместить свои собственные логотипы для каждого инструмента.

## Символизация iOS kernelcache

`ghidra_kernelcache` на первом этапе требует [iometa](https://github.com/Siguza/iometa/) (создан [@s1guza](https://twitter.com/s1guza)), мощный инструмент, предоставляющий информацию о классах C++ в двоичном файле ядра. Замечательно то, что он работает как отдельный бинарный файл, поэтому вывод можно импортировать в вашу любимую среду обратной разработки, просто проанализировав его. Моя среда берет вывод iometa и анализирует его для символизации и исправления виртуальных таблиц.

### Использование
После распаковки ядра выполните следующие команды:```sh
$ iometa -n -A /tmp/kernel A10-legacy.txt > /tmp/kernel.txt
# if you want also to symbolicate using jtool2
$ jtool2 --analyze /tmp/kernel

Как видите, вы можете полностью или частично символизировать kernelcache, если была выбрана частичная символизация, `ghidra_kernelcache` автоматически построит все зависимости классов перед продолжением.
Если запустить скрипт для всего kernelcache (полная символизация), `ghidra_kernelcache` потратит несколько минут на анализ образа ядра.

После завершения Ghidra предоставит следующее:

→ В фильтр закладок добавлена новая категория под названием «iOS»: 

<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image1.png" alt="изображение1" width="200"/>
                    
                    
→ Виртуальные таблицы классов IOKit добавлены в закладку «iOS» для лучшего и более быстрого поиска виртуальных таблиц; вы можете просто искать kext или класс, вводя буквы, слова или пакет kext в строке поиска.

<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image2.png" alt="изображение2"/>


→ Исправление виртуальной таблицы: дизассемблирует/компилирует неизвестный код, исправляет пространства имён, повторно символизирует методы класса и применяет определение функции к каждому методу:

<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image3.png" alt="изображение3"/>

→ Создание пространств имён классов и помещение каждого метода в соответствующее пространство имён:

<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image4.png" alt="изображение4"/>

→ Создание структуры класса с учётом иерархии классов:

<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image5.png" alt="изображение5"/>

→ Создание vtable классов, и каждый метод имеет собственное определение метода для лучшего вывода декомпиляции: 

<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image6.png" alt="изображение6"/>

Полная реализация находится в [`utils/class.py`.](https://github.com/0x36/ghidra_kernelcache/blob/master/utils/class.py)

Вот несколько скриншотов до и после символизации с помощью `ghidra_kernelcache`:

<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image7.png" alt="изображение7"/>

<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image8.png" alt="изображение8"/>




## Символизация Kext в macOS
---
Поддержка macOS в `ghidra_kernelcache` предназначена как для kernelcache, так и для символизации отдельных KEXT для архитектур ARM64e и x86_64. 
**ВАЖНО:** На момент написания Ghidra не может обработать весь macOS kernelcache, но его можно загрузить в IDA для начального анализа, а затем импортировать базу данных (idb в xml) в Ghidra позже, но это выходит за рамки. Если вам удастся это сделать, `ghidra_kernelcache` позаботится обо всём остальном.

Необходимо выполнить несколько шагов перед символизацией любого расширения ядра macOS, так как основная цель `ghidra_kernelcache` — восстановить иерархию классов и управлять всеми структурами классов в единой базе данных; одно расширение ядра не удовлетворяет этим требованиям, что означает, что символизация отдельного KEXT требует символизации ядра и, возможно, других расширений ядра, от которых он зависит, поэтому здесь требуется некоторая дополнительная работа.
`ghidra_kernelcache` теперь предоставляет мощный способ символизировать расширения ядра, включая ядро, управляя и разделяя структуры классов и определения виртуальных методов через мощный *DataType Project Archive* от Ghidra.

### Шаги по символизации расширения ядра
- Создайте новую папку в вашем проекте Ghidra, затем загрузите ` /System/Library/Kernels/kernel.release.XXXXX` в эту папку и позвольте Ghidra проанализировать его.
- Создайте новый *Project Archive*: перейдите в `DataType Provider` → нажмите на стрелку в правом верхнем углу окна → `New Project Archive` → поместите его в только что созданную папку → дайте ему имя (например, macOS_12.1). 
- Теперь символизируйте ядро с помощью `ghidra_kernelcache`, процесс довольно похож на символизацию *kernelcache* для iOS.```bash
$ iometa -n -A /System/Library/Kernels/kernel.release.t8101 > /tmp/kernel.txt

- После завершения создаётся связь между архивом ядра и архивом `macOS_12.1`. Теперь щёлкните правой кнопкой мыши на `kernel.release.t8001` → `Commit DataTypes To` → `macOS_12.1`.
- Затем `Правый клик` → `Выбрать всё` → `Commit`.
- Сохраните архив проекта: `Правый клик` → `Save Archive`.
Мы только что создали архив проекта, который можно использовать во всех расширениях ядра.
Рассмотрим пример Kext `IOSurface` для Apple Silicon:```bash
$ lipo /System/Library/Extensions/IOSurface.kext/Contents/MacOS/IOSurface -thin arm64e -output /tmp/iosurface.arm64e
$ iometa -n -A /tmp/iosurface.arm64e > /tmp/iosurface.txt

**Важное замечание**: иногда `kc.process_kernel_kext()` завершается неудачей, потому что Ghidra не смогла деманглировать некоторые символы C++. Чтобы это исправить, откройте менеджер скриптов и запустите скрипт `DemangleAllScript.java`, затем  снова запустите  `kc.process_kernel_kext()`  снова.

### Пользовательские классы
Бывают случаи, когда некоторые классы C++ не могут быть символизированы `ghidra_kernelcache`  и `iometa`, поэтому была добавлена новая функция для обработки этого.
Реконструкция класса `Custom()` проходит по всем символам `::vtable` и проверяет, определен ли класс уже или нет; если нет, она автоматически создает структуру класса, определения функций для каждого идентифицированного метода класса, пространство имен и виртуальную таблицу для каждого  класса.

Создание пользовательских классов в данный момент поддерживается только в macOS.```bash
$ iometa -n -A /System/Library/Kernels/kernel.release.t8101 > /tmp/kernel.txt
$ iometa -n -A <kext_path> >> /tmp/kernel.txt

kc = Custom(Obj)

kc.process_all_classes()
kc.explore_pac()

## Miscellaneous scripts
---
### Importing KDK's Dwarf4 
Ghidra по какой-то причине не может загрузить соответствующую директорию `.dsym`, я написал небольшой скрипт для исправления этого. Его можно найти [здесь](https://github.com/0x36/ghidra_kernelcache/blob/master/dwarf4_fix.py).
**Usage** : Загрузите ядро из вашего пути KDK, дайте Ghidra завершить анализ, затем запустите `dwarf_fix.py`, он загрузит символы, и процесс может занять несколько минут.
<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image12.png" alt="image12"/>

### Resolving virtual method calls references 
`ghidra_kernelcache` предоставляет два способа разрешения виртуальных вызовов: `kernelCache.explore_pac` или `fix_extra_refs` 

**kernelCache.explore_pac()**
Если вы работаете с бинарным файлом arm64e, `ghidra_kernelcache` может распознавать вызовы виртуальных методов, просматривая значение `Pointer Authentication Code`. Процесс прямолинеен и, в отличие от `fix_extra_refs()`, `kernelCache.explore_pac` не полагается на идентификацию `Pcode` или `varnode`, он просто итерирует все инструкции в программе, ищет инструкции `MOVK`, извлекает второй операнд и ищет соответствующее значение в базе данных.
Использование:
Создайте экземпляр *KernelCache* через **kernelCache**, **Kext** или **Custom**, затем вызовите метод `explore_pac()`.```py
from utils.helpers import *
from utils.kext import *

if __name__ == "__main__":
    default = "/tmp/kernel.txt"
    ff = askString("iometa symbol file","Symbol file: ",default)
    iom = ParseIOMeta(ff)
    Obj = iom.getObjects()

    kc = Kext(Obj)

   	 kc.explore_pac()

Вот пример вывода при использовании `fix_extra_refs` :

<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image9.png" alt="image9"/>

Обратите внимание, что он успешно разрешил виртуальные вызовы **IOService::isOpen()**, **OSArray:getNextIndexOfObject()** и **IOStream::removeBuffer()** без каких-либо ручных изменений.

Затем `fix_extra_refs` декомпилирует **IOStream::removeBuffer()**, получает все HighVariables этого метода, а затем разрешает их ссылки, как и предыдущий метод ... и так далее.
<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image10.png" alt="image10"/>

### Автоматическое исправление внешних таблиц методов

Я уверен, что у каждого исследователя есть какой-нибудь скрипт для работы с этой частью, так как это основная поверхность атаки IOKit. Делать это вручную — тяжёлая работа, и это должно быть автоматизировано таким образом, чтобы исследователь мог погрузиться в изучение нескольких внешних таблиц методов. 
В составе `ghidra_kernelcache` предоставлены два скрипта: **fix_methodForIndex.py** и **fix_extMethod.py**. Вы можете включить их, как и другие скрипты, показанные выше.

***Использование***: Поместите курсор в начало внешней таблицы диспетчеризации, запустите скрипт: укажите цель и количество селекторов.
Пример для `IOStreamUserClient::getTargetAndMethodForIndex()` :

<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image11.png" alt="image11"/>

### namespace.py: исправление пространств имён методов …
Это полезный скрипт для присвоения типа класса всем встреченным методам, и он является зависимостью для скрипта `extra_refs.py`, чтобы рекурсивно исследовать вызываемые функции и разрешать их ссылки.

***Использование***: Поместите курсор в вывод декомпилятора нужной функции, запустите скрипт из панели инструментов или нажмите **Meta-Shift-N** .

### Распространение имён символов и типов
`ghidra_kernelcache` предоставляет поддержку распространения типов для базовых операций Pcode, но, скорее всего, потерпит неудачу для некоторых переменных, использующих сложное приведение типов.
Если кто-то хочет помочь или начать работать с низкоуровневыми вещами в Ghidra, это хорошая возможность.
Реализацию можно найти в [ghidra_kernelcache/propagate.py](https://github.com/0x36/ghidra_kernelcache/blob/master/propagate.py)

### Загрузка сигнатур функций

Разбор заголовочных файлов C++ в Ghidra невозможен, а наличие сигнатур функций ядра в kernelcache может значительно улучшить вывод декомпилятора.
Например, если мы добавили `virtual IOMemoryMap * map(IOOptionBits options = 0 );`, Ghidra автоматически переопределит возвращаемое значение на указатель `IOMemoryMap` как для определения функции, так и для сигнатур функций.
Вы можете добавить любой символ C++ в каталог **signatures/**, соблюдая синтаксис, и в этом каталоге можно найти определённые сигнатуры функций.```c++
// Defining an instance class method
IOMemoryDescriptor * withPersistentMemoryDescriptor(IOMemoryDescriptor *originalMD);

// Defining a virtual method, it must start with "virtual" keyword
virtual IOMemoryMap * createMappingInTask(task_t intoTask,  mach_vm_address_t atAddress,  IOOptionBits options,  mach_vm_size_t offset = 0,  mach_vm_size_t length = 0);

// Defining a structure
struct task_t;

// typedef'ing a type
typedef typedef uint IOOptionBits; 

// Lines begining with '//' are ignored