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

@f666:
Die Zeiten, wo ich noch CoLo-Server im Level3-Rechenzentrum in Düsseldorf (In der Steele) zu betreuen hatte und deshalb von Zeit zu Zeit bzw. eher regelmäßig auch von Berlin nach Düsseldorf fahren mußte, sind vorbei und über die bayrischen Landesgrenzen kriegt man mich seit dem 01.08.2017 nur noch gefesselt und gegen meinen Willen.

Das macht meinerseits einen "Besuch" an den zwei Heimatorten schon mal unwahrscheinlich ... aber eigentlich sollte man solche Differenzen auch per E-Mail zumindest so weit "dämpfen" können, daß eine Zusammenarbeit denkbar wird - das schaffen wir seit drei Jahren nicht bzw. es geht - nach einer zwischenzeitlich entspannten Phase - immer wieder schief.

Ansonsten habe ich (auch schon seit Jahren) noch einen gesonderten Channel auf meinem TS3-Server unter yourfritz.de für Audio-Kommunikation im Angebot, falls man "mal reden" will ... aber das ist alles bekannt.

Es scheitert also nicht nur daran, daß ich weder Weißbier noch Kölsch oder Alt mag (Alt geht gerade noch so) ... nur Tschechen und Preußen wissen im Übrigen, wie ein Pils tatsächlich schmecken sollte (na gut, irgendwo in Sachsen gibt es auch noch ein oder zwei akzeptable Bierbrauereien).
 
@PeterPawn:

folgende Hinweise/Bitten von mir:

1. Wie schon in einem der vorigen Posts angemerkt, bitte zieh ernsthaft in Betracht die Alternative (nicht nur in Diskussionen/Auseinandersetzungen mit mir), dass deine, bis zu welchem Grad auch immer dir "als einzig plausibel" erscheinende Interpretation der Ereignisse bzw. der Beweggründe der anderen die einzig richtige ist. Interpretationen sind bzw. beruhen auf Annahmen, die nun mal nicht immer zutreffen. Die Leute können gewisse Sachen anders verstanden, wahrgenommen haben und basierend darauf gehandelt haben. Sie können deine Aussagen missverstanden haben - dies weil diese z.B. missverständlich waren oder aber auch, weil die Leute einen anderen Wissenstand im Vergleich zu dir haben (dazu gehört auch die Fragen noch gar nicht gestellt, die du dir schon längst gestellt und beantwortet hast) und basierend auf dem anderen Wissenstand andere Schlussfolgerungen (aus deinen Aussagen) machen. Sie haben dabei keine bösen Absichten dir gegenüber. Diese Absichten (voreilig) reinzuinterpretieren bzw. anzunehmen führt nur zu der Eskalation bzw. zu der Voreingenommenheit bei weiteren Diskussionen.

Weder bei r14861 noch bei r14863 hatte ich vor, dich bzw. die von dir als richtig erachteten Lösungen in irgendeine Weise anzugreifen, geschweige denn deinen Code "krankhaft nachzubessern".

r14861 ist, wie gesagt, die pure Freude es rausgefunden zu haben, was genau AVM falsch macht, getriggert durch den Wunsch dir zu helfen, weil in meiner Wahrnehmung der Stand der Dinge zu dem damaligen Zeitpunkt der folgende war - "Peter hat es versucht, ist aber gescheitert, und auf die Vermutung, was es sein könnte, keine Antwort gegeben hat". Meine Wahrnehmung mag durchaus auch auf (nicht zutreffenden) Annahmen basieren, aber gleich die bösen Absichten zu unterstellen, nur weil diese Interpretation dir als "einzig plausibel" erscheint, ist nun mal ein Weg ins nichts (in dieser Hinsicht bin ich froh, dass du nicht als ein Analytiker beim Nachrichtendienst arbeitest :) ).

r14863 ist, ebenso wie bereits gesagt, die Dokumentation des Ergebnisses der Analyse eines Freetz-TODOs und damit die Legitimation des Entfernens von diesem 2 Commits später (s. r14865). Wie ich das Abarbeiten eines Freetz-TODOs dokumentiere, sei mir überlassen. Ich hielt es für besser, es mittels eines Commits zu machen - Repository-History ist nun mal ein besseres Nachschlagewerk als der eigene Kopf. Ich kann mich dunkel erinnern, mit dem Problem schon mal konfrontiert gewesen zu sein, hätte man mich aber explizit gefragt, was es beim Lesen mittels dd aus einem Pipe zu beachten gilt, hätte ich es auf Anhieb nicht sagen können.

2. Bitte versuche bei jeglichen Diskussionen verschiedene Angelegenheiten voneinander zu trennen und deine Voreingenommenheit mir gegenüber entstanden aus einer vorigen "Meinungsverschiedenheit" in die nächste Diskussion nicht mitzunehmen (der Umzug von Freetz auf Github bzw. die "Stille" meinerseits zu bestimmten Fragestellungen/Vorgängen hat nichts mit sign_image zu tun bzw. mit den von dir mir unterstellen "krankhaften Wünschen, den fremden Code nachzubessern"). Sonst sieht die gesamte Diskussion nach einer Ehe aus, die kurz davor steht zu scheitern und wo deswegen ohne Rücksicht auf Verluste alles rausgehauen wird - und damals hast du das gesagt, und damals das gemacht, und mich nicht gefragt, und so angeschaut, etc. Jegliche Fortsetzung der Diskussion ist dann einfach mal sinnlos.

3. Und der letzte Hinweis (trifft auch auf diesen Beitrag von mir zu). Wenn du einen Menschen mit dem, was du sagst, erreichen, wirklich erreichen möchtest, versuche mal bitte dich deutlich kürzer zu fassen. Das beinhaltet indirekt auch den Punkt 2 von oben, bleib' mal im Kontext einer Angelegenheit, dann werden die Beiträge von alleine kürzer. Wie es so schön heißt - manchmal ist weniger mehr. Ich gebe es offen zu, du verlierst mich schon nach zwei, drei Absätzen und die Zeit und insbesondere die Motivation rauszufischen, wie viele, welche Messages an mich denn in dem langen Beitrag enthalten sind und in wieweit die argumentativ belegt sind, habe ich nicht, da schreibe ich lieber Code oder widme mich meinen anderen Hobbies.
 
@er13:
Ich beurteile Dich auf der Basis Deiner (für alle sichtbaren) Handlungen ... das ist nämlich das Einzige, was dabei zählt. Deine Motive magst Du (im Nachhinein) immer irgendwie rechtfertigen ... ob und in welchem Umfang man dem Glauben schenkt, kannst Du auch niemandem "vorschreiben".

Daß und wo mich Dein Vorgehen extrem stört und ärgert, ist Dir aus vergangenen Auseinandersetzungen zumindest bekannt und auch wenn Du auf einer "getrennten Betrachtung" für jedes dieser Vorkommnisse bestehen möchtest, muß man Dir dabei nicht zwangsläufig folgen ... das macht dann nämlich den (argumentativen) Nachweis, daß es sich nicht um einzelne (und vielleicht entschuldbare) Ausrutscher handelt, sondern dieses Vorgehen Deinerseits durchaus Methode hat, unmöglich.

Auch steht Dein (unbeirrtes und stets wiederholtes) Vorgehen im Umgang mit den Arbeiten anderer eben durchaus in einem Kontext, ob man für Freetz (als Haupt-Repository) eine Software verwendet (nämlich "git"), die sich wesentlich besser für verteiltes Arbeiten durch mehrere eignet, als das uralte "subversion". Es hatte schließlich auch Gründe, warum "git" vor nunmehr schon 13 Jahren aus der Taufe gehoben wurde (schon zuvor bot Bitkeeper für den Linux-Kernel ähnliche Möglichkeiten in den drei Jahren seiner Nutzung) und die bestanden sicherlich nicht darin, daß man einfach mal etwas Neues machen wollte, sondern in deutlich sichtbaren Nachteilen von "subversion" für wirklich verteiltes Entwickeln.

Durch Dein Beharren auf "subversion" verbaust Du (ob gewollt oder ungewollt, interessiert dabei gar nicht wirklcih) anderen, unabhängigen Entwicklern den Zugang zu Freetz (und auch die "Änderungsvorschläge" in Form von Pull-Requests) so weit, daß nur Du (oder ein anderer mit Schreibzugriff, wobei sich ja fast alle anderen dort "zurückhalten") die "Entscheidungsgewalt" darüber besitzt, was in den "offiziellen" Freetz-Trunk übernommen wird und vor allem auch, in welcher Form das erfolgt. Von hier führt wieder der direkte Weg in der Argumentation zu den fehlenden Style-Guides ... und auch wenn Du gerne die Augen davor verschließen möchtest, hängen diese Punkte eben alle irgendwie zusammen und ergeben ein größeres, für mich tatsächlich einigermaßen unerträgliches, Bild eines ehemals sinnvollen Open-Source-Projekts, das sich zu einer Autokratie entwickelt hat, wie sie schlimmer kaum sein könnte.

Auch das nunmehr fast 14-tägige "Schweigen" trägt wohl kaum zum Eindruck bei, daß Du tatsächlich am Ausräumen von (neuerlichen) Mißverständnissen interessiert bist und daß Du tatsächlich im Rahmen von Freetz mit irgendjemandem zusammenarbeiten würdest ... und der Knackpunkt hier ist das Wort "zusammen" i.V.m. "arbeiten". Dazu paßt dann auch wieder das Fehlen (fast) jeder "Begründung" für Änderungen, die Du am Code von anderen vorzunehmen beliebst, wie die Faust aufs Auge - und "darum" (bzw. ein erst nach Aufforderung aus den Fingern gesogener "Text") ist keine annehmbare (und für andere nachvollziehbare) Begründung.

Insofern muß ich leider Deine Bitten, die Angelegenheiten alle getrennt voneinander zu betrachten, ablehnen ... 20 Ladendiebstähle sind auch - jeder für sich genommen - noch keine "kriminelle Karriere", aber in ihrer Gesamtheit sehr wohl und da belegen sie ein Muster. Daher ist so eine getrennte Betrachtung weder sinnvoll noch erforderlich ... wenn es ein solches (wiederholtes) Verhaltensmuster gibt und das sich über die Verknüpfung mehrerer Ereignisse nachweisen läßt, kann (und muß) man das eben gerade nicht alles getrennt betrachten (und beschreiben).

Auf die Fragen meinerseits gehst Du gar nicht weiter ein und versuchst nicht einmal ernsthaft, wenigstens eine davon zu beantworten ... Du wiederholst einfach nur die Beteuerung Deiner "eigentlich guten Absichten". Wenn man diese für bare Münze nimmt, müßte man immer noch: "Vielleicht hat(te) er gute Absichten, trotzdem war das denkbar schlecht gemacht und in Anbetracht der bisherigen Auseinandersetzungen zumindest "instinktlos"." konstatieren ... und da kommt dann noch Deine beleidigte Art oben drauf, denn ich finde immer noch am Beginn von #34 nichts, was Dich zur Reaktion:
Keine Ahnung, womit ich jetzt _den_ Ton verdient hätte bzw. die an die Klugscheißerei grenzenden Aussagen "Jetzt habe ich den Faden verloren"
hätte veranlassen können ... wenn ich tatsächlich zu diesem Zeitpunkt schon mit den deutlichen Worten, die mir "auf der Zunge lagen" (oder in den Fingern zuckten) geschrieben hätte, dann hättest Du vielleicht einen Grund dafür gehabt.

Auch die schematisch wiederholte Anschuldigung, ich würde Dir immer nur böse Absichten unterstellen, stimmt ja im Kern nicht wirklich ... wenn das so wäre, hätte ich schon sehr lange tatsächlich jede Kommunikation mit Dir eingestellt und daß ich genau dieses nicht getan habe (bisher), ist sicherlich auch unstrittig. Ich beurteile Dein Verhalten auch nicht mit irgendeiner "bösen Brille" oder ähnlichem ... das brauche ich nicht. Es reicht vollkommen aus, wenn man sich die Ergebnisse dieses Verhaltens ansieht ... und das trotzige Schweigen, daß dann nach solchen Vorkommnissen (und hier muß ich erneut auf ältere Gelegenheiten Bezug nehmen, weil das Schema ansonsten nicht erkennbar ist) eintritt, tut dann ein Übriges beim Bekräftigen solcher Thesen.

Wenn Du tatsächlich mal bei einer dieser Diskussionen den "Arsch in der Hose" gehabt hättest, das bis zum Ende auszutragen und nicht einfach durch Schweigen so lange auszusitzen, bis sich Dein Gegenüber wieder etwas beruhigt hat und bei sich denkt: "Vielleicht hat er ja diesmal etwas aus der Auseinandersetzung gelernt." und man sollte ihm eine neue Chance geben, dann würde das auch nicht immer nach dem Zank innerhalb einer Ehe aussehen. Du tauchst dann aber üblicherweise einfach ab und hoffst, daß schon irgendwie Gras über die Sache wachsen würde - nur ist es dann pure Dummheit, wenn man selbst das Kamel gibt, welches dieses Gras früher oder später wieder abfrißt.

Ob und in welchem Umfang Du meine Beiträge liest, tangiert mich auch nicht wirklich ... das dürfte Dich inzwischen aber auch nicht mehr überraschen. Wenn ich das so ausführlich schildere, dann auch mit dem Hintergrund (oder nenne es meinetwegen "Anliegen"), auf Verwerfungen in der "Wartung" des Freetz-Projekts aufmerksam zu machen (auch andere und ggf. sogar "die Nachwelt"). Auch das ist für Dich alles andere als neu ... die ersten, zwischen uns ausgetauschten, E-Mails zu diesen Themen liegen 3,5 Jahre zurück.

Ob und warum Du den Trunk als Dein "privates Repository" ansiehst und mit anderen Autoren darüber "über Bande" kommunizierst, solltest Du vielleicht auch noch einmal überdenken (auch darauf bist Du ja nicht mit einer einzigen Zeile eingegangen) ... ein Commit wie dieser in Freetz (der auch nicht etwa zu einem Pull-Request für YourFritz wurde), ist jedenfalls einfach nur noch Kindergarten. Wenn Dir die zwei Zeilen unnötig erscheinen (was sie zweifellos sind), dann wendet man sich an den Autoren und weist ihn darauf hin. Sollte der sich dann weigern, das entsprechend umzusetzen, dann (und nur dann in meinen Augen) kann man immer noch die eigene Ansicht (in seinem Projekt, wobei Du dem Anschein nach ja der Ansicht bist, es handele bei Freetz genau um "Dein" Projekt) umsetzen.

Es ist eben auch nicht so, daß nur ich diese "Schwierigkeiten" mit Dir hatte und habe ... auch unter diesem Aspekt macht die Forderung, jeden Einzelfall schön getrennt zu betrachten, aus Deiner Sicht vielleicht Sinn, aber diese Sicht muß man eben nicht zwangsläufig teilen und erst recht nicht dann, wenn "auf der anderen Seite" mehr als ein Betroffener steht - irgendwann wird es dann auch mal unglaubwürdig, wenn man mehreren Personen "gekränkte Eitelkeit" vorwerfen will, weil diese mit Dir nicht zusammenarbeiten können (bzw. ja eigentlich irgendwann nicht mehr wollen, das wäre präziser).

TL;DR (falls es wieder mal zu lang war):
Nichts da mit "isolierter Betrachtung" ... ein Verhaltensmuster kann man nämlich ansonsten praktisch nicht mehr nachweisen (auch wenn die Beweggründe für diese "Forderung" Deinerseits jedem einleuchten werden).

Die Hoffnung "Vielleicht haben ihn irgendwelche Worte ja diesmal wenigstens erreicht." begrabe ich auch ... der (oben verlinkte) Patch "020-signimage_unnecessary_code.patch" dokumentiert für mich das genaue Gegenteil und wieder interessiert mich der "Beweggrund" dafür gar nicht wirklich, weil es ausreicht, das Ergebnis (inkl. des Kommentars im Commit) zu betrachten.

Ob Du Dir vielleicht auch mal überlegst, daß mancher gar keinen wirklichen Wert auf "Deine Hilfe" legt, weil Du dabei immer wieder hingehst und Deinen eigenen Namen auf alle möglichen Lösungen von anderen klatschst, während die meisten von denen das problemlos auch selbst auf die Reihe kriegen würden, wenn sie nur wüßten, wie es (nach dem Willen der Freetz-Developer-Community und nicht nur nach dem Deinen, der sich auch alle zwei Wochen ändert, wenn nicht häufiger) aussehen sollte, mußt Du letzten Endes selber wissen.

Ich werde neue Ansätze und Programme jedenfalls nur noch unter einer Lizenz veröffentlichen, die bis zur Fertigstellung der Lösung (und einer entsprechenden "Freigabe" meinerseits) eine Übernahme in Freetz, bei der Änderungen vorgenommen werden, die über das zur Integration zwingend erforderliche Maß hinausgehen, ausschließt. Ich finde es zwar traurig, wenn man zu solchen Schritten praktisch gezwungen wird (und sei es auch nur, daß man selbst den Eindruck hat, dieser Zwang würde existieren - so etwas stellt sich ja auch nicht ohne Grund oder wegen fehlender mentaler Gesundheit von heute auf morgen ein), aber dann kannst Du künftig entscheiden, ob etwas für Freetz sinnvoll ist oder nicht und ob das auch ohne "substantielle Änderungen" verwendet werden kann oder nicht. Lautet Deine Einschätzung dann "nein", mußt Du eben warten, bis ich zur Einschätzung gelange, ich wäre soweit, es unter GPLv2 zur Änderung durch Dich freizugeben. Bis dahin steht Dir (als Gleicher unter Gleichen) genau derselbe Weg für "Änderungsvorschläge" offen, wie jedem anderen auch ... und das geht über PRs für ein Git-Repository.
 
Zuletzt bearbeitet:
@PeterPawn:

Oh, Peter, Peter.

Auch für mein verspätetes Antworten bzw. Nicht-Auseinandersetzen mit bestimmten Themen oder langsames Aufnehmen von PUMA6-Änderungen gibt es auch eine ganz einfache, sogar primitive Erklärung - fehlende Zeit (oder andersrum ausgedrückt, glücklicherweise besteht mein Leben nicht nur aus Freetz). Viele der Freetz-Entwickler sind in erster Linie aus Zeit-Gründen inzwischen nicht mehr aktiv. Ich bin einer der letzten, der es noch irgendwie schafft, das Projekt mehr oder weniger übers Wasser zu halten. Die Auseinandersetzungen mit dir tragen nicht gerade dazu bei, dass meine Motivation höher wird. Es ist auch Schade um meine begrenzte Zeit, dass ich mich in die (aus meiner Sicht sinnlosen) Diskussionen mit dir überhaupt hineinziehen lasse.

Sofern dir etwas an mir bzw. meinem Stil zusammenzuarbeiten nicht gefällt, so steht es dir frei, Freetz zu forken und es so auseinander laufen zu lassen, wie es dir gefällt. Ich werde mich jedenfalls nicht auf dieses Kindergarten-Niveau herablassen und irgendwelche Ausnahmen für andere Projekte in die Lizenz-Vereinbarungen aufnehmen. Du kannst deinen Fork verändern und brauchst bei keiner Änderung nach meiner Erlaubnis bzw. meiner Meinung fragen (so wie es in GPL verankert ist). GPLv2 sagt übrigens nichts zu den "Additional Terms", GPLv3 verbietet diese explizit.

p.s. Und was die Freetz-Style-Guides angeht, so sind diese hier fast vollständig dokumentiert. Die fehlenden C-Code-Style-Guides kannst du nicht als grundsätzliches Fehlen von Style-Guides verkaufen. Wo sind übrigens die Style-Guides von YourFritz und den anderen Projekten von dir nachzulesen? Rhetorische Frage...

p.p.s. Und sollte sich das nicht aus meinen Worten oben direkt ableiten lassen, so sei explizit gesagt, das war mein letzter Beitrag in diesem Thread.

Edit: und übrigens, wenn du etwas an Freetz verändert haben wolltest, hast es auch erst in deinem Fork committet und erst danach mich informiert bzw. den Pull-Request gestellt. Deswegen deinen Wunsch, dass ich bei jeder Änderung, die ich an deinem Code vornehme, dich erst informiere, mit dir alles ausdiskutiere und auf keinen Fall VOR diesen Schritten etwas in Freetz-Repository committe, kann ich nicht nachvollziehen.
 
Zuletzt bearbeitet:
Das Paradoxe an einer "Begründung", man habe eigentlich gar keine Zeit für irgendetwas und auf der anderen Seite ständigen Änderungen am Code von anderen, hatte ich schon angesprochen ... vielleicht liegt das ja auch einfach an der falschen Herangehensweise (für gemeinsames Arbeiten).

Da beziehe ich jetzt mal die Vorschläge/Patches von @f666 für Puma-Boxen mit ein, denn auch diese hätte man erst einmal - und sei es als Branch - integrieren und hinterher entsprechend anpassen können - komischerweise treten solche "Notwendigkeiten" ja auch immer erst dann ans Tageslicht, wenn jemand irgendwelche Patches / PRs vorschlägt. Dann könnten die Freetz-User das jedenfalls inzwischen auch benutzen - ein Beispiel für jemanden, der zwei verschiedene Forks (Puma6 + FHEM von @DHU) nun selbst zusammenführen müßte, hatten wir hier erst kürzlich in einem anderen Thread.

------------------------------------------------------------------------------------------

Zur Frage, wo die Style-Guides für YourFritz sind ... es brauchte bisher schlicht noch keine, weil es sich - trotz meiner "Suche" nach Mitstreitern - immer noch um ein Ein-Mann-Projekt handelt - das war Freetz ursprünglich eben nicht, auch wenn Du es inzwischen fast zu einem solchen gemacht hast. Wie man auch ohne "contribution guidelines" einem Autoren entsprechende Patches zukommen lassen (und diese dabei auch noch begründen) kann, hat Dir erst diese Woche @enrik gezeigt ... er hätte sicherlich auch hingehen und das über einen Patch im Freetz-Trunk "dokumentieren" können, denn vermutlich hat er dort sogar noch Schreibrechte.

Auch kann ich mich nicht erinnern, daß ich an irgendwelchen Vorschlägen von anderen wegen Tippfehlern in Kommentaren oder (trailing) Whitespaces am Zeilenende oder wegen des Unterschieds zwischen einer "for"- oder einer "while"-Schleife schon mal (ohne Begründung meinerseits, warum ich das so und nicht anders sehe) herumgeändert hätte ... das sind dann eben doch noch zwei unterschiedliche Paar Schuhe.

