Fritzbox 6490 Cable Firmware Update?

[Kirandia]

@ noob_noob

Hi,

hab dir ne private message geschickt. Bis jetzt hast nicht drauf geantwortet. Handy-Nummer hab ich hinterlegt.
Hätte sogar einen guten deal für dich. (wäre auch einer für mich dann). Hab heute von nem Kumpel eine FB 6490 geschenkt bekommen. Ist eine UM-Box (2000 2689) die er fälschlicherweise aus der Bucht ersteigert hat. Die Box ist trotzdem eine rote. Der Verkäufer hat das gemacht. Mein Kumpel dachte es wäre eine echte KD-Box. Aber ist ja egal, ob nun weisser oder roter Deckel, auf das innere kommt's drauf an.
UM hat ihm diese Box nicht provisoniert weil sie sofort gemerkt haben dass es eine UM-Box ist als er die Seriennummer und CM MAC-Adresse telefonisch durchgegeben hat. Der Ebay-Verkäufer weigert sich die Box zurückzunehmen.
Er kauft sich jetzt eine Retailbox aus dem Mediamarkt den es bei uns auch in Bruchsal gibt.
Ich hab seine Box (hatte FW 06.24 drauf) auf die 06.62 manuell geflasht und von dort das Online-Update auf die aktuellste FW 06.63 wieder am UM-Arris-Modem von meiner Mutter per LAN1 gemacht. Box hatte nach dem Update wie alle anderen Boxen die ich so schon updgedatet habe (new/new)-Zertifikate drauf.
Jetzt zum Angebotsdeal:
Du wolltest mir deine schicken. Wenn es mir gelingt sie auf die 06.63 upzudaten, würde ich die gerne behalten, weil die bei UM provisioniert wird und ich würde dir die rote UM-Box schicken im Tausch.
Somit hättest du dann ebenfalls eine voll online updatefähige Fritte mit UM-Artikelnummer, die bei KD/Vodafone auch als eigene Box dann provisioniert werden kann.
Das ist mein Angebot.
Ansonsten schau ich halt wieder bei ebay ob ich einen finde der seine rote KD/Vodafone-Box (2000 2691) verkaufen will weil er sie bei Kabel Deutschland eben nicht provsioniert bekommt und mit einem Tauch auch einverstanden wäre.

 

[PeterPawn]

@tetzlav:
Minimale Korrektur und Ergänzung(en) meinerseits ... ansonsten danke für die Aufstellung - ich weigere mich ja, so etwas zu verfassen.

Die Wahl des TFFS-Images für das Auseinandernehmen (Punkt 2.4 oben) hat nichts mit der aktuellen Variablen "linux_fs_start" zu tun. Die FRITZ!Box beschreibt von beiden Systemen aus die TFFS-Partitionen immer im Wechsel (vereinfacht, es gibt noch Caching), welche Partition das "jüngste" (also aktuellste) Image enthält, kann man an den ersten 8 Byte (eigentlich auch schon an den vier Byte ab Offset 4) sehen:

$ for dev in $(sed -n -e "s|^mount=\(.*\)|\1|p" /proc/tffs); do dd if=/dev/$dev bs=8 count=1 2>/dev/null | hd; done
00000000  00 01 00 04 [COLOR="#FF0000"]ff ff ff af[/COLOR]                           |........|
00000008
00000000  00 01 00 04 [COLOR="#FF0000"]ff ff ff b0[/COLOR]                           |........|
00000008

(hier halt "live" aus den TFFS-Partitionen einer 7490 ausgelesen). Der kleinere (vorzeichenlose) Wert (hier der erste) steht in der zuletzt geschriebenen Version, die nächste würde dann auf "ae" enden und in der Partition landen, wo jetzt die "b0" steht. Beim Start geht das FRITZ!OS ebenso vor - die Partition mit dem kleinsten Wert ist die aktive und von dort werden die aktuellen Einstellungen geladen.

Wenn man also nicht die letzten Änderungen "verlieren" will (das können auch Daten sein, die das System selbst geschrieben hat, das muß nicht zwangsläufig eine selbst geänderte Einstellung sein), dann nimmt man die Datei, die den kleineren Wert enthält - wobei man ja i.d.R. die Änderungen des Systems nach dem Extrahieren der Support-Daten ohnehin nicht mehr berücksichtigen kann.

---

-Nachdem @fesc den Beitrag zur Zusammenstellung des eigenen TFFS-Images erstellt hatte, habe ich im Verzeichnis "tffs" noch eine passende Name-Table (Version @L, eine neuere habe ich noch nicht gesehen) hinzugefügt - man hat also nach dem Clonen des Repositories bereits eine passende Name-Table und muß die nicht aus einem IPPF-Beitrag kopieren - weder aus dem von @fesc noch aus dem von mir (war glaube ich bei der 7412 in irgendeinem Thread).

Die Punkte 4 und 5 bei @fesc waren nur der Tatsache geschuldet, daß bei ihm die Dateien von der FRITZ!Box ohne "\r" am Zeilenende vorlagen (daher wurden die Einträge nicht gefunden) - der Grund dafür ist weiterhin unklar, aber ich habe dann die Skripte noch einmal dahingehend geändert (ich hatte mich ohnehin vertan), daß sowohl DOS- als auch UNIX-Zeilenenden jetzt funktionieren.

Ansonsten sind die Skript-Dateien im Repository immer entweder für die "bash" oder für die "ash" der Busybox gedacht, sofern ich nicht extra "POSIX-kompatibel" dazuschreibe (wie bei "juischeckupdate") - das ist einfach so, weil die Skript-Dateien auch auf einer FRITZ!Box (mit originaler Firmware) oder einem RasPi lauffähig sein sollen.

Wer Probleme von Beginn an vermeiden will und z.B. ein System verwendet, wo "/bin/sh" die "dash" ist, der muß einfach die Dateien anpassen (jeweils das SheBang). Auch ist das jeweils richtige "Startverzeichnis" beim Aufruf eines Skripts wirklich entscheidend (auch wenn der natürliche "Reflex" vielleicht wäre, im /tmp-Verzeichnis zu starten), solange man nicht ein paar weitere Angaben in den Skript-Dateien (meistens als 'YF_SCRIPT_DIR="."'-Zeile, damit die Hilfsfunktionen gefunden werden) anpassen will.

- - - Aktualisiert - - -

Nachdem mir aufgefallen ist, wieviele Schritte für das Bereitstellen von Name-Table, Environment und Zählern notwendig sind, könnte man mal darüber nachdenken, das gleich ebenfalls aus dem TFFS-Image in der Support-Datei zu extrahieren.

Wenn das so eine lange Liste ergibt, liegt das zu einem guten Teil auch daran, daß die Skript-Dateien ja für einen vollkommen anderen Einsatzzweck vorgesehen waren und dabei dann auch Zwischenresultate von Bedeutung waren.

Wenn man nur eine eigene Datei dem TFFS-Image hinzufügen will, braucht man die eigentlich nur an der richtigen Stelle (die erste "ID" aus binären Einsen ist das Ende der "Liste" der vorhandenen Einträge, die richtige Stelle findet man durch sequentielles Durchsuchen des Images, wobei man für jeden Eintrag die ID und die Länge liest und dann bei einer ID <> 65535 um die Länge (+4, weil ID und Längenfeld nicht in der Längenangabe enthalten sind) "weiterrutscht") ans Ende der vorhandenen Daten zu schreiben und den Wert an Offset 4 so setzen, daß er sicher kleiner ist als die bereits vorhandenen Werte in den Partitionen der Box. Ansonsten braucht man am Ende auch nur eine einzelne Partition zu flashen - es ist sogar egal, welche man nimmt.

Man muß also auch nicht das Image aus der zweiten Dump-Datei nach MTD4 schreiben und das aus der ersten nach MTD3 - das System sucht sich beim Start eben die Partition mit der kleinsten Segment-ID (das ist der Wert in den ersten 8 bzw. 4 Byte) und nimmt diese - subtrahiert man gleich selbst einen größeren Wert (16 wäre schon recht viel), ist man ziemlich sicher kleiner, solange die Support-Daten nicht steinalt sind. Das Auslassen eines Flashvorgangs für eine Partition "schont" den Flash-Speicher (der hat nur eine begrenzte Zahl von Schreibzyklen) - nur dann, wenn man sich nicht sicher ist, ob die eigene verwendete Segment-ID tatsächlich die kleinste ist, flasht man beide Partitionen mit dem eigenen Image. Dann nimmt das System halt die erste Partition, weil die Segment-ID in der zweiten nicht kleiner ist.

Alle anderen Schritte (bis auf das Zusammenstellen eines passenden Tarballs) sind tatsächlich auf das Dekodieren des TFFS-Images (das steht ja in "base64" in der Support-Datei), das Suchen des passenden Offsets und das Schreiben des zusätzlichen Nodes (unter der Annahme, daß der Platz dafür noch ausreicht) zu reduzieren, dann muß das entstandene Image nur noch in die richtige Partition geschrieben werden.

 

[tetzlav]

@PeterPawn:
Ich hatte heute übrigens beim zweiten Test eine Firmware via deiner autoupdate scripte zu installieren einen Hänger der Box. Das update wurde zwar durch geführt, aber die Box startete nicht neu und nur die WLAN-LED leuchete noch. Hier ist das remote-log dazu:

 tetzlav@T410s # sudo nc -l 514
