Ich weiss nicht wo ich dir sonst schreiben soll

wo ich dir sonst schreiben soll

Discussions wäre z.B. eine Möglichkeit gewesen - deshalb konvertiere ich da im Anschluß auch.

"key9" hat mit NG nichts zu tun

Das hat ja auch niemand behauptet. Ich habe ihm vor längerer Zeit schon gezeigt, wie man - automatisiert - mit meinen Repos eine originale Firmware von AVM modifizieren und signieren kann, so daß man sie (beim zweiten Mal, weil der öffentliche Schlüssel schon in der laufenden Firmware enthalten sein muß) auch über das Web-GUI von AVM installieren kann.

Das kann man alles hier: https://www.ip-phone-forum.de/threads/wie-modifiziere-ich-die-originale-firmware-vom-hersteller-und-wie-installiere-ich-meine-eigene-dann-auf-der-fritz-box.307161/ nachlesen und irgendwo am Ende klappt es dann auch mit dem Signieren. Dabei WIRD der Key nun mal mit Index 9 gespeichert - da gibt es gar kein "Geheimnis" und es hat weder mit Freetz noch mit Freetz-NG etwas zu tun.

Das stimmt also inhaltlich auch nicht mit "hereingefallen" (und ich weiß tatsächlich auch selbst, wer wo mit welchen Pseudonymen unterwegs ist - nicht zu schreiben heißt ja nicht automatisch auch, daß man nicht lesen kann/will) - das Problem mit der Verifikation durch AVM bei ZWEI bestimmten Dateigrößen (bisher ging ich immer von einer aus und bin nicht mal sicher, ob das "schon immer" zwei Größen betraf) und den AVM-Images, die nicht zum TAR-Standard passen, ist ja nicht weg zu diskutieren.

Hier habe ich mal ein Protokoll angehangen, bei welchen Dateigrößen die AVM-Komponenten zu einem anderen Hash über die zu signierenden Daten kommen, als meine Skript-Dateien: https://www.ip-phone-forum.de/threads/wie-funktioniert-eigentlich-das-signieren-der-avm-firmware.286213/post-2450313

