[HowTo] Alice IAD 7570 - telnetd/others

4nt4r3s

Neuer User
Mitglied seit
26 Nov 2010
Beiträge
30
Punkte für Reaktionen
0
Punkte
0
Servus allseits,

nachdem Hansenet(mittlerweile O2) mit den letzten Firmwareupdates das starten von telnetd unterbindet, hier eine kleine Anleitung zum Starten von Telnetd(damit jemand der wie ich ewigkeiten nach lösungswegen googled auch mal fündig wird):

Was brauchen wir:
- ein serielles kabel mit TTL-Pegelwandler
- Ein terminal-Programm
- einen vorkompilierten telnetd/dropbear

Ausgangslage:
Mit den letzten firmware versionen hat Alice/O2 telnetd aus der Firmware entfernt. /var/flash/debug.cfg existiert nicht, und wird auch nicht von /etc/init.d/rc.S ausgeführt.

Man logge sich daher via serial auf der box ein. Dazu verbindet man das Serial-Kabel über die vorgebohrten löcher im linken teil der platine:
fbox%20hack.png

(Originalbild: wehavemorefun.de)

Für die Verbindung zur IAD benutzt man die folgenden Einstellungen: 38400/8/N/1
anschliessend fährt man die box hoch. nach abgeschlossenem Booten bittet die konsole um das drücken der enter-taste, um die konsole zu aktivieren.
Da wir wie gesagt keinen telnetd und keine debug.cfg auf der box haben, gehen wir ein wenig anders vor:

cat /var/flash/calllog > /var/tmp/calllog
und bearbeiten diese dann mit nvi:
nvi /var/tmp/calllog

Dort geben wir das folgende script ein:
Code:
#!/bin/sh
if [ -f /var/tmp/utelnetd.pid ]
then
  exit 0
fi
while !(ping -c 1 google.de) ; do sleep 1; done
cd /var/tmp
wget http://tecnode.org/fritzbox/utelnetd
chmod +x utelnetd
./utelnetd -d -l /sbin/ar7login
touch /var/tmp/utelnetd.pid

Anschliessend beenden und speichern wir die datei ab, und kopieren sie über die alte:
cat /var/tmp/calllog > /var/flash/calllog

einen reboot später sollte telnetd dann beim ersten eingehenden anruf heruntergeladen und gestartet werden.
Alternativ kann man die serielle konsole auch einfach dazu benutzen, dsl und voip zugangsdaten auszulesen, und eine richtige fritzbox ohne diese lächerlichen einschränkungen der Alice-Firmware aufstellen. Ist vielleicht auch die bessere lösung, sicher aber meine lösung.
 
Nur mal so als "Randbemerkung":

Die Datei /var/flash/debug.cfg ist physikalisch auf keiner (jungfräulichen) Fritz!Box vorhanden!
Dieses File muss zunächst z.B. mittels echo > /var/flash/debug.cfg angelegt werden.
Erst jetzt kann man die debug.cfg auch befüllen. Ausgeführt wird sie bei jedem Neustart der Fritz!Box.

Joe
 
Zuletzt bearbeitet:
servus Joe_57:

die Alice IAD 7570 ignoriert die debug.cfg. normalerweise wird der node in /etc/init.d/rc.S erstellt und dann gelinkt. die rc.S der 7570 IAD von Alice enthält die entsprechenden stellen jedoch nicht. daher hilft auch das anlegen der datei nicht, da nicht persistent. Und selbst wenn, die debug.cfg wird von rc.S bei der IAD 7570 auch nicht ausgeführt, sprich selbst wenn du die datei anlegst, die nach dem reboot dann auch nicht mehr da ist(inhalt ist noch da, wenn man den node manuell angelegt hat, aber der link wird nicht erzeugt), wird die datei beim booten der box nicht ausgeführt. Die IAD7570 ist zwar auf der verpackung ne fritte, aber Alice hat da recht hart und viel kastriert.
 
... Die IAD7570 ist zwar auf der verpackung ne fritte, aber Alice hat da recht hart und viel kastriert...
Das Ausmaß der Veränderungen durch "das Wunderland" war mir bisher noch nicht bekannt.
Danke für die ausführliche Beschreibung!

Joe
 
hehe, ja leider...

zumal Alice/O2 das was sie in der firmware dringelassen haben fast überall verkrüppelt haben. So geht Dyndns bei deren website nur mit den voreingestellten providern, die Firewall lässt forwards nur dann zu, wenn sie von der maschine eingerichtet werden, auf die das forward zielt(und auch dann leider nicht immer), static dhcp leases sind defekt, und noch so einiges anderes geht nicht. davon dass die box recht häufig einfach hängen bleibt, will ich erst gar nicht anfangen.(IMHO ein fehler im WLAN, tritt verstärkt auf, wenn ich mein android phone verbinde)

Es ist übrigens auch eine schande, dass O2 sich weigert, der GPL bei diesen geräten folge zu leisten. bin mal gespannt was der typ bei gpl-violations.org dazu meint.
 
Ha, wie großartig ist das denn. Gerade wollte ich selber einen Thread genau zu diesem Thema starten und siehe da, es gibt schon einen :)

Nur mal vorab als Erklärung warum Telnet nicht mehr funktioniert:

Seit der .86er FW (Start FW) wurde das telnetd Applet aus der Busybox herauskompiliert und zusätzlich der Symlink /usr/sbin/telnetd -> /bin/busybox entfernt.

Nun zu meinem Approach. Zuerst habe ich die Busybox der .86er FW in die FW kopiert und dann lasse ich den Node für die debug.cfg in der rcS erstellen

Code:
##########################################################################################
## user rc file
##########################################################################################
if [ -z "$CPU_NR" ] || [ "$CPU_NR" = "1" ] ; then
mknod /var/flash/debug.cfg c $tffs_major $((0x62))
if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then
. /var/flash/debug.cfg
fi
fi

danach lasse ich durch rcS ein Telnet Startscript ausführen (ich denke das muss viel eleganter gelöst werden, aber so funktionierts erstmal)

Code:
##########################################################################################
## start_telnet ausführen
##########################################################################################
## if /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then
if [ -f /sbin/start_telnet ] ; then
/sbin/start_telnet
fi
## fi

im Startscript steht nichts anderes, als das telnetd gestartet werden soll und das der Login über ar7login erfolgen soll.

echo '/usr/sbin/telnetd -l /sbin/ar7login' > /var/flash/debug.cfg

Nun zu meinem Problem. Gucke ich mir die Support Datei an, so wird mir angezeigt, das

1. telnetd als Prozess aktiv ist

694 root 1424 S /usr/sbin/telnetd -l /sbin/ar7login

2. somit als Vorraussetzung der debug.cfg Eintrag vorher wohl ok sein muss

// EOF
sed: /var/flash/user.cfg: No such file or directory
sed: /var/flash/userstat.cfg: No such file or directory
sed: /var/flash/vpn.cfg: No such file or directory
/usr/sbin/telnetd -l /sbin/ar7login

3. auf Port 23 gelauscht wird

tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN

4. Wenn ich mit Putty versuche eine Verbindung aufzubauen, geht auch von meinem Client eine Anfrage an den Port

tcp 0 0 192.168.1.1:23 192.168.1.8:3738 ESTABLISHED

allerdings bekomme nun keine Aufforderung zur Eingabe meines WebGUI PWs bekommen. Putty bleibt einfach schwarz, kein Prompt. Woran kann das liegen?

-----------

Edit & Frage: kann es sein, das ich den telnetd mit dem Parameter -d (vermutlich für Daemon) ausführen MUSS? das ist nämlich bei kurzen überfliegen der einzige Unterschied. Hab jetzt allerdings keine Zeit mehr, sollte es daran liegen, zu testen, muss in wenigen stunden wieder aufstehen (dann morgen Abend).
 
