[Sammlung] Wie modifiziere ich die originale Firmware vom Hersteller und wie installiere ich meine eigene dann auf der FRITZ!Box?

[NDiIPP]

Alles was du geändert haben willst in dem Envoriment schreibst du als export.

Nein, so geht das nicht.

Kann mir gut vorstellen das ein export firmware_version=avm das selbe bewirkt wie ein export oem=avm

Nein, das ist eben nicht der Fall.

 

[eisbaerin]

Alles was du geändert haben willst

Aber welche sind es genau bei dir?

 

[Insti]

Das was ich schon #184 geschrieben habe https://www.ip-phone-forum.de/threads/sammelthema-zur-avm-fritz-box-7520.302364/page-10#post-2372095

 

[NDiIPP]

Und die beiden geänderten Zeilen aus Beitrag #175 (wovon aber auch nur eine relevant ist).

Bis jetzt also nur eine Änderung die Wirkung zeigen sollte.

 

[Insti]

D.h Easy Support ist unabhängig von einem CWMP Account?

 

[NDiIPP]

Ja.

 

[Insti]

Und woher soll die tr069_serial kommen? Oder wird das auch nicht gebraucht?

 

[NDiIPP]

Wird auch nicht gebraucht. Zumindest nicht aus der Variable "tr069_serial".

Wie Peter schon in #223 schon geschrieben hatte, bei anderen Providern funktioniert TR069 auch ohne diese beiden Variablen, auch bei 1und1 (weshalb diese auch keine Werte für diese beiden Variablen erhalten).

 

[eisbaerin]

IMO wird das dazu genommen:

ConnectionRequestUsername = "acs.t-online.de";
ConnectionRequestPassword = "0f5bc0a4bb5a85990872214f29e15bb1";

@PeterPawn: Könntest du bitte zu EasySupport auch ein eigenes Thema auf machen.
Am besten mit deinem Beitrag #223.
Ich hätte auch noch ein paar Fragen, die aber die 7520 nicht betreffen.
Und ehe wir wieder mit verschieben anfangen ...

Falls du nicht willst, dann gib bitte bescheid, dann mache ich eines auf, ich wollte dir aber den Vortritt lassen.

 

[PeterPawn]

Da dort auch "Meinung" meinerseits (zum Zustand der TR-069-Implementierung von AVM) enthalten ist und das (m.E.) in einer "objektiven Beschreibung" nur "am Rande" relevant wäre, taugt der Beitrag in meinen Augen auch nicht für das Eröffnen eines "Info"-Threads.

Da gehört dann - wenn es um EasySupport geht - die Beschreibung der "Besonderheiten" ggü. anderen TR-069-Verwendern hinein, angefangen beim Client-Zertifikat (aber sicherlich auch nicht unbedingt das Kennwort für den dort enthaltenen privaten Schlüssel) bis hin zur Beschränkung auf die drei Modelle über die Provider-Profile.

Wobei auch diese Beschränkung wohl eher "willkürlich" ist bzw. vermutlich auch einer "Zertifizierung" der jeweiligen FRITZ!Boxen durch die Telekom beruhen wird - was bei der nächsten Firmware-Version schon wieder wenig Sinn ergeben dürfte/würde. Die angebotenen Funktionen der TR-069-Implementierung sollten sich jedenfalls bei den anderen Modellen auch nicht sehr von denen bei der 7490/7530/7590 unterscheiden.

Ich würde daher sogar tippen, daß auch andere Boxen (wenn man die "tr069.cfg" passend präpariert - wie das aussehen sollte, findet man ja im betreffenden Telekom-Profil) am EasySupport der Telekom teilnehmen könnten ... vermutlich sogar die 7520 mit der originalen Firmware, wenn man ihr eine passende "tr069.cfg" verpaßt und ein Profil auswählt/festlegt, das nicht seinerseits diese Datei wieder überschreibt.

Ich würde #223 jedenfalls auch nur ungern abgetrennt und als "Eröffnungsrede" in einem neuen Thread sehen - ich weiß nicht mal sicher, ob sich EasySupport tatsächlich als separates "Thema" eignet und TR-069 generell, was es tatsächlich kann (diesmal anhand von Aufrufen der angebotenen Funktionen und nicht anhand von Analysen von AVM-Dateien) und was eigentlich bei der Kommunikation mit dem AVM-ACS passiert, ruht bei mir immer noch in der Schublade im Ordner "Geplante Projekte".

 

[eisbaerin]

@PeterPawn
Kann man eigentlich bei diesen FB7530 noch dein Skript install_inactive_rootfs nutzen?
Geht das auch für die GRX Boxen?
Und wie sieht es bei der 7490 mit neusten FW aus?
Da wurde doch IMHO auch etwas am Dateisystem verändert.

 

[PeterPawn]

Das funktioniert so nur bei den VR9-Boxen mit dem YAFFS2-Wrapper. Da allerdings auch bei den aktuellen Labor-Versionen, weil der Unterschied am Ende nur darin besteht, daß das Dateisystem, in dem dieser gesamte Inhalt des YAFFS2 bei AVM gespeichert ist, nun wieder direkt ein SquashFS-Image ist.

Dessen Inhalt muß ohnehin irgendwie extrahiert/gemountet werden und erst die darin enthaltene "filesystem_core.squashfs" ist die Datei, welche von "install_inactive_rootfs" installiert wird und zwar in die inaktive Partition, aber eben auch nur das SquashFS-Image mit dem Root-Dateisystem und nicht der Teil rundherum.

Ich hatte das eigentlich mal genutzt, um geänderte SquashFS-Images auch ohne neuen Inhalt der YAFFS2-Partition (bzw. ohne deren alten Inhalt zu löschen) zu installieren, weil manches bei den VR9-Boxen (u.a. das "Implantieren" zusätzlicher Dienste mit den Beispielen aus "toolbox") durch Dateien in dieser YAFFS2-Partition erfolgt und es nervig war, die auch immer wieder neu zu installieren.

Auch die eine Option beim "modfs", die ein Root-Dateisystem direkt installieren kann, arbeitet so - und da auch dort das inaktive Dateisystem verwendet wird, ist dieser Weg von "modfs" am Ende (iirc) praktisch identisch mit dem "install_inactive_rootfs".

Das, was "modfs" da bei richtiger Parametrierung (inkl. "Ausgabedatei" anstelle der direkten Installation auf der Box) erzeugt, ist auch nur dieses eine SquashFS-Image und nicht der gesamte Inhalt der YAFFS2-Partition wie in einer "filesystem.image" von AVM (egal ob mit "ext2" oder als SquashFS4-Image).

Für die Boxen mit dem UBI-Layer (die IPQ-Modelle hier und die GRX-Boxen) kann man das neue SquashFS-Image direkt mit dem AVM-Kommando "update_kernel" in die passende Partition schreiben - so, wie man es auch mit einem Kernel-Image (da halt nur nicht in eine UBI-, sondern direkt in eine Flash-Partition) machen würde.

Ob das AVM-Kommando jetzt automatisch vorher den alten Inhalt löscht oder nicht, weiß ich aus dem Kopf auch nicht 100% sicher ... aber man kann es auch erst mal mit dem direkten Schreiben versuchen und wenn dann der Inhalt (in Kombination des bisherigen Inhalts und des neu zu schreibenden Images) nicht mit dem "geplanten" Image übereinstimmt, braucht's wohl doch noch den expliziten Aufruf zum Löschen (wo man einfach auf die Spezifikation der Eingabedatei verzichtet, damit das Programm nur löscht).

 

[eisbaerin]

direkt mit dem AVM-Kommando "update_kernel" in die passende Partition schreiben

Könntest du das bitte noch näher erklären und ein Beispiel machen.

update_kernel [options]
        -i       input
        -o       output
         ohne input wird output geloescht

Der Input ist klar, hoffentlich: z.B. /var/7530/new.image aus #149 richtig?
Geht auch jede andere in-memory Datei?

Aber was nehme ich als output?

Das update_kernel gibt es auch bei der 7490-07.12.
Kann man es da genau so nutzen? Mit einer in-memory Datei?
Wahrscheinlich aber nicht die Datei, welche ich mit install_inactive_rootfs nutze.

 

[PeterPawn]

Nein, die Datei zum Start aus dem RAM besteht ja immer aus einem Kernel, an dem dann das Dateisystem direkt klebt - damit paßt das "new.image" aus #149 auch nicht. Wenn man das machen wollte, müßte man die beiden Dateien, aus denen das "new.image" dort zusammengestellt wird ("kernel.bin" und "fs.sqfs"), verwenden.

In die Partitionen kommt (außer bei den Boxen, die das System im NOR- oder SPI-Flash haben und auch keine zwei alternativen Partition-Sets nutzen) jeweils nur eines - entweder der Kernel oder das Dateisystem. Welche Partition wofür ist, verrät der Blick in "/proc/mtd" - die Partitionen mit dem "reserved" im Namen, sind für das inaktive System.

Das "update_kernel" wird auch von "modfs" verwendet: https://github.com/PeterPawn/modfs/blob/master/modfs#L603 - wobei ich da jeweils explizit den Aufruf ohne Eingabedatei zum Löschen verwende (wie gesagt, ich bin nicht sicher, ob das notwendig ist oder ob das ggf. sogar zwei Löschzyklen auslöst).

Die "Ausgabedatei" ist halt das jeweilige MTD (hier noch ein "device" ranzuhängen, wäre falsch, weil das bereits ein "memory technology device" ist) für die Zielpartition ... und zwar die Variante für "character oriented I/O" (also ohne das "block" im Namen) - ich vermute mal, daß die "block device"-Emulation auch nicht funktionieren würde (weil die die notwendigen IOCTL-Kommandos nicht kennt).

Jedenfalls flasht man bei einer Box mit NAND-Speicher (egal ob mit YAFFS2 oder vom UBI-Layer verwaltet) definitiv kein "in-memory"-Image ... das geht ggf. bei einer Box mit NOR- oder SPI-Flash noch gut, weil da das Format identisch ist, mit Ausnahme der TI-Prüfsumme am Ende, die man beim Laden ins RAM abschneiden muß/sollte, damit das Alignment (die Ausrichtung) des Images im Speicher stimmt (oder man muß auf die nächste 256 Byte-Grenze auffüllen). Bei den anderen Modellen schreibt man schön den Kernel und das Dateisystem einzeln in die passenden Partitionen - bei Puma-Boxen dann sogar für beide Systeme.

 

[eisbaerin]

Also ich mache erst:

7520:/var/mod/root# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00020000 "reserved-kernel"
mtd1: 002c0000 00020000 "urlader"
mtd2: 00840000 00020000 "nand-tffs"
mtd3: 00400000 00020000 "kernel"
mtd4: 06d00000 00020000 "ubi"
mtd5: 02c14000 0001f000 "reserved-filesystem"
mtd6: 02c14000 0001f000 "filesystem"
mtd7: 0020f000 0001f000 "config"
mtd8: 00c79000 0001f000 "nand-filesystem"

suche mir die 2 "reserved" raus: mtd0 und mtd5
dann mache ich

