Das Flattened uImage Tree-Format (FIT) ist dann auch das Problem - das entstammt dem
U-Boot-Projekt (
https://github.com/u-boot/u-boot/tree/master/doc/uImage.FIT) und AVM hat da wohl auch wieder dran herumgebastelt für die eigene Firmware (zumindest wird das behauptet, ich habe es nie selbst geprüft). Beim U-Boot gibt es aber üblicherweise keine Notwendigkeit, eine einmal zusammengestellte
itb-Datei (das ist die binäre Form des Images) wieder in ihre Bestandteile zu zerlegen (man hat üblicherweise die Dateien noch, aus denen man es mittels
mkimage erzeugt hat) und auch wenn das letztlich dasselbe Format verwendet, wie die Flattened Device Trees (FDTs) und deshalb auch beim Erstellen auf das DTC-Projekt (Device Tree Compiler) zurückgreift, kann das dort vorhandene Programm
fdtdump meines Wissens auch die Binär-Streams nicht aus einem fertigen Image extrahieren - selbst ohne AVM-Änderungen am Format würden also die Tools zum Zerlegen fehlen.
Das einzige Programm, was ich bisher gesehen habe zum Zerlegen und Zusammenfügen von Images in diesem Format, wäre das hier:
https://www.ip-phone-forum.de/threads/software-fitimg-avm-fit-image-manipulator.308941/ und das ist Perl. Üblicherweise reicht diese Feststellung bereits aus um zu erkennen, daß spätestens da dann Schluß ist mit dem "all-in-one"-Skript (wo alles jenseits von einfachen POSIX-Kommandos dann von einer definierten Stelle geladen und "automatisch eingerichtet" und "aufgerufen" wird und genauso spurlos wieder zu entsorgen ist), denn entweder man definiert Perl dann gleich als Voraussetzung und delegiert das alles damit an den Ausführenden (wobei man das denjenigen, die es nicht brauchen, weil ihre Boxen kein FIT-Format benutzen, besser erspart) oder man holt sich jede Menge zusätzlichen Ärger an Bord, denn üblicherweise ist es mit der Installation des "puren" Perl-Interpreters auch noch nicht getan und man muß erst noch (wenn man's skripten will, am ehesten mit
cpan) zusätzliche Perl-Module/-Pakete nachinstallieren, auch wenn ich noch gar nicht nachgesehen habe, was das o.a. Perl-Skript am Ende bräuchte.
Denn dann ist das üblicherweise (es sei denn, man macht eine "side by side"-Installation für das benötigte Perl) auch nicht einfach wieder dadurch entsorgt, daß man das verwendete Verzeichnis einfach nur löscht - wenn's ganz, ganz schlecht läuft, aktualisiert man (versehentlich) irgendwelche Module systemweit und am Ende funktionieren "angestammte" Perl-basierte Lösungen nicht mehr wie erwartet. Das ist mir tatsächlich zu kompliziert - wenn ich da jemals in die Verlegenheit kommen sollte, daß ich dieses Format auch unterstützen will, kommt da etwas in C oder in Shell hin - aber nichts in Perl, PHP oder Python oder einer ähnlichen "Hochsprache".
Nicht deshalb, weil ich die generell ablehne oder damit nicht umgehen könnte - aber ich habe eben immer eher "embedded systems" als Plattform für meine Software im Auge und da gibt es diese Optionen in aller Regel nicht. Solange man das dann nicht wegen der Portierbarkeit ausschließlich mit Shell-Syntax und POSIX-Kommandos lösen kann (dann muß man auch nicht über mehrfache Bereitstellung passender Binaries nachdenken), kann man auch gleich zu C als Sprache greifen, das ist praktisch überall auch bereits in Verwendung (in Form einer C-Library, die üblicherweise von dynamisch gelinkten Programmen genutzt wird) und das selbst auf "embedded devices". Da muß man jetzt nicht noch auf Teufel komm raus eine Hochsprache auf so ein Gerät bringen - soweit ich mich erinnere, gibt es selbst in den Freetz-Forks schon lange kein aktuelles(!) Perl mehr (
https://www.perl.org/get.html).
Ansonsten kann/muß sich jeder selbst die passenden Skript-Files zusammenbauen - man muß dann halt vor dem
unsquashfs das FIT-Image erst noch in seine Bestandteile zerlegen (lassen) und am Ende das neu gepackte SquashFS-Image dann in der originalen Datei ersetzen (denn die enthält noch deutlich mehr als nur einen Kernel und ein Dateisystem). Wo man die Perl-Installation dann her bekommt und daß man das Perl-Skript (das ist noch einmal als TAR-File mit
gzip gepackt - aber außer dem Perl-File ist nur noch eine
readme.txt und der GPLv2-Text mit im Archiv) dann laden und entpacken muß, ist nichts, was ich meinerseits irgendwie hilfreich beschreiben oder gar automatisieren wollte. Wem das zu kompliziert ist, der kann ja auch wieder auf den "no-freetz"-Modus in Freetz-NG ausweichen (ich hoffe mal, den gibt es noch) - dort wird m.W. auch das o.a. Skript genutzt, wenn es um das FIT-Format geht.
Nur ist das dann eben auch wieder eine "komplette" Freetz-(NG-)Installation ... dafür ist dort dann sogar Perl bereits installiert, denn das ist iirc auch an anderen Stellen in Freetz(-NG) eine Voraussetzung zum Arbeiten. Die hier mittlerweile geskripteten, einfachen Schritte hatte ich ja ursprünglich nur mal gezeigt, um dem ständigen "Das ist aber kompliziert und braucht fürchterlich lange." entgegen zu treten - eigentlich wollte ich nur zeigen, daß die von mir immer wieder behauptete Modifikation "im Handumdrehen" kein Hirngespinst war, sondern mit entsprechender Vorbereitung (in erster Linie mit dem "Draufschaffen" des notwendigen Wissens, was hier mehrfach geteilt wurde - die "Zutaten" stehen ja ohnehin bereit seit längerer Zeit) auch tatsächlich in kürzester Zeit erledigt werden kann - wenn die Ansprüche an die auszuführenden Modifikationen zum vorhandenen Angebot passen.
Ich habe gerade doch mal noch kurz einen Blick in das Skript geworfen und - je nachdem, was die eigene Perl-Installation direkt nach dem Ende schon bereitgestellt hat - es könnte tatsächlich erforderlich sein, noch Module zusätzlich zu installieren:
Perl:
use String::CRC32; # May need 'cpan install String::CRC32'
- so steht es zumindest im Skript.
Aber bis auf die zwei zusätzlichen Schritte mit dem Extrahieren des SquashFS-Images aus dem FIT-Image und das Ersetzen des SquashFS-Images am Ende vor dem Einpacken mit
tar, ist das genau dasselbe, wie bei den anderen Modellen auch - zumindest würde ich das annehmen. Probiert habe ich es selbst noch nicht - ich könnte es ohnehin am Ende nicht auf Lauffähigkeit testen.
Denn ich habe auch keine aktuelle Sammlung von FRITZ!Box-Modellen mehr, an der ich jeweils diese Aussagen selbst überprüfen könnte - mein Interesse an diesen Boxen als "Spielzeug" hat doch einigermaßen nachgelassen (und die AVM-Produktpalette wird auch immer breiter). Eigentlich hatte ich mir die Teile auch von Beginn an nur unter Security-Aspekten angesehen - mein erster Anstoß, mich überhaupt mit den Geräten und ihrer Firmware eingehender zu befassen, war eine Factory-Reset-Aktion meines damaligen Providers (KDG) auf einer 6360, die am Ende dazu führte, daß nicht mehr die zuvor von mir konfigurierten VPN-Verbindungen zu meinen Servern als "Standardgateway" genutzt wurden, sondern alles schön im Klartext beim Provider abgeliefert wurde (und ich stinksauer war), weil der nach dem Reset natürlich auch noch die Box wieder neu konfiguriert hatte - nur eben ohne meine VPN-Verbindungen.
Mittlerweile hat die AVM-Firmware aber ein Schutzniveau erreicht, mit dem man einigermaßen zufrieden sein kann und das in den allermeisten Punkten auch den BSI-Forderungen entspricht. Das macht diese Firmware auch deutlich unattraktiver für die Suche nach weiteren Problemen (außer die springen einen dann tatsächlich mal wieder an, was aber nur selten der Fall ist) und damit geraten die Teile bei mir zunehmend aus dem Fokus.
