signimage: new and enhanced version #12
Comments
|
In a first step, I've added a workaround to the old version of image signing script to circumvent the MD5 computation failure from "firmwarecfg stream", if the signature starts at the "wrong" offset. |
|
After 3 years still urgent? ;-) Minor/optional feature requests for https://github.com/Freetz-NG/freetz-ng/blob/master/fwmod#L2108
|
|
Jetzt gehe ich mal zu Deutsch zurück, damit es keine weiteren Mißverständnisse geben kann. Deine Änderungen an Freetz-NG sind ja jetzt gerade erst ein paar Stunden alt - ich sehe noch nicht so ganz, wo das am Ende landen soll (die Kommentare der Commits sorgen auch nicht für weitere Erhellung). Wenn Du tatsächlich dem Benutzer die Wahl lassen willst, womit er sein Image signieren lassen will, dann warte bitte noch etwas. Ich bin gerade an umfangreichen Änderungen für die Dateien in Der Teil mit dem Signieren ist zwar jetzt praktisch fertig (und sollte dank POSIX-Kompatibilität sowohl mit Deine "feature requests" verstehe ich so nicht ... kannst Du das bitte noch einmal klarer schreiben (gerne auch in Deutsch)? Was soll "read private key without temporary file" sein? Der private Schlüssel sollte doch irgendwo im Home-Verzeichnis des Benutzers landen bzw. sogar als kleines Paket (zumindest in Freetz) bereitgestellt werden, das man sichern und wieder einspielen kann - ansonsten hat man (spätestens wenn man mit VMs arbeitet und da dann mal wieder ein neues Image auf dem Markt ist, das man verwenden will) früher oder später ja ein "Duuuscheinander" bei den RSA-Keys. Ich wüßte gar nicht, wo man da eine temporäre Datei brauchen sollte. Und beim Image-Signieren braucht man nun mal die Ausgabe in eine andere Datei - theoretisch wäre zwar auch ein "in-place"-Signieren möglich, aber eben nur dann, wenn das Image per se genug freie Blöcke am Ende enthält oder bereits ein Signatur-Member enthalten ist, den man überschreiben könnte. Außer du meintest eigentlich auch beim Signieren ein "--append" an die Ausgangsdatei - da gibt es aber schon ein paar Hürden. Genau das mit dem "genug Platz" wird aber selbst bei der Verwendung von GNU-tar zum Packen des neuen Images (vor dem Signieren) nicht immer der Fall sein - wenn dabei eine Datei herauskommt, die im letzten 10K-Block (immer unter der Annahme, daß stets volle 10K-Blöcke ausgegeben werden, wobei das Beim ersten Mal sind es 36 Verzeichnisse (1x ./var + 35x var/subdirXX) a 512 Byte = 18432 Byte gesamt, mit 4 freien 512-Byte-Records im letzten 10-KB-Block. Wie zu erwarten, braucht es dafür exakt 2x 10 KB (die ersten 10 KB sind nur Füllstoff, damit es wenigstens zwei Blöcke werden) und am Ende sind noch 4 Records frei (von 0x4800 bis 0x5000). Fügt man jetzt eine weitere Datei hinzu (anstelle der Signatur-Datei, der Platzbedarf ist aber derselbe: 512 Byte für den Header und 512 Byte für die Daten), landet die in den Bytes von 0x4800 bis 0x4C00 und es bleiben immer noch zwei leere Blöcke am Ende über -> das TAR-File wächst durch das Beim zweiten Mal sind es dann schon per se 38 Blöcke (es sind die Daten für die Denn wenn AVM in diesem Falle eine Datei als "gültig" ansieht, die OHNE diese 20 weiteren leeren (512-Byte-)Records daherkommt, dann kann das eigentlich für die Datei MIT dem zusätzlichen 10-KB-Block nicht auch noch gelten - der signierte Hash kann sich nur auf eine der beiden Dateigrößen stützen und damit sollte auch nur eine der beiden als gültig signiert akzeptiert werden. Daß die AVM-Variante (ohne zwingende EoA-Blöcke) von der AVM-Firmware verstanden wird, ist bereits geklärt (7530 07.29-Image) - bleibt die Frage, was sie zur anderen Variante sagt (und alles andere als ein "rc=210" wäre dann schon ein sehr absonderlicher Fall). Verweigert sie da aber die Zustimmung, gibt es auch bei der Methode mit OpenSSL und Soviel zu dem, was ich bisher im Bezug auf die Frage, ob das Signieren mit Wenn das tatsächlich so sein sollte, daß AVM den leeren 10 KB-Block hinter der Signatur (den es so bei AVM eben nicht gibt) ignoriert und ihn NICHT in die Hash-Berechnung mit einfließen läßt (es ist ja anzunehmen, daß AVM da Block für Block liest und dann immer entscheidet, ob der den MD5-Status aktualisieren soll oder nicht), sondern den Inhalt des letzten Blocks ignoriert (weil beim Auftauchen der Signatur-Datei im TAR-Stream bereits die abschließende Berechnung ( Aber wie gesagt - das müßte man erst mal testen ... Jedenfalls sehe ich schon aufgrund der o.a. Problematik, daß so ein File auch mal größer werden kann beim Signieren (und es garantiert auch immer größer wird, wenn man es mit ), nicht so richtig, wie man da generell ein "in-place"-Signieren machen sollte und als "Sonderfall", wo man erst noch aufwändig prüfen muß, ob der freie Platz für so ein Signieren an Ort und Stelle auch reicht, ist mir das eigentlich erst mal zu "künstlich" als Bedarf. In Freetz-NG solltest Du immer genug Platz für eine zweite Kopie haben und selbst auf der Box habe ich bisher eigentlich nie an DIESER Stelle Probleme bekommen. Zumal ja eigentlich die Ausgabe-Datei am Ende diejenige ist, die dann auch irgendwohin übertragen werden muß/soll (am besten auf die Box) und da kann man die dann auch gleich am Ziel irgendwie ablegen. Die unsignierte Eingabedatei ist dann halt die überflüssige - die muß man dann eben so schnell es geht entsorgen, wenn es um den belegten Platz geht. Ein Signieren im Rahmen einer Pipe (wo also das Signieren die Eingabedatei nur einmal als Stream lesen kann - es sei denn, man speichert sie doch noch irgendwo und liest diese Kopie dann mehrfach) ist mit meiner Methode nicht möglich - schon für die ganzen Prüfungen (um die Anwender vor den Folgen des Nichtlesens von Anleitungen u.ä. zu bewahren) muß die Eingabedatei mehrfach verarbeitet werden. Das wäre das, was ich unter Deinem ersten "Wunsch" verstehen würde - m.E. nur schlecht (sicher!) umzusetzen und da ist es mir dann eigentlich auch wieder lieber, wenn meine Skript-Dateien gar nicht erst in den Verdacht geraten können, sie wären am Verstümmeln und/oder Verschwinden einer Datei schuld, weil sie die Eingabedatei "angefaßt" haben. Die Fälle, wann da nun genug Platz für eine Signatur ist und wann die Datei "verlängert" werden müßte (zumindest wenn man korrekte EoA-Records haben möchte), sind mir auch zu komplex - es ist ja nicht zwingend gesagt, daß die Eingabedatei unbedingt auch Zwar wird eigentlich schon mittels Line 640 in a276313 dd-Prozesses umleiten, aber das ist mir irgendwie doch zu heiß (zumindest im Moment) - ich würde erst mal sehen wollen, wie sich das mit dem Ersetzen einer vorhandenen Signatur letztlich macht. Wenn das halbwegs sauber läuft (auch "in the wild") und damit dann auch mehrfache Signier-Versuche funktionieren (denn die "unsignierte Eingabedatei" wäre nach einem "in-place"-Signieren ja nicht mehr vorhanden), dann denke ich darüber noch einmal nach.
Mit dem zweiten Punkt kann ich aber gar nichts anfangen - da verstehe ich nur Bahnhof, weil ich gar keine Vorstellung habe, wo da der Key irgendetwas mit einer temporären Datei zu tun haben sollte (s.o.). |
|
Und nebenbei: Dringend war das tatsächlich mal, als das hier erstellt wurde - aber der gefundene Workaround: #12 (comment) hatte das dann schon in der Zeitspanne, die man als "urgent" ansehen würde, entschärfen können. Ganz so schlimm, wie das auf den ersten Blick aussieht, ist es also auch nicht - wirklich "urgent" war nur der vierte Punkt im ersten Beitrag und der war dann relativ zeitnah auch erledigt. Da hätte ich vermutlich das "urgent" dann auch gleich löschen sollen - so hole ich es jetzt eben nach. 😎 |
|
Deutsch ist mir lieber und einfacher.
Jo, muss nicht sein, wäre halt ganz praktisch wenn der Output nicht in eine Datei umgeleitet werden müsste und diese dann über das Original verschoben werden müsste.
Beim signieren durch fwmod liegt die Datei schon in images/ und könnte geflasht werden. Die Signierung kann man im menuconfig auch deaktivieren, dann wird das ganze einfach übersprungen
Ja, das hab ich auch festgestellt, ng (freetz/) weiss ich nicht) gibt die Größen vorher und nachher an |
Da redest Du offenbar dann aber vom (künftigen) https://tldp.org/LDP/abs/html/process-sub.html Aber tatsächlich funktioniert auch das oben nicht wirklich (jedenfalls im Moment), weil die bisherige Version immer die Existenz einer "Datei" prüft, bevor diese gelesen wird und das Ich würde auch hier nur ungerne auf Kommandozeilen-Parameter ausweichen, weil so ein Modulus schon ganz schön lang ist, wenn man ihn auch noch hexadezimal darstellen will/muß - bei einem 4096-Bit-Key (was der Rest meiner Skripte ja auch kann), sind das dann schon 1024 Zeichen nur für diesen Wert. Aber ich könnte mir vorstellen (wie gesagt, das
Die neue Version ist da schon gesprächiger, auch wenn ich nicht so genau weiß, wo Du da eine Fehlermeldung (dann vermutlich ohnehin bei der alten Version) vermißt hast. Deinen Ansatz, die Dateien nur So ein Problem könnte man zwar auch noch mit Unterverzeichnissen lösen - aber wäre es nicht viel schlauer (und komfortabler), wenn das alles nicht fix in der In der neuen Konfigurationsdatei für YourFritz/signimage/yf_signimage.conf Line 77 in f3fc9a4 pub und prv sieht man nun mal nicht an, was da drin stecken sollte.
Das muß auch nicht immer so sein ... die meisten Programme gehen ja auch hin, lesen ihre Daten von der Eingabe und schreiben sie (unter einem neuen Namen) in eine zusätzliche Datei - wenn dann am Ende alles glatt gegangen ist, wird die alte umbenannt (
Etwas in der Art ist auch bei mir schon lange vorbereitet - nur werden da die Keys als XML-Datei erfaßt/verwaltet: https://github.com/PeterPawn/YourFritz/blob/signimage/signimage/key_database.xml und bei Bedarf dann die richtigen (als Datei für die Option Auch das (automatische) Auslesen der AVM-Keys aus den Images habe ich irgendwo schon mal gemacht (müßte ich mal suchen), deshalb gibt z.B. dieses Skript: https://github.com/PeterPawn/YourFritz/blob/signimage/toolbox/image/extract_version_values auch die Keys mit aus, die es aus dem Image gelesen hat - dessen Ursprung war nämlich genau das Generieren der erwähnten Datenbasis für die Signaturprüfung. Das habe ich nur schon vorab irgendwann "öffentlich" gemacht (und es funktioniert ohnehin nicht mehr 100% in der öffentlichen Version, weil es schon wieder ein paar Monate/Jahre alt ist und nicht alle "Neuerungen" berücksichtigt), weil es irgendwo als Beispiel mal ganz praktisch war. Fertig ist das leider noch nicht - dafür gibt es zu viele offene Baustellen.
Ich hoffe, wir sind uns einig, daß das mit dem "nicht wachsen" aber auch bei der Methode mit dem Solange mein Ansatz, die Datei dann bei kritischen Fällen einfach auf eine "sichere Größe" zu erweitern, funktioniert, bleibe ich jedenfalls bei der Methode, nach dem "echten Payload" alle weiteren Daten abzuschneiden und exakt 4 leere Records in die Signatur einzubeziehen. Die ersten beiden werden dann zum Signatur-Member und die letzten beiden bilden die EoA-Marker aus dem Standard-Format. Etwas anderes bleibt mir auch gar nicht übrig, denn das ganze Signieren und Prüfen soll ja nicht ausschließlich für AVM-Firmware funktionieren bei mir, sondern einen generellen Mechanismus zum sicheren Speichern und Wiederherstellen von Daten bieten. Da wäre es Unsinn, wenn ich mich an den "Fehlern" von AVM orientieren würde bei meinem Ansatz der Prüfung. Wobei die Prüfung ja ohnehin nicht mein Problem ist (iirc klappt die sogar für die vergurkte 07.29 der 7530 bei mir, weil ja nur die Signatur durch leere Records ersetzt wird), sondern eher das richtige Signieren, damit die AVM-Firmware nicht in ihre eigene Falle tappt - wobei ja niemand bei AVM behauptet, daß ein korrektes TAR-Format auch das Ziel wäre. Es ist vermutlich ohnehin nur Zufall, daß man gerade dieses Format gewählt hat und nicht überall |
|
Ich habe mal noch Erstens kannst Du - wenn der Punkt jetzt zur Extension gehört - durch geschicktes Setzen von YF_SIGNIMAGE_PRIVKEYEXT ( YourFritz/signimage/yf_signimage.conf Line 77 in 0b8fb11 prv) und YF_SIGNIMAGE_KEYS (nur auf den Pfad, ohne meinen "common prefix") auch bei Deinem bisherigen Namen für den Key ohne Symlink auskommen.
Zweitens gibt es jetzt eine gesonderte Nachricht, wenn der Key nicht gefunden wird - wobei das natürlich schon dadurch festgelegt wird bzw. wurde, welchen "Pfad" man selbst gesetzt hat(te) über Drittens gibt es jetzt so etwas wie einen "fake mode", bei dem man das Signieren in einer Pipe aufrufen kann, wo dann halt das zu signierende Image-File auf STDIN reingeht und die signierte Datei auf STDOUT rauskommt. Allerdings ist das eben "geschummelt", weil dabei tatsächlich der komplette Stream von STDIN erst mal in eine temporäre Datei geschrieben wird (sonst könnte das Skript den Inhalt nicht mehrmals verarbeiten) und dann im weiteren Verlauf diese benutzt wird. Das führt dann zu einem höheren Platzbedarf beim temporären Speicherplatz, den das Skript benötigt. Außerdem muß man dabei dann das Kennwort für den privaten Schlüssel (wenn eines erforderlich ist, das Skript prüft das inzwischen auch erst einmal, bevor es ggf. danach fragt) auf irgendeinem anderen Weg schon festgelegt haben (entweder über eine Environment-Variable oder als zweiter Parameter beim Aufruf), weil das Skript es natürlich nicht von STDIN lesen kann (wenn es danach fragt), wenn da gar nicht das Terminal verbunden ist. |
Ah, wenn man shebang ersetzt hat man immer eine: https://github.com/Freetz-NG/freetz-ng/blob/master/tools/make/yourfritz-host/yourfritz-host.mk#L6 Die Sache mit /dev/fd/ find ich nett, hab aber noch nicht so durchgeblickt dass ich selbst damit was schreiben würde
"the private key file" sagt mir nicht wo die gesucht wird Wobei "falsche Passwort" nicht ganz korrekt ist da es gar keine Datei zum prüfen gab
Jo... mir ist halt nichts netteres eingefallen. Im .signature Verzeichnis liegt normalerweise sonst nichts. Ich glaub die pub hatte ich noch extra (in diesem Format) gespeichert weil die später auch ins Image soll. Evtl gibt es dann auch kein Passwort, da fakeroot sich rekursiv aufruft, mal mit fakeroot/pseudo und mal ohne. Bei Aliens mit mehreren Images sogar noch öfter
Klar wäre das möglich, wäre aber Aufwand. Und braucht das wirklich jemand? Ich bin mir nicht sicher. Das ".signature" Verzeichnis verhält sich wie das "dl", es wird ein Link nach $HOME erstellt falls es nicht existiert. Ansonsten kann man vorher einen Link oder Verzeichnis erstellen.
Prima, dann kann ich das so verwenden
Am besten nimmst du einfach die key1s aus ng, die sind vollständig ausser https://freetz-ng.github.io/freetz-ng/FIRMWARES.html#not-supported-devices
Seit auch andere Schreibrechte in ng haben, hab ich auf signierte Commits umgestellt, das müsste reichen
Das wäre eine schlechte Idee da geprüft werden soll ob die zu entpackende Datei (freetz/: md5 beim download) von avm signiert wurde. Vor allem bei über Juis automatisch heruntergeladene Dateien.
Die funktioniert sogar mit beiden Varianten. :D Wie wahrscheinlich ist Zufall? Übrigens kann man freetz mit Ich warte aber vorerst noch mit dem bump, bis der signimage-Branch gemergt ist. Sonst gibt es nacher im YourFritz-master eine Änderung die unbedingt nötig ist... |
Na halt da, wo Du das - in
Da steht auch wieder nicht "Das Kennwort ist falsch.", sondern "Das Kennwort für den privaten Schlüssel wird geprüft ... fehlgeschlagen" (und auch das ist schon Absicht, ich versuche nun mal solche Meldungen auch so zu verfassen, daß sie die tatsächlichen Umstände wiedergeben). Das kann nun mal alles sein, was eine erfolgreiche Prüfung des Kennworts verhindert - bis hin zum fehlenden privaten Schlüssel und wo der zu liegen hat, sollte man eben auch vorher schon wissen. Ja, wer den Key mit dem ebenfalls dafür bereitgestellten Shell-Skript erzeugt hat, der hat dabei auch die Information erhalten (egal, ob sie ihn interessiert oder nicht), wo die Dateien erzeugt wurden: YourFritz/signimage/generate_signing_key Line 213 in 60deb45 Aber hier weiß ich jetzt ohnehin nicht genau, worauf Du hinaus willst - schon hier: #12 (comment) habe ich Dir ja in "Zweitens" geschrieben, daß ich dann eben auch noch eine Prüfung (samt Fehlermeldung) eingebaut habe, ob das Key-File beim Signieren existiert oder nicht.
Danke für das Angebot, aber: Danke, nein - keinesfalls. Du hast vermutlich die mit dieser Datei/XML-Datensammlung verbundenen Intentionen nicht verstanden - vielleicht liegt das ja daran, daß Du das alles immer nur durch die Freetz-Brille betrachtest? Bei mir gibt es schon seit 2 1/2 Jahren diesen Branch: https://github.com/PeterPawn/YourFritz/tree/signimage_database/ und die darin zu findenden Skript-Files (in erster Linie in Etwas anderes braucht es üblicherweise auch nicht (und wer das nicht für "alle" Boxen haben will, kann sich sogar auf ein paar ausgewählte Modelle beschränken - außerdem sind die Keys üblicherweise in allen Firmware-Versionen eines Modells dieselben) und bei den erwähnten Skript-Files wird dann VOR dem (TLS-gesicherten) Download der Benutzer auch noch aufgefordert, sich von der Gültigkeit des AVM-Zertifikats für den Download-Server zu überzeugen und dann werden nur damit gesicherte Verbindungen beim Download irgendwelcher Images akzeptiert. Wenn man dann aus diesen - sicher von AVM stammenden - Images die Keys extrahiert, kann man auch sicher sein, daß man die korrekten Daten erhalten hat und die Datenbank am Ende (als XML-Datei) signieren. Und DIESE Datenbank kann man dann selbst verwenden oder ich schaffe es irgendwann doch noch, mal eine "komplette" zu veröffentlichen und meinerseits zu "unterschreiben" - dann kann jemand, der mir vertrauen möchte (wozu man nicht gezwungen wird, weil man sich die DB dann auch selbst zusammenstellen kann), auch eine vorbereitete Datenbank verwenden. Diese Datenbank kann man dann beim Download aus unsicheren Quellen verwenden, um die Echtheit der Datei (und auch ihre Integrität, weil Übertragungsfehler ebenfalls die Prüfung fehlschlagen lassen beim Download vom Hersteller) zu prüfen. Und das eben nicht nur in Freetz, sondern da, wo man es selbst braucht - angefangen hat das ganze Thema für mich überhaupt nur (als "öffentliches" Projekt), weil ich für modfs eine Möglichkeit haben wollte, die Echtheit der Vorlage zu prüfen, um mich nicht dem Vorwurf auszusetzen, mit der Benutzung ohne eine solche Prüfung zusätzliche Sicherheitslücken zu ermöglichen. Man KANN die Signaturprüfung auch übergehen, wenn man bewußt das Risiko eingehen will - der Standard ist (seitdem die Signier-Lösung verwendbar ist) ein anderer. Du magst ja primär Freetz als Ziel sehen und wenn etwas auf dem Build-Host funktioniert, auch damit zufrieden sein. Das ist aber nicht mein eigener Anspruch - ja, Freetz/-NG ist für mich nur EIN anderes Projekt, was diese Lösung nutzen kann (oder auch nicht, je nach Gusto) und ich werde auch immer eine Implementierung vorziehen, die solche Lösungen allgemeiner einsetzbar macht. Daher der Drang, so etwas max. POSIX-kompatibel zu machen und auf alles Unnötige (auch an zusätzlichen Programmen) zu verzichten - auch wenn das nicht bei allen Alternativen performant genug zu lösen ist und dann muß man eben auch mal auf andere Tools (hier eben auf Jedenfalls gibt es eben auch nicht nur Firmware-Files für Boxen und Repeater, sondern auch noch für Zubehör und daher ist Deine Wahl, nur die ersten Keys jeweils zu sichern, zwar für Freetz-NG vielleicht nachvollziehbar, aber das bringt für andere Anwendungen eben nichts. Während man aus einer solchen XML-Datei auch die Daten für Freetz generieren könnte, klappt das umgekehrt schon aus offensichtlichen Gründen (die Daten liegen in Freetz gar nicht ALLE vor) überhaupt nicht. Und dazu gehört auch die Frage, warum ich jeweils auch die Dateinamen der Key-Files aus der Firmware in der Datensammlung speichere ... die Info, wofür der Schlüssel eigentlich mal gedacht war (als Deduktion aus dem Dateinamen, unter dem er gespeichert war), ist in anderen Anwendungen vielleicht doch mal wichtig - und da juckt es mich nicht einmal, wenn der Zubehör-Key (der mit Index 3) in jeder Box/Firmware derselbe ist. Wenn es nämlich mal nicht so sein sollte, braucht man nur den richtigen, anderen Key einzutragen und die Sache funktioniert wieder wie zuvor.
Die Definitionen in der XSD-Datei sind jederzeit anpassbar, wenn es neue bekannte "Key-Typen" geben sollte - und wenn ich mich richtig erinnere, interessiert es die Skript-Files zum Generieren der Datenbasis gar nicht, wieviele Key-Files es gibt, sondern es werden einfach alle, die auf die Namensvorgaben passen, ausgelesen und abgelegt - da wo es bekannt ist, wofür die benutzt werden, wird dann
Da liegt ja auch offensichtlich ein Mißverständnis vor - die Datenbank bei mir soll ja nicht "on the fly" erstellt werden, wenn man ein bestimmtes Image prüfen will, sondern irgendwann zuvor einmalig (ggf. mit Update). Obwohl "on the fly" sogar ginge, denn die Prüfung des TLS-Zertifikats für den Download-Server sollte ebenso sicher sein, wie die Prüfung mit Public-Keys aus unsignierten Quellen - aber das war eigentlich auch nie das Ziel, sondern die Präferenz war/ist die bereits vorliegende Datenbank mit gesichertem Inhalt, so daß die Public-Keys auch nicht verändert worden sein können. Beim Einsatz auf der FRITZ!Box (da hat das eben - wegen
Ich habe mir das in Jetzt habe ich doch mal einen Blick in Dein Aber das mit der Kopie versuche ich mir jetzt als (eigene) Prüfung gerade auf einer FRITZ!Box - sagen wir mal mit 256 MB RAM - vorzustellen ... auch AVM hat da einiges zu tun, um das alles "in einer Pipe" zu erledigen und ohne zusätzliche Kopien des gesamten Images - deshalb lädt man dort gerne mal direkt aus dem Internet und speichert das Image zwischendurch gar nicht erst (bzw. neuerdings dann sogar im NAS-Flash) und nimmt nur den entpackten Archiv-Inhalt ins DAS habe ich bei der Prüfung schon eleganter gelöst - zwar müssen auch bei mir die Daten irgendwo liegen, aber nur einmal und danach werden sie direkt an das Hashen verfüttert, wobei anstelle der Signatur-Datei dann eben leere Blöcke verwendet werden. Mit diesen drei YourFritz/signimage/check_signed_image Line 720 in 60deb45 openssl-Aufruf geht. Einige Wege, wie man die Anzahl der Blöcke vor und nach dem Signatur-Member ermitteln kann (danach MUSS man eigentlich nicht wissen und kann einfach bis zum Dateiende arbeiten lassen), hatte ich im Signatur-Thread im IPPF erst kürzlich gezeigt - wenn man mit der Suche nach dem Header am Dateiende beginnt, geht das ratz-fatz, auch ohne passendes grep oder ähnliches - alles nur mit dd und cmp.
Und ohne die Veränderungen an der zu prüfenden Image-Datei braucht man auch die ganze Kopie nicht - Deinen "fix" (der für mich selbst bei Obendrein geht das (so aus dem Kopf und als "erste Überlegung") auch dann schon schief, wenn das zu prüfenden Image mal keine 10 KB-Blöcke verwendet (für das BB- Letztlich besteht meine Prüfung auch nur aus den drei (bzw. vier mit dem Abseits von der AVM-Firmware kann man auch heute schon mehr Sicherheit nutzen - und auch wenn das mal für AVM-Firmware geschrieben wurde, ist die Verwendung ja nicht darauf limitiert. Schon das Signieren von Images mit dem Box-Schlüssel, der mittlerweile auch ein 2048-Bit-Key ist, war von Beginn an eine "Erweiterung" - wenn ich nur stumpf das AVM-Zeug nachbauen wollte, könnte man sich in der Tat ein paar Kunststücke ersparen ... nur ist das eben (bei mir) gar nicht die Aufgabenstellung. Das alles sollte man bei einem "geht doch alles viel einfacher" auch immer im Hinterkopf behalten - das KANN stimmen, nur sollte man dann die richtigen "Umstände" und die aus der Implementierung folgenden Limitierungen auch immer mit aufzählen. Das ist in etwa wie bei den vielen (falschen) Anleitungen zum Debranden der 6490-Boxen von den Kabel-Providern - die beziehen sich i.d.R. auch nur auf das Modell, was die jeweiligen Autoren kennen (und das ist meist eben nur eines bzw. ihr eigenes) und da das eben nie klar "herausgearbeitet" wird, fallen so viele 6490-Besitzer auf die falschen Versprechungen dieser Anleitungen herein. |
Ich hatte das Script ohne irgend welche Optionen aufgerufen
Das hatte ich mir gar nciht angesehen. Wollte ich auch nicht weil ich schon einen Key hab
Dort wo nötig wird auch der inhaus-key (4) genutzt, zb neueste dvb-c firmware (inhaus) https://github.com/Freetz-NG/freetz-ng/blob/master/config/avm/signature.in#L5
Prima, ich habs nicht gewusst und trotzdem gemacht :D
Beim prüfen ja. Die Funktion legt sich ein Verzeichnis an und löscht es. Wie du das intern gemacht hast weiss ich nicht, ich finde es aber umständlich wenn man FÜR ein Script temporäre Dateien angeben kann und diese nach Aufruf wieder löschen muss.
mein (gnu) tar ist etwas zickig bei kaputten tar-archiven, wenn ich es richtig in Erinnerung hab bleibt es in manchen Fällen einfach stecken und wartet unendlich auf das nicht vorhandene Ende |
|
Die neuen Versionen werden auch komplett ohne Nur das OpenSSL werde ich wohl nicht so einfach ersetzen können durch irgendetwas POSIX-Konformes und das ist bei Krypto-Implementierungen ohnehin keine gute Idee, es selbst machen zu wollen. Aber mit dieser einen Abhängigkeit jenseits der POSIX-Spezifikationen kann ich dann leben ... auch die Abhängigkeit von Alles das, was ich in den Branch einchecke, ist noch nicht in Stein gemeißelt - daher noch einmal dringend die Bitte, nicht auf dieser Basis jetzt schon irgendetwas irgendwo anders einbauen. Ich mache so etwas i.d.R. iterativ - wenn's erst mal prinzipiell läuft, wird es hinterher "schön" gemacht (sofern ich die Zeit dafür finde, was hier aber so sein wird). |
|
Jo, ich warte auf den merge zum master-branch. Falls dort zb zuerst ein bootmanager update reinkommt |
|
etwas bekomme nicht ganz mit der Signierung halt hin..Update über AVM UI gehen nicht. bash YourFritz/signimage/generate_signing_key Wenn ich meine key´s durch die "pub und prv" (avm_firmware_public_key9 = image_signing.asc = pub = oder generiert von Freetz-NG -> avm_firmware_public_key8) in ".freetz-signature" ersetze gehts mit dem Update über AVM UI nicht. Dasselbe ist doch, wenn der Ordner ".freetz-signature" gelöscht wird und neue key´s mit meinem Passwort in "fmod Sign image file ---> erstellt werden. Es wird ein "avm_firmware_public_key8" ... /build/modified/filesystem/etc/.. generiert. Das Image mit meinem generierten öffentlichen key ist schon auf der Box 6660, oder 6490 drauf. Anders geprüft: meine mit meinem Passwort generierte key´s in YourFritz/signimage/ im Verzeichnis ".freetz-signature" passen umbenannt werden durch mein Passwort vor der Signierung in Freetz-NG überprüft. Wenn das Passwort passt, läuft alles mit dem Bau des Images durch. Was läuft falsch? Die ( ) Use tar --oldgnu / (X) Use yf-signimage Varianten, spielen keine Rolle. Alles ist gleich. |
|
Ich habe nur die Hälfte verstanden beim Versuch, das zu lesen. Aber zum "Stichwort" 6660 verweise ich auf: https://www.ip-phone-forum.de/threads/update-auf-neue-version-fb6591.311669/ - da stellt(e) sich dann auch heraus, daß es gar nicht an der Signatur scheitert, sondern erst beim Aufruf von Wenn's bei der 6490 auch Probleme gibt, dann bitte noch einmal versuchen, das irgendwie zu erläutern - diesmal aber bitte verständlich. Wenn's an der deutschen Sprache scheitern sollte, gerne auch in Englisch ... aber aus dem o.G. werde ich bei aller Mühe, die ich mir gebe, nicht schlau. Vielleicht hilft auch eine der neuen Versionen aus dem signimage-Branch - dem fehlen zur Veröffentlichung eigentlich nur noch ein paar Funktionen zum Konvertieren der öffentlichen Schlüssel zwischen verschiedenen Formaten in |
|
Ein Image wird signiert und auf die Box 6490 geflasht. Selbes Image kann danach dennoch nicht über die AVM Oberfläche geflasht werden. |
Wann, wie genau und womit (mit welchem Key, ist der öffentliche schon installiert, etc.) - da gibt es schon beim Signieren mehrere (offene) Fragen und beim Flashen erst recht, denn hier ist nicht mal erwähnt, auf welchem Weg dieses Flashen erfolgt
Das wäre auch nicht wirklich überraschend, wenn z.B. in diesem Image der öffentliche Schlüssel fehlt (jedenfalls der, der zum privaten Key gehört, mit dem das Image signiert wurde) - aber auch hier ist ja nicht wirklich klar, welches OS da gerade auf der Box arbeitet, wenn dieses Flashen über das AVM-GUI nicht funktioniert. Das könnte (a) ein originales von AVM oder (b) ein älteres, bereits modifiziertes oder sogar (c) das zuvor (siehe erstes Zitat) auf anderem Weg geflashte neue OS sein. Dir mag das ja alles sehr präsent sein, weil Du es gemacht hast - alle anderen fangen mit ihrem Wissensstand (was Dein Problem anbelangt) aber bei Null an und DENEN mußt Du das so erklären, daß sie Dein Problem auch verstehen können. Was mich anbelangt, ist Dir das in Deinen zwei letzten Versuchen nicht gelungen. |
|
Vor drei Tagen wurde die F!B 6490 mit der Image "6490_07.29.ger_freetz-ng-33164MOA-UNKNOWN_20211224-134437.image" über die Freetz Oberfläche geflasht. Erstellt wurde dieses Image zum ersten Mal mit den dazu erzeugten keys "image_signing.rnd, mage_signing.pem, age_signing.key, image_signing.asc". Paralel wird ein Ordner ".freetz-signature" im Homeverzeichnis mit 2 Dateien "prv und pub" erstellt. Info. Wenn die beiden Keys im Ordner ".freetz-signature" gelöscht werden, kann man sich neue mit einem neuen Passwort in Freetz-NG erzeugen lassen. Wenn diese nicht gelöscht werden, das Passwort aber in Freetz-NG verändert wird, wird es keine Signierung geben. Wen alles passt, wird ein "avm_firmware_public_key8" in ... /build/modified/filesystem/etc/.. generiert. Dieser gleicht der Größe zumindest hin den image_signing.asc und dem pub. Alternativ kann man sich die passenden Keys über dein Skript erzeugen, (YourFritz/signimage/generate_signing_key) Die Flash-Methode wurde alternativ mit Ftp und Push-Firmware durchgeführt. Ergebnis war gleich: das Flashen über System/Update/FRITZ!Osdatei ging nicht. Hast Recht: Meine Frage und deren Ausführung muss dem möglichen künftigen Mitleser in etwa nachvollziehbar sich ergeben, obwohl die Problematik vermutlich schon zuvor wohl nachvollziehbar war. |
|
Implementation partially done 8 month ago: https://github.com/PeterPawn/YourFritz/commits/main/signimage |
The text was updated successfully, but these errors were encountered: