Sniffing the Rigol's internal I2C bus

[Jonson.poisk]

Hello dear!
You could help me?
Are there any have this firmware unlocking methods other than soldering pins FRAM?
Analyzer DSA815-TG

Firmware 00.01.09
Boot 00.01.04
Mainboard 00.07
Radio board 00.05
FPGA 00.04

Thank you

[smgvbest]

Hello dear!
You could help me?
Are there any have this firmware unlocking methods other than soldering pins FRAM?
Analyzer DSA815-TG

Firmware 00.01.09
Boot 00.01.04
Mainboard 00.07
Radio board 00.05
FPGA 00.04

Thank you

Currently the U1105 hack is the only way to keep you're features enabled on the DSA815
I'm trying to figure it out but am new to this so my approach is to educate myself but I am missing one thing
I'm looking for a memory dump of a DSA815 with the boot 1.03 when it it was possible.   I want to trace exactly what rigup did to find the private key then see if I can duplicate with boot 1.04 but so far no one has offered up a dump with boot 1.03 so nothing is is happening for now.

[MiataMuc]

Hi
I have a DSA 815, Bootloader 00.01.03, Firmware 00.01.12, all options enabled..
I'd be willing to help you. Do I have to read the flash by network or by an adapter?

[longview]

FRAM can be read out over USB/Network, at least part of it.

I use Rigol Bildschirmkopie to send commands, mostly for convenience:
:SYST:FRE? 0,1048576
:SYST:FRE? 1048576,1048576
:SYST:FRE? 2097152,1048576
:SYST:FRE? 3145728,1048576

I've got an Atmel ICE coming soon, can I use the JTAG in that to do an SDRAM dump?

[Jonson.poisk]

Well, that have proposed the post above 

[smgvbest]

FRAM can be read out over USB/Network, at least part of it.

I use Rigol Bildschirmkopie to send commands, mostly for convenience:
:SYST:FRE? 0,1048576
:SYST:FRE? 1048576,1048576
:SYST:FRE? 2097152,1048576
:SYST:FRE? 3145728,1048576

I've got an Atmel ICE coming soon, can I use the JTAG in that to do an SDRAM dump?

FTI

Tha'ts a SDRAM dump not a fram dump.    the first 8M of memory in the Blackfin is from 0000 0000 - 007F FFFF and only 4M is used.  the 2nd 4M is a copy of the first 4.

FRAM is not memory mapped into the address space of blackfin from what I can tell.  the FRAM is a I2C device and would have to be read out directly    Howardlong can correct me if I'm wrong

If someone can get me the first 4Mb of SDRAM using this commands who has a boot 1.03 It would help allot.
:SYST:FRE? 0,1048576
:SYST:FRE? 1048576,1048576
:SYST:FRE? 2097152,1048576
:SYST:FRE? 3145728,1048576

you can save each memory block then combine them at either a dos prompt or linux commandline and let me know how to get it
right now I've dumped 1.14 with boot 1.04 and looking at it I see nothing that look like the same eye catchers
rigup used this
      0      02 00 84 00 10 00
      6      <16 bytes of XXTEAKey>
     22      20 00
     24      <16 bytes of RC5Key1>
     40      <16 bytes of RC5Key2>
     56      08 00
     58      <8 bytes of bit-shuffled ECC public key>
     66      40 00
     68      <64 bytes of some ASCII-HEX data>
    132      <END>

for the MSO1000Z the only change was offset zero for the eye catcher
      0      01 00 84 00 10 00
then a change to how things are encrypted.

I see nothing like that in the dump I have so they could have simple bit shifted things to scramble them for example.
That's why I want to see a dump of boot 1.03 SDRAM

[MiataMuc]

pm

[smgvbest]

pm

Thank you.   this confirms to me that the keys for the DSA815 where found in another manner.  the eye catchers are not there in your dump or mine with V1.14 and boot 1.04 which means to me they where found in another way

[Orange]

pm

Thank you.   this confirms to me that the keys for the DSA815 where found in another manner.  the eye catchers are not there in your dump or mine with V1.14 and boot 1.04 which means to me they where found in another way

