Author Topic: Sniffing the Rigol's internal I2C bus  (Read 1349316 times)

0 Members and 2 Guests are viewing this topic.

Offline zombie28

  • Regular Contributor
  • *
  • Posts: 69
Re: Sniffing the Rigol's internal I2C bus
« Reply #675 on: July 25, 2013, 11:09:35 PM »
Quote
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).
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 246
  • Country: 00
  • pm deactivated, use the search function ...
Re: Sniffing the Rigol's internal I2C bus
« Reply #676 on: July 25, 2013, 11:14:39 PM »
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.
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline olsenn

  • Frequent Contributor
  • **
  • Posts: 997
Re: Sniffing the Rigol's internal I2C bus
« Reply #677 on: July 25, 2013, 11:21:06 PM »
Quote
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.
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 246
  • Country: 00
  • pm deactivated, use the search function ...
Re: Sniffing the Rigol's internal I2C bus
« Reply #678 on: July 25, 2013, 11:25:40 PM »
Quote
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 .. ;-)
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline mickpah

  • Regular Contributor
  • *
  • Posts: 148
  • Country: au
    • Yeti Hacks
Re: Sniffing the Rigol's internal I2C bus
« Reply #679 on: July 26, 2013, 09:08:16 AM »
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 ?  >:D
 

Offline jeremy

  • Frequent Contributor
  • **
  • Posts: 703
  • Country: au
Re: Sniffing the Rigol's internal I2C bus
« Reply #680 on: July 26, 2013, 09:13:46 AM »
I just bought one from Emona, hopefully I can get it soon. Which supplier was it?
 

Offline mickpah

  • Regular Contributor
  • *
  • Posts: 148
  • Country: au
    • Yeti Hacks
Re: Sniffing the Rigol's internal I2C bus
« Reply #681 on: July 26, 2013, 09:21:00 AM »
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.
 

Offline bleckers

  • Contributor
  • Posts: 10
  • Country: au
Re: Sniffing the Rigol's internal I2C bus
« Reply #682 on: July 26, 2013, 12:09:35 PM »
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.
 

Offline jeremy

  • Frequent Contributor
  • **
  • Posts: 703
  • Country: au
Re: Sniffing the Rigol's internal I2C bus
« Reply #683 on: July 26, 2013, 02:15:51 PM »
ironically enough, I bought one because I needed it, not because I knew about this. jackpot
 

Offline bleckers

  • Contributor
  • Posts: 10
  • Country: au
Re: Sniffing the Rigol's internal I2C bus
« Reply #684 on: July 26, 2013, 02:24:29 PM »
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.
 

Offline Uup

  • Regular Contributor
  • *
  • Posts: 71
  • Country: au
Re: Sniffing the Rigol's internal I2C bus
« Reply #685 on: July 26, 2013, 11:13:55 PM »
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.
« Last Edit: July 27, 2013, 12:49:59 AM by Uup »
Ununpentium
 

Offline adh

  • Contributor
  • Posts: 15
  • Country: cz
Re: Sniffing the Rigol's internal I2C bus
« Reply #686 on: July 26, 2013, 11:20:12 PM »
Quote from: benemorious
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.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 10110
  • Country: gb
    • Mike's Electric Stuff
Re: Sniffing the Rigol's internal I2C bus
« Reply #687 on: July 27, 2013, 01:42:46 AM »


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.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline JimFouch

  • Newbie
  • Posts: 4
Re: Sniffing the Rigol's internal I2C bus
« Reply #688 on: July 27, 2013, 01:48:57 AM »
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
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 246
  • Country: 00
  • pm deactivated, use the search function ...
Re: Sniffing the Rigol's internal I2C bus
« Reply #689 on: July 27, 2013, 03:21:13 AM »
...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.
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline alank2

  • Super Contributor
  • ***
  • Posts: 1710
Re: Sniffing the Rigol's internal I2C bus
« Reply #690 on: July 27, 2013, 03:31:39 AM »
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?
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 246
  • Country: 00
  • pm deactivated, use the search function ...
Re: Sniffing the Rigol's internal I2C bus
« Reply #691 on: July 27, 2013, 03:34:21 AM »
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
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline tlu

  • Regular Contributor
  • *
  • Posts: 142
Re: Sniffing the Rigol's internal I2C bus
« Reply #692 on: July 27, 2013, 04:41:54 AM »
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.
 

Offline zombie28

  • Regular Contributor
  • *
  • Posts: 69
Re: Sniffing the Rigol's internal I2C bus
« Reply #693 on: July 27, 2013, 08:27:36 AM »
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.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 10110
  • Country: gb
    • Mike's Electric Stuff
Re: Sniffing the Rigol's internal I2C bus
« Reply #694 on: July 27, 2013, 10:59:43 AM »
...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. 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline ve7xen

  • Frequent Contributor
  • **
  • Posts: 642
  • Country: ca
    • VE7XEN Blog
Re: Sniffing the Rigol's internal I2C bus
« Reply #695 on: July 27, 2013, 11:30:40 AM »
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...
73 de VE7XEN
 

Offline Marc M.

  • Regular Contributor
  • *
  • Posts: 124
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #696 on: July 27, 2013, 11:47:49 AM »
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??  >:D >:D >:D
Don't replace the cap, just empty the filter!
 

Offline etc6849

  • Contributor
  • Posts: 19
Re: Sniffing the Rigol's internal I2C bus
« Reply #697 on: July 28, 2013, 05:30:16 AM »
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.
 

Offline IanJ

  • Frequent Contributor
  • **
  • Posts: 716
  • Country: scotland
  • Pro EE guy many years ago, now it's a hobby.
    • IanJohnston.com
Re: Sniffing the Rigol's internal I2C bus
« Reply #698 on: July 28, 2013, 05:56:19 AM »
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.
« Last Edit: July 28, 2013, 05:58:29 AM by IanJ »
 

Offline brob

  • Newbie
  • Posts: 4
  • Country: ca
Re: Sniffing the Rigol's internal I2C bus
« Reply #699 on: July 28, 2013, 05:59:41 AM »
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
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf