[Frage] Übersicht von FRITZ!Boxen mit "junk bytes" im SquashFS-Image?

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
15,138
Punkte für Reaktionen
1,703
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:
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
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.
 
Im "remove-junk-bytes"-Skript im Trunk sind leider nur die Versionen aufgelistet, aber keine FRITZ!Box-Modelle.

Hallo PeterPawn,
mir sind 3 AVM-Devices bekannt, die "junk-bytes" in ihren FW-Images verwenden:
  • FB4020
  • FB6810
  • FB6842
siehe auch: http://www.freetz.org/browser/trunk/tools/remove-junk-bytes?rev=13345

Gruß
PantaRhei

PS: für etwaige unsquasfs-/mksquashfs-Tests mit Build-In remove-junk-bytes Funktion (repack_fw) von DVB-C Geräte stehe ich gerne zur Verfügung

EDIT: DVB-C gemäß Hinweis von Opto #5 aus Liste entfernt
 
Zuletzt bearbeitet von einem Moderator:
@PantaRhei:
Ja, mein Zahlendreher und die von Dir verlinkte Liste sind - nach dem CS-Comment - alle v2.

Die 7270 und die 7390 haben auch den NMI-Vector, da beide in v1 - die kenne ich auch schon.

Danke für die Hinweise ...

@opto:
Kenne ich ... vielleicht habe ich es etwas unglücklich ausgedrückt: Ich bin mehr auf der Suche nach unbekannten und bisher nicht korrekt behandelten Modellen, wo ich dann in der von mir gesuchten "Liste" entsprechende Hinweise erwarten würde.

Kann man tatsächlich davon ausgehen, daß die Einstellung für die Boxen in Freetz immer stimmt? Für die (für Freetz wohl nicht relevante) Unterscheidung zwischen den verschiedenen Längen und Befehlsfolgen gibt es nicht auch noch ein FREETZ-Symbol? Wenn doch, welches? Gibt es Boxen, die Freetz bekanntermaßen nicht entpacken kann (natürlich MIPS, nicht ARM/ATOM)?

Gibt es am Ende gar keine Boxen, die 64 KB oder 256 KB beim Bootloader verwenden und dann gleichzeitig den Einsprung an Adresse 0xBFC00000 berücksichtigen oder haben die dann alle einen über SI_ExceptionBase verschobenen RBASE-Wert?

Wenn das wirklich so wäre, braucht man das nicht gesondert zu behandeln und kann (wie remove-junk-bytes) einfach mit 0xBE0000 rechnen. Ich wüßte ohnehin nicht so richtig, wie ich außerhalb der richtigen Box die korrekte Größe der Bootloader-Partition ermitteln sollte, da müßte man dann ohnehin bei 0xBC0000 (256 KB) bzw. 0xBF0000 (64 KB) eine weitere Suche durchführen und daraus dann auf die Bootloader-Size schließen.

Wie sieht das denn bei den älteren Modellen aus (auch wenn die vermutlich gar kein SquashFS3 verwenden und der "legacy mode" (müßte ich prüfen) vielleicht gar kein SquashFS2 bietet), die 7170 hat ja 64KB Bootloader, allerdings geht dort der Flash mit seinen 8 MB ja ohnehin nicht bis 0xC00000 (12 MB), so daß da wohl irgendetwas anderes (hardwired) beim Reset-Signal eingeblendet wird (nur dafür ist das ja wirklich interessant, wenn ich es richtig interpretiere).

Ich könnte das tatsächlich alles selbst nachsehen ... hatte halt eine kleine Hoffnung, daß irgendjemand so eine Liste bereits hat und ich mir die Arbeit sparen kann. So wird es wohl darauf hinauslaufen, daß ich meine offenen Fragen einfach selbst ignoriere und nur die Fälle korrekt behandele, die ich selbst kenne bzw. die man aus "remove-junk-bytes" ableiten kann.

Ich wollte mehr auf die "Exoten" anstelle der (ehemaligen) Flagships hinaus ... da könnte ja auch mal eine 7170-Variante (bzw. AR7-) mit mehr als 8 MB Flash dabei gewesen sein (diese kenne ich gar nicht alle, nicht mal dem Namen nach) und diese müßte dann tatsächlich (wenn die anderen Voraussetzungen zusammenkommen) da eine abweichende Behandlung erfordern. Auch die ganzen anderen Ableger mit UR8 müßten ja irgendwie damit umgehen, bei meiner 7270v3 habe ich nachgesehen (da habe ich die Quellen ohnehin rumliegen).

Bei den Modellen mit SPI- und NAND-Flash dürfte das nach meiner Ansicht nicht zu behandeln sein, denn da wird wohl beim Reset eher kein Flash-Inhalt (zumindest keiner, den man beschreiben könnte, eher ein paar wenige ROM-Zellen) an 0xBFC00000 eingeblendet sein - da sind eben keine 12 MB verbaut (und bei SPI muß da ohnehin noch irgendein Controller dazwischen hängen, denn den kann man ja nicht direkt über den Bus adressieren).

Wobei ich immer noch ein kleines Verständnisproblem habe ... wenn das tatsächlich die "Einsprungadresse" nach einem Reset-Signal (oder nach NMI, wenn der regulär im Betrieb verwendet werden sollte,wobei der später per MMU auch woanders liegen kann) ist und da liegt aber im ROM (solange die MMU nicht initialisiert wurde, ist halt der ROM-Inhalt direkt gemappt, oder?) an der Adresse 0xBFC00000 vollkommen anderer Code, weil das zu schreibende Image den Platz nicht "freigehalten" hat, dann dürfte der Prozessor aus meiner Sicht gar nicht in den Bootloader kommen (die 0x380 liegt ja dann bei direktem ROM-Mapping innerhalb des Bootloaders).

Die einzig plausible Erklärung, die mir da einfallen würde, wäre eine "Spezialbehandlung" in flash_update.ko, wo dann beim Schreiben halt derselbe Versatz organisiert wird (und der fehlende Block mit dem aktuellen Vector gefüllt wird), wie er in den diversen Flash-Treibern (die dazu das "set_nmi_vetor_gap" enthalten und das fehlende "c" ist tatsächlich bei AVM schon verschwunden (und wird genauso "gepflegt" wie das "mounth" im TFFS) und nicht erst bei mir ... ich glaube auch nicht, daß diese Funktion von einem Brasilianer in einer Mischung aus Englisch und Portugiesisch benannt wurde) dann beim Lesen wieder berücksichtigt wird.

Hat irgendjemand mit einem Freetz-Image in der Box (das hat ja keinen NMI-Vector) mal mit JTAG den tatsächlichen Inhalt der Flash-Chips ausgelesen? Das Lesen aus dem laufenden System heraus blendet diesen Bereich ja extra aus ... in den verschiedenen Quellen für die Flash-Chips nachzulesen und den deutschen Kommentaren nach zu urteilen auch eine "AVM-Spezialität" ... daher kann ich mir auch vorstellen, daß es beim Schreiben ebenfalls berücksichtigt wird, selbst wenn sich so auf den ersten Blick keine dazu passenden Zeichenketten finden lassen im Treiber-Binary (EDIT: hier meine ich den flash_update.ko, nicht den Chip-Treiber).
 
Zuletzt bearbeitet:
Hallo Opto und andere Interessierte,
habe gerade bzgl. FB4020 und DVB-C nachgesehen:
Code:
freetz@freetz-vm:~/freetz-trunk$ ./fwmod -u -d unpacked_firmware FRITZ.Box_4020.de-en-es-it-fr-pl.147.06.50.image
STEP 1: UNPACK
unpacking firmware image
Skipping 0 Bytes garbage...removing AVM SquashFS junk bytes
[COLOR=#0000ff]Junk header v3 found at offset 0xBE0000, removing v3 junk bytes ... done.[/COLOR]
splitting kernel image
unpacking filesystem image
    Reading a different endian SQUASHFS filesystem on unpacked_firmware/original/kernel/kernelsquashfs.raw
    Filesystem on unpacked_firmware/original/kernel/kernelsquashfs.raw is lzma compressed (3:76)
    Parallel unsquashfs: Using 1 processor
    2832 inodes (3239 blocks) to write
    created 2324 files
    created 188 directories
    created 422 symlinks
    created 86 devices
    created 0 fifos
unpacking AVM plugins
    webcm_interpreter image
unpacking var.tar
done.

detected firmware 4020_de-es-fr-it-pl 147.06.50 rev32833 (13.04.2016 12:28:12)

FINISHED
freetz@freetz-vm:~/freetz-trunk$

Code:
freetz@freetz-vm:~/freetz-trunk$ ./fwmod -u -d unpacked_firmware FRITZ.Box_WLAN_Repeater_DVB_C.133.06.32.image
STEP 1: UNPACK
unpacking firmware image
Skipping 0 Bytes garbage...splitting kernel image
unpacking filesystem image
    Reading a different endian SQUASHFS filesystem on unpacked_firmware/original/kernel/kernelsquashfs.raw
    Filesystem on unpacked_firmware/original/kernel/kernelsquashfs.raw is lzma compressed (3:76)
    Parallel unsquashfs: Using 1 processor
    1521 inodes (1781 blocks) to write
    created 1143 files
    created 88 directories
    created 292 symlinks
    created 86 devices
    created 0 fifos
unpacking var.tar
done.

WARNING: Failed to determine avm_fw_product, even though this is a cosmetic bug only please report it to the Freetz developers and provide your .config
detected firmware _de 133.06.32 rev31507 (01.10.2015 17:40:12)

FINISHED
freetz@freetz-vm:~/freetz-trunk$

Tatsächlich, bei DVB-C sind keine "Junk-Bytes" vorhanden. Da bin ich durch die SoC-Architekturnähe zw. FB4020 und DVB-C fehlgeleitet worden.
Habe #2 bzgl. DVB-C angepasst.

Gruß
PantaRhei
 
Ich habe mir gerade mal das Ticket zu den "junk bytes" durchgelesen (das kannte ich noch nicht, gibt es denn den von @hippie2000 angesprochenen "alles-entpacker" irgendwo bisher? - dann muß man den sicherlich nicht neu erfinden) ... damals mag der AVM-Code noch nicht vorgelegen haben, inzwischen ist der AVM-eigene Code zum Lokalisieren der _nmi_vector_location-Struktur ja nachzulesen (z.B. bei der 7390 in arch/mips/fusiv/fusiv_mips32/fusiv_mtd.c in find_nmi_vector_gap()) und damit wäre die auch von AVM verwendete Methode beim Scannen des Flashs (bzw. des RAMs, denn dort wird nur bei "mtdram"-Partitionen nach der Lücke gesucht und die sind sicherlich auch dort eine 1:1-Kopie von "kernel.image" - bei "hidden root" ja dann ohne gesondertes Filesystem ... beim Systemstart aus dem Flash liegt die ohnehin fix an 0xBFC00040) dann, bei Offset 0x40 ab der Basis-Adresse (der RAM-Partition) zu starten und den Speicher von dort bis zur Basisadresse+0xBE0040 jeweils in 256-Byte-Schritten zu durchsuchen - wobei die Ende-Adresse vielleicht doch wieder modellspezifisch ist, denn die ist für meinen Geschmack bei der erwähnten 7390 dann zu fest verdrahtet, bei 64 KB Bootloader könnte die Struktur auch erst an Offset 0xBF0040 liegen.

Dabei wird dann immer an Offset 8 (nach den Längenfeldern aus der nmi_vector_location) ein String-Vergleich auf "NMI Boot Vector" ausgeführt. Die Tatsache, daß AVM da selbst in 256-Byte-Schritten sucht, würde ich so interpretieren, daß es (vielleicht aus reiner Vorsicht) auch denkbar wäre, daß es kein 64 KB-Alignment für den Start des Kernel-Images gibt (was im Flash nach dem Bootloader ja vorhanden wäre). Zumindest sollte man aber bei der Verwendung genau desselben Algorithmus dann auch auf der sicheren Seite sein, daß es eben immer an einer Adresse liegt, die auf 0x40 endet und nicht plötzlich an einem vollkommen anderen Offset.

Der Bereich selbst beginnt dann eben 64 Byte vor dieser Adresse und die Länge steht wieder in der nmi_vector_location direkt drin. Alles andere (angefangen bei der Suche mit der Image-Größe und dem Ausrechnen, ob der Superblock mit seiner Länge dann zum ersten Wert in nmi_vector_location paßt) ist zwar als Plausibilität vielleicht nett, aber - wenn man AVM folgt - nicht notwendig (und damit dann wohl auch nicht gesichert, daß es immer so ist bzw. bleiben muß/wird).

Das hatte ich aus dem AVM-Code abgeleitet, aber der steht eben in jeweils einer "architekturspezifischen" Datei unterhalb von "arch" und unterscheidet sich - zumindest vom Dateinamen - auch von Modell (bzw. Prozessor) zu Modell. Daher die Frage, ob es bekannte Abweichungen gibt. Vielleicht macht das mein eigentliches "Anliegen" ja noch klarer ... ich suche praktisch nach einem Test-Case, der ggf. meinen Algorithmus (bzw. den von AVM in der 7390) invalidiert. Gibt es den nicht, ist es mir auch recht und ich lasse es so, wie es jetzt ist.

- - - Aktualisiert - - -

So, ich habe das Ergebnis für das Entpacken mit der SquashFS4-Version mit "legacy support" (auf der Basis der Änderungen von @er13 im Trunk, u.a. wird ja auch in Freetz seit CS 13352 nur noch mit diesem Tool entpackt) mal in meinen Fork eingecheckt.

Zum Bauen einer eigenen Version mit diesen Änderungen (nur als Hinweis an die, die es nicht ohnehin selbst wissen) einfach den Patch von https://raw.githubusercontent.com/P...hfs4-host/patches/910-superblock_offset.patch unter dem Pfad tools/make/squashfs4-host/patches/910-superblock_offset.patch in der eigenen Kopie des Trunks ablegen und mit make squashfs4-host-dirclean;make squashfs4-host die Variante für den Build-Host bzw. mit make squashfs4-dirclean;make squashfs4-precompiled die Variante für die FRITZ!Box selbst (das Ergebnis liegt dann unterhalb von packages, bei der ersten Variante unter tools direkt) neu erstellen lassen.

Um auch denen, die keine eigene Freetz-Umgebung unterhalten wollen (oder - aus welchem Grund auch immer - können), habe ich unterhalb des YourFritz-Repositories mal ein bin-Verzeichnis eingeführt, das auch künftig vermutlich erweitert wird. Im Moment gibt es dort jedenfalls Unterverzeichnisse für x86 und mips, in denen jeweils ein unsquashfs-Binary mit dem o.a. Patch liegt (bei x86 dynamisch, für mips statisch gelinkt) und ein mksquashfs4-avm, das nur ein umbenanntes Binary aus denselben Quellen ist (der Name ist bei manueller Verwendung schon sperrig genug, da habe ich das lzma und be im Namen ausgelassen).

Neben jeder dieser Dateien liegt dann auch noch eine GPG-Signatur unter Verwendung des Schlüssels, den ich für alle YourFritz-bezogenen Themen verwende und der ebenfalls im GitHub zu finden ist unter https://raw.githubusercontent.com/PeterPawn/YourFritz/master/PeterPawn.asc - der Schlüssel hat die keyid 30311D96 und den Fingerprint 0DF4 F707 AC58 AA38 B35A AA0B C04F CE52 3031 1D96 (was man auch vor der ersten Verwendung prüfen sollte, denn auch die Schlüsseldatei im GitHub ist ja ansonsten erst einmal ungesichert).

Mit dieser Version von unsquashfs kann man dann auch direkt eine kernel.image-Datei aus einem Firmware-Image von AVM entpacken:
Rich (BBCode):
$ mkdir demo
$ cd demo
$ wget -O - ftp://ftp.avm.de/fritz.box/fritzbox.fon_wlan_7390/firmware/deutsch/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.51.image | tar -O -x ./var/tmp/kernel.image >84.06.51_kernel.image
--2016-06-19 12:21:28--  ftp://ftp.avm.de/fritz.box/fritzbox.fon_wlan_7390/firmware/deutsch/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.51.image
           => ‘-’
Resolving ftp.avm.de (ftp.avm.de)... 212.42.244.98, 212.42.244.9, 212.42.224.71, ...
Connecting to ftp.avm.de (ftp.avm.de)|212.42.244.98|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD (1) /fritz.box/fritzbox.fon_wlan_7390/firmware/deutsch ... done.
==> SIZE FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.51.image ... 17100800
==> PASV ... done.    ==> RETR FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.51.image ... done.
Length: 17100800 (16M) (unauthoritative)

FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.51.image               100%[==================================================================>]  16.31M  2.74MB/s   in 6.1s

2016-06-19 12:21:34 (2.68 MB/s) - written to stdout [17100800]

$ ls -l
total 14816
-rw-r--r-- 1 root root 15168280 Jun 19 12:21 84.06.51_kernel.image
$ unsquashfs -k -stat 84.06.51_kernel.image
Found superblock at 0x00153300 while scanning 84.06.51_kernel.image.
NMI vector gap found at 0x00BE0000, size=256
There's a TI CRC checksum at the end of the image.
Reading a different endian SQUASHFS filesystem on 84.06.51_kernel.image
Found a valid big endian SQUASHFS 3:76 superblock on 84.06.51_kernel.image.
Creation or last append time Mon Apr 25 12:46:02 2016
Filesystem size 13455.77 Kbytes (13.14 Mbytes)
Compression lzma
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Check data is not present in the filesystem
Duplicates are removed
Number of fragments 250
Number of inodes 6320
Number of uids 1
Number of gids 0
Die drei roten Zeilen sind zusätzlich in der Ausgabe und können z.B. dazu genutzt werden, das Image dann doch wieder in seine Bestandteile zu zerlegen, wenn man es vielleicht anders wieder zusammensetzen will (selbst den NMI-Vector-Block könnte man ja mit dd ausschneiden und in ein selbst erstelltes Image wieder einbauen).

Das ist auch schon der einzige Grund, warum dieses Programm auch noch nachschaut, ob da am Ende eine TI-Prüfsumme zu finden ist, weil dann die "echte" Dateilänge um 8 zu verringern ist und wenn man ohnehin schon das Image durchsuchen muß, kann man auf zusätzliche Tests (mit dd könnte man das ja auch feststellen) verzichten - also praktisch die Änderung auch gleich noch als "Scanner" verwenden (wenn man die Angaben zum Superblock und zum NMI-Vector-Block auswertet), sofern man auf die Benutzung von sfk verzichten will (oder muß).

Man kann das geänderte Programm auch auf ein SquashFS-Image loslassen, welches man bereits vom Kernel getrennt hat ... wo also der Superblock bereits an Offset 0 liegt. Will man auch dort den Code für das Suchen nach dem NMI-Vector-Block und/oder der Prüfsumme verwenden, muß man trotzdem noch die Option -scan (oder die Kurzform -k) angeben, damit der zusätzliche Code überhaupt aktiviert wird.

Neben dem reinen Scannen nach den Angaben kann das geänderte Programm natürlich auch weiterhin zum Entpacken eines SquashFS-Images verwendet werden (macht vermutlich auch mehr Sinn):
Rich (BBCode):
$ unsquashfs4-avm -k 84.06.51_kernel.image
Found superblock at 0x00153300 while scanning 84.06.51_kernel.image.
NMI vector gap found at 0x00BE0000, size=256
There's a TI CRC checksum at the end of the image.
Reading a different endian SQUASHFS filesystem on 84.06.51_kernel.image
Filesystem on 84.06.51_kernel.image is lzma compressed (3:76)
Parallel unsquashfs: Using 2 processors
5945 inodes (6328 blocks) to write

[===========================================================\] 6328/6328 100%

created 5195 files
created 375 directories
created 663 symlinks
created 87 devices
created 0 fifos
dabei wird dann der Block mit dem NMI-Vector beim Lesen automatisch übergangen und man erspart sich auch hier das Umkopieren in eine Zwischendatei ohne NMI-Vector-Block. Das ist zwar nicht so flexibel wie ein Shell-Skript (wie in Freetz), aber es geht wesentlich schneller und (gerade auf der Box selbst oder auf kleineren Systemen mit wenigen Resourcen ist das nicht ganz unwichtig) es verringert den Speicherbedarf im RAM und/oder Schreiboperationen in irgendeinen Flash (und sei es ein USB-Stick) als Zwischenspeicher.

Sollte jemand ein Firmware-Image von AVM finden, das sich damit nicht auspacken läßt, kann er mir gerne einen entsprechenden Hinweis hier hinterlassen ... bisher fehlen mir absolute "Ausreißer" bei den von mir getesteten Versionen (7490 06.30 + 06.50, 7270v3 06.06, 7390 06.30 + 06.51, 7360 06.50 (hat keinen NMI-Vector-Block)).
 
Zuletzt bearbeitet:
Hallo Peter,

meine Antwort bezieht sich ausschließlich auf die in Freetz unterstützten Fritz! Boxen, wie es mit Powerline-, Repeatern, sonstiger Gerätschaft aussieht, weiß ich nicht.

Das menuconfig-Symbol ist meines Wissens vollständig.

7390,7340 haben beide v1-"Junk"-Block (seit der Firmware-Version seit der es diesen gibt). 4020 seit Firmware-Version 6.5x hat v3 (wobei die Unterscheidung zwischen v3 und v2 eventuell überflüssig bzw. etwas künstlich ist). Alle anderen Boxen und Furmware-Versionen (inkl. 4020 vor 06.5x) haben v2.

Der inzwischen in remove-junk-bytes umgesetze Algorithmus könnte verkürzt wie folgt formuliert werden.

1. Finde die Zeichenfolge "NMI Boot", diese darf maximal genau einmal vorkommen.
2. Kommt diese vor, so beginnt der zu entfernende bzw. der zu ignorierende Block 0x48 Bytes davor. Die Länge des (zu ignorierenden) Blocks ist dabei in den 4 Bytes unmittelbar vor der "NMI Boot"-Folge kodiert (aus dem Kopf - da auf dem Buildsystem keine Umwandlung notwendig ist, müsste diese immer little-endian kodiert sein).
3. Jeglicher Abgleich auf bekannte Startreihenfolgen (aus denen dann v1 bis v3 abgeleitet wird), ist pure Kosmetik im Sinne "doppelt hält besser".

Der von Dir beschriebene Algorithmus scheint inhaltlich identisch zu sein und sollte somit (bezogen auf die Fritz! Boxen) allgemein gültig sein.

VG,Gene
 
@Gene:
Danke für die Zusammenfassung ... ich hatte dann beim eigenen Review noch einen Fehler bei der Berechnung der Länge der zweiten Lese-Operation gefunden, wenn um den NMI-Vector "herumgelesen" werden muß/soll. Der dürfte jetzt auch erledigt sein und damit ist das Thema für mich erst einmal durch, bis jemand einen Fehler in meiner Implementierung findet (oder die Firmware, an der das Entpacken dann scheitert).

Solltest Du den Patch übernehmen wollen in den Trunk, beachte bitte den nachfolgenden Commit auch noch, der korrigiert erst beim Lesen aus der Datei das Schreiben in den Puffer außerhalb der Grenzen und auch der davor würde noch dazugehören, denn darauf baut der Patch zur Behandlung des "NMI vector gaps" erst auf - insgesamt also drei Commits und vermutlich wäre ein Diff der fertigen Datei gegen den Trunk ohnehin einfacher.

Selbst wenn ich mich noch zu den (alternativ angedachten, s. E-Mail) kleinen Zusätzen zur BusyBox hinreißen lassen sollte, schadet es vermutlich nicht, wenn dann der Code zum Entpacken auch direkt mit den "hidden root"-Images umgehen kann - man muß es ja nicht nutzen und von der Größe des Binaries her trägt es nicht wirklich auf.

Die Version für SquashFS3 werde ich aber wohl eher nicht mehr ergänzen um diese Möglichkeiten ... außer es ist jemand der Ansicht, das wäre notwendig bzw. sinnvoll (und es gibt eine akzeptable Begründung für diese Ansicht) - im Großen und Ganzen ist das ohnehin dasselbe wie bei der Version 4, nur die Datentypen unterscheiden sich und damit ist das etwas Schreibarbeit.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.