- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,300
- Punkte für Reaktionen
- 1,761
- Punkte
- 113
EDIT: 01.06.2017
Ich habe eine neue Version in einem GitHub-Repository veröffentlicht, die zwar ein OpenSSL-CLI-Programm benötigt (was praktisch auf jeder Linux-Installation vorhanden sein sollte), aber nicht mehr auf irgendwelche speziellen AVM-Dateien angewiesen ist.
EDIT: 12.05.2016
Es gibt in diesem Thread weiter hinten einen Beitrag, der u.a. auch beschreibt, wie man an das benötigte Programm zum Entschlüsseln der AVM-Kennwörter gelangen kann, wenn man das ältere "webdavcfginfo" (und damit das hier beschriebene "decode_passwords") benutzen möchte. Allerdings steht man dann wieder vor dem Problem, die passende ältere Firmware-Version von AVM zu besorgen.
Generell könnte man meiner Meinung nach die Unterscheidung zwischen der Suche nach einem alten "allcfgconv"-Binary und einer passenden Version von "webdavcfginfo" daran festmachen, ob man es zum einmaligen Gebrauch oder zum wiederholten - auch programmgesteuerten - Zugriff auf verschlüsselte Daten in der FRITZ!Box benötigt. Für den ersten Fall sind die Vorbereitungsarbeiten weniger umfangreich, dafür braucht es "speziellere" Firmware-Versionen, während ansonsten etwas mehr Vorbereitung erforderlich ist, aber die mögliche Auswahl an Firmware-Versionen als Quelle für das AVM-Programm größer ist und nach den einmalig auszuführenden Vorbereitungsarbeiten ist der Aufwand für das Entschlüsseln dann sogar wieder geringer (und vermutlich lizenzrechtlich nicht zu beanstanden) als bei der Variante mit der Extraktion von "allcfgconv".
EDIT: 20.04.2016
Da ich immer noch Zugriffe für diese Datei auf "yourfritz.de" registriere, habe ich den nächsten Teil mal deutlich in abweichender Farbe hervorgehoben ... es gibt auf yourfritz.de nichts mehr zu "decode_passwords" (mit kleinen, aber unbedeutenden Abstrichen), das ist alles nur noch über GitHub zu erreichen.
Auch wenn es aus dem FRITZ!OS heraus m.W. derzeit keine Möglichkeit gibt, Inhalte von dort direkt zu laden (das wget-Applet der AVM-Firmware kennt kein HTTPS und das AVM-eigene httpsdl kommt nach meinen Tests nicht damit klar, daß da mehrfache Redirections erfolgen beim Versuch eines Downloads), ist das bei diesem Programm für mich kein Grund, es noch einmal gesondert (und über eine ungesicherte Verbindung) als Archiv-Datei (tgz) bereitzustellen.
Man kann es problemlos aus dem GitHub-Repo laden und auf einen USB-Stick übertragen, den man dann an die FRITZ!Box steckt (oder man speichert es gleich auf einem Stick an der Box - über NAS-Zugriff) oder man lädt die Textversion von yourfritz.de (und da endet die URL nicht auf einen Slash).
EDIT 11.02.2016:
Das Skript ist von meinem Server umgezogen in Richtung GitHub, es ist jetzt unter https://github.com/PeterPawn/YourFritz/tree/master/decode_passwords zu finden. Als Archiv-Datei gibt es das Skript jetzt gar nicht mehr.
Der neue Download-Link wäre dann
https://github.com/PeterPawn/decode_passwords/blob/v0.1_freeze/decode_passwords
für die bisher als Textform verfügbare Version.
Da die FRITZ!Box keinen direkten Download von dieser URL erlaubt (das wget der Busybox kennt keinen "https"-Präfix und mit dem AVM-Programm "httpsdl" klappt das irgendwie auch nicht so richtig - warum das so ist, will ich jetzt nicht erkunden), werde ich die Textform weiterhin über meinen Server unter der URL http://yourfritz.de/decode_passwords/0.1/decode_passwords zugänglich machen. Die Kommandofolge sieht dann - in ihrer einfachsten Form - also so aus:
Es gibt eine etwas geänderte neue Version, die u.a. der Tatsache Rechnung tragen soll, daß AVM die Funktion von "webdavcfginfo" in Firmware ab 06.25 geändert hat. Die Änderungen gegenüber der Version 0.1 sind in #36 beschrieben, die Version ist ebenfalls über GitHub verfügbar und der Download-Link über den yourfritz.de-Server wäre dann: http://yourfritz.de/decode_passwords/0.2/decode_passwords
-EDIT: Beginnend mit dem Labor-Zweig 06.25 für die 7490 hat AVM das Decodieren der WebDAV-Credentials auf ein anderes Interface umgestellt (Shared-Memory), über Sinn und Unsinn würde ich gerne hier weiter diskutieren. Damit gilt aber: Die hier vorgestellte Lösung funktioniert - vermutlich, noch ist das ja nicht offiziell erschienen - ab der ersten Release-Version nach 06.24 nicht mehr in dieser Form.
Mir ist es auch erst jetzt aufgefallen, daß ich die Verwendung von "decode_passwords" tatsächlich noch nie richtig (meint: an einer einzigen Stelle im IPPF) beschrieben habe.
EDIT: Das Skript ist unter dem Namen "decrypt-fritzos-cfg" ab CS 12914 auch Bestandteil des Freetz-Trunks. Die Bedienung hat sich m.W. nicht verändert, es fällt nur der Download und das Entpacken ggf. weg. Dann noch den Namen entsprechend "substituiert" in einem Freetz-Image und die folgenden Zeilen gelten auch dort.
Das Umbenennen der Version von meinem Server werde ich nicht in Angriff nehmen ... bei einem Nicht-Freetz-Image und dem Download gilt also weiterhin der Name "decode_passwords".
Das Skript selbst kann man auf zwei möglichen Wegen laden (wenn es nicht - s.o. - im eigenen Freetz-Image ohnehin enthalten ist):
- aus dem Freetz-Ticket #2558 unter der URL: http://freetz.org/raw-attachment/ticket/2558/decode_passwords.tar.2.gz (der bessere Weg, aber kein Einzeiler)
-von einem meiner eigenen Server (yourfritz.de) unter der URL: http://yourfritz.de/decode_passwords (gepackt unter http://yourfritz.de/decode_passwords.tgz, keine Unterverzeichnisse im Archiv, nur zwei Shell-Files und 4 Dateien mit Hash-Werten für die beiden) siehe "EDIT" vom 11.02.2016 weiter oben, die URL hat sich geändert
Für das Entschlüsseln der Kennwörter wird ein kleines Tool von AVM namens "webdavcfginfo" verwendet oder auch "mißbraucht", wenn das aus irgendeinem Grund nicht in der Firmware enthalten ist (der "Remove WebDAV"-Patch von Freetz entfernt es z.B. im Moment nochin Freetz geändert inzwischen), wird auch das Skript nicht funktionieren.
Im Kopf der Datei ist ein Block aus Shell-Kommentarzeilen enthalten, der einige Informationen zur Verwendung enthält, das Lesen kann eigentlich nicht schaden.
Download und Entpacken des Skripts aus dem Trac erfolgt dann z.B. mit
Das ganze geht - wenn man nicht lesen will - auch als Einzeiler bei der Benutzung der Version aus Trac:
Bevor ich einige Beispiele für die Verwendung gebe, noch Download/Entpacken/Einzeiler für yourfritz.de:
Das wäre die Version für das gepackte Archiv, es geht natürlich noch kürzer, wenn man gleich das Text-File lädt. Da auch ich nicht vor einem gehackten Server gefeit bin, warne ich jedoch noch einmal mit Nachdruck vor der Ausführung von ungeprüftem Shell-Code auf diese Art und Weise. Die bessere Lösung ist in jedem Fall der Download, die Prüfung und dann eine lokale Speicherung, dann braucht man nur noch Angreifer und Modifikationen im eigenen Netz befürchten und mein Server (oder auch Freetz-Trac) ist aus dem Spiel. Aber ich verstehe auch, daß nicht jeder den Code selbst prüfen will und manchmal wirklich nur die Credentials ausgelesen werden müssen, weil der Brief mit den DSL-Zugangsdaten vom Hund gefressen wurde und man die Daten unbedingt für einen anderen Router benötigt. Selbst da kann aber die Aufteilung des gesamtem Vorgangs in - Download/Auspacken, Internet-Verbindung trennen, Skript aufrufen - eine zusätzliche sinnvolle Vorsichtsmaßnahme sein. Da es sich um Shell-Code handelt und jeder selbst einen Blick hineinwerfen kann, machen die von mir dazu gepackten Dateien mit Hash-Werten für die beiden Shell-Files im Archiv auch nur bedingt Sinn, da ich die nirgendwo für einen Vergleich veröffentlicht habe. So, genug der Warnungen ... wenden wir uns wieder dem "direkten Aufruf aus dem Internet" zu:
EDIT: Dieser direkte Aufruf funktioniert mit der aktuellen Version tatsächlich wieder richtig (s. frühere Probleme ab #3 bis #9) , solange die Datei von yourfritz.de geladen wird (die Trac-Version kann ich nur bedingt beeinflussen), auch die Version in Freetz ist entsprechend angepaßt worden. (Hintergrund der "3" in der Zeile: Es wird nun erst einmal getestet, ob die Eingabe auf dem Filedescriptor 3 "angeboten" wird, bevor das "cat"-Kommando fälschlicherweise den Rest des Skripts in die Zwischendatei kopiert, was unweigerlich stattfindet, wenn die Shell mit "stdin=Skript-Datei" aufgerufen wird und somit nicht erst die Abarbeitung des Skript-Codes diesen Descriptor öffnet, sondern schon die Shell selbst. Unter den Bedingungen der Busybox-Shell ist die Reihenfolge des Öffnens von Files offenbar etwas abweichend gelöst - der "Umweg" über FD 3 (und nur ein zusätzliches Zeichen beim Aufruf 
) löst das Problem auch dann zuverlässig, wenn die direkte Angabe von /proc/self/fd/0 als "Skript-File" beim Aufruf der Shell nicht dazu führt, daß anstelle von stdin die angegebene Datei als Quelle der auszuführenden Kommandos verwendet wird).
Wer das Problem der Entschlüsselung nicht nur spontan hat, sondern damit eigene Sachen schreiben will, der speichert das komplette 'decode_passwords' ohnehin besser irgendwo auf seiner Box (notfalls auf USB, wenn die keinen NAND-Flash hat) und kann es dann auch ohne Internet-Verbindung jederzeit benutzen. Ich habe es auf Boxen ohne NAND sogar ins NOR-Flash geschrieben unter einer unbenutzten Minor-ID (die 97 ist i.d.R. frei, wenn man nicht selbst damit hantiert), allerdings die wirklich schlanke Version, zu der wir später noch kommen.
Den Teil input_file_name muß man in allen oben gezeigten Kommandofolgen dann natürlich durch die zu dekodierende Datei ersetzen, z.B. /var/flash/voip.cfg für die SIP-Accounts.
Oder auch durch eine passende Shell-Maske wie "/var/flash/*.cfg"; wenn man sich nicht daran stört, daß dabei auch eine kleine binäre Datei (aha.cfg) mit verarbeitet wird, sähe das dann z.B. so aus:
Das gibt dann wirklich alle Konfigurationsdateien mit potentiell verschlüsselten Einstellungen in Textform auf der Konsole aus, was i.d.R. eher unpraktisch sein dürfte und z.B. so
auch in einer Datei mit dem Namen "passwords.txt" auf dem ersten gemounteten USB-Volume (oder als /var/passwords.txt, wenn kein USB-Volume vorhanden ist) gespeichert werden kann für eine spätere Durchsicht.
Ab jetzt nehmen wir mal die Speicherung der Shell-Datei an einer Stelle an, wo sie durch bloße Eingabe des Namens gefunden werden kann (als 'decode_passwords') und auch das "ausführbar" als Dateiattribut soll ab jetzt vorhanden sein. Wenn das nicht der Fall ist, muß man sich eben immer den kompletten Pfad zur Datei da hindenken und ggf. den expliziten Aufruf per "sh".
Da das Skript nur den Teil seiner Standardeingabe, der vom Aufbau her einem verschlüsselten Wert bei AVM entspricht, Wert für Wert dekodiert, kann man sich das Leben auch leichter machen (und die Wartezeit bei der Ausführung verkürzen), wenn man gezielt nur die Werte dekodieren läßt, die einen wirklich interessieren. Dafür gibt es bei AVM ja Tools, die gezielt einzelne Einstellungen aus einer Konfigurationsdatei auslesen können. Die dabei erhaltenen verschlüsselten Daten kann man dann einfach einzeln an 'decode_passwords' verfüttern:
entschlüsselt z.B. nur das einzelne E-Mail-Kennwort für den Versand der Push-Nachrichten. Das ist natürlich weniger etwas für die manuelle Ausführung, aber damit läßt sich eigentlich ganz passabel eigener Shell-Code schreiben. Wenn man z.B. wirklich die kompletten Einstellungen zum Mailversand aus der Box benötigt, kann man das - unter anderem, es gibt bei Shell-Code nicht nur eine Wahrheit - so machen:
Das kann man auch für DynDNS-Accounts und eigentlich jedes beliebige Datum in der AVM-Konfiguration ausführen, wenn einen ansonsten die Verschlüsselung davon abhalten würde. Die bei den AVM-Tools vorhandene Aufteilung in ar7cfgconv, wlancfgconv und usbcfgconv interessiert das Skript nicht, man kann ihm jede beliebige Datei auf stdin servieren. Wenn die Datei keine verschlüsselten Daten enthält, wird sie 1:1 wieder ausgegeben.
Was wäre noch zu sagen ... :gruebel:
Es gibt in der Archiv-Datei noch eine zweite Version (micro_decode), die auch im Kopf von 'decode_passwords' noch einmal enthalten ist. Sie stellt die kleinste - bisher(!) - gefundene Variante dar, die einen analogen Ablauf zu 'decode_passwords' realisiert. Was zuerst nur eine Fingerübung und pures Interesse war, wie weit man das treiben könnte, hat sich bei mir inzwischen zu einem ernsthaften Einsatzzweck entwickelt. Wenn eine FRITZ!Box keinen NAND-Flash hat und damit auch kein yaffs2-Filesystem unter /var/media/ftp einbindet, wo man eigene Dateien ablegen kann, kann man 'micro_decode' problemlos im NOR-Flash irgendwo unterbringen, denn es benötigt insgesamt nur 469 Byte. Damit ist es für mich klein genug, wenn man es mit einer Anrufliste mit 400 Einträgen vergleicht. Je nach Modell kann man das Skript auch unter /data (also im AB-Speicher) ablegen ... der Phantasie sind da nur wenige Grenzen gesetzt. Mit etwas Geschick kann man das tatsächlich noch durch ein 'gzip -9' jagen und es so auf 331 Byte verkleinern. Das ist so winzig, daß man u.U. schon Probleme kriegt, es wiederzufinden. Selbst auf einer Box mit NAND-Flash kann die zusätzliche Ablage im TFFS noch Sinn machen, denn anders als der NAND-Inhalt überlebt es dort bei passend gewählter Minor-ID ja auch ein Werksreset.
legt das Skript im TFFS ab und trägt nicht wirklich auf ... und ja, es bleibt bei einem Werksreset erhalten. Braucht man dann mal seine Dienste, läßt es sich mit
leicht wieder aufrufen. Der Aufruf mit '/proc/self/fd/0' sieht vielleicht auf den ersten Blick etwas wild aus, ich kenne aber (bei der Busybox-ash) keinen anderen Weg, einem per Pipe an 'sh' übergegebenen Shell-Skript wieder eine vernünftige Parameterliste zu übergeben und anders als 'decode_passwords', was Eingaben auf seiner Standardeingabe erwartet, macht 'micro_decode' ein 'cat $*' und verarbeitet damit den Inhalt jeder einzelnen Datei (das kann auch eine Liste sein oder das Ergebnis eines Shell-Patterns), die als Parameter angegeben wurde. Wobei ich selbst ohnehin die nicht noch einmal komprimierte Variante verwende und damit dann auch ein "sh /var/97 /var/flash/vpn.cfg" möglich ist, da man auf das zcat verzichten kann.
Ich habe eine neue Version in einem GitHub-Repository veröffentlicht, die zwar ein OpenSSL-CLI-Programm benötigt (was praktisch auf jeder Linux-Installation vorhanden sein sollte), aber nicht mehr auf irgendwelche speziellen AVM-Dateien angewiesen ist.
EDIT: 12.05.2016
Es gibt in diesem Thread weiter hinten einen Beitrag, der u.a. auch beschreibt, wie man an das benötigte Programm zum Entschlüsseln der AVM-Kennwörter gelangen kann, wenn man das ältere "webdavcfginfo" (und damit das hier beschriebene "decode_passwords") benutzen möchte. Allerdings steht man dann wieder vor dem Problem, die passende ältere Firmware-Version von AVM zu besorgen.
Generell könnte man meiner Meinung nach die Unterscheidung zwischen der Suche nach einem alten "allcfgconv"-Binary und einer passenden Version von "webdavcfginfo" daran festmachen, ob man es zum einmaligen Gebrauch oder zum wiederholten - auch programmgesteuerten - Zugriff auf verschlüsselte Daten in der FRITZ!Box benötigt. Für den ersten Fall sind die Vorbereitungsarbeiten weniger umfangreich, dafür braucht es "speziellere" Firmware-Versionen, während ansonsten etwas mehr Vorbereitung erforderlich ist, aber die mögliche Auswahl an Firmware-Versionen als Quelle für das AVM-Programm größer ist und nach den einmalig auszuführenden Vorbereitungsarbeiten ist der Aufwand für das Entschlüsseln dann sogar wieder geringer (und vermutlich lizenzrechtlich nicht zu beanstanden) als bei der Variante mit der Extraktion von "allcfgconv".
EDIT: 20.04.2016
Da ich immer noch Zugriffe für diese Datei auf "yourfritz.de" registriere, habe ich den nächsten Teil mal deutlich in abweichender Farbe hervorgehoben ... es gibt auf yourfritz.de nichts mehr zu "decode_passwords" (mit kleinen, aber unbedeutenden Abstrichen), das ist alles nur noch über GitHub zu erreichen.
Auch wenn es aus dem FRITZ!OS heraus m.W. derzeit keine Möglichkeit gibt, Inhalte von dort direkt zu laden (das wget-Applet der AVM-Firmware kennt kein HTTPS und das AVM-eigene httpsdl kommt nach meinen Tests nicht damit klar, daß da mehrfache Redirections erfolgen beim Versuch eines Downloads), ist das bei diesem Programm für mich kein Grund, es noch einmal gesondert (und über eine ungesicherte Verbindung) als Archiv-Datei (tgz) bereitzustellen.
Man kann es problemlos aus dem GitHub-Repo laden und auf einen USB-Stick übertragen, den man dann an die FRITZ!Box steckt (oder man speichert es gleich auf einem Stick an der Box - über NAS-Zugriff) oder man lädt die Textversion von yourfritz.de (und da endet die URL nicht auf einen Slash).
EDIT 11.02.2016:
Das Skript ist von meinem Server umgezogen in Richtung GitHub, es ist jetzt unter https://github.com/PeterPawn/YourFritz/tree/master/decode_passwords zu finden. Als Archiv-Datei gibt es das Skript jetzt gar nicht mehr.
Der neue Download-Link wäre dann
https://github.com/PeterPawn/decode_passwords/blob/v0.1_freeze/decode_passwords
für die bisher als Textform verfügbare Version.
Da die FRITZ!Box keinen direkten Download von dieser URL erlaubt (das wget der Busybox kennt keinen "https"-Präfix und mit dem AVM-Programm "httpsdl" klappt das irgendwie auch nicht so richtig - warum das so ist, will ich jetzt nicht erkunden), werde ich die Textform weiterhin über meinen Server unter der URL http://yourfritz.de/decode_passwords/0.1/decode_passwords zugänglich machen. Die Kommandofolge sieht dann - in ihrer einfachsten Form - also so aus:
Code:
cd /var
wget -q http://yourfritz.de/decode_passwords/0.1/decode_passwords
sh /var/decode_passwords < /var/flash/vpn.cfg-EDIT: Beginnend mit dem Labor-Zweig 06.25 für die 7490 hat AVM das Decodieren der WebDAV-Credentials auf ein anderes Interface umgestellt (Shared-Memory), über Sinn und Unsinn würde ich gerne hier weiter diskutieren. Damit gilt aber: Die hier vorgestellte Lösung funktioniert - vermutlich, noch ist das ja nicht offiziell erschienen - ab der ersten Release-Version nach 06.24 nicht mehr in dieser Form.
Mir ist es auch erst jetzt aufgefallen, daß ich die Verwendung von "decode_passwords" tatsächlich noch nie richtig (meint: an einer einzigen Stelle im IPPF) beschrieben habe.
EDIT: Das Skript ist unter dem Namen "decrypt-fritzos-cfg" ab CS 12914 auch Bestandteil des Freetz-Trunks. Die Bedienung hat sich m.W. nicht verändert, es fällt nur der Download und das Entpacken ggf. weg. Dann noch den Namen entsprechend "substituiert" in einem Freetz-Image und die folgenden Zeilen gelten auch dort.
Das Umbenennen der Version von meinem Server werde ich nicht in Angriff nehmen ... bei einem Nicht-Freetz-Image und dem Download gilt also weiterhin der Name "decode_passwords".
Das Skript selbst kann man auf zwei möglichen Wegen laden (wenn es nicht - s.o. - im eigenen Freetz-Image ohnehin enthalten ist):
- aus dem Freetz-Ticket #2558 unter der URL: http://freetz.org/raw-attachment/ticket/2558/decode_passwords.tar.2.gz (der bessere Weg, aber kein Einzeiler)
-
Für das Entschlüsseln der Kennwörter wird ein kleines Tool von AVM namens "webdavcfginfo" verwendet oder auch "mißbraucht", wenn das aus irgendeinem Grund nicht in der Firmware enthalten ist (
Im Kopf der Datei ist ein Block aus Shell-Kommentarzeilen enthalten, der einige Informationen zur Verwendung enthält, das Lesen kann eigentlich nicht schaden.
Download und Entpacken des Skripts aus dem Trac erfolgt dann z.B. mit
Code:
[S]
cd /var
wget -qO - http://freetz.org/raw-attachment/ticket/2558/decode_passwords.tar.2.gz | gunzip -c | tar x -C /var
... jetzt kann man sich z.B. das Skript ansehen und es auf potentielle Gefahren prüfen
vi /var/decode_passwords/decode_passwords
... oder es auch ausführen, wenn man es zu eilig hat
sh /var/decode_passwords/decode_passwords < /var/flash/vpn.cfg
... zeigt dann die entschlüsselte Datei mit den VPN-Konfigurationen auf der Konsole an[/S]
Code:
cd /var;wget -qO - http://freetz.org/raw-attachment/ticket/2558/decode_passwords.tar.2.gz | gunzip -c | tar x -C /var;sh decode_passwords/decode_passwords <[B]input_file_name[/B]
Code:
[S]cd /var;wget -qO - http://yourfritz.de/decode_passwords.tgz | gunzip -c | tar x;sh decode_passwords <[B]input_file_name[/B][/S]
Code:
wget -qO - http://yourfritz.de/decode_passwords | sh 3<[B]input_file_name[/B]Wer das Problem der Entschlüsselung nicht nur spontan hat, sondern damit eigene Sachen schreiben will, der speichert das komplette 'decode_passwords' ohnehin besser irgendwo auf seiner Box (notfalls auf USB, wenn die keinen NAND-Flash hat) und kann es dann auch ohne Internet-Verbindung jederzeit benutzen. Ich habe es auf Boxen ohne NAND sogar ins NOR-Flash geschrieben unter einer unbenutzten Minor-ID (die 97 ist i.d.R. frei, wenn man nicht selbst damit hantiert), allerdings die wirklich schlanke Version, zu der wir später noch kommen.
Den Teil input_file_name muß man in allen oben gezeigten Kommandofolgen dann natürlich durch die zu dekodierende Datei ersetzen, z.B. /var/flash/voip.cfg für die SIP-Accounts.
Oder auch durch eine passende Shell-Maske wie "/var/flash/*.cfg"; wenn man sich nicht daran stört, daß dabei auch eine kleine binäre Datei (aha.cfg) mit verarbeitet wird, sähe das dann z.B. so aus:
Code:
cat /var/flash/*.cfg 2>/dev/null | sh /var/decode_passwords/decode_passwords
Code:
cat /var/flash/*.cfg 2>/dev/null | sh /var/decode_passwords/decode_passwords >/var$(sed -n -e 's#^/dev/sd[a-z][0-9] /var\(/media/ftp/[^ ]*\) .*#\1#p' /proc/mounts | sed -n -e '1p')/passwords.txtAb jetzt nehmen wir mal die Speicherung der Shell-Datei an einer Stelle an, wo sie durch bloße Eingabe des Namens gefunden werden kann (als 'decode_passwords') und auch das "ausführbar" als Dateiattribut soll ab jetzt vorhanden sein. Wenn das nicht der Fall ist, muß man sich eben immer den kompletten Pfad zur Datei da hindenken und ggf. den expliziten Aufruf per "sh".
Da das Skript nur den Teil seiner Standardeingabe, der vom Aufbau her einem verschlüsselten Wert bei AVM entspricht, Wert für Wert dekodiert, kann man sich das Leben auch leichter machen (und die Wartezeit bei der Ausführung verkürzen), wenn man gezielt nur die Werte dekodieren läßt, die einen wirklich interessieren. Dafür gibt es bei AVM ja Tools, die gezielt einzelne Einstellungen aus einer Konfigurationsdatei auslesen können. Die dabei erhaltenen verschlüsselten Daten kann man dann einfach einzeln an 'decode_passwords' verfüttern:
Code:
echo "emailnotify.passwd" | ar7cfgctl -s | decode_passwords
Code:
#! /bin/sh
eval $(echo -e "emailnotify.From\nemailnotify.To\nemailnotify.SMTPServer\nemailnotify.accountname\nemailnotify.passwd" | ar7cfgctl -w -s | sed -e 's/^emailnotify.//' -e 's/ = /=/1' | decode_passwords)
# an dieser Stelle stehen jetzt die abgefragten Daten in den Shell-Variablen From, To, SMTPServer, accountname und passwd zur Verfügung
# wir zeigen sie an dieser Stelle nur an, man kann damit aber z.B. auch das AVM-Programm "mailer" in der FRITZ!Box-Firmware aufrufen
echo "From=\"$From\""
echo "To=\"$To\""
echo "Server=\"$SMTPServer\""
echo "Login=\"$accountname\""
echo "Password=\"$passwd\""Was wäre noch zu sagen ... :gruebel:
Es gibt in der Archiv-Datei noch eine zweite Version (micro_decode), die auch im Kopf von 'decode_passwords' noch einmal enthalten ist. Sie stellt die kleinste - bisher(!) - gefundene Variante dar, die einen analogen Ablauf zu 'decode_passwords' realisiert. Was zuerst nur eine Fingerübung und pures Interesse war, wie weit man das treiben könnte, hat sich bei mir inzwischen zu einem ernsthaften Einsatzzweck entwickelt. Wenn eine FRITZ!Box keinen NAND-Flash hat und damit auch kein yaffs2-Filesystem unter /var/media/ftp einbindet, wo man eigene Dateien ablegen kann, kann man 'micro_decode' problemlos im NOR-Flash irgendwo unterbringen, denn es benötigt insgesamt nur 469 Byte. Damit ist es für mich klein genug, wenn man es mit einer Anrufliste mit 400 Einträgen vergleicht. Je nach Modell kann man das Skript auch unter /data (also im AB-Speicher) ablegen ... der Phantasie sind da nur wenige Grenzen gesetzt. Mit etwas Geschick kann man das tatsächlich noch durch ein 'gzip -9' jagen und es so auf 331 Byte verkleinern. Das ist so winzig, daß man u.U. schon Probleme kriegt, es wiederzufinden
. Selbst auf einer Box mit NAND-Flash kann die zusätzliche Ablage im TFFS noch Sinn machen, denn anders als der NAND-Inhalt überlebt es dort bei passend gewählter Minor-ID ja auch ein Werksreset.
Code:
mkconfigfile /var/97 97;gzip -9c </var/micro_decode >/var/97;rm /var/97
Code:
mkconfigfile /var/97 97;zcat /var/97 | sh /proc/self/fd/0 /var/flash/ar7.cfg;rm /var/97
Zuletzt bearbeitet:
