Automatisches Auslesen eines ROMs mittels Bilderkennung

[HWL News Bot]

Während aktuelle Chips je nach Komplexität mehrere Milliarden Transistoren und komplexe Verschaltungen beinhalten können, waren die Prozessoren vor einigen Jahrzehnten noch deutlich weniger kompliziert aufgebaut – auch weil die modernen Fertigungsverfahren natürlich noch nicht zur Verfügung standen.
... weiterlesen

 

[Viper63]

Schon ziemlich abgefahren, wie praktikabel dass im größeren Stil wäre würde ich allerdings mal hinterfragen, da das Freilegen des Die nicht immer komplett zerstörungsfrei möglich ist.

 

[suali]

Autismus Maximus

 

[Bitmaschine]

Ich glaube es wird nur dann funktionieren, wenn die zu ausgelesene Information einschichtig auf dem bearbeiteten DIE platziert wurde. Trotzdem ein interessanter Ansatz maschinell Hardwarestrukturen einer vordefinierten Befehlssequenz zuzuordnen. Es gibt sicher auf modernen CPU's auch einschichtige Strukturen (Befehlssequenzen), die in ähnlicher Weise ausgelesen und interpretiert werden können (Befehlssatz der CPU?). Das letzte Geheimnis eines Chips wird gebrochen ... zumindest kann man mit diesem Verfahren unbekannte Chips zum gewissen Teil entschlüsseln.

 

[Techlogi]

Zu dem Thema gab es auf 2016 dem 33c3 einen sehr interessanten Vortrag:

Datenschutzhinweis für Youtube

An dieser Stelle möchten wir Ihnen ein Youtube-Video zeigen. Ihre Daten zu schützen, liegt uns aber am Herzen: Youtube setzt durch das Einbinden und Abspielen Cookies auf ihrem Rechner, mit welchen sie eventuell getracked werden können. Wenn Sie dies zulassen möchten, klicken Sie einfach auf den Play-Button. Das Video wird anschließend geladen und danach abgespielt.

Youtube Videos ab jetzt direkt anzeigen

Video anzeigen

Für die Ungeduldigen: Ab Minute 18.

 

[SystemX]

Schon hammer was nich alles möglich ist...

 

[Dshing]

Warum nicht mit einem CT, dann spart man sich das aufwändige präparieren. Ist ja nicht so als wenn diese Geräte nicht bereits fürs Reverse Engineering eingesetzt werden würden. So könnte man dann auch mehrlagige ROMs auslesen. Das hier gezeigte automatisieren halte ich auch nicht für besonders anspruchsvoll. Das Stammbild ist sehr eindeutig und kontrastreich. Das erkennt ja jeder von uns sofort was Hi und was Low ist. Anhand des Kontrastes in einem einfachen 2D Raster den Wert auf größer oder kleiner als abgefragt und das war es dann schon fast. Man muss halt nur einmal die Randbedingungen definieren und wenn das der Mensch tut und nicht die Maschine selbst, dann ist das eine bessere Fingerübung für jeden Informatikstudent.

 

[Richard88]

Warum nicht mit einem CT, dann spart man sich das aufwändige präparieren. Ist ja nicht so als wenn diese Geräte nicht bereits fürs Reverse Engineering eingesetzt werden würden. So könnte man dann auch mehrlagige ROMs auslesen. Das hier gezeigte automatisieren halte ich auch nicht für besonders anspruchsvoll. Das Stammbild ist sehr eindeutig und kontrastreich. Das erkennt ja jeder von uns sofort was Hi und was Low ist. Anhand des Kontrastes in einem einfachen 2D Raster den Wert auf größer oder kleiner als abgefragt und das war es dann schon fast. Man muss halt nur einmal die Randbedingungen definieren und wenn das der Mensch tut und nicht die Maschine selbst, dann ist das eine bessere Fingerübung für jeden Informatikstudent.

Im text stsht dass das bild nachbearbeitet werden musste. Villeicht sehen wir hier ja das machbearbeitete bild.

Ausserdem wird hier geschliffen und geätzt. Da kann es gut sein dass das endergebniss immer stark variiert. Der mensch ist beim erkennen von mustern eben einfach eine klasse für sich.

 

[Bitmaschine]

Für die Ungeduldigen: Ab Minute 18.

Wer glaubt das alles sicher ist, der irrt sich gewaltig
Oh Gott, ich muss los und meine Sicherheitslücken in Windows stopfen .... wo ist das Update?

 

[Dshing]

Im text stsht dass das bild nachbearbeitet werden musste. Villeicht sehen wir hier ja das machbearbeitete bild.

Das Bild ist definitiv nachbearbeitet, das ist ja auch unumgänglich und macht jeder bei einem Die-Shot. Die Frage (oder eine Frage) wäre jetzt, ist das Bild maschinell oder per Hand nachbearbeitet worden? Ich denke der Kontext legt es eindeutig nahe, das es von einem Menschen gemacht wurde. Nun kann das aber sicherlich Photoshop und Konsorten auch mit heutigen Boardmitteln automatisch, so ein Bild aus den Rohdaten zu generieren, das ist letztlich auch nicht so schwer. Gute Lichtmikroskope haben entsprechende Bildanpassungen bereits in der Capturesoftware integriert. Aber noch mal, es so wie hier gezeigt per Hand zu tun ist eben keine Herausforderung. Diesen einen Schritt des "Durchzählens" zu automatisieren ist leicht, wenn die Eingangsdaten so wie hier vorliegen.

 

[Olstyle]

aber noch einmal: 1,7 kB sind bei weitem nicht die Komplexität, wie wir sie von modernen Chips kennen.

Ich kenne eine Reihe aktuell kaufbarer, sicherheitsrelevanter (Teil einer Zugangskontrolle) Produkte welche besagten Atmega einsetzt. Ganz so "egal" ist das Gezeigte damit nicht.
Allerdings kann man besagte Chips im geöffneten Zustand auch elektronisch auslesen, da ist es fast egal ob es optisch auch geht.

 

[Dshing]

Also nach lesen der original Quelle, kann man letztlich feststellen, dass er das Tool "rompar" nutzt, das ist keine Entwicklung von Ihm und ist ein manuelle Auslesehilfe (funktioniert wie von mir oben beschrieben). Er schreibt selbst: "We can adjust the threshold by going to CV Options -> Pixel Threshold. Adjust it until we can see something like this:[...] This is inverted as needed during post processing if it’s reversed into an actual binary". Man muss also erst einen Referenzwert per Auge selbst auslesen und dann die Helligkeit solange anpassen, dass der Bitwert dem selbst ausgelesenen entspricht, dann kann das Programm selbst den Rest auslesen, was ja dann nun wirklich keine Kunst mehr ist.
Es handelt sich also in keiner Weise, wie von einigen (auch mir) gehofft, um eine automatische Erkennung, sondern nur um eine automatisch unterstützte auslese Hilfe.

 

[LuckyDice]

"um nachvollziehen, welche Daten gespeichert wurden. In der Halbleiterhersteller wurde aus"

 

[fdsonne]

Es handelt sich also in keiner Weise, wie von einigen (auch mir) gehofft, um eine automatische Erkennung, sondern nur um eine automatisch unterstützte auslese Hilfe.

Naaaja, kann man jetzt so oder so sehen. Ich sag mal so, das ist ja jetzt kein Ding der Unmöglichkeit eine Art Suchmechanismus zu implementieren, die für dich das Justieren auf die jeweilige Quelle vornimmt. Das ist komplett automatisierbar. Warum das hier nicht gemacht wurde, liegt doch auch auf der Hand, es handelt sich hier um eine privat Person, die das quasi als Hobby zu machen scheint. Er nutzt dabei existierende Tools. Es geht dabei wohl eher um Fun anstatt einer Massenabfertigung. Wozu einer Autoerkennung wenn man das eh nicht braucht? Die Zeitersparnis wäre hier wohl quasi nicht vorhanden. Denn die Masse der Zeit geht für das Vorbereiten der Chips drauf - und am Ende für die Auswertung des Binärcodes, nicht für das Suchen der richtigen Bildparameter.

