Re-Engineering: Ist ein FPGA-Programmierfile per KI dekodierbar?

Hier die Antwort meiner kleinen Orts-KI:

profile qwen3-coder:30b Um diese Frage präzise beantworten zu können, benötige ich zunächst weitere Informationen. Es gibt verschiedene Arten von FPGA-Programmfiles, z.B. HDL-Dateien (wie VHDL oder Verilog), bitstream-Dateien (wie .bit oder .rbf) und andere Formate.

HDL-Dateien (VHDL/Verilog): Diese sind Textdateien, die von Menschen lesbar sind und in der Regel nicht direkt per KI dekodiert werden müssen. Sie können jedoch mit KI-gestützten Tools analysiert oder generiert werden. Bitstream-Dateien: Diese sind binäre Dateien, die von einem FPGA direkt verwendet werden können. Obwohl sie binär sind, kann man sie mit KI-Tools analysieren, um ihre Struktur zu verstehen, aber nicht unbedingt "dekodieren" im herkömmlichen Sinne. Andere Formate: Es gibt auch spezifische Formate für verschiedene FPGA-Hersteller (z.B. Xilinx oder Intel), die möglicherweise andere Eigenschaften aufweisen. Welche Art von FPGA-Programmfile meintest du genau? Möchtest du wissen, ob es möglich ist, einen bestimmten Typ von Datei mit KI zu analysieren oder zu dekodieren? Falls ja, können wir den genauen Dateityp oder den Inhalt näher betrachten.

Es geht um .bit-Dateien von Xilinx. Kann eine KI diese analysieren und deren Funktionsweise erklären?

profile qwen3-coder:30b Ergebnis von ask_user ansehen Ich werde eine allgemeine Erklärung über .bit-Dateien von Xilinx und deren Analyse mit KI bereitstellen. Diese Dateien sind binäre Dateien, die von Xilinx-FPGAs verwendet werden, um die Konfiguration des Chips zu speichern.

Allgemeine Informationen zu .bit-Dateien von Xilinx .bit-Dateien sind binäre Dateien, die zur Konfiguration von Xilinx-FPGA-Chips (Field-Programmable Gate Arrays) verwendet werden. Sie enthalten die erforderlichen Daten, um den FPGA auf eine bestimmte Funktionalität zu programmieren.

Struktur einer .bit-Datei Eine .bit-Datei besteht aus mehreren Abschnitten:

Header: Enthält Informationen über die Datei, wie z.B. die Version und das verwendete FPGA. Configuration Data: Die Hauptdaten, die den FPGA konfigurieren, bestehen aus Bitmuster, die die Verbindungen und Funktionen der FPGA-Logik definieren. Checksums: Um sicherzustellen, dass die Datei nicht beschädigt ist. Analyse mit KI Obwohl .bit-Dateien binär sind, können sie mit KI-Tools analysiert werden:

Struktur- und Inhaltserkennung: KI kann helfen, die Struktur der Datei zu erkennen und den Inhalt zu interpretieren. Funktionsanalyse: Durch maschinelles Lernen können Muster in den Konfigurationsdaten identifiziert werden, was zur Erklärung der Funktionalität des FPGAs führen kann. Vergleich mit anderen Dateien: KI kann .bit-Dateien mit bekannten Mustern vergleichen, um ihre Funktion zu verstehen. Einschränkungen Binäre Natur: Da .bit-Dateien binär sind, ist die direkte Interpretation durch KI schwierig. Hersteller-spezifisch: Die Struktur kann von Hersteller zu Hersteller variieren. Zugriff auf Dokumentation: Um die vollständige Funktionsweise zu verstehen, benötigt man oft zusätzliche Dokumentation oder spezifische Tools. Fazit Obwohl .bit-Dateien nicht direkt mit KI dekodiert werden können, kann KI helfen, ihre Struktur und Funktionalität zu analysieren. Es ist wichtig, dass die Analyse durch geeignete Tools und zusätzliche Informationen ergänzt wird.

Wenn du eine spezifische .bit-Datei zur Analyse hast, können wir den Prozess genauer durchgehen.

ps: Ich hab inzwischen gelernt, das binäre Dateien erst mal ins Hex-Format umgewandelt werden sollten, dann kann die KI mehr damit anfangen.

mfg

Daraus die Funktion zu ermitteln, dürfte schwierig sein.

Ich denke, das kommt drauf an. :-D

Es gibt fuer einige wenige FPGAs auch Opensourcetools. Also haben Menschen da herausgefunden wofuer die einzelnen bits stehen. In dem Falle kann die KI das sicher auch und das 1000x schneller.

Wenn aber gar nicht bekannt ist was ein Bit bewirkt sieht es schwierig aus.

Aber war es nicht so das man die Bitfiles der groesseren FPGAs auch verschluesseln kann? Dann wuerde das ja das Problem loesen und gleichzeitig beweisen das man sich ohne Verschluesselung berichtigt Sorgen machen muss.

Vanye

Rolf schrieb:

AES-Encryption geht meines Wissens nur so, daß man das file als fertig programmiertes Flash auf dem PCB ausliefert und unauslesbar macht.

Bei Xilinx kann man den Schlüssel ins FPGA speichern, entweder volatil per Batterie gepuffert oder einmalig in eine Fuse. Bei der Gelegenheit kann man auch das jtag per Fuse durchbrennen. Das mit zum passenden Schlüssel verschlüsselte File kann man in den Flash packen und nach Belieben updaten, es wird dann nur geladen wenn es mit dem richtigen Schlüssel verschlüsselt ist. In den Fuse Optionen kann man auch einstellen, dass keine unverschlüsselten Files geladen werden dürfen, also geht dann nur noch eures.

Interessant!

Welches Verschlüsselungsverfahren wird da angewandt, und wie groß kann der schlüssel sein?

mfg

Ich habe mir den Spass vor einer Weile mal gegeben, von einem Bit-File ist man mit KI-Fuzzing relativ schnell bei der Architektur, somit bei einer Netzliste. Einen in der Fabric versteckten Schlüssel auffinden: Check. Der Crypto-Bootloader (noch Spartan6) ist also hinfällig. Aus der Netzliste wirklich wart- und lesbare HDL herzustellen ist schon schwieriger, aber neuere Claude-Agenten sind erschreckend gut im Aufräumen. Wenn einzelne Module mit Bauchgefühl von der HI isoliert werden, kannst du auf jeden Fall eine Rechenpipeline relativ gut identifizieren und schauen, was da genau passiert. Schwieriger wird es schon bei obskuren Architekturen, wie kleinen Rechen-Units mit eigenem oder etwas umgemapptem Transputer-Style-Befehlssatz.

Im Grunde genommen müssen wir uns dran gewöhnen, dass es bald keinen Unterschied zwischen Open und Closed-Source mehr geben wird. Dann verlagert sich die Schlacht auf die juristische Ebene. Ob es dann einfacher wird, dem Konkurrenten den Klau nachzuweisen, sei dahingestellt, ob sich Richter auf eine KI-Analyse stützen dürfen ist ja auch noch nicht geklärt.

Thema "Gegen Auslesen schützen": Der Crypto-Bootstream ist solange sicher, bis der Key irgendwo rauspurzelt. Da sind schon einige super ausgedachte Konzepte völlig gegroundet worden, weil es dann eben doch ging, sich in den JTAG-Zugang reinzuglitchen, oder die schwereren Jungs offenbar mit dem AFM (atomic force microscope) auffahren. Schlussendlich ist man immer wieder bei Security through obfuscation, oder bei sehr architekturspezifischen Lösungen. FPGAs mit internem Flash wo wirklich der JTAG gefuset werden kann helfen schon mal. Versuche, das z.B. beim MachXO3 zu umgehen, resultierten zumindest in einem komplett toten Chip.

Was die Zähler angeht: Viele Glitch- oder Seitenkanalattacken basieren darauf, dass irgendwann mal ein einfacher Binärcounter umschlägt und sich das dann in der Versorgungsspannung messbar macht. Brauchte noch nicht mal KI um diese zu identifizieren und in die "besseren" Gray- oder LFSR-Counter umzuwandeln.

Da sind schon einige super ausgedachte Konzepte völlig gegroundet worden, weil es dann eben doch ging

Alles geht irgendwann und irgendwie. Man muss nur den Aufwand hoch genug treiben damit ehrlich nachprogrammieren weniger aufwendig ist als zu kopieren.

Man darf sich dann nur nicht ins Internet stellen und ein:

Haha, ich bin die coole XY-Firma, mein Megaansatz bekommt ihr nicht geknackt.

Weil damit motiviert man dann gleich 1000Studenten mit zuviel Zeit, die sich herausgefordert fuehlen und da ist dann mal einer drunter der es doch schafft. :)

Vanye

Lotta schrieb:

und wie groß k

The 7 series FPGA AES encryption logic uses a 256-bit encryption key.

Martin S. schrieb:

Im Grunde genommen müssen wir uns dran gewöhnen, dass es bald keinen Unterschied zwischen Open und Closed-Source mehr geben wird.

Oder das die KI mit bisschen Vibe-Coding das gleiche hinbekommt, für was Entwickler früher paar Jahre gebraucht haben ;-) Interessante Zeiten....

Oder das die KI mit bisschen Vibe-Coding das gleiche hinbekommt, für was Entwickler früher paar Jahre gebraucht haben ;-) Interessante Zeiten....

Das denke ich auch, allerdings gilt das IMHO nur fuer die ersten 90%, die letzten 10% sind dann aber Erfahrungen aus der Praxis die in ein Projekt eingeflossen sind und die sich niemanden mehr so richtig logisch erschliessen. Da wird es dann hart, besonders wenn der Nachprogrammierer nicht weiss was er macht.

Vanye

IMHO grenzt das Anliegen des TO schon an Wunderglauben. Es scheint ja heutzutage nicht ungewöhnlich das man von einer KI Wunder erwartet, dabei ist eine KI nur ein automatisierter Internetschnüffler ...

In der Vergangenheit wurden einfache FPGA's (oder was man so nannte, es waren wohl eher CPLD) bezüglich des bitstreams partiell decodiert. Aber dazu waren BlackBox-Messungen an realen Exemplaren nötig. so an Lattice MAchXO Typen geschehen (Project Oxide -> https://github.com/gatecat/prjoxide/blob/main/README.md ). Auch bei Lattice ice wurden male Erfolge verlautbart:

• https://hackaday.com/2015/03/29/reverse-engineering-lattices-ice40-fpga-bitstream/

Also müsste man erstmal einen passenden teststand bauen den man dann einige Zeit durchlaufen lässt. Das erinnert mich irgendwie an Blechtley park und seine Brute-Force machinery

Sollte man damit Erfolg haben, hat man immer noch nicht alle nötigen Daten für ein eigenes P&R, es fehlen die (internen) timing-Infos. Und ohne die kann man die Limits für die Pfadlängen abhängig von den User-timing-constraints nicht überprüfen.

Und hinsichtlich der Zukunfssicherheit sind auch nicht alle Hürden genommen, vom Hersteller undokumentierte Feauture fallen auch mal in späteren Revision/Varianten weg. In den schnellen transceivern von AMD (GTH u.ä.) sollen etliche undokumentierte Feature Register-settings stecken.

Zur Verschlüsselung von bitstreams (zwecks authentifizierung) ist einiges geforscht und gecrackt wurden: https://www.isec.tugraz.at/wp-content/uploads/2022/09/fpga_bitstream_encryption.pdf

Deshalb lassen sich die Herstelle immer wieder Neues einfallen.

Schonmal bitstream-komprimierung getestet, da ist zwar nichts verschlüsselt aber der Angreifer ist erstmal verwirrt: https://docs.amd.com/r/2022.2-English/ug835-vivado-tcl-commands/write_bitstream