Hacking the Rigol DHO800/900 Scope

[swperk]

From an earlier posting by Serg65536:

DHO800/DHO900 UNLOCK TOOLS

1) Install GOLang distribution

2) In the "run_DHO_Tools.bat":
- set the GO installation directory path
- set the IpAddress variable (your scope's address is on the IO tab of the "Utility" window)
- change options list, if DHO900
- change scopeID, if DHO900
- if you don't want to create a backup file and pull it to the computer, delete line 35, or make it comment like this:
rem call "adb\05 make Backup And pull it - adb rm updateGEL, sh buildGEL, pull.bat"

3) Run the "run_DHO_Tools.bat"

4) Send the generated SCPI commands to the scope via the SCPI browser tab, opened by the script. Common command view:
:SYSTem:OPTion:INSTall DHOX00-<option>@XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Scope reboot is not needed.

5) Check BW limit on the "About" tab and the memory depth (for the DHO804) on the "Options" tab of the "Utility" window.

PS: To remove installed options use the "adb\03 adb remove ALL options.bat" file or the ":SYSTem:OPTion:UNINstall" command from p268 of the DHO800/DHO900 Programming Guide.

UPDATE REASON: extending the description text.

All the necessary files and info are in this EEVBlog thread. Once you've run the batch file and generated the license key(s), be sure to copy the license string(s) from the SCPI_commands_generated.txt file (NOT from your terminal window) to avoid inserting any extraneous characters into your license string.

BTW, the measured bandwidth on my newly upgraded DHO914S is 265 MHz on each channel. Of course, activating more than one channel at a time cuts the sampling rate, so the bandwidth will be decreased.

[Martin72]

BTW, the measured bandwidth on my newly upgraded DHO914S is 265 MHz on each channel.

Show it please...

[ebastler]

is 250MHz BW now enabled in DHO800? how about AFG and LA capability? any news?

The original hacking approach, where the vendor.bin file is replaced and a DHO800 can be turned into a 900 (from a software perspective), has fallen out of fashion somewhat. Several users have observed offset voltages afterwards which could not be removed by auto-calibration, and have hence gone back to the DHO800 configuration.

The alternative approach (referred to by swperk two posts above) is limited to enabling the full memory and higher bandwidth on the DHO800 -- nominally 100 MHz, but close to 200 MHz in practice. Or it can upgrade a DHO914 to a 924. It does not have any side effects.

To my knowledge, nobody has reported on having actually tried any hardware upgrades (LA or AWG). Given the mentioned side effects of the DHO800-to-900 software hack, retrofitting the LA has become even less attractive in my view. Adding the AWG to a DHO900 (non-S version) would require a copy of the AWG piggyback board; I have not seen any efforts in that direction beyond photos of the original board.

[Fungus]

BTW, the measured bandwidth on my newly upgraded DHO914S is 265 MHz on each channel.

Show it please...

I had 1.6ns rise time on my DHO804 when I copied the 924 vendor.bin onto it. That's 280MHz. 

[Fungus]

The original hacking approach, where the vendor.bin file is replaced and a DHO800 can be turned into a 900 (from a software perspective), has fallen out of fashion somewhat. Several users have observed offset voltages afterwards which could not be removed by auto-calibration, and have hence gone back to the DHO800 configuration.

I don't recall anybody copying the DHO900 .cal files across though. Maybe that would fix it.

Me? I stopped hacking when I measured 200Mhz bandwidth. It seems a sensible limit given the limited sample rate. 280MHz would limit you to one channel if you need to obey Nyquist and I only have the 150MHz probes.

Does anybody have a factory 914? It would be interesting to know the measured bandwidth on that, given that the "70MHz" 804 measures in at over 120MHz.

[ebastler]

Me? I stopped hacking when I measured 200Mhz bandwidth. It seems a sensible limit given the limited sample rate. 280MHz would limit you to one channel if you need to obey Nyquist and I only have the 150MHz probes.

I agree that even more bandwidth is not worth the extra effort and potential side effects. But having the CAN and LIN decoders, which so far are only available in the DHO900 series, might be valuable for some users. Personally I have not come across LIN but would certainly appreciate CAN support.

[Mechatrommer]

The original hacking approach, where the vendor.bin file is replaced and a DHO800 can be turned into a 900 (from a software perspective), has fallen out of fashion somewhat. Several users have observed offset voltages afterwards which could not be removed by auto-calibration, and have hence gone back to the DHO800 configuration.

I don't recall anybody copying the DHO900 .cal files across though. Maybe that would fix it.

Me? I stopped hacking when I measured 200Mhz bandwidth. It seems a sensible limit given the limited sample rate. 280MHz would limit you to one channel if you need to obey Nyquist and I only have the 150MHz probes.

Does anybody have a factory 914? It would be interesting to know the measured bandwidth on that, given that the "70MHz" 804 measures in at over 120MHz.

but you still dont have bode plot feature.. i'm working on AFG module now, there's hope. I now know what ic d and e do and what they are suppose to be... Posibbly LA too later on. while you people figure out how to properly upgrade to dho900.

[Serg65536]

I've developed vendor.bin repack utility. It allows editing of any field of the vendor.bin file. I'm not sure if I should share it here. Not everyone who reads this thread can make and restore backup....

[Serg65536]

The image is from my DHO804 scope. I hoped to fix the offset issue while transitioning to DHO924 model, but had no luck.
It seems like the only way to fix the offset and DC accuracy is to find the difference in calibration algorithm and fix the initial values.
cal_adc.hex is 1.83KB, cal_vertical.hex is 200KB. It's huge files for such a simple task. And the size of 924 firmware cal_vertical file is different.

[Fungus]

I've developed vendor.bin repack utility. It allows editing of any field of the vendor.bin file. I'm not sure if I should share it here. Not everyone who reads this thread can make and restore backup....

I was working on it but I haven't had much time this week and I'm trying to do it in Javascript so it's fiddly.

The idea is to have an HTML file with the keygen in it so nobody has to download GO or ADB (or whatever). Just open the HTML file in a browser, enter your serial number, and press "generate".

The image is from my DHO804 scope. I hoped to fix the offset issue while transitioning to DHO924 model, but had no luck.

Did you try copying all the 924's .cal files onto your DHO800?

I see no reason at all why the hardware would be different. 

[Martin72]

I had played with the SCPI command set earlier, based on the programming guide dho1000/4000(800/900 have the same version 3.0).
https://www.batronix.com/files/Rigol/Oszilloskope/DHO1000/dho10004000_programmingguide_en.pdf
Most of it works, but not the interesting stuff.

:SYSTem:MODules? for example shows 0,0,0,0,0 which makes sense because my 804 do not have any hardware modules like AWG and/or LA.

Also :SYSTem:RAMount? (number of analog channels), but :SYSTem:OPTION:STATus? <type> won´t work, although I have the BW7T10 and RLU "option" installed.
This at least tells me that these options and the possibility to install them do not actually exist.
But I will play with the command again in "test mode" (3x "about"), or generate another bandwidth key greater than 100Mhz and see if it is accepted in this mode.

[Fungus]

I agree that even more bandwidth is not worth the extra effort and potential side effects. But having the CAN and LIN decoders, which so far are only available in the DHO900 series, might be valuable for some users. Personally I have not come across LIN but would certainly appreciate CAN support.

I can switch it to a 924 in two minutes if I ever need that. 

[Serg65536]

Did you try copying all the 924's .cal files onto your DHO800?

I see no reason at all why the hardware would be different. 

I've tried this combinations:
1) 924 vendor.bin on 804 firmware: non correctable DC offset, voltage accuracy is low, fluffy waveform
2) 924 vendor.bin on 804 firmware but with 924 cal files: non correctable DC offset, voltage accuracy is low (1.6%), fluffy waveform
3) 804 vendor.bin but with 924 cal files: no DC offset, voltage accuracy is low (1.6%), waveform is normal (not sure)
4) back to the original unlocked DHO804 vendor.bin and cal files: no DC offset, voltage accuracy is high (0.26%), waveform is normal

BTW, waveform fluffines, probably, would dissapear by itself if I keep the scope with no power for 12H or more.

[zelea2]

I wanted a tool to decode/encode the vendor.bin file in my daily OS which is linux,
so I've written my own tool https://github.com/zelea2/rigol_vendor_bin in C with no dependencies.
I've cross-compiled it for windows too but is is just command line.

I don't have a DHO800 scope yet but I'm ordering one soon   

[iMo]

..BTW, waveform fluffines, probably, would dissapear by itself if I keep the scope with no power for 12H or more.

Sounds strange  .. What would be the mechanism behind?

[Martin72]

I wanted a tool to decode/encode the vendor.bin file in my daily OS which is linux,
so I've written my own tool

Interesting.
I had downloaded the exe file and copied it together with the 924 vendor bin into the same folder.
Then run the exe in the command line and it seems it decodes the bin file.
And how does it work the other way round?

[bulba99]

I wanted a tool to decode/encode the vendor.bin file in my daily OS which is linux,
so I've written my own tool

And how does it work the other way round?

On Windows:

Code: [Select]

rigol_vendor_bin.exe -h
Regards.

[Serg65536]

..BTW, waveform fluffines, probably, would dissapear by itself if I keep the scope with no power for 12H or more.

Sounds strange  .. What would be the mechanism behind?

Some not initialized memory. You should wait for it to discharge, or for the software to init it. I've done this just once, so I'm not sure. And someone also has reported the same behavior here.

[Serg65536]

I don't have a DHO800 scope yet but I'm ordering one soon   

Where did you get the second key, if you don't have the scope to debug?

[zelea2]

Where did you get the second key, if you don't have the scope to debug?

I presume you are talking about the 'Key.data' file'; I've extracted both (including 'vendor.bin') from and SD card image which was published here.
The 'Key.data'  is only needed to generate the unlock option strings and is not tied to the 'vendor.bin'.
What's interesting is that after the XXTEA decryption the Key.data reveals a very long hex string. Only the first 32 characters of that string are used
as the AES256 key (as ASCII characters not as hex data) to encrypt the options.

[bulba99]

Hi zelea2,

thank you for sharing your work. I have a question about the operation of the keygen.
I tested the original vendor bin and the one generated with your tool.
I used kd2.go for testing from the website:
https://gitlab.com/riglol/rigolee/hdo-tools

original vendor.bin :

Code: [Select]

using key [ab12cd34 ab12cd34 ab12cd34 ab12cd34]
raw data:
54 96 A6 A2 CC 00 00 00 04 00 00 00 05 00 00 00 38 00 00 00 74 02 DE 0A 2C 00 00 00 06 00 00 00 31 67 FA 5A AE C8 12 02 15 AA 70 96
0A CA 4E A0 EF 82 04 1B B2 36 40 C3 23 CF 2E EF 3A 03 58 80 76 02 1B CD BF 10 1A 36 45 2C 02 98 04 00 00 00 07 00 00 00 38 00 00 00
2C E5 84 61 2C 00 00 00 0E 00 00 00 80 1D FD C7 EA 3E 89 0F 5F EF BA F5 B0 98 79 86 7C 3A 75 E0 69 2F 6E 1E 89 72 B3 88 4E B0 93 B0
B1 53 F3 31 89 5F 8D 92 7F 5B CF C3 04 00 00 00 09 00 00 00 38 00 00 00 92 C4 92 82 2C 00 00 00 0C 00 00 00 86 33 95 9A BE 57 EE 5D
BA 58 82 86 E4 9E 39 30 67 24 28 3C 4D 04 09 A7 7F E4 AF 3D 93 72 85 8B 96 AC A7 7C 67 C2 1D 45 35 83 0D 64
vendor crc ok a2a69654
id:5 | str:DHO924 | data:[7d ca b7 dd 76 31 c4 3d b0]
id:7 | str:DHO9A252500008 | data:[7b 77 71 3d d a e8]
id:9 | str:0019AFA00004 | data:[96 c9 16 c6 ab 9 56 85]

generated vendor.bin :

Code: [Select]

using key [ab12cd34 ab12cd34 ab12cd34 ab12cd34]
raw data:
3F B9 06 18 CC 00 00 00 04 00 00 00 05 00 00 00 38 00 00 00 A7 A9 56 84 2C 00 00 00 06 00 00 00 D4 95 85 AC 49 94 9F B2 4D 3D B5 EE
E7 08 69 E5 AC 86 9C 8E 84 48 16 BE 76 ED A4 E9 C8 49 34 31 2A AC F9 75 5C 7D B1 D3 BF 28 82 B5 04 00 00 00 07 00 00 00 38 00 00 00
AC 40 49 5F 2C 00 00 00 0E 00 00 00 FA 9F 5B E3 1D F5 82 9B 2D FE 47 EA D0 18 7B 99 A7 21 BA 86 3B 8E F1 A1 A2 93 2F 93 E3 C3 7C EA
2A 96 37 09 1C 45 E3 03 76 4F 02 26 04 00 00 00 09 00 00 00 38 00 00 00 9B 63 F8 40 2C 00 00 00 0C 00 00 00 C1 37 FC B5 5C 98 5E 11
53 75 16 47 6B 13 BD 87 1A 50 45 A3 A4 8D 7E E3 A2 C7 94 68 D7 68 FB B1 11 EF BC DE 3A FE 1A 8F 97 D2 45 29
vendor crc ok 1806b93f
id:5 | str:DHO924 | data:[0 0 0 0 0 0 0 0 0]
id:7 | str:DHO9A252500008 | data:[0 0 0 0 0 0 0]
id:9 | str:0019AFA00004 | data:[0 0 0 0 0 0 0 0]

Is this correct and the differences do not matter?


Regards.

[zelea2]

Is this correct and the differences do not matter?

A string field is 44 bytes long regardless of the actual string length.
I've zeroed the rest of the bytes rather than leaving them random.

[bulba99]

Is this correct and the differences do not matter?

A string field is 44 bytes long regardless of the actual string length.
I've zeroed the rest of the bytes rather than leaving them random.

Thank you for your answer.

[zelea2]

An .imgc  image is a compressed image of the scope filesystem made with the "HDD Raw Copy Tool" which is windows only.
If you want to decompress it in linux you can use the 'unimgc' utility and the destination can be an SD card (root partition) or a local file (of approx 30GB size).

If you want to read/write files from the image (and make offline permanent changes) I've made a quick script which mounts all the scope partitions using the loop devices on linux (offsets and sizes are hardcoded).

[sergk]

If you want to read/write files from the image (and make offline permanent changes) I've made a quick script which mounts all the scope partitions using the loop devices on linux (offsets and sizes are hardcoded).

you can setup loop device on whole image and use kpartx -av on this loop, it'll automatically create all partitions in /dev/mapper without hardcoding (in case something will change in future units).
edit: sorry this won't work with this android sd card image, only standard partition tables