+ test -f /var/media/ftp/newfirmware.image
+ test -f /var/media/ftp/newfirmware.image
+ stat -c %s /var/media/ftp/newfirmware.image
+ fsize=45690368
+ test 45690368 -eq 0
+ tarlist=/var/tmp/run_update.3909.list
+ tar -t -v -f /var/media/ftp/newfirmware.image
+ test -s /var/tmp/run_update.3909.list
+ sed -n -e s|.*\(var/tmp/filesystem.image\).*|\1|p /var/tmp/run_update.3909.list
+ test var/tmp/filesystem.image = var/tmp/filesystem.image
+ sed -n -e s|.*\(var/tmp/kernel.image\).*|\1|p /var/tmp/run_update.3909.list
+ test var/tmp/kernel.image = var/tmp/kernel.image
+ sed -n -e s|.*\(var/install\).*|\1|p /var/tmp/run_update.3909.list
+ test var/install = var/install
+ test -f /var/media/ftp/check_signed_image
+ tar -C / -x -f /var/media/ftp/newfirmware.image
+ grep -B 5 ^[ \t]*if *\[ *"$i" *= *"${OEM}" *\] *; *then[ \t]*$ /var/install
+ sed -n -e s|for *i *in *\(.*\) *; *do|\1|p
+ echo avm
+ brandings=avm
+ found=0
+ changebranding=0
+ test avm = avm
+ found=1
+ break
+ test 1 -eq 0
+ test 1 -eq 0
+ test 0 -eq 1
+ sed -e s|>[ ]*/dev/console|>\&6|g /var/install
+ mv /var/tmp/install.tmp /var/install
+ test 0 -eq 1
+ force=
+ pwd
+ opwd=/
+ cd /
+ /bin/sh /var/install
install: have Kernel 2.6.39.3 - set kversion '2.6.39' and FlashUpdateTool '/lib/modules/2.6.39.3/kernel/drivers/char/flash_update/flash_update.ko'
install: check and install new firmware ...
OEM=
ANNEX=Kabel
testing acceptance for device Fritz_Box_HW213a ...
korrekt install type: arm_2GB_xilinx_4eth_2ab_isdn_nt_usb_host_dect_wlan11ac_kabel_03023
device has installtype arm_2GB_xilinx_4eth_2ab_isdn_nt_usb_host_dect_wlan11ac_kabel_03023
assumed ANNEX Kabel -- found ANNEX Kabel
device has ANNEX Kabel
OK - accept this update for device Fritz_Box_HW213a ...
testing acceptance for device Fritz_Box_HW213a done
curr: 141.06.63  new: xx.06.63
debug: curr: 141.06.63
debug: new: "XX.06.63"
major_currFWver=141
middle_currFWver=6
minor_currFWver=63
middle_newFWver=6
minor_newFWver=63
check Firmware Version: xx.06.63
DEBUG: 6 >= 6
DEBUG: 63 >= 63
Accept Firmware Version: xx.06.63
install: 2.6.39 check files...
read 0x0 MACIG 0x0
File doesn't contain the checksum, adding
[cs_calc_sum] sum 0xacd8e69b
Calculated checksum is ACD8E69B
[cs_set_sum] tagged 0
write 0x23de53c4, 0x9be6d8ac MAGIC 0xc453de23 
Adding failed
chksum for file /var/remote/var/tmp/x86/filesystem.image ok
size for file /var/remote/var/tmp/x86/filesystem.image ok
read 0x69120b31 MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0x69120b31
Calculated checksum is 69120B31
Saved checksum is 69120B31
Checksum validation successful!
chksum for file /var/remote/var/tmp/x86/kernel.image ok
size for file /var/remote/var/tmp/x86/kernel.image ok
read 0x0 MACIG 0x0
File doesn't contain the checksum, adding
[cs_calc_sum] sum 0x65514c3f
Calculated checksum is 65514C3F
[cs_set_sum] tagged 0
write 0x23de53c4, 0x3f4c5165 MAGIC 0xc453de23 
Adding failed
chksum for file /var/remote/var/tmp/filesystem.image ok
size for file /var/remote/var/tmp/filesystem.image ok
read 0xc9040a34 MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0xc9040a34
Calculated checksum is C9040A34
Saved checksum is C9040A34
Checksum validation successful!
chksum for file /var/remote/var/tmp/kernel.image ok
size for file /var/remote/var/tmp/kernel.image ok
/var/install [4042]: +++++++++++++ update start
/var/install [4042]: +++++++++++++ FlashCMDs (to be executed):
/var/install [4042]: +++++++++++++ ATOM Kernel     FlashCMD: dd if=/var/remote/var/tmp/x86/kernel.image of=/dev/mmcblk0p4 count=2048 bs=4096 conv=sync
/var/install [4042]: +++++++++++++ ATOM Filesysten FlashCMD: dd if=/var/remote/var/tmp/x86/filesystem.image of=/dev/mmcblk0p3 count=16384 bs=4096 conv=sync
/var/install [4042]: +++++++++++++ ARM Kernel     FlashCMD: dd if=/var/remote/var/tmp/kernel.image of=/dev/mmcblk0p2 count=2048 bs=4096 conv=sync
/var/install [4042]: +++++++++++++ ARM Filesysten FlashCMD: dd if=/var/remote/var/tmp/filesystem.image of=/dev/mmcblk0p1 count=16384 bs=4096 conv=sync
/var/install [4042]: +++++++++++++ ATOM flash kernel
902+1 records in
903+0 records out
/var/install [4042]: +++++++++++++ ATOM check kernel
/var/install [4042]: +++++++++++++ ATOM md5sum of kernel image: 40a881256c2419ad96fa3941f495ee2c  
/var/install [4042]: +++++++++++++ ATOM size of kernel image: 3697840
/var/install [4042]: +++++++++++++ ATOM md5sum of kernel mtd : 40a881256c2419ad96fa3941f495ee2c  
/var/install [4042]: +++++++++++++ ATOM write to /dev/mmcblk0p4 done
/var/install [4042]: +++++++++++++ ATOM flash filesystem
5524+0 records in
5524+0 records out
/var/install [4042]: +++++++++++++ ATOM check filesystem
/var/install [4042]: +++++++++++++ ATOM md5sum of filesystem image: 3353a96d903df55ec2aa5835a53d98fa  
/var/install [4042]: +++++++++++++ ATOM size of filesystem image: 22626304
/var/install [4042]: +++++++++++++ ATOM md5sum of filesystem mtd : 3353a96d903df55ec2aa5835a53d98fa  
/var/install [4042]: +++++++++++++ ATOM write to /dev/mmcblk0p3 done
/var/install [4042]: +++++++++++++ ARM flash kernel
443+1 records in
444+0 records out
/var/install [4042]: +++++++++++++ ARM check kernel
/var/install [4042]: +++++++++++++ ARM md5sum of kernel image: fa185616c693b50190b7f14a6ab01fa8  
/var/install [4042]: +++++++++++++ ARM size of kernel image: 1818288
/var/install [4042]: +++++++++++++ ARM md5sum of kernel mtd : fa185616c693b50190b7f14a6ab01fa8  
/var/install [4042]: +++++++++++++ ARM write to /dev/mmcblk0p2 done
/var/install [4042]: +++++++++++++ ARM flash filesystem
3820+0 records in
3820+0 records out
/var/install [4042]: +++++++++++++ ARM check filesystem
/var/install [4042]: +++++++++++++ ARM md5sum of filesystem image: 1231b8a44ed24a8ac4f519291f0e492e  
/var/install [4042]: +++++++++++++ ARM size of filesystem image: 15646720
/var/install [4042]: +++++++++++++ ARM md5sum of filesystem mtd : 1231b8a44ed24a8ac4f519291f0e492e  
/var/install [4042]: +++++++++++++ ARM write to /dev/mmcblk0p1 done
/var/install [4042]: +++++++++++++ ARM Calling additional procedure (ewnw_check_install)
/var/docsiscertdefaults: Kein CM Zertifikat im Urlader
/var/install [4042]: +++++++++++++ linux_fs_start = linux_fs_start    1
/var/install [4042]: +++++++++++++ linux_fs_start:     1
/var/install [4042]: +++++++++++++ set linux_fs_start=0
/var/install [4042]: +++++++++++++ set linux_fs_start = 0
/var/install [4042]: +++++++++++++ check linux_fs_start = linux_fs_start    0
/var/install [4042]: +++++++++++++ UPDATE SUCCESS
+ rc=1
+ cd /
+ test 1 -gt 1
+ test 0 -eq 1
+ exec
+ exec /var/post_install
stopping WLAN ...
sh: y: unknown operand
sh: 213: unknown operand
WLAN ... stopped

 

