[Info] Software: fitimg AVM fit-image Manipulator

hippie2000

Neuer User
Mitglied seit
20 Jan 2008
Beiträge
144
Punkte für Reaktionen
59
Punkte
28
Hallo,

für alle Freetz-Forks und andere Modding-Projekte habe ich ein Programm namens fitimg zum Hantieren der neuen fit-image Dateien geschrieben.

fitimg kann hier heruntergeladen werden (GPLv2+) :


fitimg ermöglicht es fit-images zu listen, testen, zu zerlegen und nach eventueller Modifikation wieder zusammenzubauen und eröffnet den Weg auch die 7530ax, 5530 und den kommenden Repeater 6000 modifizieren zu können. Genau das fehlt bisher in allen Freetz-Forks, das muss aber nun auch erst mal eingebaut und getestet werden. Noch ist unbekannt ob meine Images korrekt zusammengebaut werden, da es im Kopf des FIT-Formats immer noch Daten gibt deren Sinn ich nicht erkennen kann.

Das Format habe ich hier erforscht - die Informationen werden nach und nach auf der oben angegebenen BoxMatrix-Seite hinzugefügt:


Edit (2021-01-13): fitimg 0.2 Release - Info in diesem Posting:


Wer kann helfen?

Gesucht wird jemand der eine 5530 hat und mal eine Recovery mit Wireshark oder Ähnlichem dumpen würde, damit wir lernen können wie ein fit-image übertragen wird. Edit; Dump der 7530ax vorhanden, siehe nächstes Posting.

Auch suche ich noch unzensiertes Supportdata 5530. Edit: Supportdata der 7530ax vorhanden.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: eisbaerin

hippie2000

Neuer User
Mitglied seit
20 Jan 2008
Beiträge
144
Punkte für Reaktionen
59
Punkte
28
@JERKBALL war so nett mir die Recovery der 7530ax mitzuschneiden, vielen Dank!

Hier der Transscript;


Aus dem abgrufenen counter und environment wird ein neues nandtffs gebaut und hochgeladen.
Danach wird die kernel commandline und ramsize für das sdram update gesetzt und das fit-image hochgeladen.

Auch die 7530ax ist dual boot, Partitionen für Filesystem und Kernel gibt es nicht mehr, nur noch fit Partitionen.
Je fit Partition reserviert AVM 50MB, derzeitige 7530ax fit Grösse ist 34MB. Die 128MB NAND teilen sich also in 50+50MB fit + 2MB urlader + 8MB nand-tffs + 1MB nvram + 16MB ubi = 127MB auf. Das übrige MB könnte vielleicht für Reserveblöcke, die NSA oder den Bundestrojaner reserviert sein. Das Innenministerium ist in der selben Strasse wie AVM ;-)

Die Partitionierung aus Bootloader-Sicht:
Code:
linux_fs_start    1
...
mtd0    0x0,0x0
mtd1    0xB00000,0x3D00000 = 50MB = fit0/fit1
mtd2    0x100000,0x300000 = 2MB = urlader
mtd3    0x300000,0xB00000 = 8MB = nand-tffs
mtd4    0x3D00000,0x6F00000 = 50MB = fit1/fit0
mtd5    0x0,0x100000 = 1MB = nvram
mtd6    0x6F00000,0x7F00000  = 16MB = ubi

Die Partitionierung aus Linux-Device-Sicht:
Code:
major minor  #blocks  name
   1        0       8192 ram0 = 8MB = ramdisk oder kernel?
  31        0      31112 mtdblock0 = 30,4MB = rootfs_ram (ram-filesystem, squashfs)
  31        1      51200 mtdblock1 = 50MB = fit0 (brcmnand, fit-image)
  31        2       2048 mtdblock2 = 2MB = urlader (brcmnand)
  31        3       8192 mtdblock3 = 8MB = nand-tffs (brcmnand, tffs3-nand)
  31        4      51200 mtdblock4 = 50MB = fit1 (brcmnand, fit-image)
  31        5       1024 mtdblock5 = 1MB = nvram (brcmnand)
  31        6      16384 mtdblock6  = 16MB = ubi (brcmnand, ubi)
  31        7       2108 mtdblock7 = 2,05MB = [ubi_intern] (ubifs)
  31        8      12772 mtdblock8  = 12,5MB = avm_userdata (ubifs)

Die Partitionierung aus Linux-MTD-Sicht:
Code:
[    1.512641] Creating 1 MTD partitions on "ram-filesystem":
[    1.518154] 0x000000000000-0x000001e62000 : "rootfs_ram"
...
[    1.914366] Creating 6 MTD partitions on "brcmnand.0":
[    1.919510] 0x000000b00000-0x000003d00000 : "fit0"
[    1.925914] 0x000000100000-0x000000300000 : "urlader"
[    1.932525] 0x000000300000-0x000000b00000 : "nand-tffs"
[    1.939274] 0x000003d00000-0x000006f00000 : "fit1"
[    1.945633] 0x000000000000-0x000000100000 : "nvram"
[    1.952069] 0x000006f00000-0x000007f00000 : "ubi"
...
[    4.078035] ubi0: attaching mtd6
[    4.132901] ubi0: scanning is finished
[    4.142642] ubi0: attached mtd6 (name "ubi", size 16 MiB)
[    4.148042] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[    4.154920] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[    4.161704] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
[    4.168659] ubi0: good PEBs: 128, bad PEBs: 0, corrupted PEBs: 0
[    4.174660] ubi0: user volume: 2, internal volumes: 1, max. volumes count: 128
[    4.181882] ubi0: max/mean erase counter: 5/3, WL threshold: 4096, image sequence number: 52028916
[    4.190836] ubi0: available PEBs: 0, total reserved PEBs: 128, PEBs reserved for bad PEB handling: 4
[    4.199970] ubi0: background thread "ubi_bgt0d" started, PID 507
...
[   31.648820] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" started, PID 1573
[   31.667328] UBIFS (ubi0:1): recovery needed
[   31.722410] UBIFS (ubi0:1): recovery completed
[   31.722544] UBIFS (ubi0:1): UBIFS: mounted UBI device 0, volume 1, name "avm_userdata"
[   31.722557] UBIFS (ubi0:1): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[   31.722569] UBIFS (ubi0:1): FS size: 11808768 bytes (11 MiB, 93 LEBs), journal size 1015809 bytes (0 MiB, 6 LEBs)
[   31.722579] UBIFS (ubi0:1): reserved for root: 557756 bytes (544 KiB)
[   31.722593] UBIFS (ubi0:1): media format: w4/r0 (latest is w4/r0), UUID <snip>, small LPT model

UBI ist ein Volume-Manager, ein Image kann mehrere Partitionen enthalten, die mit UBIFS gemountet werden können. Derzeit wird eine interne UBI Partition und eine Partition "avm_userdata" gemountet, siehe im Log:

Code:
[    4.174660] ubi0: user volume: 2, internal volumes: 1, max. volumes count: 128
 
Zuletzt bearbeitet:
  • Like
Reaktionen: prisrak1

Daniel Lücking

IPPF-Promi
Mitglied seit
18 Apr 2008
Beiträge
3,886
Punkte für Reaktionen
323
Punkte
83
Mittlerweile sind Innenministerium und AVM aber nicht mehr nur wenige Meter auseinander... das war schon mal anders.
 

KunterBunter

IPPF-Urgestein
Mitglied seit
12 Okt 2005
Beiträge
26,011
Punkte für Reaktionen
544
Punkte
113
Die sind mehr als einen Kilometer voneinander entfernt, und dazwischen liegt noch das berühmte Gefängnis Moabit. ;)
 

Daniel Lücking

IPPF-Promi
Mitglied seit
18 Apr 2008
Beiträge
3,886
Punkte für Reaktionen
323
Punkte
83
... bis zur Inbetriebnahme dieser Liegenschaft war es mal Alt-Moabit 101D ... der @hippie2000 weiß schon, was er da andeutet... Aber so blöd, den Staatstrojaner dort abzulegen dürfte eigentlich niemand sein ... hoffe ich jedenfalls.
 

hippie2000

Neuer User
Mitglied seit
20 Jan 2008
Beiträge
144
Punkte für Reaktionen
59
Punkte
28
fitimg-0.2 Rlelease

> boxmatrix.info/wiki/FIT-Image#Download

Soeben habe ich fitimg 0.2 released. Neuerungen sind u.a. dass alle Pperationen nun auf fit-image, firmware.image und recovery.exe dateien anwendbar sind aufs infile.
Dazu gibt es nun zusätzlich einen Befehe zum Kopieren eines unveränderten fit-images (nützlich zum extrahieren aus firmware.image und recovery.exe).

> /boxmatrix.info/wiki/FIT-Image#Copy

Ausserdem gibt es nun einen Befehl zum Ansehen der Hunkstruktur eines Images der mittlerweile alle Hunknamen aller 3 FIT-Modelle kennt.
So kann man nun lückenlos alle Metadaten zu den enthaltenen Binaries studieren. Das Beispiel spricht Bände:

> boxmatrix.info/wiki/FIT-Image#Show

Die genauen Verbesserungen:

Code:
- Added: The show command (-s) now knows all hunknames of the 7530ax, 5360 and 6000.
- Added: A new show command (-s) can show the hunk structure of a fit-image. Useful for development.
- Added: A new copy command (-c) can extract a fit-image from a fit-image, firmware.image or recovery.exe.
- Changed: All commands now work on fit-image, firmware.image and recovery.exe files for the <infile>.
- Fixed: A nasty bug calculated wrong offsets in Replace (-r) when the fit-image filesize changes.
- Fixed: Removed wrong info in docs and help text which showed a [<file>] filter for the -x command.
- Fixed: Bug which reported "Use of uninitialized value" if called without arguments.
- Fixed: The release archive now contains a versioned subfolder (in favour of the prior bin folder).

TODO:

Wir bauen gerade erste Schritte der 7530ax in Freetz-ng ein. Es baut aber ist noch weit weg von fertig und erst wird jetzt dabei fitimg debuggt.
Das ist auch der Grund warum 0.2 so schnell kam, es gab einen Bug im Replace (-r) Befehl.
 
  • Like
Reaktionen: prisrak1

prisrak1

Mitglied
Mitglied seit
14 Mai 2017
Beiträge
412
Punkte für Reaktionen
36
Punkte
28
Nur zum Verständnis eben wird den die selbstgebaute nandtffs über die Updateoberfläche der AVMGui angenommen, oder läufts mit push_firmware?
 

NDiIPP

IPPF-Promi
Mitglied seit
13 Apr 2017
Beiträge
4,834
Punkte für Reaktionen
923
Punkte
113
  • Like
Reaktionen: prisrak1

hippie2000

Neuer User
Mitglied seit
20 Jan 2008
Beiträge
144
Punkte für Reaktionen
59
Punkte
28
push_firmware ist ziemlich universell geworden im freetz-ng fork:
Code:
$ 
Usage: tools/push_firmware [image] [ -m<s|r|d|u|f> ] [ -f ] [ -ip <ip> ] [ -ram <mb> ] [ -lfs <0|1|9> ] [ -cmd <ftp|ncftp> ] [ -hn ]

[image]           When no 'image' file is given, images/latest.image will be tried.
-ms               Force mode single-boot (classic devices, like 7270 & 7390)
-mr               Force mode ram-boot (newer devices, like 7490 & 7590)
-md               Force mode dual-boot (classic docsis devices, like 6490 & 6590)
-mu               Force mode uimg-boot (newer docsis devices, like 6591 & 6660)
                    See https://bitbucket.org/fesc2000/ffritz/src/6591/README-6591.md
-mf               Force mode fit-boot (latest devices, like 5530 & 7530 AX)
                    Experimental and not tested with real hardware!
-f                Disable safety prompt.
-ip <ip>          Bootloader IP address or hostname, default 192.168.178.1
-ram <mb>         Only ram-boot and fit-boot mode: Usable ram size in MB of your device.
                    Without this parameter, the default of 128 MB (FIT: 384) will be used.
                    Some devices like Repeater 3000 need 256 MB to flash.
                    Use '0' to detect and use all available ram.
-lfs <0|1|9>      Not single-boot mode: Set linux_fs_start to 0 or 1 and flash into this.
                    Without this parameter, the inactive linux_fs_start will be used.
                    Use '9' for the currently active linux_fs_start.
-cmd <ftp|ncftp>  Force the prefered usage of ftp or ncftp command for upload.
-hn               Only single-boot mode: Flash to an 'Alice/HanseNet' version of 7570.
Edit: Hilfe von aktuellem checkout aktualisiert.
 
Zuletzt bearbeitet:

NDiIPP

IPPF-Promi
Mitglied seit
13 Apr 2017
Beiträge
4,834
Punkte für Reaktionen
923
Punkte
113
Aus der Beschreibung kann ich nicht erkennen, ob man mit diesem Tool auch TFFS-Images in mtd3/4 bzw. mtdnand hochladen kann. Ist das möglich? Wenn ja, wie?
 

hippie2000

Neuer User
Mitglied seit
20 Jan 2008
Beiträge
144
Punkte für Reaktionen
59
Punkte
28
@NDiIPP Kann man schon, das Programm heisst push_firmware und nicht push_config. :)

Ich bin seit 10 Jahren mir den Mund am franselig reden gegen die mtd/3/4 cleaner, und der Spur von entwerteten Boxen, und sage wie immer: Nor eine AVM Recovery weiss je Modell am besten wie das TFFS schadfrei restauriert wird. Es gab nie und es wird so schnell kein Tool geben mit dem modellübergreifenden Knowhow das Schaden abwendet. Bis das hinreichend erforscht ist betrachte ich TFFS Gefrickel als Brachialmurks.

Aber auf dem Gebiet rede ich seit 10 Jahren gegen Betonmauern und die Unsitte diese zerstörerische Funktion in jedes Tool reinzuknallen ist nicht auszulöschen. Auf keinen Fall will ich die Forschung von PeterPawn diskreditieren, im Gegenteil. Aber das sind Werkzeuge die einnfach nicht für Average-Joe geeignet sind und auch ohne das notwendige Modellwissen gefährlich sind.

Zu push_firmware: Ziel ist es jedes Modell möglichst genau so zu flashen wie AVM es in der Recovery macht, aber ohne Restauration des TFFS. Ich werde da auch versuchen mit einem Recovery-Scanner zu ermitteln ob man die Methode erscannen kann um evtl. eine HWR zu Flash-Methode Automatik für push_firmware zu implementieren. Wie alle Software ist auch push_firmware noch ausbaufähig und enthält sicher auch noch Fehler. Insgesamt ist es gefährlich dass es keine Anleitung gibt wie man welches Modell am besten Flasht, bei keinem mir bekannten Tool modellübergreifend.
 

NDiIPP

IPPF-Promi
Mitglied seit
13 Apr 2017
Beiträge
4,834
Punkte für Reaktionen
923
Punkte
113
@NDiIPP Kann man schon, das Programm heisst push_firmware und nicht push_config. :)
Lustigerweise kann "eva_store_tffs" nicht nur TFFS-Images sondern auch Firmware-Images hochladen. ;)

Mir ging es nicht darum zu diskutieren ob es (in diesem Fall) sinnvoll ist TFFS-Image hochzuladen, sondern ob es prinzipiell mit diesem Tool möglich ist. Denn so "universell" ist es dann wohl doch (noch) nicht.

Aber BTW:
Bis das hinreichend erforscht ist betrachte ich TFFS Gefrickel als Brachialmurks.
Schlimmer finde ich es (aka "Brachialmurks"), wenn man (wie bspw. das ehm rKT oder einige andere hier mal im Forum angebotene Scripte) mtd3+4 "nullt" anstatt ein gültiges TFFS-Image hochzuladen. Und BTW, für einige Modelle gibt es auch bis heute keine Recovery-Tools von AVM, von denen man ein "ordentliches" TFFS-Image hätte erstellen und hochladen können.
 
Zuletzt bearbeitet:

hippie2000

