Sniffing the Rigol's internal I2C bus

[Gandalf_Sr]

I don't know if it still works but have you tried the SCPI system that's mentioned in this thread https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg657936/#msg657936 It's only 17 pages to read.

[chbrules]

I've been trying to do some research, and it appears you can still hack the Rigol DS2072A no problem? Questions:

1) Is any special hardware required? I saw a .pdf guide (http://gotroot.ca/rigol/D2072A%20Unlocking%20Guide.pdf) on gotroot.ca that says you can just hook it to your PC via USB and run some apps to get the private key with modified firmware.

2) Can you still use this modified firmware to do the hack? Or is there an updated version?

3) If that guide isn't accurate anymore, is there a new guide?

Anything else I should know? I'm new to this. Thanks! 

[PE1DHI]

Hello Rigol stars! 

I'am the owner from a brand new DSA832-TG and wonderd if someone can tell or has already hacked it or set free the options?

DSA832-TG
DSA8F1701xxxxx
Firmware 00.01.00

I read this long thread with pleasure, go on! 
With regards, Jugo

[Crille77]

Yeeehaaaa! I now have hacked my MSO1104Z-S with full options using USBBlaster.


USBBlaster can be used BUT it is slow as a old modem for the PC!!!! I'm not kidding... But it works! ;-)
When I dumped my memory, I made copies of my dumpfile during the dump and tested rigup to see if it could find any kees in it. When I found keys, I aborted the dump. It took a awful lot of time but now I'm a happy owner of a fully unlocked scope.

I just wanted to share some pinouts and findings to all you out there to make it easier for you if you also will use the USB blaster...
And a HUGE thank you to all the people that made all of this work! You are awesome!

Pinout:

Connect 2 & 10 from the JTAG and both GND from the scope to the breadboard so they are connected!

When you have connected the scope with the JTag and connected the powersupply again, be careful not to damage the cables and close the two parts together as tight as possible to make shure the cooling works. This is how it looked for me:


Use a breadboard and connect all GND connections together! (here is a picture of my scope open with the JTAG and breadboard connected.


One other thing that needs to be done if you are using Linux as rmd79 wrote in a previous post, is to modify the Makefile for the patched rigup tool.
Change the following line from:

LDFLAGS                 := -O2 -Wl,-dead_strip

To:

LDFLAGS                 := -O2 -Wl,--gc-sections -s

Again... A HUGE thank you to all that made this possible!

[McBryce]

Nice pics.

If you had used the "speed 6000" command (increases connection speed to 6Mhz) before doing the savebin it would have sped the process up considerably. The entire dump takes about 7 or 8 minutes at 6Mhz.

McBryce.

[Crille77]

Nice pics.

If you had used the "speed 6000" command (increases connection speed to 6Mhz) before doing the savebin it would have sped the process up considerably. The entire dump takes about 7 or 8 minutes at 6Mhz.

McBryce.

Thanks!

I used openocd and that doesn't recognize speed for the USBBlaster... I tried every command related to speed without any luck... Maybe it would work with the "genuine" USBBlaster and not the cheep ebay version that I got.

[McBryce]

Not sure about that. I used a Segger with the J-Link software.

McBryce.

[Fluxx1122]

Hey Guys,

nice work

since I saw Crille77s post, I remembered I got a genuine USB-Blaster myself. I thought I would give it a try myself and unlock my MSO1104z.
So far, unfortunately, it hasn't worked ;(
First I tried Win7 (vm) and openocd in different configs, reinstalled usbblaster driver and ftdi multiple times.
PID/VID are default (checked), still openocd reports

Code: [Select]

Error: unable to open ftdi device: usb_open() failed in procedure 'init'

So far so good, thought maybe it is about the Windows being a VM, so I tried Linux Ubuntu 14.04.
On Linux I can get access to the JTAG and openocd 0.7.0 recognizes the usbblaster.

Code: [Select]

openocd -d2 -f interface/altera-usb-blaster.cfg -f target/imx28.cfg
Open On-Chip Debugger 0.7.0 (2013-10-22-08:31)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.sourceforge.net/doc/doxygen/bugs.html
debug_level: 2
Warn : Adapter driver 'usb_blaster' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
dcc downloads are enabled

Which looks good so far, but a few seconds after it outputs;

Code: [Select]

Info : This adapter doesn't support configurable speed
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: imx28.cpu: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : Embedded ICE version 15
Error: unknown EmbeddedICE version (comms ctrl: 0xffffffff)
Info : imx28.cpu: hardware has 2 breakpoint/watchpoint units
Warn : WARNING: unknown debug reason: 0xf
Warn : ThumbEE -- incomplete support

Anyone any idea how to solve it?
Since it reports "all ones", I figuered that there may be pullups/pulldowns required, but in the post it did't look like it?

Regards
Fluxx1122

[Fluxx1122]

Ok, I got it!
using the newer ocd seems to fix it.

Now unlocked with all options

But Crille77 got it right, it's got glacial speed, took about 10h for the 34MB needed to get the keys.

Thanks to all contributers who made this possible

Regards
Fluxx1122

[uski]

I'am the owner from a brand new DSA832-TG and wonderd if someone can tell or has already hacked it or set free the options?

DSA832-TG
DSA8F1701xxxxx
Firmware 00.01.00

As far as I know the newest DSA815 are not hacked yet. I didn't read anything about the DSA832. Maybe you can dump its memory and post it, it may help (but it may expose your S/N depending on what part of the memory you are dumping)

I might buy a DSA832 if it becomes hacked -  otherwise it's just too expensive with no options.

[smgvbest]

I'm still looking for dumps of a hacked 815 running the latest firware so I can compare to a unhacked 815 and would love a dump of a 832 if someone is willing to provide one.    I'm not the best at this but been trying.

[Asmyldof]

@smgvbest : Not exactly your request, but would a dump of another unhacked "new" DSA815-TG help?

Been too busy still to actually open it up (and read all of the first pages to get "a hang"), but willing to let it jump the queue if it helps you at all.

[longview]

I did an FRAM dump on my DSA815 (latest hardware, unhacked) using SCPI :SYST:FRE? 3145728,1048576 (the lower 3 MB seemed generally uninteresting).
My hope was to see if the FWrite command could be used to reset the license status of the trials, but I can't see any of the data changing even between reboots so that's probably a non starter.

There was a string repeated two times in the dump in the form of SECRET<14 digit key>.
I tried searching for it in the thread but doesn't look like it's been posted before or anywhere online. It's certainly the right length to be a public key, and rigup 0.2 spits out a private key when I feed that into it (not the one used on previous FWs), but the license keys don't work (not entirely unexpected).

Being way out of my depth here, I can't say what this is, could be a red herring or a joke left for us by the developers. Any thoughts?

[Asmyldof]

In my experience with the kind of design or development Rigol uses, I don't think it's a red herring or a joke. I've run across companies with similar tactics and the more general thing to do is change request codes, public keys and their location. So you may well have found half the puzzle, now only need to find the new request codes to apply?

Anyway, I have only used the DSA815-TG I have for a few hours to test it, as the project I needed it for got cancelled/postponed (still not clear on which), I could do an FRAM dump this weekend to compare, see if you can divine some meaning from differences. I might be willing to make some time to read up on the relevant threads and join in, but that depends a bit on the result of a customer visit today.

I'm even willing to work through Git for anything that can be "scrubbed" of my device's ID and just have it all out on Github in some account or another, let other people follow the steps and results.

[longview]

Yeah, it would be silly not to pursue the secret. They have probably changed the request codes too, if they've changed the way the cipher is implemented then it becomes more difficult.

Some other possible avenues:
It seems to be possible to write ASCII text to arbitrary FRAM locations using SCPI commands, but probably not binary values. The license key storage is duplicated in the FRAM, possibly for fault finding or anti-tamper, but depending on how often the checking is done it might be possible to overwrite both stores over SCPI.

Assuming the key turns out to be difficult to crack, we know the firmware will keep options already installed using old keys, it could be possible to overwrite the key stores with license information generated from old option keys.
Resetting the countdown timer could potentially be quite simple if I can work out where that information is stored in the FRAM.

I think the easiest way to work out new option codes is by brute force, the keyspace isn't massive (less than 2 million combinations) and if we can work out the option codes for the trial keys already installed then the full versions should be pretty close (usually at least).
Only issue with that is I don't know how to convert the keys I can read on the screen or see in the FRAM into the format used to activate the option.

E: some more information, could be useful:
Installing and reading installed license keys can be done with these commands:
:SYSTem:LKEY? <int between 1-5, 3 is probably 10 Hz RBW and returns nothing for me)
My system has two keys installed for EMI and AMK, for those numbers the return is two keys with a 0x0A between

