Hacking the Rigol DHO800/900 Scope

[AceyTech]

I'm sort of a casual Linux user with rudimentary skills.  Does upgrading a Rigol DHO804 to a higher level require upper echelon computer hacking skills, or can us children of a lesser god accomplish it without trashing a $400+ initial investment?

Provided you haven't upgraded to the latest firmware, you should have a fairly easy time following the guide in this post. If you upgraded, you'll need to learn how to downgrade to do the hacks.
Good luck.

[Fungus]

I'm sort of a casual Linux user with rudimentary skills.  Does upgrading a Rigol DHO804 to a higher level require upper echelon computer hacking skills

No.

or can us children of a lesser god accomplish it without trashing a $400+ initial investment?

Yes.

[AceyTech]

Additionally, they are running Android 7 which is, as we say here in the north east, wicked old.

Rigol is building on v10 (API 29.Q), but targets v7 (API 25.N_MR1) <-- 9 revs behind the latest available.

So speaking of Android 7: Any of you Android peeps working on running Android 11 or 12 on the DHO's that some of the SBC vendors are shipping with their RK3399 boards? 
Maybe it's me, but it sure seems like the newer versions are so much faster at booting. --actually, pretty much everything.

[Fungus]

or can us children of a lesser god accomplish it without trashing a $400+ initial investment?

Yes.

Remember: There's two ways to do it. One is easy - just change the "vendor.bin" file to a higher model (even a 900 series).

adb connect 192.168.XX.YY:55555
adb push vendor.bin /rigol/data

The other way is more involved and needs you to generate license keys for extra features.

[AndyBig]

I would like to experiment with various option strings (using the new key) but whatever SCPI option command I send to the scope I get no reply.
Is this the normal way when the option license doesn't match or do I still have a bad update?
If you're on firmware v1.2 it's not that hard to put a ":SYST:OPT:INST DHO800-RLU@0000000000000000000000000000000000000" string in your web
interface and let me know the output (if any)

When sending an option to SCPI that is unknown to the oscilloscope (for example, sending :SYST:OPT:INST DHO900-BODE to a DHO814 oscilloscope), nothing happens at all. No notifications on the oscilloscope, no response to the SCPI terminal. When sending a known option, but with an incorrect key, a notification “License invalid” appears on the oscilloscope screen and a counter of remaining attempts, starting from 9. There is also no response in the SCPI terminal.
I no longer remember what happened when sending a known option with the correct key It seems that there was no response in SCPI either, and a notification like “Option installed” appeared on the oscilloscope screen. But I can't guarantee that I remember correctly
PS: After all attempts to add an option have been exhausted, new attempts to add an option will cause a "Trial option install failure" notification to appear on the screen. SCPI still does not receive any response.

[zelea2]

When sending an option to SCPI that is unknown to the oscilloscope (for example, sending :SYST:OPT:INST DHO900-BODE to a DHO814 oscilloscope), nothing happens at all. No notifications on the oscilloscope, no response to the SCPI terminal. When sending a known option, but with an incorrect key, a notification “License invalid” appears on the oscilloscope screen and a counter of remaining attempts, starting from 9. There is also no response in the SCPI terminal.

Thanks for that Andy. My scope and computer were in different rooms and I've never noticed the messages. With all this testing I keep my scope half of the day on
and what I do to minimize wear is turn off all channels and also stop the acquisition. I also reduce the screen brightness a lot:

Code: [Select]

echo 20 > /sys/devices/platform/backlight/backlight/backlight/brightnessThe number of failed attempts are recorded in FRAM but they don't seem to survive a reboot. The entire structure stored in FRAM at address 0x100 handles licenses.
Your RKey.data is also stored there and right after the individual options:

Code: [Select]