Zuletzt bearbeitet:
hast du geschaut ob /sbin/ar7login tatsächlich existiert? probiere telnetd mal mit /bin/sh statt /sbin/ar7login zu starten. allerdings kriegst du dann keine passwortabfrage mehr.

Btw, darf ich mir eine frage erlauben? wie hast du die rcS modifiziert? eigenes Firmware-image? ich wäre sehr an dieser modifikation interessiert, und vor allem wie du verhinderst dass die box beim einspielen die freischaltung zurücknimmt, womit das internet tot ist und die box sich selbst auf das offizielle image zurückstellt.
 
kannst du gerne fragen.

Die 86er Busybox habe ich aus dem 86er_dump aus dem RuKernel Tool. ALs meine Firmware zum modifizieren habe das 96er_dump als FW besorgt (RuKernel Tool), dieses einfach mit fwmod entpackt, meine Modifikationen in der rcS ausgeführt und dann die FW mit fwmod wieder gepackt. Danach hab ichs mit dem push_firmware Tool für Windows (in einem Forum gefunden) auf die Box gezwungen. Da ich die 8 MB Grenze des Images nicht gesprengt habe und sonst ja auch keine Änderungen vorgenommen habe, ging das alles ohne Probleme.

Dadurch das die Änderungen in der rcS ausgeführt wurden, wird bei jedem booten das ausgeführt, was ich möchte und daher werden die Einstellungen nicht zurückgesetzt.

kannst du mir kurz mal das Kommando geben (also einfach die gesamte Syntax der Zeile) die in die debug.cfg echoen soll (das mit dem /bin/sh)
 
kannst du gerne fragen.

Die 86er Busybox habe ich aus dem 86er_dump aus dem RuKernel Tool. ALs meine Firmware zum modifizieren habe das 96er_dump als FW besorgt (RuKernel Tool), dieses einfach mit fwmod entpackt, meine Modifikationen in der rcS ausgeführt und dann die FW mit fwmod wieder gepackt. Danach hab ichs mit dem push_firmware Tool für Windows (in einem Forum gefunden) auf die Box gezwungen. Da ich die 8 MB Grenze des Images nicht gesprengt habe und sonst ja auch keine Änderungen vorgenommen habe, ging das alles ohne Probleme.

Dadurch das die Änderungen in der rcS ausgeführt wurden, wird bei jedem booten das ausgeführt, was ich möchte und daher werden die Einstellungen nicht zurückgesetzt.

kannst du mir kurz mal das Kommando geben (also einfach die gesamte Syntax der Zeile) die in die debug.cfg echoen soll (das mit dem /bin/sh)

/sbin/utelnetd -l /bin/sh

sollte alles sein. was ar7login normalerweise macht, ist das passwort zu erfragen und dann eine shell zu starten. btw, es kann sein dass dein default für /bin/sh keine autocompletion/history etc hat. in dem fall würde ich das ar7login aus deiner zusatzbusybox benutzen. das ginge etwa so:
mkdir /var/tmp/sbin
cd /var/tmp/sbin
ln -S /path/to/your/custom/busybox ar7login
/sbin/utelnetd -l /var/tmp/sbin/ar7login
 
Also, habs nun getestet. Funktioniert leider nicht. Um Verwechslungen vorzubeugen, ich benutze nicht utelnetd, sondern direkt das telnetd Applet was aus der Busybox aus der .86er Firmware kommt. Ich hab einfach stumpf die Busybox aus der 86er über die der 96er kopiert, danach die korrekten Rechte gesetzt und Fimrware als Custom wieder gepackt.

Zu meinem Test, es wird trotz dessen dass das Kommando /usr/sbin/telnetd -l /bin/sh als Prozess mit PID und allem PiPaPo aktiv ist, keine Shell anboten. Nur schwarzen Screen. Habs jetzt mit Putty und dem Telnet Client von Win7 über RuKernel probiert. In den Debug Logs vom RuKernel bekomme ich eine Fehlermeldung

26.06.2012, 21:54:29,235, >ru_btOpenTelnetWindow<: PID: 5736 - Error: 0

