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.
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 ;-)
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
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.
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.
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";
}
#!/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)
Does the hacks works for DSA815 SAs?
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.
// 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.
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.
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";
}
#!/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.
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 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
Ahh very happy to hear that.
--
Darryl
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!
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 ?
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
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
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
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.
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
Windows user can use this Tool here to activate licenses:
https://github.com/xyphro/WinUsbTmc/releasesTo 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.
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 ...
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 ?
(...)
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!