Fritzbox 6490 Cable Firmware Update?

- Nach System/Sicherung/Wiederherstellen navigieren
- "Entwickler-Tools" im browser aktivieren
- Rechtsklick auf den "Datei auswaehlen" Button --> Inspect
- Folgende elemente im HTML code aendern:
id=uiImport aendern in id=uiFile
name=ConfigImportFile aendern in name=UploadFile
- Dann auf "Datei auswaehlen" und das pseudo-image (telnet-1.tar) hochladen (http://www.antary.de/2015/07/28/fri...telnet-temporaer-via-pseudo-image-aktivieren/)


Nach ca. 15 sek sollte ein Dialog erscheinen der auffordert eine nicht-Offizielle firmware zu bestaetigen.
Dies tun, jetzt sollte telnet auf die box (normales passwort) funktionieren (bis zum naechsten reboot).


Manchmal stuerzt die box beim hochladen komplett ab, einfach nochmal probieren.

Funktioniert das dann auch noch mit der Version 6.50?
 
Funktioniert bei mir leider nicht

Das Update ist fehlgeschlagen:

Es trat ein nicht näher spezifizierter Fehler während des Updates auf. (0)

Wiederholen Sie das Update oder starten Sie die FRITZ!Box neu.
 
Welche Firmware?
 
habe 6.24 drauf
und beim ausführen von
telnet-1.tar
 
Zuletzt bearbeitet:
Servus an alle
bei mir klappt auch nicht nach deine Anleitung ich kann mich zwar einlogen über putty aber nach demm ich password eingebe kommt das

[COMMON_COMPONENTS.EXT_SWITCH(pid=842)]: extSwitchGetStatusPerLink(1) failed
[ERROR] [COMMON_COMPONENTS.L2SWITCH(pid=842)]: _L2Sw_System5SemOp:639 semget() fail, errno=2
[ERROR] [COMMON_COMPONENTS.L2SWITCH(pid=842)]: L2SWITCH_MdioAccessLock:1554 _L2Sw_System5SemOp() fail, Rc=-1
[ERROR] [COMMON_COMPONENTS.EXT_SWITCH(pid=842)]: [athRegRead] unable to acquire lock.
[ERROR] [COMMON_COMPONENTS.EXT_SWITCH(pid=842)]: extSwitchGetStatusPerLink(2) failed
[ERROR] [COMMON_COMPONENTS.L2SWITCH(pid=842)]: _L2Sw_System5SemOp:639 semget() fail, errno=2
[ERROR] [COMMON_COMPONENTS.L2SWITCH(pid=842)]: L2SWITCH_MdioAccessLock:1554 _L2Sw_System5SemOp() fail, Rc=-1
[ERROR] [COMMON_COMPONENTS.EXT_SWITCH(pid=842)]: [athRegRead] unable to acquire lock.

in Dauerschleife ,

Firmware 06.26 avm umbranding von kdg
 
Auf dem ersten telnet login kommt der ganze Konsolenoutput. Einfach eine 2te session aufmachen, da ist Ruhe.
 
Auf dem ersten telnet login kommt der ganze Konsolenoutput. Einfach eine 2te session aufmachen, da ist Ruhe.

danke hast recht gehabt mit 2te session
wie geht jetzt weiter bitte detailliert wo hast du 6.50 image her?

ich bin neu in Frizbox Scene.
hatte bis jetzt nur mit DDWRT zutun gehabt
 
Zuletzt bearbeitet:
- Nach System/Sicherung/Wiederherstellen navigieren
- "Entwickler-Tools" im browser aktivieren
- Rechtsklick auf den "Datei auswaehlen" Button --> Inspect
- Folgende elemente im HTML code aendern:
id=uiImport aendern in id=uiFile
name=ConfigImportFile aendern in name=UploadFile
- Dann auf "Datei auswaehlen" und das pseudo-image (telnet-1.tar) hochladen (http://www.antary.de/2015/07/28/frit...ge-aktivieren/)

nachdem ich das getanhabe kommt
das

2.PNG

anstatt
das
Nach ca. 15 sek sollte ein Dialog erscheinen der auffordert eine nicht-Offizielle firmware zu bestaetigen.
 
Es hatte doch bei mir geklappt ich hatte einen Fehler begangen und zwar ich hatte für die webif von Fritzbox kein Passwort vergeben, weshalb hatte die Datei gar nicht hochgeladen gehabt. Ich habe erst die Fehlermeldung überflogen beim zweiten Versuch hatte ich's gemerkt :)

Das telnet geht in zweiter Session ruhig nur wenn die erste Session offen bleibt.
 
ein Kennwort habe ich für die Fritzbox auch vergeben, doch nach dem Drücken auf "Wiederherstellen" passiert nichts: Der Post auf http://<ipderFB6490>/cgi-bin/firmwarecfg steht weiterhin aus.
Oder muss die Fritzbox eine spezielle IP haben? Oder muss man sonst irgendetwas zaubern?
 
Zuletzt bearbeitet:
Funktioniert das dann auch noch mit der Version 6.50?

Also bei einer weißen UM-Box mit Firmware 6.50 und avm-Branding wird das Pseudo-Update leider nicht mehr akzeptiert.
Screenshot at 2016-08-07 18:00:38.png
Ich dachte die Signaturprüfung wurde erst mit 6.51 eingeführt?
 
@tetzlav:
Bei der 7490 stimmt das ... ansonsten dürfte alles, was als Firmware ca. ab Februar 2016 erschienen ist, eine gültige Signatur verlangen.

- - - Aktualisiert - - -

@1of16:
Bei mir funktioniert der angegebene Link auch nicht ... da wird nicht einmal der Host 192.168.1.222 gefunden.
 
Also mit dem cgi-bin/firmwarecfg​ Link hatte bei mir auch nicht funktioniert.
Es funktioniert bei mir nur mit der "Entwicklertools"-Methode...
 
Also mit dem cgi-bin/firmwarecfg​ Link hatte bei mir auch nicht funktioniert.
Was muß man sich darunter vorstellen?

Das Absenden eines Formulars endet ja immer in einem Aufruf von cgi-bin/firmwarecfg, wenn man eine Image-Datei "hochladen" will.

Auf welchem Weg man diesen Request dann ausführt (ich hatte schon einmal "wget" und/oder "curl" angesprochen, hier wird der Upload eines "multipart/form-data"-Formulars am Ende mit "nc" ausgeführt - das ist vom Prinzip her sogar dasselbe, lediglich die Namen der POST-Elemente unterscheiden sich beim Upload eines Firmware-Files) spielt dafür erst einmal keine Rolle.

Meintest Du etwa den direkten Aufruf von cgi-bin/firmwarecfg als URL auf der Box? Das funktioniert erst mal gar nicht, egal was Du anstellst - da muß schon ein passender HTTP-Request mit dem richtigen Payload her.
 
ok, da habe ich mich auch etwas doof ausgedrückt: Ich versuche es auch über die "Entwicklertools"-Methode, passe "id" und "name" des Input-Feldes an, wähle über den jetzt modifizierten Button "Datei auswählen" (bei anderen Browsern heißt der Button dafür "Durchsuchen") die telnet-1.tar aus und klicke zum Abschließen auf den Button "Wiederherstellen". Damit wird die Datei lt. dem Protokoll der Entwicklungstools via POST an cgi-bin/firmwarecfg​ geschickt, nur bei diesem Schritt passiert bei mir halt nichts.
Denn nur durch das Ändern der Eigenschaften des Input-Feldes und das Auswählen der Datei, kann ja nichts passieren. Oder gibt es einen anderen Knopf, den man drücken muss?
 
Zuletzt bearbeitet:
Damit wird die Datei lt. dem Protokoll der Entwicklungstools via POST an cgi-bin/firmwarecfg​ geschickt, nur bei diesem Schritt passiert bei mir halt nichts.
Denn nur durch das Ändern der Eigenschaften des Input-Feldes und das Auswählen der Datei, kann ja nichts passieren. Oder gibt es einen anderen Knopf, den man drücken muss?

Doch, ziemlich genau so funktioniert das.
Man kann das anscheinend mit jeder Firmware auf der 6490 machen. Nur dass eben bei 6.50 aufwärts der Hinweis auf nicht autorisierte Firmware kommt und die tar nicht entpackt wird.
 
Ich denke mal, daß ein Button mit "Wiederherstellen" schon per se der falsche sein könnte (kommt halt auf den "name"-Eintrag dieses Buttons an, weil sich daraus der Inhalt des HTTP-Requests ableitet) ... das Formular enthält u.U. mehrere Möglichkeiten und wie so ein Datei-Upload (für eine Firmware-Datei) richtig auszusehen hat, kannst gerade Du ja problemlos bei der 7390 probieren (sie startet dann allerdings neu, wenn man eine angebliche Firmware-Datei übertragen hat, auch wenn keine Änderung am System stattfindet).

Je nach Version der Firmware ist dann die Reaktion auf den Versuch des unsignierten Uploads eine andere und man muß ggf. noch einen weiteren Request absetzen (der dann aber die Image-Datei nicht erneut im Payload haben muß), damit man das "Update fortsetzen" simuliert. Das gilt und funktioniert zwar alles per se nur für die DSL-Modelle, aber wenn da jemand bei den DOCSIS-Modellen tatsächlich diese Funktion freundlicherweise eingebaut hat in eine (wenn auch inzwischen ältere) Firmware-Version, dann wird das vermutlich auch dort funktionieren.

Ich habe gerade mal bei mir nachgesehen, das entsprechende Skript für den PoC für dieses Problem hat einen Zeitstempel vom 09.12.2014 - das ist auch so in etwa der Zeitpunkt, wo eine solche (oder sehr ähnliche) Lücke an AVM gemeldet wurde - das war die Zeit, wo bei der 6490 gerade mal die 06.10 aktuell war (für KDG-Kunden, bei anderen Anbietern gab es die 6490 noch gar nicht). Warum die in einer 06.26 jetzt immer noch offen sein soll (in erster Linie sogar, warum da überhaupt unsignierte Images akzeptiert werden), ist mir ein echtes Rätsel ... da muß etwas ziemlich durcheinander geraten sein bei der Versionierung.
 
Zuletzt bearbeitet:
Ich denke mal, daß ein Button mit "Wiederherstellen" schon per se der falsche sein könnte (kommt halt auf den "name"-Eintrag dieses Buttons an, weil sich daraus der Inhalt des HTTP-Requests ableitet) ... das Formular enthält u.U. mehrere Möglichkeiten und wie so ein Datei-Upload (für eine Firmware-Datei) richtig auszusehen hat, kannst gerade Du ja problemlos bei der 7390 probieren (sie startet dann allerdings neu, wenn man eine angebliche Firmware-Datei übertragen hat, auch wenn keine Änderung am System stattfindet).
ja, deine Vermutung ist richtig. Ich musste beim "Wiederherstellen" Button name="apply" durch id="uiUpdate" ersetzen, dann funktionierte es auch bei mir.
Zwar trennte die Box danach die Internetverbindung, aber das ist weniger tragisch.

Dann bin ich nun gespannt auf Teil zwei der Anleitung von fesc :)
 
7490 6.50 und neuer ist auch nicht entpackbar
Dann hast Du vermutlich eine andere Version von "unsquashfs", als ich sie habe.

@er13 wird sicherlich irgendwann (im Moment fehlt die Zeit, wie er mir per E-Mail schrieb) das "unpack all" inkl. "NMI vector gap"-Behandlung nachziehen im Trunk, das bisher ist ja nur eine (recht inkompatible) Änderung bzgl. des Suchens nach dem Superblock. Aber dann müßtest Du halt den richtigen Patch (bzw. die resultierende Version der "patch"-Datei für das "make"-Verzeichnis in Freetz) selbst auschecken und ersetzen - was da im Trunk im Moment geht und was nicht, weiß ich nicht, weil ich eben an dieser Stelle meinen Fork benutze.

Wenn sich eine 06.50 oder neuer für die 7490 auch damit nicht entpacken ließe, würden sicherlich die "modfs"-Benutzer Sturm laufen ... vielleicht probierst Du ja mal meine Version für x86.
 
Ok, das hatte ich vollkommen falsch verstanden ... es gibt zuviele Leute, die Image und Recovery-Programm nicht auseinanderhalten können.

Keine Ahnung, was AVM da vielleicht macht ... was sagen denn die üblichen Tools zur Analyse von PE-Images? Vielleicht nur eine andere Kompression des ".data"-Segments, in dem die Images ja bisher direkt lagen? Oder werden die verschiedenen Image-Dateien jetzt vielleicht als Ressourcen im ".rsrc"-Segment hinterlegt? Das würde dann das Erstellen neuer Recovery-Programme durch einfaches Linken ermöglichen, bei der bisher verwendeten Methode dürfte jedesmal eine komplette Übersetzung erforderlich sein, bei der die fertigen Images irgendwie in "inline"-Definitionen für die Daten umgewandelt werden. Ist aber auch nur Spekulation ... so sehr interessieren mich jetzt die Recovery-Programme auch nicht, daß ich das unbedingt erkunden müßte. Genauso gut kann es natürlich sein, daß AVM da irgendwie die Images maskiert ... wobei das schon wieder recht sinnfrei wäre, denn man kann ja auch einfach die Kommunikation mit der FRITZ!Box mitschneiden und wenn da die Daten nicht auch verschlüsselt sind (das wäre doch mal etwas :mrgreen:), dann hat man sie auf diesem Wege. Wobei das bei vorhandener Image-Datei ja auch wieder Unsinn ist, jedenfalls dann, wenn diese Image-Datei sich problemlos entpacken läßt. Wie gesagt ... klingt zwar alles nicht vollkommen uninteressant, aber es gibt einfach zuviele denkbare Erklärungen.
 
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.