Fritzbox 6490 Cable Firmware Update?

[Aux]

Nun das Problem ist, dass im Moment weder *.image noch ...recover-image.exe für FB6490 gibt.
Wenn man die hätte dann könnte man weiter forschen ;-)

 

[PeterPawn]

Angesteckt von der Frage (und weil ich mich ohnehin im Moment auf nichts wichtiges konzentrieren kann), habe ich dann doch mal in die Recovery-Version für die 7490 geschaut.

Nach Download und Auspacken des ".data"-Segments (mit 7z unter Linux) ergibt sich folgendes Bild für den Inhalt (am Beginn):

00000000  31 38 35 00 00 00 00 00  00 20 44 00 00 00 00 00  |185...... D.....|
00000010  64 65 00 00 00 00 00 00  10 20 44 00 00 00 00 00  |de....... D.....|
00000020  61 76 6d 20 31 75 6e 64  31 00 00 00 00 00 00 00  |avm 1und1.......|
00000030  20 20 44 00 00 00 00 00  61 76 6d 00 00 00 00 00  |  D.....avm.....|
00000040  38 20 44 00 00 00 00 00  04 [COLOR="#FF0000"]73 71 73 68[/COLOR] 81 [COLOR="#008000"]fc 04[/COLOR]  |8 D......sqsh...|
00000050  00 01 [COLOR="#FF0000"]d8[/COLOR] 00 03 02 [COLOR="#FF0000"]b4 56[/COLOR]  00 06 05 [COLOR="#FF0000"]7e 07[/COLOR] 00 00 09  |.......V...~....|
00000060  00 03 01 01 00 0b 09 e8  1c 00 00 e8 1c 00 00 48  |...............H|
00000070  00 07 0b a2 53 97 57 00  00 14 00 53 ef 01 00 05  |....S.W....S....|
00000080  04 a2 53 97 57 81 bc 03  00 01 03 00 03 01 04 00  |..S.W...........|
00000090  03 01 05 00 05 03 05 00  01 00 0f 11 eb 1c 00 00  |................|
000000a0  ec 1c 00 00 ed 1c 00 00  7e 07 02 00 08 00 0f 0a  |........~.......|
000000b0  d3 39 00 00 d4 39 00 00  d5 39 00 04 03 02 00 02  |.9...9...9......|
000000c0  81 af 03 00 81 08 04 ff  01 07 81 f7 03 ff 00 80  |................|
000000d0  02 ed 41 00 03 0f 04 00  00 a2 53 97 57 a2 53 97  |..A.......S.W.S.|
000000e0  57 a2 53 97 57 00 06 03  0b 00 02 00 0b 01 0e 81  |W.S.W...........|
000000f0  57 04 00 05 ff a1 00 00  0e 00 03 0c a2 53 97 57  |W............S.W|
00000100  a2 53 97 57 a2 53 97 57  00 06 01 01 00 0d 0e 2e  |.S.W.S.W........|
00000110  2e 2f 62 69 6e 2f 62 75  73 79 62 6f 78 00 4a 05  |./bin/busybox.J.|
00000120  ff a1 00 00 0e 00 03 0c  a2 53 97 57 a2 53 97 57  |.........S.W.S.W|
00000130  a2 53 97 57 00 06 01 01  00 0d 0e 2e 2e 2f 62 69  |.S.W........./bi|
00000140  6e 2f 62 75 73 79 62 6f  78 00 4a 05 ff a1 00 00  |n/busybox.J.....|
00000150  0e 00 03 0c a2 53 97 57  a2 53 97 57 a2 53 97 57  |.....S.W.S.W.S.W|
00000160  00 06 01 01 00 0d 0e 2e  2e 2f 62 69 6e 2f 62 75  |........./bin/bu|
00000170  73 79 62 6f 78 00 4a 05  ff a1 00 00 0e 00 03 0c  |sybox.J.........|
00000180  a2 53 97 57 a2 53 97 57  a2 53 97 57 00 06 01 01  |.S.W.S.W.S.W....|
00000190  00 0d 0e 2e 2e 2f 62 69  6e 2f 62 75 73 79 62 6f  |...../bin/busybo|
000001a0  78 00 4a 05 ff a1 00 00  04 00 03 0c a2 53 97 57  |x.J..........S.W|
000001b0  a2 53 97 57 a2 53 97 57  00 06 01 01 00 0d 04 64  |.S.W.S.W.......d|
000001c0  73 6c 64 00 54 05 ff a1  00 00 0e 00 03 0c a2 53  |sld.T..........S|
000001d0  97 57 a2 53 97 57 a2 53  97 57 00 06 01 01 00 0d  |.W.S.W.S.W......|
000001e0  0e 2e 2e 2f 62 69 6e 2f  62 75 73 79 62 6f 78 00  |.../bin/busybox.|
000001f0  4a 05 ff a1 00 00 12 00  03 0c a2 53 97 57 a2 53  |J..........S.W.S|
00000200  97 57 a2 53 97 57 00 06  01 01 00 0d 12 2f 2e 2f  |.W.S.W......././|
00000210  73 62 69 6e 2f 73 68 6f  77 72 6f 75 74 65 73 00  |sbin/showroutes.|
00000220  46 05 ff a1 00 00 0e 00  03 0c a2 53 97 57 a2 53  |F..........S.W.S|
00000230  97 57 a2 53 97 57 00 06  01 01 00 0d 0e 2e 2e 2f  |.W.S.W........./|

Das sieht schon ab Offset 0x48 wie das richtige "filesystem.image" aus, aber offenbar noch irgendwie komprimiert. Vergleicht man das mal mit einem Dump der "filesystem.image":

00000000  [COLOR="#FF0000"]73 71 73 68[/COLOR] 00 00 00 00  00 00 00 00 00 00 00 00  |sqsh............|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000500  [COLOR="#FF0000"]d8[/COLOR] 00 00 00 [COLOR="#FF0000"]b4 56[/COLOR] 00 00  00 00 00 00 [COLOR="#FF0000"]7e 07[/COLOR] 00 00  |.....V......~...|
00000510  09 00 00 00 01 00 00 00  00 00 00 00 00 00 00 00  |................|
00000520  e8 1c 00 00 e8 1c 00 00  48 00 00 00 00 00 00 00  |........H.......|
00000530  77 ab 7b 57 00 00 14 00  53 ef 01 00 00 00 00 00  |w.{W....S.......|
00000540  77 ab 7b 57 00 00 00 00  00 00 00 00 00 00 00 00  |w.{W............|
00000550  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000900  03 00 00 00 04 00 00 00  05 00 00 00 00 00 05 00  |................|
00000910  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000920  eb 1c 00 00 ec 1c 00 00  ed 1c 00 00 7e 07 02 00  |............~...|
00000930  08 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000940  d3 39 00 00 d4 39 00 00  d5 39 00 00 00 00 02 00  |.9...9...9......|
00000950  02 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000960  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000d00  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00001100  ff ff ff ff ff ff ff ff  07 ff ff ff ff ff ff ff  |................|
00001110  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00001500  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001580  ed 41 00 00 00 04 00 00  77 ab 7b 57 77 ab 7b 57  |.A......w.{Ww.{W|
00001590  77 ab 7b 57 00 00 00 00  00 00 0b 00 02 00 00 00  |w.{W............|
000015a0  00 00 00 00 00 00 00 00  0e 00 00 00 00 00 00 00  |................|
000015b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001a00  ff a1 00 00 0e 00 00 00  77 ab 7b 57 77 ab 7b 57  |........w.{Ww.{W|
00001a10  77 ab 7b 57 00 00 00 00  00 00 01 00 00 00 00 00  |w.{W............|
00001a20  00 00 00 00 00 00 00 00  2e 2e 2f 62 69 6e 2f 62  |........../bin/b|
00001a30  75 73 79 62 6f 78 00 00  00 00 00 00 00 00 00 00  |usybox..........|
00001a40  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001a80  ff a1 00 00 0e 00 00 00  77 ab 7b 57 77 ab 7b 57  |........w.{Ww.{W|
00001a90  77 ab 7b 57 00 00 00 00  00 00 01 00 00 00 00 00  |w.{W............|
00001aa0  00 00 00 00 00 00 00 00  2e 2e 2f 62 69 6e 2f 62  |........../bin/b|
00001ab0  75 73 79 62 6f 78 00 00  00 00 00 00 00 00 00 00  |usybox..........|
00001ac0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001b00  ff a1 00 00 0e 00 00 00  77 ab 7b 57 77 ab 7b 57  |........w.{Ww.{W|
00001b10  77 ab 7b 57 00 00 00 00  00 00 01 00 00 00 00 00  |w.{W............|
00001b20  00 00 00 00 00 00 00 00  2e 2e 2f 62 69 6e 2f 62  |........../bin/b|
00001b30  75 73 79 62 6f 78 00 00  00 00 00 00 00 00 00 00  |usybox..........|
00001b40  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001b80  ff a1 00 00 0e 00 00 00  77 ab 7b 57 77 ab 7b 57  |........w.{Ww.{W|
00001b90  77 ab 7b 57 00 00 00 00  00 00 01 00 00 00 00 00  |w.{W............|
00001ba0  00 00 00 00 00 00 00 00  2e 2e 2f 62 69 6e 2f 62  |........../bin/b|
00001bb0  75 73 79 62 6f 78 00 00  00 00 00 00 00 00 00 00  |usybox..........|
00001bc0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001c00  ff a1 00 00 04 00 00 00  77 ab 7b 57 77 ab 7b 57  |........w.{Ww.{W|
00001c10  77 ab 7b 57 00 00 00 00  00 00 01 00 00 00 00 00  |w.{W............|
00001c20  00 00 00 00 00 00 00 00  64 73 6c 64 00 00 00 00  |........dsld....|
00001c30  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001c80  ff a1 00 00 0e 00 00 00  77 ab 7b 57 77 ab 7b 57  |........w.{Ww.{W|
00001c90  77 ab 7b 57 00 00 00 00  00 00 01 00 00 00 00 00  |w.{W............|
00001ca0  00 00 00 00 00 00 00 00  2e 2e 2f 62 69 6e 2f 62  |........../bin/b|
00001cb0  75 73 79 62 6f 78 00 00  00 00 00 00 00 00 00 00  |usybox..........|
00001cc0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001d00  ff a1 00 00 12 00 00 00  77 ab 7b 57 77 ab 7b 57  |........w.{Ww.{W|
00001d10  77 ab 7b 57 00 00 00 00  00 00 01 00 00 00 00 00  |w.{W............|
00001d20  00 00 00 00 00 00 00 00  2f 2e 2f 73 62 69 6e 2f  |.......././sbin/|
00001d30  73 68 6f 77 72 6f 75 74  65 73 00 00 00 00 00 00  |showroutes......|
00001d40  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

fällt ja schon auf, daß die von 00 verschiedenen Bytes aus der "filesystem.image" (ich habe mal die ersten Vorkommen farblich hervorgehoben) auch in der Datensektion vorhanden sind, aber eben ohne die "Platzverschwendung", die in der ext2-Dateisystemstruktur gang und gäbe ist. Bei der grünen "fc 04"-Folge dürfte es sich um die Anzahl der 00-Bytes zwischen den beiden anderen Folgen handeln (4 Byte "sqsh" + 0x4fc Byte Nullen == 0x500 als Start des nächsten Wertes).

Nun wird sicherlich der wirklich wichtige und platzraubende Inhalt der Partition (das wäre ja die filesystem_core.squashfs) nicht so richtig gut zu komprimieren sein und damit würde wohl ein "richtiger" zusätzlicher Packer an der Stelle eher mehr als weniger Daten produzieren, wenn der noch Prüfsummen zu irgendwelchen Blöcken hinzufügt o.ä. - also wird das vermutlich irgendeine sehr simple Kompression (vielleicht ganz einfaches RLE-Encoding?) sein, die da verwendet wird.

Mal schauen, welcher Algorithmus da paßt ... vermutlich findet man sonst das Ende des Dateisystems nicht wirklich und der Kernel kommt ja wohl erst danach. Auf Anhieb hätte ich gesagt, daß der in der ".data" bei Offset 0x13d3fa0 startet, da findet sich zumindest die "Erkennung" des Kernels (81 12 ed fe + die LZMA-"Flags" 12 Byte weiter). Da der Kernel eigentlich selbst wieder komprimiert ist, macht für den auch eine zusätzliche Kompression keinen wirklichen Sinn.

Das würde dann doch eine recht erhebliche Einsparung durch die Kompression ergeben, denn die "natürliche Länge" der "filesystem.image" wären 0x15AD100 Byte und in der ".data" blieben davon nur noch 0x13CE719 - 0x48 Byte übrig (also eine Einsparung von 0x15AD100 - 0x13CE719 - 0x48 = 1960351 Byte), denn am Offset 0x13CE711 findet sich dann die Byte-Folge (b0 80 6a b7 de 1c 2a 74), mit der die "filesystem.image" endet (die sollte ja keine Checksumme am Ende haben und die Nullen sind sicherlich auch ziemlich umsonst (müßte man mal bei Recovery mitschneiden) - zumindest sollten die auch nicht "auftragen" bei der komprimierten Größe.

EDIT:
Ich würde das tatsächlich für irgendeine Abart einer RLE-Codierung halten ... finde jetzt aber keine Library, die so etwas enthalten würde - zumindest nicht in dieser Form.

Wenn ich das richtig sehe, wird immer genau 1 Byte gelesen und dessen Inhalt entscheidet dann erst einmal, was danach kommt.

Ist das direkt eine 0, macht das als Längenangabe ja keinen Sinn und so kommt danach dann ein einzelnes Byte mit der Anzahl der Nullen, die in die Ausgabe zu übernehmen sind ... damit wird diese Art der Kodierung von Nullen natürlich auf max. 255 sequentiell begrenzt.

Ist das gelesende Byte < 128, gibt es die Anzahl der Zeichen an, die im Anschluß 1:1 in die Ausgabe zu übernehmen sind.

Ist es größer als 129, gibt die Differenz zur 128 an, wie oft das nachfolgende Zeichen zu wiederholen ist.

Ist es 129, gibt das folgende 16-Bit-Feld an, wie oft das darauf folgende Zeichen zu wiederholen ist. Da wäre dann "81 fc 04 00" die Angabe für 1276 aufeinanderfolgende Nullen ... eine Angabe von "1" als Anzahl der Wiederholungen direkt macht ja auch wenig Sinn (braucht ja mehr statt weniger Platz).

Wofür eine 128 direkt steht, habe ich noch nicht herausgefunden.

Mit diesem Algorithmus müßte man sich jetzt erst einmal an die Decodierung der ersten Blöcke machen, damit man weitere - bisher nicht berücksichtigte - Kombinationen findet. Vielleicht kennt ja auch jemand einen Quellcode, der eine solche Komprimierung implementiert? Davon bräuchte man dann den Decoder. Irgendwo weiter hinten müßte es noch andere Kombinationen geben, denn im SquashFS-Image gibt es garantiert fast keine Stellen, die sich irgendwie wiederholen und wo so eine RLE dann Sinn machen würde.

EDIT2: Das klappt auch erst einmal einigermaßen ... wobei dann irgendwo mittendrin noch ein Problem existieren muß, denn ein fsck für das entstehende Image (ab Offset 256) bringt noch einiges an Fehlern zutage.

 

[PeterPawn]

113.06.60 ... warum sollte ich jetzt weiter zurück nachsehen und das ist die jüngste Recovery-Version (7490 habe ich schon weiter oben geschrieben). Deine Feststellung, daß die Versionen für 06.50 und 06.51 nicht signiert wären, kann ich nicht nachvollziehen. Vielleicht hast Du die von einer anderen Quelle ... ich habe sie vom FTP-Server von AVM (06.50 vom 08.02., 06.51 vom 17.02.) und beide sind mit demselben Zertifikat signiert, wie die 06.60.

Daß AVM jetzt mal den Schritt zu einem Zertifikat von Verisign für einen besseren Hash-Algorithmus vollzogen hat, hat damit sicherlich nichts zu tun (außer daß es vielleicht zeitgleich erfolgt, weil schon mal jemand an der Build-Umgebung dran war). Nun mag man ja die Entscheidung, sich das CodeSigning-Zertifikat von Verisign zu besorgen, geteilter Meinung sein (http://heise.de/-2864798), aber wenigstens haben die aktuellen Recovery-Versionen eine Code-Signatur. Bisher hat die m.W. nur bei einigen Versionen gefehlt, die bei Labor-Versionen (in Form von ZIP-Files) mit eingepackt waren.

 

[PeterPawn]

Anhang anzeigen 87121
Bei mir nicht ...

- - - Aktualisiert - - -

Ach so, Du hast nach dem Zertifikat des Timestamp-Services gesehen ... ich meinte schon das Zertifikat für das Signieren des Codes.

- - - Aktualisiert - - -

Ich habe mal ein kleines C-Programm begonnen, was die RLE-komprimierten Daten aus einer Recovery-Version dekodieren soll.

Das funktioniert so halbwegs, wenn man ihm die ".data"-Sektion (mit 7z entpackt) aus einer Recovery-Version als STDIN vorsetzt (ab Offset 0x48 aber erst), die Ausgabe erfolgt nach STDOUT und es wird jede Menge auf STDERR protokolliert.

Allerdings hat das erzeugte ext2-Image schon noch so seine Probleme ... das scheint auch keine 1:1-Kopie der "filesystem.image" aus dem Update-Image zu sein, wenn man sich die Daten schon am Beginn dort so ansieht. Aber das müßte man wohl mal mit Wireshark und der Ausführung des Recovery-Programm probieren und das dabei übertragene Image dann mal vergleichen. Am Ende sollte wohl aus der RLE-Dekodierung das herauskommen, was das Recovery-Programm als Dateisystem nach dem Kernel auf die Box kopiert und startet ... ich habe aber weder Zeit noch Lust, jetzt meine 7490 auf die 06.60 von AVM zu bringen.

Jedenfalls könnte das so in etwa funktionieren ... wer Lust hat, kann ja das C-Programm weiterführen. Mich hatte es nur mal interessiert, was es sein soll, das ein Auslesen der Images aus einer Recovery-Datei verhindert.

 

[stanpete78]

Mir ist gerade aufgefallen:
Mit der 6.26/AVM konnte ich in FritzOS unter Internet/Zugangsart genau wie bei den DSL Fritzboxen
einstellen, dass die Box als Router Ihre Verbindung von LAN1 bekommt. Hauptsache IP. Sehr praktische Funktion.


In meinem 6.50 fehlt diese Möglichkeit. Die setzt jetzt vorraus, dass die Box am Coax hängt.

 

[thtomate12]

In meinem 6.50 fehlt diese Möglichkeit. Die setzt jetzt vorraus, dass die Box am Coax hängt.

Welches Branding? Hing die Box seit den letzten Werkseinstellungen am Coax?

 

[stanpete78]

AVM Branding, Werksreset gemacht.
Soll aber laut fesc nur bei mir so sein.
Und nein, bisher hing sie nur am Ethernet.

 

[stanpete78]

Dein Provider hat die Box umprogrammiert. Das DVB-C Streaming geht bestimmt auch nicht mehr. Deshalb die Frage, ob die Box nach den letzten Werkseinstellungen am Coax angeschlossen wurde.

Nene, die Box hatte seit dem Update kein Internet. Da hat mniemand was aufgespielt.
Egal, ist eh ein bisschen OT. Ich prüfe das in Ruhe.

 

[Aux]

Mir ist gerade aufgefallen:
Mit der 6.26/AVM konnte ich in FritzOS unter Internet/Zugangsart genau wie bei den DSL Fritzboxen
einstellen, dass die Box als Router Ihre Verbindung von LAN1 bekommt. Hauptsache IP. Sehr praktische Funktion.


In meinem 6.50 fehlt diese Möglichkeit. Die setzt jetzt vorraus, dass die Box am Coax hängt.

Ich konnte feststellen, dass die o.g. Funktion nur bei avm branding gibt, bei lgi branding verschwindet die Funktion wieder und da muss man nicht einmal die Fritzbox zurücksetzen, die Funktion erscheint bzw. verschwindet je nach verwendeter branding gleich nach dem reboot.
Bei der OS 06.50 gibt es wahrscheinlich kein avm branding mehr und damit auch die Funktion für LAN1 nicht mehr vorhanden.
Wer also FB6490 nur als reinen Router verwenden will muss/soll (zumindest bis man keine andere Lösung findet) bei der ältere Version bleiben.

 

[tetzlav]

[...]
Bei der OS 06.50 gibt es wahrscheinlich kein avm branding mehr und damit auch die Funktion für LAN1 nicht mehr vorhanden.

Das kann ich so nicht bestätigen. Meine 6490 mit v6.50 und lgi branding hatte nach dem umstellen auf avm alle Funktionen bis auf System/Firmwareupdate. Nur mag die eben nur noch signierte image-Dateien...

 

[domzigm]

#119 der Unpacker ist schon nahe dran, aber es gibt noch zwei Opcodes mehr. http://**********com/Lcf0Z9pg (na dort wo man raw Dateien im Netz ablegt -> PB)

Die Images scheinen sich auf den ersten Blick zu unterscheiden, allerdings dürfte der Inhalt größtenteils identisch zu sein. Die Daten liegen im Image nur an anderer Stelle und die Inodes sind dementsprechend anders. Muss es bei Gelegenheit entpacken und die Dateien einzeln vergleichen.

 

[fesc]

Im entsprechenden lua code fuer die GUI steht das:

g_nochoice = config.ETH_COUNT < 2 or config.oem == 'kdg' or config.oem == 'unity' or config.oem == 'lgi'

Wenn g_nochoice gesetzt ist dann wird "standard", d.h. Kabel, gesetzt. Kann es seine dass du aus versehen lgi branding hast?

Ansonsten, der html code wenn beide buttons da sind sieht so aus:

<input type="radio" checked="" id="uiOpmode:standard" value="opmode_standard" name="opmode">
<label for="uiOpmode:standard">Internetzugang über Kabel
</label>

<input type="radio" id="uiOpmode:eth_ip" value="opmode_eth_ip" name="opmode">
<label for="uiOpmode:eth_ip">Internetzugang über LAN 1
</label>

Vielleicht kannst du das ja wieder "editieren"?

 

[muya]

Hallo,

hab eine FB 6360 mit kdg branding. Kann ich da auch telnet und AVM firmware wie bei der 6490 aktivieren?
Bin auch bei KMS und hab die Freischaltung schon beauftragt, aber keine Antwort mehr seit ich die MAC und Gerätebezeichnung mitgeteilt hab.

<j:BoxInfo><j:Name>FRITZ!Box 6360 Cable (kdg)</j:Name><j:HW>157</j:HW><j:Version>85.06.06</j:Version><j:Revision>30492</j:Revision><j:Serial>xxxx</j:Serial><j:OEM>kdg</j:OEM><j:Lang>de</j:Lang><j:Annex>Kabel</j:Annex><j:Lab/><j:Country>049</j:Country></j:BoxInfo>

gruß,

Muya

 

[PeterPawn]

es gibt noch zwei Opcodes mehr

Ich habe nicht weiter getestet ... wenn ich es richtig lese, soll 0x80 im nächsten Byte einen 8-Bit-Counter (n) haben und danach ein Zeichen, welches n-mal ausgegeben wird? Das wäre dann "fill" für Längen zwischen 127 und 255? Mit >= 0x83 kommt man ja nur von 3-127 Zeichen. Ich hatte das erste Vorkommen von 0x80 irgendwo bei 0x7aa2a9 gefunden und erst mal ignoriert, weil ich mir (im Vergleich mit den vielen Vieren in einem Dump von filesystem.image) erst einmal keinen Reim darauf machen könnte. Dann wäre also "80 a3 34" an dieser Stelle die Wiederholung von 163 Vieren in ASCII. Damit kann ja dann bei mir der weitere Verlauf nicht stimmen, denn ich hatte daraus bisher 35 Vieren gemacht ... das kam irgendwie besser hin mit meinem originalen AVM-Image. Immerhin hätte ich dann noch Glück gehabt, weil es danach wieder einen OpCode an derselben Stelle gibt.

Bei 0x82 lese ich eine Wiederholung von n Leerzeichen in der Ausgabe? Tritt bei mir das erste Mal am Offset 0x7a8957 auf (Ausgabe 0x7a3260) - mir fehlt der Vergleich zu anderen Dateien, was da stehen sollte. Womit hast Du das verglichen? Hast Du RE weiterbetrieben oder kanntest Du eine Library, die mit genau diesen OpCodes arbeitet?

Ich bin deshalb etwas erstaunt, weil das Komprimieren von 8 Leerzeichen an dieser Stelle als "82 08" jetzt nicht so viel anders ist als "88 20" und m.E. ist das Datensegment nun nicht gerade eine Umgebung, wo man mehr als 127 aufeinanderfolgende Leerzeichen erwarten würde und erst dann macht dieser spezielle OpCode ja Sinn, weil er für 128-255 Leerzeichen auch noch funktioniert und damit 2 Byte (ein weiteres "ff 20" für max. 127 Leerzeichen) spart.

Das erscheint mir irgendwie untypisch für eine eigene Implementierung von AVM und daher würde ich dann (wenn das stimmt mit 0x82, hast Du es mit "fsck" mal getestet? das stimmt, "fsck" paßt und auch die enthaltene SquashFS-Datei läßt sich entpacken, was bei falschem Payload eher nicht funktionieren würde) doch eher auf die Nachnutzung irgendeines anderen Codes tippen. Immerhin gibt man die Kodierung zweier identischer aufeinanderfolgender Zeichen als "82 xx" damit auf und müßte diese (wenn sie nicht ohnehin Bestandteil eines anderen Tupels sind) als "02 xx xx" kodieren mit 50% Overhead.

Die Behandlung von 0x00 verstehe ich irgendwie (teilweise) nicht:

            if (buffer == 0x00u)
            {
                fread_s(&l8, 1u, sizeof(uint8_t), 1u, fin);
                DBGLOG("Writing %d times (%02x) 00\n", l8, buffer);
 [COLOR="#FF0000"]               if (buffer != 0u && buffer != 0xffu)[/COLOR]
                {
                    DBGLOG("Pos: %i\n", ftell(fin));
                }
                if (l8 == 0u)
                {
                    break;
                }
                while (l8--)
                {
                    fwrite(&buffer, 1u, 1u, fout);
                }
                continue;
            }

Der komplette Abbruch bei "00 00" ist noch verständlich, aber wie sollte sich "buffer" so ändern, daß der rote Test jemals erfolgreich wird?

Wenn Du tatsächlich eine vergleichbare Kodierung (inkl. Encoder) kennen solltest, wäre ein passender Link nett.

Eigentlich bin ich davon ausgegangen, daß irgendwelche "EXE-Packer"-Komprimierungen bereits durch das Entpacken des Datensegments mit 7z Geschichte sind ... wenn ich mir Dein "main" ansehe, kann man offenbar davon ausgehen, daß da gar keine zusätzliche Kompression vorhanden ist?

Dann müßte die Größendifferenz in dieser Anzeige:

 # 7z l FRITZ.Box_7490.06.60.recover-image.exe

7-Zip [64] 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)

Listing archive: FRITZ.Box_7490.06.60.recover-image.exe

--
Path = FRITZ.Box_7490.06.60.recover-image.exe
Type = PE
CPU = x86
Characteristics = Executable 32-bit NoRelocs NoLineNums NoLocalSyms
Created = 2016-07-05 14:44:00
Physical Size = 23848920
Headers Size = 4096
Checksum = 23901332
Image Size = 23871488
Section Alignment = 4096
File Alignment = 4096
Code Size = 200704
Initialized Data Size = 23666688
Uninitialized Data Size = 0
Linker Version = 6.0
OS Version = 4.0
Image Version = 0.0
Subsystem Version = 4.0
Subsystem = Windows GUI
Stack Reserve = 1048576
Stack Commit = 4096
Heap Reserve = 1048576
Heap Commit = 4096
Image Base = 4194304

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
2016-07-05 14:44:00 .....       199613       200704  .text
2016-07-05 14:44:00 .....        64446        65536  .rdata
2016-07-05 14:44:00 .....     [COLOR="#FF0000"]23507120     23482368[/COLOR]  .data
2016-07-05 14:44:00 .....          560         4096  .sxdata
                    .....          246          232  .rsrc/BITMAP/112.bmp
                    .....          246          232  .rsrc/BITMAP/113.bmp
                    .....          246          232  .rsrc/BITMAP/114.bmp
                    .....        68054        68040  .rsrc/BITMAP/115.bmp
                    .....         1206         1192  .rsrc/BITMAP/261.bmp
                    .....         1206         1192  .rsrc/BITMAP/262.bmp
                    .....         1206         1192  .rsrc/BITMAP/263.bmp
                    .....         1206         1192  .rsrc/BITMAP/264.bmp
                    .....         1206         1192  .rsrc/BITMAP/265.bmp
                    .....         1206         1192  .rsrc/BITMAP/266.bmp
                    .....         1206         1192  .rsrc/BITMAP/267.bmp
                    .....         1206         1192  .rsrc/BITMAP/268.bmp
                    .....         1206         1192  .rsrc/BITMAP/269.bmp
                    .....          766          744  .rsrc/ICON/1.ico
                    .....          260          260  .rsrc/DIALOG/117
                    .....          216          216  .rsrc/DIALOG/118
                    .....          138          138  .rsrc/DIALOG/119
                    .....          138          138  .rsrc/DIALOG/120
                    .....          138          138  .rsrc/DIALOG/121
                    .....          530          530  .rsrc/DIALOG/122
                    .....          220          220  .rsrc/DIALOG/123
                    .....           20           20  .rsrc/GROUP_ICON/100
                    .....          744          744  .rsrc/VERSION/1
2016-07-05 14:44:00 .....         6104         6104  CERTIFICATE
------------------- ----- ------------ ------------  ------------------------
                              23860659     23841420  28 files, 0 folders

an irgendeiner Stelle vorhanden sein (am Beginn oder am Ende), wo es für das enthaltene Image keine Rolle mehr spielt.

EDIT: Ne, ich sehe gerade, daß 7z da eine 1:1-Kopie in der "compressed"-Größe ausgibt, dann ist das auch klar, warum es direkt mit dem Executable funktioniert.

EDIT2: Ja, mit den zusätzlichen OpCodes ist das Image dann auch benutzbar. Bleibt die Suche nach dem Kernel im Datensegment und nach ggf. dort ebenfalls liegenden Urlader-Images.

EDIT3: Ich habe die zusätzlichen OpCodes in das C-Programm eingearbeitet ... C++ ist zwar auch nett, aber in Freetz ist vieles eben doch in "purem C" und vermutlich gehört das Extrahieren von Daten aus den Recovery-Programmen am ehesten dorthin. Ich bin auch beim "linux filter" geblieben, weil es ja noch andere RLE-codierte Bereiche geben kann und nicht nur das SquashFS-Image aus der Recovery-Version benötigt wird. Das Suchen des richtigen Anfangs macht sich dann mit Shell-Kommandos "außen herum" wieder besser.

 

[stanpete78]

Leute, das ist jetzt echt unangenehm. Werksreset setzt die Ansicht auf Standard zurück und da gibt es die Auswahl seltsamerweise nicht.

 

[PeterPawn]

@stanpete78:
LOL ... ich wollte das schon vorschlagen, habe dann aber bei mir getestet und da war (allerdings bei einer Box, die tatsächlich schon mal auf LAN1 stand und erst auf Kabel zurückgestellt wurde) dann der Punkt auch in der Standard-Ansicht vorhanden:
Anhang anzeigen 87126

 

[domzigm]

@opto - Ich wollte niemandem mit dem Link auf die Füße treten, einige Mods sind da sehr ... Ich meinte das Firmware image (*.image) und das extrahierte Image aus dem Recovery Tool.
@PeterPawn - Meine Vermutung war, dass die Leute bei AVM genauso faul sind wie ich und daher etwas vorhandenes genommen haben. Eine kurze Suche nach "rle 0x80" hat zwar einige Ergebnisse zu Tage gebracht, aber nichts was ich als offizielle, gepflegte Library interpretieren würde. Durch das wiederkehrende Muster (0x80, 0x7f etc.) war es leicht den Dump aus der data section mit dem original Image zu vergleichen (Beyond Compare). MP3 hat ja einen ähnlichen Aufbau mit den Sync Bytes. Die rot markierte Stelle ist ein copy+paste Fehler...

Mir ist eben noch eingefallen das in der Datasection mehrere sqsh tags vorkamen, darum auch das Offset. Hab noch nicht probiert ob sich das auch extrahieren lässt.

 

[por]

Leute, das ist jetzt echt unangenehm. Werksreset setzt die Ansicht auf Standard zurück und da gibt es die Auswahl seltsamerweise nicht.

Not even at http://192.168.178.1/internet/internet_settings.lua ?
This page is available on the 6490 with 6.26.

 

[Aux]

Gestern hatte ich mich entschieden die FritzBox 6490 (lgi branding) bei UM anzumelden, am Telefon wurde ich nach Aufnahme den Daten (CM MAC und SNR) informiert, dass es zu 2 Tagen dauern kann bis es freigeschaltet wird, es hatte jedoch weniger wie eine Stunde gedauert und ich konnte die Box an das Kabel anschließen, da wurde ich positiv überrascht. Nach neustart alles vorhanden, lediglich die SIP Daten musste ich im Kundencenter abrufen um das Tel. einzurichten.
Bis jetzt wurde die Box noch nicht mit neuen FritzOS upgedatet es läuft alles noch mit OS 06.26. Ich hatte danach das branding auf avm umgebrandet die Box zeigte das alles i.O. ist das speed wurde anders erkannt und zwar 136/6.3Mbit anstatt 120/6 das Problem war aber, dass es keine DNS Abfragen mehr statt fand und damit kein surfen möglich. Aktuell habe ich wieder lgi branding, ich weiß nicht was passieren würde, wenn nach dem ich das branding auf avm umstellte die Box zurücksetzen würde. Das hatte ich nicht probiert.

 

[informerex]

Das hatte ich nicht probiert.

vielleicht mal testen
bevor alles fertig eingerichtet hast