- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,300
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
Es gibt eine neue Version des Skripts, dazu habe ich auch ein neues Thema aufgemacht.
Um es noch einmal ganz deutlich zu schreiben: Wenn jemand die nach wie vor auf dem Server vorhandene alte Version (modfs_7490.tgz) nutzen will, habe ich nichts dagegen. Aber irgendwelche Anfragen beantworte ich nur noch zur neuen Version (modfs.tgz) ... ich ändere auch nichts mehr an der alten Version, selbst wenn mir Fehler dort zur Kenntnis gelangen.
Quickstart für diejenigen, die grundsätzlich nur "machen" wollen - die Kommandos ohne Lametta
Nach dem Neustart sollte der Inhalt der rc.user (AVM nennt sie debug.cfg) abgearbeitet werden.
Wer das jetzt trotz aller Warnungen als Einzeiler für die Box haben will, nimmt folgendes:
Und das Ganze noch einmal als Einzeiler mit dem Download einer "frischen Kopie" des Firmware-Images vom AVM-FTP-Server:
Der originale Text beginnt hier, aber Einzelheiten wurden nachträglich korrigiert:
Auf der Basis des in der 7490 doppelt vorhandenen Flash-Speichers für das Kernel-Image und der anderen Handhabung des root-Filesystems ist es - mit zwei zusätzlichen Binaries - möglich, die Abarbeitung der debug.cfg (aka rc.user) direkt auf der FRITZ!Box 7490 wieder zu aktivieren.
Bereits bei der Abschaffung der debug.cfg in den Labor-Versionen wurde von er13 ja ein Patch und eine Änderung von "fwmod" im Freetz-Trunk eingepflegt, mit denen man sich ein eigenes Freetz-Image ohne freetz-mod erstellen konnte. Einige sind diesen Weg bereits gegangen, andere werden sicherlich noch zögern.
Auch wenn ich i.d.R. das Benutzen von "fremden Übersetzungen" eher ablehne (also die Verwendung von Binaries aus "OpenSource"-Quellen, die von anderen erzeugt wurden, eher nicht empfehlen würde), habe ich mich doch entschlossen, diese Binaries - zusammen mit einigen Shell-Skripten - auch anderen zur Verfügung zu stellen. Ich hoffe, damit noch weiteren Interessenten wieder die Verwendung eigener Software auf einer 7490 ohne großen eigenen Aufwand zu ermöglichen.
Spätestens wenn das dann nicht nur ein paar Skripte unter Verwendung bereits vorhandener Kommandos sind, sondern auch wieder zusätzliche Binaries benötigt werden, würde ich aber wieder auf die vorstehende Bemerkung verweisen und die Verwendung von Diensten(!) auf Basis fremder Binaries eher ablehnen.
Egal, zum Wesentlichen ... die Aktivierung der Abarbeitung der debug.cfg ließe sich ganz einfach in einer Telnet-Session mit den folgenden Kommandos erledigen:
Als erstes wird das Paket mit den Binaries und den Skripten von einem meiner Server geladen und die Prüfsumme des geladenen Archivs gebildet. Hier bin ich leider auf die Verwendung des echt antiquierten MD5 als Algorithmus angewiesen, da die AVM-Firmware von sich aus keine Kommandos für einen moderneren Algorithmus anbietet.
Wichtig ist es in jedem Falle, daß die oben farbig dargestellte Prüfsumme auch wirklich stimmt, ansonsten wurde das Archiv irgendwie modifiziert und man sollte die Finger davon lassen.
Weil ich gerade beim "Finger davon lassen" bin, mir ist genauso wenig zu trauen, wie jedem anderen Anbieter von nicht zu überprüfender Software auch. Wer also meiner Beschreibung folgt, tut dies absolut auf eigenes Risiko. Allerdings kann ich mir keinen Schaden vorstellen, der größer wäre, als er bei einem "normalen" Flashvorgang auch sein könnte. Insofern sollte im Falle eines unerwarteten Abbruchs spätestens mit dem AVM-Recovery-Programm jedes Problem wieder zu beseitigen sein.
Wenn jemand für das Archiv modfs_7490.tgz die Hashes mit anderen Programmen prüfen will, hier sind die Werte für einige andere gängige Algorithmen:
Wenn wir jetzt sicher sind, daß das Archiv auch wirklich das richtige ist, können wir weitermachen:
Wir legen uns ein Verzeichnis /var/mod auf der Box an (das ist temporär, da nur im RAM) und entpacken dort das Archiv. Nach einem kurzen Blick, was da so alles drin ist, checken wir erst, ob die notwendigen Voraussetzungen für das Aktivieren der debug.cfg vorliegen. Dabei werden noch einmal die einzelnen Dateien anhand ihres MD5-Hashes mit den von mir eingepackten Dateien verglichen (die stehen in checksums), was sicherlich doppelt gemoppelt ist, aber ich bin ein vorsichtiger Mensch.
Eine der Voraussetzungen für den erfolgreichen Einsatz der Skripte ist, daß die Box in den beiden verfügbaren Flash-"Versionen" dasselbe FRITZ!OS enthält. Die Modifikation zur Reaktivierung der debug.cfg erfolgt nämlich so, daß das root-Filesystem des laufenden FRITZ!OS (in der Datei /wrapper/filesystem_core.squashfs enthalten und per loop-Device als / gemounted) entpackt, anschließend modifiziert und dann wieder zu einem SquashFS gepackt wird. Dieses neue SquashFS wird dann in die nicht-aktive Filesystem-Partition kopiert und anschließend auf den Start aus der anderen "Flash-Variante" umgeschaltet. Beim nächsten Start der Box wird dann das neue root-Filesystem mit den ausgeführten Änderungen benutzt.
Sollten auf der Box noch zwei unterschiedliche System sein (z.B. direkt nach einem Update mit einem neuen AVM-Image), sähe das in etwa so aus:
Aber auch dieser Fall läßt sich relativ leicht lösen, indem einfach auch der Kernel des laufenden Systems in die inaktive Kernel-Partition kopiert wird. Dasselbe wird mit dem Wrapper-Filesystem praktiziert, danach enthalten beide "Versionen" der FRITZ!Box 7490 dann ein identisches System und der Modifikation des root-Filesystems steht nichts mehr im Weg.
Jetzt sind die beiden Systeme identisch und ein erneuter Test mit "./prereq_7490" sollte keine Probleme mehr melden.
Wer absolut auf Nummer sicher gehen will, bootet noch einmal kurz seine Box neu und fängt von vorne an.
Zur Sicherheit empfehle ich die Box nach dieser "Gleichmacherei" neu zu starten und von vorne zu beginnen.
Im nächsten Schritt wird jetzt das root-Filesystem des laufenden FRITZ!OS ausgepackt (dazu dient das unsquashfs) und anschließend werden alle im "modscripts"-Verzeichnis liegenden Shell-Skripte (in aufsteigender alphabetischer Reihenfolge der Dateinamen) abgearbeitet. Diese Skripte kriegen als einzigen Parameter den Pfad zum "root-Verzeichnis" des entpackten SquashFS übergeben und können nun ihrerseits die dort liegenden Dateien modifizieren.
Ich habe meinerseits dort drei Skripte bereits hinterlegt, das entscheidende dürfte 'mod_rc_tail_sh' sein:
Damit wird die Datei etc/init.d/rc.tail.sh in der vorletzten Zeile dahingehend geändert, daß die frühere debug.cfg-Datei (unter anderem Namen an anderer Stelle, aber das ist meine volle Absicht) auf das Vorhandensein irgendeines Inhalts geprüft wird und - wenn dort etwas drin stehen sollte - dieser Inhalt dann in die Datei "/var/tmp/rc.user" kopiert wird. Dann wird auch - mit einer Sekunde Verzögerung über einen Mechanismus im FRITZ!OS - eine Shell gestartet, die die Abarbeitung der Kommandos übernimmt. Anschließend wird das "Fenster" in das TFFS, durch das wir den Inhalt der debug.cfg kopiert haben, wieder geschlossen (auch wenn die debug.cfg leer war). Das ist eine etwas andere Vorgehensweise, als die bisher von AVM gewählte, aber sie hat in meinen Augen folgende Vorteile:
1. Der Init-Prozess ist praktisch abgeschlossen, die meisten AVM-Prozesse laufen schon.
2. Die Abarbeitung der debug.cfg erfolgt jetzt asychron zum Init-Prozess, in der debug.cfg auftretende Fehler beeinflussen die weitere Abarbeitung der rc.tail.sh nicht mehr.
3. Durch die Nutzung von multid (über das delay-Kommando) werden solche Spiele wie nohup o.ä. unnötig.
Selbstverständlich ist das aber nur eine denkbare Modifikation des Filesystems. Wer es lieber mag, wenn seine eigenen Skripte eher bei einer Änderung des Online-Status der Box ausgeführt werden, schreibt sie eben nach /etc/onlinechanged. Auch diverse andere Änderungen, für die ansonsten die debug.cfg bisher immer "zu spät" kam im Init-Prozess, lassen sich mit einem Einzeiler realisieren:
Das fügt in ein udev-Skript die Suche nach einem Label für ein Filesystem auf einem angeschlossenen Speicher ein und sorgt - wenn eines gefunden wird - dafür, daß dieses Label als Pfad in /var/media/ftp für das Volume verwendet wird. Wenn man also seinem USB-Volume den Namen "Music" gibt, steht dieses dann unter /var/media/ftp/Music zur Verfügung.
Ich habe aus meinem Vorrat an Skripten nur noch zwei weitere bereits in das Paket integriert.
Das erste modifiziert die Datei /etc/profile so, daß als letzte Aktion das Vorhandensein einer Datei /var/custom/profile getestet wird und - so diese Datei existiert - die dort stehenden Kommandos auch noch abgearbeitet werden. Da das ja bei jedem Shell-Login passiert, kann man dort gut noch weitere eigene Modifikationen einbauen, die nicht unbedingt im root-FS liegen müssen und man spart sich trotzdem das bind-Mount für die nachträgliche Änderung der /etc/profile.
Das zweite zusätzliche Skript erzeugt im neuen root-FS ein zusätzliches Kommando "edit_rcuser", das im Endeffekt nichts anderes als eine Art 'nvi' für die rc.user (AVM nannte sie ja debug.cfg) ist und das Editieren der Datei auch dann erlaubt, wenn es kein "char-Device" dafür in /var/flash gibt (ansonsten einfach mal in die README schauen).
Auch die komplette Integration eigener Binaries und Skripte direkt ins root-Filesystem ist natürlich machbar, wenn man die entsprechenden Skripte dafür vorbereitet. Das geht von der Korrektur kleiner nerviger Probleme (z.B. ist es problemlos möglich, die VPN-Verbindungen wieder in die Übersicht zu bringen oder den FTP-Server wirklich komplett abzuschalten - der kann zwar AUTH TLS auch nach innen, aber wer benutzt das schon wirklich und schickt nicht spätestens beim FTP-Zugriff dann im LAN die Credentials im Klartext durch die Gegend) bis zur Integration eines SSH-Servers anstelle des doch eher unsicheren Telnet-Zugangs. Wenn man dann den Link zum Busybox-telnetd (/usr/sbin/telnetd) mit einem Link zu einem passenden Skript für den Start des Dropbear ersetzt, kann man diesen sogar über die Tastenkombination von AVM für den Telnetd ein- und ausschalten. Der Phantasie sind also fast keine Grenzen gesetzt, das muß halt nur alles in einem Skript im Unterverzeichnis passieren, solange man das "update_7490"-Skript unverändert benutzen will. Die Skripte müssen dann natürlich auch vor dem Start von "update_7490" ins richtige Verzeichnis gelegt werden.
An Platzmangel wird das ja bei einer 7490 nicht so schnell scheitern, da paßt noch so einiges hinein ... auch die Integration der SquashFS-Hilfsprogramme in das root-Filesystem trägt nicht merklich auf, die Skripte kann man auch irgendwo im System lagern.
Wie weitere Änderungen bewerkstelligt werden könnten (es führen in der Shell immer mehrere Wege zum Ziel), steht wieder in der README.
Das ist zweifellos natürlich auch alles mit einem eigenen Freetz-Image möglich, aber gerade die "Bastler", die desöfteren mal neue Software in ihr Image integrieren wollen, werden vielleicht die Vorteile auch zu schätzen wissen, daß man mit den Skripten und dem Boot-Manager in Kombination ziemlich gefahrlos eigene Sachen ausprobieren kann, ohne auf ein Recover oder Downgrade zurückgreifen zu müssen. Man muß lediglich beachten, daß die Änderungen kumulativ sind, da jaimmer das root-Filesystem des laufenden Systems als Basis für die Modifikationen dient. Führt man also dieselben Skripte zur Modifikation mehrmals aus, werden diese Änderungen auch mehrfach übernommen. Das von mir bereitgestellte Skript fügt dann eben mehrmals eine vorletzte Zeile in die rc.tail.sh ein. Das wäre wohl kaum im Sinne des Erfinders, das sollte aber jeder selbst bei Kenntnis des potentiellen Problems lösen können.Die neue Version des 'update_7490' kann jetzt auch ein anderes SquashFS-Image für die Basis verwenden als das root-FS des laufenden Systems. Wieder hilft ein Blick in die README-Datei ...
EDIT: Neu ist jetzt auch die Möglichkeit, durch die Angabe von 'fresh' als Parameter für den Aufruf des update_7490-Skripts auch ein "frisches" Firmware-Image vom AVM-Server laden zu lassen und die Änderungen dann auf das root-Filesystem in diesem Image anzuwenden. Das setzt allerdings voraus, daß auf dem AVM-Server auch ein passendes Image liegt (und das gilt auch nur für die deutsche Version der Firmware, solange man das Skript 'get_7490_freshcopy' nicht selbst modifiziert - dann aber die MD5-Prüfung in update_7490 auch ausschalten oder den Inhalt von 'checksums' entsprechend korrigieren).
Ansonsten muß man eben den Download aus einer passenden Quelle von Hand ausführen und kann dann durch den Aufruf von
das root-Filesystem aus diesem Image extrahieren und in das NAND-Flash der Box verschieben (das ist kein Einzeiler für C&P, da muß der eigene Image-Name ersetzt werden). Dann kann man den Aufruf von update_7490 auf
ändern und - je nach Platzbedarf im NAND-Flash - das "Basis-Filesystem" dort für weitere Versuche gleich liegen lassen.
:doktor:
Bitte auch immer darauf achten, daß im tmpfs ausreichend freier Speicher zur Verfügung steht. Nach meinen Tests sind ~ 90 MB freier Speicher in /var erforderlich. Wer also dort 3 verschiedene Firmware-Images als Downloads liegen hat und dann trotzdem die Skripts startet, wird wahrscheinlich nur seine Zeit vergeuden, da spätestens beim Packen des neuen Filesystems dann wohl der freie Platz im tmpfs ausgehen wird.
Also weiter im Text. Als nächstes wird jetzt also das root-Filesystem entpackt (das rekursive Kopieren aus / war mir persönlich zu kompliziert angesichts der u.U. dort schon erfolgten Modifikationen durch bind-Mounts o.ä.) und die Skripte zur Modifikation abgearbeitet. Anschließend wird das Ganze wieder zusammengepackt. Dabei werden absichtlich alle Dateien im neuen SquashFS aufgelistet, da der Vorgang zwischen 3 und 5 Minuten dauern kann, dient die Ausgabe gleichzeitig als "Lebenszeichen" des mksquashfs.
Wenn dann das neue SquashFS erstellt wurde, wird es in die inaktive Partition kopiert und für den nächsten Start des FRITZ!OS auf die alternative Partition umgeschaltet.
Jetzt noch schnell das Verzeichnis /var/mod entsorgt, um den dort belegten Platz im RAM für den Neustart des Systems (eigentlich eher für das Beenden der AVM-Prozesse) wieder zur Verfügung zu stellen, und wir können die Box neu starten.
Nach dem Neustart des Systems sollte dann auch unsere debug.cfg (unabhängig vom Namen, denn sie heißt ja jetzt rc.user) wieder abgearbeitet werden. Ich hoffe mal, niemand kommt auf die Idee, die Kopie der Kommandos aus dem TFFS in /var/tmp/rc.user zu modifizieren und dann zu erwarten, daß diese Änderungen einen Neustart der Box überleben.
Zum Editieren der Kommandos in der "rc.user" (oder meinetwegen auch debug.cfg) empfehle ich die Verwendung von 'edit_rcuser', wenn man das hat erzeugen lassen.
Auch beim Editieren der Kommandos unter dem Dateinamen "/var/flash/debug.cfg" (der existiert ja nicht, solange man ihn nicht selbst als char-Device anlegt) ist bei der 7490 besondere Vorsicht anzuraten. Anders als andere Modelle hat die 7490 auf /var/flash kein tmpfs ("geerbt" von /var) sondern ein NAND-Flash (/dev/mtdblock4) gemounted, wenn man dort eine reguläre Datei anlegt, überlebt diese - eben anders als bei den anderen Modellen - auch einen Neustart. Das kann - wenn man sich darauf verläßt, das bei einem Neustart schon alles in /var/flash ordentlich "restauriert" wird - auch mal eine böse Überraschung geben, wenn dann eine vorhandene reguläre Datei das Anlegen eines char-Devices für den TFFS-Inhalt verhindert und plötzlich eine leere Einstellungsdatei daraus entsteht.
Eigentlich bilden also die Skripte und die beiden Hilfsprogramme zum (Ent-)Packen des SquashFS nur eine Art "Framework", was man damit machen will, muß man sich selbst überlegen. Der eine baut mit 6 Kommandos per C&P von hier einfach wieder die debug.cfg in seine Box ein, der andere modifiziert bei der Gelegenheit gleich noch das GUI der Box dauerhaft für seine Zwecke oder schaltet durch Änderung der provider-049.tar das TR-069 für seinen Provider richtig aus (irgendwann wird auch wieder eine einheitliche Umsetzung für die verschiedenen Modelle einziehen).
Noch ein paar Bemerkungen zur Sicherheit:
Erstens benötigt man zur Benutzung des Paketes den Zugang zur Kommandozeile der FRITZ!Box. Wenn ein Unbefugter diesen erlangt, ist ohnehin schon alles zu spät. Insofern wird die Sicherheit per se nach meinem Dafürhalten nicht geschmälert ... wenn man die Änderungen an seiner Box nicht vornimmt, ändert sich gegenüber dem AVM-Original absolut nichts.
Zweitens ist mir sehr wohl bewußt, das ein Angreifer nach demselben Prinzip auch die Box gegen den Willen des Besitzers modifizieren könnte. Aber ich bin auch der Überzeugung, daß ein potentieller Angreifer dazu nicht meine Anleitung benötigen würde und daß dieser sicherlich wesentlich finsterere Absichten und mindestens genauso viel Kenntnis des FRITZ!OS hätte. Die Zeiten, als das noch "Script-Kiddies" ohne eigene Erfahrungen und Ideen waren, sind lange vorbei.
Drittens kann ich damit auch mal zeigen, daß die permanente Modifikation des FRITZ!OS - immer unter der Voraussetzung, ein Angreifer erlangt Shell-Zugriff - nicht nur theoretisch möglich ist. Dieselbe Vorgehensweise läßt sich natürlich auch für ein anderes Modell adaptieren, da läuft dann nur der Flashvorgang etwas anders (im Rahmen eines Neustarts) und im Falle eines Problems brickt der Angreifer die Box (was bei genauer Überlegung ja sogar von Vorteil wäre). Bei einigen Modellen mag es sogar am Speichermangel im RAM scheitern, dann würde ein Angreifer das eben "extern" ausführen.
Es ist also ein sehr reales Szenario, daß bei Shell-Zugriff das System der Box (fast) mit Bordmitteln modifiziert werden kann. Daraus leitet sich dann wieder für mich die Folgerung ab, auf jede nur erdenkliche Weise den Shell-Zugriff für einen Unberechtigten zu unterbinden. Dazu gehört es eben auch, selbst im LAN nur verschlüsselt mit der Box zu kommunizieren. Selbst wenn man vielleicht nicht direkt ein Kennwort für den Zugriff "sniffen" kann, der Mißbrauch einer SID nach gezielter Ausschaltung des berechtigten Benutzers (oder nachdem der "fertig hat" mit der Box ohne sich abzumelden) ist nun wirklich kein Hexenwerk.
Letzte Bemerkung, jetzt zu den Binaries: Ich werde in den nächsten Tagen auch noch einen Patch für den Freetz-Trunk auf dem Server bereitstellen, damit sich jeder ggf. auch selbst sein mksquashfs und unsquashfs für die 7490 erzeugen kann. Im Moment habe ich da noch ein Problem, weil die Toolchain ein benötigtes Include-File (squashfs_fs.h) nicht in der korrekten Version für den Kernel enthält. Da bin ich noch am Überlegen, ob nicht auch ein einfaches Kopieren der Datei an die richtige Stelle ausreichend wäre. Baue ich das mit allen Abhängigkeiten in das make für die Toolchain ein, würde vermutlich nach der Anwendung meines Patches erst einmal die Toolchain neu erstellt. Das wäre dann zwar die "automatische" Lösung, aber auch ein unverhältnismäßig hoher Aufwand für das Erzeugen dieser beiden kleinen Hilfsprogramme.
Ich werde direkt im Anschluß einen Patch für das Erzeugen der beiden Binaries als Freetz-Package auf freetz.org hochladen (erst einmal nur für die 7490), der dann hoffentlich in nicht allzu ferner Zukunft seinen Weg in den Trunk findet. Das unsquashfs-Binary aus der vorhergehenden Version (in debugcfg_7490.tgz) hatte ein Problem mit dem Entpacken eines bereits vom zugehörigen mksquashfs "behandelten" Images, da wurde eine falsche Versionsnummer des SquashFS angegeben.
Es steht nicht explizit in den Skripten drin (die beiden Binaries sind ohnehin nicht von mir), aber das steht natürlich alles unter GPLv2. Es darf also jeder damit machen, was er will. Genauso gilt natürlich auch der Rest des Textes der GPL, besonders der Teil zum Nutzwert der Software.
Ich habe nur keine Lust mehr auf das Hinzufügen des GPLv2-Hinweises zu den ganzen Files, da sich dann auch wieder die Hashes ändern und ich zumindest dort von vorne beginnen müßte. Sowie der Patch (damit wäre dann auch das Veröffentlichen der Quellen nach GPL für mich erledigt) verfügbar ist, ändere ich diesen Beitrag noch einmal. Vielleicht entschließe ich mich dann ja doch noch zur Änderung der Skripte, inkl. der Aktualisierung der o.a. Hashes.
Ich habe das Paket um eine README-Datei und die entsprechenden Lizenzhinweise auf die GPLv2 ergänzt.
Um es noch einmal ganz deutlich zu schreiben: Wenn jemand die nach wie vor auf dem Server vorhandene alte Version (modfs_7490.tgz) nutzen will, habe ich nichts dagegen. Aber irgendwelche Anfragen beantworte ich nur noch zur neuen Version (modfs.tgz) ... ich ändere auch nichts mehr an der alten Version, selbst wenn mir Fehler dort zur Kenntnis gelangen.
Quickstart für diejenigen, die grundsätzlich nur "machen" wollen - die Kommandos ohne Lametta
Code:
Eingabe => mkdir /var/mod;cd /var/mod;wget http://www.yourfritz.de/modfs_7490.tgz;md5sum modfs_7490.tgz
Ausgabe prüfen => 94c32f1ffbe7ff62199ba81b3b806c38 modfs_7490.tgz
Eingabe => gunzip -c modfs_7490.tgz | tar x
Eingabe => ./prereq_7490
bei Ausgabe => There are different kernel images at your box.
To copy the running system to the other partition, execute './copy_7490_systems'.
Eingabe => ./copy_7490_systems
Eingabe => reboot
Und das Ganze noch einmal von vorne beginnen ...
Ausgabe => Ok, it looks like your system could be updated now. Simply execute './update_7490' to ...
Eingabe => ./update_7490
Ausgabe => jede Menge Zeilen und am Schluß dann:
Your alternative system will use the modified root file system now. Please reboot to activate the alternative system.
Eingabe => cd /;rm -r /var/mod
Eingabe => rebootWer das jetzt trotz aller Warnungen als Einzeiler für die Box haben will, nimmt folgendes:
Code:
mkdir /var/mod;cd /var/mod;wget -q -O - http://www.yourfritz.de/modfs_7490.tgz | gunzip -c | tar x;./prereq_7490 && ./update_7490 && cd / && rm -r /var/mod && rebootUnd das Ganze noch einmal als Einzeiler mit dem Download einer "frischen Kopie" des Firmware-Images vom AVM-FTP-Server:
Code:
mkdir /var/mod;cd /var/mod;wget -q -O - http://www.yourfritz.de/modfs_7490.tgz | gunzip -c | tar x;./prereq_7490 && ./update_7490 fresh && cd / && rm -r /var/mod && rebootDer originale Text beginnt hier, aber Einzelheiten wurden nachträglich korrigiert:
Auf der Basis des in der 7490 doppelt vorhandenen Flash-Speichers für das Kernel-Image und der anderen Handhabung des root-Filesystems ist es - mit zwei zusätzlichen Binaries - möglich, die Abarbeitung der debug.cfg (aka rc.user) direkt auf der FRITZ!Box 7490 wieder zu aktivieren.
Bereits bei der Abschaffung der debug.cfg in den Labor-Versionen wurde von er13 ja ein Patch und eine Änderung von "fwmod" im Freetz-Trunk eingepflegt, mit denen man sich ein eigenes Freetz-Image ohne freetz-mod erstellen konnte. Einige sind diesen Weg bereits gegangen, andere werden sicherlich noch zögern.
Auch wenn ich i.d.R. das Benutzen von "fremden Übersetzungen" eher ablehne (also die Verwendung von Binaries aus "OpenSource"-Quellen, die von anderen erzeugt wurden, eher nicht empfehlen würde), habe ich mich doch entschlossen, diese Binaries - zusammen mit einigen Shell-Skripten - auch anderen zur Verfügung zu stellen. Ich hoffe, damit noch weiteren Interessenten wieder die Verwendung eigener Software auf einer 7490 ohne großen eigenen Aufwand zu ermöglichen.
Spätestens wenn das dann nicht nur ein paar Skripte unter Verwendung bereits vorhandener Kommandos sind, sondern auch wieder zusätzliche Binaries benötigt werden, würde ich aber wieder auf die vorstehende Bemerkung verweisen und die Verwendung von Diensten(!) auf Basis fremder Binaries eher ablehnen.
Egal, zum Wesentlichen ... die Aktivierung der Abarbeitung der debug.cfg ließe sich ganz einfach in einer Telnet-Session mit den folgenden Kommandos erledigen:
Code:
# mkdir /var/mod;cd /var/mod;wget http://www.yourfritz.de/modfs_7490.tgz;md5sum modfs_7490.tgz
Connecting to www.yourfritz.de (85.214.20.177:80)
modfs_7490.tgz 100% |*****************************************************************************************************| 88407 0:00:00 ETA
[B][COLOR="#0000FF"]7a40c2100172059e88ff20063e104c2e[/COLOR][/B] modfs_7490.tgzWichtig ist es in jedem Falle, daß die oben farbig dargestellte Prüfsumme auch wirklich stimmt, ansonsten wurde das Archiv irgendwie modifiziert und man sollte die Finger davon lassen.
Weil ich gerade beim "Finger davon lassen" bin, mir ist genauso wenig zu trauen, wie jedem anderen Anbieter von nicht zu überprüfender Software auch. Wer also meiner Beschreibung folgt, tut dies absolut auf eigenes Risiko. Allerdings kann ich mir keinen Schaden vorstellen, der größer wäre, als er bei einem "normalen" Flashvorgang auch sein könnte. Insofern sollte im Falle eines unerwarteten Abbruchs spätestens mit dem AVM-Recovery-Programm jedes Problem wieder zu beseitigen sein.
Wenn jemand für das Archiv modfs_7490.tgz die Hashes mit anderen Programmen prüfen will, hier sind die Werte für einige andere gängige Algorithmen:
Code:
MD5: 7a40c2100172059e88ff20063e104c2e
SHA-1: b7c1c974ed3c2a8c559265489f6d65672245c44e
SHA-256: 6ee3ae9dd15aae6e7470494fb7befbadf33aec08782dac2ae78c0f4f6a98a117
SHA-512: e93c16f83a669a046c390a4caa583345566937275da18d6ab7c8bb7866332f30ea4d3711fbe9a485cafac1f6953af06b8e15921ad891366daf094ad1949ba6a5
SHA3-256: 9a4d67baf5a2a1f734a22c1b00d1da4530749a4c07a73bd9a19ff71b81c505b5
SHA3-512: 3de8aacf8f0d47f440e00da9b987735e1c61d29c784fd57f129ff65d4354a99889c12b08731ba65b4563c109fbf1ef5e4652a33a0f407db2d9088d48d8aaf5eeWenn wir jetzt sicher sind, daß das Archiv auch wirklich das richtige ist, können wir weitermachen:
Code:
# gunzip -c modfs_7490.tgz | tar x
# ls -la
drwxrwx--- 3 root root 360 Sep 8 15:30 .
drwxr-x--- 21 root root 1400 Sep 8 15:23 ..
-r--r--r-- 1 root root 18092 Sep 3 10:47 COPYING
-r--r--r-- 1 root root 9030 Sep 8 15:14 README
-rwxr--r-- 1 root root 274 Sep 1 19:41 check_7490_kernels
-r--r--r-- 1 root root 804 Sep 8 15:15 checksums
-rwxr--r-- 1 root root 1349 Sep 3 15:14 copy_7490_systems
-rwxr-x--- 1 root root 864 Sep 8 14:44 extract_7490_rootfs
-rwxr-x--- 1 root root 998 Sep 8 14:09 get_7490_freshcopy
-rwxr-xr-x 1 root root 105824 Sep 3 09:57 mksquashfs
-rwxr--r-- 1 root root 1460 Sep 3 17:15 mod_7490_rootfs
-rw-rw---- 1 root root 88407 Sep 8 15:23 modfs_7490.tgz
drwxr-xr-x 2 root root 100 Sep 8 15:30 modscripts
-rwxr--r-- 1 root root 488 Sep 3 15:20 prereq_7490
-rwxr--r-- 1 root root 508 Sep 2 20:12 rep_7490_rootfs
-rwxr--r-- 1 root root 484 Sep 2 20:12 switch_7490_system
-rwxr-xr-x 1 root root 56420 Sep 3 09:57 unsquashfs
-rwxr--r-- 1 root root 1778 Sep 8 15:15 update_7490
# ./prereq_7490
COPYING: OK
README: OK
check_7490_kernels: OK
copy_7490_systems: OK
extract_7490_rootfs: OK
get_7490_freshcopy: OK
mksquashfs: OK
mod_7490_rootfs: OK
prereq_7490: OK
rep_7490_rootfs: OK
switch_7490_system: OK
unsquashfs: OK
update_7490: OK
modscripts/edit_rcuser: OK
modscripts/mod_profile: OK
modscripts/mod_rc_tail_sh: OK
Ok, it looks like your system could be updated now. Simply execute './update_7490' and be patient while building the new root file system.Eine der Voraussetzungen für den erfolgreichen Einsatz der Skripte ist, daß die Box in den beiden verfügbaren Flash-"Versionen" dasselbe FRITZ!OS enthält. Die Modifikation zur Reaktivierung der debug.cfg erfolgt nämlich so, daß das root-Filesystem des laufenden FRITZ!OS (in der Datei /wrapper/filesystem_core.squashfs enthalten und per loop-Device als / gemounted) entpackt, anschließend modifiziert und dann wieder zu einem SquashFS gepackt wird. Dieses neue SquashFS wird dann in die nicht-aktive Filesystem-Partition kopiert und anschließend auf den Start aus der anderen "Flash-Variante" umgeschaltet. Beim nächsten Start der Box wird dann das neue root-Filesystem mit den ausgeführten Änderungen benutzt.
Sollten auf der Box noch zwei unterschiedliche System sein (z.B. direkt nach einem Update mit einem neuen AVM-Image), sähe das in etwa so aus:
Code:
# ./prereq_7490
COPYING: OK
...
modscripts/mod_rc_tail_sh: OK
There are different kernel images at your box.
To copy the running system to the other partition, execute './copy_7490_systems'.
Code:
# ./copy_7490_systems
info 0x0
{mtd_info} type 0x4
{mtd_info} size 0x400000
{mtd_info} erasesize 0x20000
{mtd_info} writesize 0x800
{mtd_info} oobsize 0x40
[main] written 0x20000 Bytes
...
[main] written 0x20000 Bytes
[main] exit error 0
info 0x0
{mtd_info} type 0x4
{mtd_info} size 0x3000000
{mtd_info} erasesize 0x20000
{mtd_info} writesize 0x800
{mtd_info} oobsize 0x40
[main] exit error 0Zur Sicherheit empfehle ich die Box nach dieser "Gleichmacherei" neu zu starten und von vorne zu beginnen.
Im nächsten Schritt wird jetzt das root-Filesystem des laufenden FRITZ!OS ausgepackt (dazu dient das unsquashfs) und anschließend werden alle im "modscripts"-Verzeichnis liegenden Shell-Skripte (in aufsteigender alphabetischer Reihenfolge der Dateinamen) abgearbeitet. Diese Skripte kriegen als einzigen Parameter den Pfad zum "root-Verzeichnis" des entpackten SquashFS übergeben und können nun ihrerseits die dort liegenden Dateien modifizieren.
Ich habe meinerseits dort drei Skripte bereits hinterlegt, das entscheidende dürfte 'mod_rc_tail_sh' sein:
Code:
# cat modscripts/mod_rc_tail_sh
# DESC
# modify /etc/rc.tail.sh to execute the commands at TFFS node 98, if it's not empty
# QUESTION
# Do you want to apply that modification ?
sed -e '$ircuser=/var/tmp/rc.user;mkconfigfile $rcuser.tffs 98;! checkempty $rcuser.tffs && cat $rcuser.tffs >$rcuser && delay -d 1 USER "/bin/sh $rcuser";rm $rcuser.tffs' -i "$1/etc/init.d/rc.tail.sh"1. Der Init-Prozess ist praktisch abgeschlossen, die meisten AVM-Prozesse laufen schon.
2. Die Abarbeitung der debug.cfg erfolgt jetzt asychron zum Init-Prozess, in der debug.cfg auftretende Fehler beeinflussen die weitere Abarbeitung der rc.tail.sh nicht mehr.
3. Durch die Nutzung von multid (über das delay-Kommando) werden solche Spiele wie nohup o.ä. unnötig.
Selbstverständlich ist das aber nur eine denkbare Modifikation des Filesystems. Wer es lieber mag, wenn seine eigenen Skripte eher bei einer Änderung des Online-Status der Box ausgeführt werden, schreibt sie eben nach /etc/onlinechanged. Auch diverse andere Änderungen, für die ansonsten die debug.cfg bisher immer "zu spät" kam im Init-Prozess, lassen sich mit einem Einzeiler realisieren:
Code:
sed -e "/^nicename/alocal \$(/sbin/blkid /dev/\\\${1}\\\${3} | sed -n -e 's/^[^ ]* \\\(.*\\\)/\\\1/p');[ \${#LABEL} -gt 0 ] && eval echo \$LABEL && return" -i "$1/etc/hotplug/udev-mount-sd"Ich habe aus meinem Vorrat an Skripten nur noch zwei weitere bereits in das Paket integriert.
Das erste modifiziert die Datei /etc/profile so, daß als letzte Aktion das Vorhandensein einer Datei /var/custom/profile getestet wird und - so diese Datei existiert - die dort stehenden Kommandos auch noch abgearbeitet werden. Da das ja bei jedem Shell-Login passiert, kann man dort gut noch weitere eigene Modifikationen einbauen, die nicht unbedingt im root-FS liegen müssen und man spart sich trotzdem das bind-Mount für die nachträgliche Änderung der /etc/profile.
Das zweite zusätzliche Skript erzeugt im neuen root-FS ein zusätzliches Kommando "edit_rcuser", das im Endeffekt nichts anderes als eine Art 'nvi' für die rc.user (AVM nannte sie ja debug.cfg) ist und das Editieren der Datei auch dann erlaubt, wenn es kein "char-Device" dafür in /var/flash gibt (ansonsten einfach mal in die README schauen).
Auch die komplette Integration eigener Binaries und Skripte direkt ins root-Filesystem ist natürlich machbar, wenn man die entsprechenden Skripte dafür vorbereitet. Das geht von der Korrektur kleiner nerviger Probleme (z.B. ist es problemlos möglich, die VPN-Verbindungen wieder in die Übersicht zu bringen oder den FTP-Server wirklich komplett abzuschalten - der kann zwar AUTH TLS auch nach innen, aber wer benutzt das schon wirklich und schickt nicht spätestens beim FTP-Zugriff dann im LAN die Credentials im Klartext durch die Gegend) bis zur Integration eines SSH-Servers anstelle des doch eher unsicheren Telnet-Zugangs. Wenn man dann den Link zum Busybox-telnetd (/usr/sbin/telnetd) mit einem Link zu einem passenden Skript für den Start des Dropbear ersetzt, kann man diesen sogar über die Tastenkombination von AVM für den Telnetd ein- und ausschalten. Der Phantasie sind also fast keine Grenzen gesetzt, das muß halt nur alles in einem Skript im Unterverzeichnis passieren, solange man das "update_7490"-Skript unverändert benutzen will. Die Skripte müssen dann natürlich auch vor dem Start von "update_7490" ins richtige Verzeichnis gelegt werden.
An Platzmangel wird das ja bei einer 7490 nicht so schnell scheitern, da paßt noch so einiges hinein ... auch die Integration der SquashFS-Hilfsprogramme in das root-Filesystem trägt nicht merklich auf, die Skripte kann man auch irgendwo im System lagern.
Wie weitere Änderungen bewerkstelligt werden könnten (es führen in der Shell immer mehrere Wege zum Ziel), steht wieder in der README.
Das ist zweifellos natürlich auch alles mit einem eigenen Freetz-Image möglich, aber gerade die "Bastler", die desöfteren mal neue Software in ihr Image integrieren wollen, werden vielleicht die Vorteile auch zu schätzen wissen, daß man mit den Skripten und dem Boot-Manager in Kombination ziemlich gefahrlos eigene Sachen ausprobieren kann, ohne auf ein Recover oder Downgrade zurückgreifen zu müssen. Man muß lediglich beachten, daß die Änderungen kumulativ sind, da ja
EDIT: Neu ist jetzt auch die Möglichkeit, durch die Angabe von 'fresh' als Parameter für den Aufruf des update_7490-Skripts auch ein "frisches" Firmware-Image vom AVM-Server laden zu lassen und die Änderungen dann auf das root-Filesystem in diesem Image anzuwenden. Das setzt allerdings voraus, daß auf dem AVM-Server auch ein passendes Image liegt (und das gilt auch nur für die deutsche Version der Firmware, solange man das Skript 'get_7490_freshcopy' nicht selbst modifiziert - dann aber die MD5-Prüfung in update_7490 auch ausschalten oder den Inhalt von 'checksums' entsprechend korrigieren).
Ansonsten muß man eben den Download aus einer passenden Quelle von Hand ausführen und kann dann durch den Aufruf von
Code:
# image=$(./extract_7490_rootfs [I]image_file[/I]);mv $image /var/media/ftp/${image##*/};rm -r ${image%/*}
Code:
# ./update_7490 /var/media/ftp/filesystem_core.squashfs:doktor:
Bitte auch immer darauf achten, daß im tmpfs ausreichend freier Speicher zur Verfügung steht. Nach meinen Tests sind ~ 90 MB freier Speicher in /var erforderlich. Wer also dort 3 verschiedene Firmware-Images als Downloads liegen hat und dann trotzdem die Skripts startet, wird wahrscheinlich nur seine Zeit vergeuden, da spätestens beim Packen des neuen Filesystems dann wohl der freie Platz im tmpfs ausgehen wird.
Also weiter im Text. Als nächstes wird jetzt also das root-Filesystem entpackt (das rekursive Kopieren aus / war mir persönlich zu kompliziert angesichts der u.U. dort schon erfolgten Modifikationen durch bind-Mounts o.ä.) und die Skripte zur Modifikation abgearbeitet. Anschließend wird das Ganze wieder zusammengepackt. Dabei werden absichtlich alle Dateien im neuen SquashFS aufgelistet, da der Vorgang zwischen 3 und 5 Minuten dauern kann, dient die Ausgabe gleichzeitig als "Lebenszeichen" des mksquashfs.
Code:
# ./update_7490
check_7490_kernels: OK
...
scripts/mod_rc_tail_sh: OK
3770 inodes (4278 blocks) to write
[==================================================================================================/] 4278/4278 100%
created 3175 files
created 219 directories
created 509 symlinks
created 86 devices
created 0 fifos
Parallel mksquashfs: Using 2 processors
Creating big endian 3.1 filesystem on repacked.sqfs, block size 65536.
mksquashfs: file squashfs-root/bin/allcfgconv, uncompressed size 9496 bytes
...
mksquashfs: directory squashfs-root inode 0x95ae1d93
Exportable Big endian filesystem, data block size 65536, compressed data, compressed metadata, compressed fragments, duplicates are removed
Filesystem size 21496.82 Kbytes (20.99 Mbytes)
38.60% of uncompressed filesystem size (55697.67 Kbytes)
Inode table size 40638 bytes (39.69 Kbytes)
31.14% of uncompressed inode table size (130511 bytes)
Directory table size 39654 bytes (38.72 Kbytes)
49.32% of uncompressed directory table size (80405 bytes)
Number of duplicate files found 1357
Number of inodes 3989
Number of files 3175
Number of fragments 244
Number of symbolic links 509
Number of device nodes 86
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 219
Number of uids 1
root (0)
Number of gids 0
Your alternative system will use the modified root file system now. Please reboot to activate the alternative system.Jetzt noch schnell das Verzeichnis /var/mod entsorgt, um den dort belegten Platz im RAM für den Neustart des Systems (eigentlich eher für das Beenden der AVM-Prozesse) wieder zur Verfügung zu stellen, und wir können die Box neu starten.
Code:
# cd /;rm -r /var/mod
# reboot
# killall: printserv: no process killed
stopping hd-idle
storage:unmounting /var/media/ftp/WDCWD16-00BEVE-11UYT0-02
storage:unmounting /var/media/ftp/WDCWD16-00BEVE-11UYT0-03
rmmod: can't unload 'vfat': unknown symbol in module, or unknown parameter
rmmod: can't unload 'fat': unknown symbol in module, or unknown parameter
rmmod: can't unload 'nls_cp437': unknown symbol in module, or unknown parameter
rmmod: can't unload 'nls_iso8859_1': unknown symbol in module, or unknown parameter
rmmod: can't unload 'sd_mod': Resource temporarily unavailable
rmmod: can't unload 'ext2': unknown symbol in module, or unknown parameter
rmmod: can't unload 'usb_storage': Resource temporarily unavailable
rmmod: can't unload 'scsi_mod': Resource temporarily unavailable
XHCI USB 3.0 Host stopped
cat: can't open '/proc/bus/usb/devices': No such file or directory
cat: can't open '/proc/bus/usb/devices': No such file or directory
ls: /var/USB-proc-bus-usb-*: No such file or directory
[2521]++ ++ do internalflash 'prepare unmount'... ++ ++
[2521] WARNING: /var/media/ftp still used by process 1951
1951 root 3504 S contfiltd
[2521]++ ++ ...done ++ ++
Sep 1 22:57:10 chronyd[2430]: Source 192.168.xxx.2 offline
Sep 1 22:57:10 chronyd[2430]: Can't synchronise: no reachable sources
Connection closed by foreign host.Zum Editieren der Kommandos in der "rc.user" (oder meinetwegen auch debug.cfg) empfehle ich die Verwendung von 'edit_rcuser', wenn man das hat erzeugen lassen.
Auch beim Editieren der Kommandos unter dem Dateinamen "/var/flash/debug.cfg" (der existiert ja nicht, solange man ihn nicht selbst als char-Device anlegt) ist bei der 7490 besondere Vorsicht anzuraten. Anders als andere Modelle hat die 7490 auf /var/flash kein tmpfs ("geerbt" von /var) sondern ein NAND-Flash (/dev/mtdblock4) gemounted, wenn man dort eine reguläre Datei anlegt, überlebt diese - eben anders als bei den anderen Modellen - auch einen Neustart. Das kann - wenn man sich darauf verläßt, das bei einem Neustart schon alles in /var/flash ordentlich "restauriert" wird - auch mal eine böse Überraschung geben, wenn dann eine vorhandene reguläre Datei das Anlegen eines char-Devices für den TFFS-Inhalt verhindert und plötzlich eine leere Einstellungsdatei daraus entsteht.
Eigentlich bilden also die Skripte und die beiden Hilfsprogramme zum (Ent-)Packen des SquashFS nur eine Art "Framework", was man damit machen will, muß man sich selbst überlegen. Der eine baut mit 6 Kommandos per C&P von hier einfach wieder die debug.cfg in seine Box ein, der andere modifiziert bei der Gelegenheit gleich noch das GUI der Box dauerhaft für seine Zwecke oder schaltet durch Änderung der provider-049.tar das TR-069 für seinen Provider richtig aus (irgendwann wird auch wieder eine einheitliche Umsetzung für die verschiedenen Modelle einziehen).
Noch ein paar Bemerkungen zur Sicherheit:
Erstens benötigt man zur Benutzung des Paketes den Zugang zur Kommandozeile der FRITZ!Box. Wenn ein Unbefugter diesen erlangt, ist ohnehin schon alles zu spät. Insofern wird die Sicherheit per se nach meinem Dafürhalten nicht geschmälert ... wenn man die Änderungen an seiner Box nicht vornimmt, ändert sich gegenüber dem AVM-Original absolut nichts.
Zweitens ist mir sehr wohl bewußt, das ein Angreifer nach demselben Prinzip auch die Box gegen den Willen des Besitzers modifizieren könnte. Aber ich bin auch der Überzeugung, daß ein potentieller Angreifer dazu nicht meine Anleitung benötigen würde und daß dieser sicherlich wesentlich finsterere Absichten und mindestens genauso viel Kenntnis des FRITZ!OS hätte. Die Zeiten, als das noch "Script-Kiddies" ohne eigene Erfahrungen und Ideen waren, sind lange vorbei.
Drittens kann ich damit auch mal zeigen, daß die permanente Modifikation des FRITZ!OS - immer unter der Voraussetzung, ein Angreifer erlangt Shell-Zugriff - nicht nur theoretisch möglich ist. Dieselbe Vorgehensweise läßt sich natürlich auch für ein anderes Modell adaptieren, da läuft dann nur der Flashvorgang etwas anders (im Rahmen eines Neustarts) und im Falle eines Problems brickt der Angreifer die Box (was bei genauer Überlegung ja sogar von Vorteil wäre). Bei einigen Modellen mag es sogar am Speichermangel im RAM scheitern, dann würde ein Angreifer das eben "extern" ausführen.
Es ist also ein sehr reales Szenario, daß bei Shell-Zugriff das System der Box (fast) mit Bordmitteln modifiziert werden kann. Daraus leitet sich dann wieder für mich die Folgerung ab, auf jede nur erdenkliche Weise den Shell-Zugriff für einen Unberechtigten zu unterbinden. Dazu gehört es eben auch, selbst im LAN nur verschlüsselt mit der Box zu kommunizieren. Selbst wenn man vielleicht nicht direkt ein Kennwort für den Zugriff "sniffen" kann, der Mißbrauch einer SID nach gezielter Ausschaltung des berechtigten Benutzers (oder nachdem der "fertig hat" mit der Box ohne sich abzumelden) ist nun wirklich kein Hexenwerk.
Ich werde direkt im Anschluß einen Patch für das Erzeugen der beiden Binaries als Freetz-Package auf freetz.org hochladen (erst einmal nur für die 7490), der dann hoffentlich in nicht allzu ferner Zukunft seinen Weg in den Trunk findet. Das unsquashfs-Binary aus der vorhergehenden Version (in debugcfg_7490.tgz) hatte ein Problem mit dem Entpacken eines bereits vom zugehörigen mksquashfs "behandelten" Images, da wurde eine falsche Versionsnummer des SquashFS angegeben.
Ich habe nur keine Lust mehr auf das Hinzufügen des GPLv2-Hinweises zu den ganzen Files, da sich dann auch wieder die Hashes ändern und ich zumindest dort von vorne beginnen müßte. Sowie der Patch (damit wäre dann auch das Veröffentlichen der Quellen nach GPL für mich erledigt) verfügbar ist, ändere ich diesen Beitrag noch einmal. Vielleicht entschließe ich mich dann ja doch noch zur Änderung der Skripte, inkl. der Aktualisierung der o.a. Hashes.
Ich habe das Paket um eine README-Datei und die entsprechenden Lizenzhinweise auf die GPLv2 ergänzt.
Zuletzt bearbeitet:
