- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,156
- Punkte für Reaktionen
- 1,707
- Punkte
- 113
Die in Freetz als "junk bytes" behandelten zusätzlichen Daten in einem SquashFS-Image sind ja in Wirklichkeit Maschinencode zur "Weiterleitung" eines Interrupts, wenn man sie mal durch einen Disassembler jagt:
Das ist m.W. die längste Sequenz, die bisher gefunden wurde ... die als v1 und v2 bezeichneten Versionen haben kürzere Befehlsfolgen (bei v2 fehlt das "move to coprocessor 0" für das k1-Register und bei v1 auch das für k0).
Es handelt sich um den Code zur Behandlung von nicht-maskierbaren Interrupts (als "post-reset and NMI entry point" beschrieben "in der Literatur"), der bei MIPS-Architekturen standardmäßig erst mal mit 0xBFC00000 als Basisadresse startet (siehe hier, ist zwar 74k, aber in diesem Aspekt abwärtskompatibel), was bei entsprechendem Speicherausbau und Layout dann mitten im (NOR-)Flash-Mirror liegt. Da wird dann nicht lange gefackelt an dieser Stelle im Speicher und der Code ab 0x380 als Sprungziel verwendet, das "or" für den low-order-Teil der Adresse könnte zwar dazu führen, daß die sieben niederwertigsten Bits von k0 "überleben" (was 128 / 4 = 32 mögliche unterschiedliche Sprungadressen mit korrektem Alignment ergäbe), aber ich vermute mal, das sind auch nur Null-Bits und da wird tatsächlich direkt zur Instruktion verzweigt, die an der Adresse KSEG0+0x380 steht (das wird vermutlich sogar direkt wieder ein "jump" an die Adresse des passenden Handlers sein oder ein "branch" - je nach Entfernung).
Soviel als Einleitung ... warum "erzähle" ich das überhaupt? Ich baue gerade etwas am "unsquashfs" herum, um für das automatische Inventarisieren der von AVM verwendeten öffentlichen Schlüssel (beim Thema "Signieren und Prüfen") tatsächlich nur ein einziges Programm zum Extrahieren von Dateien aus einer filesystem.image oder dem kombinierten kernel.image zu benötigen. Selbst wenn man dann den Superblock direkt in einem "hidden root image" sucht und findet, muß man ja immer noch um den zusätzlichen Block mit diesem Code (und ein paar Längenangaben dahinter) "herumlesen". Bisher habe ich das immer ignoriert (dann ließ sich diese Firmware eben nicht nach "losetup" mit passendem Offset direkt entpacken, was die Alternative ist, wenn man nicht direkt im "unsquashfs" so ein Offset berücksichtigt), aber jetzt würde ich in das "unsquashfs4" mit "legacy support" von @er13 doch gerne noch die Behandlung dieses Spezialfalls einbauen, weil es dann wirklich nur noch dieses eine einzige Programm braucht, um alle bisher bekannten Dateisystemvarianten im FRITZ!OS zu entpacken, ohne erst irgendwelche Kopfstände mit Umkopieren machen zu müssen. Gerade auf der Box selbst spart das natürlich auch noch jede Menge Platz im tmpfs bzw. das ständige Aufräumen nach solchen Dateioperationen.
Der Umstieg auf ein "unsquashfs"-Programm, was das auch für Version 4 des Dateisystem-Formates beherrscht, ist indirekt durch AVM "erzwungen", nachdem mit der 7360v2/v3 ja ein Modell mit so einem Format versorgt wurde, wo auch Version 4 verwendet wird. Anstatt jetzt aber beim Vorhandensein einer "_nmi_vector_location"-Struktur im Image wieder auf den "alten Weg" mit Kopieren auszuweichen, würde ich Nägel mit Köpfen machen und dem Programm das "Überlesen" beibringen wollen. Soviel zur Motivation und zum Ziel ...
Meine Frage in die Runde an dieser Stelle wäre es, ob irgendjemand eine Liste hat oder zumindest kennt, in der die Modelle aufgeführt sind, die diese Struktur im Image enthalten und möglichst auch noch, welche Instruktionen dort enthalten sind bzw. wie lang die Blöcke sind, sprich welche Version (nach Freetz-Lesart) die Boxen verwenden. Im "remove-junk-bytes"-Skript im Trunk sind leider nur die Versionen aufgelistet, aber keine FRITZ!Box-Modelle.
Ich würde gerne vor dem Start des vollständigen Inventarisierens sicherstellen, daß meine Änderung tatsächlich für alle bekannten Versionen dieser Struktur funktioniert und dabei dann auch wissen wollen/müssen, ob es derzeit bekannte Modelle gibt, bei denen die Firmware nicht entpackt werden kann, weil der Block zwar vorhanden, aber nicht an 0xBE0000 zu finden ist (die müßten dann eine andere Größe der Bootloader-Partition verwenden anstelle der 128 KB, die sich aus 0xBE0000 ergeben würden).
Wenn ich das richtig sehe, würde das "remove-junk-bytes" in Freetz bisher solche Images gar nicht behandeln und da wäre eben die Frage, ob es Modelle gibt (nach den Änderungen von @er13 für die 6480), bei denen es immer noch nicht mit dem Entpacken/Splitten funktioniert und die ich auf eine Abweichung vom bisher Bekannten untersuchen könnte.
Die abschließende "jr k0"-Instruktion bei v3 ist ja meinerseits auch nur geraten, weil da in "remove-junk-bytes" die Überprüfung schon vorher abgebrochen wird (der von AVM reservierte Platz für den Code ist 64 Byte lang, die _nmi_vector_location-Struktur sollte immer an der effektiven Adresse 0xBFC00040 im Speicher liegen, wenn man die Verschiebung durch den Bootloader berücksichtigt und der Logik folgend, müßte natürlich an Offset 16 dann auch noch ein Befehl nach dem "or immediate" kommen bei v3) - solange ich nicht weiß, welche Box nun so einen Block in v3 verwendet, ist es ziemlich aussichtslos, da die richtigen Quellen zu konsultieren.
Was dieses "nmi vector gap" am Ende bewirkt, wie es beim Scannen nach Partitionen im Speicher beseitigt und beim Lesen aus den Flash-Chips auf "normalem Weg" auch noch ausgeblendet wird, kann man sich in den diversen Kernel-Quellen ja ansehen ... solange man aber keine vollständige Liste der betroffenen Modelle hat, ist das ziemlich umständlich und zeitraubend; daher zunächst mal die Frage, ob jemand so eine Liste bereits hat oder weiß, wo man eine finden könnte.
Code:
:00000000 409ae805 mtc0 k0,c0_datahi2
:00000004 409be004 mtc0 k1,c0_taglo2
:00000008 3c1a8000 lui k0,0x8000
:0000000c 375a0380 ori k0,k0,0x380
:00000010 03400008 jr k0
Es handelt sich um den Code zur Behandlung von nicht-maskierbaren Interrupts (als "post-reset and NMI entry point" beschrieben "in der Literatur"), der bei MIPS-Architekturen standardmäßig erst mal mit 0xBFC00000 als Basisadresse startet (siehe hier, ist zwar 74k, aber in diesem Aspekt abwärtskompatibel), was bei entsprechendem Speicherausbau und Layout dann mitten im (NOR-)Flash-Mirror liegt. Da wird dann nicht lange gefackelt an dieser Stelle im Speicher und der Code ab 0x380 als Sprungziel verwendet, das "or" für den low-order-Teil der Adresse könnte zwar dazu führen, daß die sieben niederwertigsten Bits von k0 "überleben" (was 128 / 4 = 32 mögliche unterschiedliche Sprungadressen mit korrektem Alignment ergäbe), aber ich vermute mal, das sind auch nur Null-Bits und da wird tatsächlich direkt zur Instruktion verzweigt, die an der Adresse KSEG0+0x380 steht (das wird vermutlich sogar direkt wieder ein "jump" an die Adresse des passenden Handlers sein oder ein "branch" - je nach Entfernung).
Soviel als Einleitung ... warum "erzähle" ich das überhaupt? Ich baue gerade etwas am "unsquashfs" herum, um für das automatische Inventarisieren der von AVM verwendeten öffentlichen Schlüssel (beim Thema "Signieren und Prüfen") tatsächlich nur ein einziges Programm zum Extrahieren von Dateien aus einer filesystem.image oder dem kombinierten kernel.image zu benötigen. Selbst wenn man dann den Superblock direkt in einem "hidden root image" sucht und findet, muß man ja immer noch um den zusätzlichen Block mit diesem Code (und ein paar Längenangaben dahinter) "herumlesen". Bisher habe ich das immer ignoriert (dann ließ sich diese Firmware eben nicht nach "losetup" mit passendem Offset direkt entpacken, was die Alternative ist, wenn man nicht direkt im "unsquashfs" so ein Offset berücksichtigt), aber jetzt würde ich in das "unsquashfs4" mit "legacy support" von @er13 doch gerne noch die Behandlung dieses Spezialfalls einbauen, weil es dann wirklich nur noch dieses eine einzige Programm braucht, um alle bisher bekannten Dateisystemvarianten im FRITZ!OS zu entpacken, ohne erst irgendwelche Kopfstände mit Umkopieren machen zu müssen. Gerade auf der Box selbst spart das natürlich auch noch jede Menge Platz im tmpfs bzw. das ständige Aufräumen nach solchen Dateioperationen.
Der Umstieg auf ein "unsquashfs"-Programm, was das auch für Version 4 des Dateisystem-Formates beherrscht, ist indirekt durch AVM "erzwungen", nachdem mit der 7360v2/v3 ja ein Modell mit so einem Format versorgt wurde, wo auch Version 4 verwendet wird. Anstatt jetzt aber beim Vorhandensein einer "_nmi_vector_location"-Struktur im Image wieder auf den "alten Weg" mit Kopieren auszuweichen, würde ich Nägel mit Köpfen machen und dem Programm das "Überlesen" beibringen wollen. Soviel zur Motivation und zum Ziel ...
Meine Frage in die Runde an dieser Stelle wäre es, ob irgendjemand eine Liste hat oder zumindest kennt, in der die Modelle aufgeführt sind, die diese Struktur im Image enthalten und möglichst auch noch, welche Instruktionen dort enthalten sind bzw. wie lang die Blöcke sind, sprich welche Version (nach Freetz-Lesart) die Boxen verwenden. Im "remove-junk-bytes"-Skript im Trunk sind leider nur die Versionen aufgelistet, aber keine FRITZ!Box-Modelle.
Ich würde gerne vor dem Start des vollständigen Inventarisierens sicherstellen, daß meine Änderung tatsächlich für alle bekannten Versionen dieser Struktur funktioniert und dabei dann auch wissen wollen/müssen, ob es derzeit bekannte Modelle gibt, bei denen die Firmware nicht entpackt werden kann, weil der Block zwar vorhanden, aber nicht an 0xBE0000 zu finden ist (die müßten dann eine andere Größe der Bootloader-Partition verwenden anstelle der 128 KB, die sich aus 0xBE0000 ergeben würden).
Wenn ich das richtig sehe, würde das "remove-junk-bytes" in Freetz bisher solche Images gar nicht behandeln und da wäre eben die Frage, ob es Modelle gibt (nach den Änderungen von @er13 für die 6480), bei denen es immer noch nicht mit dem Entpacken/Splitten funktioniert und die ich auf eine Abweichung vom bisher Bekannten untersuchen könnte.
Die abschließende "jr k0"-Instruktion bei v3 ist ja meinerseits auch nur geraten, weil da in "remove-junk-bytes" die Überprüfung schon vorher abgebrochen wird (der von AVM reservierte Platz für den Code ist 64 Byte lang, die _nmi_vector_location-Struktur sollte immer an der effektiven Adresse 0xBFC00040 im Speicher liegen, wenn man die Verschiebung durch den Bootloader berücksichtigt und der Logik folgend, müßte natürlich an Offset 16 dann auch noch ein Befehl nach dem "or immediate" kommen bei v3) - solange ich nicht weiß, welche Box nun so einen Block in v3 verwendet, ist es ziemlich aussichtslos, da die richtigen Quellen zu konsultieren.
Was dieses "nmi vector gap" am Ende bewirkt, wie es beim Scannen nach Partitionen im Speicher beseitigt und beim Lesen aus den Flash-Chips auf "normalem Weg" auch noch ausgeblendet wird, kann man sich in den diversen Kernel-Quellen ja ansehen ... solange man aber keine vollständige Liste der betroffenen Modelle hat, ist das ziemlich umständlich und zeitraubend; daher zunächst mal die Frage, ob jemand so eine Liste bereits hat oder weiß, wo man eine finden könnte.