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

0 Members and 1 Guest are viewing this topic.

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: Sniffing the Rigol's internal I2C bus
« Reply #300 on: July 03, 2013, 08:58:51 pm »
Do you have the codemap_20688e - it isn't in your example above - I thought I'd try your function!

updated
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline zibadun

  • Regular Contributor
  • *
  • Posts: 112
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #301 on: July 03, 2013, 11:04:01 pm »
Do you have the codemap_20688e - it isn't in your example above - I thought I'd try your function!

updated

it compiled but what string should i pass to it (lic_skipped)?  i tried s/n 20 bytes, getting back 35.  don't think I'm doing it right. 
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: Sniffing the Rigol's internal I2C bus
« Reply #302 on: July 03, 2013, 11:10:33 pm »
Do you have the codemap_20688e - it isn't in your example above - I thought I'd try your function!

updated

it compiled but what string should i pass to it (lic_skipped)?  i tried s/n 20 bytes, getting back 35.  don't think I'm doing it right.

that would be a bit too easy ;-) this is not a keygen, its a chunk that explains the 4 magic bytes e.g. VSAH, DSAH ... they serial/key algo is magnitudes more complicated/obsfuscated ...
and i leave it as a challenge, so everybody can have a bit fun tinkering with it for now ;-)
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline zibadun

  • Regular Contributor
  • *
  • Posts: 112
  • Country: us
Sniffing the Rigol's internal I2C bus
« Reply #303 on: July 04, 2013, 03:32:29 am »
that would be a bit too easy ;-) this is not a keygen, its a chunk that explains the 4 magic bytes e.g. VSAH, DSAH ... they serial/key algo is magnitudes more complicated/obsfuscated ...
and i leave it as a challenge, so everybody can have a bit fun tinkering with it for now ;-)

It converts 4 digits of base 32 (5 bits) to 5 digits of base 16 (4 bits)...

dsa9 = 1c01f
dsar = 1c00f
dsaa = 1c000

right?

I don't think so. Look at the calloc call, making a 28 1 byte element array. Must be something to do with the 28 character code. But may be I'm wrong
 

Offline EV

  • Frequent Contributor
  • **
  • Posts: 525
  • Country: fi
  • Aficionado
Re: Sniffing the Rigol's internal I2C bus
« Reply #304 on: July 04, 2013, 07:11:31 am »
Hey Guys ,
I have located this new Firmware has anyone tried it.?

Did you update? :-//
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: Sniffing the Rigol's internal I2C bus
« Reply #305 on: July 04, 2013, 07:26:46 am »
that would be a bit too easy ;-) this is not a keygen, its a chunk that explains the 4 magic bytes e.g. VSAH, DSAH ... they serial/key algo is magnitudes more complicated/obsfuscated ...
and i leave it as a challenge, so everybody can have a bit fun tinkering with it for now ;-)

It converts 4 digits of base 32 (5 bits) to 5 digits of base 16 (4 bits)...

dsa9 = 1c01f
dsar = 1c00f
dsaa = 1c000

right?

right - 0x1c = permanent option, 0x9c = temporary option - last 3 nibbles are the bitflags for the options.
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline ve7xen

  • Super Contributor
  • ***
  • Posts: 1192
  • Country: ca
    • VE7XEN Blog
Re: Sniffing the Rigol's internal I2C bus
« Reply #306 on: July 04, 2013, 07:58:47 am »
In case somebody uses IP to talk to the scope

found a small VXI-11 module here https://github.com/alexforencich/python-vxi11

After installing the module, a short python script:

import vxi11
rigol = vxi11.Instrument("192.168.x.x")
print(rigol.write(":SYSTem:OPTion:INSTall LLLLLLL<your favorite code>LLLLLLLLLL"))

Thanks for the heads up on the module. I've combined it with one of my favourite simple tools apinger which can execute commands when hosts go up or down (in addition to tracking/acting on latency/loss). In this case I'm triggering my python script within a few seconds of the scope booting up, which then stores the config a la the other script posted above (much simpler with VXI), loads the license key, and restores the config. I just run this on a server that's on anyway and the options will be installed within a few seconds of the scope booting up.

Code: (apinger.conf) [Select]
user "nobody"
group "nogroup"

alarm default {
# When the 'DOWN' alarm state is changed to UP, run this command
command off "/usr/local/bin/ds2000.py %t"
}
alarm down "down" {
time 10s
}
target default {
interval 5s
alarms "down"
}
target "192.168.65.169" {
description "Rigol DS2000";
alarms override "down";
}

Code: (ds2000.py) [Select]
#!/usr/bin/env python

LICENSE = "LLLLLLLRLGLLDSDSA9LLLLLLLLLL"

import vxi11, sys, time

retries = 0
while retries < 30:
try:
rigol = vxi11.Instrument(sys.argv[1])
config = rigol.ask_raw(":SYSTem:SETup?")
rigol.write(":SYSTem:OPTion:INSTall " + LICENSE)
rigol.write_raw(":SYST:SET " + config)
sys.exit(0)
except(SystemExit):
raise
except:
retries = retries + 1
time.sleep(1)
73 de VE7XEN
He/Him
 

Offline fqahmad66

  • Regular Contributor
  • *
  • Posts: 79
  • Country: 00
Re: Sniffing the Rigol's internal I2C bus
« Reply #307 on: July 04, 2013, 10:17:17 am »
Does the hacks works for DSA815 SAs? >:D
« Last Edit: July 04, 2013, 10:19:27 am by fqahmad66 »
 

Offline docmandu

  • Contributor
  • Posts: 17
Re: Sniffing the Rigol's internal I2C bus
« Reply #308 on: July 04, 2013, 12:04:47 pm »
sry, but its not that simple ;-)
try something like this but reversed.

Haven't read everything here yet.. but saw this snippet of code.. not sure if you're wondering how to do the reverse, but it's actually very simple. What the code does is basically turn every input character in a 5 bit value.. the entire output is then chopped up in 4 bit nibbles and converted to a hex character for display.

So.. doing the reverse is just writing the entire output value as a binary string, then converting every 5 bits back to a character using codemap_ee00d0.

Code: [Select]
//                               0    1    2     3     4     5     6     7     8     9                               
unsigned char encode_tbl[] =   { 0x0, 0x0, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f,
                             //                                          A     B     C   
                                 0x0, 0x0, 0x0,  0x0,  0x0,  0x0,  0x0,  0x0,  0x1,  0x2,
                             //  D    E    F     G     H     I     J     K     L     M
                                 0x3, 0x4, 0x5,  0x6,  0x7,  0x0,  0x8,  0x9,  0xa,  0xb,
                             //  N    O    P     Q     R     S     T     U     V     W
                                 0xc, 0x0, 0xd,  0xe,  0xf,  0x10, 0x11, 0x12, 0x13, 0x14,
                             //  X     Y     Z
                                 0x15, 0x16, 0x17 };

Ie. PDUY9N9QTS9PQSWPLAETRD3UJHYA code gives 68E56FB3EE8C3ED7428D5009178F3241EC0.
So for example for the first letter doing the reverse, take 68, which is binary 0110 1000, the first 5 bits 01101 = 0xD .. and 0xD in that table is P. Repeat for all the rest.


But like I said.. not sure if this was what you were looking for.


 

Offline zibadun

  • Regular Contributor
  • *
  • Posts: 112
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #309 on: July 04, 2013, 12:16:11 pm »
In case somebody uses IP to talk to the scope

found a small VXI-11 module here https://github.com/alexforencich/python-vxi11

After installing the module, a short python script:

import vxi11
rigol = vxi11.Instrument("192.168.x.x")
print(rigol.write(":SYSTem:OPTion:INSTall LLLLLLL<your favorite code>LLLLLLLLLL"))

Thanks for the heads up on the module. I've combined it with one of my favourite simple tools apinger which can execute commands when hosts go up or down (in addition to tracking/acting on latency/loss). In this case I'm triggering my python script within a few seconds of the scope booting up, which then stores the config a la the other script posted above (much simpler with VXI), loads the license key, and restores the config. I just run this on a server that's on anyway and the options will be installed within a few seconds of the scope booting up.

Code: (apinger.conf) [Select]
user "nobody"
group "nogroup"

alarm default {
# When the 'DOWN' alarm state is changed to UP, run this command
command off "/usr/local/bin/ds2000.py %t"
}
alarm down "down" {
time 10s
}
target default {
interval 5s
alarms "down"
}
target "192.168.65.169" {
description "Rigol DS2000";
alarms override "down";
}

Code: (ds2000.py) [Select]
#!/usr/bin/env python

LICENSE = "LLLLLLLRLGLLDSDSA9LLLLLLLLLL"

import vxi11, sys, time

retries = 0
while retries < 30:
try:
rigol = vxi11.Instrument(sys.argv[1])
config = rigol.ask_raw(":SYSTem:SETup?")
rigol.write(":SYSTem:OPTion:INSTall " + LICENSE)
rigol.write_raw(":SYST:SET " + config)
sys.exit(0)
except(SystemExit):
raise
except:
retries = retries + 1
time.sleep(1)

Thanks for the code Keenan!  Very cool.
 

Offline darrylp

  • Regular Contributor
  • *
  • Posts: 127
  • Country: gb
Re: Sniffing the Rigol's internal I2C bus
« Reply #310 on: July 04, 2013, 07:09:14 pm »
I might have missed it, but the DSA9 code, the one that says official options. Will that work on a scope that has its trial minutes expired ?
For that power cycle of the scope of course I understand.
--
 Darryl

 

Offline darrylp

  • Regular Contributor
  • *
  • Posts: 127
  • Country: gb
Re: Re: Sniffing the Rigol's internal I2C bus
« Reply #311 on: July 04, 2013, 07:18:34 pm »
I might have missed it, but the DSA9 code, the one that says official options. Will that work on a scope that has its trial minutes expired ?
For that power cycle of the scope of course I understand.
--
 Darryl

i could not test that with real trail options, but when trail options where loaded (VSA), the DSA key overwrites
in my test.

I was meaning the trial time expired minute wise. ie I'm down to less than 1800 mins and I've only used the scope for one evening.... Plus a few quick 10 minute play a rounds.


--
 Darryl

 

Offline darrylp

  • Regular Contributor
  • *
  • Posts: 127
  • Country: gb
Re: Sniffing the Rigol's internal I2C bus
« Reply #312 on: July 04, 2013, 07:51:43 pm »
Ahh  very happy to hear that.

--
 Darryl

 

Offline doma

  • Contributor
  • Posts: 11
  • Country: 00
Re: Sniffing the Rigol's internal I2C bus
« Reply #313 on: July 04, 2013, 08:29:09 pm »
HI All,

I have a DS2072 - I was lucky to have it purchased 4 months ago so before today's "high demand".

Anyway, I had the 0.0.1.0.5 FW installed when it arrived in the box. Today I updated it to the latest FW: 0.1.1.0.2.

Then I applied the

LLLLLLL-RLGLLDS-DSARLLL-LLLLLLL
and
LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL
codes.

Results:
- It stays on 200 Mhz, with BW limits 20M/100M, and 2ns/div, says it's a DS2202 even after power cycling
- The options are activated only for the current power session, they are gone after reboot.

Thanks for the great work on this, highly appreciated!
« Last Edit: July 04, 2013, 08:48:00 pm by doma »
 

Offline playfsx

  • Contributor
  • Posts: 23
  • Country: gr
Re: Sniffing the Rigol's internal I2C bus
« Reply #314 on: July 04, 2013, 10:36:22 pm »
Today batronix (the store from i buy the ds2072) sent a e-mail with a firmware update, now im not ask for firmware update and i thing that this is not coincident, isn't it ?
With a hex editor i found that is the version 00.01.01.00.02... did anyone else get similar e-mail ?
In 2004 nobody knows that you're a robot surfing the web, today they try to stop us using captcha and other human technologies,
but history showed us only the strongest survive, and humans aren't made from steel.
 

Offline gierig

  • Newbie
  • Posts: 8
  • Country: de
Re: Sniffing the Rigol's internal I2C bus
« Reply #315 on: July 04, 2013, 10:47:39 pm »
Quote
i found that is the version 00.01.01.00.02... did anyone else get similar e-mail ?

it's allreday link to the bottom of this here:
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684


And Yes fix some Bugs, and the DSA9xxx Codes are still Valid.
gierig
 

Offline mickpah

  • Regular Contributor
  • *
  • Posts: 148
  • Country: au
    • Yeti Hacks
Re: Sniffing the Rigol's internal I2C bus
« Reply #316 on: July 04, 2013, 10:48:30 pm »
So much in this thread now so I hope I not repeating a question.
can some one put  FW: 0.1.1.0.2. up for download please ?

thanks

PS, Rigol DP832 Power supply delivery last week, too busy to tear it apart aside from the excentric keypad and I have to extend my shelve a bit to hold it I'm really happy.
Bonus , it has lots of firmware options to hack  :)
 

Offline mickpah

  • Regular Contributor
  • *
  • Posts: 148
  • Country: au
    • Yeti Hacks
Re: Sniffing the Rigol's internal I2C bus
« Reply #317 on: July 04, 2013, 10:50:31 pm »
So much in this thread now so I hope I not repeating a question.
can some one put  FW: 0.1.1.0.2. up for download please ?


don't worry,  as I clicked post gierig answered my question
« Last Edit: July 04, 2013, 11:10:49 pm by mickpah »
 

Offline orbiter

  • Frequent Contributor
  • **
  • Posts: 619
  • Country: gb
  • -0 Resistance is Futile
Re: Sniffing the Rigol's internal I2C bus
« Reply #318 on: July 04, 2013, 10:53:50 pm »
Today batronix (the store from i buy the ds2072) sent a e-mail with a firmware update, now im not ask for firmware update and i thing that this is not coincident, isn't it ?
With a hex editor i found that is the version 00.01.01.00.02... did anyone else get similar e-mail ?

Yes I got a FW update email too from Batronix. Which Included a link to the Rigol website so I could request the new FW files 00.01.01.00.02.

However I didn't need the file as I know some friends at a great forum called the EEVBlog :D
 

Offline doma

  • Contributor
  • Posts: 11
  • Country: 00
Re: Sniffing the Rigol's internal I2C bus
« Reply #319 on: July 05, 2013, 08:21:41 am »

tested some codes:

DSA9 is all options VSA9 is same but then with trail options
DSA9 overwrites VSA9, VSA can not overwrite DSA
xSA5 is same as xSA9

xSA2 is only 110 and 200 Mhz options on
xSA3 is Trigger and bandwidth options on
xSA6 is mem56 and bandwidth options on
xSA7 is trigger and mem56 and bandwidth on
xSA8 is decoder and mem56 and bandwidth on

xSAB is only Trigger options on
xSAC is only decode options on
xSAE is only mem56 on

Good job Wim13 - so we know that:

0000x   trigger
000x0   decode
00x00   memory
xx000   200Mhz

Do you have a facility for bandwidth testing?  I wonder what the xx in xx000 correlate to:

00000 - ? could 00 mean the factory setting, a DS2072 would be a DS2072, a DS2102 would be a DS2102, etc.
10000 - Forced DS2072 ???  Can someone verify this one - what does "DSAS" show for a model number?
01000 - Forced DS2102
11000 - Forced DS2202

Thanks,

Alan

How do these make the options across reboots permanent? The DSA9 for me with DS2072- FW  0.1.1.0.2. made 200MHz permanent while leaving the options volatile.
 

Offline doma

  • Contributor
  • Posts: 11
  • Country: 00
Re: Sniffing the Rigol's internal I2C bus
« Reply #320 on: July 05, 2013, 09:10:26 am »

In order to get a Permanent Option Key for your DSO it would have to be generated using your specific DS2000 serial number.
Did you send your Serial number to Someone?? 
Probably not, then do NOT expect to have a Option  Key Code for permanent Options!!

Thanks. I did not expect it to be permanent. However the 200MHz stayed permanent. So do you reckon this is a mere firmware bug - maybe even specific to FW version - , which we should also just enjoy?

Are the "options" keys different than the "type" keys. By looking at the Rigol_DS2000_patch_attiny85.ino (found here using google - all credit goes to author) they all are just values in FRAM. So do you suggest that the two codes work differently. More specifically they make the FW in case of the 200MHz to _write_ to FRAM (starting at locations 0x4A, 0x56, 0x5A and 0x62), while in case of the options it stays in volatile RAM?

Doma
« Last Edit: July 05, 2013, 09:25:04 am by doma »
 

Offline Xyphro

  • Regular Contributor
  • *
  • Posts: 116
  • Country: de
Re: Sniffing the Rigol's internal I2C bus
« Reply #321 on: July 05, 2013, 10:08:43 am »
Windows user can use this Tool here to activate licenses:

https://github.com/xyphro/WinUsbTmc/releases


To enable the license, use this command from the command line:
> WinUsbTmc Rigol ":SYST:OPT:INST LLLLLLLRLGLLDSDSA9LLLLLLLLLL"


Advantage of this WinUsbTmc tool compared to NI or Agilent IVI under windows is, that it is much smaller (No several hundred MB download required), much easier to integrate and... it is open source :-)
It is also possible to integrated it as DLL or static library in your own code.

« Last Edit: July 05, 2013, 10:17:10 am by Xyphro »
Looking for a unique, cheap versatile USB to GPIB adapter with standard USBTMC interface?
Build it yourself :-) https://github.com/xyphro/UsbGpib
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: Sniffing the Rigol's internal I2C bus
« Reply #322 on: July 05, 2013, 11:57:54 am »

In order to get a Permanent Option Key for your DSO it would have to be generated using your specific DS2000 serial number.
Did you send your Serial number to Someone?? 
Probably not, then do NOT expect to have a Option  Key Code for permanent Options!!

Thanks. I did not expect it to be permanent. However the 200MHz stayed permanent. So do you reckon this is a mere firmware bug - maybe even specific to FW version - , which we should also just enjoy?

Are the "options" keys different than the "type" keys. By looking at the Rigol_DS2000_patch_attiny85.ino (found here using google - all credit goes to author) they all are just values in FRAM. So do you suggest that the two codes work differently. More specifically they make the FW in case of the 200MHz to _write_ to FRAM (starting at locations 0x4A, 0x56, 0x5A and 0x62), while in case of the options it stays in volatile RAM?

Doma

suggest u read the whole thread ...
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline Orange

  • Frequent Contributor
  • **
  • Posts: 346
  • Country: nl
Re: Sniffing the Rigol's internal I2C bus
« Reply #323 on: July 05, 2013, 04:56:41 pm »

tested some codes:

DSA9 is all options VSA9 is same but then with trail options
DSA9 overwrites VSA9, VSA can not overwrite DSA
xSA5 is same as xSA9

xSA2 is only 110 and 200 Mhz options on
xSA3 is Trigger and bandwidth options on
xSA6 is mem56 and bandwidth options on
xSA7 is trigger and mem56 and bandwidth on
xSA8 is decoder and mem56 and bandwidth on

xSAB is only Trigger options on
xSAC is only decode options on
xSAE is only mem56 on

Good job Wim13 - so we know that:

0000x   trigger
000x0   decode
00x00   memory
xx000   200Mhz

Do you have a facility for bandwidth testing?  I wonder what the xx in xx000 correlate to:

00000 - ? could 00 mean the factory setting, a DS2072 would be a DS2072, a DS2102 would be a DS2102, etc.
10000 - Forced DS2072 ???  Can someone verify this one - what does "DSAS" show for a model number?
01000 - Forced DS2102
11000 - Forced DS2202

Thanks,

Alan
Why do you constantly ask other people to do your testing ? Don't you have a DS2000 your self ?
 

Offline 5V

  • Contributor
  • Posts: 17
Re: Sniffing the Rigol's internal I2C bus
« Reply #324 on: July 05, 2013, 05:57:32 pm »
(...)

Then I applied the

LLLLLLL-RLGLLDS-DSARLLL-LLLLLLL
and
LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL
codes.

Results:
- It stays on 200 Mhz, with BW limits 20M/100M, and 2ns/div, says it's a DS2202 even after power cycling
- The options are activated only for the current power session, they are gone after reboot.

Thanks for the great work on this, highly appreciated!

I did the above and it worked as described (thanks Doma :-+). My DS2072 is converted in a 200MHz/DS2202. It stays as 200MHz/DS2202 mode after reboot. 8)

It may sound a silly question but... is there a way to switch back to 70MHz/DS2072, just in case I need to send the scope back in the warranty period?

Thanks!

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf