FritzBox 6490 MAC Ändern - Ich will es wirklich!

[Flole]

Dies ist doch ein public key, oder?

Ein Zertifikat ist mehr als nur ein Public Key.

 

[sb0373]

@Flole, danke für Deinen Input. Leider kann ich ihn nicht so ganz interpretieren.
Ein Zertifikat besteht aus einem Schlüsselpaar (private und public).

Nach meinem aktuellen Verständnis:
- cm_key_prv.bin = Private Key
- cm_cert.cer = Public Key (sehe ich jetzt bestätigt durch Deinen Post).

Mein weiteres Verständnis:
- CER Dateien beinhalten immer nur den Public key.
- base64 cm_cert.cer lässt optisch nur einen Schlussel vermuten.

Erfolgreich verifizieren konnte ich die CER Dateil allerdings leider nicht. Daher würde ich mich über Hinweise zum Anzeigen des Inhalts freuen.

 

[Flole]

Ein Zertifikat besteht aus einem Schlüsselpaar (private und public).

Nein tut es nicht.

- cm_cert.cer = Public Key (sehe ich jetzt bestätigt durch Deinen Post).

Solltest du nicht, denn ich habe geschrieben das ein Zertifikat mehr als ein Public Key ist. Wenn der Dateiname also den Inhalt beschreibt (cert = Zertifikat) dann ist es eben kein Public Key sondern ein Zertifikat.

base64 cm_cert.cer lässt optisch nur einen Schlussel vermuten.

So ziemlich alles was relativ kurz ist könnte in base64 kodiert optisch ein Schlüssel sein.

- CER Dateien beinhalten immer nur den Public key.

Nein, sie beinhalten üblicherweise ein Zertifikat und nicht nur den Public key.

Mach dich am besten mal damit vertraut wie Zertifikate funktionieren bzw. was sie von reinen öffentlichen Schlüsseln abgrenzt bzw. was sie zwangsläufig noch enthalten müssen. Da gibt es so viel Literatur zu dem Thema.

 

[sb0373]

Danke, ich glaube die Online Literatur ist etwas zu vielfältig und verwirrend. Werde nochmal ein paar Schritte zurück gehen.

Im Moment bin ich wieder an der Stelle:

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

Bin ich hier auf dem falschen Weg oder sollte ich davon ausgehen, dass meine Datei korrupt ist (was ich ja unter Anderem verifizieren wollte)?

 

[sb0373]

ok, ich kann bestätigen, dass ich das Zertifikat mit openssl asn1parse -in cm_cert.cer --inform DER von einer 6590 erfolgreich lesen kann. Also scheint es aus meiner 6490 anders oder korrupt zu sein. Interessanter Weise ist die Länge und Terminierung (mit ==) bei Beiden Versionen identisch.

 

[PeterPawn]

Interessanter Weise ist die Länge und Terminierung (mit ==) bei Beiden Versionen identisch.

Dann solltest Du vielleicht auch gleich noch mal nachlesen, wie Base64-Kodierung "fehlende Bits" am Ende behandelt ... dabei werden ja 24 Bit Binärdaten in 32 Bit Text kodiert und wenn am Ende nur noch 8 oder 16 Bit übrig sind (also 1 oder 2 Byte, weil die gesamte Datenlänge kein Vielfaches von 3 ist -> 24 Bit = 3 Byte), müssen solche "Füllbytes" ja irgendwie von "richtigen Daten" unterschieden werden. Bei einem Byte "Rest" ergibt das ja trotzdem in jedem Falle 2 Text-Zeichen (das erste mit den ersten 6 Bit, das zweite mit den restlichen 2 Bit) und da werden dann eben noch zwei Gleichheitszeichen angehangen, damit die Textlänge wieder ein Vielfaches von 4 ist. Läßt sich die originale Länge als 3x + 2 ausdrücken (mit x ∈ ℕ), ergeben die letzten beiden Byte dann drei Zeichen Text und es wird nur noch ein Gleichheitszeichen gebraucht zum Auffüllen auf Vielfache von 4.

 

[sjnldymbhgk789]

Hmm, ich habe das hier versucht, erhalte aber bei "ftp: get CONFIG" ein "551 unknown media type". Übertragung auf binary stellen hatte nichts geändert. Wie kommt man hier weiter?

 

[NDiIPP]

Das hatten wir doch erst kürzlich…
https://www.ip-phone-forum.de/threads/f-b-6591-bootloop.318729/post-2551631
https://www.ip-phone-forum.de/threads/6490-ohne-ansprechbaren-bootloader.303402/post-2381472

 

[sjnldymbhgk789]

Verstehe ich nicht was dieser Zeig bedeuten soll...

Eva tools gibt mir eine leere Datei mit GetEnvironmentFile aus, und mit GetEnvironmentValue ein Fehler, weil CONFIG kein Wert ist.
Manuell mit ftp erhalte ich wohl auch die Ursache: Fehler 551.

 

[PeterPawn]

Eva tools

Und dabei wurde gar nichts weiter ausgegeben? Komisch ... DAS ist normalerweise das Minimum, was bei mir bisher (na ja, fast) immer funktionierte. Ich mußte dafür nur die passenden Optionen beim Aufruf angeben - wie diese aussehen, habe ich (a) beschrieben (https://www.ip-phone-forum.de/threa...n-aus-yourfritz-eva_tools.298591/post-2264928) und wird (b) auch in der PowerShell angezeigt, wenn man dort, wo diese Optionen beim Aufruf zu platzieren sind, einfach mal die TAB-Taste drückt (das nennt sich dann "tab completion").

mit GetEnvironmentValue ein Fehler

Wo steht denn, daß man so etwas machen könnte oder gar sollte?

Manuell(???) [...] die Ursache: Fehler 551

Ambitioniert ... aber dann fehlt ja offenbar noch die Analyse der dazugehörigen Fehlermeldung durch Dich, oder? Was KÖNNTE diese Nachricht denn bedeuten, wenn man sie einfach mal - sogar wortwörtlich - übersetzt? Was unterscheidet sich denn bei Deinem Vorgehen im FTP-Dialog von anderen Beispielen, die man hier auch findet (oder zumindest finden kann)?

---

Ich bin halt immer wieder verblüfft, wie man auf die Idee kommt, wenn man das "von Hand" machen würde, anstelle die Skript-Dateien zu benutzen, würde das irgendwie besser werden. Warum sollte(n) denn dabei der bzw. die - vermutlich systematische(n) - Fehler, die man zuvor bei der Verwendung der Skript-Dateien gemacht hat, plötzlich verschwunden sein? Woher weiß man denn - solange man sich die Fehlermeldungen nicht ausgeben läßt oder die nicht richtig ansieht - überhaupt, welches Problem da aufgetreten ist?

Wenn ich raten soll (und ohne Protokoll bleibt mir ja gar nichts anderes übrig), wurde hier wieder einer der üblichen Fehler gemacht (oder auch gleich mehrere) ... das geht los beim falschen Speichern des Skript-Codes (der dann gar kein PS-Code ist) und endet beim fehlenden "Unblock" für die Datei, die ja beim Speichern spezielle Attribute erhält um zu markieren, daß sie aus dem Netz geladen wurde und erst nach einer "Spezialbehandlung" ausgeführt werden darf.

Generell ist das alles ausreichend "dokumentiert" (und nicht nur bei mir, sondern auch hier: https://www.yourfritz.de/desc-docsis - und der Umgang mit EVA ist auch bei den Puma7-Boxen kein anderer, nur die Partitionen beim Schreiben sind andere) und ich würde einfach mal die Vermutung äußern, daß eine VORHERIGE Lektüre tatsächlich nicht schaden würde - unabhängig davon, was man am Ende als Werkzeug benutzen sollte für den Zugriff auf EVA.

Und genau das wollte @NDiIPP hier wohl sagen ... was ich übrigens genauso sehe. So langsam geht mir das ständige Wiederholen von bereits gegebenen Antworten jedenfalls mächtig auf den Zeiger, vor allem dann, wenn die Leute die simpelsten "Weisheiten", hinsichtlich sinnvollen Verhaltens in Boards wie diesem, nicht berücksichtigen: https://tty1.net/smart-questions_de.html

Das MUSSTE ich einfach mal wieder loswerden - ansonsten bin ich hier raus.

 

[sjnldymbhgk789]

Und dabei wurde gar nichts weiter ausgegeben? Komisch ... DAS ist normalerweise das Minimum, was bei mir bisher (na ja, fast) immer funktionierte.

Leere Datei (ich habe ">" benutzt) heißt keine Ausgabe, oder?

Wo steht denn, daß man so etwas machen könnte oder gar sollte?

Es ist naheliegend "eva" oder "count" durch "config" zu ersetzen.

fehlt ja offenbar noch die Analyse der dazugehörigen Fehlermeldung

Deutet wohl auf einen MIME-Type Fehler hin?
Jedenfalls gibt's hier nix zu 551 in der Suche weil zu kurz oder zu oft und sonst findet man bei ftp zu 551 nichts Richtung Dateityp sondern mehr der Art falsche/zu häufige Anfrage.
Deswegen.. wie kommt man hier weiter?

wie man auf die Idee kommt, wenn man das "von Hand" machen würde

Wieso sollte man das nicht, zumal das an jeder Ecke per Hand gemacht wird, auch bei Anleitungen zu bspw. ffritz.

ohne Protokoll bleibt mir ja gar nichts anderes übrig

Ich hab mich nur an die Wortkargheit und jeder-ist-Experte-hier gehalten, denn wie du sehen kannst, bin ich neu hier, und mache den Mimicry.

gar kein PS-Code ist

sh und bash kann ich noch von PS auseinanderhalten, aber gerade so.

daß eine VORHERIGE Lektüre

Ich habe schon Stunden mit der Thematik verbracht, aber es ist alles zerstreut und nicht chronologisch und sehr schwer einen konsistenten Zusammenhang herzustellen wenn man neu reinkommt.

"Weisheiten"

Hier ist eine: Konstruktiv war dein "Beitrag" nicht.

Zum nun konstruktiven Teil:
Die sh Version von get environment hat tatsächlich 256kB gelesen (wdh.: PS war 0kB).
Ich habe nun eine config.bin, in der ich nach der magischen Zahl gesucht und gefunden habe. Leider auch vom Typ 0x04, ergo keine Zertifikate in dem tar.
Dennoch scheinen die Zertifikate an anderer Stelle enthalten zu sein. denn ich sehe Dateinamen cm_cert_euro.cer, cm_key_prv_euro.bin, euro_mfg_cert.cer, euro_root_pub_key.bin.
Das sind dann wohl die gesuchten, neuartigen Zertifikate, ne?
Allerdings weiß ich hier nicht, wie ich Dateilänge auslesen kann usw.
Wie geht's hier weiter?