ret-sync

ret-sync steht für Reverse-Engineering Tools Synchronisation (Synchronisierung von Reverse-Engineering-Werkzeugen). Es handelt sich um eine Reihe von Plugins, die die Synchronisation einer Debugging-Sitzung (WinDbg/GDB/LLDB/OllyDbg/OllyDbg2/x64dbg) mit einem Disassembler (IDA/Ghidra/Binary Ninja) ermöglichen. Die zugrundeliegende Idee ist einfach: das Beste aus beiden Welten (statische und dynamische Analyse) nutzen.

Debugger und dynamische Analyse bieten uns:

• lokale Ansicht mit dynamischem Live-Kontext (Register, Speicher, usw.)
• eingebaute spezialisierte Funktionen/APIs (z.B. WinDbgs !peb, !drvobj, !address, usw.)

Disassembler und statische Analyse bieten uns:

• Makroansicht über Module
• Codeanalyse, Signaturen, Typen, usw.
• ausgefeilte Graphansicht
• Dekompilierung
• dauerhafte Speicherung von Wissen in IDBs/GPRs

Hauptfunktionen:

• Synchronisierung von Graph- und Dekompilierungsansichten mit dem Debugger-Zustand
• keine Notwendigkeit, sich mit ASLR zu befassen, Adressen werden on-the-fly neu basiert
• Daten (Kommentar, Befehlsausgabe) vom Debugger an den Disassembler übergeben
• mehrere IDBs/GPRs können gleichzeitig synchronisiert werden, sodass einfach durch mehrere Module getraced werden kann
• Disassembler und Debugger können sich auf verschiedenen Hosts/VMs befinden

ret-sync ist ein Fork von qb-sync, den ich während meines Aufenthalts bei Quarkslab entwickelt und gewartet habe.

---

Inhaltsverzeichnis

• Repository-Inhalt
• Allgemeine Voraussetzungen
• Binäre Veröffentlichung
• ret-sync Konfiguration
• Installation
  • IDA-Erweiterung
  • Ghidra-Erweiterung
  • Binary Ninja-Erweiterung
  • WinDbg-Erweiterung
  • GNU gdb (GDB) Installation
  • LLDB-Installation
  • OllyDbg 1.10 Installation
  • OllyDbg2 Installation
  • x64dbg Installation
• Verwendung
  • ret-sync Debugger-Befehle
  • IDA-Verwendung
  • Ghidra-Verwendung
  • Binary Ninja-Verwendung
  • WinDbg-Verwendung
  • GNU gdb (GDB) Verwendung
  • LLDB-Verwendung
  • OllyDbg 1.10 Verwendung
  • OllyDbg2 Verwendung
  • x64dbg Verwendung
  • Verwendung der Python-Bibliothek
• Erweitern
• TODO
• Bekannte Fehler/Einschränkungen
• Lizenz
• Danksagungen

---

Repository-Inhalt

Die Debugger-Plugins:

• ext_windbg/sync: WinDbg-Erweiterungsquellen, nach dem Bau: sync.dll
• ext_gdb/sync.py: GDB-Plugin
• ext_lldb/sync.py: LLDB-Plugin
• ext_olly1: OllyDbg 1.10-Plugin
• ext_olly2: OllyDbg v2-Plugin
• ext_x64dbg: x64dbg-Plugin

Die Disassembler-Plugins:

• ext_ida/SyncPlugin.py
• ext_ghidra/dist/ghidra_*_retsync.zip: Ghidra-Plugin
• ext_bn/retsync: Binary Ninja-Plugin

Und das Bibliotheks-Plugin:

• ext_lib/sync.py: eigenständige Python-Bibliothek

Allgemeine Voraussetzungen

IDA- und GDB-Plugins benötigen eine funktionierende Python-Umgebung. Python 2 (>=2.7) und Python 3 werden unterstützt.

Binäre Veröffentlichung

Vorgefertigte Binärdateien für WinDbg/OllyDbg/OllyDbg2/x64dbg-Debugger werden über eine Azure DevOps-Pipeline bereitgestellt:

Wählen Sie den letzten Build aus und überprüfen Sie die Artefakte im Bereich Related: 6 published.

