Nand einer toten Fritzbox 7490 auslesen und Konfiguration sichern

[noomad]

Hat schonmal jemand den Nand einer toten 7490 ausgelesen und die Konfiguration im AVM export Format abgespeichert?
Geht das mit den tools von @PeterPawn irgendwie?
Ich stelle mir das so vor, Nand auslöten und in einem externen Lesegerät (mit TSOP48 Socket) auslesen.
Datei teilen, Konfiguration separieren und im AVM typischen export Format sichern.

 

[PeterPawn]

Die 7490 hat die Konfiguration in einem SPI-Flash und nicht im NAND.

EDIT: Und einen Dump einer der TFFS-Partitionen kann man tatsächlich zerlegen - zur Export-Datei müßte man den aber "von Hand" wieder zusammenbauen.

 

[eisbaerin]

Wie tot ist sie denn? Was geht noch?

 

[noomad]

@PeterPawn Prima, dann darf ich annehmen, dass es der MX25L8035EM2I-10G ist der sich etwa mittig auf der Unterseite befindet?
Gibt eines deiner tools das zusammensetzen her?

@eisbaerin Es geht nur um das technisch Mögliche. Angenommen die Box ist unrettbar verloren oder, sie wurde mir als Ersatzteilspender überlassen. Der Spender möchte aber alle seine Daten retten.

 

[noomad]

@PeterPawn Den flashrom dump von dem MX25L8035E habe ich. Mit binwalk habe ich mal reingeschaut. Es werden damit über 200 Dateien extrahiert. Sieht nach dem Inhalt aus den ich erwartet habe.
Deine YourFritz/tffs tools habe ich ausprobiert, erhalte aber einen Fehler.
Der übliche Weg für die Tools ist ./tffs_from_supportdata <file> <dir> <1 oder 2>. Erwartet wird dafür eine tar.gz file, als output gibts einen dump für dissect_tffs_dump. Die tar.gz file habe ich nicht.
Wenn ich ./dissect_tffs_dump ./MX25L8035E_RT809H.bin aufrufe startet zwar ein job der ein Verzeichnis in /tmp erzeugt und die Datei tffsdump anlegt. Der job wird aber nicht fertiggestellt. Es passiert nichts. Wenn ich abbreche und mir tffsdump anschaue ist die file leer.

Wenn ich ./dissect_tffs_dump < MX25L8035E_RT809H.bin aufrufe erhalte ich den Fehler:
./dissect_tffs_dump: 68: Bad substitution

Dort steht in Zeile 63 68:
header="$(dd if=$tffsdump bs=4 skip=$(( offset / 4 )) count=1 2>/dev/null | yf_bin2hex)"
if [ ${header:0:4} == ffff ]; then

Hast du einen Tipp für mich wie ich mit dem flashrom dump und deinen tools umgehen muss?

 

[PeterPawn]

Das "dissect_tffs_dump" erwartet natürlich auch nur einen TFFS-Dump als Eingabe (sonst hieße es vermutlich auch "dissect_spi_dump") - ich kann hier nicht erkennen, daß Du den Dump des gesamten SPI-Flashs (der ja alle Daten aus dem Chip beinhalten wird) so weit auseinandergenommen hättest, daß da tatsächlich nur noch der TFFS-Dump (einer einzelnen Partition - der Flash enthält zwei und die neuere hat den kleineren 32-Bit-Wert an Offset 4 stehen, weil der Zähler dort negiert gespeichert ist) in der Eingabedatei steht.

Die Partitionierung des Flash-Speichers kannst Du Dir aus jeder funktionsfähigen 7490 herleiten oder aus einer der zahlreichen Quellen von technischen Einzelheiten zur 7490 im Internet.

Ob dann der Aufruf von "dissect_tffs_dump" funktioniert (das könnte z.B. auch noch am falschen/unvollständigen Auschecken liegen, denn die Dateien aus "scriptlib" werden dafür ebenfalls benötigt), kann ich so nicht sehen ... mal abgesehen davon, daß ich nicht verstehe, warum Du bei einem Fehler in Zeile 68 (lt. Fehlermeldung) in Zeile 63 nachsehen solltest.

Aber angesichts des Inhalts von Zeile 68 würde ich raten (so als erste Idee), daß da keine "bash" unter "/bin/sh" zu finden ist - die Syntax mit dem Extrahieren von Zeichen aus einer Variablen in Zeile 68 ist nicht POSIX-konform und wenn da z.B. die "dash" verwendet werden sollte (weil mal wieder jemand einen Debian-Abkömmling mit "/bin/sh -> /bin/dash" benutzt), dann kennt die Shell diese Syntax nicht.

 

[noomad]

Kann mir denn jemand im Forum weiterhelfen? Die tools von YourFritz sind ungeeignet für mein Vorhaben und laufen nicht auf jedem System fehlerfrei.
Die Hinweise von @PeterPawn führen ins leere. Jedenfalls in leere Dateien. Die Partitionierung habe ich in Ermangelung einer funktionsfähigen 7490 hier https://freetz.github.io/wiki/help/howtos/development/flash.html angesehen.
Aus dem SPI dump habe ich die ersten 128k in eine Datei geschrieben und dann die jeweils darauf folgenden 64k in zwei weitere Dateien. Die letzteren sind leer.

Hat das schonmal jemand gemacht? Für die Friitzboxen gibt es keine Anleitungen für mein Vorhaben zu finden.

 

[PeterPawn]

Die tools von YourFritz sind ungeeignet für mein Vorhaben und laufen nicht auf jedem System fehlerfrei.

Bist Du da sicher? Auch auf einem Debian-basierten System hält einen niemand davon ab, dafür auch eine anständige Shell zu verwenden ... ich finde es schon einigermaßen kühn, für die eigene Unkenntnis im generellen Umgang mit einer Linux-Kommandozeile die Tools verantwortlich zu machen und nicht erst einmal beim "Anwender" zu suchen.

Es gibt so viele dokumentierte Wege, wie man die Shell ändern kann (von der eigenen aktuellen Login-Session über die permanente Änderung für einen einzelnen Benutzer oder das gesamte System oder sogar durch Änderung des SheBang in den aufzurufenden Skripten), daß es da schon an "Verweigerung" grenzt, wenn man dann einfach behauptet, die Skripte wären fehlerhaft.

Aus dem SPI dump habe ich die ersten 128k in eine Datei geschrieben und dann die jeweils darauf folgenden 64k in zwei weitere Dateien. Die letzteren sind leer.

Ich finde bei der allerersten Google-Suche nach "7490 SPI flash" folgende Sites:

Schon der erste Link bei der Fundstelle für das IPPF führt hierhin:

Fritzbox 7490 Reparaturen

Hallo zusammen, ich bin neu in diesem Forum, ich betreibe Elektronikwerkstatt, wo ich Fernseher, Notebooks repariere. Seit kurzem habe ich einen Auftrag von einer Firma auf Reparaturen von Fritzbox 7490 bekommen. Für den Anfang habe ich 45 Geräte bekommen. Bei mehr als der Hälfte habe ich Fehler...

www.ip-phone-forum.de

und dort im allerersten Beitrag findet man ein Boot-Log einer 7490, in dem dann auch die tatsächliche Aufteilung der 8 MBit (oder 1 MByte) des SPI-Flashs korrekt "angesagt" wird:

[    2.450000] Creating 3 MTD partitions on "ifx_sflash":
[    2.460000] 0x000000000000-0x000000040000 : "urlader"
[    2.470000] 0x000000040000-0x0000000a0000 : "tffs (1)"
[    2.470000] 0x0000000a0000-0x000000100000 : "tffs (2)"
[    2.480000] Lantiq SPI flash driver, version 2.0.2, (c) 2001-2011 Lantiq Deutschland GmbH

Die erste Partition mit dem Loader umfaßt also 256 KB und jede der beiden TFFS-Partitionen dann 384 KB (0xA0000 - 0x40000 = 0x60000 = 393216) - macht in der Summe dann wieder 256 + 2 * 384 = 1024 KB = 1 MB (die "Probe" macht also auch wieder Sinn).

Die Hinweise von @PeterPawn führen ins leere.

Das sehe ich zwar anders (siehe oben), aber ich kann (und will) Dich gar nicht vom Gegenteil überzeugen. Solange man bei Problemen immer erst die Fehler bei anderen sucht, kann ich auch nicht weiterhelfen.

 

[noomad]

@PeterPawn Ich wollte nicht kühn auftreten und jemanden auf den Fuß treten. Ich bin nur kein Entwickler sondern Bastler mit dem Schwerpunkt auf Hardware und nicht auf Software. Auch wenn ich Linux schon sehr lange einsetze, war für mich der Fehler nicht so leicht ersichtlich. Ich esse auch Schnitzel und fahre Auto ohne genau zu wissen wie aus einem Tier das über die Weide oder durch den Stall läuft mein Endprofukt wird oder wie mein Fahrzeug genau funktioniert. Bisher hat es ausgereicht zu wissen wie ich tanke und den Reifendruck kontrollieren kann.
Ich habe das ganze auf einem RPi getestet. Und ja, es war eine Debian Umgebung mit einem Symlink auf dash. Wenn ich eine Software einsetze und die nicht funktioniert, weil die Umgebungsvariablen nicht geprüft werden und es keine konkreten Hinweise gibt, gehe ich erstmal nicht von einem Fehler bei mir aus. Ich bin nur Anwender.

Es mag für einen erfahrenen Entwickler nicht einfach nachzuvollziehen sein, aber manchmal wird Software auch von nicht so erfahrenen Benutzern eingesetzt die nicht wissen wie es programmiert wird.

Bei dem Hinweis auf den Link zur 7490 Reparatur bist du klar im Vorteil, auch ohne Suche. Denn du hast dort mitgewirkt. In den letzten Tagen bin ich auf genau dieser Seite mehrmals gelandet. Aber ohne deinen konkreten Hinweis auf die Einträge in der logfile wäre ich da nicht drauf gekommen.

wenn ich zum aufteilen der dumpfile nun die Werte

0x000000000000-0x000000040000 : "urlader"
0x000000040000-0x0000000a0000 : "tffs (1)"
0x0000000a0000-0x000000100000 : "tffs (2)"

und mit

dd if=8035.bin of=mtd1-256kb_2.bin bs=1 count=$((0x40000))
dd if=8035.bin of=mtd3-384kb_tffs2_2.bin bs=1 skip=$((0xa0000-0x40000)) count=$((0xa0000))
dd if=8035.bin of=mtd4-384kb_tffs2_2.bin bs=1 skip=$((0x100000-0xa0000)) count=$((0x100000))

den flashdump teile, macht dissect_tffs_dump das gleiche wie vorher.
Ich erhalte die unbrauchbaren Dateien b40f.bin d07f.bin fceb.bin nodelist tffsdump.

Wenn ich die Datei mit
dd if=8035.bin of=mtd1-256kb.bin bs=1 count=256k
dd if=8035.bin of=mtd3-384kb_tffs2.bin bs=1 skip=256k count=384k
dd if=8035.bin of=mtd4-384kb_tffs2.bin bs=1 skip=640k count=384k
teile, erhalte diese files:

-rw-r--r-- 1 xx xx 4 3. Mai 20:08 0001.bin
-rw-r--r-- 1 xx xx 4 3. Mai 20:08 0057.bin
-rw-r--r-- 1 xx xx 0 3. Mai 20:08 0057.inflated
-rw-r--r-- 1 xx xx 1241 3. Mai 20:09 005f.bin
-rw-r--r-- 1 xx xx 4457 3. Mai 20:09 005f.inflated
-rw-r--r-- 1 xx xx 12204 3. Mai 20:09 0060.bin
-rw-r--r-- 1 xx xx 60315 3. Mai 20:09 0060.inflated
-rw-r--r-- 1 xx xx 1936 3. Mai 20:09 0070.bin
-rw-r--r-- 1 xx xx 5364 3. Mai 20:09 0070.inflated
-rw-r--r-- 1 xx xx 16985 3. Mai 20:09 0071.bin
-rw-r--r-- 1 xx xx 113845 3. Mai 20:09 0071.inflated
-rw-r--r-- 1 xx xx 2944 3. Mai 20:08 0072.bin
-rw-r--r-- 1 xx xx 11701 3. Mai 20:08 0072.inflated
-rw-r--r-- 1 xx xx 1863 3. Mai 20:09 0073.bin
-rw-r--r-- 1 xx xx 7096 3. Mai 20:09 0073.inflated
-rw-r--r-- 1 xx xx 486 3. Mai 20:09 0074.bin
-rw-r--r-- 1 xx xx 2074 3. Mai 20:09 0074.inflated
-rw-r--r-- 1 xx xx 1368 3. Mai 20:09 0076.bin
-rw-r--r-- 1 xx xx 2791 3. Mai 20:09 0076.inflated
-rw-r--r-- 1 xx xx 1533 3. Mai 20:09 0077.bin
-rw-r--r-- 1 xx xx 3921 3. Mai 20:09 0077.inflated
-rw-r--r-- 1 xx xx 665 3. Mai 20:09 0078.bin
-rw-r--r-- 1 xx xx 4719 3. Mai 20:09 0078.inflated
-rw-r--r-- 1 xx xx 328 3. Mai 20:09 0079.bin
-rw-r--r-- 1 xx xx 1980 3. Mai 20:09 0079.inflated
-rw-r--r-- 1 xx xx 7269 3. Mai 20:09 007a.bin
-rw-r--r-- 1 xx xx 44412 3. Mai 20:09 007a.inflated
-rw-r--r-- 1 xx xx 480 3. Mai 20:09 0081.bin
-rw-r--r-- 1 xx xx 27592 3. Mai 20:09 0081.inflated
-rw-r--r-- 1 xx xx 85 3. Mai 20:08 0082.bin
-rw-r--r-- 1 xx xx 5940 3. Mai 20:08 0082.inflated
-rw-r--r-- 1 xx xx 8568 3. Mai 20:09 0084.bin
-rw-r--r-- 1 xx xx 109132 3. Mai 20:09 0084.inflated
-rw-r--r-- 1 xx xx 1676 3. Mai 20:09 0085.bin
-rw-r--r-- 1 xx xx 4710 3. Mai 20:09 0085.inflated
-rw-r--r-- 1 xx xx 5769 3. Mai 20:09 008e.bin
-rw-r--r-- 1 xx xx 44683 3. Mai 20:09 008e.inflated
-rw-r--r-- 1 xx xx 4395 3. Mai 20:09 008f.bin
-rw-r--r-- 1 xx xx 93301 3. Mai 20:09 008f.inflated
-rw-r--r-- 1 xx xx 197 3. Mai 20:08 0091.bin
-rw-r--r-- 1 xx xx 8436 3. Mai 20:08 0091.inflated
-rw-r--r-- 1 xx xx 4068 3. Mai 20:09 00a1.bin
-rw-r--r-- 1 xx xx 32989 3. Mai 20:09 00a1.inflated
-rw-r--r-- 1 xx xx 498 3. Mai 20:09 00a2.bin
-rw-r--r-- 1 xx xx 1830 3. Mai 20:09 00a2.inflated
-rw-r--r-- 1 xx xx 434 3. Mai 20:09 00a3.bin
-rw-r--r-- 1 xx xx 917 3. Mai 20:09 00a3.inflated
-rw-r--r-- 1 xx xx 242 3. Mai 20:09 00b1.bin
-rw-r--r-- 1 xx xx 2551 3. Mai 20:09 00b1.inflated
-rw-r--r-- 1 xx xx 60 3. Mai 20:09 00b2.bin
-rw-r--r-- 1 xx xx 63 3. Mai 20:09 00b2.inflated
-rw-r--r-- 1 xx xx 1379 3. Mai 20:08 00c9.bin
-rw-r--r-- 1 xx xx 1766 3. Mai 20:08 00c9.inflated
-rw-r--r-- 1 xx xx 979 3. Mai 20:08 00ca.bin
-rw-r--r-- 1 xx xx 1395 3. Mai 20:08 00ca.inflated
-rw-r--r-- 1 xx xx 2706 3. Mai 20:08 00cb.bin
-rw-r--r-- 1 xx xx 3607 3. Mai 20:08 00cb.inflated
-rw-r--r-- 1 xx xx 2443 3. Mai 20:09 00cc.bin
-rw-r--r-- 1 xx xx 3596 3. Mai 20:09 00cc.inflated
-rw-r--r-- 1 xx xx 3060 3. Mai 20:08 00cd.bin
-rw-r--r-- 1 xx xx 4290 3. Mai 20:08 00cd.inflated
-rw-r--r-- 1 xx xx 1136 3. Mai 20:08 00d1.bin
-rw-r--r-- 1 xx xx 3965 3. Mai 20:08 00d1.inflated
-rw-r--r-- 1 xx xx 22 3. Mai 20:08 00d2.bin
-rw-r--r-- 1 xx xx 2 3. Mai 20:08 00d2.inflated
-rw-r--r-- 1 xx xx 14 3. Mai 20:08 00d3.bin
-rw-r--r-- 1 xx xx 0 3. Mai 20:08 00d3.inflated
-rw-r--r-- 1 xx xx 14 3. Mai 20:08 00d8.bin
-rw-r--r-- 1 xx xx 0 3. Mai 20:08 00d8.inflated
-rw-r--r-- 1 xx xx 14 3. Mai 20:09 00e1.bin
-rw-r--r-- 1 xx xx 0 3. Mai 20:09 00e1.inflated
-rw-r--r-- 1 xx xx 34 3. Mai 20:08 00e5.bin
-rw-r--r-- 1 xx xx 24 3. Mai 20:08 00e5.inflated
-rw-r--r-- 1 xx xx 73 3. Mai 20:08 00e7.bin
-rw-r--r-- 1 xx xx 83 3. Mai 20:08 00e7.inflated
-rw-r--r-- 1 xx xx 4 3. Mai 20:08 0100.bin
-rw-r--r-- 1 xx xx 16 3. Mai 20:08 0101.bin
-rw-r--r-- 1 xx xx 17 3. Mai 20:08 0102.bin
-rw-r--r-- 1 xx xx 2 3. Mai 20:08 0104.bin
-rw-r--r-- 1 xx xx 4 3. Mai 20:08 0181.bin
-rw-r--r-- 1 xx xx 7 3. Mai 20:08 0182.bin
-rw-r--r-- 1 xx xx 5 3. Mai 20:08 0183.bin
-rw-r--r-- 1 xx xx 10 3. Mai 20:08 0185.bin
-rw-r--r-- 1 xx xx 11 3. Mai 20:08 0186.bin
-rw-r--r-- 1 xx xx 48 3. Mai 20:08 0187.bin
-rw-r--r-- 1 xx xx 18 3. Mai 20:08 0188.bin
-rw-r--r-- 1 xx xx 18 3. Mai 20:08 0189.bin
-rw-r--r-- 1 xx xx 18 3. Mai 20:08 018a.bin
-rw-r--r-- 1 xx xx 18 3. Mai 20:08 018b.bin
-rw-r--r-- 1 xx xx 11 3. Mai 20:08 018c.bin
-rw-r--r-- 1 xx xx 15 3. Mai 20:08 018d.bin
-rw-r--r-- 1 xx xx 15 3. Mai 20:08 018e.bin
-rw-r--r-- 1 xx xx 14 3. Mai 20:08 018f.bin
-rw-r--r-- 1 xx xx 8 3. Mai 20:08 0190.bin
-rw-r--r-- 1 xx xx 10 3. Mai 20:08 0192.bin
-rw-r--r-- 1 xx xx 10 3. Mai 20:08 0193.bin
-rw-r--r-- 1 xx xx 18 3. Mai 20:08 0194.bin
-rw-r--r-- 1 xx xx 18 3. Mai 20:08 0195.bin
-rw-r--r-- 1 xx xx 18 3. Mai 20:08 0196.bin
-rw-r--r-- 1 xx xx 2 3. Mai 20:08 0198.bin
-rw-r--r-- 1 xx xx 61 3. Mai 20:09 01a1.bin
-rw-r--r-- 1 xx xx 7 3. Mai 20:08 01a2.bin
-rw-r--r-- 1 xx xx 7 3. Mai 20:08 01a3.bin
-rw-r--r-- 1 xx xx 15 3. Mai 20:08 01a4.bin
-rw-r--r-- 1 xx xx 4 3. Mai 20:08 01a5.bin
-rw-r--r-- 1 xx xx 6 3. Mai 20:08 01a6.bin
-rw-r--r-- 1 xx xx 2 3. Mai 20:08 01a9.bin
-rw-r--r-- 1 xx xx 21 3. Mai 20:08 01ab.bin
-rw-r--r-- 1 xx xx 10 3. Mai 20:09 01ae.bin
-rw-r--r-- 1 xx xx 19 3. Mai 20:08 01b0.bin
-rw-r--r-- 1 xx xx 13 3. Mai 20:08 01b1.bin
-rw-r--r-- 1 xx xx 12 3. Mai 20:08 01b2.bin
-rw-r--r-- 1 xx xx 16 3. Mai 20:08 01b3.bin
-rw-r--r-- 1 xx xx 17 3. Mai 20:08 01b4.bin
-rw-r--r-- 1 xx xx 13 3. Mai 20:08 01b5.bin
-rw-r--r-- 1 xx xx 5 3. Mai 20:08 01fd.bin
-rw-r--r-- 1 xx xx 1268 3. Mai 20:08 01ff.bin
-rw-r--r-- 1 xx xx 8 3. Mai 20:08 0400.bin
-rw-r--r-- 1 xx xx 4 3. Mai 20:08 0401.bin
-rw-r--r-- 1 xx xx 4 3. Mai 20:09 0402.bin
-rw-r--r-- 1 xx xx 4 3. Mai 20:09 0403.bin
-rw-r--r-- 1 xx xx 4 3. Mai 20:09 0404.bin
-rw-r--r-- 1 xx xx 4 3. Mai 20:08 0405.bin
-rw-r--r-- 1 xx xx 6 3. Mai 20:08 0406.bin
-rw-r--r-- 1 xx xx 4 3. Mai 20:08 0407.bin
-rw-r--r-- 1 xx xx 1117 3. Mai 20:09 nametable.txt
-rw-r--r-- 1 xx xx 2773 3. Mai 20:09 nodelist
-rw-r--r-- 1 xx xx 393216 3. Mai 20:08 tffsdump

Meine Hoffnung war, die Datei entpackt zu bekommen mit Verzeichnisstruktur und korrekter Benennung.

So ähnlich das das mit binwalk auch schon aus. Nur dass ich da keine nametable.txt bekommen habe.

 

[PeterPawn]

Dann war die Hoffnung wohl trügerisch ... was "binwalk" tatsächlich mit einem SPI-Dump einer 7490 macht, schaue ich mir bei Gelegenheit (schon aus Neugier) glatt mal an - es wäre mir neu, daß "binwalk" inzwischen TFFS-Partitionen zerlegen kann. Insofern wäre ich dankbar, wenn anstelle von "binwalk" da auch noch eine Quelle oder zumindest eine Versionsnummer für das "binwalk" stehen würde.

Es wäre mir aber im Moment tatsächlich neu, wenn "binwalk" (https://github.com/ReFirmLabs/binwalk) das Zerlegen der TFFS-Strukturen von AVM unterstützt ... insofern halte ich das

So ähnlich das das mit binwalk auch schon aus.

eher für einen Trugschluß - wobei "binwalk" sicherlich auch die eine oder andere Signatur im Bootloader gefunden haben wird und da wahrscheinlich auch irgendetwas zerlegt. Aber wenn das tatsächlich irgendwelche "nutzbaren" Teile wären, würde mich das ziemlich überraschen.

=======================================================================

Es mag sogar sein, daß ich "klar im Vorteil" bin, was die Kenntnis dessen angeht, was hier im Board alles schon beschrieben wurde mit Blick auf die FRITZ!Boxen - das ist mir aber auch von niemandem vorgesungen worden, das mußte ich mir meinerseits ebenso "anlesen" oder es (an der einen oder anderen Stelle) auch selbst aufschreiben.

Was erwartest Du denn jetzt von mir? Daß ich den Aufbau des SPI-Flashs einer 7490 im Kopf habe und ihn nur noch für Dich aufschreibe? Oder daß ich den - für Dich - raussuche, damit Du das nicht machen mußt?

Ich habe es zumindest "geschafft", Dir aufzuschreiben, wo Dein Fehler lag und wie man ihn beheben kann, ja sogar, wonach Du suchen müßtest.

Das Suchen und Finden und Lesen aber, das kann (und will) ich Dir nicht abnehmen ... wenn Du Dich dazu berufen fühlst, die Daten des Vorbesitzers irgendwie wiederherzustellen, dann bist das immer noch DU, der das übernommen hat und wenn Du dazu erst einmal Neues erlernen mußt, dann kann Dir das auch niemand abnehmen.

Ist Dir das zu anstrengend, schicke mir den Dump und Du kriegst von mir die PayPal-Adresse, an die Du das Honorar überweisen kannst. Nach dessen Eingang zerlege ich Dir das Image dann "kunstgerecht" und baue Dir (wenn der Preis stimmt) auch noch eine Datei daraus, die sich wieder importieren läßt.

Ansonsten ist das hier immer noch eine - absolut freiwillige - Veranstaltung, bei der Du zwar Hilfe erhalten kannst, aber nicht in der Form, daß man Dir alles und jeden einzelnen Schritt vorkaut und Du immer nur noch "Und was kommt jetzt als nächstes?" fragen mußt. Da wärest Du zumindest bei mir vor der deutlich falschen Schmiede.

Und Du hast Dich hier eben nicht nur zum Tanken und zum Prüfen des Reifendrucks an irgendeinem Auto gemeldet ... wenn Du da unter die Haube schauen und irgendwas am Steuergerät herumpfuschen willst, mußt Du Dich auch (a) mit den richtigen Werkzeugen versorgen und (b) das notwendige Wissen haben oder es Dir aneignen.

Das., was Du hier mit der FRITZ!Box bzw. dem ausgelesenen Inhalt ihres SPI-Flashs machen willst, hat auch mit "Tanken" nichts mehr zu tun ... bzw. mit dem "normalen Gebrauch" der FRITZ!Box. Wenn Du Dich trotzdem dazu berufen fühlst, solltest/mußt Du Dir halt auch hier die richtigen Werkzeuge und das notwendige Wissen zulegen - oder Du gehst eben doch davon aus, daß das ja ruhig ein Anderer für Dich machen könnte. Nur nenne mir einen einzigen Grund (außer "nett sein"), warum das jemand anderes für Dich übernehmen sollte, wenn Du Dich doch offenbar bereit erklärt hast (gegenüber dem Vorbesitzer), das zu machen. Es ist kein Problem, wenn Du dabei um Hilfe nachsuchst ... aber wenn Du dann erwartest, daß man Dir das alles "vorsingt", wird es wieder "unanständig" in meinen Augen.

Und die Ansage:

Ich wollte nicht kühn auftreten und jemanden auf den Fuß treten.

nach einem vorhergehenden:

Die Hinweise von @PeterPawn führen ins leere.

kann ich auch nur schwer glauben (letztlich schiebst Du die "Schuld" ja doch wieder mir zu, weil ich "die Umgebungsvariablen" nicht ausreichend prüfe - wenn das ein "fertiges Programm" wäre oder sein sollte, dann würde ich darüber vielleicht noch diskutieren, so ist das aber nur eine Zumutung, was Du da an Erwartungshaltung offenbarst) ... und alles das, was Du dann zur Begründung (oder als "Entschuldigung") in #9 dazu noch geschrieben hast (vom RasPi bis zu Deinen Vorkenntnissen), wäre dann eben schon in #1 angebracht gewesen.

Wobei ich auch zugebe, daß ich mich dann herausgehalten hätte ... denn "nur Anwender", die dann bei einem Fehler auch noch als Erstes davon ausgehen, daß ein Problem ja gar nicht bei ihnen selbst liegen kann:

Wenn ich eine Software einsetze und die nicht funktioniert, weil die Umgebungsvariablen nicht geprüft werden und es keine konkreten Hinweise gibt, gehe ich erstmal nicht von einem Fehler bei mir aus. Ich bin nur Anwender.

, sollten sich dann auch nur an die Sachen heranwagen, wo sie mit diesen Ansichten zum Ziel gelangen können und das hätte ich hier dann zu Beginn bereits ausgeschlossen - die Skripte sind nämlich nur "Hilfsmittel" und kein "Programm", was man nur aufrufen muß und wo dann irgendwann das gewünschte Ergebnis hinten "herauspurzelt".

=======================================================================

Ansonsten weiß ich halt nicht genau, was Du willst ... bzw. das habe ich vermutlich schon verstanden, aber Du hast vielleicht nicht begriffen, was hier passiert und was diese Skript-Dateien machen.

Schon das

[...] zur Export-Datei müßte man den aber "von Hand" wieder zusammenbauen.

mit nachfolgender Frage

Gibt eines deiner tools das zusammensetzen her?

offenbart wohl unterschiedliche Erwartungshaltungen.

Daß das Zerlegen im ersten Anlauf falsch war (hier meine ich den mit den hexadezimalen Angaben aus #9), ergibt sich ja schon daraus, daß Du bei "count" falschen Angaben verwendet hast. Und nun erzähle mir bitte nicht wieder, das wäre halt, weil Du "nur" Anwender bist - auch die Stelle mit 63 vs. 68 zeigt für mich, daß Du Dich schnell mit ersten Ergebnissen "nach Augenschein" und Deinen eigenen Vermutungen zufrieden gibst, anstatt es noch einmal zu überprüfen, was Du da eigentlich machst und ob das auch richtig war.

Wobei Du das hier ja dann in #9 doch noch einmal anders angegangen bist (aber sicherlich auch nicht deshalb, weil Du erkannt hast, daß die Angaben bei "count" im ersten Anlauf falsch waren, oder?) und damit dann offenbar einen Schritt weiterkommen konntest.

Wie gesagt ... ich weiß ja nicht, was Du da erwartet hast. Warum sollte irgendjemand irgendwann einmal hingegangen sein und irgendwelche Tools geschrieben haben, um aus einem TFFS-Dump eine "fertige" Export-Datei zu machen? Immerhin kann das ein laufendes FRITZ!OS ganz von alleine ... es macht also nur sehr begrenzten Sinn (zumindest als wiederholte Aufgabe), aus so einem Dump eine AVM-Export-Datei zu erstellen - folglich wird sich auch kaum jemand die Mühe machen (bzw. gemacht haben), das "fertig" für Dich so umzusetzen, daß Du es nur noch aufrufen mußt.

=======================================================================

Was Du da jetzt hast, sind die einzelnen "Nodes" aus dem TFFS - was das ist, ob man das essen kann oder ob es das auch in burgunderrot gibt, müßtest Du wieder einmal selbst ergründen ... es ist definitiv auch irgendwo im IPPF beschrieben und ich weiß schon wieder nicht, wo genau das wäre und ich suche das auch nicht (für Dich) heraus; ich brauche das nämlich nicht und so viel "Eigeninitiative" ist nun mal das Minimum dessen, was ich meinerseits erwarte, wenn ich jemandem "auf die Sprünge" helfe.

Wenn Du das dann ergründet hast, findest Du in den "inflated"-Dateien die "entpackten Daten" (das TFFS speichert das nun mal mit ZIP-Kompression) und wenn Du die "IDs" der Dateien einem Namen zuordnen willst, kannst Du einen Blick in diese Datei werfen: https://github.com/PeterPawn/YourFritz/blob/master/tffs/data/tffs.files (ich hoffe, Du kennst den Unterschied zwischen Dezimal- und Hexadezimal-Zahlen, weil die Dateinamen hex sind, während die Liste Dezimalzahlen verwendet).

Dabei wirst Du dann feststellen, daß das FRITZ!OS die "wichtigen" Daten (wie Credentials und noch einiges mehr, was man nicht unbedingt "im Klartext" lesen muß) in den TFFS-Nodes nur mit Verschlüsselung speichert ... wenn der Vorbesitzer damit etwas anfangen können soll, mußt Du diese also auch noch entschlüsseln. Dazu gibt es ebenfalls einen (eher langen) Thread hier irgendwo ... dessen Link hätte ich glatt in meiner Sammlung, aber den findest Du auch ganz leicht selbst - so viele Thread befassen sich nicht mit dem Entschlüsseln der Daten in den AVM-Einstellungen (ich finde ihn bei einer eigenen Suche auf Anhieb - und für die Verwendung von "avm einstellungen entschlüsseln" braucht es genauso wenig einen "Kenntnisvorsprung", wie das bei "7490 spi flash" der Fall war).

Um das dann aber wieder in eine Export-Datei zu packen (und zwar auch noch in eine, die sich tatsächlich importieren ließe), müßtest Du Dich dann halt auch noch mit deren Aufbau vertraut machen ... immerhin habe ich hier eine gute Nachricht für Dich: Die Datei DARF auch Klartext an den Stellen enthalten, wo ansonsten verschlüsselte Daten stehen - aber das "Import-Passwort" muß richtig sein im Header der Datei (und das heißt nach meinem Test, daß es auch "verschlüsselt" sein muß). Wie das dann geht, habe ich im Verschlüsselungsthread erklärt, den Vorgang muß man an dieser Stelle nur umkehren.

Ich hoffe mal, daß Du meinen Hinweis, wie man die "aktuellere" Version des TFFS-Inhalts findet (steht irgendwo weiter vorne im Thread) auch berücksichtigt hast ... sonst machst Du Dir am Ende die Arbeit für recht alte Daten (das kommt immer etwas darauf an, was sich da wie und wann ändert, wann die TFFS-Partition gewechselt wird).

 

[noomad]

@PeterPawn vielen Dank für die hilfreichen Hinweise.
Wenn ich raus habe wie es geht schreibe ich es, gerne auch für andere zum nachmalen, in Einzelschritten auf.
Ich habe kein Problem damit anderen eine Abkürzung aufzuzeigen und mein (wenn auch geringes) Wissen zu teilen.

Zum untersuchen des SPI flash dumps habe ich binwalk in der aktuellen Version 2.2.0 (https://github.com/ReFirmLabs/binwalk) verwendet.

Mit binwalk -eM mtd3-384kb_tffs2.bin -c -f log.csv (oder nur -f log.txt) bekomme ich neben den entpackten Dateien eine logdatei in die für einige Dateien auch der ursprüngliche Name und Speicherort geschrieben wird.

Sieht dann beispielsweise so aus:
(Auszug log.txt)
DECIMAL,HEXADECIMAL,DESCRIPTION
6,6,Unix path: /var/flash/usb.cfg
FILE,MD5SUM,TIMESTAMP
/home/<user>/elektronik/YourFritz/tffs/_mtd3-384kb_tffs2.bin.extracted/2534,b026324c6904b2a9cb4b88d6d61c81d1,2020-05-04 09:52:18

bzw. (Auszug log.txt)

--------------------------------------------------------------------------------
6 0x6 Unix path: /var/flash/usb.cfg


Scan Time: 2020-05-04 10:26:50
Target File: /home/<user>/elektronik/YourFritz/tffs/_mtd3-384kb_tffs2.bin-0.extracted/2534
MD5 Checksum: b026324c6904b2a9cb4b88d6d61c81d1
Signatures: 404
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------

 

[PeterPawn]

Das ist aber schon wieder etwas anderes, als Du es in #5 beschrieben hast.

Da steht/stand nämlich nichts davon, daß Du dem "binwalk" nur einen Teil des Flash-Dumps vorgesetzt hättest - das wiederum steht jetzt aber in Deinem Aufruf in #11, denn der Dateiname "mtd3-384kb_tffs2.bin" deutet ja eher nicht darauf hin, daß Du da den gesamten Dump "verfüttert" hättest und nach #9 hast Du ja auch erst dort dann den Dump erfolgreich in einzelne Partitionen zerlegt ... daher kannst Du den vorher kaum schon in dieser Form mit "binwalk" versucht haben zu analysieren.

Und wenn Deine Aussage:

So ähnlich das das mit binwalk auch schon aus. Nur dass ich da keine nametable.txt bekommen habe.

am Ende nur darauf zielte, daß Du vor dem Versuch mit dem "dissect_tffs_dump" erst noch einem mit "binwalk" gestartet hast und zwar auch genau schon für den tatsächlichen Inhalt einer einzelnen TFFS-Partition, dann solltest Du das vielleicht etwas deutlicher formulieren.

Denn das ist ja offensichtlich "Präteritum" in der Aussage, oder? Ich habe jetzt einfach mal das erste "das" im zitierten Text durch ein "sah" ersetzt, damit der Satz einen Sinn ergibt und das "sah" wäre - sowohl von der Länge als auch von der Wahl der Buchstaben (66% Übereinstimmung) und im Angesicht des Perfekts im folgenden Satz - da die naheliegendste Erklärung.

Aber selbst dann sehe ich schon noch einen gewaltigen Unterschied zwischen dem Ergebnis eines "binwalk" und der Ausgabe meines Skripts. Während "binwalk" auf alles, was da irgendwie nach einem "zlib compressed stream" aussieht, losgeht und das versucht zu dekomprimieren, "versteht" mein Skript durchaus den Inhalt eines TFFS-Dumps und extrahiert dort auch nur das, was tatsächlich enthalten ist und zwar auch nur die jeweils letzte Version eines jeden Wertes. Bei "dissect_tffs_dump" findet man eben nur eine einzige "stat.cfg" in der Ausgabe (nämlich die Datei, welche die ID 116 (0x6A0x74 natürlich, bei 0x6A sind wir erst bei 106) im Namen trägt) und das ist dann auch diejenige, die den aktuellen Inhalt repräsentiert.

Läßt man hingegen zählen, wieviele "stat.cfg" das "binwalk" in einem Dump findet:

pi@pi4:/tmp $ dd if=spi-dump.bin bs=65536 skip=4 count=6 2>/dev/null >tffs1.bin
pi@pi4:/tmp $ dd if=spi-dump.bin bs=65536 skip=10 count=6 2>/dev/null >tffs2.bin
pi@pi4:/tmp $ binwalk -eMv -f - tffs1.bin | grep "/stat\.cfg"
6             0x6             Unix path: /var/flash/stat.cfg
6             0x6             Unix path: /var/flash/stat.cfg
[...]
6             0x6             Unix path: /var/flash/stat.cfg
6             0x6             Unix path: /var/flash/stat.cfg
pi@pi4:/tmp $ binwalk -eMv -f - tffs1.bin | grep "/stat\.cfg" | wc -l
64
pi@pi4:/tmp $

, erkennt man schon auf den ersten Blick, daß das von der Struktur eines TFFS überhaupt keine Idee hat, wenn es 64 Inkarnationen der "stat.cfg" in dem Dump erkennt. Was nicht heißt, daß die nicht tatsächlich auch mal da waren ... nur ist es ja gerade der Sinn und Zweck des TFFS, "fortgeschrieben" zu werden und da gibt es dann eben immer nur eine einzige gültige Datei und nicht 64.

Wie arbeitet denn das "binwalk"?

Das sucht sich alle Stellen, die irgendwie ein komprimierter Datenstrom sein KÖNNTEN und versucht dann, diese zu entpacken. Das geht mal gut (wenn es tatsächlich komprimierte Daten sind) und mal fährt das voll gegen den Baum.

Du brauchst Dir nur mal die Diskrepanz der Größen der "compressed chunks" und der letztlich daraus "entpackten" Daten ansehen (im Ausgabeverzeichnis von "binwalk"), um zu erkennen, daß da praktisch alles versucht wird zu entpacken ... daher ist die Summe aus dem Dateinamen (Offset in hex) und der Dateigröße der ganzen "zlib"-Files auch immer konstant die 393216, nämlich die Größe der Eingabedatei. Je größer der Offset wird, um so kleiner wird der "Rest" des Images, der da entpackt werden soll (oder für den man das zumindest versucht).

Es gibt auch genug Stellen, wo die Annahme "zlib stream" einfach nicht stimmt und dann die entpackte Datei auch die Länge 0 hat - wobei das tatsächlich auch mal bei einem "echten" Stream passieren kann, wenn der TFFS-Node dann wirklich keine Daten enthält.

Ansonsten beruht die "Hellsichtigkeit" von "binwalk" in Bezug auf die Dateinamen in einer AVM-Firmware lediglich darauf, daß AVM immer schön den Namen der Datei als Kommentar an ihren Anfang schreibt und daher sind dann solche Zeilen wie

Scan Time:     2020-05-04 12:18:34
Target File:   /tmp/_tffs1.bin.extracted/12318
MD5 Checksum:  e832106eaad5246c51b5957c166f7a48
Signatures:    404
DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
6             0x6             Unix path: /var/flash/stat.cfg

auch nichts anderes als die "Ansage", daß da in dem "deflated stream", der am Offset 0x12318 gefunden wurde, an der Verschiebung 6 die Zeichenkette "/var/flash/stat.cfg" steht, die halt wie ein Unix-Pfad aussieht. Und genau das steht auch in der Box im "Dateiinhalt":

root@fb7490:~ $ busybox hexdump -C /var/flash/stat.cfg | head -n 5
00000000  2f 2a 0a 20 2a 20 2f 76  61 72 2f 66 6c 61 73 68  |/*. * /var/flash|
00000010  2f 73 74 61 74 2e 63 66  67 0a 20 2a 20 4d 6f 6e  |/stat.cfg. * Mon|
00000020  20 4d 61 79 20 20 34 20  31 32 3a 32 39 3a 32 35  | May  4 12:29:25|
00000030  20 32 30 32 30 0a 20 2a  2f 0a 0a 6d 65 74 61 20  | 2020. */..meta |
00000040  7b 20 65 6e 63 6f 64 69  6e 67 20 3d 20 22 75 74  |{ encoding = "ut|
00000050  66 2d 38 22 3b 20 7d 0a  0a 49 6e 74 65 72 6e 65  |f-8"; }..Interne|
00000060  74 53 74 61 74 20 7b 0a  20 20 20 20 20 20 20 20  |tStat {.        |
00000070  54 69 6d 65 53 74 61 6d  70 20 3d 20 34 34 31 32  |TimeStamp = 4412|
00000080  37 34 68 3b 0a 20 20 20  20 20 20 20 20 54 6f 64  |74h;.        Tod|
00000090  61 79 20 7b 0a 20 20 20  20 20 20 20 20 20 20 20  |ay {.           |
root@fb7490:~ $

Diese Kriterien erfüllt aber praktisch jede Zeichenkette, die zwischen zwei Schrägstrichen nur Zeichen enthält, die man auch in einem Dateinamen verwenden dürfte - das hat also mit "Kenntnis" vom Aufbau eines TFFS-Images so viel zu tun, wie ein mathematischer Beweis mit einer Multiple-Choice-Frage.

Den Beweis kann man nur erbringen/plausibel erläutern, wenn man den Inhalt verstanden hat ... bei der MC-Frage hat man eine Chance von 1:n (mit n = Anzahl der möglichen Antworten), die richtige auch durch puren Zufall zu treffen.

==========================================================

Wo man hier dann auch nur eine "entfernte Ähnlichkeit" in den Ausgaben erkennen kann, erschließt sich mir halt nicht ... man muß eben auch bei einem Werkzeug (das gilt für "binwalk" ebenso, wie für meine Shell-Skripte, um die es hier geht) auch wissen, wie man es benutzt (sonst ist auch mal ratz-batz der Daumen blau, wenn für den Mann mit dem Hammer alles wie ein Nagel aussieht).

Das lernt man beim Löten recht schnell, daß der Lötkolben an einem Ende heiß wird - das ist halt bei solchen Werkzeugen zur Analyse von unbekannten Dateien und/oder Formaten nicht ganz so offensichtlich, aber sinnvolle Ergebnisse wird man eben auch nur dann erzielen, wenn man die Ausgaben/Aussagen der Werkzeuge tatsächlich interpretieren kann. Das ist dann die Lernkurve, die man an dieser Stelle "absolvieren" muß.

Ich habe kein Problem damit [...] mein (wenn auch geringes) Wissen zu teilen.

Das ist ja praktisch ... das habe ich nämlich auch nicht, wie man leicht an diesem Thread und an diversen anderen Beiträgen, wo ich etwas erläutere oder jemandem (manchmal auch erfolgreich) geholfen habe, erkennen kann.

Wenn da in Deinem Satz also das "ich" besonders betont sein sollte (ansonsten erschließt sich mir eigentlich nicht, wo der Zusammenhang wäre und was Dich dazu bewogen haben könnte, diesen Satz zu formulieren - mal abgesehen davon, daß ich mit "nachmalen" nichts anfangen kann), dann unterschreibe ich das gerne ... solange da nicht doch ein unterschwelliges "im Gegensatz zu anderen, konkret sogar zu Dir" mitschwingen soll.

Ich habe zwar auch Deinen Dank im ersten Satz von #11 zur Kenntnis genommen ... aber irgendwie finde ich trotzdem keinen (weiteren) Beleg dafür, daß Dich meine Worte überhaupt erreicht haben und das irgendwie über den "rein technischen Erfolg" hinausgehen würde. Aber das werde ich ja dann anhand künftiger Reaktionen merken ...

 

[noomad]

Kleines update. Ich habe die .export Datei aus dem flashrom gesichert. Allerdings habe ich es softwaremäßig nicht hinbekommen. Als Hardware-Bastler war es der geringste Aufwand eine funktionierende Box (günstig) zu erwerben und den MX25L8035E-fashrom zu tauschen. Auslöten dauert mit ChipQuick 7 Sekunden, einlöten 15 Sekunden.

Nach dem einlöten von drei Pins für den UART Port (mache ich bei allen Fritzboxen) wollte ich das Kennwort für das webui aus der ar7.cfg rauslöschen um Zugang ohne Kennwort zu bekommen. Es war aber gar kein Kennwort eingetragen. Ich habe das Kennwort vom Vorbesitzer bekommen und konnte mich dann ganz normal anmelden über das webui.

Es gab noch die Möglichkeit den Chip mit einer Pomona-Klemme (5250) und einem RPi (oder irgendeinem anderen Linux Rechner) über

flashrom -w 8035.bin -p linux_spi:dev=/dev/spidev0.0 -c MX25L8035E

mit den Daten zu füttern. Das hätte mir das aus- und einlöten erspart. Den flashrom dump hatte ich ja bereits. Teste ich im Nachgang vielleicht noch.