Hacking the Rigol DHO800/900 Scope

[ebastler]

The licensing method being correct has nothing to do with ADB being enabled/disabled.

They are technically separate things, of course, but clearly they both impact "hackability": Having ADB access (or some other access to the file system) was required to perform the license generation, in order to get to the key.data file. And having ADB access has been sufficient to perform some upgrades by swapping or modifying vendor.bin, independent of the license generation scheme used.

So I do see Fungus' point: If Rigol wanted to close the "hack door", they could also have disabled ADB access. Anyway, they took a different approach.

Has anyone tried the vendor.bin swap with the new firmware yet? Rigol didn't put additional checks in place for that, or did they?

[AndyBig]

(Does anybody know where the 'scope's "Internal storage" is mounted in the file system?)

/data/UserData/

Has anyone tried the vendor.bin swap with the new firmware yet? Rigol didn't put additional checks in place for that, or did they?

I just changed from 914 to 924 - everything is ok, the oscilloscope considers itself a DHO924 model with a bandwidth of 250 MHz. Despite the fact that in the original it is DHO814

[Fungus]

The licensing method being correct has nothing to do with ADB being enabled/disabled.

It wasn't clear what you meant by "correcting".

They don't care much about hacking so why would they be working on the encryption math to make sure it was correct?

If they want to prevent hacking then step 1 would be disabling ADB.

So I do see Fungus' point: If Rigol wanted to close the "hack door", they could also have disabled ADB access. Anyway, they took a different approach.

The only reason I can think of is that they decided to start selling upgrades and the math was broken.

Has anyone tried the vendor.bin swap with the new firmware yet? Rigol didn't put additional checks in place for that, or did they?

vendor.bin works perfectly.

How would they check it anyway? They'd have to add some hardware to the PCB to identify the model.

[AndyBig]

It appears that the AES key used to decode the Key.data file has changed. When decoding a file from the previous firmware, a text string similar to the key is obtained that looks like this:
brainpoolP256r1;0405B21204BBA6FF16B9110FD458F4B2EF5A8484B7B46A259BCA90D66BC425BD5E960DFDEB0F6D368EFDB0FB64B43D93FF4FB554D33EB74D0006E5D09A54791EF2

But when decoding a file from the new firmware, we get some nonsense with non-printable characters as in screenshot.


We need to extract a new AES key from the new Sparrow.apk application. I think it is in this application.

[ebastler]

vendor.bin works perfectly.
How would they check it anyway? They'd have to add some hardware to the PCB to identify the model.

Shouldn't be too difficult to check whether that extra memory chip is populated, i.e. whether it's a 900 or 800 series. And maybe there is redundant information in the FRAM (as it is the case for the key.data content) which they are ignoring so far but could check against the vendor.bin?

[Randy222]

The start scripts in /rigol/shell/ are interesting.
Some lines of the shell scripting seem to be extraneous/useless.
But today I did set a screen dim timer so if you walk away for an hour or so the screen will dim to about -95% after the timer, and lowered the overall screen brightness from 255 to 200.
They also set a boot count tracker, does a "+1" to the counter on each boot and set into a property key. I fixed that, changed +1 to a +0
getprop, setprop, settings are all good to know commands.
Not sure why they don't use hwclock and set it to OS date.
Btw, it also starts ftpd, and has sshd running. Do I need ftp? I shut down ftpd. ssh can be handy for not wanting to use adb

Thanks, interesting information.
I also set automatic screen dimming, but through the Android settings. And I use FTP to take screenshots, so I probably won’t disable it
Regarding the download counter - very interesting, is it just for statistics or can it be used somehow? Well, for example, every 100th boot, request an update via OTA, or something similar.
And I found the time zone setting for Asia/Shanghai, I’ll try to replace it with my own zone and see what happens, maybe there will no longer be a need for a separate application to force installation when loading the correct time zone.

Zone setting is in the /rigol/shell/start_rigol_app.sh script, so yep, just change it to your TZ using std TZ setting. I changed mine.
I did not get to the hwclock line yet. Not sure why they call it like they do.
They load things in a time sensitive sequence, I tried reducing the sleep timers and found issues when doing that.

