könnte ja auch über EVA ein Image laden dass sich dann booten lässt.
Das ist schon mal der richtige Weg - das funktioniert nämlich bei der 7390 ebenso, wie bei anderen Modellen, auch wenn es eine NOR-Box ist.
Gibts aber doch bestimmt ein image das ich aufspielen kann um dann ne shell oder nen smb Zugriff zu bekommen.
Seitdem ich alle 7390 ausgemustert habe, habe ich auch für dieses Modell kein fertiges Forensik-Image mehr zur Hand ... müßte ich auch erst neu zusammenstellen.
------------------------------------------------------------------------------------------------
Das ist aber ziemlich leicht selbst zu machen ... entweder mit den passenden Programmen von Hand (man braucht Linux, die SquashFS-Tools und ein paar andere (Standard-)CLI-Tools) oder mittels "fwmod" aus dem Freetz-Projekt:
https://freetz.github.io/wiki/help/howtos/development/repack_fw (braucht halt auch Linux und muß erst mal den ganzen "make tools"-Zweig durchlaufen lassen).
Wichtig ist, zunächst mal in den Init-Files in "/etc/init.d" das Laden jedes Treibers zu unterbinden, den man nicht benötigt ... denn meist sind es im Ergebnis einer Überspannung ja die Telefonie-Funktionen, die ein erfolgreiches Booten verhindern (passende Threads findet man mit "7390 boot loop" o.ä.) und dann sollte man deren Treiber möglichst nicht laden, weil diese beim Feststellen von Hardware-Schäden schnell mal zur Kernel-Panic greifen. Am besten wirft man alle Init-Skripte raus, die nichts mit dem zu tun haben, was man mit dem zu erstellenden Image machen will.
Wenn die Netzwerk-Hardware noch komplett in Ordnung ist, kann es bereits ausreichen, wenn man ISDN, POTS, DECT, WLAN (das wäre zwar automatisch raus, wenn es kein Plugin im NAND-FS gäbe, aber das wird wohl dort liegen, wenn die Box vorher WLAN hatte), AHA und den ganzen anderen Quatsch am Starten hindert, weil es die entsprechenden Init-Files nicht gibt. Kommt dann der "dsld" in die Gänge (der muß erst mal die Netzwerk-Interfaces dann konfigurieren) und auch noch der "ctlmgr", kann es sogar schon mit dem GUI-Zugriff funktionieren. Das birgt aber in sich auch das Risiko, daß doch noch Änderungen am NAND-Inhalt erfolgen ... würde man als reine Forensik, wo der Gegenstand der Untersuchung am besten vollkommen unverändert bleibt, eher nicht machen - ist am Ende aber einfacher zu realisieren, weil man nur Teile der AVM-Firmware "deaktivieren" muß.
Ansonsten muß man sich die notwendigen "Funktionen" halt selbst "einschalten" (am besten auch mit dem eigenen Filesystem-Image, was man von Grund auf selbst baut - Beispiele gibt es bei mir im "toolbox"-Folder im YourFritz-Repo) ... im Prinzip muß man bei der Initialisierung des Systems nichts weiter machen, als die passenden Dateisysteme mounten (tmpfs, ggf. devtmpfs, wobei das bei der 7390 iirc nicht existiert, sysfs, usw. - nicht vergessen, die "/var.tar" zu entpacken und die beschreibbaren Strukturen unter "/var" damit einzurichten) und die Netzwerk-Interfaces mit einer IP-Adresse versehen und starten. Danach noch eine Shell aktiviert über den "inetd" (Kennwort interessiert ja nur dann, wenn man diese Shell mit einem Login versieht - bei Forensik verzichtet man auf die Authentifizierung und startet gleich "/bin/sh") und man kann zumindest mal auf die Box zugreifen und sich genauer ansehen, was da schiefgeht - i.d.R. sollte irgendetwas im Panic- bzw. Crash-Log stehen, warum die Box nicht mehr wollte.
Die Netzwerkanbindung der Shell übernimmt dann der "inetd" ... ansonsten müßte man sich noch einen Telnet-Daemon einbauen (bzw. den Link unter "/usr/sbin/telnetd") oder eine BusyBox, die etwas wie "nc" enthält oder irgendetwas anderes in der Richtung ... am einfachsten ist es immer noch, mit einer Zeile in der "/var/tmp/inetd.conf" auf Port 514 eine Shell zu starten, dann kann man von außen quasi per "rcmd" zugreifen - das ist dann auch zu empfehlen, da die Shell auf der Box per se kein "command line editing" beherrscht und man sich ansonsten dumm und dämlich tippt, wenn nicht mal die Korrektur von Eingaben 100% funktioniert.
Aber man kann natürlich auch das NAND-FS versuchen zu mounten (Vorsicht, daß beim Starten keinesfalls "recovered=X" in "firmware_info" im Environment steht, sonst löschen einige AVM-Init-Skripte den Inhalt der Partition doch noch ... deshalb auch KEINESFALLS mit einem Recovery-Programm und/oder "Werkseinstellungen" an die Box gehen) und sich den Inhalt mal ansehen. Findet man das Gesuchte, kann man es z.B. mittels "tftp" aus der Box expedieren ... auf den Start des FTP-Servers in der Box, um das "abzuholen", würde ich (aus Forensik-Sicht) wieder eher verzichten.
Klappt es nicht mit der Initialisierung des Netzwerks oder ist die Shell nicht erreichbar (und man hat die Serielle nicht bestückt), lädt man am besten recht früh auch den AVM-Treiber für die LEDs (der ist aber (C) AVM und verhindert die (lizenzrechtlich einwandfreie) Weitergabe eines solchen Forensik-Images) und signalisiert die verschiedenen Schritte über "led-ctrl" (ebenfalls (C) AVM) ... dann kann man zumindest auch von außen erkennen, bis wohin die Initialisierung funktioniert. Hat man erst mal das Netzwerk aktiviert (und das noch erfolgreich, wenn's geht), kann man natürlich auch einfach die Console-Ausgaben per UDP irgendwo ins Netzwerk pusten (bei UDP stört sich niemand daran, wenn da kein Empfänger ist) ... anzeigen lassen die sich dann auf einem anderen PC z.B. mittels "nc". Wie man das machen könnte, hatte ich mal bei der 6490 gezeigt, als es um die Ausgabe von "autoupdate" ging:
https://github.com/PeterPawn/YourFritz/blob/master/autoupdate/run_update#L98 (auch wenn hier TCP verwendet wurde).