Wenn mich jemand, dessen Vorschläge ich aus Style-Gründen ablehne, nach solchen Richtlinien fragt, hat der einen Grund und eine Berechtigung dazu ... ich habe Dich auch nie ohne entsprechenden Anlaß nach solchen vereinbarten Konventionen gefragt und ich hatte bisher nur eine einzige Gelegenheit, einen "pull request" von Dir abzulehnen ... der aber auch deutlich mehr eine Zumutung war und es nicht einmal für nötig hielt, entsprechende Begründungen zu liefern oder (nachvollziehbare) Überlegungen zu irgendwelchen Änderungen mit anderen zu teilen.

Warum ich das so nicht akzeptieren konnte (und wollte), habe ich damals überdeutlich erklärt (ff.) - wenn auch nicht im GitHub, sondern in Reaktion auf Deine (ebenfalls wieder nachgelieferten) "Begründungen". An Antworten von Dir an dieser Stelle kann ich mich nicht so richtig erinnern.

------------------------------------------------------------------------------------------

Außerdem ist es schon ziemlich schlechter Stil, auf eine Kritik nur noch mit der Frage: "Und ... bist Du denn besser?" zu reagieren - das zeigt irgendwie nicht einmal, ob man solcher Kritik nun eigentlich inhaltlich zustimmt oder nicht. Es ist also eigentlich nur ein weiterer Versuch, von eigentlichen Thema abzulenken.

Ähnliches gilt für den Hinweis hinsichtlich der Konventionen bei der Shell-Programmierung ... es ging - bei unseren Auseinandersetzungen und meinem wiederholten Ansprechen dieser fehlenden Konventionen - nie um irgendwelchen Shell-Code (auch wenn Du da ebenfalls immer Deinen eigenen Kopf durchsetzen mußt, da habe ich dann halt auf die Zähne gebissen).

Zum Inhalt der Konventionen für Shell-Code schreibe ich jetzt mal nichts, denn dort ist weder etwas zum verwendbaren "Sprachumfang" (wie weit sind denn "bash"-ismen zulässig?) erwähnt, noch sind irgendwelche Konstrukte wie "if [ x"$FOO" = x"0" ]; then" dort thematisiert, wo das "x" eben noch eine zusätzliche "Schutzfunktion" hat, weil es selbst bei passend numerischen Variablen und versehentlich als Vergleich verwendetem "eq"-Operator (ein Fehler, der gerade Shell-Anfängern häufig unterläuft) zu einem Fehler anstelle des falschen Vergleichs führt. Das war sogar mal "anerkannter Coding-Stil" bei der Benutzung von "bash" und "ksh" (siehe z.B. im "ABS Guide") und solange man nicht POSIX-Kompatibilität als Prinzip festlegt (was dann auch wieder "-a" und "-o" in "test"-Kommandos ausschließt), sind das alles "peanuts" oder eben "Geschmackssache", die man ohne weiteres stehen lassen kann, solange man selbst auch in der Lage ist, das zu verstehen und zu interpretieren.

Es muß nicht immer so aussehen, wie es dem eigenen "Schönheitsempfinden" entspricht - ist es syntaktisch und logisch richtig, muß es auch nicht auf Teufel komm raus geändert werden - es sei denn, es gibt entsprechende Festlegungen/Konventionen und dann gehört zu einer "Aufforderung" an den Autoren, das entsprechend anzupassen (was immer noch der erste Schritt vor der eigenen Änderung wäre) lediglich noch der Hinweis auf die vereinbarten(!) Konventionen (samt Link für den Adressaten zum Nachlesen), wenn die eigene "Kritik" tatsächlich vom dortigen Inhalt gedeckt und nicht nur "heiße Luft" ist.

Und einiges in diesen "shell styles" ist auch schlicht fahrlässig oder falsch bzw. viel zu ungenau, wie z.B. diese Festlegung:
Variable Assignments

Variable assignments should not be quoted if unnecessary:
Genau das (nämlich der "unerwartete" Inhalt von nicht korrekt gequoteten Variablen) ist eines der größten Sicherheitsrisiken in der Shell-Programmierung (und immer wieder ein Einfallstor für Angreifer) und so eine Festlegung kann max. hinsichtlich der Variablen gelten, deren Inhalt man tatsächlich zu 100% voraussagen kann und dann sind das i.d.R. keine "echten" Variablen mehr, sondern lediglich "verkleidete" Konstanten oder tatsächlich Werte, bei denen man auf der Basis bereits erfolgter Behandlungen und/oder Tests das Vorhandensein von "whitespaces" innerhalb des Wertes absolut ausschließen kann. An dieser Stelle ist es sogar sinnvoller, die Konvention genau andersherum zu handhaben und immer zu quoten, solange es keinen plausiblen Grund dagegen gibt - das "schleift" sich dann nämlich auch ein und führt (fast automatisch) zu sichereren Variablenzuweisungen.

------------------------------------------------------------------------------------------

Zum Forken ... ja, das wird tatsächlich immer mehr "eine Überlegung wert". Aber selbst so ein Fork würde mich nicht davon abhalten, mich gegen solche "feindlichen Übernahmen" von fremdem Code durch Dich zu positionieren und daraus auch kein Geheimnis zu machen - das löst also das Problem Deines Umgangs mit fremdem Code nicht wirklich.

Danke für den Hinweis auf den Unterschied zwischen GPLv2 und GPLv3 ... nun kannst Du noch raten, warum ich das YourFritz-Repository unter GPLv2 gestellt habe und nicht (at your option) auch unter GPLv3 (die hat auch noch andere Punkte, die für mich nicht passen) und das nur in den entsprechenden (Unter-)Verzeichnissen "aufweiche" in irgendwelchen Header-Zeilen.

Außerdem finde ich es höchst großzügig, daß Du mir die Benutzung von Freetz (wo das Urheberrecht ja wohl auch nicht nur bei Dir liegt - und mit dem "Einbau" von irgendeinem x-beliebigen Projekt unter GPLv2/GPLv3 in Freetz könntest Du eine solche Ergänzung für Freetz auch gar nicht vereinbaren) nicht verwehren wirst ... auch das zeigt ja irgendwo, als was Du Freetz tatsächlich ansiehst.

Anders als Du ändere ich an meinem (ja ohnehin bereits vorhandenen) Freetz-Fork auch nur das, was funktionell notwendig ist (und dann auch noch im Stil des jeweiligen originalen Autors irgendeiner anzupassenden Software) ... ich käme jedenfalls nie auf die Idee, einen Patch für einen Schreibfehler in einem Kommentar zu erstellen; dafür wäre mir meine eigene Zeit viel zu schade (und die "Besserwisserei" viel zu offensichtlich und vordergründig, die kann dem Gegenüber ja nur unangenehm aufstoßen).

------------------------------------------------------------------------------------------

EDIT:
Um auch noch auf den Zusatz unter #46 einzugehen, den ich erst später gesehen habe ... wenn Du den Unterschied zwischen einem Fork eines Projekts, dem anschließenden Branch und den darin vorgenommenen Änderungen, die dann als Änderungsvorschlag (oder "Pull-Request") wieder an den Upstream übermittelt werden, und Deinem Vorgehen mit dem direkten Einchecken von Patches für alle Freetz-Benutzer tatsächlich nicht erkennen kannst, ist deutlich mehr im Argen, als ich eigentlich vermutet hätte - dann ist Dir nämlich die "normale Arbeitsweise" bei der Verwendung von "git" (bzw. GitHub als einem möglichen Git-Hoster) tatsächlich nicht bekannt.

Das muß(te) man zwar aufgrund der Tatsache, daß Du auch zusammenhängende Patches nie als Branch vorbereitest und dann erst eincheckst, wenn das wirklich komplett ist, bereits annehmen, aber diese (indirekte) Bestätigung kommt für mich dann doch schon ziemlich überraschend. Dich interessiert auch gar nicht, was das dann für Auswirkungen auf andere Nutzer hat ... bei Dir weiß man nie, wann ein "intermediate goal" erreicht ist und es sich lohnt, seinen Fork mit dem Trunk zu synchronisieren oder ob da nicht in 5 Minuten der nächste Patch kommt.

Das normale Vorgehen wäre es eben, daß man zusammenhängende Änderungen erst mal in einem gesonderten Branch vorbereitet und diesen dann - als Ganzes - mit dem Master mischt. Dann stellt sich auch die Frage "Kommt da in 5 Minuten die nächste Änderung?" nicht wirklich ... mit dem Merge ist der Branch dann erledigt.

Mal vollkommen davon abgesehen, daß Du eben gerade keine Pull-Requests daraus machst bzw. den Hauptkritikpunkt, daß Du auf jedwede plausible Begründung für (oft unmotiviert anmutende) Änderungen von Deiner Seite verzichtest und das deshalb den Anschein von Willkür hat, hier erneut einfach ausblendest ... ebenso den gravierendsten Unterschied, obwohl Du ihn doch selbst so schön formuliert hast:
hast es auch erst in deinem Fork committet und erst danach mich informiert bzw. den Pull-Request gestellt.
Der Freetz-Trunk ist eben nicht mit Deinem Fork von Freetz zu verwechseln - auch wenn Du Dich immer wieder so verhältst.

Das normale Vorgehen wäre es (bei einem gemeinsamen Projekt und wenn "subversion" das nicht leisten kann, ist das erst recht ein Grund für den Umstieg auf "git"), daß auch Du einen Fork des Repos hast, dort Deine Änderungen vornimmst (solange es nicht nur kleinere Korrekturen sind, sondern "new features" oder tiefgreifende Änderungen) und sie dann als Ganzes in das Projekt-Repository überführst.

Vor der Frage "Kommt da in 5 Minuten die nächste Änderung?" stehen nämlich auch nicht nur die Leute mit eigenen Forks des Freetz-Projektes, sondern genauso "normale User", die auch nie genau wissen, wann denn nun der nächste "version bump" für weitere Pakete erfolgt und ob sie lieber noch eine Stunde warten sollten, damit sie wenigstens den Stand auschecken können, der die nächsten 24 Stunden halbwegs aktuell ist.

Von dem Moment an, wo Du solche Sachen eincheckst, müssen eben alle Freetz-Benutzer, die den Trunk danach klonen (und sie haben gar keine andere Chance, weil der Trunk sowohl "Entwicklerzweig" als auch der einzige überhaupt funktionierende Branch in Freetz ist), mit Deinen Änderungen leben ... und daß diese teilweise nicht mal bis zum Ende von Dir durchdacht wurden, hast Du einige Beiträge weiter vorne selbst als "Entschuldigung" vorgebracht - auch da wieder mit zuwenig Zeit (für solche Überlegungen) begründet.

Wenn ich einen Branch im meinem Freetz-Fork mache, dort Änderungen vornehme und diese als PR in den Freetz-Master einfließen lassen will, geht das auch nie (aber definitiv nie) um irgendwelche Änderungen um der Änderung willen ... und ich schreibe immer dazu, warum es diese Änderungen nach meiner Ansicht braucht (und diese meine Änderungen an meinem Fork gelten eben auch nicht automatisch für alle Freetz-User, die ab diesem Zeitpunkt das Repository klonen).

