Die Abläufe beim "eva_to_memory" habe ich mal im Thread zum "modfs-Starter" beschrieben, zusammen mit einer Erklärung, wie man ein solches Image "von Hand" erstellen könnte.
Ansonsten erwartet "eva_to_memory" halt eine FRITZ!Box, die auf eine FTP-Verbindung zum Bootloader reagiert - wie die dahin kommt, interessiert das Skript nicht wirklich.
Aufgerufen wird es mit einem oder zwei Parametern, der erste ist der Dateiname eines passenden Images (welche Voraussetzungen das erfüllen muß, ist auch irgendwo mehrfach beschrieben und diskutiert) - image2ram würde aus einem "normalen" Image (egal ob "Freetz" oder "AVM original") eine passende Datei erstellen. Der zweite Parameter kann die IP-Adresse der FRITZ!Box sein - fehlt sie, wird 192.168.178.1 verwendet.
Das Skript ermittelt dann die Größe des Images und errechnet aus der Größe des Hauptspeichers und des Images einen neuen (temporären) Wert für "memsize" und eine Ladeadresse für das Image im RAM der Box. Dann werden diese errechneten Werte in der Box gesetzt (inkl. "kernel_args_tmp" mit der korrekten Beschreibung des RAM-Images) und im letzten Schritt wird dann die Image-Datei zur Box übertragen. Tritt dabei kein Fehler auf, startet die Box dieses Image nach der Übertragung ... das heißt dann, der Rest der FTP-Session "fällt aus" und die Box beendet ihrerseits einfach die Verbindung.
Das funktioniert aber nur für Boxen, die zur Beschreibung des Images im RAM auf den Parameter "mtdram1" setzen (findet man in den Kernel-Quellen für das jeweilige Modell) ... die 6490 gehört da (so wie es "eva_to_memory" im Moment macht) aber ohnehin nicht dazu, dort ist das Skript also auch nicht wirklich "zielführend". Die 6490 verwendet ja auch keine (Init-)Skripte, mit denen ein ins RAM geladenes System sich selbst in die korrekten Partitionen schreibt - das machen m.W. die Versionen mit einem "Wrapper"-Filesystem (über die /etc/inittab im Wrapper und einen dort enthaltenen Aufruf von "/sbin/flash_update" im Wrapper-FS) und die GRX500-Modelle (7560/7580), wobei bei letzteren das über das "normale" Filesystem und die dort liegende "/etc/init.d/E03-flash_update" (aus dem Kopf, ohne Gewähr) erfolgt.
Für die 6490 bringt "eva_to_memory" also gar nichts und für die (erste) Installation eines Freetz-Images reicht (sofern die Box im richtigen "Modus" ist), einfach ein "eva_to_memory <image_file>". Wer das neue System in die inaktive Partition schreiben lassen will, kann einfach vorher noch die Variable "linux_fs_start" auf den alternativen Wert setzen ... dann schreibt sich auch ein nicht weiter modifiziertes System ("wenn man keine Vorkehrungen trifft") in die richtige (sprich, die zuvor inaktive) Partition.
-Auch wenn das Signieren (bzw. der wichtigere Einbau eines eigenen öffentlichen Schlüssels) auf den ersten Blick bei einem Freetz-Image keinen unmittelbaren Vorteil versprechen mag, so gibt es noch einen weiteren Aspekt, den ich zumindest mal erwähnen möchte (habe ich im "modfs"-Thread letztens bereits einmal getan).
Der "autorun"-Mechanismus von Freetz ist ja ein etwas zweischneidiges Schwert ... wenn der aktiviert ist, kann jeder mit einem physikalischen Zugang zur Box einfach einen USB-Stick mit einem eigenen "autorun.sh"-Skript anstecken (so ist jedenfalls mein Wissensstand, den ich gerne korrigieren lasse, wenn ich etwas übersehen habe) und damit problemlos die komplette Box übernehmen - inkl. Einrichtung zusätzlicher Konten oder Zurücksetzen des Admin-Kennworts oder oder oder ... die Box ist praktisch schutzlos. Das wird zwar m.W. auch "angesagt" bei der Aktivierung oder es steht irgendwo im Wiki, aber es gäbe auch eine wesentlich bessere - oder zumindest sicherere - Lösung.
Setzt man an dieser Stelle nämlich ein (selbst-signiertes) Image für diesen "autorun"-Mechanismus ein, braucht es nur einen einzigen Aufruf einer AVM-Komponente (tr069fwupdate), um die in so einem Image enthaltene Datei "./var/install" nach automatischer Signaturprüfung durch die AVM-Firmware zu starten und dabei kann so ein Image auch noch (fast) beliebige weitere Dateien enthalten (wenn man ein paar wenige Fallstricke beachtet).
Damit hat man dann wieder ein "autorun", was eben keine riesige Sicherheitslücke in das System reißt ... ähnliches könnte man sich auch für die Dateien beim "Externalisieren" überlegen, denn auch das reißt - sofern irgendein "Nicht-Admin" (Schreib-)Zugriff auf den Ort der Speicherung dieser Daten haben sollte (im schlechtesten Fall reicht dafür eine "directory traversal"-Lücke in einer zusätzlichen (Server-)Software, die man in sein Freetz-Image installieren läßt) - eine gewaltige Lücke in das FRITZ!OS.
So, wie "normale" Linux-Distributionen die Integrität ihrer Pakete und Repositories über PGP-Signaturen absichern, so könnte man den AVM-Mechanismus auch selbst (und auch generell für Freetz) "zweckentfremden". Das hat den Vorteil, daß alles dafür Notwendige bereits im FRITZ!OS von AVM enthalten ist (und ohnehin bei den meisten Benutzern drinbleiben muß, sonst gehen auch keine DECT-Update usw.) und man nicht erst mühsam (und platzfressend) eine andere Signaturlösung installieren muß.
- - - Aktualisiert - - -
BTW ... ich weiß ja nicht, wieviele Leute dieses "autorun" dann auch benutzen, aber bei der aktuellen Firmware (die ohne entsprechende Patches USB-Volumes immer mit "noexec" mountet) dürfte das ohnehin nicht funktionieren, so wie es derzeit in der "libmodmount.sh" steht.
EDIT: Es kann natürlich auch sein, daß Freetz da die "udev-mount-sd" auch bei neuerer Firmware soweit "entkernt", daß deises "noexec" von AVM gar nicht zum Zuge kommt. Dann sollte man das vermutlich nachziehen und nur auf ausdrücklichen Wunsch des Benutzers weglassen - gelingt es einem Angreifer, den Suchpfad auf ein solches USB-Volume zu erweitern und dort ein Kommando zu hinterlegen, was bei AVM (oder auch in Freetz, allerdings weiß ich nicht, ob es so etwas dort gibt) ohne (absoluten) Pfad aufgerufen wird, dann würde eine solche Datei auch von einem USB-Volume geladen und ausgeführt - genau dagegen hilft ja die "noexec"-Option beim Mounten.
Je nach installierter Software sollte man sich sogar überlegen, ob man nicht zusätzliche Optionen (z.B. "nodev") auch noch hinzufügen möchte. Richtet jemand dort (also auf einem USB-Volume mit einem geeigneten Dateisystem) ein "device file" für eine TFFS-Partition ein und gibt es eine (Server-)Software auf der Box, die dort (aus so einer Datei) lesen könnte (bei AVM fehlt diese bzw. es wird korrekt "abgelehnt" bei den NAS-Funktionen) und derselbe Angreifer kann diese Software irgendwie ansprechen/benutzen, dann ist im Handumdrehen der komplette TFFS-Inhalt aus der Box extrahiert und bei Schreibzugriff sogar wieder ein modifizierter Inhalt (ggf. inkl. neuer Freetz-Settings samt Admin-Passwort oder -Konto) auf der Box installiert.
