Reverse Engineering: Wie das Oszilloskop bootet

Im ersten Teil einer fünfteiligen Serie habe ich Linux auf einem Oszilloskop zum Laufen bekommen. In Teil zwei meiner Serie zur Analyse eines Oszilloskops per Reverse Engineering erkunde ich den Bootvorgang des Oszilloskops und untersuche dessen Dateisystem - wobei ich mir zum Schluss ein wenig die Haare raufe.

Die CPU im Oszilloskop ist ein Samsung S3C2416-SoC mit DDR2-SDRAM als Arbeitsspeicher und einem NAND-Flash-Speicher als Massenspeicher - ein einfaches Embedded-System, das Samsungs SMDK2416-Referenzdesign sehr ähnlich ist.

Ich habe schon mit anderen SoCs (System-on-a-Chip) der S3C24xx-Familie gearbeitet, ich weiß ungefähr, wie der Bootloader funktioniert und mit dem Flash-Speicher umgehen müsste. NAND-Speicherbausteine sind ein wenig unzuverlässig, mit der Zeit entwickeln sich Bitfehler und einige Speichersektionen sind dann derart kaputt, dass sie überhaupt nicht mehr verwendet werden können.

Jedes Flash-Dateisystem unterstützt deshalb Fehlerkorrekturcodes (ECC), um Bitfehler zu korrigieren und fehlerhafte Sektionen umzukopieren. Viele Flash-Speicher-Hersteller garantieren allerdings, dass im ersten Sektor oder in den ersten drei Sektoren des Speichers niemals Fehler auftreten werden. Deswegen kann dort ein sehr kleiner Bootloader untergebracht werden, der sogenannte First-Stage-Bootloader.

Im ROM der CPU befindet sich ein Programm, das die ersten 8 KByte vom Flash-Speicher in den 64 KByte großen RAM der CPU kopiert und dann ausführt. Dieser First-Stage-Bootloader führt einige Basiskonfigurationen durch, etwa die Konfiguration der GPIO-Pins und die Initialisierung des DDR-Speichers. Dann lädt er den größeren Second-Stage-Bootloader aus dem Flash-Speicher, kopiert ihn in den DDR-Speicher und führt diesen aus. Der First-Stage-Bootloader sollte ECC beherrschen und Flash-Sektoren umkopieren können, um zuverlässig mit den Einschränkungen des Flash-Speichers umzugehen.

Der Bootvorgang nach dem Bootvorgang

Wenn Anwender vom Bootloader sprechen, meinen sie meist den Second-Stage-Bootloader. Er hat zumeist eine Kommandoeingabe, die über einen seriellen Anschluss oder USB verfügbar ist. Er lädt das Betriebsystem, zum Beispiel von einem Flash-Speicher und verfügt dafür über eine einfache Implementierung eines geeigneten Dateisystems. Um die Entwicklung zu vereinfachen, kann ein Bootloader manchmal auch ein Betriebssystem über die serielle Schnittstelle, USB oder Ethernet laden.

Den Inhalt des Flash-Speichers analysieren

Als ich per JTAG auf das Oszilloskop zugreifen kann, erstelle ich als Erstes ein komplettes Abbild des Flash-Speichers. Die CPU lädt den First-Stage-Bootloader aus den ersten 8 KByte des Flash-Speichers, also fange ich dort an. Ich sehe einige Zeichenketten, die dem gleichen, was ich auf der seriellen Ausgabe gesehen habe, nachdem ich das Oszilloskop angeschaltet hatte. Andere Zeichenketten deuten auf eine Art Speicherinitialisierung und einen Speichertest hin. Soweit entspricht der Code zum Glück also meinen Erwartungen.

00000a30  30 31 32 33 34 35 36 37  38 39 41 42 43 44 45 46  |0123456789ABCDEF|
00000a40  4c 49 4c 4c 49 50 55 54  0d 0a 00 44 53 4f 20 54  |LILLIPUT...DSO T|
00000a50  41 52 47 45 59 20 42 4f  41 52 44 20 56 45 52 20  |ARGEY BOARD VER |
00000a60  31 2e 30 0d 0a 00 54 45  53 54 20 53 44 52 41 4d  |1.0...TEST SDRAM|
00000a70  20 4d 45 4d 4f 52 59 0d  0a 00 4d 45 4d 4f 52 59  | MEMORY...MEMORY|
00000a80  20 41 4c 4c 20 4f 4b 0d  0a 00 4d 45 4d 4f 52 59  | ALL OK...MEMORY|
00000a90  20 54 45 53 54 20 46 41  49 4c 0d 0a 00 45 52 4f  | TEST FAIL...ERO|
00000aa0  52 52 20 41 44 44 52 45  53 53 20 00 4f 4b 20 00  |RR ADDRESS .OK .|
00000ab0  45 4e 54 45 59 20 4d 41  49 4e 00 00 04 f0 1f e5  |ENTEY MAIN......|

Dem First-Stage-Bootloader folgt wahrscheinlich der Second-Stage-Bootloader. Und tatsächlich taucht später im Abbild eine Liste von Zeichenketten auf, die nach Befehlen für eine Kommandozeile aussehen. Das sieht vielversprechend aus.

Außerdem habe ich den Eindruck, dass der Bootloader yaffs implementiert, ein beliebtes Dateisystem für NAND-Flash-Speicher für Linux, das auch unter einer kommerziellen Lizenz für andere Plattformen verfügbar ist.

Es ist recht eindeutig, wo der Bootloader aufhört. Nach 75 KByte kommen im Abbild nur 0xff-Werte. Dabei handelt es sich um den Standardwert, wenn Flash-Speicher gelöscht wird. Das geht so weiter, bis nach 640 KByte etwas anfängt, das nach einem Dateisystem aussieht.

Ich speichere die ersten 75 KByte in einer eigenen Datei.