So I want to investigate the TG788vn v2, of which I have two.
The reason? ultimately modding the hosts file to include and block all the Windows 7/8/8.1/10 telemetry adresses.
I have a hardware serial connection, and root SSH access through the smb exploit.
Now before I begin bricking it again flashing left and right with mtd_debug, I would really like a complete JTAG NAND dump. So I have been trying to enable the 14-Pin JTAG port next to the serial port:
Info:
ST ST_NAND512W3A 64MB, 64MB NAND, blocksize=16KB, pagesize=512B
CPU : BCM63168-D0
CPU revision is: 0002a080 (Broadcom4350) : 399.36 BogoMIPS
Google says Huawei HG658c has the same CPU
Boot Loader Version : 2.0.16
Linux version 2.6.30 (gcc version 3.4.6)
#Booting bank two
0x000002b50000-0x000003ea0000 : "rootfs"
Creating 5 MTD partitions on "technicolor-nand-tl":
0x000000080000-0x000001600000 : "userfs"
0x000001600000-0x000002a50000 : "bank_1"
0x000002a50000-0x000003ea0000 : "bank_2"
0x000000020000-0x000000040000 : "eripv2"
0x000000040000-0x000000080000 : "rawstorage"
0x000002a50000 + 0x000000100000 to 0x000003ea0000 = rootfs
So rootfs is bank_1/2 minus a header of 0x000000100000
Secondary rootfs gotta be bank_2 - the same header
I also have the compiled binaries and I am able to create a valid lzma squashfs v. 4.0 image and mount it through SSH. So building a proper rootfs should be no problem, flashing it though...
I also did a complete backup using dd if=/dev/mtdblock0 of=/var/mtdblock0.bin , but I'm not sure this can be flashed with JTAG, and jtag isnt even working.
So if I mess up the CFE, I will be boned.
After all this, I am still pretty well and truly confused, so any hints, no matter how simple, are greatly appreciated.
I'm new to this forum and found your post while looking for answers myself. I'm trying to download the flash from a Technicolor TG799TSvn v2, which I believe can't be that far away from a TG789.
I'm too unsuccessful in getting a JTAG connection with the device. Tried both a buffered Wiggler cable, and a now gpio with Raspberry pi B. Same result, openocd finds a chip (can't tell if it's 0x7204B04F because it's not hooked up right now, but it surely is close, that's for sure). Urjtag fails with both cables, claims TDO is stuck to 0.
I too have followed the connections which seems to run all the way to the cpu. Double checked my soldering, cables, etc.
So I'm thinking - could it be that Thomson disabled the JTAG feature? Has ANYONE successfully read any of these devices? I'd be happy to hear about any of your progress.
Not exactly the same cpu, but close enough. Regarding the jtag, I also suspect something is funny with the TRST pin. Openocd seems to control it and pulls it high, while urjtag keeps it floating (which gives a 0 since it's pulled down).
So I naturally tried running urjtag with a 300Ohm pull-up on the nTRST, but no luck. Actually, it seems strange to have a pull-down on that pin. Perhaps it's a TRST, not nTRST? I wonder if openocd/urjtag can even handle that. Have you tried to invert it with a NOT-gate or similar? That will have to be my next step.
Btw, I don't have ssh access on mine at all, would you point in the right direction on how to do that? I have some experience with metasploit if that's needed. My unit is running a locked firmware to which I have only limited access. I can activate ftp, smb, media content sharing and stuff like that, but not telnet/ssh. Thanks!
I don't have a clear cut set of instructions to get ssh.
But it involves creating an EXT2/EXT3 usb key.
Create a symlink folder called 'rootfolder' which points to '\' directory.
It's basicly a folder shortcut from the usb drive to the device root dir.
Once the device mounts and shares the key, you can browse to the keys' symlink folder. Like
\\10.0.0.2\UsbKey\rootfolder\etc
\\10.0.0.2\UsbKey\rootfolder\var
\\10.0.0.2\UsbKey\rootfolder\ dosn't work.
Once you can get that, you can upload a dropbear MIPS binary, and execute it by modifying the smb.conf to execute the commands on connection.
I did make a script to automate that part, as it clears on reboot. But gives you software access to the nand.
I havn't tried any more of JTAG'ing my TG799, I'm still waiting for an USB JTAG device from ebay, but in the CLI i found something that you might want to look into.
There is a "system debug engineering unlock" feature that warns the user that:
Quote:
---------------
!! WARNING !!
---------------
Specifying a valid tag will transform this board into a developer board!
If you continue, the board could not be used in a production environment anymore!
tag =
Just maybe that enables JTAG, but perhaps I'm just naive. What do you think? Do you know where the tag for unlocking this can be found?
I can take a look with IDA Pro, see if it's a hardcoded tag or what. Might be something there. I don't think I have the command on my box, but I will check later. If not, I might need a dump to go through.
I know this is an old discussion but I had recently had the opportunity to give a look at newer technicolor devices which substantially works the same way for what concerns the bootloader.
I have a couple of questions about your experience with this old tg799 that I would really appreciate to get answered.
First, @TAz00, how you managed to get the smb daemon to reload the smb.conf file? And what you edited to get it run the binary you uploaded? (edit: I sorted this out, it does not need reload, and it's just a matter of setting up samba "properly")
Second, what urjtag version you tried? Do you remember if you used any custom patches to get there?
I'm trying to figure out if these devices have the jtag port disabled by secure-boot features burnt into efuses or it is the bootloader that disables the port at boot time. So I would like to reproduce your result to investigate a bit more the situation.
Made some steps further into the JTAG thing of my 799vn v2.
First, I had your same results with meaningless Chip IDs from zJTAG 1.0 and 1.8-RC3, as well as "TDO stuck at 0" from UrJTAG 0.10.0 and latest 2018.09. My jtag adapter is a TUMPA.
After some random experiments, I loaded this one (https://github.com/cyphunk/JTAGenum) on my Wemos D1 (which is an esp8266 powered arduino uno compatible board, which conveniently runs at 3.3V by itself) and played a little bit with results. Here is the key point: running an 'idcode scan' immediately after powering the board on cause the board to enter a strange, new mode, where all board leds are off.
Here is an old thread with a possible explaination about why timing matters and also a nice tip on how a jtag adapter should be capable of controlling this by itself: https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=704951
Back to the JTAGenum tool on the wemos, the 'idcode scan' did not produced any interesting results by itself. However, in this board mode, running a 'pattern scan' gives the final confirmation of the pinout:
Code:
> s
================================
Starting scan for pattern:0110011101001101101000010111001001
active ntrst:D3 tck:D4 tms:D7 tdo:D6 tdi:D5 bits toggled:15
active ntrst:D7 tck:D4 tms:D3 tdo:D6 tdi:D5 bits toggled:15
active ntrst:D7 tck:D4 tms:D5 tdo:D6 tdi:D3 bits toggled:2
active ntrst:D8 tck:D4 tms:D2 tdo:D6 tdi:D5 bits toggled:15
active ntrst:D8 tck:D4 tms:D3 tdo:D6 tdi:D5 bits toggled:15
active ntrst:D8 tck:D4 tms:D5 tdo:D6 tdi:D2 bits toggled:11
active ntrst:D8 tck:D4 tms:D5 tdo:D6 tdi:D3 bits toggled:11
FOUND! ntrst:D8 tck:D4 tms:D5 tdo:D6 tdi:D7 IR length: 25
active ntrst:D8 tck:D4 tms:D7 tdo:D6 tdi:D5 bits toggled:15
================================
> c
Available pins, the index is based on them
D2[0] D3[1] D4[2] D5[3] D6[4] D7[5] D8[6]
Current pin configuration
ntrst:D8 tck:D4 tms:D7 tdo:D6 tdi:D5
TCK(2) = 2
TMS(5) = 3
TDO(4) = 4
TDI(3) = 5
TRST(6) = 6
Configuration saved
That "IR length: 25" got me to remember I had seen something like that here (https://www.dslreports.com/forum/r29580886-Jtag-to-bcm63168-with-urJtag) where I had got patches for UrJTAG at first. So I went back to UrJTAG but no matter what version, patches or anything, 'detect' command does not retunr anything - at least no more "stuck at 0" - and 'idcode' returns all ones (0xff).
Differently, zJTAG does manage to get the correct idcode and also finds the same 5 chain elements in the link above. Both zJTAG 1.0 and 1.8-RC3 fail to autodetect IR len to 25, so if you use zJTAG remember to add "/instrlen:25" option: Adding "/skipdetect", they both parse the correct idcode.
Dev 0:
Flags=0x2
Type=0x6
ID=0x4038a98
LocId=0x11321
SerialNumber=TI3KURHLA
Description=TIAO USB Multi-Protocol Adapter A
ftHandle=0x0
Set I/O speed to 10000 KHz
USB TAP device has been initialized. Please confirm VREF signal connected!
Press any key to continue... ONCE target board is powered on!
Detected IR chain length = 32
There are 5 device(s) in the JTAG chain
IDCODE for device 1 is 0xFFFFFFFF (IR length:1)
IDCODE for device 2 is 0xFFFFFFFF (IR length:1)
IDCODE for device 3 is 0xFFFFFFFF (IR length:1)
IDCODE for device 4 is 0xFFFFFFFF (IR length:1)
IDCODE for device 5 is 0xFFFFFFFF (IR length:1)
Probing bus ... Done
Instruction Length manually set to 25
CPU assumed running under BIG endian
CPU Chip ID: 10000110001100100110000101111111 (0x8632617F)
CPU Manufacturer :Broadcom(ID=0x17E)
CPU Device ID :6326
CPU Revision :8
*** CHIP DETECTION OVERRIDDEN ***
- EJTAG IMPCODE ....... : 00000000100000010000100100000100 (0x00810904)
- EJTAG Version ....... : 1 or 2.0
- EJTAG DMA Support ... : Yes
- EJTAG Implementation flags: R4k MIPS16 MIPS32
Issuing Processor / Peripheral Reset ... Done
Enabling Memory Writes ... Done
Halting Processor ... <Processor did NOT enter Debug Mode!> ... Done
Clearing Watchdog ... Done
Loading CPU Configuration Code ... Skipped
Probing Flash at Address: 0x1FC00000 ...
Detected Chip ID (VenID:DevID = 0000 : 0000)
*** Unknown or NO Flash Chip Detected ***
*** REQUESTED OPERATION IS COMPLETE ***
So, IMHO, zJTAG lacks support for this SoC family, UrJTAG does not work fine with my adapter on windows at least. Switching on linux, UrJTAG, with previously mentioned patches works at least as fine as zJTAG, but this is a nand device, so the next point would be to get openocd working too.
I would therefore argue that JTAG is not really disabled on these devices after all.