Was ich mich allerdings frage - "von einigen gehofft" -> wieso gehofft? Hoffen klingt wie, als wäre es eine Notwendigkeit, dass es sowas gibt, was bis jetzt noch keiner erfunden hat und man hoffte jetzt darauf, dass so eine Arbeit den Durchbruch für das Thema findet? Aber wieso hoffen??
Ich behaupte mal ganz frech, wie so oft schon bei ähnlichen Themen - die Hardware ist das geringste Problem, was aktuell in Zusammenhang mit PC und Sicherheit von der Allgemeinheit zu befürchten ist. Warum? Es gibt seit Jahren schon immer mal wieder wirklich extrem problematische Sicherheitslücken in der Software, die halt public werden, aber schon Jahre, teils 10+ Jahre mitgeschleppt werden. Vor nicht all zu langer Zeit war das bspw. die sudo Sicherheitslücke im Linux Umfeld, was so ziemlich jedes Linux based Gerät betrifft/betraf. 10 Jahre lang von der Öffentlichkeit nicht mitbekommen. In quell offenen Code.

Themen wie hier, wo es um extrem umständliches auseinander nehmen von hard coded Stuff geht, sind nur die halbe Miete. Das "Wissen" um den Code heist lange nicht, dass es auch sicher ist/wird. Und nur weil man rein sehen kann wird das nicht automatisch auch bis ins Klein Klein wirklich auseinander genommen. Diese Themen wie die Sudo Lücke vor kurzem zeigen, dass sowas über Jahre unentdeckt überall mit geschleppt wird.. Ich bin 100% sicher, solche "Fehler" findet man auch in Hardware bzw. hard coded Stuff in Hardware. Die lässt sich dort auch nicht fixen. 100% klar. Aber wozu bitte den Aufwand betreiben um sowas zu suchen/finden? Man kommt doch über Software ans gleiche Ziel und bekommt den Code sogar noch auf dem Silber Tablet durch die OpenSource Sachen vorgezeigt
Nicht zu vergessen, die bösartigen Köpfe in Sachen Sicherheitsanalysten von Codes werden weder die hard coded Themen noch die simplen Software Themen publizieren, damit Hersteller das fixen können, sondern behalten die Sachen für sich bzw. nutzen das für sich aus OHNE dem Hersteller den Wink zu geben, damit der das fixt.
Dazu kommen Geheimdienste als ich würde es zwischen Ding zwischen Good Guy und Bad Guy nennen. Die von sich aus Stuff publizieren wenn irgendwo raus kommt, dass sie selbst Sachen nutzen, die aktuell nicht öffentlich kommuniziert wird - aber 100% sicher, ihre Klappe halten, nicht öffentlichbekannt ist, dass ihnen diese oder jene Sicherheitslücke bekannt ist.




Btw. Thema Lesen der Quelle. Grundsätzlich immer zu empfehlen
Im Artikel sind nämlich ein paar Fehlerchen drin. Die sollte @Don am Besten noch korrigieren.

Spoiler

- Es handelt sich hier nicht, wie im Artikel geschrieben um den Atmega328P sondern um den CH340G!!
-> in der Quelle wird gesagt, dass der erste Versuch mit dem Atmega328P unternommen wurde, aber er keinen ROM Bereich in diesem Chip gefunden hat. EEPROM, SRAM und Flash konnte man sehen (siehe erstes verlinktes Bild)
-> aufgefallen ist das, weil die folgenden Bilder als Bildausschnitte gar nicht in diesem ersten Bild zu finden sind. Das freigelegte Bild des CH340G ist hingegen gar nicht verlinkt Wir aber erst ersichtlich, wenn man die Quelle ließt, wo das beschrieben steht. Da steht nämlich immer, dass der Bereich oben rechts im Bild zu finden ist... Beim Atmega328P logisch ist da nix, was darauf trifft.

- "Der darin verbaute ROM hat eine Größe von 64 Bits vertikal und 16 x 14 Bits in der Horizontalen. Insgesamt kann er also 1.792 Bytes aufnehmen."
-> das ist irgendwie seehr irreführend in der Angabe der Größe. Es handelt sich hier um 64 Zeilen. Also 64 Bit in der vertikalen. Soweit, sogut, aber es sind nicht 16 x 14 Bit, sondern es sind 14 x (meint multipliziert/mal) 16 Bit Das ist deswegen wichtig, weil in einem zweidimensionalen Koordinaten System wie so einem Grid schlicht keine drei Dimensionen funktionieren. Die "14" in dem Fall bedeutet einfach nur es sind 14 Stück von 16 Bit. Die Erklärung, was das ist bzw. warum das so ist, steht im Text der Quelle (fehlt leider im Artikel) -> es sind 16:1 Multiplexer - in Summe 14 Stück. Das ergibt eine Gesamtbreite/Horizontale von 224 Bit. (64 Bit x 224 Bit = 14.336 Bit) 8 Bit sind 1 Byte, also sind es hier exakt 1,75kB.

- "Gelingt die bitweise Erkennung, muss den Daten noch eine Bedeutung zugeordnet werden."
-> eigentlich nicht. Man hat hier einfach nur gezielt nach etwas gesucht um zu erkennen, ob das Encoding stimmt. Sprich wenn man die Bits bspw. geflippt ließt, dann kommt da nur random Zeug raus - erkennt man aber Strings, die einen Sinn ergeben, ist die Wahrscheinlichkeit seehr hoch, dass man das richtige Verfahren nutzt und das, was man da ausließt auch wirklich einen Sinn hat bzw. irgendwas darstellt. Eine Bedeutung muss man aber nicht zuordnen, vor allem nicht wenn man einmal die Parameter kennt. -> das ist das was dort beschrieben steht, dass keins der verwendeten Tools die Architektur kennt. Sprich die Parameter sind unbekannt und müssen erst evaluiert werden. Simples Trial and Error.

- "Im Falle des ROMs im Atmega328P konnte über ein Offset in den Bitstrings schnell ein Muster erkennbar gemacht werden, so dass Codeschnipsel wie "USB 2.0" oder Strings wie "Print" und "Serial" erkennbar wurden."
-> Offset bezieht sich hier im "Computersprech" wie bei Hexadezimalangaben üblich nicht auf ein Offset im Sinne von etwas, was oben drauf kommt, sondern wird verwendet um beginnend von einen Basispunkt eine Adresse anzugeben. Von 0x0 auf 0x80 ist das Offset also 0x80. Die Aussage, es konnte über ein Offset etwas erkannt werden, ergibt aber in dem Zusammenhang keinen Sinn. Es steht einfach in der Adresse 0xirgendwas der String. Man spricht halt von Offsets bei solchem Code, weil mit Offsets gearbeitet wird um von einer variablen Basis eben eine bestimmte Länge Daten zu erhalten (bspw.)
Hier aber wurde nichts verändert oder drauf gegeben. Beim ersten Lesen des Artikels dachte ich erst, die haben da einfach einen Offset drauf gesetzt. Also bspw. jedes Bit um einen Wert erhöht. Das wäre umgangssprachlich ein Offset. Hier aber nicht der Fall.
-> "Looking at offsets 0x0770 and 0x0780, we can make out the string USB 2.0" -> Offset 0x0770 und 0x0780 sind einfach die beiden Adressen. Also genauer, beginnend von der Basis 0x0 legt man 0x0770 oder 0x0780 als Offset drauf um zu dieser Adresse zu kommen. Wäre die Basis angenommen 0x0700, dann wäre der Offset für die Adresse nur noch 0x0070 bspw. 0x0080. Das aber nur zur Erklärung - weil der Teil meines Softwareentwickler-Hirns springt im Dreieck wenn es "über ein Offset in den Bitstrings" ließt. Und Bitstrings gehört da btw. auch nicht hin Bitstrings wären "USB 2.0" oder "Print" oder "Serial" in ihrer binären Form. Man setzt hier allerdings weder ein "Offset in den Bitstrings" noch sonst welche Offsets oder irgendwas anderes in Bitstrings. Man sucht gezielt nach einem human readable String in den Daten und gibt "nur" die Adresse des Fundes als Offset beginnend von 0x0 an. Thats it.