000001B0 13 09 00 00 | ED F6 FF FF | 04 00 00 00 | FC FF FF FF | 82 7F 61 DD | 70 08 00 03
000001C8 15 09 00 00 | EB F6 FF FF | 04 00 00 00 | FC FF FF FF | 14 4F 66 AA | 70 08 00 02First word identifies the option Type (0x913 == RLU) followed by the complement word followed by length (4) then complemented
then the CRC32 of the following 4 bytes. The last '03' means that 3 attempts have been made for the RLU option.

All these attempts can easily be cleared just by setting the length of the entire structure to 0xB0 (and the following complement word) .. this saves rebooting the scope.

[zelea2]

Boyz and girlz we're back in business!
https://github.com/zelea2/rigol_vendor_bin
It was as simple as appending 16 chars to the option strings. Now the .lic files came back to my /rigol/data directory.
There is no feedback from the SCPI interface even for the correct licenses, you only get a message on the scope's screen.

It took me a while to understand all the parameters I had to set (including a new COptInfo structure). Have a look at test.c if you're curious.
First I've tried to use scope's gdbserver; that failed, then I've used a static precompiled  gdbserver for arm64 that didn't work either
In the end I've used a precompiled static gdb to trace my test program and understand the CApiLicense_verifyOption function.
That wasn't very pleasant because I had no GEF or any graphic interface and I had to type a lot of gdb commands.
Probably if I will spend some more time I will get the remote debugging working but I'll save that for the next license change 

[Randy222]

Boyz and girlz we're back in business!
https://github.com/zelea2/rigol_vendor_bin
It was as simple as appending 16 chars to the option strings. Now the .lic files came back to my /rigol/data directory.
There is no feedback from the SCPI interface even for the correct licenses, you only get a message on the scope's screen.

It took me a while to understand all the parameters I had to set (including a new COptInfo structure). Have a look at test.c if you're curious.
First I've tried to use scope's gdbserver; that failed, then I've used a static precompiled  gdbserver for arm64 that didn't work either
In the end I've used a precompiled static gdb to trace my test program and understand the CApiLicense_verifyOption function.
That wasn't very pleasant because I had no GEF or any graphic interface and I had to type a lot of gdb commands.
Probably if I will spend some more time I will get the remote debugging working but I'll save that for the next license change 

1) The lic file was written, but did that option become activated?
1a) Are these 16B (16 chars) random, or are the generated?
2) I already have options strings that work on my 804(as a 914). So, are you saying after I up the FW to 00.01.02.00.02 all I need to do is resend same option strings but pad the end of each string with random 16bytes (chars)?
3) If #2 will not work, can we still use the rigol-tools gen tool using RKey.data (rename to Key.data for the tool), and then add random 16bytes (16 chars) to the end of each string?

If none of that, then can you add clarity.
Thanks.

[muumi]

Got the RKey file mystery solved.




func LoadKeys() ([]uint8, error, []uint8) {
   data, err := ioutil.ReadFile(Expand(keyFile))
   if nil != err {
      return nil, err, nil
   }

   for i, _ := range data {
      data ^=  byte(i & 0xFF);
   }

   dd := decodeDefaultXXTEA(data)
   fmt.Printf("%s", dd)
   i := bytes.Index(dd, []uint8(";"))
   if -1 == i {
      return nil, errors.New("key format error"), nil
   }
   return dd[i+1:], nil, dd
}

[zelea2]

1) The lic file was written, but did that option become activated?
1a) Are these 16B (16 chars) random, or are the generated?
2) I already have options strings that work on my 804(as a 914). So, are you saying after I up the FW to 00.01.02.00.02 all I need to do is resend same option strings but pad the end of each string with random 16bytes (chars)?
3) If #2 will not work, can we still use the rigol-tools gen tool using RKey.data (rename to Key.data for the tool), and then add random 16bytes (16 chars) to the end of each string?

If none of that, then can you add clarity.

Yes they are activated.
AES keys in Key.data and RKey.data are different and they are both tied to your hardware. We don''t know how to generate them. The license options are decrypted with these keys
so you can't just append chars to an old option string. The keys are also encoded differently (the RKey one has an extra XOR with an incremented vector after it's XXTEA scrambled).
The new option strings have 16 extra characters at the end (the length is checked) and in the current firmware they are discarded but they might be used in the future.

[MalikovVV]

I added the BND, AUTO and RLU options to my Rigol812 v.1.2.0.2 - everything works!
Thanks

[Randy222]

1) The lic file was written, but did that option become activated?
1a) Are these 16B (16 chars) random, or are the generated?
2) I already have options strings that work on my 804(as a 914). So, are you saying after I up the FW to 00.01.02.00.02 all I need to do is resend same option strings but pad the end of each string with random 16bytes (chars)?
3) If #2 will not work, can we still use the rigol-tools gen tool using RKey.data (rename to Key.data for the tool), and then add random 16bytes (16 chars) to the end of each string?

If none of that, then can you add clarity.

Yes they are activated.
AES keys in Key.data and RKey.data are different and they are both tied to your hardware. We don''t know how to generate them. The license options are decrypted with these keys
so you can't just append chars to an old option string. The keys are also encoded differently (the RKey one has an extra XOR with an incremented vector after it's XXTEA scrambled).
The new option strings have 16 extra characters at the end (the length is checked) and in the current firmware they are discarded but they might be used in the future.

Right, new key "RKey.data", unique to each device.

So can we just pull that over to the rigol-tool generator as "Key.data", gen some options, then just add some random 16 chars to the end of each string before sending the options back in via SCPI?

The 16 chars are random?

[zelea2]

So can we just pull that over to the rigol-tool generator as "Key.data", gen some options, then just add some random 16 chars to the end of each string before sending the options back in via SCPI?
The 16 chars are random?

Do not change the file name. My program behaves differently if it finds RKey.data instead of Key.data
The 16 chars at the end don't matter.

[akos96]

