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

@eisbaerin:
Der (Shell-)Debug-Ausgabe zufolge ist das kein ext2-Image in der filesystem.image, sondern direkt ein SquashFS4 (fstype=squashfs4) ... so wie es bei den NOR-Modellen auch der Fall wäre.

Hier sollte/müßte man erst einmal in Ruhe das tar-File begutachten ... wenn es eine Box mit NAND-Flash für das System ist, steht bestimmt im SquashFS-Image (also in der filesystem.image) auch eine /etc/inittab und in dieser (vermutlich) auch wieder ein Aufruf von /sbin/flash_update (oder etwas ähnliches) zum Übertragen der Firmware aus den MTDRAM-Partitionen in den Flash-Speicher. Taucht in diesem Skript dann der Begriff "ubi" auf, ist es wohl tatsächlich eine Box mit UBIFS, wie die 7580 (wobei ich das da auch bloß aus der Analyse der Firmware geschlossen habe ... ich habe auch noch keine Support-Daten o.ä. einer 7580 gesehen).

Aber diese erwähnte "filesystem.image" müßte sich dann direkt mit dem "unsquashfs" (oder auch mit dem unsquashfs4, wobei ersteres die neue "unpack all"-Variante wäre) auch auspacken lassen, nachdem man sie mit "tar" aus dem AVM-Image extrahiert hat.

Ich komme gerade nicht dazu, mir das anzusehen bzw. ich kenne mich und weiß, daß ich dann wieder kein Ende finde und mehr als 30 Minuten Ablenkung kann ich mir momentan nicht leisten.

Ich komme hier nicht mehr mit.

HalliHalloSchat schrieb:

beide Partition waren neuer als 6.51. Das eine 6.60 das andere 6.51

Zum Vergrößern anklicken....

Hier mag ich noch an einen Schreibfehler glauben. Wobei auch das eigentlich nicht so richtig sei kann ... wenn die Box tatsächlich fabrikneu war und es noch keinen Eintrag für "linux_fs_start" gab (weiter oben in der Liste zu lesen), woher sollte dann die zweite "bespielte Partition" kommen?

Da bist Du wahrscheinlich eher durcheinander gekommen, weil Du die Zusammenhänge erst verstanden hast, nachdem Du schon mit der Umsetzung begonnen hattest.

Ja, in ShellInABox ist kein Copy&Paste möglich ... liegt aber am verwendeten Browser und der Tatsache, daß ein solcher meist keinen Zugriff auf den Clipboard-Inhalt zuläßt, wenn der nicht aus derselben Domain stammt. Kann man auch nichts dran ändern, solange der Browser keine Einstellung dafür hat. Ob eine "cross domain policy" helfen könnte, weiß ich nicht ... habe ich auch keine Lust zu ermitteln.

"modfs-Starter" ist nur ein Angebot für einen Shell-Zugang zur Box ... wer C&P braucht und will, muß eben an die Stelle von SIAB das Einrichten des Telnet-Zugangs setzen. Die Boxen, die bereits ab Werk mit einer Version >= 06.51 ausgestattet sind, kommen ja erst so nach und nach bei den Kunden an und bisher gab es einfach auch noch keinen Druck, einen anderen Weg bereitzustellen ... die notwendigen Beschreibungen dafür gibt es trotzdem bereits, nur müßte man sich seine Dateien eben selbst erstellen und/oder zusammenstellen.

Welchen "dropbear" Du da von wo installieren wolltest, geht aus dem Geschriebenen auch nicht einmal im Ansatz hervor ... woher sollen wir nun wissen, warum Dein "dropbear"-Binary eines für einen 2.6er-Kernel war? Schon das klingt komisch, weil das eigentlich keinen echten Unterschied machen sollte bei der uClibc. Also wird das wohl eine statische Variante sein und warum die auf einen 2.6er-Kernel fixiert sein sollte, muß man dann immer noch nicht verstehen. Der umgekehrte Fall, daß eine Software auf einem früheren Kernel nicht laufen will, weil dort hinzugekommene Syscalls fehlen könnten, der wäre wieder denkbar ... aber die Informationen sind einfach zu spärlich.

Ich habe noch kein SSH-Paket "veröffentlicht", nur die Patches für Freetz, damit man sich selbst einen "dropbear" basteln kann, der mit dem Box-Zertifikat/-Schlüssel arbeiten kann. Damit gibt es in "modfs" bisher keinen SSH-Zugang und ich verstehe den Zusammenhang zum SSH in diesem Thread ohnehin nicht.