Die letzten Änderungen an den Signatur-Skripts (https://github.com/PeterPawn/YourFritz/tree/signimage) passen nach meiner Überzeugung schon ... ich baue jetzt nur noch ein Skript, was man auf einer Box nur noch aufrufen muß, um genau die Tests, die in meinem Protokoll zu sehen sind, auch selbst auszuführen.

Die Tatsache, daß da für den bereits behandelten Sonderfall dann immer noch keine erfolgreiche Prüfung möglich war, lag wohl tatsächlich an einem falschen Key - nur ist das am Ende auch "kein Beinbruch", denn niemand ist immer fehlerfrei. Ich finde/fand es sogar relativ angenehm (nach dem Umzug in den richtigen Thread), wie da "mitgemacht" wurde und daß am Ende auch der eigene Fehler eingestanden wurde (mit dem verwechselten Key) ... auch das hat man nicht so oft.

Und solange meine Skript-Dateien ernsthafte und nachvollziehbare Probleme bereiten (und das mit Rest=17 KANN ich eben nachstellen, siehe Protokoll - das war bisher noch nicht behandelt, sondern nur Rest=18), fühle ich mich dafür auch verantwortlich und korrigiere sie so weit, wie es in meiner Macht liegt. Da ich obendrein den Ehrgeiz habe, daß mein Signatur-Skript auch auf der FRITZ!Box (bzw. bei mit dem BusyBox-tar gepackten Images) funktionieren soll, kann ich mich auch nicht auf irgendwelche kompletten Blöcken (physische "records") am Ende der Image-Datei verlassen, denn das macht dieses Applet nicht und es gibt auch keine passenden Optionen.

Die einzige Möglichkeit wäre es noch, das Image danach noch durch ein dd mit einer Blocksize von 10 KB zu jagen - das braucht dann aber wieder entsprechenden Platz, wenn man ggf. zwei Images (und sei es nur temporär) irgendwo auf der Box "lagern" muß. Und zu guter Letzt fehlt dann dem BusyBox-Applet auch noch die komplette Operation --append - das ist dann (für meine Zwecke) erst recht keine Option mehr. Ich kann mir die Umgebung nur in sehr geringem Maße aussuchen.

Üblicherweise ist das für mich ein FRITZ!OS mit den Kommandos, die von AVM bereitgestellt werden und alles, was darüber hinausgeht, muß ich entweder "emulieren" (wie gerade wieder das mktemp in den Signatur-Skripts) oder die passenden Programme "nachladen" - was auch nicht so einfach ist, denn wenn ich irgendwo Binaries bereitstelle, verlangen die Lizenzbestimmungen nun mal, daß ich auch die "Rezepte" dazu anbieten muß, mit denen sich andere diese Dateien selbst bauen können.

Das mache ich für die Dateien in yf_bin mit dem parallel angebotenen Freetz-Klon - wenn ich da weitere Pakete/Programme dazulegen wollte, müßte ich erst mal schauen, ob die in Freetz (und nicht in -NG, über diese Brücke gehe ich nicht) überhaupt vorhanden sind oder sie notfalls einbauen in YourFreetz. Das ist meist anstrengender, als sich bei der Auswahl der zur Verfügung stehenden Programme zu beschränken, selbst wenn dann eine Umsetzung vielleicht etwas komplizierter wird.

Aber schon die Tatsache, daß man sich bei solchen Einschränkungen auch ganz bewußt noch einmal selbst auf strikte POSIX-Kompatibilität beschränken kann, entschädigt etwas für solchen zusätzlichen Aufwand - denn dann sollte das (fast immer) auch auf anderen Systemen (bis hin zu BSD-Klons wie macOS) genauso funktionieren.

Egal ... es gibt halt "Gründe", warum ich es mir so schwer mache, wie ich es (desöfteren) tue - nicht immer ist der leichteste Weg auch der beste, gerade wenn es um Portierbarkeit geht.

Ich kann mich auch noch an Diskussionen mit Dir erinnern, wo es um die Frage ging, ob es solche "Spezialfälle" beim Signieren überhaupt gibt und/oder ob Du mit Deinem Nachbau schon deshalb auf der sicheren Seite bist, weil Du auf GNU-tar zurückgreifen kannst/willst. Da dort dann automatisch --blocking-factor=20 angenommen wird, wenn man es nicht anders angibt, könnte es tatsächlich sein, daß Du Glück hast und nie an diese kritischen Stellen kommst.

Wobei ich mir das eigentlich gar nicht so richtig vorstellen kann - denn wenn die tatsächlich zu signierenden Daten auch bei Deinem GNU-tar so groß sind, daß der letzte Block (der halt bei GNU-tar dann auch die volle Größe von 10240 Byte hat) nur noch zwei oder drei leere Blöcke (a 512 Byte) am Ende bereithält, dann müßte auch Dein GNU-tar beim Hinzufügen des Signatur-Members durch --append eigentlich einen weiteren Block anhängen.

Da Du es ja vermutlich doch noch nie selbst getestet hast, was bei den verschiedenen "Füllständen" eines Images passiert, wenn man - wie Du - mit GNU-tar (beim erstmaligen Packen und mit nachfolgendem --append) arbeitet, würde mich das glatt mal interessieren - zumal sich da auch noch eine Lücke verbergen könnte, wenn ich nicht daneben liege.

Das OpenSSL ist ja bei Dir dasselbe (kaum verwunderlich, da sind nicht so viele Permutationen möglich), wobei ich mir bei Deiner "Forderung", daß die Dateien mit den öffentlichen Schlüsseln immer 266 Bytes haben sollen, auch schon nicht so sicher wäre - ich hoffe mal, Du hast das auch mal für einen Modulus getestet, dessen "high order bit" nicht automatisch gesetzt war, bevor die Nullen davor geschrieben wurden. Denn warum stehen da manchmal (bei AVM allerdings fast immer) noch zwei Nullen vor den anderen (hexadezimalen) Ziffern?

Weil das höchste Bit als Vorzeichen angesehen wird und damit wären alle Moduli, die mit einer hexadezimalen Ziffer zwischen 8 und F beginnen, negative Zahlen. Daher setzt man noch zwei Nullen davor (für die zwei "nibble" eines Bytes in hex) und hat damit zwar eine längere Zahl, aber eine, die wieder "positiv" ist.

Es kann gut sein, daß sich die AVM-Firmware darum nicht schert und die zwei Nullen auch klaglos schluckt, wenn das High-Order-Bit im zweiten Byte nicht gesetzt ist - aber ich hätte das zumindest mal ausprobiert, auch wenn man sicherlich lange suchen muß, bis man einen Modulus gefunden hat, der dieses Bit nicht gesetzt hat (obwohl das "die andere Hälfte" des Zahlenraums wäre).

Ich hatte das jedenfalls auch mal für diese Variante getestet - allerdings den umgekehrten Fall, wo dann eben keine Nullen vorne angefügt werden, wenn es nicht notwendig ist. Hier: https://github.com/PeterPawn/YourFritz/blob/1de5493f10b5b4f34af511741fdeea8797ce9339/framework/implant_public_key#L295 hatte ich mal ein Skript geschrieben, das einen eigenen Key auch aus einer Variablen im Urlader-Environment lesen und als Datei zur Prüfung bereitstellen kann.

Da diese Variablen nur max. 256 Byte aufnehmen können (und das auch nur, wenn man sie über den FTP-Server in EVA setzt), mußte ich führende Nullen abschneiden, wenn ich die Werte ins Urlader-Environment packen wollte - und dann natürlich passend wieder rekonstruieren. Daher weiß ich auch, daß die AVM-Firmware auch mit Moduli zurecht kommt, die keine zwei führenden Nullen enthalten - selbst wenn solche bei AVM selbst offenbar nicht vorkommen in den gesammelten öffentlichen Schlüsseln.

Weil ich gerade "im Flow" bin, werde ich mir vermutlich doch mal anschauen, was bei GNU-tar und OpenSSL (so, wie es Freetz-NG in der fwmod macht) für die unterschiedlichen Füllstände im letzten 10 KB-Block so passiert - weniger weil's mich interessiert, ob es nun "so einfach" machbar ist (wenn man die Programme zur Verfügung hat mit den passenden Optionen und Operationen), als vielmehr auf der Suche nach dem Unterschied, wie AVM da bei den zwei kritischen Größen wohl zum berechneten Hash-Wert gelangt. Das ist ja praktisch die Fortsetzung der Geschichte - auch wenn ich das Problem auf anderem Weg umgehe.

Wobei mir auch noch ein weiterer Grund dafür, warum ich das halt so und nicht anders mache beim Signieren, wieder eingefallen ist (beim Lesen dessen, was ich da zusammengeklöppelt habe) - es bestand (bei mir, aber auch bei anderen, wie @er13) durchaus der Wunsch, das Signieren so auszuführen, daß die signierte Datei bei identischem Ausgangs-Image immer denselben Inhalt hat (reproducible builds) und sich nicht bei jeder neuen signierten Datei andere Hash-Werte über den gesamten Inhalt (also inkl. Signatur) ergeben (denn dann kann man eben anhand des Hashs schon entscheiden, ob es dieselbe Datei ist oder nicht). Das klappt natürlich auch nicht, wenn man es so macht, wie Du in fwmod. Aber das ist ja auch nur ein weiterer Grund, warum ich es anders machen will und mache.

PeterPawn / YourFritz

Ich weiss nicht wo ich dir sonst schreiben soll #41