Eine neue Version 0.2 ist jetzt über GitHub (
https://github.com/PeterPawn/decode_passwords/releases) verfügbar, die als Decoder auf das AVM-Binary (oder einen beliebigen anderen eigenen Decoder) über den Symlink "/var/decoder" versucht zuzugreifen. Um auch diese Version von einer "normalen FRITZ!Box" aus laden zu können (das "wget" der Busybox kann keine HTTPS-Verbindungen benutzen und das AVM-Programm "httpsdl" kommt mit GitHub-URLs irgendwie auch nicht klar), habe ich noch einen zusätzlichen Download-Link unter
http://yourfritz.de/decode_passwords/0.2/decode_passwords bereitgestellt. Die Kommandos aus
#1 muß man dann eben entsprechend anpassen.
Indem man auf irgendeinem Weg einen entsprechenden Link einrichtet (wie das bei funktionierendem Shell-Zugriff und bei Vorhandensein einer älteren AVM-Firmware auch vollkommen ohne eine Verletzung der Lizenzbedingungen von AVM geht, beschreibe ich weiter unten), kann man nun mittels "decode_passwords" auch dann noch Konfigurationsdateien entschlüsseln (eigene und - bei Kenntnis von "wlan_key" und "maca" - auch die aus anderen Boxen), wenn AVM inzwischen "webdavcfginfo" so abgeändert hat, daß der Datenaustausch zwischen "davfs2" und den AVM-Komponenten rundherum nur noch über "shared memory" läuft. Für eine "regelmäßige" Benutzung ist allerdings damit nun auch "webdavcfginfo" zu "unhandlich" geworden. Also schafft man sich entweder ein eigenes Programm zum Entschlüsseln an (das Interesse daran - bzw. an einer Diskussion daran, ob man so etwas braucht/machen sollte - hielt sich in sehr überschaubaren Grenzen) oder man muß eben auf ältere AVM-Versionen (irgendwas zwischen 06.10 und 06.25) zurückgreifen, wenn man "decode_passwords" weiterhin nutzen will.
Gegenüber "allcfgconv" hat es (zumindest in meinen Augen) immer noch einige Vorteile, insbesonders weil man es in der Kombination mit "ar7cfgctl" zum Auslesen (und Dekodieren) einzelner Einstellungen benutzen kann. Zwar geht theoretisch auch "der andere Weg" über die komplette Dekodierung mittels "allcfgconv", aber dann wird das (automatische) Parsen einer bestimmten Einstellung aus der so erzeugten Datei wieder komplexer. Liest man hingegen mit "ar7cfgctl" einen solchen Wert erst aus, kann hinterher "allcfgconv" (meines Wissens) damit nichts mehr anfangen.
Ein (ziemlich einfaches) Auslesen von Daten ist so nicht mehr möglich ... ich brauche z.B. regelmäßig das Auslesen der Credentials für die Aktualisierung eines DynDNS-Accounts, was mit dem folgenden "snippet" sehr leicht zu realisieren ist:
Code:
[...]
cfgvar()
{
local n="$1" i p="$2" v
v="$(echo -e "$n" | ar7cfgctl -w 2>/dev/null)"
[ $(expr index "$v" '\$\$\$\$') -gt 0 ] && v="$(echo "$v" | [COLOR="#008000"]decode_passwords[/COLOR])"
if ! test -z "$p"; then
p="${p//\[/\\[}"
p="${p//\"/\\"}"
p="${p//\./\\.}"
p="${p//\$/\\\$}"
v="$(echo "$v" | sed -n -e "s|$p||p")"
fi
echo "$v" | sed -n -e 's|^\([^ ]*\) = \(\".*\"\)|\1=\2|p'
}
eval $(cfgvar "ddns.accounts.username\nddns.accounts.passwd" "ddns.accounts.")
Das ergibt nach dem "eval" dann den Benutzernamen und das Kennwort für den ersten DynDNS-Account aus der ar7.cfg in den Shell-Variablen "username" und "passwd" (die Namen gibt der Einfachheit halber AVM in der ar7.cfg vor) - das muß man mir auf einem anderen Weg erst einmal in ähnlicher "Länge" zeigen ... die "cfgvar()"-Funktion kann man natürlich auch mit anderen Werten nutzen (z.B. den E-Mail-Credentials für die Push-Mails).
-Bleibt also die Frage, wie man sich ohne die Verletzung der AVM-Lizenzbedingungen ein passendes Binary beschafft ... die erwähnten Lizenzbestimmungen verbieten (ob wirksam oder nicht, lassen wir einfach dahingestellt, weil es in diesem Zusammenhang uninteressant ist) das Extrahieren einzelner AVM-Programme aus der Firmware. Das
sollte für das Erzeugen einer temporären Kopie in einem chroot-Jail nicht gelten, da diese (a) nicht dauerhaft gespeichert und (b) bereits nach dem Ende der Abarbeitung von "decode_passwords" wieder gelöscht wird, wenn man so vorgeht, wie ich es vorschlage.
Dazu greift man sich einfach eine ältere Firmware und extrahiert aus dieser das SquashFS-Image mit dem Root-Dateisystem. Diesen Schritt muß man - nach meiner Überzeugung - nur einmal ausführen, da auch die Speicherung einer Kopie des kompletten Root-Dateisystems noch durch die GPL abgedeckt sein sollte. Je nachdem, um was für ein FRITZ!Box-Modell es sich handelt, sind dazu folgende Schritte erforderlich (ich gehe davon aus, daß alle Kommandos direkt auf einer FRITZ!Box ausgeführt werden - wie man den Zugriff auf die Shell erreicht, soll hier mal nicht das Thema sein, das ist anderweitig oft genug durchgekaut):
- (optional) Download einer passenden Firmware ... nachdem AVM selbst ältere Versionen nicht mehr bereitstellt, muß man eben woanders auf die Suche gehen, wenn man selbst kein passendes Archiv hat - für den weiteren Ablauf nehme ich mal die Firmware-Version 06.20 an und die Modelle 7490 (als NAND-Box mit dem Firmware-Image "FRITZ.Box_7490.113.06.20.image") und 7390 (als NOR-Box mit der Firmware "FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.20.image").
-
- Entpacken des AVM-Images
Variante A - NAND-Box mit Firmware < 06.36 (Kernel 2.6.xx)
Code:
# mkdir /var/media/ftp/firmware_06.20
# tar -O -x -f FRITZ.Box_7490.113.06.20.image ./var/tmp/filesystem.image >/var/wrapper.image
# mkdir /var/wrapper
# mount -t squashfs /var/wrapper.image /var/wrapper
# cp -a /var/wrapper/filesystem_core.squashfs /var/media/ftp/firmware_06.20/rootfs.squashfs
# umount /var/wrapper
# rmdir /var/wrapper
# rm /var/wrapper.image
Variante B - NOR-Box (der verwendete Kernel muß das SquashFS-Format der alten Firmware - also SquashFS3 - kennen) ... das ist etwas aufwändiger, weil das Dateisystem und der Kernel in einer einzigen Datei zusammengefaßt sind:
Code:
# mkdir /var/media/ftp/firmware_06.20
# tar -O -x -f FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.20.image ./var/tmp/kernel.image >/var/kernel.image
# b=$(date +%s);f=/var/kernel.image;[COLOR="#FF0000"]i=$(( 0x140000 ))[/COLOR];s=$(stat -c %s $f);while [ $i -lt $s ]; do [ $(testvalue $f 4 $i) -eq [COLOR="#DAA520"]1936814952[/COLOR] ] && printf "\noffset = 0x%08x\n" $i && break;i=$(( i + 4096 ));printf "\r0x%08x of 0x%08x" $i $s;done;printf "duration=%u seconds\n" $(( $(date +%s) - b ));dd if=$f of=/var/media/ftp/firmware_06.20/rootfs.squashfs bs=4096 skip=$(( i / 4096 ));rm /var/kernel.image
[COLOR="#0000CD"]0x00152000 of 0x00ebdb3a
offset = 0x00152000
duration=25 seconds
3435+1 records in
3435+1 records out
14072634 bytes (13.4MB) copied, 4.574045 seconds, 2.9MB/s
[/COLOR]
Das Aufsuchen des Beginns des SquashFS-Images ist sicherlich nicht die schnellste Lösung, dafür funktioniert sie mit den Mitteln, die selbst eine originale AVM-Firmware "onboard" hat ... allerdings muß das tatsächlich alles in einer einzelnen Eingabe erfolgen (copy&paste hilft da sicherlich - der blaue Teil sind dann schon Ausgaben der Kommandos bei der Abarbeitung).
Wenn man die ungefähre Größe des Kernels der eigenen Box besser kennt, kann man durch einen anderen Startwert für "i" (die rote Stelle oben) natürlich auch später in der Datei mit der Suche beginnen.
Der gesuchte Wert 1936814952 ist in hexadezimaler Schreibweise nebenbei bemerkt 0x73717368, was für "sqsh" steht und das ist die Signatur eines SquashFS-Images im BE-Format. Wenn die verwendete FRITZ!Box LE-Speicherung verwendet, muß dieser Wert auf 0x68737173 geändert werden, was in dezimaler Schreibweise dann 1752396147 wäre - wobei meines Wissens bisher(!) keine LE-Modelle mit einer Firmware > 06.25 ausgerüstet werden können (mal vom ATOM-Core einer 6490 abgesehen - welche Endianess die 4080 (und die 4020?) verwendet, weiß ich allerdings auch nicht und auch die 5490 ist m.W. von den "Innereien" her noch ein großes Fragezeichen).
Anschließend wird dann einfach das SquashFS-Image aus der Kernel-Datei in das Zielverzeichnis kopiert und die extrahierte "Gesamtdatei" gelöscht.
Wenn das verwendete Modell keinen NAND-Flash unter /var/media/ftp bereitstellt (also keine 7390 ist), kann man natürlich stattdessen auch ein Verzeichnis auf einem USB-Stick benutzen ... wenn der ein Linux-Dateisystem hat, schadet das sicherlich nicht, es ist aber keine Bedingung.
Variante C - NAND-Box mit neuerem Kernel, der das alte SquashFS-Format nicht mehr kennt ... hier brauchen wir dann eine Version von "unsquashfs", die das alte Dateiformat unterstützt (z.B. aus dem "modfs"-Paket) und ein "mksquashfs" für das neue Format; wir packen uns das Root-Dateisystem ganz einfach um auf das aktuellere Format (braucht etwas Zeit). Dabei müssen wir aber auch den nicht allzu üppigen Hauptspeicher im Hinterkopf behalten, daher sollten die Zwischenergebnisse nicht im tmpfs abgelegt werden ... wir brauchen also genug freien Speicher in der NAND-Partition unter /var/media/ftp oder einen USB-Stick mit einem Linux-Dateisystem.
Code:
# mkdir /var/media/ftp/firmware_06.20
# tar -O -x -f FRITZ.Box_7490.113.06.20.image ./var/tmp/filesystem.image >/var/wrapper.image
# unsquashfs3 -d /var/wrapper /var/wrapper.image /filesystem_core.squashfs
[COLOR="#0000CD"]Filesystem on /var/wrapper.image is ZLIB compressed (3:0)
Parallel unsquashfs: Using 2 processors
1 inodes (336 blocks) to write
[====================================\] 336/336 100%
created 1 files
created 1 directories
created 0 symlinks
created 0 devices
created 0 fifos[/COLOR]
# rm /var/wrapper.image
Hier stehen wir jetzt am Scheideweg und müssen uns zusammenreißen, daß wir den sauberen Weg nehmen und nicht einfach mittels
Code:
# unsquashfs3 -d /var/rootfs /var/wrapper/filesystem_core.squashfs /bin/webdavcfginfo
# mv /var/rootfs/bin/webdavcfginfo /var/media/ftp/firmware_06.20/decoder
# rm -r /var/rootfs /var/wrapper
das benötigte Programm aus dem Image kopieren, denn das wäre zwar eine Abkürzung, aber auch genau der bereits erwähnte Verstoß gegen die AVM-Lizenzbestimmungen.
Das ist aber nicht notwendig, denn wir können ja einfach wieder das gesamte Root-Dateisystem in einem Format zusammenpacken (wenn wir es nicht gleich in der ausgepackten Form - auch dabei sind ja keine einzelnen AVM-Programme vom Rest der Firmware getrennt - weiter verwenden wollen, weil es schade um den vergeudeten Platz ist ... immerhin sind es bei einer 7490 ca. 56 MB, die das Root-Dateisystem auf die Waage bringt), welches unser neuer Kernel dann auch wieder mounten kann.
Code:
# unsquashfs3 -d /var/media/ftp/repackfs /var/wrapper/filesystem_core.squashfs
[COLOR="#0000CD"]Filesystem on /var/wrapper/filesystem_core.squashfs is ZLIB compressed (3:0)
Parallel unsquashfs: Using 2 processors
3770 inodes (4278 blocks) to write
[====================================\] 4278/4278 100%
created 3175 files
created 219 directories
created 509 symlinks
created 86 devices
created 0 fifos[/COLOR]
# mksquashfs4 /var/media/ftp/repackfs /var/media/ftp/firmware_06.20/rootfs.squashfs
[COLOR="#0000CD"]Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on /var/media/ftp/firmware_06.20/rootfs.squashfs, block size 65536.
[============================================================================\] 3683/3683 100%
Exportable Squashfs 4.0 filesystem, xz compressed, data block size 65536
compressed data, compressed metadata, compressed fragments, no xattrs
duplicates are removed
Filesystem size 18464.95 Kbytes (18.03 Mbytes)
33.12% of uncompressed filesystem size (55749.34 Kbytes)
Inode table size 31418 bytes (30.68 Kbytes)
23.27% of uncompressed inode table size (134998 bytes)
Directory table size 37300 bytes (36.43 Kbytes)
40.04% of uncompressed directory table size (93150 bytes)
Number of duplicate files found 1357
Number of inodes 3989
Number of files 3175
Number of fragments 244
Number of symbolic links 509
Number of device nodes 86
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 219
Number of ids (unique uids + gids) 1
Number of uids 1
root (0)
Number of gids 1
root (0)[/COLOR]
# rm -r /var/wrapper /var/media/ftp/repackfs
Das Packen mit "mksquashfs4" dauert zwar ein wenig (ca. 5 Minuten auf einer 7490), aber das gute Gefühl auch in Zukunft die AVM-Lizenzbedingungen einzuhalten, entschädigt uns dafür.
Jetzt haben wir jedenfalls bei allen Varianten irgendwo (im Beispiel unter /var/media/ftp/firmware_06.20/rootfs.squashfs) ein Image liegen, das vom aktiven System gemountet werden kann und die Kommandos von diesem Punkt an, wären nach jedem Neustart der FRITZ!Box vor der Verwendung von "decode_passwords" auszuführen.
-
- Mounten des Dateisystems unter irgendeinem Pfad in der Box
Code:
# mkdir /var/firmware_06.20
# mount /var/media/ftp/firmware_06.20/rootfs.squashfs /var/firmware_06.20
-
- Verlinken des im neu gemounteten Dateisystem enthaltenen "webdavcfginfo"-Binaries unter dem Namen "/var/decoder"
Code:
# ln -s /var/firmware_06.20/bin/webdavcfginfo /var/decoder
-Nun kann man das "decode_passwords"-Skript verwenden, als hätte das System selbst weiterhin eine passende "webdavcfginfo"-Version.