I did the unthinkable. Say hello to my DHO800, I call it the "quiet and deadly"
I had a spare standard PC case fan (10 or 12mm ? not sure what's the measurement for these, just the normal case fan), I cut the plug off the end of it, soldered it to the original two pin connector, then ziptied it to the back.
Of course I added a metal grill to it so I don't put stuff in the blades. The CPU_CHIP runs at 48.7 ˚C and CPU_AMBIENT 45.6 ˚C and it is completely mute.
It is a 12V fan but running at 7V it is perfectly quiet and moves a lot of air still.
I HIGHLY recommend it for everyone. VERY important note though: If you plug in the fan cable through the venthole then first reassemble the back and screw in the 4 screws because it is unreachable after ziptieing the fan. Zipties are cheap so you can cut them off if something is blocked anyway.
Unfortunately the carrying handle is the "deadly" part because the back side of the fan is still exposed so it is not recommended to be fingered. through the carryhole.   
No 3D printing required or any cutting of the original enclosurem just zipties and only the old fan got hurt in the process.

[Fungus]

Of course I added a metal grill to it so I don't put stuff in the blades. The CPU_CHIP runs at 48.7 ˚C and CPU_AMBIENT 45.6 ˚C and it is completely mute.

What was the temperature before?

Did you remove the old fan?

[AndyBig]

The number of failed attempts are recorded in FRAM but they don't seem to survive a reboot.

No, the number of unsuccessful attempts is saved when rebooting and turning off the power, I already checked this However, even if the number of attempts is exhausted, the option with the correct key is still activated

Boyz and girlz we're back in business!
https://github.com/zelea2/rigol_vendor_bin

Cool! I activated all the available options for myself, everything went without a hitch Thank you for the great work you did!

[akos96]

Of course I added a metal grill to it so I don't put stuff in the blades. The CPU_CHIP runs at 48.7 ˚C and CPU_AMBIENT 45.6 ˚C and it is completely mute.

What was the temperature before?

Did you remove the old fan?

Yes I did remove the old one. I cut the wire of the old fan to get the same female plug to solder onto the fan power cables. Originally the fan was a 3 pin fan PWM controllable but I removed the thrid one of course to not dangle around.

If I remember correctly the stock temp was 54C CPU_AMBIENT and 58C CPU_CHIP so it is even better and even quieter lol. And despite the huge fan it is just small enough to not interfere with the stand because of the extra width.

[alrox]

Hi , I've just got a DHO802 and ver 1.2 of the software is installed, I have installed a dongle wi-fi and found I can increase the BW and Mem depth, but only with firmware 1.1. so a couple of questions.
Is it possible to downgrade the firmware to 1.1 from 1.2?
If so where is a copy of the 1.1 firmware located - not on any site I've googled so far.?
is the process the same as the upgrade process?
Thanks

[zelea2]

Is it possible to downgrade the firmware to 1.1 from 1.2?

You don't need to downgrade, all versions can use options now. See a few messages above.

[Aleksandr]

Tell me, do the firmware of the DHO800 and DHO900 still differ from each other? I think that when switching from version 800 to version 900 by changing the vendor, it is not entirely correct. Perhaps the 800 version is missing some files? And the 800 version differs from the 900 in the presence of additional files that are not created when the vendor changes.

[Fungus]

Tell me, do the firmware of the DHO800 and DHO900 still differ from each other?

They've never differed.

Look at the name of the firmware file: "DHO800_DHO900_Update.GEL"

I think that when switching from version 800 to version 900 by changing the vendor, it is not entirely correct. Perhaps the 800 version is missing some files? And the 800 version differs from the 900 in the presence of additional files that are not created when the vendor changes.

No.

[alrox]

Not being a coding guru, and disassembler god; what process do you need to follow? Or, do you have to learn some new coding languages to get the options to work.
I'm sure there are a lot of DhO800 newbies (like me) waiting for a step-by-step guide (like on page 14 by the brilliant Serg65536) to gratefully follow. Referring back to a complex discussion with people who understand the intricacies of complex assembles languages are not really helpful. Referring to a step-by-step guide now that would be helpful.
thanks you for your thoughts never-the-less.

[Randy222]

Not being a coding guru, and disassembler god; what process do you need to follow? Or, do you have to learn some new coding languages to get the options to work.
I'm sure there are a lot of DhO800 newbies (like me) waiting for a step-by-step guide (like on page 14 by the brilliant Serg65536) to gratefully follow. Referring back to a complex discussion with people who understand the intricacies of complex assembles languages are not really helpful. Referring to a step-by-step guide now that would be helpful.
thanks you for your thoughts never-the-less.

It was C code, compiled against the device architecture.
C --> compile --> assembly

[Randy222]

The number of failed attempts are recorded in FRAM but they don't seem to survive a reboot.

No, the number of unsuccessful attempts is saved when rebooting and turning off the power, I already checked this However, even if the number of attempts is exhausted, the option with the correct key is still activated

Boyz and girlz we're back in business!
https://github.com/zelea2/rigol_vendor_bin

Cool! I activated all the available options for myself, everything went without a hitch Thank you for the great work you did!

yep. great work zelea2.

[zelea2]

Step-by-step guide:

• download the generator from here https://github.com/zelea2/rigol_vendor_bin
• Install adb on your linux or windows computer (if you haven't already)
• connect your scope to your local network and find its IP address then
• adb connect IP:55555
• adb -s IP:55555 pull /rigol/data/vendor.bin
• adb -s IP:55555 pull /rigol/data/RKey.data
• make sure that the generator and the 2 files you've downloaded are in the same directory and then generate all options
• rigol_vendor_bin -o
• Optional step: you can also modify your vendor.bin file (to change the scope type, serial number or MAC address) and then send it back to your scope with a push command
  
• open a browser and go to the scope IP address and click on SCPI commands
• copy and paste each option you desire installed in your browser and press "Send" (RLU for memory etc...)
• you won't get any confirmation in the browser but you'll see a message on your scope's display after each successful option is installed

That's it.