EEVblog Electronics Community Forum

Products => Test Equipment => Topic started by: ElectronMan on September 20, 2020, 07:23:19 pm

Title: R&S RTB2004 Snooping
Post by: ElectronMan on September 20, 2020, 07:23:19 pm
The other day I was looking at my RTB2004 and wondering what makes it tick. Given the availability of fully-optioned scopes with the COM4 bundle when it was launched, it seems to not hold a lot of interest for people to scrutinize its innards.

So, I took it apart and dug in to tease out its secrets. It is important to note that I am not focused on "hacking" licenses or anything like that. My interest is mostly in learning how it ticks.

With that out of the way, there are 3 prominent debug connectors on the bottom of the mainboard. There is a 4-pin white connector, a 10-pin white connector, and a special 12-pin red connector.

The 4-pin seems to have a 115.2kbps UART on it. It spits out unintelligible binary data immediately on boot.
The 12-pin red connector (helpfully labeled) appears to be JTAG for 2 Altera Cyclone V FPGA device instances according to openOCD.
The 10-pin white connector is the one I focused my efforts on. It is labeled HPS. This is for the Cyclone V's HPS (Dual core Arm Cortex A9 processor) that is built into their Cyclone V FPGA's, and is the primary processor that handles the UI.

(https://www.eevblog.com/forum/testgear/rs-rtb2004-snooping/?action=dlattach;attach=1070784;image)
Using this minimal OpenOCD config, I can get access to read/write memory, set breakpoints and watchpoints etc:

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 dap -irlen 4 -ircapture 0x01 -irmask 0x0f -expected-id $_DAP_TAPID
adapter_khz 4000

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

I started by examining memory dumps using OpenOCD's "dump_image" command. The memory configuration seems to put main SDRAM at memory address 0x10000000, and the CycloneV HPS memory mapping shows on-chip RAM @ 0xFFFF0000. The internal Altera Bootrom is @ 0xFFFD0000.

Access to memory is all well and good, but the contents of NAND flash would be even better. Inte'ls docs on the CycloneV HPS (https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#topic/sfo1410068585834.html (https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#topic/sfo1410068585834.html)) give detailed information on the I/O memory mapping of the NAND controller (0xFFB80000 for control, FFB90000 for data), and with openOCD it is possible to read/write these registers directly (we don't have a driver).

The NAND Flash is visible on the PCB, but just to verify functionality of the NAND controller while the CPU is halted, we can check appropriate registers with OpenOCD:
(https://www.eevblog.com/forum/testgear/rs-rtb2004-snooping/?action=dlattach;attach=1070788;image)

Doing some binary math, we can build and write a command to disable DMA on the NAND controller (necessary for our commands), select the first block and page, and read the first 16 words to verify we are getting good data.
(https://www.eevblog.com/forum/testgear/rs-rtb2004-snooping/?action=dlattach;attach=1070792;image)

With the particular command we are sending to the controller, it opens a page-size (2048 bytes) window @ 0xFFB90010 starting at the selected block/page. To get the full page we can just use openOCD's dump_image again, then select the next block/page and so forth. There are 4096 blocks with 64 pages per block with 2048 bytes per page.

A little scripting and 24hrs later (JTAG is SLOW) and you have a 512M NAND image.

binwalk returns a TON of images and files, some of the most interesting being the ELF binary executables, and the uBoot image:
(https://www.eevblog.com/forum/testgear/rs-rtb2004-snooping/?action=dlattach;attach=1070796;image)

The uboot image (via strings) has some interesting references to "MesOS" and appears to be an emergency boot image with debug capabilities:
Code: [Select]
[string]                       Writes a string.
<adr> <n>                      Loads n-bytes (binary) at <adr> in memory.
<src_adr> <n> <dst_adr>        Copys n-bytes memory from <src_adr> to <dst_adr>.
[<form> [<adr1> [<adr2>]]]     Displays memory at <adr1> to <adr2> with <form> (1, 2, 4 Byte).
<adr1> <adr2> [<pattern>]      Testing memory from <adr1> to <adr2> with <pattern> and !<pattern> (def: 0x55555555).
<adr> <value> <size>           Change memory at <adr> at <size> (1, 2, 4 Byte) to <value>.
<src_adr> <n> <dst_adr>        Copys n-bytes memory from RAM to NAND-Flash (<dst_adr> blockaligned!)
<src_adr> <n> <dst_adr>        Copys n-bytes memory from NAND-Flash to RAM (<src_adr> blockaligned!)
<dst_adr> <n> <value>          Fills n-bytes in NAND-Flash with <value> (<dst_adr> blockaligned!)
<log_adr> [<dst_adr>] [<n>]    Load and exec programm from <log_ adr> SD-Card/Nand at dst_adr ) with n-Byte (def: 0x73f33000 0x00120000 0x20000).
<adr>                          Start decrypted Update loaded at <adr>.
[<adr>]                        Quits 'MonDeb' and starts execution at <adr> (def: restart).
[<src_adr> [<n>]]              Update Monitor from RAM with <src_adr> (def.: 0x0c000000) and <n> Bytes (def.: 0x10000) AND REBOOT!!!
                               Quits 'MonDeb' and reboot at 0x0.
                               Quits 'MonDeb' and reboot at 0x0 too.
                               Displays the version of 'MonDeb'.
                               Displays the detailed version of 'MonDeb'.
                               Displays this short help.
                               Displays this short help too.
MonDeb>Quitting
Version:
Monitor & Debugger for MesOS
Hardware: CycloneVSoC
Version:
Date:     Oct  6 2016 16:40:22

The first ELF binary is ~2.2MB appears to be a firmware updater:
Code: [Select]
FWUPDATE
SERVICE
NVRAM
PWFUSB
OCFUSB
FUSB
TEST
DIAGNOSTIC
Please attach a USB flash drive containing a firmware update.
Abort!
Update failed!
Checksum incorrect!
Loading file info ... done.
No file found!
Loading file ...
The checksum of the firmware update is correct.
done.
Running update ... ! DO NOT SWITCH OFF THE DEVICE !
Reset internal memories ...
Update file OK.
Searching, please wait ...
USB flash drive ready.
File search starts in %i seconds.

The second one is ~20MB and appears to be the main binary. These are all static, stripped binaries with no relocations. The RTB2004 runs binaries bare-metal without an actual Operating system. This explains why it boots so quickly. You can see references to various memory areas via readelf, including .fpga_ram, which jives with the CycloneV HPS docs (0xc0000000 is the shared FPGA-HPS memory region).
(https://www.eevblog.com/forum/testgear/rs-rtb2004-snooping/?action=dlattach;attach=1070800;image)

I'm actually pretty impressed with what R&S has done here. Other vendors build on top of a pre-made OS. They seem to have developed their application for bare-metal and implemented it pretty efficiently. So far the most interesting stuff I have found reference a "textInit" file or folder on USB storage, but I haven't yet figured out if I can use this for something:
(https://www.eevblog.com/forum/testgear/rs-rtb2004-snooping/?action=dlattach;attach=1070804;image)
Title: Re: R&S RTB2004 Snooping
Post by: tv84 on September 20, 2020, 07:37:28 pm
Finally!  :clap:
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on September 20, 2020, 09:22:10 pm
In case anyone wants to dump their own NAND, I have attached my messy perl script.

Pre-requisites:

- Perl installed with Net::Telnet CPAN package.
- OpenOCD must be configured and connected to the device via JTAG successfully.
- OpenOCD must be listening on a user telnet port
- The top of the script has settings that must be configured.

The script will halt the CPU of the scope, disable NAND controller DMA, and start dumping. It will take many hours. You can continue a dump by specifying the 2 parameters (./rtb_nand_dump.pl <starting_block> <starting_page>) and it will append to the configured file. Launching without those starts at block 0, page 0.

The script strips out the 16 byte block header that is on blocks 1 - 4095. This appears to be part of the NAND management and corrupts files if it is not removed before processing.

[Edit to attachment: Fixed bug with restarting from a specified page/block offset]
Title: Re: R&S RTB2004 Snooping
Post by: Hydron on September 20, 2020, 11:11:44 pm
ooh, very interesting, thanks!

I have one of the launch promo units, so as mentioned there isn't such a burning reason other than curiosity to poke around, though I did have a look at the SPI bus in mine to see if the front-end VGA was doing the bandwidth limit (probably not was the answer - didn't see any change when enabling the 20MHz limit).

Did you see the R&S Open Source Acknowledgement? Sounds like FreeRTOS might be in use:
https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_osa/RTB_OpenSourceAcknowledgment_en_01.pdf
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on September 20, 2020, 11:22:11 pm
ooh, very interesting, thanks!

I have one of the launch promo units, so as mentioned there isn't such a burning reason other than curiosity to poke around, though I did have a look at the SPI bus in mine to see if the front-end VGA was doing the bandwidth limit (probably not was the answer - didn't see any change when enabling the 20MHz limit).

Did you see the R&S Open Source Acknowledgement? Sounds like FreeRTOS might be in use:
https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_osa/RTB_OpenSourceAcknowledgment_en_01.pdf

Interesting. I haven't really seen anything pointing to that, though it could be modified and renamed. As far as I can tell the main ELF is called directly from the boot loader.

I have seen a number of libraries being referenced, such as "DietCrypto" used for option keys, and there are plenty of references to this custom library and others:
"E:/jenkins/OK-Legacy-Distribution-10/workspace/ok_services_oklib/Src/COptionKeyServiceLib.cpp"

I've noticed the main binary also accesses 3 different GPIO ports, and 2 i2c slave devices are present on the i2c bus. I haven't identified them as yet.
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on September 21, 2020, 05:06:13 pm
I'm actually pretty impressed with what R&S has done here. Other vendors build on top of a pre-made OS. They seem to have developed their application for bare-metal and implemented it pretty efficiently.

As far as I know, R&S has programmed its own operating system 'MesOS', a similar one already existed in the Hameg instruments.

From the RTB2000 with undocumented SCPI command:
Code: [Select]
Build 522 built on 2018-11-06 12:37:30 by MaG? [02.202 - HCL: 03.300 - MesOS: 04.300] with GCC 5.3.0; Monitor: 03.711_CB2Ax00

Peter


Looks like that is probably the case then. Following the boot routines, I see it go to the Altera Bootrom first, then jumps to the little 44KB uBoot image at the beginning of Flash (with MesOS references) then jumps into the main ELF executable.
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on September 27, 2020, 12:03:06 am
It seems I did not look closely enough at the 4-pin connector. It is a typical 1.8V UART.

From the top of the photo I posted the first pin is GND, and the third pin is UART TX (Device out TX 115.2kbps, 8N1, idle=low).

I haven't yet been able to get a response when attempting to transmit on pins 2 or 4, so cannot identify the RX yet.

This is the output immediately following poweron:

Code: [Select]
U-Boot SPL 2013.01.01 (Oct 06 2016 - 16:39:22)
BOARD : Altera SOCFPGA Cyclone V Board
CLOCK: EOSC1 clock 50000 KHz
CLOCK: EOSC2 clock 50000 KHz
CLOCK: F2S_SDR_REF clock 0 KHz
CLOCK: F2S_PER_REF clock 0 KHz
CLOCK: MPU clock 925 MHz
CLOCK: DDR clock 400 MHz
CLOCK: UART clock 100000 KHz
CLOCK: MMC clock 62500 KHz
CLOCK: QSPI clock 3613 KHz
RESET: WARM
SDRAM: Initializing MMR registers
SDRAM: Calibrating PHY
SEQ.C: Preparing to start memory calibration
SEQ.C: CALIBRATION PASSED
SDRAM: 512 MiB
NAND:  Denali NAND controller

The very first thing this U-boot image does is to check GPIO2, PIN 7 to see if it is low, and enters the "MonDeb" debug monitor if it is. So far I can't find a front-panel button that maps to that port/pin, so I am not sure what is supposed to trigger that. It could be that some device asserts that when it has a problem, or some front-panel combination I am missing so far.
Title: Re: R&S RTB2004 Snooping
Post by: darkstar49 on September 28, 2020, 03:55:12 pm
 :clap:

didn't see this before...  well done !!! I'm rather a software guy, I had a (quick) look at the FW files (RTB, RTM, RTA), but these are all encrypted, so there was not much to chew without an image of the  boot rom and/or the FW update code (to which I had no access...).
Title: Re: R&S RTB2004 Snooping
Post by: tv84 on September 29, 2020, 08:48:49 am
This is the output immediately following poweron:

No "Hit any key to stop autoboot: " ?
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on September 29, 2020, 05:53:36 pm
This is the output immediately following poweron:

No "Hit any key to stop autoboot: " ?

Nope. I only see 2 code checks that cause the "Mondeb" diagnostics to load.

It checks a GPIO pin, and branches into it with no error if it is low. Otherwise it checks a memory location and branches into it with an error about being unable to start the bootloader.

I managed to force it to take the first code path by changing a register value. So far I have not been able to get a response from UART to keypresses, and I believe it is an issue with my UART dongle.

I got a new one and will be retesting soon.
Title: Re: R&S RTB2004 Snooping
Post by: abyrvalg on September 30, 2020, 06:32:05 am
Maybe that gpio is on one of those debug connectors? Would be more logical than having it accessible on the front panel (if the mode it triggers requires access to internal UART). Try grounding unknown pins (using some 500 Ohm resistor to stay safe) while observing that gpio reg bit via JTAG?
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on October 01, 2020, 12:42:37 am
Maybe that gpio is on one of those debug connectors? Would be more logical than having it accessible on the front panel (if the mode it triggers requires access to internal UART). Try grounding unknown pins (using some 500 Ohm resistor to stay safe) while observing that gpio reg bit via JTAG?

Could be. I was a bit wary of connecting together things that were unknown, so I went the software route to get past it.

I've finally made some progress on producing some IDA and Ghidra FunctionID signatures for these binaries too (figuring out the compiler options they used was a bear).
Title: Re: R&S RTB2004 Snooping
Post by: reyntjensm on October 05, 2020, 11:21:54 pm
I don't understand what you are trying to achieve? Just to see how R&S has build there software? I also have an RTB2004 and i'm very happy with it. I got a big discount on the scope with a lot of options( just send them an email and you can buy straight from the manufacturer, if you ask for a discount they can do some things). Sadly enough i don't have the full bandwith option. I only have 70 MHz.... If you know how to hack it to 300MHz please let me know :D. Do you know if the FFT functions depend on the bandwith option? I'm not sure about this since i can use the FFT above the 70MHz bandwith. It looks like you are doing very difficult stuff. I hope you don't blow up the logic with poking around, but i'm sure you know what you are doing with this ;)
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on October 06, 2020, 03:07:03 am
I don't understand what you are trying to achieve? Just to see how R&S has build there software? I also have an RTB2004 and i'm very happy with it. I got a big discount on the scope with a lot of options( just send them an email and you can buy straight from the manufacturer, if you ask for a discount they can do some things). Sadly enough i don't have the full bandwith option. I only have 70 MHz.... If you know how to hack it to 300MHz please let me know :D. Do you know if the FFT functions depend on the bandwith option? I'm not sure about this since i can use the FFT above the 70MHz bandwith. It looks like you are doing very difficult stuff. I hope you don't blow up the logic with poking around, but i'm sure you know what you are doing with this ;)

I just like to know what is inside the "black boxes" that I own. If I find something "useful" or provide a path for someone else to find something useful, all the better.

I am pretty much done poking around the insides. I made a JTAG cable and ran it out the little door in the back so I can connect back up if I need to test something. I am using the firmware I recovered to learn more about software reverse-engineering in general. I have no plans to do anything potentially destructive, as this is my primary scope right now.
Title: Re: R&S RTB2004 Snooping
Post by: tv84 on October 07, 2020, 08:35:36 pm
Preloader: U-Boot SPL 2013.01.01 (Oct 06 2016 - 16:39:22)
Loading address - 0xFFFF0000

Bootloader:
Code: [Select]
00010000                 Magic: 27051956    uImage File OK
00010004         Header CRC-32: FB7A652B  [00010000-0001003F]    CRC OK
00010008               Created: 06/10/2016 14:40:27
0001000C             Data Size: 0000AFB0
00010010     Data Load Address: 00100000
00010014   Entry Point Address: 00000000
00010018           Data CRC-32: 8CF4BA9E  [00010040-0001AFEF]    CRC OK
0001001C      Operating System: U-Boot Firmware
0001001D      CPU Architecture: ARM
0001001E                  Type: Firmware Image
0001001F           Compression: None
00010020                  Name: Monitor CycloneVSoC CB-2Ax
00010040 - Image 0 [00010040-0001AFEF]  0000AFB0 bytes

I included also a NAND visual map of its contents (512MB). The initial zone is the bootloader + 7 .ELF files.

Code: [Select]
Offset     Size    CRC32     ???        #
00020001  00222DA0 667AD7B6 0177B8C9  00000000  [00020040-00242DDF]  CRC OK
0025FEE1  011C2270 99B593B8 017889C3  00000001  [0025FF20-0142218F]  CRC OK
0143F5F1  01249710 0F20C41A 017A8953  00000002  [0143F630-02688D3F]  CRC OK
0269ECC1  01255230 13A3E181 017C7C27  00000003  [0269ED00-038F3F2F]  CRC OK
038FE391  01364C10 55559A0E 0180559F  00000004  [038FE3D0-04C62FDF]  CRC OK
04C7D9D1  013C9110 35F2A042 0185479D  00000005  [04C7DA10-06046B1F]  CRC OK
0605CFE1  01482CF0 DE645734 0188065F  00000006  [0605D020-074DFD0F]  CRC OK
Title: Re: R&S RTB2004 Snooping
Post by: YetAnotherTechie on October 07, 2020, 11:47:01 pm
Thank you ElectronMan for your investigation!
Can you please post your version numbers?
About the NAND, i suggest not stripping but saving the extra NAND bytes to a separate file, this could help in the future to repair a corrupted dump/chip.
Do you know that those chips have unique data sectors, that can be programmed only once, have you considered reading them too?
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on October 09, 2020, 12:24:23 am
Thank you ElectronMan for your investigation!
Can you please post your version numbers?
About the NAND, i suggest not stripping but saving the extra NAND bytes to a separate file, this could help in the future to repair a corrupted dump/chip.
Do you know that those chips have unique data sectors, that can be programmed only once, have you considered reading them too?

I haven't looked at any of the spare areas on the NAND chip. Everything appears to be out in the open. I can take an image easily enough with the NAND formatting in it, though I don't trust JTAG for writing back to my NAND unless I've got no other choice.

Here are the versions (I have never installed most of these, so they must come on there from the factory):
Code: [Select]
25FF20: " [01.100 - HCL: 02.500 - MesOS: 03.760] with GCC 5.3.0"
143F630: "Build 39 built on 2017-03-02 15:39:23 by SBC [01.203 - HCL: 02.500 - MesOS: 03.760] with GCC 5.3.0"
269ED00: " [01.210 - HCL: 02.500 - MesOS: 03.760] with GCC 5.3.0"
38FE3D0: " [02.000 - HCL: 03.100 - MesOS: 04.100] with GCC 5.3.0"
4C7DA10: " [02.121 - HCL: 03.200 - MesOS: 04.200] with GCC 5.3.0"
605D020: " [02.202 - HCL: 03.300 - MesOS: 04.300] with GCC 5.3.0"
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on October 09, 2020, 12:31:24 am
Found something interesting in memory. 32 bytes, padded with zeros on the end.... I wonder if they use the default AES256-CBC initialization vector for encrypting their firmware......  ::)

Title: Re: R&S RTB2004 Snooping
Post by: tv84 on October 09, 2020, 10:03:46 am
 :clap: :clap: :clap:

IV=0
Title: Re: R&S RTB2004 Snooping
Post by: abyrvalg on October 09, 2020, 12:20:46 pm
Great! I was afraid they hid it in the FPGA part  >:D
Title: Re: R&S RTB2004 Snooping
Post by: mikeselectricstuff on October 09, 2020, 02:10:27 pm
Maybe that gpio is on one of those debug connectors? Would be more logical than having it accessible on the front panel (if the mode it triggers requires access to internal UART). Try grounding unknown pins (using some 500 Ohm resistor to stay safe) while observing that gpio reg bit via JTAG?
A connector pin or test pad would be my guess as well.
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on October 09, 2020, 03:49:02 pm
Maybe that gpio is on one of those debug connectors? Would be more logical than having it accessible on the front panel (if the mode it triggers requires access to internal UART). Try grounding unknown pins (using some 500 Ohm resistor to stay safe) while observing that gpio reg bit via JTAG?
A connector pin or test pad would be my guess as well.

It is the second pin down on the UART 4-pin connector from my photo above. I grounded that through a 500Ohm as abyrvalg suggested and I see the GPIO pin register change to low for the pin were were interested in.

Edit:
I tested this. It looks like you need to un-ground it for the debug prompt to come up. So it seems it is supposed to be like holding a button during power-on then releasing it.

