Sniffing the Rigol's internal I2C bus

[tsmith35]

"all" that is neede is a FW dump via jtag and gdb the rest shuld be simple (as seen on the other devices)

Is there a walk-through of how to do this on a Rigol scope? May increase the likelihood of getting a dump. Curiosity for me.

[Carrington]

"all" that is neede is a FW dump via jtag and gdb the rest shuld be simple (as seen on the other devices)

Is there a walk-through of how to do this on a Rigol scope? May increase the likelihood of getting a dump. Curiosity for me.

Read this:
https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg298338/#msg298338

[tsmith35]

Read this:
https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg298338/#msg298338

Thanks! Good material.

On the subject of a potential new private key, what about the possibility of using cloud resources (ala EC2 or similar) to recover the key?

[apelly]

rediscovered LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL in cybernet's post. I'll give that a go later.

Nope

[true]

Read this:
https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg298338/#msg298338

Thanks! Good material.

On the subject of a potential new private key, what about the possibility of using cloud resources (ala EC2 or similar) to recover the key?

If it's the same as any other Rigol product...absolutely unnecessary.

Not to mention that wouldn't work anyway, mind.

[olsenn]

Damn, that is depressing! I was all hyped and ready to buy a DS2072A too. The thought of 300MHz really got me hard.

[DL5TOR]

Damn, that is depressing! I was all hyped and ready to buy a DS2072A too. The thought of 300MHz really got me hard.

no super-compiuter needed the keys for the DSA815 (same System different keys) was generated in 1h after the Firmware was dumped
Btw most of  the info on how to get the keys is in this thread

73 de DL5TOR

[Carrington]

If it's the same as any other Rigol product...absolutely unnecessary.
Not to mention that wouldn't work anyway, mind.

Please be more clear.
  - You mean that now is not so easy to discover the public key.
  - Or that make a dump is not necessary because the private key has not changed.
  - 

[jeremy]

If they have changed the key to be based on a prime (like they should have at the start...), then I don't believe it will be as easy as just dumping the firmware. The only reason this hack worked is because rigol picked a silly private key.

[Carrington]

If they have changed the key to be based on a prime (like they should have at the start...), then I don't believe it will be as easy as just dumping the firmware. The only reason this hack worked is because rigol picked a silly private key.

Yes, is very likely, but then the sales of this product will plummet. And more with the series SDS2000 just around the corner.
This is extremely suspicious, seems like they're handing the market. Now for you, now for my... 

[jeremy]

If they have changed the key to be based on a prime (like they should have at the start...), then I don't believe it will be as easy as just dumping the firmware. The only reason this hack worked is because rigol picked a silly private key.

Yes, is very likely, but then the sales of this product will plummet.

Changing the key seems a bit silly if you still want people to hack it? Why not leave it the same?

They probably have a certain sales distribution of the models that they are trying to achieve to hit R&D payoff and profit goals (otherwise why release more expensive models which have the same hardware?). The naughty forum users around here (myself included) are ruining their forecasts 

[willb]

I just ordered a 2072 a few weeks ago and got a call that it came in yesterday. I'm going to pick it up on Monday. I have no idea if it's the A version though. I'm very anxious to see if the hack will work and what version I got!

[Carrington]

If they have changed the key to be based on a prime (like they should have at the start...), then I don't believe it will be as easy as just dumping the firmware. The only reason this hack worked is because rigol picked a silly private key.

Yes, is very likely, but then the sales of this product will plummet.

Changing the key seems a bit silly if you still want people to hack it? Why not leave it the same?

They probably have a certain sales distribution of the models that they are trying to achieve to hit R&D payoff and profit goals (otherwise why release more expensive models which have the same hardware?). The naughty forum users around here (myself included) are ruining their forecasts 

I don't know if we are right about their intentions. But, I don't think that we are ruining their forecasts (not my intention).
And who knows, for now we just know that for a DS2072A (only one) the keygen not works.

[olsenn]

Changing the key seems a bit silly if you still want people to hack it? Why not leave it the same?

What makes you think Rigol wants us to hack their scopes? They don't! Trust me, the measly few sales they are getting from eevblog forum members buying their cheapest (least profit-per-sale) DSO is not going to even make a dent in their sales.

The bigger boost in their sales is from Dave and the others releasing positive reviews of the item. Dave reviewed the (unhacked) 200MHz model and said good things about it; the video is on Rigol's website as well as the product description sites of various vendors. Purchasing departments in fortune 500 companies are the ones who make Rigol the big money.

Essentially, I think Rigol is happy to provide a low cost DSO for hobbyists; however, that low cost DSO is their 70MHz version with nothing unlocked.

[marshallh]

Here's my Rigol experience:

1. Ordered 2072 from Tequipment with discount. Arrived timely, but DOA.



Emailed Tequipment. They started a warranty claim(!) and provided Rigol's UPS label. I stuck a photo of the problem in the box.

6 weeks later, I receive out of nowhere the same Rigol cardboard box via Fedex. No email from Rigol or Tequipment.
SN was reset to 0000's and trial options removed (I had not hacked the scope)
However the scope seems to work properly now...


Let's do avalanche pulser comparison, before (70mhz labeled) and after (200mhz labeled) bandwiths.

[Dave Turner]

Forgive me if I've missed it; this thread is so long that it is easy to miss and/or forget posts.

I seem to recall that the DS1074Z codes were suggested to be similar to the DS2000, but do not recollect whether any tests were made on the DS1074Z-S.

[Co6aka]

f they have changed the key to be based on a prime...

If the firmware itself can be patched, then it doesn't really matter what the key is. Also, in the process of "sniffing" around, did anyone figure out if they're just setting/clearing option flags somewhere in memory, based upon valid key detections at boot time?

[jeremy]

Changing the key seems a bit silly if you still want people to hack it? Why not leave it the same?

What makes you think Rigol wants us to hack their scopes? They don't!

Actually, that was my point 

Modifying the firmware is an option, but it isn't what occurred here. iirc: firmware was dumped via jtag, crypto routines were reversed (and subsequently discovered to be MIRACL), silly private key derived, keygen written. None of this involved modifying the firmware.

Firmware mods are a different can of worms (easy to brick, checksum hunting is hard, no model info is stored in firmware updates, etc)

[Sienna]

Just another confirmation.
I got a DP832 from Tequipment recently (I assume from the batch after the heatsink debacle).  Codes worked fine.

Thanks to everyone in the thread for their hard work!

[arvidj]

Just another confirmation.
I got a DP832 from Tequipment recently (I assume from the batch after the heatsink debacle).  ...

I asked TEquipment about the DP832 before I ordered mine and their response was ...

All the DP800 models that are ordered after 10/14/13 have a newly designed board that solves the the over heating issue. Any ordered before that are in the process of being repaired.

So either way you appear to be covered with the only question being the hassle factor if yours needs to be repaired.

[zener]

Has the private key changed in the DSA815TG with firmware rev 00.01.06?

[AndersAnd]

Has the private key changed in the DSA815TG with firmware rev 00.01.06?

No, the same key still works with 00.01.06: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg311584/#msg311584

[AndersAnd]

Awesome work guys, finally made it all the way through this topic.

I'm trying to figure out this code table made by 'Uup' for DS4000:

I 've been experimenting with the option codes on my DS4024 and have worked out the various options. However, I was unable to change the model number/bandwidth.    It appears as though it may be done via a different means, such as hardware jumpers or other hardware configuration bits. Not really sure at this point.

Attached, and below, is what I have worked out. I suspect that the only people who will really gain from this information are the dealers who will be able to work out their own option licence keys to sell to customers, instead of getting them from Rigol.   

Anyhow... 

 
DS4000 Series DSO Option Codes:

Licence code string is in the following format:


LLLLLLL-RLGLLDS-****LLL-LLLLLLL
                ABCD


     A       B       C       D
   54321   54321   54321   54321

   x0000   00000   00000   00000   0 = Official, 1 = Trial
   0x000   00000   00000   00000   must = 0
   00x00   00000   00000   00000   See Note(2)
   000x0   00000   00000   00000   Option Bank Selection
   0000x   00000   00000   00000   Option Bank Selection

   00000   x0000   00000   00000   Licence re-application bit
   00000   0x000   00000   00000   must = 0
   00000   00x00   00000   00000   must = 0
   00000   000x0   00000   00000   must = 0
   00000   0000x   00000   00000   must = 0

   00000   00000   x0000   00000   must = 0
   00000   00000   0x000   00000   must = 0
   00000   00000   00x00   00000   See Note(2)
   00000   00000   000x0   00000   See Note(2)
   00000   00000   0000x   00000   See Note(2)

   00000   00000   00000   x0000   FlexRay Decode or alternate option
   00000   00000   00000   0x000   CAN Decode or alternate option
   00000   00000   00000   00x00   I2C Decode or alternate option
   00000   00000   00000   000x0   SPI Decode or alternate option
   00000   00000   00000   0000x   RS232 Decode or alternate option


More Detailed description of Bits:


A - Control Bits

1. Option bank selection: Available options =1 (if = 1 then A.2 should = 0)
2. Option bank selection: Alternate options =1 (if = 1 then A.1 should = 0)
3. See Note(2)
4. Must = 0
5. Trial = 1, See note(1) : Official = 0


B - Control Bits

1. Must = 0
2. Must = 0
3. Must = 0
4. Must = 0
5. Alternating bit allows re-installation of the same licence, without uninstalling it (indicates "Option Installed!")


C - Control Bits

1. See Note(2)
2. See Note(2)
3. See Note(2)
4. Must = 0
5. Must = 0


D - Options (0 = OFF, 1 = ON)

1. RS232 Decode
2. SPI Decode
3. I2C Decode
4. CAN Decode
5. FlexRay Decode

