Ich wollte mich zwar verabschieden, aber sei's drum - das ist dann doch wieder zu komisch, als daß ich mir die Nachfrage verkneifen könnte.
Was mich hier viel mehr interessieren würde, ist die Feststellung:
babboy schrieb:
eine Retail fritzbox mit 6.50 läuft nicht bei unitymedia
Das wäre (soweit ich alles verfolgt habe) die erste Retail-Box, die mit einer 06.50 ausgeliefert wurde und dann würde das darauf hindeuten, daß UM eine (minimale) FRITZ!OS-Version beachtet (das eCM läuft ja offenbar, nur der eRouter nicht).
Die brennendere Frage wäre hier ansonsten, wie man eine 06.50 in eine Retail-Box bekommen hat, wenn die vielleicht doch mit 06.60 ausgeliefert wurde. Ein Downgrade per CVC-Update vom Provider sollte da ja nicht erfolgt sein ... bliebe noch das manuelle Update mit einem abgefangenen CVC-File.
Das ist per se auch nichts anderes als ein AVM-Image in etwas anderer Verpackung (die ist in der
SECv3-Spezifikation im Anhang III beschrieben).
Ansehen kann man sich das schon mal ganz nett mit "openssl":
Code:
# openssl asn1parse -in 6490.en-de-es-it-fr-pl.141.06.50.120308002013.cvc -inform der -i
0:d=0 hl=4 l=1463 cons: SEQUENCE
4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData
15:d=1 hl=4 l=1448 cons: cont [ 0 ]
19:d=2 hl=4 l=1444 cons: SEQUENCE
23:d=3 hl=2 l= 1 prim: INTEGER :01
26:d=3 hl=2 l= 11 cons: SET
28:d=4 hl=2 l= 9 cons: SEQUENCE
30:d=5 hl=2 l= 5 prim: OBJECT :sha1
37:d=5 hl=2 l= 0 prim: NULL
39:d=3 hl=2 l= 11 cons: SEQUENCE
41:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data
52:d=3 hl=4 l= 885 cons: cont [ 0 ]
56:d=4 hl=4 l= 881 cons: SEQUENCE
60:d=5 hl=4 l= 601 cons: SEQUENCE
64:d=6 hl=2 l= 3 cons: cont [ 0 ]
66:d=7 hl=2 l= 1 prim: INTEGER :02
69:d=6 hl=2 l= 16 prim: INTEGER :1CE61BB1088646D33E9052DCB417DF1C
87:d=6 hl=2 l= 13 cons: SEQUENCE
89:d=7 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption
100:d=7 hl=2 l= 0 prim: NULL
102:d=6 hl=2 l= 111 cons: SEQUENCE
104:d=7 hl=2 l= 11 cons: SET
106:d=8 hl=2 l= 9 cons: SEQUENCE
108:d=9 hl=2 l= 3 prim: OBJECT :countryName
113:d=9 hl=2 l= 2 prim: PRINTABLESTRING :BE
117:d=7 hl=2 l= 31 cons: SET
119:d=8 hl=2 l= 29 cons: SEQUENCE
121:d=9 hl=2 l= 3 prim: OBJECT :organizationName
126:d=9 hl=2 l= 22 prim: PRINTABLESTRING :tComLabs - Euro-DOCSIS
150:d=7 hl=2 l= 21 cons: SET
152:d=8 hl=2 l= 19 cons: SEQUENCE
154:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName
159:d=9 hl=2 l= 12 prim: PRINTABLESTRING :Cable Modems
173:d=7 hl=2 l= 40 cons: SET
175:d=8 hl=2 l= 38 cons: SEQUENCE
177:d=9 hl=2 l= 3 prim: OBJECT :commonName
182:d=9 hl=2 l= 31 prim: PRINTABLESTRING :Euro-DOCSIS Cable Modem Root CA
215:d=6 hl=2 l= 30 cons: SEQUENCE
217:d=7 hl=2 l= 13 prim: UTCTIME :090723000000Z
232:d=7 hl=2 l= 13 prim: UTCTIME :190722235959Z
247:d=6 hl=2 l= 94 cons: SEQUENCE
249:d=7 hl=2 l= 11 cons: SET
251:d=8 hl=2 l= 9 cons: SEQUENCE
253:d=9 hl=2 l= 3 prim: OBJECT :countryName
258:d=9 hl=2 l= 2 prim: PRINTABLESTRING :DE
262:d=7 hl=2 l= 17 cons: SET
264:d=8 hl=2 l= 15 cons: SEQUENCE
266:d=9 hl=2 l= 3 prim: OBJECT :organizationName
271:d=9 hl=2 l= 8 prim: PRINTABLESTRING :AVM GmbH
281:d=7 hl=2 l= 20 cons: SET
283:d=8 hl=2 l= 18 cons: SEQUENCE
285:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName
290:d=9 hl=2 l= 11 prim: PRINTABLESTRING :Euro-DOCSIS
303:d=7 hl=2 l= 38 cons: SET
305:d=8 hl=2 l= 36 cons: SEQUENCE
307:d=9 hl=2 l= 3 prim: OBJECT :commonName
312:d=9 hl=2 l= 29 prim: PRINTABLESTRING :Code Verification Certificate
343:d=6 hl=4 l= 290 cons: SEQUENCE
347:d=7 hl=2 l= 13 cons: SEQUENCE
349:d=8 hl=2 l= 9 prim: OBJECT :rsaEncryption
360:d=8 hl=2 l= 0 prim: NULL
362:d=7 hl=4 l= 271 prim: BIT STRING
637:d=6 hl=2 l= 26 cons: cont [ 3 ]
639:d=7 hl=2 l= 24 cons: SEQUENCE
641:d=8 hl=2 l= 22 cons: SEQUENCE
643:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Extended Key Usage
648:d=9 hl=2 l= 1 prim: BOOLEAN :255
651:d=9 hl=2 l= 12 prim: OCTET STRING [HEX DUMP]:300A06082B06010505070303
665:d=5 hl=2 l= 13 cons: SEQUENCE
667:d=6 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption
678:d=6 hl=2 l= 0 prim: NULL
680:d=5 hl=4 l= 257 prim: BIT STRING
941:d=3 hl=4 l= 522 cons: SET
945:d=4 hl=4 l= 518 cons: SEQUENCE
949:d=5 hl=2 l= 1 prim: INTEGER :01
952:d=5 hl=3 l= 131 cons: SEQUENCE
955:d=6 hl=2 l= 111 cons: SEQUENCE
957:d=7 hl=2 l= 11 cons: SET
959:d=8 hl=2 l= 9 cons: SEQUENCE
961:d=9 hl=2 l= 3 prim: OBJECT :countryName
966:d=9 hl=2 l= 2 prim: PRINTABLESTRING :BE
970:d=7 hl=2 l= 31 cons: SET
972:d=8 hl=2 l= 29 cons: SEQUENCE
974:d=9 hl=2 l= 3 prim: OBJECT :organizationName
979:d=9 hl=2 l= 22 prim: PRINTABLESTRING :tComLabs - Euro-DOCSIS
1003:d=7 hl=2 l= 21 cons: SET
1005:d=8 hl=2 l= 19 cons: SEQUENCE
1007:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName
1012:d=9 hl=2 l= 12 prim: PRINTABLESTRING :Cable Modems
1026:d=7 hl=2 l= 40 cons: SET
1028:d=8 hl=2 l= 38 cons: SEQUENCE
1030:d=9 hl=2 l= 3 prim: OBJECT :commonName
1035:d=9 hl=2 l= 31 prim: PRINTABLESTRING :Euro-DOCSIS Cable Modem Root CA
1068:d=6 hl=2 l= 16 prim: INTEGER :1CE61BB1088646D33E9052DCB417DF1C
1086:d=5 hl=2 l= 9 cons: SEQUENCE
1088:d=6 hl=2 l= 5 prim: OBJECT :sha1
1095:d=6 hl=2 l= 0 prim: NULL
1097:d=5 hl=2 l= 93 cons: cont [ 0 ]
1099:d=6 hl=2 l= 24 cons: SEQUENCE
1101:d=7 hl=2 l= 9 prim: OBJECT :contentType
1112:d=7 hl=2 l= 11 cons: SET
1114:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data
1125:d=6 hl=2 l= 28 cons: SEQUENCE
1127:d=7 hl=2 l= 9 prim: OBJECT :signingTime
1138:d=7 hl=2 l= 15 cons: SET
1140:d=8 hl=2 l= 13 prim: UTCTIME :131203070000Z
1155:d=6 hl=2 l= 35 cons: SEQUENCE
1157:d=7 hl=2 l= 9 prim: OBJECT :messageDigest
1168:d=7 hl=2 l= 22 cons: SET
1170:d=8 hl=2 l= 20 prim: OCTET STRING [HEX DUMP]:9A1D680FC5DBD828B2557BEBD1217B276EC4A4D9
1192:d=5 hl=2 l= 13 cons: SEQUENCE
1194:d=6 hl=2 l= 9 prim: OBJECT :rsaEncryption
1205:d=6 hl=2 l= 0 prim: NULL
1207:d=5 hl=4 l= 256 prim: OCTET STRING [HEX DUMP]:7CB5887BC2C9F6FC3B4AEB90E4EEC40D0F22634388242CC2F83200BCB989E3E8B94CE8F43D35ED35F5C7B210D725E2B27F4A1D13D6EA446CF1703F2FC13F73D7D610BC3704A869D73CD2282FF8832409AD6744EDFAEC336B26B4A1EC926810998F62C398E54BC4B5781C88C3BB1EA9F7C42911D141FEE3F51B5B0416CF70BFF7DE762789E26800E6496B3EF71CDA89FFE4E9C876067EFEFB17BE5E7E4B5C7038613CDD7CB959BC1F2DF4ABAF2811321D9D6AB5B22C62347EF67094B804926F345A2C29A8FF38F3AA0F7B1A6B1CC5FF185E620B642338C21DAD4A96E97604FA992499E348106C50F6356847C887ABC09D04E3285A469019943966FA22E8E38792
1467:d=0 hl=2 l= 0 prim: UNIVERSALSTRING
1469:d=0 hl=2 l= 43 prim: EOC
Den Payload kann man entweder aus der BER-Struktur polken oder einfach nachsehen, wo der erste TAR-Header für "./var" beginnt und alles davor abschneiden (wenn man keine Signaturen prüfen will).
Da gibt es eine Diskrepanz im Offset zwischen der Anzeige der BER-Struktur oben (1469 + 43 = 1512 = 0x5E8) und dem tatsächlichen Offset des Tarballs in der CVC-Datei (0x5E0). Woher die jetzt kommt, wüßte ich auch gerne ... auf der anderen Seite muß ja nur der AVM-Code damit klarkommen und vielleicht habe auch ich die Spezifikation nur falsch verstanden, denn eigentlich übernimmt diesen Teil üblicherweise der Intel-Code in "sw_dl", von dem ich bisher immer dachte, daß AVM den nur etwas angepaßt hätte (in dem, was nach dem Download und der Prüfung passiert).
Es kann durchaus auch sein, daß der ASN.1-Parser von "openssl" an der Stelle nicht so richtig arbeitet, schon ein EOC-Marker (end of content) mit einer Länge von 43 Octets ist eigentlich kaum möglich (aber das ASN.1-Type-Octet am Offset 1469 ist wirklich "0").
Bleibt die Frage, was in den 43 Byte (bzw. es sind ja eigentlich nur 35, wenn man in die Datei schaut) wirklich steht oder stehen soll und ob das auch noch funktioniert, wenn irgendjemand "co-signing" nach DOCSIS 3.1 verwenden will. In der vorliegenden Datei ist das offensichtlich nicht der Fall, da besteht die "certificate chain" nur aus dem AVM-Zertifikat und dem Root-Zertifikat für EuroDOCSIS. Egal ... das "Umkopieren" mit "dd" sollte ausreichen, um die PKCS#7-Verpackung zu entfernen.
Unter Umständen hat so ein Image-File dann das von DSL-Boxen her bekannte Problem des "short read" für den letzten Block, wenn da nicht die 1024 Byte Nullen am Ende sind, wie es das "ustar"-Format vorsieht. Da sich die AVM-Firmware nicht daran stört, ist das unkritisch.
Wie auch immer ... da ja bereits eine Signatur-Prüfung stattgefunden hat, ist eigentlich die /var/signature in so einer Datei recht überflüssig und irgendwie bin ich mir fast sicher (ohne es beweisen/testen zu können oder wollen - das ginge nur mit dem Versuch über tr069fwupdate und dann geht bei korrekter Signatur die Installation los), daß diese Datei nur "pro forma" eine Signatur enthält (bei der Installation über "sw_dl" wird die nicht geprüft).
Da diese Signatur-Datei zu allem Überfluß auch noch die erste im Tarball ist, kann eigentlich der übliche Mechanismus wie bei den DSL-Modellen nicht 1:1 übernommen worden sein - selbst wenn man natürlich beim TAR-Format auch einen Member vorne anfügen könnte. Die Skript-Dateien aus meinem "signimage"-Verzeichnis im YourFritz-Repository kommen jedenfalls zu dem Schluß, daß die (MD5-)Signatur zwar mit dem öffentlichen Schlüssel "avm_firmware_public_key1" erstellt wurde, aber nicht zum Inhalt des Images paßt. Das könnte aber auch daran liegen, daß die eben nicht davon ausgehen, daß nach der Signatur-Datei im Tarball noch weitere Daten kommen ... so ein CVC-Image ist exotisch genug, daß ich da nicht noch irgendwelche Anpassungen in "signimage" vornehmen will (@opto: Die Aufforderung aus dem Signatur-Thread ist damit also "abgelehnt" - lohnt nicht wirklich, dazu kommen zu wenige Leute an ein CVC-Image und die interessiert dann die korrekte Signatur auch als allerletztes.)
Und damit schließt sich dann der Kreis auch wieder (diejenigen, die das Thema "Signatur" nicht interessiert, werden gar nicht bis hier gelesen haben) ... damit man so eine manuell extrahierte "image"-Datei jetzt über das Datei-Update in die FRITZ!Box 6490 mit einer angenommenen Firmware-Version 06.60 bei der Auslieferung bekommt, müßte man ja ein "Downgrade" machen. Das setzt wieder voraus, daß (a) die Signaturprüfung doch funktioniert (dann steht die Signatur eben vor dem Inhalt) und (b) die 06.60-Firmware (entgegen allem, was bei den DSL-Modellen Einzug gehalten hat) sogar bereit ist, einen Downgrade der Firmware auszuführen (also /var/install mit "-f" aufzurufen).
Das kann ich mir irgendwie auch nicht so richtig vorstellen ... selbst wenn die Seite tools/downgrade.html existiert oder man natürlich auch hier die HTTP-Requests manipulieren könnte, fehlt doch normalerweise im "firmwarecfg"-Binary inzwischen die Unterstützung für einen "downgrade"-Button beim Submit - warum die bei der 06.60 jetzt vorhanden sein sollte, erscheint mir unlogisch.
Bliebe also noch die Erklärung, daß es jemandem gelungen ist, in die 06.60 per Telnet einzudringen und dort den Aufruf von "/var/install -f" manuell zu starten, damit ein Downgrade auf 06.50 erfolgt. Warum macht man so etwas? Weil es geht? :gruebel:
Vielleicht habe ich aber auch wieder ganz falsche Vorstellungen und unter einer "Retail fritzbox mit 06.50" muß man etwas vollkommen anderes verstehen ...
@Elastan:
Das mit der "urladercerts.tar.gz" hast Du genau verkehrt herum verstanden, die existiert eben nur dann, wenn die Box die Daten
nicht von AVM geladen hat und sie "in der Hardware" hinterlegt sind (ZERTIFIKATE steht in der Ausgabe von "cat /proc/sys/urlader/config"). Den Inhalt von /etc kannst Du gar nicht ohne weiteres überschreiben (also auch in "docsis" nichts löschen), das ist immer noch eine SquashFS-Partition (und damit read-only), was da den Inhalt der Dateisystem-Partition darstellt.
@all:
Lange nicht jeder Fehler beim Firmware-Update muß aus fehlenden oder falschen Zertifikaten resultieren, das ist nur
ein sehr spezieller Fehler, der halt bei den Modellen mit passenden Voraussetzungen auftreten kann, wenn die vergeblich versuchen, ein Zertifikat von AVM über das Internet zu laden. Tritt so etwas beim "Pseudo-Update" auf, hat das mit Zertifikaten (die Behauptung wage ich sogar ohne die üblichen einschränkenden Worte) mal genau gar nichts zu tun.
Auch ansonsten ist es keine wirklich gute Idee, ständig mit einem Pseudo-Image für das Aktivieren von Telnet zu hantieren.
Meine "Fundamentalkritik" daran kann man direkt im LCR-Thread nachlesen, denn das gilt keinesfalls nur für die 6490 ... hier ist es nur noch etwas komplizierter, weil das korrekte (Re-)Starten der über "prepare_fwupgrade" zuvor heruntergefahrenen AVM-Dienste (und das geht vom DECT bis zur Kindersicherung) sich auf mehrere Systeme verteilt. Das geht schon beim Stoppen des USB-Subsystems (über usb.pandu) los, das erfolgt nämlich nicht auf dem ARM-Core (wo das /var/install-Skript arbeitet), sondern auf dem ATOM-Core. Nun weiß ich ja nicht, wie das jeweils verwendete Pseudo-Image aussieht (das kann höchst unterschiedlich sein, je nachdem, woher man es bezogen hat) ... aber wenn das nicht die passenden Kommandos enthält, geht am Ende zwar Telnet, aber kein USB oder auch keine Kindersicherung oder was auch immer da beim Restart der Services noch fehlen könnte oder bei der 6490 eben anders funktioniert.
Als "Einstieg" mag das noch gängig sein oder wenn man es nur bei Bedarf verwendet und danach irgendwann (zeitnah) die Box ohnehin neu startet. Als Dauerlösung sollte sich entweder mal jemand die Arbeit machen und ein garantiert zur 6490 passendes Image erstellen (und nicht immer nur blind die "Vorgabe" verwenden, denn die ist eben auf DSL-Boxen mit einem System ausgerichtet - auch hier kann das Lesen des betreffenden Threads im LCR-Unterforum eigentlich nicht wirklich schaden) oder man greift dann eben doch zur "richtigen Lösung" und baut sich (wenn man denn schon Telnet-Zugang zur 6490 hat) auch das passende System dafür.
Alles andere ist (meine Meinung) "Flickschusterei" ... auch das gilt nicht nur für die 6490 im Speziellen, sondern für diese "Pseudo-Updates" insgesamt - solange man danach in absehbarer Zeit neu startet, funktioniert das ganz leidlich, als "Dauerlösung" nach jedem Neustart braucht es vermutlich (hängt eben davon ab, was da im Image alles neu gestartet wird - die denkbaren Dienste sind ja auch im LCR-Thread erst Stück für Stück dazugekommen) mindestens eine Anpassung an die Besonderheiten. Wenn das jemand schon gemacht haben sollte, kann er das ja mal veröffentlichen ...