[noob_noob]

@ noob_noob

Hi,

hab dir ne private message geschickt.

nun aber. rot ist meine auch. hat nur ne seriennummer, die rausfällt. aber: wenn du sie provisioniert bekommst, behalt sie gern und schick mir deine ...

 

[PeterPawn]

Beim nochmaligen Lesen ist mir noch etwas aufgefallen ... um die Box im Bootloader zu halten, reicht bereits ein einfacher Verbindungsaufbau, es braucht gar kein Login für den FTP-Server. Wer das also unter Linux macht, kann auch

echo quit | nc 192.168.178.1 21

verwenden.

 

[koyaanisqatsi]

Und unter Windows: telnet 192.168.178.1 21
...aber das Kabel sollte nicht in Lan1 stecken.

 

[PeterPawn]

@tetzlav:
Die beiden Shell-Fehler beim Aufruf von /var/post_install sind normal, die treten auch bei der originalen AVM-Version auf. Aus irgendeinem obskuren Grund sind wohl einige Variablen bei diesem Aufruf im Environment nicht gesetzt (u.a. CONFIG_PLUGINV2_WLAN und HWRevision) und das gibt dann in der rc.wlan beim Testen, auf welchen Core das WLAN läuft und ob ein Plugin gebraucht wird, den gezeigten Fehler.

Ich habe den Verdacht, daß da vom "init" irgendetwas im Environment bereinigt wird oder auch, daß der Aufruf des "reboot", was dann erst das "init" anstößt, mit so einem eingeschränkten Environment erfolgt. Hat mich bisher nicht weiter interessiert - will man es untersuchen, muß man halt mal das Environment ausgeben lassen und vielleicht auch mal den Prozessbaum, damit man einer Vererbung auf die Spur kommen kann.

Wobei so ein "klinisch reines" Environment dann auch dazu führen könnte oder sogar müßte, daß andere Variablen nicht gesetzt sind - z.B. die für die Prüfung des Brandings benötigte "OEM"-Angabe. Aber ich habe damit bisher eigentlich nie Probleme gehabt und auf anderen Modellen (wo diese Abfragen in der rc.wlan ja auch existieren) sind mir diese Ausgaben nicht aufgefallen - das muß irgendein Spezialfall bei der 6490 sein, vielleicht ist es auch der verwendeten BusyBox und irgendwelchen Optionen bei deren Build geschuldet.

Im Anschluß sieht man dann ja absolut nichts - der Mediaserver kann es nicht sein (der läuft auf dem x86-Core und damit taucht der im "ps" nicht auf) ... aber wenn da schon die Anzeige aus der Zeile

echo "unmounting '/var/media/ftp/*' .."

nicht mehr erscheint und auch keine "Warnung" aus den zwei davorstehenden "for"-Schleifen zur Identifikation von Prozessen, die noch auf /var/media/ftp zugreifen, muß er ja irgendwo dazwischen hängen und das nächste Kommando wäre ein schlichtes "ps", gefolgt von einem "grep".

Nur dann, wenn der Prozess sich quasi selbst als einen identifiziert, der noch auf /var/media/ftp zugreift (was nach dem "exec" eigentlich nicht mehr der Fall sein dürfte) und sich selbst abschießt (falls das überhaupt klappt und nicht am Ende ohnehin "init" zum Neustart treibt, weil das als das Ende der Abarbeitung der post_install gesehen wird), dann wäre so ein Hängenbleiben bei den "for"-Schleifen denkbar - wobei die ja noch gar kein "kill" enthalten und eigentlich nur die fraglichen Prozesse auflisten.

Das ist also schon etwas mysteriös ... aber ich habe es selbst eben nie auf der 6490 bis in alle Einzelheiten getestet. Erklären kann ich es mir trotzdem nicht ...

- - - Aktualisiert - - -

@koy:
Im Bootloader ist das egal, da sind (auch bei der 6490) alle Anschlüsse gleichberechtigt.

 

[Pokemon20021]

3.) provideradditive.tar erstellen oder meine nehmen

