[Info] Wie funktioniert eigentlich das Signieren der AVM-Firmware?

[B612]

mktemp: not found

Ist in den busyboxen von Peter vorhanden.

 

[PeterPawn]

busyboxen von Peter

Das ist korrekt.

Ich habe dennoch im Branch signimage eine neue Version eingecheckt (und zumindest den Zweig bei mir getestet, wenn das mktemp vorhanden ist auf dem System) - jetzt wird ein fehlendes mktemp auch emuliert: https://github.com/PeterPawn/YourFritz/commit/f5c6ae0c2e6c567270c4882aba1ca2354b70121a

Die verwendeten Routinen stammen aus meinem Framework - die sind also einigermaßen ausführlich getestet, auch wenn der Rest der Funktionen aus dem Framework hier nicht eingeschlossen ist. Um diese Versionen zu verwenden, muß man das Download-Kommando im FRITZ!OS (das httpsdl) so ändern, daß anstelle des main da ein signimage in der URL steht (also am Ende zweimal signimage hintereinander - einmal für den Branch und einmal das Unterverzeichnis).

 

[Insti]

bekomme jetzt den Fehler

# YF_SIGNIMAGE_OPENSSL=/var/openssl /var/check_signed_image /var/7530_729signed.image -b
Found OpenSSL 1.0.2u  20 Dec 2019
Check dgst command ... OK
Check rsautl command ... OK
The option -b may only be used on a FRITZ!OS device.

 

[PeterPawn]

Rufe das mal mit sh -x zwischen der Variablen am Anfang und dem Skript-Namen auf und poste die Ausgabe (ist etwas länger). Sieht so aus, als wäre meine "FRITZ!Box-Erkennung" etwas zu selektiv - die stammt noch aus der Zeit, wo es nur MIPS- und ATOM-Systeme gab bei AVM, die ich im Sinn haben mußte und noch keine ARM-basierten.

EDIT: Ich sehe gerade, daß das bei Dir wohl am Vergleich zwischen HWRevision (im Shell-Environment) und dem Wert im Urlader-Environment (der heißt halt auch HWRevision) scheitern wird, wenn das auf einer 7520 läuft, wo der Wert aber im FRITZ!OS auf 7530 gesetzt wurde. Kommentiere mal die Zeile 183 in check_signed_image aus (# in Spalte 1 - die Zeilennummer bezieht sich auf den Branch) und probiere es dann noch einmal.

 

[Insti]

Jetzt hat es geklappt, aber es wird kein Key gefunden.

# YF_SIGNIMAGE_OPENSSL=/var/openssl /var/check_signed_image /var/media/ftp/USB-DISKPro-01/7530_729signed.image -b
Found OpenSSL 1.0.2u  20 Dec 2019
Check dgst command ... OK
Check rsautl command ... OK
Trying to determine the correct key now ...
Checking the public key from /etc/avm_firmware_public_key1 ... FAILED
Checking the public key from /etc/avm_firmware_public_key2 ... FAILED
Checking the public key from /etc/avm_firmware_public_key3 ... FAILED
Checking the public key from /etc/avm_firmware_public_key9 ... FAILED
No usable public key was found.
# mount -o bind /etc/avm_firmware_public_key9 /etc/avm_firmware_public_key1
# YF_SIGNIMAGE_OPENSSL=/var/openssl /var/check_signed_image /var/media/ftp/USB-DISKPro-01/7530_729signed.image -b
Found OpenSSL 1.0.2u  20 Dec 2019
Check dgst command ... OK
Check rsautl command ... OK
Trying to determine the correct key now ...
Checking the public key from /etc/avm_firmware_public_key1 ... FAILED
Checking the public key from /etc/avm_firmware_public_key2 ... FAILED
Checking the public key from /etc/avm_firmware_public_key3 ... FAILED
Checking the public key from /etc/avm_firmware_public_key9 ... FAILED
No usable public key was found.
#

 

[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.

[...] Wenn diesbzgl. neue Erkenntnisse vorhanden sind, folgt Meldung.

Also der Eigentümer der betreffenden Box hatte leider noch keine Zeit/Lust, sich der Sache anzunehmen. Er hat jetzt das Update per Freetz-WebIf durchgeführt, was ohne Probleme ging. Daher kann ich bzgl. der Problemfindung derzeit leider nicht weiter behilflich sein.

 

[PeterPawn]

@Insti:
OK, das war jetzt mit dem Skript und man könnte das ja auch noch mit dem AVM-Programm verifizieren. Nur wird das wohl am Ergebnis nichts ändern - offenbar steht in der 9 der falsche öffentliche Schlüssel. Vielleicht überprüfst Du ja doch noch einmal, ob das richtige Schlüsselpaar verwendet wurde beim Signieren.

Man kann sich mit openssl den verwendeten Modulus anzeigen lassen, wenn man den privaten Schlüssel hat. Ich erzeuge unten im ersten Schritt einen neuen, die von mir üblicherweise verwendeten liegen nicht im Home-Verzeichnis - allerdings sollte man das auch nicht so wie gezeigt nachmachen mit dem Generieren, wenn man die "richtigen" Keys dort liegen haben sollte ... außerdem geht es ja um den schon existierenden Key und die Datei im laufenden FRITZ!OS auf der Box. Das openssl rsa kann man auch auf der Box aufrufen, wenn man es - wie weiter oben gezeigt - von irgendwoher geladen hat - dann muß man nur den privaten Schlüssel auch irgendwie auf die Box bringen (und ihn danach auch wieder löschen).

peh@vidar:/tmp/7530_test> /home/GitHub/YourFritz/signimage/generate_signing_key
Found OpenSSL 1.1.1l  24 Aug 2021
Check genrsa command ... OK
Enter a password for the generated key:
Generating RSA key as /home/peh/image_signing.key ... OK
Extracting public key to /home/peh/image_signing.pem ... OK
Extracting public key in AVM format to /home/peh/image_signing.asc ... OK

You should copy the file /home/peh/image_signing.asc to your firmware
image as /etc/avm_firmware_public_key9 to use it for image verification
with AVM components.
peh@vidar:/tmp/7530_test> openssl rsa -in ~/image_signing.key -modulus -noout
Enter pass phrase for /home/peh/image_signing.key:
Modulus=EA8C873373CCB0E92D4ACB811672D1CBA64DC052CAF2FE7DACCF542F69C0FBA4D370527B01AC3EEED2EC8C2E49C0851265CE6CB71E1E9731EC799E1520304399A95F55067BC2C35777BB08F1C6720FFD8A486FC9A46EF7263CD9CC51220B95C142FF0015D6AC8F9C833742B91C70C73E333BF4EB1D6E45E25797F3D43A5829E9
peh@vidar:/tmp/7530_test> cat ~/image_signing.asc
00ea8c873373ccb0e92d4acb811672d1cba64dc052caf2fe7daccf542f69c0fba4d370527b01ac3eeed2ec8c2e49c0851265ce6cb71e1e9731ec799e1520304399a95f55067bc2c35777bb08f1c6720ffd8a486fc9a46ef7263cd9cc51220b95c142ff0015d6ac8f9c833742b91c70c73e333bf4eb1d6e45e25797f3d43a5829e9
010001
peh@vidar:/tmp/7530_test>

Bei Dir muß man den dann natürlich mit dem Inhalt der avm_firmware_public_key9 vergleichen - aber wenn es da tatsächlich keinen Unterschied geben sollte, dann weiß ich auch keine plausible Erklärung mehr. Gibt es einen Unterschied, bist Du irgendwo bei der Verwaltung der Keys durcheinander gekommen - das würde dann zumindest erklären, warum bei Dir die Verifikation NIE klappt, egal wie groß die signierten Daten auch sind.

Das erklärt dann zwar das 17-Block-Problem auch noch nicht (weil der Hash-Wert von firmwarecfg stream ja dennoch nicht stimmt), aber zumindest die Tatsache, daß der zwischenzeitliche Versuch mit der Signatur immer am Beginn eines 10K-Blocks bei Dir auch nicht funktionierte. Aber immer einen Schritt nach dem anderen - jetzt wäre erst einmal der oben gezeigte Vergleich der öffentlichen Schlüssel erforderlich.

EDIT: Ich habe die Kommandos und Optionen extra so gewählt, daß man das Protokoll auch problemlos 1:1 zeigen kann, weil die Daten nicht geheimgehalten werden müssen. Der Modulus als Teil des öffentlichen Schlüssels ist gerade dazu da, an andere (zur Prüfung von Signaturen) weitergegeben zu werden.

---

@NDiIPP:
Dann lasse ich diesen Fall erst mal außen vor und tue so, als hätte es ihn nie gegeben. Da jetzt zu spekulieren, ob das auch 17 Blöcke im letzten 10KB-Block waren oder nicht, ist müßig ... erst recht, wenn da noch Freetz irgendwo im Spiel ist, denn das sollte noch einmal ganz andere Dateigrößen im resultierenden Image ergeben. Da bei der Freetz-Installation dann ja gar keine Signaturprüfung erfolgt, würde ich auch in diesem Fall einen falschen Schlüssel beim Signieren nicht von vorneherein ausschließen.

 

[Insti]

Ich habe die Kommandos und Optionen extra so gewählt, daß man das Protokoll auch problemlos 1:1 zeigen kann,

Vielen Dank dafür, das passt. Signiere die Firmware seit 7.25 mit gleichem Schlüssel.

root@homeserver ~ > openssl rsa -in /root/image_signing.key -modulus -noout
Enter pass phrase for /root/image_signing.key:
Modulus=E79F594B61964B80CA3BCD0B24E8CA8C69A73138EBAC719C1A8861932DDEEA5FE9CA576B8D260FA24F2A9B86578192E3234A2A49B1C5F56B7191DCF5F2F014A5AC8929789E978484DCF9B4F2EC5887D733C6349D735D7F119222A4DA7DDA8CAEB73525F110E4A2CB5FF8387C713E62E18F059871BA10F74B7963F93A86787AAF
root@homeserver ~ > cat /root/image_signing.asc
00e79f594b61964b80ca3bcd0b24e8ca8c69a73138ebac719c1a8861932ddeea5fe9ca576b8d260fa24f2a9b86578192e3234a2a49b1c5f56b7191dcf5f2f014a5ac8929789e978484dcf9b4f2ec5887d733c6349d735d7f119222a4da7dda8caeb73525f110e4a2cb5ff8387c713e62e18f059871ba10f74b7963f93a86787aaf
010001

Habe jetzt nochmal das kernel.Image + filesystem.image erstellt und den /etc/avm_firmware_public_key9 vor dem zusammenpacken geprüft. Und.....

# for script in check_signed_image sign_image avm_pubkey_to_pkcs8; do httpsdl -n https://raw.githubusercontent.com/PeterPawn/YourFritz/signimage/signimage/$script; chmod a+x $script; ls -l $script; done
ok
-rwxr-xr-x    1 root     root         31773 Nov 17 18:22 check_signed_image
ok
-rwxr-xr-x    1 root     root         26900 Nov 17 18:22 sign_image
ok
-rwxr-xr-x    1 root     root          9103 Nov 17 18:22 avm_pubkey_to_pkcs8
#
# httpsdl -n https://raw.githubusercontent.com/PeterPawn/yf_bin/master/target/armv7l/4.4.60/openssl; chmod a+x openssl; ls -l openssl
ok
-rwxr-xr-x    1 root     root       1571524 Nov 17 18:22 openssl
# rm /var/check_signed_image
# cp /var/media/ftp/USB-DISKPro-01/check_signed_image /var
# YF_SIGNIMAGE_OPENSSL=/var/openssl /var/check_signed_image /var/media/ftp/USB-DISKPro-01/7530_728signed.image -b
Found OpenSSL 1.0.2u  20 Dec 2019
Check dgst command ... OK
Check rsautl command ... OK
Trying to determine the correct key now ...
Checking the public key from /etc/avm_firmware_public_key1 ... FAILED
Checking the public key from /etc/avm_firmware_public_key2 ... FAILED
Checking the public key from /etc/avm_firmware_public_key3 ... FAILED
Checking the public key from /etc/avm_firmware_public_key9 ... OK
Checking support for the used hash algorithm md5 ... OK
Verification succeeded.
#

Es geht wieder!!!
Herzlichen Dank PeterPawn!

Edit:
Die entscheidende ist: touch var/tmp/dummy.image daurch wird die 7.29 installierbar.
Durch das viele probieren der verschiedenen Keys von 3 nach 1 und von 9 nach 1 usw.... hat es einfach zuviel Kuddelmuddel gegeben......meine Schuld und ich habe versucht das Image mit dem falschen Key zu installieren.
@PeterPawn Du bist der Hammer!!! Habe sehr viel gelernt und die ganze Befehle sind notiert

 

[PeterPawn]

Ich habe dennoch mein Test-Skript noch erweitert/geändert (https://github.com/PeterPawn/YourFritz/blob/signimage/signimage/show_signature_problem) und dabei (nun hoffentlich endgültig) herausgefunden, daß es immer dann Probleme mit der Berechnung bei AVM gibt, wenn die Daten so groß sind (und zwar VOR dem Signieren), daß sich beim Teilen ihrer Größe durch 20 (also tatsächlich bei 10 KB-Blöcken) ein Rest von 17 ODER 18 ergibt - der Fall mit "Rest=18" wurde ja bereits gesondert behandelt.

Zwar liest firmwarecfg stream die Daten (nach der strace-Ausgabe zu schließen) am Ende mit 4 KB-Blöcken (also nur Faktor 8) ein, aber irgendwie muß AVM beim Berechnen der Anzahl der Blöcke, die da noch an den Hash-Algorithmus zu übergeben sind, wenn die Daten vor der Signatur-Datei alle schon durch sind, einerseits auch von Blockfaktor 20 ausgehen und andererseits irgendwelche Fehler in der Berechnung haben. Ob man dort dann die Prüfung an eine fehlerhafte Signierung angepaßt hat oder umgekehrt, interessiert letztlich gar nicht - ich habe auch keinen Ehrgeiz das Signieren so zu ändern, daß das Skript genauso falsche Images (aus TAR-Format-Sicht) erstellt, wie man sie hin und wieder bei AVM findet.

Daher bleibe ich beim Auffüllen, wenn die Größe "gefährlich" ist und habe das jetzt auch um den Fall mit "Rest=17" erweitert, dann braucht es natürlich auch zwei Füllblöcke, weil mit einem einzelnen ja wieder der Fall "Rest=18" erreicht wäre. Den zweiten Teil der ursprünglichen Workarounds habe ich auskommentiert - der dort verwendete Blockfaktor von 8 hatte vermutlich irgendetwas mit der Größe beim Lesen durch firmwarecfg zu tun - aber ich weiß nicht mehr genau (und werde aus meinen eigenen Kommentaren auch nur halb schlau), was da der Grund war.

Jedenfalls gibt es bei aktuellen BusyBox-Applets für tar auch kein "short read" mehr und erst recht keinen Exit-Code ungleich 0, wie man mit der aktuellen 7530-Firmware (07.29) leicht ausprobieren kann, denn die hat ja gar keine EoA-Marker, wie ich weiter oben gezeigt habe. Damit ist dieser Workaround, wenn er das "short read" verhindern sollte (und einen vielleicht sogar noch davon beeinflußten Exit-Code), ohnehin obsolet.

Da das mit dem manuellen Hinzufügen einer Datei (das war weiter oben die dummy.image und das ist natürlich auch nur dann sinnvoll, wenn die Größe ohne den zusätzlichen Eintrag zu den kritischen Werten gehört - hier wurde es mit dem zusätzlichen Header dann "Rest=18" anstatt "Rest=17" und das wurde bisher schon richtig behandelt) ja keine Lösung ist, habe ich - wie gesagt - ein paar Änderungen im signimage-Branch eingecheckt - wenn man die aktuell auscheckt und verwendet, sollte das mit dem touch nicht mehr erforderlich sein.

Ich will aber erst noch ein Skript bauen, das die notwendigen Aktionen zum Test des Signierens auf der Box automatisiert, so daß man das beim nächsten Mal nur noch aufrufen muß (inzwischen geht das, weil das httpsdl von AVM mittlerweile auch mit Dateien von GitHub klarkommt, wenn man ihm eine URL ohne weitere Redirections anbietet), wenn es wieder mal irgendwelche Probleme gibt und zu vermuten ist, daß es an der Länge der zu signierenden Daten liegt. Bis ich das habe, bleiben die letzten Änderungen in dem gesonderten Branch stehen und werden noch nicht nach main übernommen.

Wer also irgendwelche Skripte zum Automatisieren der Modifikationen hat, der müßte die zeitweise auf den Branch ändern (entweder gleich beim Klonen mittels git clone -b ... oder nachträglich mit einem git switch signimage - ansonsten werden erst mal noch die alten Dateien verwendet. Wobei der ganze Branch auch wieder entfernt wird (das gehört nun mal zum Prinzip bei dieser Arbeitsweise), wenn er nach main gemerged wurde - also darf man das auch nicht "zu fest" verdrahten bei einer zeitweiligen Änderung. Wie schnell ich mit dem Merge am Start bin, kann ich noch nicht sagen.

 

[PeterPawn]

Merge ist ausgeführt - wer das Signieren auf der Box testen/überprüfen will, kann sich dieses Skript: https://github.com/PeterPawn/YourFritz/blob/signimage/signimage/run_signature_tests auf die Box laden und es aufrufen (sollte für MIPS (div. Kernel-Versionen), Puma6 (ATOM-Core) und ARMv7 funktionieren, solange die Kernel-Version in yf_bin unterstützt wird). Dabei werden dann die Skript-Dateien aus dem Repo geladen und ein zur Plattform passendes OpenSSL-Binary. Dann wird ein Key für die Tests generiert (an einer Stelle, wo nichts überschrieben werden sollte, was man gemeinhin so benutzt) und anschließend wird das Demo-Skript (https://github.com/PeterPawn/YourFritz/blob/signimage/signimage/show_signature_problem) aufgerufen. Das Protokoll kann man dann analysieren, ob bei irgendwelchen Größen der Workaround nicht funktioniert.

 

[B612]

# ./run_signatur_tests
Error downloading binary from https://raw.githubusercontent.com/PeterPawn/yf_bin/master/target/mips/4.9.198/openssl, aborting.

Im Browser kommt auch: 404: Not Found

 

[PeterPawn]

Für diese Kernelversion (wohl eine der neueren für die 7590) gibt es dann keine vorübersetzten Binaries. Da das durchaus der Fall sein könnte, beginnen die Download-Versuche auch direkt damit (inkl. Anzeige, was nicht gefunden wurde). Wenn's auch mit älteren Versionen funktionieren sollte (das meiste ist ohnehin statisch gelinkt , so daß die C-Library keine Rolle spielt), könnte ich einen zusätzlichen Symlink setzen im Repo - neue Binaries stelle ich so schnell nicht bereit (wg. der Lizenzbestimmungen aus der GPL).

 

[B612]

wohl eine der neueren für die 7590

Ja eine 7.27. Ist schon zu neu?
openssl und anderes ist ja vorhanden. Ich bräuchte da gar keinen download. Kann man das nicht umgehen?

 

[PeterPawn]

Einfach die Schleife für den Download der Binaries anpassen oder die "Liste" mit den Namen der zu ladenden Binaries (ist im Moment ohnehin nur eins, nämlich openssl) leeren, bevor man das Skript startet.

YourFritz/signimage/run_signature_tests at 60deb45a11906080365c08c7f7d924abc720f1f2 · PeterPawn/YourFritz

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

github.com

 

[NDiIPP]

@NDiIPP:
Dann lasse ich diesen Fall erst mal außen vor und tue so, als hätte es ihn nie gegeben. ...

Ja, wäre sinnvoll. Denn der "Kreuztest" (Update von modifizierter 7.29 auf die gleiche modifizierte 7.29) hatte keine Probleme verursacht.

Ich habe mir zwar mittlerweile das angeblich zuvor verwendete/installierte 7.28er Image angesehen und darin die gleichen Schlüssel vorgefunden wie im verwendeten 7.29er Image (und ein Test auf meiner GRX5-Box mit tr069fwupdate und temporär hinzugefügtem fraglichem key verlief ebenfalls positiv, also lieferte ein "rc=3" zurück, weshlab ein REST17/18 Problem wohl auch ausgeschlossen werden könnte), aber wer weiß wo das Problem tatsächlich lag... Ich "vergesse" es jetzt auch einfach mal und bitte um Entschuldigung für den mutmaßlichen "Fehlalarm"...