Unitymedia Technicolor TC4400 FW Update Wie?

[Andreas1969]

Das TC4400 wird ja aktuell mit dem FW-Stand "SW70.12.20" ausgeliefert.
Mittlerweile ist Technicolor aber beim FW-Stand "SW70.12.30a" angekommen.
Das würde eventuell das DS-Lite Problem lösen.

Laut Datenblatt lässt sich eine neue FW aber nur seitens des Providers aufspielen:

Software upgrade via WAN RF connection only

Hat jemand ne Idee, wie man die FW noch anderweitig auf das Modem bekommt?
Das müsste sich doch auch über eine UART bzw. serielle Schnittstelle mit dem CLI einspielen lassen :kratz:
Oder wie nimmt Technicolor sonst die Erstbetankung vor Auslieferung im Werk vor?
Da gibt es doch sicherlich eine Hintertür.

Über das WebIF bin ich da noch nicht so recht weiter gekommen, oder ich habe den Punkt noch nicht gefunden.
Vielleicht hat ja noch jemand den entscheidenden Tipp, wie ich die neue FW auf´s Modem bekomme.

 

[perryair]

Bilder von der Platine würden da Wahrscheinlich die ersten Anhaltspunkte geben.
Aber das macht schon Sinn für die Provider das die Firmware nur über deren System geht,
sonnst währe ja Manipulationen an der Tagesordnung.

 

[#DiRK]

Meine Vermutung nach einer ersten, kurzen Recherche im Internet:
Updates der Firmware funktionieren ähnlich wie der Download von Konfig.dateien - nämlich über einen Provider-TFTP-Server, welcher über die initiale DHCP Provisionierung mitgeteilt wird.

Siehe auch:
https://volpefirm.com/cable-modem-registration-a-second-look/

https://www.slideshare.net/nullbytecon/nullbyte-2015-hackingcablemodemsthelateryears

 

[perryair]

Also gibt es über den Provider erst irgendwelche Updates wenn der Anteil an bestimmten Endgeräten
so hoch ist das sich der Provider vom Hersteller das bezahlen lassen kann....

 

[Andreas1969]

Ah, interessant.
Im WebInterface kann ich ja einen FTP Server angeben.
Eventuell kann man da ja doch was hinbiegen.
Man kommt ja aus dem Netzwerk auf die 10er Adresse des Modems, dann müsste das Modem ja anders herum auch auf eine Adresse im Netzwerk kommen :kratz:
Wenn ich jetzt einen FTP Server im Netzwerk habe und dort die FW Datei hinlege, vielleicht zieht sich das Modem die ja dann :kratz:

 

[#DiRK]

TFTP-Server, nicht FTP-Server

https://de.wikipedia.org/wiki/Trivial_File_Transfer_Protocol

Der Ansatz ist meines Erachtens grundsätzlich möglich, sofern nicht die Security im Modem auf der LAN-Schnittstelle derartige Aktionen verbietet.

Dennoch müsstest du dem Modem (via DHCP) mitteilen:
- Adresse des TFTP-Server
- Filename des Firmware Files

 

[#DiRK]

Schon mal einen Binwalk auf die Firmware gemacht? Vllt. sind ja obige Parameter zusätzlich als Default-Wert hart-codiert?!?!

 

[Andreas1969]

Dennoch müsstest du dem Modem (via DHCP) mitteilen:
- Adresse des TFTP-Server
- Filename des Firmware Files

Na, das macht es nicht gerade einfach.
Ich muss mal im WebIF schauen, ob man da auch einen Namen angeben kann.
Dann noch 2 andere Ansätze:

Modem vom UM Netz trennen, Rechner mit TFTP Server direkt an die WAN Schnittstelle des Modems hängen.

Oder ein unprovisioniertes Modem an's UM Netz anschließen, da bekommt der Rechner ja dann auch ne 10er IP zugewiesen...

 

[Andreas1969]

Schon mal einen Binwalk auf die Firmware gemacht? Vllt. sind ja obige Parameter zusätzlich als Default-Wert hart-codiert?!?!

Muss ich mal schauen...

 

[MartinP_Do]

Meine Vermutung:
Die initiale Firmware des Modems wird entweder vor den Bestücken der Leiterplatte in der Fabrik in die noch nicht verbauten Flash-ROMs geladen oder bei der Montage der Leiterplatte in das Gehäuse über eine JTAG-Schnittstelle auf das bereits aufgelötete ROM...
Falls man auf der Leiterplatte die JTAG-Schnittstelle identifizieren kann, und ein passendes Image der neue Firmware finden kann, KÖNNTE man über diese JTAG-Schnittstelle das Flash-ROM programmieren.

Folgt man dieser Passage, könnte aber Technicolor auch Maßnahmen ergriffen haben, die JTAG-Schnittstelle nach der Fertigstellung des Modems unzugänglich zu machne.
https://de.wikipedia.org/wiki/Joint_Test_Action_Group#JTAG_und_Computer-Sicherheit


Mit einem PC mit Parallelport und Linux kann man eine JTAG-Schnittstelle einfach bewerkstelligen...
https://wiki.openwrt.org/doc/hardware/port.jtag.cable.unbuffered
https://wiki.openwrt.org/doc/hardware/port.jtag.cable.buffered


Ist natürlich ein nicht unerhebliches Risiko, das TC4400 Modem bei den Experimenten zu Kernschrott zu verwandeln ... Manchmal ändern sich z. B. in der Serie Bauteile auf den Leiterplatten, ohne dass der Hersteller das kundtut - da kann dann ein ROM-Image für die alte Bestückungsvariante fatal wirken...

Den JTAG-Port würde ich als "Plan B" im Hinterkopf behalten. Bei der Variante mit dem TFTP-Server gibt es wahrscheinlich vor dem Brennen durch das Modem selber eine Kompatibilitätsprüfung des Images mit Verweigerung des Brennprozesses, falls das Image inkompatibel zur Hardware ist... Das sollte das Risiko eines Totalverlustes stark minimieren ...

 

[Andreas1969]

und ein passendes Image der neue Firmware finden kann,

Ist vorhanden, passt auch zur HW Rev. des Modems :winken:

Bei der Variante mit dem TFTP-Server gibt es wahrscheinlich vor dem Brennen durch das Modem selber eine Kompatibilitätsprüfung des Images mit Verweigerung des Brennprozesses, falls das Image inkompatibel zur Hardware ist... Das sollte das Risiko eines Totalverlustes stark minimieren ...

Das wäre jetzt auch meine bevorzugte Variante

 

[MartinP_Do]

Das wäre jetzt auch meine bevorzugte Variante

Daneben gibt es eine Unzahl verschiedener Varianten von Formaten für ROM-Images. Theoretisch wäre sogar möglich, dass die Images verschlüsselt sind, und nach dem Laden in das RAM des Modems eine Entschlüsselungsroutine durchlaufen müssen, die in der Firmware über die Versionen vorhanden ist ... es werden wahrscheinlich Maßnahmen dagegen getroffen worden sein, dass jemand ein Image reverse-engineered, dieses manipuliert, und dann einfach in das Modem laden kann ...

 

[Andreas1969]

Daneben gibt es eine Unzahl verschiedener Varianten von Formaten für ROM-Images. Theoretisch wäre sogar möglich, dass die Images verschlüsselt sind, und nach dem Laden in das RAM des Modems eine Entschlüsselungsroutine durchlaufen müssen, die in der Firmware über die Versionen vorhanden ist ... es werden wahrscheinlich Maßnahmen dagegen getroffen worden sein, dass jemand ein Image reverse-engineered, dieses manipuliert, und dann einfach in das Modem laden kann ...

Naja. es ist ja das aktuellste FW Image vom Hersteller.
Das sollte doch wohl keine Probleme bereiten. :kratz:

 

[MartinP_Do]

Die Fritzbox hat ja ein Zertifikat an Bord. Ich vermute, dass das andere Modems auch haben. Möglicherweise ist dieses nicht nur dazu gedacht, dass die Provider vor unter falscher Flagge segelnden Modems im Segment geschützt sind, sondern dienen auch in die Gegenrichtung zur Absicherung des TFTP-Transfers beim Firmware-Update. Standardmäßig bietet das TFTP - Protokoll aber solch eine Absicherung anscheinend nicht ...

 

[Andreas1969]

Für das Management gibt es wohl auch noch andere Anmeldedaten

<X_BROADCOM_COM_LoginCfg>
<AdminPassword>KG51bGwpAA==</AdminPassword>
<SupportPassword>KG51bGwpAA==</SupportPassword>

Die hatte ich ja schon mal aus dem Modem ausgelesen, aber bisher noch nicht probiert.
Vielleicht tauchen ja dann im WebIF noch ein paar Menüpunkte mehr auf :kratz:

 

[Leseratte10]

Ich denke eher das deutet auf ein nicht gesetztes Passwort / einen unbenutzten Wert hin - "(null)" klingt nicht nach einem Passwort.

 

[nts]

Was gibt es in der Firmware denn für Neuerungen, für die es sich lohnen würde die Kiste aufzubrechen? Abgesehen davon, dass das TC4400 derzeit noch keine LA unterstützt (und vielleicht den Problemen mit DS-Lite), läuft das Teil doch sehr gut.

Im WebInterface kann ich ja einen FTP Server angeben.

War das nicht einfach eine Logfunktion, bei der man die Logfiles automatisch auf den angegebenen FTP Server laden lassen kann? Ich hab's nicht ausprobiert, aber die meisten anderen Punkte in diesem verstümmelten Router-Web-IF waren ja sowieso ohne Funktion.

 

[Andreas1969]

dass das TC4400 derzeit noch keine LA unterstützt (und vielleicht den Problemen mit DS-Lite)

Genau darum geht´s ja.
Ansonsten gebe ich Dir Recht, das Teil läuft mit der FW SR70.12.20 absolut stabil.

 

[perryair]

Vlt geht ja was über die RDK-B Software

Laut Broadcom Link

Beschreibung Technicolor Link

RDK Cental Wiki Link

 

[y0r]

Das Modem hat unter /mnt folgende Verzeichnisse: usb, nfs, hd, flash, cmnonvol, cmnonvol_bak, apps
Aber einen externen USB Port hat es nicht. Vielleicht auf der Platine?
Weiterhin hat es jede Menge Scripte im Firmware Image. Bin noch nicht dazu gekommen diese genauer zu untersuchen aber da gibt es bestimmt einen Mechanismus, SSH zu aktivieren.
Hier die passwd:
root::0:0:root:/root:/bin/sh
bin:*:1:1:bin:/bin:/dev/null
daemon:*:2:2:daemon:/sbin:/dev/null
adm:*:3:4:adm:/var/tmp:/dev/null
ftp:*:14:50:FTP User:/var/tmp:/dev/null
nobody:*:99:99:Nobody:/:/dev/null
rpcuser:x:29:29:RPC Service User:/var/tmp:/dev/null
client:x:1000:100:Nexus client:/:/bin/sh
user1001:x:1001:100:User ID 1001:/:/bin/sh
user1002:x:1002:100:User ID 1002:/:/bin/sh
nfsnobody:x:65534:65534:Anonymous NFS User:/var/tmp:/dev/null

Edit: Es muss intern einen USB Port geben, da in den Scripten oft die Rede von einem USB Ethernet Dongle ist. Meine Vermutung ist, dass darüber Services gestartet werden, sobald ein (bestimmter?) Dongle angeschlossen wurde.

 

[y0r]

BTW: Die FTP Option kann doch von "get" auf "put" umgestellt werden. Da könnte man es mal versuchen das neue Image hochzuschieben.

 

[perryair]

Das klingt nach einer guten möglichkeit

 

[y0r]

Ich habe die init-Scripts aus /etc/init.d unter http://filehorst.de/d/cDxytEsb hochgeladen. Schaut sie euch mal an.

 

[perryair]

also ein Blick auf die Platine würde ich gerne mal werfen...

{	PART=$1	DEST=$2	#Wait for a usb stick	until find_thumbdrive; do	echo "Waiting for USB"	sleep 1	done	echo "Found USB at /dev/${thumbdrive}"	#Some rare USB sticks can report "no media inserted"... access once to	#bypass this. Also it seems some delay is required for it to	#report media is available	#(tbd... could grep for FAT here to determine if partition	#table exists or not? i.e. /dev/sda vs. /dev/sda1)	sleep 1	#dd if=/dev/${thumbdrive} bs=1024 count=1 > /dev/null	mount /dev/${thumbdrive}${PART} $DEST	return $?

ROOTFS_ROOT=flash1.cm
rg_part=flash1.rg
stb_part=flash1.stb
RG_NONVOL_PARTITION=flash0.rgnonvol
CMNV_NAME=flash0.cmnonvol0
CMNV_NAME_BAK=flash0.cmnonvol1
RUN_PATH=/mnt/flash
IMAGE_PATH=/mnt/flash	# Is this a flash boot?	echo "Detected boot to non-flash rootfs, defaulting to mirror 0"	# Flash boot, which mirror did we boot from?	if [ "${VFLASH_PRESENT}" = "y" ]	modprobe vflash_server.ko part_names0=flash1.rg$mirror_index,$RG_NONVOL_PARTITION	modprobe vflash_server.ko part_names0=flash1.rg$mirror_index,$RG_NONVOL_PARTITION	# Is this a flash boot?	echo "Detected boot to non-flash rootfs, defaulting to stb and rg mirror 0"	#flash boot, which mirrors do we need to boot from?	svm_mirror_index=$(echo ${bootstring#*ubi.mtd=flash1.svm} | cut -d " " -f 1)	if [ "${VFLASH_PRESENT}" = "y" ]	if [ "${STB_VFLASH}" = "y" ]	modprobe vflash_server.ko part_names0=${rg_part}${rg_mirror_index},$RG_NONVOL_PARTITION part_names1=${stb_part}${stb_mirror_index}	modprobe vflash_server.ko part_names0=${rg_part}${rg_mirror_index},$RG_NONVOL_PARTITION	if [ "${STB_VFLASH}" == "n" ]
#Mount images to /mnt/flash, if failed, switch idx and retry
# #scrub_flash.sh $springevent # Use UBIFS apps flash image if $(ls /proc/device-tree | grep -q vflashclient) APPS_NAME=flash1.rg$rgindex	VFLASH_PRESENT=n	# STB flash partition present?	STB_VFLASH=y	STB_VFLASH=n	#Vflash device tree node is not always present...	#Assume vflash server is needed if:	VFLASH_PRESENT=y	VFLASH_PRESENT=y	echo "VFLASH: ${VFLASH_PRESENT}"	echo "VFLASH: ${VFLASH_PRESENT}"	echo "STB VFLASH: ${STB_VFLASH}"	echo "STB VFLASH: ${STB_VFLASH}"
#To support redundant flash partitions, a series of BOLT variables is used
#Erase a flash partition by name	flash_erase -q -j /dev/mtd${MTD} 0 0	flash_erase -q /dev/mtd${MTD} 0 0
#Mount a flash partition to a given location	if $(ls /proc/device-tree | grep -q vflashclient)	DATA_NAME="flash0.rgnonvol0"	DATA_NAME_BAK="flash0.rgnonvol1" # Use UBIFS apps flash image APPS_IMG_VFLASH_PART=0 CFG_IMG_VFLASH_PART=0 [ -e /dev/ubi0 ] || ubiattach -m $APPS_IMG_VFLASH_PART -d 0

 

[y0r]

Ich sag's ja, das Ding reagiert auf USB.
Und wer öffnet nun sein Modem?