Author Topic: R&S RTB2004 Snooping  (Read 11093 times)

0 Members and 1 Guest are viewing this topic.

Offline YetAnotherTechie

  • Regular Contributor
  • *
  • Posts: 207
  • Country: pt
Re: R&S RTB2004 Snooping
« Reply #75 on: November 02, 2020, 12:40:58 am »
ElectronMan:

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

Offline ElectronMan

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #76 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?
 

Offline YetAnotherTechie

  • Regular Contributor
  • *
  • Posts: 207
  • Country: pt
Re: R&S RTB2004 Snooping
« Reply #77 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?
 

Online tv84

  • Super Contributor
  • ***
  • Posts: 2421
  • Country: pt
Re: R&S RTB2004 Snooping
« Reply #78 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.
 

Offline ElectronMan

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #79 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.
« Last Edit: November 02, 2020, 03:27:54 pm by ElectronMan »
 

Offline YetAnotherTechie

  • Regular Contributor
  • *
  • Posts: 207
  • Country: pt
Re: R&S RTB2004 Snooping
« Reply #80 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.

 

Online tv84

  • Super Contributor
  • ***
  • Posts: 2421
  • Country: pt
Re: R&S RTB2004 Snooping
« Reply #81 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.
 

Offline ElectronMan

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #82 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.
 

Offline uski

  • Frequent Contributor
  • **
  • Posts: 250
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #83 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.
 

Offline ElectronMan

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #84 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
 

Offline Harjit

  • Regular Contributor
  • *
  • Posts: 127
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #85 on: November 25, 2020, 04:14:36 am »
Wondering if anyone has updates? This was fascinating to follow along.
 

Offline uski

  • Frequent Contributor
  • **
  • Posts: 250
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #86 on: November 28, 2020, 09:44:42 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
 

Offline Kean

  • Supporter
  • ****
  • Posts: 1377
  • Country: au
  • Embedded systems & IT consultant
    • Kean Electronics
Re: R&S RTB2004 Snooping
« Reply #87 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
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
« Last Edit: November 28, 2020, 10:09:36 pm by Kean »
 
The following users thanked this post: uski

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12725
  • Country: gb
    • Mike's Electric Stuff
Re: R&S RTB2004 Snooping
« Reply #88 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. 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline ElectronMan

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #89 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

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.
 

Offline Kean

  • Supporter
  • ****
  • Posts: 1377
  • Country: au
  • Embedded systems & IT consultant
    • Kean Electronics
Re: R&S RTB2004 Snooping
« Reply #90 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.
 

Offline Harjit

  • Regular Contributor
  • *
  • Posts: 127
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #91 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.
 

Offline uski

  • Frequent Contributor
  • **
  • Posts: 250
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #92 on: November 29, 2020, 06:11:28 am »
I got this : https://www.amazon.com/gp/product/B07XHW1959/
Will report if they fit or not when I receive my scope
 

Offline Harjit

  • Regular Contributor
  • *
  • Posts: 127
  • Country: us
Re: R&S RTB2004 Snooping
« Reply #93 on: January 16, 2021, 05:31:57 am »
Any updates?
 

Offline trimen

  • Newbie
  • Posts: 1
  • Country: cz
Re: R&S RTB2004 Snooping
« Reply #94 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.
 
The following users thanked this post: laoniv

Offline AnJu

  • Contributor
  • Posts: 12
  • Country: ru
Re: R&S RTB2004 Snooping
« Reply #95 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
 

Offline sergeyklenov

  • Contributor
  • Posts: 18
  • Country: ru
Re: R&S RTB2004 Snooping
« Reply #96 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.
 
The following users thanked this post: skander36

Offline sergeyklenov

  • Contributor
  • Posts: 18
  • Country: ru
Re: R&S RTB2004 Snooping
« Reply #97 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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf