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: PeDre on September 21, 2020, 04:34:53 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
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: tv84 on October 09, 2020, 01:15:48 pm
Great! I was afraid they hid it in the FPGA part  >:D

It's hardcoded in the app (MOV+STRB instructions...).
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: PeDre on October 15, 2020, 05:17:50 am
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
Title: Re: R&S RTB2004 Snooping
Post by: tv84 on October 15, 2020, 08:51:43 am
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.
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: tv84 on October 15, 2020, 01:21:56 pm
abyrvalg,

Here is an extract of the 0x08000000 offset.

It has 131.056 bytes of size (each "block"). I think that must be incorrect...

Let's see in the new full dump.
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: tv84 on October 16, 2020, 07:31:26 pm
Don't forget to pad the key out to the proper length by appending the 0's.

It's not padding. They initialized only the upper 16 bytes (maybe to confuse). If we don't add the lower 00s, then basically we are using a 16 bytes key (as in AES-128).
Title: Re: R&S RTB2004 Snooping
Post by: tv84 on October 16, 2020, 08:03:07 pm
A more detailed parsing.

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
--------------------------------------------------------------------
00177D2C **** SubSection 0x80 ****
00177D2D  SubSect Hdr Size: 0025
00177D2F   SubSection Size: 0000D5E3  [00177D51-00185333]
00177D33  SubSection CRC16: CF50    CRC OK
00177D4B     Contents Size: 0000D5DE  [00177D54-00185331]
00177D4F SubSect Hdr CRC16: 9260      [00177D2C-00177D4E]    CRC OK
00177D54 BMP (1280x800 pixels - 8 bits / compr.: 1)   [00177D54-00185331]
00185334 **** SubSection 0x18 ****
00185335  SubSect Hdr Size: 0025
00185337   SubSection Size: 01482D73  [00185359-016080CB]
0018533B  SubSection CRC16: 0ABC    CRC OK
00185353     Contents Size: 01482D70  [0018535C-016080CB]
00185357 SubSect Hdr CRC16: CC36      [00185334-00185356]    CRC OK
0018535D     ELF File Size: 01482CF0  [0018539C-0160808B]
00185361    ELF File CRC32: DE645734    CRC OK
00185365     Creation Time: 06/11/2018 11:43:00
0018539C Main Application .ELF
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