Das genau machst Du eben nicht (irgendwas zu begründen) ... wenn es tatsächlich funktionelle Änderungen braucht, würden sich auch die wenigsten Autoren dagegen wehren (es sei denn, sie haben gute Gründe dafür und selbst diese interessieren Dich aber in der Regel nicht im Geringsten) - mal ganz abgesehen davon, daß "feel free to provide a patch" ja auch eine gerne genommene Reaktion auf Änderungsvorschläge (von Freetz-Nutzern) ist und wie das funktionieren soll, ohne einen Branch und einen Patch aus dem Ergebnis so eines Branches, verstehen wohl auch die wenigsten.
 
Zuletzt bearbeitet:
Ab hier wird von mir das Signatur-Thema aus diesem Thread: https://www.ip-phone-forum.de/threads/sammelthema-zur-avm-fritz-box-7520.302364/post-2448911 fortgesetzt - wenn es sich tatsächlich um ein Problem beim Signieren handelt, gehört es einfach hierher.

Dieser Beitrag ist erst einmal nur als "Anker" gedacht, auf den ich im anderen Thread verlinken kann ... inhaltlich wird es erst in einem weiteren Beitrag fortgesetzt (zumindest von mir); wobei ich dann auch auf Nachsicht beim Aspekt der aufeinander folgenden, eigenen Beiträge hoffen würde.
 
Vorab noch eins: Da sich die Änderung im Branch signimage offenbar nicht positiv ausgewirkt hat, gehe ich davon aus, daß alles Weitere wieder mit der Version aus dem main-Branch passiert, womit dann nicht zwingend zusätzliche Füllblöcke in der signierten Datei stehen.

Aus diesem Beitrag: https://www.ip-phone-forum.de/threads/sammelthema-zur-avm-fritz-box-7520.302364/post-2449428 wissen wir, wie der von AVM ermittelte Hash über die zu signierenden Daten aussieht:
Rich (BBCode):
total=30709760 ret=0 sub_ret=0 sigcrc=1bbe7981136d832bb7a52fcd7d5d4b85
, wenn man eine originale Firmware für die 7530 überprüfen läßt.

Mit diesem Wissen ausgestattet und in Kenntnis dessen, daß der freizuhaltende Platz für die Signatur im Firmware-Image durch binäre Nullen repräsentiert wird, können wir eine Teststrategie entwickeln, bei der wir so lange den tatsächlich zu signierenden Inhalt mit einzelnen 512-Byte-Blöcken "verlängern", bis wir beim Berechnen eines MD5-Hashes über die resultierende Datei genau den Wert erhalten, der oben in rot dargestellt ist. Wobei uns die grüne Angabe der Dateilänge auch schon einen Hinweis liefert, wieviele Bytes der zu prüfende Datenstrom für den Hash wohl haben sollte ... aber wir machen das dennoch mal Schritt für Schritt.

Zuerst legen wir (ich mache das jetzt mal "unter Einbeziehen" der Leserschaft und bleibe beim "wir" anstelle des "man", obwohl ich keine weiteren Stimmen in meinem Kopf habe) für diesen Test irgendein temporäres Verzeichnis an, damit wir alles das, was im Laufe der Aktion an Dateien anfällt, auch einfach wieder entsorgen können. Anschließend definieren wir ein paar Funktionen, mit denen man üblicherweise recht einfach an die konkreten Dateinamen eines aktuellen FRITZ!OS-Images kommt - das steht normalerweise bei mir schon alles in einer Profile-Datei und damit in jeder Shell-Session zur Verfügung, aber hier wird es als Demonstration noch einmal explizit definiert (wer das oder etwas ähnliches schon zuvor definiert hat, kann natürlich auch darauf zurückgreifen - das ist ohnehin bei mir nur q&d, weil nur HTML zerlegt wird, was nicht unbedingt passen muß zu dem, was AVM da ausgibt, falls man dort wieder mal die Systematik ändert, aber zur aktuellen Lage paßt es):
Rich (BBCode):
peh@vidar:~> mkdir 7530_test
peh@vidar:~> cd 7530_test/
peh@vidar:~/7530_test> get_image_name() { [ -n "$1" ] && wget -q -O - https://ftp.avm.de/fritzbox/fritzbox-$1/deutschland/fritz.os | sed -n -e "s/.*<a href=\"\(FR[^\"]*\)\".*/\1/p"; }
peh@vidar:~/7530_test> get_image() { [ -t 1 ] && return; [ -n "$(get_image_name "$1")" ] && wget -O - "https://ftp.avm.de/fritzbox/fritzbox-$1/deutschland/fritz.os/$(get_image_name "$1")" || printf "Download failed.\n\a" 1>&2; }
Damit können wir jetzt das aktuelle Firmware-Image für eine 7530 von AVM laden, auch ohne den korrekten Dateinamen zuvor erst zu suchen. In der geladenen Datei suchen wir dann nach dem Beginn des TAR-Eintrags für die Signatur-Datei und kopieren alles davor in eine neue Datei, die wir danach zum "Grundstock" der zu testenden Datei machen werden. Für diese kann man auch gleich schon einmal den MD5-Hash bilden, der sollte aber nicht mit dem signierten Wert übereinstimmen.
Rich (BBCode):
peh@vidar:~/7530_test> get_image 7530 > avm.image
--2021-11-13 14:02:33--  https://ftp.avm.de/fritzbox/fritzbox-7530/deutschland/fritz.os/FRITZ.Box_7530-07.29.image
Resolving ftp.avm.de (ftp.avm.de)... 217.110.95.228, 217.110.95.227, 212.42.224.71, ...
Connecting to ftp.avm.de (ftp.avm.de)|217.110.95.228|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 30709760 (29M) [application/octet-stream]
Saving to: 'STDOUT'

-                                                           100%[=============>]  29.29M  12.9MB/s    in 2.3s

2021-11-13 14:02:35 (12.9 MB/s) - written to stdout [30709760/30709760]

peh@vidar:~/7530_test> grep -abo "./var/signature" avm.image
30708736:./var/signature
peh@vidar:~/7530_test> dd if=avm.image of=avm.data bs=512 count=$(( 30708736 / 512 )) 2>/dev/null
peh@vidar:~/7530_test> ls -l
total 59984
-rw-r--r-- 1 peh users 30708736 Nov 13 14:04 avm.data
-rw-r--r-- 1 peh users 30709760 Nov 13 14:02 avm.image
peh@vidar:~/7530_test> md5sum avm.*
a36571c24a65937a82ae265a3dc250b1  avm.data
8938d11f232876c3bd1af641a4a271f0  avm.image
peh@vidar:~/7530_test>
DAS ist also noch nicht die Datei, die am Ende von der Signaturprüfung im FRITZ!OS verwendet wurde - aber auch die "vollkommen originale" Datei ergibt einen anderen MD5-Hash.

Um das jetzt jeweils um 512 Bytes mit Nullen zu "verlängern", kopieren wir einfach immer wieder die passende Anzahl von Bytes aus /dev/null /dev/zero (nur "virtuell" in einer Pipe, die gleich das Hashen am anderen Ende hat), bis der MD5-Hash mit dem Wert von AVM übereinstimmt. Dazu brauchen wir auch erst einmal eine Funktion, welche die Ausgabe von md5sum so aufbereitet, daß tatsächlich nur der Hash-Wert übrig bleibt. Um zu verhindern, daß der Test zu weit geht, wenn keine Übereinstimmung beim Hash gefunden wird, begrenzen wir das Ganze aber auf max. 20 Runden (20 x 512 Byte = 10240 Byte, also ein physischer Block bei unterstellter Blocksize von 10 KB):
Rich (BBCode):
peh@vidar:~/7530_test> md5() { [ -n "$1" ] && md5sum "$1" | sed -n -e "s|\(^[a-f0-9]*\).*|\1|p"; }
peh@vidar:~/7530_test> for i in $(seq 20); do cur=$( ( cat avm.data; dd if=/dev/zero bs=512 count=$(( i - 1 )) 2>/dev/null ) | md5 -); printf "%02u = %s\n" "$(( i - 1 ))" "$cur"; [ "$cur" = "1bbe7981136d832bb7a52fcd7d5d4b85" ] && break; done
00 = a36571c24a65937a82ae265a3dc250b1
01 = d3b9d9d1b0658387b8b2a360782c8914
02 = 1bbe7981136d832bb7a52fcd7d5d4b85
Und DAS ist jetzt tatsächlich eher unerwartet ... wenn schon das Hinzufügen von zwei leeren Blöcken nach dem "tatsächlichen" Inhalt zu dem Hash-Wert führt, der vom FRITZ!OS für die Eingabedatei berechnet wurde, dann wäre das ja genau der Platz, den normalerweise die Signatur-Datei belegen würde (1x TAR-Header, 1x 512 Byte mit Daten) und dann fehlt da in der Datei ja der KOMPLETTE Ende-Marker für TAR-Files.

Und tatsächlich, wenn man sich das in der AVM-Datei ab dem Beginn der Signaturdatei ansieht:
Rich (BBCode):
peh@vidar:~/7530_test> hexdump -C avm.image | sed -n -e "/^$(printf "%08x" "30708736")/,\$p"
01d49400  2e 2f 76 61 72 2f 73 69  67 6e 61 74 75 72 65 00  |./var/signature.|
01d49410  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01d49460  00 00 00 00 30 31 30 30  36 34 34 00 30 30 30 30  |....0100644.0000|
01d49470  30 30 30 00 30 30 30 30  30 30 30 00 30 30 30 30  |000.0000000.0000|
01d49480  30 30 30 30 32 30 30 00  31 34 31 33 36 35 34 35  |0000200.14136545|
01d49490  36 37 33 00 30 31 32 30  36 34 00 20 30 00 00 00  |673.012064. 0...|
01d494a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01d49500  00 75 73 74 61 72 20 20  00 00 00 00 00 00 00 00  |.ustar  ........|
01d49510  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01d49540  00 00 00 00 00 00 00 00  00 30 30 30 30 30 30 30  |.........0000000|
01d49550  00 30 30 30 30 30 30 30  00 00 00 00 00 00 00 00  |.0000000........|
01d49560  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01d49600  4f 11 e1 f0 7f b3 9f 25  2f a5 1f f7 d1 e6 4e 18  |O......%/.....N.|
01d49610  1c 23 65 7a a4 ac ed cd  82 49 c1 c7 a4 ae c2 83  |.#ez.....I......|
01d49620  67 fb b8 31 e7 37 11 98  d8 ab a8 7d 06 86 c0 0a  |g..1.7.....}....|
01d49630  4c 3c ed 4a 65 4a b0 cd  ca e3 d4 e8 5f 1d a1 d6  |L<.JeJ......_...|
01d49640  9c f7 86 81 88 4a a2 e0  5d e9 b2 4c f7 ee f0 6d  |.....J..]..L...m|
01d49650  43 ec 36 0c ab 3a 7d b7  64 b1 e8 06 f5 34 f7 5c  |C.6..:}.d....4.\|
01d49660  18 5c ea 8d da bd cb 49  ca c2 13 04 57 4b 60 84  |.\.....I....WK`.|
01d49670  dc 6d 37 16 70 01 26 13  24 95 bb c7 c2 83 a8 01  |.m7.p.&.$.......|
01d49680  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01d49800
peh@vidar:~/7530_test>
, dann kommt danach wirklich nicht mehr ein einziger kompletter Block mit binären Nullen, während das TAR-Format davon aber wenigstens zwei (mit jeweils 512 Byte) erfordern würde: https://www.gnu.org/software/tar/manual/html_node/Standard.html
At the end of the archive file there are two 512-byte blocks filled with binary zeros as an end-of-file marker.
Das ist also erneut mal wieder einer der Fälle, wo ein AVM-Image zwar das TAR-Format verwendet, aber sich nicht an den Standard hält.

Nur so zum Spaß kann man ja mal hingehen und die anderen aktuellen Release-Versionen auf diese Merkwürdigkeit untersuchen (auch wenn das in der Ausführung etwas dauert):
Rich (BBCode):
peh@vidar:~/7530_test> empty_blocks() { fo=0; so=0; [ -n "$1" ] && eval $(hexdump -C "$1" | tail -n 3 | sed -e "2d" | sed -n -e "1s/^\([^ ]*\).*/fo=\$(( 0x\1 ))/p" -e "2s/^\([^ ]*\).*/so=\$(( 0x\1 ))/p"); printf "bytes=%u blocks=%u\n" "$(( so - fo ))" "$(( ( so - fo ) / 512 ))"; }
peh@vidar:~/7530_test> for model in 7490 7520 7530 7590 7590-ax; do get_image $model 2>/dev/null > tmp.image; printf "%s: " "$model"; empty_blocks tmp.image; done
7490: bytes=1920 blocks=3
7520: bytes=8576 blocks=16
7530: bytes=384 blocks=0
7590: bytes=2432 blocks=4
7590-ax: bytes=4480 blocks=8
peh@vidar:~/7530_test>
Die 7530 ist also (aus den getesteten Modellen) im Moment die einzige Box, bei der die Firmware-Datei mit dem TAR-Standard kollidiert - die anderen haben mind. zwei Null-Blöcke am Ende.

Aber vollkommen egal, ob man das jetzt so sieht, daß AVM sich da schon an den Standard halten sollte oder ob man dem Hersteller eher "freie Hand" lassen würde ... letztlich muß man sehen, daß die selbst signierten Dateien einen solchen Aufbau haben, daß die Signaturprüfung im FRITZ!OS sie akzeptiert. Und der Aufbau der aktuellen (Original-)Datei für die 7530 erklärt am Ende auch noch nicht wirklich, warum AVM da die eigene Signatur nicht will, wenn mein Skript doch dafür sorgt (oder zumindest dafür sorgen sollte), daß die Datei AUCH den TAR-Standard einhält - das sollte ja nicht zu einer ungültigen Signatur führen. Es illustriert nur die Schwierigkeiten, die man haben kann, wenn man die AVM-Signaturen nachbauen will.

Was kann man - wenn man eine Datei zur Verfügung hat, die vom FRITZ!OS abgelehnt wird - jetzt als Nächstes testen? Nun, man kann diese nicht akzeptierte Datei noch einmal durch die Prüfung jagen und sich dabei den Hash-Wert, den das FRITZ!OS dabei errechnet (in der firmware_stream_result) notieren, so wie ich das am Anfang des Beitrags gezeigt habe.

Dann geht man mit dieser Datei wiederum hin und behandelt sie so, wie ich es oben mit dem AVM-Image gemacht habe (alles Unwesentliche hinten abschneiden und dann so lange Null-Blöcke anhängen, bis man den AVM-Hash (der sich natürlich von dem unterscheidet, den ich oben verwendet habe) gefunden hat). Danach weiß man dann, wie AVM die angebotene Image-Datei verändert hat bei der eigenen Berechnung des Hash-Wertes - und daraus kann man dann wieder Schlüsse ziehen, wie man die eigene Datei so aufbauen kann, daß sie von der AVM-Firmware auch verifiziert werden kann.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: prisrak1 und Insti
Code:
grep -abo "./var/signature" avm.image
grep: unrecognized option: b
Ich habe schon einige busyboxen auf der FB durchsucht bekomme aber immer den gleichen Fehler. Hast du dafür bitte mal eine andere Variante.
 
Bei der BusyBox müßte das auch ohne -b eine passende Ausgabe liefern, da ist das - iirc - Standard.
 
Da fehlt dann aber das Wichtigste: Die Zahl.
Code:
grep -ao "./var/signature" avm.image
./var/signature
 
Dann braucht man wohl ein richtiges grep oder man macht es anders, wenn man's unbedingt auf der Box machen will. Wobei die Schwierigkeiten dann - je nach BusyBox - schon beim wget beginnen könn(t)en, welches nicht zwingend auch HTTPS beherrschen muß.

Eine Alternative wäre z.B. das hier:
Rich (BBCode):
peh@vidar:~> mkdir /tmp/7530_test
peh@vidar:~> cd /tmp/7530_test/
peh@vidar:/tmp/7530_test> get_image 7530 > avm.image
--2021-11-15 10:00:15--  https://ftp.avm.de/fritzbox/fritzbox-7530/deutschland/fritz.os/FRITZ.Box_7530-07.29.image
Resolving ftp.avm.de (ftp.avm.de)... 212.42.224.71, 212.42.224.73, 217.110.95.228, ...
Connecting to ftp.avm.de (ftp.avm.de)|212.42.224.71|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 30709760 (29M) [application/octet-stream]
Saving to: 'STDOUT'

-                                                           100%[=====================>]  29.29M  12.9MB/s    in 2.3s

2021-11-15 10:00:17 (12.9 MB/s) - written to stdout [30709760/30709760]

peh@vidar:/tmp/7530_test> find_member() { [ -n "$1" ] && [ -n "$2" ] && s1=$(stat -c %s "$1") && s2=$(stat -c %s "$2") || return; i=$(( ( s1 / 512 ) - 1 )); while [ "$i" -gt 0 ]; do dd if=avm.image bs=512 skip=$i count=1 2>/dev/null | dd bs=1 count=$s2 2>/dev/null >./tmpfile_cmp; cmp -s "$2" ./tmpfile_cmp && printf "offset=%u\n" "$(( i * 512 ))" && break; i=$(( i - 1 )); done; rm ./tmpfile_cmp; }
peh@vidar:/tmp/7530_test>
Die Funktion find_member sucht jetzt alle 512 Byte in der im ersten Parameter angegebenen Datei nach dem Inhalt der Datei, die als zweiter Parameter angegeben wurde. Da bereits bekannt ist, daß der gesuchte TAR-Member sich eher am Ende als am Anfang der Datei befindet, fängt die Suche gleich hinten an. Man braucht jetzt also nur noch eine Datei mit dem Namen des gesuchten Members:
Rich (BBCode):
peh@vidar:/tmp/7530_test> printf "./var/signature\000" > sig_member
peh@vidar:/tmp/7530_test> set -x
peh@vidar:/tmp/7530_test> find_member avm.image sig_member
+ find_member avm.image sig_member
+ '[' -n avm.image ']'
+ '[' -n sig_member ']'
++ stat -c %s avm.image
+ s1=30709760
++ stat -c %s sig_member
+ s2=16
+ i=59980
+ '[' 59980 -gt 0 ']'
+ dd if=avm.image bs=512 skip=59980 count=1
+ dd bs=1 count=16
+ cmp -s sig_member ./tmpfile_cmp
+ i=59979
+ '[' 59979 -gt 0 ']'
+ dd bs=1 count=16
+ dd if=avm.image bs=512 skip=59979 count=1
+ cmp -s sig_member ./tmpfile_cmp
+ i=59978
+ '[' 59978 -gt 0 ']'
+ dd if=avm.image bs=512 skip=59978 count=1
+ dd bs=1 count=16
+ cmp -s sig_member ./tmpfile_cmp
+ printf 'offset=%u\n' 30708736
offset=30708736
+ break
+ rm ./tmpfile_cmp
peh@vidar:/tmp/7530_test>
und dann hat man sich einen anderen Weg, den Signatur-Member in einem AVM-Image zu finden, gebaut.

EDIT: Wenn man die Funktion so abändert:
Code:
find_member() { [ -n "$1" ] && [ -n "$2" ] && s1=$(stat -c %s "$1") && s2=$(stat -c %s "$2") || return; i=$(( s1 / 512 )); while [ "$i" -gt 0 ]; do dd if=avm.image bs=512 skip=$i count=1 2>/dev/null | dd bs=1 count=$s2 2>/dev/null | cmp -s - "$2" 2>/dev/null && printf "offset=%u\n" "$(( i * 512 ))" && break; i=$(( i - 1 )); done; }
, dann braucht man auch keine temporäre Datei mehr für den Vergleich.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: prisrak1
Zuletzt bearbeitet:
Wer ruft bei einem normale Update der FB die tr069fwupdate auf?
Explizite Aufrufe mit packet kommen nur bei der Suche nach Updates für Zubehör vor ... daher auch der abweichende Pfad, unter dem die entpackten Daten dann im tmpfs landen. Beim "normalen Update" rief(!!) firmwarecfg intern sich selbst als firmwarecfg stream in einer Pipe auf und erledigte damit die Signaturprüfung. Das macht tr069fwupdate packet auch, aber halt mit einem anderen Basisverzeichnis (/var/packet) und die Dateien werden dann auch relativ zu dieser Basis entpackt, wenn am Ende der Pipe ein tar -x steht.

Das tr069fwupdate an sich kennt dann auch noch ein paar mehr "Tricks" als firmwarecfg ... denn das geht z.B. mittlerweile erst einmal hin und extrahiert aus dem angebotenen Image nur die Signatur-Datei und überprüft diese, bevor dann der Rest mit einem zweiten Aufruf entpackt wird (lädt dann ggf. auch zweimal eine Datei). Zuvor konnte es (iirc) auch vorkommen, daß man schon mit einem Image-File, das einfach nur zu viele Daten enthält, das tmpfs der Box so weit auslastete, daß die Box praktisch unbedienbar wurde. Die verwendeten Aufrufe von firmwarecfg stream für die verschiedenen Quellen und Typen von zu verarbeitenden Daten kann man sich ganz gut in den Zeichenketten im tr069fwupdate-Binary ansehen (mit strings).

Wobei beim "echten" Firmware-Update inzwischen (seitdem AVM das Logging und Checkpoints bei den Updates eingeführt hat - daher auch die Vergangenheitsform im ersten Absatz) auch noch die libfwupdate.so dazwischen geschaltet wird - die übernimmt wohl mittlerweile vieles von dem, was zuvor in der firmwarecfg (die war ja lange Zeit die eierlegende Wollmilch-Sau bei AVM, wo alles versammelt war, was mit CGI zu tun hatte und nicht Lua oder TR-064 war) untergebracht war (zumindest bei bestimmten Verarbeitungswegen). Aber der Aufruf dieser Funktionen erfolgt dann - je nachdem, woher und wie das Update gestartet wurde - von unterschiedlichen Stellen. Diese Library wiederum greift dann wohl ihrerseits wieder für die Signaturprüfung auf einen Aufruf von firmwarecfg stream zurück.

Beim Datei-Update über das GUI landet die Datei erst mal per CGI-Aufruf mit POST bei firmwarecfg (mit Parameter UploadFile, der die "Operation" dabei anzeigt) und dort werden dann die weiteren Maßnahmen (bis hin zu den Push-Messages beim Update) organisiert. Für später hinzugekommene Upload-Funktionen für alle möglichen Dateien (von Klingeltönen und Ansagen bis zu Portal-Logos, etc.) dient firmwarecfg nur/immer noch als "Sprungverteiler", der sich um Parameterprüfungen kümmert und am Ende irgendwelche Shell-Skripte aufruft.

Für irgendwelche Spezialfälle gibt es auch in firmwarecfg immer noch einen Aufruf wie diesen:
Code:
cd / ; wget -O - '%s' 2>/var/dl_err | /usr/www/cgi-bin/firmwarecfg stream 1 0 | tar xvf -
- nur kann der ja offensichtlich nur für andere Update-Trigger genutzt werden und nicht für das dateibasierte Update über's GUI, weil da kein wget machbar wäre (außer man würde die Datei noch einmal über einen lokalen HTTP-Server ausliefern, was wg. doppeltem Platzbedarf auch keinen Sinn ergeben würde). Außerdem kam dann auch noch die Änderung mit dem SILENT_UPDATE hinzu, wo ja die Installation (bzw. das Schreiben in den Flash) nicht erst beim nächsten Neustart erfolgt (wie es früher war), sondern direkt bei der Ausführung der /var/install erfolgt (inkl. Umschaltung von linux_fs_start), während der Neustart dann eben erst irgendwann später folgt und nicht unmittelbar. Das macht die verschiedenen Update- und Installationswege noch ein wenig unübersichtlicher - zumal da auch noch Wege hinzugekommen sind, bei denen die Firmware erst mal nur geladen und unter /var/InternerSpeicher/FRITZ/ abgelegt wird ... der "normale" NAS-Zugriff auf diese Dateien wird dann aber blockiert:
C:
 189 /**
 190  * Block access to listed files.
 191  * Only needed for files in one of the directories:
 192  * /var/InternerSpeicher
 193  * /var/media/ftp (AVM_ACL_COMMON_REAL_PREFIX)
 194  *
 195  * Other locations of bpjm.data do not need to be blocked here, because the directories are out of access scope.
 196  */
 197 static const char *blockedpaths[] = {
 198         "/var/InternerSpeicher/FRITZ/bpjm.data",
 199         AVM_ACL_COMMON_REAL_PREFIX"/FRITZ/bpjm.data",
 200         "[B][COLOR=rgb(184, 49, 47)]/var/InternerSpeicher/FRITZ/firmware_update.image[/COLOR][/B]",
 201         AVM_ACL_COMMON_REAL_PREFIX"/FRITZ/firmware_update.image",
 202         "[B][COLOR=rgb(184, 49, 47)][B]/var/InternerSpeicher/FRITZ/firmware_update.image.activ[/B][/COLOR][/B]e",
 203         AVM_ACL_COMMON_REAL_PREFIX"/FRITZ/firmware_update.image.active",
 204         "[B][COLOR=rgb(184, 49, 47)]/var/InternerSpeicher/FRITZ/firmware_update.version[/COLOR][/B]",
 205         AVM_ACL_COMMON_REAL_PREFIX"/FRITZ/firmware_update.version",
 206         "/var/InternerSpeicher/FRITZ/bpjm.update",
 207         AVM_ACL_COMMON_REAL_PREFIX"/FRITZ/bpjm.update",
 208         "/var/InternerSpeicher/FRITZ/candc.data",
 209         AVM_ACL_COMMON_REAL_PREFIX"/FRITZ/candc.data",
 210         "/var/InternerSpeicher/FRITZ/candc.update",
 211         AVM_ACL_COMMON_REAL_PREFIX"/FRITZ/candc.update"
 212 };
 213
 214 #define DIM(array) (sizeof(array)/sizeof((array)[0]))
(aus den Quellen der libavmacl2.so)

Denn zu allem Überfluß gibt es tatsächlich auch noch Aufrufe von tr069fwupdate mit anderen "Operationen" ... z.B. Ex- und Import von Einstellungen configexport bzw. configimport), aber auch bei einem richtigen "extern ausgelösten" Update (über TR-064/TR-069) übernimmt tr069fwupdate dann den Download des Firmware-Images und die weitere Verarbeitung.

Am Ende ist der Ablauf eines einzelnen Updates also abhängig von der Firmware-Version, dem Update-Trigger und dem Typ der Update-Datei, bis hin zur Frage, ob das ein SILENT_UPDATE-Image ist oder nicht. Daher gibt es da auch keine pauschalen und einfachen Antworten. Am besten verfolgt man das wieder selbst unter Verwendung von strace - dann kann man einigermaßen den Control-Flow nachvollziehen, zumindest welche Library da welche andere lädt ... oder man sucht sich die Namen von Funktionen und welche Library die jeweils bereitstellt mit einem nm -D und bastelt sich damit ein Schema der Abhängigkeiten der Libraries zusammen.

Denn gerade an dieser Stelle hat AVM auch in den letzten zwei, drei Jahren vieles geändert (man sieht es ja auch schon am Handling der verschiedenen Updates im GUI) und eigentlich müßte man (da es ja nirgends von AVM dokumentiert wird) bei jeder dieser Änderungen wieder all die Tests wiederholen, mit denen zuvor irgendwelche Zusammenhänge untersucht wurden. Nur hat dafür wohl niemand wirklich die Zeit und so wird es wohl erst dann wieder "gründlich" geprüft werden, wenn irgendjemand (außerhalb von AVM) ohnehin an diesen Stellen irgendetwas zu tun hat - von der Suche nach vorhandenen Lücken in der Sicherheit bis zum Ersatz bzw. der Nachbildung von AVM-Funktionen. Der ganze Thread hier ist ja auch schon wieder mehr als fünf Jahre alt.
 
Nun, man kann diese nicht akzeptierte Datei noch einmal durch die Prüfung jagen und sich dabei den Hash-Wert, den das FRITZ!OS dabei errechnet (in der firmware_stream_result) notieren, so wie ich das am Anfang des Beitrags gezeigt habe.

Dann geht man mit dieser Datei wiederum hin und behandelt sie so, wie ich es oben mit dem AVM-Image gemacht habe (alles Unwesentliche hinten abschneiden und dann so lange Null-Blöcke anhängen, bis man den AVM-Hash (der sich natürlich von dem unterscheidet, den ich oben verwendet habe) gefunden hat).
Erstmal vielen Dank für Deine Arbeit!
Das ist meine signierte 7.29
Code:
# cat /var/tmp/firmware_stream_result
total=30710272 ret=0 sub_ret=0 sigcrc=9eb353869595f308ff73dacc1c70b2cd

Und das Log mit Deinem "Muster"

Code:
root@homeserver /opt/7530_test > grep -abo "./var/signature" avm.image
30708224:./var/signature
root@homeserver /opt/7530_test > dd if=avm.image of=avm.data bs=512 count=$(( 30708224 / 512 )) 2>/dev/null
root@homeserver /opt/7530_test > ls -l
total 59984
-rw-r--r-- 1 root root 30708224 Nov 15 19:13 avm.data
-rw-r--r-- 1 root root 30710272 Nov 11 06:19 avm.image
root@homeserver /opt/7530_test > md5sum avm.*
4b932a67f15cc639c9bd48dd1b2cadd7  avm.data
ca5cb693532a921fe082bf29af2a243e  avm.image
root@homeserver /opt/7530_test > md5() { [ -n "$1" ] && md5sum "$1" | sed -n -e "s|\(^[a-f0-9]*\).*|\1|p"; }
root@homeserver /opt/7530_test > for i in $(seq 20); do cur=$( ( cat avm.data; dd if=/dev/zero bs=512 count=$(( i - 1 )) 2>/dev/null ) | md5 -); printf "%02u = %s\n" "$(( i - 1 ))" "$cur"; [ "$cur" = "9eb353869595f308ff73dacc1c70b2cd" ] && break; done
00 = 4b932a67f15cc639c9bd48dd1b2cadd7
01 = a9f8f4249c13f918065de2c78a2517b7
02 = ef8aa6e0422aeadbbd650f0f11d9b9e1
03 = 9da3eeda83271523a3a8003db0cfd226
04 = e2d60f2ec853b04ba7344a11b8db9c0d
05 = 1e02f963a75fc8b0c1bc4b50236eb0cd
06 = dc3dd20ec60f2f21d6199deb196484b6
07 = 599d03b5056c7937fefc020ad6a930e0
08 = b1822d3d7cec93cc81c8b3c8d26e1a38
09 = 9ab8039b883cf1c048710a8e391fdb37
10 = 4bd48534a65081adcaceb3e0028877d5
11 = 5174b5acb87a1fd0b59c0dcb3f080950
12 = a1b9c7b9af3c703fd7d2c716e9e635a8
13 = 22b41d3831eac54759dd32c62730f79c
14 = 5e881a221703ec1d0028ba5bb1255b25
15 = d2a3e94755d7a530be2e664a22d52f34
16 = f0b1ad7a16a708aa80ee0dd8f245d142
17 = 836c4a22f0bfa57b967169ecb6da38ff
18 = d67b914e9f7121fc9dd4d9b3e7de2317
19 = f5b30755f54847e98994cec9c91ae695
root@homeserver /opt/7530_test > hexdump -C avm.image | sed -n -e "/^$(printf "%08x" "30708224")/,\$p"
01d49200  2e 2f 76 61 72 2f 73 69  67 6e 61 74 75 72 65 00  |./var/signature.|
01d49210  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01d49260  00 00 00 00 30 30 30 30  37 35 35 00 30 30 30 30  |....0000755.0000|
01d49270  30 30 30 00 30 30 30 30  30 30 30 00 30 30 30 30  |000.0000000.0000|
01d49280  30 30 30 30 32 30 30 00  31 34 31 34 33 31 32 33  |0000200.14143123|
01d49290  36 36 31 00 30 31 32 34  32 31 00 20 30 00 00 00  |661.012421. 0...|
01d492a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01d49300  00 75 73 74 61 72 20 20  00 72 6f 6f 74 00 00 00  |.ustar  .root...|
01d49310  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01d49320  00 00 00 00 00 00 00 00  00 72 6f 6f 74 00 00 00  |.........root...|
01d49330  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01d49400  81 4d 2f 18 c9 a9 fc f5  70 c8 94 00 46 6a a9 80  |.M/.....p...Fj..|
01d49410  fc 74 6e 1c fb 7d 9b 46  ef e2 04 61 93 89 69 a5  |.tn..}.F...a..i.|
01d49420  86 27 b4 92 ec de 79 2f  f3 b4 5e 44 6f 66 20 66  |.'....y/..^Dof f|
01d49430  b6 b7 92 c9 b1 27 e6 75  b0 a0 6e 44 c7 db d6 27  |.....'.u..nD...'|
01d49440  3f ee 9d 85 a4 43 ff 25  ec e3 d1 50 f7 46 1d ce  |?....C.%...P.F..|
01d49450  3e aa 31 c5 4a 6a 77 5c  0d f4 f6 19 bc 0c 54 4b  |>.1.Jjw\......TK|
01d49460  d2 38 26 ab 59 ef a1 75  df f2 93 ec 57 8f b3 b9  |.8&.Y..u....W...|
01d49470  aa cf 37 ec cc bd 57 c3  62 d9 1a a9 d3 4a b6 03  |..7...W.b....J..|
01d49480  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01d49a00
root@homeserver /opt/7530_test >

VG. Insti
 
Die Länge der signierten Datei sieht schon mal richtig aus - der Signatur-Header geht von 0x1d49200 bis 0x1d493ff, die Daten in der Signatur-Datei starten an Offset 0x1d49400 und gehen bis 0x1d495ff. Danach steht an den Offsets 0x1d49600 und 0x1d49800 jeweils ein 512-Byte-Block mit binären Nullen. Damit müßte jetzt aber der Hash-Wert beim Anfügen von vier leeren Blöcken (von 0x1d49200 bis 0x1d499ff - also die Zeile, die mit 04 beginnt) dem entsprechen, den das FRITZ!OS auch verwendet/ermittelt - hier liegt dann auch der Hund begraben.

Schaut man sich aber die Größe der zu signierenden Daten an (0x1d49200 = 30.708.224), sind das 2998 Blöcke mit jeweils 10.240 Bytes und 8.704 Bytes im letzten Block, was 17 512-Byte-Blöcken (des tar-Formats) entspricht. Bei einem Block mehr (also bei 18 Blöcken = 9.216 Bytes) gäbe es schon eine Sonderbehandlung (https://github.com/PeterPawn/YourFr...34094fea4d349fb5de9/signimage/sign_image#L400) - sooo sehr kann ich eigentlich nicht daneben gelegen haben mit dem bisherigen Workaround und die Länge des Datenstroms, der da beim Signatur-Check verarbeitet wurde (30.710.272 Bytes), entspricht auch der Größe der Image-Datei, da kann also auch kein Block am Ende fehlen oder ähnliches. Das macht es irgendwie noch merkwürdiger, weil ja auch weitere Blöcke, die das FRITZ!OS zusätzlich hinten angefügt haben könnte, dann nicht ins Bild passen - es kommt ja auch bei den weiteren Zeilen keine, wo der Hash passen würde.

Bitte lege mal vor dem Einpacken mit tar noch eine leere Datei im einzupackenden Verzeichnis an (einfach ein touch dummy.image in dem Verzeichnis, wo auch kernel.image und filesystem.image liegen) und lasse dieses Image dann noch einmal signieren (inkl. Protokoll). Durch die zusätzliche Datei sollte das Image um 512 Byte größer werden und beim Signieren der oben verlinkte Workaround greifen - damit wird da noch ein weiterer Block beim Signieren hinzugefügt. Von dieser Datei dann bitte noch ein tar -t -v -f ... machen, damit man die Liste der enthaltenen Dateien sehen kann ... und dann das oben bereits für die letzte Datei ausgeführte Procedere noch einmal für dieses neue Image ablaufen lassen.

Ich will letztlich sicher gehen, daß/ob es tatsächlich nur bei dieser Dateigröße zum Problem kommt - es gibt im Repo auch noch ein Skript zum Testen dieses Problems, das ich vor einigen Jahren geschrieben hatte, um den Fehler und mögliche Workarounds zu dokumentieren: https://github.com/PeterPawn/YourFritz/blob/main/signimage/test_signature_problem - ich müßte aber erst mal selbst testen, ob das heute noch in genau derselben Form auf der Box ausgeführt werden kann, wie es früher der Fall war. Notfalls kann man dabei auch die Varianz der getesteten Dateigrößen noch erhöhen (im Moment sind das nur drei Tests, um die Länge mit dem vermuteten Fehler herum) und damit dann auch noch die anderen Fälle (20 Tests bei einer angenommenen Blocksize von 10.240 Bytes) durchprobieren.

Andererseits kann man auch erst einmal das Image direkt an firmwarecfg stream verfüttern, allerdings muß das auf der Box erfolgen (bei mir mal mit einer älteren Inhaus-Version auf einer 7490):
Rich (BBCode):
~ # cat /var/media/ftp/system/FB7490/firmware/FRITZ.Box_7490-07.24-87579-Inhaus.image | /usr/www/cgi-bin/firmwarecfg stream 1 0 | tar -x -v; cat /var/tmp/firmware_stream_result;
./var/unpack/
./var/unpack/install
./var/unpack/tmp/
./var/unpack/tmp/kernel.image
./var/unpack/tmp/filesystem.image
./var/unpack/info.txt
./var/unpack/install-features
./var/unpack/content
./var/unpack/version
./var/unpack/chksum
./var/unpack/signature
total=34682880 ret=0 sub_ret=0 sigcrc=b6254d448c7b7828d1782991c8241bd3
~ #
, das wäre eine Überprüfung, ob da irgendein Member dem FRITZ!OS nicht paßt - dann würde der als /var/ignored_tar_content (iirc) auftauchen beim Entpacken. Allerdings erfolgt die Umformung (also das Einfügen von unpack in den Pfadnamen für jeden Member) normalerweise auch erst NACH der Berechnung des Hash-Wertes - das ist also eher eine Vorsichtsmaßnahme, um nichts zu übersehen, falls da irgendein anderes Problem mit dem Aufbau der Datei besteht. Viel verspreche ich mir vom Ergebnis allerdings selbst nicht, das wird vermutlich funktionieren und ich sähe keinen Grund, warum da ein anderer Hash (bei sigcrc) berechnet werden sollte, solange das tr069fwupdate nichts an den Daten ändert, die es selbst an firmwarecfg stream weiterleitet. Aber Vorbeugen ist bekanntlich immer noch besser, als nach hinten zu fallen und ehe man sich in zwei Wochen ärgert, daß man da etwas übersehen hat, ist es besser, das gleich auch noch zu prüfen.

Wenn Du noch eine andere Box hast, kannst Du auch auf der mal ein (von der 7530 abgelehntes) Image durch firmwarecfg stream oder auch durch tr069fwupdate packet jagen - die Fragestellung dabei wäre, ob diese andere Box (am besten auch noch eine mit MIPS-Architektur, weil die 7530 ARM ist und LE-Byteorder verwendet) auf denselben Hash-Wert kommt, wie die 7530. Wenn da irgendwelche Corner-Cases bei der Frage, wie lang die zu hashenden Daten am Ende sind, mit Bitmaskierungen o.ä. gelöst sind, kann auch die unterschiedliche Byte-Order noch zu einem geänderten Verhalten führen. Das wäre dann zwar immer noch falsch und ein AVM-Problem, aber dort kann man das ja auch ganz einfach dadurch umgehen, daß man einfach die Größe der zu signierenden Daten ändert (indem man irgendwelchen Unsinn zusätzlich ins Dateisystem packt, so daß das beim Packen einen Block mehr benötigt) - und das aktuelle AVM-Image für die 7530 hat zwar ein merkwürdiges Verständnis vom TAR-Format, aber immerhin besteht es die AVM-eigene Signaturprüfung mit Bravour - hat mithin also auch kein eigenes Längenproblem.
 
Code:
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.42 Kbytes (24.81 Mbytes)
        21.40% of uncompressed filesystem size (118713.74 Kbytes)
Inode table size 75384 bytes (73.62 Kbytes)
        22.16% of uncompressed inode table size (340150 bytes)
Directory table size 98426 bytes (96.12 Kbytes)
        37.13% 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-16 06:01 ./var/
drwxr-xr-x root/root         0 2021-11-16 06:01 ./var/tmp/
-rw-r--r-- root/root  26017792 2021-11-16 06:01 ./var/tmp/filesystem.image
-rw-r--r-- root/root   3107080 2021-10-28 18:11 ./var/tmp/kernel.image
-rw-r--r-- root/root         0 2021-11-16 06:01 ./var/tmp/dummy.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
Enter the password for the signing key:
Check the password for the private key file ... OK
Repeating first entry as filler ... 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-16 06:01 ./var/
drwxr-xr-x root/root         0 2021-11-16 06:01 ./var/tmp/
-rw-r--r-- root/root  26017792 2021-11-16 06:01 ./var/tmp/filesystem.image
-rw-r--r-- root/root   3107080 2021-10-28 18:11 ./var/tmp/kernel.image
-rw-r--r-- root/root         0 2021-11-16 06:01 ./var/tmp/dummy.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
drwxr-xr-x root/root         0 2021-11-16 06:01 ./var/
-rwxr-xr-x root/root       128 2021-11-16 06:01 ./var/signature
root@homeserver ~ >

Code:
# tr069fwupdate packet file:///var/media/ftp/USB-DISKPro-01/7530_729signed.image ; echo rc=$?
rc=210
# cat /var/tmp/firmware_stream_result
total=30711296 ret=0 sub_ret=0 sigcrc=4bc391e10dd7e82a9f2015f7f50a8de8
#

Code:
oot@homeserver /opt/7530_test > grep -abo "./var/signature" avm.image
30709248:./var/signature
root@homeserver /opt/7530_test > dd if=avm.image of=avm.data bs=512 count=$(( 30709248 / 512 )) 2>/dev/null
root@homeserver /opt/7530_test > ls -l
total 59984
-rw-r--r-- 1 root root 30709248 Nov 16 06:17 avm.data
-rw-r--r-- 1 root root 30711296 Nov 16 06:02 avm.image
root@homeserver /opt/7530_test > md5sum avm.*
0a0d563eabf8745bb95b525765ff9636  avm.data
dc6a54a2085b607798bc829f4ee27794  avm.image
root@homeserver /opt/7530_test > md5() { [ -n "$1" ] && md5sum "$1" | sed -n -e "s|\(^[a-f0-9]*\).*|\1|p"; }
root@homeserver /opt/7530_test > for i in $(seq 20); do cur=$( ( cat avm.data; dd if=/dev/zero bs=512 count=$(( i - 1 )) 2>/dev/null ) | md5 -); printf "%02u = %s\n" "$(( i - 1 ))" "$cur"; [ "$cur" = "4bc391e10dd7e82a9f2015f7f50a8de8" ] && break; done
00 = 0a0d563eabf8745bb95b525765ff9636
01 = bd6953e5854a2fdd8a03286372e5472c
02 = a01e7486527bd45258e29928aa02e685
03 = 84652703132b7e6cac3110744c3f4024
04 = 4bc391e10dd7e82a9f2015f7f50a8de8
root@homeserver /opt/7530_test > hexdump -C avm.image | sed -n -e "/^$(printf "%08x" "30709248")/,\$p"
01d49600  2e 2f 76 61 72 2f 73 69  67 6e 61 74 75 72 65 00  |./var/signature.|
01d49610  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01d49660  00 00 00 00 30 30 30 30  37 35 35 00 30 30 30 30  |....0000755.0000|
01d49670  30 30 30 00 30 30 30 30  30 30 30 00 30 30 30 30  |000.0000000.0000|
01d49680  30 30 30 30 32 30 30 00  31 34 31 34 34 36 33 35  |0000200.14144635|
01d49690  35 30 31 00 30 31 32 34  32 33 00 20 30 00 00 00  |501.012423. 0...|
01d496a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01d49700  00 75 73 74 61 72 20 20  00 72 6f 6f 74 00 00 00  |.ustar  .root...|
01d49710  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
01d49720  00 00 00 00 00 00 00 00  00 72 6f 6f 74 00 00 00  |.........root...|
01d49730  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01d49800  40 0b d8 10 ef 6e e8 69  d7 56 0d 61 37 a7 cf fb  |@....n.i.V.a7...|
01d49810  27 2b 64 d7 5a 84 55 46  42 39 16 89 db 7c 27 a7  |'+d.Z.UFB9...|'.|
01d49820  ad 34 06 df e5 16 00 86  96 10 c0 5d 46 a0 5d 16  |.4.........]F.].|
01d49830  b8 4a 0d 17 37 02 ae 66  2c e0 ea 67 4e 7b b1 38  |.J..7..f,..gN{.8|
01d49840  b7 76 15 cc 79 ed d0 17  9b cc 17 c5 2b fd 2e 09  |.v..y.......+...|
01d49850  41 4c 9a 36 08 5f df 10  63 a0 15 12 b2 05 c6 2a  |AL.6._..c......*|
01d49860  24 77 82 88 01 55 72 79  5f b2 d8 66 7b 61 26 ba  |$w...Ury_..f{a&.|
01d49870  08 43 dd 9e f6 54 f1 2c  33 c3 00 61 7f 5b d6 49  |.C...T.,3..a.[.I|
01d49880  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01d49e00
root@homeserver /opt/7530_test >

Lässt sich trotzdem nicht über das Webinterface installieren.

VG.
 
Lässt sich trotzdem nicht über das Webinterface installieren.
Solange da rc=210 steht kann das auch nicht gehen. Da muss schon rc=3 stehen. Und dann muss es auch noch nicht gehen. Aber das ist erstmal Grundvoraussetzung.
 
Zuletzt bearbeitet:
ob diese andere Box (am besten auch noch eine mit MIPS-Architektur, weil die 7530 ARM ist und LE-Byteorder verwendet) auf denselben Hash-Wert kommt, wie die 7530.
Habe noch eine 7412 mit openwrt auf Partition 0 und ein unverändertes FritzOS 6.86 auf Partition 1.
Kannst Du mir einen Tip geben wie man Telnet von openwrt aus auf die inaktive Partition 1 aktiviert? Geht das überhaupt? Könnte dann auf Partition 1 stellen und auf FritzOS firmwarecfg stream und tr069fwupdate packet testen.
 
Die 7412 kann man ja auch auf linux_fs_start=1 umstellen und dann einfach den Telnet-Zugang mit diesem Image installieren: https://github.com/PeterPawn/first_...a2ffd7348955b/implant_siab_3.10.73.image.7412 - Download-Button in der Seite benutzen. Das kann man auch "auf Vorrat" machen, wenn man will - der Telnet-Daemon muß dann aber noch über die Telefoncodes (oder über das Telefonbuch, wenn man kein Telefon angeschlossen hat und auch keines anschließen kann) gestartet werden, das macht das Image absichtlich nicht, weil es der Benutzer weiterhin kontrollieren soll. Das komplette Zeug ist hier beschrieben: [Info] modfs-Starter - "Einmal-Impfung" mit ShellInABox für VR9-Boxen und wer's noch nicht kennt, sollte auch bis zum Ende lesen, weil sich ein paar Pfade und Namen nach #1 noch geändert haben.

Aber das wäre im Moment tatsächlich nur ein Nebengleis ... die anderen Ergebnisse liefern genug Stoff für weitere Tests und da der letzte Versuch ja wieder einen passenden Hash-Wert gezeigt hat, kann man das auf später vertagen, wenn man wirklich prüfen will, was bei 17 TAR-Blöcken in den letzten 10 KB der Image-Datei passiert.



Die um 512 Bytes größere Image-Datei hat dann genau das erwartete Ergebnis erbracht - durch den einen zusätzlichen Block wird der Workaround getriggert, der Füllblock (samt Nachricht beim Signieren) eingefügt und die resultierende, signierte Datei damit insgesamt um 1.024 Bytes größer als die vom Versuch zuvor. Für die berechnet jetzt auch das FRITZ!OS einen passenden Hash, der wieder genau mit dem übereinstimmt, wenn man "von Hand" den zu signierenden Inhalt um die vier leeren 512-Byte-Blöcke erweitert.

Ich kann es Dir leider nicht ersparen ... aber die Tatsache, daß trotz übereinstimmendem Hash-Wert die Signatur-Prüfung von AVM den Kopf schüttelt, deutet zunächst einmal darauf hin, daß da kein passender öffentlicher Schlüssel zum Decodieren der Signatur-Datei gefunden wurde .. . die 17-Block-Geschichte lassen wir jetzt mal außen vor und versuchen herauszufinden, warum auch die größere Image-Datei, bei der AVM den passenden Hash errechnet, nicht akzeptiert wird.

Weiter oben wird ja gezeigt (https://www.ip-phone-forum.de/threads/sammelthema-zur-avm-fritz-box-7520.302364/post-2449428), daß in der fwsign.log nur so lange neue Einträge auftauchen, bis ein passender öffentlicher Schlüssel gefunden wurde - bei der AVM-Datei, die mit dem privaten Key verschlüsselt wurde, dessen öffentlicher Teil in avm_firmware_public_key1 steht, taucht da nur ein einziger Eintrag für einen Key auf in der Datei.

Das kann man ja jetzt wieder relativ simpel testen. Man ersetzt einfach die erste Datei (avm_firmware_public_key1) durch den eigenen öffentlichen Schlüssel (der wird sicherlich in avm_firmware_public_key9 liegen) und jagt das Image noch einmal durch die Signaturprüfung. Wenn dabei dann in der fwsign.log noch weitere Keys aufgelistet werden, hat der erste offensichtlich "nicht gepaßt". Den Austausch des Keys macht man am einfachsten mit einem mount -o bind /etc/avm_firmware_public_key9 /etc/avm_firmware_public_key1 - nach dem nächsten Reboot ist das dann auch wieder Geschichte, ansonsten kann man auch ein passendes umount nach dem Test verwenden. Allerdings muß dabei dann avm_firmware_public_key9 auch ein "regular file" sein und kein Symlink o.ä. - sollte bei Dir aber der Fall sein, wenn man Dein Skript zum Erstellen anschaut.

Wenn da dann der erste Key NICHT paßt, wäre die nächste Frage, warum das so ist - dazu kann/sollte man dann doch einmal hingehen und alle Voraussetzungen auf der FRITZ!Box schaffen, damit man auch dort die Signaturen unabhängig von der AVM-Firmware prüfen kann. Das wird künftig auch noch mal wichtig werden - die oben erwähnten, systematischen Tests mit unterschiedlichen "Resten" im letzten Block kann man nur auf der Box machen und dafür braucht man dann ohnehin die Möglichkeit, dort auch Images zu signieren und Signaturen zu prüfen. Dafür braucht man (insgesamt) drei Skript-Files aus meinem YourFritz-Repository und ein passendes openssl-Binary - bei der 7530 eines für ARMv7, aber das gibt es (in einer älteren Version, was aber für's Signieren und Prüfen keine Rolle spielt) auch im yf_bin-Repo:
Rich (BBCode):
Trying 192.168.130.1...
Connected to fb7490.
Escape character is '^]'.
Fritz!Box user: **masked**
password:
ermittle die aktuelle TTY
tty is "/dev/pts/0"
Console Ausgaben auf dieses Terminal umgelenkt
disable start/stop characters and flowcontrol
~ # cd /var
/var # for script in check_signed_image sign_image avm_pubkey_to_pkcs8; do httpsdl -n https://raw.githubusercontent.com/PeterPawn/YourFritz/main/signimage/$script; chmod a+x $script; ls -l $script; done
ok
-rwxr-xr-x    1 root     root         30398 Nov 16 14:11 check_signed_image
ok
-rwxr-xr-x    1 root     root         25510 Nov 16 14:11 sign_image
ok
-rwxr-xr-x    1 root     root          9103 Nov 16 14:11 avm_pubkey_to_pkcs8
/var # 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 16 14:16 openssl
/var #
Jetzt hat man die notwendigen Dateien (bis zum nächsten Booten der Box, also nur temporär) auf seiner FRITZ!Box und kann sie verwenden, um die Signatur-Prüfung mit dem Skript oder auch in einzelnen Schritten selbst zu machen. Da es bei mir keine ARM-Box ist, sondern eine 7490, muß ich erst noch das richtige openssl-Binary laden - das darf man auf einer ARM-Box dann halt nicht nachmachen, während man auf einer MIPS-Box (ab VR9) auch gleich das passende Binary laden sollte.
Rich (BBCode):
/var # httpsdl -n https://raw.githubusercontent.com/PeterPawn/yf_bin/master/target/mips/3.10.107/openssl; chmod a+x openssl; ls -l openssl
ok
-rwxr-xr-x    1 root     root       2581544 Nov 16 14:20 openssl
/var # YF_SIGNIMAGE_OPENSSL=/var/openssl /var/check_signed_image /var/media/ftp/system/FB7490/firmware/FRITZ.Box_7490-07.24-87579-Inhaus.image -b
Found OpenSSL 1.0.2s  28 May 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 ... OK
Checking support for the used hash algorithm md5 ... OK
Verification succeeded.
# Gegenprobe, bei welcher der passende Key durch einen anderen "überdeckt" wird
/var # mount -o bind /etc/avm_firmware_public_key3 /etc/avm_firmware_public_key1
/var # YF_SIGNIMAGE_OPENSSL=/var/openssl /var/check_signed_image /var/media/ftp/system/FB7490/firmware/FRITZ.Box_7490-07.24-87579-Inhaus.image -b
Found OpenSSL 1.0.2s  28 May 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
No usable public key was found.
/var # umount /etc/avm_firmware_public_key1
/var # 
Die Gegenprobe soll zeigen, wie das aussehen müßte, wenn da tatsächlich kein passender Key existiert - der nächste Test sollte jetzt die Signaturprüfung der zuletzt verwendeten Image-Datei (die mit der Länge 30.711.296) mit dem Skript auf der Box sein. Je nachdem, wie das Ergebnis dabei ausfällt, muß man dann weitersehen - der Teil mit den 17 Blöcken kommt erst danach, wenn das Problem für die zuletzt erzeugte Image-Datei geklärt werden konnte.

Die zwei Eingaben aus dem ersten CODE-Kasten kann/sollte man sich auch gut weglegen - ich würde die Dateien immer wieder direkt aus dem Netz laden und NICHT auf irgendwelchen USB-Sticks oder im NAS-Flash speichern (zumindest nicht von dort aufrufen), da dort üblicherweise Mounts mit noexec-Option aktiv sind und es am Ende egal ist, ob man nur dieses Hindernis beseitigt oder die Dateien einfach nur schnell noch einmal lädt oder nach /var kopiert - das temporäre Speichern in /var ist einfach per se die sicherere Methode, weil sie keine permanenten Löcher reißt und dort kann man dann auch mal schnell irgendwelche Änderungen mit einem Editor an Skript-Dateien vornehmen, ohne die am Original danach wieder rückgängig machen zu müssen. Allerdings habe ich hier auch auf die Prüfung der Signatur (für das openssl aus dem Repo) verzichtet, weil GnuPG auf der Box nicht so einfach ist - wer das tatsächlich ordentlich geprüft hat (z.B. kann man auf einen System mit GnuPG die Signatur prüfen und dann den Hash-Wert für das Binary auf dem anderen System und auf der Box vergleichen - dann aber bitte auch mind. mit SHA2-Algorithmen), kann sich die Datei natürlich auch lokal speichern und sie dann eben von dort nach /var kopieren.
 
  • Like
Reaktionen: prisrak1
Vielen Dank @PeterPawn für die Muster!
Die zwei Eingaben aus dem ersten CODE-Kasten kann/sollte man sich auch gut weglegen -
Code:
YF_SIGNIMAGE_OPENSSL=/var/openssl /var/check_signed_image /var/media/ftp/USB-DISKPro-01/7530_729signed.image -b
/var/check_signed_image: line 376: mktemp: not found
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.
 

Statistik des Forums

Themen
246,084
Beiträge
2,245,795
Mitglieder
373,539
Neuestes Mitglied
Horst Fürst
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.