Sniffing the Rigol's internal I2C bus

[zombie28]

I've sent you PM

I replied to this message with the information you need

I have analysed your data and I think it is likely that DSA815 uses the same encoding method and elliptic curve as DS2k, but with different keys. However, if all curve parameters are the same, then it will be very easy to find out private key form the public one (which is somewhere in the firmware).

[cybernet]

is anyone working on gaining JTAG access to a DSA ? i can provide the schematics on how to patch it up ... dump the memory 0x0-0x20000000 with gdb, and then u should have the curve parameters. contact me if u need jtag access guidance.

[olsenn]

is anyone working on gaining JTAG access to a DSA ? i can provide the schematics on how to patch it up ... dump the memory 0x0-0x20000000 with gdb, and then u should have the curve parameters. contact me if u need jtag access guidance.

Can you tell me if the "ADZS-ICE-100B" emulator can be used for the blackfin MCU in the DSA815? Either way, if there is a cheaper/better alternative, please just name that.

[cybernet]

is anyone working on gaining JTAG access to a DSA ? i can provide the schematics on how to patch it up ... dump the memory 0x0-0x20000000 with gdb, and then u should have the curve parameters. contact me if u need jtag access guidance.

Can you tell me if the "ADZS-ICE-100B" emulator can be used for the blackfin MCU in the DSA815? Either way, if there is a cheaper/better alternative, please just name that.

seems like yes - but u can check for urjtag on the bfin uclinux pages to get a list or scroll up - i posted the compatible ones. 150$ sounds rather pricey for a stupid jtag adapter, i would get a cheaper one .. ;-)

[mickpah]

On an Australian Rigol reseller web site

"Due to large requirement reently, all of DS2072 sold before put on the shelf, few ordered units come in stock around 3rd of August, Please contact us early if you need urgently!" - their spelling not mine.

Appears to be stock of other models wonder what happened ? 

[jeremy]

I just bought one from Emona, hopefully I can get it soon. Which supplier was it?

[mickpah]

I just bought one from Emona, hopefully I can get it soon. Which supplier was it?

eyou, http://www.eyou.com.au/. got my dp832 there seem pretty good to deal with, notice they are starting to put rigol firmware up on site too for some stuff.
i think Emona is the official distributor, but as they didn't follow up on a promised firmware upgrade for my ds2072 so i moved on. don't believe it's a customer's job to chase sales/support they don't get many chances with this grumpy old man.

[bleckers]

I just bought one from Emona, hopefully I can get it soon. Which supplier was it?

eyou, http://www.eyou.com.au/. got my dp832 there seem pretty good to deal with, notice they are starting to put rigol firmware up on site too for some stuff.

I got mine from eyou just after the test codes got released and they were very fast to deliver. They also offer pickup if you live nearby and give them a call. I don't like anyone's chances of getting one in Aus any time soon.

[jeremy]

ironically enough, I bought one because I needed it, not because I knew about this. jackpot

[bleckers]

I had an old Tek DSO which I bought from uni when they were clearing surplus about 7 years ago, but one of the inputs had died on it recently. This hack just pushed me to finally upgrade.

[Uup]

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.

[adh]

There is a fair chance that they deliberately chose the level of difficulty they wanted us to encounter in hacking these models knowing full well that it would generate extra sales.

Have you seen, in general, Chinese programming for consumer devices? It's not very different for special devices, either. This is not the first time such ideas have been brought up in this thread. This is purely a case of ignorance and poor practices.

There is no well-known secure method to generate reasonably short license keys. There is relatively simple modification to their method that would allow to use roughly ~100bit ECC keys that are in the realm of "can be cracked in month with resources of university department" with comparable length of license key you have to type in, but it is not something that is widely recommended by cryptography community.

I would say that this scheme shows that somebody actually thought about security of this scheme but had to weight security against convenience and grossly underestimated the complexity of breaking 56bit ECC. With product keys it is almost standard practice to use ECDSA or RSA with ridiculously short keys, because it allows you to claim to management that it uses "secure asymetric cryptograpy" and nobody then cares about actual security of the used key. On the other hand license keys for most embedded things I've seen are so short that it's clear that they cannot use anything other than some checksum and rely on the assumption that nobody is going to spend time reverse engineering 10kEUR+ piece of hardware to build keygen for it.

[mikeselectricstuff]

There is no well-known secure method to generate reasonably short license keys. There is relatively simple modification to their method that would allow to use roughly ~100bit ECC keys that are in the realm of "can be cracked in month with resources of university department" with comparable length of license key you have to type in, but it is not something that is widely recommended by cryptography community.

I would say that this scheme shows that somebody actually thought about security of this scheme but had to weight security against convenience and grossly underestimated the complexity of breaking 56bit ECC. With product keys it is almost standard practice to use ECDSA or RSA with ridiculously short keys, because it allows you to claim to management that it uses "secure asymetric cryptograpy" and nobody then cares about actual security of the used key. On the other hand license keys for most embedded things I've seen are so short that it's clear that they cannot use anything other than some checksum and rely on the assumption that nobody is going to spend time reverse engineering 10kEUR+ piece of hardware to build keygen for it.

...of course for a product like this there is a really easy, very secure solution.
At manufacture, each unit has a randomly generated key, which is logged along with the serial number in the manufacturer's database. No mathematical relationship between key and serial = no keygen possible. With a timeout etc. to prevent brute-forcing, it doesn't even need to be very long.
Not hard to do, not hard to administer.

[JimFouch]

Years ago I was the head of a development team that put many man years into a piece of software. We often thought about putting copy protection on it. But, in the end, we decided it was so complicated to get running, that there were only two people on the planet that understood how it worked. We decided that if someone went through the trouble to steal it and *make it work* they deserved to have it for free... lol

[cybernet]

...of course for a product like this there is a really easy, very secure solution.
At manufacture, each unit has a randomly generated key, which is logged along with the serial number in the manufacturer's database. No mathematical relationship between key and serial = no keygen possible. With a timeout etc. to prevent brute-forcing, it doesn't even need to be very long.
Not hard to do, not hard to administer.

whatever the secret is, be it a hash, or some mathematical unrelated thing - it has to be stored on the device - and can therefore be found. they just choose a path with "sounds" good (we use ecc crypto and signatures) but given that it took 170ms to find the private key had not much clue of ecc crypto.

[alank2]

they just choose a path with "sounds" good (we use ecc crypto and signatures) but given that it took 170ms to find the private key had not much clue of ecc crypto.

Was it the private key that was found?  Or the public key.  Since the decryption process occurs on the device, did the device really have the private key for decryption and they use the public key to encrypt.  Is this one of the reasons why it was so easy to find the public key from the private key and not the other way around?

[cybernet]

Was it the private key that was found?  Or the public key.  Since the decryption process occurs on the device, did the device really have the private key for decryption and they use the public key to encrypt.  Is this one of the reasons why it was so easy to find the public key from the private key and not the other way around?

suggested bed time lecture http://en.wikipedia.org/wiki/Elliptic_Curve_DSA

[tlu]

I put the changes people suggested before into the original Rigen before I released it.

You should be able to just leave the seed at 1. If RiGen detects that the seed won't work, it'll automatically choose another one up to 10 times.

Thanks for the info regarding the seeding.

[zombie28]

Was it the private key that was found?  Or the public key.  Since the decryption process occurs on the device, did the device really have the private key for decryption and they use the public key to encrypt.  Is this one of the reasons why it was so easy to find the public key from the private key and not the other way around?

The public key is hardcoded in firmware together with other public ECC domain parameters, and private key is (was  ) kept by Rigol in secrecy. This is how assymetric cryptography works. However Rigol used flawed ECC parameters, namely they didn't use prime numer for 'modulus', so it was trivial to compute the private key. It wouldn't be so easy if Rigol used proper modulus.

[mikeselectricstuff]

...of course for a product like this there is a really easy, very secure solution.
At manufacture, each unit has a randomly generated key, which is logged along with the serial number in the manufacturer's database. No mathematical relationship between key and serial = no keygen possible. With a timeout etc. to prevent brute-forcing, it doesn't even need to be very long.
Not hard to do, not hard to administer.

whatever the secret is, be it a hash, or some mathematical unrelated thing - it has to be stored on the device - and can therefore be found.

Yes, but for only one device. Assuming it was stored securely (e.g. battery backed SRAM, BGA flash, protected MCU etc.), and there was no easy way to recover it without surgery, then any hacks would be limited to individual units. 

[ve7xen]

Yes, but for only one device. Assuming it was stored securely (e.g. battery backed SRAM, BGA flash, protected MCU etc.), and there was no easy way to recover it without surgery, then any hacks would be limited to individual units.

Mike, shocked to see you giving up so easily!

It might be more difficult than the current (trivial) approach, but there are doubtless plenty of bugs that can be exploited to dump the key out of memory in that case. For the end user, the hack may be as easy as the current one, it will just take more effort to implement. If that's not feasible, the firmware updates appear to be unsigned...

[Marc M.]

Can't we all agree on the fact the current protection scheme is very secure so there's no need to change it in future products  .  We just got lucky and stumbled upon their key!  After all, we certainly don't want to give them advise on how to prevent us from getting 'lucky' with future products do we??  Failing that, can we at least include some anti-Chinese government propaganda in every reply to guarantee that it's blocked?? 

[etc6849]

There's a test code for the DP832?  I would definitely buy one if someone could provide more information such as what it unlocks, etc...

Also, my DS2072 arrive this week.  It's a nice looking piece of equipment.  I ordered it a week ago from tequipment.net.  It appears to be from week 17 of 2013, so it came with the RP3300 probes (not the RP3300A probes).

The software version it came with is 00.01.00 and it has a 13 character serial number.  I gather I should update the firmware to the latest version before using the keygen?

I just bought one from Emona, hopefully I can get it soon. Which supplier was it?

eyou, http://www.eyou.com.au/. got my dp832 there seem pretty good to deal with, notice they are starting to put rigol firmware up on site too for some stuff.

I got mine from eyou just after the test codes got released and they were very fast to deliver. They also offer pickup if you live nearby and give them a call. I don't like anyone's chances of getting one in Aus any time soon.

[IanJ]

Hi all,

13 char serial here, applied using windows exe today using default settings.................perfect first time. Thanks to all those who worked on this.

Btw, I don't actually like the sprung hooks that came with my DS2072 probes (RP3300), I found they don't attach tightly enough to the probes themselves. Need very little pull and the probe is detached.

Ian.

[brob]

IanJ

I had the same problem as you until I realized I was not installing the clip attachments to the probes properly. Try to push them harder together and you should hear a click, very seem very solid to me once I installed them correctly