Hacking the Rigol DHO800/900 Scope

[zelea2]

Unfortunately, the options created by the new version do not work The oscilloscope writes “License is invalid.”.
Although the key decoded from RKey.dat is similar to the real one (in the Key.dec file with the -d option):

At least I've solved the RKey.data problem. They must have changed something in the option gen also.
One thing that comes to mind is that previously they were using the ASCII of the hex key as key, maybe now they read it properly as hex not as string.

[ebastler]

[...] issue that would arise from end-users who bought upgrade options and installed the lic to activate an option, unless the new Rkey.data process can still properly deciper old option lics?

Then some new updated FW comes along with a new key, which would then cause issue for the older lics based on older key data? Then end-user would need to have Rigol re-gen new option lics?

Do we have evidence that any upgrade options have successfully been sold under the old scheme? When I got my DHO1074 with a "bundled" memory upgrade,

• Rigol struggled mightily to send the upgrade info at all -- took a few weeks and three reminders;
• The sheet they eventually sent, as well as the website to generate the unlock code, did not make any reference to the way the unlock info needs to be entered in the DHO series scopes;
• When I had figured that out -- using info from the hacking thread here, since full information on the SCPI parameters was just not available from the Rigol documentation -- the code did not work.

So maybe the original key.data scheme is flawed, and that was the reason to switch to a new one?

[AndyBig]

This part though I still question. New key?
That does not make much sense given the issue that would arise from end-users who bought upgrade options and installed the lic to activate an option, unless the new Rkey.data process can still properly deciper old option lics?
Then some new updated FW comes along with a new key, which would then cause issue for the older lics based on older key data? Then end-user would need to have Rigol re-gen new option lics?
I don't see anywhere where Rigol mentions this might be an issue. This suggests to me perhaps the old option lics still work, but installing a new option lic is a different process, not necesarily with "new" key?

But it is true - the options that were active in version 00.01.02.00 were canceled when updating to version 00.01.02.02.

[Randy222]

if you want the "meaningless clock"

SCPI :DIS:CLOC 1 cammand activates screen clock directly under LXI logo bottom right of screen.

I then do a :SYST:DATE 2099,12,31;:SYST:TIME 23,59,59
At least now I can use the clock as an uptime from boot, starting at basically 01/01/2100 00:00:00

So, send :DIS:CLOC 1;:SYST:DATE 2099,12,31;:SYST:TIME 23,59,59 via toolbox "toybox nc" in the start script.

The DHO will not accept SCPI year higher than 2099, but the clock will turn over to year 2100.

Anyone know what :SYST:KIMP is, the key value accepts 0 or 1

:SAVE:SET 1 crashes the Sparrow.apk

[Randy222]

This part though I still question. New key?
That does not make much sense given the issue that would arise from end-users who bought upgrade options and installed the lic to activate an option, unless the new Rkey.data process can still properly deciper old option lics?
Then some new updated FW comes along with a new key, which would then cause issue for the older lics based on older key data? Then end-user would need to have Rigol re-gen new option lics?
I don't see anywhere where Rigol mentions this might be an issue. This suggests to me perhaps the old option lics still work, but installing a new option lic is a different process, not necesarily with "new" key?

But it is true - the options that were active in version 00.01.02.00 were canceled when updating to version 00.01.02.02.

If that's the case, then I suspect there are little to no buyers of option lics, so to kill off the user generated lics they just modify the lic process in a new FW.

Rigol's reponse to "all you crackers".

[tv84]

Rigol's reponse to "all you crackers".

Almost.   The damage is done. 

[Martin72]

If that's the case, then I suspect there are little to no buyers of option lics, so to kill off the user generated lics they just modify the lic process in a new FW.

I would like to remind you that there are still no purchasable options for this series.
If you think about it a little, apparent contradictions resolve themselves.

[zelea2]

I'm really confused now.
I've upgraded my scope first via internet to version 1.2 and that has created a RKey.data. When compared to FRAM stored version it's the same but without the XOR over it.
Then I upgraded manually to DHO800_DHO900(Software)Updatev00.01.02.00.02 and when I tried to run my test program with this version of the libscope-auklet.so I've got no key back.
When I have straced my program I get the following failed accesses:

Code: [Select]

1566  openat(AT_FDCWD, "/rigol/data/BND.lic", O_RDWR) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/BW7T10.lic", O_RDWR) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/EMBD.lic", O_RDWR) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/COMP.lic", O_RDWR) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/Key.data", O_RDONLY) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/Key.data", O_RDONLY) = -1 ENOENT

When I've disassembled the new libscope-auklet.so  I haven't found any 'RKey.data' string .. only 'Key.data' 
WTF?

[Randy222]

I'm really confused now.
I've upgraded my scope first via internet to version 1.2 and that has created a RKey.data. When compared to FRAM stored version it's the same but without the XOR over it.
Then I upgraded manually to DHO800_DHO900(Software)Updatev00.01.02.00.02 and when I tried to run my test program with this version of the libscope-auklet.so I've got no key back.
When I have straced my program I get the following failed accesses:

Code: [Select]

1566  openat(AT_FDCWD, "/rigol/data/BND.lic", O_RDWR) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/BW7T10.lic", O_RDWR) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/EMBD.lic", O_RDWR) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/COMP.lic", O_RDWR) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/Key.data", O_RDONLY) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/Key.data", O_RDONLY) = -1 ENOENT

When I've disassembled the new libscope-auklet.so  I haven't found any 'RKey.data' string .. only 'Key.data' 
WTF?

RKey.data is there for sure. Are you looking at the correct .so file?

Note this function says "Gen NEW KEY". I think it's Rigol just blocking all the generated option lics simply by installing this new FW. We hacked it, they blocked it.

attached

[AndyBig]

Rigol's reponse to "all you crackers".

Heh, well, I won’t have a DHO814 with options that expand the bandwidth and memory depth, but a DHO914, which without any options already has a 125 MHz bandwidth and a memory depth of 50 megapoints )

When I've disassembled the new libscope-auklet.so  I haven't found any 'RKey.data' string .. only 'Key.data' 
WTF?

This line is definitely in the new library

[AndyBig]

I'm really confused now.
I've upgraded my scope first via internet to version 1.2 and that has created a RKey.data. When compared to FRAM stored version it's the same but without the XOR over it.
Then I upgraded manually to DHO800_DHO900(Software)Updatev00.01.02.00.02 and when I tried to run my test program with this version of the libscope-auklet.so I've got no key back.
When I have straced my program I get the following failed accesses:

Code: [Select]

1566  openat(AT_FDCWD, "/rigol/data/BND.lic", O_RDWR) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/BW7T10.lic", O_RDWR) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/EMBD.lic", O_RDWR) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/COMP.lic", O_RDWR) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/Key.data", O_RDONLY) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/Key.data", O_RDONLY) = -1 ENOENT

I don’t quite understand the essence of these errors, but if this is an attempt to open these files, then there will be errors, because updating to version 00.01.02.00.02 deletes all .lic files as they are no longer valid due to the changed option generation algorithm.

[AndyBig]

if you want the "meaningless clock"

SCPI :DIS:CLOC 1 cammand activates screen clock directly under LXI logo bottom right of screen.

Cool! My oscilloscope receives the date and time from the network, so I can get by with one command

[AceyTech]

For the effort needed to hack in more USB ports,
just get a small USB "hub" that has a 12" USB cord on it, plug it in and then attach the hubby to rear of scope.

But that's just me.

As for the USB-C in rear, in the teardown does it look like data pins weave into the RK3399? Or is thet USB-C soley just power?
If the read C data pins can be used, then it is possible to make a power & data-pins combiner using 3 USB-C female connectors, this way you can do feedthrough for the power wart and for a serial data line.

I did read through the RK3399 datasheet PDF. There are several ways to boot it, one being a USB OTG method, where you can actually boot something like ubuntu. I just not sure how USB OTG works.

Again, I was saying "...USB ports on these to plug devices into without going through a hub

FYI; I think those "data pins" traces you're referring to are the USB-B data traces.  I haven't beeped it out yet, tho'.
 
The USB-C port is for power input only, or at least what I've found so far.  My C dock/hub device will pass power, but peripherals don't connect to the Rigol, like they do on the A/host port up front.  I've tested this dock with 3 other tablet/notebook devices, and it works as intended.

Hmmm.  Well, AFAIK; USB OTG is basically USB where the host(phone, tablet, etc) has the capability to power the devices that are plugged into it.  It takes software and hardware to implement it, I'm pretty sure. -And it's doubtful Rigol would've spent the time/effort. **
Also, a lot of these boot methods require a physical button to be pressed prior to boot time.  Hey, maybe that's what the empty tact switch pads are for?(shown in the teardown photos)

So you haven't booted it from a USB stick then?

** Given the fact that there's a lot of other features the RK3399 have, that they clearly ignored.

[Randy222]

I don’t quite understand the essence of these errors, but if this is an attempt to open these files, then there will be errors, because updating to version 00.01.02.00.02 deletes all .lic files as they are no longer valid due to the changed option generation algorithm.

I am wondering if the new RKey.data method parks a unique key onto each system, perhaps used by Rigol later in some way to gen new lic files? Now each device becomes unique in some way, hence my key won't gen lics for your device, as we have done before with a common tool. However, knowing the method can still yield good lic files, but the key used for each system is perhaps different.

There's perhaps a test to find out.
Maybe take v01.02.00.02 GEL, unpack the files into a "orig" folder, install the GEL to the device, then use the device script to re-GEL a backup, and then find the file diffs between the two. This should show us what the new FW did during it's install and 1st boot?
Then perhaps take md5 of all the files from this 1st backup. Then restore something like v01.02.00.00 to the device, then update device with v01.02.00.02 again, grab a GEL backup, and repeat the compare steps again.
Now you have two lists of md5, one from backup #1 and one from backup #2.
Now find all files that have different md5. Then analuze that to determine if you expect such file to have same or different md5.

This method might lead to knowing of this new key method creates unique key during the FW install/boot, or not. Might also help find more info about the key itself.

The 2nd method which seems perhaps doable, mod the APK and re-sign it so it runs as shared user "system". Then we can muck around with functions and what-not, bypass the new key methos, etc.

[pdellacapanna]

Here is the DHO804 FW1.14 image (Thanks to @hubertyoung) with the DHO924 vendor file preloaded. Extract using 7zip then flash using HDD Raw Copy Tool (compressed image). If there is an vertical offset then use self cal or extended self cal.

https://mega.nz/file/UjBC3KRY#Kqv1BCHNQdPcUGMfR8IqbuUwHUsUhU4GpO1keTAXqf8

and

Here is the DHO804 FW1.14 image (Thanks to @hubertyoung) with the DHO924 vendor file preloaded. Extract using 7zip then flash using HDD Raw Copy Tool (compressed image). If there is an vertical offset then use self cal or extended self cal.

https://mega.nz/file/UjBC3KRY#Kqv1BCHNQdPcUGMfR8IqbuUwHUsUhU4GpO1keTAXqf8

Hi,

• This is what I've done:
  1. Run the Win32 Disk Imager
  2. Backup the SD
  3. Flash the SD with the image from the link
  4. Run the claibartation (offset gone) - device identifies as DHO804
  5. Connect the scope to ethernet
  6  Run adb:
      6.1 adb devices
      6.2 adb connect 192.xxx.x.xxx:55555
      6.3 "adb pull /rigol/data/vendor.bin"
      6.4 backup the generated vendor bin file from the adb folder to a new location
      6.5 copy in the adb folder the DHO924 image
      6.6 "adb push vendor.bin /rigol/data"

Is this procedure usable with firmware 00.01.02?

[Randy222]

Again, I was saying "...USB ports on these to plug devices into without going through a hub

FYI; I think those "data pins" traces you're referring to are the USB-B data traces.  I haven't beeped it out yet, tho'.
 