update_kernel -o /dev/mtd0
update_kernel -i /var/7530/kernel.bin  -o /dev/mtd0
update_kernel -o /dev/mtd5
update_kernel -i /var/7530/fs.sqfs  -o /dev/mtd5

Richtig?

Und wenn ich aus versehen mtd1 nehme ist die FB tot?

Sehr gefährlich.

Und dafür gibt es noch kein Skript, welches das sicher macht?

Ich glaube da bleibe ich lieber bei den EVA-Tools.
Mich stört dabei nur, daß ich jedes mal erst einen Switch suchen und dazwischen bauen muß, um in das Bootmenu zu kommen
Deshalb hoffte ich, daß es eine einfache Variante über das CLI gibt.
Dem ist aber wahrscheinlich nicht so. Oder?

 

[Insti]

Bin Heute Morgen nicht ganz fertig geworden weil ich zur Arbeit musste, aber wollte es so probieren:

cat /dev/mtdblck5 > /var/media/ftp/USBSTICK/fs.sqfs

Das fs.sqfs File auf meinem Ubuntu gezogen und ausgepackt:

YourFritz/bin/squashfs/x86_64/unsquashfs4-le -no-progress fs.sqfs

im squashfs-root Ordner die Dateien bearbeiten die geändert werden sollen und das ganze wieder verpacken

YourFritz/bin/squashfs/x86_64/mksquashfs4-le squashfs-root/ geändert.sqfs -all-root -no-progress

Bis hierher bin ich gekommen und später soll es weiter gehen mit File auf das NAS der FB und auf das mtd5 schreiben.

cat /var/media/ftp/USBSTICK/geändert.sqfs > /dev/mtdblck5

Über den BM das inaktive System auswählen und neu booten.
Damit ist die Frage in #201 zur vollsten Zufriedenheit beantwortet dank @PeterPawn!
(Hoffe ich bekomme keinen zweiten Briefbeschwerer)
Solange es nichts neueres als die 7.14 für die 7520/7530 gibt, braucht der Kernel ja nicht geändert werden oder?

Und wenn ich aus versehen mtd1 nehme ist die FB tot?

Ja!
Hier findest du das Startlog dazu

VG Insti

 

[eisbaerin]

Also ich mache erst:

7520:/var/mod/root# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00020000 "reserved-kernel"
mtd1: 002c0000 00020000 "urlader"
mtd2: 00840000 00020000 "nand-tffs"
mtd3: 00400000 00020000 "kernel"
mtd4: 06d00000 00020000 "ubi"
mtd5: 02c14000 0001f000 "reserved-filesystem"
mtd6: 02c14000 0001f000 "filesystem"
mtd7: 0020f000 0001f000 "config"
mtd8: 00c79000 0001f000 "nand-filesystem"

suche mir die 2 "reserved" raus: mtd0 und mtd5
dann mache ich

update_kernel -o /dev/mtd0
update_kernel -i /var/7530/kernel.bin  -o /dev/mtd0
update_kernel -o /dev/mtd5
update_kernel -i /var/7530/fs.sqfs  -o /dev/mtd5

Richtig?

Und wenn ich aus versehen mtd1 nehme ist die FB tot?

Sehr gefährlich.

Und dafür gibt es noch kein Skript, welches das sicher macht?

Ich glaube da bleibe ich lieber bei den EVA-Tools.
Mich stört dabei nur, daß ich jedes mal erst einen Switch suchen und dazwischen bauen muß, um in das Bootmenu zu kommen
Deshalb hoffte ich, daß es eine einfache Variante über das CLI gibt.
Dem ist aber wahrscheinlich nicht so. Oder?

 

[PeterPawn]

@Insti:
Ich würde nicht mittels cat in eines der Block-Devices für die MTD-Partitionen installieren, sondern - wie oben schon gezeigt - mit update_kernel.

Das ist ein eher simples Binary von AVM, was - wie ich gerade noch einmal getestet habe:

/var/media/ftp/YourFritz # cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00020000 "kernel"
mtd1: 03000000 00020000 "filesystem"
mtd2: 00400000 00020000 "reserved-kernel"
mtd3: 03000000 00020000 "reserved-filesystem"
mtd4: 00200000 00020000 "config"
mtd5: 19600000 00020000 "nand-filesystem"
mtd6: 00040000 00001000 "urlader"
mtd7: 00060000 00001000 "tffs (1)"
mtd8: 00060000 00001000 "tffs (2)"
/var/media/ftp/YourFritz # cat /dev/mtd0 >kernel.mtd0
/var/media/ftp/YourFritz # cat /dev/mtd2 >reserved-kernel.mtd2
/var/media/ftp/YourFritz # cmp kernel.mtd0 reserved-kernel.mtd2
kernel.mtd0 reserved-kernel.mtd2 differ: char 5, line 1
/var/media/ftp/YourFritz # update_kernel -i kernel.mtd0 -o /dev/mtd2
info 0x0
{mtd_info} type 0x4
{mtd_info} size 0x400000
{mtd_info} erasesize 0x20000
{mtd_info} writesize 0x800
{mtd_info} oobsize 0x40
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] written 0x20000 Bytes
[main] exit error 0
/var/media/ftp/YourFritz # cmp -l /dev/mtd2 kernel.mtd0
/var/media/ftp/YourFritz #

- vor dem Schreiben den Flash-Speicher über den passenden ioctl()-Aufruf löscht (ein gesondertes Löschen ist also nicht notwendig, wie der letzte cmp-Befehl oben zeigt). Schaut man sich das Programm genauer an, beschränken sich auch die importierten Funktionen aus der C-Library auf Speicherverwaltung (malloc, free), Consolen-Nachrichten (perror, printf) und eben wenige I/O-Funktionen (open, close, read, write, ioctl). Wenn's das also nicht schon gäbe, müßte man es erfinden ... oder durch passende "Standardprogramme" (manche sind auch als BusyBox-Applets verfügbar) ersetzen.

Vor dieser Aufgabe steht man dann, wenn man aus einem eigenen Image (das man seinerseits publizieren will) heraus eine Partition vor dem Schreiben löschen will - der Einsatz von update_kernel verbietet sich da ja, da es sich um ein Programm von AVM handelt, welches man - nach dem Herauslösen aus der Firmware als Ganzem - nicht verbreiten darf nach der AVM-Lizenz. Also muß man sich anders behelfen, z.B. so:

/var/media/ftp/YourFritz # flash_eraseall /dev/mtd2
Erasing 128 Kibyte @ 400000 - 100% complete.
/var/media/ftp/YourFritz # tr '\0' '\377' < /dev/zero | cmp /dev/mtd2 -
cmp: EOF on /dev/mtd2
/var/media/ftp/YourFritz # cat reserved-kernel.mtd2 >/dev/mtd2
/var/media/ftp/YourFritz # cmp -l /dev/mtd2 reserved-kernel.mtd2
/var/media/ftp/YourFritz #

Wie man am cmp wieder sehen kann, enthält die Partition nach dem Löschen nur noch binäre Einsen - das flash_eraseall (hier das aus der BusyBox) hat also genau das gemacht, was man von ihm erwartet. Anschließend kann man dann den Flash (über das mtdchar-Device) auch wieder einfach mittels cat beschreiben - der Vergleich danach zeigt, daß das Schreiben erfolgreich war. Für Geräte mit UBI-Layer sollte das ebenso funktionieren (der UBI-Layer stellt für die von ihm verwalteten Partitionen ja dann wieder die mtdchar-Interfaces bereit) - ich kann/will das nur gerade nicht auf der 7580 testen und illustrieren.

Bei manchen Modellen gibt es - dank einer Änderung von AVM an den Kernel-Quellen - auch noch die Möglichkeit, eine MTD-Partition über einen Schreibzugriff (mit der passenden Zeichenkette) nach /proc/mtd zu löschen (der Vanilla-Kernel kennt gar keinen Schreibzugriff auf /proc/mtd). Welche Optionen es dort gibt bzw. was implementiert wurde an "Kommandos", kann man sich in der Datei drivers/mtd/mtdcore.c in den passenden Kernel-Quellen ansehen. Aber wie geschrieben ... das gilt nicht für alle Modelle. Bei den Boxen mit UBI-Layer hat AVM das (m.W., wobei ich nicht wirklich immer für alle Modelle "kontrolliere") nicht weiter verfolgt - da gibt es für solche Zwecke ja dann auch die ubi-utils (als Bestandteil des mtd-util-Projekts: http://git.infradead.org/mtd-utils.git) und nicht zuletzt hatte man mittlerweile ja auch das eigene update_kernel.

Warum es keine gute Idee ist, über mtdblock zu flashen, kann man nebenbei bemerkt hier: https://bootlin.com/blog/managing-flash-storage-with-linux/ (Kapitel "Manipulating MTD devices" - hier hätten wir wieder den Pleonasmus bzw. das redundante Akronym mit dem doppelten "device") ganz gut nachlesen.

@eisbaerin:
Ja, der potentiell mögliche Schreibzugriff auf die urlader-Partition ist ein Problem bzw. kann zu einem werden. Ich meine, ich hätte irgendwann mal bei AVM in den Kernel-Quellen Ansätze gesehen, den Schreibzugriff aus dem laufenden System auf diese Partition zu begrenzen (direkt im Hardware-Treiber für den Flash-Chip) - ob das heute noch so ist, müßte man prüfen. Aber ich habe auch schon bei Boxen den Konfigurationsbereich im Bootloader geändert (Dumpen, mit Hex-Editor oder passenden Kommandos ändern, neu schreiben, zuvor löschen - wie oben gezeigt) - es hat also auch seine Vorteile. Da im update_kernel von AVM auch nichts zu sehen ist von einem Test, ob das angegebene Device nicht doch der urlader ist, könnte man damit diesen wohl auch überschreiben - mit dem AVM-Programm habe ich das aber noch nicht gemacht, sondern wenn ich das tat, dann immer "von Hand".

Und wenn ich aus versehen mtd1 nehme ist die FB tot?

Ja, wenn man es nicht doch noch merkt und vor dem Neustart einfach seine Kopie des Bootloaders (die man natürlich für jede eigene Box "in der Schublade" hat) wieder in die Partition schreibt.

Ansonsten kann man natürlich problemlos auch einen passenden "wrapper" um die Kommandos schreiben (der auch noch einmal prüft, daß es nicht doch die urlader-Partition ist bzw. der das passend aus /proc/mtd ausliest) ... wie das u.a. geht, findet man in den entsprechenden Skript-Dateien von AVM, die ja auch immer Bestandteil der AVM-Firmware sind bei den Boxen, wo sich die Firmware beim Start aus dem RAM selbst in den Flash-Speicher befördert. Da wird ja auch jeweils die "aktive" Partition ermittelt (im Gegensatz zum Vorgehen in den /var/install-Dateien aus den Firmware-Image-Dateien, die nach den reserved-Paritionen suchen) und dann in diese geschrieben. (BTW ... das mit dem Lesen aus dem procfs macht "modfs" genauso und auch der BM ermittelt das natürlich auf diesem Weg.)

Abgesehen davon, muß man häufig ja auch nur die Dateisystem-Partition neu schreiben lassen nach einer Modifikation - wenn's nicht gleichzeitig noch ein Update auf eine andere FRITZ!OS-Version ist (ist es kein solches Update, kann der Kernel ja unangetastet bleiben).

Daß es (bei vorhandenem Shell-Zugang) natürlich nervig ist, wenn man für EVA immer erst mal alles neu verkabeln muß, versteht sich von selbst ... ich persönlich habe halt auch meine Test-Boxen (alles, was DSL kann/macht, ist bei mir nicht mehr wirklich im Einsatz und dient nur noch der Entwicklung bzw. dem Test von AVM-Firmware) "in Reichweite" und ohnehin mit einem Kabel angeschlossen (schon damit ich das WLAN deaktivieren kann - sonst wird die Liste der Netze auch ohne die von den Nachbarn sehr schnell sehr lang). Trotzdem installiere ich natürlich - wenn's paßt - auch immer durch direktes Schreiben in den Flash aus der Shell heraus - schon weil man dort nach dem Schreibvorgang noch einmal vergleichen kann.

 

[PeterPawn]

Ich mache mal weiter im Thema ... den aufgebrachten Vorschlag/die Frage, ob es die Möglichkeit bzw. keine Automatisierung für die Installation über die Shell gibt, kann man auf zwei Wegen angehen/beantworten.

Einmal auf dem von Freetz, wobei sich das eben auch immer auf die /var/install von AVM stützt und dazu diese Datei aus einem originalen Firmware-Image (was nur per tar gepackt wurde und damit nach meiner Ansicht "mit Standard-Tools" zu zerlegen wäre - mithin auch nicht mehr unbedingt als "distribution as a whole" gelten würde) in das eigene, finale Image kopiert.

Auch hier wird es sicherlich keine Urheberrechtskonflikte geben, solange man das jeweils selbst macht (und dann muß man es erst recht nicht an die große Glocke hängen) - aber will man selbst Images zusammenstellen, die irgendwelche Veränderungen an der Box vornehmen (und keine originale AVM-Komponente enthalten, die nicht auch unter GPL-Bedingungen vertrieben werden darf), muß man ohnehin selbst "in die Tasten hauen" und sich ein Skript bauen, was die notwendigen Kommandos enthält, um den Inhalt solcher Images zu installieren. Das wäre die Alternative zur Nutzung des AVM-Skripts.

Das muß ja nicht mal immer ein Kernel und ein Dateisystem sein, was da in solch einem Image enthalten ist ... mit einem selbstsignierten Image kann man auch (vorausgesetzt, der öffentliche Schlüssel ist in der laufenden Firmware bekannt) solche Dinge wieder ausführen, wie sie in den früheren "Pseudo-Updates" erfolgten - ja, beim passenden Aufruf (wenn man sein Image als Update für Zubehör "tarnt", woraufhin die enthaltene /var/install anders aufgerufen wird) wird nicht mal die Firmware so weit "heruntergefahren", daß man um einen Neustart nur noch schwer herumkommt - mancher erinnert sich vielleicht noch an alte "Pseudo-Updates" zum Start eines Telnet-Daemons, die dann erst den Rest der Firmware wieder zum Laufen bringen mußten, der beim prepare_fwupgrade zuvor gestoppt wurde.

Der Nachteil an der Benutzung des AVM-Skripts ist es außerdem, daß dieses erst mal hingeht und die "Prüfsumme" für die enthaltenen Dateien mit derjenigen, die dort jeweils in den letzten acht Byte enthalten ist (vier Byte als Signatur, vier Byte mit dem Wert), vergleicht - ein etwas "archaisches" Vorgehen bei der Absicherung, daß die zu installierenden Dateien auch in Ordnung sind. Und nebenbei bemerkt auch der Grund, warum man beim Zusammenbau eines "in-memory images" zum Start einer Box aus dem RAM, die letzten acht Byte von Kernel und Dateisystem abschneiden muß, bevor man sie zum finalen Image zusammenfügt.

Aber schon aus der Tatsache, daß diese CRC32-Prüfsummen eben bei der Installation aus dem RAM gar nicht vorhanden sind und die Firmware trotzdem den Inhalt der "Partitionen" aus dem RAM direkt in die jeweiligen Ziele kopiert und da keine weiteren Prüfsummen berechnet und angehangen werden, kann man ja ersehen, daß diese am Ende gar nicht mehr benötigt werden - sie stellen eigentlich nur sicher, daß die jeweilige Datei "bis zum Ende" ausgepackt werden konnte und wenn es dabei tatsächlich Probleme geben sollte, müßte/würde das schon das zum Entpacken verwendete tar-Kommando bemerken und entsprechend an seinen Aufrufer melden.

Aber es ist nun mal, wie es ist ... auch Freetz packt letztlich diese AVM-Datei zur Installation nicht weiter an (sie wird nur 1:1 kopiert, von einer Ausnahme abgesehen, die aber in unserem Kontext keine Rolle spielt) und sorgt daher brav dafür, daß die Eingabedateien auch das erwartete Format haben - es berechnet die CRC32-Prüfsummen und hängt sie an die jeweilige Datei an (mit tichksum: https://github.com/Freetz/freetz/tree/master/tools/make/tichksum-host/src).

Das kann man nun so machen, man muß es aber nicht. Daher findet sich bei mir in den vorkompilierten Programmen für alle Lebenslagen auch dieses Tool nicht - abgesehen davon, daß das eben auch mit "Standard-Tools" problemlos funktioniert:

peh@vidar:~> cd /home/FritzBox/FB7490/firmware/
peh@vidar:/home/FritzBox/FB7490/firmware> mkdir /tmp/demo_cksum
peh@vidar:/home/FritzBox/FB7490/firmware> tar -x -f FRITZ.Box_7490-07.19-79325-LabBETA.image -O ./var/tmp/kernel.image >/tmp/demo_cksum/kernel.bin
peh@vidar:/home/FritzBox/FB7490/firmware> tar -x -f FRITZ.Box_7490-07.19-79325-LabBETA.image -O ./var/tmp/filesystem.image >/tmp/demo_cksum/fs.bin
peh@vidar:/home/FritzBox/FB7490/firmware> cd /tmp/demo_cksum/
peh@vidar:/tmp/demo_cksum> dd if=kernel.bin of=kernel.raw bs=$(( $(stat -c %s kernel.bin) - 8 )) count=1 2>/dev/null
peh@vidar:/tmp/demo_cksum> dd if=fs.bin of=fs.raw bs=$(( $(stat -c %s fs.bin) - 8 )) count=1 2>/dev/null
peh@vidar:/tmp/demo_cksum> ls -l
total 65900
-rw-r--r-- 1 peh users 31047688 Jun 17 20:26 fs.bin
-rw-r--r-- 1 peh users 31047680 Jun 17 20:30 fs.raw
-rw-r--r-- 1 peh users  2687496 Jun 17 20:26 kernel.bin
-rw-r--r-- 1 peh users  2687488 Jun 17 20:30 kernel.raw
peh@vidar:/tmp/demo_cksum> hexdump -C kernel.bin | tail -n 3
*
00290200  23 de 53 c4 96 f7 c9 94                           |#.S.....|
00290208
peh@vidar:/tmp/demo_cksum> hexdump -C fs.bin | tail -n 3
*
01d9c000  23 de 53 c4 14 4d d6 fd                           |#.S..M..|
01d9c008

Die grün markierten Bytes sind die Signatur für diese Art von Prüfsumme nach TI-"Standard" - sie wird immer im "little endian"-Format gespeichert, wo das höchstwertige Byte als letztes im Speicher (oder wo auch immer) steht.

Daher ist das in Wirklichkeit die hexadezimale Konstante 0xC453DE23 (dezimal 3293830691) - an ihr kann man auch automatisch erkennen, ob ein Image nun eine solche Prüfsumme am Ende hat oder nicht. In der image2ram (https://github.com/PeterPawn/YourFritz/blob/master/eva_tools/image2ram) überprüfe ich das z.B., indem ich diese vier Byte (die 8 Byte vor dem Dateiende stehen) mit base64 in eine Zeichenkette umwandeln lasse, die man dann mit dem "erwarteten Wert" I95TxA== für die "Signatur" vergleichen kann.

image2ram ist auch eher Demo als ein komplettes Skript und dient ja genau dazu, die oben gezeigten Operationen für die kernel.image und die filesystem.image zu automatisieren - als da wären das Extrahieren aus dem TAR-File von AVM und das Abschneiden der Prüfsumme, aber nur, wenn sie auch wirklich vorhanden ist, auszuführen, wobei für die Ausgabe dann die "blanken" Dateien einfach hintereinander kopiert werden. Das ist also eigentlich die "Umkehroperation" für das Anbringen der TI-Prüfsummen, wobei nur eine einzelne Datei (eben das "in-memory image") ausgegeben wird.

Die oben rot markierten Byte sind dann die eigentliche Prüfsumme - das ist nichts anderes als das Ergebnis der Berechnung eines bekannten CRC32-Polynoms über den gesamten Inhalt der Datei (natürlich ohne die Signatur), wobei auch hier das Ergebnis wieder im LE-Format gespeichert wird. Das Kommando cksum verwendet genau dieses Polynom ebenfalls (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cksum.html):

peh@vidar:/tmp/demo_cksum> cksum kernel.raw
2496264086 2687488 kernel.raw
peh@vidar:/tmp/demo_cksum> printf "%#x\n" $(cksum kernel.raw | sed -e "s| .*||")
0x94c9f796
peh@vidar:/tmp/demo_cksum> printf "%#x\n" $(cksum fs.raw | sed -e "s| .*||")
0xfdd64d14

Wie man sieht, stimmen die Werte in Rot mit denen aus der oben gezeigten TI-Prüfsumme des "Originals" überein - die Reihenfolge der Bytes ist nur "gedreht" (weil die Anzeige halt das Byte mit der niedrigsten Wertigkeit als letztes darstellt, wie man das von Zahlen nun mal kennt).

Gesetzt den Fall, man will also mit dem eigenen (Dateisystem-)Image das AVM-Skript zur automatischen Installation verwenden, muß man jetzt irgendwie dafür sorgen, daß sowohl der Kernel als auch das Dateisystem (bei den UBI-Boxen ist das ja einfach nur das SquashFS-Image aus dem mksquashfs-Aufruf beim Einpacken) die passende Prüfsumme haben. Beim Kernel wird das (solange es der von AVM ist) meist bereits der Fall sein - man darf nur das dd-Kommando aus #5 dann natürlich nicht verwenden, denn das schneidet ja diese Prüfsumme erst ab.

An das eigene SquashFS-Image muß man sie dann eben irgendwie anhängen ... solange man das Programm aus der Freetz-Toolchain nicht für die verwendete Plattform vorliegen hat, muß man sich anders zu helfen wissen - das eigentliche Problem ist es am Ende, die berechnete Prüfsumme irgendwie in die passende binäre Darstellung zu bringen (eben das LE-Format), die man an die Datei anhängen kann.

Dazu bauen wir uns erst mal eine kleine Funktion, die eine gegebene Zahl in das passende Binärformat bringen kann und testen diese gleich mal mit der Signatur und der oben (grün) gezeigten Prüfsumme für den Kernel:

peh@vidar:/tmp/demo_cksum> le32() { v=$1; i=4; while [ $i -gt 0 ]; do i=$(( i - 1 )); b=$(( ( v >> ( ( 3 - i ) * 8 ) ) & 0xFF )); printf "%b" "$(printf '\\0%03o' "$b")"; done; }
peh@vidar:/tmp/demo_cksum> ( le32 3293830691; le32 2496264086 ) | hexdump -C
00000000  23 de 53 c4 96 f7 c9 94                           |#.S.....|
00000008

Das sieht doch schon mal gut aus ... diese 8 Byte sind mit denen aus der "originalen" Signatur identisch und mit der Funktion haben wir jetzt auch die Möglichkeit, jede beliebige Zahl (solange sie in den Wertebereich paßt) in die passende Darstellung zu konvertieren. Daraus kann man natürlich auch gleich ein komplettes Skript bauen oder sich die Zeile als Shell-Funktion in seiner .profile speichern oder sie eben auch nur als "Einzeiler" irgendwo ablegen, wo man sie wiederfindet.

Am Ende sähe das z.B. so aus:

peh@vidar:/tmp/demo_cksum> ticksum() { le32() { v=$1; i=4; while [ $i -gt 0 ]; do i=$(( i - 1 )); b=$(( ( v >> ( ( 3 - i ) * 8 ) ) & 0xFF )); printf "%b" "$(printf '\\0%03o' "$b")"; done; }; cat "$1"; le32 3293830691; le32 $(cksum "$1" | sed -e "s| .*||"); }
peh@vidar:/tmp/demo_cksum> ticksum kernel.raw > kernel.new
peh@vidar:/tmp/demo_cksum> ticksum fs.raw > fs.new
peh@vidar:/tmp/demo_cksum> cmp kernel.bin kernel.new
peh@vidar:/tmp/demo_cksum> cmp fs.bin fs.new

Die Funktion ticksum nimmt also jetzt den Dateinamen als Parameter entgegen und gibt auf STDOUT (hier dann umgeleitet in eine Datei) die Datei mit der angehangenen Signatur aus - der Vergleich mit dem cmp zeigt, daß die originale Datei von AVM und die mit den "selbstberechneten" Prüfsummen (*.new) identisch sind im Anschluß.

Diese beiden Dateien packt man jetzt in eine Verzeichnisstruktur, die ein Unterverzeichnis var und darunter wieder eines mit dem Namen tmp enthält. Da man obendrein noch das AVM-Programm zum Überprüfen der Prüfsumme braucht und natürlich auch das AVM-Skript /var/install, ist es am einfachsten, man packt gleich das gesamte AVM-Image mittels tar aus auf der Box und ersetzt dann nur noch die AVM-Dateien durch die eigenen ... solange man den Kernel nicht ändert, wäre das also nur das eigene Dateisystem-Image.

~ # wget http://ftp.avm.de/fritzbox/fritzbox-7490/deutschland/fritz.os/FRITZ.Box_7490-07.12.image -O - -q | tar -x -C / -v
./var/
./var/tmp/
./var/tmp/filesystem.image
./var/tmp/kernel.image
./var/content
./var/version
./var/info.txt
./var/regelex
./var/chksum
./var/install
./var/signature
~ # ls -l /var/tmp/*.image /var/install /var/chksum
-r-xr-xr-x    1 root     root        283980 Jul  3  2019 /var/chksum
-rwxr-xr-x    1 root     root         36448 Jul  8  2019 /var/install
-rw-r--r--    1 root     root      29954056 Jul  8  2019 /var/tmp/filesystem.image
-rw-r--r--    1 root     root       2649096 Jul  8  2019 /var/tmp/kernel.image
~ # cp /var/media/ftp/own_filesystem.sqfs /var/tmp/filesystem.image

Anschließend ruft man /var/install auf und betet, daß alles gut gehen möge ... wobei hier auch schon fast nichts mehr schiefgehen kann. Die Fallstricke liegen i.d.R. davor, wenn AVM noch die (kryptographische) Signatur von Images prüft oder wenn es bei einer Box mit wenig RAM-Ausstattung durch den Aufruf von prepare_fwupgrade erst mal darum geht, Prozesse zu beenden und Platz im RAM für das Image zu schaffen.

Mittlerweile hat AVM auch einen Mechanismus für ein "SILENT_UPDATE" erfunden, dessen Funktion mir noch nicht ganz klar ist - der kam (in vollem Umfang) erst mit 07.19 (obwohl schon davor ein paar Vorbereitungen zu sehen waren) und ich habe den noch nicht "live" erleben und beobachten können. Zwar gab es wohl zwischendrin auch mal eine Inhouse-Version, die das getestet hat, aber da bin ich nicht so richtig schlau draus geworden ... vor allem nicht daraus, wann da die Gültigkeitsprüfungen genau ablaufen und ob die nun doppelt (einmal beim Download und einmal vor der (verzögerten) Installation) oder nur einmal ausgeführt werden.

Aber zurück zur /var/install ... bei den meisten Modellen (mit Ausnahme der Puma6-Boxen) schreibt dieses Skript die Firmware gar nicht direkt in die passenden Partitionen - nein, sie prüft erst mal nur alles mögliche (u.a. eben die TI-Prüfsummen) und schreibt die zur eigentlichen Installation erforderlichen Kommandos in die Datei /var/post_install, die im Rahmen des (irgendwann später mal erfolgenden) Neustarts der FRITZ!Box dann die tatsächlichen Kopieroperationen ausführt. Man muß also nach dem Aufruf der /var/install die Box auch i.d.R. erst einmal neu starten, damit die geänderte Firmware auch tatsächlich installiert(!) wird (und das meint nicht nur, daß sie "benutzt" wird - vorher ist sie noch nicht in der passenden Flash-Partition angekommen).

Das mag ja alles für ein "unbeaufsichtigtes" Update ganz spannend und sinnvoll sein (wobei vieles in meinen Augen auch wieder "historisch gewachsen" ist) - aber es geht auch anders und so macht es halt "modfs" schon seit langem (auch wenn das VR9 ist) und ich habe an dieser Stelle eigentlich nie wirklich Klagen gehört, daß dieser Teil nicht funktioniert hätte. Daher ist dieser Weg (den ich trotzdem noch mal erläutern wollte, weil es eben auch der ist, den Freetz-Images nehmen) in meinen Augen auch viel zu kompliziert ... auch wenn AVM i.d.R. natürlich am besten weiß, wie welche Firmware auf welcher Box installiert wird, gibt es da nicht soo viele unterschiedliche Herangehensweisen bei AVM (zumindest nicht bei aktuellen Boxen) und so kann man das i.d.R. auch noch "von Hand" selbst machen oder sich eben ein passendes Shell-Skript dafür bauen.

===============================================

EDIT: Außerdem hat das Verwenden eines eigenen Skripts am Ende sogar noch einen deutlichen Vorteil ... das AVM-Skript installiert immer beides zusammen, den Kernel und das Dateisystem. Auch bei den Boxen, die den UBI-Layer verwenden, sind aber die Kernel-Partitionen "fest" im Flash verankert und verwenden gerade nicht diesen Layer, der ja die physischen Blöcke (PEB) von den "logischen" (LEB) entkoppelt. Während also beim Schreiben des Dateisystem-Images der UBI-Layer für das "wear leveling" sorgt (das ist das Verteilen von Löschzyklen über alle verfügbaren Blöcke, weil diese nur eine begrenzte Anzahl von Löschoperationen vertragen und besonders stark beanspruchte Blöcke dann sehr schnell den Geist aufgeben würden), gibt es das beim Beschreiben der Kernel-Partitionen nicht und jeder zusätzliche Löschzyklus beansprucht ALLE Blöcke in der betreffenden Partition. Solange man also denselben Kernel verwendet, der bereits (in der richtigen Partition wohlgemerkt, denn es gibt ja zwei) installiert ist, sollte man - wenn man das häufiger macht - ohnehin auf das erneute Schreiben des Kernel-Images verzichten - das spricht zusätzlich gegen die Verwendung des originalen AVM-Skripts und am Ende auch gegen die ständige Installation über den Start aus dem RAM, weil auch dabei immer beide "Teile" des Systems neu geschrieben werden, ungeachtet des bisherigen Inhalts.

===============================================

Geht man an diese Aufgabe mit der Idee heran, daß das Skript so viel "Sicherheit" wie möglich bieten soll, muß man natürlich auch entsprechende Tests in das Skript einbauen, damit der Benutzer so wenig Fehler wie möglich dabei machen kann ... das geht bei der Kontrolle des Formats für das Filesystem-Image los und endet bei der Überprüfung der Größe. Vieles von dem, was dieses Skript leisten sollte, macht aber auch das AVM-Skript für die Installation beim Start aus dem RAM (i.d.R. E03-flash_update bei UBI bzw. /wrapper/sbin/flash_update bei VR9 - wobei das ggf. ab 07.20 wieder anders aussieht) bereits ... nur daß dieses Skript halt keine Datei mit dem Image nimmt, sondern sich das Image aus der passenden "Partition" im Hauptspeicher (wohin man es ja per EVA geladen hat) erst einmal in eine Datei schreibt und diese dann flasht.

Wer sich dafür interessiert, kann also auch in dieser (Skript-)Datei nachsehen, wie eine solche Installation ablaufen müßte ... man muß dabei ja auch immer davon ausgehen, daß der Vorrat an verfügbaren Kommandos auf der Box (wo das ja dann laufen muß) schon stark eingeschränkt ist, solange man nicht selbst weitere Kommandos (z.B. mit der eigenen BusyBox) hinzugefügt hat.

Ich mache hier erst mal Schluß und widme mich mal dem Erstellen eines passenden Beispiels, das ich dann ins YourFritz-Repo stelle - ich muß ohnehin aufpassen, daß der Beitrag nicht die max. zulässige Zeichenzahl reißt und ich den hinterher erst wieder splitten muß.

 

[eisbaerin]

@PeterPawn Danke! Sehr gut erklärt!
Da kann ich jetzt also aus einer *.in-memory eine *.image bauen.
Fehlt mir nur noch, wie ich die *.in-memory (new.image) wieder in die 2 einzelnen Dateien zerlegen kann.
Also das Umgekehrte von:
cat kernel.bin fs.sqfs >new.image

Hast du dafür einen Vorschlag?

~ # wget http://ftp.avm.de/fritzbox/fritzbox-7490/deutschland/fritz.os/FRITZ.Box_7490-07.12.image -O - -q | tar -x -C / -v

Muß das unbedingt nach / entpackt werden, um nachher installieren zu können?
Man findet ja die einzelnen Dateien kaum wieder.

~ # cp /var/media/ftp/own_filesystem.sqfs /var/tmp/filesystem.image

Muß hier die own_filesystem.sqfs mit Prüfsumme sein?

---------------------------------------------------------------------------------------------------

Ziel ist es meine 7520 der 7530 von der Fritmware "gleich" zu machen

Welchen Nutzen willst du damit erzielen?