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

[Micha0815]

Vielen Dank @PeterPawn für Deine Bemühungen. Ich weiss nichtmehr genau, mit welcher modfs-Version und welchen FWs ich das wann mit avm und avme getestet hatte. Hier z.Zt. in AT reiste die 7490 von den Kanaren (dort als UMTS-Box) direkt mit zwei 6.80er Versionen avm und avme.
Mit der aktuellen modfs Version habe ich gestern einen halben Tag experimentiert, und nun scheint überhaupt nix mehr zu gehen?
Nachdem mir telnet abhanden kam, machte ich ein recovery 6.69-avm und spielte eine 06.80-42651 INTERN mit aktiviertem telnet auf. Sämtliche Versuche mit modfs eine deutsche oder internationale FW in der anderen fs-Partition zu starten scheitern kläglich. Egal welche GUI-Version 0.3. oder 0.4 ich bemühe. Da alles fehlerfrei durchläuft stehe ich etwas auf dem Schlauch, weshalb das Starten so rein garnicht mag? Kein GUI-Zugriff, LAN/WLAN tot. Ich werde per vpn schauen, mit welcher frühen 3er modfs-Version das noch lief.
LG
P.S.: Die 7490 ist eine rote mit SN F472, Subrev. 5 und hat mutmasslich noch keine Branding-Umsetzprobleme? Erstaunlich, dass eine unter int. FW gemachte *.export komplett abgelehnt wird zum selektiven Import einzelner Einstellungen.

 

[PeterPawn]

Was nimmst Du denn für das neu zu installierende System?

Ich hatte zumindest keinerlei Problem, bei meiner Test-7490 die 45818 auf die 45942 zu aktualisieren, mit praktisch komplettem Umfang an benutzten "modscripts":

+copy_binaries
+dectcmds.modscript
+edit_rcuser
-gui_boot_manager_v0.3
+gui_boot_manager_v0.4
+mod_custom
-mod_custom_images
+mod_default_show_mac
+mod_enable_telnet
+mod_mount_by_label
+mod_night
+mod_profile
+mod_rc_tail_sh
+mod_leddisplay
+mod_prefer_fonnumber_name
+mod_show_vpn_on_overview
+mod_show_name
+mod_swapoff
-template
-yourfritz_hooks

Damit gehe ich eigentlich davon aus, daß es nicht am "modfs" liegt, wenn da hinterher etwas nicht startet (ich denke auch, daß es dann schon mehrere Meldungen für die neuen Labor-Versionen gegeben hätte, denn es gibt auch Leute, die - wie ich selbst auch - diese Versionen nur noch über "modfs" installieren und dabei anpassen lassen) ... solange das ein "modfs"-Lauf mit Installation ist, sonst kann natürlich bei der Installation noch etwas schiefgehen.

Auch die Patches (inkl. dem für die automatische Anzeige von LAN-Clients mit der MAC-Adresse) funktionieren für diese Mesh-Versionen weiterhin - nur der LED-Patch und dessen Zukunft ist im Moment etwas unklar, weil ich hier erst einmal eine Release-Version abwarte. Zwar wird die Anzeige der Registerkarte ordentlich in das Menü hineingepatcht, aber die Änderung an der Seite, bei der das "verzögert aus" hinzugefügt werden soll, will nicht so richtig - warum, muß ich erst mal suchen.

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

Ansonsten ist das mit dem Import immer so eine Sache zwischen verschiedenen Versionen und Zweigen (Labor, Beta, international, usw.) ... am einfachsten ist es am Ende, entweder die Export-Datei komplett zu entschlüsseln und die Dateien direkt im System zu ersetzen (bei gestopptem "ctlmgr" und hier ausnahmsweise dann doch mal mit komplettem Neustart nach dem Ersetzen der Dateien, weil das sonst zu komplex wird, was da neu zu starten ist) oder man geht einfach hin und ändert in der Export-Datei die "Quellenangabe" (ob mit oder ohne Entschlüsselung ist Geschmackssache) und läßt die Prüfsumme korrigieren (das kann inzwischen mein "decoder"-Projekt alles auch außerhalb einer Box und sogar ohne eine solche erledigen), bevor man das der AVM-Firmware als "normalen Import" unterjubelt.

Das geht nur dann (auch lange nicht immer) schief, wenn da vollkommen neue und alter Firmware noch unbekannte Settings irgendwo herumstehen (oder zusätzliche Dateien enthalten sind - die Mesh-Versionen fügen z.B. weitere TFFS-Nodes hinzu). Da die Binärdateien allerdings nach meiner Beobachtung beim Import nicht geprüft werden (einige der Textdateien schon), kann sich ein Problem auch erst nach dem Neustart zeigen, falls da doch irgendwelche Binärdateien in der Export-Datei nicht kompatibel sind.

 

