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

[KunterBunter]

Usage screen könnte das sein, was nach dem Aufruf auf dem Bildschirm erscheint.

password ist das Kennwort für den privaten RSA-Schlüssel, der zum Signieren verwendet werden soll.
Wenn es nicht beim Aufruf angegeben und der private Schlüssel mit einem Kennwort gesichert wurde, wird das Kennwort vom Terminal gelesen (ohne Anzeige der eingegebenen Zeichen). Alternativ kann das Kennwort auch über die Environment-Variable YF_SIGNIMAGE_KEYPASSWORD bereitgestellt werden.
Wenn die option -i (lang: --in-place) nicht angegeben wurde, wird die signierte Image-Datei auf STDOUT ausgegeben und der Aufrufer ist dafür zuständig, die Daten per Umleitung an einem passenden Ort zu speichern. Wenn STDOUT ein Terminal sein sollte, wird die Verarbeitung abgebrochen. Bei Verwendung der vorstehenden Option wird die angegebene Image-Datei nach dem zu signierenden Payload abgeschnitten und danach dieser Datei direkt die Signatur (und die notwendigen Blöcke zur Anzeige des Dateiendes) hinzugefügt.

 

[PeterPawn]

Meine dringende Bitte an alle Verwender meiner Software: BITTE nur dann wirklich etwas daran ändern, wenn es UNUMGÄNGLICH ist, weil wirklich etwas fehlt und/oder nicht funktioniert (und man sich ganz, ganz sicher ist, was man da macht, denn man sollte dann keine weitere Unterstützung von mir erwarten für die geänderte Version) - man kann auch mit mir (vernünftig) reden und mich (bei fehlenden Features) versuchen zu überzeugen … bei wirklichen Fehlern erst recht.

HIER sind eigene Änderungen jedenfalls (im Kontext des Anliegens: https://github.com/PeterPawn/YourFr...c28b8081bd24beeb91c43/signimage/yf_sign#L1079) absolut unnötig … aber das allermeiste davon steht (explizit) unter GPL-Lizenz und damit DARF es tatsächlich (unter (Beibehaltung/)Nennung der Quelle und Lizenzbedingungen - das gilt auch für meine "Zusatzbedingungen") jeder ändern, daran macht auch meine BITTE keine Abstriche (um das auch nochmal klarzustellen).

 

[Insti]

Mahlzeit,
Peter kannst du dir bitte yf_genkey anschauen, es kann kein Passwort gesetzt werden und beim signieren gibt es dann einen Fehler.

toni@pi3:~/Fritzbox-Image7530/YourFritz/signimage $ ./yf_genkey

yf_genkey, version 1.0.1

Copyright (C) 2016-2022 P. Haemmerlein ([email protected])

Licensed to you according to GPLv2 or a later version, with some additions.
Please refer to the usage screen for detailed license terms.

Found version: OpenSSL 3.0.16 11 Feb 2025 (Library: OpenSSL 3.0.16 11 Feb 2025) ... OK
Check genrsa command ... OK
Check rsa command ... OK
Generating RSA key (with size of 1024 bits) as /home/toni/.yf_signimage/image_signing.key ... OK
Extracting public key from /home/toni/.yf_signimage/image_signing.key to /home/toni/.yf_signimage/image_signing.pem ... OK
Extracting public key (AVM's format) from /home/toni/.yf_signimage/image_signing.pem to /home/toni/.yf_signimage/image_signing.asc ... OK

You should copy the file /home/toni/.yf_signimage/image_signing.asc to your firmware image as /etc/avm_firmware_public_key9 to use it for image verification with AVM components later.

yf_sign, Version 1.0.1

Copyright (C) 2016-2021 P. Haemmerlein ([email protected])

Lizenziert nach den Bestimmungen der GPLv2 oder einer höheren Version, mit ein paar Zusätzen.
Einzelheiten sind dem Hilfe-Bildschirm (in englischer Sprache) zu entnehmen.

Gefundene Version: OpenSSL 3.0.17 1 Jul 2025 (Library: OpenSSL 3.0.17 1 Jul 2025) ... OK
Prüfe Verfügbarkeit des dgst-Kommandos ... OK
Prüfe Verfügbarkeit des rsa-Kommandos ... OK
Prüfe, ob der Digest-Algorithmus md5 unterstützt ist ... OK
Prüfung des Formats der Image-Datei ... OK
Zu viele leere Blöcke am Ende der Image-Datei: erwartet=2, gefunden=4.
Die überflüssigen Blöcke werden vor dem Signieren abgeschnitten.
Signieren des Hash-Wertes (md5) über den Inhalt der Image-Datei mit dem RSA-Schlüssel von /home/toni/.yf_signimage/image_signing.key ...No environment variable KEYPASSWORD
Error getting password
 FEHLER

 

[PeterPawn]

Beim Generieren eines neuen Schlüsselpaars mag es noch Probleme geben, wenn man das Kennwort für den neuen privaten Schlüssel über das Environment angeben will - das steht tatsächlich falsch im "usage screen" von yf_genkey - nur ist das ein einmaliger(!) Vorgang (bzw. sollte es sein) und die Angabe beim Aufruf sollte funktionieren.

Es sieht so aus, als wäre mir da eine unvollständige Version bei der Re-Implementierung ins (öffentliche) Repository gerutscht, denn es erfolgt wohl auch keine Abfrage für das Kennwort auf der Console, wenn es beim Aufruf nicht angegeben wurde.

Irgendwie habe ich das am Ende vor langer Zeit (April 2022) vergessen, daß da noch etwas offen war/ist: https://github.com/PeterPawn/YourFritz/commits/main/signimage

Ich werde mal schauen, wann ich das komplettieren kann - bis dahin einfach das Kennwort beim Generieren als Parameter angeben, das sollte funktionieren und mehr als einmal (wie erwähnt) ohnehin nie erfolgen bzw. notwendig sein.

Oder man nimmt sich einen älteren Stand des Repositorys, wo noch die Vorgängerversion enthalten war: https://github.com/PeterPawn/YourFr...f7897eeda670dd/signimage/generate_signing_key - dafür gilt noch das früher in diesem Thread Geschriebene hinsichtlich der Env-Variablen KEYPASSWORD (andere Schreibweise).

Wer will (auch helfen will) und einen GitHub-Account hat, kann auch ein(e) Issue dafür eröffnen (es IST ein Fehler), damit ich von (m)einem schlechten Gewissen geplagt werde, bis ich das Problem gelöst habe.

 

[Insti]

damit ich von (m)einem schlechten Gewissen geplagt werde, bis ich das Problem gelöst habe.

Du brauchst überhaupt kein schlechtes Gewissen haben auch der Fritzbox-Gott kann mal etwas übersehen.
Danke für den link zur älteren Version.
Wenn du das korrigierst, kannst du auch den Ordner .yf_signimage erstellen lassen?

Wer will (auch helfen will) und einen GitHub-Account hat,

Kenne mich mit GitHub nicht aus, sonst würde ich gerne beitragen.

VG

 

[fweite]

Ich habe mir das Signieren angeschaut, und möchte anmerken daß sich mM avm exakt beim unsignierten packen an den Tar-Standard hält.

In einer .image ist die signature immer die letzte Datei, als 1 512b Block Header und 1 512b Block Payload in den die Signatur immer passt.
Danach sollen mindestens noch 2 Blöcke "end of archive" (s.u.)

The end of the archive is indicated by two records consisting entirely of zero bytes.

Eine Tar wird default auf 10240b (20 512b Blöcke) gepadded:

For compatibility with tape drives that use fixed block sizes, programs that read or write tar files always read or write a fixed number of records with each I/O operation. These “blocks” are always a multiple of the record size. The maximum block size supported by early implementations was 10240 bytes or 20 records. This is still the default for most implementations [..]

Angenommen man "löscht" nun die signature am Ende der Datei, indem man sie durch 2 512b Blöcke die aus 0x00 bestehen "überschreibt", endet die .image im Grenzfall mit 2+19=21 512b Null-Blöcken.
Da aber auf max 20 Null-Blöcke gepadded werden soll, können die letzten 20 weg, die image wird 10kb kleiner

Der avm Hack:
Beim hinzufügen der signature hat avm aber was eigenes genutzt: Es wird direkt hinter der letzten Payload 2 0x00 gefüllte Blöcke mit Header + Payload "ersetzt".
Diese gibt es immer, da immer 2 EOF Marker Blöcke bei Tar vorhanden sein müssen.

Problem: Falls das die letzten 2 Blöcke sind, weil die Datei so auf 10kb gepadded war ist diese Datei nicht standardkonform! Denn AVM macht keine 10kb 0x00 Padding dazu. Beispiel: FRITZ.Box_7520-07.29.image
Dagegen FRITZ.Box_7520-08.10-123540-Inhaus.image: Diese hat 21 512b Blöcke nach der Signatur, nach dem löschen also 23 0x00 Blöcke am Ende, also 20 zu viel

TL;DR Bei der überprüfung muss die image um 10kb abgeschnitten werden, falls nach dem überschreiben der signature doch am Ende mindestens 22 512b mit 0x00 gefüllte Blöcke vorhanden sind.

Vermutlich nutzt AVM gar keine gesonderte crypto lib, da kein certificate sondern nur exponent und modulus vorhanden sind und mit signature die hash (rekursiv schneller) berechenbar ist:
hash = (signature^exponent) % modulus


[1] https://man.archlinux.org/mantar.5.en

 

[KunterBunter]

Ich habe mir das Signieren angeschaut, und möchte anmerken daß sich mM avm exakt beim unsignierten packen an den Tar-Standard hält.

Du möchtest eher anmerken, dass dem wohl nicht so ist. Zumindest nicht so ganz exakt.

 

[PeterPawn]

Entpackt wurde und wird in der AVM-Firmware immer mit dem tar-Applet der BusyBox und dieses verwendet m.W. eben KEINE 10 KB-Blöcke, egal was andere Implementierungen als (unspezifizierten) Standard verwenden mögen.

Ergebnis der AVM-"Fehler" bei der Einhaltung des ursprünglichen POSIX-Standards:

Physically, an archive consists of a series of file entries terminated by an end-of-archive entry, which consists of two 512 blocks of zero bytes.

(aus https://www.gnu.org/software/tar/manual/tar.html#Tar-Internals - die ursprüngliche POSiX-Quelle fimde ich nicht mehr, seit POSIX tar durch pax ersetzt hat)

für das ustar-Format (wo eben auch keine zusätzlichen Blockgrößen/-faktoren vorgegeben(!) sind, abseits der 512 Bytes für einen einzelnen Block), führte (ob das noch so ist, kann man nur entscheiden, wenn diese Konstellation mal wieder auftritt oder man testet es gezielt, worauf ich später komme) in der Vergangenhait sogar mehrmals zu einem "short read"-Error, wenn eben nicht die spezifizierten zwei aufeinanderfolgenden Blöcke mit binären Nullen das Ende der (Archiv-)Datei bildeten.

Bei der überprüfung muss die image um 10kb abgeschnitten werden, falls nach dem überschreiben der signature doch am Ende mindestens 22 512b mit 0x00 gefüllte Blöcke vorhanden sind.

Meines Wissens gab es (bei meiner Implementierung) eigentlich nie ein Problem beim Überprüfen(!) einer originalen AVM-Signatur - problematisch war allenfalls das eigene Signieren, so daß diese Image-Dateien danach auch von der AVM-Implementierung akzeptiert wurden und dennoch auch weiterhin mit dem ustar-Format kompatibel waren.

Mittlerweile dürfte aber auch das schon seit längerem nicht mehr relevant sein … (unsignierte) Image-Dateien werden einfach mit einen zusätzlichen Dummy-Member versehen (https://github.com/PeterPawn/YourFr...c28b8081bd24beeb91c43/signimage/yf_sign#L1166), der nichts anderes ist, als eine Kopie des ersten Eintrags im gesamten Archiv, der zuvor als Verzeichnis-Eintrag für /var/ geprüft/identifiziert wurde - allerdings nur bei den zwei potentiellen Dateigrößen, bei denen ansonsten eine falsche Anzahl von EOA-Blöcken (von der AVM-Implementierung) erwartet würde.

Nach demselben Prinzip wird der TAR-Header für die Signatur-Datei zusammengebaut, was parallel noch den Vorteil des "reproducible build" hat, weil Zeit und Datum des Signierens keine Rolle mehr spielen. Die zusätzlichen Verzeichnis-Eintrage, falls das Auffüllen erforderlich sein sollte, spielen beim Entpacken keine Rolle mehr, da das Verzeichnis bereits angelegt ist (auch wenn es am Beginn nicht relativ zum "root"-Verzeichnis für das Entpacken existiert hätte (ein führender Slash wird ohnehin immer abgeschnitten), wurde es durch den ersten Eintrag bereits erzeugt) und sind daher (m.E.) die effektivste Lösung, sowohl dem AVM-Algorithmus als auch den ustar-Format gerecht zu werden.

Wo genau das AVM-Problem liegt (und ggf. sogar, ob das immer noch existiert oder mittlerweile korrigiert wurde), kann man mit diesem Skript: https://github.com/PeterPawn/YourFritz/blob/main/signimage/show_signature_problem aus meiner Implementierung (es werden weitere Dateien benötigt, siehe Repo) auf einer FRITZ!Box mit Shell-Zugang prüfen und nachvollziehen.

 

[fweite]

Ich wolle nicht deine Implementiereung kritisieren da ich mir sie gar nicht im Detail angeschaut hatte, sondern wie es zu den Fehler in der Tar-Struktur kommt. Ich habe mich auch mehr mit der überprüfung beschäftigt
Das unsignierte image wird jedenfalls offenbar ganz normal mit tar gepackt, mit 2 eof und 10kb padding.

Entpackt wurde und wird in der AVM-Firmware immer mit dem tar-Applet der BusyBox und dieses verwendet m.W. eben KEINE 10 KB-Blöcke, egal was andere Implementierungen als (unspezifizierten) Standard verwenden mögen.

Wenn die siganture entfernt wurde und valide ist, entspricht die image auch dem Standard, wenn nicht entfernt rauscht ein sort read ohne Auswirkungen durch

Das short read resultiert daraus dass die 2 512b Blöcke für die signature hinter den letzten Payload Block geschrieben werden, dort sind immer mindestens auch 2 Blöcke vorhanden vorhandenen, im schlimmsten Fall nur die 2 end-of-file Blöcke wenn es so 10kb gepadded ist. Falls es durch das 10kb Padding sonst keine weitere Blöcke gibt werden diese auch nicht von hinzgefügt wenn schon an 10kb gepadded.

FRITZ.Box_7520-07.29.image 0 0x00 Blöcke am Ende, 2 ohne signature
FRITZ.Box_7520-08.10-123540-Inhaus.image 21 0x00 Blöcke am Ende, 23 ohne signature

Stimmt, hier ist rätselhaft warum das unsignierte image nach dem löschen 23 Blöcke am Ende hat, da 3 leere ausreichen würden. Das ist inkonsistent
Vielleicht ist die Version 08.10 verbessert?

 

[PeterPawn]

OK, ich bin dann hier raus, da ich nicht verstehe, was Du uns (oder mir, weil ich mich angesprochen fühlte, so ganz ohne "Ziel" Deiner Aussagen) damit sagen willst, daß da (durchaus schon ältere, wie man hier im Board auch nachlesen kann - vermutlich so um die Zeit herum, als das verlinkte Skript zum Nachstellen des Problems entstand) Erkenntnisse noch einmal wiederholt und bestätigt werden.

EDIT: Spätestens ab hier: https://www.ip-phone-forum.de/threa...ignieren-der-avm-firmware.286213/post-2449730 habe ich das m.E. alles schon einmal aufgedröselt.

 

[fweite]

Oh, ich dachte das wären neue Erkenntnisse