[Info] Sammelthema zur AVM FRITZ!Box 7520

[Insti]

Aber das ist alles Spekulation - erst mal exakt feststellen, daß es bei der 07.29 tatsächlich nicht mehr funktioniert

Danke für deine Antwort.
Nutze schon ziemlich lange dein Script und habe den erstellten Key nicht geändert.
Script zu modfs + signieren

Spoiler

cd /opt/Fritzbox-Image
wget -q -O var.tar https://download.avm.de/fritzbox/fritzbox-7530/deutschland/fritz.os/FRITZ.Box_7530-07.29.image
tar -x -f var.tar
rm -r var.tar
mv var/tmp/filesystem.image filesystem.image
YourFritz/bin/squashfs/armv7l/unsquashfs4-le -no-progress filesystem.image
rm filesystem.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
mv image_signing.asc squashfs-root/etc/avm_firmware_public_key9
ls squashfs-root/etc | grep avm_firmware_publ*
YourFritz/bin/squashfs/armv7l/mksquashfs4-le squashfs-root/ filesystem.image -all-root -no-progress
mv filesystem.image var/tmp/filesystem.image
rm var/signature
tar -c -f var.tar ./var/
tar -tvf var.tar
bash YourFritz/signimage/sign_image var.tar > 7530.image
tar -tvf 7530.image
mv 7530.image 7530_729signed.image
rm -r var var.tar squashfs-root

Log vom ausführen des Scripts.

Spoiler

              .-.
        .-'``(|||)
     ,`\ \    `-`.                 88                         88
    /   \ '``-.   `                88                         88
  .-.  ,       `___:      88   88  88,888,  88   88  ,88888, 88888  88   88
 (:::) :        ___       88   88  88   88  88   88  88   88  88    88   88
  `-`  `       ,   :      88   88  88   88  88   88  88   88  88    88   88
    \   / ,..-`   ,       88   88  88   88  88   88  88   88  88    88   88
     `./ /    .-.`        '88888'  '88888'  '88888'  88   88  '8888 '88888'
        `-..-(   )
              `-`


Linux Version 5.4.0-1044-raspi, Compiled #48-Ubuntu SMP PREEMPT Thu Sep 9 15:24:                                                                                           01 UTC 2021
             Four ARM  Processors, 3.9GB RAM, 432.00 Bogomips Total
                                   homeserver

root@homeserver ~ > /opt/Fritzbox-Image/7530.sh
Found TI checksum (0x9622DCBF) at the end of the image.
Filesystem on filesystem.image is xz compressed (4:0)
Parallel unsquashfs: Using 4 processors
9645 inodes (10620 blocks) to write


created 8963 files
created 539 directories
created 681 symlinks
created 1 devices
created 0 fifos
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
avm_firmware_public_key1
avm_firmware_public_key2
avm_firmware_public_key3
avm_firmware_public_key9
Parallel mksquashfs: Using 4 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 25406.46 Kbytes (24.81 Mbytes)
        21.40% of uncompressed filesystem size (118713.74 Kbytes)
Inode table size 75408 bytes (73.64 Kbytes)
        22.17% of uncompressed inode table size (340150 bytes)
Directory table size 98454 bytes (96.15 Kbytes)
        37.14% of uncompressed directory table size (265070 bytes)
Number of duplicate files found 6303
Number of inodes 10192
Number of files 8970
Number of fragments 383
Number of symbolic links  682
Number of device nodes 1
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 539
Number of ids (unique uids + gids) 1
Number of uids 1
        root (0)
Number of gids 1
        root (0)
drwxr-xr-x root/root         0 2021-11-05 20:21 ./var/
drwxr-xr-x root/root         0 2021-11-05 20:21 ./var/tmp/
-rw-r--r-- root/root  26017792 2021-11-05 20:21 ./var/tmp/filesystem.image
-rw-r--r-- root/root   3107080 2021-10-28 18:11 ./var/tmp/kernel.image
-rw-r--r-- root/root        34 2021-10-28 18:10 ./var/version
-rwxrwxrwx root/root    580088 2021-10-28 18:10 ./var/tzupdate
-rw-r--r-- root/root      2807 2021-10-28 18:11 ./var/info.txt
-rw-r--r-- root/root       348 2021-10-28 18:11 ./var/content
-rwxrwxrwx root/root    687460 2021-10-28 18:10 ./var/sblupdate
-rwxr-xr-x root/root     28246 2021-10-28 18:11 ./var/install
-rwxr-xr-x root/root    275956 2021-10-28 18:02 ./var/chksum
-rw-r--r-- root/root        14 2021-10-28 18:10 ./var/install-features
Found OpenSSL 1.1.1f  31 Mar 2020
Check dgst command ... OK
Check rsa command ... OK
Verify hash algorithm md5 is supported ... OK
Checking input file format ... OK
The end of archive markers at the input file are too large: blocks expected=2, blocks present=3.
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
drwxr-xr-x root/root         0 2021-11-05 20:21 ./var/
drwxr-xr-x root/root         0 2021-11-05 20:21 ./var/tmp/
-rw-r--r-- root/root  26017792 2021-11-05 20:21 ./var/tmp/filesystem.image
-rw-r--r-- root/root   3107080 2021-10-28 18:11 ./var/tmp/kernel.image
-rw-r--r-- root/root        34 2021-10-28 18:10 ./var/version
-rwxrwxrwx root/root    580088 2021-10-28 18:10 ./var/tzupdate
-rw-r--r-- root/root      2807 2021-10-28 18:11 ./var/info.txt
-rw-r--r-- root/root       348 2021-10-28 18:11 ./var/content
-rwxrwxrwx root/root    687460 2021-10-28 18:10 ./var/sblupdate
-rwxr-xr-x root/root     28246 2021-10-28 18:11 ./var/install
-rwxr-xr-x root/root    275956 2021-10-28 18:02 ./var/chksum
-rw-r--r-- root/root        14 2021-10-28 18:10 ./var/install-features
-rwxr-xr-x root/root       128 2021-11-05 20:21 ./var/signature
root@homeserver ~ >

Und ... hat AVM jetzt etwas an der Signatur bzw. an deren Prüfung geändert?

Sieht für mich so aus.
Vielleicht berichtet ja noch jemand ob es bei ihm geklappt hat.

 

[erik]

7520 im Lieferzustand mit Recover der 7530 7.29 bearbeitet, zwischendurch per ftp "quote SETENV HWRevision 236" gesetzt, lief einwandfrei durch. Danach alle Update-Such- und Auto-Update Mechanismen unter Anbieterdienste, AVM-Dienste und Firmwareupdate deaktiviert, funktioniert immer noch. Wenn man dann kein Update manuell sucht, blinken auch keine Mobilteile und kündigen ein nicht vorhandenes Update an. Beim nächsten Update lade ich einfach die .image der 7530 auf den Rechner und von dort per Webinterface auf die Box.
Auf https://www.ip-phone-forum.de/threads/sammelthema-zur-avm-fritz-box-7520.302364/post-2366333 ist es gut erklärt.

 

[PeterPawn]

Sieht für mich so aus.

Meine Theorie mit der nunmehr begrenzten Anzahl von öffentlichen Keys, die da probiert werden, kannst Du ja auch selbst prüfen. Einfach den eigenen nicht mit dem Suffix 9 in die Firmware kopieren, sondern mit 1. Damit kann man zwar keine originale AVM-Firmware mehr installieren, aber das will man ja i.d.R. ohnehin nicht, wenn man eine eigene verwendet. Wenn dieses Image sich dann wieder installieren ließe (von der 07.27 oder 07.28 aus), dann könnte/müßte man noch schauen, wie weit AVM das eingegrenzt hat.

Wie man das per Shell-Zugriff prüfen kann und wo man das Protokoll findet (oder zumindest fand, als ich das alles beschrieben habe), steht in dem Thread, wo ich erkläre, wie das Signieren technisch funktioniert und welche Programme bei AVM dazu verwendet werden ([Info] Wie funktioniert eigentlich das Signieren der AVM-Firmware?).

Man kann diese Signaturprüfung auch von der Shell aus machen, ohne die Firmware am Ende tatsächlich zu installieren. Dazu ruft man einfach tr069fwupdate auf (wie genau, steht im erwähnten Thread) - das wird dann zwar einen Fehler melden (weil die Pfade in der /var/install in der zu prüfenden Firmware nicht stimmen bei packet), aber zuvor noch die Signaturprüfung ausführen und protokollieren, mit welchen Dateien das versucht wurde. Notfalls läßt man sich die Versuche, die Schlüssel zu lesen, auch mit strace protokollieren.

 

[Insti]

Einfach den eigenen nicht mit dem Suffix 9 in die Firmware kopieren, sondern mit 1.

Habe es auf 1 probiert und geht auch nicht.
Wenn ich aus der 7.28 ein Image erstelle und signiere geht das zu installieren, aber die 7.29 geht nicht.
Die Prüfung scheint allerdings zu passen:

root@homeserver /opt/Fritzbox-Image > bash YourFritz/signimage/check_signed_image 7530_729signed.image -a /root/image_signing.asc
Found OpenSSL 1.1.1f  31 Mar 2020
Check dgst command ... OK
Check rsautl command ... OK
Checking the public key from /root/image_signing.asc ... OK
Checking support for the used hash algorithm md5 ... OK
Verification succeeded.

 

[NDiIPP]

Konnte problemlos das neue 7.29 der 7530 über das Webinterface der "7520" flaschen.

Also das originale Image von AVM und kein selbst signiertes?

Da aber wieder die Meldung kam, Firmware wäre nicht aktuell, habe ich genau wie zu Beginn das modfs 7.29 in-memory auf "1" installiert.

Also per Bootloader und nicht per Webinterface?

7520 im Lieferzustand mit Recover der 7530 7.29 bearbeitet, zwischendurch per ftp "quote SETENV HWRevision 236" gesetzt, lief einwandfrei durch.

Es geht aber nicht um die Installation (originaler) Images per Bootloader (inkl. Recovery) sondern um die Installation selbst signierter Images per Webinterface, die nun angeblich ein Problem darstellen.

 

[PeterPawn]

Nun ist das ja wahrscheinlich immer eine 7530-Firmware, die da auf einer 7520 installiert werden soll. Da das GUI ja nur noch ein "geht nicht" von sich gibt, kann das durchaus immer noch an anderen Problemen liegen - z.B. einer ausführlicheren oder abgewandelten Prüfung, ob es ein passendes Modell ist.

Ich hatte ja auch geschrieben, daß man sich das Ganze noch einmal neu ansehen müßte, WENN es mit dem Ersetzen der avm_public_key1 wieder funktionieren sollte - dann wäre zumindest eine plausible Theorie, warum das mit der 9 nicht geklappt hat, vorhanden gewesen. Aber genau das ist ja nicht passiert - es geht mit der 1 auch nicht.

Daher würde ich doch weiterhin auf den zweiten und dritten Absatz in #323 verweisen - um wirklich sicher zu gehen, daß das Problem an der Signatur liegt und nicht an irgendetwas anderem, müßte das halt mal jemand auf der Kommandozeile der FRITZ!Box mit den AVM-Utilities testen.

---

Was mir jedenfalls noch aufgefallen ist - beim Signieren behauptet mein Skript, daß da ein NULL-Block zuviel in der Archiv-Datei wäre:

