Das Fortis IRD Format

Transkript

1 Das Fortis IRD Format Version Juli 2011 smogm

2 Inhaltsverzeichnis 1 Das IRD Format Überprüfung des IRD Containers Der Flash-Vorgang Partitiontypes 5 3 Logischer Flash-Aufbau 6 4 Weitere Bootloader Checks SquashFS Prüfung Das Application Backup Aushebeln der SquashFS Prüfung Aushebeln des Application Backups Das Fortis IRD Format Seite 2

3 1 Das IRD Format Das vom koreanischen Unternehmen Fortis entwickelte IRD Format, ist ein variables Container Format in dem die Flash-Partitionen als einzelne Abbilder (Images) eingebettet sind. Der Container wird zusammen mit einem modifizierten uboot Bootloader, der ab Werk auf den Set top Boxen aufgespielt ist, zu einem komfortablen Firmware Update System für den Endkunden. Er muss nur den IRD Container auf einen FAT32 formatierten USB-Stick kopieren, und diesen am Receiver anschließen. Drückt der Anwender nun beim Einschalten des Gerätes eine bestimmte Taste wird der Bootloader in den Update-Modus getriggert und beginnt den USB-Stick nach Dateien mit der Endung *.ird zu durchsuchen. Findet er eine solche Datei wird diese zunächst vom USB-Stick in den lokalen, schnelleren Arbeitsspeicher kopiert und anschließend einer Prüfungsprozedur unterzogen. 1.1 Überprüfung des IRD Containers Bei der Überprüfung werden grundlegende Sicherheitsvorkehrungen überprüft. So enthält jeder IRD Container zu Beginn einen Header der Informationen über die folgenden Daten, und eine eindeutige Modellbezeichnung des für das Image gedachten Receivers mitliefert. Von diesem Header wurde beim Erstellen des IRD Containers zum Schutz vor leichtfertigen Modifikationen eine CRC16 Prüfsumme errechnet, und direkt nach dem Header im IRD Container angefügt. Der Bootloader liest den Header ein, und errechnet ebenso die CRC16 Prüfsumme und vergleicht diese mit der im Container gespeicherten. Stimmen beide überein wird zum nächsten Schritt übergegangen, unterscheiden sich die Prüfsummen wird der Vorgang mit einem Error Code ( ERR 0x?? ) im VFD des Receivers abgebrochen. Jeder Fortis-Reseller bekommt für jede Fortis Modellreihe eine sogenannte ResellerID zugeteilt. Diese ResellerID befindet sich hartcodiert im Bootloader. Bei der Überprüfung des IRD Containers wird nun zuerst geprüft ob die im IRD Container vermerkte ResellerID mit der eigenen ResellerID übereinstimmt. Ist dies der Fall wird mit dem nchsten Schritt fortgefahren. Ansonsten erscheint wieder ein Error Code im VFD. Das Fortis IRD Format Seite 3

4 1.2 Der Flash-Vorgang Nach dem IRD Header folgen die einzelnen Partitionen. Sie wurden beim Erzeugen des Containers in möglichst gleichgroße Blöche zerlegt und zlib deflate komprimiert. Das Resultat der Kompression wird anschließend mit einem 32 Bit Header versehen, der den Partitionstyp (2 Byte) und die ursprüngliche Länge (2 Byte) der vom Partitionsimage gelesenen Daten enthält. Von diesem komprimierten Block inclusive Header wird nun eine CRC16 Prüfsumme errechnet die in einen weiteren 32 Bit Header, zusammen mit der komprimierten Länge des Blocks (die tatsächlich im Container vorliegende Anzahl an Bytes des folgenden Blockes) angefügt wird. Aus diesem Wert kann der Bootloader zuverlässig den Beginn des nächsten Blocks errechnen. Dieser Vorgang wird wiederholt bis das Ende des Images erreicht ist. Der Bootloader geht den soeben beschriebenen Weg einfach rückwärts. Er liest die 16 Bit die die komprimierte Länge angeben, und anschließend die 16 Bit mit der CRC16. Danach wird die durch die compressed Length definierte Anzahl an Bytes gelesen und davon erneut die CRC16 gebildet und mit der bereits gelesenen CRC16 verglichen. Stimmen beide überein und die uncompressed Length ist größer als die compressed Length wird der Block entpackt. Stimmen die CRC16 Summen nicht überein wird der Vorgang an dieser Stelle mit einem Error Code abgebrochen. Sind compressed Length und uncompressed Length gleich groß, wird der Block direkt ohne Dekomprimierung weiterverarbeitet. Das Fortis IRD Format Seite 4

5 Im Arbeitsspeicher setzt der Bootloader nun das ursprüngliche Image wieder Block für Block zusammen, bis entweder das Ende des IRD Containers erreicht ist, oder das Partitiontype-Byte eine neue Partition definiert. Nachdem das Partitionsabbild wieder unkomprimiert vorliegt wird es an die entsprechende Adresse, die aus dem Partitiontype resultiert, im Flash kopiert. Enthält der IRD Container noch weitere Partitionen wird der gleiche Vorgang dementsprechend wiederholt. Der IRD Header des kompletten Containers enthält zusätzlich noch die Anzahl der insgesamt im Container enthaltenen Blöcke, unabhängig vom Partitiontype. So kann schon vor dem Entpacken geprüft werden ob die Anzahl an Blöcken auch tatsächlich im Container verfügbar ist. 2 Partitiontypes Der Bootloader setzt ein festes Flash-Layout vorraus. Es gibt zehn einzelne Partitionen die mit einer eindeutigen ID gekennzeichnet werden. Die chronologische Reihenfolge der IDs entspricht nicht der logischen Position der Partitionen im Flash. ID Bezeichnung 0 Bootloader 1 Application 2 Configuration - first 258 KiByte 3 Configuration - next 258 KiByte 4 Configuration - next 128 KiByte 5 Configuration - next 128 KiByte 6 Kernel 7 Device 8 Root 9 User Von einer Fortis STB mit 32 MiByte Flash ausgegangen, sind vom Bootloader aus nur 26,75 MiByte beschreibbar. Das liegt daran dass die Applikations-Partition einmal gespiegelt wird. Die für die Applikation (im Folgenden kurz App ) genutzten 5 MiByte werden somit doppelt genuzt weshalb einmal 5 MiByte verloren gehen. Für die App werden somit insgesamt 10 MiByte verbraucht von denen nur 5 MiByte effektiv genutzt werden können. Weiterhin ist die 1 MiByte große Configuration-Partition in fünf einzelne Teile zerlegt, von denen nur die vier unteren Teile vom Bootloader beschrieben werden können. Deshalb gehen hier die 256 KiByte der oberen Partition ebenfalls für die Nutzung als flashbaren Bereich verloren. Das Fortis IRD Format Seite 5

6 3 Logischer Flash-Aufbau Entgegen der Partitiontype-Nummerierung befinden sich die einzelnen Partitionen in einer anderen Reihenfolge. Die in der folgenden Tabelle genannten Speicheradressen treffen nur auf die 32 MiByte Flash STBs zu! ID Bezeichnung Offset Länge Ende 0 Bootloader 0x x x002FFFFF 6 Kernel 0x x x005FFFFF Application Low 0x x x00AFFFFF 1 Application High 0x00B x x00FFFFFF 8 Root 0x x x017FFFFF 7 Device 0x x x01AFFFFF 2 Configuration1 0x01B x x01B3FFFF 3 Configuration2 0x01B x x01B7FFFF 4 Configuration3 0x01B x x01B9FFFF 5 Configuration4 0x01BA0000 0x x01BBFFFF Configuration5 0x01BC0000 0x x01BFFFFF 9 User 0x01C x x01FFFFFF Wie zu sehen ist, sind die Application Low und Configuration5 nicht per IRD Container ansprechbar. Deren Speicherbereiche können erst später, sobald der Linux-Kernel die Kontrolle des System übernommen hat, genutzt werden. Das Fortis IRD Format Seite 6

7 4 Weitere Bootloader Checks Der Fortis Bootloader prüft vor jedem Start des Linux-Kernels zuerst einige Partitionen auf deren Integrität. 4.1 SquashFS Prüfung Der Bootloader erwartet zunächst von zwei Partitionen ein zlib deflate komprimiertes SquashFS Dateisystem. - Application High - daraus resultiert die gespiegelte Application Low - Root Da SquashFS ein Read Only Dateisystem ist, werden dort normalerweise nach dem Flashen keine Veränderungen mehr durchgeführt. Aus diesem Grund errechnet Fortis von jeder SquashFS Partition eine CRC32 Prüfsumme und hängt diese vier Byte an das reguläre Ende der Partition an. Der Bootloader liest also den SquashFS Superblock ein, errechnet anhand der darin enthaltenen Informationen die absolute Größe der SquashFS Partition, springt an deren Ende und liest die CRC32 Prüfsumme. Anschließend wird über die komplette SquashFS Partition erneut die CRC32 Prüfsumme errechnet und diese mit der gespeicherten verglichen. Stimmt diese nicht überein wird der Bootvorgang mit einem Error Code abgebrochen. Wird also vor dem Erstellen des IRD Containers über die SquashFS Partition keine CRC32 Prüfsumme errechnet und nicht ans Ende angehängt, wird das System nicht booten. 4.2 Das Application Backup Der Bootloader prüft weiterhin vor dem Starten des Kernels ob die CRC32 Prüfsummen der SquashFS Partitionen in der Application Low und High identisch sind. Sind diese unterschiedlich kopiert der Bootloader die SquashFS Partition der App High in die App Low und startet anschließend. Der Bootloader versucht also die App High Partition als Backup zu nutzen, falls die für den regulären Betrieb genutzte App Low Partition beschädigt wird (warum auch immer bei Read Only Zugriff). Das Fortis IRD Format Seite 7

8 4.3 Aushebeln der SquashFS Prüfung Da der Bootloader in der App Low, App High und RootFS Partition ein bestimmtes zlib deflate komprimiertes SquashFS 3.1 erwartet, und ansonsten nichts akzeptiert, kann man sich eines Tricks bedienen. Der Bootloader prüft die SquashFS Dateisysteme mithilfe ihrer absoluten Länge, was bedeutet dass er die CRC32 nicht am Ende der Partition sucht, sondern am Ende des Dateisystems. Befindet sich also ein 1 MiByte großes SquashFS Dateisystem in einer 5 MiByte großen Partition, wird der Bootloader bei 1 MiByte + 1 das erste Byte der CRC32 erwarten. Ihm ist es egal was sich hinter der CRC32 befindet. Und genau das ist der Ansatz. Da die zlib deflate Kompression im Vergleich zu LZ- MA um einiges schlechter ist, lohnt es nicht ein selbst erzeugtes Image deflate zu komprimieren. Stattdessen kann man eine zlib deflate SquashFS Partition von minimaler Größe erzeugen, diese samt korrekter CRC32 an den Beginn der Partition stellen, und direkt hinter deren CRC32 ein beliebiges Dateisystem anbringen, z.b. SquashFS LZMA anhängen, das auch keine CRC32 mehr benötigt. Der Bootloader prüft im Folgenden dann nur die kleine Fake-Partition und wird damit zufrieden sein. Er startet dann den Kernel, der allerdings wissen muss dass sich das echte Dateisystem erst einige Byte hinter dem eigentlichen Beginn der Partition befindet. An dieser Stelle ist es auch notwending zu wissen wie die Blockgröße des verbauten NAND Flash ist. Da ein Flash nur Blockweise gelesen und geschrieben werden kann darf die neue Partition erst an einem neuen sogenannten Erase-Block beginnen. Ist die Fake-Partition beispielsweise 200 Byte groß, die Block-Size beträgt allerdings 256 KiByte, dann darf das echte Dateisystem nicht ab Byte 200 beginnen, sondern frühestens ab dem Byte. Das Fortis IRD Format Seite 8

9 4.4 Aushebeln des Application Backups Wie bereits im Punkt zuvor erwähnt errechnet der Bootloader die CRC32 absolut und beachtet den Inhalt der Partition hinter dem Ende dem Fake-SquashFS Dateisystem nicht weiter. Dies eröffnet die Möglichkeit in App Low und App High hinter dem Fake Dateisystem völlig verschiedene Daten zu speichern, und so nahezu die kompletten 10 MiByte nutzbar zu machen. Da der Bootloader in App Low und App High nur jeweils das kleine Fake Dateisystem prüft, wird nur einmal nach dem ersten Flashen dieses von App High nach App Low kopiert. Der Kernel kann anschließend beide dahinter liegenden Bereiche als getrennte Dateisysteme einbinden und die App Low dann im Betrieb JFFS2 formatieren und als solches nutzen. Das Fortis IRD Format Seite 9