[Frage] Provisioning bei 7430 ewetel Edition

[slemke]

Hallo,

ich habe hier eine ewetel 7430, bei der die Firmware nicht gebrandet ist; diese hat folgendes gesetzt:

---> GETENV firmware_version
firmware_version avm
ftp> quote GETENV provider
---> GETENV provider
provider 7430_ewe_07_2017

Wenn ich das mittels UNSETENV aufhebe, dann Werkseinstellungen lade, sollte sie ja "blank" sein (so steht es in der FAQ ;-)
Frage: Was passiert, wenn jemand anderes obigen Wert wieder einstellt und die Box an einem ewetel Anschluss anklemmt? Bekommt er dann meine Daten?

Oder umgekehrt: Sind die Daten vom Provisionierungsserver von das physikalischen Leitung abhängig (ich glaube, bei der Telekom gibt es so etwas, aber dann braucht man gar keine Zugangsdaten im Router)?

Grüße
Sebastian

 

[trendchiller]

Normalerweise benötigt man einen Code, um sich am Provisionisrungsserver zu authentifizieren („Startcode“), es sei denn, der Provider provisioniert die Box über die MAC-Adresse, dann könntest (wirst) du Pech haben.

 

[PeterPawn]

so steht es in der FAQ ;-)

In welcher/welchen FAQ genau steht denn so etwas Falsches?

 

[slemke]

Hallo,

ich war ja artig und habe die SuFu genutzt ;-) Es geht zwar um die 7490, aber anscheinend handelt es sich um die gleiche Vorgehensweise:

http://rukerneltool.rainerullrich.de/Kurzanleitung_7490-o2-Edition-von-o2-Leine-befreien.pdf

https://www.ip-phone-forum.de/threa...-entfernen-flashen.275188/page-7#post-2159365
https://www.ip-phone-forum.de/threa...-entfernen-flashen.275188/page-7#post-2079118

Inzwischen gibt es auch eine ausführlichere Anleitung als PDF. Die ist zwar für O2 geschrieben, deckt sich aber mit der Version für die EWE.

Erleuchte mich bitte ;-)

Sebastian

 

[PeterPawn]

Also Vorgehen 3a bei r@iner (Werkseinstellungen) löscht keine existierende "provider_additive.tar" aus dem TFFS-Node 29. Da ein dort enthaltenes korrektes TAR-File aber immer(!) ausgepackt wird (eine Möglichkeit, in ältere Firmware "einzudringen", besteht genau in so einer "customized"-Version dieses Tarballs, siehe hier) und dabei keine Rücksicht auf den Inhalt von "active_provider" in der "ar7.cfg" oder auf den Inhalt der "provider"-Variablen im Environment genommen wird, bleibt dann auch dieser Inhalt erhalten ... die Firmware geht (wenn die Einstellungen aus diesen Dateien angewendet wurden, weil die Box tatsächlich unkonfiguriert war) sogar hin und packt diese Datei (mit ein paar Änderungen) erneut zusammen, bevor sie wieder im Node 29 gespeichert wird.

Wenn also tatsächlich eine solche "provider_additive.tar" über einen "provider"-Eintrag im Environment vor dem Überschreiben durch Anwendung des AVM-Recovery-Programms geschützt war (nur dafür ist der Eintrag da, nach dem, was bisher bekannt ist - zumindest mir), dann existiert die auch nach dem Löschen der "provider"-Variablen weiter (vielleicht war das in einer alten Version Anfang 2016 tatsächlich noch anders) und wenn die tatsächlich mal verwendet wird, kann es auch ohne weiteres passieren, daß die Firmware selbst wieder ein "additive" als Zeichenkette in die "provider"-Variable einträgt (egal, was da zuvor bei o2, ewetel, netcologne, usw. stand - der Inhalt ist vermutlich weniger wichtig als der existierende Wert an sich) - über die genauen Rahmenbedingungen für dieses Schreiben in "provider" weiß ich aus dem Kopf auch gerade nicht Bescheid und müßte erst irgendwo in meinen Notizen suchen.

