UPC Technicolor TC7200 - serial console

BloqueNegro

Please be EXTREMLY careful while using this modem. My cat somehow managed to the device. To fix it, I read I should connect a serial cable. I just bought "USB zu TTL-Konverter-Modul mit eingebautem in CP2102", that should do it.

For KabelBW in Germany I was also unable to login via telnet, I always got "invalid password". Maybe I can get some information from the KabelBW Firmware (I was not able to download that - how can I get the tftp-ip from my isp?).

BloqueNegro

Please be EXTREMLY careful while using this modem. My cat somehow managed to open the device. To fix it, I read I should connect a serial cable. I just bought "USB zu TTL-Konverter-Modul mit eingebautem in CP2102", that should do it.

For KabelBW in Germany I was also unable to login via telnet, I always got "invalid password". Maybe I can get some information from the KabelBW Firmware (I was not able to download that - how can I get the tftp-ip from my isp?).

caspase

@Bi0H4z4rD, @Cronix Sorry to necrobump, but would anyone in possession of the dumps care to share them with me? Can't PN anyone as I don't have enough posts yet.

degsie

caspase wrote: »

@Bi0H4z4rD, @Cronix Sorry to necrobump, but would anyone in possession of the dumps care to share them with me? Can't PN anyone as I don't have enough posts yet.

necrobump. verb: (internet) To revive a long dormant forum thread by adding a new post

Had to look that one up!

caspase

I've played around with the dumps, but haven't gotten any further...
The TC7200U-D6.0.1.27-131031-F-1C1.bin is a bit of a mystery. From the bootloader serial output,
the size is reported as 5298465:

Image 2 Program Header:
   Signature: a825
     Control: 0005
   Major Rev: 0100
   Minor Rev: 01ff
  Build Time: 2013/10/31 09:45:22 Z
 File Length: [b]5298465[/b] bytes
Load Address: 80004000
    Filename: TC7200U-D6.01.27-131031-F-1C1.bin
         HCS: 0046
         CRC: 87e2a6ee

the extracted size is reported as 23970120:

NandFlashRead: Reading offset 0x2080000, length 0x200
NandFlashRead: Reading offset 0x2080200, length 0x50d77d
Performing CRC on Image 2...
CRC time = 152229967
Detected LZMA compressed image... decompressing... 
Target Address: 0x80004000
decompressSpace is 0x8000000
Elapsed time 110742320
Decompressed length: [b]23970120[/b]

but the size of my file is 16777215 (0xffffff). How exactly did you obtain that file? Also, starting from offset 0xe0d0a0 there's a block of strings which seem to be related - amongst others - to the UPC web interface...

TL;DR: The file size 16777215 is too large to be the compressed data, and too small to be the decompressed data.

gsustek

hi guys,
is it possible to get better internet speed with tweeking some parameters?
how to do that?
thanks..

morter

this thread won't simply die.. anyone will be kind enough to share image with me?
thanks

BloqueNegro

I'ld also like to get a copy of that dump. Is that possible via PN?

The new firmware seems to be encrypted with an (for me) unknown key, can somebody have a look at it? I'll also supply a configuration dump later with a known password, if that may help you decrypting it.

caspase

To fuel the fire a little bit: apparently Technicolor has released sources for the TC72xx modems:

hxxps://github.com/tch-opensrc

I've tried both TC72XX_LxG1.0.10mp5_OpenSrc and TC72XX_LxG1.7.1mp1_OpenSrc. The repository descriptions mention the TC7210 and TC7230 only, no mention of the TC7200. I could get my TC7200 to download the image (option "g" in the bootloader), but it crashed before booting.

This happens when attempting to boot the initrd image (./build_gpl.sh 93383LxG initrd), but it also crashes when using the regular images (when building with ./build_gpl.sh 93383LxG)

TFTP Get Selected
Board TFTP Server IP Address [192.168.0.2]:
Enter filename [vmlinux_initrd_sto.bin]:


Destination: a5f00000

Destination: a5f00000
Starting TFTP of vmlinux_initrd_sto.bin from 192.168.0.2
Getting vmlinux_initrd_sto.bin using octet mode
..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Tftp complete
Received 1471014 bytes

Image 3 Program Header:
   Signature: 0000
     Control: 0005
   Major Rev: 0003
   Minor Rev: 0000
  Build Time: 2016/3/14 14:01:31 Z
 File Length: 1470922 bytes
Load Address: 84010000
    Filename: vmlinux_initrd_sto.bin
         HCS: b293
         CRC: 61b7f94e

WARNING: Signatures do not match!  This may be a bad image!
Image sig = 0000, chip sig = a825

Store parameters to flash? [n] n
NandFlashRead: Reading offset 0x2740000, length 0x5c

Image 3 Program Header:
   Signature: a825
     Control: 0005
   Major Rev: 0100
   Minor Rev: 03ff
  Build Time: 2014/2/24 14:02:37 Z
 File Length: 1507236 bytes
Load Address: 84010000
    Filename: LNXD6.02.07-kernel-20140224.bin
         HCS: b184
         CRC: 72a7cada

Found image 3 at offset 2840000
NandFlashRead: Reading offset 0x2740000, length 0x200
NandFlashRead: Reading offset 0x2740200, length 0x16fe00
Performing CRC on Image 3...
CRC time = 188588101
Detected LZMA compressed image... decompressing...
Target Address: 0x84010000
decompressSpace is 0x8000000
Elapsed time 1153661470

Decompressed length: 6291567
Done Copying Root File System...

Performing CRC on Image 4...
CRC time = 224147203
Detected LZMA compressed image... decompressing...
Target Address: 0x84010000
decompressSpace is 0x8000000
Elapsed time 1733865110

Decompressed length: 4914804
Copying partition table to 0x83fffc04 180
Copying partition table to 0x80000904 180

Executing Image 4...



******************** CRASH ********************
EXCEPTION TYPE: 10/Reserved instruction
TP0
r00/00 = 00000000 r01/at = 10000000 r02/v0 = 0000002f r03/v1 = 00000001
r04/a0 = 84479770 r05/a1 = 000000ee r06/a2 = ffffffff r07/a3 = 00003fff
r08/t0 = 00000034 r09/t1 = 00000001 r10/t2 = 00000001 r11/t3 = 0000000f
r12/t4 = 843b7528 r13/t5 = 84477850 r14/t6 = 00000000 r15/t7 = 00000000
r16/s0 = 00000000 r17/s1 = ffffff00 r18/s2 = 80000904 r19/s3 = 844c0000
r20/s4 = 00000004 r21/s5 = 00008023 r22/s6 = 84010000 r23/s7 = 80000800
r24/t8 = 00000010 r25/t9 = 00001021 r26/k0 = 84010000 r27/k1 = ffffff00
r28/gp = 84474000 r29/sp = 84477b40 r30/fp = 00000215 r31/ra = 8449f3c0

pc   : 0x8449f3d4               sr  : 0x10000002
cause: 0x00008028               addr: 0xffffff04

Note that I had to apply the following patch to get it to compile under Ubuntu 15.10:

diff --git a/hostTools/mtd-utils/mkfs.ubifs/hashtable/hashtable_itr.h b/hostTools/mtd-utils/mkfs.ubifs/hashtable/hashtable_itr.h
index eea699a..a1ef9f2 100755
--- a/hostTools/mtd-utils/mkfs.ubifs/hashtable/hashtable_itr.h
+++ b/hostTools/mtd-utils/mkfs.ubifs/hashtable/hashtable_itr.h
@@ -28,20 +28,14 @@ hashtable_iterator(struct hashtable *h);
 /* hashtable_iterator_key
  * - return the value of the (key,value) pair at the current position */
 
-extern inline void *
-hashtable_iterator_key(struct hashtable_itr *i)
-{
-    return i->e->k;
-}
+extern void *
+hashtable_iterator_key(struct hashtable_itr *i);
 
 /*****************************************************************************/
 /* value - return the value of the (key,value) pair at the current position */
 
-extern inline void *
-hashtable_iterator_value(struct hashtable_itr *i)
-{
-    return i->e->v;
-}
+extern void *
+hashtable_iterator_value(struct hashtable_itr *i);
 
 /*****************************************************************************/
 /* advance - advance the iterator to the next element

naunyet

Is there any update on this? So the only path ahead is to dump or download the firmware and hunt for the password in there?

I barely made 4-5 attempts when the telnet gave me:

telnet 192.168.100.1
Trying 192.168.100.1...
Connected to 192.168.100.1.
Escape character is '^]'.

Telnet connection from 192.168.1.12:32108 refused.

Your IP address has been logged and reported.

That's when I decided I would not give up let my cat play with this

caspase

The firmware can be dumped via serial console using bcm2-utils (hxxps://github.com/jclehner/bcm2-utils), but the telnet password is most likely set by your ISP's DOCSIS config file during provisioning, so dumping the firmware won't be of much use. Your best bet is to use the bootloader to flash a firmware image with the serial console enabled. What exactly are you after?

naunyet

caspase wrote: »

The firmware can be dumped via serial console using bcm2-utils (hxxps://github.com/jclehner/bcm2-utils), but the telnet password is most likely set by your ISP's DOCSIS config file during provisioning, so dumping the firmware won't be of much use. Your best bet is to use the bootloader to flash a firmware image with the serial console enabled. What exactly are you after?

I am not very familiar with DOCSIS and I admit I haven't looked up online how it works.

But if I flash the firmware:
1) will my internet stop working or it will somehow still receive the necessary settings? Or I can copy/get them from somewhere
2) what firmware image can I flash? Is there a vanilla one from Thomson? I see people here can't compile from sources
3) will my ISP notice it? Although not much important as they'd also loose their remote access to it
4) is this device supported upstream by the Linux kernel? I think not and haven't seen a Thomson fork

What I am after is using the device as I like, possibly with some customization of the daemons running there. Also I don't like my ISP being in control of enabling a WiFi they sell to people passing by. Generally my purpose is customization and security.

caspase

Does SNMP stay enabled after your modem has registered with your ISP? If so, you might be able to change the telnet password using an SNMP client.

Regarding your questions:
1. It might continue to work.
2. The Technicolor firmware of the TC7200.20 works on the TC7200.U (they're the same device, just the branding differs).
3. Quite possibly, yes.
4. This device's primary firmware is not based on Linux, but eCos. There is a secondary
firmware running on another processor, based on Linux, but this is only used to provide NAS and media server capabilities (broken on the TC7200.U, at least in STD6.02.11), nothing else. The eCos-based firmware is the only one that matters on this device.

The problem with disabling/enabling certain features is the fact that, when registering with your ISP, the modem downloads a config file which might revert some of the changes you made. So the only way in this case would be to patch the firmware itself, to permanently disable stuff.

naunyet

caspase wrote: »

Does SNMP stay enabled after your modem has registered with your ISP? If so, you might be able to change the telnet password using an SNMP client.

Will try this ASAP, although I believe not since a default scan returned only telnet and http open on the .100 address

caspase wrote: »

Regarding your questions:
1. It might continue to work.
2. The Technicolor firmware of the TC7200.20 works on the TC7200.U (they're the same device, just the branding differs).
3. Quite possibly, yes.
4. This device's primary firmware is not based on Linux, but eCos. There is a secondary
firmware, based on Linux, but this is only used to provide NAS and media server capabilities (broken on the TC7200.U, at least in STD6.02.11), nothing else. The eCos-based firmware is the only one that matters on this device.

I see. Thanks for your replies. Then I'd use the TC7200.20.

caspase wrote: »

The problem with disabling/enabling certain features is the fact that, when registering with your ISP, the modem downloads a config file which might revert some of the changes you made. So the only way in this case would be to patch the firmware itself, to permanently disable stuff.

I assume that this functionality is also in the TC7200.20; the best I could achieve is a sort of backdoor. Would this firmware accept remote upgrades from ISP? This would revert everything..

caspase

naunyet wrote: »

Will try this ASAP, although I believe not since a default scan returned only telnet and http open on the .100 address

SNMP uses UDP, and most port scanners are TCP-only by default.

I assume that this functionality is also in the TC7200.20; the best I could achieve is a sort of backdoor. Would this firmware accept remote upgrades from ISP? This would revert everything..

Yes, since this is how DOCSIS modems register themselves on your ISP's network. This firmware would accept remote upgrades, in fact, your ISP might detect that you're not using its latest firmware, and force an upgrade immediately after successful registration (this could be circumvented by spoofing the version).

PN me if you need more info.

naunyet

Yeah it's there but closed:

PORT    STATE  SERVICE
161/udp closed snmp

Given all the blockers, I am a bit demotivated to dig more into this device. It seems to have little RAM for creative purposes and hard to keep in control, but thanks for the help.

awesomedonald

Any progress made on this? This seems like the furthest anyone has got.