Fritzbox 6490 Cable Firmware Update?

Ich habe gerade eine eventuell gute Nachricht zu verkünden. Habe ein bisschen auf meiner 6490 mit Firmware 6.26 rumgespielt...
Und habe einen Weg gefunden, auf die offzielle manuelle Update-Seite zu gelangen. Kein Spaß.

Ich würde jetzt mal aus taktischen Gründen drauf verzichten, den Weg zu beschreiben - aber wenn jetzt ein Image zur Verfügung stünde...

fritz.jpg

PS: Die Fehlermeldung kam, weil ich versucht habe ein Pseudo-Image für Telnet zu laden. Das ist mir bisher noch nicht gelungen.
 
Zuletzt bearbeitet:
Mit der neuen Firmware (mit dem "responsive design") sollte der Aufruf dann auch nicht mehr funktionieren ... wobei man sich die im Screenshot gezeigte Seite problemlos durch die URL "fritz.box/tools/update_not_signed.html" anzeigen lassen kann (zumindest sollte das auch bei der 06.26 so sein).

Hier frage ich mich auch, was die "offizielle manuelle Update-Seite" sein soll ... hat AVM tatsächlich in die 06.26 die Lua-Dateien "update.lua", "update_file.lua" oder "update_auto.lua" eingebaut? Diese Version fehlt mir in meiner Sammlung, aber alle davor vorhandenen Versionen (seit der 06.08) hatten die notwendigen Seiten tatsächlich nur für den ATOM-Core an Bord und da scheitert das dann schon wieder daran, daß dort die "Zieldatei" (usr/www/cgi-bin/firmwarecfg) nicht vorhanden ist.

Wenn Du also durch den Aufruf der "update_file.lua"-Seite auf dem ATOM-Core (normalerweise der mit der IP-Adresse 192.168.178.254) zu diesem Ergebnis gelangt bist, wird das auf dem ATOM-Core trotzdem nichts werden und auch die Umleitung des HTML-Formulars auf den ARM-Core sollte dabei nichts (mehr) helfen (vielleicht noch mit einer tatsächlich korrekt signierten Firmware-Datei) - aber um so einen HTTP-Request zu erzeugen, braucht man ja auch nicht unbedingt die passende HTML-/Lua-Seite und insofern würde ich das jetzt nicht als Durchbruch interpretieren. Das kann man auch "zu Fuß" über wget oder meinetwegen mit curl oder PHP oder was auch immer erreichen.
 
Bei der Seite "tools/update_not_signed.html" kommt bei mir nur ein farblose Seite mit dem selben Text.
Sobald ich einen Button drücke, lande ich auf der Anmeldeseite.

Meine Version lässt mich eine Firmware auswählen und auf die Box übertragen.
Bildschirmfoto 2016-08-05 um 16.38.56.jpg

Konnte man das schon? Ich wusste es zumindest nicht...
 
@stanpete78:
Du weißt aber schon, daß die Box zwei parallel arbeitende Prozessoren hat?

Beide stellen einen HTTP-Server zur Verfügung und wenn ich das in den Vorgängerversionen ansehe, dann gibt es auf dem ARM-Core (da läuft die "Verwaltung" der Box ab) die betreffenden Seiten nicht. Daher tippe ich eben darauf, daß Du die Seite über den ATOM-Core aufrufst ... außer AVM hat tatsächlich bei der 06.26 die fraglichen Dateien auch auf den ARM-Core gepackt (was mir richtig spanisch vorkäme). Daher einfach ganz deutlich die Frage, ob Du das über den ARM-Core (.1) oder den ATOM-Core (.254 bei 24er-Maske) machst.

Aber noch einmal ... diese Seiten sind ja am Ende nichts anderes als Hilfsmittel für den unbedarften Benutzer, damit ihm der Browser den richtigen HTTP-Request zur Box abnehmen kann. Wenn man den von Hand ausführt, erreicht man im Prinzip dasselbe ... es braucht also diese Seiten gar nicht wirklich. Bisher war das jedenfalls immer "stateless" auf der Box (wenn man mal von "webuicookie" absieht) ... wobei die Einführung der neuen Sicherheitsfunktion mit der Code-Eingabe in der 113.06.69 das so ein wenig aufweicht.
 
Strange ...

@opto:
Hast Du eine 06.26 und kannst dort mal im Dateisystem nachsehen, warum es da die Dateien geben soll bzw. ob das so ist (also die drei "update*.lua"-Files)? Das kann ja noch keine Retail-Version sein, wenn es eine 06.26 ist und damit verstehe ich absolut nicht, warum die da plötzlich vorhanden sein sollen.
 
@PeterPawn
Ich finde hier auch nichts in Richtung update.lua
Was sagt Dir "form method="POST" action="/cgi-bin/firmwarecfg" ?
 
Nichts ... andererseits ist das ja nun genau das, was ich weiter oben geschrieben habe.

Die Frage war da ja, was die "offizielle manuelle Update-Seite" sein soll (in #46). Daß man gar keine HTML- oder Lua-Seite für einen solchen Aufruf braucht, habe ich ja ebenfalls in #46 geschrieben.

Leider aber auch, daß Du ohne passend signierte Firmware-Datei (und das gilt m.E. bei der 6490 auch schon für die Versionen der Firmware vor 06.5x - bei den DSL-Boxen wurde das erst mit dieser Version eingeführt) das "firmwarecfg"-Binary (auch das habe ich in #46 ja erwähnt) vermutlich nicht davon überzeugen wirst, irgendeine Aktion in der enthaltenen /var/install auszuführen.

Bei der 06.26 (zumindest bei der 6490) sollte dann auch der hier beschriebene Bug bereits beseitigt sein ... wenn nicht, sollte der Provider eigentlich eine Box mit einer so alten Firmware-Version gar nicht erst provisionieren und erst recht nicht mit neuerer Firmware versorgen.

Das dürfte die Idee bei AVM gewesen sein, als man eine andere Artikelnummer eingeführt hat ... wenn der Provider hier bei einer bereits angegriffenen Box trotzdem provisioniert und auch noch die Firmware aktualisiert, ist ja wieder der Zugriff auf dieses Update möglich und das ist vermutlich etwas, was AVM tatsächlich nicht möchte.

Solange der Provider die Box nur provisioniert und der Kunde sie verwenden darf, ist halt für diesen Kunden auch der Zugriff auf die DOCSIS-Konfiguration möglich - aber das ist dann eben das Problem des Providers und erst dann, wenn der Kunde über eine solche Box auch noch ein Update abfangen kann, wird es zu einem solchen für AVM.

Hier unterstelle ich jetzt mal, daß AVM tatsächlich keine Firmware-Images und/oder Recovery-Programme veröffentlichen möchte und es am liebsten sähe, wenn diese Updates ausschließlich innerhalb der FRITZ!Box bleiben würden. Ist erst einmal ein solches Image "allgemein verfügbar", steht wieder der Modifikation der FRITZ!Box Cable-Modelle nichts mehr im Wege und das kann bei DOCSIS-Geräten eigentlich nicht im Interesse des Herstellers sein.

Das Urheberrecht wird das nur unzureichend verhindern können, so eine Firmware ist nun mal ein Gesamtwerk und der Kernel steht unter GPLv2 - damit darf ihn jeder weiterverbreiten - und auch Teile der restlichen Firmware (die als Dateisystem-Image nun mal eine Einheit von Open- und Closed-Source-Komponenten bildet) stehen unter Lizenzen, die jedem das Recht zur Weiterverbreitung ausdrücklich einräumen und von vorhergehenden Lizenznehmern in der Kette (hier wäre das AVM) verlangen, daß diese ihrerseits dieses Recht auch an den Teilen einräumen, die sie selbst mit den betreffenden Komponenten zusammengebracht haben. Auch da war eigentlich das Cybits-Urteil recht eindeutig ... AVM darf sich nicht darauf berufen, daß die ClosedSource-Komponenten in der Firmware dazu führen, daß diese nun plötzlich nicht mehr unter die von den ursprünglichen Autoren eingeräumten Lizenzen fallen.

Wenn man mangels der Quellen keine komplette unabhängige Firmware mit identischem Funktionsumfang erstellen kann, ist das zwar ein ewiger Zankapfel in der OpenSource-Szene, aber inzwischen mehr oder weniger akzeptiert und es gibt ja auch gute Gründe, warum der Kernel immer noch unter der alten GPLv2 steht und nicht einfach unter die GPLv3 gestellt wurde (dann wäre diese "Tivoisierung" - also das Verriegeln von Geräten, so daß man die Firmware nicht einfach auslesen kann - nämlich auch nicht mehr möglich und es wurde befürchtet, daß dann viele Hersteller von Linux auf ein paar andere existierende Mikrokernel umschwenken würden).

Also wird AVM vermutlich einige Anstrengungen unternehmen (das ist aber auch nur eine Annahme meinerseits), um die Verbreitung von Firmware für die DOCSIS-Modelle nach Möglichkeit zu verhindern - ansonsten ist tatsächlich die Gefahr der Störung anderer durch modifizierte DOCSIS-Boxen nicht so ganz von der Hand zu weisen (und die Zertifizierung bei CableLabs erfolgt natürlich für die unmodifizierte Firmware und nicht für eine vom Besitzer noch einmal angepaßte). Wobei auch das mit Vorsicht zu genießen ist ... manchmal sind solche Argumentationen auch vorgeschoben, wie wir wissen.
 
Ich habe die daten aus der support.txt datei.

Das file lag in /var/tmp. Interessanterweise habe ich noch eine .txt datei in der ein tftp prozess lief an dem man die IP addresse des servers sieht.
An den habe ich mich gerade mit tftp verbunden, es funktioniert und der download laeuft ... :)

was kann ich denn nun mit der .cvc datei anfangen?
 
Der ATOM-Core benutzt natürlich das "native" LE-Format.

Ansonsten sollte bei x:y ja irgendetwas stehen ... da würde ich jetzt dem blkid nicht allzu weit trauen, andererseits kann es ja auch ein SquashFS-Image mit einem Dummy-Header für ein SquashFS-Image geben - wobei sich mir der Sinn auch nicht so richtig erschließen würde.

Verstehe ich das richtig, daß die 06.26 tatsächlich im ARM-System eine Update-Funktion über das GUI enthält und auch noch eine, die ein Datei-Image akzeptiert? Was ist denn daran genau "buggy"? Wenn ich #52 nun endlich richtig verstehe, soll es ja wieder genau keine "Update"-Seite geben - jetzt werde ich ja immer neugieriger auf die (alte) 06.26; die habe ich nie in den Händen gehabt (auch keine 06.3x).

Ansonsten muß das Flashen ja nicht unbedingt über ein RAM-Image erfolgen ... das ist (imho) ein durchaus beachtlicher Unterschied zu den MIPS-Bootloadern, aber es geht natürlich auch nicht einfach als "MTD1".

- - - Aktualisiert - - -

Na da wird AVM aber schwer begeistert sein, wenn da bei KMS ein TFTP-Server mit der CVC-Datei einfach so erreichbar ist von einem Client hinter der Box. Mann, mann, mann ...
 
Der update lief uebrigens so:

1402 root 6848 S /usr/sbin/sw_dl 0 0 6490.en-de-es-it-fr-pl.141.06.50
1405 root 1256 S tar xvf -
1406 root 1048 S ti_tftp XXX.XXX.XXX.XXX -f ...

Die Parameter sind leider von ps abgeschnitten, aber ich nehme an man kann das update von Hand anstossen wenn man sich auf die Box einloggt (was ich bisher nicht probiert habe).
 
Dann ist das vermutlich kein echter SquashFS-Superblock ... wobei 4:0 ja noch stimmen könnte.

Schau ich bei Gelegenheit mal rein in die Repeater-Firmware ... aber nicht auf die Schnelle.

Der ATOM hat auch sein Web-Interface, aber dem fehlt eben (bis zu den Versionen, die ich kenne) das "firmwarecfg"-Binary als "Ziel" für den Update-Request und an ein "cross interface" kann/will ich nicht glauben.

Wenn das "buggy" auf die fehlenden Links im GUI hinausläuft, dann ist das ja eher ein Fehler im "firmwarecfg", wenn das überhaupt (unabsichtlich?) auch solche Requests reagiert ... aber das wird hoffentlich wenigstens die Signaturprüfung richtig machen, sonst stehen AVM jede Menge geschrottete Boxen ins Haus, weil die meisten die Unterschiede eben doch nicht kennen und dann einfach mal eine 7490-Firmware so abändern, daß sie sich an der unterschiedlichen Hardware auch nicht mehr stört.
 
#53 - Bei der "Homebox" von Vodafone ist eine CD dabei, auf der ist kein Recovery Image. Was aber nichts über die Release Version aussagt.
#57 - Ich kann bestätigen das es keine update.lua, update_file.lua und update_auto.lua in /system gibt - zumindest per Webinterface.
#59 - Ich konnte die aktuelle Labor Version der 7490 mit der letzten Version von fwdu entpacken.

http://fritz.box/cgi-bin/firmwarecfg ist vorhanden, leider kann ich kein Bild anhängen.
Code:
[COLOR=#3F464C][FONT=Arial]Das Update ist fehlgeschlagen:[/FONT][/COLOR]
[COLOR=#FF0000][FONT=Arial]Unsupported Request Method.[/FONT][/COLOR]
[COLOR=#3F464C][FONT=Arial]Wiederholen Sie das Update oder starten Sie die FRITZ!Box neu.[/FONT][/COLOR]
[B] Update wiederholen[/B]

[COLOR=#3F464C][FONT=Arial]
[LIST=1]
[*]Geben Sie die Datei mit dem Update an:
[*]Starten Sie das Update mit der Schaltfläche "Update".
Update
[/LIST]
[/FONT][/COLOR]
[B] FRITZ!Box neu starten[/B]

Der Versuch Telnet per image zu aktivieren ist fehlgeschlagen, hatte aber keine Zeit für die Fehlersuche.

Zu #54, die Vermutung AVM könnte den Updateprozess für die Kabelboxen geändert haben hört sich für mich stimmig an. Gerade im Bezug darauf Manipulationen an der Firmware zu verhindern zu wollen. Ist aber reine Mutmaßung. Ich persönlich werde mein Widerrufsrecht nutzen und die Box zurück schicken. Da warte ich lieber auf den Preisverfall nach dem 6590 Release bzw. falls das Update möglich ist, lassen sich immer noch Boxen bei e... ergattern.
 
@opto:
Ich habe gar kein Auto, Senorita ... bzw. ich habe keine Firmware für die 6490 in der Version 06.26 oder 06.3x - damit kann ich auch keine Sicherheitslücken in diesen Versionen (sicher) kennen.

Ich will auch gar nicht, daß alle Binaries auf beiden Systemen vorhanden sind, aber wenn eine Lua-Seite von einem Core geladen wird, dann wird beim Absenden eines HTML-Formulars (ohne explizite Angabe eines Hosts in der URL und das ist bei den Seiten ja nicht der Fall, die enthalten normalerweise nur ein target=/cgi-bin/firmwarecfg) der Inhalt dieses Formulars auch genau an den Server gesendet, von dem das Formular geladen wurde.

Da wir hier nicht darüber reden, über den Briefkasten auf dem anderen Prozessor Kommandos auszuführen, ist es schon entscheidend, daß "firmwarecfg" als CGI-Programm auf dem ATOM-Core (da wo die Update-Dateien in Lua liegen) eben nicht vorhanden ist und da nutzt auch kein NFS-Share etwas, wenn das Programm mit der falschen ABI auf dem anderen Prozessor existiert.

Auch das "Umschiffen" dieser Klippe - also das "Umleiten" des Aufrufs von "firmwarecfg" auf den ARM-Core (das ist nun mal der einzige, auf dem firmwarecfg vorliegt und damit kann das über die CGI-Schnittstelle auch nur dort aufgerufen werden) - hatte ich irgendwo vorher bereits "angetextet" ... alles machbar, aber zumindest primär wohl nicht von Erfolg gekrönt, solange das Image nicht signiert ist.

Wobei ich mir (mangels 06.26) auch nicht 100% sicher bin, daß die von RedTeam gemeldete Lücke mit dem "Einschmuggeln" eines falschen CSS-Files (da wird ja ein eigentlich statisches CSS-File durch eine Lua-Variante ersetzt, wenn ich mich richtig erinnere) auch in der 06.26 bereits gefixt ist ... ich gehe nur aufgrund von zeitlichen Abfolgen davon aus, testen konnte ich es ja nie selbst.
 
In meinem 6.50 image fure 6490 sind zwei squashfs images, eines fuer ARM, eins fuer x86.
Das x86 image kann ich auspacken, das arm image wird angemeckert.
:~/tmp/fs/var/remote/var/tmp/x86$ unsquashfs -s filesystem.image
Found a valid SQUASHFS 4:0 superblock on filesystem.image.
Creation or last append time Thu Jun 4 20:23:52 1970
Filesystem size 13065.46 Kbytes (12.76 Mbytes)
Compression xz
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always_use_fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 198
Number of inodes 3327
Number of ids 1
:~/tmp/fs/var/remote/var/tmp$ unsquashfs -s filesystem.image
Reading a different endian SQUASHFS filesystem on filesystem.image
Filesystem on filesystem.image is (4:0), which is a later filesystem version than I support!

Gibt es ein unsquashfs für big endian?
 
Gibt es ein unsquashfs für big endian?
Nein. Ist geheim ... bloß nicht suchen vor dem Fragen. Sorry, manchmal kommt man sich glatt vor wie auf Facebook oder Twitter, wo es mehr darum geht, sich bemerkbar zu machen als das zu lesen, was andere schreiben (oder geschrieben haben).
 
Sorry der Nachfrage, wird nicht wieder vorkommen. Ich hatte auch eher an source gedacht der beides kann, da ich das fuer ARM/Debian bräuchte. Selbst die letzten sourcen (4.3.) können das nicht, da hilft auch suchen auf die schnelle nix. Egal.
 
@fesc:
Ich weiß nicht, ob das "sorry" jetzt ernsthaft gemeint ist oder der Ausdruck eines "Eingeschnapptseins" ... ich nehme es mal als Bestätigung, daß Du den Hinweis auf die Suche, die da umgehend Ergebnisse liefern sollte, aufgenommen und verstanden hast. Andererseits paßt das dann wieder nicht zur Feststellung
fesc schrieb:
Selbst die letzten sourcen (4.3.) können das nicht, da hilft auch suchen auf die schnelle nix.
Dann hast Du einfach nicht richtig gesucht ... es gibt eine Version der SquashFS-Tools 4.3, die auch für AVM-BE angepaßt wurde und damit tatsächlich in der Lage ist, alle die Formate des SquashFS zu behandeln, die nicht bereits mit der normalen (LE-)Version der offiziellen SquashFS 4.3-Tools verarbeitet werden können und bei AVM derzeit in Gebrauch sind. Und das logischerweise auch mit den entsprechenden Sourcen ... schließlich ist das OpenSource-Software.

Wenn man wirklich nichts findet, kann man tatsächlich nachfragen ... aber wenn Du tatsächlich nichts gefunden hast, dann hast Du sehr merkwürdig gesucht (und nicht nur hier, sondern auch im gesamten Web).

Sowie man bei Google nach "unsquashfs avm" sucht, landet man praktisch zwangsweise bei den richtigen Treffern und das ist als Suchbegriff sicherlich nicht sehr weit hergeholt. Der vierte Treffer in den Ergebnissen führt dann zum Freetz-Trac und selbst wenn man davon noch nie etwas gehört haben sollte, bringt schon ein flüchtiger Blick in die betreffenden Seiten die Erkenntnis, daß man genau dort vor der richtigen Schmiede ist.

Wenn man allerdings lieber fragt als zu suchen, dann muß man auch damit leben können (das ist hier eben kein "live chat", wo die Frage "in time" beantwortet werden muß/kann), wenn man auf seine Irrtümer hingewiesen wird ... so schön und richtig es auch ist, wenn Du Deine Erkenntnisse mit uns teilst, so sollte das dann trotzdem nicht dazu führen, daß man "private Nachhilfe" geben muß, was die Grundzüge von FRITZ!Boxen angeht. Daß Du da nicht der erste Interessent bist und sicherlich mind. 95% der "üblichen Fragen" bereits irgendwo einmal beantwortet wurden, müßte Dir auch beim Schreiben Deiner Frage bereits bewußt gewesen sein - die 6490 ist nun auch nicht die erste FRITZ!Box, die jemals in freier Wildbahn gesichtet wurde.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.