Insofern ist dieses Entfernen der Zusatzkonfiguration vom Provider tatsächlich einer der wenigen Fälle, wo das AVM-Recovery-Programm zu recht zum Zuge kommen sollte ... oder man schreibt irgendwie anders ein "sauberes" TFFS-Image ohne diesen Node für die Minor-ID 29. Die Frage, ob es in so einem Falle eine "provider_additive.tar" überhaupt gibt, stellt sich eigentlich auch nicht mehr ... die "provider"-Variable dient ja (wieder nur nach dem was wir so wissen) gerade zum Schutz dieser Datei (vor dem AVM-Recovery) und wäre ohne ihre Existenz eher sinnlos.

Es kann durchaus sein, daß die Beschreibung bei r@iner mal stimmte ... aber die oben von mir verlinkte Lücke funktionierte tatsächlich nicht nur bei der 6490, wo sie dann für das Erlangen eines Shell-Zugangs auch (zumindest eine Zeit lang) aktiv genutzt wurde - Einzelheiten finden sich in unserem großen Thread zur 6490. Meine eigenen Erfahrungen zum Umgang des FRITZ!OS mit dieser "provider_additive.tar" stützen sich auf Versionen jenseits der 06.5x - für Versionen davor will ich mich nicht festlegen.

 

[Shirocco88]

Das Entfernen der Provider-Additive.tar Datei könnte auch mit einem clear_minor_node_dec29.image analog zu build_reset_tainted_image erfolgen;
Quelle:
https://www.ip-phone-forum.de/threa...l-recovery-a-la-avm-oder-besser-nicht.294386/
https://github.com/PeterPawn/YourFritz/blob/master/toolbox/build_reset_tainted_image

Line 371/372:

printf 'clear_id 87\n' >/proc/tffs
printf 'cleanup\n' >/proc/tffs

sind durch entsprechende Befehle, z.B.

echo "provider" > /proc/sys/urlader/environment
mkconfigfile /var/tmp/minor-c-code_dec29.tar 29
cat > /var/tmp/minor-c-code_dec29.tar

zu ersetzen; anschließend das clear_minor_node_dec29.image mittels "eva_tools" (PowerShell-Variante: EVA-Discover.ps1, EVA-FTP-Client.ps1 oder Shell-Variante: eva_discover, eva_to_memory) anstarten.

Dies als Alternative zu klassischem Recovery; als Einsatzzweck wäre Providerwechsel mit "Entfernen der Provider-Additive ohne Werksreset (Löschen des NAS-Speichers, DECT-Pairing, Telefonbuch, ...)" denkbar.

 

[PeterPawn]

mkconfigfile /var/tmp/minor-c-code_dec29.tar 29
cat > /var/tmp/minor-c-code_dec29.tar

Ein einfaches "printf 'clear_id 29\n' >/proc/tffs" macht es hier aber auch ... oder wo wäre der Vorteil der "cat"-Methode, wenn man keine Daten schreiben will? In diesem Falle wäre es klar ... und natürlich wäre so ein eigenes Image beim Start über den Bootloader auch eine Alternative, wenn man eigene Daten in Node 29 bringen wollte - man muß das ja nicht immer über ein komplettes TFFS-Image machen.

Wobei letzteres eben i.d.R. direkt vom Bootloader aus möglich ist ... bei der 6490 hat es sich m.W. noch nicht herumgesprochen, wie die aus einem Image im Speicher zu starten wäre und damit wäre diese Methode bei der 6490 nicht anwendbar gewesen, weshalb dort auf die Image-Methode zurückgegriffen werden mußte.

 

[Shirocco88]

Ein einfaches "printf 'clear_id 29\n' >/proc/tffs" macht es hier aber auch

Danke!!!
die clear_id Direktive war mir so nicht bekannt;