R&S RTB2004 Snooping

[ElectronMan]

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.

[abyrvalg]

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.

[KaneTW]

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.

[tv84]

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


[uski]

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 ? 

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

[Hydron]

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.

[Harjit]

@uski - curious how you figured out these commands?

[uski]

@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.

[uski]

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 

[maginnovision]

Probably just some common stuff between the 2000, 3000 and 4000 series scopes.

[ElectronMan]

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.

[ElectronMan]

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 ? 

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

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.

[uski]

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

[tv84]

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.

[YetAnotherTechie]

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.

[tv84]

Peter,

Please attach the output of this command:

Code: [Select]

:SERV:MODE WEN;:SYST:TREE?

[YetAnotherTechie]

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...

[YetAnotherTechie]

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.

[YetAnotherTechie]

ElectronMan:

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

[ElectronMan]

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?

[YetAnotherTechie]

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?

[tv84]

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.

[ElectronMan]

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.

[YetAnotherTechie]

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.

[tv84]

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.