[Sammlung] Wie modifiziere ich die originale Firmware vom Hersteller und wie installiere ich meine eigene dann auf der FRITZ!Box?

[PeterPawn]

Es hängt halt von der Größe der "Eingabedatei" beim (AVM-)Signieren ab. Ich habe in meinem "sign_image" die passenden Maßnahmen zur Umgehung eingebaut:

YourFritz/signimage/sign_image at ed5d2ab931da0ac33e46432eb19ce051ed3e54b6 · PeterPawn/YourFritz

dynamic package management for AVM routers. Contribute to PeterPawn/YourFritz development by creating an account on GitHub.

github.com

Damit sind - nach allem, was ich getestet habe - sowohl die Probleme beim Signieren behoben, als auch das "short read", was bei AVM ab und an mal auftritt. Ich habe jedenfalls danach keine "Klagen" mehr gehört, daß sich durch die Signatur irgendwelche Probleme ergeben hätten oder daß die AVM-Komponenten eine solche Signatur nicht verifizieren konnten.

Die 0,05 ergibt sich daraus, daß bei einer Anzahl von zu signierenden Blöcken, die bei der Division durch 20 einen Rest von 18 ergibt (wo also die zwei Blöcke mit dem Header und dem Inhalt für die Signatur den letzten 10 KByte-Block der Ausgabedatei komplett ausfüllen, weil die ja mit lauter Nullen in die Signatur eingehen müssen), der Platz für die zwei "end of archive"-Blöcke auch noch hinzugefügt werden muß. Weder bei 17 noch bei 19 Blöcken "am Ende" der Daten tritt dieses Problem auf - daher eben nur "in einem von 20 Fällen". Wenn jetzt 3 von 12 Dateien exakt diese Größe aufweisen, ist das eben eine Häufung dieser Fälle, aber deren Wahrscheinlichkeit wird damit nicht größer.

Ich kopiere in diesen Fällen einfach noch einmal den allerersten Block der Image-Datei (das sollte ein Header für das Verzeichnis "./var" sein (das wird zuvor überprüft) und dessen mehrmaliges Auftreten in der Datei ist schon deshalb harmlos, weil das Verzeichnis nicht mehrfach angelegt werden kann und es trotzdem keinen Fehler hervorruft, wenn so ein Header erneut auftritt) in die Ausgabe - damit ergibt sich wieder eine Größe der zu signierenden Daten, bei der die Berechnungen (zur Kontrolle) durch die AVM-Komponenten so funktionieren, wie ich das im zugehörigen IPPF-Thread beschrieben habe.

 

[eisbaerin]

Danke, jetzt habe ich Verstanden, wie du auf die 1 aus 20 = 0,05 kommst.

BTW: Wird es auch ein "decoder" für die IPQ-FB geben?
Ich habe es auf der 7520/30 noch nicht geschafft die *.cfg zu entschlüsseln.
Die binarys laufen nicht und mit den Scripte schaffe ich es auch nicht.

 

[PeterPawn]

Das könnte an einer anderen Handhabung des Environments liegen (ich habe da irgendeine Spezialbehandlung im Kernel-Code für diese Plattform im Hinterkopf, müßte da aber erst noch einmal prüfen) ... ohne 7520/7530 bin ich da auf Input anderer angewiesen, was exakt nicht funktioniert.

Was erhält man denn, wenn man die richtige Version (https://github.com/PeterPawn/decoder/blob/master/bin/decoder.armv7l) von GitHub lädt, ausführbar macht und dann mit "-d" aufruft (zunächst mal egal, welche Funktion es ist)?

Wobei ich die Frage hier eigentlich gar nicht abhandeln will ... wenn Du antworten möchtest, würde ich Dich bitten, das im Thread zu diesem Thema "decoder" zu machen (https://www.ip-phone-forum.de/threa...verschlüsselung-für-die-einstellungen.295101/) und dann hier (und ggf. dort) nur zu verlinken.

 

[Insti]

Guten Morgen zusammen,
kann mir bitte jemand einen verständlichen Tip geben wie man das Script aus #5 signiert? Ist das überhaupt möglich?
Würde das gerne mit einbauen damit man das fertige modifizierte Image über das Webinterface installiert werden kann? Würde mich sehr freuen.

 

[eisbaerin]

Hallo Peter, machst du schon Versuche zu den neuen Boxen (z.B. 7530AX, 5530, 6000) mit der völlig neuen Art beim Installieren (fit-image).
Kann man die auch modifizieren?
Gibt es schon eine Möglichkeit das fit-image auf der FB auszupacken?

 

[PeterPawn]

Nein, das habe ich mir noch nicht genauer angesehen - daher kann ich dazu selbst nichts sagen, weder positiv noch negativ.

Ich habe nur irgendwo gelesen (iirc, war es von @fda89), daß die Tools vom "u-boot"-Projekt nicht zum Zerlegen des AVM-Images genutzt werden konnten.

Solange diese Boxen noch Exoten sind, wird es sicherlich auch schwierig, an die Support-Daten zu kommen - ohne diese (siehe mein letzter Beitrag irgendwo zur 6820v3) sollte man gar nicht erst anfangen, denn das Zerlegen der Images ist nur der erste Teil. Wenn AVM mit dem Umstieg dann doch irgendwann mal mit dem Signieren der Firmware selbst (und nicht nur des Containers zur Installation) beginnt, kann man sich die Box ja auch leicht "zerschießen".

 

[eisbaerin]

Solange diese Boxen noch Exoten sind,

Der Buschfunk berichtet:
Die ersten 7530AX sind heute bei Kunden angekommen.

 

[TomTomNavigator]

Hi,
danke für die hilfreichen Beiträge auf Seite 1!
Kurze Frage: funktioniert die Ausführung von modfs direkt auf der 7530; oder liegt das an mir? Schätze nein - für ersteres.

Guten Rutsch!

 

[PeterPawn]

Nein, auf der 7530 funktioniert "modfs" nicht direkt. Die unterstützten Modelle stehen hier: https://github.com/PeterPawn/modfs/blob/master/modfs#L52 und für andere Modelle braucht es deutlich mehr Änderungen, als nur deren HWRevision-Nummern an der gezeigten Stelle zu ergänzen.

 

[Insti]

Nein, auf der 7530 funktioniert "modfs" nicht direkt.

Auch indirekt funktionieren nicht alle modfs Scripts.

 

[PeterPawn]

Das mag sein ... viele sind ja auch schon von deutlich älteren FRITZ!OS-Versionen übernommen und manche machen bei aktuellen Versionen gar keinen Sinn (mehr) bzw. werden nicht länger benötigt.

Ich halte eigentlich im "modfs"-Thread die Liste der funktionierenden Skripte immer halbwegs aktuell (wenn auch nur noch im Text, also in fortlaufenden Beiträgen, die dann in der Summe den aktuellen Stand wiedergeben - praktisch als eine Art "Event Sourcing") und passe diejenigen, die (aus meiner Sicht) weiterhin nützlich sein könnten für die Allgemeinheit (denn intern verwende ich noch eine erkleckliche Zahl weiterer Änderungen), dann auch an die neuen Versionen an.

Andererseits habe ich ziemlich das Interesse an der Thematik der FRITZ!OS-Modifikationen verloren (daher kommt im Moment auch praktisch kein Commit in einem meiner öffentlichen Repos für irgendetwas Neues) - somit mag meine eigene Einschätzung, was "sinnvoll" ist (und leicht umzusetzen/zu warten, denn ich will mir mit neuen Skripts auch nicht neuen Aufwand ans Bein binden, wenn das dann auf irgendwelchen - für mich exotischen - Modellen nicht funktioniert), nicht immer mit den Interessen anderer korrelieren.

Wenn es für eines der "unterstützten" Skripte ein Problem geben sollte (und das nicht nur mit einer Labor-/Inhouse-Version auftritt, weil mir AVM da zu unstet ist, als daß ich immer sofort Zeit investieren wollte), dann schaue ich mir das auch an und wenn ich eine (vom Aufwand her vertretbare) Lösung sehe, setze ich die um.

Man muß sich auch mal die Historie von "modfs" vor Augen führen ... es war damals für die (zu diesem Zeitpunkt auch noch relativ neue) Plattform der VR9-SoCs gedacht als leichtere Alternative für diejenigen, die sich selbst nicht mit Freetz befassen wollten, weil ich Freetz (in der Gesamtheit) für einen Dino ansah, der den damals existierenden anderen Plattformen nicht das Wasser reichen konnte, womit die Verwendung von Freetz immer mehr zur "Nerd-Spielwiese" geriet und "Normal-User" abgehangen wurden. Das damals "Aktuelle" ging vom Jailbreak beim iOS, mit der Möglichkeit, sich auch aus alternativen App-Stores zu bedienen bis hin zu den GUI der dedizierten NAS-Systeme, die immer mehr Verbreitung fanden und die alle auch ohne die Existenz eines zusätzlichen "Build-Systems" auskamen, bei dem der Benutzer schon einiges an "Spezialkenntnissen" erwerben mußte.

Und exakt dieser Punkt mit dem "es braucht kein weiteres System" war der Aufhänger für die VR9-Systeme und "modfs" - als es auf späteren Systemen dann nicht mehr so einfach war, sich einen Shell-Zugang zu verschaffen (für die VR9-Modelle biete ich das heute noch mit dem Image zum Implantieren von Shell-in-a-Box), hatte/hat auch "modfs" einiges von seiner Daseinsberechtigung verloren, denn wenn ich ohnehin ein weiteres System brauche, um die Images zu erstellen, kann ich eigentlich auch gleich zu Freetz (oder etwas ähnlichem) greifen.

Auch das "run_modscripts" wurde ja nur nachträglich als Beispiel nachgeschoben, wie man die einzelnen Änderungen (die ich ja absichtlich in gesonderte Dateien ausgelagert hatte - "modfs" war schon immer nur das "Framework" für deren Anwendung und die von mir bereitgestellten waren ursprünglich auch nur als Beispiele gedacht) auf einen bereits entpackten Inhalt der AVM-Firmware loslassen könnte.

Man muß/sollte seine "Erwartungen" an "modfs" also auch daran ausrichten, was ich selbst mit diesem Projekt erreichen wollte - auch wenn ich am Beginn noch weitergehende Pläne hatte, die ich dann halt (zuerst für die 7390, wo das gleich an mehreren Faktoren scheiterte, es "sicher" zu implementieren - nämlich am geringen Angebot an Ressourcen (bis hin zum RAM) und am "alternativen" System im (NOR-)Flash) jeweils beerdigen mußte, wenn die "richtigen Schwierigkeiten" auftauchten.

Dazu (zu den eingestampften Plänen) gehört auch die Unterstützung weiterer FRITZ!Box-Modelle - wenn es keine einfache Möglichkeit gibt, ein "Starter-System" (ohne die Verwendung von urheberrechtlich geschützten Programmen von AVM) auf die Box zu bringen, mit dem man den für "modfs" nun mal erforderlichen Shell-Zugriff erlangt, macht es auch keinen Sinn, das "finale System" in zwei Schritten zu erstellen, wenn es auch in einem einzelnen (halt nur auf einem externen, zweiten System, was dann zur Voraussetzung wird) machbar ist.

 

[eisbaerin]

denn wenn ich ohnehin ein weiteres System brauche, um die Images zu erstellen, kann ich eigentlich auch gleich zu Freetz (oder etwas ähnlichem) greifen.

Sehe ich nicht ganz so.

Ich habe es gerade geschafft run_modscripts auf einem RasPi2B auszuführen.
Da würde ein Freetz viel zu lange laufen.
Vorteile des RasPi sind mehr RAM (1GB) und daß ich mir meine aktive FB nicht abschieße, was bei un/mksquashfs schon mal wegen zu wenig RAM vorkommen kann.

Ich habe das run_modscripts auch etwas ergänzt, so daß jetzt auch ein precheck und postcheck mit entsprechenden Fehlermeldungen und Abweisungen erfolgt.
Das hat auch den Vorteil, daß einige modscripts nur bei ausgewählten FBs angewendet werden.

 

[Insti]

Wenn es für eines der "unterstützten" Skripte ein Problem geben sollte (und das nicht nur mit einer Labor-/Inhouse-Version auftritt, weil mir AVM da zu unstet ist, als daß ich immer sofort Zeit investieren wollte), dann schaue ich mir das auch an und wenn ich eine (vom Aufwand her vertretbare) Lösung sehe, setze ich die um.

Es wäre schön wenn du dir das sign_image Script anschaust. Ich kenne mich zu wenig aus und denke das funktioniert nur bei Images für VR9 Router (wrapper Partition?)
Ich kann das auch ausführen aber das Image wird nicht signiert.

root@ubuntu /opt/Fritzbox-Image7530 > bash YourFritz/signimage/sign_image var.tar > 7530.image
Found OpenSSL 1.1.1  11 Sep 2018
Check dgst command ... OK
Check rsa command ... OK
Verify hash algorithm md5 is supported ... OK
Enter the password for the signing key:
Check the password for the private key file ... OK
Signing the image hash (md5) with RSA key from /root/image_signing.key ... OK
Copying resulting image to output ... OK
root@ubuntu /opt/Fritzbox-Image7530 > bash YourFritz/signimage/check_signed_image 7530.image /root/image_signing.asc
Found OpenSSL 1.1.1  11 Sep 2018
Check dgst command ... OK
Check rsautl command ... OK
The specified image file 7530.image contains no signature file.
root@ubuntu /opt/Fritzbox-Image7530 >

Habe in deinem Script auch die Sektion mit der TAR Prüfung auskommentiert gehabt, aber das hat nicht wirklich viel gebracht und endete in einer Fehlermeldung.

als leichtere Alternative für diejenigen, die sich selbst nicht mit Freetz befassen wollten, weil ich Freetz (in der Gesamtheit) für einen Dino ansah,

Sehe es genauso und möchte mich auch nicht mit Freetz beschäftigen.
Danke!

 

[PeterPawn]

Das hat aber eigentlich nichts mehr mit "modfs" zu tun ... aber wenn man sich die beim Signieren entstehende Ausgabedatei ansieht, sollte da eigentlich ein Member "./var/signature" enthalten sein. Genau den findet das "check_signed_image" dann nicht - also wäre der erste Schritt die Überprüfung (mittels "tar -tvf 7530.image"), ob der Member tatsächlich fehlt oder nicht. Damit weiß man wenigstens, wo man suchen muß - beim Signieren oder bei der Prüfung.

Abgesehen davon verstehe ich nicht, was:

Habe in deinem Script auch die Sektion mit der TAR Prüfung auskommentiert gehabt, aber das hat nicht wirklich viel gebracht und endete in einer Fehlermeldung.

heißen soll - ich gehe davon aus, daß berichtete Fehler immer mit der originalen Datei, so wie sie von mir bereitgestellt wird, aufgetreten sind.

Ich kann mir auch fast nicht vorstellen, daß es tatsächlich ein Fehler in den Skript-Dateien ist - meines Wissens funktionieren die unter Freetz (wo sie 1:1 eingesetzt werden, nur der SheBang wird auf "/bin/bash" geändert) weiterhin klaglos. Ich rate mal, daß da beim Zusammenpacken ein falscher Aufruf verwendet wurde - da wäre es natürlich hilfreich, wenn man mal den gesamten Ablauf (auch den Teil vor dem Signieren) sehen würde.

 

[Insti]

wenn man mal den gesamten Ablauf (auch den Teil vor dem Signieren) sehen würde.

Spoiler: 7530buildlog

root@localhost:~# cd /opt/Fritzbox-Image
root@localhost:/opt/Fritzbox-Image# git clone --recurse-submodules https://github.com/PeterPawn/YourFritz.git
Cloning into 'YourFritz'...
remote: Enumerating objects: 118, done.
remote: Counting objects: 100% (118/118), done.
remote: Compressing objects: 100% (70/70), done.
remote: Total 3483 (delta 73), reused 83 (delta 45), pack-reused 3365
Receiving objects: 100% (3483/3483), 4.03 MiB | 1.53 MiB/s, done.
Resolving deltas: 100% (2227/2227), done.
Submodule 'bin' (https://github.com/PeterPawn/yf_bin.git) registered for path 'bin'
Submodule 'first_aid' (https://github.com/PeterPawn/first_aid.git) registered for path 'first_aid'
Cloning into '/opt/Fritzbox-Image/YourFritz/bin'...
remote: Enumerating objects: 99, done.
remote: Counting objects: 100% (99/99), done.
remote: Compressing objects: 100% (78/78), done.
remote: Total 926 (delta 22), reused 90 (delta 19), pack-reused 827
Receiving objects: 100% (926/926), 75.25 MiB | 9.08 MiB/s, done.
Resolving deltas: 100% (180/180), done.
Cloning into '/opt/Fritzbox-Image/YourFritz/first_aid'...
remote: Enumerating objects: 42, done.
remote: Total 42 (delta 0), reused 0 (delta 0), pack-reused 42
Submodule path 'bin': checked out '761344186579a26a7f60791f76f0f938b19b3a44'
Submodule path 'first_aid': checked out '0359a4db07ffb555b5714184f16a2ffd7348955b'
root@localhost:/opt/Fritzbox-Image# git clone --recurse-submodules https://github.com/PeterPawn/modfs.git
Cloning into 'modfs'...
remote: Enumerating objects: 105, done.
remote: Counting objects: 100% (105/105), done.
remote: Compressing objects: 100% (64/64), done.
remote: Total 1710 (delta 59), reused 78 (delta 39), pack-reused 1605
Receiving objects: 100% (1710/1710), 17.22 MiB | 2.52 MiB/s, done.
Resolving deltas: 100% (1150/1150), done.
root@localhost:/opt/Fritzbox-Image# mv modfs/modscripts/ modfs/modscripts.org
root@localhost:/opt/Fritzbox-Image# mv modfs/contrib/modscripts modfs/contrib/modscripts.org
root@localhost:/opt/Fritzbox-Image# mkdir modfs/modscripts
root@localhost:/opt/Fritzbox-Image# cp modfs/modscripts.org/gui_boot_manager_v0.6 modfs/modscripts/
root@localhost:/opt/Fritzbox-Image# cp modfs/modscripts.org/mod_enable_calllog modfs/modscripts/
root@localhost:/opt/Fritzbox-Image# cp modfs/modscripts.org/mod_fixed_branding modfs/modscripts/
root@localhost:/opt/Fritzbox-Image# cp modfs/modscripts.org/mod_telnet_enable modfs/modscripts/
root@localhost:/opt/Fritzbox-Image# cp modfs/modscripts.org/mod_rc_tail_sh modfs/modscripts/
root@localhost:/opt/Fritzbox-Image# wget -q -O var.tar https://download.avm.de/fritzbox/fritzbox-7530/deutschland/fritz.os/FRITZ.Box_7530-07.21.image
root@localhost:/opt/Fritzbox-Image# tar -x -f var.tar
root@localhost:/opt/Fritzbox-Image# rm -r var.tar
root@localhost:/opt/Fritzbox-Image# mv var/tmp/filesystem.image filesystem.image
root@localhost:/opt/Fritzbox-Image# YourFritz/bin/squashfs/$(uname -m)/unsquashfs4-le -no-progress filesystem.image
Found TI checksum (0xED68084B) at the end of the image.
Filesystem on filesystem.image is xz compressed (4:0)
Parallel unsquashfs: Using 1 processor
8325 inodes (9284 blocks) to write


created 7631 files
created 516 directories
created 693 symlinks
created 1 devices
created 0 fifos
root@localhost:/opt/Fritzbox-Image# rm filesystem.image
root@localhost:/opt/Fritzbox-Image# bash YourFritz/signimage/generate_signing_key
Found OpenSSL 1.1.1  11 Sep 2018
Check genrsa command ... OK
Enter a password for the generated key:
Generating RSA key as /root/image_signing.key ... OK
Extracting public key to /root/image_signing.pem ... OK
Extracting public key in AVM format to /root/image_signing.asc ... OK

You should copy the file /root/image_signing.asc to your firmware image
as /etc/avm_firmware_public_key9 to use it for image verification with
AVM components.
root@localhost:/opt/Fritzbox-Image# cp /root/image_signing.asc /opt/Fritzbox-Image
cd modfs/
./run_modscripts ../squashfs-root
cd ..
sed -i '150s/export HWRevision/export HWRevision=236/g' squashfs-root/etc/init.d/rc.conf
root@localhost:/opt/Fritzbox-Image# mv image_signing.asc squashfs-root/etc/avm_firmware_public_key9
root@localhost:/opt/Fritzbox-Image# ls squashfs-root/etc | grep avm_firmware_publ*
avm_firmware_public_key1
avm_firmware_public_key2
avm_firmware_public_key3
avm_firmware_public_key9
root@localhost:/opt/Fritzbox-Image# cd modfs/
root@localhost:/opt/Fritzbox-Image/modfs# ./run_modscripts ../squashfs-root
Running script 'gui_boot_manager_v0.6' ...
      Patching file 'usr/www/1und1/system/reboot.js' ...
      Patching file 'usr/www/1und1/system/reboot.lua' ...
      Patching file 'usr/www/avm/system/reboot.js' ...
      Patching file 'usr/www/avm/system/reboot.lua' ...
      Patching file 'usr/www/avme/system/reboot.js' ...
      Patching file 'usr/www/avme/system/reboot.lua' ...
Finished script 'gui_boot_manager_v0.6', rc=0
Running script 'mod_enable_calllog' ...
Finished script 'mod_enable_calllog', rc=0
Running script 'mod_fixed_branding' ...
Das Branding für das neue System wurde fest auf 'avm' eingestellt.
Finished script 'mod_fixed_branding', rc=0
Running script 'mod_rc_tail_sh' ...
Finished script 'mod_rc_tail_sh', rc=0
Running script 'mod_telnet_enable' ...
Finished script 'mod_telnet_enable', rc=0
root@localhost:/opt/Fritzbox-Image/modfs# cd ..
root@localhost:/opt/Fritzbox-Image# sed -i '150s/export HWRevision/export HWRevision=236/g' squashfs-root/etc/init.d/rc.conf
root@localhost:/opt/Fritzbox-Image# YourFritz/bin/squashfs/$(uname -m)/mksquashfs4-le squashfs-root/ filesystem.image -all-root -no-progress
Parallel mksquashfs: Using 1 processor
Creating 4.0 filesystem on filesystem.image, block size 65536.

Exportable Squashfs 4.0 filesystem, xz compressed, data block size 65536
        compressed data, compressed metadata, compressed fragments, no xattrs
        duplicates are removed
Filesystem size 25160.42 Kbytes (24.57 Mbytes)
        21.72% of uncompressed filesystem size (115822.93 Kbytes)
Inode table size 65498 bytes (63.96 Kbytes)
        22.05% of uncompressed inode table size (297106 bytes)
Directory table size 83676 bytes (81.71 Kbytes)
        37.52% of uncompressed directory table size (223018 bytes)
Number of duplicate files found 5052
Number of inodes 8849
Number of files 7638
Number of fragments 383
Number of symbolic links  694
Number of device nodes 1
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 516
Number of ids (unique uids + gids) 1
Number of uids 1
        root (0)
Number of gids 1
        root (0)
root@localhost:/opt/Fritzbox-Image# mv filesystem.image var/tmp/filesystem.image
root@localhost:/opt/Fritzbox-Image# tar -c -f var.tar var/
root@localhost:/opt/Fritzbox-Image# bash YourFritz/signimage/sign_image var.tar > 7530.image
Found OpenSSL 1.1.1  11 Sep 2018
Check dgst command ... OK
Check rsa command ... OK
Verify hash algorithm md5 is supported ... OK
The end of archive markers at the input file are too large: blocks expected=2, blocks present=6.
The input file will be truncated after the last archive member.
Enter the password for the signing key:
Check the password for the private key file ... OK
Signing the image hash (md5) with RSA key from /root/image_signing.key ... OK
Copying resulting image to output ... OK
root@localhost:/opt/Fritzbox-Image# bash YourFritz/signimage/check_signed_image 7530.image /root/image_signing.asc
Found OpenSSL 1.1.1  11 Sep 2018
Check dgst command ... OK
Check rsautl command ... OK
The specified image file 7530.image contains no signature file.
root@localhost:/opt/Fritzbox-Image# tar -tvf 7530.image
drwxr-xr-x root/root         0 2020-10-19 18:31 var/
drwxr-xr-x root/root         0 2021-01-01 12:16 var/tmp/
-rw-r--r-- root/root  25767936 2021-01-01 12:16 var/tmp/filesystem.image
-rw-r--r-- root/root   3104520 2020-10-19 18:31 var/tmp/kernel.image
-rwxrwxrwx root/root    580088 2020-10-19 18:30 var/tzupdate
-rwxrwxrwx root/root    687460 2020-10-19 18:30 var/sblupdate
-rw-r--r-- root/root       343 2020-10-19 18:31 var/content
-rwxr-xr-x root/root    276012 2020-10-19 18:23 var/regelex
-rwxr-xr-x root/root    275956 2020-10-19 18:23 var/chksum
-rwxr-xr-x root/root     31992 2020-10-19 18:31 var/install
-rw-r--r-- root/root        14 2020-10-19 18:30 var/install-features
-rw-r--r-- root/root      2807 2020-10-19 18:31 var/info.txt
-rw-r--r-- root/root        34 2020-10-19 18:30 var/version
-rw-r--r-- root/root       128 2020-10-19 18:31 var/signature
drwxr-xr-x root/root       128 2020-10-19 18:31 var/
root@localhost:/opt/Fritzbox-Image#

#Bearbeitet wegen copy-paste Fehler

 

[PeterPawn]

Fällt Dir etwas auf, wenn Du den originalen Inhalt von AVM:

peh@vidar:~> wget -q -O - https://download.avm.de/fritzbox/fritzbox-7530/deutschland/fritz.os/FRITZ.Box_7530-07.21.image | tar -t -v
drwxr-xr-x 0/0               0 2020-10-19 18:31 ./var/
-rwxr-xr-x 0/0           31992 2020-10-19 18:31 ./var/install
-rwxrwxrwx 0/0          580088 2020-10-19 18:30 ./var/tzupdate
-rwxr-xr-x 0/0          276012 2020-10-19 18:23 ./var/regelex
drwxr-xr-x 0/0               0 2020-10-19 18:31 ./var/tmp/
-rw-r--r-- 0/0         3104520 2020-10-19 18:31 ./var/tmp/kernel.image
-rw-r--r-- 0/0        25763848 2020-10-19 18:31 ./var/tmp/filesystem.image
-rwxrwxrwx 0/0          687460 2020-10-19 18:30 ./var/sblupdate
-rw-r--r-- 0/0            2807 2020-10-19 18:31 ./var/info.txt
-rw-r--r-- 0/0              14 2020-10-19 18:30 ./var/install-features
-rw-r--r-- 0/0             343 2020-10-19 18:31 ./var/content
-rw-r--r-- 0/0              34 2020-10-19 18:30 ./var/version
-rwxr-xr-x 0/0          275956 2020-10-19 18:23 ./var/chksum
-rw-r--r-- 0/0             128 2020-10-19 18:31 ./var/signature
peh@vidar:~>

und Deinen nach dem tar -c:

root@localhost:/opt/Fritzbox-Image# tar -tvf 7530.image 
drwxr-xr-x root/root         0 2020-10-19 18:31 var/
drwxr-xr-x root/root         0 2021-01-01 12:16 var/tmp/
-rw-r--r-- root/root  25767936 2021-01-01 12:16 var/tmp/filesystem.image
-rw-r--r-- root/root   3104520 2020-10-19 18:31 var/tmp/kernel.image
-rwxrwxrwx root/root    580088 2020-10-19 18:30 var/tzupdate
-rwxrwxrwx root/root    687460 2020-10-19 18:30 var/sblupdate
-rw-r--r-- root/root       343 2020-10-19 18:31 var/content
-rwxr-xr-x root/root    276012 2020-10-19 18:23 var/regelex
-rwxr-xr-x root/root    275956 2020-10-19 18:23 var/chksum
-rwxr-xr-x root/root     31992 2020-10-19 18:31 var/install
-rw-r--r-- root/root        14 2020-10-19 18:30 var/install-features
-rw-r--r-- root/root      2807 2020-10-19 18:31 var/info.txt
-rw-r--r-- root/root        34 2020-10-19 18:30 var/version
-rw-r--r-- root/root       128 2020-10-19 18:31 var/signature
drwxr-xr-x root/root       128 2020-10-19 18:31 var/
root@localhost:/opt/Fritzbox-Image#

miteinander vergleichst?

Hast Du diesen Thread: https://www.ip-phone-forum.de/threa...ignieren-der-avm-firmware.286213/post-2165904 gelesen, speziell diesen Abschnitt:

Will man die erzeugte Datei mit AVM-Komponenten verarbeiten, ist es wichtig, daß das Einpacken der Dateien immer relativ zum Pfad ./var erfolgt. Andere Pfadangaben werden von der AVM-Firmware ausgefiltert und durch den Namen /var/tmp/ignored_tar_content ersetzt, die kriegt man also an seinem Ziel nie zu sehen.

auch gelesen? Ist Dir aufgefallen, daß ich auch hier wieder von der Datei ./var/signature geschrieben hatte?

Ich hoffe, das ist nicht wieder "zuviel Rätselraten", was ich da einfordere ... noch genauer kann man jemanden nicht mit der Nase auf seinen Fehler stoßen und wenn das jetzt wieder zu genau sein und als "offense" angesehen werden sollte, dann weiß ich auch nicht mehr weiter.

====================================================================

Und "by the way" ... wenn Du diesen Fehler korrigiert hast, wirst Du danach beim Aufruf von sign_image auf ein weiteres Problem stoßen (was derzeit vom Skript nur nicht erkannt wird, weil der Aufbau des Tarballs falsch ist), was Dir vom Skript aber auch deutlich "angesagt" werden sollte - ein zu signierendes Image darf nicht bereits eine andere Datei ./var/signature enthalten (die neue Signatur wird ja in jedem Falle hinten angefügt) und Du packst hier auch die (alte) AVM-Signatur wieder brav mit ein.

Je nachdem, um was für eine Version des tar-Kommandos es sich bei Dir handelt (das zeigt ein tar --version üblicherweise), kann es auch notwendig sein, weitere Optionen beim Einpacken anzugeben, beim GNU-tar wäre das üblicherweise noch ein --format=gnu, denn die AVM-Komponenten sind auch hinsichtlich des Aufbaus eines Image-Files einigermaßen wählerisch. Das von Freetz verwendete tar-Applet der BusyBox kennt keine Erweiterungen und erzeugt automatisch das passende Format.

Der merkwürdige Inhalt der letzten Zeile des tar -t -v für Dein selbst erzeugtes Image dürfte nur daraus resultieren, daß der "originale" Dateiname im ersten Eintrag schlicht ein Zeichen zu wenig enthält und damit nach dem "Zusammenbasteln" des TAR-Headers für das Signatur-File noch eine binäre Null zwischen "/var" und "signature" steht, weil ich das direkt nach dem sechsten Byte in den Header schreibe (die ersten sechs Zeichen sollten ja "./var/" lauten, wie man im AVM-Listing sieht).

Warum dann das Ändern des Typs von "Verzeichnis" auf "Datei" nicht klappen soll (https://github.com/PeterPawn/YourFr...c672e3375a781d1080e/signimage/sign_image#L445), erschließt sich mir nicht - ich nehme mal an, daß hier die Ausgabe des tar -t -v lügt und im Header eigentlich auch die erwartete Null für die reguläre Datei steht. Nur ist das halt ein doppelter Name (denn dieselbe Datei existiert ja direkt am Beginn als Verzeichnis) und da könnte es sein, daß die Ausgabe die falschen Daten anzeigt.

Ich werde wohl trotzdem noch einen Test in das Signier-Skript einbauen, ob der erste Member tatsächlich ./var/ und ein Verzeichnis ist - offenbar ist es noch zu einfach, dem Skript eine falsch aufgebaute Datei vorzusetzen, wenn man den Thread nicht (richtig) gelesen hat ... wenigstens hat mich mein "Gefühl", wo das Problem vermutlich liegen dürfte, nicht getrogen.

EDIT:
Ich habe ein paar Änderungen am sign_image vorgenommen - jetzt sollte es darauf hinweisen, wenn beim Einpacken nicht relativ zu ./var gestartet wurde.

========= zusammengefaßt =========

#Bearbeitet wegen copy-paste Fehler

Der Teil:

root@localhost:/opt/Fritzbox-Image# cp /root/image_signing.asc /opt/Fritzbox-Image
cd modfs/
./run_modscripts ../squashfs-root
cd ..
sed -i '150s/export HWRevision/export HWRevision=236/g' squashfs-root/etc/init.d/rc.conf

sieht auch noch komisch aus in #155.

 

[Insti]

Vielen Herzlichen Dank @PeterPawn
Endlich klappt das mit dem signieren und über das Webinterface installieren.

Spoiler: Buildlog7530

root@ubuntu /opt/Fritzbox-Image7530 > wget -q -O var.tar https://download.avm.de/fritzbox/fritzbox-7530/deutschland/fritz.os/FRITZ.Box_7530-07.21.image
root@ubuntu /opt/Fritzbox-Image7530 > tar -x -f var.tar
root@ubuntu /opt/Fritzbox-Image7530 > rm -r var.tar
root@ubuntu /opt/Fritzbox-Image7530 > mv var/tmp/filesystem.image filesystem.image
root@ubuntu /opt/Fritzbox-Image7530 > YourFritz/bin/squashfs/$(uname -m)/unsquashfs4-le -no-progress filesystem.image
Found TI checksum (0xED68084B) at the end of the image.
Filesystem on filesystem.image is xz compressed (4:0)
Parallel unsquashfs: Using 2 processors
8325 inodes (9284 blocks) to write


created 7631 files
created 516 directories
created 693 symlinks
created 1 devices
created 0 fifos
root@ubuntu /opt/Fritzbox-Image7530 > rm filesystem.image
root@ubuntu /opt/Fritzbox-Image7530 > cp /root/image_signing.asc /opt/Fritzbox-Image7530
root@ubuntu /opt/Fritzbox-Image7530 > mv image_signing.asc squashfs-root/etc/avm_firmware_public_key9
root@ubuntu /opt/Fritzbox-Image7530 > cd modfs/
root@ubuntu /opt/Fritzbox-Image7530/modfs > ./run_modscripts ../squashfs-root
Running script 'gui_boot_manager_v0.6' ...
Finished script 'gui_boot_manager_v0.6', rc=0
Running script 'mod_enable_calllog' ...
Finished script 'mod_enable_calllog', rc=0
Running script 'mod_fixed_branding' ...
Finished script 'mod_fixed_branding', rc=0
Running script 'mod_rc_tail_sh' ...
Finished script 'mod_rc_tail_sh', rc=0
Running script 'mod_telnet_enable' ...
Finished script 'mod_telnet_enable', rc=0
root@ubuntu /opt/Fritzbox-Image7530/modfs > cd ..
root@ubuntu /opt/Fritzbox-Image7530 > sed -i '150s/export HWRevision/export HWRevision=236/g' squashfs-root/etc/init.d/rc.conf
root@ubuntu /opt/Fritzbox-Image7530 > YourFritz/bin/squashfs/$(uname -m)/mksquashfs4-le squashfs-root/ filesystem.image -all-root -no-progress
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on filesystem.image, block size 65536.

Exportable Squashfs 4.0 filesystem, xz compressed, data block size 65536
        compressed data, compressed metadata, compressed fragments, no xattrs
        duplicates are removed
Filesystem size 25143.38 Kbytes (24.55 Mbytes)
        21.73% of uncompressed filesystem size (115699.56 Kbytes)
Inode table size 65378 bytes (63.85 Kbytes)
        22.02% of uncompressed inode table size (296897 bytes)
Directory table size 83544 bytes (81.59 Kbytes)
        37.48% of uncompressed directory table size (222906 bytes)
Number of duplicate files found 5052
Number of inodes 8843
Number of files 7633
Number of fragments 383
Number of symbolic links  693
Number of device nodes 1
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 516
Number of ids (unique uids + gids) 1
Number of uids 1
        root (0)
Number of gids 1
        root (0)
root@ubuntu /opt/Fritzbox-Image7530 > mv filesystem.image var/tmp/filesystem.image
root@ubuntu /opt/Fritzbox-Image7530 > rm var/signature
root@ubuntu /opt/Fritzbox-Image7530 > tar -c -f var.tar ./var/
root@ubuntu /opt/Fritzbox-Image7530 > tar -tvf var.tar
drwxr-xr-x root/root         0 2021-01-01 17:40 ./var/
-rwxr-xr-x root/root     31992 2020-10-19 18:31 ./var/install
drwxr-xr-x root/root         0 2021-01-01 17:40 ./var/tmp/
-rw-r--r-- root/root   3104520 2020-10-19 18:31 ./var/tmp/kernel.image
-rw-r--r-- root/root  25747456 2021-01-01 17:39 ./var/tmp/filesystem.image
-rwxrwxrwx root/root    687460 2020-10-19 18:30 ./var/sblupdate
-rwxr-xr-x root/root    275956 2020-10-19 18:23 ./var/chksum
-rw-r--r-- root/root        14 2020-10-19 18:30 ./var/install-features
-rw-r--r-- root/root       343 2020-10-19 18:31 ./var/content
-rw-r--r-- root/root        34 2020-10-19 18:30 ./var/version
-rwxrwxrwx root/root    580088 2020-10-19 18:30 ./var/tzupdate
-rwxr-xr-x root/root    276012 2020-10-19 18:23 ./var/regelex
-rw-r--r-- root/root      2807 2020-10-19 18:31 ./var/info.txt

root@ubuntu /opt/Fritzbox-Image7530 > bash YourFritz/signimage/sign_image var.tar > 7530.image
Found OpenSSL 1.1.1  11 Sep 2018
Check dgst command ... OK
Check rsa command ... OK
Verify hash algorithm md5 is supported ... OK
The end of archive markers at the input file are too large: blocks expected=2, blocks present=8.
The input file will be truncated after the last archive member.
Enter the password for the signing key:
Check the password for the private key file ... OK
Signing the image hash (md5) with RSA key from /root/image_signing.key ... OK
Copying resulting image to output ... OK
root@ubuntu /opt/Fritzbox-Image7530 > tar -tvf 7530.image
drwxr-xr-x root/root         0 2021-01-01 17:40 ./var/
-rwxr-xr-x root/root     31992 2020-10-19 18:31 ./var/install
drwxr-xr-x root/root         0 2021-01-01 17:40 ./var/tmp/
-rw-r--r-- root/root   3104520 2020-10-19 18:31 ./var/tmp/kernel.image
-rw-r--r-- root/root  25747456 2021-01-01 17:39 ./var/tmp/filesystem.image
-rwxrwxrwx root/root    687460 2020-10-19 18:30 ./var/sblupdate
-rwxr-xr-x root/root    275956 2020-10-19 18:23 ./var/chksum
-rw-r--r-- root/root        14 2020-10-19 18:30 ./var/install-features
-rw-r--r-- root/root       343 2020-10-19 18:31 ./var/content
-rw-r--r-- root/root        34 2020-10-19 18:30 ./var/version
-rwxrwxrwx root/root    580088 2020-10-19 18:30 ./var/tzupdate
-rwxr-xr-x root/root    276012 2020-10-19 18:23 ./var/regelex
-rw-r--r-- root/root      2807 2020-10-19 18:31 ./var/info.txt
-rwxr-xr-x root/root       128 2021-01-01 17:40 ./var/signature
root@ubuntu /opt/Fritzbox-Image7530 >

Ich konnte das Image über die Weboberfläche flashen.

Es gibt nur ein Problem.....wahrscheinlich ist mir ein Fehler passiert und ich probiere es später nochmal. Bootmanager, Telnet und das Branding ist noch vorhanden so als wären die modscripts nicht durchgeführt worden.

Der Teil:

.sed -i '150s/export HWRevision/export HWRevision=236/g' squashfs-root/etc/init.d/rc.conf

sieht auch noch komisch aus in #155.

Ist für mich ganz neu das du trockenen Humor hast. Finde ich gut!

Danke nochmal!!

 

[PeterPawn]

Da ging es mir aber weniger um den Unterschied zwischen 136 und 236 - hier wollte ich schon darauf hinaus, daß das nach "kopierten Kommandos" aussieht, aber nicht nach "ausgeführten Kommandos" an dieser Stelle in #155.

Und Humor ist eigentlich so gar nicht meins ... wenn dann eher unfreiwillig komisch.

Da Du es aber geschafft hast, auch die Phase, in der ich richtig "angepißt" war ob der vorhergehenden Reaktionen, ohne weitere Eskalation Deinerseits zu überstehen, ziehe ich meinerseits den Hut vor Dir (meine Antwort in #156 war immer noch etwas von bestehendem Mißmut geprägt) und entferne Deinen Eintrag wieder aus meiner "Ignore"-Liste. Damit ist das Thema für mich dann auch vergessen und ich werde mir künftig Anspielungen darauf verkneifen - sieh also #156 in dieser Hinsicht bitte auch als letztes Ansprechen dieses Themas meinerseits (was ich jetzt wg. "intellektueller Redlichkeit" aber auch nicht nachträglich ändern möchte).

=== zusammengeführt ===

das Branding ist noch vorhanden

Der Aufruf von sed ist ja auch "sehr speziell" ... so, wie das oben erfolgt, würde die Änderung nur stattfinden, wenn das export HWRevision auch genau in Zeile 150 der rc.conf steht - jede Änderung der Position durch Änderungen seitens AVM läßt das Kommando ins Leere laufen. Warum genau gibst Du da die Zeilennummer vor? Besser wäre ein sed -i "s|^\(export HWRevision\)\$|\1=236|" oder etwas ähnliches. Damit wird auch nur exakt die eine Zeile gefunden (und nicht die mit "_ATA" und "_BitfileCount" am Ende) und nur wenn die noch unverändert ist (sie also beim "n" auch endet), wird die Änderung vorgenommen.

Allerdings ist das bei der 07.21 wohl tatsächlich Zeile 150 - damit würde ich trotzdem wieder darauf tippen, daß das Image zwar durch die Signaturprüfung des FRITZ!OS kam, aber nicht wirklich installiert wurde bzw. daß dabei dann ein anderer Fehler auftrat. Der erfolgreiche Upload des Images heißt eben leider noch nicht, daß es auch problemlos installiert werden konnte ... wenn Du da das AVM-Skript /var/install verwenden willst, mußt Du wohl noch die Prüfsummen an den Dateien anbringen, denn meines Wissens ist deren Überprüfung immer noch Bestandteil der Kommandos in dieser Datei:

# next: check_files
#! /bin/sh
echo install: ${kversion} check files...
##################################################################################
# firmware Files pruefen
##################################################################################
CHKSUMEXT=""
# skip filesystem if empty
if [ -f /var/tmp/filesystem.image ] && [ $filesystem_size -ne 0 ] ; then
    if ! /var/chksum${CHKSUMEXT} /var/tmp/filesystem.image ; then
        echo "chksum for file /var/tmp/filesystem.image failed."
        echo "set INFO led to off (modul=7, state=1)"
        /bin/update_led_off
        exit $INSTALL_FILESYSTEM_CHECKSUM
    fi
    echo chksum for file /var/tmp/filesystem.image ok
    filesystem_image_size="`ls -l /var/tmp/filesystem.image | sed -e 's/[^0-9]/#/g' | sed -e 's/#\+[0-9]\+#\+\([0-9]\+\).*/\1/'`"
    if [ "${filesystem_image_size}" -gt "${filesystem_size}" ] ; then
        echo "Size of file /var/tmp/filesystem.image bigger than MTD-Size (${filesystem_image_size} > ${filesystem_size})."
        echo "set INFO led to off (modul=7, state=1)"
        /bin/update_led_off
        exit $INSTALL_FILESYSTEM_CHECKSUM
    fi
    echo size for file /var/tmp/filesystem.image ok
fi
if [ -f /var/tmp/kernel.image ] ; then
    if ! /var/chksum${CHKSUMEXT} /var/tmp/kernel.image ; then
        echo "chksum for file /var/tmp/kernel.image failed."
        echo "set INFO led to off (modul=7, state=1)"
        /bin/update_led_off
        exit $INSTALL_KERNEL_CHECKSUM
    fi
    echo chksum for file /var/tmp/kernel.image ok
    kernel_image_size="`ls -l /var/tmp/kernel.image | sed -e 's/[^0-9]/#/g' | sed -e 's/#\+[0-9]\+#\+\([0-9]\+\).*/\1/'`"
    if [ "${kernel_image_size}" -gt "${kernel_size}" ] ; then
        echo "Size of file /var/tmp/kernel.image bigger than MTD-Size (${kernel_image_size} > ${kernel_size})."
        echo "set INFO led to off (modul=7, state=1)"
        /bin/update_led_off
        exit $INSTALL_KERNEL_CHECKSUM
    fi
    echo size for file /var/tmp/kernel.image ok
fi

 

[JokerGermany]

Da das nächste Release für die FB7590 von AVM näher rückt und ich doch so langsam mal von 7.12 gerne wegkommen würde, aber freetz-ng nicht als stabil und zurechnungsfähig genug halte, wollte ich mich mal nach dem Aufwand erkundigen bind und dnsmasq selbst in das orginale Image zu injizieren und vor multid zu starten.
modfs unterstützt diese Box nicht, wenn ich richtig liege, oder?

 

[NDiIPP]

modfs unterstützt diese Box nicht, wenn ich richtig liege, oder?

Direkt nicht, aber indirekt. Aber es bietet sich hierbei auch an, die Modifikationen mit Hilfe von YourFritz vorzunehmen. Muss man ja nicht unbedingt auf der Fritzbox selbst durchführen, wozu ja modfs gedacht war.