1. 1. cd /tmp
   2. touch provider_additive_enables_post_install.txt (ist nur ein Platzhalter um ein tar-file zu erstellen und könnte später auch wieder raus)
   3. tar cvf /tmp/provideradditive.tar ./provider_additive_enables_post_install.txt
   4. ln -s /var symlink_to_var
   5. tar --append -f /tmp/provideradditive.tar symlink_to_var
   6. rm symlink_to_var
      
   7. mkdir symlink_to_var
      
   8. cp /<pfad_zur_modifizierten>/post_install ./symlink_to_var/post_install
      1. original post_install
      2. notwendige Modifizierung
   9. chown 0:0 ./symlink/post_install
      
   10. chmod 755 ./symlink/post_install
       

Hallo tetzlav,
vorab Danke fürs Evaluieren und Dokumentieren!

ich denke bei 3.9/3.10 liegt ein Tippfehler vor
9.) chown 0:0 ./symlink_to_var/post_install
10.) chmod 755 ./symlink_to_var/post_install

Gruß
Pokemon20021

 

[koyaanisqatsi]

@PeterPawn: Das dachte ich auch mal, zumindest an einer 7560 hab ich es auf "Teufelkommraus" nicht geschafft, an Lan1.
Erst das Umstecken auf Lan2 brachte das begehrte adam2 Prompt.
...hatte sie aber auch mal im Routermodus über Lan1 konfiguriert.
Das könnte der Knackpunkt gewesen sein.

 

[Pokemon20021]

/var/install [4042]: +++++++++++++ ARM Calling additional procedure (ewnw_check_install)
/var/docsiscertdefaults: Kein CM Zertifikat im Urlader
...
/var/install [4042]: +++++++++++++ UPDATE SUCCESS

Bedeutet das, dass hier die CM Zertifikate erfolgreich Online upgedatet wurden
oder waren da schon neue Zerts in /nvram/1/security/download ?

 

[tetzlav]

ich denke bei 3.9/3.10 liegt ein Tippfehler vor
9.) chown 0:0 ./symlink_to_var/post_install
10.) chmod 755 ./symlink_to_var/post_install

Jupp, hab ich geändert. Danke.

- - - Aktualisiert - - -

Bedeutet das, dass hier die CM Zertifikate erfolgreich Online upgedatet wurden
oder waren da schon neue Zerts in /nvram/1/security/download ?

Nein, die Box hatte schon die neuen Zertifikate und während des Updates auch kein (Inter-)netz.

 

[Pokemon20021]

@tetzlav:
eigentlich sollte sich "3. provideradditive.tar erstellen" wie folgt vereinfachen lassen:

1. cd /tmp
2. ln -s /var symlink_to_var
3. cp /<pfad_zur_modifizierten>/post_install ./symlink_to_var/post_install
        original post_install
        notwendige Modifizierung 
4. chown 0:0 ./symlink_to_var/post_install
5. chmod 755 ./symlink_to_var/post_install
6. tar cvf /tmp/provideradditive.tar symlink_to_var/post_install
7. zlib-flate -compress < /tmp/provideradditive.tar > /tmp/provideradditive.zlib (sollte auch irgendwie mit openssl zlib möglich sein)
8. cp /tmp/provideradditive.zlip /tmp/tffs_dump/tffs_1/001d.bin

 

[koyaanisqatsi]

@tetzlav: Mein Beileid zur "braunweißen" 6490 hier aus dem IPPF-Flohmarkt

 

[PeterPawn]

@koy:
OK, 7560 und 7580 nehme ich aus von meiner Behauptung ... die mögen irgendwo noch einen "Konfigurationsspeicher" haben und das wäre - gerade für Boxen, die an LAN4 ein Gastnetz bereitstellen können - auch dringend notwendig; vielleicht ist AVM da tatsächlich tätig geworden und es war nicht nur das "Überbleibsel" der letzten Switch-Konfiguration nach einem Neustart (wobei auch das m.W. neu wäre, wenn die Switch-Konfiguration einen Neustart (ohne Power-Switch) überlebt).

Wenn das Festhalten im Bootloader auch von diesem Gast-LAN-Port aus funktioniert und im Bootloader alle Ports (vermutlich über die Crossbar des internen Switches) erreichbar sind, dann kann nämlich auch ein bösartiger Gast die Box beim Neustart anhalten und hat dann über den Switch den Zugang zu den anderen Ports (immerhin nicht zum WLAN, weil das auch noch nicht zur Verfügung steht) und daran angeschlossenen Geräten.

Bei der 6490 geht aber meines Wissens noch jeder beliebige und bei einigen Boxen gab (ob "gibt" richtig wäre, schaue ich jetzt nicht nach) es sogar mal die Empfehlung, für die Verwendung des Recovery-Programms unbedingt den Port mit der Beschriftung "LAN1" in Betracht zu ziehen.

Ohne einen solchen zusätzlichen Konfigurationsspeicher müßte (zumindest nach "Strom weg") der interne Switch in einer Standardkonfiguration starten ... was man im FRITZ!OS eingestellt hat oder hatte, spielt zu diesem Zeitpunkt noch keine Rolle - der Bootloader selbst konfiguriert den Switch (oder startet ihn zumindest).

---

-@Pokemon20021:
Das läßt sich tatsächlich vereinfachen, aber nicht so weit. Der Symlink muß schon explizit auch "eingepackt" werden, aber da wird dann - zumindest beim BusyBox-tar, was ich dafür immer verwende - auch nur der Symlink selbst und nicht das Verzeichnis, wohin er zeigt, einbezogen. Man kann das also wirklich mit einem einzelnen "tar"-Aufruf machen (das BB-tar kennt ohnehin kein "--append") - aber solche "Optimierungen" sind vielleicht auch nicht notwendig. Meine Überlegungen zur Vereinfachung resultierten mehr daraus, daß da erst noch jede Menge zusätzliche Informationen beschafft werden müssen, die gar nicht benötigt werden oder bereits im TFFS-Image aus den Support-Daten stehen. Das ursprüngliche Skript zum Erstellen eines eigenen TFFS-Images ist auch älter als die Möglichkeit, über die "erweiterten" Support-Daten ohne Probleme an einen Dump der TFFS-Partitionen zu gelangen - das ist nur später erst ins GitHub-Repo gewandert.

Allerdings könnte es sich als nicht so einfach erweisen, das erwähnte "zlib-flate" zu finden ... das ist kein Standardprogramm in Linux-Distributionen und m.W. nur im "qpdf"-Paket enthalten. Da ist dann OpenSSL doch weiter verbreitet (das soll sich sogar schon bis zum Windows herumgesprochen haben) und dessen Verwendung ist auch ziemlich simpel:

openssl zlib [ -d | -e ] <input_file >output_file

"-e" komprimiert (aber ohne den Header, den "gzip" hinzufügen würde und den man dann erst wieder entfernen müßte) und "-d" dekomprimiert die Eingabedatei - hier braucht man also "-e" als Option. Höchstens eine OpenSSL-CLI-Version ohne diese "zlib"-Unterstützung (je nachdem, wer die Version erstellt hat und mit welchen Optionen) könnte noch existieren ... iirc ist die Integration von "zlib" als Algorithmus für das "enc"-Kommando (das sich hinter der Kurzform mit "zlib" verbirgt) optional. Das läßt sich aber durch den Aufruf "openssl list-cipher-commands" prüfen, wenn die Liste "zlib" enthält, ist es auch verfügbar.

- - - Aktualisiert - - -

Ich habe mal ein Skript eingecheckt, das die Idee mit dem Zusammenfassen einiger Schritte umsetzt (schließlich gibt es jetzt die erweiterten Supportdaten und das macht einiges leichter) - nicht in erster Linie für die 6490, aber es sollte auch dafür funktionieren.

Das Skript nimmt als Parameter den Namen einer Support-Datei und dann (optional) Paare aus Node-Nummer und Dateiname entgegen und gibt das Ergebnis nach STDOUT aus. Dabei wird automatisch das jüngere der beiden TFFS-Images aus der Datei extrahiert, im Standardfall die Segment-ID um 16 verringert und dann das Ergebnis (ein TFFS-Image) ausgegeben. Sind noch zusätzliche Paare aus Node-Nummer und Dateinamen beim Aufruf angegeben, werden die Dateien mit OpenSSL komprimiert und unter der Node-Nummer ins Image geschrieben - solange ausreichend Platz zur Verfügung steht.

Das ist nicht in allen Einzelheiten durchgetestet ... man sollte also zumindest am Beginn vor der Verwendung des erzeugten Images erst noch einmal "dissect_tffs_image" darauf loslassen und dann die extrahierten Dateien (zumindest bei denen, die man hinzufügen wollte) mit den originalen Eingabedaten abgleichen.

Stimmt das so halbwegs überein, reicht es eben aus, das erzeugte Image in die MTD-Partition der Wahl zu schreiben - s.o. - und dabei zu berücksichtigen, daß man nur eine der beiden wirklich schreiben muß. Welche man nimmt, ist reine Geschmackssache.

Aber dieses neue Skript kann dann auch viele Schritte der Liste von @tetzlav ersetzen - man braucht außer der Support-Datei und dem hinzuzufügenden Inhalt keine weiteren Dateien zusammensuchen.

 

[tetzlav]

[...]
Allerdings könnte es sich als nicht so einfach erweisen, das erwähnte "zlib-flate" zu finden ... das ist kein Standardprogramm in Linux-Distributionen und m.W. nur im "qpdf"-Paket enthalten. Da ist dann OpenSSL doch weiter verbreitet (das soll sich sogar schon bis zum Windows herumgesprochen haben) und dessen Verwendung ist auch ziemlich simpel:

openssl zlib [ -d | -e ] <input_file >output_file

[...]

Ich habe mal ein Skript eingecheckt, das die Idee mit dem Zusammenfassen einiger Schritte umsetzt (schließlich gibt es jetzt die erweiterten Supportdaten und das macht einiges leichter) - nicht in erster Linie für die 6490, aber es sollte auch dafür funktionieren.

Danke @PeterPawn, das würde den Hack sehr stark vereinfachen. Leider verwendet das script openssl zlib und der zlib-support wurde bei RedHat und Debian/Ubuntu leider komplett deaktiviert um CVE-2012-4929 zu fixen.

tetzlav@T410s:~/Downloads/YourFritz/tffs$ ldd $(which openssl) | grep zlib
tetzlav@T410s:~/Downloads/YourFritz/tffs$

Und gerade die Linux-Lerner und Anwender der Anleitung werden vermutlich ein Debian-Derivat einsetzen... :/

Kannst du da nicht alternativ zlib-flate einbauen?

#######################################################################################
#                                                                                     #
# check openssl utility                                                               #
#                                                                                     #
#######################################################################################
if ! command -v openssl 2>/dev/null 1>&2; then
        printf "Unable to find an executable called 'openssl'.\n" 1>&2
        exit 2
fi
if ! [ "$(echo | openssl zlib -e | dd bs=2 count=1 2>/dev/null | yf_bin2hex)" = 789c ]; then
        # 78 - deflate with 32K window (RFC 1950) has to be the first byte
        # 9c - default level (2), no dictionary preload, check bits
        printf "Unexpected result checking OpenSSL compression with zlib algorithm.\n" 1>&2
        exit 1
fi

