Ich würde (logisch) zu Variante 1 greifen ... für die letzte Release-Version (also den älteren 3.10.73-Kernel und die alte uClibc) gibt es ein fertiges Image im "first_aid"-Repository und man braucht parallel nur noch eine der Möglichkeiten, die Firmware in den Speicher der Box zu bringen. Unter Windows sind das drei Downloads (die beiden PS-Skripte + das Image) und ca. 5 Minuten. Das ändert auch die aktuell installierte Version vom Provider - wobei "o2" davon eher nichts mitkriegen würde. Die Änderung überlebt das Update auf die nächste Version nicht - das ist aber Absicht.
Beim Einsatz einer Inhouse-Version kriegt der Provider die Änderung mit (solange TR-069 aktiv bleibt), denn die Informationen im "INFORM"-Request ändern sich ebenfalls ... von der Versionsnummer bis zu möglichen Änderungen an den implementierten TR-069-Interfaces.
Die ganzen Downgrade-Varianten gehen zwar ... die Frage wäre nur, warum man sich den Aufwand (inkl. Beschaffung von alten Images, Sicherung der "provider_additive.tar", Entfernen der "provider"-Sicherung im Environment, usw.) und Verlust von Einstellungen (und nicht alles wird bekanntlich wieder importiert) überhaupt antun will, wenn man in Wirklichkeit gar nichts von dieser Firmware will.
Das wäre ja nun wirklich der denkbar komplizierteste Weg, wie man die Aufgabenstellung angehen könnte ... was natürlich nicht heißt, daß er nicht funktioniert. Nur der Sinn des Ganzen, wenn man die leichteren Wege auch kennt und verstanden hat (und die beinhalten ja eigentlich auch keine anderen Schritte, für die man zusätzliche Kenntnisse o.ä. bräuchte und die beim Downgrade dann wegfallen können, denn wenn man am Ende ein (aktuelles) System mit Shell-Zugang in der Box haben will, ist es rein mit Recovery ja noch nicht getan und man muß schon noch weitere Schritte gehen), erschließt sich mir halt nicht ... ich kann auch von Berlin erst nach Hamburg fahren, um den ICE Hamburg-München zu nehmen, aber ich muß das nicht tun.
Für ein komplettes Freetz-Image braucht es (wie für die meisten anderen Schritte, wenn man nicht auf das fertige Image und die PS-Skripte zugreift) dann das eigene Linux ... und bei einem Freetz-Image auch noch ein deutlich "umfangreicheres" Linux (und mehr Zeit), als bei Variante 1, selbst wenn man sich das eigene Image erst mit den "toolbox"-Skripten erstellen lassen müßte.
Es führen also viele Wege nach Rom ... die einen direkt, die anderen über die Seidenstraße. Das Restaurieren ist auch bei der SIAB-Variante ganz einfach ... man setzt mit dem letzten eigenen Shell-Zugriff das "tainted"-Flag in TFFS-Node 87 zurück (das würde erst bei der nächsten Anmeldung erneut gesetzt) und installiert (per Datei) einfach noch einmal dieselbe Firmware, die gerade installiert ist (das sollte sogar übers GUI problemlos funktionieren, weil nur Downgrades blockiert werden - notfalls macht man es eben über den Bootloader) und der SIAB-Zugang ist wieder verschwunden.
So ein Update ist leider notwendig, weil bei der SIAB-Installation Dateien überschrieben werden (müssen), deren Restaurierung viel zuviel Aufwand wäre (deshalb gibt es auch - anders als beim ersten "modfs-Starter" - hier keine Vorkehrungen für ein "uninstall"), weil das mit einer neuerlichen Installation der Firmware (bei der ja auch nichts anderes verloren geht, als genau diese SIAB-Installation) viel einfacher zu realisieren ist. Selbst wenn man davor vergessen hat, das "tainted"-Flag zurückzusetzen ... dann kann man das immer noch nachträglich mit einem einzelnen Start des passenden Images (dafür gibt es ein "toolbox"-Skript und für die 7490 auch wieder das fertige Image in "first_aid") löschen lassen.
Bei GRX-Boxen wird es dann halt schwieriger ... aber die VR9-Modelle mit dem YAFFS2-Dateisystem sind da sehr dankbare Patienten, weil man dessen Inhalte sehr leicht auch dauerhaft ändern kann. Bei den GRX-Boxen geht das im Prinzip auch, wenn man das SquashFS-Image ändert ... da beim Laden in den Speicher über den Bootloader der verfügbare Hauptspeicher begrenzt werden muß, braucht man (für das Packen) eigentlich wieder Swap-Space und damit den USB-Stack. Ich habe mal mit ein paar Experimenten in dieser Richtung angefangen (auch ohne Swap-Space, weil man ja eigentlich keine weiteren AVM-Dienste starten muß für solche Modifikationen) ... aber am Ende ist das auch recht umständlich.
Wenn man ohnehin so ein Image zum Modifizieren bauen muß (und das ist etwas umfangreicher als die VR9-Toolbox-Images), kann man irgendwie auch gleich die komplette Firmware nehmen und entsprechend modifizieren. Der einzige Vorteil des "umständlichen" Weges wäre es, daß man dabei auch Images erstellen und selbst verbreiten kann (wie die in "first_aid"), ohne gegen die Bestimmungen in der AVM-Lizenz zu verstoßen, solange man nur den Kernel und GPL-Programme dafür verwendet.
Leider geht es aber schon bei der Frage der LEDs dann los ... wenn man irgendwelche länger laufenden Sachen auf der Box macht (und das Einpacken eines SquashFS-Images dauert etwas), möchte man das ja auch irgendwie nach außen signalisieren ... aber schon die komplette LED-Ansteuerung macht AVM eben nicht auf den "Lantiq-Weg", wo es am Ende sogar Zugriff auf die LEDs über das "procfs" gäbe, sondern da geht man den eigenen Weg mit dem LED-LKM (was zugegebenermaßen dann auch noch einen "Stack" für die Zustände verwaltet und nach dem Wegfall einer Kondition auf den vorherigen Stand der LEDs zurückschalten kann) und das ist natürlich auch der einzige, der in dem AVM-Kernel unterstützt wird ... dessen "Nachnutzung" ist aber der Knackpunkt bei diesem gesamten Vorgehen. Wenn man sich erst noch den eigenen Kernel kompilieren muß, ist dieser Weg (wie er hier im Thread beschrieben wurde) Nonsens.
Bei den VR9-Boxen kann man sich wieder mit direktem "memory mapped I/O" für die LED-GPIO-Pins behelfen und bei der 6490 hat AVM sogar noch das GPIO-Interface unter "/sys/class/gpio" im Kernel, über das man die LEDs auch steuern kann, wenn man den richtigen Pin kennt ... aber bei den GRX-Boxen (und um die ginge es beim Packen des SquashFS-Images auf der Box ja gerade) sind die noch mal hinter einem Multiplexer versteckt und da kommt man mit den "üblichen" I/O-Möglichkeiten (z.B. über das "devmem"-Applet in der BusyBox) nicht mehr ohne weiteres ran. Mit eigenem Treiber wieder kein Problem ... heißt aber auch wieder eigener Kernel oder zumindest, daß man immer den passenden Treiber zum AVM-Kernel zusätzlich bereithalten (und zuvor natürlich erst mal erzeugen) müßte.
Alles das hat ja am Ende dazu geführt, daß ich bei GRX-Boxen die "Technik" des "modfs"-Projekts nicht fortsetzen will (irgendein Weg würde sich schon finden lassen - nur wäre der eben in meinen Augen komplizierter, als wenn man gleich außerhalb der Box das passende Image zusammenstellt) und an anderen Wegen arbeite.
-----------------------------------------------------------------------------------------------------
Der präferierte Weg ist es für mich im Moment, die Box mit einem eigenen öffentlichen Key für das Signieren von Images "zu impfen" (das geht - mit ein paar Kniffen - sogar bei den GRX-Modellen und zwar auch mit der originalen AVM-Firmware und ist der einzige Schritt, der dann tatsächlich auch den Zugriff auf den Bootloader braucht ... aber mit so fest definierten Abläufen und über alle Modelle einheitlich, daß man das tatsächlich - so wie AVM's Recovery-Programm - fix vorgeben kann und der Benutzer nicht länger "von Hand" irgendwelche Funktionen aufrufen müßte) und dann kann man auf diesem Key aufbauen und die diversen, von AVM bereits selbst vorgesehenen und genutzen Mechanismen in der originalen Firmware "nachnutzen".
Das geht dann von der Akzeptanz selbst-signierter Images beim dateibasierten Update (wo man dann ggf. wieder mit den alten Problemen der "Pseudo-Updates" zu kämpfen hat, daß vor deren Start erst mal das System weitgehend heruntergefahren wird) bis zu den DECT-Updates per USB-Stick ... denn auch wenn da ein fester Name gesucht wird (je nachdem, wofür so ein Update sein soll), kann man auch dort in der "var/install" problemlos eigene Befehle unterbringen, solange das Image nur eine Signatur hat, die von der Firmware akzeptiert wird ... und da wird nicht erst das halbe System gestoppt, bevor das "install"-Skript zur Ausführung gelangt.
Der eigentliche Knackpunkt für "Modifikationen für Dummies" ist also die Frage, wie man den eigenen öffentlichen Key in die Firmware bugsiert ... und hier ist AVM durchaus dadurch hilfreich, daß bisher halt nur RSA-Keys mit 1024 Bit verwendet werden. Deren Modulus (das ist praktisch der öffentliche Teil des Schlüssels, denn der Exponent ist fix und bei AVM immer 65537) paßt in hexadezimaler Kodierung (es ginge natürlich auch mit Base64 noch kürzer) ziemlich genau in eine Environment-Variable einer FRITZ!Box (256 Byte) und da gibt es (derzeit zumindest) noch so einige, die von AVM nicht (mehr) genutzt werden. Ein Beispiel wären die "bb
n"-Einträge - hier kann man wunderbar zusätzliche öffentliche Schlüssel hinterlegen, die dann nur irgendwie von der Firmware in "richtige Dateien" überführt werden müssen, bevor man zu einer Signaturprüfung gelangt ... aber der Weg dafür, wäre eben immer derselbe (und damit einer, den man auch am Stück vorbereiten kann), während der konkrete eigene Schlüssel wieder aus dem Environment käme und man damit weiterhin "sicher" bleibt.
Dazu trägt es auch bei, daß man Environment-Einträge mit 256 Byte für den Wert tatsächlich nur über den Bootloader einrichten kann ... aus dem System heraus ist die gesamte Zeile zum Schreiben auf max. 256 Byte begrenzt und man kriegt deshalb (wegen der 4 oder 5 Zeichen für den Namen der Variablen und das erste Trennzeichen) keinen kompletten Modulus in einen solchen Wert, wenn man es aus dem laufenden FRITZ!OS heraus versucht. Ein Angreifer auf das laufende System kann also keinen eigenen Schlüssel dort eintragen ... wer an den Bootloader kommt und dort etwas anderes eintragen kann, dem steht die Box ohnehin sperrangelweit offen.
Da man diesen Key eben über den Bootloader setzen kann, gehört das auch zu den automatisierbaren Abläufen ... die exakten Einstellungen für eine spezielle Box sind auf diesem Weg von allen Skript-Inhalten und allen notwendigen Modifikationen der Firmware entkoppelt und man kann solche Änderungen und Skript-Dateien erstellen und anbieten, ohne daß sich deren Benutzer dabei automatisch ins Knie schießen, weil die Sicherheit ihrer Geräte damit aufgeweicht wird.
Was der Einzelne dann aus den Möglichkeiten, ein selbst-signiertes Image zu laden und die dort enthaltene "var/install" zur Ausführung zu bringen, macht, steht wieder auf einem anderen Blatt ... aber dieser eigene öffentliche Key, den die Firmware auch zur Prüfung heranzieht, ist am Ende für mich "der Schlüssel" für alles weitere.
Ein paar der Skripte für diesen Weg gibt es auch schon ... das Einbinden eines solchen Keys in die laufende Firmware (allerdings nicht das Auslesen aus dem Environment, weil das ja nicht die einzige Möglichkeit zur Bereitstellung eines Modulus ist und bleiben soll) ist z.B. hier realisiert (und getestet):
https://github.com/PeterPawn/YourFritz/blob/master/framework/implant_public_key - dem Skript wirft man nur noch den gewünschten Weg der "Impfung" und den Modulus vor die Füße und um den Rest kümmert es sich selbst und zwar bei VR9-, GRX- und Puma-Boxen, jeweils mit "fallback", falls ein Weg nicht funktioniert aufgrund des Modells. Das Skript kann man dann wieder über NAS-Verzeichnisse auf die Box bringen ... das eigentliche Problem ist, wie man es zur (erstmaligen) Ausführung bringt und zwar auch mit der originalen AVM-Firmware.
nur ist dies irgendwo eher die Ausnahme.
