[Info] FRITZ!Box 7580 - Firmware 153.06.90 - Telnet-Service freischalten (geht auch für 7560 und 7590)

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
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?

  • 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/
Der erste Schritt ist das Anlegen eines Arbeitsverzeichnisses und der Download der AVM-Firmware in diesen Ordner. Wir nehmen an, wir arbeiten auf einem Debian-basierten System als normaler Benutzer, haben aber die Rechte, uns mittels "sudo" auch an Superuser-Kommandos zu machen ... das dafür ggf. notwendige Kennwort sollte jeder auf seinem eigenen System bereits kennen - sonst braucht er gar nicht erst weitermachen an dieser Stelle.

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:
[email protected]:~$ mkdir /tmp/yourfritz
[email protected]:~$ cd /tmp/yourfritz
[email protected]:/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]

[email protected]:/tmp/yourfritz$
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:
Code:
[email protected]:/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.
[email protected]:/tmp/yourfritz$ cd yf
[email protected]:/tmp/yourfritz/yf$ git checkout binaries
Branch binaries set up to track remote branch binaries from origin.
Switched to a new branch 'binaries'
[email protected]:/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
[email protected]:/tmp/yourfritz/yf$ cd ..
[email protected]:/tmp/yourfritz$
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.
Code:
[email protected]:/tmp/yourfritz$ tar -x -f FRITZ.Box_7580.153.06.90.image -O ./var/tmp/filesystem.image >filesystem.image
[email protected]:/tmp/yourfritz$ tar -x -f FRITZ.Box_7580.153.06.90.image -O ./var/tmp/kernel.image >kernel.image
[email protected]:/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
[email protected]:/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
[email protected]:/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
[email protected]:/tmp/yourfritz$ cd squashfs-root/usr/sbin/
[email protected]:/tmp/yourfritz/squashfs-root/usr/sbin$ sudo ln -s ../../bin/busybox telnetd
[email protected]:/tmp/yourfritz/squashfs-root/usr/sbin$ cd ../../../
[email protected]:/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)
[email protected]:/tmp/yourfritz$
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.
Code:
[email protected]:/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
[email protected]:/tmp/yourfritz$ cat kernel.bin filesystem.bin >yf/eva_tools/myimage.bin
[email protected]:/tmp/yourfritz$ cd yf/eva_tools
[email protected]:/tmp/yourfritz/yf/eva_tools$ find . -type f -executable -exec sed -e "1s|/bin/sh|/bin/bash|" -i '{}' \;
[email protected]:/tmp/yourfritz/yf/eva_tools$
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:
Code:
[email protected]:/tmp/yourfritz/yf/eva_tools$ export PATH=.:$PATH
[email protected]:/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 ...
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:
Code:
[email protected]:/tmp/yourfritz/yf/eva_tools$ export PATH=.:$PATH # kann entfallen, wenn es vorher schon bei der Umschaltung verwendet wurde
[email protected]:/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.
[email protected]:/tmp/yourfritz/yf/eva_tools$
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:
Code:
[email protected]:/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
#
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.
 
Zuletzt bearbeitet:

er13

Aktives Mitglied
Mitglied seit
20 Dez 2005
Beiträge
1,031
Punkte für Reaktionen
31
Punkte
48
Ohne jetzt mit Peters Methode konkurieren zu wollen, sei (was das Erstellen des modifizierten Images angeht) auf eine Freetz-basierte Alternative hingewiesen: Freetz im "no_freetz"-Modus. Fürs Flashen, "Telnet einschalten", etc. bitte weiterhin Peters Anleitung befolgen.
 
  • Like
Reaktionen: HarryHase

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
Ich sehe da gar keine Konkurrenz ... es ist nur der leichtere Weg und mit weniger Aufwand/Lernkurve (was muß in die "fwmod_custom" genau rein?) verbunden, sofern man nicht ohnehin auf Freetz setzen will. Ich habe es auch nur noch einmal so ausführlich beschrieben, weil es offenbar immer noch Unklarheiten gibt, wie man das machen kann und wie einfach es am Ende ist (schon verglichen mit dem Freetz-Wiki und den dort beschriebenen "first steps" für den Build-Host).

Auch die Voraussetzungen bei dem, was zuvor schon installiert sein muß auf dem "Build-Host", sind natürlich geringer beim oben beschriebenen Vorgehen als beim Klonen des Trunks, dem Erstellen der "host-tools" (die werden doch m.W. nicht auch in der Download-Toolchain schon mit vorbereitet oder irre ich mich da?) und dem anschließenden Modifizieren der AVM-Firmware.

Ich habe das ja eigentlich in #1 mit den Worten "mit max. 10 Minuten investierter Arbeitszeit" eingeleitet ... und ich scheue mich nicht es zuzugeben, daß ich (auch kein allzu geübter und eifriger Freetz-Benutzer) diese 10 Minuten in der Regel dann schon brauche, um ein neues System (das kann auch irgendein Live-System vom Stick sein) entsprechend vorzubereiten - ja, vermutlich klappt das in den 10 Minuten gerade mal so mit der Installation der "prerequisites". Freetz ist halt an dieser Stelle das Zweihandschwert und das oben Beschriebene eher ein Florett (und funktioniert auch für Boxen/Firmware-Versionen, die von Freetz noch nicht unterstützt werden).

Da bin ich mit der Installation von "git", "socat", "netcat-openbsd" und dem Klonen des Repos dann deutlich schneller und dank der inzwischen aufgenommenen Binärdateien aus den "squashfs-tools" (da habe ich mich ja in der Vergangenheit immer gesträubt, aber mit Signatur kann man das schon mal machen - irgendwelche Distro-Server machen ja auch nichts anderes, nur halt automatisch) im Repo dauert das wirklich nicht länger als 10 Minuten insgesamt - auch von einem Live-System in einer VM aus. Das würde ich persönlich mit Freetz (auch im "Sparmodus") nicht in dieser Zeit schaffen.

Spätestens wenn es um weitere Änderungen geht, muß man sich ja dann ohnehin überlegen, was man nun benutzen will und da kann man bei 7560/7580/7590 im Moment eigentlich nur Freetz verwenden (oder alles von Hand machen), denn "modfs" unterstützt die GRX5-Boxen mit dem fehlenden Wrapper-Dateisystem ja immer noch nicht offiziell. Das habe ich mir eigentlich für diese Zeit des Jahres fest vorgenommen, wo AVM nun mit der neuen Version als Release aufläuft und man nicht mehr mit weiteren tiefergreifenden Änderungen rechnen muß, die ggf. irgendwelche Patches dann wieder ins Leere laufen lassen.

[EDIT]
Und was ich oben auch nicht noch einmal explizit erwähnt habe: Das hier funktioniert für die VR9-Boxen mit NAND-Flash keineswegs 1:1 - da läuft schon das Entpacken der Firmware deutlich anders und auch beim Einpacken ist mehr Aufwand zu treiben, wenn man das AVM-Skript zur Installation einspannen will. Ohne Wrapper-FS läuft da dann nichts ... deshalb habe ich in den Titel auch ausdrücklich die 7580 geschrieben - auch wenn man das wohl auf die 7560 und 7590 übertragen könnte, habe ich das dort nicht selbst probiert. Das bleibt den jeweiligen Besitzern überlassen ... passieren kann eigentlich nichts. Man riskiert halt nur, daß das System irgendwie nicht starten kann im Speicher und dann sollte es auch nie bis zur Abarbeitung der "S03-flash_update" kommen, in der es sich selbst in den Flash-Speicher schreibt.
[/EDIT]

