Backup/Restore der Freetz-NG-Settings

[PeterPawn]

Da ich diesen Commit: ec0f126 gerade gesehen habe, will ich das Thema noch einmal generell ansprechen.

Das Backup ermöglicht es ja auch, die anderen "Flash-Dateien" in die Sicherung einzubeziehen (bzw. es läßt einem gar keine Wahl und schließt diese Dateien immer generell mit ein) und dann - auch auf einem anderen Gerät - wiederherstellen zu lassen.

Das KANN bei den AVM-Files aber so gar nicht funktionieren, da diese bekanntlich die schützenswerten Daten (zumindest das, was AVM dahingehend einschätzt) nur in verschlüsselter Form enthalten und diese Verschlüsselung von der (Bootloader-)Konfiguration des einzelnen Gerätes abhängig ist:

• https://www.ip-phone-forum.de/threads/wie-funktioniert-eigentlich-die-avm-verschl%C3%BCsselung-f%C3%BCr-die-einstellungen.295101/
• https://github.com/PeterPawn/decoder
• https://github.com/Freetz-NG/freetz-ng/tree/master/make/decrypt-fritzos-cfg

Das führt dann dazu, daß die Kollegen, die mit einer solchen Sicherung auf einem anderen Gerät beim Wiederherstellen die Option Nur Freetz-Einstellungen wiederherstellen ABWÄHLEN, am Ende definitiv mit einer FRITZ!Box dastehen, die sich nur durch Recovery wieder zum (sinnvollen, also mit Möpsen) Leben erwecken läßt.

Dafür (bzw. genauer ja: dagegen) gäbe es natürlich mehrere (Software-)Lösungen ... die einfachste dürfte es zunächst mal sein, daß man - zumindest beim Vorhandensein von decrypt-fritzos-cfg mit decode_secrets-Funktion (keine Ahnung mehr, ob die da noch einmal umbenannt wird, wenn das originale Projekt in Freetz eingebunden wird) - die restlichen Dateien auf verschlüsselte Daten durchsucht (die identifiziert man ganz einfach an den vier Dollarzeichen) und dann versucht, diese Daten mit den Properties der aktuellen Box zu entschlüsseln. Wenn das nicht funktionieren sollte, stammt das Backup von einem anderen Gerät und es macht gar keinen richtigen Sinn, die anderen Einstellungen auch wiederherstellen zu wollen.

Wenn man das dann in diesem Falle für diese zusätzlichen Files einfach bleiben läßt und eine entsprechende Warnung ausgibt, macht man zumindest nichts falsch. Bleibt noch die Frage, was man macht, wenn das Binary zum Dekodieren nicht vorhanden ist - dann wird die Erkennung, daß es sich um ein Backup von einem anderen Gerät handelt, schon deutlich schwieriger.

Eine Option wäre es dann z.B., daß man die relevanten Properties der Source-Box einfach mit in die Sicherungsdatei einpackt - dann kann man (natürlich nur wieder mit dem passenden Programm) diese Einstellungsdateien auch noch nachträglich entschlüsseln. Das müßte/sollte dann natürlich wieder nur so erfolgen, daß diese zusätzlichen Properties OPTIONAL in der Sicherungsdatei vorhanden sein können ... erstens existieren sie in älteren Sicherungen ohnehin nicht (Rückwärtskompatibilität) und zweitens macht man damit die Box ja tatsächlich "nackig", denn die Freetz-Sicherung selbst ist auch überhaupt nicht weiter geschützt und selbst das sollte ohnehin mal in Angriff genommen werden:

The router MAY offer an option to save the current configuration of the router to a file. This backup can be used to easily restore a previously running configuration on the same router model. The configuration file SHOULD only be exported in an encrypted way and SHOULD be protected by a user selected password. The end-user SHOULD be assisted upon setting the password by a mechanism indicating the strength of the password by a mechanism similar to the one described for access to the configuration (see above). To export and/ or import the router settings the end-user MUST be successfully authenticated at the device.

(aus: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03148/TR03148.pdf?__blob=publicationFile&v=1)

Denn auch die Sicherung der Freetz-Einstellungen enthält ja ggf. wichtige Dateien, die man besser wirklich "geheim" halten sollte - das geht bei privaten Schlüsseln (für VPN oder SSH) los und zieht sich bis zu Credentials für irgendwelche anderen Services, die von Freetz-Komponenten benutzt werden.

Schon die Frage, ob es tatsächlich notwendig oder auch nur sinnvoll ist, die anderen Einstellungen ebenfalls in die Sicherung einzubeziehen (auch wenn bei AVM die wichtigsten Daten eben verschlüsselt sind - das würde man mit der zusätzlichen Speicherung der Properties ja auch wieder "aufweichen" und diese zusätzliche Speicherung bräuchte man nur/machte nur Sinn, wenn man die anderen Files einschließt in die Sicherung), sollte noch einmal gründlich durchdacht werden - die AVM-Sicherung weiß damit viel besser umzugehen und selbst wenn man einige der bei AVM nicht automatisch mit gesicherten Dateien einbeziehen will (z.B. die websrv_ssl_key.pem und die websrv_ssl_cert.pem bzw. deren LE-Gegenstücke von AVM), so sollte man das auf diese Dateien beschränken und nicht einfach alles in die Freetz-Sicherungsdatei klatschen.

Aber selbst wenn man das AVM-Zeug weiterhin alles sichern wollte ... auch dann sollte man unterscheiden, ob die Sicherung von derselben Box stammt (das geht z.B. mit einem Hash über ein paar feste Einstellungen aus dem Urlader-Environment auch dann, wenn man diese einzelnen Einstellungen gar nicht einschließen will in die Sicherungsdatei) und sich für die AVM-Files bei der Wiederherstellung weigern, wenn es sich um eine andere Box handelt.

Wobei das dann das Problem der Sicherung der Freetz-Einstellungen "im Klartext" auch nicht löst - das bliebe bestehen. Je nachdem, wofür man sich jetzt bei den AVM-Einstellungen entscheidet, sollte man dann eben auch zusätzlich das Freetz-Backup noch mit einer Verschlüsselung ausgeben - das macht auch gleich einen viel besseren "Eindruck" (s.o. das Zitat aus der BSI-Richtlinie).

Und so eine Verschlüsselung der gesamten Backup-Datei würde dann auch wieder die Sicherung der AVM-Dateien im dekodierten Zustand ermöglichen (zumindest sollte man das ohne zusätzliche Verschlüsselung des Backups gar nicht erst in Erwägung ziehen) - dann müßte man allerdings decoder (bzw. decrypt-fritzos-cfg) wieder automatisch mit einschließen lassen (das kann man auch auf die notwendigen Applets beschränken) oder diese "Gesamtsicherung" vielleicht auch nur dann überhaupt anbieten, wenn das Binary dafür existiert in der vorliegenden Installation.

