Hacking the Rigol DHO800/900 Scope

[AndyBig]

I think I figured out my problem. True, at the same time I killed the system boot a couple of times
For some reason, apktool was disassembling services.jar with the “do not compress dex” parameter set. After I removed this parameter from apktool.yml everything worked.

An interesting thing is that control.html accepts query parameters "size" and "rate", which can take the values of "1080p" or "720p", and "Extra", "High", or "Low", respectively, and they do get passed to the respective websocket server that does the actual streaming when the websocket session starts, and there is some logic in the server code to switch size and bit rate accordingly (below the lines where the default size constants are set), but for some reason it does not work at all -- it always sets the values to default. Maybe I will try to untangle the spaghetti of conditions and gotos in the smali code to see why, but before that I'll try to change the default bitrate to different values to see if that works at all.

If you look in debug, you can see that the "size" and "rate" parameters are passed with the value null , so the server code sets these values by default.
I also thought about this point: with changes in services.jar described in the link, it turns out that checking application privileges is completely disabled. That is, any application can receive any permission. This may not be very good, I think. We need to think about how to make sure that permissions are granted only to our modified applications. You can try making a condition based on the application class name, for example. If this is com.rigol.scope or com.rigol.webcontrol, then the signature verification returns an unconditional positive result, otherwise let the standard verification be carried out.

As far as the screen recording goes, I think we already have the highest bitrate it can do. The encoder itself supports bitrate values up to 40000000 (10000000 was another value that I saw somewhere), but if I change the default value of 6000000 to a higher one, it doesn't result in the increase of the output file size or the video quality. If I make it lower, however (say 500000), then yes the quality drops, so we know that this parameter isn't ignored.

This is the maximum bitrate. Probably, during the compression process, the bitrate simply does not reach maximum values above 6,000,000. In general, the codec settings should have other parameters that are responsible for the quality of the compressed video stream, most likely because of them the bitrate does not rise high.

[souldevelop]

Hello guys!
 I haven't been online for a long time, I want to know the latest DH800 900 firmware v00.01.02.00.02 , is there any other way besides using the modifying apk vendor.bin?

glad to hear from you in PM and here... currently we are using rigol_vendor_bin from zelea2 to edit vendor.bin. with vendor.bin edited, other features such as 250MHz BW and 50Mpts memory, AFG and LA features automatically activated, no need extra *.lic anymore. although yours RigolTool can also still be applicable for the job, but its auto destruct now when we run it. its still very usefull for me as file explorer of DHO800, last time i pulled many file system using it.

and other update we were talking about your post is changing HW number read by hdcode_gpio.ko...
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5382392/#msg5382392

we managed to find where the config resistors are..
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5388278/#msg5388278
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389301/#msg5389301
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5389916/#msg5389916

but other guys (norbert.kiszka and Randy222 iirc) tried to do it in SW/FW by spoofing start_rigol_app.sh by disabling hdcode_gpio.ko and writing a number into its output file, but we dont find the method stable, i tried and caused the dso to hanged and reboot indefinetely.. so i'll stick with HW modification. since HW12 with hacked dho800 to 900 still not work correctly on LA channel trigger with latest FW 1.2.2 i suspect the FW will check for HW number before activating or not activating LA trigger. ymmv.

Thank you for your concluding answers, and I'm glad you can continue the discussion. In the new firmware, Key.data has been renamed RKey.data, so I don't know if the encryption method of vendor.bin files has also changed, I took a rough look at the lib library algorithm in the apk a few days ago and changed a lot. As for the hdcode_gpio.ko method, I don't recommend using the method of disabling the driver and then spoofing it through other programs, I prefer to refactor hdcode_gpio.ko, this file implementation is very simple, the standard RK3399 driver is written, if anyone has the time and energy can try.

[souldevelop]

Hello guys!
 I haven't been online for a long time, I want to know the latest DH800 900 firmware v00.01.02.00.02 , is there any other way besides using the modifying apk vendor.bin?

Hey there.  Looks like your Q was answered... I just wanted to thank you for your early work here in the forums, and welcome you back.  Cheers!

Thank you for your concern, recently the time is more tight, so there is very little online time, I started to try to rebuild the new hdcode.ko kernel driver very early, but found that it is not so easy, the main thing is to restore RIGOL's RK3399 development environment, especially the kernel version must be consistent with the goal, otherwise even if you compile it, there will be errors. I'll take the time to try again, cheers friends!

[AndyBig]

Yes, after changing the resolution of the recorded video screen and increasing the bitrate, the video quality has seriously increased.
For comparison, here are screenshots from a video recorded in the original web control and in the modified one. I also attached a screenshot with information about the videos. After the modification, the bitrate almost doubled, despite the fact that the number of pixels in the image decreased by almost four times. And the frame rate also increased.
In the video from the original webcontrol, compression artifacts are very noticeable, the picture is unclear. In the video from the modified web control, the compression is almost imperceptible, the picture is very clear.

