**Nota importante**: O projeto foi testado no Ghidra 10.1_PUBLIC e 10.2_DEV e não é compatível com versões anteriores.

Vá para *`Windows → Script Manager`,* clique em *`script Directory`,* depois adicione *`ghidra_kernelcache`* à lista de diretórios.
Vá para *`Windows → Script Manager`,* na listagem de *scripts*, vá para a categoria *`iOS→kernel`* e marque os plug-ins vistos lá, eles aparecerão na Barra de Ferramentas do GHIDRA.

No diretório [logos/](https://github.com/0x36/ghidra_kernelcache/tree/master/logos), você pode colocar seus próprios logos para cada ferramenta.

## Simbolização do kernelcache do iOS

`ghidra_kernelcache` requer, na primeira etapa, [iometa](https://github.com/Siguza/iometa/) (feito por [@s1guza](https://twitter.com/s1guza)), uma ferramenta poderosa que fornece informações de classes C++ no binário do kernel. O ótimo é que funciona como um binário independente, então a saída pode ser importada para seu framework de RE favorito apenas analisando-a. Meu framework pega a saída do iometa e a analisa para simbolizar e corrigir tabelas virtuais.

### Uso
Após descomprimir o kernel, execute os seguintes comandos:```sh
$ iometa -n -A /tmp/kernel A10-legacy.txt > /tmp/kernel.txt
# if you want also to symbolicate using jtool2
$ jtool2 --analyze /tmp/kernel

Como pode ver, pode simbolizar total ou parcialmente o kernelcache; se a simbolização parcial for escolhida, o `ghidra_kernelcache` construirá automaticamente todas as dependências de classe antes de prosseguir.
Se executar o script contra todo o kernelcache (simbolização completa), o `ghidra_kernelcache` levará vários minutos para analisar a imagem do kernel.

Uma vez terminado, o Ghidra fornecerá o seguinte:

→ Uma nova categoria foi adicionada no Filtro de Marcadores chamada "iOS": 

<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image1.png" alt="image1" width="200"/>
                    
                    
→ Tabelas virtuais de classes IOKit são adicionadas ao Marcador 'iOS' para uma consulta melhor e mais rápida da tabela virtual; pode procurar por uma kext ou classe fornecendo letras, palavras ou o bundle da kext na barra de busca.

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


→ Corrigindo a tabela virtual: desmonta/compila código desconhecido, corrige namespaces, re-simboliza os métodos da classe e aplica definição de função a cada método:

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

→ Criação de namespaces de classe e coloca cada método no seu próprio namespace correspondente:

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

→ Criando estrutura de classe com respeito à hierarquia de classes:

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

→ Criando vtables de classe, e cada método tem sua própria definição de método para uma melhor saída de descompilação:

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

A implementação completa pode ser encontrada em [`utils/class.py.`](https://github.com/0x36/ghidra_kernelcache/blob/master/utils/class.py)

Aqui estão algumas capturas de tela de antes/depois da simbolização usando `ghidra_kernelcache`:

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

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




## Simbolização de Kext do macOS
---
O suporte do `ghidra_kernelcache` no macOS é tanto para simbolização de kernelcache quanto de KEXT individual para as arquiteturas ARM64e e x86_64. 
**IMPORTANTE:** No momento da escrita, o Ghidra não consegue analisar todo o kernelcache do macOS, mas é possível carregá-lo no IDA para análise inicial e depois importar a base de dados (idb para xml) para o Ghidra mais tarde, mas isso está fora do escopo. Se conseguir fazê-lo, o `ghidra_kernelcache` cuidará do resto.

Existem alguns poucos passos que devem ser tomados antes de simbolizar qualquer Extensão de Kernel do macOS, pois o objetivo principal do `ghidra_kernelcache` é reconstruir a hierarquia de classes e gerenciar todas as estruturas de classe em uma única base de dados; uma extensão de kernel não cumpre esses requisitos, o que significa que a simbolização de um único KEXT requer uma simbolização do kernel e talvez de outras Extensões de Kernel das quais depende, portanto algum trabalho extra precisa ser feito aqui.
O `ghidra_kernelcache` agora fornece uma maneira poderosa de simbolizar Extensões de Kernel, incluindo o kernel, gerenciando e compartilhando estruturas de classe e definições de métodos virtuais através do poderoso *DataType Project Archive* do Ghidra

### Passos para simbolizar uma Extensão de Kernel
- Crie uma nova pasta no seu projeto Ghidra, depois carregue ` /System/Library/Kernels/kernel.release.XXXXX` nessa pasta e deixe o Ghidra analisá-la.
- Crie um novo *Project Archive*: Vá até `DataType Provider` → Clique na seta no canto superior direito da janela → `New Project Archive` → Coloque-o dentro da pasta recém-criada → Dê um nome a ele (ex.: macOS_12.1).
- Agora simbolize o kernel usando `ghidra_kernelcache`; o processo é bastante similar à simbolização do *kernelcache* do iOS.```bash
$ iometa -n -A /System/Library/Kernels/kernel.release.t8101 > /tmp/kernel.txt

- Uma vez concluído, uma associação de banco de dados foi criada entre o arquivo do kernel e o arquivo `macOS_12.1`. Agora, clique com o botão direito em `kernel.release.t8001` → `Commit DataTypes To` → `macOS_12.1`.
- Em seguida, `Clique com o botão direito` → `Selecionar Tudo` → `Commit`.
- Salve o arquivo do projeto: `Clique com o botão direito` → `Save Archive`.
Acabamos de criar um arquivo de projeto que pode ser compartilhado entre todas as extensões do kernel.
Vamos tomar como exemplo o `IOSurface` Kext para 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

**Nota Importante**: às vezes `kc.process_kernel_kext()` falha porque o Ghidra não conseguiu desmistificar alguns símbolos C++. Para corrigir isso, vá ao gerenciador de scripts e execute o script `DemangleAllScript.java`, depois reinicie `kc.process_kernel_kext()` novamente.

### Classes personalizadas
Existem alguns casos em que algumas classes C++ onde `ghidra_kernelcache` e `iometa` não conseguem simbolizar, então um novo recurso foi adicionado para lidar com isso.
A reconstrução da classe `Custom()` itera por todos os símbolos `::vtable` e verifica se a classe já está definida ou não; se não estiver, cria automaticamente uma estrutura de classe, definições de função para cada método de classe identificado, um namespace e uma tabela virtual para cada classe.

A criação de classes personalizadas é suportada apenas no macOS no momento.```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()

## Scripts diversos
---
### Importando o Dwarf4 do KDK
Ghidra de alguma forma não consegue carregar o diretório `.dsym` correspondente, fiz um pequeno script para corrigir isso. Ele pode ser encontrado [aqui](https://github.com/0x36/ghidra_kernelcache/blob/master/dwarf4_fix.py).
**Uso**: carregue o kernel do seu caminho KDK, deixe o Ghidra terminar a análise, então execute `dwarf_fix.py`, ele carregará os símbolos e o processo pode levar vários minutos.
<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image12.png" alt="image12"/>

### Resolvendo referências de chamadas de métodos virtuais
`ghidra_kernelcache` fornece duas maneiras de resolver chamadas virtuais por  `kernelCache.explore_pac` ou `fix_extra_refs`

**kernelCache.explore_pac()**
Se você está trabalhando em um binário arm64e, o `ghidra_kernelcache` pode reconhecer chamadas de métodos virtuais procurando pelo valor `Pointer Authentication Code`. O processo é direto e, diferentemente do `fix_extra_refs()`, o `kernelCache.explore_pac` não depende da identificação de `Pcode` ou `varnode`, ele apenas itera por todas as instruções no programa, procura por instruções `MOVK`, busca o segundo operando e procura seu valor correspondente no banco de dados.
Uso:
Crie uma instância *KernelCache* via **kernelCache** , **Kext** ou **Custom**, então chame o método `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()

Aqui está um exemplo de saída do uso de `fix_extra_refs`:

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

Observe que ele resolveu com sucesso as chamadas virtuais de **IOService::isOpen()**, **OSArray:getNextIndexOfObject()** e **IOStream::removeBuffer()** sem qualquer modificação manual.

Em seguida, `fix_extra_refs` descompilará **IOStream::removeBuffer()**, obterá todas as HighVariables deste método e então resolverá suas referências como no método anterior ... e assim por diante.
<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image10.png" alt="image10"/>

### Correção automática de tabelas de métodos externos

Acredito que todo pesquisador tenha algum script para lidar com esta parte, já que é a principal superfície de ataque do IOKit; fazê-lo manualmente é um fardo, e deve ser automatizado de forma que o pesquisador possa mergulhar em várias tabelas de métodos externos.
Existem dois scripts fornecidos pelo `ghidra_kernelcache`: **fix_methodForIndex.py** e **fix_extMethod.py.** Você pode ativá-los como os outros scripts, conforme mostrado acima.

***Uso***: Coloque o cursor no início da tabela de despacho externa, execute o script: forneça o alvo e o número de seletores.
Exemplo para `IOStreamUserClient::getTargetAndMethodForIndex()`:

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


### namespace.py: corrigir namespaces de métodos…
Este é um script útil para popular o tipo de classe em todos os métodos encontrados, e é uma dependência para o script `extra_refs.py` para explorar recursivamente as funções chamadas e resolver suas referências.

***Uso***: Coloque o cursor na saída do descompilador da função desejada, execute o script a partir da barra de ferramentas ou pressione **Meta-Shift-N**.

### Propagação de nome e tipo de símbolo
O `ghidra_kernelcache` fornece suporte à propagação de tipos para operações básicas de Pcode, mas provavelmente falhará para algumas variáveis que usam casting complexo.
Se alguém quiser ajudar ou quiser começar a trabalhar com coisas de baixo nível no Ghidra, esta é a oportunidade.
A implementação pode ser encontrada em [ghidra_kernelcache/propagate.py](https://github.com/0x36/ghidra_kernelcache/blob/master/propagate.py)

### Carregamento de assinaturas de funções

Analisar arquivos de cabeçalho C++ no Ghidra não é possível, e ter assinaturas de funções do kernel no kernelcache pode melhorar muitas coisas na saída do descompilador.
Por exemplo, suponha que adicionamos `virtual IOMemoryMap * map(IOOptionBits options = 0 );`. O Ghidra irá reatribuir automaticamente o valor de retorno para um ponteiro `IOMemoryMap` tanto para a definição da função quanto para as assinaturas de função.
Você pode adicionar qualquer símbolo C++ no diretório **signatures/** respeitando a sintaxe e pode encontrar assinaturas de função definidas neste diretório.```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