- "... aber noch einmal: 1,7 kB sind bei weitem nicht die Komplexität, wie wir sie von modernen Chips kennen."
-> Es handelt sich doch hier um "moderne Chips" - das ist ein quasi aktueller IO Controller für ein Ardoino Dev. Board? Btw. sind es keine 1,7kB, es sind genau genommen 1,75kB. Gerundet also entweder 1,8kB. Oder man nennt es ca. 1,7kB -> hier hat die Quelle aber auch nur 1,7kB stehen.
-> meiner Ansicht nach hinkt der Vergleich zu einem Prozessor im Zusammenhang mit der Komplexität, wie nem aktuellen Ryzen oder Core i irgendwas ziemlich extrem. Es spielt für das Verfahren gar keine Rolle, wie "breit" der Speicher ist. Das Verfahren schaut einfach nur jedes Bit an und ließt da 0 oder 1 aus. Es gibt nur diese beiden Zustände. Es wird also nicht komplexer, es wird nur einfach mehr Binärcode. Komplexer wird demnach vielleicht nur den Output auch zu verstehen. Ob man das aber bei 1,75kB noch im Kopf überblickt, wage allerdings auch schon zu bezweifeln. Das ist hart Maschinencode - nix mit fancy Variablennamen und netten Befehlsketten einer Hochsprache und so nem Kram. Jeder der schon mal etwas intensiver Assembler Code versucht hat zu lesen, der wird da denke ich klar zustimmen. Das zu "verstehen" im Kopf beim Lesen oder so, schaffen selbst gute Software Entwickler nicht.

 

[Dshing]

Was ich mich allerdings frage - "von einigen gehofft" -> wieso gehofft? Hoffen klingt wie, als wäre es eine Notwendigkeit, dass es sowas gibt, was bis jetzt noch keiner erfunden hat und man hoffte jetzt darauf, dass so eine Arbeit den Durchbruch für das Thema findet? Aber wieso hoffen??

Ja ok einverstanden, "hoffen" ist vllt. das falsch Wort. Ich meinte hoffen hier eher im Sinn von erwarten. Also bei der Überschrift hatte ich jetzt durchaus an maschinelles lernen gedacht, oder eben das professionelle Reverse Engineering Also Mechanismen, die wir schon kennen zusammen geführt. Also CT Durchleuchtungen mittels AI interpretieren lassen, wie wir es bei Gehirntumoren schon kennen z.B.. Ob es das braucht und wenn ja wozu steht auf einem anderen Blatt und würde den Rahmen sprengen.

Ich stimme dir zu, bei der Diagnose, dass es hier die Arbeit eines Hobbyisten ist. Auch wenn dieser wohl Zugang zu einem Labor hat, scheint es für mich aber kein Sicherheitsforscher (im Sinne von Wissenschaft) zu sein, bzw. der Blog nicht auf eine professionale Betätigung in diesem Feld hinzudeuten.

Was den Schritt der möglichen Automatisierung betrifft, ja den sehe ich hier auch, aber eben nicht vollzogen. Damit eben aber auch nicht erfüllt. Das Startwertproblem, das es hier gilt zu lösen, komplett zu automatisieren, ist eben noch ein kleiner Schritt der zum Ziel fehlt. Und ein Marathon Läufer, der 2km vor dem Ziel aufgibt, har den Marathon eben nicht gelaufen ^^ Also technisch kein Problem, aber als Hobby Ziel nicht erreicht