Wenn Du die Bootloader-Variable "linux_fs_start" nicht auslesen kannst bei einer fabrikneuen Box, liegt die Vermutung nahe, daß sie einfach noch nicht gesetzt ist. Wenn Du sie dann aber auch nicht setzen kannst, liegt wieder eine andere Vermutung näher ... wahrscheinlich arbeitest Du einfach mit dem falschen FTP-Server (nämlich dem aus dem FRITZ!-NAS) und das sollte eigentlich auch nicht passieren, wenn man von Beginn an und bis zum Ende liest, bevor man ans Werk geht. Es ist auch nicht weiter schwer, diese FTP-Server auseinanderzuhalten ... in der BOOTSELECTION.ger steht ausdrücklich drin, wie die "welcome message" des Bootloaders aussieht und die ist kaum mit der des NAS-FTP-Servers zu verwechseln.

Dann hätte sich auch eine Beschreibung finden lassen, wie man unter Zuhilfenahme einer älteren FRITZ!OS-Version (es geht auch eine neue mit 3.10er-Kernel, aber die Beschreibung arbeitet noch mit einer älteren) ShellInABox bei einer Firmware mit strikter Signaturprüfung zum Laufen bringen kann .... auch ohne Recovery auf eine Version <= 06.50. Insofern stimmt die Aussage

HalliHalloSchat schrieb:

Es muss ein Recovery auf eine ältere Version gemacht werden.

Zum Vergrößern anklicken....

einfach nicht und sie kann daher nicht unwidersprochen stehenbleiben. Das ist ein einziger Weg, das Problem zu lösen und es gibt viele andere, die ebenso zum Erfolg führen.

---

-Beim Thema Firewall würde ich aber trotzdem von einer Änderung an der AVM-Firewall abraten. Auch da hättest Du ohnehin den steinigen Weg über Neustarts zwischen den Änderungen an Einstellungen in der ar7.cfg vor Dir, wenn Du sicher sein willst, daß die Änderungen auch wirksam werden und damit bist Du beim Vorgehen nicht weit vom Import entfernt (außer daß eben nur eine einzelne Datei neu geschrieben wird). Hier dürfte es wesentlich effektiver sein, wenn eine Filterung nach Ursprungsadressen tatsächlich erst auf dem Zielserver erfolgt ... die Möglichkeiten der AVM-Firewall sind da nicht so vielfältig, als das etwas wie das Geplante ohne weiteres umgesetzt werden könnte. Ich persönlich würde schon bezweifeln (weiß es aber zugegebenermaßen auch nicht), daß sich da beliebig viele Regeln einstellen lassen und Du gehst ja sicherlich nicht davon aus, daß man alle Adressen außerhalb der D-A-CH-Region mit einigen wenigen Regeln ausschließen könnte (oder auch einschließen, das macht in diesem Falle von der Anzahl her wahrscheinlich wenige Unterschiede). Das Abfragen irgendwelcher (DNS- oder WhoIs-)Datenbanken und eine "live decision" ist m.E. auch nicht machbar ... das sind aber alles Problemstellungen, für die es normalerweise schon fertige Pakete gibt, solange die nicht auf einer FRITZ!Box laufen sollen.

@HalliHalloSchat:
Die sind auch bisher nicht dafür gedacht, daß sie jemand einfach auf sein System kopiert und dort ausführt, ohne den Aufbau und die Anwendung vorher zu untersuchen und zu verstehen (diese Aufforderung gehört bei mir zum "Standardrepertoire", wie man unschwer nachlesen kann).

Wenn das fertig wäre und irgendeinen Status jenseits einer "Konzeptstudie" erreicht hätte, gäbe es entsprechende (ausfürhliche) Hilfetexte für den Aufruf und die Verwendung. Einzige Ausnahme (eigentlich kann sie auch das nicht wirklich sein, weil sie auf unfertige Bestandteile - wie z.B. eva_discover - zurückgreifen muß) wäre eva_switch_system ... das funktioniert bei vielen auch in der "dargebotenen" Form, kann aber logischerweise nicht auf jedem unix-artigen System "out of the box" verwendet werden.

Was da jetzt mit dem Interface beim Aufruf von "eva_switch_system" ist, kann man ja auch mal untersuchen, wenn's denn interessiert ... leider fehlt aber wirklich jeder Fakt, um das auch nur im Ansatz nachvollziehen zu können. Wenn ich es nicht überlesen habe, könnte das locker ein FreeBSD-System oder ein MacOS X sein, von dem Du da schreibst ... da nehme ich zwar die Erfahrung zur Kenntnis, leite daraus aber tatsächlich keinerlei Konsequenz für mein eigenes Handeln ab.

Nicht einmal die Verwendung des "dot"-Kommandos anstelle von "source" ist dadurch zu rechtfertigen (die Frage, was "die shell" ist, stelle ich gar nicht erst - ich kenne Debian-Nutzer, die tatsächlich der Meinung sind, "die shell" wäre "dash", nur weil der Symlink /bin/sh bei ihrer Installation auf diese "Geschmacksrichtung" verweist) ... ich habe genau zwei Umgebungen, in denen ich die Dateien in meinen Repos vorher teste (auch das steht irgendwo in den Weiten des IPPF).

Das ist einerseits die Box selbst als primäres Ziel (hier ist die "ash"-Implementierung aus der BusyBox "die shell") und daneben eine OpenSuSE-Installation, wo eben die "bash 4.2.irgendwas" "die shell" ist. Mit beiden sollte es so funktionieren, wie es im Repo eingecheckt wurde, zumindest hat es das bei mir getan.

Beide Testumgebungen (die ash und die bash) unterstützen das Synonym "source" anstelle des "." und da dieser allzu leicht "überlesen" wird beim Review (wozu ich - nochmal wiederholt - jeden Verwender meiner Elaborate stets aufs Neue ermutige/auffordere), benutze ich da lieber das "source". Wer tatsächlich mit einer 100% Posix-kompatiblen Shell arbeitet und keine Möglichkeit zur Verwendung einer anderen hat (selbst auf anderen "embedded systems" wie Einplatinen-Computern gibt es in aller Regel die BusyBox mit "ash"), der muß eben die Dateien vorher anpassen. Wenn ich bereits im SheBang ein "/bin/bash" eintragen würde, funktioniert es am Ende auf der originalen AVM-Firmware nicht mehr, dort gibt es nämlich keinen /bin/bash-Symlink ... einen Tod muß man sterben.

Wenn man das auf andere Installationen "überträgt" (z.B. auch auf solche, wo es explizit des Aufrufs mit "sudo" bedarf, falls ein Programm oder Shell-Skript Aktionen starten will, die "root"-Rechte erforderlich machen), dann muß man auch genug davon verstehen, um selbst solche "Klippen" bei der Adaption zu erkennen und da gehört die Änderung des "SheBang" von /bin/sh auf /bin/bash noch zu den harmloseren Schwierigkeiten, auf die man dabei stoßen mag.

Auf die Diskussion über /bin/sh lasse ich mich nicht wirklich ein ... in aller Regel ist das ein Link auf die tatsächlich verwendete/bevorzugte Shell, zumindest war es das in der Historie über eine lange Zeit.

Die Dateien sind eben (siehe oben) auch nicht zur "blinden Anwendung" gedacht und solange man nicht bereits dort mit "autoconf" oder einem ähnlichen Helfer eine Anpassung an das jeweils vorhandene System vornehmen will (was ich definitiv nicht unterstützen werde), wird es auch kaum möglich sein, sämtliche *nix-Umgebungen beim Entwurf zu berücksichtigen.

@eisbaerin:
Dann wirf mal einen Blick in die /var/install ... steht da etwas vom "UBIFS"? Wenn nicht, machst Du mich dann doch neugierig - also bitte bitte finde dort das "Formatieren" der Dateisystem-Partitionen mit den "ubi"-Utilities (im Interesse meines Zeitmanagements). Daß die 7560 wieder auf NOR-Flash für das System setzt (dann wäre die filesystem.image ja wieder 1:1 in den Flash übertragbar, auch wenn AVM dann wohl doch eher wieder ein "hidden root image" daraus gemacht hätte), kann ich eigentlich nicht glauben.

EDIT: @HalliHalloSchat:
An anderen Stellen kann ich mir (beim wiederholten Lesen) das Schmunzeln auch nicht verkneifen ... anstatt nach der Ursache zu suchen, warum der FTP-Server einfach die ausdrücklich beschriebenen Credentials mit "adam2" nicht akzeptieren will, hast Du dann einfach einmal die vorhandenen FRITZ!Box-Benutzer "substituiert" und warst immer noch der Überzeugung, Dich dabei auf dem von mir beschriebenen Weg zu befinden? Wir haben vermutlich vollkommen unterschiedliche Vorstellungen, wie man an solche Probleme herangehen sollte. Wenn es bei Dir dann irgendwann auch funktioniert, freut mich das (für Dich) ... aber bitte verstehe auch, wenn ich daraus jetzt nicht unbedingt direkte Konsequenzen für eine Änderung von Beschreibungen oder gar Shell-Skripten ableite. Bei "penibler Vorbereitung" und verstehendem Lesen der (gesamten) vorhandenen Beschreibungen bevor man irgendetwas lädt oder gar ausführt, sollte man nach meiner Überzeugung gar nicht in die von Dir eingeschlagene Richtung "abdriften" können. Selbst wenn ... überprüft man bei unerwarteten Ergebnissen dann die Eingangsvoraussetzungen/-vermutungen noch einmal anstatt recht unbekümmert irgendwelche Randbedingungen zu variieren, sollte man auch wieder auf den richtigen Weg zurückfinden.

Steht ja da ... "#### no wrapper" - sieht so aus, als würde AVM bei der 7560 auf das "äußere Dateisystem" verzichten und direkt ein SquashFS-Image in die Dateisystem-Partition schreiben (das ist dann tatsächlich wie bei den NOR-Modellen, nur eben wohl doch Kernel und Dateisystem getrennt - vermute ich mal, man sieht ja die Installation des Kernels in dem Auszug oben nicht).

Das wäre etwas schade, weil es einige meiner Erweiterungen dort tatsächlich unmöglich macht (in erster Linie solche, die einen beschreibbaren dauerhaften Speicher in der Box aus abseits des yaffs2-Dateisystems unter /var/media/ftp benutzen) ... aber lassen wir es erst einmal so stehen, daß die 7560 im Moment nicht mit "modfs" zu modifzieren ist. Irgendwelche Anpassungen kann ich da auch nur dann vornehmen, wenn ich den kompletten Aufbau der Box (das geht bei den Support-Daten los und braucht dann wohl noch ein paar zusätzliche Angaben, für die man wohl erst einmal eine Shell benötigt) auch verstanden habe.

Ist im Moment nicht vordringlich ... erst einmal müssen sich die Boxen auch materialisieren und zwar in nennenswertem Umfang und nicht nur als Vorabexemplare für die Presse o.ä. - dann kann man weitersehen.

Eine FRITZ!Box (wenn "modfs" sie unterstützt) hat zwar 2x Kernel und ein jeweils dazu gehörendes Dateisystem, aber ebenso nur 1x Einstellungen, wie jede andere auch.

Damit muß/kann da also gar nichts bei den Einstellungen kopiert werden ... es sind exakt dieselben für beide Systemversionen. Wenn es sich um unterschiedliche Firmware-Stände in den beiden Partition-Sets handeln sollte, muß man selbst dafür sorgen, daß da entsprechende Rücksicht genommen wird auf Inkompatibilitäten.

Die erste Version von "modfs" mußte darauf gar keine Rücksicht nehmen, weil sie eigentlich mal damit anfing, in beiden Partitionen das identische System vorauszusetzen. Auch heute noch wird das als allererstes geprüft, wenn man "modfs" ohne "update"-Parameter aufruft. Ruft man es hingegen mit diesem (später erst eingeführten) Parameter auf, erfolgt m.W. extra noch ein Hinweis, daß der Benutzer für die Verwaltung der Einstellungen selbst verantwortlich ist und ggf. bei inkompatiblen Systemen dann eben einen gesicherten Stand wiederherstellen muß, der zum startenden System paßt.

Ansonsten installiert jeder Aufruf von "modfs" eben genau ein einzelnes modifiziertes System in der inaktiven Partition und schaltet dann um ... das ist ziemlich exakt dasselbe, was eine Update-Installation von AVM auch macht ... "modfs" paßt halt dieses zu installierende System dabei noch an. Wenn man ohne eine solche Anpassung das AVM-System installiert und dann auf dieses umschaltet, was sollte denn dann passieren? Da kann doch gar keine Änderung durch "modfs" in diesem System vorhanden sein, wenn man es 1:1 aus der "stock firmware" installieren läßt.

Micha0815 schrieb:

für den Ausdruck "Kladderradatsch" in #736 möchte ich mich entschuldigen, falls PeterPawn dies als persönliche Beleidigung ansah.

Zum Vergrößern anklicken....

Sieht/sah er nicht ... er kann sich trotzdem den Hinweis nicht verkneifen, daß es schon mehrfach beschrieben wurde, worin der Unterschied zwischen "update" und "recovery" liegt, welches System dabei jeweils "beschrieben" wird und was man anstellen muß, damit man z.B. eine Box hat, bei der zwischen einer Release-Version und einer Labor-Version mit der Erweiterung der "Neustart"-Seite hin- und hergeschaltet werden kann. (Ab hier ist dann auch wieder Schluß mit "dritte Person Singular", sonst diagnostiziert noch jemand Pronominalumkehr als klinisches Zeichen bei mir.)

Wenn man halt in der aktiven Partition eine (unveränderte) AVM-Version mit der 06.60 liegen hat, dann bietet diese logischerweise keine Auswahl des Systems beim Neustart an. Will man hier also eine Labor-Version installieren und hat nur in der inaktiven Partition eine Firmware mit aktiviertem Shell-Zugang liegen, bleibt ja gar nichts anderes als per Bootloader (FTP zur EVA) auf das andere System umzuschalten und von dort aus mit "modfs" ein Update zu machen ... das schreibt dann logischerweise in die zum Zeitpunkt der Ausführung von "modfs" inaktive Partition - im Beispiel also in die, wo bisher das 06.60 liegt bzw. dann lag.

Wenn man also erst einmal verinnerlicht hat, daß es gar keine zwei Sätze von Einstellungen gibt (das hatte ich mal versucht beim "alten Boot-Manager", wo man die Einstellungen pro System speichern konnte, hat aber mit "modfs" absolut nichts zu tun), dann sollten sich die Fragen, wann welches System aktualisiert wird und wie man sich beim Update auf die nächste Version verhalten muß, quasi von alleine erledigen. Die Frage, daß eben "modfs" nur ein einziges System ändert und sich nicht so im System verankert, daß es sich bei einem "normalen AVM-Update" auch wieder in das System einklinkt (das geht tatsächlich, aber dann wird man "modfs" nicht mehr durch einfaches Update auch wieder los und es erinnert schon wieder mehr an Malware), ist aber tatsächlich schon mehrfach erörtert worden.

Für diejenigen, die es ausprobieren wollen: Man kann die /var/post_install entsprechend ändern ... bei AVM werden dort ja die Kommandos zum Schreiben des Systems in die inaktiven Partitionen hinter den üblichen Ablauf beim Neustart angefügt. Läßt man also in der /var/post_install (nachdem man geprüft hat, daß da hinten noch ein AVM-Update in der Datei steht) das alte System auspacken, ändert z.B. den Telnet-Symlink und fügt die Kommandos zum (späteren) Ändern des Systems beim nächsten Update auch gleich noch zur var.tar für das neue System hinzu (inkl. der benötigten zusätzlichen Binaries), kann man sogar ganz normal mit dem AVM-Update ein vom Hersteller signiertes Update installieren lassen.

Die Prüfung der Signatur erfolgt nämlich bereits davor ... und wenn die Firmware diese Hürde erst einmal genommen hat, kann man sie hinterher ziemlich leicht wieder ändern. Man muß nur auch hier aufpassen, daß man das ausführen läßt, bevor einem das USB-Subsystem unter dem Sattel weggeschossen wird ... das klappt mit einer passenden Swap-Partition einfach besser und parallel muß man noch aufpassen, daß keine Watchdog-initiierten Neustarts das Packen eines neuen SquashFS-Images dann doch noch unterbrechen. Kriegt man das auf die Reihe, installieren die AVM-Kommandos auch klaglos das modifizierte Image.

Aber das geht eben wirklich schon mehr in die Richtung "Wurm" oder "Virus", der sich über Updates hinweg in der Firmware festkrallt (so eine Reproduktion ist ja ein Merkmal eines Virus) und auch wenn ich das als Machbarkeitsstudie tatsächlich mal umgesetzt habe (damit in einer Kundenbox gerne auch automatische Updates eingeschaltet werden können und trotzdem eine (recht einfache) Änderung wie mein "heartbeat service" nicht verloren geht), würde ich das für "normale Benutzer" nicht für sinnvoll und notwendig erachten. Hier ist es m.E. besser, wenn bei jedem Update der Besitzer der Box sich ganz bewußt dafür entscheiden muß, welche Änderungen er am System vornehmen lassen will. Spätestens bei signifikanten Änderungen durch AVM müßte man ohnehin wieder eingreifen und den Reproduktionsmechanismus entsprechend anpassen.