The USB-C port is for power input only, or at least what I've found so far.  My C dock/hub device will pass power, but peripherals don't connect to the Rigol, like they do on the A/host port up front.  I've tested this dock with 3 other tablet/notebook devices, and it works as intended.

Hmmm.  Well, AFAIK; USB OTG is basically USB where the host(phone, tablet, etc) has the capability to power the devices that are plugged into it.  It takes software and hardware to implement it, I'm pretty sure. -And it's doubtful Rigol would've spent the time/effort. **
Also, a lot of these boot methods require a physical button to be pressed prior to boot time.  Hey, maybe that's what the empty tact switch pads are for?(shown in the teardown photos)

So you haven't booted it from a USB stick then?

** Given the fact that there's a lot of other features the RK3399 have, that they clearly ignored.

Right, not every pin/feature of the RK3399 is used or implemented. Common practice.
I assume Rigol has to flash the boot-rom some how, there has to be a method.
The FW Rigol puts out for download is not even the android OS, it's just the scope app stuff.

It's probably easier to just make a USB-A nano that has a Logitech key/mouse, BT, wifi, and a passthrough 1-port USB "hub" for a 128GB mem stick, so you can have all that in one front USB-A port.

As for data transfer, the droid has nc in toybox, so you could essentially stream data in bi-directional fashion over wifi between the DHO and another device.

Another option is to try and find a USB hub that uses wifi between a USB desk hub and the DHO. Essentially USB<--wifi-->USB config. Essentially a double ended USB/wifi mux.

I could be wrong, but I am guessing there's not that many people who want their DHO800/900 to have 6 v3.1 USB ports.

[Randy222]

Is this procedure usable with firmware 00.01.02?

I suspect that's all old method.
Read through this thread.

Also, the 01.02 has several rev's already, 00.01.02.00.00 .01 and .02

[LEER333]

Dear friends, could you please provide the list or close-up photos of the missing devices of 814? Thank you!

[AndyBig]

I am wondering if the new RKey.data method parks a unique key onto each system, perhaps used by Rigol later in some way to gen new lic files? Now each device becomes unique in some way, hence my key won't gen lics for your device, as we have done before with a common tool. However, knowing the method can still yield good lic files, but the key used for each system is perhaps different.

The keys were always different, which is why it was necessary to generate options for each device individually

The 2nd method which seems perhaps doable, mod the APK and re-sign it so it runs as shared user "system". Then we can muck around with functions and what-not, bypass the new key methos, etc.

It would be great to pull off such a trick! This would open up enormous possibilities for modifying the oscilloscope application. I thought about this myself, but although I am a programmer, I only use C/C++ for microcontrollers, and Android with its applications is a dark forest for me. I can’t even imagine how realistic it is to do this and how much work will be required.

[zelea2]

I'm really confused now.
I've upgraded my scope first via internet to version 1.2 and that has created a RKey.data. When compared to FRAM stored version it's the same but without the XOR over it.
Then I upgraded manually to DHO800_DHO900(Software)Updatev00.01.02.00.02 and when I tried to run my test program with this version of the libscope-auklet.so I've got no key back.
When I have straced my program I get the following failed accesses:

Code: [Select]

1566  openat(AT_FDCWD, "/rigol/data/BND.lic", O_RDWR) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/BW7T10.lic", O_RDWR) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/EMBD.lic", O_RDWR) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/COMP.lic", O_RDWR) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/Key.data", O_RDONLY) = -1 ENOENT
1566  openat(AT_FDCWD, "/rigol/data/Key.data", O_RDONLY) = -1 ENOENT

When I've disassembled the new libscope-auklet.so  I haven't found any 'RKey.data' string .. only 'Key.data' 
WTF?

Darn ... I have "updated" to an old backup instead of version 1.2.2 because all of the update files have to be called DHO800_DHO900_Update.GEL with no version in the file
and I used one from the wrong directory.
Now my scope is in a weird state I can ping it, I can see the 55555 port open with nmap, the web interface is working but I can't adb connect to it anymore. So downgrading doesn't go so smooth.

I guess I'll have to open it now and manually restore the sdcard.

The above strace is when I run my test program linked to a particular libscope-auklet

Code: [Select]

  set_RString( &z, "License" );
  CApiLicense_CApiLicense( &AL, z, 0x24 );
  CApiLicense_init( &AL );
  set_RString( &a, "key" );
  set_RString( &b, "seed" );
  CApiLicense_getLicenseKey( &AL, &a, &b );
  printf( "key: %s\n", get_RString( &a, NULL ) );
  printf( "seed: %s\n", get_RString( &b, NULL ) );

and since I was using the one from version 1.0 it was just looking for Key.data which has been previously erased by version 1.2

Now again I can't do anything until I get home 

[zelea2]

The ssh server on your scope doesn't accept passwords. If you want ssh access do the following:

Code: [Select]

mount -o rw,remount /system
cat > /system/etc/ssh/authorized_keys
and paste your .ssh/id_rsa.pub then press Ctrl-D
cat > /system/etc/profile
export ANDROID_DATA=/data
export ANDROID_ROOT=/system
# also your favorite aliases, then press Ctrl-D
you can also vi /system/etc/ssh/sshd_config if you need to change any other settings like the ssh port
mount -o ro,remount /system

At next boot or when init.rigol.rc is executed it will

Code: [Select]

copy /system/etc/ssh/authorized_keys /data/ssh/authorized_keys
service daemonssh /system/bin/start-ssh

The you can ssh without password on port 22.

[zelea2]

Can someone please shed some light on which Sparrow.apk is the one currently running and where did it came from?
I have 2 versions residing on my scope:

Code: [Select]

rk3399_rigol:/rigol # ll /rigol/app/Sparrow.apk /system/app/Sparrow/Sparrow.apk
-rwxrwxrwx 1 root root 36898060 2023-07-21 08:21 /rigol/app/Sparrow.apk
-rw-r--r-- 1 root root 37148630 2023-08-23 03:40 /system/app/Sparrow/Sparrow.apk

I also have 3 GEL packages containing Sparrow.apk:

Code: [Select]

GEL.v1.1 36816140 Sparrow.apk
GEL.v1.2 36840716 Sparrow.apk
GEL.v1.2.2 36840716 Sparrow.apk

(same file in both 1.2 and 1.2.2)
None of the apk sizes match!

The /rigol/shell/do_update.sh and do_extract.sh scripts update the one in the /rigol/app directory

Are the apk modified when they are installed?

Code: [Select]

$ scp root@10.0.0.227:/rigol/app/Sparrow.apk .
$ unzip Sparrow.apk
$ strings lib/arm64-v8a/libscope-auklet.so | grep -i key.dat
Key.data

same happens with the /system/app/Sparrow/Sparrow.apk they all seem to use an old version of the libscope-auklet.so
But when I extract it directly from the GEL file:

Code: [Select]

$ tar -zxvf DHO800_DHO900_Update.GEL.v1.2.2.tar.gz
$ unzip app/Sparrow.apk
$ strings lib/arm64-v8a/libscope-auklet.so | grep -i key.dat
RKey.data

[Randy222]

So, Android is an odd type of mini beast.
With this level of droid there's actually 3 places where APK's can live, and depending on where they live the permissions get assigned or inherited different ways.

3 locations
/data/app/
/system/app/
/system/priv-app/

The update GEL (GEL = PK file) script on my DHO appears to unpack the GEL into a tmp folder, and from there the install and copies are done.

You can't really rely of hash or filesize of all the Sparrow APK's, a simple change made to the signing cert/key can make all that recon look different. You can however extract out the files of the APK's and then compare files.

So, I went looking around with tools am and pm, it appears all 3 rigol APK's (scope, launcher, webcontrol) all live in /data/app/
"scope" runs as package "com.rigol.scope"

My DHO has orig 00.01.02.00.00 FW. I have not changed anything on FW side.
It appears loading the scope app does not even happen in the start script, the am command to load .MainActivity has been commented out.

There's also some bloatware still active on the device, I post about that in a new post.

Do the APK's in the GEL get unpacked and perhaps manipulated? I don't think they do. Multiple APK's of same name on the filesystem are likely remnants.
Droid is a pita when it comes to naming stuff. Your have "APK" file name, but inside that you have the actual package name.
Why on my DHO I have Rigol package dir names with "-1", not sure.

These are the running Rigol apps on my DHO

Code: [Select]

adb shell cmd package list packages -f
package:/data/app/com.rigol.scope-1/base.apk=com.rigol.scope
package:/data/app/com.rigol.webcontrol-1/base.apk=com.rigol.webcontrol
package:/data/app/com.rigol.launcher-1/base.apk=com.rigol.launcher

[Randy222]

I am wondering if the new RKey.data method parks a unique key onto each system, perhaps used by Rigol later in some way to gen new lic files? Now each device becomes unique in some way, hence my key won't gen lics for your device, as we have done before with a common tool. However, knowing the method can still yield good lic files, but the key used for each system is perhaps different.

The keys were always different, which is why it was necessary to generate options for each device individually

The 2nd method which seems perhaps doable, mod the APK and re-sign it so it runs as shared user "system". Then we can muck around with functions and what-not, bypass the new key methos, etc.

It would be great to pull off such a trick! This would open up enormous possibilities for modifying the oscilloscope application. I thought about this myself, but although I am a programmer, I only use C/C++ for microcontrollers, and Android with its applications is a dark forest for me. I can’t even imagine how realistic it is to do this and how much work will be required.

Ahhh, that's right, now I recall. We were just pulling out Key.data into the ext tool, but each Key.data was diffent.

But noted here, we have access to droid via root. We can turn on "allow install of apps from unknown sources" in Security. I suspect this means we can install anything, which means mod the Rigol APK's, rebuild them, install.

[Randy222]

DHO bloat, not needed, at least from my testing, scope runs a-ok after disabling stuff.

The default build only has the Android Demo package disabled, but we can disable more.

Disabling does appear to be boot persistent (can likely ditch printspooler) NOTE: package:com.android.captiveportallogin seems to be needed for wifi connection to work.

Code: [Select]

pm disable [package name]
com.android.wallpapercropper
com.android.proxyhandler
com.android.smspush
com.android.providers.blockednumber
com.android.bluetooth
com.android.wallpaperpicker
package:com.android.captiveportallogin

The full list of packages installed

Code: [Select]

package:com.android.cts.priv.ctsshim
package:com.android.providers.media
package:com.rigol.webcontrol
package:com.android.wallpapercropper
package:com.rigol.launcher
package:com.android.externalstorage
package:com.android.htmlviewer
package:com.android.providers.downloads
package:com.android.defcontainer
package:com.android.pacprocessor
package:com.android.certinstaller
package:android.rockchip.update.service
package:android
package:com.android.mtp
package:com.android.backupconfirm
package:com.android.provision
package:com.android.statementservice
package:com.android.providers.setting:com.android.sharedstoragebackup
package:com.android.printspooler
package:com.android.dreams.basic
package:com.android.webview
package:com.android.rk
package:com.android.inputdevices
package:com.android.retaildemo
package:android.ext.shared
package:com.android.keychain
package:com.android.printservice.recommendation
package:android.ext.services
package:com.android.packageinstaller
package:com.svox.pico
package:com.android.proxyhandler
package:com.android.managedprovisioning
package:com.android.smspush
package:com.android.storagemanager
package:com.android.settings
package:acr.browser.barebones
package:com.android.cts.ctsshim
package:com.android.shell
package:com.android.wallpaperbackup
package:com.android.providers.blockednumber
package:com.android.providers.userdictionary
package:com.android.location.fused
package:com.android.systemui
package:com.ampak.rftesttool
package:com.android.bluetooth
package:com.android.wallpaperpicker
package:com.android.captiveportallogin
package:com.rigol.scope