[gelöst] filesystem.image einer Fritzbox SL bearbeiten

joha.ma

Neuer User
Mitglied seit
9 Apr 2007
Beiträge
13
Punkte für Reaktionen
0
Punkte
1
Hallo

Ich möchte einige Dateien in die Firmware meiner Fritzbox SL integrieren. Dazu bin ich wie hier beschrieben vorgegangen. Ich habe ds-0.2.9-opensrc-04.06.tar.bz2 verwendet. Allerdings lässt sich filesystem.image nicht öffnen:
Code:
a184098:~/Desktop/ds-0.2.9-opensrc-04.06/ds-0.2.9/tools> ./unsquashfs -dest build/root/ build/firmware/var/tmp/filesystem.image
Can't find a SQUASHFS superblock on build/firmware/var/tmp/filesystem.image

Was kann ich tun?
 
Zuletzt bearbeitet:
Such mal nach der Zeilenfolge "hsqs". Sowohl im filesystem.image als auch im kernel.image. Dort fängt das squashfs an.

MfG Oliver
 
Dateisystem der Fritz!Box SL (Contiguous SquashFS) entpacken

Genau, Oliver. Etwas knapp vielleicht für Einsteiger, denn Danisahnes Thread, nach dem Joha vorgegangen ist, geht auf eine Besonderheit hier nicht ein:

Die SL ist ein Spezialfall, da sie Contiguous SquashFS verwendet, d.h. das Firmware-Layout bzgl. der mtd-Partitionen sieht so aus:

software:ds-mod:development:flash_7050_contiguous.png


Die Zahlen stimmen nicht, denn sie stammen von einer 4-MB-Box, die SL hat ja nur 2 MB. Das Prinzip ist aber gleich: Dein SquashFS verteilt sich auf beide Image-Dateien. Die Werkzeuge find-squashfs und unsquashfs gehen aber von einem kompletten SquashFS innerhalb einer Datei aus. Das kannst Du ihnen geben, indem Du einfach sowas wie
Code:
$ cat kernel.image filesystem.image > compound.image
aufrufst und auf der neuen Datei dann die beiden Programme werkeln läßt. Siehe da, Dein Dateisystem wird gefunden und sauber entpackt!

Nachdem Du Deine Modifikationen gemacht hast, packst Du nach Anleitung das SquashFS wieder zusammen und klebst es an das kernel.raw, welches Du Dir vom Entpackvorgang noch aufgehoben hast:
Code:
$ cat kernel.raw my_modified_squashfs > compound.image
Jetzt bleibt nur noch, das Compound-Image (welches hoffentlich die Maximalgröße nicht überschreitet) wieder so zu zersäbeln, daß der erste Teil genauso groß ist wie das ursprüngliche kernel.image (in der SL-FW, die ich mir gerade angesehen habe, genau 640 KB oder 655.360 Bytes), welches es nun ersetzt. Die zweite Hälfte ist dann Dein filesystem.image und ersetzt ebenfalls die entsprechende Datei aus dem Original-FW-Image. Da der split-Befehl drei Teile aus dem Compound-Image macht, muß man die letzten beiden eben wieder zusammenfügen - statt cat hätte man auch join nehmen können - aber was soll's?
Code:
$ split -d -b 640k compound.image part-
$ ls -l part-*

-rw-r--r-- 1 ubuntu ubuntu 655360 2007-04-18 05:06 part-00
-rw-r--r-- 1 ubuntu ubuntu 655360 2007-04-18 05:06 part-01
-rw-r--r-- 1 ubuntu ubuntu 649216 2007-04-18 05:06 part-02

$ mv part-00 kernel.image
$ cat part-01 part-02 > filesystem.image
$ ls -l *.image

-rw-r--r-- 1 ubuntu ubuntu 1304576 2007-04-18 05:07 filesystem.image
-rw-r--r-- 1 ubuntu ubuntu  655360 2007-04-18 05:07 kernel.image
Tadaa! Der Rest ist ja dann wieder bei Danisahne beschrieben.
 
