Sniffing the Rigol's internal I2C bus

[cybernet]

Do you have the codemap_20688e - it isn't in your example above - I thought I'd try your function!

updated

[zibadun]

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. 

[cybernet]

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 ;-)

[zibadun]

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

[EV]

Hey Guys ,
I have located this new Firmware has anyone tried it.?

Did you update?

[cybernet]

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.

[ve7xen]

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)

[fqahmad66]

Does the hacks works for DSA815 SAs?

[docmandu]

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.

[zibadun]

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.

[darrylp]

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

[darrylp]

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

[darrylp]

Ahh  very happy to hear that.

--
 Darryl

[doma]

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!

[playfsx]

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 ?

[gierig]

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.

[mickpah]

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 

[mickpah]

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

[orbiter]

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

[doma]

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.

[doma]

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

[Xyphro]

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.

[cybernet]

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 ...

[Orange]

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 ?

[5V]

(...)

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.

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!