FritzBox 6490 MAC Ändern - Ich will es wirklich!

[f666]

Aus der Erinnerung weiß ich nicht mehr, was genau das Containerformat ist. Mach mal 'file 1.bin', eventuell spuckt das was brauchbares aus.

Die Datei scheint deinem Bildschrimfoto nach Klartext zu sein. Mit dem Hexeditor kannst du die dann natürlich auch weiter zerteilen, wenn du die Zertifikate findest. Einfach durchsehen, ob ein Anfang und ein Ende erkennbar ist.

PeterPawn hat oben auch geschrieben, dass in den Kernel Quellen (http://osp.avm.de/fritzbox/fritzbox-6490-cable/) das Format beschrieben ist.

 

[vaxinf]

Das gzipped-Teil war ein tar-file und enthält das directory DownstreamCal und UpstreamCal.
Ich denke nicht, dass dort noch die Zertifikate drin stecken.
============================
$ file 3.dat
3.dat: POSIX tar archive (GNU)

$ tar xvf 3.dat
DownstreamCal/
DownstreamCal/MxL267
UpstreamCal/
UpstreamCal/usNewFreqTableFile
UpstreamCal/usTablesFile
UpstreamCal/usParametersFile
===========================

Any ideas????

 

[PeterPawn]

Es gibt dort mehrere Tarballs, die mit "gzip" gepackt sind.

Am ehesten findet man das Gesuchte in den Quellen mit dem Stichwort "wlan_dect_config" - da wirft ein "grep" sowohl die Funktionen als auch die Strukturen in den Header-Files aus.

Mit der 07.0x hat sich das auch geändert bei den Auswertungen, vermutlich weil jetzt auch bei der 6490 ein ODT im Kernel "simuliert" wird, der bei der 6490 (zumindest bei den älteren Modellen) noch nicht aus dem Bootloader kommt.

Zusätzlich ist das ja alles (was da sonst noch líegt, jenseits der Zertifikate) von "/proc/sys/urlader/config" nach "/proc/avm/calib/" umgezogen ... AVM setzt vermutlich (ich habe es noch nicht sooo genau angesehen) hier auf das "Verstecken" der Zertifikate vor Programmen auf dem ATOM-Core - eine legitime und sinnvolle Hürde gegen Manipulationen an dieser Stelle vom ATOM-Core aus.

Wer noch ältere Quellen hat (bei AVM gibt's auch noch die der 06.61), kann auch dort nachsehen ... da ist das noch leichter zu überblicken (meine Ansicht), weil die 6590/6591 noch keine wirkliche Rolle spielten in den Quellen und (iirc) noch ohne ODT gearbeitet wurde beim Initialisieren der internen Strukturen.

 

[Freesurf]

Ich bin leider noch nicht dazu gekommen mich weiter mit der Box zu beschäftigen. Die Frage, die ich mir stelle, ist allerdings, wie bekommt man denn die Zertifikate am Ende wieder auf die Box? Und wenn es sich um einen dump des Filesystems handelt, wäre ein Mount des gesamten Dumps unter Linux ggf. möglich?

 

[f666]

Man könnte z.B. ein Firmwareimage mit ergänzten Initskripten erzeugen, welche dann beim Booten die neuen Zertifikate an die Stelle kopieren, wo die Intel/AVM Software sie erwarten.

 

[vaxinf]

Ich hänge immer noch am Problem beim Entpacken der CONFIG-datei. Es befindet sich bei mir nur ein tar.gz-Datei in der Datei und keine weiteren entpackbaren files.

Deshalb nochmals die Bitte um die Information, wie groß in Bytes die CONFIG-datei regulär ist, wenn das Zertifikat sich darin befindet!!!!

Danke

 

[PeterPawn]

Deshalb nochmals die Bitte um die Information, wie groß in Bytes die CONFIG-datei regulär ist, wenn das Zertifikat sich darin befindet!!!!

Die Anzahl der Ausrufungszeichen wird auch nichts daran ändern, daß die Größe des CONFIG-Bereichs fix ist - schließlich ist das ein reservierter Datenbereich innerhalb der Bootloader-Partition und den Bootloader selbst interessieren nur wenige Teile aus diesem Bereich ... folglich interpretiert der den Inhalt beim Ausgeben vermutlich gar nicht, sondern schreibt ihn "blind".

Wenn da (bei Dir) keine weitere gzip-Datei enthalten ist (vor der Signatur 0x1f8b steht dann die Länge (16 Bit, bei mir 0x849) und davor noch die Version (0x02) und der Typ (0x03 für Zertifikate) des Eintrags:

 70 #define PUMA_MAX_CONFIG_ENTRIES  8
 71
 72 enum wlan_dect_type {
 73     WLAN,
 74     DECT,
 75     WLAN2,
 76     ZERTIFIKATE,
 77     DOCSIS,
 78     MAX_TYPE
 79 };
 80
 81 #define PUMA_MAX_CONFIG_ENTRIES 8
 82
 83 struct __attribute__ ((packed)) wlan_dect_config {
 84     unsigned char           Version;        /*--- z.Z. 1 ---*/
 85     enum  wlan_dect_type    Type :8;        /*--- 0 - WLAN; 1 - DECT ---*/
 86     unsigned short          Len;            /*--- 384 - WLAN, 128 - DECT ---*/
 87 };

), dann gibt es wohl den betreffenden Eintrag nicht in dieser Box - ergo wohl auch keine Zertifikate im Bootloader.

Normalerweise sähe das jedenfalls so aus:

vidar:~/FritzBox/FB6490_Pentest/savesystem/XXXX $ dd if=config.bin bs=1 skip=$(( 0x404 )) count=$(( 0x849 )) | tar tvz
2121+0 records in
2121+0 records out
2121 bytes (2.1 kB, 2.1 KiB) copied, 0.00571801 s, 371 kB/s
-rw-rw-r-- 0/0             634 2016-05-30 xx:xx cm_key_prv.bin
-rw-rw-r-- 0/0             775 2016-05-30 xx:xx cm_cert.cer
-rw-r----- 0/0            1013 2016-05-30 xx:xx mfg_cert.cer
-rw-r----- 0/0             294 2016-05-30 xx:xx mfg_key_pub.bin
vidar:~/FritzBox/FB6490_Pentest/savesystem/XXXX $

- wie man sehen kann, steht hier die Datei ziemlich am Beginn des betreffenden Bereichs (davor stehen die Daten aus dem/für das Environment).

 

[f666]

Wenn die Dateien nicht im Bootloader liegen, scheint es sich um eine Box zu handeln, welche damals über c4 neue Zertifikate bekommen hat.
In diesem Fall baust du dir eine Firmware mit Shell Zugang (z.B. Freetz, gibt aber auch schlankere Möglichkeiten) und kopierst die Zertifikate in den verbleibenden Minuten, bis die Box einen Neustart hinlegt, z.B. auf einen USB-Stick.

 

[vaxinf]

Danke für f666 und PeterPawn für die Hinweise.

Ich habe bei meiner zweiten FB6490 die CONFIG-Datei ausgelesen und fand tatsächlich darin die Zertifikate. Damit stimmt auch die Erklärung von f666, dass es sich um zwei verschiedene Typen handelt. Eine mit Zertifikat im bootloader und eine ohne.

Wäre es sinnvoll, die Zertifikate der FB6490 ohne Bootloader-Zertifikat auszulesen und dann in das Bootloader-FS dieser Box einzubauen?

 

[f666]

Bist du dir sicher, dass die Zertifikate aus dem Bootloader old/old sind? Ich hatte die Erwartungshaltung, dass bei Boxen mit diesem Produktionsdatum die Zertifikate alle new/new sind.
Ich halte es für prinzipiell möglich, durch Bastelei an den Initskripten einer FritzBox die Zertifikate einer anderen unterzuschieben. Speziell die Transplantation von new/new einer defekten auf eine laufende old/old macht absolut Sinn. Habe es selbst aber noch nicht gemacht.

 

[fesc]

Die Zertifikatdatein sollten final im NVRAM unter /nvram/1/security (ARM) liegen.

# ls -l /nvram/1/security/
lrwxrwxrwx 1 root root 38 Sep 5 2016 cm_cert.cer -> /nvram/1/security/download/cm_cert.cer
lrwxrwxrwx 1 root root 41 Sep 5 2016 cm_key_prv.bin -> /nvram/1/security/download/cm_key_prv.bin
drwxr-xr-x 2 root root 0 Sep 5 2016 download
lrwxrwxrwx 1 root root 39 Sep 5 2016 mfg_cert.cer -> /nvram/1/security/download/mfg_cert.cer
lrwxrwxrwx 1 root root 42 Sep 5 2016 mfg_key_pub.bin -> /nvram/1/security/download/mfg_key_pub.bin
lrwxrwxrwx 1 root root 42 Jan 1 1970 root_pub_key.bin -> /etc/docsis/security/euro_root_pub_key.bin

"old/old" ist gleichbedeutend mit "download pfad existiert nicht", d.h. es gibt keine Zertifikate im Urlader, und es wurde auch noch nie ein online-Update derselben gemacht. D.h. wenn du sie so anlegst hast du eine "new/new" box und sie werden auch nicht mehr ueberschrieben.

 

[vaxinf]

Ich habe jetzt zwei FB6490 gefreetzt, um an die Zertifikate zu kommen.

Ich finde aber kein /nvram-Verzeichnis in der hochgefahrenen FB.

Was mache ich falsch?

 

[f666]

Der Shellzugang mit Freetz ist auf dem X86 Kern. Das /nvram Verzeichnis wird auf dem ARM Kern eingebunden. Mit dem Befehl rpc kannst du Befehle auf dem anderen Kern ausführen. Beispiele:

rpc ls -la /nvram
rpc cat /nvram/1/security/download/cm_key_prv.bin > /tmp/cm_key_prv.bin

 

[vaxinf]

Hat geklappt.

Eine Merkwürdigkeit: cm_cert.cer ist ausgestellt am 23.07.2015, support-Daten meint, dass das Zertifikat "new" sei.

Mir kommt das Datum verdächtig vor, weil erst Anfang 2015 der Zertifikattausch begann.

 

[fesc]

Die supportdatei zeigt nur an ob das Zertifikat aus dem download Verzeichnis kommt. Das ist dann "new", egal was drin steht.

Edit: In https://www.ip-phone-forum.de/threa...e-firmware-update.286994/page-33#post-2180353 hatte ich mal die daten des alten und neuen gepostet, passt also.

 

[vaxinf]

Um nun ein gültiges Zertifikat von einer FB auf die andere zu schaufeln, muss man also "nur" das /nvram verändern (nv steht wohl für non-volatile, oder?) und die MAC-Adresse der alten FB per SETENV eintragen.

Ich habe aber bisher nichts gefunden, ob und wie das Verändern von nvram geht.

 

[fesc]

/nvram auf dem ARM ist ein flash filesystem auf einem EPROM, also Daten einfach reinkopieren und sie sind persistent.
Einloggen auf dem arm kannst Du dich mit "armconsole". Das rpc Kommando geht dann in die andere Richtung (arm->atom).

Etwa so (aus dem kopf, bitte kein copy/paste)

armconsole
mkdir -p /nvram/1/security/download
rpc cat /tmp/cm_key_prv.bin > /nvram/1/security/download/cm_key_prv.bin
...
cd /nvram/1/security
ln -s download/* .

Mit der Aenderung der MAC adresse sollte es dann passen.

Edit: Die alten vorher sichern und aus /nvram/1/security loeschen!

 

[sb0373]

Hallo zusammen.

Ich möchte wie hier beschrieben die MAC zwischen zwei 6490 transferieren (defekt zu alt). So wie ich es verstanden habe, habe ich die relevanten Zertifikate schon:

-rw-rw-r--. 1 root root 775 30. Mai 2016 cm_cert.cer
-rw-rw-r--. 1 root root 636 30. Mai 2016 cm_key_prv.bin
-rw-rw-r--. 1 root root 58364 30. Apr 07:58 config.bin

Wie kann ich die beiden Zertifikate lesen/verifizieren? Meine Versuche ergeben immer nur Strukturinterpretationsfehler. Nach meiinem Verständnis aus den ersten Posts hier sind es DER kodierte RSA Zertifikate.

base64 <filename> zeigt optisch ein OK aussehendes Zertifikat ohne ---begin/----end--- Zeilen.

Sowas in der Art hab ich in verschiedenen Versionen probiert:
openssl rsa -in cm_key_prv.pem -text -pubin -noout -inform DER

Ist dies der richtige Weg?

 

[PeterPawn]

Theoretisch schon - nur warum sollte man beim Lesen eines privaten Schlüssels die Option -pubin angeben?

 

[sb0373]

Danke! der cm_key_prv.bin hat ohne -pubin funktioniert. Allerdings bekomme ich den cm_cert.cer noch nicht hin:

Dies ist doch ein public key, oder? Hat diese Datei ein anderes Format als die cm_key_prv.bin

$ openssl rsa -in cm_cert.cer -text -inform DER
unable to load Private Key
140693347403584:error:0D06C0C3:asn1 encoding routines:asn1_d2i_ex_primitive:type not primitive:crypto/asn1/tasn_dec.c:749:
140693347403584:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:615:
140693347403584:error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:crypto/asn1/tasn_dec.c:1149:
140693347403584:error:0D06C03A:asn1 encoding routines:asn1_d2i_ex_primitive:nested asn1 error:crypto/asn1/tasn_dec.c:713:
140693347403584:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:646:Field=version, Type=RSAPrivateKey
140693347403584:error:04093004:rsa routines:old_rsa_priv_decode:RSA lib:crypto/rsa/rsa_ameth.c:133:
140693347403584:error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:crypto/asn1/tasn_dec.c:1149:
140693347403584:error:0D06C03A:asn1 encoding routines:asn1_d2i_ex_primitive:nested asn1 error:crypto/asn1/tasn_dec.c:713:
140693347403584:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:646:Field=version, Type=PKCS8_PRIV_KEY_INFO

$ openssl rsa -in cm_cert.cer -text -inform DER -pubin
unable to load Public Key
140129873237824:error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:crypto/asn1/tasn_dec.c:1149:
140129873237824:error:0D06C03A:asn1 encoding routines:asn1_d2i_ex_primitive:nested asn1 error:crypto/asn1/tasn_dec.c:713:
140129873237824:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:646:Field=algorithm, Type=X509_ALGOR
140129873237824:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:646:Field=algor, Type=X509_PUBKEY

$ openssl x509 -inform der -in cm_cert.cer
unable to load certificate
139907069007680:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:crypto/asn1/asn1_lib.c:101:
139907069007680:error:0D068066:asn1 encoding routines:asn1_check_tlen:bad object header:crypto/asn1/tasn_dec.c:1137:
139907069007680:error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:309:Type=X509_NAME_ENTRY
139907069007680:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:615:
139907069007680:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:615:
139907069007680:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:646:Field=issuer, Type=X509_CINF
139907069007680:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:646:Field=cert_info, Type=X509

Sieht so aus als fehlt mir noch ein ganzes Stückchen Wissen an Zertifikaten...