[Problem] 6490 ohne ansprechbaren Bootloader

[_web_]

Ich bin wieder hoffnungsvoller! Das "EVA-Discovery.ps1"-Skript identifiziert die Box immer zielsicher:

PS C:\Users\Sascha\Downloads\YourFritz\eva_tools> .\EVA-Discover.ps1
EVA_IP=192.168.178.1
True

Nach diesen Vorgang blink die rote Info - Leuchte zwar immer noch, aber die Power - Leucht ist permanent an, was zuvor nicht der Fall war. Eine FTP - Session wird allerdings nicht gestartet und ich kann den Fehler nicht wirklich zuordnen:

PS C:\Users\Sascha\Downloads\YourFritz\eva_tools> .\EVA-FTP-Client.ps1
Error connecting to remote host
Ausnahme beim Aufrufen von ".ctor" mit 2 Argument(en):  "Eine bestehende Verbindung wurde softwaregesteuert
durch den Hostcomputer abgebrochen 192.168.178.1:21".

Ich hatte das ganze mit Wireshark mitgeschnitten und zwei UDP Antworten von der Box erhalten. Die waren relativ identisch (an Stelle von 2G stand 2F in dem anderen Payload):

0000   98 29 a6 33 41 cf 30 78 30 30 2c 20 08 00 45 00   .).3A.0x00, ..E.
0010   00 2c 32 47 00 00 fa 11 a9 1c c0 a8 b2 01 c0 a8   .,2G............
0020   b2 0a 13 ab 13 ab 00 18 34 97 00 00 12 01 02 00   ........4.......
0030   00 00 01 b2 a8 c0 00 00 00 00 00 00               ............

Ich weiß jetzt nicht, wie ich die Fehlermitteilung vom FTP Skript deuten soll und Tante Google hat auch nichts ausgespuckt, was auf die Ursachen hindeuten würden. Hat jemand eine Idee?

 

[stoney]

PS C:\Users\PeH> .\Desktop\EVA-Discover.ps1 -maxWait 120 -Debug -Verbose
VERBOSE: Sending discovery packet (1) ...
VERBOSE: Sending discovery packet (2) ...
DEBUG: Received UDP packet from 192.168.178.1:5035 ...
VERBOSE: Trying to connect to the FTP port to hold up the device in bootloader ...
EVA_IP=192.168.178.1
True

funktioniert nicht?

 

[_web_]

Sieht ähnlich aus, nur das er kein FTP - Verbindung aufbauen konnte. Ich habe das mehrfach versucht (parallel zu dem Lauf des Discover - Skriptes 'ftp 192.168.178.1' aufgerufen), allerdings ohne Erfolg

PS C:\Users\Sascha\Downloads\YourFritz\eva_tools> .\EVA-Discover.ps1 -maxWait 120 -Debug -Verbose
AUSFÜHRLICH: Sending discovery packet (1) ...
AUSFÜHRLICH: Sending discovery packet (2) ...
DEBUG: Received UDP packet from 192.168.178.1:5035 ...
AUSFÜHRLICH: Trying to connect to the FTP port to hold up the device in bootloader ...
DEBUG: Error during FTP connection attempt ...
EVA_IP=192.168.178.1
True

 

[PeterPawn]

Und jetzt erwartest Du tatsächlich, daß sich jemand hinstellt und "von Hand" den Inhalt dieses Pakets auswertet? Wozu gibt es die Wireshark-Dissectoren?

Aber selbst mit bloßem Auge ist ja das - inzwischen von mir mehrfach erwähnte, auch wenn Du das wohl eher nicht verstanden hast - "0x00, " im Paket zu sehen - es handelt sich also hier wohl tatsächlich wieder um eine Version des Bootloaders, die das allzu rüde Löschen des TFFS-Inhalts mit Unwillen bei der ARP-Antwort quittiert.

Das heißt dann, daß man sich jetzt als erstes mal ein vernünftiges TFFS-Image erstellen muß. Wo Du die richtigen Daten für die MAC-Adressen herbekommst, mußt Du halt selbst sehen, der Rest steht normalerweise auf dem Typenschild der Box. Welche Angaben man wo zusammensuchen kann, habe ich (damals, als das immer wieder mal Thema und noch "neu" war) mehrfach beschrieben.

Wenn man dann ein passendes TFFS-Image hat, kann man mittels "arp"-Kommando die passende MAC-Adresse für die IP der Box setzen und dann in der nunmehr möglichen FTP-Session (wenn man die richtige MAC-Adresse verwendet, sollte die FTP-Session auch funktionieren) das neu erstellte TFFS-Image in die Box schreiben.

Kriegt man nicht alle notwendigen Werte für das TFFS-Image zusammen (die Name-Table muß man dann halt von Hand erstellen bzw. irgendeine passende aus dem Board hier oder aus einem GitHub-Repo laden), kann man auch erst mal mit einer provisorischen Tabelle arbeiten ... wenn die Box erst mal wieder sauber und ohne "arp"-Kommando (den Eintrag muß man auf seinem Host-Rechner dann auch wieder löschen können, ohne daß danach nichts mehr geht) startet, kann man sich auch den Konfigurationsbereich über den Bootloader ausgeben lassen - darin stehen dann auch die "Geburtsdaten" der Box und insbesondere auch die ursprünglich vergebenen MAC-Adressen für die einzelnen Interfaces. Alles außer diesen MAC-Adressen kriegt man ja problemlos raus, solange der Aufkleber auf der Unter-/Rückseite der Box existiert.

 

[pedro_panda]

Guten Tag PeterPawn,

als erstes wollte ich mich für deine Bemühungen um das Debranden von Fritzboxen 6490 bedanken, vor allem für die von Ihnen geschriebenen Scripts.
Mich damit zu beschäftigen, war sehr lehrreich.
Mir ist auch bewusst, dass Sie schon sehr viele posts dazu verfasst haben und nachvollziehen kann, dass Sie nicht unbedingt motiviert sind, noch eine Frage zu beantworten.

Leider habe ich beim Versuch die neue Firmware per Adam/Eva zu flashen ein Tippfehler unterlaufen und habe die mtd3 und mtd4 (Environment) zerschossen. Laut Recovery Tool ist das Environment ,mtd3+4, leer.
Als Folge erreicht ftp die Adresse 192.168.178.1 nicht mehr und der Weg zum Bootloader scheint versperrt. Meine Frage: Gibt es einen Weg Sesam wieder zu öffnen?



Falls Sie doch interessiert sind: Meine Werkzeuge, die ich noch zur Hand habe: ältere Environment Ausgaben - Recovery FB 7490 - , als die Box noch zugänglich war und das Fritzbox 6490 Cable 141.06.87-Image. Die tffs-File hab ich nach folgendem Schema rekonstruiert:

7590 in Bootschleife

Moin Moin, ich habe schon viel im Forum nachgelesen, aber leider bekomme ich das nicht hin. Ich habe eine FB 7590 mit einem 1und1 Branding. Ich wollte die Fritzbox mit dem AVM Recoverytool zurücksetzten. Leider hat meine Tochter während des Flashvorgangs den Stecker gezogen. Die FB war...

www.ip-phone-forum.de

Die eigens erstellten mtd-Dateien sind leider verloren gegangen, ebenso die mittels Script erstellten Dateien env.txt und count.txt. [https://www.triebwerk23.de/joomla/index.php/firewalls/fritzbox-6490-cable-reset-bei-bootloop]

Mein aktueller Wissensstand, nachdem die Box nicht mehr mit mir kommunizieren will, ist: https://web.archive.org/web/2019010...n-der-retail-firmware-bei-fritz-box-cable-160

Vielen Dank für die Zeit, die Sie sich zum lesen nehemen. Über eine Antwort würde ich mich freuen.

mit freundlichen Grüßen Pedro

P.S. als Autodidakt kann es passieren, dass man sich auf gefährliches Halbwissen beruft, das ist wohl bei mir der Fall.
P.P.S. mir ist bewusst, dass man alte Threads nicht wiederbeleben soll, aber hier schien der TE das gleiche Problem wie mein Router zu haben.
P.P.P.S. mir gelingt es nicht, die MAC Addresse mittels Wireshark zu ermitteln, da mein LAN Anschluss die Verbindung zum Router unterbindet.
P.P.P.P.S. die Lichtorgel sagt folgendes: In Betriebnahme leuchtet die Power LED auf, danach blinkt die Info LED 4x rot, kurz Pause und wieder 4 rot.

 

[PeterPawn]

ältere Environment Ausgaben

Was bedeutet das genau?

Bitte diese Dateien hier anhängen ... solange die Daten sich rekonstruieren lassen und ein Linux-System zur Verfügung steht, wäre eine FRITZ!Box 6490 mit gelöschtem Environment (das Problem tritt auch nicht bei allen Bootloader-Versionen auf) noch zu retten. Das habe ich mittlerweile vielfach selbst gemacht, weil es solche "kaputt gespielten" Boxen (zumindest eine Zeit lang) auf eBay in Massen gab, was dann entsprechend auch die Preise drückte.

Das alles macht aber nur dann Sinn, wenn man die Daten für das Environment zusammen bekommt ... die "counter" interessieren bei der 6490 eher nicht, die gibt ohnehin nur "u" aus für jeden Wert, was dann auf 0 gesetzt wird. Die meisten Angaben kann man von anderen Boxen übernehmen, einige stehen auf dem Aufkleber auf der Rückseite des Gerätes und wieder andere braucht es entweder nicht oder sie können dann nach eigenem Gusto vergeben werden (z.B. das TR069-Kennwort).

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

Außerdem kann man - wenn man erst mal wieder per FTP an EVA kommt - diese "Geburtsdaten" einer FRITZ!Box 6490 auch aus der Sicherung der Konfiguration ("RETR config" bzw. "eva_get_environment config > config.bin" als Aufruf bei den "eva_tools") wieder extrahieren - man kann also auch erst einmal mit irgendwelchen Phantasie-Daten wieder sicherstellen, daß die ARP-Antworten der Box wieder stimmen (daß die falsch sind, ist ja die Ursache des Problems, wenn da "0x00, " (allerdings in hex) von der Box kommt) und dann hinterher anhand der Angaben im Bootloader die Daten ergänzen.

Die betroffenen Bootloader-Versionen benutzen dann als MAC-Adresse tatsächlich auch diejenige, die im Bootloader (im Konfigurationsbereich) hinterlegt ist ... man "sieht" es (in einem Packet-Dump), wenn sie auf Broadcasts an den UDP-Port 5035 mit einer Unicast-Antwort reagieren - dort ist die korrekte MAC-Adresse enthalten. Erst wenn danach dann auf L3 versucht wird, die MAC-Adresse für eine IP-Adresse (die von der Box in der vorhergehenden Unicast-Antwort auch korrekt gesetzt wurde) per ARP zu ermitteln, enthalten die ARP-Pakete eine falsche Antwort, die aus einem Buffer-Overflow resultieren dürfte.

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

Mit den Daten für das Environment generiert man sich ein TFFS-Image, setzt per "arp" eine feste Auflösung der richtigen(!) MAC-Adresse für die IP-Adresse der FRITZ!Box (hier nimmt man dann der Einfachheit halber tatsächlich 192.168.178.1 und stellt sich den Rest des verwendeten Linux-Systems passend ein) und startet die FTP-Session, nachdem das Discovery-Skript die Box gefunden hat. Wenn man die MAC-Adresse nicht ermitteln kann, weil jemand den Aufkleber auch noch entfernt hat (gab es auch schon), muß man eben die Unicast-Antwort beim Discovery mitschneiden und sich die MAC-Adresse der Box dort heraussuchen.

In der FTP-Session schreibt man dann erst mal das TFFS-Image in mindestens eine der Partitionen (mtd3/mtd4) oder auch gleich in beide, wenn man ohnehin weiß, daß diese defekt sind - was bei den Boxen mit diesem Symptomen dann tatsächlich meist der Fall ist, weil wohl immer noch irgendwelche "Anleitungen" kursieren, man könnte diese beiden Partitionen einfach mit einer leeren Datei beschreiben.

Nach einem Neustart sollte die Box (EVA) dann auch ohne den festen ARP-Eintrag (den man dann wieder entfernen sollte) per FTP erreichbar sein und kann dann "normal" weiterbehandelt werden.

EDIT: Ich habe gerade erst selbst gelesen, daß ich das fast genauso schon in #24 erläutert hatte (war halt schon vor 15 Monaten und ist ja auch nicht die einzige Beschreibung, was man machen könnte, seit 2016) ... nun weiß ich also auch nicht mehr weiter und es bleibt nur die Hoffnung, daß da #24 zuvor doch nicht so richtig gelesen (und/oder verstanden) wurde.

 

[pedro_panda]

Erstmal ein Zwischenbericht, was ich ergeben hat:

Was bedeutet das genau?

Wenn man mit der "fritz.box_7490-07.12-recover.exe" den bootloader anhalten möchte und das ganze als admin ausführt schreibt die recovery.exe einen Environment_XX.log und ftp.log:


Inhalt wie folgt:

HWRevision            213


HWSubRevision         4


ProductID             Fritz_Box_HW213a


SerialNumber          0000000000000000


annex                 Kabel


autoload              yes


bootloaderVersion     1.2411


bootserport           tty0


cpufrequency          1200000000


firstfreeaddress      0x00b20000


firmware_info         141.06.65


firmware_version      avm


flashsize             nor_size=0MB sflash_size=2MB nand_size=2048MB


language              de


linux_fs_start        1


maca                  C8: Vorhanden


macb                  C8: Vorhanden


macwlan               C8: Vorhanden


macwlan2              C8: Vorhanden


macdsl                C8: Vorhanden


memsize               0x10000000


modetty0              38400,n,8,1,hw


modetty1              38400,n,8,1,hw


modulemem             3862387


mtd0                  0x0,0x4000000


mtd1                  0x4000000,0x4800000


mtd2                  0xa0000,0xc0000


mtd3                  0xc0000,0x100000


mtd4                  0x100000,0x140000


mtd5                  0x140000,0x1e0000


mtd6                  0x4800000,0x8800000


mtd7                  0x8800000,0x9000000


mtd8                  0x0,0x80000


mtd9                  0x80000,0x90000


mtd10                 0x90000,0xa0000


mtd11                 0x9000000,0xd000000


mtd12                 0xd000000,0xd800000


mtd13                 0xd800000,0x11800000


mtd14                 0x11800000,0x12000000


my_ipaddress          192.168.178.1


prompt                Eva_AVM


req_fullrate_freq     100000000


sysfrequency          100000000


tr069_passphrase      Vorhanden


tr069_serial           Vorhanden


urlader-version       3411


usb_board_mac         C8: Vorhanden


usb_device_id         0x0000


usb_device_name       USB DSL Device


usb_manufacturer_name  AVM


usb_revision_id       0x0000


usb_rndis_mac         C8: Vorhanden


wlan_key               Vorhanden

Anmerkung zum Code: hier wird die Firmware als avm genannt, also sollte die Log nach "quote SETENV firmware_version avm" enstanden sein. Aber da das eine gebrandete Vodafone war wird es wohl kdg gewesen sein.


Des weiteren ist es mir auch gelungen, wie Sie schon beschrieben haben, per arp und der maca Adresse aus dieser environment_XX.log wieder mit EVA zu kommunizieren. (Dies erstmal unter Windows, aber mit meinem Arch-Linux sollte ich das auch noch hinbekommen)


Mein nächster Arbeitsschritt wäre die tffs dateien diesmal richtig zu schreiben und diese in mtd3/4 zu laden und dann nach

Wayback Machine

web.archive.org

fort zu fahren.

EDIT: Ich habe gerade erst selbst gelesen, daß ich das fast genauso schon in #24 erläutert hatte (war halt schon vor 15 Monaten und ist ja auch nicht die einzige Beschreibung, was man machen könnte, seit 2016) ... nun weiß ich also auch nicht mehr weiter und es bleibt nur die Hoffnung, daß da #24 zuvor doch nicht so richtig gelesen (und/oder verstanden) wurde.

Gelesen schon, aber das Verstehen dauert ein wenig. Zumal sehr viel zu diesen Boxen geschrieben wurde, aber bei teilweise 100 Thread Seiten sieht man auch den Wald für lauter Bäumen manchmal nicht.
So langsam ergibt das auch alles Sinn

 

[PeterPawn]

Alles gut ... und wer sich wirklich selbst um die Lösung bemüht und dann nicht weiterkommt oder sich doch lieber noch einmal vergewissert, der wird hier auch Hilfe finden/erhalten.

In diesem Sinne von mir ein "Daumen hoch" - daß man ggf. nicht alles auf Anhieb versteht/durchblickt, ist weder ein Problem noch ungewöhnlich. Einfach selbst (mit der gebotenen Vorsicht, bei der man sich überlegt, was die Konsequenzen eines Fehlers wären) probieren und bei unerwarteten/unverständlichen Ergebnissen dann besser nachfragen, als die Box tatsächlich zum Briefbeschwerer zu machen.

 

[pedro_panda]

So, da bin ich wieder.
Nach einigem Probieren habe ich zwar die ./build_tffs_image mit den angegeben Parametern zum laufen gebracht, aber das Ergebnis heißt dann mtd.dmg und nicht mtd.img (siehe Terminal log file) und sieht seltsam aus. Die Datei lässt sich nicht mittels ./dissect_tffs_dump verifizieren, da der Prozess kein Ende findet (Loop)

mtd.dmg-Datei

ˇˇˇ˛ˇº˛@LØAutoMDIXDMCHWRevisionHWSubRevisionProductIDSerialNumber©annexÅautoloadbb0bb1bb2bb3bb4bb5bb6bb7bb8 bb9ÇbootloaderVersionÉbootserport¨bluetooth_keyÑbluetooth®countryÖcpufrequency°crashÜfirstfreeaddressÆfirmware_info¶firmware_versionáflashsizeπjffs2_size†kernel_argsükernel_args1ßlanguageòlinux_fs_startàmacaâmacbämacwlanñmacwlan2ãmacdslåmemsizeçmodetty0émodetty1ƒmodulemem∞mtd0±mtd1≤mtd2≥mtd3¥mtd4µmtd5∂mtd6∑mtd7∫mtd8ªmtd9ºmtd10Ωmtd11æmtd12ømtd13∆mtd14«mtd15èmy_ipaddress≈plc_dak_nmkêprompt√provider™ptestëreservedíreq_fullrate_freqìsysfrequency¡tr069_passphrase¿tr069_serial˝urlader-versionîusb_board_mac¢usb_device_id§usb_device_name•usb_manufacturer_name£usb_revision_idïusb_rndis_mac¬webgui_pass∏wlan_cal´wlan_key»wlan_ssidˇˇ

Terminal Log File, hier muss auch etwas nicht rund gelaufen sein. Deuter auf einen OSI-Layer 8 Fehler von meiner Seite aus hin.

~/bin/yourfritzness/tffs (master*) [10:19:04]
alfred$ ./build_tffs_image ~/env.txt ~/count.txt > mtd.img
name table entry for 'reboot_major' not found, value ignored
name table entry for 'reboot_minor' not found, value ignored
name table entry for 'run_hours' not found, value ignored
name table entry for 'run_days' not found, value ignored
name table entry for 'run_mounths' not found, value ignored
name table entry for 'run_years' not found, value ignored
./build_tffs_image: line 46: : No such file or directory
./build_tffs_image: line 50: shift: 3: shift count out of range
~/bin/yourfritzness/tffs (master*) [10:22:34]

Nicht das einfachste Projekt um seine Skills zu vertiefen, aber man wächst mit seinen Aufgaben

Desweiteren hätte ich noch eine Frage bezüglich der Zuordnung der Box im Netzwerk:
da ja Partition 3 und 4 zur Zeit leer sind und Box ihre Mac Adresse "vergessen" hat, habe ich in Windows' Cmd zunächst den arp cache mittels
"arp -d" geleert und dann über "arp -s ip mac addresse" im Grunde dem arp Cache gesagt, dass die ip Adresse genau diese MAC Adresse hat.

wie wäre hier das Equivalent dazu in Linux. Es würde mir einige Zeit an Nachforschungen ersparen.

Danke bereits im Voraus

 

[PeterPawn]

arp(8) - Linux manual page

oder die neuere Version mit "ip":

ip-neighbour(8) - Linux manual page

Der Dateiname der "Ausgabedatei" des "build_tffs_image" ist ja das, was da hinter der Redirection (dem ">") von Dir angegeben wurde beim Aufruf - irgendwo da muß dann also auch der Tippfehler liegen, wenn das File plötzlich "mtd.dmg" heißen sollte.

Der korrekte Aufruf von "build_tffs_image" steht in der Datei selbst: https://github.com/PeterPawn/YourFritz/blob/master/tffs/build_tffs_image#L10 - wenn ich das mit dem "Terminal-Log" vergleiche, werde ich den Eindruck nicht los, daß da etwas nicht stimmen würde bei Deinem Aufruf.

Außerdem besteht das Ganze aus mehreren Skript-Dateien und daher ist der Download einzelner Dateien eher nicht wirklich zielführend (hier aber offensichtlich erfolgt), solange man die Zusammenhänge nicht kennt und auch alle notwendigen Dateien an die richtigen Stellen lädt. Das Einfachste ist es da tatsächlich, das gesamte Repository zu klonen - dann stimmen auch Links und relative Pfadangaben automatisch.

 

[NDiIPP]

(z.B. das TR069-Kennwort).

Hiermit sei auch noch einmal darauf hingewiesen, dass das nicht sein muss. Denn die kompletten "Credentials" (inkl. Passwort) für den CWMP-Account sind ebenfalls auf dem Aufkleber auf der Rückseite vorzufinden, wenn auch nicht im Klartext sondern in einem 2D-Code versteckt. @eisbaerin hatte mich mal darauf Aufmerksam gemacht (hatte ich zwischendurch auch mal wieder vergessen, weshalb er mich erneut darauf aufmerksam machen musste).

Hatte ja auch schon solche 6490er und dank der Informationen aus dem 2D-Code konnte ich das ursprüngliche Environment wohl zu 100% wiederherstellen (inkl. dem originalen CWMP-Account).

 

[PeterPawn]

Nicht jeder hat den Barcode-Reader oder eine App für den Code (das war wohl mal für die Provider gedacht, da gab es die CWMP-Daten auch noch einmal auf dem Karton als Aufkleber) ... daher auch mein Hinweis (ich wußte schon nicht mehr, daß ich den vor 15 Monaten auch schon gegeben hatte), daß das in der "config" ebenfalls alles noch einmal steht - inkl. der richtigen Reihenfolge der verschiedenen MAC-Adressen, die man sonst ja auch eher erraten müßte (wobei die wieder egal sind, wenn man von "maca" (für EVA) und "macdsl" (für das eCM) absieht).

 

[pedro_panda]

Oh, das ist mir jetzt aber peinlich. Definitiv wurde von mir die Nametable beim Aufruf vergessen. So wird das nichts.
Auch mit der Kontrolle mittels ./dissect_tffs_dump wird es wohl nichts, da im Skript ja steht, dass das nicht mit "NAND based TFFS dump" funktioniert.
Laut Wikipedia hat die 6490 aber NAND Speicher. Korregiert mich bitte, wenn da zwei unterschiedliche Dinge in einen Topf schmeisse.

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

Ich hab das jetzt noch mal ordentlich gemacht, das git hatte ich zwar geklont, aber dem Grundsatz "keep it simple" widersprochen, als ich die Aufrufe quer durch meinen Root Tree gejagt habt. Jetzt kam folgendes Ergebnis dabei rum:

Der Inhalt der mtd.img Datei im TextEdit (OS x)

ˇˇˇ˛ˇº˛@LØAutoMDIXDMCHWRevisionHWSubRevisionProductIDSerialNumber©annexÅautoloadbb0bb1bb2bb3bb4bb5bb6bb7bb8 bb9ÇbootloaderVersionÉbootserport¨bluetooth_keyÑbluetooth®countryÖcpufrequency°crashÜfirstfreeaddressÆfirmware_info¶firmware_versionáflashsizeπjffs2_size†kernel_argsükernel_args1ßlanguageòlinux_fs_startàmacaâmacbämacwlanñmacwlan2ãmacdslåmemsizeçmodetty0émodetty1ƒmodulemem∞mtd0±mtd1≤mtd2≥mtd3¥mtd4µmtd5∂mtd6∑mtd7∫mtd8ªmtd9ºmtd10Ωmtd11æmtd12ømtd13∆mtd14«mtd15èmy_ipaddress≈plc_dak_nmkêprompt√provider™ptestëreservedíreq_fullrate_freqìsysfrequency¡tr069_passphrase¿tr069_serial˝urlader-versionîusb_board_mac¢usb_device_id§usb_device_name•usb_manufacturer_name£usb_revision_idïusb_rndis_mac¬webgui_pass∏wlan_cal´wlan_key»wlan_ssid2134Fritz_Box_HW213a0000000000000000©KabelÅyesÇ1.2411Étty0Ö1200000000Ü0x00b20000Æ
141.06.50¶VFá.nor_size=0MB sflash_size=2MB nand_size=2048MBßdeò0à _MACADRESSE_ ä _MACADRESSE_ ñ _MACADRESSE_ ã _MACADRESSE_ å0x10000000ç38400,n,8,1,hwé38400,n,8,1,hwƒ3862387∞0x0,0x4000000±0x4000000,0x4800000≤0xa0000,0xc0000≥0xc0000,0x100000¥0x100000,0x140000µ0x140000,0x1e0000∂0x4800000,0x8800000∑0x8800000,0x9000000∫0x0,0x80000ª0x80000,0x90000º0x90000,0xa0000Ω0x9000000,0xd000000æ0xd000000,0xd800000ø0xd800000,0x11800000∆0x11800000,0x12000000è192.168.178.1êEva_AVMí
100000000ì
100000000¡

[...] weiter unten stehen dann noch die MAC Adressen, ähnlich chiffriert.

Vim (OS X)

^@^A^@^Dÿÿÿþ^Aÿ^D¼^@^@^Aþ@L^@^@^@^@^A¯AutoMDIX^@^@^@^@^@^@^A^CDMC^@^@^@^A^@HWRevision^@^@^@^@^A^DHWSubRevision^@^@^@^@^@^A^AProductID^@^@^@^@^@^A^BSerialNumber^@^@^@^@^@^@^A©annex^@^@^@^@^@^A<81>autoload^@^@^@^@^@^@^B^@bb0^@^@^@^B^Abb1^@^@^@^B^Bbb2^@^@^@^B^Cbb3^@^@^@^B^Dbb4^@^@^@^B^Ebb5^@^@^@^B^Fbb6^@^@^@^B^Gbb7^@^@^@^B^Hbb8^@^@^@^B bb9^@^@^@^A<82>bootloaderVersion^@^@^@^@^@^A<83>bootserport^@^@^@^A¬bluetooth_key^@^@^@^@^@^A<84>bluetooth^@^@^@^@^@^A¨country^@^@^@^A<85>cpufrequency^@^@^@^@^@^@^A¡crash^@^@^@^@^@^A<86>firstfreeaddress^@^@^@^@^@^@^A®firmware_info^@^@^@^@^@^A¦firmware_version^@^@^@^@^@^@^A<87>flashsize^@^@^@^@^@^A¹jffs2_size^@^@^@^@^A kernel_args^@^@^@^A<9f>kernel_args1^@^@^@^@^@^@^A§language^@^@^@^@^@^@^A<98>linux_fs_start^@^@^@^@^A<88>maca^@^@^@^@^@^@^A<89>macb^@^@^@^@^@^@^A<8a>macwlan^@^@^@^A<96>macwlan2^@^@^@^@^@^@^A<8b>macdsl^@^@^@^@^A<8c>memsize^@^@^@^A<8d>modetty0^@^@^@^@^@^@^A<8e>modetty1^@^@^@^@^@^@^AÄmodulemem^@^@^@^@^@^A°mtd0^@^@^@^@^@^@^A±mtd1^@^@^@^@^@^@^A²mtd2^@^@^@^@^@^@^A³mtd3^@^@^@^@^@^@^A´mtd4^@^@^@^@^@^@^Aµmtd5^@^@^@^@^@^@^A¶mtd6^@^@^@^@^@^@^A·mtd7^@^@^@^@^@^@^Aºmtd8^@^@^@^@^@^@^A»mtd9^@^@^@^@^@^@^A¼mtd10^@^@^@^@^@^A½mtd11^@^@^@^@^@^A¾mtd12^@^@^@^@^@^A¿mtd13^@^@^@^@^@^AÆmtd14^@^@^@^@^@^AÇmtd15^@^@^@^@^@^A<8f>my_ipaddress^@^@^@^@^@^@^AÅplc_dak_nmk^@^@^@^A<90>prompt^@^@^@^@^AÃprovider^@^@^@^@^@^@^Aªptest^@^@^@^@^@^A<91>reserved^@^@^@^@^@^@^A<92>req_fullrate_freq^@^@^@^@^@^A<93>sysfrequency^@^@^@^@^@^@^AÁtr069_passphrase^@^@^@^@^@^@^AÀtr069_serial^@^@^@^@^@^@^Aýurlader-version^@^@^@^A<94>usb_board_mac^@^@^@^@^@^A¢usb_device_id^@^@^@^@^@^A¤usb_device_name^@^@^@^A¥usb_manufacturer_name^@^@^@^@^@^A£usb_revision_id^@^@^@^A<95>usb_rndis_mac^@^@^@^@^@^AÂwebgui_pass^@^@^@^A¸wlan_cal^@^@^@^@^@^@^A«wlan_key^@^@^@^@^@^@^AÈwlan_ssid^@^@^@^A^@^@^D213^@^A^D^@^B4^@^@^@^A^A^@^QFritz_Box_HW213a^@

VIM (Arch Linux) sieht nochmal ganz anders aus, zumindest kann ich dort Daten aus der Env.txt mit dem bloßen Auge sehen Zur Not poste ich mal einen Screenshot, ob das was bringt, weiß ich leider nicht

 

[PeterPawn]

wenn da zwei unterschiedliche Dinge in einen Topf schmeisse.

Das ist tatsächlich so, daß da Äpfel und Pferdeäpfel verglichen werden.

Ein TFFS-Image, das mit dem Skript erstellt wurde, verwendet das "legacy format" von AVM und kann zur Kontrolle auch wieder zerlegt werden (sonst würde ich das ja nicht immer so beschreiben, daß man das zur Sicherheit noch einmal zerlegen lassen soll).

Die Umsetzung in die richtigen Strukturen bei anderen TFFS-Formaten übernimmt dann der Bootloader beim Schreiben der Daten. Außerdem ist die Angabe, daß die 6490 NAND-Flash für die TFFS-Partitionen verwenden würde, ohnehin falsch - dafür hat sie einen 2 MB großen SPI-Flash an Bord, in dem auch der Bootloader gespeichert ist (siehe "flashsize").

Man kann das also durchaus wieder zerlegen zur Kontrolle - ansonsten ist es aber auch Unfug, den Inhalt hier in Form einer Textdatei zeigen zu wollen. Das sind nun mal binäre Daten und wenn man das tatsächlich jemandem zeigen wollte (Warum eigentlich genau? Meine Frage(n) bezog(en) sich ja nur auf die Ausgangsdaten für die "Kontrolle", ob das alles vorhanden ist.), dann wohl am ehesten als Hexdump der Datei.

Schlauer wäre es aber ohnehin, nach erfolgreichem Zerlegen und Vergleich, daß die dabei separierten Daten denen entsprechen, aus welchen das Image zusammengestellt wurde, endlich mal auf die Box zu bringen und danach dann nach der Anleitung zum Flashen der 6490 weiterzumachen.

Wobei es sicherlich auch nicht verkehrt ist, vorher noch einiges zu lesen ... irgendwo weiter vorne habe ich etwas von einer Annahme gelesen, daß "firmware_version = kdg" angeblich richtig sein sollte (was natürlich Quatsch ist, wenn man die Retail-Firmware installieren will - egal, was auf dem Typenschild stehen mag) und irgendwie kann ich in dem Zeug, was da in #33 steht, weder "avm" noch "kdg" als Zeichenkette sehen (vielleicht übersehe ich die aber auch nur, weil das so als Textanzeige natürlich Kohl ist).

 

[pedro_panda]

Man kann das also durchaus wieder zerlegen zur Kontrolle - ansonsten ist es aber auch Unfug, den Inhalt hier in Form einer Textdatei zeigen zu wollen. Das sind nun mal binäre Daten und wenn man das tatsächlich jemandem zeigen wollte (Warum eigentlich genau? Meine Frage(n) bezog(en) sich ja nur auf die Ausgangsdaten für die "Kontrolle", ob das alles vorhanden ist.), dann wohl am ehesten als Hexdump der Datei.

Vielen Dank für die Erklärung, wieder was gelernt.

Wobei es sicherlich auch nicht verkehrt ist, vorher noch einiges zu lesen ... irgendwo weiter vorne habe ich etwas von einer Annahme gelesen, daß "firmware_version = kdg" angeblich richtig sein sollte (was natürlich Quatsch ist, wenn man die Retail-Firmware installieren will - egal, was auf dem Typenschild stehen mag) und irgendwie kann ich in dem Zeug, was da in #33 steht, weder "avm" noch "kdg" als Zeichenkette sehen (vielleicht übersehe ich die aber auch nur, weil das so als Textanzeige natürlich Kohl ist).

Das avm oder kdg bezieht sich auf die ausgegebene Environment Datei des Recovery Programms für die 7490, das ich zum anhalten des BootLoaders verwendet habe. Die Recovery schreibt ja ein Protokoll der Environment Partition mit, wenn man mit dem Programm versucht damit eine 6490 zu recovern. (siehe Post #27)
Klar, am Ende des Tages hat da avm zu stehen, wenn man das ganze dann debranden will.

Schlauer wäre es aber ohnehin, nach erfolgreichem Zerlegen und Vergleich, daß die dabei separierten Daten denen entsprechen, aus welchen das Image zusammengestellt wurde, endlich mal auf die Box zu bringen und danach dann nach der Anleitung zum Flashen der 6490 weiterzumachen.

So sieht der Plan aus, erstmal scheiter ich gerade an der Kontrollle, du hast mir ja gerade bestätigt, dass meine Annaheme, dass das nicht ginge, weil der Speicher NAND sei, falsch ist. Ergo das Zerlegen muss funktionieren, meine Anwendung ist wohl falsch. Ich kümmere mich nachher mal darum.

Der Fahrplan ist wie folgt:

- mtd.img erstellen und kontrollieren
- mittels arp EVA guten Tag wünschen
- mtd wieder in mtd3/4 flashen
- diesmal alles richtig einstellen und das firmware Image das ich in #25 erwähnt habe zu flashen
- hoffentlich wieder zugriff auf das fritz.box Interface haben
- zurücksetzen auf Werkseinstellungen

Falls Lücken oder Logikfehler im Fahrplan sind, korregieren ich natürlich gerne

Edit: mittels "./sudo ./dissect_tffs_dump < mtd.img" ist mir jetzt auch gelungen, die Datei aufzuspalten.
Wo die Daten hinkommen kam nicht als Aussage per stdout, sondern sind einfach im /tmp Ordner gelandet.
als Ergebnis gab es einen Ordner mit einem Haufen .bin Dateien, nodelist, tffsdump und eine nametable.txt Datei.
irgendwie bin ich davon ausgegangen, dass da jetzt auch eine env.txt und count.txt bei rum kommt.
Aber wenn eine nametable mit identischem Inhalt wie in der ursprünglich nametable dabei rauskommt, sollte das ja bedeuten, dass die mtd.img richtig ist?

Grüße