You can grab screen pics direct from web ui.

I was trying to do scpi commands from droid shell, but it's not easy to do, they use an encoding scheme in the web ui page via .js scripts. The actual encoded scpi command gets pushed direct to tcp port 9004 vis basic web socket. If you run the same command in web ui, the actual encoding sent changes. I want the unit to boot up and then go to STOP state with CH1 off.

[AndyBig]

I was trying to do scpi commands from droid shell, but it's not easy to do, they use an encoding scheme in the web ui page via .js scripts. The actual encoded scpi command gets pushed direct to tcp port 9004 vis basic web socket. If you run the same command in web ui, the actual encoding sent changes. I want the unit to boot up and then go to STOP state with CH1 off.

Hmm, it seems that no coding is performed to send the command, the command text is sent as is. Here the answers come in a hex that needs to be converted to UTF8.
But I can’t help here - I’m very unfamiliar with Linux and web programming

[Randy222]

I was trying to do scpi commands from droid shell, but it's not easy to do, they use an encoding scheme in the web ui page via .js scripts. The actual encoded scpi command gets pushed direct to tcp port 9004 vis basic web socket. If you run the same command in web ui, the actual encoding sent changes. I want the unit to boot up and then go to STOP state with CH1 off.

Hmm, it seems that no coding is performed to send the command, the command text is sent as is. Here the answers come in a hex that needs to be converted to UTF8.
But I can’t help here - I’m very unfamiliar with Linux and web programming

I can confirm that the command you type into web gui is not the actual payload sent to tcp port 9004.
There's actually 4 sets of command types, each type will be sent to a different port, 9001 9002 9003 or 9004.

The javascript used on the SCPI page does some form of coding beyond just a UTF8. Using Wireshark I can see the payload each time I send command via web ui, I will send :RUN numerous times and each payload is different, but 10bytes with 1st four the same for the :RUN command

[AndyBig]

The javascript used on the SCPI page does some form of coding beyond just a UTF8. Using Wireshark I can see the payload each time I send command via web ui, I will send :RUN numerous times and each payload is different, but 10bytes with 1st four the same for the :RUN command

Strange, I see on the page sending text directly from the command input field to the websocket: websocket.send(command.value);
No coding is done before this.
I even created a local page for sending SCPI commands and disabled external scripts - and it works I checked it with a Java script trace.

[Fungus]

You can send SCPI commands via  "telnet" (really just a raw IP connection) on port 5555.

[Randy222]

The javascript used on the SCPI page does some form of coding beyond just a UTF8. Using Wireshark I can see the payload each time I send command via web ui, I will send :RUN numerous times and each payload is different, but 10bytes with 1st four the same for the :RUN command

Strange, I see on the page sending text directly from the command input field to the websocket: websocket.send(command.value);
No coding is done before this.
I even created a local page for sending SCPI commands and disabled external scripts - and it works I checked it with a Java script trace.

Just for reference, my 804 came with 00.01.02 FW

open scpi page IP/scpi.html
I use FF, so I do "view source"
There's 2 .js files loaded in.
open each .js, there's an obvious encoding scheme going on, on "input" data, which then comes back as command.value
They appear to encode the data prior to websocket.send()
in config.js you'll see the "function encode(input)" section

The actual web socket construct to tcp 9004 for sending the command is made in the js file, not in any code in scpi.html.

Can you share your html page for sending scpi commands.

[AndyBig]

I just read a little about websockets. Simply sending command texts to port 9004 (websocket) will not work. There you must first initiate the websocket protocol with a special header.

There's 2 .js files loaded in.
open each .js, there's an obvious encoding scheme going on, on "input" data, which then comes back as command.value
They appear to encode the data prior to websocket.send()
in config.js you'll see the "function encode(input)" section