Alternate Options (when A.1 =0 && A.2 =1)

1. Reserved (Empty Option)
2. Reserved (Empty Option)
3. Reserved (Empty Option)
4. Reserved (Empty Option)
5. Reserved (Empty Option)

 
Notes:

(1) Re-applying the same trial licence will extend the trial time by an additional 1932 minutes to a maximum time of 5796 minutes.

(2) If any one of these bits are = 1, then re-applying the same licence will result in the error "Licence Unavailable!"
     If all of these bits are = 0, then re-applying the same licence will result in the message "The Option Has Been Installed!" or, in the case of a trial licence with maximum time reached, the message "Time Trial is Arrived!"
 

To work out the option code, use the following bit-to-code conversion table:

A = 00000
B = 00001
C = 00010
D = 00011
E = 00100
F = 00101
G = 00110
H = 00111
J = 01000
K = 01001
L = 01010
M = 01011
N = 01100
P = 01101
Q = 01110
R = 01111
S = 10000
T = 10001
U = 10010
V = 10011
W = 10100
X = 10101
Y = 10110
Z = 10111
2 = 11000
3 = 11001
4 = 11010
5 = 11011
6 = 11100
7 = 11101
8 = 11110
9 = 11111


Eg.

A) Option code to install SPI and FlexRay Decode Trial Options: 10001 00000 00000 10010 = T A A U
   LLLLLLL-RLGLLDS-TAAULLL-LLLLLLL

B) Option code to install all 5 official options: 00001 00000 00000 11111 = B A A 9
   LLLLLLL-RLGLLDS-BAA9LLL-LLLLLLL

 

Edit: use the above code you work out (eg. BAA9) along with your serial number and the private key to generate (eg. with RiKey) a license key. I only used the test key format above to indicate the placement of the code.

And compare the above table to this online key generator by 'studio25':

http://riglol.3owl.com/

DS4000 device options:
first character: D = official, V = trial
DSHB - RS232 Decoder
DSHC - SPI Decoder
DSHE - I2C Decoder
DSHJ - CAN Decode
DSHS - FlexRay Decoder
DSA9 - all options

Can anyone explain why the 3rd letter for 'all options' isn't the same as for all the other options? [A vs. H]
Wouldn't DSH9 work to?


Trying to relate the 4 license letters back to the individual options in the table:

       A           B           C           D
   54321   54321   54321   54321

   x0000   00000   00000   00000   0 = Official, 1 = Trial
   0x000   00000   00000   00000   must = 0
   00x00   00000   00000   00000   See Note(2)
   000x0   00000   00000   00000   Option Bank Selection
   0000x   00000   00000   00000   Option Bank Selection
   00011 = D   [3rd digit = 0 means the 1st of 4 "Note(2)" bits = 0]

   00000   x0000   00000   00000   Licence re-application bit
   00000   0x000   00000   00000   must = 0
   00000   00x00   00000   00000   must = 0
   00000   000x0   00000   00000   must = 0
   00000   0000x   00000   00000   must = 0
                10000 = S

   00000   00000   x0000   00000   must = 0
   00000   00000   0x000   00000   must = 0
   00000   00000   00x00   00000   See Note(2)
   00000   00000   000x0   00000   See Note(2)
   00000   00000   0000x   00000   See Note(2)
                             00111 = H   [for the last 3 of 4 "Note(2)" bits = 111]
                         or 00000 = A   [for the last 3 of 4 "Note(2)" bits = 000]

   00000   00000   00000   x0000   FlexRay Decode or alternate option
   00000   00000   00000   0x000   CAN Decode or alternate option
   00000   00000   00000   00x00   I2C Decode or alternate option
   00000   00000   00000   000x0   SPI Decode or alternate option
   00000   00000   00000   0000x   RS232 Decode or alternate option
                                          11111 = 9   [for all 5 options selected]


DSH9 / DSA9


A vs. H changes 3 out of four bits in the "Note(2)":

(2) If any one of these bits are = 1, then re-applying the same licence will result in the error "Licence Unavailable!"
     If all of these bits are = 0, then re-applying the same licence will result in the message "The Option Has Been Installed!" or, in the case of a trial licence with maximum time reached, the message "Time Trial is Arrived!"

D as the 1st letter means the 1st of 4 "Note(2)" bits is always = 0.

H as the 3rd letter means the last 3 of 4 "Note(2)" bits are always = 111. [All 4 "Note(2)" bits combined = 0111].
A as the 3rd letter means the last 3 of 4 "Note(2)" bits are always = 000. [All 4 "Note(2)" bits combined = 0000].

[jsykes]

Has the private key changed in the DSA815TG with firmware rev 00.01.06?

No, the same key still works with 00.01.06: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg311584/#msg311584

 
Has anyone tried the latest DSA815 firmware 00.01.07 with the same private key ?

[dr.diesel]

Has anyone tried the latest DSA815 firmware 00.01.07 with the same private key ?

Yup, works just fine.