Reverse Engineering: Pin sucht Kontakt

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?

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.