ich muss mir nochmal angucken ob das mit meinem weg überhaupt geht. Hast du sonst noch einen anderen Vorschlag? Im Wehavemorefun Wiki steht noch die Möglichkeit, dass man die passwd via rc.user script mit einem eigenen passwort für den root User versieht. Aber wenn ich nicht mal eine Prompt bekomme, sollte das relativ zwecklos sein, oder?

gruß
edge
 
Also, habs nun getestet. Funktioniert leider nicht. Um Verwechslungen vorzubeugen, ich benutze nicht utelnetd, sondern direkt das telnetd Applet was aus der Busybox aus der .86er Firmware kommt. Ich hab einfach stumpf die Busybox aus der 86er über die der 96er kopiert, danach die korrekten Rechte gesetzt und Fimrware als Custom wieder gepackt.

Zu meinem Test, es wird trotz dessen dass das Kommando /usr/sbin/telnetd -l /bin/sh als Prozess mit PID und allem PiPaPo aktiv ist, keine Shell anboten. Nur schwarzen Screen. Habs jetzt mit Putty und dem Telnet Client von Win7 über RuKernel probiert. In den Debug Logs vom RuKernel bekomme ich eine Fehlermeldung

26.06.2012, 21:54:29,235, >ru_btOpenTelnetWindow<: PID: 5736 - Error: 0

ich muss mir nochmal angucken ob das mit meinem weg überhaupt geht. Hast du sonst noch einen anderen Vorschlag? Im Wehavemorefun Wiki steht noch die Möglichkeit, dass man die passwd via rc.user script mit einem eigenen passwort für den root User versieht. Aber wenn ich nicht mal eine Prompt bekomme, sollte das relativ zwecklos sein, oder?

gruß
edge

probier mal meine telnetd binary aus. die url steht ja in meinem OP.
 
So, ich habs mal mit deiner Binary probiert

Code:
#!/bin/sh
if [ -f /var/tmp/utelnetd.pid ]
then
  exit 0
fi
while !(ping -c 1 google.de) ; do sleep 1; done
cd /var/tmp
wget http://tecnode.org/fritzbox/utelnetd
chmod +x utelnetd
#./utelnetd -d -l /sbin/ar7login
./utelnetd -l /bin/sh
touch /var/tmp/utelnetd.pid

Lt. Supportdata ist Telnet aktiv

737 root 160 S ./utelnetd -l /bin/sh

-rwxr-xr-x 1 root root 73372 Jun 28 08:47 utelnetd

Interessanterweise beim Aufruf mit -l /bin/sh toucht er mir die PID nicht mehr -> hier mal von einem früheren Versuch

-rw-r--r-- 1 root root 0 Jun 28 08:19 utelnetd.pid (das fehlt beim letzten Versuch)

Egal wie rum ich es drehe, ob ar7login oder die direkte Anforderung einer Shell, ich bekommen keine präsentiert. Die Verbindung via Telnet steht aber

tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN

tcp 0 0 192.168.1.1:23 192.168.1.2:4891 ESTABLISHED

Bin Langsam mit meinem Verständnis am Ende

Gruß
Edge
 
ich würde dir direktsupport anbieten, zb via teamviewer, wenn du interesse daran hast. Allerdings solltest du ne serielle verbindung zur box offen haben, damit man "sehen kann, was sache ist"
 
Kurzer Zwischenstand. Nachdem ich das FW Image komplett neu aufgebaut hatte, ging es. hatte das ganze erstmal direkt mit dem Bash Aufruf ohne Passwort und mit deinem Script (also besorgen von utelenetd via wget und nicht das feste raufpacken in das FW Image und dann aufrufen/starten lassen), welches von rcS direkt aufgerufen wird, gemacht.

Wenn ich meine aktuelle große Baustelle durch habe, werd ich mich nochmal ranmachen und utelnet fest auf die Box packen und dann per, geänderten Script (ohne den Ping auf google und wget des binary) durch rcS (also das Script (telnet_start) durch rcS) mit ar7login testen.

Ich meld mich dann

Gruß
edge
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.