FritzBox 6490 MAC Ändern - Ich will es wirklich!

[Flole]

Hi,

ich habe einige Beobachtungen die ich gerne Teilen möchte und sich daraus ergebende Fragen die Speziell auf das ändern der CM-MAC abzielen bzw. auf den Weg den ich dabei gehe. Dies wird keine Schritt-bei-Schritt Anleitung sondern ist eher als proof-of-concept gedacht. Konkret sind mir folgende Dinge aufgefallen:

1. Das cm_cert.cer enthält die volständige MAC (soweit alles super, hier kommt mein neues Cert hin)
2. Der cm_key_prv.bin hat ein komisches Format (wie ist dieses aufgebaut bzw was verbirgt sich dahinter? Es ist nicht pkcs7, 8, 12 und auch nicht PEM. Ist diese Datei eventuell Verschlüsselt? Ein bisschen disassemblieren der liball_docsis.idb bringt einen Aufruf von bpicrypto zutage, vielleicht hat das was damit zu tun?)
3. mfg_cert.cer enthält das AVM Manufacturer Cert, vermutlich um die Chain zu bilden und an die CMTS zu senden
4. mfg_key_pub.bin hat wieder ein komisches Format, und ich hab absolut keine Ahnung was die bewirken soll bzw wofür diese gebraucht wird. Das Manufacturer Cert liegt doch schon in der mfg_cert.cer, mehr braucht man doch für die Cert Chain nicht. Auch kann ich in keiner Binary eine Verwendung hiervon finden (zumindest nicht auf dem ARM)
5. 1/1 enthält die letzten 6 stellen der MAC (was tut diese Datei? Warum nur die letzten 3 Stellen? Wie ist diese Datei aufgebaut? Ist diese optional da sie in /etc/docsis/nvramdontremove nicht erwähnt wird? Ist die in einer brandneuen Box vor dem Start schon vorhanden oder wird irgendwann erzeugt? Es gibt ein Script um Zertifikate aus /var/tmp/urladercerts.tar.gz zu holen, da werden nur die cm_cert.cer cm_key_prv.bin mfg_cert.cer mfg_key_pub.bin berücksichtigt. Würde es also reichen die Zertifikate in diese Datei zu packen? Wo dieses tar Archiv herkommt ist mir allerdings schleierhaft)
6. Steht die MAC noch zusätzlich im env und muss dort ebenfalls angepasst werden?
7. Wenn das alles getan ist: Wars das dann und sollte es dann mein von der CableLabs Test-CA signiertes Test-Zertifikat an meiner Test-CMTS die besagter Test-CA vertraut funktionieren?

Man sieht vielleicht schon das dies nicht wirklich einen nutzen für die breite Masse hat (da man nicht einfach Zertifikaten in der CMTS vertrauen kann wie man lustig ist), trotzdem würde ich das ganze gerne einfach mal testen um auch endgültig zu zeigen das es theoretisch möglich ist die MAC zu ändern und die FritzBox so zu nutzen (wenn man denn dann eine CMTS rumstehen hat die man selbst verwaltet). Ein Backup des NVRAM habe ich natürlich erstellt. Ich scheitere nun ja aber schon an Punkt 2, bzw. an dem Format das diese Datei hat.

 

[PeterPawn]

Zu 2.) Das ist überhaupt kein "komisches Format" ... das ist "stinknormales" BER (ASN.1) und genau derselbe Inhalt (abgesehen von "Kopfzeilen", die ja gleichzeitig die Information über den Inhalt der Base64-kodierten Daten "transportieren"), wie ihn ein PEM-File hätte - nur eben als binäre Daten.

Üblicherweise nennt man dieses Format (eigentlich ist es gar keines, weil es eben die reinen Binärdaten sind) DER - genauer wäre hier: DER-kodierte Daten. Das mußt Du ja aber auch schon irgendwie entdeckt haben, denn auch die Zertifikate liegen ja nur DER-kodiert vor.

Nun, da es sich bei diesen "Gegenstücken" zu den anderen beiden "bin"-Files ja um RSA-Zertifikate handelt (auch hier wäre wieder "Zertifikate für öffentliche Teile eines RSA-Schlüssels" die korrektere Formulierung), liegt es irgendwie nahe, daß es sich bei den binären Dateien ebenfalls um RSA-Keys handeln sollte.

Für die Speicherung solcher Daten gibt es mehrere Quasi-Standards (teilweise auch in RFCs verewigt und die wichtigsten beim Umgang der FRITZ!Box mit RSA-Zertifikaten habe ich (zum Signieren von Firmware-Images) hier für Windows mal in PowerShell nachgebaut, da stehen dann auch die Nummern der RFCs in den Kommentaren zum "Selbstnachlesen") und da es sich eben um binäre Daten handelt, die keinerlei Information über das Format und/oder den Inhalt der Datei enthalten, muß man halt beim Versuch der Verarbeitung mit Standard-Programmen wie "openssl" auch ganz genau angeben, worum es sich nun handeln soll beim Inhalt.

Das eine ist jedenfalls ein kompletter RSA-Key inkl. der privaten Faktoren und das andere eine Datei, die nur die öffentlichen Bestandteile eines anderen Schlüssels enthält - das ist allerdings derselbe (Modulus: 00:f9...0f:a7), der in der "mfg_cert.cer" von der EuroDOCSIS-Verwaltung in Belgien für AVM "unterschrieben" wurde.

"openssl" (das CLI-Utility) kennt dann für die Verarbeitung von RSA-Keys z.B. die Unterfunktion mit dem abwegigen Namen "rsa" und mit dieser kriegt man die Schlüsseldateien auch in eine "Textform" (auch wenn das nur "big numbers" mit den Bestandteilen des Schlüssels sind, die da angezeigt werden).

Damit sollte sich 4) auch selbst erklären. Diese Dateien liegen da halt "zusätzlich" (beim privaten Schlüssel geht das gar nicht anders, weil das Zertifikat ja die privaten BNs nicht enthält und durch die separate Speicherung des öffentlichen Schlüssels von AVM muß man den nicht immer erst aus dem Zertifikat herausklamüsern, wenn man ihn mal brauchen sollte) noch in binärer Form herum - ob AVM den öffentlichen Schlüssel nun noch weiterhin irgendwo verwendet oder nicht.

Solange die Boxen ihre Zertifikate "on-the-fly" signierten (mit dem alten, hoffentlich inzwischen bei allen Providern gesperrten Schlüssel von AVM), gab es ja sogar den kompletten privaten Schlüssel des Herstellers in jeder Firmware (die CVC-Keys (der Public-Teil natürlich nur) und -Zertifikate liegen heute noch irgendwo unter "/etc/docsis" im ARM-Image, wenn ich mich nicht irre) ... anfangs war der noch vollkommen "blank" und später wurde er dann notdürftig verschlüsselt.

6) kann eigentlich nur ein (schlechter?) Witz sein ... denn das ist nun eine "Frage", die man sich jederzeit selbst beantworten kann, wenn man Zugriff auf eine Box hat - dasselbe gilt für den Teil mit dem Tarball in Frage 5.

Die Kernel-Quellen sind schließlich verfügbar und die Shell-Kommandos in der "docsiscertdefaults" (oder so ähnlich, das ist nur aus dem Kopf) kann auch jeder nachlesen ... damit klärt sich die Frage, "wo die herkommen" dann wieder von alleine, wenn man es nicht hier im IPPF findet (wo ich es zugegebenermaßen aber auch nur "erwähnt" hatte, wie das Ganze abläuft und das dann nicht weiter ausgewalzt habe - aus naheliegenden Gründen).

Da das aber im Verlauf der "Fragen" auch immer mehr in die Richtung des Klonens einer Box geht, war's das dann von meiner Seite mit Informationen (das Vorstehende ist ohnehin bereits bekannt oder durch eigene Recherche ziemlich einfach zu ermitteln) ... den Sinn oder Nährwert von 7) verstehe ich ohnehin nicht so ganz. Wenn es nur um reines technisches Interesse geht, wie das Ganze eigentlich funktioniert, muß man das ja noch lange nicht "nachbauen" wollen und wenn mir jemand etwas von einer "privaten Test-CMTS" erzählt, bin ich erst mal skeptisch.

Da (m.W. jedenfalls) sämtliche Authentifizierungsversuche mit dem CM-Zertifikat nur in die Richtung der RF-Interfaces erfolgen, kann man das eigentlich nicht auf der LAN-Seite einer Box testen und wieso jemand daheim (und "privat") den kompletten Aufbau eines Kabelnetzes betreiben sollte (mal abgesehen von der Frage, wo man so eine "private CTMS" denn herbekommen kann), erschließt sich sicherlich auch nicht jedem auf den ersten Blick.

Da liegt dann (leider) zu oft die Vermutung nahe, daß es sich gar nicht wirklich um eine "private Test-CTMS" handelt und jemand eher damit beginnen will, eine "alte" FRITZ!Box 6490 ohne neues Zertifikat so zu manipulieren, daß sie doch noch vom Provider provisioniert wird. Davon würde ich aber deutlich abraten ... und das auch nicht nur als "Schutzbehauptung".

Denn hier gibt es meiner Ansicht nach gar nichts weiter "nachzuweisen" oder als "theoretisch möglich" zu zeigen ... ja, man kann (bekanntermaßen) die MAC-Adresse einer FRITZ!Box ändern (auch wenn es nicht so ganz simpel ist, das "bootfest" zu machen). Solange man dann nicht - für diese neue Adresse - auch das passende CM-Zertifikat hat (das von AVM signiert wurde) und den dazugehörenden privaten Schlüssel, nutzt einem das aber nichts - zumindest nicht bei einem Provider, der das beim Provisionieren der Box ordentlich testet.

Das war genau der Pferdefuß am früheren Umgang von AVM mit dem ersten Hersteller-Zertifikat. Da wurde extra die Firmware so angepaßt, daß sie beim "blanken" Start (also in Werkseinstellungen) für die gerade eingestellte MAC-Adresse ein gültiges(!) Zertifikat selbst generierte ... was im Kabelnetz nun mal ein "no go" ist, da die Identifikation des Kunden über die Verknüpfung der Kundendaten mit dieser CM-MAC erfolgt.

Das Klonen der Identität von Kabel-Endgeräten ist auch kein "Der will doch nur spielen." ... und damit gehört es (allerspätestens bei irgendwelchen Erklärungen, wie man dazu vorgehen sollte - egal ob die nun "step by step" sind oder nur als "proof of concept" daherkommen) auch nicht in ein öffentliches Forum. Wie gesagt ... die oben stehenden Informationen von meiner Seite sind bereits bekannt und nicht neu bzw. sehr simpel zu ermitteln (speziell die Dateiinhalte); außerdem reichen sie (glücklicherweise) noch nicht aus, um damit wirklich eine Box klonen zu können.

 

[NDiIPP]

Da liegt dann (leider) zu oft die Vermutung nahe, daß es sich gar nicht wirklich um eine "private Test-CTMS" handelt und jemand eher damit beginnen will, eine "alte" FRITZ!Box 6490 ohne neues Zertifikat so zu manipulieren, daß sie doch noch vom Provider provisioniert wird.

Ich hatte ja eher den Verdacht, dass der TO eine beim Kabelnetzbetreiber bereits gelistete Fritzbox dennoch verwenden möchte. Also beispielsweise eine ehemalige Vodafone-Box mit neuem CM-Zertifikat, welche nun entbrandet und mit Retail-Firmware ausgestattet ist, an einem Vodafone-Anschluss doch als "freie" Fritzbox verwenden zu können.

Edit:
Oder eben um das neue Zertifikat einer anderen Box, entsprechend geändert, auf eine alte Box kopieren zu können welche dieses neue Zertifikat noch nicht hat um diese somit weiterhin verwenden zu können.

Aber das war auch mein letzter Kenntnisstand, dass beides so nicht möglich ist in Verbindung mit dem neuen CM-Zertifikat da dieses bei einer geänderten MAC-Adresse von AVM signiert werden müsste. Ein reines ändern der MAC-Adresse, nicht nur im Environment sondern auch in den Zertifikatsdateien (egal welches Format die haben), kann (imo) nicht ausreichen denn damit wäre ja dann das Zertifikat ungültig, oder?.

 

[Flole]

Hallo Peter,

Vielen Dank für deine Antwort und deine Ausführungen. Das DER Format hatte ich ganz "vergessen", ich war dort von PKCS ausgegangen. Jetzt kann ich jedoch auch meine Keys ins passende Format ändern.

In /etc/docsis/security liegen (zumindest in der 6.85) die Zertifikate der EuroDocsis Root CA sowie der Test-CA (die ich nutzen werde).

Warum man so etwas testen möchte will ich dir sehr gerne erklären: Ursprünglich ging es darum zu schauen was der Provider über DOCSIS tatsächlich so alles tun kann und auch bestimmte Dinge "einfach mal auszuprobieren". Eine CMTS kannst du dir für sowas bei Alibaba kaufen, mit 1200€ + Zoll bist du dabei und kannst selbst zum Kabelanbieter werden (wenn auch mit sehr begrenzter Bandbreite). Im Unitymedia Forum gibt es übrigens noch jemanden der sich eine chinesische CMTS gegönnt hat.

Eine alte FritzBox kann man ohne gültiges Zertifikat auch nicht mehr fit bekommen, egal was man da verrücktes versucht. Und ein gültiges Zertifikat bekommt man nur wenn man bei CableLabs bezahlt und sonst noch einige Anforderungen einhält. Aber das ist auch gar nicht mein Ziel, sondern das nutzen einer Fritzbox mit einer eigenen CA an einer eigenen CMTS die dieser CA vertraut (und hier ist zumindest für mich klar das es nie an einer anderen CMTS funktionieren wird, warum sollten die auch meiner gestern erst erstellten CA vertrauen (zumal sie natürlich selbstsigniert ist).

Das was NDilPP da beschreibt funktioniert nicht, wie du schon selbst richtig erkannt hast. Man kann nicht "mal eben" so ein Zertifikat verändern, also da ist nicht mal eben neue Mac Adresse eintragen und das ganze dann nutzen, dadurch wäre das ganze ja auch relativ sinnfrei. Wenn das funktionieren würde, dann würde man das eher an tausend anderen Orten nutzen, aber bestimmt nicht im Kabelnetz. Es funktioniert im Kabelnetz eben nur, wenn man selbst eine CA ist und das CMTS dieser CA aus irgendeinem Grund vertraut, entweder weil die CA von der CableLabs Root CA signiert wurde, oder aber weil man die CA in der CMTS eingetragen hat.

Zusammenfassend ist dies weder dazu geeignet um ehemalige Providerboxen doch irgendwie provisioniert zu bekommen, noch dazu um old/old Boxen an dem "öffentlichen" Kabelnetz zu betreiben, aber das ist auch gar nicht die Motivation oder der Sinn hinter dieser Aktion.

 

[vaxinf]

Für den Preis von 1200 Euronen für die CMTS kann ich mir aber doch einige neue FB6490er kaufen, die überall provisioniert werden.

 

[PeterPawn]

mit 1200€ + Zoll bist du dabei

Das war u.a. auch der Grund, warum ich das "privat" für sehr, sehr außergewöhnlich halten würde (wobei es schon komische Hobbys gibt) - zumal der praktische "Nutzwert" einer eigenen CMTS sich mir max. noch bei jemandem eröffnet, der damit am Ende einen Block von Wohnhäusern o.ä. versorgen will (über Lizenzfragen und Zulassungspflichten denke ich dabei jetzt mal gar nicht erst nach).

Für rein theoretische Überlegungen, wie das gehen würde mit BPI+ und EAE (und selbst für entsprechende "Gehversuche", die man auch nicht notgedrungen in aller Öffentlichkeit dokumentieren muß), reicht es ja bereits aus zu verfolgen, ob die Netzwerk-Kommunikation zwischen CMTS und CM bei der Authentifizierung so läuft, wie man es erwartet - dazu braucht man ja nicht den "ganz großen Versuchsaufbau".

Daher bleibt für mich die Frage, warum man sich eine eigene CMTS "gönnen" sollte ... zum Lernen und zum eigenen Erkenntnisgewinn bräuchte es die aus meiner Sicht halt nicht und "nur so zum Spaß" ist es dann doch noch etwas anderes, als zum gezielten Entwickeln irgendeiner - wie auch immer gearteten - Lösung ... denn daß der Weg beim Klonen naürlich nicht von der gewünschten CM-MAC über das Zertifikat zur Provisionierung führt (da braucht man dann eben die "Schlüsselgewalt"), sondern man eher zum (woher auch immer stammenden) Zertifikat (wobei das Entscheidende ja weiterhin auch der Zugriff auf den privaten Key ist, der mit dem Zertifikat nur beglaubigt wird) die CM-MAC für die Kommunikation passend setzen will (gerade dann, wenn man nur "vermutet", daß die irgendwo im Environment steht), springt ja ins Auge.

Ich bin bei solchen Ideen halt auch immer etwas skeptisch, weil die Kenntnis des privaten CM-Schlüssels natürlich gleichzeitig eine Voraussetzung für das Abfangen/Belauschen von Traffic ist ... so etwas wie PFS gibt es beim Key-Exchange zwischen CM und CMTS nicht (jedenfalls nicht bis 3.0, wenn ich mich richtig erinnere - bevor ich mich festlege, würde ich aber noch mal in die SEC-Spec. schauen, da müßte BPI+ beschrieben sein) und damit braucht man zum Entschlüsseln der Kommunikation zwischen CMTS und CM nur den privaten Key des CM und natürlich den komplett abgelauschten Schlüsselaustausch, weil der "Authorization Key" von der CMTS zum CM mit dem Public-Key des CM verschlüsselt wird.

An solchen Aktionen (dem "Abfangen" von Traffic außerhalb des Provider-Netzes, was bei "lawful interception" jenseits der CMTS sicherlich wieder deutlich einfacher wäre) sind sicherlich auch verschiedene Gruppen interessiert ... da könnte ich mir dann die eigene CMTS für einen PoC auch wieder vorstellen.

 

[Flole]

Ein kleines Update von dem aktuellen Fortschritt:

Die Zertifikate und Private Keys sind da wo sie hingehören, glaub ich zumindest. Meine CMTS meldet aber einen Fehler in der Cert Chain und ein Mitschnitt direkt auf der CMTS hat gezeigt das da tatsächlich noch irgendwie das AVM Root Cert seinen weg reingefunden hat. Ich hab auch schon eine Vermutung wo das herkommen könnte, aber ich denke das Peter recht hat und sowas im Idealfall sehr schlecht dokumentiert wird wie das ganze genau abläuft um zu verhindern das es eben an einer öffentlichen CMTS eingesetzt wird. Ich denke mal das ich an dieser Stelle ohne Zugriff aufs CMTS gescheitert wäre, denn die FritzBox sagt nichts darüber was hier schief läuft, erst die CMTS hat es etwas erläutert und Licht ins dunkle hat der Mitschnitt über die CMTS gebracht, wo die DOCSIS MGMT Frames sichtbar werden.

EDIT: Die FritzBox überschreibt bei jedem Start im Prinzip bedingungslos die Zertifikate mit denen aus dem Urlader

 

[Flole]

Sooo, das ganze war erfolgreich. Es ist also durchaus möglich die MAC einer FritzBox Cable zu ändern und die zu nutzen, vorausgesetzt man hat ein Zertifikat dem die CMTS vertraut.

Und bevor jemand fragt: Ja, dadurch ist es auch möglich old/old Boxen wiederzubeleben.

Proof of concept abgeschlossen.

 

[PeterPawn]

Die FritzBox überschreibt bei jedem Start im Prinzip bedingungslos die Zertifikate mit denen aus dem Urlader

Das kann sie - logischerweise - nur dann, wenn da überhaupt eines liegt (steht so aber auch schon im "großen" 6490-Thread). Gerade das ist ja bei den "old/old"-Boxen nicht der Fall.

EDIT: Wobei das mit dem Überschreiben bei jedem Start auch nicht so 100% stimmt ... denn das erfolgt nur dann, wenn das "cmp"-Kommando in "/bin/docsiscertdefaults" (das Skript hatte ich oben schon mal "angesprochen") feststellt, daß es sich beim "zur Verwendung verlinkten" Zertifikat nicht um das aus dem Urlader handelt.

Da man dieses Skript naturgemäß auch modifizieren kann (wie jede andere Datei in der Firmware), spielt dieser Umstand für die Frage, ob und wie man die MAC-Adresse ändern kann, praktisch auch keine Rolle bzw. wäre als Feststellung auf "mit originaler Firmware" zu beschränken (wenn es schon um einen PoC gehen soll, muß man ja auch die Rahmenbedingungen passend abstecken).

Falls jemand sich die Kommunikation zwischen CTMS und CM vom Ranging bis zur Provisionierung mal ansehen will und er nicht ebenfalls 1200 EUR + Zoll ausgeben möchte: Die AVM-Firmware speichert diese Phase der Kommunikation beim Booten auf dem ARM-Core in der Datei "/var/tmp/docsis_boot_mng.pcap".

An diese Datei kommt man auch "regulär", wenn man sich die DOCSIS-Diagnosedaten in der Support-Seite ausgeben läßt (aus dem Kopf: das ist dann eine ZIP-Datei, die u.a. auch diese pcap-Datei enthält). Dieser Punkt taucht dort aber u.U. nur dann auf, wenn es sich um eine "private" oder eine "Beta/Labor"-Version handelt - weiß ich nicht mehr aus dem Kopf, kann man sich aber in den Quellen der Support-Seite problemlos ansehen.

Allerdings habe ich nach 06.8x nicht mehr nachgesehen, ob beim "Umzug" des gesamten GUI auf den ATOM-Core auch das Auslesen dieser Datei bzw. der ganzen Support-Daten angepaßt wurde. Vermutlich müssen die über den "glue code" erst auf den ATOM-Core kopiert werden, weil sie natürlich im Betrieb auf dem CM (und damit auf dem ARM-Core) anfallen.

Das ist auch alles noch Wissen, was man problemlos durch das Zerlegen und die Analyse einer "normalen" Firmware erwerben kann (ohne weitere Investitionen in irgendeine Hardware außer einer eigenen Box) - es ist weder "geheim", noch irgendwie gefährlich. Ganz im Gegenteil ... der grundlegende Ablauf ist sogar in den (frei zugänglichen) DOCSIS-Spezifikationen beschrieben (die kriegt man u.a. hier "von der Quelle": https://apps.cablelabs.com/specification/?query=&category=DOCSIS&subcat=DOCSIS%203.0&doctype=&content=false&archives=false) und die konkrete Umsetzung durch Intel (und in Teilen eben durch AVM, wobei der überwiegende Teil schon noch Intel-Code ist und daher in allen Puma6-Geräten - auch von anderen Herstellern - ähnlich läuft, wie man beim Vergleich der AVM-Firmware mit anderen Modellen von anderen Herstellern - z.B. dem Hitron CVE-30360 - auch leicht feststellen kann) kann man sich auch in der Firmware problemlos ansehen, soweit sie aus Shell-Skripten besteht.

 

[Freesurf]

Hallo,
Es passt zwar nicht ganz zum Thema, aber scheint schon sehr nah dran zu sein.
Ich habe zwei 6490 hier, die eine hat old/old, läuft ansonsten tadellos. Die andere hat new/new, startet aber nach 3-4 Minuten immer wieder neu und kommt dann nicht mehr richtig hoch. Ich vermute hier einen Hardwaredefekt.
Nun stelle ich mir die Frage, ob es nicht möglich ist, CM und certs der „defekten“ auf die old/old zu übertragen.

Falls jemand eine Idee hat, immer her damit.
Falls jemand eine Idee hat, was das Problem der Hardwaredefekten ist, auch da wäre ich aufgeschlossen.

 

[f666]

Du kannst im Bootloader der neuen Box mit "retr CONFIG" den Bereich mit den Zertifikaten auslesen. Diese "Datei" besteht aus mehreren Bereichen, einer dieser ist gzip komprimiert (Header 0x1f 0x8b) und enthält die Zertifikate. Muss manuell auseinandergepfriemelt werden.
Alternativ installierst du dir eine Firmware mit Shellzugang und kopierst die Zertifikate manuell von der ständig neustartenden Box runter.

Auf der alten Box musst du dann die neuen Zertifikate an der entsprechenden Stelle ablegen und die MAC Adresse im Bootloader auf die der spendenden Box ändern.

Geht also. Ich schreibe nicht mehr, weil ich die Details nicht aus der Erinnerung wiedergeben kann und selbst (erneut) nachvollziehen müsste.

 

[vaxinf]

Ich brauche doch noch mehr Tipps, wie man an die Config-Daten kommt.

Über das adam2-Interface ging bei mir nur das Auslesen von den env-Daten.

Ein "quote RETR config" bzw. "quote RETR CONFIG" scheiterte.

Danke im Voraus
Eberhard

 

[PeterPawn]

nur das Auslesen von den env-Daten.

Im Gegensatz zu GETENV und SETENV brauchen die "Pseudodateien" (dazu gehören "env", "count" und eben auch "config") eine Dateiübertragung im FTP - und die wird in einem FTP-Client (der passive Transfers beherrschen muß) immer noch per "get" angestoßen (zumindest in den meisten). Geht es gar nicht um einen FTP-Client, braucht's auch kein "quote" vor dem Kommando - irgendwas paßt hier nicht zusammen.

 

[f666]

Als Vorlage, welche ich auf die Schnelle gefunden habe, kann Punkt 7 in diesem Beitrag dienen:
https://www.ip-phone-forum.de/threads/fritz-box-6490-cable-branding-entfernen.296797/

Der FTP Dialog enthält auch völlig überflüssige Befehle, aber die machen nichts kaputt.
Die wesentliche Zeile ist "get env". Dieser Befehl startet einen Abruf der Datei namens "env". Analog willst du die Datei "CONFIG".

 

[vaxinf]

Nach den Hinweisen habe ich die "Lösung". Problem war, dass config "CONFIG" geschrieben werden muss!

1. FB im adam2-Modus anhalten.

2. Dann in der Eingabeaufforderung:

Mit ncftpget env holen:

ncftpget -t 5 -o doNotGetStartCWD=1 -W "quote MEDIA SDRAM" -u adam2 -p adam2 -C 192.168.178.1 env c:\users\a\env.txt

Mit ncftpget count holen:

ncftpget -t 5 -o doNotGetStartCWD=1 -W "quote MEDIA SDRAM" -u adam2 -p adam2 -C 192.168.178.1 count c:\users\a\count.txt

Und nun kommt's:

Mit ncftpget CONFIG holen:

ncftpget -t 5 -o doNotGetStartCWD=1 -W "quote MEDIA SDRAM" -u adam2 -p adam2 -C 192.168.178.1 "CONFIG" c:\users\a\config.gz

c:\users\a\config.gz: 58368 bytes (Frage: stimmt die Größe???)

Das nächste Problem config.gz ist binär, lässt sich aber nicht mit 7zip öffnen.
Ich versuche nun per HEX-Editor den Teil zu extrahieren, den f666 in #11 genannt hat...

 

[prisrak1]

wenn da es nur einer so was wie "MAC Canger" einbauen könnte, wie bei "Nethunter". Es läuft ja fast auf jedem Handy und Linuxsystemen. Ist nur eine Frage der Umsetzung. Wenn ein eigenes Gerät defekt ist, warum könnte man nich ein Anderes mit den selben Daten an seiner Stelle betreiben dürfen. Aus meiner Sicht währe es gerade richtig.

 

[PeterPawn]

@f666 hatte ja (richtigerweise) auch nicht geschrieben, daß es sich um eine gzip-komprimierte DATEI handelt. Das ist der Dump eines Bereichs, in dem auch zlib-komprimierte Daten enthalten sind. Der Aufbau des Bereichs ist in den Kernel-Quellen "nachzulesen", wenn daraus die verschiedenen "Datenquellen" unterhalb von "/proc/sys/urlader" erstellt werden bzw. wenn diese ausgelesen werden (ein Teil des Codes kommt dann erst zum Einsatz).

 

[vaxinf]

Hier ein sceenshot des gunzip-baren (schönes Wort!) Teile der CONFIG-Datei.

Ich weiss nicht, ob jetzt nochmal den HEX-Editor benutzen muss oder anders vorgehen muss?

 

[f666]

Du musst nach dem Header (siehe Beitrag oben) suchen und alles davor löschen (also die verbleibende Datei muss direkt mit dem Header beginnen). Dann kannst du das entpacken.

 

[vaxinf]

Genau das habe ich gemacht!
Die 1F 8B kommen in der CONFIG-Datei einmal vor. 4 Bytes merkwürdigerweise noch davor.
Wenn ich dann ab 1F 8B den Inhalt in eine neue Datei namens 1.dat.gz abspeichere und dekomprimiere, dann kommt die Datei heraus, deren hexdump in #18 ich gepostet habe.
Die FB hat 7.02 drauf, vielleicht spielt das eine Rolle. Es wäre super, wenn jemand mein Ergebnis mit einer FB6490 mit 7.02 nachvollziehen könnte, um zu sehen, wo ich etwas falsch mache, oder ob sich etwas geändert hat bei der Firmwareversion.

Hier ist zum Vergleich der Screenshot der CONFIG-Datei, wo 1F 8B zu finden ist.



//edit by stoney: Bild geschrumpft