#######################################################################################
#                                                                                     #
# add specified files                                                                 #
#                                                                                     #
#######################################################################################
i=0
payload="$(yf_mktemp -p "$tmp")"
header="$(yf_mktemp -p "$tmp")"
while [ $i -lt $add_files_count ]; do
        i=$(( i + 1 ))
        eval fn=\"\${add_file_name_$i}\"
        eval id=\${add_file_node_$i}
        openssl zlib -e <"$fn" >"$payload"
        packed_size=$(stat -c %s "$payload")
        needed_size=$(( ( packed_size + 4 + 3 ) & ~3 ))
        if [ $needed_size -gt $rem_size ]; then
                printf "Not enough free space to add file '%s' as node '%d'.\n" $fn $id
                exit 1
        fi
        yf_pack B16 $id B16 $packed_size >"$header"
        cat "$header" "$payload" | dd bs=4 conv=sync 2>/dev/null | dd bs=4 of="$image" seek=$(( offset / 4 )) count=$(( needed_size / 4 )) conv=notrunc 2>/dev/null
        offset=$(( offset + needed_size ))
        rem_size=$(( rem_size - needed_size ))
done

 

[PeterPawn]

@tetzlav:
Mit "zlib-flate" funktioniert es dann wieder bei anderen Distributionen nicht richtig, die kein "qpdf" nachinstallierbar bereitstellen. Das Übersetzen dieses Paketes für die eigene Distribution ist dann sicherlich für manchen noch schlechter, ich kenne auch Linux-Benutzer, die tatsächlich keinen "gcc" installiert haben.

Aber es sollte sich ja auch aus der Ausgabe von "gzip" "herauspopeln" lassen (beim Entpacken in "dissect_ttfs_image" nehme ich ja auch "gunzip" und füge halt vorher einen Header hinzu) ... ich schaue es mir mal an, das sollte umgekehrt auch problemlos klappen.

Ansonsten ist so ein "filter" für die Kommandozeile als C-Programm auch schnell erstellt - auch bei den Distros, die "qpdf" anbieten, würde ich das Nachinstallieren des kompletten Paketes eher für unnötig ansehen. Solange da Perl/PHP/Python installiert ist, kann man fast immer mit einem Einzeiler auch eine solche Kompression erhalten - bei mir funktioniert das halt wieder auf der Box selbst und da steht i.d.R. "openssl" zwar nicht in "stock firmware" zur Verfügung, aber gehört zu den ersten Programmen, die ich nachinstalliere (und auch für MIPS im "modfs"-Repo bereitstelle) ... normalerweise auch nur als statisch gelinktes Binary und nicht in Form der Libraries, so daß der alte CVE da keine Rolle spielt, solange man nicht "s_server/s_client" verwendet. Da sieht es dann eher mit den anderen Interpreter-Sprachen wieder schlecht aus.

Da ich normalerweise Ubuntu/Debian meide, war mir zwar irgendetwas in Erinnerung (daher die "Einschränkung" und der Verweis, wie man die "zlib"-Unterstützung im CLI-Programm prüfen kann), aber nicht so konkret, daß es wg. der CRIME-Attacke geschah. Wenn hier der HTTP-Server seinerseits die (TLS1.2-)Kompression verweigert, ist das ja auch ausreichend ... da jetzt im OpenSSL die zlib-Unterstützung komplett zu entfernen, finde ich über das Ziel hinausgeschossen von den Maintainern. Aber nun sind ja für Server-Pakete und das OpenSSL-Paket in einer Distro selten dieselben Leute zuständig und ehe man sich auf andere verläßt, macht man es halt selbst - nur für diejenigen, die tatsächlich OpenSSL auf der Kommandozeile benutzen wollen als Dienstprogramm ist das dann eben "Pech gehabt".

Mal schauen, was mit "gzip" geht ...

- - - Aktualisiert - - -

Ich habe mal eine neue Version mit "gzip" eingecheckt ... der Payload sieht etwas anders aus, nach dem "inflate" stimmen die Daten aber mit den ursprünglichen überein.

Ich habe das allerdings nur an den aus dem Image extrahierten Daten getestet (und dabei mit anderen Utilities entpackt) und nicht mit einem in die Box übertragenen TFFS-Image und dem dortigen TFFS(2)-Treiber der 6490 - erst recht nicht mit dem Treiber auf dem x86-Core, der ja noch die Endianess der ganzen Integer-Werte berücksichtigen muß (das TFFS-Image bei der 6490 verwendet das BE-Schema).

Ich gehe aber davon aus, daß auch der andere komprimierte Inhalt plattformübergreifend kompatibel ist - ist schließlich ein standardisierter Algorithmus und die zlib-Implementierung ist vermutlich ohnehin dieselbe.

 

[tetzlav]

@PeterPawn:
ich hab mal eine solche "Filterweiche" dafür eingebaut, damit funktionierts bei mir mit zlib-flate und openssl

--- tffs_add_file.orig  2016-11-03 16:31:45.822227665 +0100
+++ tffs_add_file       2016-11-03 19:16:10.314930199 +0100
@@ -107,14 +107,26 @@
 # check openssl utility                                                               #
 #                                                                                     #
 #######################################################################################
-if ! command -v openssl 2>/dev/null 1>&2; then
-       printf "Unable to find an executable called 'openssl'.\n" 1>&2
-       exit 2
+zlibcmd=""
+if ! command -v zlib-flate 2>/dev/null 1>&2; then
+       printf "Unable to find an executable called 'zlib-flate'.\n" 1>&2
+else
+       printf "Use 'zlib-flate' for compression.\n" 1>&2
+       zlibcmd="zlib-flate -compress"
+fi
+if [ "$zlibcmd" == "" ]; then
+       if ! command -v openssl 2>/dev/null 1>&2; then
+               printf "Unable to find an executable called 'openssl'.\n" 1>&2
+               exit 2
+       else
+               printf "Use 'openssl' for compression.\n" 1>&2
+               zlibcmd="openssl zlib -e"
+       fi
 fi
-if ! [ "$(echo | openssl zlib -e | dd bs=2 count=1 2>/dev/null | yf_bin2hex)" = 789c ]; then
+if ! [ "$(echo | $zlibcmd | dd bs=2 count=1 2>/dev/null | yf_bin2hex)" = 789c ]; then
        # 78 - deflate with 32K window (RFC 1950) has to be the first byte
        # 9c - default level (2), no dictionary preload, check bits
-       printf "Unexpected result checking OpenSSL compression with zlib algorithm.\n" 1>&2
+       printf "Unexpected result checking compression with zlib algorithm.\n" 1>&2
        exit 1
 fi
 #######################################################################################
@@ -218,7 +230,7 @@
        i=$(( i + 1 ))
        eval fn=\"\${add_file_name_$i}\"
        eval id=\${add_file_node_$i}
-       openssl zlib -e <"$fn" >"$payload"
+       $zlibcmd <"$fn" >"$payload"
        packed_size=$(stat -c %s "$payload")
        needed_size=$(( ( packed_size + 4 + 3 ) & ~3 ))
        if [ $needed_size -gt $rem_size ]; then

PS: du solltest evtl. in der Doku ergänzen, dass das script nach SDOUT schreibt. Hat mir erstmal schön mein Terminal zerschossen...

- - - Aktualisiert - - -

Achso, beim Zerlegen des erstellten tffs kommt noch:

$ ./dissect_tffs_dump < /tmp/mtd_new.img                                                                                                                           
unexpected duplicate entry found for id 0x001d

?

 

[TomTomNavigator]

Da ich normalerweise Ubuntu/Debian meide

OT: Darf man fragen welche Distribution du einsetzt?

 

[PeterPawn]

@TomTomNavigator:
openSuSE oder auch mal ein SLES - auch historischen Gründen (gab noch nicht so viele verschiedene Distributionen damals) und wegen größerer Nähe zum früher verwendeten SCO. Aber auch nur als "bevorzugt" ... ich nehme auch ein Ubuntu-Derivat, wenn es paßt. Auch bei mir läuft der Mediaplayer mit Kodibuntu - paßt einfach "out of the box" und da ist der Bedarf für eigene Anpassungen (des Systems) nahe Null.

@tetzlav:
Danke für den Hinweis, da muß noch die erste ID überschrieben werden, wenn der als Ausgangsmaterial verwendete Dump schon eine Datei mit derselben Node-Nummer enthält - sollte zumindest beim ersten Mal und beim Hinzufügen von "node 29" nicht auftreten, wird aber noch korrigiert.

Ich muß mir nur überlegen, wie man das am dümmsten macht. Das Ablaufen der Einträge in Shell-Code ist schon langsam genug (das ist der größte Teil der Laufzeit des Skripts und dabei sucht es im Moment nur nach dem Ende der vorhandenen Daten) und dann sollte man das für alle IDs wohl in einem Rutsch erledigen und nicht erst dann, wenn man neue Daten dafür einträgt. Das ist also nicht so ganz trivial umzusetzen ... bis dahin erst einmal nur "neue" Node-Nummern verwenden oder eben alte Images, wo die noch nicht enthalten sind.

- - - Aktualisiert - - -

@tetzlav:
Ich hoffe, nach der Umstellung auf "gzip" braucht es keine Weiche mehr?

Das mit der Ausgabe nach STDOUT hat eben den Vorteil, daß man keine Parameter/Dateinamen dafür übergeben (bzw. auswerten) muß ... ich baue noch eine Abfrage ein, daß STDOUT kein Terminal ist.

- - - Aktualisiert - - -

So, jetzt aber ... nun sollten auch keine doppelten Einträge mehr im neuen Image vorhanden sein.

 

[tetzlav]

[...] da muß noch die erste ID überschrieben werden, wenn der als Ausgangsmaterial verwendete Dump schon eine Datei mit derselben Node-Nummer enthält - sollte zumindest beim ersten Mal und beim Hinzufügen von "node 29" nicht auftreten, wird aber noch korrigiert.

Die bei dem Test verwendeten support-Daten waren aber noch von der Box ohne die provideradditive in Node 29...

Ich muß mir nur überlegen, wie man das am dümmsten macht. Das Ablaufen der Einträge in Shell-Code ist schon langsam genug

Ach naja, das geht jetzt schon wesentlich schneller als das build_tffs_image mit den einzelnen Nodes. Das hat bei mir gestern schonmal 15-20min gedauert. Mach dir da nicht zu viel Arbeit...

@tetzlav:
Ich hoffe, nach der Umstellung auf "gzip" braucht es keine Weiche mehr?

Jupp, tut jetzt ohne Anpassungen. Danke.
Jetzt ist auch der duplicate entry weg.

$ ./dissect_tffs_dump < /tmp/mtd_new2.img                                                                                                                          
/tmp/tmp_1478203873_16054

- - - Aktualisiert - - -

In meiner "Anleitung" hab ich jetzt auch auf tffs_add_file verwiesen. Der Hack über die provideradditive ist ja jetzt fast schon DAU-sicher - fast schon ein bisschen schade...

- - - Aktualisiert - - -

@PeterPawn: Hab ich das richtig verstanden, dass das tffs_add_file auch gleich die Segment-ID ändert um vom System als aktuelleres tffs erkannt zu werden?