No, command.value is simply the value of the page element with id command.
You can remove links to these two additional scripts from the source text of the page and sending/receiving commands will still work, just the results will not be displayed on the page. You just need to substitute a specific address in the websocket creation function instead of the standardCommandServerUrl variable.
That is, the websocket creation line in the main file should look like this:
const websocket = new WebSocket("ws://192.168.1.171:9004");
(Replace the IP address with the address of your oscilloscope)
That's all. No other scripts, no coding
The encoding function encode(input) located in the config.js file is only called from another function in the same file - getImageData(event). Judging by the content of this function, encoding applies to jpeg images. Perhaps it is encoded into base64 or vice versa from it.

Attached are screenshots of the script trace with sending direct command text to the websocket and receiving a response from the oscilloscope. This is from a local file in which references to external scripts have been removed.

[AndyBig]

So... It seems that the issue of licenses and keys is not dealt with by the application itself, but by one of the binary libraries in it - libscope-auklet.so
Only in this library is the file name RKey.data found, and it also contains a list of all oscilloscope models, and not only the 800/900 series.
And it also contains functions with promising names. Glory to the Rigol programmers who give us binaries with debugging information )
But the disassembler (Ghidra) has been analyzing and parsing this library for about 40 minutes; I have never encountered such a long analysis time.

[Fungus]

So... It seems that the issue of licenses and keys is not dealt with by the application itself, but by one of the binary libraries in it - libscope-auklet.so

Yes, almost all the 'scopes functions are in that file.

When it was announced I thought there would be a lot of Java to hack around and modify but it turns out there isn't. There's a huge .so file with everything except the UI in it.

It should be possible to search the old .so file for the previous AES key then look in the same area of the new .so for the new key.

[sonic]

I guess you could drop in any compiled-for-droid driver source there, to support any wifi adapter you wanted to use.

Really? Is that how it works? The drivers are totally agnostic of any details of the specific SoC the OS is running on?

Must be compiled against android sdk (OS), and the platform architecture.

The kernel then

Code: [Select]

disagrees about version of symbol module_layoutwhen insmodding, so Module.symvers has to be extracted from the kernel partition and used for the build.
I did this and here are the Wifi modules that fall out of an Advantech rk3399 BSP build:

Code: [Select]

8188fu.ko  8189fs.ko  8723bs.ko  8723cs.ko  8822be.ko  mlan.koI don't own any of these models, but if someone does and wants to give it a try:
https://sven.killig.de/android/DHO/system/lib/modules/

[hpmaxim]

well, some sleuthing around, dug up some info.

@hpmaxim, when you plug in that nano wifi into Windows, what RT chipset is identified?

If the v2 with 8188EUS works (8188CU from v1 did not), then I would expect v3 v3.6 v3.8 (v3.x) to also work, they (v2 v3) should all have the RTL8188EUS wifi chipset. I say that because the current downloadable driver package for linux is for RTL8188E.
RT has variants of 8188E (EUS, ETV, etc). Feature diffs, etc. I suspect the drivers provided by TP-link are source code snipped to accomodate 8188EUS.
Side note, the driver package has lines in makefile for compiling against an android sdk, but those lines are commented out.

browse into /system/lib/modules
read the readme.txt file

then
modinfo /system/lib/modules/8188eu.ko

I guess you could drop in any compiled-for-droid driver source there, to support any wifi adapter you wanted to use.

Looks like 8188EU to me.

[sonic]

Can you copy'n'paste the Hardware IDs property on the Details tab?

[Randy222]

SCPI info

1st, the webserver on the 9000 ports is a Java websocket server  "TooTallNate Java-WebSocket"
2nd, the Java app requires "websocket upgrade" when making tcp connection to implement encryption.
Hence why telnet will not work, and explains what I was seeing in Wireshark.
The ws client needs to support the encryption part, otherwise the server side rejects the comms.

[Randy222]

The kernel then

Code: [Select]

disagrees about version of symbol module_layoutwhen insmodding, so Module.symvers has to be extracted from the kernel partition and used for the build.
I did this and here are the Wifi modules that fall out of an Advantech rk3399 BSP build:

Code: [Select]

8188fu.ko  8189fs.ko  8723bs.ko  8723bu.ko  8723cs.ko  8822be.ko  mlan.koI don't own any of these models, but if someone does and wants to give it a try:
https://sven.killig.de/android/DHO/system/lib/modules/

I went to the page you listed, browser gave me the big red DANGER warning and blocked page.
However, I did grab a ko file to see it it insmod's on my 804
Will report back shortly.

[sonic]

I went to the page you listed, browser gave me the big red DANGER warning and blocked page.

Oh my, what did it say? Perhaps a homepage on a server behind DSL is too unusual these days...

[Randy222]

I went to the page you listed, browser gave me the big red DANGER warning and blocked page.

Oh my, what did it say? Perhaps a homepage on a server behind DSL is too unusual these days...

I have a couple of the sec extensions loaded in FF, so one of them ID's the site as being "dangerous". I suspect by fqdn or by the IP from dns.

Anyways, I insmod the 8188fu.ko into the 804, no complaints.
Note: an initial insert (1st time) the device would not attach, a reboot with 8188eu atached and now it fine, I can remove it and re-insert, no issue at all. No green light though, I see the light controls in linux source code, but perhaps the 8188eu.ko on the DHO left that part out, or the x-compile removes that feature.

dmesg shows it as "idProduct 8179"

@hpmaxim - did you do the lsusb / dmesg procedure I listed earlier?

[Randy222]

New update for the RT 8188eu v3.6 nano wifi

From my testing, it appears that when you attempt to insert the nano after the DHO is running, the 8188eu.ko KLM fails to load in.
If you boot with the nano in USB port, the system loads the 8188eu.ko KLM.

I fix this issue by doing an insmod in the "/rigol/shell/start_rigol_app.sh" script
I added the following just after the section (near top) where it loads the Motorcomm ETH KLM

Code: [Select]

insmod /system/lib/modules/8188eu.ko
Now I can insert the nano after boot time and there's no issue of the wifi coming up.

The system should just do a insmod of the ko KLM when it recoginizes that device being inserted into USB port, and then do a rmmod to pull the KLM out when the nano gets pulled from USB port.

That said, most will just leave the wifi nano in the USB port, so it's always there at boot. However, some like me have a USB hub in USB-A port, and the hub has ports that have on/off switches. I don't always have the nano wifi up and running, I turn it on when needed, etc.

Update: another odd thing. You have to insert the nano and manually turn on the wifi slider (android). Leave the slider as is (on position), now the wifi goes on/off in sync with presence of the nano. However, if you manually have the slider to off, the insertion of the nano will not turn on the wifi. That's some odd functionality.

[sonic]

I don't own any of these models

...but I own the Edimax EW-7822ULC, so I built its driver for the USB IDs

Code: [Select]

0b05:184c
0bda:b812
0bda:b82c
13b1:0043
7392:b822
7392:c822
and insmodded
https://sven.killig.de/android/DHO/system/lib/modules/88x2bu.ko
Its LED is blinking, and 5 GHz seems to work:



Build instructions on https://sven.killig.de/android/DHO

[hpmaxim]

New update for the RT 8188eu v3.6 nano wifi

From my testing, it appears that when you attempt to insert the nano after the DHO is running, the 8188eu.ko KLM fails to load in.
If you boot with the nano in USB port, the system loads the 8188eu.ko KLM.

I fix this issue by doing an insmod in the "/rigol/shell/start_rigol_app.sh" script
I added the following just after the section (near top) where it loads the Motorcomm ETH KLM

Code: [Select]

insmod /system/lib/modules.8188eu.ko
Now I can insert the nano after boot time and there's no issue of the wifi coming up.

The system should just do a insmod of the ko KLM when it recoginizes that device being inserted into USB port, and then do a rmmod to pull the KLM out when the nano gets pulled from USB port.

That said, most will just leave the wifi nano in the USB port, so it's always there at boot. However, some like me have a USB hub in USB-A port, and the hub has ports that have on/off switches. I don't always have the nano wifi up and running, I turn it on when needed, etc.

Update: another odd thing. You have to insert the nano and manually turn on the wifi slider (android). Leave the slider as is (on position), now the wifi goes on/off in sync with presence of the nano. However, if you manually have the slider to off, the insertion of the nano will not turn on the wifi. That's some odd functionality.

Sorry for taking so long, here's what I got:

rk3399_rigol:/ # dmesg
rk3399_rigol:/ # lsusb
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
rk3399_rigol:/ # lsusb
Bus 003 Device 002: ID 0bda:8179
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
rk3399_rigol:/ # dmesg
[  271.381320] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[  271.500329] usb 3-1: New USB device found, idVendor=0bda, idProduct=8179
[  271.500409] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  271.500424] usb 3-1: Product: 802.11n NIC
[  271.500437] usb 3-1: Manufacturer: Realtek
[  271.500461] usb 3-1: SerialNumber: 00E04C0001
[  271.753363] SELinux: Unable to set superblock options before the security server is initialized

I then tried your insmod command (although you had a typ-o, should be /system/lib/modules/8188eu.ko), it now seems to be mostly working:

I booted several times in a row.  First two worked great.  Third time it still worked, but seemed a bit slower to start.  I also tried unplugging and plugging it back in and this didn't seem to work.  Fourth time, I plugged in the hub and keyboard along with the WiFi dongle and it didn't seem to work.  Fifth and sixth times I went back to just WiFi, and it worked but was a bit slow to start.  Then I unplugged and plugged back in, and that worked.  Repeated a few times.  All good.  Then tried a 7th time with the hub, and it still worked.

So weird that mine is behaving so differently from other people's...  Should I edit the file /rigol/shell/start_rigol_app.sh and add the insmod command in there?  How do I edit it?  vi?

[Randy222]

Sorry for taking so long, here's what I got:

rk3399_rigol:/ # dmesg
rk3399_rigol:/ # lsusb
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
rk3399_rigol:/ # lsusb
Bus 003 Device 002: ID 0bda:8179
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
rk3399_rigol:/ # dmesg
[  271.381320] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[  271.500329] usb 3-1: New USB device found, idVendor=0bda, idProduct=8179
[  271.500409] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  271.500424] usb 3-1: Product: 802.11n NIC
[  271.500437] usb 3-1: Manufacturer: Realtek
[  271.500461] usb 3-1: SerialNumber: 00E04C0001
[  271.753363] SELinux: Unable to set superblock options before the security server is initialized

I then tried your insmod command (although you had a typ-o, should be /system/lib/modules/8188eu.ko), it now seems to be mostly working:

I booted several times in a row.  First two worked great.  Third time it still worked, but seemed a bit slower to start.  I also tried unplugging and plugging it back in and this didn't seem to work.  Fourth time, I plugged in the hub and keyboard along with the WiFi dongle and it didn't seem to work.  Fifth and sixth times I went back to just WiFi, and it worked but was a bit slow to start.  Then I unplugged and plugged back in, and that worked.  Repeated a few times.  All good.  Then tried a 7th time with the hub, and it still worked.

So weird that mine is behaving so differently from other people's...  Should I edit the file /rigol/shell/start_rigol_app.sh and add the insmod command in there?  How do I edit it?  vi?

That dmesg shows fail to load driver. When the driver load ok you'll see many lines of "RTW", then you should see the rockchip binding MAC address, etc etc.



I fixed my edit goof
After editing start sh file, reboot with the nano in USB
Then using keyboad go into the Android settings --> WiFi  , and slide the wifi on/off slider to on. If it won't slide on then the nano driver did not load for some reason.
Configure your wifi settings. No need for this step if just testing that the 8188eu.ko driver loads, but you'll need to add wifi settings at some point to get on a wifi network.
Leave it there.

Power off the scope
Remove the nano
Power up
Go back to Android wifi settings with keyboard (it should show wifi slider as off)
Insert nano, Wifi slider should auto-on itself
Remove nano, Wifi slider should auto-off itself

That is the consistent functionality I get.