On the DS2000 the change came when a new hardware revision was introduced. With new hardware on the DS2000A RIGOL also introduced customized encryption parameters for each unit. Perhaps they did the same on the DS815. I don't think the boot code plays a role here, apart from the fact that you cannot downgrade.

Have you tried scanning the dumps for license keys with 'rigup search [KEYFILE] DUMPFILE'

BTW on a DS2000A you need at least 32Meg to get results

[smgvbest]

pm

Thank you.   this confirms to me that the keys for the DSA815 where found in another manner.  the eye catchers are not there in your dump or mine with V1.14 and boot 1.04 which means to me they where found in another way

On the DS2000 the change came when a new hardware revision was introduced. With new hardware on the DS2000A RIGOL also introduced customized encryption parameters for each unit. Perhaps they did the same on the DS815. I don't think the boot code plays a role here, apart from the fact that you cannot downgrade.

Have you tried scanning the dumps for license keys with 'rigup search [KEYFILE] DUMPFILE'

BTW on a DS2000A you need at least 32Meg to get results

Yes I did,  I also tried a 8MB dump on mine and neither found anything.   I also tried dumping over SCPI the first 32Meg and it could not find anything either

[Orange]

pm

Thank you.   this confirms to me that the keys for the DSA815 where found in another manner.  the eye catchers are not there in your dump or mine with V1.14 and boot 1.04 which means to me they where found in another way

On the DS2000 the change came when a new hardware revision was introduced. With new hardware on the DS2000A RIGOL also introduced customized encryption parameters for each unit. Perhaps they did the same on the DS815. I don't think the boot code plays a role here, apart from the fact that you cannot downgrade.

Have you tried scanning the dumps for license keys with 'rigup search [KEYFILE] DUMPFILE'

BTW on a DS2000A you need at least 32Meg to get results

Yes I did,  I also tried a 8MB dump on mine and neither found anything.   I also tried dumping over SCPI the first 32Meg and it could not find anything either

I scanned my DSA815 via dumping over SCPI, it is an early one.

Boot is 01.02
Version of main board is 00.04
Firmware is 1.09
 
I found 5 license keys in the lower part of the flash memory, basically the four I put in myself, and there was already one present, probably for the tracking gen.

Also i tried to find the known private key in the flash (32 meg) and did not find it.

[smgvbest]

Yes,  Looking at a pre boot 1.04 I was able to find the same in even a 4Meg dump but in mine at 1.04 a search turned up nothing at all.
The eye catcher bytes seem to typically be there but not on the DSA's.  I manually went through the 32Meg dump and saw nothing that looked familiar
I do have one throught and maybe something that's been tried before but I was thinking if I went into the licensing screen and entered even a bad key it would maybe have a deciphered bit strings in memory at that point so I'm going to try that out next

[cybernet]

if u are after the bootloader for the DSA than i would assume that it is located at 0x2000 0000 in the Flash as a LDR stream. (thats how the DS2x does it)
0x2000 0004 contains the length of the LDR stream for the bootloader

try to dump that and use a tool like ldrviewer to see if it actually contains a LDR stream if so - i have a nice LDR loader for ida pro that i can share.
usually the bootldr (again DS2x knowledge) then loads yet another LDR which is the actual APP image.
dumping from 0x0 onwards is RAM - which gets overwritten by the bootloader with the APP image, so i doubt u get that data out with SCPI.

best to use gdb, and break the boot process before the APP image gets executed.

from my old notes

Code: [Select]

BootMode (BMODE) is 0001b

The kernel boots from address 0x20000000 in asynchronous memory bank 0.
The first byte of the boot stream contains further instructions whether the memory is eight or 16 bits wide.
BootLoader takes care of:

bfin init (EBIU, PLL, PORTS, DMA, SPORT)
fpga init
lcd init and displaying ultravision & rigol logo
load the application image LDR from flash @0x20040000+0x4 (first 4 bytes contain length of LDR stream)
optionally firmware upgrade via DS2000Update.GEL
run bfin executable from RigolDsExe.ldr (you need to disable any interrupts quickly or it will crash)

[Macbeth]

try to dump that and use a tool like ldrviewer to see if it actually contains a LDR stream if so - i have a nice LDR loader for ida pro that i can share.

Hi cybernet,

Please share... anything about Rigol and Blackfin. I'm quickly learning about it as I just bricked my DM3058E doing a firmware downgrade using the Rigol method of a supplied file on a USB stick plugged into it. I've flashed these firmwares before and not had a problem, but this time Murphy got me

I've been reading up on the ADSP-BF531 documentation and the Rigol binary file appears to follow the LDR format, just prefixed with a null terminated RIGOL firmware ID string. An example is the previous DM3058 firmware available here.

I've got the 90 day trial of VisualDSP running and tried that LDRViewer application, but it doesn't seem to like the Rigol files even when I strip the header firmware string out and start on the 4 byte address, 4 byte count, and 2 byte flag immediately after it. But following the headers and blocks manually in a hex editor it seems ok.

Now, I have to re-flash using the JTAG port. I'm guessing the supplied rigol firmware minus the id string is probably ok. I only have an Altera USB blaster so had a look at the official tools and nearly had a heart attack at the prices  - is it possible to flash with the USB blaster? I also noticed an Olimex ARM-USB-OCD tool that looks reasonably priced and supports debugging so would be worthwhile for me to have a go at reversing this thing and fixing bugs that Rigol are so slow to...

I've also got an, ahem, evaluation version of IDA Pro 6.6+SDK and found a Blackfin module but haven't had much luck getting it to work, it seems to be for an earlier version

Anyway, any help much appreciated

Sorry to move off track from the DSA guys, but there is a lot of info here relevant to my DMM. Why do Rigol love the Blackfin DSP so much? It seems like total overkill for a simple DMM  Though I guess if they paid for all the licensed tools for their scopes and stuff... and their devs are used to it... maybe it makes sense?

[Asmyldof]

Hey Guys and Gals,

I want to aware-nize you all of this post I made in chat:
New Bootloaders for DG5 and DP800

Also, @smgvbest, once I have time again from the freelance assignment from hell (should be soon), as I am interested in hacking the DS815 myself as well, I could look into the rigup code, possibly confer about what I see and how that fits the "old dump" you have and how that might be adapted to the new one.

[smgvbest]

Thank you cybernet
I need to get a header on my JTAG port as I looks like mine was no populated then I will try that
I'm sure others have noticed but the newer keys seem to be mixed case vs. uppercase.
not sure what that implies though.

if u are after the bootloader for the DSA than i would assume that it is located at 0x2000 0000 in the Flash as a LDR stream. (thats how the DS2x does it)
0x2000 0004 contains the length of the LDR stream for the bootloader

try to dump that and use a tool like ldrviewer to see if it actually contains a LDR stream if so - i have a nice LDR loader for ida pro that i can share.
usually the bootldr (again DS2x knowledge) then loads yet another LDR which is the actual APP image.
dumping from 0x0 onwards is RAM - which gets overwritten by the bootloader with the APP image, so i doubt u get that data out with SCPI.

best to use gdb, and break the boot process before the APP image gets executed.

from my old notes

Code: [Select]

BootMode (BMODE) is 0001b

The kernel boots from address 0x20000000 in asynchronous memory bank 0.
The first byte of the boot stream contains further instructions whether the memory is eight or 16 bits wide.
BootLoader takes care of:

bfin init (EBIU, PLL, PORTS, DMA, SPORT)
fpga init
lcd init and displaying ultravision & rigol logo
load the application image LDR from flash @0x20040000+0x4 (first 4 bytes contain length of LDR stream)
optionally firmware upgrade via DS2000Update.GEL
run bfin executable from RigolDsExe.ldr (you need to disable any interrupts quickly or it will crash)

[JHERCULEES1]

DS4000 series Bandwidth (model type) Option Codes.

For those who have an interest in the DS4000, I have found the option codes for selecting the bandwidth .
This also sets the model type.

For example the code FAB9 will select 500Mhz, (DS405x), with all Decoders enabled.

The attached file contains all the details.

There are also two un-documented, possibly future, options called "Power Analysis" and "MA".

The option codes have been tested with firmware ver 00.02.00.00.04 and ver 00.02.01.00.03.

here he mentions unlocking the options in the rigol 4000 series but no mention of the private key that is needed for the tool to work ?

does anyone know what posts talk about the private key for the 4000 series , i located the private keys for both the 1000 and 2000 series but no 4000  private key

[Macbeth]

Re: Dead Rigol DM3058. Thanks to a lot of pointers in this thread I've managed to fix my DMMs corrupt flash.  Rigol wanted me to send it to them for some weird reason. Other manufacturers like Keithley have not had issue sending me raw chip level firmware files so I can hardware flash my own, but Rigol wouldn't. Sorry, but I prefer to DIY.

Oh. Windows 10 appears to be rubbish with this sort of stuff. BSOD's constantly since trying to get drivers to work with Olimex and Altera Blaster. The absurd driver protection scheme rules out most FTDI based devices. Linux is a far more sensible environment. Dual Boot FTW (with the grub loader remembering what OS I last booted) 

[MarkF]

here he mentions unlocking the options in the rigol 4000 series but no mention of the private key that is needed for the tool to work ?

does anyone know what posts talk about the private key for the 4000 series , i located the private keys for both the 1000 and 2000 series but no 4000  private key

I have a DS1000Z series scope.  However, if the DS4000 series is the same, the Riglol key generator will fill in the private key after you enter your serial number..

[nbritton]

What is the DS4064? I did a strings dump on the firmware update and that was in there.

Code: [Select]

$ strings DS4000Update.GEL | grep DS406
DS4064
Given Rigol's model naming system that would imply a 600 MHz DS4000 exists.

[wyx]

Hi, I am a EE student in US. I recently purchased a MSO2072scope and I follow the hack instruction using ubuntu to unlock my scope feature. However, there's always some error message while compiling the code from github. Can anyone help me with that? My scope is running software 03.01 and hardware 2.2 is it able to be upgraded using that hack??

[nbritton]

Hi, I am a EE student in US. I recently purchased a MSO2072scope and I follow the hack instruction using ubuntu to unlock my scope feature. However, there's always some error message while compiling the code from github. Can anyone help me with that? My scope is running software 03.01 and hardware 2.2 is it able to be upgraded using that hack??

What is the error message? What version of Ubuntu are you using, I would recommend the 14.04 LTS release.

[Macbeth]

Just remember with Ubuntu you often have to use sudo to do stuff. Like when compiling something you need to do sudo make install rather than make install.

I know obvious, but I wasted a whole day when I didn't realise that just accessing serial ports or USB also requires root privilege! 

[farzadb82]

Just remember with Ubuntu you often have to use sudo to do stuff. Like when compiling something you need to do sudo make install rather than make install.

I know obvious, but I wasted a whole day when I didn't realise that just accessing serial ports or USB also requires root privilege! 

It sounds like you need to create a udev rule for your device. You should really avoid running things as sudo when possible. The only time you'd absolutely have to is when you're installing something into the system. Other than that, you shouldn't have to run commands using sudo.

Here's a good reference for creating udev rules (http://ubuntuforums.org/showthread.php?t=168221). It talks specifically about creating rules for external media, but the same concepts can be applied to any usb device.

[Macbeth]

Just remember with Ubuntu you often have to use sudo to do stuff. Like when compiling something you need to do sudo make install rather than make install.

I know obvious, but I wasted a whole day when I didn't realise that just accessing serial ports or USB also requires root privilege! 

It sounds like you need to create a udev rule for your device. You should really avoid running things as sudo when possible. The only time you'd absolutely have to is when you're installing something into the system. Other than that, you shouldn't have to run commands using sudo.

Here's a good reference for creating udev rules (http://ubuntuforums.org/showthread.php?t=168221). It talks specifically about creating rules for external media, but the same concepts can be applied to any usb device.

Yes, that is exactly what I ended up doing. Thanks for reminding me!

I also had to add my account to the dialout group to allow me to use /dev/ttyUSBx

Oh, one thing that bugs me. I've installed the blackfin toolchain and whenever I am using UrJTAG (bfin-jtag) I've found the cursor keys seem to be mapped to something strange and so I just get things like "[]]]" output when I press a key. It makes recalling command history a PITA. I've also tried UrJTAG from the official repo using apt-get-install and with that version the command history and editing using cursor keys works as expected.