The end of archive markers at the input file are too large: blocks expected=2, blocks present=3.
The input file will be truncated after the last archive member.

Schaue ich mir dann das zum Einpacken verwendete tar-Kommando an (irgendwo weiter vorne), kann ich nicht erkennen, ob das nun ein "ausgewachsenes" GNU-tar ist oder irgendetwas anderes. Ich habe immer wieder darauf hingewiesen, daß man bei Verwendung des GNU-Kommandos noch ein --format=gnu hinzufügen muß bzw. sollte (https://www.ip-phone-forum.de/threa...ignieren-der-avm-firmware.286213/post-2167387 oder auch https://github.com/PeterPawn/YourFr...334094fea4d349fb5de9/signimage/sign_image#L20) - aber ich weiß (ohne einen Blick ins Innere des zu signierenden Files zu werfen) auch nicht, ob das zu dem Problem beiträgt oder nicht.

Jedenfalls ist das ein bekanntes "Problem" auch beim GNU-tar, daß da manchmal zuviele Ende-Blöcke enthalten sind ... bei der Verwendung, für die dieses Kommando und das Format ursprünglich mal gedacht waren (zum Beschreiben von Magnetbändern), spielt die exakte Zahl der Ende-Blöcke auch keine Rolle. Aber AVM hat dieses Format ja "zweckentfremdet" und die "Kunstgriffe" beim Signieren (damit die Signatur auch Bestandteil der Archiv-Datei werden kann, ohne selbst in den signierten Hash-Wert einzugehen) tun dabei ein übriges - damit WIRD die Anzahl dann doch relevant, weil der Aufbau der zu signierenden Datei eingehalten werden muß. Deshalb wird das auch vom Skript explizit getestet und wenn nötig, werden überflüssige NULL-Blöcke entfernt - daher auch die Meldungen des Skripts, die nicht zwangsläufig auf ein Problem hindeuten und auch bei (korrekter) Verwendung von --format=gnu mit der GNU-Version auftreten können.

Aber nachdem offenbar die Prüfung mit check_signed_image auch funktioniert, würde ich nicht zwingend als erstes auf die Signatur tippen, wenn sich die Firmware nicht installieren läßt über das GUI ... aber das KANN natürlich trotzdem so sein. Daher muß das dann halt mal jemand (der das Problem auch hat, denn dazu braucht es ja eine Datei, die per GUI nicht akzeptiert wird) in einer Shell-Session prüfen.

Wenn man Problemen/Warnungen mit dem tar-Format aus dem Weg gehen will, nimmt man am besten gleich das tar-Applet der BusyBox - mit dem wird das letzten Endes auch wieder entpackt auf der Box: https://github.com/PeterPawn/yf_bin...scripts/create_YourFritz_framework_image#L186

EDIT: Ich konnte mich zwar nur schwach erinnern und mußte selbst erst etwas suchen: https://www.ip-phone-forum.de/threa...ne-dann-auf-der-fritz-box.307161/post-2403488 - aber es hätte mich schwer gewundert, wenn ich irgendwo das Signieren erkläre und dabei nicht auch die notwendigen "Zusatzoptionen" für das GNU-tar erwähnen würde (das sähe mir so gar nicht ähnlich, denn ich schreibe lieber einen Satz mehr als einen zu wenig).

 

[Insti]

z.B. einer ausführlicheren oder abgewandelten Prüfung, ob es ein passendes Modell ist.

Ein User von hier hat das auch bei einer echten 7530 probiert ohne Erfolg. Vielleicht meldet er sich ja auch dazu.
Zum Probieren habe ich auch mal kernel.image und filesystem.image von der 7.28 mit das der 7.29 getauscht und jeweils signiert. Das 7.28 lässt sich installieren (von 7.28 aus) das 7.29 allerdings nicht. Diese Prüfung müsste also über das kernel.image und/oder filesystem.image der 7.29 sein.

 

[PeterPawn]

Wenn wir alle Tests und die Ergebnisse beieinander haben, kann man sich ans Überlegen, was da anders sein mag, machen. Ich weise noch einmal darauf hin, daß der einfachste Weg, die URSACHE der Probleme zu finden, der Versuch mit tr069fwupdate auf der Box wäre (irgendjemand wird ja wohl eine Shell haben, wenn er/sie auch das Problem mit der abgelehnten, eigenen Signatur hat) - anschließend kann man die Protokoll-Dateien in /var/tmp auswerten und kann dann auch zuverlässig sagen, ob es nun an der Signatur oder etwas anderem liegt.

 

[B612]

Falls es hilft:
Bei einer 7590 mit Sig7 gab es bei der 7.29 keine Probleme.

 

[NDiIPP]

Bei einer weiteren 7520 mit (modifizierter und entspr. vorh. eigenem Schlüssel) Ver. 7.28 (7530 Alien) und Update auf (ebenfalls modifizierte und selbst signierte) Ver. 7.29 (ebenfalls 7530 Alien) gab es auch dieses Problem. Da die Box jedoch nicht bei mir ist, steht die weitere/tiefere Diagnose noch aus.

Update über Bootloader oder "manuell" wurde bisher noch nicht gemacht, um bei passender Gelegenheit das Problem (wie von @PeterPawn beschrieben/vorgeschlagen) per Konsole noch genauer untersuchen zu können. Wenn diesbzgl. neue Erkenntnisse vorhanden sind, folgt Meldung.

 

[PeterPawn]

Hört sich gut an ... aber man kann den Test durchaus auch noch dann machen, wenn man bereits über den Bootloader die neue Version installiert hat. Solange die Nummer nicht kleiner wird als die installierte, kann man (iirc) die Firmware auch noch einmal installieren.

Wobei das beim Aufruf von tr069fwupdate ohnehin (absehbar) NICHT wirklich installiert würde - das dient nur dem Ermitteln, wo es am Ende klemmt. Die /var/install in einem Firmware-Image hat einen Aufbau, der für tr069fwupdate packet (wie beim DECT-Update z.B. verwendet) NICHT paßt. Daher gibt das dann auch nur einen (erwartbaren) Fehlercode ... aber wenn zumindest mal versucht wurde/wird, dieses Skript auszuführen, dann sind da schon jede Menge Prüfungen erfolgt und das Image hat die bis zu diesem Punkt auch bestanden.

 

[Insti]

aber wenn zumindest mal versucht wurde/wird, dieses Skript auszuführen, dann sind da schon jede Menge Prüfungen erfolgt und das Image hat die bis zu diesem Punkt auch bestanden.

Habe das selbstsignierte Image auf meinen Webserver geladen und in einem Beitrag von dir geschaut wie das angewendet werden kann.

tr069fwupdate packet https://instinto.mooo.....7530.image 2>>/var/media/ftp/usb-01/1.log >>/var/media/ftp/usb-01/2.log

Nach ca. 15 sec erscheint der Promt wieder und auf dem USB Stick sind die Dateien 1.log und 2.log mit 0bytes geschrieben.

Notfalls läßt man sich die Versuche, die Schlüssel zu lesen, auch mit strace protokollieren.

strace kennt das FritzOS nicht.

Danke für Deine Hilfe.

 

[PeterPawn]

Die entscheidenden Daten stehen nicht in STDOUT und/oder STDERR von tr069fwupdate (und das ist es, was Du mit Deinen Umleitungen auf den USB-Stick geschrieben hast), sondern in Dateien mit definierten Namen im tmpfs des FRITZ!OS.

Die exakten Namen der Dateien habe ich auch nicht mehr im Kopf - das steht aber (iirc) alles im Thread, wo ich das Prinzip des Signierens beschrieben habe. Vielleicht ist es am einfachsten, wenn Du Dir den Zeitpunkt des Starts einprägst und dann nach dem Ende des Kommandos die geänderten Dateien (anhand des Zeitstempels findet man die - ls -lrt /var/tmp verwenden, dann stehen die neuesten Dateien hinten in der Ausgabe) ansiehst.

Anhand des Inhalts läßt sich schnell erkennen, was zum gestarteten Kommando gehört und von diesem geändert wurde und was nicht. Das Kommando sieht - ohne die Redirections - für mich erst mal plausibel aus, wobei man das auch problemlos mit einer lokalen Datei aufrufen kann (dann mit file://-Präfix und Pfad (EDIT: direkt) dahinter, der mit einem weiteren Slash beginnt - das sieht immer etwas komisch aus, ist aber syntaktisch korrekt) und dafür nicht über einen HTTP-Server gebieten muß.

EDIT: strace ist natürlich nicht im FRITZ!OS und nicht mal in den angebotenen Binaries in yf_bin enthalten. Aber es ist hier auch (zumindest vorerst) nicht erforderlich - das wäre nur dann der Fall gewesen, wenn man hätte untersuchen wollen, welche Dateien mit öffentlichen Schlüsseln bei der Signaturprüfung gesucht werden (und geöffnet werden sollen). Da es offensichtlich aber nicht an der Verringerung der Anzahl der möglichen Dateien liegt, ist das erst mal nicht unbedingt Priorität und aus den anderen Syscalls, die damit protokolliert würden, kann man - ohne konkrete Hinweise, was man eigentlich sucht - nur wenig Neues entnehmen.

 

[Insti]

findet man die - ls -lrt /var/tmp verwenden,

Habe 2 Dateien die auf die Zeit passen:

# cat /var/tmp/fwsign.log
public num='00a199d98aaa5ff1a8f9a9f8f956930470ae533fd6a4731468acf686cd2234a6ba4ae17798ec93a5862a56baf1ff3741ea13c4fb35a4ca76df9be66eb0b2c0d3d7f271cc061f394f201b62290d8a9d8695735aa3dafb54a43e3521b4df42c5e52188228b8e133079872bdd7357ceb7379336715e9b50f2d2e678dc79e90c231d8f'
public exp='010001'
public num='00b7ad86f7002a3539a54a5c65b42ae58b018a3563e64468a96f13d870a259c668111110390964c06062d198a6ef91b840da862b666a8080760217369cc2e352860abb9d0f30e2e4c13ed0ef4a10b90a6031b5ddef3cf09c08759b3d98dbe4392c6539f6a322cd3cdec115bc737066d54fb82cd59ce066abccd7dfe7c775b96cb1'
public exp='010001'
public num='00f2ee9ffd8556211f5644da48a252b107124b330d4c20dcf3b9bac892924cabaa4df4f53e1c62e3f2aa12a23eb1d770df1520a998078738407e6a71b077f73ba976363836b880b0dd88741bc3b83ab061691226e823404b7fc88ed278d8130fe5336eb925c78f2f8ad7cb87d9586286f768ab3236fa8fb51ae7c4bbe1e041d849'
public exp='010001'
public num='00e79f594b61964b80ca3bcd0b24e8ca8c69a73138ebac719c1a8861932ddeea5fe9ca576b8d260fa24f2a9b86578192e3234a2a49b1c5f56b7191dcf5f2f014a5ac8929789e978484dcf9b4f2ec5887d733c6349d735d7f119222a4da7dda8caeb73525f110e4a2cb5ff8387c713e62e18f059871ba10f74b7963f93a86787aaf'
public exp='010001'
# cat /var/tmp/firmware_stream_result
total=30710272 ret=0 sub_ret=0 sigcrc=d8d637e56fbabfa4ed377e8631e15c82

 

[PeterPawn]

Jetzt müßte man nur noch wissen, welchen Fehlercode das tr069fwupdate am Ende ausgegeben hat (einfach noch ein ; echo rc=$? anhängen an das Kommando). Die fwsign.log zeigt, daß zumindest vier Keys bei der Signaturprüfung durchprobiert wurden - ob einer davon nun paßte, sieht man am erwähnten Fehlercode. Ob der letzte (das dürfte wohl der eigene sein) nun klappte oder nicht, erkennt man am Inhalt der Datei leider nicht - die wäre nur kürzer, wenn einer der Keys zuvor schon genutzt werden konnte. Für den "letzten" sieht man das in dieser Datei leider nicht richtig.

Wenn allerdings parallel dazu keine Dateien /var/tmp/install* existieren, deutet das darauf hin, daß die /var/unpack/install nicht gefunden wurde und/oder nicht aufgerufen. Nun kann es natürlich sein, daß AVM da irgendetwas an den internen Tests, ob es eine gültige Firmware ist oder nicht, gedreht hat - aber warum dann nur bei der 7520/7530? Andere Modelle sollen ja weiterhin funktionieren - auch mit eigener Signatur.

Der Returncode 0 IN der Datei firmware_stream_result müßte aber (nach meiner Erinnerung) schon ein Zeichen dafür sein, daß die Signaturprüfung erfolgreich absolviert wurde (die Gegenprobe mit einer falschen/unsignierten Firmware-Datei ist ja einfach zu machen) und ein vorliegendes Problem erst danach auftrat. Wenn auch eine falsche Firmware-Datei zu einem [...] ret=0 sub_ret=0 [...] in der firmware_stream_result führen sollte, muß man ggf. tatsächlich noch einmal nach der Signatur sehen - ansonsten liegt irgendein anderes Problem vor.

Wobei der Returncode von tr069fwupdate dann auch einen Hinweis geben sollte, wo das Problem liegen könnte - mögliche Werte findet man im Shell-Skript für die DECT-Updates (irgendwas mit "dect" und "upgrade" oder "update" im Namen, den exakten Namen müßte ich auch erst wieder suchen/prüfen - das findet man sehr gut auch alleine) und anhand dieses Ergebnisses kann man dann weitere Tests in Angriff nehmen.

 

[Insti]

(einfach noch ein ; echo rc=$?

# tr069fwupdate packet https://instinto.moo******/*********/7530.image /var/media/ftp/USB-DISKPro-01/729 ; echo rc=$?
rc=203

 

[PeterPawn]

vidar:/home/FritzBox/FB7490/firmware/113.07.28-91757 $ grep -A 3 203 sbin/start_dect_update.sh
        203)
            debug_print "ERROR unbekannter fehler (ftp, http)"
            update_text=${DECT_RETURN_ERROR_OFFLINE}
            ;;
vidar:/home/FritzBox/FB7490/firmware/113.07.28-91757 $

Ist zwar eine frühere Version und ein anderes Modell, aber da wird AVM eher nicht ändern.

Wenn Du jetzt noch den Tipp mit dem file:// aufgenommen hättest und nicht weiterhin https:// verwenden würdest, könnte man auch besser einschätzen, ob es am Ende tatsächlich ein Problem beim Download ist (wie ich es aus der Fehlermeldung ableiten würde -> ERROR_OFFLINE) oder irgendein anderer Fehler. Denn das Minimieren der denkbaren Fehlerquellen gehört auch dazu, ein Problem auf das herunterzubrechen, was tatsächlich die Ursache darstellt - wenn man lokale Dateien verwendet, schließt man alle Netzwerk-Probleme schon mal per se aus.

Was das hier genau sein könnte, wenn es tatsächlich ein Netzwerk-Problem ist (was zu beweisen wäre), kann man dann immer noch überlegen (falls es überhaupt interessiert) - das kann bis zu einem nicht akzeptierten Server-Zertifikat für die TLS-Verbindung gehen. Wobei das eigentlich wieder nicht dazu paßt, daß bei der libfwsign.so angeblich 30710272 Byte vorbeigekommen wären (s.o. in #334).

Vielleicht klappt es ja auch mal mit einem Protokoll, wo man das "alles auf einmal" sehen kann? Ich weiß, das sind mehr als drei Wünsche und das funktioniert nicht mal beim Überraschungs-Ei ... aber vielleicht bin ich ja auch nur zu pessimistisch. Wenn ich jedenfalls raten sollte bei der Interpretation des Fehlercodes, würde ich sagen, daß hier nicht mal der Download funktioniert hat und dann KANN da eigentlich auch keine Signaturprüfung erfolgen - nur sieht man in dieser Form eben nicht, was da an Ergebnissen tatsächlich zueinander gehört und was nicht.

Und wer das dann "verfolgen" will, was an Ergebnissen zusammen kam, muß obendrein noch ständig hoch und runter blättern - was noch Sinn machen KÖNNTE, wenn man dabei sicher sein dürfte, daß die Ergebnisse tatsächlich zueinander passen. Aber das in #336 wird ja ein weiterer Aufruf sein (vorher wurde der Returncode halt nicht ausgegeben) und in der gezeigten Form weiß niemand, was nach DIESEM Aufruf nun in den anderen Protokoll-Dateien stand.

Deshalb sieht ein plausibler und nachvollziehbarer Test halt so aus, daß da zuvor alle in Frage kommenden Dateien gelöscht werden (welche das sind, steht wieder in der Beschreibung, wie das Signieren funktioniert - es wären vier Dateien, iirc), das Kommando mit einer LOKALEN Datei ausgeführt wird (die Begründung dafür steht oben) und danach die Protokoll-Dateien angezeigt werden (am besten mit cat und innerhalb desselben CODE-Blocks, in dem auch der Rest der Session steht). Dann hat man (1) alles beisammen und kann sich (2) sicher sein, daß die jeweiligen Ergebnisse auch zueinander gehören und nicht zwei unabhängige Probleme miteinander vermischt werden, weil man beim Test selbst einen Fehler gemacht hat.

Dann wäre eben auch die vorgeschlagene Gegenprobe noch nützlich (auch das bitte "am Stück" und nicht wieder als Geschnetzeltes) - einfach irgendeine andere originale Firmware (für ein falsches Modell) auf den NAS-Speicher der Box laden, das tr069fwupdate aufrufen und nachschauen, was da am Ende in der firmware_stream_result steht - auch das natürlich alles protokolliert und nicht wirklich nur "nachschauen" ... ein Protokoll ist 100x aussagekräftiger, als jede Prosa (solange man damit nicht erläutern will, was im Protokoll zu sehen wäre und warum das so ist).

 

[Insti]

Original Firmware 7.29

Spoiler: Original Fritz OS

Fritz!Box user: root
password:


BusyBox v1.29.3 (2020-11-19 19:00:39 CET) built-in shell (ash)

ermittle die aktuelle TTY
tty is "/dev/pts/0"
Console Ausgaben auf dieses Terminal umgelenkt
disable start/stop characters and flowcontrol
# tr069fwupdate packet file:///var/media/ftp/USB-DISKPro-01/729/FRITZ.Box_7530-07.29.image /var/media/ftp/USB-DISKPro-01/729 ; echo rc=$?
rc=3
# cat /var/tmp/fwsign.log
public num='00a199d98aaa5ff1a8f9a9f8f956930470ae533fd6a4731468acf686cd2234a6ba4ae17798ec93a5862a56baf1ff3741ea13c4fb35a4ca76df9be66eb0b2c0d3d7f271cc061f394f201b62290d8a9d8695735aa3dafb54a43e3521b4df42c5e52188228b8e133079872bdd7357ceb7379336715e9b50f2d2e678dc79e90c231d8f'
public exp='010001'
# cat /var/tmp/firmware_stream_result
total=30709760 ret=0 sub_ret=0 sigcrc=1bbe7981136d832bb7a52fcd7d5d4b85
#

Eigene Firmware

Spoiler: Eigene Firmware

Fritz!Box user: root
password:


BusyBox v1.29.3 (2020-11-19 19:00:39 CET) built-in shell (ash)

ermittle die aktuelle TTY
tty is "/dev/pts/0"
Console Ausgaben auf dieses Terminal umgelenkt
disable start/stop characters and flowcontrol
# tr069fwupdate packet file:///var/media/ftp/USB-DISKPro-01/729/7530.image /var/media/ftp/USB-DISKPro-01/729 ; echo rc=$?
rc=210
# cat /var/tmp/fwsign.log
public num='00a199d98aaa5ff1a8f9a9f8f956930470ae533fd6a4731468acf686cd2234a6ba4ae17798ec93a5862a56baf1ff3741ea13c4fb35a4ca76df9be66eb0b2c0d3d7f271cc061f394f201b62290d8a9d8695735aa3dafb54a43e3521b4df42c5e52188228b8e133079872bdd7357ceb7379336715e9b50f2d2e678dc79e90c231d8f'
public exp='010001'
public num='00b7ad86f7002a3539a54a5c65b42ae58b018a3563e64468a96f13d870a259c668111110390964c06062d198a6ef91b840da862b666a8080760217369cc2e352860abb9d0f30e2e4c13ed0ef4a10b90a6031b5ddef3cf09c08759b3d98dbe4392c6539f6a322cd3cdec115bc737066d54fb82cd59ce066abccd7dfe7c775b96cb1'
public exp='010001'
public num='00f2ee9ffd8556211f5644da48a252b107124b330d4c20dcf3b9bac892924cabaa4df4f53e1c62e3f2aa12a23eb1d770df1520a998078738407e6a71b077f73ba976363836b880b0dd88741bc3b83ab061691226e823404b7fc88ed278d8130fe5336eb925c78f2f8ad7cb87d9586286f768ab3236fa8fb51ae7c4bbe1e041d849'
public exp='010001'
public num='00e79f594b61964b80ca3bcd0b24e8ca8c69a73138ebac719c1a8861932ddeea5fe9ca576b8d260fa24f2a9b86578192e3234a2a49b1c5f56b7191dcf5f2f014a5ac8929789e978484dcf9b4f2ec5887d733c6349d735d7f119222a4da7dda8caeb73525f110e4a2cb5ff8387c713e62e18f059871ba10f74b7963f93a86787aaf'
public exp='010001'
# cat /var/tmp/firmware_stream_result
total=30710272 ret=0 sub_ret=0 sigcrc=d8d637e56fbabfa4ed377e8631e15c82
#

 

[PeterPawn]

Erster Test = Signatur (von AVM) stimmt, Fehlercode 3 kommt aus der /var/install und dürfte an dieser Stelle:

echo install: --assert---------------------------------------------
if ! test -d "/var/tmp" ; then
    echo "Install: Error: Directory '/var/tmp' doesn't exist. --> Abort"
    /bin/update_led_off; echo "set INFO led to off"
    exit $INSTALL_OTHER_ERROR
elif ! test -f "/var/tmp/kernel.image" ; then
    echo "Install: Error: File 'kernel.image' doesn't exist. --> Abort"
    /bin/update_led_off; echo "set INFO led to off"
    exit $INSTALL_KERNEL_CHECKSUM
elif ! test -f "/var/tmp/filesystem.image" ; then
    echo "Install: Error: File 'filesystem.image' doesn't exist. --> Abort"
    /bin/update_led_off; echo "set INFO led to off"
    exit $INSTALL_FILESYSTEM_CHECKSUM
elif test -d "/var/tmp/fs" ; then
    echo "Install: Error: Directory '/var/tmp/fs' already exist. --> Abort"
    /bin/update_led_off; echo "set INFO led to off"
    exit $INSTALL_FILESYSTEM_CHECKSUM
elif test -d "/var/tmp/fs_mtd" ; then
    echo "Install: Error: Directory '/var/tmp/fs_mtd' already exist. --> Abort"
    /bin/update_led_off; echo "set INFO led to off"
    exit $INSTALL_FILESYSTEM_CHECKSUM
fi

zuschlagen, weil die entpackten Dateien unter einem anderen Pfad zu finden wären (beim tr069fwupdate packet wird ein anderer Pfad verwendet als bei einem regulären Update). DAS sollte dann aber auch in den Dateien /var/tmp/install* zu sehen sein.

Zweiter Test = Signatur stimmt offenbar nicht (210 ist ERROR_UNSIGNED) - jetzt wäre es hilfreich (als Gegenprobe), wenn für exakt diese Datei das Ganze auch noch einmal mit meinem check_signed_image-Skript auf der FRITZ!Box getestet würde. Dazu braucht es nur das Shell-File (das funktioniert auch unter FRITZ!OS) und das passende openssl-Binary - letzteres läßt sich selbst übersetzen oder aus meinem yf_bin-Repo laden (die ARM-Version verwenden und zusätzlich vor dem Skript-Aufruf noch probieren, ob das Binary unter FRITZ!OS auch wie erwartet arbeitet).

Dritter Test = ?
Die Idee war ja eigentlich zu prüfen, ob der Teil ret=0 sub_ret=0 in der Zeile der firmware_stream_result schon Auskunft darüber gibt, wenn die Signaturprüfung erfolgreich war oder nicht. Das wäre mit einer falschen(!) originalen Firmware von AVM zu machen gewesen (so hatte ich das auch mehrfach geschrieben) - aber offensichtlich steht da auch im zweiten Test ja immer noch ret=0 sub_ret=0 in der Zeile. Das könnte man jetzt als "getestet" ansehen - offenbar ist das aber immer eine 0, denn ich habe auch in der alten Beschreibung nichts anderes gefunden (auch wenn da die Zeile noch kein sub_ret-Feld enthielt, das hat AVM wohl irgendwann hinzugefügt). Damit wäre dann anzunehmen, daß der Fehlercode 210 auch bei einer originalen Firmware für ein falsches Modell auftritt - das wäre dann also der Code, der bei nicht oder falsch signierter Firmware zu erwarten ist.

Wenn Du schon die Ausgabe jeweils speichern lassen willst (ich bin nicht sicher, ob Du absichtlich auch eine Ausgabedatei beim tr069fwupdate-Aufruf angegeben hast und ich weiß auch nicht sicher, ob das auf der 7520/7530 so funktioniert, weil das eigentlich nur beim Laden von Plugin-Archiven vom AVM-Server verwendet wurde, damit die Datei dann beim nächsten Mal schon lokal vorliegt), dann kann man die auch gleich noch mit der Eingabedatei vergleichen und dabei prüfen, ob irgendwelche Änderungen an der Datei zu sehen wären. Ansonsten braucht es diese Ausgabe gar nicht - der letzte Parameter kann also problemlos weggelassen werden - den gibt es in den allermeisten AVM-Skripts (auch in der mehrfach erwähnten Skript-Datei für die DECT-Updates) in dieser Form auch nicht und ich mußte selbst erst mal suchen, wo das bei AVM jemals so eingesetzt wurde (eben beim bereits erwähnten PLUGINv2-Mechanismus).

---

Aber primär bleibt der Test mit check_signed_image als nächster Schritt - wenn das dann immer noch der Ansicht ist, die Signatur wäre korrekt, dann haben wir hier entweder wieder einen der seltenen "corner cases" gefunden, wo die AVM-Verifikation (wieder mal) nicht mit meiner übereinstimmt oder AVM hat zwischenzeitlich doch etwas bei der Überprüfung geändert und stößt sich jetzt daran, daß mein Skript versucht, die bei AVM "kritischen Dateigrößen" zu vermeiden: https://github.com/PeterPawn/YourFr...34094fea4d349fb5de9/signimage/sign_image#L400, indem es zusätzliche Füllblöcke vor der Signatur hinzufügt. Dann landet die selbst signierte Firmware wohl wieder bei einer "komischen Dateigröße", wo AVM die Prüfsumme zumindest anders berechnet als ich - um es nicht gleich "falsch" zu nennen, obwohl das alles irgendwie nicht wirklich zueinander paßt und AVM sich hier das tar-Format wohl nur als Anhaltspunkt herausgesucht hat, anstatt es konsequent und standardkonform umzusetzen.

Wenn's das wirklich sein sollte und das Protokoll vom Signieren, was weiter oben zu sehen war, immer noch stimmen sollte, fehlt eigentlich die Nachricht: "Repeating first entry as filler ..." in der Ausgabe beim Signieren - also wird da offenbar kein Füllblock eingebaut, weil keiner der beiden Trigger zuschlägt (https://github.com/PeterPawn/YourFr...34094fea4d349fb5de9/signimage/sign_image#L401). Entweder meine Berechnung stimmt dann (immer noch) nicht oder irgendetwas anderes ist faul.

Wenn das sich tatsächlich so festmachen läßt, daß mein Skript die Signatur (auf der Box! - alles andere lasse ich jetzt mal nicht zählen, weil nur so tatsächlich sichergestellt ist (mit einem fortlaufenden Shell-Protokoll), daß keine anderen Fehlerquellen in Frage kommen) als korrekt ansieht und das FRITZ!OS anderer Ansicht ist (wie gesagt: beides bitte nacheinander und für genau dieselbe Datei ausführen), dann brauche ich eine Kopie der Datei VOR dem Signieren, um den Vorgang selbst noch einmal nachvollziehen zu können (angefangen bei den Berechnungen, wann ein Füllblock hinzugefügt werden soll und wann nicht).

Allerdings wäre es dann leicht zu lösen ... da mir das jetzt alles zu viele Unwägbarkeiten sind, würde ich künftig dann einfach dafür sorgen, daß da stets so viele Füllblöcke eingefügt werden, daß die Signatur IMMER an derselben Stelle im letzten Block (mal eine Blocksize von 10240 angenommen) steht. Eigentlich gab es lange Zeit nur eine einzige Bedingung, wann da aufgefüllt werden mußte ... wenn bei einer Blockanzahl von 20 (logischen) Blöcken pro physischem Block (20 x 512 Byte = 10.240 Byte) im letzten Block exakt 18 (logische) Blöcke übrig blieben und die beim Signieren hinzugefügten 2 Blöcke damit den letzten physischen Block exakt ausfüllen würden.

Irgendwann kam dann AVM wieder mal mit einer originalen Firmware um die Ecke, die beim Entpacken durch das BusyBox-tar ein "short read" lieferte, weil es nach dem Signieren durch AVM nicht genug NULL-Blöcke am Ende gab, um das Dateiende korrekt anzuzeigen (wie es der Standard definiert). Da erst habe ich einen weiteren Test hinzugefügt (https://github.com/PeterPawn/YourFr...d88073b353101b65b5a56f03f4f0ed23e145654bcc2cf) - der könnte allerdings immer noch falsch sein und den gibt es eigentlich nur, weil ich selbst vermeiden wollte, daß von meiner Lösung signierte Dateien auch dieses "short read" triggern können.

Warum da jetzt 4K-Blöcke genommen werden, weiß ich mittlerweile auch nicht mehr genau (da würden zwei weiteren 512-Byte-Blöcke von mir eingefügt, wenn die originale Blockanzahl bei der Division durch 8 (8 x 512 = 4K bzw. 4096) den Rest 5 oder 6 ergibt) - aber der Witz ist ja, daß das hier in diesem Fall eigentlich keine Rolle spielen KANN, weil dieser neue Zweig ja offenbar auch nicht durchlaufen wird (auch für den fehlt die Nachricht mit dem "filler"). Damit kann diese (fast letzte) Änderung aber auch nicht dafür verantwortlich sein, daß in diesem speziellen Fall die Signatur nicht stimmt - das Ergebnis wäre vor und nach dieser Änderung dasselbe gewesen.

Es muß halt exakt dasselbe Format beim Signieren vorliegen, was AVM bei der Prüfung auch intern erzeugt, wenn die Signatur "überschrieben" wird mit binären Nullen - und da spielt auch die korrekte Dateilänge (wieviele leere Blöcke gibt es am Ende) eine entscheidende Rolle, weil der zu signierende Hash halt über exakt denselben Inhalt gebildet werden muß, sonst kann er nicht stimmen. Alles das, was vor der Signatur in der Datei steht (inkl. meiner zusätzlichen Blöcke, die eigentlich nur den ersten Eintrag für das Verzeichnis ./var/ wiederholen, was in einem Tarball nicht stört), sollte keine entscheidende Rolle spielen (außer daß es halt den Hash beeinflußt) ... auch wenn ich nie getestet habe, ob AVM auch damit klarkäme, wenn die Signatur nicht als letzte Datei im Archiv steht, sondern irgendwo am Beginn oder mittendrin.

 

[PeterPawn]

Ich habe mal eine Änderung in einem neuen/alten Branch eingecheckt (https://github.com/PeterPawn/YourFritz/tree/signimage), bei der in jedem Falle die zu signierende Datei so aufgefüllt wird, daß der letzte komplette 10K-Block bis zum letzten Byte gefüllt wird (da wird dann der erste Verzeichniseintrag ./var/ mehrfach wiederholt) und damit dann der Eintrag für die hinzugefügte Signaturdatei immer am Beginn eines neuen 10K-Blocks steht.

Ob das dann auch in jedem Falle gegen ein "short read" schützt, weiß ich nicht - aber mein Skript zum Signieren schreibt ja in jedem Falle nach der Signatur noch zwei logische Blöcke mit zusammen 1024 Nullen als Dateiende-Marker. Somit sollten sich auch bei einem Blocking-Faktor von 20 (also 10K-Blöcken) im letzten Block immer exakt 2048 Byte befinden (Signatur-Header, Signatur-Inhalt, 2 EOA-Blöcke) - DAMIT sollte der AVM-Algorithmus auch in jedem Falle klarkommen und die zusätzlichen Verzeichniseinträge werden beim Entpacken ohnehin ignoriert.

Zum Testen kann/muß man dann eben den Branch auschecken (wenn man das automatisiert hat, muß man entsprechend ändern) - wenn's damit funktionieren sollte, übernehme ich die Änderung in den regulären Zweig. Das ist zwar immer noch "auf Verdacht" - aber etwas anderes fällt mir beim besten Willen (anhand der aktuell vorliegenden Informationen) auch nicht ein und es ist gar nicht so einfach, sich selbst ein Image mit einer "kritischen" Größe zu bauen.

Aber wenn ich damit das Theater mit den unterschiedlichen Dateigrößen bei der Berechnung des MD5-Hashs ein für alle mal erschlagen kann, sind mir die zusätzlichen Einträge am Ende auch egal.

(@Mods: Ich ziehe das morgen selbst in den vorhergehenden Beitrag um - aber als nachträgliche Änderung wäre die Info wohl eher untergegangen.)