@er13:
Wenn dann Dein YourFritz-Fork (mit Ausnahme von "avm_kernel_config" natürlich, wo wir uns ja nicht einig sind) wieder synchron ist, braucht man auch nicht mehr das YourFritz-Repo gesondert klonen für die Installation und kann in Freetz gleich die "eva_tools" aus "tools/yf/eva_tools" verwenden (dafür patchst Du ja sicherlich dort auch die She-Bangs, damit man die verwendet). Hier wäre ich Dir allerdings wirklich dankbar, wenn Du ein Auseinanderlaufen vermeidest ... ansonsten müßte man bei jeder Fehlermeldung hier im IPPF bzgl. dieser Skripte erst einmal abklären, ob das nun die Version aus meinem Repo oder aus Deinem Fork ist - in Hinblick darauf, wer sich da bei einem Problem dann angesprochen fühlen sollte, ist das ja keine ganz unwichtige Information. Ich habe extra die Binärdateien im YourFritz-Repo in einen gesonderten Branch verschoben, damit ein "rebase" auf den "master" nicht auch die automatisch in den Fork mit einbringt (zumindest nicht sichtbar, solange der Branch nicht der aktive Zweig ist - die Übertragung kann man m.E. nicht verhindern beim "clone").
 
Zuletzt bearbeitet:

er13

Aktives Mitglied
Mitglied seit
20 Dez 2005
Beiträge
1,031
Punkte für Reaktionen
31
Punkte
48
Hallo Peter,

um mögliche Missverständnisse zu vermeiden. Die Kernaussage meines Posts ist lediglich "es sei auf eine Alternative hingewiesen". Im Grunde genommen möchte ich Deine Aussage "es ist weiterhin mit einfachen Mitteln möglich an einen Shell-Zugang zu gelangen" unterstützen und sie lediglich ums "und es existieren sogar mehrere Wege dafür" erweitern. Keine Konkurrenz, keine versteckte die Alternativen bewertende Botschaft, nix dergleichen.

VG, Gene
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
Habe ich auch nicht wirklich herausgelesen ... keine Bange. Ich wollte nur noch mal klarstellen, warum ich nicht bereits selbst hier - wie sonst an vielen Stellen - auf Freetz als denkbare Alternative hingewiesen hatte.

Für Freetz gibt es eben schon genug solcher "Anleitungen" und da brauchte es keine weitere. Als "Ansporn", das doch einfach mal zu probieren, war eben der Weg mit 12 einzugebenden Kommandos (wenn man die "ls" ausläßt und auch die Installation von Paketen aus einem Distro-Repo unterschlägt bei der Zählung) leichter zu vermitteln.

Daß ich generell gar keine Konkurrenz zur Toolchain und den Paketen sehe, habe ich auch oft genug klargestellt ... auf der Mailing-Liste und auch hier im IPPF in einigen Threads. Ich betrachte auch "modfs" nach wie vor ausschließlich als alternative Möglichkeit für die "vierte Kraft" im Freetz-Projekt und das ist der "mod"-Teil. Da soll/wird irgendwann mal "YourFritz" als "Plattform" übernehmen ... das ist aber weiterhin Zukunftsmusik, weil niemand wirklich mitmachen will und es vermutlich immer noch für Spinnerei gehalten wird, daß man die Firmware auch dynamisch erweitern kann.

Der Freetz-Mod ist - für simple Dienste und auch bzw. gerade für Patches von AVM-Code, wo ich ja meist nur Details ändere und wenig neu dazu gebe - einfach überdimensioniert und - absehbar, wenn AVM weitermacht auf dem eingeschlagenen Weg - unsicherer als das AVM-eigene GUI. @frater hat das ja zwar gerade erst hinter einen "stunnel" gepackt und scheint damit auch zufrieden, aber man merkt dem GUI (und der Technik dahinter) m.E. schon an, daß das zum großen Teil noch aus der "pre-LUA"-Ära bei AVM ist und es paßt ja auch nicht wirklich zum neuen AVM-"Design" (und das meint weniger die Darstellung als die Technologie).

Auch der - zur AVM-Version identische - Aufbau der Firmware als Monolith ("externals" zähle ich da noch dazu) ist eben nicht mehr ganz zeitgemäß und ich möchte nicht wissen, wieviele Boxen mit Freetz und alten (ggf. angreifbaren) Versionen irgendwelcher Erweiterungen irgendwo im Internet herumgeistern, weil deren Besitzer - mit viel Glück - bei jedem AVM-Release vielleicht mal ein neues Freetz-Image erstellen.

Auch wenn es nur langsam vorangeht mit YourFritz ... es geht voran. Mit dem Signieren von TAR-Files und dem Decodieren der AVM-Einstellungen (mit der Möglichkeit der "Nachnutzung") sind inzwischen einige wichtige Voraussetzungen vorhanden, um direkt mit dem AVM-Plugin-Mechanismus (zumindest mit "tr069fwupdate" als dessen zentraler Komponente für Prüfung und Installation) eigene Erweiterungen zur Laufzeit dynamisch zu installieren und die ggf. sogar aus einem zentralen Repository mit aktuellen Paketen zu laden, wenn es neue Versionen gibt.

Die (individuelle) Verschlüsselung von Einstellungen sichert dann wieder, daß auch bei der Ablage von solchen Paketen und deren lokalen Daten im NAS-Speicher (oder im YAFFS2 bei VR9, es gibt ja praktisch keine Boxen mit 16 MB NOR-Flash und daraus resultierendem "Sparzwang" mehr) keine unbemerkten Veränderungen von außen erfolgen können (in einem vernünftigen Rahmen - sicherer als die AVM-Firmware mit dem Bootloader kann man halt auch nicht sein) - auch das Erstellen von signierten Images auf der Box (zur Sicherung von Einstellungen) und die Verwendung des Box-Zertifikats dafür anstelle irgendwelcher anderen Keys, gingen ja schon in diese Richtung.

Ich bin da also durchaus auch selbstbewußt genug und denke schon, daß die Idee dahinter tatsächlich Hand und Fuß hat. Teile davon nutze ich auch bereits selbst, die sind halt nur noch nicht so weit, daß man sie bedenkenlos jedem in die Hand drücken möchte - obwohl es ja auch immer wieder mal ein paar verstreute Bausteine von mir gibt, wenn es irgendwo gerade passend erscheint (z.B. E99-custom oder auch run_update als Vorsichtsmaßnahme gegen Updates durch AVM). Als Gegenpart kommt natürlich trotzdem AVM immer wieder auch dazu (sicherlich nicht immer absichtlich, aber halt doch mit Konsequenzen, wenn jetzt z.B. bei der GRX-Generation das YAFFS2 fehlt - dafür ist hier "overlayfs" im Kernel, was theoretisch wieder auch AVM-Teile ohne "bind-mount" überlagern könnte) und da dauert das alles halt länger, als ich eigentlich will - ich möchte ja auch die Suche nach neuen und weiterhin bestehenden Lücken (oder Problemen, die nur ich darin sehe) nicht unter den Tisch fallen lassen und das braucht halt auch seine Zeit.
 

lowmaster

Neuer User
Mitglied seit
2 Sep 2010
Beiträge
58
Punkte für Reaktionen
0
Punkte
6
Eine schöne Anleitung. Danke!

Ich denke es wird wohl nicht möglich sein, dass man Teile dieser Anleitung dafür verwenden kann, um bei einem 1750E Repeater, ein, zwei Zeilen Code an ein Script dranzuhängen um z.B. STP beim Start mit zu aktivieren, oder?
 

tuxedonet

Neuer User
Mitglied seit
20 Sep 2015
Beiträge
108
Punkte für Reaktionen
3
Punkte
18
bei einem 1750E Repeater, ein, zwei Zeilen Code an ein Script dranzuhängen um z.B. STP beim Start mit zu aktivieren, oder?
also bei mir hat das von er13 genannte Vorgehen Freetz im "no_freetz"-Modus bei DVB-Repeater zum "Telnet einschalten" funktioniert;
einfach in Freetz-Umgebung bei "make menuconfig" die FB4020 gewählt und fwmod manuell angeworfen.