Zuletzt bearbeitet:
Ich kann mit find-squashfs eine kernelsquashfs erzeugen. Aber unsquashfs bringt mir einen Fehler:
Code:
 #./unsquashfs
SYNTAX: ./unsquashfs [-ls | -dest] filesystem
        -version                print version, licence and copyright information
        -info                   print files as they are unsquashed
        -ls                     list filesystem only
        -dest <pathname>        unsquash to <pathname>, default "squashfs-root"
# ./unsquashfs -ls kernelsquashfs.raw
*** glibc detected *** ./unsquashfs: free(): invalid next size (normal): 0x080dea00 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7e02911]
/lib/libc.so.6(__libc_free+0x84)[0xb7e03f84]
/lib/libz.so.1(zcfree+0x1d)[0xb7ec718d]
/lib/libz.so.1(inflateEnd+0x53)[0xb7ec7463]
/lib/libz.so.1(uncompress+0xa7)[0xb7ec2a87]
./unsquashfs[0x804b2e1]
./unsquashfs[0x804b421]
./unsquashfs[0x804bcf1]
/lib/libc.so.6(__libc_start_main+0xdc)[0xb7db487c]
./unsquashfs[0x8048ad1]
======= Memory map: ========
08048000-0804d000 r-xp 00000000 03:43 4240       /home/johannes/Desktop/Fritzbox/ds/ds-0.2.9-opensrc-04.06/ds-0.2.9/tools/unsquashfs
0804d000-0804e000 rw-p 00004000 03:43 4240       /home/johannes/Desktop/Fritzbox/ds/ds-0.2.9-opensrc-04.06/ds-0.2.9/tools/unsquashfs
0804e000-080f3000 rw-p 0804e000 00:00 0          [heap]
b7c00000-b7c21000 rw-p b7c00000 00:00 0
b7c21000-b7d00000 ---p b7c21000 00:00 0
b7d93000-b7d9d000 r-xp 00000000 03:42 17654      /lib/libgcc_s.so.1
b7d9d000-b7d9e000 rw-p 00009000 03:42 17654      /lib/libgcc_s.so.1
b7d9e000-b7d9f000 rw-p b7d9e000 00:00 0
b7d9f000-b7eb8000 r-xp 00000000 03:42 13939      /lib/libc-2.4.so
b7eb8000-b7eba000 r--p 00118000 03:42 13939      /lib/libc-2.4.so
b7eba000-b7ebc000 rw-p 0011a000 03:42 13939      /lib/libc-2.4.so
b7ebc000-b7ebf000 rw-p b7ebc000 00:00 0
b7ebf000-b7ed0000 r-xp 00000000 03:42 18065      /lib/libz.so.1.2.3
b7ed0000-b7ed1000 rw-p 00010000 03:42 18065      /lib/libz.so.1.2.3
b7ed1000-b7ed2000 rw-p b7ed1000 00:00 0
b7ee7000-b7f01000 r-xp 00000000 03:42 13932      /lib/ld-2.4.so
b7f01000-b7f03000 rw-p 00019000 03:42 13932      /lib/ld-2.4.so
bfd09000-bfd1f000 rw-p bfd09000 00:00 0          [stack]
ffffe000-fffff000 ---p 00000000 00:00 0          [vdso]
Aborted

Ich vermute, das das mit den Meldungen zutun hat, die mir make tools liefert:

Code:
g++ -O3 -Wall -c ZLib.cpp
../../../Common/MyWindows.h:120: warning: ‘struct IUnknown’ has virtual functions but non-virtual destructor
../LZMA/../../IStream.h:14: warning: ‘struct ISequentialInStream’ has virtual functions but non-virtual destructor
../LZMA/../../IStream.h:32: warning: ‘struct ISequentialOutStream’ has virtual functions but non-virtual destructor
../LZMA/../../IStream.h:43: warning: ‘struct IInStream’ has virtual functions but non-virtual destructor
So geht das noch lange weiter. c++ und zlib-devel hab ich installiert. Ich benutze OpenSuse 10.1
 
Welchen Mod nimmst Du?
 
Ich habe ds-0.2.9-opensrc-04.06.tar.bz2 benutzt.

Ich habe mir jetzt squashfs3.2.tgz von sourceforge runtergeladen und daraus die squashfs-tools erstellt. make läuft ohne Fehler durch, aber unsquashfs bringt genau den gleichen Fehler. Ich sollte mir wohl ein anderes Linux zulegen.
 
Ich habe einfach den DS-Mod, genauer ds26-14.3 (heute neu, kann aber auch etwas älter sein), genommen und ausgepackt, dort dann make tools gemacht und die Tools von dort genommen. Ob die Versionen identisch mit Deinen sind, kann ich nicht sagen.

Edit: Außerdem würde ich gern noch die Firmware-Version wissen, die Du zerlegen wolltest. Ich habe das fritz.box_sl.10.03.94.image von der AVM-FTP-Seite benutzt.
 
Das funktioniert gar nicht:

johannes@a184098:~/Desktop/Fritzbox/ds/ds26-14.3/ds26-14.3> make tools
make: *** Keine Regel vorhanden, um das Target »dl/busybox-1.4.1.tar.bz2«,
benötigt von »source/busybox-host/.unpacked«, zu erstellen. Schluss.

Ich wollte fritz.box_sl.10.03.94.image benutzen.
 
Erst mal make menuconfig und einmal die Konfiguration speichern.
 
Muss ich da irgendwas einstellen? Einfach make menuconfig und dann speichern nützt nichts.
 
Lad dir die Datei "busybox-1.4.1.tar.bz2" runter und pack sie nach dl/. Ich weiß wo der Fehler herkommt, aber ich weiß nicht warum er kommt...

MfG Oliver
 
Jetzt findet er beim patchen die Dateien nicht, deshalb hab ich die Patches überspringen lassen. Anschließend wieder das gleiche Problem, unsquashfs bricht beim Auspacken von kernelsquashfs.raw (aus fritz.box_sl.10.03.94.image erstellt) mit der oben genannten Fehlermeldung ab.

Ich habe versuchsweise einige Dateien mit mksquashfs eingepackt, eine Checksum angefügt und wieder mit unsquashfs ausgepackt. Das ging problemlos.
 
Zuletzt bearbeitet:
Nur zur Sicherheit: Mein unsquash_fbox_sl.sh sieht so aus (erster Parameter ist FW-Image, DS_MOD_DIR ist anzupassen):
Code:
#! /bin/bash

DS_MOD_DIR="/home/ubuntu/ds/0.2.9_26"
TOOLS_DIR="$DS_MOD_DIR/tools"

KERNEL_IMAGE="$1"

TARGET_DIR="unsquash"
rm -rf "$TARGET_DIR"

UNTAR_DIR="untar"
rm -rf "$UNTAR_DIR"
mkdir "$UNTAR_DIR"

tar -C "$UNTAR_DIR" -xvf "$KERNEL_IMAGE"
"$TOOLS_DIR/rmtichksum" -f "$UNTAR_DIR/var/tmp/filesystem.image"
"$TOOLS_DIR/rmtichksum" -f "$UNTAR_DIR/var/tmp/kernel.image"
cat "$UNTAR_DIR/var/tmp/kernel.image" "$UNTAR_DIR/var/tmp/filesystem.image" > compound.image
#rm -rf "$UNTAR_DIR"
"$TOOLS_DIR/find-squashfs" compound.image
"$TOOLS_DIR/unsquashfs" -dest "$TARGET_DIR" kernelsquashfs.raw
"$TOOLS_DIR/unsquashfs" -ls kernelsquashfs.raw
#rm -f kernelsq*.raw
 
Alles klar.

Habe nicht gewusst, das ich die Prüfsumme von kernel.image entfernen muss.

Jetzt gehts, vielen Dank
 
(War doch der richtige Thread, nur hattest Du inzwischen das Problem für gelöst erklärt. Trotzdem die nachgeschobene Erklärung für das Make-Problem...)

joha.ma schrieb:
Jetzt findet er beim patchen die Dateien nicht, deshalb hab ich die Patches überspringen lassen.

Du hast wahrscheinlich kein make menuconfig gemacht oder nicht gespeichert. Zum Nachvollziehen nochmal komplett:
Code:
tar xvjf ds26-14.3.tar.bz2 
cd ds26-14.3
make menuconfig   # dann speichern, ändern mußt Du nichts
make dl
# jetzt busybox-Archiv nach dl kopieren, z.B. 
cp ../dl/busybox-1.4.1.tar.bz2 dl
make tools
Inzwischen habe ich auch herausgefunden, weshalb es das Problem überhaupt gibt. Die Ursache liegt in der Tatsache, daß Busybox 2x gebraucht wird für DS-Mod, aber nur ein Make-Target existieren darf, welches das Archiv nach dl lädt, weil es sonst eine Make-Warnung gibt. Deshalb ist das Target in tools/make/busybox-tools.mk auskommentiert. Das macht normalerweise nichts, da die meisten ja den Mod bauen und sowieso nach make menuconfig ein make precompiled machen. Dadurch wird das andere Makefile-Include für die Busybox auf der Fritz!Box angezogen. welches das Download-Target enthält und auch die Tools damit versorgt. Wenn jetzt aber nur die Tools gebaut werden direkt mit make tools, dann gibt es Probleme. Das werde ich entsprechend sauberer gestalten in Zukunft, ich weiß auch schon, wie. Im Moment funktioniert der Workaround wie oben gezeigt.

Ich hoffe, das war jetzt nicht zu kompliziert erklärt. Genauer würde auch mehr Text beanspruchen...
 
Zuletzt bearbeitet:
da hat bei mir das make dl gefehlt.
 
Zuletzt bearbeitet:
Oder einfach mkdir dl, wenn man deswegen nicht gleich Make aufrufen möchte. War etwas überkorrekt von mir. Geht beides, Hauptsache, das Verzeichnis und das Busybox-Quellcode-Archiv sind da.

Edit als Antwort auf Deinen Edit (den Du jetzt - Edit 2) nach unten in ein neues Posting verschoben hast: Eine Liste nicht, aber einen neuen Wiki-Artikel von mir mit allgemeinen Überlegungen und Hinweisen zum Thema Platz sparen im Dateisystem der Fritz!Box.
 
Zuletzt bearbeitet:
Wo finde ich eine Auflistung, was man alles aus der Firmware rausschmeissen kann?
Der Speicherplatz auf der FritzBox SL ist ja sehr begrenzt.
 
Hallo,
ich weiß, daß dieser Thread hier schon ewig alt ist, aber er trifft nun einmal genau mein Thema und war deshalb auch die Anleitung für meine bisherigen Versuche.

Mein Vorhaben ist es, meinen Rechner von überall auf der Welt über wol aufwecken, auf meinen FTP-Server zugreifen, Daten hoch- und runterladen und ihn dann über SSH wieder herunterfahren zu können. Das war alles eigentlich viel einfacher als ich dachte und funktioniert mittlerweile auch wunderbar, bis auf eine Kleinigkeit eben:

Meine Fritzbox SL weigert sich Ports an den Broadcast weiterzuleiten, weshalb ich das Zauberpaket direkt an meinen Rechner senden muß. Wenn dieser allerdings länger als eine Stunde aus war, löscht die Fritzbox den Arp-Cache und hat keine Ahnung mehr welche MAC-Adresse meine Netzwerkkarte habe, was wiederum dazu führt, daß dieser nichts zugestellt wird und mein Rechner weiter schläft.

Leider steht nun aber der arp-Befehl, mit dem man statische Arp-Einträge vornehmen kann, in meiner Busybox nicht zur Verfügung und kann auch nicht ständig über wget nachgeladen werden, da dies ebenfalls nicht drauf ist. Die einzige Möglichkeit Daten auf meine Box zu laden ist die Firmware-Update-Variante, die aber das Squash-Dateisystem nicht beschreiben kann (oder doch?), oder tftp, was wegfällt, da ich keinen öffentlichen tftp-Server kenne, von dem man bei jedem Neustart die Busybox mit dem arp-Bewfehl nachladen könnte.

Deswegen kam ich nun zu dem Schluß, daß die einzige Möglichkeit sei, das 10.03.94-Image zu modifizieren und die Arp-Busybox in das Squash-Dateisystem einzubauen. Wenn ich damit falsch liege und es einen einfacheren Weg gibt, fände ich das natürlich toll (deswegen schrieb ich auch die ganze Vorgeschichte).

Nun also zum Thread-Thema:

Ich versuchte mich an die Anleitung, die danisahne hier zur Verfügung stellte, zu halten und dabei die Abweichungen für die 2MB-SL Box aus diesem Thread zu berücksichtigen. Resultat sind diese beiden Skripte:

squash_sl:
Code:
#! /bin/bash

TOOLS_DIR="./werkz"
TARGET_DIR="unsquash"
UNTAR_DIR="untar"

"$TOOLS_DIR/mksquashfs_alt" "$TARGET_DIR" filesystem.image -b 65536 -noappend -all-root
cat kernel.raw filesystem.image > alles.image
split -d -b 640k alles.image teil-
mv teil-00 "$UNTAR_DIR/var/tmp/kernel.image"
cat teil-01 teil-02 > "$UNTAR_DIR/var/tmp/filesystem.image"
"$TOOLS_DIR/tichksum" "$UNTAR_DIR/var/tmp/filesystem.image"
"$TOOLS_DIR/tichksum" "$UNTAR_DIR/var/tmp/kernel.image"
"$TOOLS_DIR/tar" -C "$UNTAR_DIR/" -cf - --owner=0 --group=0 --mode=0755 --format=oldgnu . > neue_firmware.image
rm -rf unsquash untar alles.image filesystem.image kernel.raw kernelsquashfs.raw teil-*

unsquash_sl (ist zum größten Teil von kriegaex übernommen):
Code:
#! /bin/bash

TOOLS_DIR="./werkz"

KERNEL_IMAGE="$1"

TARGET_DIR="unsquash"
rm -rf "$TARGET_DIR"

UNTAR_DIR="untar"
rm -rf "$UNTAR_DIR"
mkdir "$UNTAR_DIR"

"$TOOLS_DIR/tar" -C "$UNTAR_DIR" -xvf "$KERNEL_IMAGE"
"$TOOLS_DIR/rmtichksum" -f "$UNTAR_DIR/var/tmp/filesystem.image"
"$TOOLS_DIR/rmtichksum" -f "$UNTAR_DIR/var/tmp/kernel.image"
cat "$UNTAR_DIR/var/tmp/kernel.image" "$UNTAR_DIR/var/tmp/filesystem.image" > alles.image
#rm -rf "$UNTAR_DIR"
"$TOOLS_DIR/find-squashfs" alles.image
"$TOOLS_DIR/unsquashfs" -dest "$TARGET_DIR" kernelsquashfs.raw
"$TOOLS_DIR/unsquashfs" -ls kernelsquashfs.raw
#rm -f kernelsq*.raw

mksquashfs, unsquashfs, tichksum, tar und eigentlich alles bis auf cat klaute ich mir aus dem danisahne-mod (ds26-14.3), den kriegaex hier auch schon erwähnte. Es funktioniert auch eigentlich fast alles, wie es soll: das Image wird mit unsquash_sl entpackt und kann mit squash_sl wieder eingepackt werden (und dann auch wieder entpackt, es sollte also nicht korrupt sein). Vorerst fügte ich noch keine Datein hinzu, um auf Nummer sicher zu gehen. Dabei fiel mir auf, daß die neugepackte Version immer ca 70KB kleiner ist als die originale und tatsächlich kommt meine Fritzbox mit dem Resultat nicht klar: Sie blinkt ewig und dann brennt nur noch die Power-Lampe. Danach ist sie zu nichts mehr zu gebrauchen...

Ist irgendetwas an den Skripten verkehrt?
Hat jemand eine andere Idee, wie ich mein Ziel erreichen kann?
Irgendein Tipp?

Ich sitze jetzt schon ein paar Tage an dieser Kleinigkeit und möchte irgendwie mal fertig werden...

Danke im Voraus!
 
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.