R&S RTB2004 Snooping

[ElectronMan]

The OTPData SCPI command appears to just write data to Block 0, Page 0. It does disable ECC before doing this, but I don't see it writing into the spare area.

Maybe you have to set the block/page with another command prior to read.

It is using the altera hwlib command. It takes care of that, but the first parameter is the START page/block and is set to 0. Technically it could be writing any number of pages, but it certainly looks like it starts at address 0.

[uski]

FYI I tried decrypting the firmware for the RTM3000 series scopes with the same key and it didn't work. Meh.

[ElectronMan]

FYI I tried decrypting the firmware for the RTM3000 series scopes with the same key and it didn't work. Meh.

Did you try this one?
https://www.eevblog.com/forum/testgear/rs-rtm2000-has-anybody-hacked-this-scope/msg3282494/#msg3282494

[Harjit]

Wondering if anyone has updates? This was fascinating to follow along.

[uski]

Hi

I am trying to identify the part number for a matching connector for the JTAG connector. Any idea ?
Pre-made cables would be even better but that's probably a stretch

Thanks

[Kean]

Hi

I am trying to identify the part number for a matching connector for the JTAG connector. Any idea ?
Pre-made cables would be even better but that's probably a stretch

Thanks

Looks like a Molex Picoblade 1.25mm pitch 10 way.  https://www.molex.com/product/picoblade.html
PCB connector is 53398-1071.  Receptacle housing is 51021-1000.  Contacts are 50079-8000 or -8100.

I suggest buying pre-crimped leads as the proper crimp tool is very expensive!
They can be bought from Mouser/Digikey/Aliexpress/etc - e.g Digikey 0500798000-12-R8-D

Or you can buy a complete pre-made cable assembly and cut it in half to splice to your own JTAG interface - e.g. 150mm long Digikey WM17230-ND Molex PN 0151341002

[mikeselectricstuff]

I suggest buying pre-crimped leads as the proper crimp tool is very expensive!
They can be bought from Mouser/Digikey/Aliexpress/etc - e.g Digikey 0500798000-12-R8-D

Or you can buy a complete pre-made cable assembly and cut it in half to splice to your own JTAG interface - e.g. 150mm long Digikey WM17230-ND Molex PN 0151341002

Absolutely - very hard to crimp the contacts without the proper tool. 

[ElectronMan]

I ended up getting these: https://www.amazon.com/gp/product/B07PWZTC88/ref=ppx_yo_dt_b_asin_title_o07_s01?ie=UTF8&psc=1

And then I took the 8 pin, and a 2-pin, and trimmed down the edges so they would fit together. I then pulled the 1-pin connectors off the other end and put them into a block to fit the JTAG pinout of my J-link.

It's not ideal, but it worked for me.

[Kean]

And then I took the 8 pin, and a 2-pin, and trimmed down the edges so they would fit together. I then pulled the 1-pin connectors off the other end and put them into a block to fit the JTAG pinout of my J-link.

Yes, that is a good solution - although you can buy a pack of the 10 pin housings for a few bucks and transplant the crimped ends across to one.

[Harjit]

Fantastic! You all are really good. I just spent a few minutes looking at JST connectors but didn't find a match.

[uski]

I got this : https://www.amazon.com/gp/product/B07XHW1959/
Will report if they fit or not when I receive my scope

[Harjit]

Any updates?

[trimen]

I was able to dump my scope via JTAG, it took only about 4-5 hours and I didn't encounter any JTAG related errors. (I used XDS100v3)

In my unit, there wasn't placed Molex picoblade connector, so I populate it myself.

For anyone interested I can provide dumped images for comparison.

[AnJu]

I was able to dump my scope via JTAG, it took only about 4-5 hours and I didn't encounter any JTAG related errors. (I used XDS100v3)
For anyone interested I can provide dumped images for comparison.

Please to provide your NAND image.
anjugm gmail com

[sergeyklenov]

Whatever "filesystem" they are using seems to place 16 bytes of NAND management data at the beginning of each block after block 0 (possibly data for previous block?) I did not look too much at that and just discarded it, as it was corrupting the extracted firmware sections.

Doing it methodically:

The first 0x08000000 bytes (128 MB) are perfect. All the bytes in the right place and we can see all the previous FW versions fully stored there. I wonder when they start writing on top of each other since we have the 128 MB almost all filled up.

The problem rises after the 0x08000000 as the dump starts having this format:

- a macro-block of 8 blocks of 0x4000 bytes (with the first 16 bytes being OOB) but the last block not having its own 16-bytes OOB.

This repeats itself up to file's end.

I've just reread your dumping explanation and I'm sure that your "The script strips out the 16 byte block header that is on blocks 1 - 4095."  was not correctly executed on the whole NAND dump.  So you did strip out the OOB data on the first 128 MB but not on the rest (at least not fully, as one of the 8 consecutive blocks has it strippeed out)?

I extracted the remaining OOB stuff, concatenated its contents and did some sanitization of certain patterns that seem to be flashed previously on the NAND (before writing newer files).

The remaining information seems to be some settings files and huge log files. I think even the calibration logging is there. But, I have a feeling something may be missing...

I'm not very good at interpreting perl stuff, so some questions remain as I can't verify your scripts fully:

- The last 384 MB must have a stripping/extraction error. Can you please verify.
- If you did extract 512 MB we should have 536.870.912 bytes. We have 512 MB - 4095 x 16 bytes.

It looks like the first 0x2000 blocks (of 0x4000 bytes) had their OOB data correctly stripped but the rest not. And if so, and you tried to also strip them in the rest of the data, then you stripped some good data (which was not the OOB portions).

Here is the output from a SCPI command to the flash memory. But I do not know exactly what it means. Maybe it helps a little bit.

I'll try to have a look, Peter.

I recall when working with a mostly-complete unaltered dump before that the 16-byte block headers may have ended later in the flash. I am taking a raw image now.

My scope indicates it has ~380M of free internal flash memory, so I don't think there's anything major missing. I have noticed a few things like screenshot thumbnail BMP files in the last 3/4 of the flash, alignment logs, and possibly mask files.

Yes, really content repeat each 0x2000 after 0x8000000

i think mistake in setting page for nand reading.

[sergeyklenov]

For info: i found in flash MSDOS5.0 FAT16 table. So i think this NAND formatted as usual PC disk.

[ElectronMan]

For info: i found in flash MSDOS5.0 FAT16 table. So i think this NAND formatted as usual PC disk.

There are references to that in the firmware, but it is specifically for the USB disk emulation when you connect your RTB to your PC via USB. There are also components that allow mounting USB drives. The flash filesystem itself is not DOS compatible.

[uski]

Hi,

I have soldered the missing 10-pin connector on my oscilloscope.

I had to extremely carefully remove the solder on the connector pads with a bit of flux and desoldering braid.
There are 0201 resistors nearby and significant ground heatsinking, so this is not for beginners...

Then, I soldered the connector, and made a custom cable with only the relevant pins (less pins = less force to remove = less chance to damage something = better)

I used the following:
- Pre-crimped cables: DigiKey 0500798000-12-L8-D-ND which I cut in half
- SMD connector: DigiKey WM7614CT-ND
- Housing: DigiKey WM1728-ND

Now, on to JTAGing...

[skander36]

Success!
It took me about 5 hours using a JTAG interface (TMS320-XDS100-V3) which is considered high speed and OpenOCD.
I'm curious how long it will took you.

[uski]

So because I am so late into the party, I needed to update a few things to get the openocd script to work.

First, I had an issue where the syntax of the "target create" command no longer accepts the chain-position parameter, I rather had to create a dap separately.

I have followed the guide here: https://visualgdb.com/support/chainposition/

The resulting script is:

Code: [Select]

source [find interface/jlink.cfg]
reset_config trst_and_srst
if { [info exists CHIPNAME] } {
   set _CHIPNAME $CHIPNAME
} else {
   set _CHIPNAME fpgasoc
}
if { [info exists DAP_TAPID] } {
        set _DAP_TAPID $DAP_TAPID
} else {
        set _DAP_TAPID 0x4ba00477
}

jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x01 -irmask 0x0f -expected-id $_DAP_TAPID
adapter_khz 4000

dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpu

set _TARGETNAME1 $_CHIPNAME.cpu.0
target create $_TARGETNAME1 cortex_a -dap $_CHIPNAME.dap -endian little -coreid 0 -dbgbase 0x80110000
init
cortex_a dbginit

If anyone is more familiar with OpenOCD than I am, and can check that I did this right, feel free to take a look.

I am now downloading the flash using the rtb_nand_dump.pl script (thanks ElectronMan for the fantastic background work in post #1, really couldn't have done it without you).

I am using a clone JLink V9 (this is what I had in stock...). It had an internal VTref of 3.3V, and I didn't have an exposed 2.5V on the connector of the scope, so I switched the AMS1117 3.3V LDO that creates that reference inside the probe to a 2.5V one (the scope uses 2.5V signals). I don't seem to have issues reading the data, and I checked the signals with a voltmeter and all is at 2.5V.

As to the speed, here is a quick measurement:

Code: [Select]

$ ls -l RTB_NAND_IMAGE.img && sleep 60 && ls -l RTB_NAND_IMAGE.img
-rw-rw-r-- 1 x x 16191568 Nov  5 13:20 RTB_NAND_IMAGE.img
-rw-rw-r-- 1 x x 17897344 Nov  5 13:21 RTB_NAND_IMAGE.img
1705776 bytes per minute. Image is 512MB. 512*1024*1024/1705776=314 minutes, so around 5 hours if all goes well (no interruptions - hopefully my probe is stable)

Stay tuned! 

[EDIT] Image file seems to contain valid data so far. I can see the bootloader that was discussed previously at the beginning of the image, with legible text etc.

[skander36]

As I have different adapter i have used this script (thanks Trimen!) :

#source [find interface/jlink.cfg]
source [find interface/ftdi/xds100v3.cfg]
#source [find target/altera_fpgasoc.cfg]

adapter speed 5000

transport select jtag

reset_config trst_and_srst


# Altera cyclone V SoC family, 5Cxxx
#
if { [info exists CHIPNAME] } {
   set _CHIPNAME $CHIPNAME
} else {
   set _CHIPNAME fpgasoc
}

# CoreSight Debug Access Port
if { [info exists DAP_TAPID] } {
        set _DAP_TAPID $DAP_TAPID
} else {
        set _DAP_TAPID 0x4ba00477
}

jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x01 -irmask 0x0f \
        -expected-id $_DAP_TAPID

# Subsidiary TAP: fpga
if { [info exists FPGA_TAPID] } {
   set _FPGA_TAPID $FPGA_TAPID
} else {
   set _FPGA_TAPID 0x02d020dd
}
#jtag newtap $_CHIPNAME.fpga tap -irlen 10 -ircapture 0x01 -irmask 0x3 -expected-id $_FPGA_TAPID

set _TARGETNAME1 $_CHIPNAME.cpu.0
#set _TARGETNAME2 $_CHIPNAME.cpu.1

# A9 core 0
dap create $_CHIPNAME.dap  -chain-position $_CHIPNAME.cpu
target create $_TARGETNAME1 cortex_a -dap $_CHIPNAME.dap \
 -coreid 0 -dbgbase 0x80110000

$_TARGETNAME1 configure -event reset-start { adapter speed 1000 }
$_TARGETNAME1 configure -event reset-assert-post "cycv_dbginit $_TARGETNAME1"

# A9 core 1
#target create $_TARGETNAME2 cortex_a -dap $_CHIPNAME.dap \
#        -coreid 1 -dbgbase 0x80112000

#$_TARGETNAME2 configure -event reset-start { adapter speed 1000 }
#$_TARGETNAME2 configure -event reset-assert-post "cycv_dbginit $_TARGETNAME2"


proc cycv_dbginit {target} {
        # General Cortex-A8/A9 debug initialisation
        cortex_a dbginit
}

init; ftdi_set_signal PWR_RST 1; jtag arp_init
init
#jlink targetpower on

#targets

#targets $_CHIPNAME.cpu.1
#halt
#targets $_CHIPNAME.cpu.0
#halt

halt

targets