noahware/binprotectx64 PE bin2bin-Obfuskator, der der Binärdatei keinen Abschnitt hinzufügt
Siehe 4. Bauen für Bauanweisungen.
Dieser Verschleierer ist bin2bin, das heißt, er nimmt eine bereits kompilierte ausführbare Binärdatei und reproduziert sie mit den angewendeten Verschleierungspässen. Dies kann verwendet werden, um eine Anwendung zu schützen, ohne Zugriff auf den ursprünglichen Quellcode zu haben. Derzeit werden nur x64 PE (portable executable) Dateien unterstützt, aber es gibt Pläne, in Zukunft Unterstützung für andere Binärformate (z. B. ELF) hinzuzufügen.
Derzeit fügen alle bekannten bin2bin-Verschleierer einen Abschnitt am Ende der Binärdatei ein, um den verschleierten Code oder die verschleierten Daten darin zu platzieren. Dadurch bleibt das ursprüngliche Layout der Binärdatei erhalten, da der Inhalt der vorhandenen Abschnitte nicht geändert werden muss. Dies ist viel einfacher zu verwalten, da die meisten RVAs (relative Adressen) gültig bleiben.
Dieses Projekt verfolgt einen einzigartigen Ansatz für bin2bin, bei dem jeglicher verschleierter Code oder verschleierte Daten innerhalb der ursprünglichen Abschnitte der Binärdatei eingefügt werden. Dies erfordert die Verfolgung jeder einzelnen RVA in der Anwendung. Die Vorteile dieses Ansatzes sind:
Dieses Dokument beschreibt sowohl das Umschreiben der ausführbaren Binärdatei als auch die implementierten Verschleierungstechniken. Die folgenden Verschleierungstechniken wurden implementiert:
Darüber hinaus unterstützt dieses Projekt auch Ausnahmen (C++-Ausnahmen und SEH) und kann Funktionen verschleiern, die Ausnahmebehandlung besitzen.
Zur Unterstützung der Disassemblierung und Entdeckung von Code in der Binärdatei werden optional Symboldateien (sowohl PDB als auch MAP) akzeptiert. Die Bereitstellung von Symboldateien ist nicht erforderlich, hilft aber bei der Disassemblierung komplexer Binärdateien. Einige Funktionen wie Ausnahmebehandlung und Kontrollflussabflachung erfordern die Bereitstellung einer Symboldatei.
Ein Binär-Rewriter nimmt eine ausführbare Binärdatei und ändert den darin enthaltenen Code oder die Daten, um eine Ausgabebinärdatei mit den angewendeten Änderungen zu erzeugen.
Da der verschleierte Code direkt in die ursprünglichen Abschnitte der Binärdatei eingefügt wird, müssen die relativen Adressen im Programm verfolgt werden, damit alle Verweise auf sie angepasst werden können. Dadurch wird sichergestellt, dass die Verweise nach dem Einfügen von Code und Daten immer noch auf dieselbe Stelle zeigen. Andernfalls würde auf Daten oder Code an der falschen Stelle zugegriffen, was das Verhalten der Ausgabebinärdatei verändert und schwere Instabilitäten verursacht.
Immer wenn ein Verweis auf eine relative Adresse gefunden wird (z. B. Anweisungen mit rip-relativen Operanden oder PE-Datenverzeichnisse), wird er zu einer Tracking-Liste hinzugefügt, die am Ende des Umschreibens aktualisiert wird. Die RVA, an der der Verweis auftritt, wird verfolgt (um zu wissen, wo der Verweis aktualisiert werden muss), ebenso wie die RVA, auf die verwiesen wird (um zu wissen, mit welcher RVA der Verweis aktualisiert werden muss).
Wenn der Disassembler eine rip-relative Anweisung findet, fügt er sie zu einer Liste von Verweisen hinzu, die am Ende der Verschleierung aktualisiert werden müssen. Dadurch wird sichergestellt, dass alle diese Anweisungen immer noch auf die Stelle zeigen, die sie ursprünglich hatten. Andere relative Anweisungsfälle wie Sprungtabellen werden ebenfalls als zu aktualisierende Verweise hinzugefügt.
Alle verfolgten RVAs müssen angepasst werden, wenn Bytes in die Binärdatei eingefügt oder daraus entfernt werden. Hier ist zum Beispiel der Byte-Einfüge-Handler:```cpp
void binwrite::binary_t::insert(const rva_t rva, const std::span data, const bool inclusive)
{
buffer_.insert_range(buffer_.begin() + rva.value(), data);
update_rvas(rva, static_cast<rva_t::size_type>(data.size()), inclusive);
}
`update_rvas` ist der Ort, an dem jede verfolgte RVA aktualisiert wird, um die im Binärfile aufgetretene Änderung widerzuspiegeln. Hier ist ein Diagramm dieses Vorgangs:
Abbildung 1. Relative Adressverfolgung.
Die eingefügten Daten (blau) verschieben die aktuellen Daten (grau). Die referenzierte RVA der Anweisung (orange) wird aktualisiert, um auf denselben Speicher zu verweisen, unter Berücksichtigung der eingefügten Daten (blau).
## 2.2. Disassemblierung
Alle potenziellen Codeeinträge (Exporte, Einstiegspunkt, Umleitungen, die auf den Codeschnitt zeigen, usw.) werden zu einer Disassemblierungs-Warteschlange hinzugefügt. Wenn eine Symboldatei vorhanden ist, werden alle durch die Symboldatei beschriebenen Funktionen ebenfalls zur Disassemblierungs-Warteschlange hinzugefügt. Jeder Eintrag in der Warteschlange wird als einzelner grundlegender Block behandelt.
Ein grundlegender Block ist eine Gruppe von Befehlen ohne Verzweigungen; das bedeutet, dass er an Kontrollflussanweisungen (z.B. Sprung, Rückkehr, Interrupt) beendet wird. Grundlegende Blöcke werden nicht an Aufrufen beendet, da diese in den meisten Fällen zurückkehren. Einige Funktionen kehren nicht zurück (z.B. _CxxThrowException) und werden im Folgenden als 'noreturn'-Aufrufe bezeichnet.
Wenn ein grundlegender Block aus der Disassemblierungs-Warteschlange verarbeitet wird, wird jeder Befehl von oben beginnend disassembliert, bis einer der folgenden Fälle eintritt:
- Ein weiterer bereits analysierter grundlegender Block wird erreicht, was zu einer Überlappung führt. Siehe „Grundlegende Blöcke aufteilen“.
- Eine terminierende Anweisung wird gefunden (Sprung, Rückkehr, Interrupt).
- Die Befehlsdisassemblierung ist fehlgeschlagen.
- Code-Padding wurde gefunden.