rev.ng-Decompiler wird Open Source

 (rev.ng)
3 Punkte von GN⁺ 2024-03-31 | 1 Kommentare | Auf WhatsApp teilen
  • rev.ng hat mit revng-c das Backend seines Decompilers veröffentlicht und damit die Decompilation-Engine als Open Source freigegeben; dazu kommen eine geschlossene Beta der UI, eine neue Website, rev.ng Hub und Dokumentation
  • Lokal lässt sich per Installationsskript die CLI einrichten; mit revng artifact und revng ptml kann man Decompilation-Ergebnisse in Form von gültigem C-Code ansehen
  • Die interaktive UI basiert auf VSCode und soll im Browser sowie als eigenständige App laufen; sie ist in einer geschlossenen Beta verfügbar, zu der Newsletter-Abonnenten nach dem FIFO-Prinzip eingeladen werden
  • Automatische Wiederherstellung von Datenstrukturen, kollaboratives Reversing, Unterstützung verschiedener Architekturen und Erweiterbarkeit sind zentrale Ziele; aktuell konzentriert sich die QA jedoch am stärksten auf Linux-x86-64-Binaries
  • Framework und CLI sind Open Source; die Cloud-UI ist für öffentliche Projekte kostenlos, während private Projekte und die eigenständige Offline-UI als kostenpflichtiges Modell getrennt sind

Wechsel zu Open Source und geschlossene Beta

  • rev.ng hat revng-c, das Backend seines Decompilers, als Open Source veröffentlicht
    • Durch diese Veröffentlichung ist die gesamte Decompilation-Engine Open Source
    • Erste Dokumentation wird ebenfalls bereitgestellt
  • Für die UI sollen Einladungen zu einer geschlossenen Beta für Newsletter-Abonnenten starten
    • Die Einladungen erfolgen nach dem FIFO-Prinzip
    • Für die Teilnahme an der Beta ist eine Newsletter-Registrierung erforderlich
  • Auch eine neue Website und rev.ng Hub wurden veröffentlicht
    • rev.ng Hub ist der Einstiegspunkt für die Cloud-Version
    • Beta-Nutzer können Projekte erstellen, die UI im Browser ausführen und mit anderen Nutzern zusammenarbeiten
    • Auch wer nicht zur geschlossenen Beta gehört, kann öffentliche Projekte ansehen
  • Für Nutzer, die die Funktionen von rev.ng direkt prüfen möchten, werden auch private Demos angeboten

rev.ng per CLI ausprobieren

  • revng kann ohne Root-Rechte in ein einzelnes Verzeichnis installiert werden; durch Löschen dieses Verzeichnisses wird es entfernt
curl -L -s https://rev.ng/downloads/revng-distributable/master/install.sh | bash
cd revng
source ./environment
  • Das Beispiel example.c ist ein einfaches Programm, das argc * 3 zurückgibt
int main(int argc, char *argv[]) {
  return argc * 3;
}
  • Nach dem Kompilieren mit gcc liefert revng artifact ein Decompilation-Ergebnis als einzelne Datei
gcc example.c -o example -O2
revng artifact \
        --analyze \
        --progress \
        decompile-to-single-file \
        example \
        | revng ptml --color \
        | grep -A2 -B1 '[^_]main\b' \
        > decompiled.c

Umfang der Beta und Testziele

  • Für die Nutzung der UI muss man sich für den Newsletter registrieren; Einladungen erfolgen in kleinen Batches
  • Diese Veröffentlichung konzentriert sich darauf, die UI und Decompilation-Ergebnisse an einigen Binaries zu demonstrieren sowie Feedback und Bug-Reports zur Arbeit mit realen Binaries zu sammeln
  • Die getesteten nichttrivialen Binaries und ihre .text-Größen sind:
  • rev.ng unterstützt mehrere ABIs und Plattformen, doch die frühe QA in dieser Phase konzentriert sich auf Linux-x86-64-Binaries
  • Bei Problemen kann man über Discourse Hilfe erhalten