P.S. Links to the videos themselves:
original - https://drive.google.com/file/d/12yizmAu-FhmWpCYIUk34HciwkJnIht-e/view?usp=sharing
modified - https://drive.google.com/file/d/1e6QkCdBJsKthzY1yc9gNk0e04Attq5by/view?usp=sharing

[shapirus]

Did you only change the 1920 and 1080 constants or something else too?

[AndyBig]

Did you only change the 1920 and 1080 constants or something else too?

Changed these constants and bitrate from 6000000 to 10000000 in the file smali\com\rigol\webcontrol\server\PrintWSS.smali (lines 697-701).

[shapirus]

That's what I did, too. Strangely enough, it did not change the bitrate for me -- however, I don't exactly remember what it was at 1920x1080 (only remember it was roughly ~7MB for a 20-sec recording). I changed the size first, and then I tried different bitrates at 1024x600: there was no difference in the resulting file's bitrate with the constant set to anywhere from 3000000 to 10000000.

[AndyBig]

That's what I did, too. Strangely enough, it did not change the bitrate for me -- however, I don't exactly remember what it was at 1920x1080 (only remember it was roughly ~7MB for a 20-sec recording). I changed the size first, and then I tried different bitrates at 1024x600: there was no difference in the resulting file's bitrate with the constant set to anywhere from 3000000 to 10000000.

Initially it was 6,000,000. Which picture did you try it on? It’s just that in the absence of noise, when the channel trace is a straight line with little noise, there won’t be a high bitrate when encoding video, because the picture is almost static. To achieve the maximum bitrate, you need to change as much of the screen area as possible in each frame; this is why I brought out the noise on such a scale.

[AndyBig]

By the way, in remote screen control, an increase in bitrate has a very noticeable effect on video quality. The screenshots show the quality of the picture in its original form (average bitrate over the network - 9 Mbps) and after increasing the bitrate (average bitrate over the network - 19 Mbps).
But only when connected to cable Ethernet. Through Wi-Fi, my network flow is limited to 4.3 Mbps, it seems that this is the limit of the Wi-Fi connection itself.

[AceyTech]

By the way, in remote screen control, an increase in bitrate has a very noticeable effect on video quality. The screenshots show the quality of the picture in its original form (average bitrate over the network - 9 Mbps) and after increasing the bitrate (average bitrate over the network - 19 Mbps).
But only when connected to cable Ethernet. Through Wi-Fi, my network flow is limited to 4.3 Mbps, it seems that this is the limit of the Wi-Fi connection itself.

Or, the limitation may be imposed by Rigol devs enabling more data over physical ETH.??  I posted a question suggesting this when @shapirus brought it up a couple nights ago, but deleted it after a short while, in favor of not interrupting you and shapirus' "flow".

p.s., Wow, those artifacts are definitely a reason to increase the quality output. eww.

Exciting stuff guys!  Nice bit of progress..

[AndyBig]

By the way, in remote screen control, an increase in bitrate has a very noticeable effect on video quality. The screenshots show the quality of the picture in its original form (average bitrate over the network - 9 Mbps) and after increasing the bitrate (average bitrate over the network - 19 Mbps).
But only when connected to cable Ethernet. Through Wi-Fi, my network flow is limited to 4.3 Mbps, it seems that this is the limit of the Wi-Fi connection itself.

Or, the limitation may be imposed by Rigol devs enabling more data over physical ETH.??  I posted a question suggesting this when @shapirus brought it up a couple nights ago, but deleted it after a short while, in favor of not interrupting you and shapirus' "flow".

p.s., Wow, those artifacts are definitely a reason to increase the quality output. eww.

Exciting stuff guys!  Nice bit of progress..

I don't know why the developers did this. The bitrate is calculated as width*height*K. The K coefficient depends on the specified quality and can be from 1.5 to 5. Thus, for a 1024x600 screen, the maximum bitrate is 1024*600*5=3072000, which is obviously very small. I set the bitrate to a constant 10000000 and this significantly improved the video quality in remote control.

[AceyTech]

By the way, in remote screen control, an increase in bitrate has a very noticeable effect on video quality. The screenshots show the quality of the picture in its original form (average bitrate over the network - 9 Mbps) and after increasing the bitrate (average bitrate over the network - 19 Mbps).
But only when connected to cable Ethernet. Through Wi-Fi, my network flow is limited to 4.3 Mbps, it seems that this is the limit of the Wi-Fi connection itself.

Or, the limitation may be imposed by Rigol devs enabling more data over physical ETH.??  I posted a question suggesting this when @shapirus brought it up a couple nights ago, but deleted it after a short while, in favor of not interrupting you and shapirus' "flow".

p.s., Wow, those artifacts are definitely a reason to increase the quality output. eww.

Exciting stuff guys!  Nice bit of progress..

I don't know why the developers did this. The bitrate is calculated as width*height*K. The K coefficient depends on the specified quality and can be from 1.5 to 5. Thus, for a 1024x600 screen, the maximum bitrate is 1024*600*5=3072000, which is obviously very small. I set the bitrate to a constant 10000000 and this significantly improved the video quality in remote control.

Interesting.  I'm familiar with bpp in the formula for video encoding/streaming etc., but the K is new to me.  Is the color depth part of the K coefficient, specified elsewhere, or is it not needed in this context?

Sorry, just a curious musing.  Don't let me distract if you have other stuff to do.

[AndyBig]

Interesting.  I'm familiar with bpp in the formula for video encoding/streaming etc., but the K is new to me.  Is the color depth part of the K coefficient, specified elsewhere, or is it not needed in this context?

Sorry, just a curious musing.  Don't let me distract if you have other stuff to do.

No, this is just a certain coefficient, a multiplier for calculating the bitrate. It is not related to anything technical. It’s just that Rigol’s engineers decided that to calculate the bitrate in low quality they would multiply the number of pixels by 1.5, in high quality by 4, and in extra quality by 5. I called this number - 1.5, 4 or 5 - coefficient K

[LektroiD]

Hi, I wonder if anyone can help me out, when I run "run_DHO_Tools", I get an error "adb: error: remote object '/rigol/data/Key.data' does not exist". I'm connected to the scope remotely using a wifi dongle. Anyone else had this issue, or know how to cure it?

Code: [Select]

adb: error: remote object '/rigol/data/Key.data' does not exist

go run rgtoolMod.go
keyFile: Key.data
deviceId: DHO8
SCPI format: ':SYSTem:OPTion:INSTall'
options: [RLU BW7T10]
error open Key.data: The system cannot find the file specified.
exit status 10

[souldevelop]

Hi, I wonder if anyone can help me out, when I run "run_DHO_Tools", I get an error "adb: error: remote object '/rigol/data/Key.data' does not exist". I'm connected to the scope remotely using a wifi dongle. Anyone else had this issue, or know how to cure it?

Code: [Select]

adb: error: remote object '/rigol/data/Key.data' does not exist

go run rgtoolMod.go
keyFile: Key.data
deviceId: DHO8
SCPI format: ':SYSTem:OPTion:INSTall'
options: [RLU BW7T10]
error open Key.data: The system cannot find the file specified.
exit status 10

You can try RKey.data.

[AndyBig]

Hi, I wonder if anyone can help me out, when I run "run_DHO_Tools", I get an error "adb: error: remote object '/rigol/data/Key.data' does not exist". I'm connected to the scope remotely using a wifi dongle. Anyone else had this issue, or know how to cure it?

Code: [Select]

adb: error: remote object '/rigol/data/Key.data' does not exist

go run rgtoolMod.go
keyFile: Key.data
deviceId: DHO8
SCPI format: ':SYSTem:OPTion:INSTall'
options: [RLU BW7T10]
error open Key.data: The system cannot find the file specified.
exit status 10

In the firmware, starting with version 00.01.02.00.00 (or 00.01.02.00.02, I don’t remember exactly), Rigol changed the coding of options. Now instead of the Key.data file there is an RKey.data file and other keys, so the old key generation tools do not work. Use this tool - https://github.com/zelea2/rigol_vendor_bin from Zelea, it is adapted for new firmware.

[LektroiD]

Hi, I wonder if anyone can help me out, when I run "run_DHO_Tools", I get an error "adb: error: remote object '/rigol/data/Key.data' does not exist". I'm connected to the scope remotely using a wifi dongle. Anyone else had this issue, or know how to cure it?

Code: [Select]

adb: error: remote object '/rigol/data/Key.data' does not exist

go run rgtoolMod.go
keyFile: Key.data
deviceId: DHO8
SCPI format: ':SYSTem:OPTion:INSTall'
options: [RLU BW7T10]
error open Key.data: The system cannot find the file specified.
exit status 10

In the firmware, starting with version 00.01.02.00.00 (or 00.01.02.00.02, I don’t remember exactly), Rigol changed the coding of options. Now instead of the Key.data file there is an RKey.data file and other keys, so the old key generation tools do not work. Use this tool - https://github.com/zelea2/rigol_vendor_bin from Zelea, it is adapted for new firmware.

Hi, thanks for the info, on the page it says "Precompiled Linux, Windows and Android ARM64 binaries are available from 'Releases' section", but there doesn't appear to be a "releases" section on his page.

Is it possible to roll back to 1.01? I don't remember hacking being this difficult on the 1054z.

Rather annoying, I followed the Retro Channel's video carefully, which suggested to update to any version beyond 1.00, I was on 1.01 already, if I'd ignored that section it would have made my life so much easier. That guy needs to add a card to that video saying not to go beyond 1.01, it'll totally snooker you otherwise lol

Double annoying is that I was all set to buy a 924, but someone pointed out that I could simply get an 804, hack it up to the 924 and save a chunk of money, like it was an easy thing to hack. I could have afforded the 924, but can't afford to get the 924 after already spending out on the 804 which would then sit redundant. Frustrating! lol

[ebourg]

Hi, thanks for the info, on the page it says "Precompiled Linux, Windows and Android ARM64 binaries are available from 'Releases' section", but there doesn't appear to be a "releases" section on his page.

There: https://github.com/zelea2/rigol_vendor_bin/releases/tag/Rigol

[AceyTech]

Hi, thanks for the info, on the page it says "Precompiled Linux, Windows and Android ARM64 binaries are available from 'Releases' section", but there doesn't appear to be a "releases" section on his page.

Rather annoying, I followed the Retro Channel's video carefully, which suggested to update to any version beyond 1.00, I was on 1.01 already, if I'd ignored that section it would have made my life so much easier. That guy needs to add a card to that video saying not to go beyond 1.01, it'll totally snooker you otherwise lol

Double annoying is that I was all set to buy a 924, but someone pointed out that I could simply get an 804, hack it up to the 924 and save a chunk of money, like it was an easy thing to hack. I could have afforded the 924, but can't afford to get the 924 after already spending out on the 804 which would then sit redundant. Frustrating! lol

TBH, It's not super clear where the "download" link is on the GitHub page..  It's on the right side.


Your best chance of success is to follow the detailed step-by-step guide in @AndyBig's signature ^^ above your post.

[Mechatrommer]

Frustrating! lol

first thing you should do.... backup your original sd card that came from factory. this is most critical step if you want anything to be reversible... but behold... you still can copy the hubertyoung's 924Ss FW from first page and get a 924s scope, with later steps to do hardware modification scattered in this thread. but keep your original sd card even if already upgraded to 1.01 or later somewhere else safe. like mine, i put it here (see attached) along with various images of original and upgraded path branch saved in my PC, ymmv.

[LektroiD]

Your best chance of success is to follow the detailed step-by-step guide in @AndyBig's signature ^^ above your post.

I followed the instructions by AndyBig carefully, but a couple of things didn't go quite the same; there was no data folder added, instead it added a bunch of files directly inside the "platform-tools" directory where adb was launched from. so I copied the two files to the "rigol_vendor_bin" directory and and wrote the command: rigol_vendor_bin.exe -M DHO924S in that folder as instructed, but now have this error:

[Veteran68]

I followed the instructions by AndyBig carefully, but a couple of things didn't go quite the same; there was no data folder added, instead it added a bunch of files directly inside the "platform-tools" directory where adb was launched from. so I copied the two files to the "rigol_vendor_bin" directory and and wrote the command: rigol_vendor_bin.exe -M DHO924 in that folder as instructed, but now have this error:

The solution is right there in the error message and subsequent suggestion. The Powershell shell does not search the current directory for an EXE specified on the command line, same as a bash shell. You have to specify the current direction with .\<exe name>.

[Mechatrommer]

i think this is where knowledge on "Command Prompt" run as admin... or batch file (*.bat) is valuable... ymmv.

[LektroiD]

I must be blind. All working now, just running a calibration, but seems I now have a DHO924S masquerading as a 804.

Thank you, and a huge thanks to everyone who helped me to get this working

***** ADDENDUM *****

Something interesting just happened. Adding the 924'S' version showed the function generator up, but when I went into it, there menu was there, but no waveform, so I'm going to assume the function generator is hardware based. To cut a long story short, it (temporarily) bricked my scope (no waveform, menu in the bottom left was not responding, etc.). I double pressed the default button on the front of the scope and it came back to life, but my 804, that was transformed to a 924S was now masquerading as a 814. So it seems that hitting the Default button twice reverts the scope to an 814. So basically the hack is not permanent. Anyone else found this?

[Randy222]

Oh, fellow failure ) I also killed the loading of the oscilloscope by trying to make the application system using the modperms.sh script from Randy222 )
Then I connected to the hardware UART and through it in the console I restored the original file /system/etc/permissions/platform.xml

Which permission(s) did you add to the Template?