[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

joman · 2 Mai 2017

Ja, die beiden Zeilen sind mir auch aufgefallen. Nur weiß ich nicht, was ich daraus lernen muss

Meine Vermutung in Hinblick auf den ersten Fehler ist, dass der Kernel des aktuellen Systems nicht in der Lage ist das SquashFS4 (?) in dem das zu extrahierende Wurzeldatensystem liegt einzubinden. Der kennt das noch gar nicht und kann nur mit älteren SquashFS umgehen. Daraus resultiert dann auch Fehler 2. Er kann es folglich auch nicht extrahieren.

Aber es muss doch auch einen "Upgradepfad" für dieses Problem geben. AVM selbst kann ja auch seine Boxen auf neue Dateisysteme heben.

Ein unverändertes 6.83 .image lässt sich mittels './modfs install FRITZ.Box_7362_SL.131.06.83.image' auch nicht einspielen.
Auch hier klappt das Einbinden des äußeren Dateisystems nicht. (gleicher Fehler)

Kann evtl. ein Zwischenschritt (z.B. auf eine Version 6.50) Abhilfe schaffen? Und wenn ja, hat ggf. noch irgendwer ein solches Dateisystemimage?
AVM stellt meines Wissens ja nur aktuelle Firmwares zum Download bereit. (Ist so eine Frage hier überhaupt erlaubt?)

Pokemon20021 · 2 Mai 2017

joman schrieb:
Meine Vermutung in Hinblick auf den ersten Fehler ist, dass der Kernel des aktuellen Systems nicht in der Lage ist das SquashFS4 (?) in dem das zu extrahierende Wurzeldatensystem liegt einzubinden. Der kennt das noch gar nicht und kann nur mit älteren SquashFS umgehen. Daraus resultiert dann auch Fehler 2. Er kann es folglich auch nicht extrahieren.

der Kernel muß beim modfs-Lauf kein SquashFS4 einbinden,
bei modfs wird das Filesystem detectiert (Funktion detect_image_filesystem()), ggf. wird das rootfs noch aus dem WrapperFS extrahiert (Umkopieren per dd bzw. mounten des ext-Filesystems) und dann mittels unsquashfs3/4 ausgepackt, anschließend werden die Modscripts angewendet und dann das modifzierte Verzeichnis mit dem Rootfilesystem wieder mit mksquashfs3/4 gepackt und ggf. gewrappt.

Code:

detect_image_filesystem()
# detect filesystem image type
# types supported: squashfs3, squashfs4, ext2, sqfs_dummy256_{type}

joman · 2 Mai 2017

Danke für die Erklärung. Das Erkennen scheint ja auch noch zu funktionieren:
"2017-05-02 11:55:52.913 - detect_image_filesystem: src=/var/media/ftp/General-USBFlashDisk-01/1493718943/filesystem.image, offset=0, fstype=sqfs_dummy256_ext2, rc=0"
Das Einbinden ins tmpfs bringt dann den Fehler:
"2017-05-02 11:55:52.940 - get_temp_dir: directory=/var/tmp/5361_14937189522017-05-02 11:55:52.957 - mount_ext2_image: src=/var/media/ftp/General-USBFlashDisk-01/1493718943/filesystem.image, mp=/var/tmp/5361_1493718952, type=sqfs_dummy256_ext2
2017-05-02 11:55:53.075 - mount_ext2_image: exiting, rc=255"
Am mount point wird es doch wohl nicht liegen? Der benötigt ja keinen Platz im fs. Und die image Datei findet reichlich Platz in der gemounteten Partition auf dem USB-Stick.

Pokemon20021 · 2 Mai 2017

ich habe gerade mal die FW 06.83 Imagedatei der FB7362SL auf der FB7490 (FW 06.8x) für die FB7362SL gemodded:

Code:

FB7490# NOVERIFY=1 [COLOR=#0000ff]./modfs update FRITZ.Box_7362_SL.131.06.83.image FRITZ.Box_7362_SL.131.06.83_modfs.squashfs[/COLOR]
respawn script with custom BusyBox shell, SHLVL=4
/var/media/ftp/USB-STICK-01/download/modfs-0.4.5-300320172215/bin/185/busybox sh ./modfs update FRITZ.Box_7362_SL.131.06.83.image FRITZ.Box_7362_SL.131.06.83_modfs.squashfs
Using debug mode with a 64 KB buffer
Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ... übersprungen
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK

Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.

Im Moment läuft auf der Box die Version: 113.06.83-43494

Die Angabe einer Datei nach dem 'update'-Parameter unterbindet jede Versionprüfung.
Somit ist jeder selbst dafür zuständig, die Kompatibilität der vorhandenen Einstellungen
mit dem verwendeten System sicherzustellen, speziell wenn ein Downgrade ausgeführt wurde
oder ggf. die 'Werkseinstellungen' wiederherzustellen.

Die angegebene Datei '/var/media/ftp/USB-STICK-01/download/modfs-0.4.5-300320172215/FRITZ.Box_7362_SL.131.06.83.image' wird als Quelle für die Aktualisierung genutzt.
Extrahieren des neuen Kernel-Images aus dem Firmware-Image ... OK
Extrahieren des Flash-Filesystems aus dem Firmware-Image ... OK
Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem ... OK
[COLOR=#0000ff]Entpacken des root-Dateisystems für die Modifikationen ... OK[/COLOR]

Das entpackte Dateisystem ist jetzt bereit für die Modifikationen.

Verzeichnis des root-Dateisystems : /var/media/ftp/USB-STICK-01/1493752704/squashfs-root


Die Modifikation 'own files' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK  

SNIP

Das ist die letzte Chance zum manuellen Modifizieren des Dateisystems in folgendem Verzeichnis: /var/media/ftp/USB-STICK-01/1493752704/squashfs-root

Die Eingabetaste drücken, um mit dem Packen des neuen root-Dateisystems zu beginnen
oder 'q' eingeben, um die letzte Möglichkeit zum Abbruch zu nutzen :

[COLOR=#0000ff]Packen des neuen root-Dateisystems ...  OK[/COLOR]
Die erzeugte Image-Datei wird nach '[COLOR=#0000ff]FRITZ.Box_7362_SL.131.06.83_modfs.squashfs[/COLOR]' kopiert ... OK
#

Code:

2017-05-02 21:18:22.230 - progress: mode=1, msg=Extrahieren des neuen Kernel-Images aus dem Firmware-Image ...
2017-05-02 21:18:22.253 - extract_kernel: src=/var/media/ftp/USB-STICK-01/download/modfs-0.4.5-300320172215/FRITZ.Box_7362_SL.131.06.83.image, target=/var/tmp/1493752702/kernel.image
2017-05-02 21:18:22.324 - extract_kernel: exiting, rc=0
2017-05-02 21:18:22.374 - progress: mode=3, msg= OK
2017-05-02 21:18:22.442 - progress: mode=1, msg=Extrahieren des Flash-Filesystems aus dem Firmware-Image ...
2017-05-02 21:18:22.465 - extract_filesystem: src=/var/media/ftp/USB-STICK-01/download/modfs-0.4.5-300320172215/FRITZ.Box_7362_SL.131.06.83.image, target=/var/tmp/1493752702/filesystem.image
2017-05-02 21:18:22.875 - extract_filesystem: exiting, rc=0
2017-05-02 21:18:22.930 - progress: mode=3, msg= OK
2017-05-02 21:18:22.994 - progress: mode=1, msg=Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem ...
2017-05-02 21:18:23.017 - extract_rootfs_from_wrapper: src=/var/tmp/1493752702/filesystem.image, target=/var/tmp/1493752702/filesystem_core.squashfs
2017-05-02 21:18:23.072 - detect_image_filesystem: src=/var/tmp/1493752702/filesystem.image, offset=256, fstype=ext2, rc=0
2017-05-02 21:18:23.092 - detect_image_filesystem: src=/var/tmp/1493752702/filesystem.image, offset=0, fstype=sqfs_dummy256_ext2, rc=0
2017-05-02 21:18:23.131 - get_temp_dir: directory=/var/tmp/6136_1493752703
2017-05-02 21:18:23.150 - mount_ext2_image: src=/var/tmp/1493752702/filesystem.image, mp=/var/tmp/6136_1493752703, type=sqfs_dummy256_ext2
2017-05-02 21:18:23.320 - mount_ext2_image: exiting, rc=0
2017-05-02 21:18:24.116 - remove_directory: directory=/var/tmp/6136_1493752703, rc=0
2017-05-02 21:18:24.144 - extract_rootfs_from_wrapper: exiting, rc=0
2017-05-02 21:18:24.222 - progress: mode=3, msg= OK
2017-05-02 21:18:24.246 - modfs: baseimage=/var/tmp/1493752702/filesystem_core.squashfs
2017-05-02 21:18:24.263 - modfs: newkernelimage=/var/tmp/1493752702/kernel.image
2017-05-02 21:18:24.281 - modfs: wrapperimage=/var/tmp/1493752702/filesystem.image

hier gibt es keine Probleme mit detect_image_filesystem(), extract_rootfs_from_wrapper()
evtl. hilft es Dir als Workaround;

EDIT: Imagename auf FRITZ.Box_7362_SL.131.06.83_modfs.squashfs angepasst

Code:

# ls -la FRITZ.Box_7362_SL.131.06.83.image FRITZ.Box_7362_SL.131.06.83_modfs.squashfs
-rw-r--r--    1 root     root      23828480 May  2 21:13 FRITZ.Box_7362_SL.131.06.83.image
-rw-r--r--    1 root     root      17416192 May  2 21:34 FRITZ.Box_7362_SL.131.06.83_modfs.squashfs

# tar tvpf FRITZ.Box_7362_SL.131.06.83.image
drwxr-xr-x 0/0         0 2017-03-10 10:20:01 ./var/
-rwxr-xr-x 0/0     34468 2017-03-10 10:20:01 ./var/install
-r-xr-x--- 0/0    283844 2016-09-28 21:29:46 ./var/regelex
drwxr-xr-x 0/0         0 2017-03-10 10:20:01 ./var/tmp/
-rw-r--r-- 0/0   2505736 2017-03-10 10:20:01 ./var/tmp/kernel.image
-rw-r--r-- 0/0  20709384 2017-03-10 10:20:01 ./var/tmp/filesystem.image
-rwxr-xr-x 0/0      2795 2017-03-10 10:20:01 ./var/info.txt
-r-xr-x--- 0/0    278552 2016-09-28 21:29:46 ./var/chksum
-rw-r--r-- 0/0       128 2017-03-10 10:20:01 ./var/signature
#

Details zu "Erzeugen einer Installations-Datei für eine andere FB", siehe:
http://www.ip-phone-forum.de/showthread.php?t=284778&p=2153607&viewfull=1#post2153607
sowie Installation dieser Installations-Datei am Beispiel einer FB7412:
http://www.ip-phone-forum.de/showthread.php?t=284778&p=2153612&viewfull=1#post2153612
Hier wird mittels install_inactive_rootfs Skript eine FB7412 gemodded;
ggf. kann dies als Vorlage für Deine FB7362SL dienen.

Hinweis: die Befehle zur Installation der kernel.image Datei können der ./var/install Datei entnommen werden.

joman · 2 Mai 2017

Danke. Weiter oben hatte ich geschrieben, dass ich genau das bereits gemacht hatte. Aber ich weiß nicht, wie ich nun das Ergebnis daraus in die passive Partition der 7362SL bringe.
Eisbären hatte dazu folgendes geschrieben:

Die Datei .squashfs auf die 7412 nach /var/tmp kopieren.

Auf der 7412:
- in beiden Partionen muß eine FW installiert sein!!!
- der Kernel der inaktiven Partition muß zur .squashfs passen, sonst neuen Kernel mit normalem update installieren, und auf alte Partition zurückschalten (oder mit "modfs install", siehe 11.).

Code:
cd /var/tmp;wget -q http://yourfritz.de/7490/install_inactive_rootfs
sh ./install_inactive_rootfs /var/tmp/FRITZ.Box_7412.137.06.50.squashfs

cd /var/tmp;wget -q http://yourfritz.de/7490/switch_system;sh ./switch_system
Der kritische Punkt ist dabei, dass der Kernel der inaktiven Partition bereits einen "neueren" Kernel (als den der 6.30) haben muss.
Und ich weiß nicht, was "sonst Kernel mit normalem update installieren" heißen soll.

PeterPawn · 2 Mai 2017

Die Frage wäre, was da mit den Loop-Devices auf der 7362SL geschehen ist. Das "losetup -a" in Zeile 1268 muß ja noch erfolgreich sein, ansonsten gäbe es eine andere Nachricht im Protokoll (kein "losetup" ab Zeile 1274). Da es auch noch die Version aus der BusyBox ist, die beim "modfs" dabei war (das "$bb" steht ja richtigerweise davor und wurde nicht vergessen von mir), muß die auch die benutzten Optionen kennen.

Bleiben also noch die Aufrufe von "losetup" (Zeile 1270) zum Einbinden des Images, das Auslesen des automatisch zugewiesenen Loop-Devices (Zeile 1272) und das Mounten an sich (Zeile 1291) als mögliche Fehlerursachen übrig. Nun könnte man zwar lang und breit nachsehen, welches dieser beiden Kommandos überhaupt einen Return-Code von "-1" (255) liefern könnte, aber einfacher ist es sicherlich, das einfach mal von Hand anzugehen und zunächst mal mit "<modfs_directory>/bin/VR9/busybox losetup -a" nachzuschauen, ob es da noch unbenutzte Loop-Devices gibt.

Bei der 7490 werden iirc 8 Stück eingerichtet (ls -l /dev/loop*) - vielleicht sind es bei der 7362SL weniger oder es sind aus irgendeinem Grund mehr als üblich belegt. Im Normalfall sollte da nur "/dev/loop0" für das rootFS in Benutzung sein - ob es noch freie Devices gibt, kann man auch mit "losetup -f" ermitteln.

Ansonsten muß man mal die Protokollierung innerhalb der Funktion noch etwas erweitern und genauer protokollieren, welches der drei in Frage kommenden Kommandos nun zum Fehler führt - leider kommen derzeit noch alle drei in Frage.

Das Dateisystem-Image in der 06.83 für die 7362SL ist jedenfalls auch ganz offensichtlich (sowohl nach Debug-Log als auch dem Augenschein mit "hexdump" nach) genauso aufgebaut, wie erwartet.

joman · 2 Mai 2017

Leider bin ich kein Linux-Kenner. Aber gerne liefere ich mal die Infos den Loop-Devices:

# ./bin/VR9/busybox losetup -a
/dev/loop0: 0 /filesystem_core.squashfs
/dev/loop1: 256 /var/media/ftp/General-USBFlashDisk-01/1493748949/filesystem.im
/dev/loop2: 256 /var/media/ftp/General-USBFlashDisk-01/tmp/1493751063/filesyste
#

# ls -l /dev/loop*
brw-rw---- 1 root root 7, 0 Jan 1 1970 /dev/loop0
brw-rw---- 1 root root 7, 1 Jan 1 1970 /dev/loop1
brw-rw---- 1 root root 7, 2 Jan 1 1970 /dev/loop2
brw-rw---- 1 root root 7, 3 Jan 1 1970 /dev/loop3
brw-rw---- 1 root root 7, 4 Jan 1 1970 /dev/loop4
brw-rw---- 1 root root 7, 5 Jan 1 1970 /dev/loop5
brw-rw---- 1 root root 7, 6 Jan 1 1970 /dev/loop6
brw-rw---- 1 root root 7, 7 Jan 1 1970 /dev/loop7
#

Wie könnte ich denn die Protokollierung innerhalb der Funktionen erweitern?

Das Image der 6.83 für die 7362SL wird wohl ok sein. Es lässt sich ja mit einer 7490 mit 6.83 auch ohne Probleme verarbeiten.

PeterPawn · 2 Mai 2017

Da sind aus irgendeinem Grund noch zwei Images eingerichtet, eines von einem "modfs"-Aufruf um 20:15 und eines von 20:51 - mach mal bitte als erstes einen Neustart der 7362SL.

Ansonsten sieht die Ausgabe von "losetup -a" so aus, als würde da nach einer definierten Länge die Ausgabe abgeschnitten ... wenn das nicht nur ein Fehler beim C&P hier ins Forum ist, kann das Auffinden des korrekten Loop-Devices auch daran scheitern - dort wird ja nach einer Zeile gesucht, die den kompletten Image-Namen (inkl. Pfad) enthält.

Hier hilft es natürlich, wenn man dem USB-Speichergerät einen Namen verpaßt (vorausgesetzt, man hat die Modifikation zum Mounten per Label installieren lassen beim letzten "modfs" für das laufende System) - das wäre ein möglicher Weg.

Alternative ist ein zusätzlicher Mountpoint mit einem kürzeren Namen ... das braucht aber ein paar Linux-Kenntnisse. Ein simples bind-Mount sollte schon funktionieren, ich bin nur nicht sicher, ob ein so gemountetes Volume auch vom Code zum Suchen der Mountpoints sauber erkannt und zur Auswahl angeboten wird - das müßte man ggf. ausprobieren, wenn man nicht einfach mit "tune2fs -L <label> /dev/sdXX" dem Stick auf einem anderen System ein Label verpassen will für die ext3-Partition (sofern die Modifikation installiert ist, ich weiß nicht mehr genau, ob AVM bei der 06.30 schon den "mount by label"-Code in der "udev-mount-sd" hatte).

Dieses "tune2fs" für die FRITZ!Box habe ich leider nicht beigelegt - das ist auch eher eine seltene Aufgabe. Wenn ansonsten nichts wichtiges auf dem Stick in der ext3-Partition ist, kann man die aber auch neu formatieren lassen (das "mke2fs" beherrscht auch ext3-Format und das liegt dem "modfs"-Archiv bei) und dabei gleich über "-L <volume_name>" einen Namen setzen lassen. Vorher muß man sie dann halt "dismounten" oder man läßt das vom FRITZ!OS über das GUI erledigen, ändert den Namen und steckt den Stick aus und wieder ein.

joman · 2 Mai 2017

@PeterPawn

Vielleicht habe ich zu viele loop devices durch Abbrüche (wobei das einen ersten Abbruch nicht erklären würde).
Ich heb ein wenig weiter gesucht. losetup in 1270 ergibt rc=0.
Aber das nach sed gepipete Ergebnis aus 1272 gibt mehr als eine Zeile zurück.

# ./bin/VR9/busybox losetup -a
/dev/loop0: 0 /filesystem_core.squashfs
/dev/loop1: 256 /var/media/ftp/General-USBFlashDisk-01/1493755142/filesystem.im
/dev/loop2: 256 /var/media/ftp/General-USBFlashDisk-01/1493757295/filesystem.im
/dev/loop3: 256 /var/media/ftp/General-USBFlashDisk-01/1493757380/filesystem.im
# ./bin/VR9/busybox losetup -a | $bb sed -n -e "s|^$[^ ]*$:.*$src.*\$|\1|p"
/dev/loop0
/dev/loop1
/dev/loop2
/dev/loop3

In 1291 soll aber genau ein device gemountet werden. So verstehe ich es zumindest.
Kann da der Fehler liegen?

Ich sehe gerade, dass ich *$src.* nicht "aufgelöst" habe.
Das war also nix.

PeterPawn · 2 Mai 2017

Ich habe mal eine Änderung eingecheckt (mit neuer Timestamp) und die Länge des zu vergleichenden Image-Namens auf 63 Zeichen begrenzt (soviele sind es in der Ausgabe von "losetup -a" weiter oben).

Das ist zwar nicht so ganz sauber (es unterstellt, daß es innerhalb dieser ersten 63 Zeichen einen eindeutigen Treffer in der "losetup"-Ausgabe gibt), aber es sollte funktionieren - allerdings ist es nicht getestet, weil ich dazu erst ein Volume passend umbenennen müßte und das dauert etwas länger; soviele Fehler sollte man dabei auch nicht machen können (was nicht heißen muß, daß ich es nicht trotzdem geschafft haben könnte).

EDIT:
@joman:
Der Test auf der Kommandozeile ist natürlich nicht ganz "valide" ... mangels gesetzter Variable "$src" wird da ja gar nichts selektiert. Beim Aufruf in "modfs" wird hingehen eher gar keine Ausgabe von diesem Kommando erzeugt, weil der Dateinamen (vor der o.a. Änderung) nicht paßte.

joman · 3 Mai 2017

Ich habe mal ausprobiert. Vorher habe ich noch eine Zeile vor 1291 eingefügt (nur das echo- damit ich auch mal was sehe):

if [ $rc -eq 0 ]; then
echo $bb mount "$loopdev" "$mp"
$bb mount "$loopdev" "$mp" 2>/dev/null
rc=$?

Das Ergebnis war leider wieder ein Fehler:

Extrahieren des Flash-Filesystems aus dem Firmware-Image ... OK
Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem .../var/media/ftp/General-USBFlashDisk-01/mod/bin/203/busybox mount /var/tmp/15249_1493761295
Fehler

Allerdings wirkt es so, als ob $loopdev tatsächlich leer oder besser nichts ist.

Hier nochmal die Ausgabe von:
# /var/media/ftp/General-USBFlashDisk-01/mod/bin/203/busybox losetup -a
/dev/loop0: 0 /filesystem_core.squashfs
/dev/loop1: 256 /var/media/ftp/General-USBFlashDisk-01/1493761284/filesystem.im
#

- - - Aktualisiert - - -

Ich habe einfach mal loopdev auf /dev/loop1 gesetzt:
loopdev=/dev/loop1 vor Zeile 1273

Dann funktioniert es. (habe natürlich vorher alle nicht genutzten loop devices gelöscht).
Danach habe ich aber abgebrochen, weil ich nicht weiß, ob so etwas im script nochmal kommt.
Hier ein Auszug aus dem Vorgang:

Extrahieren des Flash-Filesystems aus dem Firmware-Image ... OK
Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem .../dev/loop1
/var/media/ftp/General-USBFlashDisk-01/mod/bin/203/busybox mount /dev/loop1 /var/tmp/19986_1493762919
OK
Löschen des geladenen Firmware-Images ... OK
Entpacken des root-Dateisystems für die Modifikationen ... OK

Das entpackte Dateisystem ist jetzt bereit für die Modifikationen.

Verzeichnis des root-Dateisystems : /var/media/ftp/General-USBFlashDisk-01/1493762941/squashfs-root

Die Modifikation 'own files' wird verarbeitet ...

Der helle Kram kommt von meinen Echos.
Irgendwie funktioniert bei mir Zeile 1272 nicht richtig und liefert deshalb kein loop device zurück.
Vielleicht ist einfach die Pfadangabe zu lang (Endlos langer Gerätename des USB-Sticks)

PeterPawn · 3 Mai 2017

Ist dieser Test nun mit oder ohne meine Änderung von 22:41 Uhr? Ich bin etwas verwirrt.

Ok, offenbar mit - sagt jedenfalls das letzte Debug-Log.

Ich ändere mal noch etwas - aber ohne den Zeitstempel erneut anzupassen. Ich verstehe zwar nicht, warum das Suchen des Loop-Devices nun schief geht, aber ich werde zumindest diesen Fall noch gesondert abfangen und protokollieren - auch wenn damit das Problem noch nicht gelöst ist.

Mist, das "substring" in der Shell ist nullbasiert, die ersten 63 Zeichen sind also "${src:0:63}" - das kommt davon, wenn man nicht testet (auch wenn ich das angesagt hatte).

Ich habe es korrigiert und nun doch einen neuen Zeitstempel verwendet. Jetzt sollte es aber endlich klappen ... als Umgehungslösung bleibt Dir ansonsten ja immer noch der kürzere Pfad mit dem Volume-Label.

- - - Aktualisiert - - -

So, jetzt aber hoffentlich ... getestet habe ich es immer noch nicht selbst.

joman · 3 Mai 2017

@PeterPan

Wir sind doch schon echt weit gekommen.
Habe meinen USB-Stick nun in einen kurzen Pfad gemountet:

mount /dev/sda1 /var/media/ftp/USB -t ext3

Jetzt funktioniert modfs

Das Update habe ich jetzt durchlaufen lassen und meine 7362SL läuft jetzt mit 6.83.

Dein Script probiere ich noch eben aus, dann muss ich aber für heute (Oh, ist schon morgen) ins Bett.
Gerne machen wir bei dann später weiter ok?

Rückmeldung zur Änderung kommt gleich.

- - - Aktualisiert - - -

@PeterPawn

Das habe ich gerade gesehen:

Wenns für dich ok ist riskier ich den Neustart erst morgen in aller Ruhe. Dann habe ich auch genug Muße um mich ggf. mit Adam und eva herumzuschlagen.

PeterPawn · 3 Mai 2017

@joman:
Das kannst Du testen, wenn es bei Dir paßt ... von der Ansicht beim Bootmanager darfst Du Dich auch nicht schocken lassen, das ist normal, wenn unterschiedliche Kernel (und mithin unterschiedliche SquashFS-Versionen) benutzt werden - dann kann der Bootmanager (anders als "modfs", aber das muß auch nichts mounten) mit dem alternativen Dateisystem jeweils nichts anfangen (weil er es nicht mounten kann).

joman · 3 Mai 2017

@PeterPawn:

konnte ohne Probleme wieder auf die alte 6.30 umschalten und habe modfs mit deiner Änderung ausgeführt. Klappt prima.
Hier ein kurzer Auszug:
Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.

Im Moment läuft auf der Box die Version: 131.06.30-30889

Die Auswahl des 'update'-Modus erfordert eine neuere Firmware-Version vom Hersteller.

Ermitteln der neuesten Version durch Abfrage beim Hersteller ... OK
Es wurde eine neuere Version (131.06.83) gefunden.
Download eines Firmware-Images für Version 131.06.83 vom Server des Herstellers ... OK
Überprüfen der Signatur der geladenen Datei ... OK
Extrahieren des neuen Kernel-Images aus dem Firmware-Image ... OK
Extrahieren des Flash-Filesystems aus dem Firmware-Image ... OK
Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem ... OK
Löschen des geladenen Firmware-Images ... OK

Hab dann aber abgebrochen. Hier noch das debug file Anhang anzeigen debug.txt

Es bleibt natürlich das Problem lei sehr langen Pfaden. Da könnte die Eindeutigkeit innerhalb der ersten 63 Zeichen auf der Strecke bleiben.
Gibt es vielleicht eine Version von losetup, die komplette Pfade ausgibt? Ggf. muss du auch eine maximale Pfadlänge voraussetzen.
Vielleicht ist auch gar nichts nötig.
(Ich scheine ja der erste Kandidat zu sein mit dem laaaaangen USB Gerätenamen)

Also Danke nochmal für die tolle Arbeit mit modfs und natürlich auch für deine schnelle kompetente Hilfe.

KiRKman · 6 Mai 2017

Ich wollte nur kurz vermelden, dass ich mit diversen FRITZ!Box 7490 seit geraumer Zeit keine Probleme mehr beim Updaten mittels modfs feststellen konnte.

Auch "Sprünge" direkt von 113.06.60 auf 113.06.83 waren problemlos möglich. Alle von mir benutzten Modifikationen funktionieren bis dato tadellos.

Die gerade aktuelle Labor 113.06.86-44065 klappt denn ebenfalls ohne Probleme.

Und dabei habe ich momentan nicht einmal eine Swap-Partition eingebunden. Also vielen Dank nochmals für die tolle Arbeit!

Micha0815 · 8 Mai 2017

Ich musste leider ein nicht erkennbares Problem konstatieren bei der Verwendung einer 6.83-AT/CH Branding avme und 6.80 Branding avm. Die gebootete 6.83 lässt keinen GUI Zugriff zu, Wlan tot nur LAN funktioniert ohne GUI? sprich die FB7490 ist mit DSL verbunden. VPN streikt nur per Teamviewer ging Zugriff auf Lan Client um adam2 Firewall feste Lan ip remote vorzubereiten. Da flossen Tränchen der Wut, bis das linux_fs_start umschalten via falschem Recovery Programm funktionierte. Zu Zeiten der Laborreihe 6.69 für die 7490 lief das Umschalten zwischen 2 unterschiedlichen FWs mit unterschiedlichen Brandings ohne Probleme. Da imho alle subscripts fehlerfrei durchliefen, bin ich irritiert, wo es hakeln könnte.
LG

Gesendet von meiner Handquetsche mit dicken Fingern

Micha0815 · 17 Aug 2017

Zur Zeit bin ich in AT und konnte das Problem eingrenzen. Es klappt schlicht und einfach das Umsetzen des Brandings von avm auf avme nicht über das GUI. In meinem Fall von linux_fs_start 0 (FW 6.83-DE) nach linux_fs_start 1 (FW 6.83-A/CH). Loggt man sich aufwändig über adam2 in die aktuell gestartete A/CH-version ein und setzt das Branding dort zufuss auf avme, passt es. Die etwas seltsam anmutenden Effekte einer gestarteten 6.83-AT/CH-Version mit Branding avm kann ich nur nochmals wiederholen. Zumindest hier an einem ADSL-Anschluss läuft die AT/CH-Version ohne Fehler und Einschränkungen mit Annex A, während die DE-Version und Annnex B mit einer Fehlerrate aufwartet. Die Gegenstelle ist ein Broadcom 177.169 von A1 und die DSL-Treiber scheinen unterschiedlich gut zu sein.
LG

PeterPawn · 17 Aug 2017

Da ja seit Ende März das "modscript" für diesen Boot-Manager in der neuen Version 0.4 vorliegt und ich nicht einschätzen kann, wann da das letzte Update erfolgte, wo es noch ging, wäre ggf. die Verwendung der älteren Version 0.3 zumindest einen Test wert. Ich sehe zwar beim besten Willen auch beim dritten und noch häufigeren Lesen das Problem nicht (auch nicht, wenn ich v0.3 und v0.4 nebeneinander lege und vergleichen lasse), aber es ist auch nicht auszuschließen, daß es da irgendeinen Tippfehler gibt.

Wenn das mit v0.3 wieder reibungslos klappt, muß man weitersuchen ... das braucht dann aber ein paar Tests von Hand auf einer Box mit der passenden Firmware-Konstellation. Die Umschaltung zwischen "avm" und "1und1" (bei einer alternativen Firmware, die mehr als ein Branding unterstützt) klappt bei mir jedenfalls reibungslos - da käme dann m.E. nur noch der "Spezialfall" als Ursache in Frage, daß es für das alternative System eben keine Wahlmöglichkeit gibt.

Man muß nun erst einmal ermitteln, ob da ein falscher Wert für das Branding gesetzt werden soll und das auch klappt oder ob das Setzen des ansonsten korrekten Wertes fehlschlägt. Dazu wäre es hilfreich, wenn es Dir gelingt, den zusätzlich generierten HTML-Code aus der Seite zu extrahieren. Das ist allerdings beim "responsive design" nicht mehr einfach mit "Quelltext der Seite anzeigen" erledigt ... aber ein Mitschnitt der Netzwerk-Kommunikation mit den Developer-Tools eines Browsers und die Suche in den Ergebnissen eines Aufrufs der "data.lua" für "page=reboot" sollte dann etwas wie den folgenden Abschnitt enthalten:

HTML:

<div id="managed_reboot" class="reboot_managed">
<br /><h3>Folgende Systeme stehen auf dieser FRITZ!Box zur Auswahl bei einem Neustart:</h3><br />
<input type="radio" id="radioRunning" name="linux_fs_start" value="running" checked="checked" />
<label for="radioRunning">das aktuell laufende System</label><br /><br />
Version 113.06.88-45818 vom 08.08.2017 18:54:30 (linux_fs_start=1), das System wurde am 10.08.2017 17:00:18 zuletzt modifiziert<br /><br />
<input type="radio" id="radioAlternative" name="linux_fs_start" value="alternative" />
<label for="radioAlternative">das derzeit inaktive System</label><br /><br />
Version 113.06.88-45942 vom 14.08.2017 13:39:40 (linux_fs_start=0), das System wurde am 14.08.2017 16:32:30 zuletzt modifiziert<br /><br />
<span id="running_branding">
<h4>Das oben ausgew&auml;hlte System unterst&uuml;tzt mehrere Firmware-Versionen (Brandings), im Moment ist "1und1" eingestellt.</h4>
<label for="idRunningBranding">Beim n&auml;chsten Start wird folgender Wert gesetzt und bis zur n&auml;chsten &Auml;nderung verwendet: </label>
<select id="idRunningBranding" name="running_branding">
<option value="1und1" selected="selected">1und1</option>
<option value="avm">avm</option>
</select>
</span>
<span id="alternative_branding">
<h4>Das oben ausgew&auml;hlte System unterst&uuml;tzt mehrere Firmware-Versionen (Brandings), im Moment ist "1und1" eingestellt.</h4>
<label for="idAlternativeBranding">Beim n&auml;chsten Start wird folgender Wert gesetzt und bis zur n&auml;chsten &Auml;nderung verwendet: </label>
<select id="idAlternativeBranding" name="alternative_branding">
<option value="1und1" selected="selected">1und1</option>
<option value="avm">avm</option>
</select>
</span>
<script type="text/javascript">
function onBootManagerClick(evt) {
var radioButton = jxl.evtTarget(evt);
if ( radioButton.id == "radioRunning" ) {
jxl.show("running_branding");
jxl.hide("alternative_branding");
} else {
jxl.hide("running_branding");
jxl.show("alternative_branding");
}
}
function initBootManager() {
jxl.addEventHandler("radioRunning","click",onBootManagerClick);
jxl.addEventHandler("radioAlternative","click",onBootManagerClick);
jxl.display("running_branding", true);
jxl.display("alternative_branding", false);
}
ready.onReady(initBootManager);
</script>

</div>

Da kann man dann sehen, was beim finalen Aufruf zum Umschalten verwendet werden sollte als Parameter ... stimmt das, ist die Frage, ob die Umschaltung ggf. bei der verwendeten Box nicht mehr dauerhaft möglich ist. Es gibt ja einzelne Berichte, daß das bei neueren 7490 nicht (mehr) klappen soll - ich hatte den Fall (bei einer 7490) noch nicht. Das müßte man dann natürlich auch erst einmal von Hand probieren - überlebt der neue Wert (der sich vom Wert bei der Herstellung unterscheiden muß) einen Neustart nicht, ist diese Frage auch geklärt.

Dann blieben zwar auch noch ein paar andere Modifikationen an einer zu installierenden Firmware als Option übrig, wenn man seine Box mit unterschiedlichen Versionen (D vs. intl.) betreiben will (wo man einfach auf die Auswertung im Environment verzichtet und das Branding fest in der Firmware setzt) - aber das ist eine andere Vorgehensweise.

PeterPawn · 17 Aug 2017

Ich habe jetzt etwas gefunden ... wenn das aber die Ursache ist, dann kann das seit dem 06.11.2016 (also bei allen Modifikationen, die danach erfolgten) schon nicht mehr funktioniert haben. Bei der Umstellung auf POSIX-kompatiblen Code habe ich vergessen, an einer Stelle ein "printf" korrekt mit Parametern zu versehen und die Variablensubstitution in der "Maske" findet nicht statt:

Code:

printf '<input type="hidden" name="alternative_branding" value="$alternative_brandings" />\n'

Damit wird dann wohl versucht, direkt den Wert "$alternative_brandings" als Parameter zu verwenden, was dann natürlich beim (zweiten) Aufruf zum Umschalten zu "leer" substituiert wird und damit bleibt der alte Wert stehen im Environment ... aber wie gesagt, der Defekt wurde bereits Anfang November eingeführt und blieb in den folgenden sechs Monaten unbemerkt (aber er tritt auch nur dann auf, wenn das alternative System wirklich nur ein Branding unterstützt, was auch eher selten ist). Wegen der Bemerkung mit der Labor-Reihe 06.69 (die ja bis in den Januar 2017 lief) habe ich da an der falschen Stelle gesucht.

Ich ändere das jetzt mal - die neue Version sollte dann am neuen Zeitstempel auch zu erkennen sein, da kommt nicht noch einmal eine gesonderte Meldung meinerseits.

Dabei kann ich dann auch gleich die von mir aufgerissene "command injection"-Lücke mit dem "os.execute" im Lua-Code fixen ... ich habe (fahrlässigerweise) nicht damit gerechnet, daß da noch Ersetzungen stattfinden könnten - zumindest in der Theorie sieht das jetzt aber so aus (wenn da bei @Micha0815 nicht "$alternative_brandings" im Environment stand, sondern wirklich weiterhin "avm"). Daher packe ich einfach noch ein paar Hochkommata um die Werte, die vom Browser kommen.

Der Wertebereich für "linux_fs_start" ist ohnehin schon auf "running" und "alternative" beschränkt bei der späteren Auswertung im Shell-Code. Eine zusätzliche Überprüfung, daß der als Branding vom Browser übermittelte Wert auch gültig ist, würde das erneute Mounten des Dateisystems in der alternativen Partition erfordern - das ist mir zuviel Aufwand (für die Box und nicht für mich, das wären nur wenige Zeilen, weil das ja schon existiert) und solange da ein Angreifer keine eigenen Kommandos ausführen kann, muß man ggf. mit einem falschen Wert leben (dann bemerkt man den Angriff wenigstens).

[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

Neuer User

Mitglied

Neuer User

Mitglied

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

Anhänge

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

Aktives Mitglied

IPPF-Promi

IPPF-Promi

Anhänge

IPPF-Urgestein

IPPF-Urgestein

Statistik des Forums