[Gelöst] NAND-Boxen: Filesystem.image aus Dump erstellen

[Regdone]

Hallo,

ich möchte gern aus einer laufenden NAND-Box ein Firmwareimage zum Flashen (per EVA) erstellen. Bei NOR-Boxen war das ja simpel, einfach kernel.image aus mtd1 auslesen und bei Bedarf wieder dort einspielen, da ja dort neben dem eigentlichen kernel.image auch das Filesystem.image enthalten war.
Bei NAND-Boxen komm ich nicht recht weiter, ich habe schon Stunden mit der Suche im Forum und im Netz verbracht, jedoch außer "das geht ganz einfach" nichts konkretes gefunden. Vielleicht kann mir jemand etwas auf die Sprünge helfen.

Was habe ich bisher versucht?
Meine Versuchsbox, eine 7412, per Telnet ausgelesen. Kernel.image aus mtd0 (bzw. mtd2) mit Telnet über cat /dev/mtd0 ausgelesen, per FTP aus der Box geschleußt, per HEX-Editor die überflüssigen "Auffüllbits" abgeschnitten. Funktioniert, Kernel.image in gestripptes Originalimage eingepackt (per Freetz im No-Freetz-Modus) und gefasht. Klappt.
Filesystem aus mtd1 (bzw. mtd3) per Telnet ausgelesen (sowohl mtd1, als auch blockweise über mtdblock1) und wieder per FTP aus der Box geschleußt.
Nun scheitere ich aber. Ich habe den Dump mittels Hexeditor geöffnet und angesehen. IMHO sollte doch hier das Filesystem.image enthalten sein, oder nicht? Die erhaltene Datei beginnt mit
00 00 00 03 00 00 00 01 FF FF 62 69 6E 00 00 00 (IMHO Füllzeichen und dann BIN)
Ich habe daraufhin im Dump nach der Zeichenfolge 73 71 73 68 (sqsh) gesucht und alles vorher abgeschnitten. Auch die Füllzeichen am Ende der Datei habe ich entfernt.
So bekomme ich eine Datei, von der ich meinte, es könnte sich um das Filesystem.image handeln. Leider ist das eine Fehleinschätzung gewesen. Während sich das originale, aus der Firmwaredatei entpackte Filesystem.image natürlich entpacken läßt und das Filesystem freigibt, ist das bei meiner Datei nicht der Fall, sie enthält kein Archiv. Entpackungsversuch mit 7-Zip sagt z.B. "Es wurde versucht, den Dateizeiger vor den Anfang der Datei zu bewegen", also die Fehlermeldung, die bei zerstörten Archiven kommt.
Wo liegt mein Fehler? Was habe ich hier noch nicht verstanden? Vielleicht kann mir jemand auf die Sprünge helfen, vielleicht hab ich auch nur mit den falschen Begriffen gesucht?

 

[PeterPawn]

Die 7412 verwendet als Root-Dateisystem ein SquashFS-Image, das in einer YAFFS2-Partition liegt. Dieses Image hört auf den Namen "filesystem_core.squashfs" (aus dem Gedächtnis, ohne Garantie).

Das YAFFS2-Dateisystem enthält noch ein paar andere (wenige) Dateien, dieses ist auch das FS, was beim Linux-Start als "root" angegeben/angesehen wird - das Umschalten auf das SquashFS-Image erfolgt erst im Rahmen der Initialisierung des Systems durch "pivot_root".

Wer hier also einen Dump einer MTD-Partition erstellt, ist per se schon auf dem Holzweg - das YAFFS2-Format ist ein spezialisiertes Dateisystemformat für NAND-Flash. Deshalb enthalten die originalen Firmware-Images (bei den VR9-Boxen mit NAND-Flash) an dieser Stelle auch ein "ext2"-Image, welches den Inhalt ebendieser YAFFS2-Partition (also inkl. des SquashFS-Images für das später verwendete "rootfs") umfaßt.

Und jetzt kommt dann noch eine Besonderheit dazu, die dem Flash-Parser im Kernel geschuldet ist bzw. die man dort nachlesen kann ... vor diesem "ext2"-Image stehen noch 256 Byte als Dummy-Header mit einer "sqsh"-Signatur (und da der Rest dann Nullen sind, mit einer SquashFS-Version 0:0).

Ansonsten kann man sich hier: https://github.com/PeterPawn/YourFritz/tree/master/toolbox ansehen, wie man ein komplettes Firmware-Image für eine 7412 erzeugen kann - ich hatte zugegebenermaßen bisher die Hoffnung, daß man das tatsächlich finden könnte.

Aber irgendwie erschien (und erscheint) mir auch die Überlegung logisch, daß ja eine modifizierte Firmware (so, wie man sie z.B. mittels Freetz erzeugen kann) auch mit diesem Format arbeiten müßte ... ICH hätte da tatsächlich in dieser Richtung gesucht (und wäre natürlich auch fündig geworden).

Hast Du Dich bei Deiner stundenlangen Suche (Zitat) vielleicht doch eher verrannt?

 

[Regdone]

Hallo PeterPawn,

Hast Du Dich bei Deiner stundenlangen Suche (Zitat) vielleicht doch eher verrannt?

ja, Du hast recht, auch ich vermute, daß ich mich verrannt habe, deshalb ja meine Frage, weil ich selbst keine Lösung gefunden habe.
Deinen Ausführungen entnehm ich nun, daß man das einmal auf einer Box laufende System bei NAND-Boxen nicht sichern und später wieder einspielen kann? Ich hatte das u.a. in dem Thread https://www.ip-phone-forum.de/threads/1und1-kabel-modem-fritzbox-7412-wireless-aktivieren.282779 so verstanden, daß das funktioniert, speziell auch Dein Post #104 wo Du schriebst, das System vorher gesichert zu haben. Ich dachte sichern = mögliches Zurückspielen.

Die 7412 verwendet als Root-Dateisystem ein SquashFS-Image, das in einer YAFFS2-Partition liegt. Dieses Image hört auf den Namen "filesystem_core.squashfs"