Ein vorgefertigtes Plugin-Archiv des Ghidra-Plugins wird in ext_ghidra/dist bereitgestellt.

ret-sync Konfiguration

ret-sync sollte für die meisten Benutzer mit einer typischen Einrichtung sofort funktionieren: Debugger und Disassembler auf demselben Host, Modulnamen stimmen überein.

In einigen Szenarien kann dennoch eine spezifische Konfiguration erforderlich sein. Dazu suchen Erweiterungen und Plugins optional nach einer globalen Konfigurationsdatei namens .sync im Home-Verzeichnis des Benutzers. Sie muss eine gültige .INI-Datei sein.

Zusätzlich suchen die IDA- und Ghidra-Plugins auch zuerst im IDB- oder Projektverzeichnis (<project>.rep) nach der Konfigurationsdatei, um lokale, pro-IDB/Projekt-Einstellungen zu ermöglichen. Wenn eine lokale Konfigurationsdatei vorhanden ist, wird die globale Konfigurationsdatei ignoriert.

Werte, die in diesen Konfigurationsdateien deklariert sind, überschreiben die Standardwerte. Bitte beachten Sie, dass standardmäßig keine .sync-Datei erstellt wird.

Im Folgenden beschreiben wir drei häufige Szenarien, in denen eine Konfigurationsdatei nützlich/notwendig ist:

• Remote-Debugging
• Modulnamen stimmen nicht überein
• Fehlende PID

Remote-Debugging: Debugger und Disassembler befinden sich auf verschiedenen Hosts

Der Abschnitt [INTERFACE] wird verwendet, um netzwerkbezogene Einstellungen anzupassen. Angenommen, man möchte IDA mit einem Debugger synchronisieren, der auf einer virtuellen Maschine (oder einfach einem anderen Host) läuft – ein häufiges Szenario beim entfernten Kernel-Debugging.

Erstellen Sie einfach zwei .sync-Dateien:

• eine auf dem Rechner, auf dem IDA installiert ist, im IDB-Verzeichnis:
• Für Ghidra platzieren Sie sie im Home-Verzeichnis, z.B. "/home/user" oder "C:\Users\user".``` [INTERFACE] host=192.168.128.1 port=9234

Es weist das **ret-sync** ``IDA``-Plugin an, auf dem Interface ``192.168.128.1`` mit Port ``9234`` zu lauschen. Es versteht sich von selbst, dass dieses Interface vom entfernten Host oder der virtuellen Maschine aus erreichbar sein muss.

* eines auf dem Rechner, auf dem der Debugger ausgeführt wird, im Home-Verzeichnis des Benutzers:```
[INTERFACE]
host=192.168.128.1
port=9234

Es teilt dem ret-sync Debugger-Plugin mit, sich mit dem zuvor konfigurierten ret-sync IDA-Plugin zu verbinden, das auf diesem Interface lauscht.

HINWEIS: Sie müssen hier eine echte IP angeben und nicht 0.0.0.0 verwenden. Dies liegt daran, dass die Variable von mehreren Quellen sowohl zum Binden als auch zum Verbinden verwendet wird. Die Verwendung von 0.0.0.0 führt daher zu seltsamen Fehlern.

IDB- und Debugger-Modulnamen sind unterschiedlich```

[ALIASES] ntoskrnl_vuln.exe=ntkrnlmp.exe

Der Abschnitt ``[ALIASES]`` wird verwendet, um den Namen anzupassen, der von einem Disassembler (IDA/Ghidra) verwendet wird, um ein Modul bei seinem Dispatcher/Programm-Manager zu registrieren.

Standardmäßig verwenden Disassembler-Plugins den Namen der Eingabedatei. Allerdings kann es vorkommen, dass man die Datei vorher umbenannt hat und sie nicht mehr mit dem Namen des tatsächlichen Prozesses oder geladenen Moduls übereinstimmt, wie er vom Debugger gesehen wird.

Hier teilen wir dem Dispatcher einfach mit, dass er den Namen `ntkrnlmp.exe` (echter Name) anstelle von `ntoskrnl_vuln.exe` (IDB-Name) verwenden soll.

## gdb mit Qt Creator Debugging-Frontend