Die von rev.ng angestrebte Decompilation-Erfahrung

  • Die Schwerpunkte von rev.ng liegen auf automatischer Wiederherstellung von Datenstrukturen, moderner UX, kollaborativem Reversing, breiter Plattformunterstützung und Erweiterbarkeit

  • Automatische Wiederherstellung von Datenstrukturen

    • Mit Data Layout Analysis lassen sich struct-Layouts durch interprozedurale Analyse automatisch wiederherstellen
    • Das Beispiel eines Linked-List-Knotens behandelt eine Struktur mit einem Array int64_t data[5] und einem Zeiger auf den nächsten Knoten
    • Die Ausgabe von rev.ng erzeugt Struktur- und Funktionscode, der die Array-Größe 5 und den Zugriff auf den Zeiger zum nächsten Element automatisch erkennt
    • Die Ausgabe des Decompilers ist syntaktisch gültiger C-Code
    • Diese Funktion ist derzeit verfügbar

  • Interaktive UI auf VSCode-Basis

    • Da die UI auf VSCode basiert, können VSCode-Nutzer auf vertraute Weise damit arbeiten
    • Sie kann sowohl in einem Browser-Tab als auch als eigenständige Anwendung ausgeführt werden
    • Die wichtigsten Tastenkürzel sind:
      • Ctrl + Click: Zur Definition der Funktion oder des Typs unter dem Cursor springen
      • N: Umbenennen
      • Y: Typ bearbeiten
      • X: Referenzen anzeigen
    • rev.ng ist ein interaktiver Decompiler, der bei Änderungen nur die betroffenen Teile neu berechnet
    • Die UI steht derzeit Teilnehmern der geschlossenen Beta zur Verfügung

  • Kollaboratives Reversing

    • Die rev.ng-UI verwendet eine Client-Server-Architektur
    • Mehrere Nutzer können sich mit derselben Daemon-Instanz verbinden und gleichzeitig am selben Projekt arbeiten
    • In der Cloud-Version ist rev.ng Hub verfügbar, eine GitHub-ähnliche Anwendung zur Projektverwaltung
    • Die Kollaborationsfunktionen funktionieren, benötigen aber Verbesserungen der Nutzererfahrung; dies wird in Roadmap-Eintrag #797 verfolgt

Architektur und Plattformunterstützung

  • rev.ng nutzt den vorderen Teil der QEMU-Pipeline, um ausführbaren Code in tiny code zu liften, wandelt diesen in LLVM IR um und führt anschließend die Decompilation durch
  • Dank dieser Struktur lassen sich von QEMU unterstützte Architekturen vergleichsweise leicht unterstützen
  • Neben der Architekturunterstützung ist auch die Plattformunterstützung, insbesondere ABI-Support, wichtig
    • rev.ng verwendet das ABI description format, um ABI-Eigenschaften deklarativ zu beschreiben
    • Dieses Format ist allgemein genug gestaltet, um die Unterstützung neuer ABIs einfach zu machen
  • Der aktuelle Support-Stand ist:
    • Architekturen: x86, x86-64, ARM, AArch64, MIPS und s390x mit unterschiedlichem Reifegrad
    • Binary-Formate: Unterstützung für ELF, PE/COFF und Mach-O
    • Importe: Unterstützung für .idb, DWARF-Debug-Informationen und PDB-Debug-Informationen
  • Der Großteil der QA wurde mit Linux-x86-64-Binaries durchgeführt; der Rest benötigt zusätzliche QA
  • Weitere Plattform-QA wird in Roadmap-Eintrag #58 verfolgt

Erweiterbarkeit und Scripting

  • rev.ng zielt darauf ab, ein Framework für Reverse-Engineering-Tools zu sein; das gesamte Projekt mit Ausnahme der interaktiven UI ist Open Source
  • Die Projektdatei, das model, ist ein YAML-Dokument, sodass sich rev.ng skripten lässt, sofern JSON oder YAML geparst werden kann
  • Das Modell enthält unter anderem Architektur, Standard-ABI, Segmente, Funktionsliste und Typliste des zu dekompilierenden Binaries
  • Das Modell kann über Wrapper für Python und TypeScript geändert werden
    • Derzeit gibt es Wrapper zur Modellmanipulation, aber noch keine einfache Möglichkeit, Analysen auszuführen und Artefakte abzurufen
    • Ein vollständiger Python-Client wird in Roadmap-Eintrag #17 verfolgt
  • In den internen Darstellungen wird häufig LLVM IR verwendet, sodass Tools aus dem LLVM-Ökosystem genutzt werden können

Trennung zwischen Open-Source-CLI und kostenpflichtiger UI

  • Das rev.ng-Framework ist vollständig Open Source, und über die CLI kann jedes gewünschte Ziel dekompiliert werden
  • Die UI wird in drei Formen angeboten
    • Die Cloud-UI für öffentliche Projekte kann kostenlos genutzt werden
    • Die Cloud-UI für private Projekte erfordert ein Abonnement
    • Eine vollständig eigenständige und vollständig offline nutzbare UI wird kostenpflichtig angeboten
  • Die Cloud-Nutzung funktioniert wie folgt
    • In rev.ng Hub erstellt man Projekte und lädt Mitwirkende ein
    • Die UI läuft im Browser
    • Das Backend läuft in der rev.ng-Cloud
  • Wenn es in Ordnung ist, die Projektdateien öffentlich zu machen, kann rev.ng in der Cloud-Version inklusive UI kostenlos genutzt werden
  • Auch die Installation eines On-Premises-Private-Cloud-Dienstes mit Kubernetes kann besprochen werden

1.0-Roadmap und Kontaktkanäle

  • Die Roadmap bis 1.0 ist in vier Tiers unterteilt
    • Tier 1: Alpha-Version, Demos für Bekannte, abgeschlossen
    • Tier 2: Beta-Version, Zugang zur Cloud-Version für Newsletter-Abonnenten, derzeit gestartet
    • Tier 3: offene Beta, geplant
    • Tier 4: 1.0-Release, geplant
  • Den detaillierten Fortschritt kann man auf der Roadmap-Seite verfolgen
  • Projektneuigkeiten und Support-Kanäle sind:
    • X/Twitter: Entwicklungsneuigkeiten und wichtige Ankündigungen
    • Discord: Echtzeit-Austausch mit dem Entwicklungsteam
    • Discourse: Nutzer-Support und Bug-Reports
    • GitHub: Open-Source-Entwicklung und Issue-Erfassung
    • Monthly newsletter: Teilnahme an der geschlossenen Beta und monatliche Neuigkeiten
    • E-mail: private Anfragen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-31
Meinungen auf Hacker News

  • Das Preismodell sieht so aus, dass das rev.ng-Framework vollständig Open Source ist und man in der CLI alles dekompilieren kann.
    Die UI soll für öffentliche Projekte in der Cloud kostenlos sein, für private Projekte als Cloud-Abo angeboten werden, und eine vollständig eigenständige Offline-App soll kostenpflichtig verfügbar sein.
    Zum Vergleich: Hopper kostet 100 Dollar inklusive Updates für ein Jahr https://www.hopperapp.com/index.html, Ghidra und Radare2 sind frei und Open Source und damit komplett kostenlos, während IDA Pro sehr teuer ist.

    • Binary Ninja ist ebenfalls eine gute Option.
      Nach meiner Erfahrung ist es IDA ziemlich ähnlich, aber benutzerfreundlicher und hat viele gut gestaltete Funktionen, die die Produktivität erhöhen.
      Hopper habe ich nicht ausprobiert, aber bei Ghidra und Radare2 fand ich die Entwicklungserfahrung nicht besonders gut, und der erzeugte C-Code war auch nicht gut lesbar. Allerdings bezieht sich das auf meine Nutzung vor einigen Jahren.
      Binja kostet 300 Dollar, die kommerzielle Version 1500 Dollar, und es gibt auch Studierendenrabatte: https://binary.ninja/features
    • Dekompilierung ist bei IDA/Ghidra oft der am wenigsten wichtige und am wenigsten verlässliche Teil, daher ist ein einfacher Vergleich der beiden unfair.
      Trotzdem gibt es nie genug gute C-Dekompiler, daher sind neue Ansätze immer willkommen.
    • Ich mag das Lizenzmodell mit Einmalzahlung und festgelegtem Update-Zeitraum wirklich sehr.
      Allerdings frage ich mich, wie man das durchsetzt, ohne dass die App zwingend Internetzugriff benötigt.

  • Wenn man sich die Teamseite https://rev.ng/about und die Code-Beiträge https://github.com/revng/revng/graphs/contributors ansieht, wirkt es etwas ungewöhnlich, dass der CEO (aleclearmind) deutlich mehr Commits hat als der CTO (pfez).
    Andere CEOs sagen oft, dass sie kaum Zeit zum Coden haben, und auch CTOs machen normalerweise mehr Management und weniger tatsächliches Coding.
    Wenn dieser Ansatz aber gut funktioniert, dürfte das für das Team ziemlich interessant sein. Edit: Ich habe die Timeline nicht geprüft.

    • Der CTO arbeitet hauptsächlich am gerade veröffentlichten Dekompiler-Backend revng-c: https://github.com/revng/revng-c/commits/develop/
      Am Ende sollen die beiden Repositories zusammengeführt werden.
      Und ich entwickle täglich daran, aber aus irgendeinem Grund erfasst GitHub meinen Nutzer nicht richtig.
      Es macht tatsächlich Spaß.
    • Der CTO hat in jüngerer Zeit mehr Commits gemacht, und die Commits von aleclearmind sind seit 2020 auf 0 gefallen, sodass es so aussieht, als sei es auch dort schwieriger geworden, Zeit zum Coden zu finden.
    • Ich wollte überhaupt nicht kritisieren und frage mich ein wenig, warum ich Downvotes bekommen habe.
      Im Gegenteil, mir gefiel dieses Bild, und ich fand es interessant, weil es anders war als das, was ich anderswo gesehen habe.
      Wurde es downgevotet, weil es nicht interessant oder nicht ungewöhnlich ist?

  • Das wirkt wie eine spannende Firma, die von einem der besten existierenden Bücher zur Theorie von Programmiersprachen inspiriert wurde: https://link.springer.com/book/10.1007/978-3-662-03811-6
    „Er traf auch Pietro, der sein Komplize werden sollte. Ziemlich romantisch: Er traf ihn dank des Buchs, das zur Grundlage des Unternehmens werden sollte.“
    https://rev.ng/about

    • Die ganze Geschichte zu diesem Buch geht so: Ich hatte angefangen, Compiler zu studieren, aber die Theorie war viel zu schwierig, und die bekannten Bücher passten nicht zu mir, sodass ich ziemlich entmutigt war.
      Dann entdeckte ich dieses Buch, das dicht, aber klar wirkte, und fragte meinen Betreuer, ob ich es kaufen dürfe. Er sagte: „Schau zuerst in der Universitätsbibliothek nach.“
      Die Bibliothek hatte ein Exemplar, aber es war bereits ausgeliehen. Da ich in der einzigen Gruppe war, die Compiler-Forschung betrieb, dachte ich: „Wer außerhalb unserer Gruppe wagt es, Compiler zu machen?“
      Ich ging in die Bibliothek und fragte, wer es ausgeliehen hatte, aber sie konnten es mir wegen des Datenschutzes nicht sagen. Also fragte ich nur nach dem dritten Buchstaben des Nachnamens und dem zweiten Buchstaben des Vornamens und bekam Z und I.
      Darüber habe ich ihn gefunden: https://www.deib.polimi.it/ita/personale-lista-alfabetica
      Mit der Zeit wurden wir Freunde und gründeten gemeinsam die Firma.
      Bis zum Launch war wirklich sehr viel Arbeit nötig.

  • Es wäre gut, Variablen- und Struct-Member-Namen automatisch zu vergeben, basierend darauf, wie der Code Variablen und Struct-Member behandelt.
    Zum Beispiel sollte sich der Next-Pointer einer verketteten Liste leicht als next identifizieren lassen.
    Es scheint möglich, ganz GitHub herunterzuladen, nach Variablen mit möglichst ähnlichem Layout und ähnlichen Interaktionen im Code zu suchen und bei ausreichend hoher Vertrauenswürdigkeit diesen Namen zu verwenden.

    • Früher wollte ich so etwas manuell versuchen.
      Zum Beispiel, wenn man eine Induktionsvariable erkennt, benennt man sie in i um.
      Heute scheint der richtige Ansatz dafür aber ziemlich klar darin zu bestehen, ein LLM zu verwenden.
      In dieser Phase sind wir allerdings eher diejenigen, die ein robustes Fundament bauen; sobald dieses Fundament steht, ist es vergleichsweise einfach, mit fertigen Modellen Namen umzubenennen oder Kommentare hinzuzufügen.
      Der Kern ist: Die schwierige Dekompilierungsarbeit, die 100 % Genauigkeit erfordert, übernehmen wir, während man für Dinge wie Namen und Kommentare, bei denen Näherungen akzeptabel sind, LLMs einsetzen kann.
      Skripte zum Umbenennen zu schreiben ist jedenfalls recht einfach, siehe Dokumentation: https://docs.rev.ng/user-manual/model-tutorial/
    • Das wäre wirklich cool und fühlt sich ähnlich an wie http://jsnice.org/.
      Ein Paper, das beschreibt, was JSNice intern macht: https://files.sri.inf.ethz.ch/website/papers/jsnice15.pdf
    • Klingt ähnlich wie Sidekick von Binary Ninja.
    • So etwas wie GitHub Copilot fürs Reversing?

  • Funktioniert bei meiner ELF-Datei nicht
    Wenn ich ./revng artifact --analyze --progress decompile-to-single-file ../maytag.ko ausführe, erscheint Only ELF executables and ELF dynamic libraries are supported, und die Datei wird als ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped angezeigt
    Werden FreeBSD-Binaries nicht unterstützt?
    Update: Ich hatte übersehen, dass Kernel-Module nicht unterstützt werden, und es liegt wohl weniger an FreeBSD, sondern eher daran, dass es keine einfache ausführbare Datei ist

    • Könntest du ein Issue auf GitHub eröffnen und das Binary anhängen?
      Das zu laden dürfte nicht allzu schwierig sein

  • Ich hoffe, dass dem Collaboration-Workflow viel Aufmerksamkeit gewidmet wird
    Ich habe so etwas wie IDA Teams zwar nicht ausprobiert, aber wenn eine reibungslose Reverse-Engineering-Erfahrung wie bei Google Docs möglich wäre, wäre das großartig

    • Genau das ist unser Ziel
      Früher haben wir UI-basiert QtCreator verwendet, was eine furchtbare Entscheidung war
      Danach sind wir zu VSCode gewechselt, und zufällig konnte es auch im Browser laufen
      Also haben wir mit etwas Kubernetes einen Cloud-Decompiler gebaut, der genau dieselbe User Experience bietet wie die vollständig eigenständige Version
      Der Collaboration-Teil braucht noch mehr QA, funktioniert aber grundsätzlich
      Die Architektur ist sehr einfach: mehrere Clients an einem Daemon
      Ich glaube, inspiriert wurden wir von der früheren Erfahrung bei CTFs, auf einer X-Session auf dem Server mit mehreren IDA-Fenstern und mehreren Cursorn zu „kollaborieren“. Das war eine extrem verfluchte Methode, hat aber funktioniert

  • Gibt es Pläne, Type Inference zu unterstützen?
    Aktuell scheinen alle Variablen als generic64_t angezeigt zu werden; es wäre schön, wenn Typen wie bei Ghidra automatisch erkannt würden. Natürlich liegt auch Ghidra gelegentlich daneben

  • Sieht interessant aus
    Ich würde gern die vollständig eigenständige Version ausprobieren
    Gibt es schon ungefähr Neuigkeiten zum Preis? Es wäre schön, wenn es auch für Hobby-Nutzer erschwinglich wäre

  • Dass es mehr Tools fürs Binary-Hacking gibt, ist immer erfreulich
    Da ich es vielleicht selbst ausprobieren möchte, hinterlasse ich ein paar übermäßig detaillierte Vorschläge zum gewählten Packaging-Format
    source ./environment ist kein gutes Zeichen. Ich habe mir das tar geholt, und es setzt tatsächlich mehrere Umgebungsvariablen, darunter PATH; zum Glück aber nicht LD_LIBRARY_PATH
    Die meisten haben den Präfix HARD_ und sind vermutlich eindeutig, aber REVNG wirkt klarer, und Kollisionen mit bestehenden Umgebungsvariablen sind schlecht
    Es setzt auch AWS_EC2_METADATA_DISABLED="true"; ich nutze kein AWS, also geht bei mir nichts kaputt, aber generell wirkt das verdächtig
    RPATH_PLACEHOLDER, HARD_FLAGS_CXX_CLANG, ein langer PATH, Strings wie mingw32/gentoo/mips usw. wirken anfällig
    Wenn in der Anleitung zum Ausführen steht: „Ändern Sie jetzt Ihre Umgebungsvariablen“, gebe ich normalerweise auf; das korreliert stark mit Programmen, die auf Nicht-Ubuntu-Systemen nicht richtig funktionieren
    Wenn man den Kontrollfluss einer Anwendung an die Ausführungsumgebung koppelt, gibt es mehr Fehlermodi, als zunächst sichtbar ist, und es ähnelt sehr globalen Variablen
    Clang kann beim Build Default-Werte wie -DCLANG_DEFAULT_CXX_STDLIB=libc++ einbacken, und DEFAULT_SYSROOT ist ebenfalls nützlich
    Selbst wenn man rpath verwendet, kann das DT_RUNPATH des Binaries überschrieben werden, wenn der Nutzer es mit gesetztem LD_LIBRARY_PATH ausführt
    Heutzutage bedeutet -Wl,rpath tatsächlich nicht rpath, sondern das weniger nützliche runpath; vermutlich ist der gewünschte Aufruf -Wl,rpath -Wl,--disable-new-dtags, damit der Loader bei der Bibliothekssuche LD_LIBRARY_PATH ignoriert
    Mit einer Kombination aus Clang-Build-Flags, statischem Linken und dem Einbetten von Binaries in Binaries ließe sich die Manipulation von Umgebungsvariablen wahrscheinlich vollständig vermeiden
    Dass das clang-16-Binary dynamisch gelinkt ist und zur Laufzeit Dinge wie libLLVMAArch64CodeGen.so.16 sucht, erhöht ebenfalls die Zahl der Fehlermodi
    LLVM_BUILD_STATIC=ON kann die Probleme verringern, bei denen in Umgebungen mit aktiviertem HPC-Modul-Toolchain die falschen Bibliotheken aufgegriffen werden
    Die Tools sind gegen libc++.so, libc++abi.so usw. gelinkt; statisches libc++ wäre eine Überlegung wert, und zumindest libc++abi und libunwind sollte man besser statisch in libc++ linken
    Meine Geduld für die Auslieferung dynamisch gelinkter Programme unter Linux ist völlig erschöpft
    Wenn source ourhack aus einem README oder von einem Modulsystem übrig gelassene Umgebungsvariablen die Runtime-Bibliotheken meiner Anwendung verändern, werden Nutzererfahrung und die späteren Kosten für Bug-Reports furchtbar
    Im Vergleich dazu ist statisches Linken wirklich gut

    • Die meisten Bedenken bezüglich Eingriffen in die Umgebung treffen eigentlich nur unter der Annahme zu, dass man tatsächlich source environment ausführt
      Tatsächlich haben wir das nur vorgeschlagen, damit für Demo-Binaries das von uns ausgelieferte GCC verwendet wird; die vorgesehene Nutzungsweise ist das Skript ./revng
      In diesem Fall wirken sich die Umgebungsänderungen nur auf den Aufruf von revng aus
      Die Dokumentation ist hier: https://docs.rev.ng/user-manual/working-environment/
      Es wäre gut, eine Warnung zu source ./environment hinzuzufügen
      Wir haben viel Zeit darauf verwendet, LD_LIBRARY_PATH nicht zu benutzen, und einen vollständig in sich geschlossenen Satz von Binaries gebaut, bei dem jedes ELF seine Abhängigkeiten über relative Pfade referenziert. LD_LIBRARY_PATH ist böse
      Die HARD_-Variablen werden nur in Compiler-Wrappern verwendet, und ich halte tatsächliche Kollisionen für sehr unwahrscheinlich
      Die ursprüngliche Diskussion zu AWS_EC2_METADATA_DISABLED="true" steht unter https://github.com/revng/revng/pull/309#discussion_r12805759...
      Man könnte das auch durch Patchen des AWS SDK vermeiden, aber in jedem Fall hat es nur Auswirkungen, wenn rev.ng in der Cloud läuft
      RPATH_PLACEHOLDER und HARD_FLAGS_CXX_CLANG werden verwendet, wenn revng die übersetzten Binaries linkt, und sind nicht wichtig, wenn man sich nicht für End-to-End-Binary-Translation interessiert
      Wir wollen absichtlich DT_RUNPATH. DT_RPATH ist deprecated, und es kann Use-Cases geben, in denen unsere Bibliotheken per LD_LIBRARY_PATH ersetzt werden müssen
      Den Einwand zur „Umgebungsmanipulation“ halte ich nur dann für stichhaltig, wenn es nicht um private Umgebungsvariablen geht
      RPATH_PLACEHOLDER, HARD_*, REVNG_* sind private Variablen und dienen alle der Binary-Translation
      Man könnte sie in einen enger gefassten Compiler-Wrapper verschieben, aber da wir Python mit ausliefern, können wir die Umgebung nicht vollständig eliminieren
      Es reicht nicht, einige Flags in Clang einzubacken. Diese Flags beeinflussen auch den Linker, und es gibt Wrapper-Funktionen, die sich nicht einfach einbauen lassen
      Man kann sie allerdings an einen noch privateren Ort verschieben
      Du scheinst dynamischem Linken gegenüber skeptisch zu sein; wir haben hier Aufwand investiert, und inzwischen funktioniert es ziemlich gut und findet immer den richtigen Ort
      Wir hardcoden keine absoluten Pfade, und es gibt auch keinen Installationsschritt, der Binaries „patcht“. Das entpackte Verzeichnis kann überallhin verschoben werden
      Unsere Lösung verwendet kein LD_LIBRARY_PATH; stattdessen referenzieren alle Binaries einander robust über $ORIGIN
      Wenn man ./root/bin/python ./root/bin/revng artifact --help ausführt, sieht man, dass es funktioniert
      Noch einmal: source environment ist fast nur für Demos gedacht; in der realen Nutzung führt man nur ./revng aus, und die Umgebung bleibt unverändert
      Wir liefern auch Python mit aus, aber man muss es nicht verwenden. Man kann ./revng nutzen oder im Daemon-Modus über das Netzwerk interagieren
      Der Ansatz ist, die YAML-Projektdatei mit dem gewünschten Scripting-Tool zu parsen und zu ändern und anschließend ./revng artifact aufzurufen oder mit dem Daemon zu interagieren: https://docs.rev.ng/user-manual/model-tutorial/
      Im Ergebnis nutzen wir eine aktuelle Python-Version, und die Nutzer können die Sprache verwenden, die sie möchten

Künftig werden wir einen Hilfs-Wrapper auf PyPI bereitstellen, der mit verschiedenen Python-Versionen kompatibel ist.
Kurz gesagt: nicht source ./environment ausführen, sondern ./revng verwenden.
Es freut mich, dass es Leute gibt, die auf solche Details achten.
In der nächsten großen Iteration könnten wir nix + Mount-Namespace einführen, um /nix/store ohne Root-Rechte nutzbar zu machen, was vieles vereinfachen könnte.
Solche Diskussionen führt man vielleicht besser auf dem Discord-Server als hier.

  • Glückwunsch
    Bereut ihr, das Lifting QEMU TCG überlassen zu haben, oder hat es gut funktioniert?
    • Es hat sehr gut funktioniert. Es gibt zwei Dinge, die wir bereuen
      Erstens haben wir unseren QEMU-Fork über Jahre nicht rebased, was zu einer schlechten Situation geführt hat
      Trotzdem hat ein Teammitglied noch heute erfolgreich mit dem aktuellen QEMU geliftet, und wir konnten auch den Qualcomm-Hexagon-Code liften, bei dessen Unterstützung in QEMU wir geholfen haben
      Am Ende werden wir damit der erste richtige Hexagon-Decompiler sein
      Zweitens ist das Frontend durch unseren zu starken Fokus auf QEMU eng an QEMU gekoppelt
      Um nun zusätzliche Frontends zu unterstützen, die nicht auf QEMU basieren, ist etwas Aufwand nötig, aber unmöglich ist es nicht
      Die Idee ist, dass Nutzer beim Hinzufügen von Unterstützung für eine neue Architektur in C nur eine CPU-Zustandsstruktur und ein paar Funktionen definieren müssen, die darauf arbeiten
      Sie müssen unsere interne Darstellung nicht lernen
      Kurz gesagt: QEMU war eine ausgezeichnete Wahl, und weil es so gut funktionierte, haben wir diesen Teil der Codebasis lange nicht angerührt, wodurch technische Schulden entstanden sind; die räumen wir aber gerade auf