Reverse Engineering: Pin sucht Kontakt
Ohne die notwendige Hardware-Unterstützung ist auch ein lauffähiges Linux nicht viel Wert. Mit einigen Tricks analysieren wir, wie der Prozessor die Hardware eines Oszilloskops ansteuert.
Im dritten Teil meiner fünfteiligen Serie zur Analyse eines Oszilloskops per Reverse Engineering versuche ich, herauszufinden, welche Funktion die GPIO-Pins des SoC haben. Bis jetzt habe ich es geschafft, Linux auf dem Oszilloskop zum Laufen zu bekommen und weiß, was alles in dessen Flashspeicher steckt.
Wo anfangen?
- Reverse Engineering: Pin sucht Kontakt
- I2C mit Linux
- Mal eben einen Treiber schreiben
- Arbeite cleverer, nicht fleißiger
- Ein kurzer Schreckmoment
Disassemblierten Binärcode zu analysieren, ist aufwendig und langweilig. Die 3 MByte große Binärdatei mit dem originalen Betriebssystem des Oszilloskops durchzugehen, würde Jahre brauchen, deswegen habe ich beschlossen, eine Abkürzung zu nehmen.
Was mich am meisten interessiert, ist Code, der mit der Hardware interagiert, sprich die GPIO-Pins. Üblicherweise lädt der entsprechende Code zum Zugriff auf die GPIO-Register die Basis-Adresse der zugehörigen GPIO-Bank in ein CPU-Register und steuert dann den Pin mit einer Kombination aus CPU-Register plus Offset-Wert des jeweiligen GPIO-Registers des betreffenden Pins. Eine Bank ist hier ein zusammenhängender Speicherbereich, der eine Anzahl von Pins und ihre Eigenschaften repräsentiert.
Die Basis-Adresse für die GPIO-Register ist 0x56000000. Und der Binärcode für eine ARM-Instruktion, um einen Wert in ein CPU-Register zu laden, ist 0xe3a0?456. Das Fragezeichen steht für die CPU-Register-Nummer und die 56 am Ende sind die höchsten 8 Bit der Adresse. Die Suche ist nun recht trivial, ich gebe die Betriebsystemdatei "os" aus, leite die Ausgabe an das Kommandozeilenprogramm less um und verwende dessen /-Kommando, um nach den Bytes der Instruktionen suchen zu lassen.
$ hd "os" | less /56 .4 a0 e3
Dann benutze ich das Programm Medusa, um den Code um die Fundstellen anzuschauen und zu analysieren. Immer noch aufwendig, aber immer noch besser, als den gesamten Code durchzugehen.
Ein Blick auf die Fundstellen
So finde ich zum Beispiel einige Wrapper-Funktionen, mit denen die GPIO-Pins GPB4 und GPB9 gesteuert werden.
Das ist an sich noch wenig nützlich. Aber ich versehe die Funktionen mit beschreibenden Namen und setze die Disassemblierung fort. So stoße ich auf den Code, wo diese Funktionen aufgerufen werden.
Wie bereits an den Funktionsnamen erkennbar, habe ich schon herausgefunden, dass diese Pins für den I2C-Bus benutzt werden. Die erste Funktion i2c_start konfiguriert die beiden Pins für die Ausgabe und setzt dann GPB4 und GPB9 auf Low. Die zweite Funktion setzt GPB4 zuerst auf Low, GPB9 auf High und danach GPB4 ebenfalls auf High.
Hier ist eine Abbildung aus einem I2C-Tutorial, wie der Signalverlauf auf dem I2C-Bus aussieht:
Wenn GPB4 die SDA-Leitung ansteuert und GBP9 die SCL-Leitung entspricht der Code perfekt den I2C-Start- und Stop-Signalen. Weitere Funktionen im Binärcode an dieser Stelle implementieren Schreib- und Lese-Operationen für den I2C-Bus.
I2C mit Linux |
Ähm, ja.... Was meinst du wie Leute wie der ursprüngliche Autor gefragt sind...
heißen die Dinger hier. Vielleicht bin ich aber auch nur zu oldschool :)
Einfach nur große Klasse. Könnten sich andere eine Scheibe von abschneiden.