Neuer User
Mitglied seit
20 Jan 2008
Beiträge
144
Punkte für Reaktionen
59
Punkte
28
Auch wenn du noch so viel TFFS cleaner Promo machst, es ist ein Relikt von vor 15 Jahren und mindestens seit 10 Jahren als dümmste aller Lösungen eines Problems bekannt. Wenn du nichts dagegen hast finde ich zur Topic des Threads zurück. Wir versuchen gerade konkrete Herausforderungen zu lösen die keine frei verfügbare Software auf der Welt bisher löst - auch kein tffs cleaner. So ein Quatsch das heute noch zu promoten. Jede Software die das als Nebenfearure (für "Universalität") implementiert betrachte ich als gefährliche Malware.

Also, back to Topic: fitimg ist immer noch buggy, ich hab heute 3 bugs gefunden die sehr wahrscheinlich die Funktion modifizierter Firmware verhindern. Siehe History im Artikel auf BoxMatrix.
fitimg 0.1 wurde im Januar 167x runtergeladen, Version 0.2 sogar 272x. Es scheint also Interesse zu geben an Software die nicht tffs bügeln kann.

Die Bugs werde ich in 0.3 fixen. Ich hab leider keine 7530ax sonst könnte ich selbst prüfen obs funktioniert. Vielleicht finde ich jemand der mir eine leiht.

Natürlich brauche ich modifizierte Firmware um das zu testen, daher wird Hand in Hand mit dem derzeit aktivsten Freetz Fork gearbeitet - Freetz-ng. Natürlich steht das Resuiltat dann jedem Fork zur Verfügung, ist ja freie Software. 0.2 kann man schon als Platzhalter nehmen um Images zu bauen. Die Funktion würde ich erst mit 0.3 testen. Wir arbeiten auch noch am Uploader push_firmware mit der Hoffnung das beides eines Tages funktioniert, so dass man es vergessen kann das Thema...
 
  • Like
Reaktionen: prisrak1

eisbaerin

IPPF-Urgestein
Mitglied seit
29 Sep 2009
Beiträge
10,793
Punkte für Reaktionen
914
Punkte
113

NDiIPP

IPPF-Promi
Mitglied seit
13 Apr 2017
Beiträge
4,834
Punkte für Reaktionen
923
Punkte
113
Auch wenn du noch so viel TFFS cleaner Promo machst, [...]
Hast du wirklich gelesen, was ich geschrieben habe? Ich habe meine Zweifel... Wenn ich dafür wäre (was ich nicht bin, wie ganz richtig von @eisbaerin angemerkt), dann bräuchte man auch kein neues TFFS-Image hochladen (wenn man jetzt nicht eine Null als Image versteht).

Wenn du nichts dagegen hast finde ich zur Topic des Threads zurück.
Nun, ich hatte das "OT-Fass" eigentlich gar nicht aufgemacht. Von daher habe ich auch absolut nichts dagegen. Hatte ja schon in #12 geschrieben, dass es mir eigentlich gar nicht darum ging.
 

hippie2000

Neuer User
Mitglied seit
20 Jan 2008
Beiträge
144
Punkte für Reaktionen
59
Punkte
28
Ich versuche einfach mal meine Arbeit weuterzumachen auch wenn der Thread weiter offtopic gekapert wird:

titimg 0.3 Release:


Neuerungen:

Im FIT steckt bei der 7530ax und dem Repeater 6000 ein kernel-args String je Filesystem, der bisher nicht angepasst wurde, Bsp 7530ax (fitimg -s Auszug):

Code:
0211fb80  hunk 3 #95 [4] - loadaddr = 0x19c00000
0211fb90  hunk 3 #117 [97] - avm,kernel-args = 'mtdram=ram-filesystem,0x19c00000,0x1bb00000 mtdparts_ext=ram-filesystem:[email protected](rootfs_ram)'

Die erste Hexzahl ist die Adresse an die geladen wird, der untere Angang der filesys Partition, das obere Ende der 50MB grossen Partition findet sich im Environment in firstfreeaddress.
Also muss die untere Adresse und die loadaddr nicht geändert werden beim Modifizieren.

Die zweite Hexzahl ist das Ende des Filesystems, gepaddet auf 0x10000 also 1MB. Die dritte Dezimalzahl ist die Grösse des Filesystems.
Die letzten beiden Werte werden nun angepasst wenn das Filesystem ersetzt wird im Replace Modus (-r).
Beim Ersetzen mit den Originaldateien entsteht ein identisches image, das funktioniert also.

Leider hab ich noch kein Supportdata vom Repeater 6000, aber ich nehme an da ist es nicht anders. Das wird dann geprüft sobald ich die Daten habe.

Edit: Die 5530 FIT images enthalren /bisher) keine kernel-args.
 
Zuletzt bearbeitet:

eisbaerin

IPPF-Urgestein
Mitglied seit
29 Sep 2009
Beiträge
10,793
Punkte für Reaktionen
914
Punkte
113

hippie2000

Neuer User
Mitglied seit
20 Jan 2008
Beiträge
144
Punkte für Reaktionen
59
Punkte
28
Analyse der 7530ax Recovery-Methode:

Code:
#7530ax
env: memsize 0x20000000     =>   0x20000000 - 34733863 = 0x1DEE00D9
[[fit-image]]: 34733863 = 0x211FF27

SETENV memsize 0x1dee0000
SETENV kernel_args_tmp "avm_fwupdate mtdram1=0x1dee0000,0x20000000 mtdparts_ext=update-image.0:[email protected](fit-image)"
TYPE I
MEDIA SDRAM
[email protected]
STOR 0x1dee0000 0x20000000

Im Gegensatz zu den kernel-args im fit-image bleibt hier die zweite Hexzahl endaddr statisch, und nimmt den Ortiginalwert von memsize im Environment an.
Die erste Hexzahl startaddr ist der Ortiginalwert von memsize minus der Grösse des fit-image, nach unten gepadded auf 0x10000 boundaries / 64kB.
Dieser Wert wird dann auch in memsize geschrieben um den belegten oberen Teil des Speichers zu schützen.
Das ist eine historische Methode mit der schon beim C64 BASIC-Variablen angelegt wurden. ;-)
Die dritte Hexzahl imgsize ist die Grösse des fit-image, wieder mit Padding auf 64kB.
Da EVA nun nicht wissen kann wie gross das eigentliche fit-image ist muss der Upload auch auf 64kB boundariies gepaddet werden.

Natürlich gibt es try and error Methoden die auch meistens funktionieren. Aber ich schlage vor wir orientieren uns an AVM und sind für immer bulletproof.

Da Freetz-ng weiss dass es ein fit-image gebaut hat könnte diese Methode nun in push_firmware ohne Argumente eingebaut werden.

Langfristig könnte man alle Flashmethoden automatisch erkennen, man hat Zugriff aufs install Script und da steht alles je Firmware drin.

Edit: Details in english language can be found here:

boxmatrix.info/wiki/FIT-Image#Research
 
Zuletzt bearbeitet:
  • Like
Reaktionen: prisrak1

prisrak1

Mitglied
Mitglied seit
14 Mai 2017
Beiträge
412
Punkte für Reaktionen
36
Punkte
28
super Arbeit! wie könnte der vollständige Befehl für die Methode nun in push_firmware lauten? Danke!

z.B. für die 7590 etwa so -> make push_firmware -mr 7590.image ( <0|1|9> ist klar)
-mf oder -ram <mb> je nach dem, was gebraucht wird?
 
Zuletzt bearbeitet:

hippie2000

Neuer User
Mitglied seit
20 Jan 2008
Beiträge
144
Punkte für Reaktionen
59
Punkte
28
@prisrak1 : Das wird jetzt erst eingebaut. Ziel wird es langfristig zu erreichen dass eben kein Wissen mehr notwendig ist und man einfach push_firmware aufruft.
Ein image muss man jetzt schon nicht mehr angeben, es wird automatisch das letzte gebaute verwendet.
Heute wurde fitimg 0.3 in Freetz-ng gebumped. An der Anpassung von push_firmware wird noch gearbeitet. Ich halte euch auf dem Laufenden.
 
  • Like
Reaktionen: prisrak1

Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

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.
oder via