Unfortunately, even with my new serial dongle, I am not getting any response from the device when trying to type commands. The bottom connector must be RX, as it is the only one left.  Still investigating that.
Title: Re: R&S RTB2004 Snooping
Post by: KaneTW on October 09, 2020, 04:01:18 pm
Very cool!
Title: Re: R&S RTB2004 Snooping
Post by: abyrvalg on October 09, 2020, 07:59:38 pm
Great! If you know UART IO addresses you can try finding Rx the same way as that gpio - setup the PC to send something to the dongle port continuously, touch Rx candidate pins with your dongle’s Tx while observing the UART status/data regs via JTAG.
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on October 09, 2020, 09:19:40 pm
Great! If you know UART IO addresses you can try finding Rx the same way as that gpio - setup the PC to send something to the dongle port continuously, touch Rx candidate pins with your dongle’s Tx while observing the UART status/data regs via JTAG.

I finally figured it out... The Mondeb interface actually uses that same GPIO pin to receive. It provides no echo (so you have to turn on local echo).

You have to send BREAK (usually Alt-B on terminals) at the end of each command. You also need to hold BREAK while turning it on to trigger the debug terminal.

So from the top of the photo in the original post, the pins on the 4-pin debug connector are:
1 - GND
2 - UART RX
3 - UART TX
4 - VCC?
Title: Re: R&S RTB2004 Snooping
Post by: tv84 on October 13, 2020, 07:28:14 pm
ElectroMan,

Please explain how you did the NAND dump and why the first 0x0800 0000 seem all good and the rest seems to contain raw NAND bytes plus OOB.
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on October 14, 2020, 09:39:31 pm
ElectroMan,

Please explain how you did the NAND dump and why the first 0x0800 0000 seem all good and the rest seems to contain raw NAND bytes plus OOB.

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.

Do you have other specific questions about the process? I explained the methodology in the first post and provided the script I used here: https://www.eevblog.com/forum/testgear/rs-rtb2004-snooping/msg3242084/#msg3242084 (https://www.eevblog.com/forum/testgear/rs-rtb2004-snooping/msg3242084/#msg3242084)

I was basically emulating a crude NAND controller driver via memory reads/writes through OpenOCD to get the NAND contents.

The image that was extracted seems to have all the software (and a bunch of different versions), but if there are errors in the latter memory regions it would be difficult to tell for certain what should be there. I double-checked my binary math a few times, and as all the important data seemed to be there I assumed some of the garbage later in the file was an artifact of however they were flashing these from the factory.

Note that the apps seem to use about 25-30M of a 512M flash. A lot of the other stuff there are older firmware versions (the scope came with a version newer than most of them on the flash). This leads me to believe the image they use to flash these devices has a lot of stuff left over from earlier testing stages.

It is, of course, also possible there's something wrong with my methodology and my binary math fell apart. A second set of eyes on that would be welcome.
Title: Re: R&S RTB2004 Snooping
Post by: abyrvalg on October 15, 2020, 09:58:21 am
Peter’s txt contains an answer: there is an FTL (and that is natural - this is NAND), so in general you can’t just strip and ignore OOB data. It’s a luck (and high quality components choice by R&S) that simple stripping worked on the first part of data without hitting a bad/remapped block. Btw, what about ECC? Is it done automatically by Cyclone’s NAND controller?
Title: Re: R&S RTB2004 Snooping
Post by: tv84 on October 15, 2020, 10:35:23 am
Peter’s txt contains an answer: there is an FTL (and that is natural - this is NAND), so in general you can’t just strip and ignore OOB data. It’s a luck (and high quality components choice by R&S) that simple stripping worked on the first part of data without hitting a bad/remapped block. Btw, what about ECC? Is it done automatically by Cyclone’s NAND controller?

Maybe I used the wrong term. I don't think that those stripped 16 bytes are really OOB with sector recovery info, etc. Maybe more like checksum, framing, etc... it seems too few bytes to have a meaningful goal.
Title: Re: R&S RTB2004 Snooping
Post by: mikeselectricstuff on October 15, 2020, 11:01:10 am

Maybe I used the wrong term. I don't think that those stripped 16 bytes are really OOB with sector recovery info, etc. Maybe more like checksum, framing, etc... it seems too few bytes to have a meaningful goal.
Could they be ECC data ?
Title: Re: R&S RTB2004 Snooping
Post by: tv84 on October 15, 2020, 11:12:08 am
Could they be ECC data ?

Well, as I was saying, they sure are OOB (out of band) but they don't seem ECC as they are only 16 bytes for each 16384 bytes block. I think that is very few bytes to do any recovery or error signaling. But, for sure, I'm no expert on this. And, most of all, i think 4 or more bytes are always the same... so it is even less useful data.
Title: Re: R&S RTB2004 Snooping
Post by: abyrvalg on October 15, 2020, 11:33:22 am
Checked the Cyclone docs and ElectronMan's script, the command used for reading (MAP01) handles the ECC internally, NAND spare area is not included in the readout at all. Those 16 bytes should be FTL metadata. PeDre's txt contains Sector Size: 16384 and User Sector Size: 16368 - exactly 16 bytes difference. FTL block map dump (the big part of txt) consists of small entries fitting to 16 bytes easily. I don't have a dump to see how those OOB bytes looks like, could someone post an example?

That txt also explains why simple stripping works (for now): all "bad" counters (bad blocks, sectors, ECC errors, relocs etc) are 0.
Title: Re: R&S RTB2004 Snooping
Post by: tv84 on October 15, 2020, 11:51:15 am
Here (https://www.eevblog.com/forum/testgear/rs-rtb2004-snooping/msg3266974/#msg3266974) I shared a very rough map of the whole NAND with 32kB lines width (heavily resized).

One can see the patterns although the 16 bytes are completely obfuscated given the resizing.

I'll see if there is an anonymized extract block that I could share.
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on October 15, 2020, 01:17:10 pm
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.
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on October 15, 2020, 01:25:20 pm
Peter’s txt contains an answer: there is an FTL (and that is natural - this is NAND), so in general you can’t just strip and ignore OOB data. It’s a luck (and high quality components choice by R&S) that simple stripping worked on the first part of data without hitting a bad/remapped block. Btw, what about ECC? Is it done automatically by Cyclone’s NAND controller?

The NAND controller does do ECC transparently when reading in "Main area" mode, which is what I used. Main mode does not include the Spare area.

From the CycloneV HPS technical reference manual:

Code: [Select]
Main Area Transfer Mode
In main area transfer mode, when ECC is enabled, the NAND flash controller inserts ECC check bits in
the data stream on writes and strips ECC check bits on reads. Software does not need to manage the ECC
sectors when writing a page. ECC checking is performed by the flash controller, so software simply
transfers the data.
If ECC is turned off, the NAND flash controller does not read or write ECC check bits
Title: Re: R&S RTB2004 Snooping
Post by: abyrvalg on October 15, 2020, 03:51:07 pm
Looks like 08000000+ area uses some different data/metadata layout, so the reader script strips metadata incorrectly. The dump by tv84 looks like it has some data stripped at wrong positions (16 "metadata" bytes are at +0 in each 16K sector of the first 128K block, but the same looking data is moved by 16 bytes upper in the next block, then by 32 bytes upper, ...).
It would be better to turn off that stripping at all, read everything as is, then decide what to strip for each area. Or even use MonDeb "cr" command to read NAND to RAM (so a builtin read function that knows the correct data format will be used), then dump it from there either via JTAG (this can be done in huge portions) or with MonDeb "du" command.
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on October 15, 2020, 04:31:58 pm
Looks like 08000000+ area uses some different data/metadata layout, so the reader script strips metadata incorrectly. The dump by tv84 looks like it has some data stripped at wrong positions (16 "metadata" bytes are at +0 in each 16K sector of the first 128K block, but the same looking data is moved by 16 bytes upper in the next block, then by 32 bytes upper, ...).
It would be better to turn off that stripping at all, read everything as is, then decide what to strip for each area. Or even use MonDeb "cr" command to read NAND to RAM (so a builtin read function that knows the correct data format will be used), then dump it from there either via JTAG (this can be done in huge portions) or with MonDeb "du" command.

Yeah, I was considering using the Mondeb interface to do just that. I had tried doing DMA transfers via script from flash but could never get them to work.

I have a full raw JTAG dump happening now at home via the flash controller. Problem is that long runs of 0xFF seem to cause JTAG timeouts and errors, so getting a good dump is a challenge. If it isn't complete when I get home I'll try using Mondeb to transfer it into RAM so I can read it in larger chunks.
Title: Re: R&S RTB2004 Snooping
Post by: tv84 on October 15, 2020, 04:52:04 pm
Agree with both. With a successful raw dump, we should be able to parse in no time.

Electro, remember we don't need the 1st 128 MB again. You can restart at 0x08000000.   :)

By doing a bitmap with the whole 512MB it's very easy to see those 16-bytes "junk" zones and do a visual integrity check.
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on October 15, 2020, 05:01:36 pm
Agree with both. With a successful raw dump, we should be able to parse in no time.

Electro, remember we don't need the 1st 128 MB again. You can restart at 0x08000000.   :)

By doing a bitmap with the whole 512MB it's very easy to see those 16-bytes "junk" zones and do a visual integrity check.

I just started pulling the entire 512M so I'd have it for disaster recovery. It doesn't matter much anyway, as the first 128M transfers pretty quickly. It is the parts of flash that have a lot of 0xFF's (empty) that cause all kinds of JTAG errors and restarts. The first 128M takes about an hour or two, and the remainder ends up taking about 18hrs or so.
Title: Re: R&S RTB2004 Snooping
Post by: tv84 on October 15, 2020, 06:32:53 pm
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.

Peter

Peter, show us the command that you used for this.

We can easily see here:

"Block Size: 131072",
"Sector Size: 16384",
"User Sector Size: 16368",

So, we definitely should have blocks of 128 kB = 8 sectors x 16 kB (but each sector has -16 usable bytes).
Title: Re: R&S RTB2004 Snooping
Post by: abyrvalg on October 15, 2020, 11:34:04 pm
The command to show those FTL stats should be DIAGNOSTIC:SERVICE:PFSTATUS
Title: Re: R&S RTB2004 Snooping
Post by: abyrvalg on October 16, 2020, 12:56:08 am
(more or less) complete SCPI command list:
Title: Re: R&S RTB2004 Snooping
Post by: tv84 on October 16, 2020, 01:29:29 pm
.FWU parsing (after decryption):

Code: [Select]
00000000      Header Size: 0400      [00000000-000003FF]    FileSize OK
00000002   Section 1 Size: 0017792C  [00000400-00177D2B]
00000006   Section 2 Size: 014903A4  [00177D2C-016080CF]
0000000A  Section 1 CRC16: 2AE2    CRC OK
0000000C  Section 2 CRC16: 50A4    CRC OK
0000000E             ????: 0x10330000
0000001E            Model: RTB2004
0000002E       FW Version: 02.202
0000003E     Release Date: 2018-11-06
0000004E             ????: 6731.19395
0000005E      Compilation: Build 522 built on 2018-11-06 12:37:30 by MaG? [02.202 - HCL: 03.300 - MesOS: 04.300] with GCC 5.3.0
0000015E  (???) Hash Type: 2
00000198            Build: 522
000001AA Section 1 SHA256: 898ADDB2A111DBE0C45BC0EA363D4CD5    HASH OK
000001CA Section 2 SHA256: 7208D30AF3FB85125AD5082BC46230FB    HASH OK
000003FE     Header CRC16: 25E7    CRC OK
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on October 16, 2020, 02:15:07 pm
.FWU parsing (after decryption):

Code: [Select]
00000000      Header Size: 0400      [00000000-000003FF]    FileSize OK
00000002   Section 1 Size: 0017792C  [00000400-00177D2B]
00000006   Section 2 Size: 014903A4  [00177D2C-016080CF]
0000000A  Section 1 CRC16: 2AE2    CRC OK
0000000C  Section 2 CRC16: 50A4    CRC OK
0000000E             ????: 0x10330000
0000001E            Model: RTB2004
0000002E       FW Version: 02.202
0000003E     Release Date: 2018-11-06
0000004E             ????: 6731.19395
0000005E      Compilation: Build 522 built on 2018-11-06 12:37:30 by MaG? [02.202 - HCL: 03.300 - MesOS: 04.300] with GCC 5.3.0
0000015E  (???) Hash Type: 2
00000198            Build: 522
000001AA Section 1 SHA256: 898ADDB2A111DBE0C45BC0EA363D4CD5    HASH OK
000001CA Section 2 SHA256: 7208D30AF3FB85125AD5082BC46230FB    HASH OK
000003FE     Header CRC16: 25E7    CRC OK

Good info!

The 0x10330000 is known as the "Material Number." The 6731.19395 Appears in some strings associated with a date and time, but not sure what it represents.
19395 2018-11-06 12:37:30
6731(6730:6731;2018/11/06 12:28:21)
19395(19399;2018/10/24 15:01:02)
19383(19399;2018/10/18 10:30:34)
19377(19399;2018/10/17 11:30:25)

Title: Re: R&S RTB2004 Snooping
Post by: KaneTW on October 16, 2020, 04:38:32 pm
How did you decrypt the FWU? I tried with the AES key posted in this thread, but it failed.
Title: Re: R&S RTB2004 Snooping
Post by: tv84 on October 16, 2020, 04:42:28 pm
How did you decrypt the FWU? I tried with the AES key posted in this thread, but it failed.

It's AES-256, not AES-128. You have to consider the 32 bytes of the key.
Title: Re: R&S RTB2004 Snooping
Post by: KaneTW on October 16, 2020, 04:50:30 pm
Oh. I didn't realize it was 0-padded 256-bit AES. It even worked the last time round, I just didn't notice that it succeeded. Oops.

E: welp, didn't work. just didn't fail, but the data's still encrypted. hmm.
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on October 16, 2020, 05:08:24 pm
Make sure you're using AES-256CBC with an IV of 0. Openssl can be used.
Title: Re: R&S RTB2004 Snooping
Post by: abyrvalg on October 16, 2020, 05:22:27 pm
If all you want from decrypted FWU is to get the main part for study - just find the ELF header signature (7F "ELF") and rip from there till end of file, you'll get a correct ELF.
Title: Re: R&S RTB2004 Snooping
Post by: KaneTW on October 16, 2020, 06:48:24 pm
Using this:
Code: [Select]
openssl aes-256-cbc -K 43C6B3E57510A3C5547AA4DF9528B783  -iv 0 -in RTB2004.FWU -out RTB2004.FWU.dec
Resulting .dec file is either compressed or encrypted (bytes are uniformly distributed)
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on October 16, 2020, 07:24:14 pm
Using this:
Code: [Select]
openssl aes-256-cbc -K 43C6B3E57510A3C5547AA4DF9528B783  -iv 0 -in RTB2004.FWU -out RTB2004.FWU.dec
Resulting .dec file is either compressed or encrypted (bytes are uniformly distributed)

You're missing some things... Not sure what the defaults are, but I'd specify them. It may be encrypting it rather than decrypting it, as I see no -d in your command.

Code: [Select]
openssl enc -aes-256-cbc -nopad -nosalt -d -in <infile> -out <outfile> -K '<key>' -iv '0'
Don't forget to pad the key out to the proper length by appending the 0's.
Title: Re: R&S RTB2004 Snooping
Post by: abyrvalg on October 16, 2020, 10:06:05 pm
Great! So an update file consists of 3 main things: a loader code that writes update to flash, a splash screen to show during update and an all-in-one ELF to be flashed.
Title: Re: R&S RTB2004 Snooping
Post by: KaneTW on October 16, 2020, 11:45:24 pm
Using this:
Code: [Select]
openssl aes-256-cbc -K 43C6B3E57510A3C5547AA4DF9528B783  -iv 0 -in RTB2004.FWU -out RTB2004.FWU.dec
Resulting .dec file is either compressed or encrypted (bytes are uniformly distributed)

You're missing some things... Not sure what the defaults are, but I'd specify them. It may be encrypting it rather than decrypting it, as I see no -d in your command.

Code: [Select]
openssl enc -aes-256-cbc -nopad -nosalt -d -in <infile> -out <outfile> -K '<key>' -iv '0'
Don't forget to pad the key out to the proper length by appending the 0's.

Duh. That's what I get for not double-checking. The args were what was missing.
Title: Re: R&S RTB2004 Snooping
Post by: tv84 on October 17, 2020, 10:34:46 am
Great! So an update file consists of 3 main things: a loader code that writes update to flash, a splash screen to show during update and an all-in-one ELF to be flashed.

Exactly, but in this RTC10002 FW there are additional sections. ;)  (but the structure is the same)

RTC1002:
Code: [Select]
00000000      Header Size: 0400      [00000000-000003FF]    FileSize OK
00000002   Section 1 Size: 00044BC0  [00000400-00044FBF]
00000006   Section 2 Size: 0097F250  [00044FC0-009C420F]
0000000A  Section 1 CRC16: EF35    CRC OK
0000000C  Section 2 CRC16: 033B    CRC OK
0000000E             ????: 0x101B0000
0000001E            Model: RTC1002
0000002E       FW Version: 06.100
0000003E     Release Date: 2018-06-27
0000004E             ????: 17479.19094
0000005E      Compilation: Build 38186 built on 2018-06-27 15:59:39 by MaG? [06.100 - HCL: 02.500 - MesOS: 03.760] with GCC 5.3.0
0000015E  (???) Hash Type: 2
00000198            Build: 38186
000001AA Section 1 SHA256: 9264B3CF9410BDEF8B744AA0F5570FE6    HASH OK
000001CA Section 2 SHA256: 4F0237325E515FB0DCF8C5606A672288    HASH OK
000003FE     Header CRC16: D71A    CRC OK
--------------------------------------------------------------------
00044FC0 **** SubSection 0x80 ****
00044FC1  SubSect Hdr Size: 0025
00044FC3   SubSection Size: 0000809F  [00044FE5-0004D083]
00044FC7  SubSection CRC16: D361    CRC OK
00044FDF     Contents Size: 0000809C  [00044FE8-0004D083]
00044FE3 SubSect Hdr CRC16: 1A08      [00044FC0-00044FE2]    CRC OK
00044FE8 BMP (640x480 pixels - 8 bits / compr.: 1)   [00044FE8-0004D083]
0004D084 **** SubSection 0x11 ****
0004D085  SubSect Hdr Size: 0025
0004D087   SubSection Size: 00005B4B  [0004D0A9-00052BF3]
0004D08B  SubSection CRC16: A31B    CRC OK
0004D0A3     Contents Size: 00005B48  [0004D0AC-00052BF3]
0004D0A7 SubSect Hdr CRC16: D911      [0004D084-0004D0A6]    CRC OK
0004D0AC Bootloader Programmer
00052BF4 **** SubSection 0x18 ****
00052BF5  SubSect Hdr Size: 0025
00052BF7   SubSection Size: 0096EFE3  [00052C19-009C1BFB]
00052BFB  SubSection CRC16: F0CC    CRC OK
00052C13     Contents Size: 0096EFE0  [00052C1C-009C1BFB]
00052C17 SubSect Hdr CRC16: 9A46      [00052BF4-00052C16]    CRC OK
00052C1D     ELF File Size: 0096EF60  [00052C5C-009C1BBB]
00052C21    ELF File CRC32: E0061AED    CRC OK
00052C25     Creation Time: 27/06/2018 14:12:00
00052C5C Main Application .ELF
009C1BFC **** SubSection 0x12 ****
009C1BFD  SubSect Hdr Size: 0070
009C1BFF   SubSection Size: 000025A0  [009C1C6C-009C420B]
009C1C03  SubSection CRC16: 1726    CRC OK
009C1C1B     Contents Size: 0000255F  [009C1CAC-009C420A]
009C1C6A SubSect Hdr CRC16: 7F25      [009C1BFC-009C1C69]    CRC OK
009C1CAC Bootloader EEPROM Programming
Title: Re: R&S RTB2004 Snooping
Post by: uski on October 29, 2020, 10:35:03 am
There are these SCPI commands :

DIAGNOSTIC:PRODUCT:OPTION:STATUS
DIAGNOSTIC:PRODUCT:OPTION:LIST
DIAGNOSTIC:PRODUCT:OPTION:ENABLE    OFF ON
DIAGNOSTIC:PRODUCT:OPTION:FACTORY:CLEAR
DIAGNOSTIC:PRODUCT:MNUMBER:SET

Obviously I would not try CLEAR... but STATUS/LIST and ENABLE seem interesting...

Regarding reverse engineering, if the ENABLE command asks for a key, it could be possible to statically decompile the code and look at what checks are performed. This could yield to the key algorithm.

I don't have an RTB - I am waiting to see where this thread goes before maybe getting one. Someone wants to try these commands ?  ;D

PS: Oh and MNUMBER can be promising... maybe it allows changing the model number to... a higher bandwidth version ?  >:D
Title: Re: R&S RTB2004 Snooping
Post by: Hydron on October 29, 2020, 11:35:59 am
OK so I wouldn't get too worked up about the NUMBER thing, the bandwidth seems to be an option only thing, unlike the old Tek scope BW hack.

When sending the LIST? command there isn't much of use in the output other than the actual keys used for activating each option (and the activation date) - could be useful if one lost the original info and cleared the list or something. These match the License keys on the document included in the original packaging (and the K36 bode plot key I was emailed).
STATUS doesn't seem to give any output, and no way I'm trying the rest.
Title: Re: R&S RTB2004 Snooping
Post by: Harjit on October 31, 2020, 03:31:51 am
@uski - curious how you figured out these commands?
Title: Re: R&S RTB2004 Snooping
Post by: uski on October 31, 2020, 03:55:13 am
@uski - curious how you figured out these commands?

Someone posted a txt file with all the commands earlier.
But otherwise... I am pretty sure you can run "strings" on the decrypted firmware image and get the same result (and possibly find other interesting stuff such as some error messages that can be interesting)

I didn't have time to play around with the firmware (yet?). Another option is to load it in IDA or a similar disassembler, and then things get even more interesting. :)
Title: Re: R&S RTB2004 Snooping
Post by: uski on October 31, 2020, 06:11:07 am
Some pretty cool content in the firmware...

An error message :

Code: [Select]
1GHz Bandwidth extension is not supported
with present hardware configuration.
TXT_ID_LICENCE_OKL_1GHz_BW_UPGRADE_NOT_SUPPORTED

And a bunch of license numbers and descriptions, including these :

Code: [Select]
B1 - MSO 16 Logic Channels
TXT_ID_LICENCE_OKL_DESIG_B1
B200 - Bandwidth ext. 500MHz
TXT_ID_LICENCE_OKL_DESIG_B200
B201 - Bandwidth ext. 350MHz
TXT_ID_LICENCE_OKL_DESIG_B201
B202 - Bandwidth ext. 500MHz
TXT_ID_LICENCE_OKL_DESIG_B202
B203 - Bandwidth ext. 1GHz
TXT_ID_LICENCE_OKL_DESIG_B203
B204 - Bandwidth ext. 1GHz
TXT_ID_LICENCE_OKL_DESIG_B204
B205 - Bandwidth ext. 1GHz
TXT_ID_LICENCE_OKL_DESIG_B205

Not saying it will work or it is supported... but these strings are there in the firmware  ^-^
Title: Re: R&S RTB2004 Snooping
Post by: maginnovision on October 31, 2020, 02:55:12 pm
Probably just some common stuff between the 2000, 3000 and 4000 series scopes.
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on October 31, 2020, 03:45:58 pm
Some pretty cool content in the firmware...

An error message :

Code: [Select]
1GHz Bandwidth extension is not supported
with present hardware configuration.
TXT_ID_LICENCE_OKL_1GHz_BW_UPGRADE_NOT_SUPPORTED

And a bunch of license numbers and descriptions, including these :

Code: [Select]
B1 - MSO 16 Logic Channels
TXT_ID_LICENCE_OKL_DESIG_B1
B200 - Bandwidth ext. 500MHz
TXT_ID_LICENCE_OKL_DESIG_B200
B201 - Bandwidth ext. 350MHz
TXT_ID_LICENCE_OKL_DESIG_B201
B202 - Bandwidth ext. 500MHz
TXT_ID_LICENCE_OKL_DESIG_B202
B203 - Bandwidth ext. 1GHz
TXT_ID_LICENCE_OKL_DESIG_B203
B204 - Bandwidth ext. 1GHz
TXT_ID_LICENCE_OKL_DESIG_B204
B205 - Bandwidth ext. 1GHz
TXT_ID_LICENCE_OKL_DESIG_B205

Not saying it will work or it is supported... but these strings are there in the firmware  ^-^

That's just the LUT (look-up-table) for English names for those licenses.  RTM and RTA licenses are included in that database.
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on October 31, 2020, 10:16:37 pm
There are these SCPI commands :

DIAGNOSTIC:PRODUCT:OPTION:STATUS
DIAGNOSTIC:PRODUCT:OPTION:LIST
DIAGNOSTIC:PRODUCT:OPTION:ENABLE    OFF ON
DIAGNOSTIC:PRODUCT:OPTION:FACTORY:CLEAR
DIAGNOSTIC:PRODUCT:MNUMBER:SET

Obviously I would not try CLEAR... but STATUS/LIST and ENABLE seem interesting...

Regarding reverse engineering, if the ENABLE command asks for a key, it could be possible to statically decompile the code and look at what checks are performed. This could yield to the key algorithm.

I don't have an RTB - I am waiting to see where this thread goes before maybe getting one. Someone wants to try these commands ?  ;D

PS: Oh and MNUMBER can be promising... maybe it allows changing the model number to... a higher bandwidth version ?  >:D

This is an interesting SCPI command on the RTB2004:
Code: [Select]
JOSHUA?
"Have Fun"
I haven't been able to tell what it does, but if someone knows a SCPI command that fails due to permissions and can try it after that, it could be helpful.
Title: Re: R&S RTB2004 Snooping
Post by: uski on November 01, 2020, 01:14:12 am
That's just the LUT (look-up-table) for English names for those licenses.  RTM and RTA licenses are included in that database.

Stop breaking my dreams !
1 GHz bandwidth on a 2.5GSPS scope would not be too helpful anyway.

Have you found out how the strings from the LUT are referenced in the rest of the firmware ? Having some trouble with Xrefs.

This is an interesting SCPI command on the RTB2004:
Code: [Select]
JOSHUA?
"Have Fun"
I haven't been able to tell what it does, but if someone knows a SCPI command that fails due to permissions and can try it after that, it could be helpful.

If you managed to get Xrefs between the strings and the rest of the code, you can see if any flag in memory is altered from the code handling this command.
You can then see the Xrefs to these flags (if any) and see what else it affects
Title: Re: R&S RTB2004 Snooping
Post by: tv84 on November 01, 2020, 09:43:10 am
I do not really understand your question. Are you looking for a SCPI command so that you can execute e.g. the diagnostic commands?

He's asking if the joshua command enables something that, before issuing it, could be forbidden. He hasn't discovered none but maybe someone can show him one of those forbidden commands.
Title: Re: R&S RTB2004 Snooping
Post by: YetAnotherTechie on November 01, 2020, 11:10:05 am
There are plenty of commands that silently fail, like the ones mentioned earlier to check the file system, trough SCPI they don't work, the ones to check temperature or fan speed don't work either. It would be nice to discover how to enable them, and avoid jtaging in.
Title: Re: R&S RTB2004 Snooping
Post by: tv84 on November 01, 2020, 11:43:04 am
Peter,

Please attach the output of this command:

Code: [Select]
:SERV:MODE WEN;:SYST:TREE?
Title: Re: R&S RTB2004 Snooping
Post by: YetAnotherTechie on November 01, 2020, 07:37:32 pm
Can you jtag yours?

I haven't opened it yet, but i could, there's no warranty left. I'm not sure about what jtag hardware to get that supports 1.8v and doesn't take several months to arrive. After some research, i think a usb blaster would be ideal? I might have one packed in a box somewhere...


Title: Re: R&S RTB2004 Snooping
Post by: YetAnotherTechie on November 01, 2020, 07:40:59 pm
There are some comments in german. The list of 'abyrvalg' helps with the meaning of the short commands.

Peter
Interesting, for sure my RTM didn't reboot or answered to fan or time commands, i'll need to try with the service enable command.
Title: Re: R&S RTB2004 Snooping
Post by: YetAnotherTechie on November 02, 2020, 12:40:58 am
ElectronMan:

Do you know how to issue SET FEATURE (EFh) commands to the nand via jtag?
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on November 02, 2020, 03:04:23 am
ElectronMan:

Do you know how to issue SET FEATURE (EFh) commands to the nand via jtag?

Normally you talk to the controller and not the NAND directly, but there are some pass-through commands. I'd have to look it up. Why?
Title: Re: R&S RTB2004 Snooping
Post by: YetAnotherTechie on November 02, 2020, 12:04:02 pm
ElectronMan:

Do you know how to issue SET FEATURE (EFh) commands to the nand via jtag?

Normally you talk to the controller and not the NAND directly, but there are some pass-through commands. I'd have to look it up. Why?

From PeDre list we can see that OTP area is in use. Therefore any backup that doesn't have those thirty full pages (2112 bytes per page) of data is incomplete. Things like model/serial number, board type, permanent licenses or certificates could be stored there and couldn't be restored in case of nand failure.
Is there a way to read it using the monitor?

In a previous post you mentioned running a raw dump, does this mean talking directly to the nand and including ecc, or the entire chip through the HPS layer?
Title: Re: R&S RTB2004 Snooping
Post by: tv84 on November 02, 2020, 12:55:26 pm
In a previous post you mentioned running a raw dump, does this mean talking directly to the nand and including ecc, or the entire chip through the HPS layer?

When we mentioned "raw dump", we meant dumping without deleting any byte from the read instruction (look at Electroman original script where he cutted 16 bytes for each page).

The goal is read all the NAND and post process after. The NAND controller provides a very clean output with all the ECC taken care of.
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on November 02, 2020, 03:24:05 pm
In a previous post you mentioned running a raw dump, does this mean talking directly to the nand and including ecc, or the entire chip through the HPS layer?

When we mentioned "raw dump", we meant dumping without deleting any byte from the read instruction (look at Electroman original script where he cutted 16 bytes for each page).

The goal is read all the NAND and post process after. The NAND controller provides a very clean output with all the ECC taken care of.

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.

You can write to a register to tell it the read mode you want (just MAIN area, or MAIN and SPARE) so it would not be difficult to make the script grab that area in a dump as well.

EDIT: It is writing 0x840 bytes, which is the full 2112 byte MAIN + SPARE. I'll see if I can get that data out of Block 0, page 0 on my device.
Title: Re: R&S RTB2004 Snooping
Post by: YetAnotherTechie on November 02, 2020, 04:53:09 pm

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.

You can write to a register to tell it the read mode you want (just MAIN area, or MAIN and SPARE) so it would not be difficult to make the script grab that area in a dump as well.

EDIT: It is writing 0x840 bytes, which is the full 2112 byte MAIN + SPARE. I'll see if I can get that data out of Block 0, page 0 on my device.

From the datasheet:
https://eu.mouser.com/datasheet/2/671/micron_technology_micts06228-1-1759217.pdf
"The OTP area is only accessible while in OTP operation mode. To set the device to OTP operation mode, issue the SET FEATURE (EFh)
command to feature address 90h and write 01h to P1, followed by three cycles of 00h to P2-P4. For parameters to enter OTP mode, see Features Operations.
When the device is in OTP operation mode, all subsequent PAGE READ (00h-30h) and PROGRAM PAGE (80h-10h) commands are applied to the OTP area. The OTP area is assigned to page addresses 02h-1Fh. "

So the code would look like reading block 0 page 0, but it's a diferent block than what you read before (bootblock) do you agree?
It would also be interesting to get "read id" byte 4 to determine if they are using the internal on-chip ecc or not. it's also possible to use command "get features" to check ECC status and/or if you are reading from otp area or not.

Title: Re: R&S RTB2004 Snooping
Post by: tv84 on November 02, 2020, 04:53:53 pm
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.
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on November 02, 2020, 06:26:20 pm
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.
Title: Re: R&S RTB2004 Snooping
Post by: uski on November 07, 2020, 04:57:02 am
FYI I tried decrypting the firmware for the RTM3000 series scopes with the same key and it didn't work. Meh.
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on November 09, 2020, 09:39:32 pm
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 (https://www.eevblog.com/forum/testgear/rs-rtm2000-has-anybody-hacked-this-scope/msg3282494/#msg3282494)
Title: Re: R&S RTB2004 Snooping
Post by: Harjit on November 25, 2020, 04:14:36 am
Wondering if anyone has updates? This was fascinating to follow along.
Title: Re: R&S RTB2004 Snooping
Post by: uski on November 28, 2020, 09:44:42 pm
Hi

(https://www.eevblog.com/forum/testgear/rs-rtb2004-snooping/?action=dlattach;attach=1070784;image)

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
Title: Re: R&S RTB2004 Snooping
Post by: Kean on November 28, 2020, 10:06:04 pm
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 (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
Title: Re: R&S RTB2004 Snooping
Post by: mikeselectricstuff on November 28, 2020, 10:27:31 pm

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. 
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on November 28, 2020, 10:51:52 pm
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 (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.
Title: Re: R&S RTB2004 Snooping
Post by: Kean on November 28, 2020, 11:39:33 pm
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.
Title: Re: R&S RTB2004 Snooping
Post by: Harjit on November 29, 2020, 12:10:33 am
Fantastic! You all are really good. I just spent a few minutes looking at JST connectors but didn't find a match.
Title: Re: R&S RTB2004 Snooping
Post by: uski on November 29, 2020, 06:11:28 am
I got this : https://www.amazon.com/gp/product/B07XHW1959/ (https://www.amazon.com/gp/product/B07XHW1959/)
Will report if they fit or not when I receive my scope
Title: Re: R&S RTB2004 Snooping
Post by: Harjit on January 16, 2021, 05:31:57 am
Any updates?
Title: Re: R&S RTB2004 Snooping
Post by: trimen on April 13, 2021, 11:10:29 am
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.
Title: Re: R&S RTB2004 Snooping
Post by: AnJu on October 16, 2021, 09:32:25 pm
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
Title: Re: R&S RTB2004 Snooping
Post by: sergeyklenov on November 01, 2021, 07:51:48 pm
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.
Title: Re: R&S RTB2004 Snooping
Post by: sergeyklenov on November 02, 2021, 05:46:23 am
For info: i found in flash MSDOS5.0 FAT16 table. So i think this NAND formatted as usual PC disk.
Title: Re: R&S RTB2004 Snooping
Post by: ElectronMan on February 10, 2022, 05:40:24 pm
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.
Title: Re: R&S RTB2004 Snooping
Post by: uski on November 05, 2023, 07:14:19 pm
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... :popcorn:
Title: Re: R&S RTB2004 Snooping
Post by: skander36 on November 05, 2023, 07:26:05 pm
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.
Title: Re: R&S RTB2004 Snooping
Post by: uski on November 05, 2023, 09:23:09 pm
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!  8)

[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.
Title: Re: R&S RTB2004 Snooping
Post by: skander36 on November 05, 2023, 10:12:35 pm
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