Hacking the Rigol DHO800/900 Scope

[hpmaxim]

Sorry, haven't had an opportunity to try the suggestions yet.  To clear things up, yes, I watched the Doom video.  Yes, I used a USB 4 port hub, with a USB keyboard and the TP Link Dongle.

I want to be clear that I have never seen a version number listed on any of the listings.  So, in order to "be safe", I ordered off the Amazon listing pointed to by the video that was identified as version 3.0.  If Amazon is shiping V3.6 (and it appears they are), and version 3.6 is incompatible for whatever reason, someone really should I identify a seller who will reliably sell you V3, and remove the Amazon link from the video and/or elsewhere.  I think it's also reasonable to assume that if TPLink is now producing V3.6, that they will cease to produce V3, and that V2 and V3 will become increasingly difficult to get, and it may be a good idea to start hunting for other compatible devices.

[ebastler]

I had a look at the TP-Link website, and there is no mention of a version 3.6, neither on the product nor support part of the site, and whether I select Germany or US as the country. (But here is no mention of other "decimal point" sub-versions either, they just talk about V1, V2 and V3.)

Hence I guess a comparison of dmesg outputs, or outputs from whatever other tools might give detailed information under whichever OS, is our best bet to try and understand potential differences between versions 3.0 and 3.6. I no longer have my DHO1074, but still have a v3.0 TP-Link dongle which I could ask Windows or Linux about. But diagnostic outputs directly from a DHO's Android environment might be more useful?

[Randy222]

I had a look at the TP-Link website, and there is no mention of a version 3.6, neither on the product nor support part of the site, and whether I select Germany or US as the country. (But here is no mention of other "decimal point" sub-versions either, they just talk about V1, V2 and V3.)

Hence I guess a comparison of dmesg outputs, or outputs from whatever other tools might give detailed information under whichever OS, is our best bet to try and understand potential differences between versions 3.0 and 3.6. I no longer have my DHO1074, but still have a v3.0 TP-Link dongle which I could ask Windows or Linux about. But diagnostic outputs directly from a DHO's Android environment might be more useful?

I have observed the same on TP site.
I did some searching around and apparently some box stickers now say "v3.8".

You can use my procedure in reply #845 (a page back) on any basic linux install. Droid will just have limited switches to use with dmesg and lsusb, so that's what I put in #845.
Try it with your v3.0 on linux, post what you get.

The next step is to just dig out the driver the dho has for a usb wifi device.

[AndyBig]

Here is the result of dmesg from my scope with a normally working adapter TL-WN725N(EU) according to Randy222's instructions, just for comparison:

rk3399_rigol:/ # lsusb
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
rk3399_rigol:/ # lsusb
Bus 003 Device 006: ID 0bda:8179
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0003
rk3399_rigol:/ # dmesg
[17956.250192] usb 3-1: new high-speed USB device number 6 using xhci-hcd
[17956.370762] usb 3-1: New USB device found, idVendor=0bda, idProduct=8179
[17956.370849] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[17956.370865] usb 3-1: Product: 802.11n NIC
[17956.370878] usb 3-1: Manufacturer: Realtek
[17956.370889] usb 3-1: SerialNumber: 00E04C0001
[17956.378239] bFWReady == _FALSE call reset 8051...
[17956.405746] RTW: 0x000: 29 81 00 6C 0B 00 00 00    00 0C 00 00 00 00 00 00
[17956.405944] RTW: 0x010: 25 24 24 25 25 25 29 29    29 28 28 F1 FF FF FF FF
[17956.406046] RTW: 0x020: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.406126] RTW: 0x030: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.408038] RTW: 0x040: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.408150] RTW: 0x050: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.408240] RTW: 0x060: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.408323] RTW: 0x070: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.408423] RTW: 0x080: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.408508] RTW: 0x090: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.408599] RTW: 0x0a0: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.408680] RTW: 0x0b0: FF FF FF FF FF FF FF FF    A1 3F 17 00 00 00 00 00
[17956.408769] RTW: 0x0c0: 00 01 00 10 00 00 00 00    00 03 FF FF FF FF FF FF
[17956.408854] RTW: 0x0d0: DA 0B 79 81 43 66 00 78    8C B5 B8 A3 8C 09 03 52
[17956.408937] RTW: 0x0e0: 65 61 6C 74 65 6B 0D 03    38 30 32 2E 31 31 6E 20
[17956.409044] RTW: 0x0f0: 4E 49 43 0C 03 30 30 45    30 34 43 30 30 30 31 00
[17956.409135] RTW: 0x100: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.409224] RTW: 0x110: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.409317] RTW: 0x120: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.409438] RTW: 0x130: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.409534] RTW: 0x140: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.409634] RTW: 0x150: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.409717] RTW: 0x160: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.409810] RTW: 0x170: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.409892] RTW: 0x180: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.410081] RTW: 0x190: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.410219] RTW: 0x1a0: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.410321] RTW: 0x1b0: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.410437] RTW: 0x1c0: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.410535] RTW: 0x1d0: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.410645] RTW: 0x1e0: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.410738] RTW: 0x1f0: FF FF FF FF FF FF FF FF    FF FF FF FF FF FF FF FF
[17956.410841]
[17956.410910] RTW: hal_com_config_channel_plan chplan:0x21
[17956.413652] RTW: rtw_regsty_chk_target_tx_power_valid return _FALSE for band:0, path:0, rs:0, t:-1
[17956.413818] [WLAN_RFKILL]: rockchip_wifi_mac_addr: enter.
[17956.413835] [WLAN_RFKILL]: get_wifi_addr_vendor: rk_vendor_read wifi mac address failed (-1)
[17956.418688] RTW: rtw_ndev_init(wlan0) if1 mac_addr=78:8c:b5:b8:a3:8c
[17956.421098] RTW: rtw_ndev_init(p2p0) if2 mac_addr=7a:8c:b5:b8:a3:8c
rk3399_rigol:/ #

