- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,341
- Punkte für Reaktionen
- 1,777
- Punkte
- 113
EDIT 11.02.2020:
Achtung: Die Struktur im Repo hat sich etwas geändert (schon im Okt. 2018) und damit sieht das Kommando zum Auschecken aus GitHub jetzt anders aus und die bereitgestellten Binaries haben andere Namen und eine zusätzliche Verzeichnisebene (die Ausgabe von "uname -m" für die Plattform) ist ebenfalls vorhanden: https://www.ip-phone-forum.de/threads/fritz-box-7580-firmware-153-06-90-telnet-service-freischalten-geht-auch-für-7560-und-7590.296678/post-2301475
Der Verweis auf die späteren Änderungen sollte einen aber nicht vom Lesen des Restes in diesem Beitrag abhalten, denn an der oben verlinkten Stelle stehen nur neue Kommandos und keine ausführliche Erklärung.
=================================================================
Weil es immer wieder Fragen in dieser Richtung gibt, will ich noch einmal (in der von mir gewohnten Kürze) erklären, wie man mit max. 10 Minuten investierter Arbeitszeit auch in der heute neu veröffentlichten AVM-Firmware zu einem Shell-Zugang über einen Telnet-Service gelangt.
Alle zusätzlichen Ausführungen, warum das (auf Dauer) eine schlechte Idee und Lösung ist, hierfür gerade einen Telnet-Service zu verwenden, spare ich mir an dieser Stelle ... es ist und bleibt ein Provisorium, was man im eigenen Interesse nicht überbeanspruchen sollte und was man max. für einen etwas tieferen Einblick in die Firmware verwenden sollte.
Was brauchen wir dafür?
Die folgenden Zeilen zeigen die Konsole des verwendeten Linux-Systems ... die fehlenden BBCode-Möglichkeiten im Xenforo verhindern leider, daß man die einzugebenden Kommandos und die Ausgaben des Systems irgendwo farblich kennzeichnet - dafür kann ich nichts.
Das wäre schon mal erledigt ... als Nächstes klonen wir uns das YourFritz-Repository in unser Arbeitsverzeichnis und - weil ich die Binaries in einem gesonderten Branch habe - schalten auf den richtigen Zweig um:
Damit haben wir die "externen Zutaten" nun schon beisammen ... die oben angezeigten Dateien wären an dieser Stelle jetzt mittels "gpg" o.ä. auf Authentizität zu prüfen, der öffentliche Schlüssel (PeterPawn.asc) steht im Repository bzw. auf keys.gnupg.net (KeyID 0x30311D96).
Wir müssen jetzt aus der AVM-Firmware die Dateien "kernel.image" und "filesystem.image" extrahieren und den Kernel am Ende etwas "stutzen", weil da noch eine - hier nicht benötigte - Prüfsumme dahinterhängt. Die "filesystem.image" entpacken wir dann gleich im Anschluß und erstellen in dieser Struktur den fehlenden Symlink, dessen Fehlen am Ende den Start des Telnet-Daemons in der AVM-Firmware verhindert. Anschließend packen wir das Dateisystem einfach wieder ein.
Wir haben jetzt einen passenden Kernel und ein vernünftiges Dateisystem, die kopieren wir nun einfach hintereinander und erhalten damit ein Image, welches wir in den Hauptspeicher der 7580 laden können und das sich dann von dort aus selbst in den Flash-Speicher schreibt (in die aktive Partition, wenn wir keine Vorkehrungen treffen).
Da wir für das Arbeiten mit dem Bootloader die Skripte aus "eva_tools" benutzen werden, erstellen wir das eigene Image gleich in diesem Verzeichnis, das erspart uns später die Angabe von zusätzlichen Verzeichnisebenen.
Bis hierher haben wir noch keine fertigen Skript-Dateien benutzt und daher macht es auch keinen Unterschied, ob auf dem verwendeten System der Symlink "/bin/sh" nun auf eine "dash" oder eine "bash" oder was auch immer zeigt ... das wird jetzt anders. Die Skript-Dateien in "eva_tools" funktionieren entweder mit der "ash" der BusyBox oder mit einer "richtigen", ausgewachsenen "bash" als Shell. Wenn auf dem verwendeten System der Symlink also auf eine "dash" zeigt, ist entweder diese Standard-Shell zu ändern oder die erste Zeile in den Skripten in "eva_tools" (der sogenannte "She-Bang") ist entsprechend anzupassen. Wir gehen mal den Weg des geringeren Widerstands und ändern die Skripte, bevor wir sie verwenden.
Damit wir später nicht in Zeitnot geraten (EVA läßt uns ja nur 5-10 Sekunden Zeit für den Aufbau der FTP-Verbindung), müssen wir jetzt entscheiden, ob wir die aktive Partition überschreiben wollen oder ob wir zuvor lieber auf die inaktive Partition umschalten wollen, die damit natürlich die aktive wird. Unser Image schreibt sich halt immer in die zum Zeitpunkt seines Starts als aktiv markierte Partition ... wir müssen das also bereits vorher regeln.
Um es besser auseinanderhalten zu können, verpacken wir den zusätzlich notwendigen Schritt bei der Umschaltung in einen komplett eigenen Anlauf für den Bootloader. Wer in die aktive Partition installieren will, kann diesen Schritt dann komplett überspringen.
Für die Benutzung der Skripte für den Bootloader brauchen wir noch ein paar Informationen über das Netzwerk unseres Linux-Systems ... erstens den Namen des Interfaces, an dem unsere FRITZ!Box nunmehr mit einem Ethernet-Kabel angeschlossen ist (am besten noch über einen Switch, das spart viele Probleme, die hier ebenfalls nicht behandelt werden sollen) und die auf diesem Interface verwendete IP-Adresse samt Maske. Aus der eigenen Adresse basteln wir uns dann die "Wunschadresse" für die FRITZ!Box, diese muß nur in unserem eigenen Segment liegen und darf natürlich von keinem anderen System verwendet werden. Der Einfachheit halber ist unser Interface hier "eth0" und die eigene IP-Adresse die 192.168.178.254 ... damit können wir der FRITZ!Box die 192.168.178.1 "zuweisen", das ist auch gleichzeitig deren Standardadresse.
Die Umschaltung auf das andere System in der inaktiven Partition (egal, ob da schon eines ist oder welche Version das hat) erfolgt einfach mit dem folgenden Aufruf:
Nachdem das Kommando gestartet wurde, muß die FRITZ!Box einmal kurz stromlos gemacht werden und dann neu starten. Bei der 7580 funktioniert der Zugriff auf den Bootloader nach einem "Soft Reboot" offenbar nicht mehr ... ein Sicherheitsgewinn, wenn das absichtliches Verhalten ist und nicht nur eine Fehlfunktion, weil der interne Switch der FRITZ!Box nicht richtig initialisiert wird. Wird die Box dann irgendwann gefunden (die GRX5-Modelle brauchen wesentlich länger bereits in der Initialisierung des Bootloaders, das können schon mal 15 Sekunden oder so sein), wird auf das andere System umgeschaltet und die Box neu gestartet. Den Start können wir dann natürlich gleich durch das Ziehen des Netzsteckers wieder abbrechen ... uns kam es ja nur auf die Umschaltung an.
Im nächsten Anlauf lassen wir jetzt die Box noch einmal beim Start im Netzwerk suchen und wenn sie dann gefunden wurde, laden wir das eigene Image in den Hauptspeicher und lassen die Box mit diesem Image starten (das erfolgt implizit nach erfolgreichem Laden). In der Konsole sieht das dann so aus:
Jetzt ist es aber wichtig, daß man nicht der FRITZ!Box sofort wieder den Stecker zieht ... nun gilt es die LEDs zu beobachten. Wenn sich das System in den Flash schreibt, blinkt die INFO-LED in einem relativ hektischen Modus und danach startet dann die gesamte Box noch einmal neu (das charakteristische kurze Aufflackern aller LEDs).
Wenn alles glatt gegangen ist, startet nun eine Version 06.90 mit der Möglichkeit, den Telnet-Service über ein angeschlossenes Telefon (oder auch über die Wählhilfe, wie das dann geht, steht wieder in anderen Threads) mit der Tastenkombination #96*7* zu aktivieren. Dabei darf man sich nicht davon verwirren lassen, daß da kein Quittungstext mehr angezeigt wird, wie das früher einmal der Fall war ... und es ist auch nur einmal pro Bootvorgang möglich, den Telnet-Service neu zu aktivieren. Aber diese Aktivierung wird in der "fx_conf" abgespeichert und sollte da beim nächsten Systemstart das Telnet-Flag den richtigen Wert haben, wird auch der Telnet-Service vom "telefon"-Daemon automatisch gestartet. Man braucht diese Aktivierung also nur ein einziges Mal vorzunehmen, wenn man den Service nicht wieder deaktiviert hat.
Benutzen kann man den dann ganz einfach mit einem Telnet-Client:
Die Anmeldung braucht dann - je nach eingestellter Kontenprüfung in der AVM-Firmware - entsprechende Credentials ... das geht von "gar nichts" bis zum Benutzernamen und dem richtigen Kennwort. Da dabei auch das AVM-Programm "ar7login" für die Prüfung der Credentials verwendet wird, setzt das natürlich die "Vom Hersteller nicht unterstützte Änderungen"-Kennzeichnung ... wie man die wieder wegbekommt (auch ohne Recovery), steht auch wieder in anderen Threads hier.
Um das verwendete Linux-System wieder aufzuräumen, reicht das rekursive Löschen des eigens eingerichteten Arbeitsverzeichnisses ("/tmp/yourfritz") aus.
Hat man das erst ein- oder zweimal gemacht, dauert das auch nur noch um die fünf Minuten ... am meisten Zeit nimmt immer noch das Packen des Dateisystem-Images in Anspruch - da hilft ein schnellerer Rechner mit etwas Hauptspeicher am ehesten.
Es ist also eigentlich ziemlicher Quatsch zu behaupten, AVM würde dem Kunden hier tatsächlich irgendwelche Steine in den Weg legen ... zumindest derzeit kann ich da keine erkennen. Es ist nicht mehr ganz so simpel wie früher, aber so ein eigenes Firmware-Image ist keine "rocket science" und der eigenen Phantasie, was man da noch so "von Hand" einbauen könnte, sind auch kaum Grenzen gesetzt ... jedenfalls solange man die eigenen Fähigkeiten richtig einschätzen kann und keine Änderungen vornimmt am AVM-Code, die dann die Box nicht mehr richtig starten oder arbeiten lassen.
Im Prinzip gilt das geschilderte Vorgehen auch für jedes Freetz-Image, wenn die Box das erste Mal mit einem "fremden" Image in Kontakt kommt ... die dort erzeugte "in-memory"-Image ist am Ende auch nichts anderes als ein Kernel und ein Dateisystem in einem, was in die Box geladen werden kann und sich dann dort (ebenfalls in die aktive Partition, weil das Skript dazu von AVM stammt und von Freetz nicht geändert wird) selbst installiert.
Es ist also genauso blödsinnig, erst ein Downgrade auf irgendeine alte Firmware zu machen, die noch unsignierte Images unterstützt, wenn man nur ein eigenes Image installieren will ... das geht über den Bootloader (auch bei VR9-NAND-Boxen) deutlich einfacher und bei den GRX5-Modellen gibt es solche alten Images ja ohnehin nicht.
Achtung: Die Struktur im Repo hat sich etwas geändert (schon im Okt. 2018) und damit sieht das Kommando zum Auschecken aus GitHub jetzt anders aus und die bereitgestellten Binaries haben andere Namen und eine zusätzliche Verzeichnisebene (die Ausgabe von "uname -m" für die Plattform) ist ebenfalls vorhanden: https://www.ip-phone-forum.de/threads/fritz-box-7580-firmware-153-06-90-telnet-service-freischalten-geht-auch-für-7560-und-7590.296678/post-2301475
Der Verweis auf die späteren Änderungen sollte einen aber nicht vom Lesen des Restes in diesem Beitrag abhalten, denn an der oben verlinkten Stelle stehen nur neue Kommandos und keine ausführliche Erklärung.
=================================================================
Weil es immer wieder Fragen in dieser Richtung gibt, will ich noch einmal (in der von mir gewohnten Kürze) erklären, wie man mit max. 10 Minuten investierter Arbeitszeit auch in der heute neu veröffentlichten AVM-Firmware zu einem Shell-Zugang über einen Telnet-Service gelangt.
Alle zusätzlichen Ausführungen, warum das (auf Dauer) eine schlechte Idee und Lösung ist, hierfür gerade einen Telnet-Service zu verwenden, spare ich mir an dieser Stelle ... es ist und bleibt ein Provisorium, was man im eigenen Interesse nicht überbeanspruchen sollte und was man max. für einen etwas tieferen Einblick in die Firmware verwenden sollte.
Was brauchen wir dafür?
- ein Linux-System mit einer halbwegs sinnvollen Shell - die "dash" ist hier eher ungeeignet, besser nimmt man eine "bash" oder - auf Systemen mit einer BusyBox - auch die "ash" aus deren Angebot (wobei prinzipiell auch die "dash" natürlich reichen würde, aber als interaktive Shell ist sie "unterentwickelt")
- ein originales Firmware-Image von AVM, für die 7580 finden wir das hier: http://ftp.avm.de/fritz.box/fritzbox.7580/firmware/deutsch/FRITZ.Box_7580.153.06.90.image
- zwei Programme aus den "squashfs-tools" in Version 4.3, mit den passenden Patches, damit diese auch das AVM-Format verarbeiten können - die notwendigen Patches sind inzwischen in das Freetz-Projekt eingeflossen und man könnte dort die notwendigen Programme mit einem "make host-tools" bauen lassen ... andererseits habe ich die Binaries für ein x86-basiertes Linuxsystem in meinem YourFritz-Repository hinterlegt und die kann man (mit entsprechender Vorsicht und nach Prüfung der Signatur - wie das geht, ist aber nicht Thema dieses Beitrags) auch direkt verwenden; wie das Klonen eines Repositories mittels "git" funktioniert, kommt nachher im Text
- ja ... und wir brauchen halt auch "git", wenn wir mit dem YourFritz-Repository auf github.com arbeiten wollen; spätestens bei der Übertragung des Images auf die Box brauchen wir dann ohnehin die dort liegenden "eva_tools"
- für das Suchen der FRITZ!Box im Netzwerk brauchen wir dann für die Skripte in "eva_tools" auch noch das Programm "socat", das sich garantiert irgendwo in einem Paket-Repository für das verwendete Linux-System finden läßt und vorher installiert werden muß
- und last, but not least ... wir brauchen noch das Programm "netcat" in der "openbsd"-Ausführung (Paket "netcat-openbsd" unter Debian), um später mit dem FTP-Server im Bootloader zu kommunizieren
- das verwendete Linux-System muß die C-Library auch für 32-Bit-Software bereitstellen, ebenso eine "libz.so" in einer 32-Bit-Version, sofern es ein x86_64-System ist - das YourFritz-Repository enthält ohnehin nur die Binärdateien für x86 und MIPS32 zur Zeit ... das könnte sich in der Zukunft ändern; die MIPS-Binaries für "unsquashfs" und "mksquashfs4" sind aber wirklich statisch gelinkt und brauchen keine weiteren Dateien - zur Verwendung mit 64-Bit-Systemen siehe auch hier: https://www.ip-phone-forum.de/threads/fritzbox-7560-fritz-os-6-90-telnet-shell-zugriff.296795/
Die folgenden Zeilen zeigen die Konsole des verwendeten Linux-Systems ... die fehlenden BBCode-Möglichkeiten im Xenforo verhindern leider, daß man die einzugebenden Kommandos und die Ausgaben des Systems irgendwo farblich kennzeichnet - dafür kann ich nichts.
Code:
peh@yourfritz:~$ mkdir /tmp/yourfritz
peh@yourfritz:~$ cd /tmp/yourfritz
peh@yourfritz:/tmp/yourfritz$ wget http://ftp.avm.de/fritz.box/fritzbox.7580/firmware/deutsch/FRITZ.Box_7580.153.06.90.image
--2017-09-06 02:49:31-- http://ftp.avm.de/fritz.box/fritzbox.7580/firmware/deutsch/FRITZ.Box_7580.153.06.90.image
Resolving ftp.avm.de (ftp.avm.de)... 212.42.244.7, 194.109.20.244, 212.42.224.71, ...
Connecting to ftp.avm.de (ftp.avm.de)|212.42.244.7|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 25384960 (24M) [application/octet-stream]
Saving to: ‘FRITZ.Box_7580.153.06.90.image’
100%[=======================================>] 25,384,960 9.91MB/s in 2.4s
2017-09-06 02:49:34 (9.91 MB/s) - ‘FRITZ.Box_7580.153.06.90.image’ saved [25384960/25384960]
peh@yourfritz:/tmp/yourfritz$
Code:
peh@yourfritz:/tmp/yourfritz$ git clone https://github.com/PeterPawn/YourFritz.git yf
Cloning into 'yf'...
remote: Counting objects: 2113, done.
remote: Compressing objects: 100% (52/52), done.
remote: Total 2113 (delta 17), reused 58 (delta 12), pack-reused 2049
Receiving objects: 100% (2113/2113), 12.67 MiB | 5.80 MiB/s, done.
Resolving deltas: 100% (1317/1317), done.
Checking connectivity... done.
peh@yourfritz:/tmp/yourfritz$ cd yf
peh@yourfritz:/tmp/yourfritz/yf$ git checkout binaries
Branch binaries set up to track remote branch binaries from origin.
Switched to a new branch 'binaries'
peh@yourfritz:/tmp/yourfritz/yf$ ls -ln bin/x86
total 484
-rwxr-xr-x 1 1000 1000 278076 Sep 6 02:53 mksquashfs4-avm
-rw-r--r-- 1 1000 1000 543 Sep 6 02:53 mksquashfs4-avm.sig
-rwxr-xr-x 1 1000 1000 207772 Sep 6 02:53 unsquashfs
-rw-r--r-- 1 1000 1000 543 Sep 6 02:53 unsquashfs.sig
peh@yourfritz:/tmp/yourfritz/yf$ cd ..
peh@yourfritz:/tmp/yourfritz$Wir müssen jetzt aus der AVM-Firmware die Dateien "kernel.image" und "filesystem.image" extrahieren und den Kernel am Ende etwas "stutzen", weil da noch eine - hier nicht benötigte - Prüfsumme dahinterhängt. Die "filesystem.image" entpacken wir dann gleich im Anschluß und erstellen in dieser Struktur den fehlenden Symlink, dessen Fehlen am Ende den Start des Telnet-Daemons in der AVM-Firmware verhindert. Anschließend packen wir das Dateisystem einfach wieder ein.
Code:
peh@yourfritz:/tmp/yourfritz$ tar -x -f FRITZ.Box_7580.153.06.90.image -O ./var/tmp/filesystem.image >filesystem.image
peh@yourfritz:/tmp/yourfritz$ tar -x -f FRITZ.Box_7580.153.06.90.image -O ./var/tmp/kernel.image >kernel.image
peh@yourfritz:/tmp/yourfritz$ ls -ln
total 48992
-rw-r--r-- 1 1000 1000 20701192 Sep 6 03:04 filesystem.image
-rw-r--r-- 1 1000 1000 25384960 Sep 5 18:20 FRITZ.Box_7580.153.06.90.image
-rw-r--r-- 1 1000 1000 4067592 Sep 6 03:04 kernel.image
drwxr-xr-x 23 1000 1000 4096 Sep 6 02:53 yf
peh@yourfritz:/tmp/yourfritz$ dd if=kernel.image of=kernel.bin bs=256 count=$(( $(stat -c %s kernel.image) / 256 ))
15889+0 records in
15889+0 records out
4067584 bytes (4.1 MB) copied, 0.233845 s, 17.4 MB/s
peh@yourfritz:/tmp/yourfritz$ sudo yf/bin/x86/unsquashfs filesystem.image
Filesystem on filesystem.image is xz compressed (4:0)
Parallel unsquashfs: Using 2 processors
3991 inodes (4681 blocks) to write
[=========================================\] 4681/4681 100%
created 3340 files
created 257 directories
created 564 symlinks
created 87 devices
created 0 fifos
peh@yourfritz:/tmp/yourfritz$ cd squashfs-root/usr/sbin/
peh@yourfritz:/tmp/yourfritz/squashfs-root/usr/sbin$ sudo ln -s ../../bin/busybox telnetd
peh@yourfritz:/tmp/yourfritz/squashfs-root/usr/sbin$ cd ../../../
peh@yourfritz:/tmp/yourfritz$ sudo yf/bin/x86/mksquashfs4-avm squashfs-root/ filesystem.bin -all-root
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on filesystem.bin, block size 65536.
[================================================\] 4030/4030 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 20207.63 Kbytes (19.73 Mbytes)
27.72% of uncompressed filesystem size (72890.43 Kbytes)
Inode table size 33680 bytes (32.89 Kbytes)
23.21% of uncompressed inode table size (145137 bytes)
Directory table size 40820 bytes (39.86 Kbytes)
41.40% of uncompressed directory table size (98596 bytes)
Number of duplicate files found 1345
Number of inodes 4249
Number of files 3340
Number of fragments 299
Number of symbolic links 565
Number of device nodes 87
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 257
Number of ids (unique uids + gids) 1
Number of uids 1
root (0)
Number of gids 1
root (0)
peh@yourfritz:/tmp/yourfritz$Da wir für das Arbeiten mit dem Bootloader die Skripte aus "eva_tools" benutzen werden, erstellen wir das eigene Image gleich in diesem Verzeichnis, das erspart uns später die Angabe von zusätzlichen Verzeichnisebenen.
Bis hierher haben wir noch keine fertigen Skript-Dateien benutzt und daher macht es auch keinen Unterschied, ob auf dem verwendeten System der Symlink "/bin/sh" nun auf eine "dash" oder eine "bash" oder was auch immer zeigt ... das wird jetzt anders. Die Skript-Dateien in "eva_tools" funktionieren entweder mit der "ash" der BusyBox oder mit einer "richtigen", ausgewachsenen "bash" als Shell. Wenn auf dem verwendeten System der Symlink also auf eine "dash" zeigt, ist entweder diese Standard-Shell zu ändern oder die erste Zeile in den Skripten in "eva_tools" (der sogenannte "She-Bang") ist entsprechend anzupassen. Wir gehen mal den Weg des geringeren Widerstands und ändern die Skripte, bevor wir sie verwenden.
Code:
peh@yourfritz:/tmp/yourfritz$ ls -ln
total 73180
-rw-r--r-- 1 0 0 20692992 Sep 6 03:14 filesystem.bin
-rw-r--r-- 1 1000 1000 20701192 Sep 6 03:13 filesystem.image
-rw-r--r-- 1 1000 1000 25384960 Sep 5 18:20 FRITZ.Box_7580.153.06.90.image
-rw-r--r-- 1 1000 1000 4067584 Sep 6 03:08 kernel.bin
-rw-r--r-- 1 1000 1000 4067592 Sep 6 03:04 kernel.image
drwxr-xr-x 15 0 0 4096 Sep 5 11:42 squashfs-root
drwxr-xr-x 23 1000 1000 4096 Sep 6 02:53 yf
peh@yourfritz:/tmp/yourfritz$ cat kernel.bin filesystem.bin >yf/eva_tools/myimage.bin
peh@yourfritz:/tmp/yourfritz$ cd yf/eva_tools
peh@yourfritz:/tmp/yourfritz/yf/eva_tools$ find . -type f -executable -exec sed -e "1s|/bin/sh|/bin/bash|" -i '{}' \;
peh@yourfritz:/tmp/yourfritz/yf/eva_tools$Um es besser auseinanderhalten zu können, verpacken wir den zusätzlich notwendigen Schritt bei der Umschaltung in einen komplett eigenen Anlauf für den Bootloader. Wer in die aktive Partition installieren will, kann diesen Schritt dann komplett überspringen.
Für die Benutzung der Skripte für den Bootloader brauchen wir noch ein paar Informationen über das Netzwerk unseres Linux-Systems ... erstens den Namen des Interfaces, an dem unsere FRITZ!Box nunmehr mit einem Ethernet-Kabel angeschlossen ist (am besten noch über einen Switch, das spart viele Probleme, die hier ebenfalls nicht behandelt werden sollen) und die auf diesem Interface verwendete IP-Adresse samt Maske. Aus der eigenen Adresse basteln wir uns dann die "Wunschadresse" für die FRITZ!Box, diese muß nur in unserem eigenen Segment liegen und darf natürlich von keinem anderen System verwendet werden. Der Einfachheit halber ist unser Interface hier "eth0" und die eigene IP-Adresse die 192.168.178.254 ... damit können wir der FRITZ!Box die 192.168.178.1 "zuweisen", das ist auch gleichzeitig deren Standardadresse.
Die Umschaltung auf das andere System in der inaktiven Partition (egal, ob da schon eines ist oder welche Version das hat) erfolgt einfach mit dem folgenden Aufruf:
Code:
peh@yourfritz:/tmp/yourfritz/yf/eva_tools$ export PATH=.:$PATH
peh@yourfritz:/tmp/yourfritz/yf/eva_tools$ ./eva_switch_system eth0 192.168.178.1 192.168.178.254
Found AVM bootloader: AVM EVA Version 1.3229 0x0 0x46409
Current system selected: 1
New system selected: 0
New value set, rebooting the device ...Im nächsten Anlauf lassen wir jetzt die Box noch einmal beim Start im Netzwerk suchen und wenn sie dann gefunden wurde, laden wir das eigene Image in den Hauptspeicher und lassen die Box mit diesem Image starten (das erfolgt implizit nach erfolgreichem Laden). In der Konsole sieht das dann so aus:
Code:
peh@yourfritz:/tmp/yourfritz/yf/eva_tools$ export PATH=.:$PATH # kann entfallen, wenn es vorher schon bei der Umschaltung verwendet wurde
peh@yourfritz:/tmp/yourfritz/yf/eva_tools$ eval $(sudo ./eva_discover INTERFACE=eth0 FROM=192.168.178.254 TO=192.168.178.1 BLIP=1 HOLD=0); echo "EVA_FOUND=$EVA_FOUND"; echo "EVA_IP=$EVA_IP"; [ "$EVA_FOUND" = "1" ] && ./eva_to_memory myimage.bin $EVA_IP
EVA_FOUND=1
EVA_IP=192.168.178.1
Found AVM bootloader: AVM EVA Version 1.3229 0x0 0x46409
Found hardware revision: 225
Memory size is 0x08000000 (128 MB)
Memory size limited to 128 MB
Image size is 0x179d100 (23 MB)
Setting temporary memory size to: 0x06862f00
Setting temporary kernel args to: mtdram1=0x86862f00,0x88000000
Image uploaded to device.
peh@yourfritz:/tmp/yourfritz/yf/eva_tools$Wenn alles glatt gegangen ist, startet nun eine Version 06.90 mit der Möglichkeit, den Telnet-Service über ein angeschlossenes Telefon (oder auch über die Wählhilfe, wie das dann geht, steht wieder in anderen Threads) mit der Tastenkombination #96*7* zu aktivieren. Dabei darf man sich nicht davon verwirren lassen, daß da kein Quittungstext mehr angezeigt wird, wie das früher einmal der Fall war ... und es ist auch nur einmal pro Bootvorgang möglich, den Telnet-Service neu zu aktivieren. Aber diese Aktivierung wird in der "fx_conf" abgespeichert und sollte da beim nächsten Systemstart das Telnet-Flag den richtigen Wert haben, wird auch der Telnet-Service vom "telefon"-Daemon automatisch gestartet. Man braucht diese Aktivierung also nur ein einziges Mal vorzunehmen, wenn man den Service nicht wieder deaktiviert hat.
Benutzen kann man den dann ganz einfach mit einem Telnet-Client:
Code:
peh@yourfritz:/tmp/yourfritz/yf/eva_tools$ telnet 192.168.178.1
Trying 192.168.178.1...
Connected to 192.168.178.1.
Escape character is '^]'.
password:
BusyBox v1.22.1 (2016-10-31 15:55:10 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.
ermittle die aktuelle TTY
tty is "/dev/pts/0"
Console Ausgaben auf dieses Terminal umgelenkt
disable start/stop characters and flowcontrol
#Um das verwendete Linux-System wieder aufzuräumen, reicht das rekursive Löschen des eigens eingerichteten Arbeitsverzeichnisses ("/tmp/yourfritz") aus.
Hat man das erst ein- oder zweimal gemacht, dauert das auch nur noch um die fünf Minuten ... am meisten Zeit nimmt immer noch das Packen des Dateisystem-Images in Anspruch - da hilft ein schnellerer Rechner mit etwas Hauptspeicher am ehesten.
Es ist also eigentlich ziemlicher Quatsch zu behaupten, AVM würde dem Kunden hier tatsächlich irgendwelche Steine in den Weg legen ... zumindest derzeit kann ich da keine erkennen. Es ist nicht mehr ganz so simpel wie früher, aber so ein eigenes Firmware-Image ist keine "rocket science" und der eigenen Phantasie, was man da noch so "von Hand" einbauen könnte, sind auch kaum Grenzen gesetzt ... jedenfalls solange man die eigenen Fähigkeiten richtig einschätzen kann und keine Änderungen vornimmt am AVM-Code, die dann die Box nicht mehr richtig starten oder arbeiten lassen.
Im Prinzip gilt das geschilderte Vorgehen auch für jedes Freetz-Image, wenn die Box das erste Mal mit einem "fremden" Image in Kontakt kommt ... die dort erzeugte "in-memory"-Image ist am Ende auch nichts anderes als ein Kernel und ein Dateisystem in einem, was in die Box geladen werden kann und sich dann dort (ebenfalls in die aktive Partition, weil das Skript dazu von AVM stammt und von Freetz nicht geändert wird) selbst installiert.
Es ist also genauso blödsinnig, erst ein Downgrade auf irgendeine alte Firmware zu machen, die noch unsignierte Images unterstützt, wenn man nur ein eigenes Image installieren will ... das geht über den Bootloader (auch bei VR9-NAND-Boxen) deutlich einfacher und bei den GRX5-Modellen gibt es solche alten Images ja ohnehin nicht.
Zuletzt bearbeitet:
