 Herzlich Willkommen zur Übersetzung vom Vortrag HAL, dem Open Source Hardware Analyse Tool. Wir sind Goonys Pro und Tribut und wir sind froh den Vortrag für euch übersetzen zu können. Wenn ihr Feedback für uns habt, meldet euch mit dem Hashtag C3T auf euren Lieblingssozialenetzwerk. Der Speaker heute heißt Max Hoffmann. Er hat HAL geschrieben den Open Source Hardware, das Hardware Analyse Tool und er wird uns heute die Grundlagen und die Herausforderungen bei Hardware Reverse Engineering vorstellen und wird uns zeigen, was er mit dem Framework machen kann, dass er und sein Team entwickelt. Große Runde von Applaus bitte für Max Hoffmann. Herzlich Willkommen auch von meiner Seite. Herzlich Willkommen für all die Leute, die so früh erschienen sind und auch diejenigen, die zu Hause geblieben sind und am Stream zu schauen. Wie fängt man den letzten Tag das Kongressus an? Ich dachte, wir fangen am besten mit einem Zitat an. Vertraut mir, ich bin ein Ingenieur. Es ist ein sehr... im Wesentlichen jeder Ingenieur hat das schon mal gesagt. Und wenn wir uns anschauen, was es draußen gibt in der echten Welt, dann stellt sich raus, also das ist auf jeden Fall richtig. Wir sehen viele Beispiele für großartige Ingenieurleistungen in der Welt. Und die sind großartig, da sind wir wirklich begeistert davon. Diese großartigen Beispiele betreffen so viele Gebiete. Technologie ist für uns hier aber der Hauptfokus, was Ingenieursleistungen angeht. Und wenn man darüber nachdenkt, unsere aktuelle Technologie, alles, das wir hier die letzten drei Tage erlebt haben, die ganze Welt zu ihrem jetzigen Zeitpunkt wird von Technologie vorangetrieben. Und das ist das Ergebnis von vielen Jahren von Ingenieuren. Und wenn ich jetzt Ingenieure definieren sollte, dann wäre meine Beschreibung eine hochlevelige Beschreibung umzuwandeln in eine tatsächliche Sache. Es ist jetzt nicht alles, aber ich denke, erfasst ganz gut den Kern dessen, was ein Ingenieur täglich tut. Und die Menschheit wird von Koriosität, von Neugier getrieben. Und wenn wir es wirklich faszinierend ist, dann wollen wir es verstehen. Und wie, wenn man ein YouTube-Video, als ich anschaue, da sind also ganz viele Jahre von Ausbildung mit drin. Wie können wir das verstehen? Wie können wir daraus was lernen? Und die einfachste Antwort ist, indem wir darüber reden. Wir sprechen mit Ingenieuren, mit den Teams, die dafür verantwortlich sind. Aber wenn es niemanden gibt, der uns das beibringen kann, oder niemand das machen will, oder niemand das darf, dann müssen wir es uns wohl selber anschauen. Also wenn der Weg von der Beschreibung auf einem hohen Ebene nicht da ist, dann müssen wir sie rausfinden und das nennt man Reverse Engineering. Also um das andersrum noch mal zu definieren, Reverse Engineering ist, wir analysieren eine Sache, um die Beschreibung, die hochlevelige oder eine hochlevelige Beschreibung wieder herzustellen. Und das geht hier um eine Hochlevel-Beschreibung, also nicht diejenige, sondern es geht um eine, vielleicht auch nur eine Annäherung, etwas Äquivalentes dazu. Und wenn wir darüber nachdenken, irgendeine Art von Reverse Engineering haben wir in unserem täglichen Leben alle schon gemacht. Wenn man über das Auto nachdenkt, wenn der Motor kaputt geht, dann muss man sich das anschauen. Mit großer Wahrscheinlichkeit habt ihr diesen Motor nicht gebaut, aber ihr müsst verstehen, wie er funktioniert. Und das ist schon Reverse Engineering. Oder noch abstrakter, wenn man einen leckeren Cookie macht, dann will man wissen, wie der Bäcker den Cookie hergestellt hat. Wie könnte das Rezept ausgesehen haben? Also geht man von einer Sache zu einer Beschreibung. Und hier geht es aber um Hardware und spezieller um Chips. Also diese ganzen Mikrochips, die in den Smartphones eingebaut sind, in den Gaming-PCs und so weiter. Und eine grundlegendere Frage ist, warum würde das überhaupt jemand machen wollen? Warum will man sich Chips und wie die gemacht werden überhaupt anschauen? Naja, Neugier als allererstes. Aber man könnte vielleicht auch Fehler verstehen oder den lokalisieren wollen. Wenn das ein Produkt ist, das schon produziert ist, das schon alle Tests bestanden hat, dann muss man vielleicht reinschauen. Und auch von einer rechtlichen Perspektive möchte man vielleicht auch erkennen können, dass wenn jemand das Design, das du entwickelt hast, benutzt hat, ohne Gebühren dafür bezahlen, also Patentrechtsverletzungen. Und das sind die üblichen Use Cases. Aber es gibt auch noch einen. Also man könnte zum Beispiel Trojaner erkennen wollen, die in jemand anderes, aber man könnte vielleicht auch Trojaner einfügen wollen. Und auf einer größeren Skala möchte man einfach intellektuelles Eigentum klonen oder klauen. Und auch dafür könnte man Reverse-Engineering machen. Und das wurde auch in den Medien behandelt, die letzten Jahre. Also zum Beispiel hier der Artikel The Big Heck, der in Bloomberg Business Week erschienen ist. Und nur ein Disclaimer, also das sind nur Anschuldungen. Nichts wurde bewiesen. Am Ende gab es keine definitiven Aussagen. Was Sie behaupten haben, was Sie gefunden haben, ist im Server-Hardware von der Firma Super Micro gab es einen Hardware-Implant-Hard, ein zusätzlicher kleiner Chip auf diesem Server-Board, das Zugriff erlaubt hat für einen angeblich hier da innerhalb dieses kleinen weißen Kreises, dieses kleine Ding war die Hardware-Backdoor. Und die Behauptung ist, dass das während der Konstruktion des Boards, also während die Teile zusammengesetzt wurden, in China wurde das eingebaut. Und Sie haben behauptet, dass der Chip so aussah wie ein passiver Komponent, also es wurde in gewisser Weise getarnt, so auszusehen, als wäre es etwas Passives, aber tatsächlich war es etwas, das aktiv mit Kommunikation eingegriffen hat. Und dann gab es den Telekommunikationsverbot, also das Bootverbot für Huawei, das immer noch in Kraft ist. Und ich will in diesem Talk zuerst über die Einführung geben, über die Grundlagen von Hardware Reverse Engineering, aber auch Hardware Engineering. Also wie man umgekehrt den Weg gehen kann, muss man sich auch den Vorwärtsweg anschauen. Und dann spreche ich über HAL, also das Hardware-Analyse-Tool, und dann will ich über die Forschung sprechen, die an der Universität noch passiert. Also Disclaimer erstmal, das ist ein Grundlagenvortrag, ich kann euch nicht zu Experten machen in dieser kurzen Zeit, aber ich möchte einen groben Überblick geben, damit ihr auch mit anderen sprechen könnt, damit ihr die grundsätzlichen Probleme versteht und die Grundlagen von Hardware Reverse Engineering. Also, sprechen wir erst über Hardware-Design, also ich denke die meisten von euch wissen, kennen sich mit Software relativ gut aus, aber bei Hardware ist es häufig schwierig, ich werde mich bemühen Analogien herzustellen zu Software, damit ihr das möglichst gut verstehen könnt. Und ich werde in diesem Talk mich auf zwei verschiedene Arten von Chips, integrierte Schaltungen. ASIC sind die ersten, anwendungsspezifische integrierte Schaltungen und das zweite sind FPGAs, also vor Ort programmierte Logikgatteranordnungen. Und ein ASIC ist in gewisser Weise der klassische integrierte Chip, das wird für einen speziellen Anwendungsfall optimiert und die Logik darin wird über Bulliengatter und Flip Flops implementiert. Das gibt noch ein paar andere, aber das sind die zentralen Elementen, die aus denen das besteht. Und FPGAs sind neu programmierbare Hardware. Also der ASIC, der ist fest, also wenn man das gebaut hat, dann macht er, was es macht, aber man kann es nicht mehr ändern. Bei FPGA, klar, die Hardware ist auch fest, aber man kann ihn neu programmieren. Das heißt, man kann da einen großen Level, also eine große Menge von Freiheitsgraden haben, um das neu zu konfigurieren. Und die Logik wird über Lookup-Tables, also über Nachschlagetabellen und über Routing-Elemente implementiert. Die Idee ist, man nimmt die logischen Funktionen, man legt sie in die Nachschlagetabellen, die Lookup-Tables und dann verbindet man die Ein- und Ausgaben mit den Routing-Elementen, so wie ihr das gerne haben wollt. Und da kommt am Ende programmierbare Hardware raus. Also die ist in gewisser Weise dynamisch, man kann die ändern, man kriegt die Vorteile von Programmierung, aber mit dem Parallel-Vorteil von Hardware. Und da schauen wir uns das hier an, wie man da anfängt. Es gibt was ganz Ähnliches wie eine Programmiersprache. Das ist eine Hardware-Beschreibungssprache, HDL. Und das ist ein Beispiel. Es gibt viele Hardware-Beschreibungssprachen und der Code, den ihr schreibt, der beschreibt die Hardware, die ihr am Ende haben wollt. Das ist dieses kleine Beispiel, beschreibt dieses Schaltungsdiagramm. Und wenn wir jetzt nochmal über Software nachdenken, der Compiler, den ihr benutzt, muss in der Lage sein, ein gewisses spezifisches Instruktionenset auszuführen. Und der muss die Anweisungen, die ihr schreibt, auf dieses Instruktionenset abbilden. Und das ist ganz ähnlich bei Hardware und diese Dinger heißen Gata Bibliotheken, Gate Libraries. Und die enthalten alle die Elemente, die ihr benutzen könnt, also für ein FPGA alle programmierbaren Elemente, damit ihr wisst, womit ihr arbeiten könnt und für ASICs beschreibt es alles, was man aus Transistorern zusammenbauen kann. Ja, also alles wird aus diesen Elementen zusammengebaut. Ein anderer Unterschied zu Software ist, dass Software kompelliert wird. Also meistens jedenfalls HDL jedoch wird synthesisiert und wird zusammengesetzt. Diese Zusammensetzung, das ist die Architekturabbildung, wo man die Beschreibung nimmt und es auf diese Gate Element abbildet. Also die Baustelle, die man hat. Der zweite Schritt ist dann das Placement, wo man die Baustelle auf den Layout macht und dann verbindet man sie. Das Resultat dieser Synthese heißt Netzliste. Das ist das, worum wir uns heute beschäftigen. Also in einem Bild, wir starten mit dem HDL Code, dann kommt die Synthese und am Ende kommt raus die Netzliste. Was ist diese Netzliste? Also wir erinnern uns an Physik. Diese Schaltkreise hier mussten wir alle mal zeichnen. Das ist im Wesentlichen eine Netzliste, zumindest eine Abbildung davon. Wir können zum Beispiel mal hier diese Lampe mit irgendeinem Begatter ersetzt und dann kommt das hier raus. Alles ist in der Netzliste drin. Die Elemente, die Gaze, die Flip Flops, die Verbindungen und auch weitere Informationen wie die Position beispielsweise oder irgendwie Ströme, Leitungsstärken etc. Um die Analogung zu Software wieder zu ziehen, die Netlist ist einfach wie Assembly in Software. Um den Blick auf das große Bild zu richten, wir wissen jetzt wie wir zur Netzliste kommen. Wie kommen wir dann eigentlich zum FPGA oder zum ASIC? Starten wir mal mit dem FPGA. Der FPGA ist neu konfigurierbar, wie wir wissen. Wir müssen unsere Netzliste jetzt in den FPGA reinbringen. Das ist ziemlich einfach eigentlich. Wir nehmen die Netzliste und übersetzen sie in einen Konfigurations-Bitstrom. Diese Konfiguration bildet einfach die Elemente der Netzliste auf die Elemente des FPGAs ab. Und dann tun wir den Bitstrom auf den FPGA. Der FPGA konfiguriert sich. Fertig, super. Jetzt schauen wir uns den ASIC an. Hier schaut die Sache ein bisschen anders aus. Wenn wir uns einfach diese Schaltung angucken, sehen wir sofort ein Problem. Wie können wir eigentlich etwas wie diese Kreuzung hier implementieren? Wenn wir die jetzt einfach mal so auslegen, dann kriegen wir ja einen Kurzschluss. Was ist die Lösung? Die Lösung ist, hier mehrere Schichten oder Ebenen zu nehmen. Und das zeigen wir hier auf diesem Bild. Also im Wesentlichen tut man alle Logik, also die ganzen Elemente in die unterste Ebene und alle weiteren Ebenen oben werden nur verwendet, um die zu verbinden. Und man kann also hier sehen auch diese Metalldrähte. Und die Ornchen-Elemente sind sogenannten VIAs. Das sind VIA-Verbindungen, die verbinden die einzelnen Ebenen miteinander. Das hier nennen wir ein Layout. Und dieses Layout, das wird man an eine Fertigungsanlage schicken und fertig. So, dann werden wir das Bild wieder angucken. Wir wissen also, wie wir von HDL nach zu einem Netzliste kommen und dann am Ende zu einem FPGA oder zu einer Masik. So, nach diesem kurzen Überblick über Hardware Engineering und schauen wir uns jetzt mal das Hardware Reverse Engineering an. Natürlich, wie immer, fangen wir mal an mit der Software. In Software ist es so, dass wir normalerweise mit einem Bein reached hatten, also mit den BNAIR-Code. Und wenn man das nicht hat, dann muss man den BNAIR-Code erst aus dem Flasch sich rausholen, aus dem Speicher sich rausholen. Und das wandelt man in den Assembler-Code um und vielleicht reicht es schon. Und ansonsten geht es einfach noch weiter nach C++ auf irgendeiner Hochsprache. Das ist dann die andere Analysephase. Diese Schritte gibt es auch in Hardware. Die schauen ein bisschen anders aus. Fangen wir mal wieder an mit den FPGAs. Also, wie ich schon sagte, der FPGA wird konfiguriert von einem Bittstrom. Der Bittstrom, die hat man da irgendwie reingesteckt. Wie kriegen wir ihn wieder raus? Naja, es zeigt sich tatsächlich, es ist so, dass der Bittstrom eigentlich, also dass der FPGA durch einen externen Speicher konfiguriert wird. Und wir müssen uns eigentlich gar nicht mit dem FPGA selbst beschäftigen. Wir müssen einfach nur die Inhalte von dem Flaschspeicher auslesen und dann haben wir schon den Bittstrom. Das heißt, wir müssen auch vom Bittstrom zur Netliste. Wie schon früher sagte, ist es so, dass der Bittstream einfach eine Abbildung der Netliste ins FPGA ist. Es ist einfach nur eine andere Repräsentation. Und sobald wir also das Bittstromformat verstehen, verstehen wir die Netliste. Also, dann können wir dann hin und her übersetzen und dann wird es immer fertig. Super. Ja, okay, gut. Jetzt bleibt noch der ASIC übrig. Beim ASIC schaut die Sache erwähnt anders aus. Also, wir wissen, wie wir zum Layout kommen und das Layout geht dann in die Fertigungsanlage und die Fertigungsanlage gibt uns ein Chip. Das verstehen wir, aber wie kommen wir in die andere Richtung? Wie geht denn das? Also, wenn ich jetzt sage Chip, dann denken die meisten an das da. Aber das ist nicht wirklich das, was dann Dinge berechnet. Also, wenn wir jetzt irgendwie das Packaging, wenn wir das Paket aufschneiden, dann kommen wir hier zu dem sogenannten DAI. Und der DAI ist das, was eigentlich aktiv ist. Das ist das, was die Foundry baut. Die Verpackung ist ein Extra-Shit. Und diese winzigen Drähte, die also von den Ein-Ausgabe-Pads an zum DAI gehen, die gehen dann dahin, wo man anlöten kann. Der DAI, also das Herz dieses Paket ist, daran sind wir interessiert beim Reverse-Entstieg. Und wenn man das jetzt überlegt, der DAI ist genau das, was wir mit dem Layout-File vorher spezifiziert haben. Wie kommen wir jetzt also von den physikalischen Dingen auf dieses Layout, oder vielleicht auch gleich in den Schwert weiter? Also ganz einfach, wir nehmen Sandpapier und eine Kamera. Na ja, ganz einfach ist es nicht, aber so können wir uns das vorstellen. Also wir nehmen mit ihnen den DAI und dann machen wir ein Bild von der O-, von der O ist nicht eben von dem DAI. Dann nehmen wir ein paar Chemikalien oder Erzschritte und machen denn erst die erste Ebene weg und machen ein neues Bild von der zweiten Ebene und natürlich auch mit den Viers und Verbindungen dazwischen. Und das machen wir dann für alle Ebenen, für alle Schichten, die da drin sind. Am Ende hat man eine Reihe von Bildern, ein Bild für jeden Layer, für jede Ebene. Ja, ganz einfach so ist es nicht. Also das Problem ist, dass optische Mikroskopie einfach nicht ausreicht. Also wir nehmen hier einen Raster-Elektronen-Mikroskop und die können sehr, sehr, sehr kleine Einzelheiten auflösen. Also von einem einzelnen Layer kriegen wir Tausende von Bildern und dann muss das Raster-Elektronen-Mikroskop wieder Verfahren und ein neues Bild nehmen. Also wir haben nicht nur ein paar Bilder, wir haben moderne Chips, die hätten vielleicht so 10 oder 14 Layers oder mehr. Wir haben Tausende von Bildern, die wir jetzt alle irgendwie zusammenpacken müssen, die wir zusammen nähen müssen, die wir alle ausrichten müssen. Und wenn wir dann in jedem Layer, jeder Layer perfekt ist, dann müssen wir die Layer gegeneinander noch ausrichten. Also um das jetzt nochmal wieder etwas formal auszudrücken, der erste Schritt ist die Entkapselung aus dem Package rauszuholen. Der zweite Schritt ist die Entschichtung, die Schichten aufzulösen und dann, das machen wir mit dem Imaging. Und dann am ganz am Ende nehmen wir diese Images und verarbeiten die. Und wenn wir diese finalen Bilder uns angucken, dann schließlich kommen wir zur Netzliste. Jetzt wieder im Big Picture, um von einem FPGA zu kommen auf den Bitstream und dann zur Netzliste, das geht durch Format, um Formatierung in Prinzip, um von einem ASIC auf die Netzliste zu kommen, müssen wir die Entkapselung und ein paar komplexe Schritte unternehmen. Jetzt könnt ihr euch denken, na gut, also ich habe das jetzt verstanden. Die ganzen Schritte scheinen ja alle relativ nahe liegen zu sein. Ich habe das jetzt natürlich zusammengefasst. Aber wo ist jetzt das Problem? Und ich werde jetzt ein paar der schweren Probleme, die wir haben, mal hier vorstellen. Das erste Problem, diese Stelle, diese Schritte, wo man vom ASIC zur Netzliste kommt, die sind sehr kompliziert. Die brauchen sehr, sehr lange. Die braucht man sehr viel Experten wissen. Das Equipment selbst ist teuer. Und die Ingenieure, die das ausführen müssen, ist auch sehr teuer. Das ist also ein wirklich großer Schritt. Und das zweite Problem ist, dass die Gate Bibliotheken, also die Gata Bibliotheken, die Formate für die Bitstreams, die sind häufig proprietär. Die haben gar nicht, wie diese Dinge abgebildet werden oder was es eigentlich tut. Und das dritte Problem, mit dem man vielleicht auch so nicht beschäftigen könnte, ist, wenn ich jetzt Netzlist sage, also wenn ich Diagramm sage für eine Schaltung, dann könnte man sich sowas vorstellen. Aber in Wirklichkeit sieht es vielleicht eher so aus. Und das ist eine sehr, sehr kleine Netzliste. Das zeigt eine Schaltung für AES, etwa 6000 Elemente. Die Kabel, die ihr seht, die werden hier zusammengefasst. Also hier könnten möglicherweise 8-Bits transparent werden. Aber in der Wirklichkeit werden 8 einzelne Kabel dafür benutzt. Und das sind wirklich schwierige Probleme. Wie geht man damit um, wenn man sich jetzt die Probleme nochmal anschaut? Für das erste Problem, es gibt Firmen, die sind darauf spezialisiert. Die machen all das für euch. Und es gibt auch Forschung, wie man das jetzt immer effizienter machen kann und schneller. Und da gibt es auch sehr viel, was da gerade passiert. Und die Gatterbibliotheken, die kann man auch im Prozess reverse-engineern. Das sind also zum Beispiel ein Endgate. Da schauen wir einfach ein paar Transistoren an, finden raus, was die machen und dann suchen wir mit Muster-Suche, wo es weitere von diesen Komponenten gibt. Und dann kann man das ganz gut machen. Und was Bitstream-Formate angeht, da gibt es ganz viel Arbeit, die da aktuell gemacht wird, wie man diesen Bitstream zum Beispiel für Interoperatibilität rausbekommen kann. Also das große Problem, was übrig bleibt, ist, wie kann man eine netliste reverse-engineern. Und das ist auch die zentrale Frage, mit der wir uns an der Universität beschäftigen. Also wie kommt man von, also weniger, wie kommt man von ASIC zu Netlist, sondern wie kommt man von der Netlist zu so einem ASIC. Und wenn ihr euch erinnert, Netlist hat eine gewisse Analogie zu Assembly. Also schauen wir uns noch mal Software an, wo wir wissen, wie wir mit Assembly umgehen sollen. Da gibt es mächtige Tools, es gibt EIDA Pro oder Gidra. Aber wir haben auch Open Source Tools und Frameworks, die man erweitern kann mit Plugins und so weiter. Also es gibt ein sehr großes Feld, mit dem man da umgehen kann. Also wenn wir uns das Bild angucken, es gibt ja viele Optionen, so könnte das aussehen, gibt es viele Optionen und viele Leute, die das ausprobieren. Und so sieht es aus für Hardware. Das sieht ziemlich schlimm aus. Also es gibt jetzt kein solches Tool, es gibt kein Gidra. Und auch sehr wenig Leute beschäftigen sich damit. Weil sie denken, die Eingangshürde ist einfach sehr hoch. Aber es gibt Hoffnung, vor vier Jahren an der Ruhr-Universität Bochum, in dem IT-Gebäude, haben wir ein Gebäudegestart, ein Projekt gestartet, was jetzt vom MPI für Cybersecurity in Bochum weitergemacht wird. Und mein ehemaliger Kollege hat sich das jetzt hier genau angeschaut. Und was er festgestellt hat, ist vieles, was da in der Forschung existiert. Es ist nicht reproduzierbar. Es gibt keine Skripte für die Algorithmen. Es gibt keine gute Auswertung. Wenn es was gibt, dann crasht es, sobald man seine eigene Netliste da reintut. Und wir mussten also daraus schließen, dass Forschung auf diesem Gebiet sich in einem ziemlich schlechten Zustand ist. Was er also haben wollte, war ein IDA-Prof für Netlist Reverse Engineering. Und so was wie ein offenes Framework mit dem ultimativen Ziel, Forschern und Leuten in der Industrie täglich weiterzuhelfen. Denn das ist wirklich die Hölle. Aber das hier ist HELL. HELL ist unser Open Source Framework für Netlist-Analyse. Und es ermöglicht automatisierte und generelle Inspektion. Und wir können sowohl ASICS als auch FPGAs bearbeiten. Es ist in modernem C++ geschrieben. Und es kann mit Plugins erweitert werden. Und es gibt ein grafischer Oberflächern. Also was ist die Idee hinter HELL? Die Idee ist, dass wir eine Netlist im Wesentlichen als Graf darstellen können. Als Multi-D-Graph. Grafen-Theorie. Grafen-Wish stehen aus Kanten und Knoten. Und diese Kanten, die Knoten verbinden, das sind wie Netze und Kabel, die Elemente der Netlist verbinden. Es ist also nicht schwierig, eine Netlist abzubinden auf so eine Grafenstruktur. Das heißt, wir können Algorithmen aus der Grafen-Theorie benutzen. Da gibt es viel Forschung dazu, wurde viel Gedanken dazu gemacht. Und das haben wir uns auch nicht ausgedacht, sondern Darstellung als Graf ist tatsächlich der üblichste Schritt in allen Forschungsarbeiten zu dem Thema. Also, wie funktioniert HELL? Da müssen wir also erstmal eine Netlist laden und dann lädt HELL diese Netlist in eine Grafdarstellung. Der Benutzer kann dann über die grafische Oberfläche oder über die Python-Shell damit interagieren. Man kann das auch einfach nur als Kommando-Zahlen-Tool für sehr große Analysen benutzen. Und man kann dann eben auch Plugins laden und auf diesen Grafen ausführen. Man kann dann auch Berichte erzeugen und kann dann auch diese Struktur bearbeiten und dann auf die veränderte Netlist auch exportieren. Man kann dann auch Snapshots erzeugen mit anderen Forschern zusammenarbeiten und die können an der Stelle dann weiterarbeiten. Also schauen wir uns HELL nochmal genauer an. Und ich werde euch das nachher noch in Aktion vorstellen. Aber jetzt schauen wir uns erstmal ein Bild an, damit ich da besser reinsoumen kann. Das ist der Hauptview. Wenn man HELL erstmal aufmacht, schauen wir uns erstmal die linke Seite an. Das Erste, was man hier sieht, ist die Grafenansicht. Das ist eine Netlist habe ich hier aufgemacht. Und man sieht alle, also ein paar von den Elementen und deren Verbindung. Und jetzt vermuten wir mal, wir wollen mehr Information haben über dieses Element. Also klicken wir da drauf. Und HELL gibt einem dann die Details, einen Übersicht, was das tatsächlich ist und zeigt alle Informationen, die da mit zu tun haben. Hier kann man sehen, ein Typ hier ist Lot 6, also ein Lookup-Table mit 6 Eingaben. Man sieht die logische Funktionen, die da implementiert wird. Und man kann die Ein- und Ausgabe sehen und alle mögliche Informationen. Und das gilt für alle Elemente, die man da sich anschauen kann. Und jetzt kann man auch sehen, es gibt auch Farben. Und diese Farben haben eine Bedeutung. HELL ist dafür gemacht, euch dabei zu helfen, die Netliste in Module aufzuteilen. Also wenn ihr euch an das Bild von der Netlist erinnert, dann denkt ihr, naja, ihr habt da wahrscheinlich verschiedene Module, die da miteinander interagieren. Und das ist auch die Art und Weise, wie ihr mit HDL Hardware schreibt. Aber nach dem Syntheseschritt ist das nicht mehr sichtbar. Und eines der Ziele von vielen Forschungsarbeiten auf dem Gebiet der Reverse Engineering wird eine gewisse Modularität wiederzuerzeugen. Und um HELL erlaubt euch, eine gewisse Modularität zu erzeugen. Man sieht in Lila ein Modul, was ausgeklappt ist, und wenn wir da jetzt draufgehen, dann kann man die einzelnen Teile, die da mit drin sind, man kann sich also die ganzen verwirrenden Sachen ausblenden lassen, damit man nur noch die Sachen sieht, die man sich interessiert. Und um da die Navigation einfacher zu machen, gibt es hier links eine Baubenstruktur, denn so ist es angeordnet. Und man kann dann auch nur einzelne Teile, dass der Netlist anzeigen und verschiedene Isolationen. Und auf der rechten Seite ist das die Python-Umgebung. Das ist ein sehr, sehr mächtiges Werkzeug. Da gibt es einen Python-Editor auf der recht eroberen Seite und unten drunter ist eine Konsole. Und die interagieren direkt mit dem Kern von HELL. Also alle Gatter und Elemente. Das heißt, man kann jetzt hier also erkundungsgetriebene Analyse machen. Man muss also keinen C++-Plugin schreiben. Man kann das alles live auf eine erforschende Art und Weise machen. Und unsere Vision für HELL ist, dass ihr die Netliste nehmt in HELL öffnet. Führt da Plugins aus, die ihr oder andere geschrieben haben und ihr könnt eigenes kritisches Denken da investieren. Und dann kommt man von dieser Haufe von Gattern auf eine gewisse modulare Repräsentierung. Und dafür haben wir das grafische Benutzerinterface gebaut. Und um da jetzt tatsächlich mal HELL anzugucken, möchte ich euch zwei Beispiele zeigen, wo wir HELL benutzt haben, um den Forschungsstand zu verbessern. Das erste Beispiel, was ich euch zeigen will, ist ein Paper, wo es um FSM-basierte Hardware gibt. Es geht um Obfuscation und Verschleierung. Wenn man stellt euch vor, ihr nehmt so was und dann macht man daraus so was. Man nimmt was, was man verstehen kann und führt das über, was dieselbe Funktionalität abbildet, aber sehr viel schwerer zu verstehen ist. Und wenn wir das jetzt nochmal von großer Distanz aus anschauen, das erzeugen ... Die Ingenieursleistung ist einfach und der Rückweg ist schwer. Und wenn man jetzt quasi diese Verschleierung benutzt, dann wird das unglaublich schwierig das zu rekonstruieren. Und wenn wir jetzt uns angucken in unserem Paper, da gibt es endliche Automaten, das Final-State-Machines. Ihr habt das vielleicht alle schon mal gesehen, aber es gibt quasi eine gewisse Menge von Zuständen und bei bestimmten Ereignissen geht man dann über von einem Zustand zu einem anderen Zustand. Also stellt euch vielleicht vor, ein Geldautomat der ist in dem Zustand, dass es darauf wartet, dass ihr eine Karte reinschiebt und dann geht es über zu dem nächsten Zustand, in dem es auf eure Eingaben wartet. Und in diesem Paper, also in diesem, da haben die Leute sich unter anderem basierte FSM Verschleierungsschema angeschaut. Und da werden also bedeutungslose Zustände und Übergänge eingeführt. Die zeugen auf verschiedene Sachen viele Übergänge erzeugen schleifen. Das heißt, wenn ihr also nicht die korrekte Reihenfolge wisst, um in den Zustand reinzukommen, dann kommt ihr in dieser falschen Logik an und seid da gefangen und ein Reverse-Engineer kriegt also ganz viel Kopfschmerzen, weil er sich einfangen lässt in dieser Dummy-Logik. Also wie kommen wir da jetzt raus? Der erste Schritt ist, wir müssen den verschleierten FSM finden. Und sobald wir dieses verschleierte Modul war der Ansatz den Graf der Zustandsübergänge wieder rauszurechnen. Und indem wir den analysieren, können wir Harpoon schon besiegen. Also wie finden wir die verschleierten Zustandsmaschinen? Die haben eine feste Struktur, denn der nächste Zustand hängt immer vom aktuellen Zustand ab. Und die Elemente, die den Zustand speichern, beeinflussen die anderen. Und wenn wir das jetzt auf ein Bild malen, dann sieht das so aus. Der Zustandsspeicher hat eine Schleife, die auch von externen Eingaben abhängen könnte. Und wenn wir das von der Mathematik angucken, dann sieht das aus wie ein stark zusammenhängender Graf. Man kommt von jedem Element zu jedem anderen Element. Und jetzt um den Übergangsgraf wieder herauszurechnen, schauen wir uns das an. Und wir interessieren uns für die Ausgabelogik nicht, sondern wir wollen nur die Übergänge wissen. Das heißt, in dem Fall interessieren wir uns auch nicht für den Zustandsspeicher, sondern wir gucken uns den aktuellen Zustand, den wir kriegen können, wenn wir die Initialisierung angucken, dann versuchen wir alle übrigen Eingaben auszuprobieren. Und dann kriegen wir alle Zustände, die von unserem aktuellen Zustand erreicht werden können. Wir haben alle diese Zustände, tun wir eine Liste und dann gehen wir diese Liste durch. Und dann haben wir am Ende alle Zustände, die erreichbar sind. Und dann müssen wir nur noch den Übergangsgraf analysieren. Und jetzt gucken wir uns mal an, wie das in Hall aussieht. Also, ich habe es mal hier eine kleine Netzliste vorbereitet. Und wie ihr vielleicht seht, hier unten, hier sind kurz 128 Elemente. Wenn wir da mal reingehen, dann sieht man, dass man nichts sieht. Man sieht viele Elemente, aber hat keine Ahnung, was sie tun, was sie bedeuten, wie sie sich zueinander verhalten. Wie kann ich es damit arbeiten? Deswegen habe ich jetzt mal ein kurzes Preis in der Skripte geschrieben. Was das tut, das ist, das gruppiert alle Input und Output Puffer in Modules. Da wollen wir gar nicht draufgucken. Dann macht man diese stark zusammenhängende Form und lässt ein paar externale Grafenalgorithmen auf den drauf los laufen. Wenn ich das mache, dann kriegt man plötzlich ein viel saubereres Diagramm. Eine viel sauberere Netzliste Links oben haben wir einen Modul mit vielen Outputs. Hier haben wir einen Modul mit vielen Inputs. Also das Input-Output-Puffer, das interessiert uns nicht. Hier unten haben wir zwei verschiedene Module. Ein großes, das ist echt groß. Es hat also viele Elemente und wenn ihr Hardware-Design gemacht, dann wisst ihr, dass endliche Automaten normalerweise ziemlich klein sind und man das sehr dicht kodieren kann. Schauen wir das andere Modul nochmal an. Das sieht nett aus, klein. Schauen wir, verifizieren wir erst mal, dass das wirklich überhaupt von Interesse ist. Also wenn ich jetzt mal diesen Flip-Pop angucke und das isoliere okay, hier ist nur der Flip-Pop isoliert und ich kann jetzt die Pfeiltasten verwenden um auf den Output-Pin zu gehen und dann dem Output-Pin zu folgen an alle anderen Wahrscheinlichkeiten, die da verbunden sind. In der Liste sehe ich hier sofort ein Lookup-Table, der auch in einem selben Modul drin ist. Wenn ich da folge, sehe ich sofort dass es hier einen kleinen Feedback-Loop gibt. Also das Deutsch, das Speiche-Element und das Flip-Pop, da geht man ein Lookup-Table und dann gibt es ein Feedback wieder zurück zum Look-Loop-Gegner-Element. Schau mal wo das sonst noch hinführt und ich finde also noch zwei weitere Lookup-Tables und wenn ich jetzt mir anschaue, was die ist wieder, wo die hier verbunden sind, sehe ich sofort sehe ich wieder Kandidaten, die voll sind, also die irgendwie geflipflops und jetzt können wir die mal rumschieben hier dann sehen wir eine schöne, perfekte Feedback-Struktur für all diese Elemente. Wenn ich jetzt also alle Ausgänge mal selektiere hier auswähle, dann komme ich zu den Speiche-Elementen und alles dazwischen, das ist verbunden mit den Logikelementen. Also wir haben hier eine stark verbundene Komponente. Jetzt haben wir das Skript noch für den zweiten Teil laufen und dieses Skript das holt im Prinzip die Zustands-Tabelle raus und wenn ich es laufen lasse, dann bekomme ich dies hier. Das hier ist der Übergang der Kraft der Übergänge und das sind nur die Übergänge. Was man ganz oben sieht, das ist sozusagen unser Initialzustand. Es gibt viele Übergänge in anderen Zuständen, es gibt Schleifen und so weiter, aber hier haben wir einen einzigen Übergang und sobald wir da rüber gehen, kommen wir nie wieder zurück. Wir können sofort mit diesem Grafen sehen, dass dieser obere Teil wahrscheinlich irgendwie Harpoon, der Harpoon-Verschleierer ist und das da unten ist die ursprüngliche Logik. Also mit dieser Analyse haben wir eigentlich Harpoon bereits außer Kraft gesetzt. So. Also, ein kurzer Disclaimer. So einfach ist es in der Wirklichkeit selten. Also so endlich Automaten, die sind oft nicht unbedingt größer, aber man findet sie nicht einfach so, indem man nach stark verbundenen Komponenten sucht. Unseren Paper haben wir allerdings noch viele andere Techniken beschrieben, wie man da hinkommt und endlich ein Automaten findet. So, das andere, was ich euch noch zeigen wollte, das ist auch recht kurz, das ist eine Abfrage basierte Technik. Das wurde gemacht, basierte Forschung von der Technik und Universität in Haifa in Israel. Da geht es darum, wir noch die Nestliste zu finden. Wir haben sie noch nicht. Das ist, wie gesagt, sehr teuer, dass wir in der Annoele Arbeit irgendwie anders zu einer Nestliste kommen. Und was sie sich überlegt haben, sind eben Scanchains, Abfrage-Listen, Abfrageketten. Also, so könnte man sich ein Design vorstellen. So denkt man, dass ein Design ausguckt. Aber in Wirklichkeit schauen fast alle Designs irgendwie so aus. Oder vielleicht noch anders irgendwie so. Alle Speicher-Elemente sind in einer großen Kette zusammengefügt und je nachdem, in welchem Modus man sie benutzt, senden sie die Daten einfach in das nächste Filmblog oder sie lassen ihre Ausgänge durch die Logik durchgehen und berechnen was. Warum macht man das so? Na ja, denkt drüber nach. Also, wenn man jetzt den Chip sich hernimmt und den mit der Kette hintun, dann kann man ein zyklos langes Ding laufen lassen und kriegt den kompletten Zustand wieder raus. Also, man hat zyklengenaues In-Hardware-Debugging und fast jeder Chip hat so eine Scanchain. Normalerweise sollten die auch dann disabled werden nach dem Testing, aber man kann das auch manchmal wieder anschalten. Wie kann man also Reverse-Engine wenn man so eine Scanchain hat? Also, zunächst einmal wissen wir nicht, wie diese Flipflops mit der Logik verbunden sind. Was sind also die Abhängigkeiten zwischen den Flipflops? Das ist die erste Herausforderung und die Forscher haben das also gelöst, indem sie einen internen Stand reingetan haben und dann haben sie einzelne Bits geändert und haben geschaut, welche Bits dann mit effizienten Algorithmen konnten sie dann also die Abhängigkeiten zwischen den Flipflops herausfinden und konnten herausfinden was dadurch die Logik hindurch verbunden ist. Nur die Logik selbst war noch unbekannt und die rauszufinden, hat man einen speziellen Stand genommen also N verschiedene Zustände und da gibt es natürlich Algorithmen, die das effizient diese Zustände vorgeben und dann bekommt man eine politische Funktion, die das Dialogik abbildet. Diese Technik nennen sie Scandid und indem man das Scandid abfragen kann mit dem Scandid Chool bekommt man dann eine Annäherung der Netliste also eine ungefähre Netliste also nicht indem man wirklich das Chip aufmacht und die Netliste direkt raus holt sondern eine mehr funktionale Beschreibung Scandid wird noch momentan entwickelt. Da gibt es einen Plugin für Hall für echte Hardware aber man kann dann auch die Hardware simulieren und diese Simulation die würden wir uns jetzt anschauen also ich hab auch das hier vorbereitet ich hab hier also eine leere Netliste wenn ich jetzt in dieses Modul reingehen will dann kriegt die Nachricht da kann man nicht reingehen weil es leer ist hier ist unser Scandid Plugin mit der Simulation eines kleinen zürstlichen Schaltkreises der ersten Schritt den ich hier durchführe ist dass ich die Abhängigkeiten zwischen diesen Flip Flops und den Speicheralimenten rausholte so das ist die Netliste die hier also entdeckt wurde wir sehen sofort mehrere Flip Flops also Speicheralimente und die sind verbunden mit Lops, mit Logikblöcken wie wir sie nennen und die haben noch keine Funktionen drin so jetzt lassen wir den zweiten Teil der Analyse laufen und das ist der Teil der eigentlich die bulidischen Funktionen daraus holt das alles ist jetzt durch Simulation gemacht also wenn ich jetzt draufklicken also eine große bulidische Funktion gibt mit 6 Eingängen und einem Ausgang oder hier den anderen Logikblock da gibt es eine andere bulidische Funktion dieser Algorithmus hat uns tatsächlich die Netliste rausgeholt von diesem von diesem Schaltkreis den können wir jetzt analysieren es ist allerdings nur eine Annäherung, es ist nicht die wirkliche Netliste ja gut also ich habe euch jetzt mal gezeigt wie das aussieht ich habe euch gezeigt wie die Interna aussehen die unterliegenden Prinzipien von Hardware Design und Hardware Reverse Engineering und ich habe euch gezeigt wo die Hauptprobleme liegen und das große Problem ist immer noch die Analyse der Netliste und was wir gerne hätten ist dass ihr eure Netliste in Hell ladet natürlich, aber ihr habt gerade gesehen das ist nicht der Fall in dem Verschleuerungsbeispiel beispielsweise habt ihr das gerade gesehen in der Wirklichkeit ist es, wir nehmen Hall und das erzählt uns eine Menge aber wir müssen auch immer manuelles Nachdenken mit investieren und Reverse Engineering in nicht nur was Hardware angeht sondern in praktisch allen Gebieten das kommt immer auf menschliches Nachdenken an eine neue interdisziplinäre Forschungsrichtung an unserer Universität die wir kognitive Verschleuerung nennen und bei dieser Forschung haben wir zusammen mit Psychologen gearbeitet von unserer Universität die menschlichen Faktoren in Forschung auf Verschleuerungstechniken mit untersuchen wollten und wie man in unserem Beispiel gesehen hat das kann für eine Maschine schwierig sein das zu brechen, aber wir sind immer noch großartig im Muster erkennen wir konnten uns einfach nur anschauen und haben es direkt besiegen können und die Idee ist können wir vielleicht Metricen finden die das quantifizieren wie wie gut Verschleuerung in der echten Welt funktioniert und das heißt, möglicherweise finden wir so auch neue Techniken um die tatsächlich auch schlecht die auch gut funktionieren wenn sie gegen Menschen antreten und daran arbeiten wir aktuell also zum Abschluss, ich weiß ich stehe hier oben und rede mit euch aber das war jetzt nicht nur meine Arbeit das ganze Projekt ist gewachsen in den letzten vier Jahren nicht stetig, aber immer wieder mal und es gibt ein Team dahinter was da an Hal arbeitet das zentrale Team sind im wesentlichen Mark Sebastian und ich Mark ist nicht mehr aktuell an Hal also arbeitet daran nicht mehr als fertig mit seiner Doktorarbeit aber Sebastian und ich wir arbeiten da immer noch dran und diskutieren welche Richtungen wir einschlagen wollen und wir koordinieren mit dem Rest unseres Teams da sind einige Promotionsstudenten und wissenschaftliche Hilfskräfte dabei und ich hätte gerne eine Runde Applaus für die denn ohne die wäre das nicht möglich gewesen während ich dabei bin Leuten zu danken möchte ich auch diesen Leuten danken die haben die Icons erzeugt für diese Präsentation da gibt es nie genug Lob dafür ihr dürft auch gerne hier nochmal klatschen und ich möchte mit einem Aufruf enden wir brauchen euch denn wir wollen das hell wächst wir selbst können nur in Teilzeit daran arbeiten denn wir werden für Forschung bezahlt und leider werden Entwicklung von Werkzeigen von der Forschung Community nicht als Forschung anerkannt auch wenn es für Forschung benötigt wird also wir sind IT Sicherheitsforscher, wir sind keine Softwareentwickler wir könnten uns also viel davon versprechen dass ihr damit helft und jeder Hilfe ist großartig die hell ist unter der MRT-Lizenz ihr könnt uns über Slack, Github, Twitter kontaktieren wir würden uns sehr freuen wenn ihr da mithelfen könntet und damit herzlichen Dank und danke für die Aufmerksamkeit das war HAL der Open Source Hardware Analyse Tool von Max Hoffmann übersetzt von Goonies Bro und Tribut wenn ihr Feedback habt, gerne mit dem Hashtag C3T auf eurem Lieblings-Sozial-Netzwerk oder ihr schickt eine Mail an hello at c3lingo.org und die erste Frage geht an das kommt von dem Internet gibt es Pläne einen Debugger oder einen Emulationstool hier hin zuzufügen damit ich Daten der echten Welt dadurch fließen sehen kann ja, diese Tools gibt es also intern arbeiten wir an einem Simulator gerade in diesem Augenblick also ein Zyklan-alkoratischen Simulator und der funktioniert ziemlich gut und ist nicht in den Zustand, dass wir ihn erließen können aber trotzdem das ist etwas, was wir gerne in HAL sehen würden dieses Debugging nicht nur im Kotan auch visuell das schauen wir uns an und würden es gerne implementieren, ja ich habe eine Frage wie gut das mit größeren finanziert moderne FPGRs haben 100.000 Elementen ASICs haben also Millionen von Transistor wie gut ist da die Performance großartige Frage, also HAL ist ja, das Tool ist selbst, also der Core der Kern kann große Netlisten verarbeiten, also mit vielen 100.000 Gates aber die Benutzeroberfläche kann das nicht wie ich schon sagte die Benutzeroberfläche, die wir für HAL mit der UI haben, ist, dass wir Module unterstützen denn selbst wenn du ein Netzliste hast mit 100.000 Gates dann hilft dir das nichts was wir also wollen, ist eine grafische Benutzeroberfläche zu entwickeln, was diese Modularisierung unterstützt und dann kannst du deine ganze große Analyse laufen lassen mit der Kommande zuteilen das haben wir auch gemacht in unseren Papers die wir auf der Webseite finden kannst aber für visuelle Inspektionen wenn man da alle Gates angucken möchte dann ist halt ich das richtige Schul die erste Frage betrifft ist es üblich hier Verschleierung für endliche Automaten zu benutzen und es ändert die Funktion das Automaten nicht, aber ist es in gewisser Weise messbar in dem Sinne, dass da mehr Strom oder Performance gebraucht wird? naja, ich glaube dass sich hier der nächste Vortrag da einiges drüber erzählen wird, da möchte ich es nicht zu viel vorweg nehmen also die Antwort ist, es kommt drauf an es gibt da viel viel Research auf Stabilmaschinen Verschleierung aber die meisten sind einfach kaputt also die sind einfach nicht die sind einfach nicht stark die zweite Botschaft ist man kann immer eine Metrik finden um irgendeine Methode zu identifizieren aber man weiß es nicht, ob das auf Methode Y funktioniert kann sein dass die Verschleierung die an die du denkst mehr Strom braucht aber eine andere hat dann vielleicht mehr Elemente und dafür nicht so viel Strom verbraucht also das kann man nicht so beantworten woher wisst ihr wie dick die oberste Schicht das Dai ist bevor er die entfernt ja also wenn man sich das so überlegt diese wenn man da wirklich reingucken könnte dann sind sie klar voneinander getrennt weil es gibt immer den Metall Layer mit den Metallebene mit den Drähten und dann gibt es wieder eine Ebene mit den Drähten und diesen View kann man sich holen also man kann seinen Chip nehmen und einfach nicht die oberste Schicht abschleifen sondern einfach von der Seite anschleifen oder auch mit Röntgeln und dann kriegt man auch eine Quersche vom Chip es gibt ein altes Projekt das ist vielleicht 10 Jahre alt und heißt DeGate, kennt ihr das wie verbindet das was hat das mit Hell zu tun DeGate ist ein ein anderes also das setzt einem anderen Punkt im Prozess an DeGate wird verwendet um die Bilder zu analysieren die man kriegt und dann diese Bilder mit DeGate kommt man von den einzelnen Aufnahmen zu einer Netzliste und vielleicht kann man da auch schon ein bisschen Analyse betreiben aber da geht es nicht darum eine verhandene Netzliste zu analysieren was haltet ihr von Schutz von FPGAs mit einem Schlüssel also einer Control Lock um Reverse Engineering zu verhindern ja interessant also es gibt eine Technik die nennt sich Bitstrom Verschüsselung, natürlich mit einem Schlüssel und es gab verschiedenen akademische Arbeiten die alle diese Verschelungsschemen aufgeknackt haben also und was ich mich die Anzahl es wird nicht sehr oft verwendet es gibt, kann man eine Hand abzählen die Anzahl der Leute die das verwenden diese Verschelung es gibt auch Schemattha da kommen im nächsten Vortrag dazu wo man ein Schlüssel verwendet um den ganzen Schaltkreis so zu ändern dass er nur richtig funktioniert wenn man den richtigen Schlüssel angebt funktioniert der Schaltkreis immer noch aber er funktioniert nicht richtig das wird jetzt heftig diskutiert und es gibt mehrere auch Designfehler aus meiner Sicht ist das kein guter Ansatz aber da verweise ich auf den nächsten Vortrag es geht um die Zustandsmaschinen eine Graf wie schließt ihr denn darauf dass der obere Teil der harpoon Teil ist und der untere die tatsächliche Zustandsmaschine ist ja also ich gehe hier nochmal rein und öffne das nochmal auf das Diagramm noch einmal an deinem Wetter so also das hier war der Graf den ich gezeigt habe und ich weiß dass dieser erste Zustand eine spezielle Zustand ist ich weiß es indem ich mir ein gucke die Initialisierungswerte von den flipflops und von den also auf einem ASIC müsste man sich anschauen wie das Resetverhalten des flipflops ist und von diesem initialen Zustand gehe ich jetzt einfach sämtliche dieser Zustände ab und die Idee von harpoon ist original die eigentliche Stapemaschine davor zu schalten aber mit Schleifen aber wenn man den harpoon erstmal verlassen hat dann kommt man nie zurück man sieht es an diesem Übergang zwischen diesen beiden Zuständen wenn man den Übergang mal genommen hat dann kommt man nicht zurück dann bleibt man immer hier unten und deswegen haben wir geschlossen mit dem zustandsautomat also dieses 110 wird nicht zur eigentlichen zustandsautomat gönnen ihr benutzt einfach ausprobieren bruteforce um die zustandsmaschine rauszufinden habt ihr euch mal über einen Gedanken gemacht da künstliche Intelligenz zu benutzen wie einige eurer Kollegen in bochum was internetprotokolle angeht also mit unserem bruteforce nur die also die zustandsübergänge entdeckt von einem stapemaschinen kandidaten den es bereits ergibt wir mussten alle eingaben bruteforce die aus die aus dem von außen kam und nicht vom speicher innerhalb der stapemaschine da hilft einem maschinen lernen eigentlich nicht es geht einfach hier um berechnen und schauen was rauskommt also wenn man das ganze Design anguckt und wie man dann da zustandsautomaten identifiziert das ist ein unterschiedliches anderes thema das könnte möglich sein aber denkt also wenn man so maschinenlernen algorithms die brauchen echt viel trainingdaten und das ist schwer überhaupt dran zu kommen für hardware auch jedes jedes synthese tool synthesiert anders also wenn man jetzt ein netzwerk mit mit netzlisten trainiert die man selber gebaut hat dann lernt das neuralen netzwerk nur den syntheseizer also den du verwendet hast also ich glaube nicht dass künstliche indigenz und maschinenlearning hier tatsächlich einen ansatz ist signal angel one last question wie wird die bugging gemacht wenn verschleierungen zur anwendung kommt was machen leute die dass die bugging machen sollen also ich glaube ihr redet du redest bei des design und wenn man das design verschleiert und das wird zu die buggen darum geht es also es geht um die verscheierung technologie die eingesetzt wird aber wie man im diagramm gesehen hat ist die der gedanke hinter der verscheierung ist einfach das reverse engineering schwer zu machen aber das forward engineering ist einfach das bleibt immer noch einfach auch die gute engineering ist nie leicht aber es ist einfach also solange man weiß wie diese verscheierung funktioniert kann man das immer in test einbauen also das wenn ich ein bereits geschütztes design habe wie kann ich das dann testen ohne den den schüssel zu geben das sind die testlabore das wird auch momentan untersucht aber es kommt schwer darauf an was man so verwendet ja max vielen dank für diesen talk und für die antwort auf die fragen