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

[PeterPawn]

1. Die neue Labor-Reihe wird bisher nicht von mir unterstützt ... warum das so ist, steht weiter vorne in diesem Thread.

2. Das Protokoll wäre hilfreich - da kann man nämlich ersehen, welche Modifikationen vorgenommen wurden und welche Version des FRITZ!OS überhaupt verändert werden sollte. Wenn jemand tatsächlich mit identischen Änderungen an derselben Firmware auch dieselben Probleme hat (dazu muß man halt erst einmal wissen, ob die entstandenen Images auch gleich sein sollten), dann kann der- oder diejenige vielleicht helfen und selbst ein Dritter, der sich Deinem Problem widmen möchte, sollte schon genau wissen, wie Du zu dem nicht funktionierenden Image gelangt bist.

3. Deine Chancen, daß ich mich selbst mit dem Problem befasse, stehen allerdings eher schlecht (ich sag's gleich so deutlich) ... nicht nur, daß es eben bei mir bisher keinerlei Labor-Version aus der 06.98-Reihe im täglichen Einsatz gibt, kommt hier wohl noch die internationale Version erschwerend hinzu und die könnte noch alle möglichen anderen Probleme haben bzw. bereiten.

4. An der Übersichtsseite setzen jetzt nicht sooo viele Modifikationen an (ich wüßte im Moment tatsächlich nur zwei) ... die kann man auch alle auf einmal weglassen und dann eben Schritt für Schritt einbauen lassen, bis bei einer von ihnen dann das Problem auftritt. Auf diesem Weg kann man auch ohne tiefergehende Kenntnisse in Lua oder HTML/CSS die Ursache zumindest eingrenzen und ein Beheben (durch andere) auch erleichtern/unterstützen.

vidar:/home/GitHub/modfs # grep -r "+++.*TARGET_BRAND" modscripts/
modscripts/mod_show_name:+++ usr/www/$TARGET_BRANDING/content.lua
modscripts/mod_show_name:+++ usr/www/$TARGET_BRANDING/content.lua
modscripts/mod_show_name:+++ usr/www/$TARGET_BRANDING/content.lua
modscripts/mod_night:+++ usr/www/$TARGET_BRANDING/menus/menu_data.lua
modscripts/mod_night:+++ usr/www/$TARGET_BRANDING/menus/menu_data.lua
modscripts/mod_default_show_mac:+++ usr/www/$TARGET_BRANDING/net/net_overview.js
modscripts/mod_show_vpn_on_overview:+++ usr/www/$TARGET_BRANDING/home/home.lua
modscripts/mod_show_vpn_on_overview:+++ usr/www/$TARGET_BRANDING/home/home.lua
modscripts/mod_show_vpn_on_overview:+++ usr/www/$TARGET_BRANDING/home/home.lua
modscripts/mod_show_vpn_on_overview:+++ usr/www/$TARGET_BRANDING/home/home.lua
modscripts/mod_show_vpn_on_overview:+++ usr/www/$TARGET_BRANDING/home/home.js
modscripts/mod_show_vpn_on_overview:+++ usr/www/$TARGET_BRANDING/home/home.js
modscripts/mod_show_vpn_on_overview:+++ usr/www/$TARGET_BRANDING/home/home.js
modscripts/mod_leddisplay:+++ usr/www/$TARGET_BRANDING/menus/menu_data.lua
modscripts/mod_leddisplay:+++ usr/www/$TARGET_BRANDING/menus/menu_data.lua
modscripts/mod_leddisplay:+++ usr/www/$TARGET_BRANDING/system/led_display.lua

 

[MatuAC]

Hallo,
@PeterPawn : Falls du irgendwann einmal die neue Labor-Reihe unterstützen solltest, hier ein Hinweis zu einem Problem, den ich mit dieser Labor-Reihe und modfs habe:
Bei einem Update von einem vorherigen Labor-Stand auf den jeweils aktuellen stürzt bei mir die Fritz!Box 7490 IMMER beim Packen des neuen Firmware-Images ab...
Ich habe bereits verschiedene Varianten mit angewählten/abgewählten Mods ausprobiert, immer mit dem gleichen Ergebnis (dabei war der kleinste gemeinsame Nenner, zumindeste Telnet-Daemon und rc.user-Ausführung zu aktivieren).

Wenn ich zunächst auf die Partition mit der letzten offiziellen Version 6.93 wechsel, klappt es - wie von modfs gewohnt - problemlos.

Ein Log kann ich - wenn ich es richtig verstanden habe - nicht erstellen, da das nach einem Reboot wieder leer ist?! Zumindest ist es bei mir so...

Kennt ansonsten jemand dieses Problem bzw. eine Lösung, wie ich mir den Schritt zurück auf 6.93 (der jetzt allerdings auch nicht sonderlich aufwendig ist) zu umgehen?

 

[PeterPawn]

Die von "modfs" mitgebrachten Binärdateien sind zwar alle statisch gelinkt und könnten damit auch dann problemlos funktionieren, wenn eine andere C-Library zum Einsatz kommt, aber es ist eben auch ein anderer Kernel und selbst da kann es "Probleme" geben.

Wobei Du hier vielleicht erst einmal schauen solltest, ob Dir nicht mit etwas Swap-Space bereits geholfen wäre ... das klingt zunächst mal nach einem Problem mit dem verfügbaren Hauptspeicher. Das Packen mit LZMA-Kompression benötigt halt immer große Mengen an Speicher direkt beim Packen ... und AVM stellt die Boxen (sicherlich auch in den neuesten Labor-Versionen, auch wenn da die Abarbeitung der letzten Zuckungen von "init" beim Systemstart etwas abgeändert wurde) immer so ein, daß bei "memory pressure" gleich ein Reboot erfolgt (bzw. "panic" mit der Folge eines Reboots).

Man kann das auch probehalber mal abstellen ... allerdings führt das (ohne Swap-Space) dann noch nicht dazu, daß der Packvorgang auch erfolgreich abgeschlossen wird - dann wird nur anstelle des kompletten Systems der Verursacher einfach gekillt (bzw. es gibt noch weitere Einstellungen zur Strategie bei der Auswahl des abzuschießenden Prozesses). Dazu muß man nur vorher das Kommando

echo 0 > /proc/sys/vm/panic_on_oom

ausgeführt haben ... am besten liest man dazu aber vorher noch nach: https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Solange die neue Labor-Reihe diesen Status hat (eben "Labor") und AVM nicht die Quellen dafür veröffentlicht, wird das mit der Unterstützung aber auch nichts werden und das liegt nicht daran, daß ich nicht will ... welche Probleme dabei aus dem Weg zu räumen wären, habe ich irgendwo hier im Thread schon bei der ersten oder zweiten "inoffiziellen" Version aufgezählt.

 

[MatuAC]

[...] Wobei Du hier vielleicht erst einmal schauen solltest, ob Dir nicht mit etwas Swap-Space bereits geholfen wäre ... das klingt zunächst mal nach einem Problem mit dem verfügbaren Hauptspeicher. [...]

Wieder einmal vielen Dank für den Tipp, das Einrichten von Swap-Space hat geholfen!

 

[LaCruz]

Hi.
Habe selbige Problem. Zudem hatte ich eine 1&1 7490 von 6.30 auf aktuelle BETA heben wollen.
Hierbei hatte ich nach Neustart kein Telnet mehr. :-(

Jedoch auch Probleme mit 49953. Ich erhalte:
./modfs: Permission denied

318 2 drwxrwxr-x 1 root root 2048 Nov 19 08:35 locale
344 98 -rwxrwxr-x 1 root root 100324 Sep 19 23:13 modfs

Jemand Ideen?

Thanx LaCruz

NACHTRAG:
liegt es unter /var/mod/ funktioniert es noch.
:-(

 

[MatuAC]

Jedoch auch Probleme mit 49953. Ich erhalte:
./modfs: Permission denied

S. hier meinen Beitrag sowie die Antwort von PeterPawn:
https://www.ip-phone-forum.de/threa...ierte-fritz-boxen.273304/page-69#post-2266620

 

[LaCruz]

Besten Dank. Ich verstehe nicht warum sich AVM soviel Mühe gibt telnet/modfs etc zu verhindern.
*grrr*

 

[PeterPawn]

Machen sie ja gar nicht ... das hat schon seinen Sinn, wenn die Box von den Stellen, die per Dateizugriff erreichbar sind ("/var/media/ftp" und alle darunter liegenden Verzeichnisse/Mountpoints), keine ausführbaren Dateien akzeptiert. Das ist zwar noch kein umfassender Schutz (weil schon ein "sh modfs ..." wieder ohne "executable"-Rechte auskommt), aber einer, der praktisch "umsonst" zu haben ist und eben nicht nur für die Ausführung von "modfs" ein Problem darstellt (wobei das mit einem einzelnen "mount"-Kommando ja wieder behoben wäre - ansonsten funktioniert die "mitgelieferte" BusyBox nicht), sondern auch verhindern kann, daß irgendwelche dort abgelegten ausführbaren Dateien "eingeschleust" werden können, wenn es einem Angreifer gelingt, den Suchpfad in der "PATH"-Variablen irgendwie zu manipulieren.

Irgendwo hatten wir gerade das Thema "dsld" und von diesem aufgerufene Kommandos ... wenn ich das richtig in Erinnerung habe, ruft dieser Daemon von AVM z.B. das "tc"-Kommando zum Einrichten von QoS-Chains ohne explizite Pfadangabe auf (also nur als "tc -batch %s") und wenn jemand diesem Daemon einen Suchpfad mit "/var/media/ftp" als Bestandteil unterschiebt (vor dem richtigen Verzeichnis "sbin") und dann einfach per FTP dort eine ausführbare Datei mit dem Namen "tc" ablegt, dann würde diese Datei vom "dsld" aufgerufen ... schwupps, wäre der "Angreifer" im System (bei passendem Inhalt dieser Datei natürlich).

 

[LaCruz]

@PP: Danke für die Hintergrundinfos

 

[LaCruz]

Noch eine Frage. Habe eine zweite 7490 (1&1). Probiere von 6.50 mit modfs auf letzte Offizielle upzudaten. Nach Neustart ist 6.93 drauf, jedoch telnet nicht verfügbar? Einen Tipp für mich? (über modfs wurde telnetd mit 'j' ausgewählt)

 

[Micha0815]

#96*7* probiert? Per Pikachu`s Wählhilfetool oder angeschlossenem Telefon?
LG

 

[LaCruz]

@Micha0815: Danke! Solange her bei der ersten Box :-D

 

[PeterPawn]

Ich will noch mal kurz darauf hinweisen, daß ich (zumindest für die 7412 und 7490 - für andere Modelle kann man sich das aber ganz leicht selbst erstellen) auch ein komplettes "in-memory"-Image bereitgestellt habe, mit dem man eine FRITZ!Box (mit VR9-Prozessor und Wrapper-FS - also praktisch alles, was von "modfs" auch unterstützt wird) nur einmal booten lassen muß, damit auch dort wieder ein "Shell-in-a-Box"-Service installiert wird.

Dieses Image kann man (für weitere VR9-Modelle) ganz einfach selbst in irgendeiner Linux-Umgebung (die über die notwendigen Kommandos verfügt, bei einer FRITZ!Box muß man das sehr genau überprüfen, weil schon ein Git-Checkout zur Herausforderung wird, sofern man kein Git-Paket installiert hat) erstellen lassen ... man braucht nur eine Kopie vom YourFritz-Repository bei GitHub und irgendeine passende Firmware (mit 3.10-Kernel) für das entsprechende Modell, aus dem sich das Skript dann den Kernel holen kann.

Das Extrahieren des Kernels aus der AVM-Firmware (und damit der Verzicht auf ein wirklich generisches Image für diesen Anwendungsfall) ist leider notwendig, weil so ein Kernel von AVM die Beschreibung der jeweiligen Hardware der Boxen enthält und AVM die Vorlagen für diese Dateien (bzw. zum Einbetten dieser Dateien in den Kernel) nicht in das Paket mit den Quelltexten aufgenommen hat. Da man dann ohnehin diesen Kernel bräuchte, um die zum Gerät passenden Angaben aus dem Kernel zu extrahieren, wenn man einen eigenen bauen wollte, kann man auch gleich den AVM-Kernel verwenden ... zumal der hier ohnehin nur als Vehikel für den Zugriff auf das YAFFS2-Dateisystem in der "wrapper"-Partition dient.

Ich wollte das nur noch einmal ausdrücklich auch hier festhalten, weil ich immer wieder etwas von Downgrades auf 06.50 lese (so auch in #1450, wenn ich es richtig verstanden habe), damit man dann mit "modfs" weitermachen kann ... das ist ziemlich unnötig. Zumal ich das auch noch so verstehe, daß dann in dieser 06.50 ja wieder "modfs-Starter" in Form des unsignierten Update-Images zum Einsatz kommt ... denn einen Telnet-Service ab Werk gibt es ja bei der 06.50 auch schon nicht mehr.

Da man aber für ein Downgrade genau dieselbe Verkabelung herstellen muß, wie beim Laden eines Images in den Speicher der Box, sollte man - zumindest mit einem Linux-System am Start, bei Windows ist es ein klein wenig komplizierter, weil man erst mal das Image braucht - auf so ein Downgrade verzichten ... es sei denn, man wollte ohnehin die Einstellungen alle löschen und die Box neu aufsetzen. Bei vorhandenem Image (also zumindest für die 7412 und die 7490, wenn man den von mir bereitgestellen (und signierten) Images traut) ist das Laden in den Speicher ja dann auch unter Windows kein Problem, wenn man die PowerShell-Skripte aus "eva_tools" verwendet.

Mit der o.a. Methode funktioniert das Installieren des SIAB-Services (bis einschließlich 06.93 - ja, sogar mit der offiziellen 06.98-Labor) auch bei irgendeiner beliebigen späteren Version. Von einer noch kleineren Version aus, sollte man ohnehin nicht starten ... die arbeitet dann noch mit einem 2.6-Kernel und dem SquashFS3-Format. Das will ich aber gar nicht mehr unterstützen - ich habe bisher nur darauf verzichtet, es explizit aus "modfs" zu entfernen.

Ich bin auch bereit, für weitere Modelle passende Images zu erzeugen ... andererseits ist dieser Vorgang so simpel und praktisch auf jedem Linux-Host ausführbar, daß ich nur wenige plausible Gründe dafür sehen kann - letztlich macht es jeder RasPi schon und wer seinen Router modifizieren möchte, sollte (nach meiner tiefsten Überzeugung) auch irgendwo eine funktionierende Linux-Umgebung haben. Zumal das heute auch auf einem Windows-PC (mit Windows 10 und Hyper-V als Virtualisierung) kein wirkliches Problem mehr ist - von den ganzen "Linux-Live-Distributionen" zum Ausprobieren, die auch noch persistente Änderungen mittels "overlayfs" gestatten, mal ganz zu schweigen.

 

[Micha0815]

Upps what a pitty ich wollte auf #1410 erweitern
Es ist schon sehr lange her, dass ich auf einer Werksresetteten FB7490 via modfs-starter und SIAB-Patch auf einer 06.50 das "durchspielte". Dieser Tage bekam ich von 1und1 eine Ersatz-FB7490 im Vorabtausch zugesandt für eine defekte, die "leider" brandneu (Herstellungsdatum 12/2017 mit dem neuen, unsäglichen Bootloader 1.3179 und FW06.90 in Partition 0 werkseitig daherkam. Für modfs flashte ich einfach ein aktuelle "inhaus" >6.90 die den symlink intus haben und kurz das Pikachu-Tool bemüht, da ich nur DECT-Fon habe und die Prozedur für das simple #96*7* abzusetzen aufwändigst ist (Es braucht erst einen SIP-Account ... kann auch fake sein...um ein DECT-Fon angemeldet zu bekommen).

Da ich eh eine komplexere *.export nach modfs-Implementierung importieren wollte auf 06.93 Basis der vormals DSL-Modem-Defekten, ging es so schneller.
LG
P.S.: Da der o.g. Bootloader das UI-De-Branding erschwert und modfs via Branding-Auswahl im GUI-Bootmanager trotz "avm"-Branding-Auswahl bei alternativen linux_fs_start nicht ausblendet, muss man versuchen sich über die alternativen Methoden das hinzubiegen.

 

[Shirocco88]

Für modfs flashte ich einfach ein aktuelle "inhaus" >6.90 die den symlink intus haben und kurz das Pikachu-Tool bemüht, da ich nur DECT-Fon habe und die Prozedur für das simple #96*7* abzusetzen aufwändigst ist (Es braucht erst einen SIP-Account ... kann auch fake sein...um ein DECT-Fon angemeldet zu bekommen).

Wenn man schon eine running Inhouse-FW mit SIAB hat, dann kann man auch gleich die zwei "ctlmgr_ctl" Befehle absetzen und kann sich (IMHO) weitere Zusatztools oder Umwege mit SIP und Fritz!Fon sparen;

Quelle:
https://www.ip-phone-forum.de/threads/modfs-squashfs-image-avm-firmware-ändern-für-nand-basierte-fritz-boxen.273304/page-22#post-2148224

 

[LaCruz]

@Micha0815: #96*7* - bei der neuen Labor 55112 funktioniert das nicht mehr! Nach Eingabe #96* kommt schon Ablehnung per Telefon. 8-|

Korrektur #96*7 - siehe #1418

 

[PeterPawn]

Nach Eingabe #96* kommt schon Ablehnung per Telefon.

Da hängen dann aber noch ein paar andere Code mit dran und nicht nur die für Telnet: http://wehavemorefun.de/fritzbox/Tastencodes

Gibt's dann CAPI und Callmonitor auch nicht mehr?

 

[LaCruz]

Da hängen dann aber noch ein paar andere Code mit dran und nicht nur die für Telnet: http://wehavemorefun.de/fritzbox/Tastencodes

Gibt's dann CAPI und Callmonitor auch nicht mehr?

OK. gerade mal durchgetestet:
#96*7 - Ablehnungston
#96*3* - Quittungston
#96*5* - Quittungston

Jetzt bleibt die Frage, wie TELNET wieder aktiviert werden kann.

 

[koyaanisqatsi]

Moin


Telnet ist, nicht nur meine Meinung, nach wie vor unsicher und läuft dann die allermeiste Zeit nutzlos vor sich hin und wartet dass sich Jemand einloggt.

Mit einer "LUA Konsole" oder "ShellInABox" über HTTPS kannste dir auch einen SSH Server installieren.
( Und vorbeugend "killall telnetd" abschicken )

 

[PeterPawn]

OK, dann aber erst nach der "7" und damit stehen die anderen Codes noch zur Verfügung.

Ich habe in die aktuelle Labor-Version nicht hineingesehen ... damit der Telnet-Daemon gestartet wird, muß

• der "telefon"-Daemon die Start-Sequenz noch enthalten (einfach ein "strings" auf "telefon" machen und nach "telnetd" in der Ausgabe suchen)
• der "telefon"-Daemon das Start-Flag in der "fx_conf" auswerten - an welcher Stelle das genau steht, weiß ich nicht aus dem Kopf, habe ich mal etwas zu geschrieben vor Jahren (2014 o. 2015 - würde ich tippen)

SIAB (nachträglich in eine Nicht-"Inhouse"-Version implantiert) startet auch ohne dieses Flag und auch bei AVM hat man ja den Start des SIAB-Daemons in den Inhouse-Versionen vom CGI-Aufruf auf eine Funktion im "ctlmgr" verschoben - denkbar, daß AVM damit den Start des Telnet-Daemons aus "telefon" auch entfernt hat oder das tun will - daher der erste Punkt oben.

So bequem es auch gewesen wäre, wenn man den Telnet-Start genauso "reglementieren" kann wie die 2FA, damit der nicht ständig aktiv ist, so veraltet ist Telnet nun mal ... es ist ja auch nicht das erste Mal, daß die Empfehlung eher lautet: Nimm (oder nehmt, damit Du Dich nicht direkt angesprochen fühlst) SIAB.