Code:
./fwmod -u -d unpacked_firmware FRITZ.Box_WLAN_Repeater_DVB_C.133.06.51.image
sed -i 's%## telnetd -l /sbin/ar7login%/usr/sbin/telnetd -l /sbin/ar7login%' unpacked_firmware/original/filesystem/etc/init.d/S53-dvb
#
[ -x unpacked_firmware/original/filesystem/usr/sbin/telnetd ] || ln -s ../../bin/busybox unpacked_firmware/original/filesystem/usr/sbin/telnetd
ls -la  unpacked_firmware/original/filesystem/usr/sbin/telnetd
#
./fwmod -p -d unpacked_firmware FRITZ.Box_WLAN_Repeater_DVB_C.133.06.51.image
ls -la unpacked_firmware/*.image
ggf. einfach weiteres rc-skript einfügen.

EDIT: code-sniplet gemäß Hinweis von PeterPawn #8 (Softlink telnetd) korrigiert/ergänzt
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
@tuxedonet:
OK, das ist dann der Start des Telnet-Daemons ... aber hast Du den Symlink vergessen zu erstellen oder verwendet AVM tatsächlich bei dem Repeater eine BusyBox ohne den Symlink-Patch oder existiert der tatsächlich bereits, weil AVM davon ausgeht, daß der ohne "telefon"-Daemon ohnehin nichts hilft? Ansonsten wäre auch der Link für "/usr/sbin/telnetd" (auf ../../bin/busybox oder auch mit absolutem Pfad) erst noch in der AVM-Firmware anzulegen, bevor man sie wieder einpacken läßt.

@lowmaster:
Von mir hast Du bisher keine Antwort erhalten, weil ich es schlicht nicht weiß ... die Repeater sind einfach nicht mein Beritt (ich hatte mal einen 300E, den habe ich dann schnell wieder verschenkt, weil das ziemlich witzlos war und seitdem interessieren die mich nicht mehr wirklich). Ich hätte (bei einem Repeater ohne Ethernet-Anschluß) schon Probleme bei der Überlegung, wie ich eine unsignierte Firmware in das Gerät kriege, ohne eine andere Schwachstelle zuvor auszunutzen, um einen Shell-Zugriff für das Update zu haben. Auch über die dort verbaute Hardware beim Prozessor herrscht m.W. weitgehende Unwissenheit vor ... benutzen die MIPS- oder ARM-Prozessoren oder was sonst? Alles offene Fragen für mich ...
 

tuxedonet

Neuer User
Mitglied seit
20 Sep 2015
Beiträge
108
Punkte für Reaktionen
3
Punkte
18
@PeterPawn: Danke für Hinweis (Symlink-Patch telnetd) !!!
Anpassung von #7 ist erfolgt.
 

draellme

Neuer User
Mitglied seit
19 Nov 2005
Beiträge
96
Punkte für Reaktionen
0
Punkte
6
Hallo @PeterPawn! Danke für die ausführliche Anleitung. @KunterBunter hat mich hierher verwiesen, als ich nach dem Umfassen einer 7590 A/CH-Box auf D fragte. Interpretiere ich es richtig, dass ich das Deutsche Image nehmen kann, das squashfs extrahiere und dort lediglich die Sektion "OEM Ermitteln" manipulieren muss, iw Ersetzen durch:

OEM = "avm"
OEM_DEFAULT_INDEX = ""
export OEM_DEFAULT_INDEX
export OEM

Dann das image neu zusammenstellen und dann kann ich das neue Image auf die CH-Box laden und das neue Image sollte auch ein Reboot überleben? Annex ist an sich egal, da ich hinter einem Kabelrouter bin.

Habe ich das richtig verstanden? Danke!
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
Im Prinzip ja, wobei ich jetzt nicht in der 7590-Firmware nachsehen will, ob die Reihenfolge auf die richtige Fundstelle hinweist. Einfach die gesamte "rc.conf" (da sollte das ja zu finden sein, auch wenn ich in #10 nichts dazu finde) durchsuchen - es gibt i.d.R. einen Abschnitt, wo erst mal "Standardwerte" gesetzt werden, die dann hinterher aus dem Environment noch einmal überschrieben werden und noch etwas später dann ausgewertet werden für weitere Einstellungen.
 

lowmaster

Neuer User
Mitglied seit
2 Sep 2010
Beiträge
58
Punkte für Reaktionen
0
Punkte
6
Ich danke Euch für diese sehr ausführliche Anleitung.

Ich habe das Ganze direkt mal probiert, scheitere aber leider schon im ersten Schritt. Ich habe auch mit der DVB_C Image probiert, was mit der selben Fehlermeldung scheitert.:

Code:
[email protected]:~/freetz-trunk1750$ ./fwmod -u -d unpacked_firmware FRITZ.Box_WLAN_Repeater_DVB_C.133.06.51.image
STEP 1: UNPACK
unpacking firmware image
removing NMI vector from SquashFS
[Error] Image size encoded in NMI block (10153011) doesn't match calculated size (12451840)
ERROR: fatal error while removing NMI vector from SquashFS.
[email protected]:~/freetz-trunk1750$
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
Mir fehlt zwar die Firmware zum Vergleich und das Gerät zum Test, aber bei der Firmware für den 1750E (06.91) klappt das Entpacken mit "unsquashfs" (aus meinem Repo, mit Option "-k", weil das ja ein "hidden root image" ist) problemlos und das legt angesichts der diversen Prüfsummen, die in so einem SquashFS-Image verwurstet sind und der Empfindlichkeit der LZMA-Kompression bei "missing chunks" eigentlich nahe, daß das Entpacken dieser Firmware funktioniert. Wie sind wir jetzt eigentlich beim DVB-C-Repeater gelandet nach #6?

EDIT:
Wobei auch das Entpacken der 06.51 für den DVB-C-Repeater (Fritz_Box_HW205) problemlos möglich ist ... dann muß das Problem in irgendwelchen anderen Prüfungen in "fwmod" liegen, die @er13 eingebaut hat.

EDIT2:
Also die im NMI-Vector der 133.06.51 kodierte Länge von 0x9AEC33 korrespondiert auch ganz gut mit der tatsächlichen Länge der Firmware, also mit dem Ende des SquashFS-Images. Nur ist das hier halt um einiges kleiner als der zur Verfügung stehende Flash-Speicher und daher hängt der NMI-Vector halt komplett hinter dem SquashFS-Image (das endet schon beim o.a. Offset und der Vector beginnt erst bei 0xBE0000).
 
Zuletzt bearbeitet:

tuxedonet

Neuer User
Mitglied seit
20 Sep 2015
Beiträge
108
Punkte für Reaktionen
3
Punkte
18
also bei mir kommt mit CS13754 folgender Output:

Code:
[email protected]:/home/freetz/freetz-devel$ grep -v ^# .config | grep 4020
FREETZ_TYPE_4020=y
FREETZ_DL_KERNEL_SOURCE_ID="4020_06.27"
FREETZ_DL_SITE="@AVM/fritzbox.4020/firmware/deutsch"
FREETZ_DL_SOURCE="FRITZ.Box_4020.de-en-es-it-fr-pl.147.06.50.image"
FREETZ_AVM_SOURCE_4020_06_27=y
FREETZ_AVM_SOURCE_ID="4020_06.27"
FREETZ_TYPE_PREFIX="4020"
Code:
[email protected]:/home/freetz/freetz-devel$ ./fwmod -u -d unpacked_firmware FRITZ.Box_WLAN_Repeater_DVB_C.133.06.51.image
STEP 1: UNPACK
unpacking firmware image
Skipping 0 Bytes garbage...splitting kernel image
unpacking filesystem image
    Reading a different endian SQUASHFS filesystem on unpacked_firmware/original/kernel/kernelsquashfs.raw
    Filesystem on unpacked_firmware/original/kernel/kernelsquashfs.raw is lzma compressed (3:76)
    Parallel unsquashfs: Using 1 processor
    2319 inodes (2598 blocks) to write
    created 1897 files
    created 195 directories
    created 336 symlinks
    created 86 devices
    created 0 fifos
unpacking var.tar
done.

detected firmware _en-de-es-fr-it-pl 133.06.51 rev34135
FINISHED
[email protected]:/home/freetz/freetz-devel$
ich denke in separatem Thread in Freetz-Unterforum ist das am Besten zu diskutieren;
und dann mit .config File, zwecks Reproduzierbarkeit.

EDIT: Freetz Changeset ist 13754,
fwmod logfile ist vom Aug 29 2016.
 
Zuletzt bearbeitet:

lowmaster

Neuer User
Mitglied seit
2 Sep 2010
Beiträge
58
Punkte für Reaktionen
0
Punkte
6
ich hab gerade svn 13754 ausgecheckt und bokomme den selben fehler

make menuconfig für 4020 mit Freetz im "no_freetz"-Modus durchgeführt
make tools

Code:
[email protected]:~/freetz-trunk1750$ grep -v ^# .config | grep 4020
FREETZ_TYPE_4020=y
FREETZ_DL_KERNEL_SOURCE_ID="4020_06.27"
FREETZ_DL_SITE="@AVM/fritzbox.4020/firmware/deutsch"
FREETZ_DL_SOURCE="FRITZ.Box_4020.de-en-es-it-fr-pl.147.06.50.image"
FREETZ_AVM_SOURCE_4020_06_27=y
FREETZ_AVM_SOURCE_ID="4020_06.27"
FREETZ_TYPE_PREFIX="4020"

[email protected]:~/freetz-trunk1750$ ./fwmod -u -d unpacked_firmware FRITZ.Box_WLAN_Repeater_DVB_C.133.06.51.image
STEP 1: UNPACK
unpacking firmware image
Skipping 0 Bytes garbage...removing AVM SquashFS junk bytes
[Error] Image size encoded in junk block (10153011) does not match calculated size (12451840)
ERROR: fatal error while removing AVM SquashFS junk bytes.
[email protected]:
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,041
Punkte für Reaktionen
991
Punkte
113
Da das ja nun wirklich nichts mehr mit dem Ausgangsthema zu tun hat, wäre ein neuer Thread im Freetz-Unterforum sicherlich die bessere Lösung.

PS: Wenn man das lösen will (anstatt einen neuen Thread an anderer Stelle aufzumachen), muß man sich Zeile 99 im Skript "remove_nmi_vector" von Freetz ansehen.
 
Zuletzt bearbeitet:

tuxedonet

Neuer User
Mitglied seit
20 Sep 2015
Beiträge
108
Punkte für Reaktionen
3
Punkte
18
@lowmaster: Bitte unbedingt neuen Thread im Unterforum Freetz eröffnen;
diese Arbeit kann Dir niemand abnehmen.

Hinweis: ggf. hilft auch die .config Variable FREETZ_AVM_HAS_JUNK_BYTES=n setzen
Code:
diff .config_FB4020_147.06.50_int_ .config._DVB-C_06.51_
2131c2131
< FREETZ_AVM_HAS_JUNK_BYTES=y
---
> FREETZ_AVM_HAS_JUNK_BYTES=n
 
  • Like
Reaktionen: lowmaster

er13

Aktives Mitglied
Mitglied seit
20 Dez 2005
Beiträge
1,031
Punkte für Reaktionen
31
Punkte
48

er13

Aktives Mitglied
Mitglied seit
20 Dez 2005
Beiträge
1,031
Punkte für Reaktionen
31
Punkte
48
Es gibt Freetz schon lange für manche rextd basierte Geräte (also powerline und repeater).
Halt nur nicht im offiziellen Repo, da einer elitäre Gruppe dort den Deckel drauf hat
Mich wundert nur, dass diese nicht-elitäre Gruppe, die sich diese Arbeit gemacht hatte, wiederholt (s. z.B. hier) Geheimniskrämerei betreibt und ihren Quellcode niemandem zur Verfügung stellt.

Ist dies eigentlich nicht ein Zeichen dafür, dass sie sich für noch elitärer hält?