[koyaanisqatsi]

Moins

Kann dass eventuell mit dem Warmstart/Kaltstart Adam2/Eva Problemchen zu tun haben ?

BTW: Ich konnte bei meiner unmodifizierten 7560 nicht von einer Labor auf die andere Partition mit 6.53 INTERN switchen* und musste sie (6.53) leider aufgeben.

* Nach linux_fs_start Power LED dauerhaft an bis Neustart
(Alle LEDs kurz an, Power LED ohne blinken bis Neustart an)

 

[PeterPawn]

@koy:
Siehe auch hier und hier ... die Gründe kenne ich noch nicht.

Bei der 7490 habe ich das mit dem "Soft-Reboot" und anschließendem Problem, in den Bootloader zu kommen, aber noch nicht bemerkt (auch nicht bei der 7412) - da hat das immer reibungslos funktioniert (daher kommt ja auch die Warnung/meine Behauptung, daß ein Angreifer am LAN-Kabel beim Neustart den Router übernehmen könn(t)e).

 

[stoney]

@PeterPawn hast du schon "Daten" diesbezüglich zu einer 7490 mit Seriennummer J095? (Infos kommen heute noch)

Dazu könnte man doch einen extra Thread aufmachen wo man mal alles sammelt ?

 

[PeterPawn]

Ich hatte bisher auch noch keinen bestätigten(!) Fall einer 7490, bei der sich das Branding nicht mehr ändern ließ (ich nehme mal an, daß Du darauf hinauswillst).

Ich will auch definitiv niemandem etwas unterstellen ... aber bei den bisher zu lesenden Berichten konnte es sich m.E. immer noch um Fehlbedienungen handeln, weil deren Autoren nicht ganz so geübt waren an dieser Stelle. Andererseits habe ich mich schon oft genug selbst gewundert, weil ich einen (unbemerkten) Fehler in so einer Prozedur hatte - gestern erst wieder beim Recovery einer 7580, wo die W10-Firewall nur für "öffentliches Netzwerk" geöffnet wurde und ich die Antworten der Box im Wireshark sah, während das Programm weiterhin tapfer behauptete, es fände keine Box.

Daher bin ich eben erst einmal skeptisch (auch meine eigenen Feststellungen versuche ich immer wieder zu reproduzieren) und vielleicht habe ich auch nicht jeden Erfahrungsbericht in dieser Richtung gelesen (schon gar nicht außerhalb des IPPF).

Ich bin also weder restlos überzeugt davon, daß AVM dort etwas geändert hat (wohlgemerkt, ich rede hier nur von der 7490) noch bin ich restlos davon überzeugt, daß da ein paar Leute (m.E. waren es bisher nur zwei) selbst schuld waren am Nichtfunktionieren des "Entbrandens".

Bei den GRX-Modellen ist das ja unmittelbar mit dem Umstieg auf die Hardware-Beschreibung in Form des FDT verbunden (da gibt es dann im "chosen"-Zweig auch das Environment) ... dort wird dann der Kernel direkt vom Bootloader mit diesen Daten versorgt, während das bei den VR9-Modellen (m.W. auch bei allen) noch über "avm_kernel_config" mit den verschiedenen Beschreibungen für unterschiedliche "HWSubRevision"-Werte erfolgt und das Environment aus dem TFFS geladen wird.

Insofern frage ich mich natürlich, warum AVM das bei neueren 7490 nun auch umgestellt haben sollte (und dann, warum das nur bei der 7490 so sein sollte und nicht bei allen VR9-Boxen mit neuerem Produktionsdatum).

 

[stoney]

Ich bezog mich darauf (Im Gedanken an die 7580)

Bei der 7490 habe ich das mit dem "Soft-Reboot" und anschließendem Problem, in den Bootloader zu kommen, aber noch nicht bemerkt

Hier auf jeden Fall die Daten (allerdings war der Zugriff immer möglich)

3.10.73
DMC   9.00.205.537/3000
HWRevision   185
HWSubRevision   6
ProductID   Fritz_Box_HW185
SerialNumber   J095
bootloaderVersion   1.3179
urlader-version   4179

Mein Weg die Boxen anzuhalten (Ubuntu)

-Kaltstart-
YourFritz-master/eva_tools$ ./eva_discover INTERFACE=enp0s10 FROM=192.168.178.2 TO=192.168.178.1 BLIP=1 WAIT=120 HOLD=1;
EVA_FOUND=1
EVA_IP=192.168.178.1
boot sequence interrupted
-Neustart per GUI-
YourFritz-master/eva_tools$ ./eva_discover INTERFACE=enp0s10 FROM=192.168.178.2 TO=192.168.178.1 BLIP=1 WAIT=120 HOLD=1;
EVA_FOUND=1
EVA_IP=192.168.178.1
boot sequence interrupted

 

[Micha0815]

Was nimmst Du denn für das neu zu installierende System?

Zusätzlich zu den angebotenen, testweise auch die busybox aus modfs.tgz.

Damit gehe ich eigentlich davon aus, daß es nicht am "modfs" liegt, wenn da hinterher etwas nicht startet (ich denke auch, daß es dann schon mehrere Meldungen für die neuen Labor-Versionen gegeben hätte, denn es gibt auch Leute, die - wie ich selbst auch - diese Versionen nur noch über "modfs" installieren und dabei anpassen lassen) ... solange das ein "modfs"-Lauf mit Installation ist, sonst kann natürlich bei der Installation noch etwas schiefgehen.

Ich selbst hatte bisher kaum (eigentlich fast nie) Probleme beim Aufspielen div. Labore und Releases, sofern es sich um die DE-Versionen handelt. Hier bei meiner Freundin in AT läuft die AT-CH-Version mit Annex A störungsfrei, während die DE-Version zuviele CRC-Fehler bei Annex B erzeugt und ich unter Störsicherheit den INP um 1 Raste nach links setzen muss. (OT: Unter Annex B reagiert dieses Störsicherheits-Menue sehr empfindlich auf Veränderungen, sodass z.T. überhaupt kein Sync zustande kommt)

...
Ansonsten ist das mit dem Import immer so eine Sache zwischen verschiedenen Versionen und Zweigen (Labor, Beta, international, usw.) ...

Dessen bin ich mir bewusst, nur hatte ich vormals selektiv (DSL-Kennung und ein/zwei Rufnummern) aus einer AVM-Export importiert, wobei die *.export zum einen aus einer internationalen/avme-FW stammte und/oder einer DE/avm-Version.

Da mein AT-Aufenthalt morgen endet, werde ich wohl modfs streichen müssen. Ich zumindest schaffe es nicht, zwischen einer FW 6.83-AT-CH und einer DE-Version direkt zu switchen. In DE werde ich mich mal nach einer Reserve-7490 umschauen, um das ganze entspannter ohne Zeitdruck auf nicht-produktiv-Hardware zu testen.
LG

 

[Pokemon20021]

Zusätzlich zu den angebotenen, testweise auch die busybox aus modfs.tgz.

folgende Inputs wären hilfreich:

1.) Inhalt des modscripts "copy_busybox" bzw. "mod_replace_busybox"

2.) modfs debug outputs
a.) die Umgebungsvariable MODFS_DEBUG_SHELL=1 setzen und dann modfs starten;
anschließend Inhalt von /var/tmp/modfs_debug_shell.log als Attachement beifügen
b.) Protokolldatei "showshringbuf modfs" erstellen und ebenfalls beifügen.

Bitte auch mal testweise modfs ohne das modscript "copy_busybox" bzw. "mod_replace_busybox" durchführen,
und prüfen, ob dann die Fritzbox funktioniert.

 

[Micha0815]

Mit dem script für die busybox kann ich dienen @Pokemon20021

# MODFS_MODSCRIPT
# SUPPORTS precheck postcheck install language(en,de)
# NAME replace busybox
# DESCRIPTION en
# change busybox         
# DESCRIPTION de
# tausche busybox
# EOH
#
# process parameters
#
language=$1
rootdir=$2
mode=$3
step=$4
[ $4 == install ] && cp -a bin/VR9/busybox $2/bin/busybox
rc=0

Wie erwähnt läuft das script ja unter div. Variationen der subscripts fehlerfrei durch. Mit jeweils 2 DE Firmwaren alles paletti. Nur wenn in einer Partition eine Internationale per modfs hineingeschoben wird und der Neustart per linux_fs_start angeschoben wird - ob letztendlich durch Stromsteckerziehen oder reboot in der Konsole wohl wurst- kommt die FB nur halbtot hoch.
Kein LAN-Zugriff auf die GUI, obschon intern die DSL-Verbindung wohl steht und bei fixer IP-Zuweisung am Client 192.168.178.2 Gateway 192.168.178.1 funktioniert das browsen im I-Net, wenn zuvor in adam2 via
quote SETENV firmware_version avme
das Branding umgesetzt wurde.