[ebastler]

You can use my procedure in reply #845 (a page back) on any basic linux install. Droid will just have limited switches to use with dmesg and lsusb, so that's what I put in #845.
Try it with your v3.0 on linux, post what you get.

Sorry -- I forgot that my Linux notebook is on loan to a friend at the moment. My Raspberry-based mini-MAME cabinet refuses to even boot with the TP-Link adapter installed, so I'm out of suitable test devices unfortunately.

[Randy222]

@hpmaxim,

If you insert a usb mem stick (FAT), does the DHO (droid) attach it?
If so then you know the USB-A port is not faulty.

Which version of DHO firmware do you have?

[Randy222]

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.

[ebastler]

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?

[Randy222]

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 RTL8188 linux driver package has in it ability to compile for arm android.

Code: [Select]

ARCH := arm
#Android-JB42
#CROSS_COMPILE := /home/android_sdk/Allwinner/a31/android-jb42/lichee/buildroot/output/external-toolchain/bin/arm-linux-gnueabi-
#KSRC :=/home/android_sdk/Allwinner/a31/android-jb42/lichee/linux-3.3
#ifeq ($(CONFIG_USB_HCI), y)
#MODULE_NAME := 8188eu_sw
#endif
# ==== Cross compile setting for kitkat-a3x_v4.5 =====
CROSS_COMPILE := /home/android_sdk/Allwinner/a31/kitkat-a3x_v4.5/lichee/buildroot/output/external-toolchain/bin/arm-linux-gnueabi-
KSRC :=/home/android_sdk/Allwinner/a31/kitkat-a3x_v4.5/lichee/linux-3.3

Code: [Select]

ARCH := arm
# ===Cross compile setting for Android 4.2 SDK ===
#CROSS_COMPILE := /home/android_sdk/Allwinner/a20_evb/lichee/out/android/common/buildroot/external-toolchain/bin/arm-linux-gnueabi-
#KSRC := /home/android_sdk/Allwinner/a20_evb/lichee/linux-3.3
# ==== Cross compile setting for Android 4.3 SDK =====
#CROSS_COMPILE := /home/android_sdk/Allwinner/a20/android-jb43/lichee/out/android/common/buildroot/external-toolchain/bin/arm-linux-gnueabi-
#KSRC := /home/android_sdk/Allwinner/a20/android-jb43/lichee/linux-3.4
# ==== Cross compile setting for kitkat-a20_v4.4 =====
CROSS_COMPILE := /home/android_sdk/Allwinner/a20/kitkat-a20_v4.4/lichee/out/android/common/buildroot/external-toolchain/bin/arm-linux-gnueabi-
KSRC := /home/android_sdk/Allwinner/a20/kitkat-a20_v4.4/lichee/linux-3.4

[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

[AndyBig]

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.

[Fungus]

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

I use FTP to get screenshots and .csv files out of it.

It's much easier/faster than messing around with USB sticks.

[AndyBig]

The new firmware version has arrived - https://www.eevblog.com/forum/testgear/rigols-new-dho800-oscilloscope-unbox-teardown/msg5272446/#msg5272446
It's funny, but after the update the maximum bandwidth dropped to 125 MHz. It appears that the update has removed the band extension option. And there may be other options. Although the .LIC files are all still there.

[Fungus]

It's funny, but after the update the maximum bandwidth dropped to 125 MHz. It appears that the update has removed the band extension option. And there may be other options. Although the .LIC files are all still there.

I just installed it and did some quick tests and my license keys seem to have stopped working.

[AndyBig]

I just installed it and did some quick tests and my license keys seem to have stopped working.

Yeah. We can try to generate and activate the options again.
But what’s nice is that on the new firmware it was calibrated noticeably better than on the previous one 00.01.02.00.00, the vertical displacement is much smaller at all limits. But there was also a joke (although maybe it was there before, I just didn’t notice it): at some limits, turning on/off the 20 MHz band limit leads to a vertical shift. Moreover, if you switch the vertical scale one step up or down, and then go back, the shift disappears. This is especially noticeable on channel 4 of my oscilloscope at scales of 10, 20 and 50 mV (with a 1x probe divider installed). Here the vertical displacement jumps by as much as one and a half small divisions (a little more than a quarter of the major division).

[AndyBig]

All in all...
Now, instead of the file /Rigol/Data/Key.data, this directory contains the file /Rigol/Data/RKey.data, the contents of which are different from the old one.
The rigol_vendor_bin.exe utility generates options (if you rename RKey.data to Key.data), but the oscilloscope does not accept the generated options, it writes “License invalid. Remaining attempts: X”, where X starts with 9 and decreases with each attempt. I tried changing the key file by renaming Key.data to RKey.data and loading it into the oscilloscope. But even in this case, the oscilloscope does not accept the options, it writes “Invalid key”. Something has changed in the algorithm for generating and checking options.

[Fungus]

Oh, yeah! "Key.data" has vanished and there's a new file "RKey.data"

Maybe we can make new licenses using that...


Update: Nope, not with the existing key generator.

[tv84]

Something has changed in the algorithm for generating and checking options.

Finally!! I haven't done an analysis but I can only expect the programmers to have studied a little more about how to correctly implement ECC cryptography in a Rigol droid machine...

That clearly shows Rigol isn't happy with the DHO license mess and will be making life a little harder for people intending to license "upgrade" their machines.

However, what user @DrMefistO released yesterday in the MSO5000 hack thread should be the way to go (if all is according to plan) for this new DHO reality.

[Fungus]

That clearly shows Rigol isn't happy with the DHO license mess and will be making life a little harder for people intending to license "upgrade" their machines.

Changing vendor.bin is easier than generating license keys.

(unless somebody figured out how to do serial number->license while I wasn't paying attention)

[PELL]

Rigol release a new firmware 1.02.02 on their Chinese website, and looks like they change the "Key" file to "RKey", and all my hack was gone.

I tried to re-hack it but fail, so this looks like a completely different key file.

Thankfully I have a full disk image backup so I can recover it easily, But If you don't, DO NOT UPDATE TO THE LATEST FIRMWARE at least before people find a new way to hackin

Edit: oops looks like I am a bit late

[Fungus]

Firmware downgrade is easy.

You DID make a copy of your Key.data, right? 

[tv84]

That clearly shows Rigol isn't happy with the DHO license mess and will be making life a little harder for people intending to license "upgrade" their machines.

Changing vendor.bin is easier than generating license keys.

(unless somebody figured out how to do serial number->license while I wasn't paying attention)

If they corrected everything then even "changing vendor.bin" should become "harder".

Nonetheless, just changing vendor.bin doesn't solve all the option upgrade possibilities. At least, future ones.

[Fungus]

To upgrade/downgrade firmware I just copy DHO800_DHO900_Update.GEL onto the internal disk with FTP and use the "upgrade" menu. No need to mess around with USB sticks.

I just went back to firmware 1.01, no problem.

With firmware 1.02 I can still use a DHO914 vendor.bin for bandwidth/memory upgrade (I was on DHO804 with licenses before).

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

[Fungus]

If they corrected everything then even "changing vendor.bin" should become "harder".

I doubt they're "correcting" the protection. If they wanted that they could just disable ADB.

[tv84]

If they corrected everything then even "changing vendor.bin" should become "harder".

I doubt they're "correcting" the protection. If they wanted that they could just disable ADB.

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