Wenn ich das Original-Image entpacke, finde ich im Ordner "var" "tmp" die Dateien kernel.image und filesystem.image. Die kernel.image entspricht exakt dem, was ich aus der mtd sichern kann. Die filesystem.image (SquashFS) läßt sich weiter entpacken, ich erhalte dann einen Verzeichnisbaum und die von Dir angesprochene filesystem_core.squashfs mit dem Filesystem, welches auf der Box tatsächlich läuft.

Wer hier also einen Dump einer MTD-Partition erstellt, ist per se schon auf dem Holzweg

Ich hatte das eigentlich so verstanden, daß bei NAND-Boxen Kernel und Filesystem in den Partitionen mtd0 und mtd1 (resp. mtd2 und mtd3) liegen und beim Booten in den RAM der Box entpackt werden mit dem Inhalt der filesystem.image bzw. der filesystem_core.squashfs und ich diese in einer mtd finde.

Also ist es zusammengefaßt Quatsch, was ich machen möchte?

 

[PeterPawn]

Quatsch, was ich machen möchte?

Ne, warum?

Einfach den kompletten Inhalt (nicht die Struktur, wie es bei einem Partition-Dump der Fall ist) der YAFFS2-Partition (die kann man ja r/o mounten bzw. sie ist im aktiven System (für ebendieses jedenfalls) bereits unter "/wrapper" gemountet) in ein "ext2"-Image kopieren und den erwähnten Dummy-Header davorsetzen. Fertig ist eine "filesystem.image", die man zusammen mit der passenden "kernel.image" (da funktioniert der Dump der MTD-Partition wieder) in einem bootfähigen Image (über EVA) verwenden kann.

Hast Du tatsächlich nach meinen Hinweisen auf die zwei Quellen (die mir aus dem Stand eingefallen sind, es gibt garantiert noch mehr) dort einmal nachgelesen?

Wenn Du schreibst:

Die filesystem.image (SquashFS) läßt sich weiter entpacken

, dann verwendest Du offenbar ein ur-ur-uraltes Image, was ohnehin noch mit einem SquashFS3-Image arbeitet.

Da gab es halt den Dummy-Header nicht (den brauchte es ja auch nicht, weil das "wrapper filesystem" dort bereits ein SquashFS-Image war) und es wurde ein anderes Komprimierungsformat (iirc war es "gzip") verwendet für das SquashFS3-Format ("lzma" kam damals nur bei den NOR-Boxen zum Einsatz, die NAND-Boxen hatten genug Spielraum im Flash) - wobei der Filesystem-Treiber (wieder aus dem Gedächtnis, ich hatte es aber wohl auch mal hier irgendwo niedergeschrieben) im alten Kernel auch mit LZMA-Komprimierung umgehen konnte (es war praktisch derselbe wie in den NOR-Modellen, die ja LZMA verwendeten).

Hättest Du das etwas genauer in #1 geschildert, hätte man auch gleich gewußt, daß Du mit einer Version < 06.50 unterwegs bist und Dich darauf hinweisen können (auch wenn das ebenfalls wieder - allerdings zum damaligen Zeitpunkt, als bei AVM der Übergang von der 06.3x zur 06.5x erfolgte - laaaang und breeeiiit durchgekaut wurde in diesem Board), daß damals noch ein anderes Format verwendet wurde.

Wobei hier dann ähnliches gilt, wie das oben Geschriebene ... nur wird eben aus dem "ext2"-Image mit dem Dummy-Header dann gleich ein SquashFS3-Image mit passenden Einstellungen - fertig ist die Laube.

Zu der genaueren Schilderung in #1 hätte ich mir halt auch noch gewünscht (obwohl Du vieles schon richtig gemacht hast), daß Du uns daran teilhaben läßt, welche Suchbegriffe denn bei Deiner stundenlangen Recherche (hier im Board und im Internet allgemein) zu keinem hilfreichen Ergebnis führten ... und sei es nur, damit künftige Leser dieses Threads dann andere Begriffe verwenden für ihre eigene Suche.

 

[Regdone]

Hallo Peter Pawn,

Einfach den kompletten Inhalt (nicht die Struktur, wie es bei einem Partition-Dump der Fall ist) der YAFFS2-Partition (die kann man ja r/o mounten bzw. sie ist im aktiven System (für ebendieses jedenfalls) bereits unter "/wrapper" gemountet) in ein "ext2"-Image kopieren und den erwähnten Dummy-Header davorsetzen. Fertig ist eine "filesystem.image", die man zusammen mit der passenden "kernel.image" (da funktioniert der Dump der MTD-Partition wieder) in einem bootfähigen Image (über EVA) verwenden kann.

danke für die Antwort, ich hoffe, damit komm ich ein Stück weiter.

Hast Du tatsächlich nach meinen Hinweisen auf die zwei Quellen (die mir aus dem Stand eingefallen sind, es gibt garantiert noch mehr) dort einmal nachgelesen?

Noch nicht. 2 Quellen? Ich hab nur Deinen Github-Link als Hinweis zum Bau des Images gesehen. Aber nur kurz hineingesehen, die Zeit fehlte gerade noch, hol ich aber nach.

dann verwendest Du offenbar ein ur-ur-uraltes Image, was ohnehin noch mit einem SquashFS3-Image arbeitet.

Hab mit 6.30 und dem aktuellstem 6.86 experimentiert. Da ist das betreffende bei beiden identisch, wenn ich das originale AVM-Image entpacke. Das von mir geschriebene paßt auf beide. Ein 7.x gibt es ja offiziell nicht für die 7412. Ich hab zwar eines der 7430 angepaßt aber nur zum Experimentieren und lernen, da es keinen WLAN-Treiber gibt und die LEDs hardwaremäßig anders belegt sind. Aber das ist ein anderes Thema...

Zu der genaueren Schilderung in #1 hätte ich mir halt auch noch gewünscht..., daß Du uns daran teilhaben läßt, welche Suchbegriffe denn bei Deiner stundenlangen Recherche (hier im Board und im Internet allgemein) zu keinem hilfreichen Ergebnis führten ...

Alles bekomm ich sicher nicht zusammen aber NAND filesystem.image dump sichern, wiederherstellen, flashen usw. in verschiedenen Kombinationen, auch mit Boxnamen wie 7412, 7490 oder 7430. Ich hab mir schon wirklich Mühe gegeben, bin aber immer nur bei allgemeinen Hinweisen gelandet, die dann in solchen "Tipps" wie ruKernel-Tool mündeten oder kernel.image in mtd1 sichern und einspielen, also all das, was für NOR-Boxen gilt oder daß es halt geht oder daß jemand schrieb, er hätte es gemacht. Nichts konkretes.

Ich werde aber heut abend Deinem Hinweis nachgehen bzgl. /wrapper usw., ich denke, daß mich das weiterbringt.

 

[PeterPawn]

Da ist das betreffende bei beiden identisch, wenn ich das originale AVM-Image entpacke. Das von mir geschriebene paßt auf beide.

Ich habe keine Ahnung, wie oder was Du da testest ... aber ich bezweifle das Ergebnis.

Das paßt nicht zum tatsächlich von Dir Geschriebenen:

Die filesystem.image (SquashFS) läßt sich weiter entpacken, ich erhalte dann einen Verzeichnisbaum und die von Dir angesprochene filesystem_core.squashfs mit dem Filesystem, welches auf der Box tatsächlich läuft.

Die 06.86 hat - wie von mir (und zwar auch richtig, wenn ich das erneut lese) beschrieben - eine "filesystem.image" mit exakt dem erwarteten Dummy-Header ("sqsh" + 252 Byte NUL):

vidar:/home/FritzBox/FB7412/var/tmp $ hd filesystem.image | head -n 20
00000000  73 71 73 68 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  d8 00 00 00 f4 43 00 00  00 00 00 00 93 07 00 00  |.....C..........|
00000510  09 00 00 00 01 00 00 00  00 00 00 00 00 00 00 00  |................|
00000520  a8 16 00 00 a8 16 00 00  48 00 00 00 00 00 00 00  |........H.......|
00000530  36 78 5d 5d 00 00 14 00  53 ef 01 00 00 00 00 00  |6x]]....S.......|
00000540  36 78 5d 5d 00 00 00 00  00 00 00 00 00 00 00 00  |6x]]............|
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  03 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000920  ab 16 00 00 ac 16 00 00  ad 16 00 00 00 00 02 00  |................|
00000930  04 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000940  53 2d 00 00 54 2d 00 00  55 2d 00 00 93 07 02 00  |S-..T-..U-......|
00000950  04 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  |................|
*

und das KANN nicht identisch sein mit der 06.30, die an dieser Stelle ein SquashFS3-Image verwendet:

vidar:/home/FritzBox/FB7412/var/tmp # hd filesystem.image | head -n 20
00000000  73 71 73 68 00 00 00 c3  00 f5 97 14 00 00 00 00  |sqsh............|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 03 00 00  |................|
00000020  00 00 00 10 c0 01 00 56  1b dd 10 00 00 00 00 00  |.......V........|
00000030  00 15 c6 00 01 00 00 00  00 00 01 00 00 00 00 00  |................|
00000040  00 00 00 00 f5 97 14 00  00 00 00 00 f5 97 10 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 f5 87 fe 00  |................|
00000060  00 00 00 00 f5 8e 76 00  00 00 00 00 f5 94 f5 00  |......v.........|
00000070  00 00 00 00 f5 97 08 78  da ac bd 0f 5c 54 55 fa  |.......x....\TU.|
00000080  3f 7e ee 9d 61 18 fe a8  17 44 19 95 6a 80 41 11  |?~..a....D..j.A.|
00000090  a8 f0 cf 16 15 ed 5e 15  10 15 8d ca 76 a9 dc 65  |......^.....v..e|
000000a0  46 66 b8 fc 1d 08 b0 74  b7 fd ec 84 95 6e 59 82  |Ff.....t.....nY.|
000000b0  fc 91 41 25 12 cb da ad  d4 71 d0 3e 9f 4f bb 4b  |..A%.....q.>.O.K|
000000c0  8a 65 ff 56 1d 14 eb b3  bb bf f0 6f 0a 5a a8 90  |.e.V.......o.Z..|
000000d0  ed 6e 9f e5 f7 3e e7 de  81 83 59 bb db f7 d3 eb  |.n...>....Y.....|
000000e0  75 bc f7 39 ff 9e e7 3c  e7 79 de cf 73 ee bd 4c  |u..9...<.y..s..L|
000000f0  bf 4a cf ca 10 44 81 0c  ff 27 12 23 fe 15 88 7c  |.J...D...'.#...||
00000100  6b 32 ae b3 89 a1 7b 5b  15 91 02 71 67 46 4b 3c  |k2....{[...qgFK<|
00000110  99 42 26 a3 de c0 da 64  ad 10 81 a8 85 04 a0 e8  |.B&....d........|
00000120  51 74 a0 d1 a6 15 42 22  b4 a2 27 5c 67 8c 55 8b  |Qt....B"..'\g.U.|
00000130  a1 b3 9c 15 3a 5e 6d 11  18 3d 5f 2b 24 0c 63 63  |....:^m..=_+$.cc|

Letzteres läßt sich mittels "unsquashfs" entpacken oder direkt mounten, ersteres nicht - das braucht ein passendes Offset im Image (beim Mounten) oder das "Abschneiden" dieses Dummy-Headers, damit das "ext2"-Dateisystem erkannt und genutzt werden kann.

Entweder Du arbeitest nicht sorgfältig genug oder Dir hat jemand (entweder als 06.30 oder als 06.86) ein falsches Image von AVM untergeschoben - die Unterschiede ("ext2"-Image + Dummy-Header mit SquashFS-Signatur vs. SquashFS3-Image) sind augenfällig in den originalen Dateien und die "filesystem.image" der 06.86 kannst Du jedenfalls garantiert nicht so entpacken, wie Du das in #3 geschrieben und in #5 bekräftigt hast.

 

[Regdone]

Nein, das war wohl ein Mißverständnis. Ich schrieb, daß ich die Image-Datei von AVM entpacke und dann eine Filesystem.image im var/tmp erhalte, die ich weiter entpacken kann und die dann u.a. eine Datei filesystem_core.squashfs enthält, die ich weiter entpacken kann.
Ich dachte, Du zweifelst das an, daß das nur bei alten Versionen vor 6.5 der Fall ist und habe daraufhin geschrieben, daß das auch bei der 6.83 der Fall ist. Also alles gut, weiter hab ich noch nicht geforscht und daß das nur ein Dummy-Header ist, hast Du erst vorhin geschrieben. Ich bezog meine Aussage auf das Entpackenkönnen, weil ich Dich mißverstanden hatte. Ich schrieb

Die filesystem.image (SquashFS) läßt sich weiter entpacken

und bezog Deinen Einwand auf "läßt sich weiter entpacken" und Du meintest aber an meiner Aussage das SquashFS. Also alles gut

 

[PeterPawn]

und dann eine Filesystem.image im var/tmp erhalte, die ich weiter entpacken kann

Und genau das bezweifele ich auch tatsächlich für eine/jede (VR9-)Firmware (für AVM-Boxen mit NAND-Flash) jenseits der Version 06.50 - das hast Du also durchaus richtig verstanden. Die dort enthaltene "filesystem.image" KANN man ohne die Kenntnis ihres Aufbaus nicht weiter verarbeiten ... und selbst mit diesen Kenntnissen läßt sie sich nur irgendwo mounten und dann ihr Inhalt kopieren - da ein "ext2"-Image nicht gepackt ist, kann man es auch (per Definition) nicht entpacken.

 

[Regdone]

Doch, geht erstmal problemlos. Image vom AVM-Server genommen unter unter Windows mit 7-zip entpackt. Egal, ob 6.30, 6.50, 6.8x.
Aber, und hier hast Du natürlich recht und ich bin tatsächlich vorm Schreiben nicht gründlich genug gewesen, die im Verzeichnisbaum neben den üblichen Linux-Ordnern befindliche Datei filesystem_core.squashfs läßt sich zwar mit 7-zip auch entpacken, enthält aber keinen verwertbaren Verzeichnisbaum mehr, wie in den Versionen vor 6.5.
Aber das filesystem.image in var/tmp des AVM-Images an sich läßt sich problemlos entpacken inkl. Verzeichnisbaum. Nur die Datei filesystem_core.squashfs dann nicht mehr - mea culpa

-- Zusammenführung Doppelpost by stoney

So, kurze Rückmeldung. Das von mir Gesuchte liegt in dem Verzeichnis Wrapper. Auf die Idee, im Filesystem einer gestarteten Box zu suchen, bin ich leider nicht gekommen, Asche auf mein Haupt.
Die Daten habe ich per FTP auf den Rechner gezogen und werde nun mal versuchen, daraus und dem passenden Kernel ein flashbares Image zu basteln.
Danke nochmal Peter Pawn für die Hilfe!

 

[PeterPawn]

unter Windows mit 7-zip entpackt

Dieses Detail des Vorgehens hast Du bisher eben unterschlagen (auch wenn Du einen fehlgeschlagenen Versuch des Entpackens mit 7-Zip erwähnt hast).

Seit etwas mehr als vier Jahren (seit Version 15.08, iirc) kann 7-Zip Dateien aus ext3- und ext4-Images extrahieren (ext2 ist ext3 ohne Journal) - das würde aber keiner (zumindest keiner, der sich mit der Materie auskennt - behaupte ich jetzt einfach mal und nehme Widerspruch (samt Erklärung) gerne zur Kenntnis von jemandem, der sich damit auskennt) als "Entpacken" bezeichnen und daher rührte dann auch das "Mißverständnis".

Vom "Packen" spricht man dann, wenn durch Kompressionsalgorithmen die Daten effektiver gespeichert werden und am Ende weniger Platz belegen oder wenn - i.d.R. zum Transport oder zur Sicherung von Dateien, wobei das meist mit Kompression kombiniert wird - die Dateien in einem Format gespeichert werden (das nennt man dann eben auch "Archiv"), bei dem die Dateien direkt aufeinander folgen und in der "gepackten" Form normalerweise nicht weiter verarbeitet - insbesondere nicht geändert - werden können ... diese muß man dann für solche Zwecke auch wieder "entpacken" - also den Vorgang des Packens wieder rückgängig machen und sie in eine Form überführen, an der man Änderungen vornehmen kann.

Das Mißverständnis basierte also in erster Linie darauf, daß hier 7-Zip verwendet wird und wohl auch erneut darauf, daß Du dann die Ausgaben dieses Programms (wenn man es auf der Kommandozeile benutzt und nicht nur die GUI-Version bzw. dort nach den Einzelheiten (konkret den "Properties" der geöffneten "filesystem.image") schaut und nicht immer nur Verzeichnisebenen wechselt) nicht richtig gelesen hast - wenn Du dann trotzdem noch Fragen zum Aufbau der "filesystem.image" hattest nach diesem Vorgehen:

vidar:/tmp/test $ wget ftp://ftp.avm.de/fritzbox/fritzbox-7412/deutschland/fritz.os/FRITZ.Box_7412-06.86.image
--2019-11-13 14:32:22--  ftp://ftp.avm.de/fritzbox/fritzbox-7412/deutschland/fritz.os/FRITZ.Box_7412-06.86.image
           => ‘FRITZ.Box_7412-06.86.image’
Resolving ftp.avm.de (ftp.avm.de)... 212.42.224.71, 212.42.224.74, 217.110.95.227, ...
Connecting to ftp.avm.de (ftp.avm.de)|212.42.224.71|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD (1) /fritzbox/fritzbox-7412/deutschland/fritz.os ... done.
==> SIZE FRITZ.Box_7412-06.86.image ... 20930560
==> PASV ... done.    ==> RETR FRITZ.Box_7412-06.86.image ... done.
Length: 20930560 (20M) (unauthoritative)

FRITZ.Box_7412-06.86.image                                  100%[================================================>]  19.96M  11.8MB/s    in 1.7s

2019-11-13 14:32:23 (11.8 MB/s) - ‘FRITZ.Box_7412-06.86.image’ saved [20930560]

vidar:/tmp/test $ 7z e ./FRITZ.Box_7412-06.86.image ./var/tmp/filesystem.image

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs Intel(R) Core(TM)2 Duo CPU     P7350  @ 2.00GHz (1067A),ASM)

Scanning the drive for archives:
1 file, 20930560 bytes (20 MiB)

Extracting archive: ./FRITZ.Box_7412-06.86.image
--
Path = ./FRITZ.Box_7412-06.86.image
Type = tar
Physical Size = 20930560
Headers Size = 5632
Code Page = UTF-8

Everything is Ok

Size:       17817608
Compressed: 20930560
vidar:/tmp/test $ 7z l ./filesystem.image
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs Intel(R) Core(TM)2 Duo CPU     P7350  @ 2.00GHz (1067A),ASM)

Scanning the drive for archives:
1 file, 17817608 bytes (17 MiB)

Listing archive: ./filesystem.image

--
Path = ./filesystem.image
Type = Ext
WARNINGS:
There are data after the end of archive
Offset = 256
Physical Size = 17813504
Tail Size = 3848
Cluster Size = 1024
Free Space = 1985536
Modified = 2019-08-21 17:58:30
Last Check Time = 2019-08-21 17:58:30
Host OS = Linux
Revision = 0
inode Size = 128
Code Page = UTF-8

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
2019-08-21 17:58:27 D....                            dev
2019-08-21 17:58:30 D....                            lib
2019-08-21 17:58:30 D....                            tmp
2019-08-21 17:58:30 .....     14512128     14570496  filesystem_core.squashfs
2019-08-21 17:58:30 D....                            core
2019-08-21 17:58:30 D....                            sbin
2019-08-21 17:58:30 D....                            bin
2019-08-21 17:58:30 D....                            proc
2019-08-21 17:58:30 D....                            var
2019-08-21 17:58:30 D....                            etc
2019-08-21 17:58:30 .....            7            0  bin/mkdir
[...]
2019-08-21 17:58:30 .....           14            0  sbin/swapon
2019-08-21 17:58:30 .....           14            0  sbin/iptunnel
------------------- ----- ------------ ------------  ------------------------
2019-08-21 17:58:30           15707521     15774720  187 files, 10 folders

Warnings: 1

Denn in den oben stehenden Zeilen sind praktisch schon alle relevanten Informationen zum Aufbau der "filesystem.image" enthalten (inkl. der Info, daß die äußere "image"-Datei ein Tarball ist) - das wäre dann die "dritte Quelle" zum Aufbau, aus der man sich hätte bedienen können. Da steht bereits deutlich, daß es sich im Inneren um eine "ext"-Partition handelt und daß diese erst beim Offset 256 innerhalb der "filesystem.image" beginnt bzw. gefunden wurde.

Das paßt dann immer noch nicht zu der von Dir getroffenen Feststellung (die ich in #4 und #6 schon jeweils zitierte, weil sie der "Aufhänger" für meinen Einwand/meine Zweifel war):

Die filesystem.image (SquashFS) läßt sich weiter entpacken

, denn diese ist eben nur für Versionen < 06.50 gültig. Danach läßt sie sich mit 7-Zip zwar auch noch untersuchen, ist aber kein SquashFS-Image mehr - auch das habe ich ausführlich erklärt.

Ich lege u.a. auch deshalb so viel Wert auf eine exakte Beschreibung, weil es eben tatsächlich auch Leute gibt, die solche Thread hier im IPPF von alleine finden [ und das ist hier auch nicht der erste, der sich mit dem Aufbau von Dateisystem- und Firmware-Images bei AVM befaßt - nur um der Annahme, man hätte da gar nichts finden KÖNNEN vor diesem Thread, dann doch gleich noch einmal zuvorzukommen ] und diese dann nicht von unklaren/ungenauen/falschen Angaben oder Aussagen in die Irre geleitet werden sollen - das ist nicht nur Selbstzweck.

--------------------------------------------------------------------------------------------------------------

Wobei Du da mit Windows jetzt ohnehin nicht mehr weiterkommst ... für das SquashFS4-Dateisystem bei den MIPS-Boxen jenseits der 06.5x verwendet AVM ein eigenes, abgewandeltes SquashFS4-Format und das kennt nun mal 7-Zip nicht (wie Du inzwischen wohl selbst bemerkt hast) - die Patches gegen das offizielle Format für die "squashfs-tools" gibt es im Freetz-Repository. Wer also die "filesystem_core.squashfs" aus Systemen jenseits der 06.50 entpacken(!) will, der braucht die passenden Tools ... die Versionen davor kann 7-Zip dann tatsächlich noch entpacken, weil es da noch ein "übliches" Format war, was von AVM verwendet wurde.

Das bekanntermaßen fehlende Verständnis von 7-Zip für das AVM-Format ist wohl auch der Grund, warum ich gar nicht auf die Idee kam, irgendjemand könnte mit 7-Zip (oder gar mit Windows) an dieser Stelle arbeiten (auch meine Aussage, daß man das Image irgendwo mounten solle, zeigt das ja deutlich - damit kann Windows ohne Zusatzsoftware gar nichts anfangen) ... zumal auch diese Änderungen wieder hier im IPPF (zu dem Zeitpunkt, wo sie tatsächlich aktuell waren) lang und breit besprochen wurden und man schon bei der Suche nach "SquashFS4" hier im Board über zig Fundstellen stolpert, an denen immer wieder gefragt wurde, mit welchen Werkzeugen man dieses Format von AVM denn nun bearbeiten könne. Auch schreibst Du selbst ja weiter vorne, daß Du Freetz verwendet hättest, um ein eigenes Image zu erstellen ... da gehe ich (nach derzeitigem Kenntnisstand, wo Freetz überall läuft) dann halt auch von Linux als verwendeter Plattform aus.

Da findet man dann jedenfalls bei der eigenen Suche auch immer wieder die Erklärungen, wo man (für Linux-Systeme bzw. auch für das WSL, wenn man partout keinen gesonderten Linux-Host sein Eigen nennen darf) fertige Binaries "erhaschen" könnte ... das sind halt alles "prerequisites" in meinen Augen, daß man sich solche Informationen zusammensucht, BEVOR man sich an die Untersuchung irgendwelcher Firmware-Dumps macht (vielleicht auch daher mein Unverständnis bzw. meine Annahme, daß Du die "basics" bereits abgearbeitet hättest).

 

[Regdone]

Nur kurz, bin gerade in Eile: natürlich benutze ich für solche Arbeiten einen Linux-Rechner. Aber für die tägliche Arbeit und auch um Foren zu lesen usw. ist Windows mein OS. Von daher schau ich mir solche Dinge gern mal in Windows und damit mittels 7-zip an. Aber eben nur anschauen! Ist für mich einfach bequemer - ohne darüber jetzt diskutieren zu wollen.
Natürlich komm ich nicht auf die Idee, ein Image mit 7-Zip bearbeiten zu wollen (entpacken/packen). Also alles gut. Auf die Idee bin ich jetzt nicht gekommen, daß solche Schlußfolgerungen gezogen werden könnten.

 

[PeterPawn]

Ist ja alles gut ... mir geht/ging es auch nur darum, das möglichst exakt "herauszuarbeiten", damit spätere Leser profitieren können und nicht durch Widersprüche (ist das nun ein SquashFS-Image oder nicht?) dann doch eher wieder verwirrt werden im Vergleich zu anderen Fundstellen.

Am besten schaust Du Dir das mit den jetzt gesammelten Informationen alles noch einmal richtig an, suchst bei weiteren Unklarheiten nach den anderen Threads hier (wie es - abseits von Freetz und meinen eigenen Repos - mit anderen Quellen aussieht, weiß ich nicht bzw. diese will ich nicht be- oder verurteilen) und wenn DANN immer noch Fragen übrig bleiben, dann kann man ja weiter darüber palavern.

 

[Regdone]

So, ich hab mir nun Zeit genommen, gelesen, versucht zu verstehen und hab mir in der Versuchsbox von 6.30, 6.32 und 6.86 jeweils die kernel.image (per mtd-Dump) und die passenden Wrapper-Verzeichnisse inkl. filesystem_core.squashfs auf dem Rechner gesichert.
Gescheitert bin ich bisher daran, aus der Wrapper-Partition ein filesystem.image zu erstellen. Ich habe erst einmal mit der 6.30 angefangen, um Schritt für Schritt vorzugehen. Ziel ist es, den Inhalt des Wrapper-Verzeichnisses in ein SQUASHFS3-Image zu packen und dieses als Filesystem.image zum Flashen zu verwenden. Ich habe dazu die Squashfs-Tools benutzt und versucht, mittels mksquashfs <source> <dest> aus dem Wrapper-Verzeichnis das Filesystem.image zu erstellen.
Ersteinmal ohne Eingabe weiterer Parameter. Das Image wird auch problemlos erzeugt.
Aber hier komm ich nicht weiter, irgendwo hab ich einen Denkfehler oder ein Verständnisproblem und finde auch keine passende Erklärung.
Die originale Filesystem.image beginnt im Header mit 73 71 73 68 (sqsh), die mit mksquashfs erzeugte Datei jedoch mit 68 73 71 73 6B (hsqsk). Das ist also offenbar nicht das erwünschte Ergebnis.

Freetz verwendet zum Erzeugen des SquashFS-Images ja eigene Tools wie z.B, mksquashfs3-multi. Und im Yourfritz repository befindet sich unter Framework pack_squashfs. Beide werden von diversen Scripten der jeweiligen Pakete benutzt.

Wie komm ich nun mit dem Wrapper-Ordner am besten zum Filesystem.image? Das ist mir noch nicht klar geworden.

 

[PeterPawn]

Daß die 7490 als MIPS-Gerät mit BE-Speicherung (Big Endian) arbeitet, hast Du auch irgendwo gelesen?

Bis SquashFS3 (inkl.) gab es offiziell in den SquashFS-Tools noch die Unterscheidung zwischen LE und BE (und auch unterschiedliche Signaturen in Superblock, wie Du ja offenbar feststellen konntest, wobei das "k" am Ende von "hsqs" nicht mehr zu dieser Signatur gehört - das ist die ASCII-Darstellung von "sqsh", nur in LE-Format als 32-Bit-Integer, also rückwärts zu lesen) ... seit Version 4 gibt es diese Unterscheidung in den SquashFS-Kernel-Quellen nicht mehr und die Tatsache, daß AVM da weiterhin BE nutzt, führt ja direkt zu dem (auch in diesem Thread bereits in #10 angesprochenen) eigenen Format ... wobei jedes "file"-Kommando auch in der Lage ist, den Unterschied zwischen diesen Formaten zu erkennen und anzuzeigen.

Während das für die "filesystem.image" von AVM (aus der 06.30) die folgende Ausgabe erzeugt:

vidar:/home/FritzBox/FB7412/var/tmp $ file filesystem.image
filesystem.image: Squashfs filesystem, big endian, version 3.0, 16094996 bytes, 195 inodes, blocksize: 65536 bytes, created: Mon Oct 12 16:17:20 2015

, dürfte sich das für Deine selbst erzeugte Datei etwas anders lesen (und da meine ich nicht nur Größe und Datum) ... und trotzdem sollte genau dieser Unterschied augenfällig sein und (hätte ich mir zumindest gewünscht) weitere Recherchen nach sich ziehen, in deren Verlauf dann auch die passenden Optionen beim Aufruf für "mksquashfs" (zumindest bei dem für Version 3, sofern die Sourcen von SquashFS 3.4 genutzt wurden) gefunden würden (oder werden sollten).

Auch beim "unsquashfs" wird das mit dem Format ja ausdrücklich betont, wenn es ein anderes ist, als auf dem jeweiligen Host (hier x64) i.d.R. verwendet wird ... stellt sich halt dem unbefangenen Beobachter die Frage, warum das angegeben werden sollte, wenn es nicht auch von Bedeutung wäre:

vidar:/home/FritzBox/FB7412/var/tmp $ unsquashfs -s filesystem.image
Reading a different endian SQUASHFS filesystem on filesystem.image
Found a valid big endian SQUASHFS 3:0 superblock on filesystem.image.
Creation or last append time Mon Oct 12 18:17:20 2015
Filesystem size 15717.77 Kbytes (15.35 Mbytes)
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Check data is not present in the filesystem
Duplicates are removed
Number of fragments 1
Number of inodes 195
Number of uids 1
Number of gids 0

-------------------------------------------------------------------------------------------

BTW ... verstehe ich das richtig, daß es sich nach der Beschreibung in #13 schon um den allerersten Versuch dreht, der bei Dir direkt scheitert? Du also am Ende große Pläne für mind. drei verschiedene Firmware-Versionen hast, aber bereits bei der ersten nicht mehr weiterkommst?

Dann wüßte ich gerne mal, welche Quellen hinsichtlich des Aufbaus einer solchen Datei und zum SquashFS-Format allgemein, Du da gelesen hast, die so unzureichende Informationen vermitteln.

Ich selbst hatte Dir hier im Thread schon drei mögliche Stellen genannt, wo man sich das ansehen kann, wie andere (ja offensichtlich funktionierende) Lösungen so ein Image zusammenbauen - mir fehlt etwas das Verständnis, wieso nach der Lektüre dieser Quellen (wenn man mit einer nicht weiterkommt, muß man halt die nächste nehmen und notfalls auch alle drei lesen) der Unterschied zwischen BE und LE (bis hin zur Signatur im Superblock) nicht bereits glaskar sein sollte. Wenn das tatsächlich jenseits des eigenen Knowledge-Levels ist, würde ich mir das mit dem Erzeugen der Images noch einmal überlegen ... ansonsten ist es vermutlich doch hilfreich, wenn man einfach mal liest. DAS wäre auch der Weg, um die eigenen Kenntnisse so weit zu vertiefen, daß auch eine Aussicht auf Erfolg des eigenen Vorhabens besteht - sofern die bisher gefundenen Infos tatsächlich "zu kompliziert" sind.

Und genau weil ich dieses "by the way" loswerden wollte (und das nicht nur als "rant" daherkommen sollte), habe ich das oben noch einmal erklärt ... aber ich hoffe mal, Du verstehst, daß ich bei weiteren Fragen desselben Kalibers ab jetzt "schweigen" werde. Wenn das einzig Sinnvolle nur eine Wiederholung der Frage ist, wie genau Du gesucht hast (es ist schon erstaunlich, wenn jemand sooo wenige relevante Informationen finden kann), muß ich das nicht noch einmal auffrischen; vor allem dann, wenn die Antwort wieder so konkret wäre, wie in #5.

Vielleicht kannst Du ja doch mal konkrete Suchanfragen, die Dich nicht weiterbringen konnten, hier "zeigen" ... spätestens seit meinen Fragen weiter oben in dieser Richtung, müßtest Du ja darauf vorbereitet sein, so etwas anzubieten - mal ganz abgesehen davon, daß heutzutage praktisch jeder Browser auch eine entsprechende History führt, in der man das nachsehen kann, wenn man es selbst nicht mehr genau weiß.

Vielleicht machst Du ja auch bei der Suche etwas falsch? Man kann mit dem richtigen Vorgehen auch die ganzen alten Informationen, die aus einer Zeit stammen, wo es die 7490 noch gar nicht gab (und mit ihr bzw. mit der 7362SL änderte sich da so einiges, woraufhin alte Anleitungen nicht mehr funktionieren) aus den Ergebnissen ausschließen ... das spart (a) Zeit und (b) wird man dann nicht von diesen, nunmehr falschen Infos in die Irre geleitet.

Auch die selbständige und freiwillige Angabe, aus welchen Quellen Du Deine bisherigen Informationen gesammelt hast (abgesehen von diesem Thread), wäre sicherlich hilfreich ... erstens als "Aufzählung" für andere Leser mit demselben Anliegen und zweitens kann man dann auch darauf verzichten, das in diesem Threads Geschriebene noch einmal "wiederzukäuen".

 

[Regdone]

So, Problem ist gelöst. Ursache war die zu neue Version der squashfs-tools. Diese sind in neuen Versionen trotz gleichen Namens nicht abwärtskompatibel und können kein squashfs3 und vor allem gibts es auch den Schalter -be und -le nicht mehr.
Diese Informationen sind aber in den Tiefen des Internets versteckt, wenn man die Tools ganz normal auscheckt im Linux, bekommt man das nicht mit und sicher 80% der Anleitungen im Netz sind älter und damit unbrauchbar.
Mit DIESEM Wissen finde ich natürlich im Netz die Lösung aber ohne dieses, einfach nur nach den Optionen und der Anwendung von squashfs-tools gegooglet, ist es schwer, das herauszufinden, wenn man nicht damit rechnet, daß das Tool nicht abwärtskompatibel ist und zuerst danach sucht, welche Optionen man nun setzen muß.
Ich habe mir eine ältere Version der squashfs-Tools gesucht (Version 3.x) und damit funktioniert es einwandfrei!
Aus dem von der Box heruntergezogenen Dateisystem läßt sich problemlos die filesystem.image erstellen und diese in Verbindung mit dem gesicherten kernel.image in eine zumindest per Bootloader flashbare Fritz-OS-Datei packen.

Ab 6.5 mit dem EXT2-Image und Dummy-Header geht es fast noch einfacher. Ich hab einfach eine originale filesystem.image passender Größe eines originalen AVM-Images R/W als Loop-Device mit 256 byte Offset gemountet und den Inhalt gegen den des aus der Box geholten Wrapper-Ordners getauscht, fertig. Vorteil, nach dem unmounten des Laufwerkes kann man die Datei gleich verwenden, muß nicht erst den Dummy-Header wieder davorsetzen. Vielleicht gehts noch einfacher aber darüber kann man trefflich streiten, ich habe für mich diese Version gefunden.

 

[PeterPawn]

Ich kann mir dann doch (nicht für @Regdone, sondern für spätere Leser, die das nachmachen sollten) die folgenden Zusatzbemerkungen nicht verkneifen:

Das Mounten eines alten AVM-Images und das Austauschen der Dateien darin, funktioniert nur genau so lange, wie der im Image vorgesehene Platz dafür auch ausreicht.

Bei AVM wird (bei der 7412) ein 17 MB großes "ext2"-Image verwendet, welches - mit den originalen Dateien von AVM - zu 89% bereits gefüllt ist.

peh@vidar:~> wget -q -O - http://ftp.avm.de/fritzbox/fritzbox-7412/deutschland/fritz.os/FRITZ.Box_7412-06.86.image | tar -x ./var/tmp/filesystem.image -O > 7412.06.86.fs.img
peh@vidar:~> sudo mount -r -o offset=256 7412.06.86.fs.img /mnt
peh@vidar:~> df -h /mnt
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0       17M   16M  1.9M  89% /mnt
peh@vidar:~> sudo find /mnt/ -name "*.squashfs" -ls
       81  14229 -rw-------   1  root     root     14512128 Aug 21 18:58 /mnt/filesystem_core.squashfs
peh@vidar:~> sudo umount /mnt
peh@vidar:~> rm 7412.06.86.fs.img
peh@vidar:~>

Wird also das eigene SquashFS-Image für das Wurzeldateisystem etwas größer (z.B. weil man eigene Komponenten hinzufügte), läßt es sich nicht mehr in dieses "fertige Image" kopieren. Daß bei AVM das "ext2"-Image auch immer (zumindest grob) dem tatsächlich erforderlichen Platzbedarf angepaßt wird (offenbar mit einem kleinen "Sicherheitszuschlag"), sieht man auch daran, daß bei der 06.50 das "ext2"-Image noch kleiner war ... ebenso natürlich die "filesystem_core.squashfs":

peh@vidar:~> df -h /mnt
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0       16M   14M  2.0M  88% /mnt

Aber es ist auch tatsächlich gar kein Problem, sich ein eigenes "ext2"-Image zu erzeugen ... einen möglichen Weg dafür, hatte ich dem Fragesteller bereits in #2 verlinkt. In den Beispielen in meinem GitHub-Repository unter: https://github.com/PeterPawn/YourFritz/blob/master/toolbox/build_shellinabox_implant_image#L360
kann man sich ansehen, daß es am Ende nur ein paar einfacher Kommandos bedarf, um sich ein solches "ext2"-Image in der eigenen Wunschgröße zu erstellen (und die Dateisystem-Partitionen in den VR9-Boxen mit NAND-Flash sind i.d.R. immerhin 48 MB groß - also deutlich größer als so ein "fertiges" AVM-Image):

#######################################################################################################
#                                                                                                     #
# build an ext2 image of 10 MB size and mount it                                                      #
#                                                                                                     #
#######################################################################################################
if ! dd if=/dev/zero of="$name/ext2_image" bs=1024 count=$(( ${TOOLBOX_IMAGE_SIZE:-10} * 1024 )) 2>/dev/null; then
    [ $debug -eq 1 ] && printf "Error preparing image file for the new filesystem image.\n" 1>&2
    exit 1
fi
if ! mkfs -t ext2 "$name/ext2_image" 2>/dev/null 1>&2; then
    [ $debug -eq 1 ] && printf "Error making ext2 filesystem structures on new filesystem image.\n" 1>&2
    exit 1
fi
if ! mkdir "$name/mp" 2>/dev/null; then
    [ $debug -eq 1 ] && printf "Error creating mount point for the new filesystem image.\n" 1>&2
    exit 1
fi
if ! mount "$name/ext2_image" "$name/mp" 2>/dev/null; then
    [ $debug -eq 1 ] && printf "Error mounting ext2 image for the new filesystem.\n" 1>&2
    exit 1
fi

und auch das Erzeugen des Dummy-Headers ist natürlich kein wirkliches Problem, da der eben nur aus den vier Zeichen "sqsh" und 252 binären Nullen besteht, wie weiter oben hier auch mehrfach erläutert:

( printf "sqsh"; dd if=/dev/zero bs=4 count=$(( 256 / 4 - 1 )) 2>/dev/null ) >"$name/dummy_header"

Der wird dann einfach mittels "cat" vor dem Dateisystem-Image ausgegeben und fertig ist die Laube - daher stimme ich dem "Vorteil", der in #15 hinsichtlich dieses Headers beschrieben ist, auch nicht so ganz zu - DAS ist ja nun das allergeringste Problem beim Erzeugen des richtigen Formats für eine "filesystem.image" ab FRITZ!OS 06.5x.

Wer am Ende mit dem eigenen "ext2"-Image gar keinen Platz verschwenden will (also mit einer vordefinierten Größe nicht zufrieden ist), der kann auch den etwas ausführlicheren Weg aus Freetz gehen und sich die Größe des notwendigen Images anhand des geplanten Inhalts errechnen lassen: https://github.com/Freetz/freetz/blob/master/tools/mke2img

Der in #15 skizzierte Weg hat also für @Regdone funktioniert (daß es wohl nicht das Optimum ist, schreibt er ja selbst in #15) ... sowie man aber weitere Daten zum (selbst erzeugten) SquashFS-Image in der "filesystem_core.squashfs" hinzufügt oder auch weitere/andere Dateien im äußeren Dateisystem speichern will (und zwar schon im "ext2"-Image und nicht erst im YAFFS2, wenn das dann im NAND steht), hat man nur noch sehr begrenzten Spielraum bei der beschriebenen Methode und ehe man sich da "einen abbricht", erstellt man sich wohl besser sein eigenes "ext2"-Image - zumal die "Vorlagen" dafür eben existieren (und sei es nur, damit andere da einfach mal "nachlesen" könnten) und hier auch schon (sehr früh) verlinkt oder zumindest angeführt wurden.

Wenn man bis hier gelesen hat oder auch, wenn man einer der bereits ganz weit vorne in diesem Thread von mir angeführten Quellen gefolgt ist, bevor man bei #15 ankam, kann man sich ja seine eigene Meinung dazu bilden. Der in #15 berichtete Weg funktioniert zweifellos auch, aber eben nur unter bestimmten Voraussetzungen ... der Ansatz aus Freetz bzw. aus meiner Toolbox ist "universeller" und unterliegt ggf. vielleicht anderen Beschränkungen (spätestens denen der Partitiongröße im Flash der Box), aber nicht der einer zu kleinen "vordefinierten Größe" des verfügbaren Speicherplatzes, wie das bei der Nachnutzung eines AVM-Images der Fall ist.