**Wichtiger Hinweis**: Das Projekt wurde auf Ghidra 10.1_PUBLIC und 10.2_DEV getestet und ist nicht abwärtskompatibel.

Gehen Sie zu *`Windows → Script Manager`,*  klicken Sie auf  *`script Directory` ,* und fügen Sie dann *`ghidra_kernelcache`* zur Verzeichnispfadliste hinzu.
Gehen Sie zu *`Windows → Script Manager`,* gehen Sie in der *scripts*-Auflistung zur Kategorie *`iOS→kernel`* und aktivieren Sie die dort sichtbaren Plugins. Diese werden in der GHIDRA-Symbolleiste angezeigt .

Im Verzeichnis [logos/](https://github.com/0x36/ghidra_kernelcache/tree/master/logos) können Sie eigene Logos für jedes Tool ablegen.

## iOS kernelcache Symbolisierung

`ghidra_kernelcache` erfordert in der ersten Phase [iometa](https://github.com/Siguza/iometa/) (erstellt von [@s1guza](https://twitter.com/s1guza)), ein leistungsstarkes Tool, das C++-Klasseninformationen im Kernel-Binary bereitstellt. Das Tolle daran ist, dass es als eigenständige Binärdatei funktioniert, sodass die Ausgabe durch einfaches Parsen in Ihr bevorzugtes RE-Framework importiert werden kann. Mein Framework nimmt die Ausgabe von iometa und analysiert sie, um virtuelle Tabellen zu symbolisieren und zu reparieren.

### Verwendung
Nach dem Dekomprimieren des Kernels führen Sie die folgenden Befehle aus :

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

```
Laden Sie den Kernelcache in Ghidra, ***NICHT DEN BATCH-IMPORT VERWENDEN***, laden Sie ihn als Mach-O-Image.
Nachdem der Kernelcache geladen und automatisch analysiert wurde, klicken Sie auf das in der Symbolleiste angezeigte Symbol oder drücken Sie einfach **Meta-Shift-K**, und geben Sie dann den vollständigen Pfad der iometa-Ausgabe ein, in unserem Fall `/tmp/kernel.txt`.

Wenn Sie `jtool2`-Symbole verwenden möchten, können Sie auch `jsymbol.py` aus der Kategorie `iOS→kernel` verwenden.

### iOS Kernelcache-API
Vollständige API-Beispiele finden Sie in [`ghidra_kernelcache/kc.py`](https://github.com/0x36/ghidra_kernelcache/blob/master/KC.py)

→ Hier einige Beispiele zur Manipulation von Klassenobjekten :```py
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__")

# Process one class (including its parents)
kc.process_class("IOGraphicsAccelerator2")

# Clears the content of the class structures (vtables are excluded)
kc.clear_class_structures()

# Overwrite the old vtable structure definition and resymbolicate it again
kc.update_classes_vtable()

# Reconstructing function call trees by enumerating all pac references and find their corresponding virtual method call
kc.explore_pac()
```
Wie Sie sehen, können Sie den Kernelcache vollständig oder teilweise symbolatisieren. Falls eine partielle Symbolatisierung gewählt wurde, erstellt `ghidra_kernelcache` automatisch alle Klassenabhängigkeiten, bevor es fortfährt.
Wenn Sie das Skript gegen den gesamten Kernelcache (vollständige Symbolatisierung) ausführen, benötigt `ghidra_kernelcache` einige Minuten, um das Kernel-Image zu analysieren.

Sobald der Vorgang abgeschlossen ist, stellt Ghidra Folgendes bereit:

→ Im Bookmark-Filter wurde eine neue Kategorie namens "iOS" hinzugefügt:

<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image1.png" alt="image1" width="200"/>
                    
                    
→ IOKit-Klassen-Virtual-Tables werden zum 'iOS'-Bookmark hinzugefügt, um eine bessere und schnellere Virtual-Table-Suche zu ermöglichen. Sie können einfach nach einem Kext oder einer Klasse suchen, indem Sie Buchstaben, Wörter oder die Kext-Bundle-ID in die Suchleiste eingeben.

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


→ Reparatur der Virtual-Table: Disassembliert/übersetzt unbekannten Code, korrigiert Namensräume, resymbolisiert die Klassenmethoden und wendet Funktionsdefinitionen auf jede Methode an:

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

→ Erstellung von Klassennamensräumen und Einordnung jeder Methode in ihren entsprechenden Namensraum:

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

→ Erstellung der Klassenstruktur unter Berücksichtigung der Klassenhierarchie:

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

→ Erstellung von Klassen-VTables, wobei jede Methode eine eigene Methodendefinition für eine bessere Dekompilierungsausgabe erhält:

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

Die vollständige Implementierung finden Sie in [`utils/class.py`.](https://github.com/0x36/ghidra_kernelcache/blob/master/utils/class.py)

Hier sind einige Screenshots vor/nach der Symbolatisierung mit `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"/>




## macOS-Kext-Symbolatisierung
---
Die macOS-Unterstützung von `ghidra_kernelcache` umfasst sowohl die Kernelcache- als auch die einzelne KEXT-Symbolatisierung für ARM64e- und x86_64-Architekturen.
**WICHTIG:** Zum Zeitpunkt der Erstellung dieses Textes ist Ghidra nicht in der Lage, den gesamten macOS-Kernelcache zu parsen, es ist jedoch möglich, ihn zur ersten Analyse in IDA zu laden und die Datenbank (idb to xml) später nach Ghidra zu importieren. Dies liegt jedoch außerhalb des Rahmens. Falls Ihnen dies gelingt, kümmert sich `ghidra_kernelcache` um den Rest.

Es sind einige wenige Schritte erforderlich, bevor eine macOS-Kernel-Erweiterung symbolatisiert werden kann. Da das Hauptziel von `ghidra_kernelcache` darin besteht, die Klassenhierarchie zu rekonstruieren und alle Klassenstrukturen in einer einzigen Datenbank zu verwalten, erfüllt eine Kernel-Erweiterung diese Anforderungen nicht. Das bedeutet, dass die Symbolatisierung eines einzelnen KEXT die Symbolatisierung des Kernels und möglicherweise anderer Kernel-Erweiterungen erfordert, von denen es abhängt. Daher ist hier etwas zusätzliche Arbeit nötig.
`ghidra_kernelcache` bietet nun eine leistungsstarke Möglichkeit, Kernel-Erweiterungen einschließlich des Kernels zu symbolatisieren, indem Klassenstrukturen und virtuelle Methodendefinitionen über das leistungsstarke *DataType Project Archive* von Ghidra verwaltet und geteilt werden.

### Schritte zur Symbolatisierung einer Kernel-Erweiterung
- Erstellen Sie einen neuen Ordner in Ihrem Ghidra-Projekt, laden Sie dann `/System/Library/Kernels/kernel.release.XXXXX` in diesen Ordner und lassen Sie Ghidra es analysieren.
- Erstellen Sie ein neues *Project Archive*: Gehen Sie zu `DataType Provider` → Klicken Sie auf den Pfeil oben rechts im Fenster → `New Project Archive` → Platzieren Sie es im neu erstellten Ordner → Benennen Sie es (z. B. macOS_12.1).
- Symbolatisieren Sie nun den Kernel mit `ghidra_kernelcache`. Der Vorgang ist der iOS-*kernelcache*-Symbolatisierung recht ähnlich.```bash
$ iometa -n -A /System/Library/Kernels/kernel.release.t8101 > /tmp/kernel.txt
```
- In der Python-Konsole, oder Sie finden die vollständige Skriptimplementierung im Skript `KM.py` :```py
>>> from utils.helpers import *
>>> from utils.kext import *
>>> iom = ParseIOMeta("/tmp/kernel.txt")
>>> Obj = iom.getObjects()
>>> kc = Kext(Obj,shared_p="macOS_12.1")
>>> kc.process_kernel_kext()

```
- Sobald dies abgeschlossen ist, wurde eine Datenbankverknüpfung zwischen dem Kernel-Archiv und dem `macOS_12.1`-Archiv erstellt. Klicken Sie nun mit der rechten Maustaste auf `kernel.release.t8001` → `Commit DataTypes To` → `macOS_12.1`.
- Dann `Rechtsklick` → `Alle auswählen` → `Commit`.
- Speichern Sie das Projektarchiv: `Rechtsklick` → `Save Archive`.
Wir haben gerade ein Projektarchiv erstellt, das über alle Kernel Extensions hinweg gemeinsam genutzt werden kann.
Nehmen wir ein Beispiel von `IOSurface` Kext für 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
```
- Laden Sie das Kext in denselben Ordnerpfad, in dem sich die Kernel-Datenbank und das Projektarchiv befinden, und lassen Sie Ghidra die Analyse abschließen
- Laden Sie das zuvor erstellte Projektarchiv `macOS_12.1` : Gehen Sie zu `Data Type Manager` → `Open Project Archive` und wählen Sie dann `macOS_12.1` aus
- Führen Sie die folgenden Methoden aus, das vollständige Skript finden Sie in `KM.py`:```python
from utils.helpers import *
from utils.kext import *

kc = Kext(Obj,shared_p="macOS_12.1")

# This method fixes LC_DYLD_CHAINED_FIXUPS for M1 Kernel extension
kc.depac()

# This method reconstructs class hierarchy and builds virtual table for each class
kc.process_kernel_kext()

```
**Wichtiger Hinweis**: Manchmal schlägt `kc.process_kernel_kext()` fehl, weil Ghidra einige C++-Symbole nicht demanglen konnte. Um dies zu beheben, öffnen Sie den Skript-Manager und führen Sie das Skript `DemangleAllScript.java` aus, dann starten Sie `kc.process_kernel_kext()` erneut.

### Benutzerdefinierte Klassen
Es gibt einige Fälle, in denen `ghidra_kernelcache` und `iometa` bestimmte C++-Klassen nicht symbolisieren können. Daher wurde eine neue Funktion hinzugefügt, um dies zu handhaben.
Die `Custom()`-Klassenrekonstruktion iteriert durch alle `::vtable`-Symbole und prüft, ob die Klasse bereits definiert ist oder nicht. Falls nicht, erstellt sie automatisch eine Klassenstruktur, Funktionsdefinitionen für jede identifizierte Klassenmethode, einen Namensraum und eine virtuelle Tabelle für jede Klasse.

Die Erstellung benutzerdefinierter Klassen wird derzeit nur unter macOS unterstützt.```bash
$ iometa -n -A /System/Library/Kernels/kernel.release.t8101 > /tmp/kernel.txt
$ iometa -n -A <kext_path> >> /tmp/kernel.txt
```
| **Kategorie**          | **Wert**                          |
|-----------------------|------------------------------------|
| **Typ**                 | `#` Fest codierte Anmeldedaten     |
| **Ort**                | Fest codiert in Dockerfile         |
| **Aktueller Status**   | Aktiv                              |
| **Nachweis**           | `RUN adduser -D -s /bin/sh ...`   |

---
**Detaillierte Analyse:**

Die `Dockerfile` hartkodiert die Erstellung eines Benutzers `jenkins` mit dem Passwort `B@nk123!`:

```dockerfile
RUN adduser -D -s /bin/sh jenkins \
    && echo "jenkins:B@nk123!" | chpasswd
```

* **Risiko:** Jeder mit Netzwerk-/Containerzugriff auf die Jenkins-Oberfläche könnte diese Anmeldedaten verwenden. Werden sie an anderer Stelle wiederverwendet, vergrößert sich der Auswirkungsradius.
* **Abhilfe:** Nutzen Sie Geheimnisverwaltung (z. B. Docker Secrets, HashiCorp Vault). Hinterlegen Sie niemals Geheimnisse in einer Dockerfile. Verwenden Sie Build-Argumente (`ARG`), setzen Sie diese zur Build-Zeit und löschen Sie anschließend den Build-Verlauf.```py

from utils.helpers import *
from utils.custom_kc import *

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

    kc = Custom(Obj)

    kc.process_all_classes()
    kc.explore_pac()


```
## Miscellaneous scripts
---
### Importieren von KDK's Dwarf4 
Ghidra lädt das entsprechende `.dsym`-Verzeichnis manchmal nicht. Ich habe ein kleines Skript erstellt, um dies zu beheben. Es ist [hier](https://github.com/0x36/ghidra_kernelcache/blob/master/dwarf4_fix.py) zu finden.
**Verwendung**: Laden Sie den Kernel aus Ihrem KDK-Pfad, lassen Sie Ghidra die Analyse abschließen, führen Sie dann `dwarf_fix.py` aus. Es lädt die Symbole und der Vorgang kann mehrere Minuten dauern.
<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image12.png" alt="image12"/>

### Auflösen von Referenzen virtueller Methodenaufrufe 
`ghidra_kernelcache` bietet zwei Möglichkeiten, virtuelle Aufrufe aufzulösen: `kernelCache.explore_pac` oder `fix_extra_refs` 

**kernelCache.explore_pac()**
Wenn Sie an einer arm64e-Binärdatei arbeiten, kann `ghidra_kernelcache` virtuelle Methodenaufrufe erkennen, indem es nach dem `Pointer Authentication Code`-Wert sucht. Der Vorgang ist unkompliziert und im Gegensatz zu `fix_extra_refs()`, verlässt sich `kernelCache.explore_pac` nicht auf die Identifikation von `Pcode` oder `varnode`; es durchläuft lediglich alle Anweisungen im Programm, sucht nach `MOVK`-Anweisungen, holt den zweiten Operanden und sucht den entsprechenden Wert in der Datenbank.
Verwendung : 
Erstellen Sie eine *KernelCache*-Instanz über **kernelCache**, **Kext** oder **Custom**, und rufen Sie dann die Methode `explore_pac()` auf.```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()** 
Diese Funktion basiert auf einer grundlegenden Datenflussanalyse, um alle virtuellen Aufrufmethoden zu finden und deren Implementierungen automatisch aufzulösen. Sie arbeitet architekturübergreifend und ist in der Lage, den Quelldatentyp aus der Decompiler-Ausgabe zu erkennen und alle virtuellen Aufrufreferenzen innerhalb der Funktion aufzulösen, sodass der Benutzer direkt zur Implementierung vor-/zurückspringen kann, ohne manuell danach suchen zu müssen.

Die nützlichste Funktion, die von `fix_extra_refs` bereitgestellt wird, besteht darin, dass die Referenzen bei jeder Ausführung synchronisiert bleiben. Wenn Sie beispielsweise einen Variablendatentyp in einen Klassendatentyp ändern, erkennt `fix_extra_refs` die Änderung automatisch und durchläuft rekursiv alle Aufrufstellen, um deren Referenzen aufzulösen. Es stoppt erst, wenn die Warteschlange der Aufrufstellen leer ist.

Es gibt einige weitere Funktionen, die von `fix_extra_refs` bereitgestellt werden, wie zum Beispiel:
- Es erkennt automatisch `_ptmf2ptf()`-Aufrufe und löst deren Aufrufmethode sowohl für Offsets als auch für vollständige Funktionsadressen auf.
- Es identifiziert den Namensraum eines unaufgelösten Funktionsnamens (Funktionen, die mit FUN_ beginnen) und löst ihn auf, indem die Zielfunktion in ihren eigenen Namensraum gesetzt wird (z. B. Hinzufügen des **this**-Zeigers der entsprechenden Klasse).

Die Implementierung finden Sie in **utils/references.py**. `fix_extra_refs` analysiert die [pcode](https://ghidra.re/ghidra_docs/api/ghidra/program/model/pcode/package-summary.html)-Operationen und sucht nach `CALLIND`- und `CALL`-Opcodes. Anschließend werden alle beteiligten [varnodes](https://ghidra.re/ghidra_docs/api/ghidra/program/model/pcode/Varnode.html) in der Operation abgerufen. Sobald eine Varnode-Definition identifiziert wurde, wird deren [HighVariable](https://ghidra.re/ghidra_docs/api/ghidra/program/model/pcode/HighVariable.html) abgerufen, um den Klassenobjekttyp zu identifizieren. Wenn der Typ unbekannt ist (d. h. es scheint sich nicht um eine Klassenstruktur zu handeln), wird er ignoriert. Andernfalls wird der Klassenname übernommen, die zugehörige Virtual-Call-Table nachgeschlagen, und mithilfe des von der Varnode bereitgestellten Offsets kann der richtige virtuelle Methodenaufruf abgerufen und ein Verweis auf die Aufrufanweisung gesetzt werden.```py
fix_extra_refs(toAddr(address))
```
Hier ist ein Beispiel für die Ausgabe der Verwendung von `fix_extra_refs` :

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

Beachten Sie, dass es erfolgreich die virtuellen Aufrufe von **IOService::isOpen()**, **OSArray:getNextIndexOfObject()** und **IOStream::removeBuffer()** ohne manuelle Änderungen aufgelöst hat.

Als nächstes wird `fix_extra_refs` **IOStream::removeBuffer()** dekompilieren, alle HighVariables dieser Methode abrufen und dann deren Referenzen auflösen, wie bei der vorherigen Methode ... und so weiter.
<img src="https://raw.githubusercontent.com/0x36/ghidra_kernelcache/master/screenshots/image10.png" alt="image10"/>

### Automatische Korrektur externer Methodentabellen

Ich glaube, dass jeder Forscher ein Skript hat, um sich mit diesem Teil zu befassen, da es die Hauptangriffsfläche von IOKit ist. Manuelles Vorgehen ist mühsam und muss so automatisiert werden, dass der Forscher mehrere externe Methodentabellen untersuchen möchte. 
Es gibt zwei Skripte, die von `ghidra_kernelcache` bereitgestellt werden: **fix_methodForIndex.py** und **fix_extMethod.py.** Sie können sie wie die anderen Skripte aktivieren, wie oben gezeigt.

***Verwendung***: Setzen Sie den Cursor an den Anfang der externen Dispatch-Tabelle, führen Sie das Skript aus: Geben Sie das Ziel und die Anzahl der Selektoren an.
Beispiel für  `IOStreamUserClient::getTargetAndMethodForIndex()` :

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


### namespace.py : Methodennamensräume korrigieren …
Dies ist ein nützliches Skript, um den Klassentyp für alle gefundenen Methoden zu setzen, und es ist eine Abhängigkeit für das `extra_refs.py`-Skript, um die aufgerufenen Funktionen rekursiv zu durchsuchen und deren Referenzen aufzulösen.

***Verwendung***: Setzen Sie den Cursor in die Dekompilierungsausgabe der gewünschten Funktion, führen Sie das Skript von der Symbolleiste aus oder drücken Sie **Meta-Shift-N** .

### Symbolname- und Typenweitergabe
`ghidra_kernelcache` bietet Unterstützung für die Typenweitergabe für grundlegende Pcode-Operationen, wird aber wahrscheinlich bei einigen Variablen fehlschlagen, die komplexe Castings verwenden.
Wenn jemand helfen möchte oder mit Low-Level-Sachen in Ghidra arbeiten möchte, ist dies die Gelegenheit dazu.
Die Implementierung befindet sich in [ghidra_kernelcache/propagate.py](https://github.com/0x36/ghidra_kernelcache/blob/master/propagate.py)

### Laden von Funktionssignaturen

Das Parsen von C++-Header-Dateien in Ghidra ist nicht möglich, und das Vorhandensein von Kernel-Funktionssignaturen im Kernelcache kann viele Dinge in der Dekompilierungsausgabe verbessern.
Angenommen, wir haben `virtual IOMemoryMap * map(IOOptionBits options = 0 );` hinzugefügt, dann wird Ghidra automatisch den Rückgabetyp in einen `IOMemoryMap`-Zeiger umwandeln, sowohl für die Funktionsdefinition als auch für Funktionssignaturen.
Sie können jedes C++-Symbol in das Verzeichnis **signatures/** mit der entsprechenden Syntax einfügen, und Sie finden definierte Funktionssignaturen in diesem Verzeichnis.```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 

```
***Verwendung***: Nachdem der Kernel symbolisiert wurde, wird dringend empfohlen, das Skript `load_sigatnures.py` auszuführen, um alle verfügbaren Funktionssignaturen zu laden. Wie bei den meisten vorherigen Tools führen Sie dieses Skript aus, indem Sie es in der Symbolleiste oder über den Plugin-Manager hinzufügen oder einfach **Meta-Umschalt-S** drücken.

### Laden alter Strukturen:

Dieses Skript ist unkompliziert: Es importiert alle Strukturen, Klassen, Typedefs und Funktionsdefinitionen sowie alles mit `SourceType.USER_DEFINED` aus einem alten Projekt in ein neues.

***Verwendung***: Öffnen Sie die alten und die neuen Ghidra-Projekte im selben Tool, gehen Sie zum Skript [`load_structs.py`](https://github.com/0x36/ghidra_kernelcache/blob/master/load_structs.py), setzen Sie den alten Programmnamen in die Variable **src_prog_string** und den neuen in die Variable **dst_prog_string**, und führen Sie dann das Skript aus.

## Mitwirken
Wenn Sie das Projekt interessant finden und beitragen möchten, erstellen Sie einfach einen PR, und ich werde ihn überprüfen. In der Zwischenzeit würde ich mich über Beiträge in den folgenden Bereichen freuen:
* [ghidra_kernelcache/signatures/kernel.txt](https://github.com/0x36/ghidra_kernelcache/tree/master/signatures): Importieren Sie weiterhin XNU-Kernel-Funktionen, es ist ganz einfach, kopieren/einfügen Sie die Funktionsdefinition.
* [ghidra_kernelcache/propagate.py](https://github.com/0x36/ghidra_kernelcache/blob/master/propagate.py): Unterstützung für nicht behandelte Opcodes für eine bessere Symbolausbreitung.

## Danksagung
Ich möchte [@s1guza](https://twitter.com/s1guza) für sein großartiges [iometa](https://github.com/Siguza/iometa.git) danken, von dem ghidra_kernelcache abhängt.