Für weitere Tests geht mir die Zeit aus. Nur bin ich mir ziemlich sicher, dass dies mit einem Pärchen älterer Firmware e.g. 6.30/6.50international (die Nomenklatur der internationalen Versionen wurde erst ab Version 6.80 bzw. 6.83 der Deutschen Version angeglichen) und 6.80/6.69deutsch schonmal ging. Ab welcher Version - ob die deutsche oder die internationale weiss ich nicht - das nun nicht mehr funktioniert, konnte ich nicht herausfinden. Das ständige Umsetzen der Netzwerkkarte, abschalten der Firewall und avast neben recoverys und adam2/ftp ist zeitaufwändig auf einer Produktiv-FB.
U.U. kann jmd. mit einer Reserve-FB modfs mit 2 unterschiedlichen FWs international/deutsch mal antesten und mich Lügen strafen.

LG

 

[PeterPawn]

@Micha0815:
Hast Du denn sicher die neueste Version des Bootmanagers integrieren lassen?

Der muß natürlich in jeder der beiden Partitionen der neue sein bzw. zumindest in der Partition, wo NICHT das System mit nur einem Branding installiert ist.

Eigentlich müßtest Du also zuerst von der internationalen aus eine neue deutsche Firmware mit dem korrigierten Bootmanager installieren (das Problem im Code trat ja nur dann auf, wenn das System, auf das umgeschaltet werden sollte, nur ein einzelnes (und auch noch abweichendes) Branding hatte) und dann ggf. noch aus der deutschen Version heraus eine neue internationale installieren.

Wobei letzteres dem Bootmanager auch wieder weitgehend egal wäre, wenn die deutsche Firmware wenigstens zwei Brandings enthält, denn dann kommt man auch nicht in den (ehemals) fehlerhaften Zweig (den ich ja dummerweise erst mit der Umstellung auf die POSIX-Syntax eingeführt hatte).

 

[Micha0815]

@Micha0815:
Hast Du denn sicher die neueste Version des Bootmanagers integrieren lassen?

Imho ja, da ich modfs nach Deinem gelöschten Beitrag neu geholt hatte vom github.

Der muß natürlich in jeder der beiden Partitionen der neue sein bzw. zumindest in der Partition, wo NICHT das System mit nur einem Branding installiert ist.

Ich musste mich zum ersten Mal über ein recovery von modfs trennen und schob als update eine inhouse-Version mit telnet auf die alternative Partition, wobei ich erstmal eine recovery raussuchen musste, die kleiner als die inhouse war. Mit dieser auf der "anderen" Partition dann gestartet, nachdem telnet via DECT-Phone, was auch erstmal eine registrierte Rufnummer benötigt für #96*7*, führte ich das aktuelle modfs und als Quelle die 6.83international aus mit div. Unterscripten.

Eigentlich müßtest Du also zuerst von der internationalen aus eine neue deutsche Firmware mit dem korrigierten Bootmanager installieren

Mir ist adhoc keine neuere internationale Version bekannt, die noch einfach aktivierbares telnet onboard hätte. Den Weg über modfs-starter wollte ich mir ersparen wobei ich nicht genau wüsste, welche internationale FW-Version dafür geeignet wäre?

U.U. hätte ich wirklich erstmal auf beiden Partitionen eine DE-Firmware mit modfs und dem gui-bootmanager ausführen sollen und/oder auf beiden Partitionen ein recovery

LG

 

[Virgus]

Hello PeterPawn and everybody,
I've got a new FB 7490 (bought in France) with already OS 6.83 installed. I've been trying to launch modfs.tgz for quite some time without success.

Last time I used it without problems I had OS 6.30 and used the telnet pseudo update but now all I tried failed:
- tried to downgrade to OS 6.52 successfully but still couldn't make the telnet pseudo update work.
- tried to downgrade to OS 6.31 (using the recovery image) and the downgrade is not accepted.

How can I be able to access this FB7490 even temporarily via SSH like I used to do with OS 6.30?
All I'd like is to install modfs and upgrade to latest OS before re-creating the scripts I used in my previous FB7490.

I'm sorry if this question has already been placed, I tried reading this thread since the posts made in march but it's not easy at all to follow the discussion with the help of online translators. Could any of you please point me to the correct steps to downgrade to OS 6.30 or to be able to launch the modfs script under OS versions greater than OS 6.50 ?

Thanks and have a nice week end,
V.

 

[Pokemon20021]

- tried to downgrade to OS 6.31 (using the recovery image) and the downgrade is not accepted.

What was the problem ?
could you please describe what you have done und what was the error message

 

[PeterPawn]

Get the original firmware for your device, extract the "filesystem.image" there, unpack this file (with an appropriate "unsquashfs" utility and you will need its counterpart - mksquashfs - soon) and make the needed additions to start a first telnet daemon instance (it's only a missing symlink from /usr/sbin/telnetd to /bin/busybox, which prevents the start of telnetd).

Afterwards pack the content of the whole directory ("squashfs-root" was the default destination, if you do not specify another one with the unpack command) to a new file system image and copy the "kernel.image" file from the original firmware file (shortened by 8 bytes, if its length isn't a multiple of 256), followed by your new file system image, into a new file.

Now you may use this combined file to start your 7490 from memory (the needed FTP commands can be found in the 'eva_to_memory' script from my YourFritz repository on GitHub) and the new firmware will write itself into the active partition set. Prior you could switch to the alternative one, if you want to keep the other system intact.

After the next reboot, the device will start from its flash storage again, but now the telnet daemon may be activated with the well-known key sequence #96*7* from any DECT or wired phone, connected to the box.

The principles of extracting (and reusing) Linux kernel images from AVM's firmware, are explained in some shell scripts from the YourFritz repository ... you may have a look into "toolbox" and "first_aid", even if there is not a new "ready-to-use image" for a ShellInABox implantation as "easy shell access".

Meanwhile AVM has fixed other possible threats (in the TR-069 code) and it's not worth the effort to explain a possible exploit there, if it's anyway sooner or later only "history" (and the end of 06.83 is in sight ... at least they say this).

The other, older versions you've tried, had various flaws, which could be used to invade a box ... but these opportunities were already explained: https://github.com/PeterPawn/YourFritz/tree/master/reported_threats

 

[Virgus]

Thank you so much PeterPawn, and Pokemon 20021 for your prompt answers!
I've installed an ubuntu OS to start experimenting with the unsquashfs/mksquashfs tools you wrote me about.

After all the setup I wanted to take a snapshot for Pokemon of the error message I had with the recovery to OS 6.31
and I just tried again the procedure from linux_fs_start 0 (OS 6.52) and this time it worked!

I'm quite surprised that I didn't get the message I already got several times previously: "Version successfully detected! Hardware: FRITZ!Box 7490 Bootstrap: 2984 Firmware: 113.08.52" and then "this version is too old" or something like that. Anyway I'm glad it worked and that I got all your explanations as I learned many new things.

Thanks again so much to both of you!
V.

BTW One little note to those who've had the hassle of Media Sensing: I avoided rebooting my XP before running the 06.31 recovery image by running the attached reg file to disable/enable Media Sensing. I'm not sure if this made any difference with my problem though...

 

[Micha0815]

For further investigation? Could You mention with which Branding (avm<->avme) You tried first 6.31recovery? Bought in France may be not worth for Knowledge about Branding? Some posts about newer FB7490 are hinting to some behavior of not capable to change branding avm->avme and viceversa. May be You or the Original-Seller/Owner have had got a update from 6.xx to 6.83 online as important Firmware-Update? Otherwise a FB7490 sold untouched with Firmware 6.83international should have a Serial Jxxx from this year?
LG+TX
Edited: Normaly a recovery is writing to actual linux_fs_start x partition. If one was written under avm-branding and the other after switching to avme the behavior may be explainable?

 

[KunterBunter]

Firmware: 113.08.52

You are far ahead in the future. Version 113.06.90 was just announced today.

 

[Micha0815]

Naja die Nomenklatur für die Internationalen differrierte vormals von den DE Versionen ohne erkennbares Muster. Z.T. gab es auch eher unbemerkte Labor-Versionen?

Zahlendreher 113.05.xx aussenvor? bevor ich hier anfange genauer zu recherchieren

 

[Virgus]

Hello everybody.

@KunterBunter you're right I mistyped the other day and didn't pay attention to the 8 in place of the 6! Here the snapshot I took the other day.

@Micha0815 I suppose this model came out with OS 6.50 and the previous owner updated it to OS 6.83 before selling it (he told me he changed his internet provider and had a fiber optics new box). The serial I see on the back is F211.509.00.055.248 and it is a 7490 AVM international edition.

As I got it I saw OS 6.83 but then got aware that the telnet pseudo firmware was not working anymore. I tried the recovery to OS 6.30/6.31 from OS 6.83 and it was refused. Then I recovered to OS 6.52 and it worked but I wasn't able to go back to OS 6.30. I cannot tell exactly why I didn't succeed in the first tries I made. I did it very late at night and was really tired. I tried on both partitions by the way.

Then you already know the story: I wrote here my questions, got Peter Pawn's instructions and Pokemon's questions and so I re-tried again to downgrade, this time successfully.

Please let me know if there's any other info that might be useful somehow.

Have a nice day!