Wenn es weiterhin "nur" die Freetz-Einstellungen sind, mag es auch ohne Verschlüsselung akzeptabel sein ... wobei ich mir dann auch mal überlegen würde, ob man nicht die schützenswerten Daten (s.o., speziell private Schlüssel) ohnehin in den Freetz-Einstellungen in der Box auch nur in verschlüsselter Form ablegen sollte, wie es AVM mit den eigenen Dateien (SSL-Server bzw. Let's Encrypt) vormacht.

Solche Files werden üblicherweise auch nur einmal geöffnet von irgendwelchen Daemons und diese müssen auch nur für diesen einmaligen Vorgang beim Start das Kennwort zum Entschlüsseln kennen - da brauchen diese "geheimen Daten" nicht die ganze Zeit im Klartext irgendwo herumliegen ... selbst wenn die mit dem richtigen Kennwort auch wieder jeder entschlüsseln könnte. Das ist einfach eine Frage des Security-Designs - und da gehört es zu den Grundtugenden, daß geheime Daten nur dann und so lange zugänglich sind, wie es tatsächlich erforderlich ist.

Allerdings würde das automatische Ver- und Entschlüsseln (zumindest bei den Backups) auch wieder das permanente Einschließen entsprechender Programme (für OpenSSL oder GnuTLS, etc.) erforderlich machen, da die bei AVM ja nicht automatisch in der Firmware enthalten sind. Aber wenn man die dynamisch gegen die entsprechenden Crypto-Libraries linkt, sind die auch von der Größe her durchaus zu verkraften - und ich würde mich da sogar auf OpenSSL festlegen, weil das (a) bei AVM auch im Image ist (was OpenPGP schon mal rausfallen läßt) und (b) man ansonsten die ganze Kryptographie wieder über irgendwelche Wrapper-Skripte machen müßte, wenn man beim Ver- und Entschlüsseln unbedingt "flexibel" bleiben und auch andere CLI-Programme für diese Aufgaben unterstützen will. Das kann man (wenn es wirklich notwendig sein sollte, was ich auch in Zweifel ziehen würde) dann in einem zweiten Schritt ja auch noch nachträglich machen.

Selbst wenn man für das Ermitteln des Kennworts z.B. auf privatekeypassword (https://github.com/Freetz-NG/freetz-ng/tree/master/make/privatekeypassword) zurückgreifen könnte und damit den Daemons, die auch mit verschlüsselten Key-Files umgehen können, das Kennwort zum Entschlüsseln bereitstellen könnte (und dieses Programm ist nun wirklich von einer nicht nennenswerten Größe), braucht man zum verschlüsselten Speichern solcher Dateien immer noch ein "richtiges" Krypto-Programm und solange man das nicht selbst schreiben will (was AVM praktisch macht, denn da ist dieses verschlüsselte Speichern in den AVM-Komponenten direkt verbaut - weshalb man ja auch keine passenden Binaries für den "allgemeinen Gebrauch" in der Firmware hat). muß man eben etwas "Fertiges" nehmen und da wäre OpenSSL (bzw. das dort enthaltene CLI-Programm) zunächst mal meine eigene Präferenz, wenn ich das machen müßte.

Aber die letzten Absätze sind schon wieder Ideen, was man machen könnte (und SOLLTE!) ... das "Grundproblem" der Wiederherstellung der AVM-Files aus einer anderen Box sollte man in jedem Falle (irgendwie) lösen, denn es macht wenig Sinn (und das GUI warnt m.W. (bzw. nach meinem Lesen in der index.cgi) noch nicht einmal davor), die (AVM-)Einstellungen EINER ANDEREN Box so wiederherzustellen, wie es in der do_restore.cgi (https://github.com/Freetz-NG/freetz-ng/blob/master/make/mod/files/root/usr/mww/cgi-bin/backup/do_restore.cgi#L33) zu sehen ist.

Egal, wie man es in der Zukunft machen will ... so, wie es derzeit in Freetz(-NG) läuft, ist es bescheiden und (für den unkundigen Benutzer, der von den Fallen nichts weiß) extrem fehlerträchtig. Hier wäre eine einfache "Sperre", die ein Wiederherstellen von Einstellungen, welche die Box definitiv unbenutzbar machen, verhindert, schon ein gewaltiger Fortschritt.

[fda77]

Das mit dem "sleep" vor der Änderung war witzlos, da so einfach die Webseite erst nach dem "sleep" vollständig geladen war -.-

Parameter "char" und "file" von modsave sind in ng neu. Damit hatte ich wegen der 32kb Grenze experimentiert. Mit der 7490 funktioniert das, aber nicht 7590:

$ modsave file
Creating /var/flash/freetz (file) ... not supported, aborted.

Ich denke mit einem Freetz-Backup sollte man nicht auf einem anderen Gerätetyp wiederherstellen, dazu sollte man die AVM funktion nutzen.

Für ein anderes Gerät des gleichen Types ist das so natürlich doof.. Man könnte aus proc/sys/urlader/environment noch die "maca" mit in die Sicherung nehmen, dann kann man das Widerhestellen von AVM Einstellungen abbrechen.
Auch noch ins Backup aufnehmen könnte man das "Passwort" von AVM zum dekodieren - ich hab aber keine Ahnung wo das zu finden ist. Brauch man dafür unbeidingt privatekeypassword?
Falls dann ein anderes Gerät erkannt wird:

• kommt entweder ein Abbruch mit Hinweis
• oder es wurde vorher eine Option vom Benutzer im Webif ausgewählt die $$$$ entschlüsselt wiederherzustellen. Diese Option gibt es aber nur wenn man das zusätzlich nötigen privatekeypassword installiert hat
  Damit wird ein "normales" Image nicht größer

Eine Option zum ver/entschlüsseln könnte man auch optional anzeigen wenn openssl vorhanden ist (bei 8/16mb flash Geräten unwahrscheinlicher)

[fda77]

Laut https://github.com/PeterPawn/privatekeypassword#purpose

new version computes the password itself from maca value

Also müsste mit der maca in der tar schon alles fürs spätere Wiederherstellen vorhanden sein :)
Nur scheinbar kann man "getPrivateKeyPassword" keine maca übergeben

[PeterPawn]

Lies Dir den Thread zur Verschlüsselung durch bzw. schau in die Shell-Skripte im decoder-Projekt. Das Kennwort - für das Dekodieren des privaten Schlüssels in der websrv_ssl_key.pem von AVM - wird anhand der maca der jeweiligen Box gebildet - das hat aber mit dem Rest der Verschlüsselung von AVM-Einstellungen absolut nichts zu tun und damit ist

Also müsste mit der maca in der tar schon alles fürs spätere Wiederherstellen vorhanden sein :)

auch falsch als Annahme.

Wenn's Dir nur um die Feststellung geht, ob/daß das Backup auf einer anderen Box erzeugt wurde, nimm einfach meinen Vorschlag von oben auf und bilde mit den vier Eigenschaften, die zum Verschlüsseln der AVM-Einstellungen benötigt werden (siehe Thread, das habe ich alles schon einmal aufgeschrieben) einen eigenen Hash-Wert (am besten keinen MD5-Hash, weil das ja gerade das ist, was AVM macht oder Du müßtest wenigstens die Ausgangsdaten in anderer Reihenfolge verwenden), der zusätzlich im Backup gespeichert wird. Den kannst Du dann vergleichen mit den Daten der vorliegenden Box (einfach wieder denselben Hash bilden und die Ergebnisse vergleichen) und dann die Wiederherstellung der AVM-Daten verweigern. Löst zwar nicht das Problem alter Backups ohne diesen Hash im Inhalt, ist aber ein erster Schritt.

Brauch man dafür unbeidingt privatekeypassword?

Das braucht man (a) nicht zwingend (siehe Shell-Skript dazu) und (b) hat das mit dem Verschlüsseln von Einstellungen bei AVM gar nichts zu tun.

Das ist nur das Kennwort, mit dem AVM selbst den privaten Schlüssel für das SSL-Zertifikat der Box verschlüsselt und das privatekeypassword gibt es eigentlich nur deshalb, damit man mit einem wirklich winzigen Programm (denn decoder enthält noch einmal dieselbe Funktion, ist aber deutlich größer, dafür natürlich auch leistungsstärker) in der Lage ist, genau dieses SSL-Zertifikat der Box auch für andere Daemons (von Shell-in-a-Box über stunnel bis zu dropbear (das braucht aber weitere Patches) und httpd aus Apache2) zu nutzen, ohne die Notwendigkeit, ein weiteres Zertifikat (bzw. viel wichtiger: einen weiteren privaten Key, um dessen Sicherheit man sich auch kümmern sollte) irgendwo auf der Box speichern zu müssen, wenn einem die 2048-Bit des RSA-Keys für das von der Box selbstgenerierte Zertifikat (das man ja auch im AVM-GUI durch eigenen Key + Zertifikat ersetzen kann, die werden dann aber genauso verschlüsselt) auch reichen für eigene Zwecke.

Und ehe der Nächste fragt ... das Kennwort, mit dem AVM den Key zum LE-Zertifikat verschlüsselt, ist ein anderes und ich weiß auch noch nicht, woraus dieses gebildet wird (https://www.ip-phone-forum.de/threads/stunnel-mit-myfritz-ssl-zertifikat-ausf%C3%BChren.309489/#post-2413927). Wenn ich dafür mal die Zeit finde (und eine Box, auf der ich das testen kann, weil die sich ein LE-Zertifikat über den AVM-Weg besorgen konnte), dann baue ich das als Erweiterung auch in decoder ein - bis dahin muß es erst mal ohne gehen bzw. es steht ja jedem frei, da auch eigene Recherchen (bzw. RE) zu betreiben.

[fda77]

Schade, das wäre zu einfach gewesen. Ich muss mir den Thread/Post mal bei Zeit genau durchlesen.
Zu Prüfung ob es die richtige Box ist reicht die maca doch.
Mein Plan war es im Backup das "Passwort" zum Entschlüsseln mit zu sichern.
Und beim Wiederherstellen kann man dann angeben dass es unverändert oder entschlüsselt zurückgeschrieben wird falls nötig. Dann braucht man keine zusätzlichen Pakete ausser man will auf einem anderen Gerät Restoren. Man könnte auch ein Script für den Computer nehmen der eine Sicherung entschlüsselt

[PeterPawn]

Du solltest den Thread tatsächlich erst mal lesen ... schon die Idee:

Mein Plan war es im Backup das "Passwort" zum Entschlüsseln mit zu sichern.

ist für sich gesehen "furchtbar" (abgesehen davon, daß man decoder eben die passenden Daten der Box auch auf der Kommandozeile übergeben kann, sonst machte das Entschlüsseln auf anderen Systemen als einer weiteren Box ja auch keinen Sinn), solange dann das Backup nicht selbst noch verschlüsselt ist - das wäre dann das genaue Gegenteil dessen, was ich meinte bzw. anregen wollte. So eine Sicherung ist eine Einladung an jeden Hacker - ungefähr so schlau wie das Kennwort unter der Tastatur oder der Schreibunterlage.

Ich hoffe also mal, daß ich das bloß mißverstanden habe - ansonsten hätte ich die Freetz-Benutzer erst richtig in die Sch***e geritten.

Auch das

Zu Prüfung ob es die richtige Box ist reicht die maca doch.

ist nur bedingt richtig, denn für eine erfolgreiche Entschlüsselung von "secrets" in den wiederhergestellten AVM-Dateien braucht es eben mehr als maca - wenn man das schon vor dem Überschreiben der Dateien "testen" will, kann/sollte man es auch gleich richtig machen und dabei sicherstellen, daß tatsächlich ALLE relevanten Einstellungen auch denen entsprechen, wie sie auf der "Quell-Box" vorlagen ... denn nur dann wird danach auch die AVM-Firmware damit etwas anfangen können. Zwar wäre eine (vorsätzliche) Änderung von maca auch unwahrscheinlich, aber wenn man es tatsächlich gleich "ricthtig" bzw. "gründlich" prüfen kann, wäre es (in meinen Augen zumindest) ja Unfug, dabei auf halber Strecke stehenzubleiben und damit dann doch wieder Probleme beim Entschlüsseln durch die AVM-Komponenten zu riskieren.

[fda77]

Ich seh da kein Problem zb einfach das ganze Environment mitzusichern. (ich hab sogar ein Gerät mit richtiger Serial und tr069). Die Freetz Daten sind ja eh komplett ungeschützt. In denen hab ich zumindest wichtigere Passwörter als im AVM Teil. Wenn man Zugriff auf's Freetz-Webif hat kann man eh Shellbefehle ausführen. Falls es unbedingt sein muss kann man das env optional mitspeichern. Oder env nur sichern falls die Sicherung passwortgeschützt ist

Wenn man die tar noch mit openssl-pipe verschlüsselt ist der Freetz Teil und das env auch geschützt.

[PeterPawn]

Wenn man die tar noch mit openssl-pipe verschlüsselt ist der Freetz Teil und das env auch geschützt.

Das meinte ich ja mit "Verschlüsseln", wobei man sich überlegen kann, ob man das vor oder nach dem tar macht, denn eine verschlüsselte Datei ist dann praktisch "unkenntlich", was den Inhalt angeht und nur noch am Namen zu identifizieren.

Da ist eine Verschlüsselung der einzelnen Member (wenn die nicht - wie bei AVM - schon selbst verschlüsselte Daten für die wichtigen Secrets enthalten) dann besser zu handhaben, weil man auch noch eine kleine (unverschlüsselte) Text-Datei mit Infos (z.B. dem Hash der Source-Box) und ein paar Erklärungen zum Inhalt (Datum der Sicherung, etc.) in das TAR-File packen kann, die man dann auch ohne Kenntnis irgendeines Kennworts ansehen kann und die dafür sorgt, daß die Infos zum Inhalt nicht nur aus dem Namen der Datei bezogen werden können - das macht gerade bei "Langzeitspeicherung" bzw. bei mehreren Generationen solcher Dateien mehr Sinn.

Wenn man Zugriff auf's Freetz-Webif hat kann man eh Shellbefehle ausführen.

Und es geht ja nicht darum, daß da jemand Zugriff auf das Web-Interface von Freetz hat und sich eine eigene Backup-Datei erstellt (dann kennt der deren Kennwort üblicherweise auch), sondern es geht darum, ob sich irgendwo auf einem Datenträger (oder sogar im Download-Cache des Browsers) eine Backup-Datei befindet, die solche "geheimen" Daten im Klartext enthält und ggf. in die falschen Hände geraten könnte.

Im Extremfall ist der (Freetz-)Benutzer sogar so pfiffig und speichert solche Backup-Dateien auf einem USB-Stick, der in der Box steckt - da weiß man dann wenigstens, wo man sie suchen muß, wenn man sie mal braucht. Blöd nur, wenn dann auch noch der AVM-Media-Server in dieser Box aktiviert ist (was m.W. immer noch die Standardeinstellung bei AVM ist) und somit jeder x-beliebige Client auf der LAN-Seite der Box diese Datei - und zwar ohne jede weitere Authentifizierung - einfach auslesen kann über den Webserver (auf Port 49000), der dem Media-Server zur Seite gestellt wurde. Wenn man's weiß, kann man das zwar vermeiden ... aber wenn es der Freetz-Benutzer nicht besser weiß, ist es schon hilfreich, wenn ihm Freetz gar keine unverschlüsselte Backup-Datei anbietet - dann kann er die auch nicht am falschen Ort speichern bzw. es ist - dank Verschlüsselung - nicht länger ein Problem.

[fda77]

Gegen Dummheit kann man nichts machen.
Eine lesbare info-Datei in der tar wäre ganz nett. Nur das macht das ganze wesentlich komplizierter, da man dann nicht einfach die Pipe verlängern kann. Das hätte auch den Nachteil dass man dann verschlüsselte Backups auf alten Images einspielen kann (im foren kursieren welche die ein paar Jahre alt sind!). Und dann würden alle enthaltenen Dateien ohne Rücksicht nach /var/flash gepackt, ich glaub mit cat. Bei Boxen wie 7490 kann man Dateien (siehe modsave) anlegen....
Bei eine tar|openssl Datei passiert das auf keinen Fall (siehe 1. Zeile)

[PeterPawn]

Dann packt man eben die "alte" Version des Freetz-Backup noch einmal in eine weitere Datei ein ... und schon hat man auch einen "Anzeiger", welches Format vorliegt. Wählt man die Namen im "äußeren" Archiv dann passend, kann auch ein uraltes Images mit einer neueren Backup-Datei nichts falsch machen - wobei mich ohnehin wieder die Frage quält, warum jemand, der auf seiner Box jetzt mit einer neueren Freetz-NG-Version ein Backup erstellt hat, plötzlich dieses Backup auf einer Box mit einem "ein paar Jahre alten Image aus dem Internet" wiederherstellen wollte - das erscheint mir als Problem etwas "konstruiert". Die Annahme, daß jemand ein Backup seiner "alten Box" auf einer neuen versucht einzuspielen (die dann sicherlich auch ein neues Image hat), erscheint mir da wesentlich plausibler (und gefährlicher).

[fda77]

Nie die Intelligenz von Menschen überschätzen!
Wenn du ein aktuelles Image hast, bei dem zb dropbear fehlt, du aber ein uraltes mit dropbear findest nimmst du halt das. Die Einstellungen macht man dann nicht nochmal. Genau dafür gibt es die Archive in Foren. Schau dich mal um.

Freetz restort das aktuell so in make/mod/./files/root/usr/mww/cgi-bin/backup/do_restore.cgi

				for file in $(ls $BACKUP_DIR); do
					echo "cat $BACKUP_DIR/$file > /var/flash/$file"
					cat $BACKUP_DIR/$file > /var/flash/$file
				done

Und damit würde bei Boxen bei denen es geht neue "Dateien" erstellt

EDIT: Das ist doch kein Problem, davor ist ein

		echo "$(lang de:"Konfiguration wiederherstellen" en:"Restoring configuration") ... "
		if [ ! -e "$BACKUP_DIR/$FREETZ_BCK_FILE" ]; then
			FORM_restart=off
			echo "$(lang de:"FEHLER: Keine passende Sicherungsdatei" en:"ERROR: Not a valid backup file")"

[fda77]

@PeterPawn Ab und an (selten) erscheint

/decoder/crypto: Zeile 431: printf: --version: Ungültige Zahl.

Wenn ich sofort danach mit der gleichen Quelldatei den gleichen Befehl nochmal ausführe erscheint die Meldung nicht mehr

for x in $TDIR/var_flash/*; do
	"$DECS/decode_secrets" "$KEY" < "$x" > "$TDIR/decrypted/${x#$TDIR/var_flash/}" && echo -n "."
done

[fda77]

acbb6dd

[PeterPawn]

Ab und an (selten) erscheint

Die Shell-Files sind ja auch eigentlich eher als Demo und zum Verständnis der Abläufe gedacht - siehe hier: https://github.com/PeterPawn/decoder unter Provided files.

Wenn es da ein (reproduzierbares) Problem gibt, fixe ich das auch ... aber hier: https://github.com/PeterPawn/decoder/blob/bb0a8299baeab3a284979cfb189e6a469592c072/scripts/crypto#L431 ist einfach auch nichts auf Anhieb zu sehen.

Ich kann auch höchstens raten ... und ich tippe mal, daß da die aus /dev/urandom gelesenen Daten im Fehlerfall mit einer binären 0 starten - während $v noch nicht initialisiert ist, weil das erst im else-Zweig erfolgt und da kommt er nur lang, wenn es nicht darum geht, eine binäre 0 einzubauen (da ja gegen /dev/zero verglichen wird, fehlt bei 0 die Zeile in der Ausgabe, weil nur die Bytes angezeigt werden, die sich unterscheiden beim cmp -l).

Vermutlich kann man das lösen, indem man in Zeile 439 anstelle von "$v" direkt eine 0 beim Aufruf von yf_random_string_read_octals_print übergibt.

Letztlich ist das ganze Zeug da aber ohnehin nur dazu da, einen zufälligen Namen für ein temporäres Verzeichnis zu bilden - immer davon ausgehend, daß es kein "normales" mktemp auf dem Systm gibt und daß man /dev/urandom zum Lesen zufälliger Daten verwenden kann.

Solltest Du die Zeile 439 testweise ändern und dann das Problem nicht mehr reproduzieren können, ändere ich das auch in meinem Upstream-Projekt. Vermutlich ist das ohnehin falsch an dieser Stelle (wenn ich das jetzt so lese) und ich hatte nur Glück, daß $v nach dem ersten Schleifendurchlauf schon einen (numerischen) Wert hatte, wenn dann doch mal binäre Nullen in der Ausgabe auftauchten. Dann wurden aber vermutlich auch gar nicht diese Nullen ausgegeben, sondern der letzte Inhalt von $v wiederholt - nur fällt das halt bei einem Namen für ein temporäres Verzeichnis auch nicht weiter auf.

[fda77]

Ich hab gesehen dass man es besser compilieren soll. Aber auch dass nettle genutzt wird. Viele haben aber so ihre Probleme mit apt-get... Und wenn es eine Binary ist müsste die auch noch zu den dl-tools. Dabei darf man nicht vergessen dass das Script nur zum decodieren von Backups dient, und vielleicht 1x im Jahr genutzt wird. Da ist das so doch einfacher.
Die Laufzeit ist so komplett etwa 15 Sekunden, was okay ist
Das Problem mit verschlüsselten Passwörtern hatte ich auch schon. Mir sind diverse 546e abgebrannt und ich hab von Amazon Ersatzgeräte bekommen. Aber mir war damals gar nicht bewusst dass es daran liegt.

Ich hab das Script in einem VM aufgerufen, die sonst nicht viel zu tun hat. Und darin wird das decode_secrets in einer Schleife für jede Datei in var_flash ausgeführt - meine 7490 hat dort 65 Dateien. Und ich hab das auch öfter hintereinander mit kleiner Änderungen ausgeführt. Das kann schon einiges an Zufälligkeit kosten.
Ich ersetze das $v mal, aber nur weil ich den Fehler nicht mehr sehe heisst es nicht unbedingt dass es die Ursache war

[PeterPawn]

Ich wußte/weiß ja nicht, was Du an der Stelle noch ändern wollen könntest ... und ich wollte nur verhindern/darauf hinweisen, daß die C-Version die "primäre" ist und ich da auch versuche, nach Kräften den bekanntwerdenden Fehlern nachzugehen. Das gilt für die Shell-Skripts nicht, obwohl ich auch da ja tatsächlich versucht habe, die so zu entwerfen, daß ein anderes Crypto-Paket (z.B. GnuTLS) nur an einer einzigen Stelle zu notwendigen Änderungen führen würde.

aber nur weil ich den Fehler nicht mehr sehe

Da kommt dann schon noch meine "Analyse" dessen, was ich da entworfen habe, dazu ... es gibt nicht so viele Abläufe, bei denen das $v in Zeile 431 mal nicht-numerisch sein könnte und da bleibt am Ende eigentlich nur die Variante übrig, wo das $v beim Aufruf von yf_random_string bereits gesetzt war (da habe ich ja (absichtlich) kein local benutzt, weil das nicht POSIX-konform ist) und bis zum Aufruf von yf_random_string_read_octals_print in Zeile 439 nicht neu zugewiesen wurde.

Und da findet sich dann auch prompt diese Zeile: https://github.com/PeterPawn/decoder/blob/bb0a8299baeab3a284979cfb189e6a469592c072/scripts/crypto#L130, wo nach dem Aufruf von hier: https://github.com/PeterPawn/decoder/blob/bb0a8299baeab3a284979cfb189e6a469592c072/scripts/crypto#L147 tatsächlich noch ein --version (nach dem letzten Schleifendurchlauf in check_option()) in einer Variablen $v stehen würde.

Das läßt meine Fehleranalyse schon einigermaßen plausibel erscheinen ... erst recht angesichts der Tatsache, daß beim Aufruf hier: https://github.com/PeterPawn/decoder/blob/bb0a8299baeab3a284979cfb189e6a469592c072/scripts/crypto#L439 ja eigentlich der Fall behandelt wird, daß die Zufallsdaten an dieser Stelle eine binäre 0 enthielten und daher die Zeilen in der Ausgabe von cmp an dieser Stelle auch nicht streng aufsteigend "nummeriert" sind, sondern eine Lücke zwischen der letzten "Nummer" (das ist ja das gelesene $j) und der gerade gelesenen festgestellt wurde, für die jetzt die passende Anzahl von hexadezimalen Nullen auszugeben ist ... und dann sollte eben auch die Null als Parameter übergeben werden und nicht der letzte Wert von $v.

Das ist nicht nur dann falsch, wenn $v nicht numerisch (sondern --version) ist, weil die Zufallsdaten mit einer binären Null beginnen, sondern auch beim späteren Auftauchen einer Null, wo dann allerdings $v schon wieder eine (von oktal in $val nach dezimal in $v gewandelte) Zahl ist. Denn es soll(te) da eigentlich dann auch die binäre Null (oder sogar mehrere, wenn die Differenz zwischen $i und $j größer als eins wäre) ausgegeben werden und nicht der letzte von Null verschiedene Wert noch einmal.

Daher ist es eigentlich auch falsch, daß Zeile 444 bis 450 im else-Zweig stehen (das else sollte eigentlich ein fi sein und Zeile 451 kann dann raus - denn der gerade gelesene Wert, der auf die binäre Null (oder auch mehrere) folgt, wurde ja auch bereits gelesen (steht dann in $val) und wäre nach den Nullen auch noch auszugeben.

Aber wie schon geschrieben ... das dient in diesem Falle eigentlich alles auch nur dazu, irgendwie Chaos (im Dateinamen) zu erzeugen und das funktioniert auch, wenn da keine 1:1-Umsetzung der Daten aus /dev/urandom in die exakte hexadezimale Folge realisiert ist. Nur dann, wenn man das tatsächlich zur Umwandlung bin -> hex für "stabile Daten" verwenden wollte, wäre es wichtig, daß die Eingabedaten 1:1 in die richtigen Ausgabedaten überführt werden.

[PeterPawn]

Und 'by the way' ... es gibt im decoder-Repo auch vorkompilierte Versionen, die statisch gelinkt sind und damit libnettle schon enthalten, womit es auf dem System gar nicht vorhanden sein muß.

vidar:~/._github/decoder/bin $ file decoder.*
decoder.armv7l:     ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped
decoder.armv7l.sig: data
decoder.i686:       ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
decoder.i686.sig:   data
decoder.mips:       ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, stripped
decoder.mips.sig:   data
decoder.x86_64:     ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=9c286cc7b085455eabeb7443304e11e3bb5ee759, for GNU/Linux 3.2.0, stripped
decoder.x86_64.sig: data
vidar:~/._github/decoder/bin $

Dazu gibt es jeweils auch noch eine Signatur mit meinem YourFritz-PGP-Key ... zumindest auf den vier Plattformen sollte es also nur selten notwendig sein, auf die Shell-Skripte zurückzugreifen. Von den deutlichen Geschwindigkeitsvorteilen der Binär-Version mal ganz zu schweigen ... die Version für i686 ist praktisch die 32-Bit-Version und verwendet auch keine Atom-spezifischen Assembler-Codes mehr, die früher mal die Verwendung auf anderen Prozessoren mit x86 behinderten. Die Dateinamen sollten mit einem decoder.$(uname -m) zu ermitteln sein, so daß man für die vier (derzeit verfügbar gemachten) Plattformen auch automatisch die passende Datei finden kann.

DAS müßte man also auch nicht als Grund für die Verwendung der Shell-Skripte (die ja obendrein noch mehr als eine Datei brauchen) sehen ... die binären Dateien kann man dann sogar gezielt (über die "raw URL", die auch nach Updates noch stabil ist, wenn man anstelle des Hashs den Branch-Namen nimmt, also https://raw.githubusercontent.com/PeterPawn/decoder/master/bin/decoder.x86_64 für die x64-Version, die auch auf Deinem Fedora "out of the box" funktionieren sollte) als einzelne Datei laden, anstatt das gesamte Repo zu klonen.

Und am besten lädt man die Signatur auch noch, denn dann kann man die prüfen, wenn auf dem System GPG installiert ist, was bei den allermeisten schon deshalb der Fall sein wird, weil die Repos der Distributionen ja auch mit GPG signieren.

vidar:~/._github/decoder/bin $ gpg2 --verify decoder.x86_64.sig
gpg: assuming signed data in 'decoder.x86_64'
gpg: Signature made Mon Jul  6 14:18:34 2020 CEST
gpg:                using RSA key 0DF4F707AC58AA38B35AAA0BC04FCE5230311D96
gpg: Good signature from "PeterPawn (yourfritz.de PGP key) <[email protected]>" [ultimate]
gpg:                 aka "PeterPawn (yourfritz.de PGP key) <[email protected]>" [ultimate]
gpg:                 aka "PeterPawn (yourfritz.de PGP key) <[email protected]>" [ultimate]
gpg:                 aka "PeterPawn (yourfritz.de PGP key) <[email protected]>" [ultimate]
gpg:                 aka "PeterPawn (yourfritz.de PGP key) <[email protected]>" [ultimate]
gpg:                 aka "PeterPawn (yourfritz.de PGP key) <[email protected]>" [ultimate]
vidar:~/._github/decoder/bin $

Der Public-Key steht auch im Repo, als PeterPawn.asc.

Da müßte man also schon ein ziemlich exotisches Build-System haben (die meisten basieren wohl immer noch auf x86 oder x64), damit man auf die Shell-Version ausweichen MUSS ... bei hinreichend plausiblen Varianten (und wenn ich für die Plattform dann irgendwo - z.B. in einem Container in der Cloud - einen Build anwerfen kann) nehme ich die gerne auch noch zusätzlich auf.

Die bisherigen Varianten sollten die meisten Build-Systeme (i686 oder x86_64) und die meisten AVM-Boxen abdecken, zumindest die aktuellen Modelle, denn es gibt (absichtlich) keine Variante für MIPSEL und damit für Boxen vor der 7390.

Zwar kann man momentan nur anhand eines erfolgreichen oder fehlgeschlagenen Downloads "entscheiden", ob eine Plattform bei den Binärdateien unterstützt ist oder nicht, aber ich kann da gerne (wenn's was bringen sollte) auch noch eine Datei als "Liste" der vorkompilierten Versionen (bzw. der Plattformen) hinterlegen - das ist dann halt aber auch ein Download mehr, wenn man das anhand dieser Datei zuerst prüfen wollte.

Fertige "Pakete" will ich da nicht bereitstellen ... letztlich geht es nur um ein einzelnes (passendes) Binary und die zugehörige ("detached") Signatur - das muß man nicht wirklich noch in ein Archiv verpacken.

[fda77]

Für aarch 64 gibt es keine binary. ;) Du könntest den decoder bins noch ausführrechte geben. Gpg braucht man doch nicht, decoder ist ein Host package das anhand des git Hashes gecloned wird

[PeterPawn]

Ich schrieb ja auch, daß man das für das Prüfen meiner eigenen Signatur für die vorkompilierten Binaries braucht. Und ARM64 dürfte auch eher selten "gefragt" sein ... wobei ich die sogar auf einem RasPi4 mit 64-Bit-OS bauen könnte. Nur schrieb ich oben schon: "hinreichend plausible Varianten" ... und solange nicht ein paar Leute tatsächlich auch einen ARM-Build-Host mit einer 64-Bit-Version betreiben, kannst Du Dir das (bei Interesse) immer noch selbst übersetzen. Ich hatte mit meinem Kommentar jedenfalls eher "die breite Masse" im Blick.

---

Und zu der Variante mit den Shell-Skripten kann ich auch nur noch einmal anmerken, daß ich da gerade selbst noch ein Problem gefunden habe ... und noch mit mir hadere, ob bzw. wie ich das löse. Dieses Problem ist mit der C-Version ebenfalls nicht vorhanden.

Als ich die Shell-Skripte schrieb, war diese Stelle: https://github.com/PeterPawn/decoder/blob/bb0a8299baeab3a284979cfb189e6a469592c072/scripts/decode_secrets#L268 noch unkritisch, weil es keine Prozentzeichen (die dann als Formatierungsanweisungen verstanden würden, wenn sie in $decoded auftauchen würden - in $line sind sie wegen der Base32-Kodierung garantiert nicht vorhanden) und auch nur sehr wenige andere Sonderzeichen in den Klartext-Werten geben konnte.

Seitdem AVM die TR-064-Schnittstelle zum Registrieren von Apps eingeführt hat (X_AVM-DE_AppSetup), kann dort ein Kennwort aber 8-32 Zeichen aus dem Bereich ASCII-32 (also Leerzeichen) bis ASCII-126 enthalten ... und da muß man dann eben noch deutlich mehr Vorkehrungen treffen, wenn man den verschlüsselten Wert per sed-Kommando s gegen den Klartext tauschen will. Denn im replacement-Teil eines solchen Kommandos können schon ein paar mehr Zeichen eine besondere Bedeutung haben (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html) und die muß man dann alle (richtig) maskieren, damit da am Ende das passende Ergebnis steht und auch die verarbeitete Datei noch weiterhin gültig bleibt (gerade, was eingebettete "double-quotes" und ggf. andere, nicht-druckbare Zeichen anbelangt).

Ich gehe also Wetten ein, daß Du beim Entschlüsseln einer ar7.cfg, die in der apps-Sektion ein paar Einträge enthält, die von (halbwegs aktuellen) AVM-Apps erzeugt wurden, mit den Shell-Dateien auch nicht glücklich wirst. Die ersten zwei Probleme (das mit --version, was ich geprüft habe, indem ich den Zufallsdaten einfach mal fix eine binäre Null vorangestellt hatte und das in der o.a. Zeile, wenn da ein Prozentzeichen im Klartext ist) habe ich heute nachmittag irgendwann mal korrigiert (ich wollte die Shell-Dateien selbst nutzen, um mich bei Gelegenheit mal an die Suche zu machen, womit der Key für das LE-Zertifikat bei AVM verschlüsselt wird) - die pushe ich im Anschluß gleich ins Repo. Das Sonderzeichen-Problem ist da aber auch noch nicht gelöst.

[fda77]

Ich hab mir die Binaries mal angeschaut, deren Parameter/Ausgaben sind leider nicht kompatibel zu den Scripten (so dass man leicht wechseln könnte).
zB password_from_device Script gibt die "md5" als String aus. Die Binary davon als 0x Hexwert, der dann noch ein "xxd -p" bräuchte um einen String zu bekommen

tools/decoder/bin/decoder.x86_64 password_from_device -a environment.txt  | grep -v fdasb
%$
Übereinstimmungen in Binärdatei (Standardeingabe)

[PeterPawn]

Tu mir einen Gefallen ... wenn Du Fehler im decoder-Repo melden willst, weil Du welche entdeckt hast, mache das (in der richtigen Form) in dem richtigen Repo.

Das Problem mit der leeren Datei kann ich bestätigen (es gibt auch noch andere Probleme mit den C-Quellen, die habe ich auf dem Zettel und mache das mit, wenn ich das nächste Mal etwas ändere - speziell die Behandlung falscher Parameter ist kaputt, aber die sollten beim Aufruf aus Skript-Dateien heraus ja auch nur selten vorkommen) - aber diese Diskussion hier taugt zur Meldung und zum Tracking nicht.

Die Binary davon als 0x Hexwert, der dann noch ein "xxd -p" bräuchte um einen String zu bekommen

Hast Du die beiden Angaben mal verglichen? Bei mir gibt das Binary mit password_from_device zwar auch eine Zeichenkette aus, die mit 0x beginnt ... aber das, was das Shell-Skript password_from_device ausgibt, ist praktisch dieselbe Zeichenkette, nur daß hier das 0x fehlt und die hexadezimalen Ziffern mit Kleinbuchstaben dargestellt werden (das kommt nämlich direkt aus einer MD5-Berechnung und der Ausgabe des dafür genutzten Programms), während das Binary große verwendet.

Aber ich verstehe schon gar nicht, warum Du das überhaupt mit xxd in eine Zeichenkette (string) verwandeln willst ... das ist ein MD5-Hash und da treten in der Zeichenfolge auch Bytes auf, die gar keine druckbaren Zeichen ergeben - weshalb die auch niemand in eine Zeichenkette umwandelt; nicht einmal das md5sum, wenn Du Dir dessen Ausgabe mal anschauen möchtest.

Beim Binary habe ich nur die "Anzeige" von hexadezimalen Werten durch das vorangestellte 0x durchgezogen, wenn aus irgendwelchen Gründen Zweifel am Format der Ausgabe bestehen könnten ... einige der Applets (z.B. decode_secret - das ohne das s am Ende) erwarten auch hexadezimale Daten als Eingabe, da gibt es dann aber entweder Optionen für die Unterscheidung oder es steht schon in der Beschreibung, daß da nur hexadezimale Eingaben akzeptiert werden. Die dann allerdings (wenn ich mich richtig erinnere) auch ohne das vorangestellte 0x - aber auch das ist Absicht, weil es per Definition oder durch Optionen schon festgelegt wird, ob das nun Zeichenkette oder hexadezimale Darstellung ist. Das gilt u.a. auch für die Ausgabe von password_from_device (als Applet) ... wenn da durch die Angabe von --hex-output bereits geklärt ist, daß die Ausgabedaten eine hexadezimale Darstellung sein sollen, braucht es das 0x als Präfix nicht länger (und Skript und Binary unterscheiden sich nur noch beim A-F bzw. a-f für die Darstellung).

Aber da diskutiere ich - ehrlich gesagt - auch gar nicht drüber ... einen Wert auf den Beginn mit "0x" zu testen und das - je nach Bedarf - hinzuzufügen oder abzuschneiden, ist Shell-Basiswissen (selbst wenn's POSIX-konform mit expr erfolgt oder meinetwegen mit sed) und mit

nicht kompatibel zu den Scripten

kann ich (abseits der Feststellung, daß da mal ein 0x davor steht und mal nicht) ebenso wenig anfangen, wie sich mir der Sinn des Beispiels mit

tools/decoder/bin/decoder.x86_64 password_from_device -a environment.txt  | grep -v fdasb
%$
Übereinstimmungen in Binärdatei (Standardeingabe)

erschließt.

Wie schon festgestellt, ist die Ausgabe von password_from_device die hexadezimale Darstellung eines MD5-Hashs ... warum sollte man darin mit grep nach der Zeichenfolge fdasb suchen? Das s darin ist ja gar keine Hexadezimal-Ziffer ... daher verstehe ich weder den Aufruf grep -v fdasb (wo sollte da eine Zeile mit fdasb überhaupt herkommen, die man mit grep -v aus der Ausgabe auf STDOUT herausfiltern wollte) noch das, was danach (wohl als Ausgabe des vorhergehenden Kommandos) in den nächsten zwei Zeilen steht.

Zusätzlich ist es mir (zumindest bei dem, was ich bisher dazu gesehen habe) ein Rätsel, was Du mit dem password_from_device überhaupt anfangen willst ... viel schlauer wäre es ja, dem decode_secrets über -a <environment_copy> das passende Environment zu übergeben. Den Test, ob die zu dekodierende Datei leer ist (solange das oben attestierte Problem nicht gefixt wurde) und den Verzicht auf das Dekodieren in diesem Falle (das kommt auch nichts Sinnvolles bei heraus), kriegst Du hoffentlich auch noch hin.

---

Ich hätte also - bevor ich mich hier weiter reinhänge und ggf. Probleme "unplanmäßig" untersuche - schon gerne eine Idee, ob Du nun ernsthaft versuchen willst, das mit dem Binary zu lösen und ich daher dort enthaltene Fehler "vorziehen" sollte oder ob das nur die weitere Suche nach Gründen ist, warum Du unbedingt die Shell-Skripte verwenden willst. Dann wäre mir das nämlich auch egal ... ich kann (und will) Dich auch davon nicht abhalten (ist schließlich GPLv2-lizenziert), aber dann ist das Thema für mich auch erst einmal erledigt.

Das Problem mit den Sonderzeichen braucht schon sehr ausführliche Tests (die mache ich sicherlich auch noch irgendwann, aber bei den Shell-Skripten definitiv nicht heute oder morgen), damit das am Ende auch wieder "rund" ist - ohne diese "speziellen" Kennwörter im apps-Abschnitt funktioniert(e) bei mir auch die Shell-Version klaglos und das soll auch nach der Änderung noch so sein - sprich: das kann kein Schnellschuß werden, bei dem dann zwar senkrechte Striche im Wert funktionieren, aber keine "double-quotes" oder auch keine (oktalen) Darstellungen nicht druckbarer Zeichen (das sind dann noch einmal die von ASCII 0 bis 31 und ab ASCII 127 - bzw. die 8-Bit-Werte von 128-255) mehr machbar sind (das kann man sich z.B. beim cookie in der webui-Sektion ansehen, wie AVM die angibt).

Und noch mal zum

nicht kompatibel zu den Scripten

... da darfst Du auch gerne konkreter werden, auf welche Skript-Dateien und auf welches Applet das jeweils zutreffen soll. Wenn ich z.B. die beiden decode_secrets vergleiche (das wären ja die, die Du für das (nachträgliche) Dekodieren der Einstellungen einer fremden Box bräuchtest - wenn Du die passende environment.txt gesichert hast), dann sehe ich da keine Unterschiede in der Parametrierung ... der einzige sinnvolle Parameter mit Auswirkungen auf die Funktion ist ohnehin das --alt-env und das ist bei beiden vorhanden.

Ansonsten hat das Binary ein paar Optionen mehr, die aber nur das Verhalten beim Lesen/Sortieren der Datei beeinflussen (weil die beim Binary in den Speicher gelesen wird von STDIN - was sich nicht ohne weiteres wiederholen läßt, z.B. bei einer Pipe - und beim Skript in eine temporäre Datei gespeichert wird, von wo man sie so oft lesen kann, wie man will) und für die Ausgabe (also das Ergebnis) ohne jede Bedeutung sind - wo wäre da nach Deiner Ansicht der entscheidende Unterschied, der den einfachen Austausch Skript<->Binary verhindern würde?

Wie gesagt ... ich bin ja gerne zur Diskussion bereit, aber nur, wenn ich nicht den Eindruck habe, daß es nur ums Diskutieren geht und die Entscheidung eigentlich schon lange gefallen ist und nun mit Zähnen und Klauen verteidigt wird. Gegen Windmühlen WILL ich gar nicht kämpfen ... ich kann mich auch zurücklehnen und nur abwartend zuschauen, was da noch kommt. Wenn Du ernsthaft an der Stelle die Binärdatei benutzen willst, ist das etwas anderes - dann kann man auch darüber diskutieren, ob man etwas besser machen könnte und wenn ja, was genau.

[fda77]

Ich kann schon extra ein Issue aufmachen, nur dann wird an 2 Stellen über das gleiche geredet.

einen Wert auf den Beginn mit "0x" zu testen und das - je nach Bedarf - hinzuzufügen oder abzuschneiden, ist Shell-Basiswiss
Genau das geht ja nicht!

Ja, es ist aber kein "Wert"

$ ~/freetz-ng/tools/decoder/bin/decoder.x86_64 password_from_device -a environment.txt
0x2524XXXXXXXXXXXXXXXXXXXXXXXXXXXX

$ ~/freetz-ng/tools/decoder/bin/decoder.x86_64 password_from_device -a environment.txt | sed 's/^0x//' # wie "fdasb"!
%$

$ ~/freetz-ng/tools/decoder/bin/decoder.x86_64 password_from_device -a environment.txt | hexdump -C
00000000  25 24 XX XX XX XX XX XX  XX XX XX XX XX XX XX XX  |%$XXXXXXXXXXXXXX|

"fdasb"

Es ging darum dass man die Ausgabe der Binary nicht als "string" pipen kann
Oben nicht übersehen "Übereinstimmungen in Binärdatei (Standardeingabe)"

... da darfst Du auch gerne konkreter werde

War ich doch oben:

• Das eine gibt "string" das andere "hex" aus
• Und dass leer Inputdateien im einen akzeptiert werde und im anderen nicht

Ich hab das Script ja schon für die Binaries umgeschireben (lokal) und falls es die Binary für die Arch nicht gibt wir das Script genommen

[PeterPawn]

nur dann wird an 2 Stellen über das gleiche geredet.

Nicht zwingend ... sicherlich hast Du auch schon bemerkt, daß die Verlinkung (sogar über Repo-Grenzen hinweg) ganz gut funktioniert.

Ich hab das Script ja schon für die Binaries umgeschireben (lokal)

Das kann ich halt nicht wissen.

Ich warte mal noch, bis der letzte Beitrag "stabil" ist, bevor ich weiter antworte.

[PeterPawn]

So, jetzt setze ich mal fort ...

Es ging darum dass man die Ausgabe der Binary nicht als "string" pipen kann

Die Option --hex-output für das Applet password_from_device hast Du gesehen?

vidar:~/._github/decoder $ password_from_device -a files/fb7490.env --hex-output | hexdump -C
00000000  39 36 42 31 36 45 37 39  45 45 39 43 34 35 45 30  |96B16E79EE9C45E0|
00000010  45 43 XX XX XX XX XX XX  XX XX XX XX XX XX XX XX  |ECXXXXXXXXXXXXXX|
00000020
vidar:~/._github/decoder $

dass leer Inputdateien im einen akzeptiert werde und im anderen nicht

Das mit der leeren Eingabedatei habe ich ja bestätigt ... da muß ich erst mal suchen, warum da beim read() offenbar kein EOF signalisiert wird - das ist nämlich sowohl bei einer Pipe auf STDIN als auch beim Öffnen über einen Dateinamen der Fall, daß das read() wartet.

Entweder ich "überlese" versehentlich das EOF beim ersten Mal (weil gleich beim ersten Mal auch nur 0 Byte gelesen werden können) und der Status wird dann wieder gelöscht oder irgendetwas anderes ist faul ... ich würde nämlich auch beim wiederholten Lesen am Dateiende eine mehrfache EOF-Signalisierung erwarten.

[fda77]

Ich habs jetzt mal comitted f38c825

[fda77]

Die Option --hex-output für das Applet password_from_device hast Du gesehen?

Ah, so einfach ^^

~/freetz-ng/tools/decoder/bin/decoder.x86_64 password_from_device -a environment.txt --hex-output |grep -v ggagagaggaagag
2524.........

UPDATE:
Schade dass das Script kennt die Option nicht kennt

Unknown option '--hex-output'.

[PeterPawn]

Das Skript kennt halt nichts anderes ... wie schon weiter oben geschrieben, ist die Ausgabe des Skripts nichts anderes als die Ausgabe des Programms, mit dem der Hash berechnet wurde. Das könnte/müßte man jetzt erst von hexadezimal nach binär wandeln, damit man da wieder eine solche Option sinnvoll einbauen könnte.

Es wird ja jetzt nicht sooo viele Applets des decoder oder Shell-Skripte aus diesem Repo geben, die Du tatsächlich bei Deinem Vorhaben verwenden müßtest ... da Du ja irgendwo dann auch beim Download zwischen Binary und Shell-Skript unterscheiden mußt (die Shell-Varianten haben ja auch noch ihre Voraussetzungen, die jeweils erfüllt sein wollen), sollte die zusätzliche Angabe von --hex-output beim Verwenden der binären Version ja auch nicht so ein riesiges Problem sein.

Man darf auch hier wieder nicht aus den Augen verlieren, daß ich die Shell-Skripte zuerst zusammengeklöppelt hatte, um das Prinzip zu illustrieren und daß die eigentlich niemals für eine Benutzung "auf Dauer" ausgelegt waren. Daher sind auch die 1:1-Parameter hier nicht wichtig gewesen ... und ich habe immer noch keinen Schimmer, was Du eigentlich mit dem password_from_device anfangen willst (im Kontext des ersten Commits, weiter habe ich noch nichts dazu gelesen).

Wenn Du ohnehin eine passende Environment-Datei hast (die Du ja bei --alt-env bzw. -a angibst) ... was willst Du dann mit dem hexadezimalen Kennwort (aus den Eigenschaften der Box in Deiner environment.txt) machen? Das, was Du zum Dekodieren der "secrets" in den AVM-Dateien brauchst, ist das Applet decode_secrets und das kann selbst mit der environment.txt umgehen und aus den Angaben in dieser Datei das richtige Kennwort zum Entschlüsseln ermitteln.

[PeterPawn]

Ich habs jetzt mal comitted

Wie direkt hier drüber geschrieben ... das, was Du da mit dem password_from_device machst (erst recht in dem Teil der Bedingung, wo Du noch ein xxd dranhängen willst), verstehe ich gar nicht. Das ist komplett falsch - hier hast Du etwas fundamental mißverstanden.

Verwende einfach nur decode_secrets -a <environment_file> mit dem zu dekodierenden File auf STDIN und Du erhältst auf STDOUT die dekodierte Datei.

Das Einzige, was dabei ggf. etwas "tricky" ist, wäre die Tatsache, daß das "reine" decoder-Binary (wenn es nicht über den Symlink decode_secrets aufgerufen wird) noch die Angabe der Funktion erfordert (wie ein BusyBox-Applet ohne Symlink auch) und das beim Shell-Skript nicht der Fall ist.

[PeterPawn]

Ich klinke mich jetzt erst mal aus (für heute) und lasse das hier etwas "settlen". Im Moment schreiben wir zu viel parallel ... da kommt dann einiges durcheinander, wie ich an 0aa14ef zu erkennen glaube. Vielleicht siehst Du Dir das mit dem direkten Aufruf von decode_secrets noch einmal in Ruhe an (sowohl den Hilfe-Bildschirm des Programms, als auch meine letzten zwei Beiträge über diesem hier) und machst dann in Ruhe Deine Änderungen. Ich schaue dann hier morgend wieder rein und nach dem Ergebnis - das läßt dann ein wenig Ruhe einziehen.

[fda77]

Hätte ich vorher gewusst dass decode_secrets auch eine Env-Datei annimmt hätte ich es anders gemacht. Aber jetzt lass ich es so, so kann der Key angezeigt werden und vorab geprüft werden ob die env im Backup okay ist.
Es dürfte auch ein Tick schneller sein wenn nicht für 65 Dateien der Key jedes mal berechnet wird. Wobei mit den Bins das komplette Script in 0,1 Sec statt 15 Sec fertig ist

Ich rufe die Binary doch mit Applet auf: https://github.com/Freetz-NG/freetz-ng/blob/master/tools/decoder_for_settings_backup#L60

[fda77]

Hast du cd11f49 schon angeschaut? Vor allem die openssl-Aufrufe, ob die so okay sind. Ich hatte noch mit openssl 1.1 "salt" und "iterations" ausprobiert, das dauerte schon auf der 7490 merklich länger. So wie es ist kann man ein openssl 1.0 backup mit 1.1 wiederherstellen

[fda77]

Nicht vergessen: +x für decoder/bin/decoder.*

Die decoder.armv7l läuft übrigens auf aarch64. Was leider nicht geht ist

ln -s decoder.armv7l decoder.aarch64

./decoder.aarch64 password_from_device
             ^^^^
Usage:
    decoder.armv7l { options | applet [ parameters ] }
             ^^^^

Das geht:

ln     decoder.armv7l decoder.aarch64
   ^^^
./decoder.aarch64 password_from_device
password_from_device: Error opening environment file '/proc/sys/urlader/environment'.

---

44d35ad Laufzeit des kompletten Scriptes mit Binaries auf dem Raspberry: 0,5 Sec (PC: 0,1 Sec)
Rapberry mit Script-Version: 30 Sec

[PeterPawn]

so kann der Key angezeigt werden

Schon das ist (in meinen Augen) eher gewöhnungsbedürftig ... warum macht man so etwas und wer (außer einem Hacker) kann mit dieser Info etwas anfangen? Womit sollte das irgendein "normaler" Benutzer vergleichen wollen?

Es hat ja Gründe, warum z.B. die Eingabe von Kennwörtern üblicherweise auch "verdeckt" erfolgt - neben der Möglichkeit, die bei der Eingabe direkt (auf dem Bildschirm, denn auf dem Keyboard geht es bei den allermeisten ja trotzdem, wenn sie nach den Tasten suchen) auszuspähen, gibt es häufig genug auch noch entsprechende Protokoll-Dateien (z.B. kann auch PuTTY ein komplettes Log einer Session irgendwo ablegen) und darin sollten "geheime Daten" eben auch nicht auftauchen - schon gar nicht in einem Kontext, daß man sie auch noch problemlos als solche identifizieren kann, weil da jemand "secret key" davor schreibt. Wenn man vom Benutzer dazu aufgefordert wird, diese Info auszugeben (wie bei der Option --verbose beim Binary), ist das wieder etwas anderes - dann ist aber auch der Aufrufer dafür zuständig, die Sicherheit der ausgegebenen Daten zu gewährleisten.

Was bringt (Dir oder einem Freetz-Benutzer) also diese Anzeige genau? Das Argument: "So muß nicht mehrfach der Key berechnet werden." greift in meinen Augen hier auch nicht ... die Zeit dafür dürfte kaum ins Gewicht fallen und stattdessen hast Du jetzt diesen Key sogar wieder explizit in einer Variablen in Deinem Shell-Skript herumstehen. Zwar kann man den eben (wenn man weiß, wie es geht) auch aus den Daten im Urlader-Environment berechnen, aber das macht das Prinzip, solche Infos nur so lange wie nötig in der "berechneten Form" im Speicher zu halten, ja nicht vollkommen obsolet - auch wenn ich zu meiner Schande gestehen muß, daß ich (eben weil die Eingabedatei mit dem Environment ja auch nicht verschlüsselt ist) in den C-Quellen auch nicht immer konsequent die Schlüssel sofort wieder im Speicher lösche (oder unkenntlich mache), wenn sie nicht mehr benötigt werden. Hier war aber auch die Überlegung, daß es sich bei diesem Programm eben nicht um etwas handelt, was dauerhaft als Daemon im System läuft und wo alle Zeit der Welt ist, den Speicherinhalt des Prozesses auszulesen, ein entscheidender Punkt ... nach dem Ende sollte das OS ohnehin den Speicherinhalt verwerfen und auch in einem kompletten Dump nichts mehr zu finden sein.

Oder ganz kurz als Fazit: Ich würde die "Anzeige" des Keys nicht zum "Normalfall" machen - aus mehreren Gründen. Erstens kann damit der Benutzer nichts anfangen, zweitens ist es aus Sicherheitsaspekten ein sehr ungewöhnliches Gebahren.

---

Wobei man das auch nicht zu dogmatisch sehen darf/sollte ... und da bin ich dann bei Deinen Aufrufen von openssl. Zwar ist es auch nicht schön, wenn man ein Kennwort in einer Shell-Variablen speichert ... aber wenn man zwei Dateien mit demselben Kennwort entschlüsseln lassen will, sollte man dem Benutzer deshalb nicht gleich die zweimalige Eingabe eines Kennworts aufbürden. Das kann man entweder mit fertigen Komponenten machen (z.B. mit pinentry (https://gnupg.org/related_software/pinentry/index.html), wenn das installiert ist) oder man probiert es mit einem read -s, wenn die vorliegende Shell das unterstützt oder (und das ist dann die finale Herausforderung) schaltet das Terminal in den "raw mode" und verarbeitet die Eingaben direkt selbst (da kann man dann auch wieder Feedback pro eingegebenem Zeichen geben, wenn's unbedingt sein muß).

Wie auch immer man es macht, am Ende hat man das Kennwort (nach einmaliger Eingabe, denn hier geht es ja nur noch ums Entschlüsseln) in einer Shell-Variablen und der Benutzer muß nicht zwei- oder gar viermal (wenn's tatsächlich bei OpenSSL 1.0.x landet, wobei Du beim zweiten File ohnehin keinen weiteren Versuch mit OpenSSL > 1.0.x machen müßtest, denn es ist ja eher unwahrscheinlich, daß es sich bei beiden Dateien unterscheidet) ein Kennwort eingeben, was einerseits die Gefahr des Vertippens vervielfacht und andererseits auch die des "Mitlesens" bei der (wiederholten) Eingabe.

---

Und auch zur Art der Ver- und Entschlüsselung mit OpenSSL hätte ich noch eine Anmerkung ... wenn Du das (wie AVM beim Export-File auch) als zweistufige Verschlüsselung anlegst, kannst Du das Verhalten der früheren AVM-Versionen (wo man noch die Wahl hatte, ob man ein Kennwort angibt, wobei sich die Einstellungen ohne das Kennwort nur auf derselben Box wiederherstellen ließen) nachbilden und sogar mehrere Kennwörter für dieselben Inhalte verwenden (eines davon wäre dann das der Box und (mindestens) ein anderes das vom Benutzer festgelegte).

Dazu verschlüsselt man die enthaltenen Dateien gar nicht direkt mit dem angegebenen Kennwort, sondern man generiert sich einen Zufallswert (der sollte dann aber auch einigermaßen zufällig sein), den man zum Verschlüsseln der Dateiinhalte verwendet. Diesen Zufallswert verschlüsselt man jetzt wiederum jeweils einmal mit den gewünschten Kennwörtern, die man auch zum Entschlüsseln verwenden will.

Dann muß man nur noch darüber nachdenken, wie man diese jeweiligen Ergebnisse irgendwie speichert - hier verwenden verschlüsselnde Dateisysteme (wie EFS von MS oder LUKS) dann meist spezielle Dateiattribute (bei NTFS liegen diese Keys m.W. in "alternative streams" der jeweiligen verschlüsseltenDateien). Das paßt hier bei Dir aber eher nicht ... also würde ich hingehen und die verschlüsselten "Keys" jeweils nach Base64 wandeln und - mit einer Trennzeile versehen, damit man sie für das Entschlüsseln auseinander bekommt - in einer gemeinsamen Datei speichern.

---

Das hier: 44d35ad würde ich komplett weglassen ... stattdessen würde ich die Datei direkt beim Herunterladen umbenennen, weil man von da an dann nur noch mit dem Namen decoder arbeiten kann. Das war ja auch der Ursprung - die Erweiterung füge ich ja nur von Hand hinzu, damit die Versionen gemeinsam in einem Verzeichnis liegen können ... hätte ich die Architektur stattdessen in einer Verzeichnishierarchie abgebildet, hießen die Dateien darin auch nur noch decoder.

Wenn's was bringt, kann ich auch noch ein install-Applet einbauen, was die Symlinks für die enthaltenen Applets automatisch anlegt - der Umfang (der Applets) ist ja eigentlich variabel, auch wenn die vorkompilierten Binaries natürlich "all in one" sind.

---

Ich bin ohnehin der Ansicht, daß Du Dir das Leben hier vollkommen unnötig schwer machst ... ich habe ja nun selbst auch schon an ein paar Stellen solche Binaries aus dem Repo geladen (was auf originaler AVM-Firmware eine Herausforderung ist, aber mit dem überarbeiteten httpsdl von AVM sogar funktioniert) und dann im Anschluß ausführbar gemacht.

Dabei hat man mit den Download-Tools (wget, curl, httpsdl) generell immer das Problem, daß man die Datei nachträglich ausführbar machen muß - ich wüßte jedenfalls keinen Weg, bei einem HTTP(S)-Download irgendwelche "executable"-Attribute mit zu übergeben. Um das chmod [ugoa]+x kommt man also generell nicht herum, solange man das nicht mit anderen Kommandos macht (wie beim Klonen eines Repos, was aber - in diesem Falle - eine vollkommen unnötige Datenmenge bewegen würde) oder wieder ein Archiv-Format für den Download verwendet, das bei Entpacken diese Attribute auch wiederherstellt. Daher habe ich auch keinen großen Wert darauf gelegt, daß die Binaries im Verzeichnis bin das executable-Bit automatisch gesetzt haben - das hilft halt auch nur dann, wenn man das komplette Repo lädt (entweder klont oder das GitHub-Angebot mit dem ZIP-File annimmt).

Hier wäre es jedenfalls wirklich ein Leichtes, wenn man unter tools auf irgendeinem Weg einen "stabilen" Link auf ein passendes decode_secrets erstellt (natürlich auch unter einem "festen" Namen, womit sowohl die Architektur-Extensions als auch der Aufruf mit decoder <applet> ... unnötig werden) - dabei kann man dann nach Herzenslust die verschiedenen Optionen durchgehen und sich aussuchen, in welcher Reihenfolge man nach einem passenden File, was man verlinken könnte, suchen möchte.

Das kann z.B. zuerst nachsehen, ob das yourfritz-decoder-host überhaupt schon geladen wurde (was ich sogar weglassen würde, denn wenn ich das richtig verstehe, soll diese Kopie des YourFritz-Repos ja nur für die Verwendung an dieser Stelle dienen) und wenn das nicht der Fall ist, kann man nach einem fertigen Binary suchen.

Das mit dem aarch64 würde ich trotzdem nicht als Extension im Repo aufnehmen, weil die Existenz einer ARM32-Emulation nicht zwingend sein muß und dann funktioniert auch die armv7l-Version nicht auf ARM64 - da müßte man dann also bei "$(uname -m)" = "aarch64" noch selbst entscheiden, ob man die 32-Bit-Version stattdessen will oder nicht ... auch das Vorhandensein der Emulation kann man garantiert irgendwie testen, bevor man die 32-Bit-Version lädt.

Findet man am Ende dann aber tatsächlich kein Binary, kann man die Shell-Skripte (komplett oder anhand der Angaben in "__required_scripts" in den Shell-Files) immer noch laden (lassen).

Aber egal, was da woher dann geladen wurde (es sind ja auch jeweils noch ein paar "Nachbereitungen" erforderlich, von Umbenennen bis zum chmod +x), am Ende sollte da immer ein und derselbe Name für das Entschlüsseln der AVM-Secrets stehen und den sollte das Skript dann auch verwenden. Das spart das ganze Geraffel mit den unterschiedlichen Pfaden und unterschiedlichen Optionen (die Du Dir aber ohnehin auch nur durch die Verwendung von password_from_device eingehandelt hast).

Hier schlägt dann auch wieder die Philosophie "one tool for one job" zu ... die Aufgabe des decoder_for_settings_backup soll ja offenbar das Dekodieren der Datei sein und nicht das "Vorbereiten" der passenden Umgebung - das gehört (für mich zumindest) in ein entsprechendes "Vorbereitungsskript" und wenn man will, kann man die beiden dann auch noch zusammen in ein drittes packen, das der Benutzer dann letzten Endes aufrufen soll.

---

Ebenso gehört dann die (einmalige) Kennwort-Eingabe in ein gesondertes Skript - auch das kann man nämlich noch an vielen anderen Stellen nachnutzen. Wenn es so eine "definierte Schnittstelle" gibt, dann ist es am Ende auch wieder egal, ob dieses Kennwort jetzt in einer Terminal- oder einer X11-Session (was pinentry alles schon kann) eingegeben wird oder aus einer HTML-Seite aus den GUI kommt (wo es dann natürlich auch ein <input type="password"> gewesen sein sollte) oder sogar schon (das hast Du ja offenbar schon mal vorgesehen) in der Shell-Variablen $PASS steht. Wobei der Name natürlich schrecklich ist - wenn da irgendjemand anderes auch ein $PASS benutzt und diese Variable dann immer noch gesetzt ist, erfolgt nicht mal die Abfrage in Deinem Skript ... solche Variablen sollten nach Möglichkeit immer einen "qualifizierten" Namen haben und nicht ganz umsonst kann man bei OpenSSL den Namen der Variablen auch noch angeben: https://www.openssl.org/docs/manmaster/man1/openssl-passphrase-options.html - der sicherste Weg wäre fd, was aber aus der Shell heraus Unfug ist, wenn man da ohnehin erst das Kennwort in irgendeinem weiteren File-Deskriptor bereitstellen sollte (solange es tatsächlich in einer Variablen liegt). Für einen Daemon (also einen länger laufenden Prozess, der auch entsprechend lange im Speicher steht) sollte man das aber auch unter Shell-Bedingungen machen.

---

Wenn man die Vorbereitung des Symlinks in ein gesondertes Skript auslagert (und einiges darin parametrierbar macht - ggf. bis hin zu einem "callback", wenn eine Architektur nicht gefunden wird und man die Entscheidung für eine andere treffen muß), dann kann man das sogar an anderen Stellen wieder zum Download nachnutzen (vielleicht erinnerst Du Dich ja noch an meinen "Wrapper"-Vorschlag bei anderen Diskussionen um die tools und den Zeitpunkt für deren Erstellen) - es muß ja (auch unter Freetz) nicht alles unbedingt immer ein geklontes Repository sein, wenn das jeweilige Projekt auch "fertige Pakete" bereithält und die für die eigene Installation passend wären.

Dieses "alles 'from scratch'-Selbstmachen(wollen)" (auch bei BusyBox und (De-)Kompression/Hash-Berechnung) ist ja auch eher ein Überbleibsel aus einer Zeit, wo es nur wenige "fertige Angebote" bei anderen Projekten gab und auch die Repos der Distributionen noch nicht so üppig ausgestattet waren, wie das heute der Fall ist und wo es den Leuten egal war, wenn die Freetz-Benutzer erst mal "Kaffeepause" machen müssen/können, sobald so ein Build loslegen soll.

Ich könnte mir sogar noch vorstellen, die diversen Skript-Fragmente, die ich hier für diese Aufgabenstellung (Suche des passenden Binary, Download, Aufruf) herumfliegen habe, mal in eine Art bootstrap-Skript zu packen, das dann die oben beschriebenen Schritte zusammenfaßt und diese Skript mit ins Repo zu packen (damit man nur noch das dann laden und ausführen muß). Aber auch nicht heute (und nicht morgen) - so kompliziert ist das alles von der Umsetzung her ja auch nicht und so ein Skript wäre eher für den Gelegenheitsbenutzer gedacht und gar nicht für anderen Projekte, die das selbst noch einmal automatisieren wollen.

Ich würde tatsächlich an Deiner Stelle auch noch eine Prüfung der Signatur einbauen (zumindest dann, wenn gpg2 vorhanden ist und das sollte praktisch überall der Fall sein) ... wie man das auch machen kann, ohne gleich den verwendeten Key in den eigenen "key ring" als "vertrauenswürdig" einzuschließen, kann man sich auch wieder im decoder-Repo ansehen, denn da mache ich für den Download der libnettle-Quellen genau dasselbe: https://github.com/PeterPawn/decoder/blob/master/src/nettle/download.sh

Auch das kann man wieder "nachnutzbar" machen, so daß der Aufwand (der für diesen konkreten Fall hier auf den ersten Blick vielleicht etwas übertrieben erscheinen mag) sich deutlich relativiert.

[fda77]

Ich hab die Ausgabe des Keys verdeckt: 4730119

Ein "read" für's Passwort hatte ich eh schon gemacht, da die Ausgabedatei nun auch wieder verschlüsselt wird: 27fc97b
So wäre das PW bis zu 5x nötig. Das Passwort in einer Variable ist in den .cgi unumgänglich, da es so übergeben wird

mit OpenSSL > 1.0.x machen müßtest, denn es ist ja eher unwahrscheinlich, daß es sich bei beiden Dateien unterscheid

Das könnte schon durch das wieder-verschlüsseln vorkommen, da nur sie settings neu verschlüsselt werden

wobei sich die Einstellungen ohne das Kennwort nur auf derselben Box wiederherstellen ließen

Das ist in ng für plain als auch verschlüsselte Backups so. Da beide die $$$$ enthalten, und das entschlüsseln am PC vorgesehen ist. Wenn man will kann man aber die identity.md5 einfach aus dem Archiv löschen... Die wird übrigens "mit Zeilenumbrüchen" gebildet, hoffe das ist so okay

Wenn's was bringt, kann ich auch noch ein install-Applet einbauen

Ne, es wird gar nichts compiliert (nettle), sondern nur heruntegeladen, entpackt und verlinkt mit den normalen freetz-tools - wie yourfritz-host https://github.com/Freetz-NG/freetz-ng/blob/master/tools/make/yourfritz-decoder-host/yourfritz-decoder-host.mk

ich wüßte jedenfalls keinen Weg, bei einem HTTP(S)-Download irgendwelche "executable"-Attribute mit zu übergeben

Hier liegen 4 Bins, wobei nur 1 ausführbar ist - bei den anderen 3 fehlt es https://github.com/PeterPawn/decoder/tree/master/bin und 45851ca

weil die Existenz einer ARM32-Emulation nicht zwingend sein muß

Davon hab ich noch nie was gehört, und nichts selbst nachinstalliert. Die Emultion scheint wohl normal mitinstalliert zu sein. Deine Bins heissen "womit gebaut wurde", und in Freetz werden sie als "worauf sie lauffähig sind" benutzt. Aber es gibt ja den Fallback auf die Scripte.

Shell-Variablen $PASS steht. Wobei der Name natürlich schrecklich ist - wenn da irgendjemand anderes auch ein $PASS benutzt und diese Variable dann immer noch gesetzt ist,

Die Variable wird doch immer gesetzt, ob es $2 gibt oder nicht: https://github.com/Freetz-NG/freetz-ng/blob/master/tools/decoder_for_settings_backup#L11

es muß ja (auch unter Freetz) nicht alles unbedingt immer ein geklontes Repository sein, wenn das jeweilige Projekt auch "fertige Pakete" bereithält und die für die eigene Installation passend wären.

Das ist aber am einfachsten, weil es die Funktion schon gibt!

eine Prüfung der Signatur einbauen (zumindest dann, wenn gpg2 vorhanden ist

Das würde man besser in https://github.com/Freetz-NG/freetz-ng/blob/master/tools/freetz_download einbauen, also für alle Packages die es brauchen, zb als Checksum Alternative
Dann bräuchte man die Checksummen bei einer neuen Version auch nicht mehr zu ändern.
Reicht keyID & keyFingerprint? Oder muss man für manches andere keyServer nutzen?

[PeterPawn]

Wir reden/schreiben nur noch (oder schon wieder) aneinander vorbei. Ich kann natürlich immer nur auf das Bezug nehmen, was ich sehe (und das muß ich mir auch erst mühsam zwischen irgendwelchen anderen Commits zusammensuchen, was die Chancen, daß ich einen Commit übersehe, extrem erhöht) und was Du schon ins GitHub-Repo committed hast.

Und selbst dann fehlt eben allzu häufig auch der Kontext ... woher sollte ein "Beobachter" bei den bisherigen Commits überhaupt erkennen können, wann und von wo bei Dir das decoder_for_settings_backup jemals aufgerufen werden sollte und mit welchen Parametern? Ich habe den ganzen Teil bis zur Zeile 22 bisher gar nicht für voll genommen ... weil das für mich alles noch nach irgendwelchen Einstellungen zum Test des Skripts an sich aussah (und aussieht). Ich kann mich auch nicht entsinnen, daß ich irgendwo von Dir eine "Erklärung" gelesen zu haben und auch die NEWS geben keine Hinweise ... das muß sicherlich auch noch nicht sein, aber Du kannst eben auch nicht erwarten, daß irgendjemand hellseherische Kräfte entwickelt und damit vorhersieht, wo Du eigentlich hin willst und welche Änderungen welchen Zwecken dienen sollen.

Selbst wenn ich wie eine kaputte Schallplatte klingen mag ... erstens fehlen Deinen Commits aussagekräftige Beschreibungen und zweitens nervt es unendlich, wenn man sich (um sich einen Überblick über ein "Thema" zu verschaffen) erst durch Deine unendliche Liste von Commits graben muß, von denen dann vielleicht 10% auch für das relevant sind, was man sich gerade ansehen will/soll.

Das könnte schon durch das wieder-verschlüsseln vorkommen

Da stellt sich mir dann die Frage, warum man nicht einfach BEIDE Dateien dann neu verschlüsseln sollte - die Schleife ist ja nur auf zwei Files ausgelegt und wenn ich nichts übersehe, wird das Entschlüsseln auch für beide durchgezogen, so daß ich nichts sehe, was das erneute Verschlüsseln für BEIDE Dateien verhindern sollte.

es wird gar nichts compiliert

Das habe ich ja auch nicht behauptet ... ich habe nur darauf hingewiesen, daß man (abseits von der eigentlichen Funktion des Shell-Skripts) einen Symlink unter einem "stabilen Namen" erzeugen sollte, der dann einfach aufgerufen wird. Ob das dann das Binary ist oder die Shell-Version, muß das Skript gar nicht mehr interessieren ... und da die vorkompilierten Binaries nun mal (wie BusyBox-Applets auch) nur dann genauso aufgerufen werden können, wie die gleichnamigen Shell-Skripte, wenn es über einen Symlink mit passendem Namen erfolgt, macht auch das Anlegen dieser Symlinks Sinn. Da das gesamte Binary aber nicht zwingend immer ALLE Applets enthalten muß (das kann im Makefile konfiguriert werden), kann man diese Symlinks "auf Verdacht" anlegen und riskiert dann, daß da auch welche dabei sind, die vom vorliegenden Binary gar nicht unterstützt werden ... oder man baut eben noch ein install-Applet ein, was genau weiß, welche Applets verwendbar wären und die passenden Symlinks anlegt.

Aber vergiß es ... ich habe mich mittlerweile selbst von dieser Idee überzeugt und so wird es ein solches Applet in der nächsten Version ohnehin geben.

bei den anderen 3 fehlt es

Weil es mich - wie geschrieben - gar nicht interessiert, denn ich gehe davon aus, daß niemand so blöd ist, das komplette Repo zu klonen, nur weil er ein einzelnes der dort enthaltenen Binaries benutzen will. Und wenn er es ohnehin einzeln laden MUSS, dann gibt es (m.W.) keinen Weg, die Attribute aus dem Repo beim Download automatisch mit zu setzen.

Also interessiert es auch nicht, welche Attribute die Dateien im Repo haben und die Tatsache, daß das x64-Binary dort ausführbar ist, liegt auch nur daran, daß ich manchmal auf meinem eigenen System (wo ich die Originale der Repos verwalte) schnell auf dieses Binary zurückgreifen will (ich habe extra keines gesondert "installiert", damit ich immer die aktuelle Version aus dem Repo habe), wenn ich eine der angebotenen Funktionen brauche. Hätte ich ein 32-Bit-System, wäre sicherlich die i686-Version ausführbar.

und nichts selbst nachinstalliert.

https://forum.armbian.com/topic/4764-running-32-bit-applications-on-aarch64/ zum Beispiel.

Die Variable wird doch immer gesetzt,

Siehe oben ... hatte ich nicht für voll genommen, macht aber die mehrfache Eingabe (die es ja inzwischen auch nicht mehr geben soll) um so unverständlicher.

Da beide die $$$$ enthalten, und das entschlüsseln am PC vorgesehen ist. Wenn man will kann man aber die identity.md5 einfach aus dem Archiv löschen... Die wird übrigens "mit Zeilenumbrüchen" gebildet,

Ich habe gar keine Idee, was diese identity.md5 sein soll ... wenn es dazu auch irgendwo einen Commit gibt, habe ich den nicht gelesen. Und das mit dem "Entschlüsseln am PC" lese ich hier auch gerade das erste Mal ... bisher war mir gar nicht so richtig klar, worauf Dein decoder_for_settings_backup eigentlich abzielt und ich kann mich auch nicht erinnern, daß Du das irgendwo schon einmal erwähnt hättest.

---

Wenn ich das richtig verstehe, läuft es jetzt also darauf hinaus, daß der Freetz-Benutzer ein Backup seiner Freetz-Settings machen kann und daß ihm dabei (immer noch ohne ihm eine Wahl zu lassen) auch die AVM-Dateien aus /var/flash mit gesichert werden (nicht jeder TFFS-Node hat auch immer einen korrespondierenden "char device"-Node in /var/flash) ... jetzt aber mit einem, von ihm bei der Sicherung zu wählenden, Kennwort verschlüsselt. Das gilt auch für die Freetz-Settings und für eine Kopie des Urlader-Environments, die Du ebenfalls mit in das TAR-File der gesamten Sicherung packst.

Ohne mir das jetzt angesehen zu haben, hoffe ich mal, daß dann beim Wiederherstellen so einer Sicherung geprüft wird (ist das die identity.md5?), ob die von derselben Box stammen und wenn das nicht der Fall ist, wird die Wiederherstellung der AVM-Dateien verweigert. Das wäre zumindest das, was hier mal das Thema war, als ich den Thread eröffnete.

Und wenn jetzt jemand doch auch mit den AVM-Einstellungen auf ein anderes Gerät umziehen will (meinetwegen, weil das vorherige defekt ist), dann soll er das - nach Deiner Ansicht - in mehreren Schritten machen. Erstens soll er auf der neuen Box ein Freetz-NG-Image installieren und danach dann - über das Freetz-GUI - versuchen, die alte Sicherung einzuspielen, was zwar für die Freetz-Settings funktionieren würde, aber nicht für die AVM-Einstellungen. Was passiert jetzt eigentlich mit den Freetz-Settings, wenn die von einer anderen Box kommen? Werden die dann trotzdem verarbeitet und nur die AVM-Einstellungen nicht?

Aber weiter im Text ... wenn er jetzt im GUI liest, daß die (AVM-)Einstellungen einer fremden Box nicht wiederhergestellt werden können, soll er sich ein Linux-System greifen und auf diesem dann die gesicherten Einstellungen mit Deinem Skript dekodieren (also die in den AVM-Dateien enthaltenen "secrets") und mit der - von Dir dann neu verschlüsselten - Backup-Datei den nächsten Versuch der Wiederherstellung über das Freetz-GUI starten.

Ich habe mir das - wie gesagt - noch nicht angesehen (packe es in einen gesonderten Branch und Du machst es anderen (nicht nur mir) deutlich leichter, das alles irgendwie nachzuvollziehen) ... aber hat er jetzt tatsächlich die Wahl, nur noch die AVM-Einstellungen wiederherzustellen (die Freetz-Einstellungen hat er ja bereits und ggf. sind die sogar noch weiter geändert seit dem vorherigen Restore) und die Freetz-Einstellungen zu ignorieren?

Wie unterscheidet das GUI denn jetzt, ob die angebotene Backup-Datei (die ist ja dann sicherlich immer noch von einer anderen Box) die AVM-Einstellungen in dekodierter oder in (partiell) verschlüsselter Form enthält? Warum sollte er überhaupt die "Holzhammer-Methode" für die AVM-Einstellungen wählen wollen, bei der die Dateien einfach nur überschrieben werden?

Wenn die Sicherung von einer deutlich älteren AVM-Version stammt, wäre es ja viel schlauer, wenn er das über die AVM-Funktionen macht/machen könnte ... dabei werden dann aus den Daten in der Backup-Datei die entsprechenden Angaben gleich im neuen Format aufgebaut (intern/im Speicher) und dann auch im neuen Format in die TFFS-Nodes geschrieben.

Ich habe ja in #214 (comment) mehrere denkbare Szenarien beschrieben, wie man das Problem angehen könnte ... bisher habe ich aber noch nirgendwo gelesen, welchen Aspekt der ganzen Sicherungs-/Wiederherstellungsgeschichte (und die hat ja durchaus mehr als einen) Du nun eigentlich lösen willst und was das Ergebnis am Ende sein soll.

Aber ich glaube/hoffe nicht, daß Du tatsächlich ernsthaft der Ansicht bist, man sollte jetzt für die "Umwandlung" einer alten Freetz-Sicherung in eine Form, die man auch auf einer anderen Box einspielen kann, auf einen Linux-Host zurückgreifen, auf den man erst noch ein Freetz-NG klont und dann kann man irgendwann - nach jeder Menge Vorbereitungen - diese Datei umwandeln lassen. Ich bin der Ansicht, daß jeder, der mit seinen eigenen Sicherungen tatsächlich so vorgehen wollte, einfach nur Langeweile haben muß ... da ist es ja zig-mal einfacher, die AVM-Settings auch mit den AVM-Mitteln wiederherzustellen und beim Wiederherstellen der Freetz-Einstellungen die AVM-Einstellungen komplett wegzulassen - auf die Dateien, die sich bei AVM nicht in der Export-Datei finden lassen, muß man dann halt verzichten.

Solange Du jetzt nicht ermittelst, welche Dateien in so einer Freetz-Sicherung zusätzlich enthalten sind, die bei einer AVM-Sicherung unter den Tisch fallen würden, wirst Du auch einem Freetz-NG-Benutzer nur schwerlich den Vorteil der Sicherung ALLER AVM-Dateien klarmachen können ... ja, durch die o.a. Versionierung der AVM-Einstellungen läuft er hier sogar (weiterhin) Gefahr, daß dieses Überschreiben (als Gegensatz zum "Wiederherstellen" bei AVM, was eben auch die Daten umwandelt bzw. ihm sogar die selektive Wiederherstellung einiger Einstellungen gestattet bzw. den Ausschluß unerwünschter) negative Seiteneffekte hat und er (sicherlich im schlechtesten, aber auch nicht gänzlich unwahrscheinlichen Falle) die ganze Chose von vorne beginnen darf (zumindest ist die Chance, mit einer leeren ar7.cfg überrascht zu werden, wenn die nicht zum System paßt oder Syntaxfehler enthält, deutlich erhöht).

Du hast hier also - nach meinen Begriffen - irgendetwas zwischen Fehlerkorrektur (das wäre die reine Verweigerung der Wiederherstellung für eine fremde Box gewesen - wobei man das "fremde Box" auch aus alten Sicherungsdateien ablesen kann) und neuen Funktionen (Verschlüsselung der - durchaus sensiblen - Daten in den Freetz-Einstellungen) gewählt und Dich dabei offenbar in Deine erste Idee so sehr verliebt, daß Du die Frage, was es dem "gemeinen Freetz-(NG-)Benutzer" am Ende bringt, gar nicht weiter beachtest. Denn schon die Anwendung des decoder_for_settings_backup-Skripts ist (für diejenigen, die nicht permanent ein passendes System bereithalten) mit so einem Aufwand verbunden, daß es anstelle einer Erleichterung eher zur Beschwernis wird, wenn er die AVM-Dateien dekodieren (lassen) will.

Da die Binaries (im decoder-Repo) praktisch für alle derzeit verfügbaren AVM-Boxen vorhanden sind, wäre es ohne weiteres auch möglich, die AVM-Settings der fremden Box direkt auf der FRITZ!Box zu dekodieren - dazu müßte man nur diese Dateien halt (temporär) auf die Box laden und nicht auf den Build-Host.

Und auch wenn ich der Ansicht bin, daß man keine "fertigen Freetz-(NG-)Images für Dritte" bereitstellen darf (oder zumindest sollte), gibt es auch immer wieder Konstellationen, wo jemand für die Leute im Bekannten- und Verwandtenkreis den Bau solcher Images übernimmt (wogegen wieder nichts einzuwenden ist - zumindest meinerseits bzw. nach meiner Ansicht, denn die werden dann eben nicht irgendwo im Netz zum Download angeboten) und dann hat der Freetz-Benutzer vermutlich selbst gar keinen Build-Host, auf dem er Dein Skript abarbeiten könnte.

---

Ich weiß ja nun nicht, ob Du das noch einmal anfassen wirst oder ob Du von Deiner Lösung so überzeugt bist, daß die andere halt benutzen können oder auch nicht.

Wenn ich Dir (wieder mal ungefragt) einen Rat geben darf ... der Benutzer sollte beim Backup selbst entscheiden dürfen, welche Einstellungen er in der Sicherungsdatei sehen möchte. Für die AVM-Settings würde ich sogar so weit gehen, in die Freetz-Sicherung nur die Dateien (im "native format") einzuschließen, die in der AVM-Sicherungsdatei nicht enthalten sind und für die anderen einfach eine Export-Datei von AVM in die Freetz-Sicherung einzubinden. Denn für die Settings in der Export-Datei von AVM, weiß die originale Firmware nun mal am besten, wie und wo die wiederhergestellt werden können oder sollten - und sich eine Export-Datei mit dem - vom Benutzer im Freetz-GUI - angegebenen Kennwort erstellen zu lassen, ist ja kein Problem.

Beim Wiederherstellen über das Freetz-GUI kann man sich dann wieder aussuchen, ob man nur die Freetz-Einstellungen restaurieren will oder die "zusätzlichen AVM-Dateien" oder sogar die komplette Box (da hat so ein Freetz-Backup dann den Vorteil, daß man tatsächlich alle Einstellungen an einer Stelle/in einer Datei hat und man nicht mehrere braucht) - wobei dann das Wiederherstellen der AVM-Einstellungen (als letzter Schritt) tatsächlich auch wieder mit einem zwingenden Reboot verbunden wäre (was aber jetzt auch so ist, wenn man möchte, daß die Einstellungen nach dem Überschreiben bei den AVM-Daemons ankommen).

Und wenn man sich eine Sicherung der AVM-Einstellungen "besorgt" (und zwar "live"), kann man damit auch gleich feststellen, welche Dateien in /var/flash zwar vorhanden sind, aber nicht in der Export-Datei (die "Header" für die Files sind ja bekannt) - damit ist die gezielte Sicherung nur der zusätzlichen Dateien machbar, ggf. sogar wieder durch den Benutzer auswählbar für jede Datei, denn so viele sind es auch wieder nicht und manche sollte/will man auch gar nicht wiederherstellen, z.B. uralte Anruflisten oder Telefonbücher.

Zusätzlich hat die AVM-Sicherung im Export-Format noch den Vorteil, daß man da gar nichts selbst dekodieren muß, egal von welcher Box die stammt - denn die ist ja schon mit dem Export-Kennwort neu verschlüsselt (im Gegensatz zu den Werten, die in den Dateien im TFFS stehen). Der Rest der AVM-Dateien enthält nur noch wenige (oder sogar keine, ich weiß aus dem Stand auch nicht genau, was seit 07.2x alles so exportiert wird bzw. wann AVM vom hexadezimalen BINFILE auf B64FILE wechselte) verschlüsselte Daten - im besten Falle kann man dann sogar komplett auf decoder verzichten.

Der andere Weg, den ich im ersten Beitrag im Thread angerissen habe (und nur dafür bräuchte man dann decoder tatsächlich wieder - und nur deshalb habe ich das dort auch erwähnt), wäre eben von vorneherein die Speicherung der Klartext-Daten (natürlich dann wieder verschlüsselt für die gesamte Datei) - ohne diese (und ohne die Verwendung des AVM-Exports) braucht es dann beim Wiederherstellen der Einstellungen einer fremden Box aber auch wieder decoder (oder irgendein passendes Tool halt). Nur hatte ich beim Schreiben des ersten Beitrags NIE eine Lösung im Sinn, bei der die Datei erst noch auf einem weiteren System "bearbeitet" werden muß, damit man sie dann vielleicht doch noch (gefahrlos) zum Überschreiben der AVM-Settings benutzen kann.

---

Wie geschrieben ... die Gretchen-Frage ist es (und die solltest Du VORHER schon für Dich beantwortet haben - also bevor Du überhaupt eine einzige Zeile in ein Shell-Skript schreibst), was am Ende dabei herauskommen soll und was das für Vorteile für die Benutzer des Forks hat (oder ob überhaupt) - außer Du willst das nur für Dich (und Deine 546E) machen, denn für Dich ist die Hürde mit dem Bereithalten eines passenden Build-Hosts sicherlich keine.

Insgesamt besteht diese Geschichte jedenfalls aus mehr als einem Problem - also sollte man die auch gesondert betrachten und stellenweise sogar gesondert lösen.

• AVM-Settings überschreiben: ja/nein (automatische Erkennung, daß/ob das die AVM-Einstellungen komplett zerlegt oder nicht)
• Freetz-Settings sicher verschlüsseln, damit sensitive Daten darin geschützt sind
• Kompatibilität mit früheren Sicherungsdateien
• zusätzliche Schritte zum Wiederherstellen von AVM-Settings einer fremden Box

Das ist zwar ein gemeinsames Thema, aber eben mehrere Probleme (ich bin nicht mal sicher, daß die "Liste" komplett ist bzw. man kann die sicherlich auch anders aufteilen) und daher sollte man das auch nicht alles miteinander vermengen oder sich zumindest zuerst mal einen Plan machen, den man dann umsetzen kann und mit so einem Plan, kann man dann die eigene Idee auch anderen präsentieren und die nach ihrer Meinung fragen ... die Leute nur noch durch Commits zu jagen und davon auszugehen, daß die sich das gefälligst selbst zusammenreimen sollen, verschreckt sie (das gilt auch für mich selbst) nur wieder.

[fda77]

woher sollte ein "Beobachter" bei den bisherigen Commits überhaupt erkennen können, wann und von wo bei Dir das decoder_for_settings_backup jemals aufgerufen werden sollte

Lies mal die contents.txt in dem Einstellungsbackup das du gemacht hast
NEWS wollte ich erst updaten wenn sich das ganz soweit "gesetzt" hat und keine Größeren Änderungen mehr kommen sollten. Aber soviel gibt es nicht zu wissen ausser: Man kann verschlüsselte Backups machen. Das steht aber auch auf der Webif-Seite etwas genauer

Da stellt sich mir dann die Frage, warum man nicht einfach BEIDE Dateien dann neu verschlüsseln sollte

Am Environment änder sich doch nichts. Man könnte sie im "decoded" auch ganz weglassen, sie ist ja nur fürs decodieren (am PC) nötig und es ist ja schon decoded.

ich gehe davon aus, daß niemand so blöd ist, das komplette Repo zu klonen,

Wie gesagt, ich benutze einfach dir vorhandenen freetz-tools. Extra Aufwand find ich hierfür überflüssig. Das Package wird nur erstellt, wenn man das decodier-Script am PC startet. Und wie gesagt geh ich davon aus dass es 1x im Jahr wirklich benutzt wird. So oft wechselt man nicht auf ein Ersatzgerät!

bisher war mir gar nicht so richtig klar, worauf Dein decoder_for_settings_backup eigentlich abzielt und ich kann mich auch nicht erinnern, daß Du das irgendwo schon einmal erwähnt hättest.

contents.txt im Backup!

Ohne mir das jetzt angesehen zu haben, hoffe ich mal, daß dann beim Wiederherstellen so einer Sicherung geprüft wird (ist das die identity.md5?)

Richtig .. es gibt doch nur das Script decoder_for_settings_backup und auf der Box die 3 Dateien in https://github.com/Freetz-NG/freetz-ng/tree/master/make/mod/files/root/usr/mww/cgi-bin/backup/

Da die Binaries (im decoder-Repo) praktisch für alle derzeit verfügbaren AVM-Boxen vorhanden sind, wäre es ohne weiteres auch möglich, die AVM-Settings der fremden Box direkt auf der FRITZ!Box zu dekodieren

Klar, ich dachte du bist da aber anderer Meinung übers's dekodieren auf der Box: https://github.com/Freetz-NG/freetz-ng/blob/master/make/decrypt-fritzos-cfg/Config.in#L13
Man hätte auch die Backups dekodiert sichern können ...

dann hat der Freetz-Benutzer vermutlich selbst gar keinen Build-Host, auf dem er Dein Skript abarbeiten könnte.

Das ist dann Pech. Man kann ja zur Not einen Raspberry nehmen. Oder einfach alles neueingeben ^^

AVM-Settings überschreiben: ja/nein

Das gibt es doch schon seit Jahren/immer

Freetz-Settings sicher verschlüsseln, damit sensitive Daten darin geschützt sind

Ist doch, falls man sich dafür entschieden hat

Kompatibilität mit früheren Sicherungsdateien

Vorhanden

zusätzliche Schritte zum Wiederherstellen von AVM-Settings einer fremden Box

Das macht das Script am PC (/Raspberry...)

Das einzigste was man noch machen könnte ist die Restore-Funktion um "nur AVM" erweitern könnte. Wers unbedingt will kann aber die "freetz" aus der settings.tgz löschen

[PeterPawn]

in dem Einstellungsbackup das du gemacht hast

Schon da gehst Du von vollkommen falschen Annahmen aus. An meine FRITZ!Boxen lasse ich nur Wasser und YourFritz - alles andere sehe ich mir höchstens in irgendeinem Repo an und probiere das nicht selbst aus - erst recht nicht, bevor ich mir die gemachten Änderungen ausführlich angesehen habe und das ist bei Freetz-NG gar nicht möglich, wenn man noch andere Hobbys hat.

Am Environment änder sich doch nichts. Man könnte sie im "decoded" auch ganz weglassen, sie ist ja nur fürs decodieren (am PC) nötig und es ist ja schon decoded.

Man könnte sie aber auch einfach wieder neu verschlüsseln und mit einpacken ... schon ist die Chance, daß da verschiedene OpenSSL-Versionen zum Verschlüsseln benutzt wurden, praktisch Null. Und wenn die "dekodierte" Sicherungsdatei dann plötzlich einen anderen Inhalt hat als die mit den verschlüsselten Einträgen von AVM (ansonsten kann man das ja wohl nur an irgendwelchen zusätzlichen Dateien erkennen, oder wie willst Du das bewerkstelligen), braucht die ja letztlich auch wieder einen "eigenen Weg" bei der Wiederherstellung - was nur ein weiterer (m.E. unnötiger) Fall beim Wiederherstellen würde.

Je nachdem, wie die "Philosophie" dahinter am Ende aussehen mag (ich habe mit dem Antworten begonnen, ohne den letzten Beitrag schon komplett gelesen zu haben, das kommt gleich noch), ist es ja vollkommen gleich, ob man die verschlüsselten Einstellungen von derselben Box wiederherstellt oder die entschlüsselten einer fremden - das Einzige, was man vermeiden muß, ist das Wiederherstellen der verschlüsselten Einstellungen einer fremden Box.

Aber auch dann ist das alles noch nicht ganz so einfach, wie es sich Freetz(-NG) bisher dort macht - zumindest eben nicht, wenn es eine andere Box ist. Denn es gibt ja nicht nur die "encrypted secrets" in den AVM-Dateien, die mit den vier Dollarzeichen beginnen ... wenn man tatsächlich auch die websrv_ssl_key.pem bzw. die letsencrypt_key.pem wiederherstellen will, muß man die dort enthaltenen privaten Schlüssel auch einmal entschlüsseln und mit dem passenden Device-Key dann wieder verschlüsseln (bei der letsencrypt_key.pem muß ich die Komponenten für das passende Kennwort auch erst noch ermitteln, die kenne ich selbst noch nicht genau) ... ansonsten beißt sich der ctlmgr da beim nächsten Mal die Zähne aus, wenn er diese Keys mit dem Kennwort der neuen Box öffnen will.

Aber ich lese jetzt erst mal Deinen Beitrag weiter ... und schreibe dann eine neue Antwort. Ich bin also noch nicht fertig ... und wenn Du verhindern willst, daß wir erneut aneinander vorbei schreiben, wartest Du, bis ich "fertig" gerufen habe.

[PeterPawn]

ich dachte du bist da aber anderer Meinung übers's dekodieren auf der Box

Der Disclaimer stammt von @er13 - ich selbst sehe kein Problem darin, das Programm in ein Image einzubinden. Wer dieses Binary auf der Box aufrufen und dessen Ausgabe irgendwie "abgreifen" kann, der kann das üblicherweise genauso gut auch mit einem Dump der TFFS-Partition machen (mehr braucht es gar nicht, denn das Urlader-Environment ist darin ja genauso zu finden, wie die Streams mit den AVM-Einstellungsdateien) und damit weicht die Existenz des Programms die Sicherheit nicht zwangsläufig auf.

Wobei man das hier ja auch gar nicht permanent auf der Box ablegen müßte ... wenn man es tatsächlich nur "bei Bedarf" lädt und da macht es dann schon einen gewaltigen Unterschied, ob ich generell vor dem Backup schon entschlüsseln willl (dann wird das nämlich bei jedem Backup benötigt) oder ob ich es nur dann benutzen muß, wenn es tatsächlich zur Wiederherstellung kommt (was per se schon mal seltener sein wird, als Backup) und zusätzlich noch das Backup einer anderen Box eingespielt werden soll (was das noch einmal einschränkt in der Häufigkeit).

Ein:

Man hätte auch die Backups dekodiert sichern können ...

sollte man also nur dann in Erwägung ziehen, wenn das notwendige Binary ohnehin auf der Box vorhanden ist ... und dann versteht sich die (mittlerweile bei Dir ja nachgerüstete) eigene Verschlüsselung der Daten aber auch von selbst. Das war - wenn Du oben nachliest - meinerseits auch nur als Option genannt, wenn man die eigene Verschlüsselung hinzufügt - und das hast Du ja getan. Ich würde trotzdem (aus den o.a. Gründen hinsichtlich der Häufigkeit) das nicht direkt beim Sichern dekodieren lassen ... außer es gibt noch andere, gewichtige Gründe, die dafür sprächen - einer wäre ggf. der Wegfall der Notwendigkeit der Speicherung des Urlader-Environments und generell der Tests, ob die Einstellungen von dieser oder einer anderen Box sind.

Aber dieser Grund relativiert sich bei den oben bereits erwähnten websrv_ssl_key.pem und letsencrypt_key.pem ohnehin wieder. Die müßte man dann auch schon beim Sichern entschlüsseln lassen und beim Wiederherstellen neu verschlüsseln - denn anders als bei den Klartext-Werten in den cfg-Files, werden diese Dateien nicht beim nächsten Speichern automatisch auch neu verschlüsselt.

Damit macht das vorherige Dekodieren (wenn man noch gar nicht weiß, daß das Wiederherstellen auf einer anderen Box erfolgen wird) nur sehr begrenzt Sinn (in meinen Augen) ... und für den sehr, sehr seltenen Fall, daß tatsächlich mal die AVM-Einstellungen einer fremden Box auf diesem Wege wiederhergestellt werden sollten (ggf. reicht ja schon das Ablehnen, damit der Benutzer sich nicht selbst ins Knie schießt), kann man dann - sofern es das Programm zum Dekodieren auf der Box nicht bereits gibt - auch versuchen, einen temporären Download für eines der fertigen Binaries auszuführen (das kann hinterher ja auch wieder weg) und wenn der dann nicht klappt, hat man halt Pech gehabt. Wie weiter oben geschrieben ... es ist ohnehin nicht wirklich schlau, die AVM-Einstellungen einfach nur zu überschreiben, anstatt sie durch firmwarecfg richtig wiederherstellen zu lassen.

Das gibt es doch schon seit Jahren/immer

Einfach noch einmal lesen, was dahinter noch stand ... es geht darum, automatisch zu entscheiden, ob die Einstellungen von einer fremden Box und verschlüsselt sind und dann die Wiederherstellung zu verweigern, weil die gar nicht funktionieren KANN.

Alle weiteren Argumente zu den "vier Problemen" verlagern wieder die Verantwortung (und die Notwendigkeit, sich die passenden Kenntnisse zu verschaffen) auf den Freetz-Benutzer. Letztlich hat er (wenn es tatsächlich eine "Sperre" für das Wiederherstellen verschlüsselter Einstellungen einer anderen Box gibt) in einem Punkt ein wenig Sicherheit/Bedienkomfort gewonnen, wobei auch die Verschlüsselung der Freetz-Einstellungen ja zusätzliche Sicherheit bringt. Aber in dem anderen Punkt, wenn er bei der "Sperre" aufschlägt, machst Du es ihm vollkommen unnötig deutlich schwerer, als es sein müßte. Er hat bereits ein Linux-System (nämlich seine FRITZ!Box) und er hat eine Sicherung von verschlüsselten AVM-Einstellungen, die er auch schon versucht wiederherzustellen. Anstatt ihm jetzt eine lange Nase zu zeigen und ihn auf ein anderes System zu schicken, damit er erst mal gefälligst die Sicherungsdatei umwandelt, könnte man auch einfach hingehen und die Datei gleich auf der FRITZ!Box dekodieren.

Zuerst schaut man, ob es das Programm vielleicht schon im Image gibt, dann nimmt man das. Ist es nicht vorhanden und die Box kommt schon ins Internet, kann man versuchen, es aus meinem Repo zu laden, zu benutzen und wieder wegzuwerfen. Ist auch das nicht möglich, weil es keine Internetverbindung gibt oder kein passendes Programm gefunden wurde und auch die Skript-Lösung am Fehlen von Programmen scheitert (was schon mal unwahrscheinlicher wird, wenn das Backup/Restore ohnehin ein openssl braucht - darin erschöpfen sich nämlich eigentlich auch die Voraussetzungen für die Skript-Dateien), kann man noch auf den USB-Volumes und im NAS-Verzeichnis nach einem passenden File suchen, das der Benutzer ggf. mit einem anderen System geladen und dort abgelegt hat.

Wenn alles das nicht gefunden wird, DANN kann man auch wieder aufgeben (was Du ja schon für den Fall vorschlägst, daß jemand kein zweites Linux-System hat, auf dem er Dein Skript laufen lassen kann) und dem Benutzer eine Information anzeigen, warum man das machen mußte und wie er das Problem trotzdem noch meistern kann, wenn es tatsächlich nur an der Internetverbindung liegt und er irgendwie das passende Programm (selbst den Namen und die URL kann man ihm noch anzeigen, weil man das aus einem $(uname -m) ja ermitteln kann) auf einen USB-Stick kriegt (oder halt eine Internetverbindung mit der Box herstellen kann).

DAS wäre jedenfalls in meinen Augen dann eine Lösung, die dem Benutzer das Problem tatsächlich abnimmt, ohne ihm gleichzeitig (und ohne jede Not) andere Probleme dabei aufzubürden. Wenn er ohnehin auf das Wiederherstellen der AVM-Einstellungen verzichten will, braucht man den ganzen Kram ohnehin nicht ... dann braucht man aber auch Dein Skript in tools nicht wirklich - für mich ist das eine Lösung, die auf halber Strecke stehenbleibt.

Und wenn Du das tatsächlich so machst, daß die Dateien, die in der AVM-Sicherung enthalten sind, auch über diesen Weg gesichert werden und nur diejenigen, die dort fehlen, dann über das Kopieren aus /var/flash (mit entsprechenden Anpassungen beim Wiederherstellen auf einer fremden Box, siehe die Keys oben), dann hast Du dem Freetz-NG-Benutzer tatsächlich einen (auch verläßlichen) Vorteil verschafft ... dann kann er sich wirklich beim Sichern des Zustands seiner FRITZ!Box ausschließlich auf den Freetz-Weg verlassen.

Da kommt noch hinzu, daß Du die AVM-Export-Datei ja auch nicht noch einmal selbst verschlüsseln müßtest ... mit einer solchen Datei in einem "Freetz-Backup", die er einfach dort extrahieren kann (sogar als Windows-Benutzer, z.B. mit 7z), kann er auch nur die AVM-Einstellungen wiederherstellen lassen oder - dank der selektiven Wiederherstellung bei AVM - auch nur die Teile, die er gerne hätte. Und das alles mit nur einer einzigen Datei aus dem Freetz-Backup (womit er auch nur diese eine Datei gut weglegen müßte und nicht wieder mehrere) ... dazu müßte die halt nur das richtige Format und den passenden Inhalt haben.

So ... wie sagte Hr. Trapattoni so schön: Ich habe fertig.

[fda77]

Du hättest auch gleich schreiben können dass du dekodieren auf der Box selbst besser findest. Ich dachte die Warnung wäre von dir. Das wäre viel einfacher und man brächte das PC-Script und das host-tool gar nicht mehr

enn es tatsächlich eine "Sperre" für das Wiederherstellen verschlüsselter Einstellungen einer anderen Box gibt

Wenn du es nicht auf der Box ausprobieren willst, lies dir dir 2-3 cgi Dateien durch, so lang sind die doch nicht.
Die identity.md5 wird immer erstellt, es gibt sie also nur in alten Backups nicht (oder dekodierten). Man kann sie aus der .tar natürlich auch manuell löschen

Ich hab mir privatekeypassword mal angeschaur. Zuerst, du könntest dessen Repo auf "archived" setzen und dazuschrieben dass es im decoder enthalten ist!
Eines von den Geräten die ich getestet hab, enthält ein $ im berechneten Passwort. Das ist sehr unschön. Kann das überhaupt sein?
Muss das Passwort von key und cert geändert werden? Es ist natürlich blöd dass für websrv und letsencrpyt verschieden Passworte benötigt werden und das für letsencrypt noch unbekannt ist.
Wie kann man denn ein Passwort eines Zertifikates ändern? Gibt es dafür auch ein Applet? Oder mit openssl? Wobei es mit der Openssl-Version und der Kompatibilität mit avm so ne Sache ist

[PeterPawn]

Du hättest auch gleich schreiben können dass du dekodieren auf der Box selbst besser findest.

Erstens ... wie ich schon schrieb, hatte ich gar keine richtige Idee, wohin Du eigentlich unterwegs warst und selbst aus Deinem Skript (und nur auf einen Commit, der das ändert, hast Du hier irgendwo verlinkt) kann man wohl kaum eindeutig erkennen, daß das auf einem anderen System laufen soll/muß nach Deiner Ansicht.

Wenn Du also solche Kommentare/Hinweise erwartest, solltest Du - wieder BEVOR Du irgendetwas implementierst - die Idee dahinter erst einmal niederschreiben (spätestens in den Commit-Kommentar des ersten Patches, den Du in den dafür angelegten Branch schreibst) ... nur dann kannst Du auch "erwarten", daß andere schon vor dem Ende der Implementierung verstehen können, worin Dein eigenes Ziel gerade besteht.

Ich dachte die Warnung wäre von dir.

Wie sollte sie? Das gesamte Einbinden von decoder unter fritzos-cfg-irgendwas in Freetz basiert ja nicht auf einem PR meinerseits und selbst wenn ich da einen Vorschlag gemacht HÄTTE, wäre die Wahrscheinlichkeit, daß dieser auch tatsächlich so in Freetz gelandet wäre, ohne zuvor noch einmal umgemodelt zu werden, ja gegen Null gegangen - das haben die meisten dieser Versuche in der Vergangenheit ja deutlich gezeigt.

Das wäre viel einfacher ...

Meine Rede ... und ein größerer Teil dessen, was Du da in decoder_for_settings_backup (was es offenbar mittlerweile auch schon wieder nicht mehr gibt) "gezeigt" hast, würde ja genau so auch auf der Box selbst funktionieren - daher ja meine Verwirrung/mein Unverständnis/mein Ignorieren der Zeilen 1 bis 22, die ich nur als "Test" ansah, ob der Rest des Skripts wie erwartet arbeiten würde.

Was glaubst Du, warum ich den Aspekt der Laufzeit der Shell-Skripte im Vergleich zu den Binaries so sehr betont habe oder warum ich - sehr deutlich - darauf verwies, daß die vorkompilierten Binaries für alle (heute noch gängigen) Architekturen von FRITZ!Boxen (mit Ausnahme der Puma7-Geräte, wobei die mit der i686-Version auch laufen sollten) vorhanden sind?

Alles, was ich von Dir zu Deinen Absichten bisher gelesen habe, war ein:

Mein Plan war es im Backup das "Passwort" zum Entschlüsseln mit zu sichern.

und was ich davon halte und warum, habe ich Dir gleich im darauffolgenden Beitrag geschrieben.

Ja, selbst den Aspekt, daß man die AVM-Einstellungen besser auch mit AVM-Mitteln sichern sollte und nur den "Rest", der bei AVM nicht ohnehin schon eingeschlossen ist, dann vielleicht zusätzlich in die Freetz-Sicherung einbeziehen kann, findet man bereits im allerersten Beitrag in dieser Diskussion - ich weiß also tatsächlich nicht genau, was Du willst bzw. wo Du irgendetwas erkennst, bei dem ich erst nachträglich meine Meinung geändert hätte, so daß ein:

Du hättest auch gleich schreiben können ...

irgendeine Berechtigung hätte.

lies dir dir 2-3 cgi Dateien durch, so lang sind die doch nicht.

Ich warte da lieber auf die Verfilmung oder auf den Text, in dem Du die neue Option für die Freetz-Benutzer erklärst. Die kannst/wirst Du ja auch nicht auf die eigene Suche in den CGI-Dateien schicken - abgesehen davon, daß sich eben die Patches für diese Dateien irgendwo im master-Branch zwischen vielen anderen "verstecken" und man nicht zwangsläufig Lust auf solche "Suchspiele" haben muß.

Ich hab mir privatekeypassword mal angeschaur. Zuerst, du könntest dessen Repo auf "archived" setzen und dazuschrieben dass es im decoder enthalten ist!

Das ist einerseits sehr schön, wenn Du das mittlerweile getan hast und andererseits ist dann Deine Schlußfolgerung hinsichtlich des Status der dort enthaltenen Dateien trotzdem falsch. So kann man zwar tatsächlich mit einem Applet aus dem decoder-Projekt auch das Kennwort im Klartext ausgeben lassen ... das ist aber bei privatekeypassword nur eine konkrete Anwendung der dort eigentlich wesentlicheren Bibliothek libprivatekeypassword.so - und diese wird (m.W. sogar in ein paar Freetz-Paketen) bei anderer Software genutzt, die direkt (und ohne Umwege über die Speicherung in irgendwelchen Shell-Variablen) auf das Kennwort zugreifen soll/will, weil sie dieses zum Entschlüsseln der websrv_ssl_key.pem benötigt. Ein Beispiel wäre diese Stelle für Shell-in-a-Box: https://github.com/Freetz-NG/freetz-ng/blob/87bdbffe7f43ff9f1579e722ee7c77202501f2c6/make/shellinabox/patches/boxcert/900-box_certificate.patch und

freetz-ng/make/shellinabox/shellinabox.mk

Line 54 in 87bdbff

ifeq ($(strip $(FREETZ_PACKAGE_SHELLINABOX_BOXCERT)),y)

- da hast Du Dir das also offenbar nicht gründlich genug angeschaut.

Eines von den Geräten die ich getestet hab, enthält ein $ im berechneten Passwort. Das ist sehr unschön. Kann das überhaupt sein?

Erstens ... ja, klar ist das möglich. Die "Tabelle", anhand der die Binärwerte vom Hash in Zeichen übersetzt werden, kannst Du Dir hier: https://github.com/PeterPawn/privatekeypassword/blob/6c50c2166139cf12b12ddb572f4f5353627b4d09/shell/privatekeypassword.sh#L44 ansehen (auch hier ist die Shell-Version eigentlich wieder nur als Demo gedacht, ebenso das erzeugte Binary, das eben auch nur die Library zum Auslesen des Kennworts verwendet und dieses dann anzeigt). Und zweitens juckt so ein Dollarzeichen im Wert ohnehin niemanden, wenn man das im Shell-Code richtig behandelt.

Last, but not least ... drittens gibt es bei der Kombination aus openssl und privatekeypassword (egal, ob als Binär- oder Shell-Version) gar keine Notwendigkeit (wieder einmal), das Kennwort in irgendeiner Shell-Variablen zu speichern. Man läßt privatekeypassword das Kennwort einfach auf STDOUT ausgeben und leitet das per Pipe an OpenSSL weiter, wo man dann -pass stdin benutzen kann (oder man macht es mit einem FIFO und nimmt die fd-Version des Parameters für die Password-Bereitstellung). Damit muß das niemals in irgendeiner Shell-Variablen gespeichert werden - da stört es dann erst recht niemanden (wie gesagt, bei richtiger Handhabung ohnehin nicht), wenn da ein Dollarzeichen im Kennwort steht.

Wie kann man denn ein Passwort eines Zertifikates ändern?

Gar nicht ... das liegt aber nur daran, daß ein Zertifikat (zumindest ein X509-Zertifikat im PEM- oder DER-Format bei OpenSSL) gar nicht verschlüsselt ist. Das wäre ja auch wenig hilfreich ... schließlich wird genau dieses Zertifikat ja praktisch jeder Gegenstelle als "Ausweis" präsentiert und da bringt es nichts, wenn die Gegenstelle das dann nicht lesen könnte. Nur der zum Public-Key im Zertifikat gehörende private Key(-Teil) wird verschlüsselt - leider auch nicht immer, weil mancher Daemon keine passenden Parameter kennt. Dann sollte man für solche Daemons den ungeschützten privaten Schlüssel aber auch nur in einer "read once"-Version bereitstellen ... z.B. wieder in einer Pipe, wo er dann bei Bedarf einmalig gelesen werden kann (und auch nicht unbedingt wiederholt, denn eine Pipe erlaubt i.d.R. kein rückwärts gewandtes seek()).

[fda77]

Wie gesagt,ich dachte die nicht-auf-der-box Warnung wäre von dir

fritzos-cfg-irgendwas

Ja, das ist so ne Sache mit dem irgendwas. Ich hab versucht das auf die neuste Version zu aktualiseren, aber nur noch 1 der ganzen Patches passt... Ich hab eigentlich keine Lust dazu mich in die ganzen Patches hinenzudenken.
Da man das Tool aber immer mit openssl verwendet (crypted backup) sollte nicht nettle der default sein, und die crypto-libs statisch zu compilieren ist mit openssl auch nicht optimal
Vielleicht lad ich wirklich einfach die Binary nach (decodieren wird wohl eh seltenst verwendet)

AVM-Einstellungen besser auch mit AVM-Mitteln sichern

Ich hab keine Ahnung wie das geht. Gäbe es überhaupt Vorteile? So wie es war funktioniert doch

keine Notwendigkeit (wieder einmal), das Kennwort in irgendeiner Shell-Variablen zu speichern

Dann müsste man aber das unverschlüsselte Zertifikat zwischenspechern, und openssl|openssl funktioniert nicht.
Man braucht ja das Passwort einmal aus der alten maca und einmal aus der aktuellen.
Aber da ein $ im Passwort sein kann ist das wohl die einfachste Möglichkeit

Ich warte da lieber auf die Verfilmung

Sry, keine Video-Tuts ^^

z.B. wieder in einer Pipe, wo er dann bei Bedarf einmalig gelesen werden kann (und auch nicht unbedingt wiederholt, denn eine Pipe erlaubt i.d.R. kein rückwärts gewandtes seek()).

Ähh... eine Variable ist da doch einfacher

[PeterPawn]

Ähh... eine Variable ist da doch einfacher

Ähh - nee?

/ # mkdir -p /var/test
/ # cd /var/test
/var/test # httpsdl -O libprivatekeypassword.so -n https://raw.githubusercontent.com/PeterPawn/yf_bin/761344186579a26a7f60791f76f0f938b19b3a44/target/mips/3.10.107/libprivatekeypassword.so
ok
/var/test # httpsdl -O privatekeypassword -n https://raw.githubusercontent.com/PeterPawn/yf_bin/761344186579a26a7f60791f76f0f938b19b3a44/target/mips/3.10.107/privatekeypassword
ok
/var/test # chmod a+x ./privatekeypassword ./libprivatekeypassword.so
/var/test # mkfifo oldpw newpw
/var/test # ./privatekeypassword > oldpw &
/var/test # echo "new password" > newpw &
/var/test # exec 5<oldpw 6<newpw
/var/test # /var/custom/usr/bin/openssl rsa -in /var/flash/websrv_ssl_key.pem -out ./newly_encrypted_key.pem -passin fd:5 -passout fd:6
WARNING: can't open config file: /var/custom_config/ssl/openssl.cnf
writing RSA key
[2]+  Done                       echo "new password" 1>newpw
[1]+  Done                       ./privatekeypassword 1>oldpw
/var/test # ls -l
-rwxr-xr-x    1 root     root         11004 Mar  8 16:46 libprivatekeypassword.so
-rw-r--r--    1 root     root          1675 Mar  8 16:56 newly_encrypted_key.pem
prw-r--r--    1 root     root             0 Mar  8 16:56 newpw
prw-r--r--    1 root     root             0 Mar  8 16:56 oldpw
-rwxr-xr-x    1 root     root          4168 Mar  8 16:46 privatekeypassword
/var/test # cat newly_encrypted_key.pem
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEApdCR5nNsqyZyB9pLoHfR1Gvkny3NaZ7qtGMGCDICg9dWZOD7
[...]
-----END RSA PRIVATE KEY-----
/var/test # /var/custom/usr/bin/openssl rsa -in newly_encrypted_key.pem -passin stdin -noout -text
WARNING: can't open config file: /var/custom_config/ssl/openssl.cnf
<new password>
Private-Key: (2048 bit)
modulus:
    00:a5:d0:91:e6:73:6c:ab:26:72:07:da:4b:a0:77:
[...]
/var/test # exec 5>&- 6>&-
/var/test # rm oldpw newpw
/var/test #

Alles auf einer 7490 - openssl war allerdings in einem gemounteten SquashFS-Image vorhanden (die Warnung hinsichtlich der fehlenden Konfigurationsdatei KÖNNTE man mit einer Dummy-Datei und einem passenden Parameter beim Aufruf auch noch ausblenden), aber privatekeypassword und die Library dazu habe ich auch erst aus dem yf_bin-Repo geladen: https://github.com/PeterPawn/yf_bin/tree/761344186579a26a7f60791f76f0f938b19b3a44/target/mips/3.10.107 - das sind also alles Dinge, die mit dem eigentlichen Problem (von mkfifo bis zum openssl-Aufruf) noch nichts zu tun haben und auch das Anzeigen zur Kontrolle danach und das "Aufräumen" gehört da eigentlich nicht mehr dazu.

Bleiben also am Ende fünf Zeilen übrig, wenn man einen RSA-Key mit einem Kennwort ent- und mit einem anderen wieder verschlüsseln will ... und alles ohne daß irgendetwas bei den Kennwörtern oder beim (entschlüsselten) privaten Key in eine Datei im Filesystem geschrieben wurde (die Pipes/FIFOs schreiben ja nur in den Speicher) - nicht mal ins tmpfs.

Du mußt Dich einfach nur mal "schlaumachen" ... das ist ja keine "rocket science".

[PeterPawn]

BTW ... wenn Du Dich wundern solltest, daß das Format des neu verschlüsselten Keys nicht stimmt, dann gib einfach noch ein -aes128 als Parameter beim openssl-Aufruf mit an. Bei AVM ist der üblicherweise mit AES-128 verschlüsselt (wobei das Eingabeformat meist noch automatisch richtig erkannt wird) und mit dem Parameter wird dann auch die Ausgabe mit AES-128 verschlüsselt, was die zusätzlichen Header-Lines zur Folge hat.

[fda77]

Danke! Hab mit den FDs noch nichts zu tun gehabt, sieht aber einfach aus. Ich hoffe die openssl Version vor/ab 1.1 in Freetz machen bei den Parametern keine Problem. Ich benutze dann aber nicht privatekeypassword sondern das applet, da der decoder für die $$$$ he nötig ist

[PeterPawn]

aber nicht privatekeypassword

Das macht im konkreten Fall ohnehin keinen Sinn, weil das nur die aktuellen Daten der Box verwendet. Das Kennwort der Box, auf der das Backup erstellt wurde, müßte man also ohnehin anders ermitteln.

Irgendwann nehme ich mir auch noch die Zeit und finde heraus, wie der Key für das LE-Zertifikat verschlüsselt ist - wenn's bis dahin noch niemand anderes gemacht haben sollte.

[fda77]

Doch, im (verschlüsselten) Backup ist doch das environement. privatekeypassword akzeptiert als Parameter eine MAC

Also statt

/var/test # ./privatekeypassword > oldpw &
/var/test # echo "new password" > newpw &

/var/test # echo "$MACA" > oldpw &
/var/test # ./privatekeypassword > newpw &

[PeterPawn]

1. Wir reden vermutlich schon wieder aneinander vorbei, denn das privatekeypassword, was ich meine, interessiert sich überhaupt nicht für Parameter: https://github.com/PeterPawn/privatekeypassword/blob/6c50c2166139cf12b12ddb572f4f5353627b4d09/src/privatekeypassword.c#L34

2. So, wie Du das oben mit der MAC-Adresse machen willst, funktioniert das aber auch nicht - außer Dein $MACA soll schon das Kennwort sein und gar nicht die MAC-Adresse (dann ist der Name schlecht gewählt, weil er nicht eindeutig ist). Das Kennwort muß erst noch aus der MAC-Adresse generiert werden ... wie das im Detail funktioniert, kann man im Shell-Skript im privatekeypassword-Repo nachlesen.

[fda77]

Das Script akzeptiert aber ein MAC aus der das Passwort berechnet wird : https://github.com/PeterPawn/privatekeypassword/blob/6c50c2166139cf12b12ddb572f4f5353627b4d09/shell/privatekeypassword.sh#L78

ich ging davon aus das applet kann das auch

[PeterPawn]

Das Applet (im decoder) schon, aber das Programm aus dem privatekeypassword-Projekt nicht (weil auch die Library dahinter keine Parameter kennt).

Du mußt - nebenbei - auch nicht raten, was die Fähigkeiten von decoder angeht ... sowohl das "Hauptprogramm" als auch jedes Applet kennt auch ein --help (bzw. -h) als Option und erzählt dann einiges über sich - wie das bei Linux-Programmen halt üblich ist.

Und das privatekeypassword-Applet akzeptiert - wie die anderen Applets, wo das Sinn macht, auch - tatsächlich eine --alt-env-Option, wo man das gesicherte Environment wieder direkt angeben kann - da braucht man also nicht mal selbst die MAC-Adresse aus der Datei kramen (und man sollte es auch nicht machen - ändert sich das mal, woraus AVM das Kennwort errechnet und ich ändere dann das Applet, wäre die Verwendung der MAC-Adresse (und nur dieser) ggf. erst das Problem).

[PeterPawn]

Ich hab keine Ahnung wie das geht. Gäbe es überhaupt Vorteile? So wie es war funktioniert doch

Ich habe eine Weile mit mir gerungen, ob ich darauf noch eingehen sollte oder nicht ... bringt mir wieder viel Schreibkram (Dir vieles zu lesen) und letztlich interessiert mich persönlich der "mod" (und Backup/Restore gehört ja dazu) auch nicht wirklich.

Aber es ist halt doch so, daß viele ehemalige Freetz-Benutzer nun auf Freetz-NG gewechselt sind und in deren Interesse, will ich noch einmal versuchen, das zu erklären - sowohl, was es für Vorteile bringt, wenn man die bereits vorhandenen Funktionen von AVM nachnutzt, als auch ein paar Anregungen zu geben, WIE man das machen könnte.

Denn es gäbe natürlich Vorteile ... und auch beim "funktioniert doch" sind wir offensichtlich geteilter Meinung. Bisher funktionierte es für eine fremde Box gar nicht und ob es für dieselbe klappt(e), hängt auch sehr stark davon ab, wie alt die gesicherten (AVM-)Einstellungen am Ende tatsächlich waren.

Einerseits kamen bei AVM ja auch Dateien hinzu (die KÖNNEN also in alten Sicherungen gar nicht enthalten sein - und trotzdem gibt es auch immer mal wieder Abhängigkeiten zwischen Konfigurationsdateien bei AVM, z.B. bei der ar7.cfg mit den Benutzerkonten und der vpn.cfg mit den VPN-Verbindungen) und andererseits hat sich bei manchen Konfigurationsdateien auch das Format einigermaßen geändert ... was AVM beim Import dann eben auch gleich korrigiert/korrigieren kann, denn da wird eben die "logische Struktur" so einer (ggf. auch älteren) Konfigurationsdatei eingelesen und dann aus dieser heraus neu gespeichert.

Zumindest kann man das so unterstellen, denn wenn man sich die Inhalte einer Datei bei den "AVM-Secrets" direkt nach dem Import ansieht (also auch noch vor dem Neustart), stellt man fest, daß darin diese verschlüsselten Daten bereits mit einem neuen IV enthalten sind (und somit die Base32-Zeichenkette auch eine andere ist). Aber das war/ist ja ohnehin zu erwarten ... denn die Export-Datei bei AVM ist ja mittlerweile auch mit einem eigenen Kennwort verschlüsselt - also MÜSSEN die Daten ohnehin beim Import wieder ent- und mit dem passenden Key (aus den Geräte-Eigenschaften gebildet) neu verschlüsselt werden. Der Import bei AVM ist also deutlich mehr (und war es schon immer) als das bloße Kopieren von Dateiinhalten ... und dabei erfolgen dann eben bei AVM auch gleich noch die Anpassungen an neue Strukturen, denn natürlich erfolgt die Speicherung der internen Daten dann immer im gerade aktuellen Format.

Und dieses "Zerlegen" der Export-Datei in die einzelnen Bestandteile ermöglichte es AVM dann eben auch, nur den Import einzelner Einstellungen zuzulassen - aber auch das kam tatsächlich erst, nachdem es das Backup in Freetz schon gab. Insofern kann man zwar Freetz keinen "Vorwurf" machen, daß es das nicht genauso unterstützt (für die AVM-Einstellungen - wenn es das tatsächlich auch für die Freetz-Einstellungen könnte (also die "nach Paket" wiederherstellbar wären), wäre das natürlich die "ganz hohe Schule"), aber der AVM-Ex- und -Import hat sich eben auch weiterentwickelt, während das bei Freetz einfach nur bei der ersten Lösung blieb.

Und damit bietet die Freetz-Lösung nun mal deutliche Nachteile gegenüber der von AVM - sie kann nur "alles auf einmal" wiederherstellen, funktioniert(e bisher) nicht auf einer anderen FRITZ!Box (auch nicht desselben Modells, wo der AVM-Import auch noch über Modelle hinweg arbeiten kann) und stellt diese Daten "ohne Kenntnis vom Inhalt" einfach nur als Datei wieder her. Daß auch das nicht wirklich zielführend ist, sieht man schon an der Anrufliste (hatte ich oben schon mal als Argument angedeutet) - deren Wiederherstellung macht wohl nur dann irgendeinen Sinn, wenn das vorhandene Backup erst vor sehr, sehr kurzer Zeit erstellt wurde. Das mag zwar auch vorkommen (mancher macht vor dem Update halt ein Backup), aber es ist auch nicht die einzige denkbare Möglichkeit, von wann so ein Backup-File sein könnte - bei vielen wird es deutlich älter sein und dann taugt der Freetz-Weg einfach nicht für das Wiederherstellen der (AVM-)Einstellungen und der Freetz-Benutzer muß ohnehin mit beiden Sicherungsmöglichkeiten arbeiten. Dann bräuchte man das in Freetz aber praktisch auch gar nicht ... wenn die Lösung in Freetz per se schon schlechter ist, als die von AVM, kann man sich das Kopieren der AVM-Dateien komplett sparen.

Nur ist es eben auch wieder nicht ganz so einfach (wie so vieles im Leben) ... denn es gibt auch noch ein paar Stellen, wo AVM der Ansicht ist, daß man einiges gar nicht sichern braucht/sollte, weil das Wiederherstellen ohnehin keinen Sinn ergäbe (nach der AVM-Philosophie). Bei manchen kann man das nachvollziehen, bei anderen nicht. So enthält das LE-Zertifikat halt bei AVM den MyFRITZ!-Namen und der soll sich bei einer neuen Box ja ohnehin ändern - aber bei einer Wiederherstellung auf derselben Box gibt es erst mal keinen offensichtlichen Grund, warum man da das Zertifikat nicht auch wiederherstellen sollte, solange es noch gültig ist - wenn es schon abgelaufen ist, kann man es immer noch erneuern.

Nebenbei ... ich weiß gerade nicht mehr, wie meine Ergebnisse waren, als ich mal die MyFRITZ!-Anmeldung einer Box auf eine andere verpflanzen wollte - auch das kann Sinn machen (für mich jedenfalls), wenn man dann nach dem Wechsel des Gerätes nicht erst alles auf einen neuen MyFRITZ!-Namen umstellen muß, falls man den tatsächlich irgendwo benutzt. Aber bei den Apps bleibt einem ja gar nichts anderes übrig und die muß man dann auch erst alle wieder - nach einer Wiederherstellung, weil auch die websrv_ssl_key.pem ja nicht gesichert wird und dann hilft es auch nichts, wenn AVM nur den Public-Key pinnt und nicht das Zertifikat - neu anmelden, wobei es nicht immer ohne weiteres möglich ist, die betroffenen Geräte mit den Apps erst mal ins WLAN der Box zu bringen - z.B. wenn eines davon irgendwo in einer anderen Stadt herumschwirrt und nur per VPN zugreift.

Aber zurück zur AVM-Sicherung - da werden halt nur einige Dateien gesichert, die dann aber so gut (dank der Kenntnis der internen Strukturen), daß es beim Wiederherstellen dieser Einstellungen deutlich mehr Komfort durch eine deutlich größere Flexibilität gibt - und wenn man es wie Freetz macht, anstatt die AVM-Möglichkeiten auch im Freetz-Backup zu nutzen, verbaut man (sich und dem Benutzer) den Weg zur Nutzung dieser Flexibilität.

Dabei ist es wirklich simpel, sich eine Sicherungsdatei des FRITZ!OS ausgeben zu lassen (7490 mit Labor 07.24):

~ # mkdir /var/export
~ # cd /var/export
/var/export # tr069fwupdate configexport export_password >avm_export.txt
/var/export # head -n 10 avm_export.txt; echo "..."; tail -n 10 avm_export.txt
Date: Tue, 09 Mar 2021 10:26:40 GMT
Content-type: application/octet-stream;
Content-Disposition: attachment; filename="FRITZ.Box 7490 (UI) 113.07.24-86493LABOR_BETA_09.03.21_1126.export"

**** FRITZ!Box 7490 (UI) CONFIGURATION EXPORT
Password=$$$$HF5SE5UCGVHNFXTBOHRV3EMJ53HOL6PZ5MKDHOBDQ5Q36O4XIA2DSJXQZ1XP2V63BNRAL3LO1C1CCMGNL6H51OG1SIVKBCJO4MUCU5LX
FirmwareVersion=113.07.24
CONFIG_INSTALL_TYPE=mips34_512MB_xilinx_vdsl_dect446_4geth_2ab_isdn_nt_te_pots_2usb_host_wlan11n_27490
OEM=1und1
Country=049
...
NHI3dml2dDlENHYyUG5mclZ2aGswSkZiMFQ0cjZENXBCcUFwbFdsdjkKV0VFZytWWVJrVktOb1VM
c3ZuaXRWS2dMOGhqb3hNQUNmSE4xL0ZON0JEUmc1QkwzZXZaUjFEa1NFM1dsUWVYZAp6MHBJUERO
YU50cE8xUWZTUjdiUXFOUDdvZEtlYTh5clRBPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=";
}


// EOF

**** END OF FILE ****
**** END OF EXPORT 3E31D65F ****
/var/export #

Wie man sieht, ist das genau die Export-Datei von AVM, nur noch mit zusätzlichen HTTP-Header-Zeilen am Beginn, weil die normalerweise an den Browser des Benutzers geht und der dann informiert wird, was er damit machen soll und wie die Datei heißen könnte.

Mit dieser Datei kann man jetzt alles mögliche anfangen ... erstens kann man den Namen aus Content-Disposition verwenden, um sie mit einem "sprechenden" Dateinamen zu versehen - dann kann man sich das mit anderen Dateien (die man in dasselbe Archiv für eine Freetz-Sicherung packen möchte) schon mal klemmen (wenn man wollte).

Zweitens könnte der Freetz-Benutzer diese Datei (zu einem beliebigen späteren Zeitpunkt) aus der Freetz-Sicherungsdatei extrahieren (das 7z für Windows als potentielles Werkzeug dafür hatte ich auch schon erwähnt - und hier dürfte sich dann auch wieder auszahlen, wenn man die Datei nach dem Speichern tatsächlich noch umbenennt (schon im Freetz-Backup), denn die ersten Zeilen müßte/sollte man ja ohnehin auch entfernt haben) und mit ihr über das AVM-GUI alle oder auch wieder nur einzelne Einstellungen wiederherstellen - dafür braucht er nicht länger eine zusätzliche Sicherungsdatei von AVM (und auch nicht die zusätzlichen Arbeitsschritte zum Erstellen einer solchen). Auch das dürfte ein (deutlich erkennbarer) Vorteil sein. Daß man diese Datei jetzt nicht noch einmal zusätzlich verschlüsseln muß (denn sie ist ja bereits mit export_password (als Beispiel, da gehört natürlich das vom Benutzer eingegebene Kennwort hin) verschlüsselt), hatte ich oben auch schon erwähnt.

/var/export # export_name="$(sed -n -e "s|^Content-Disposition: .* filename=\"\(.*\)\"|\1|p" avm_export.txt)"
/var/export # mv avm_export.txt "$export_name"
/var/export # ls -l
-rw-r--r--    1 root     root        387256 Mar  9 11:26 FRITZ.Box 7490 (UI) 113.07.24-86493LABOR_BETA_09.03.21_1126.export
/var/export #

Die Leerzeichen im Dateinamen machen die (manuelle) Handhabung zwar wieder etwas komplexer, aber innerhalb einer Skript-Datei juckt das ja nicht wirklich und wenn man den exakten Namen nicht kennt ... wen juckt das schon? Man kann schließlich (solange man ein "sauberes Verzeichnis" verwendet) auch einfach mit *.export (also mit Shell-Globbing) arbeiten. Beim Abschneiden der HTTP-Header (die braucht es ja nun nicht länger, denn den Namen haben wir schon und der Rest darin ist uninteressant) kann man das dann gleich anwenden - daher würde man den letzten Code und diese Aufgabe vermutlich gleich richtig zusammenfassen:

/var/export # export_name="$(sed -n -e "s|^Content-Disposition: .* filename=\"\(.*\)\"|\1|p" avm_export.txt)"
/var/export # first_line="$(sed -n -e "/^\*\*\*\* FRITZ/=" avm_export.txt)"
/var/export # sed -e "1,$(( first_line - 1 ))d" avm_export.txt > "$export_name"
/var/export # rm avm_export.txt
/var/export # head -n 4 *.export
**** FRITZ!Box 7490 (UI) CONFIGURATION EXPORT
Password=$$$$HF5SE5UCGVHNFXTBOHRV3EMJ53HOL6PZ5MKDHOBDQ5Q36O4XIA2DSJXQZ1XP2V63BNRAL3LO1C1CCMGNL6H51OG1SIVKBCJO4MUCU5LX
FirmwareVersion=113.07.24
CONFIG_INSTALL_TYPE=mips34_512MB_xilinx_vdsl_dect446_4geth_2ab_isdn_nt_te_pots_2usb_host_wlan11n_27490
/var/export # ls -l
-rw-r--r--    1 root     root        387068 Mar  9 11:52 FRITZ.Box 7490 (UI) 113.07.24-86493LABOR_BETA_09.03.21_1126.export
/var/export #

Überzählige Zeilen entfernt, Datei umbenannt -> ab mit einer Kopie in die Datei mit der Freetz-Sicherung. Die kann da - exakt so, wie sie ist - gespeichert werden und braucht keine zusätzliche Verschlüsselung, während sie (solange sie die einzige Datei bleibt, auf die *.export paßt) jederzeit über eine Maske für den Dateinamen im TAR-File zu finden ist.

Aber mit der Datei kann man dann - neben der Kopie im Freetz-Backup - auch noch viel mehr anfangen ... man kann nämlich auch ermitteln, welche Dateien bei AVM gesichert wurden und die kann man beim Kopieren aus /var/flash (ich gehe jetzt mal davon aus, daß das weiterhin stattfindet, weil AVM eben nicht alles selbst sichert) auch gleich ignorieren:

/var/export # sed -n -e "s|^\*\*\*\* .*FILE:\(.*\)|\1|p" *.export
ar7.cfg
wlan.cfg
broadband.cfg
voip.cfg
usb.cfg
tr069.cfg
fx_cg
fx_conf
fx_def
fx_lcr
telefon_misc
phonebook
calllog
dect_misc
fonctrl
dect_eeprom
dmgr_handset_user
config
tamconf
vpn.cfg
user.cfg
userstat.cfg
umts.cfg
configd
ahausr.cfg
aha.cfg
ahadect.cfg
ahanet.cfg
ahaglobal.cfg
ahapushmail.cfg
avmnexus.cfg
/var/export #

Welche Dateien/TFFS-Streams (Unterverzeichnisse lassen wir außen vor) haben wir überhaupt in /var/flash, die auch tatsächlich Daten enthalten (sonst macht die Sicherung ja auch keinen Sinn)?

/var/export # is_empty() { [ "$(cat "$1" | wc -c | sed -n -e "s|^\([0-9]*\).*|\1|p")" -eq 0 ]; }; is_dir() { [ -d "$1" ]; }; for c in /var/flash/*; do is_dir "$c" && continue; is_empty "$c" || printf "%s\n" "$c"; done
/var/flash/aha.cfg
/var/flash/ahadect.cfg
/var/flash/ahanet.cfg
/var/flash/ahapushmail.cfg
/var/flash/ahausr.cfg
/var/flash/ar7.cfg
/var/flash/avmnexus.cfg
/var/flash/broadband.cfg
/var/flash/calllog
/var/flash/configd
/var/flash/dect_eeprom
/var/flash/dmgr_handset_user
/var/flash/ewnwstatus.cfg
/var/flash/fonctrl
/var/flash/fwupdatetrace.cfg
/var/flash/fx_cg
/var/flash/fx_conf
/var/flash/fx_lcr
/var/flash/letsencrypt_cert.pem
/var/flash/letsencrypt_key.pem
/var/flash/phonebook
/var/flash/stat.cfg
/var/flash/tamconf
/var/flash/telefon_misc
/var/flash/tr069.cfg
/var/flash/usb.cfg
/var/flash/usbgsm.cfg
/var/flash/user.cfg
/var/flash/userstat.cfg
/var/flash/voip.cfg
/var/flash/voipd_call_stat
/var/flash/vpn.cfg
/var/flash/websrv_ssl_cert.pem
/var/flash/websrv_ssl_key.pem
/var/flash/wlan.cfg
/var/flash/xdslmode
/var/export #

Diese Liste enthält halt jetzt auch noch die Nodes, die schon bei AVM mit gesichert wurden, die kann man also kürzen (hier mal in einzelnen Zeilen, wie man es in einem Skript ja auch machen würde und nicht alles in einer Shell-Zeile):

/var/export # sed -n -e "s|^\*\*\*\* .*FILE:\(.*\)|/\1/d|p" *.export >remove_saved_files.sed
/var/export # is_empty() { [ "$(cat "$1" | wc -c | sed -n -e "s|^\([0-9]*\).*|\1|p")" -eq 0 ]; }
/var/export # is_dir() { [ -d "$1" ]; }
/var/export # for c in /var/flash/*; do
> is_dir "$c" && continue
> is_empty "$c" || printf "%s\n" "$c"
> done | sed -f remove_saved_files.sed > files_to_save.txt
/var/export # rm remove_saved_files.sed
/var/export # ls -l
-rw-r--r--    1 root     root        387068 Mar  9 11:52 FRITZ.Box 7490 (UI) 113.07.24-86493LABOR_BETA_09.03.21_1126.export
-rw-r--r--    1 root     root           268 Mar  9 12:24 files_to_save.txt
/var/export # cat files_to_save.txt
/var/flash/ewnwstatus.cfg
/var/flash/fwupdatetrace.cfg
/var/flash/letsencrypt_cert.pem
/var/flash/letsencrypt_key.pem
/var/flash/stat.cfg
/var/flash/usbgsm.cfg
/var/flash/voipd_call_stat
/var/flash/websrv_ssl_cert.pem
/var/flash/websrv_ssl_key.pem
/var/flash/xdslmode
/var/export #

Das sind schon mal deutlich weniger Dateien ... und warum sollte man die anderen noch einmal (redundant) sichern? Außerdem erfordern von diesen Dateien eben viele eine "Spezialbehandlung" beim Wiederherstellen ... für die beiden mit den privaten Keys zu den Zertifikaten hatten wir das weiter oben ja schon. Beim Rest weiß ich aus dem Stand jetzt auch nicht immer aus dem Kopf, was drin steht und ob man die einfach so wieder überschreiben kann (oder ob man das überhaupt sollte) ... der große Vorteil dieser (doch eher kurzen) Liste ist es dann eben auch gleich noch, daß man für diese Dateien jeweils eine "Beschreibung" speichern kann (ähnlich wie in diesem Beispiel: https://github.com/PeterPawn/YourFritz/blob/master/tffs/data/tffs.files und die könnte man dann sogar dem Benutzer beim Restore-Versuch mit anzeigen (zusammen mit ein paar Checkboxen) und dann kann er in aller Ruhe selbst entscheiden, welche davon er gerne überschreiben lassen würde und welche nicht.

Das muß nämlich auch nicht in jeder Situation gleich sinnvoll sein ... das LE-Zertifikat (und dessen Key) nutzen mir ja tatsächlich nur dann etwas, wenn ich gleichzeitig dafür sorgen will (und kann), daß sich der MyFRITZ!-Name der Box nicht ändert oder geändert hat (das steht dann alles wieder in der ar7.cfg und wird von AVM auch nicht zwangsläufig 1:1 wiederhergestellt - wie schon geschrieben, erfolgt das bei AVM in Abstimmung über die Inhalte mehrerer Dateien hinweg). Daher kann es bei bestimmten Dateien sogar notwendig werden, daß man neben dem reinen Schreiben des entsprechenden Inhalts (hier geht es natürlich wieder in erster Linie um den Fall, daß es sich nicht um die Box handelt, von der die Sicherungsdatei stammt) auch noch weitere Daten aus der AVM-Sicherung extrahieren und neu in der Box setzen muß - weil das AVM-Restore eben auch nicht alles blind wiederherstellt.

Daher wäre es in meinen Augen ohnehin schlauer, wenn man die Auswahl in Freetz, welche der zusätzlichen AVM-Dateien wiederhergestellt werden sollen, gar nicht am Dateinamen festmacht, sondern an der damit verbundenen Einstellung. Wenn es also machbar sein sollte, den MyFRITZ!-Namen aus einer Sicherung auch auf eine andere Box zu transplantieren, dann sollte die Auswahl beim Freetz-Restore nicht die Dateien letsencrypt_key.pem und letsencrypt_cert.pem anbieten, sondern einfach MyFRITZ!-Namen aus der Sicherung übernehmen und dann reicht es auch nicht aus, einfach nur die beiden Files (bzw. deren alten Inhalt) wiederherzustellen und den Key "umzuschlüsseln" (wobei ich immer noch nicht weiß, welche Komponenten das Kennwort dafür hat), sondern dann muß man auch noch die richtigen Einstellungen für das jason-Konto bei AVM aus der ar7.cfg lesen und über entsprechende ctlmgr_ctl-Aufrufe neu setzen lassen.

Die schon erwähnte "ganz hohe Schule" auch beim Sichern/Wiederherstellen der Freetz-Einstellungen ist aber eigentlich auch kein Problem ... schließlich liegen die Einstellungen ja schon nach Paketen sortiert vor und da einmal die Paketnamen (für eine Liste zur Auswahl durch den Benutzer, der sich natürlich auch für "alle zusammen" entscheiden kann) zu extrahieren und dann beim eigentlichen Speichern der Einstellungen auch noch pro Paket ein modload mit den wiederhergestellten Einstellungen zu machen (wenn das Paket zu denen gehört, für die der Benutzer das auch so wollte), ist jetzt auch kein großes Kunststück ... aber dabei startet dann eben auch gleich das betroffene Paket neu mit den neuen Einstellungen (so sollte es jedenfalls sein) und man muß nicht mehr in jedem Falle danach auch die ganze Box neu starten lassen. Wenn ich nur die Einstellungen meines SSH-Servers wiederherstellen will, brauche ich dabei ja nicht gleich die gesamte Box booten und damit für die anderen Benutzer der FRITZ!Box eine (zeitweise) Unterbrechung der Internet-Verbindung zu verursachen. Wenn es dann immer noch "Problemfälle" gibt, wo ein Neustart der Box unumgänglich wird, kann man das über entsprechende Return-Codes beim "reload" für die Pakete auch steuern und dann kommt man ggf. ums Rebooten tatsächlich nicht herum ... meiner Ansicht nach in deutlich weniger als 10% aller Fälle tatsächlich erforderlich (und das ist schon hochgegriffen).

Was fehlt noch? Vielleicht die Info, daß das tr069fwupdate auch Einstellungen wiederherstellen kann (dann mit configimport, wenn ich mich nicht irre - das demonstriere ich jetzt nicht bzw. das probiere ich jetzt nicht aus) - aber hier wäre es m.E. ohnehin schlauer, wenn man sich das bei AVM noch einmal genau ansieht (unter /usr/www/avm/system/cfgtakeover_edit.lua und den zugehörigen Files) und sich überlegt, ob man das selbst nachmachen will (dann bleibt der Benutzer im Freetz-GUI) oder ob man dafür nicht einfach in einem anderen Browser-Fenster das AVM-GUI (direkt an der richtigen Stelle) aufruft und das dann "einfach machen läßt".

Was ich hier beschrieben habe, ist natürlich gleichzeitig auch eine "Maximallösung" ... nur sollte man sich genau überlegen (wenn man davon Abstriche machen will), welche Auswirkungen die dann haben und ob man die zusätzliche Sicherung der AVM-Dateien dann überhaupt braucht oder das Wiederherstellen dafür nicht - spätestens aber beim Wechsel des Gerätes - verweigern sollte. Nur stellt sich dann wieder die Frage, warum man die AVM-Dateien dann überhaupt mitsichern sollte ... wie geschrieben: Die AVM-Firmware hat an dieser Stelle vieles dazugelernt, seitdem das in Freetz mal so implementiert wurde, wie es heute noch ist - da ist der Zug der Geschichte eben auch über dieses Freetz-Feature gefahren und hat manches dem Erdboden gleichgemacht. Als das in Freetz implementiert wurde, gab es (wenn ich mich richtig erinnere) noch nicht mal die Option bei AVM, daß man seine gesicherten Einstellungen auch auf einem anderen Gerät, geschweige denn auf einem anderen Modell, wiederherstellen konnte.

Wenn der Benutzer ohnehin einmal eine Sicherung in Freetz machen muß und einmal eine mit dem AVM-GUI (von der automatischen Sicherung in der Mail vor einem Update fange ich jetzt gar nicht erst an), dann macht es nur noch sehr begrenzt Sinn, wenn die Freetz-Sicherung die AVM-Einstellungen mit einschließt. Bei den allermeisten Benutzern dürfte es ohnehin so sein, daß die erst einmal mit einer AVM-Firmware auf einer neuen/anderen Box starten und erst nachträglich ein Freetz-Image installieren - da wird dann auch keiner wirklich auf die Idee kommen, die bereits in der AVM-Firmware vorgenommenen Einstellungen jetzt noch einmal durch die (alten) AVM-Einstellungen aus einem Freetz-Backup überschreiben zu lassen.

Mit der Frage, was mit neuen Einstellungen für Freetz-Pakete passiert, die in dem Image, woher die Sicherung stammt, noch gar nicht vorhanden waren, will ich eigentlich auch gar nicht erst anfangen ... aber wenn da bei Restore einfach die komplette /var/flash/freetz überschrieben wird, sind ja - offensichtlich - auch deren Einstellungen hinüber. Damit nutzt auch ein solches Freetz-Backup eigentlich nur in dem (doch eher seltenen) Fall etwas, daß ich unmittelbar nach dem Installieren des Freetz-Images auch sofort die gesamten Einstellungen für alle Pakete wiederherstellen lasse und es obendrein keine größeren Unterschiede/Konflikte zwischen den installierten Paketen des Systems, von dem das Backup stammt und der neuen Box gibt (bzw. es am besten sogar noch dasselbe alte Gerät ist).

Das ist - für mein Empfinden - etwas wenig Komfort im Angesicht dessen, was AVM da mittlerweile "vorgelegt" hat und wenn man das nicht alles selbst machen will (was man vermutlich ohnehin nicht kann), sollte man dem Benutzer halt wenigstens die Option bieten, es auf dem (zweifellos komfortableren und flexibleren) Weg des Herstellers zu machen. Das geht aber nur dann, wenn man es ebenso wie der Hersteller speichert (also die *.export verwendet) oder eben die AVM-Einstellungen komplett außen vor (und in Ruhe) läßt und sich um das kümmert, wovon man selbst eine Ahnung hat ... und das wären bei Freetz eben auch nur die Freetz-Einstellungen und nicht (mehr) die von AVM.

Wofür auch immer man sich am Ende entscheidet ... man sollte sich das VORHER genau überlegen und sich auch über die Konsequenzen jedes Aspektes der eigenen Entscheidung schon VORHER klar sein (oder es werden) - das Implementieren irgendeiner Lösung kann immer erst der nächste Schritt sein, wenn das Ziel bzw. das gewünschte Ergebnis auch tatsächlich bekannt (und allen verständlich, im besten Falle sogar mit anderen ausdiskutiert) ist. Aktionismus der Form "Ich fange einfach mal an." ist zwar denkbar, aber dann muß man auch die (innere) Bereitschaft aufbringen, das alles noch einmal komplett über den Haufen zu werfen, wenn man bemerkt, wo man falsch gelegen hat und darf/sollte sich dann in so einer Situation auch nicht auf die Suche nach faulen Kompromissen (aka "Workarounds") machen, nur weil es schade um die bisher investierte Arbeit wäre. Wenn man so denkt, sollte man eben erst mal einen Plan machen und erst dann Arbeit investieren.

---

So, das reicht jetzt aber auch (wieder mal) ... ich wollte das nur noch einmal ausführlich begründen, warum ich ein "funktionierte doch bisher auch immer" für einen sehr begrenzten Blickwinkel auf das eigentliche Problem halte und zeigen, daß andere Lösungen auch kein Hexenwerk sind/wären. Was Du jetzt daraus machst, bleibt Dir überlassen - ich werde sicherlich Nachfragen auch noch weiterhin beantworten, aber ansonsten widme ich mich dann mal wieder meinen eigenen Projekten, Ideen und Aufgaben ... die sind (teilweise) ja auch dieselben, weil ich natürlich bei YourFritz vor denselben Fragen und Herausforderungen stehe, wenn es darum geht, wo und wie man die eigenen Einstellungen am besten speichert und auch sichert. Ich habe an anderer Stelle mal getestet (ist schon etwas her, sollte man also noch mal wiederholen), daß es die AVM-Sicherung (beim Sichern zumindest) auch nicht juckt, wenn man ihr (a) ein "regular file" anstelle eines "character device" in /var/flash unterjubelt und daß es auch problemlos möglich ist, da Daten unterzubringen, die deutlich größer sind, als das was komprimiert in einen TFFS-Node paßt - dann wird halt auch die Sicherungsdatei deutlich größer.

Aber wenn man die eigenen Einstellungen in einer Datei packt, die bei AVM gar nicht weiter angefaßt wird (die calllog wäre eine solche) und trotzdem in binärer Form in der Sicherungsdatei landet, dann kann man natürlich auch den umgekehrten Weg gehen und anstatt die AVM-Einstellungen in die eigene Sicherungsdatei einzubauen, die eigenen Einstellungen in einem AVM-Backup "verstecken".

Das Einzige, was es dazu braucht, ist wieder ein Wrapper um die CGI-Binaries von AVM (bzw. um das tr069fwupdate), der beim Sichern erst mal dafür sorgt, daß die eigenen Einstellungen zusammengepackt und (bei mir eben als calllog) in eine zu sichernde Datei geschrieben werden und nach dem Restore noch sicherstellt (die calllog wird einfach 1:1 wieder zurückgeschrieben, darf aber natürlich kein TFFS-Node sein zu diesem Zeitpunkt, wenn der gesicherte Inhalt dafür zu groß wäre), daß die gesicherten Einstellungen auch wieder ausgepackt werden - das "Anhängen" an das cfgtakeover_edit von AVM, um auch bei den eigenen Einstellungen eine Auswahl treffen zu können, ist noch Zukunftsmusik, aber geplant.

Aber damit hat man auch wieder nur eine einzige Sicherungsdatei (und braucht gar kein eigenes GUI für Backup/Restore), die sich natürlich auch wieder leichter "verwalten" (sprich: archivieren) läßt, als wenn man mehrere Dateien für unterschiedliche Einstellungen verwenden müßte. Das wäre halt ein anderer Ansatz ... der aber auch für Freetz offenstünde. Und damit bin ich wieder dabei, daß man sich eben erst einmal "einen Plan" machen sollte - da spielt dann der bisherige Weg in Freetz sicherlich auch eine Rolle, deshalb sollte man sich einen kompletten "Umstieg" auf die AVM-Sicherung auch genau überlegen. Aber solange AVM an der Sicherung nichts dreht und weiter die calllog sichert und dabei gar nicht auf die Größe von Dateien schaut, ist das natürlich auch ein sehr bequemer (und sehr sicherer) Weg, AVM die Arbeit zu überlassen und die eigene Kraft/Kreativität für anderes einzusetzen - man muß eben auch nicht alles "nachprogrammieren", wenn es bereits (oder auch erst mittlerweile) existiert.

PS: Ich bin jetzt etwas ermüdet ... sollten oben noch offensichtliche Tippfehler enthalten sein, bleiben die eben einfach mal - auch wenn das sonst nicht meine Art ist.

EDIT: Bevor mir jetzt jemand schreibt, daß man die oben als Beispiel gezeigten Kommandos auch anders anlegen könnte ... das war "aus dem Stegreif" und zur Illustration des Geschriebenen. So kann man z.B. das ziemlich umständliche Entfernen der HTTP-Header natürlich auch machen, ohne zuvor erst die Zeile mit **** FRITZ... zu suchen und dann von der ersten bis zur Zeile vor dieser zu löschen - das wäre mit einem sed -n -e "/^\*\*\*\* FRITZ/,\$p" avm_export.txt genau andersherum, aber mit einer Zeile, etwas eleganter zu lösen.

[fda77]

Ich glaube ich lasse das mit dem dekodieren in Freetz ganz. Man muss ja nichts nachbauen was AVM eh schon kann und dann noch mehr Optionen hat. Und erspart viel Aufwand und Spezialbehandlung von Zertifikaten usw
Solang beim Restore die gleich Box erkannt wird (identitiy), kann man es ja zulassen (wie es war). Ansonsten ist "nur Freetz" Restore erlaubt. Falls eine andere Box erkannt wird kommt dann ein Hinweis auf den export in der .tar.
Beim Backup mache ich dann einfach einen AVM-Export dazu, mit dem gleichen Passwort mit dem Freetz encrypted wird. Wobei mit altem FOS kein Passwort vewrgeben werden konnte bzw später musste. Da könnte man es auch ohne Benutzerpasswort dazumachen.
Weisst du schon wie die "assets" (Telefoniedaten) von 7.25 gesichert werden? Dafür darf man (vermulich noch) kein Passwort vergeben
Gibt es "tr069fwupdate configexport" schon immer? Ich hab leider keine alten geräte mehr um das zu testen
Freetz selektiv zu Restoren wird nichts. Die .diff in tmp/flash/ entsprechen noch dem Packagenamen. Das Verzeichnis in tmp/flash kann aber frei benannt werden, manche Packages speichern auch direkt in tmp/flash zusätzliche Dateien (hab jetzt nicht nachgeschaut)

[fda77]

Mir ist noch aufgefallen dass AVM via Juis meine lokalen Konfiguration ausspäht. Es gibt da zB das Flag "2nd_factor_disabled" ^^ Ich seh nicht die Relevanz die das für ein Update hätte

[fda77]

Man kann übrigens im AVM Webif ein Backup erstellen lassen, auch wenn mit Freetz "tr069fwupdate" entfernt wurde.
Wobei Repeater das neue "Feature" haben, gar keine Backups mehr erstellen zu können... das würde doch dafür sprechen dass Freetz dekodieren kann (546e Beispiel)

[fda77]

Wenn man ein Export ohne Passwort erstellt:

tr069fwupdate configexport >avm_export.txt

Wie kann man die im AVM Webif restoren? Dekodieren mit einer env-Datei funktioniert

[PeterPawn]

Wie kann man die im AVM Webif restoren?

Gar nicht mehr ... dazu müßte man vermutlich direkt firmwarecfg für den Upload aufrufen, wobei ich nicht sagen kann, ob das heute auch noch funktioniert, wenn man es ohne Kennwort aufruft. Ich würde es zwar vermuten, weil ich noch nirgendwo bei AVM gelesen hätte, daß ältere Export-Files nicht mehr importiert werden können ... aber WISSEN ist das nicht.

Daß dann eine Kombination aus maca und SerialNumber genutzt wird zum Verschlüsseln des "eigentlichen Keys" im Header der Export-Datei, steht ja irgendwo im decoder-Projekt in den Erläuterungen - wobei zu den Zeiten, wo ein Export ohne Kennwort auch noch im GUI möglich war, die Seriennummer ohnehin nur aus Nullen bestand bei den existierenden Modellen.

[fda77]

Dann versuch ich mal die maca als Passwort, das sollte dann ja eigentlich funktionieren

[PeterPawn]

Dann versuch ich mal die maca als Passwort, das sollte dann ja eigentlich funktionieren

Denke ich eher nicht ... auch wenn die Seriennummer nur Nullen beinhaltete (das waren ja die Ziffern 0 und keine binären Nullen), wurden die doch mit in den Hash-Wert einbezogen. Ich bin mir auch nicht sicher, ob man die Kombination aus maca und diesen Nullen (16 an der Zahl, wenn ich mich richtig erinnere - das ist aber "aus dem Kopf") an firmwarecfg übergeben kann (wenn, dann ohnehin noch irgendwo mit Newline-Zeichen zwischen den Werten und u.U. auch am Ende - auch das kriegt man aber aus den Skript-Files im decoder-Projekt raus, was da genau von AVM verwendet wird) - wenn das klappt, sollte man es auch so verwenden können, denn das ist ja am Ende bei beiden Kennwort-Varianten (der benutzerspezifizierten und dem "automatischen") dasselbe Hash-Verfahren (MD5), mit dem der Key für die Ver-/Entschlüsselung des eigentlichen Keys im Header der Export-Datei (einmal als Password und einmal als Password2 - auch wieder aus der Erinnerung) gebildet wird. Wenn man da also die Newline-Zeichen in HTML-Kodierung in die form für den Aufruf von firmwarecfg kriegt (bzw. in deren Nachbildung), dann KÖNNTE das funktionieren ... aber eben zusammen mit der Serialnumber und nicht nur mit der maca.

[fda77]

Hab es nicht hinbekommen, kenne mich da nicht so gut aus. Macht aber nichts :) Ich schreib einfach dazu dass man ein Passwort verwenden soll. Da ich ein gemeinsames Passwortfeld für verschlüsselung+export verwenden will hoffe ich dass die meisten eins setzen

[PeterPawn]

Hab es nicht hinbekommen

Ich tippe da auch tatsächlich eher auf einen "handling failure" bei Dir - sollte es über den direkten Aufruf von firmwarecfg tatsächlich nicht mehr gehen, müßte es aber über X_AVM-DE_SetConfigFile() (TR-064, DeviceConfig-Service) trotzdem (noch) funktionieren, zumindest der Beschreibung nach, denn da darf das Kennwort für den Import auch leer sein.

[fda77]

Davon gehe ich auch aus :)
Mir ging es ja mehr darum das Passwort zu finden, das man im AVM-Webif angeben muss (bei neueren FOS), auch wenn man evtl einen Export ohne PW erstellt hat