:SYSTem:LKEY <key with no spaces> seems to install keys, returns nothing but shows a message on screen if it's wrong

The keys seem to be stored in order of entry in the FRAM, presumably the license type is contained in the key or in one of the bytes before or after they key in RAM.

[Asmyldof]

Well, it is absolutely certain that the keys are of the same format, we know that, we also know that the options are kept between upgrades, so that seriously limits the changes they could have made.

90/10 likelihood they only changed the parameters to the key system and not the actual key system itself.

I did see a topic chain a while ago about someone making a PIC add-on (I think it was PIC) on the I2C to the FRAM that kept resetting the time-out on the trial options, as an alternative to making the entire FRAM write protected. I'm thinking of applying that until I manage to re-hack the new HW/FW/FlashLoader.

[TheSteve]

Don't forget the potential option of finding a way to install the older firmware just long enough to enable the features and then upgrading to current firmware.

[Asmyldof]

I have a feeling reverting the flashery-upery-datery thing is either more tiresome, or more risky than finding the new hack.

But I may be wrong. Not vested deep enough in the detailed matter of hacking Rigols yet. Once I am, I'm going to look into the DG series as well.

[Howardlong]

Well, it is absolutely certain that the keys are of the same format, we know that, we also know that the options are kept between upgrades, so that seriously limits the changes they could have made.

90/10 likelihood they only changed the parameters to the key system and not the actual key system itself.

I did see a topic chain a while ago about someone making a PIC add-on (I think it was PIC) on the I2C to the FRAM that kept resetting the time-out on the trial options, as an alternative to making the entire FRAM write protected. I'm thinking of applying that until I manage to re-hack the new HW/FW/FlashLoader.

If that's for the 815, that was a feature I put forward here (as was the pins 7&8 trick). The PIC mod only reset the FRAM "clock" (not the RTCC), but allowed other updates to happen like static LAN config that was disabled by simple shorting of 7&8.

I have the complete FRAM dump somewhere if you need it.

[Asmyldof]

Ah yes, the name rings bells :-)

I'm not very PICcy, so I hadn't checked it yet. Working on the Freelance assignment from hell right now, so it feels like I'm constantly out of time. But one way or another that's about to change soon.

[Howardlong]

Ah yes, the name rings bells :-)

I'm not very PICcy, so I hadn't checked it yet. Working on the Freelance assignment from hell right now, so it feels like I'm constantly out of time. But one way or another that's about to change soon.

There was someone else who did a similar thing early on on the 2000 series scopes based on another device, an AVR perhaps, I can't remember, but like many of us, we feel at home in our own comfort zones, and PIC has been mine for a very long time, with occasional dalliances elsewhere as necessary. The PIC solution I am sure is one of very many that could be used.

[Asmyldof]

Oh I'm happy using the PIC as well. Just too rusty to just download and get going with what little tools I have for them.

I do like the AVR better. Fits my personal taste better, but I'm not without TI/Freescale/NXP experience either. Or 68000/ix86/8080 for that matter.


Worst case I can always improvise a simple PIC programmer with an AVR :-P

[smgvbest]

If that's for the 815, that was a feature I put forward here (as was the pins 7&8 trick). The PIC mod only reset the FRAM "clock" (not the RTCC), but allowed other updates to happen like static LAN config that was disabled by simple shorting of 7&8.

I have the complete FRAM dump somewhere if you need it.

@Howardlong,   could I get a copy of that FRAM dump? please??

[Howardlong]

If that's for the 815, that was a feature I put forward here (as was the pins 7&8 trick). The PIC mod only reset the FRAM "clock" (not the RTCC), but allowed other updates to happen like static LAN config that was disabled by simple shorting of 7&8.

I have the complete FRAM dump somewhere if you need it.

@Howardlong,   could I get a copy of that FRAM dump? please??

PM'd.

[smgvbest]

If that's for the 815, that was a feature I put forward here (as was the pins 7&8 trick). The PIC mod only reset the FRAM "clock" (not the RTCC), but allowed other updates to happen like static LAN config that was disabled by simple shorting of 7&8.

I have the complete FRAM dump somewhere if you need it.

@Howardlong,   could I get a copy of that FRAM dump? please??

PM'd.

Got it
Thank you