Hacking the Rigol DHO800/900 Scope

[AceyTech]

As is in current config
USB B port on the back is an USB device or client or whatever name they have, is not a USB host port.
USB A port on front is a USB host port where you can plug devices

I do wish that we had 1-2 more native USB ports on these to plug devices into without going through a hub.  And as such, I'm curious how difficult it would be to modify the RK3399 config so the B port would be a 3.x host...  Adding a little power control chip and connector wouldn't be that difficult.  I think it would be a better use of a port than USBTMC, at least for my uses.

[gabiz_ro]

Without schematic need reverse engineering at hardware and software level.
Read RK3399 datasheet
https://www.rockchip.fr/RK3399 datasheet V1.8.pdf
Check if USB required pins are not used for alternative functions (maybe are unused or used for something else)
Route that to USB port.
Make required initialization in android OS and that's all.

[Fungus]

Is that B port only for USBTMC?

It's for plugging in your WiFi dongle. 

After that you can use FTP to grab files and web browser for screenshots.

So the USB B port on the back is for plugging devices into?  Sweet! I'll build a Male B to Female A adapter then. 
Thanks!

Ooops, no! I got confused, the one one the back is only for connecting TO the device.

The one on the front is for WiFi. It's pretty much all you need.

[Fungus]

I do wish that we had 1-2 more native USB ports on these to plug devices into without going through a hub.

I'm sure you can find a hub small enough to glue to the front if you need more ports...

I'm happy with just a WiFi dongle.

There's absolutely no need for USB sticks when you have WiFi working and I find a stylus works better than a mouse.

[shapirus]

I was wondering if there's enough room inside to bodge a small USB hub (e.g. simply with 4 wires) in place of the original front panel port and connect a wifi dongle and an extension cable leading to the front panel connector to it, making the original port now connected to the hub and creating a built-in wifi interface. One would need to be really desperate to go this way though :)

[Randy222]

Howdy.  I'm trying to get a complete backup from a new/unmodded DHO800 so I can open it up and get hackin'.

I panicked a bit when the second calibration attempt failed.  I found this post from @Mechatrommer and others about calibration failure with "testmode on"
Anyone know which of the additional options work/fail to cal, to save me some time?

Also, I know ADB works fine via Wifi, but what about via USB?  Is that B port only for USBTMC?  I can't see any devices via ChromeOS/Linux or Windoze(altho', it shows up in Device Mangler)

A linux boot USB and using ddrescue would be my approach, but there are also live droid tools that can copy block level.
Of if you just want files, maybe tar-zip / and place the output file on a large USB stick.

[Randy222]

Is the oscilloscope application really signed?
I wonder if an unsigned APK simply won’t launch? Or how does a signature work?

Yep. Surely signed.
Interesting signing info, would think the cert info would be Rigol Corp china, but appears to be SDK default with a rigol email address.

As we can see, only type-v2 signing is done.
There's also a difference between INSTALLING vs SIDE-LOADING an APK. I believe the Rigol APK's are side loaded.
Re-signing with a new key pair does seem doable. However, there seems to be conflicting text on Android site about being able to re-sign with or without same keys w/o issue.

Is it possible to derive the private key from this public key? My answer is yes we can, but will need access to some qubit cycles in cloud or something since it takes time.

Code: [Select]

apksigner verify --verbose --print-certs C:\Users\randy\Desktop\DHO\Sparrow.apk.zip

Verifies
Verified using v1 scheme (JAR signing): false
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Verified using v3.1 scheme (APK Signature Scheme v3.1): false
Verified using v4 scheme (APK Signature Scheme v4): false
Verified for SourceStamp: false
Number of signers: 1
Signer #1 certificate DN: EMAILADDRESS=hexiaohua@rigol.com, CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US
Signer #1 certificate SHA-256 digest: f48e7189aac174df7fd19acf58b6d15832760fcf25ac0a6d4bcd5fc1974d4c03
Signer #1 certificate SHA-1 digest: df345a93532e902ff6291668c20ad69da3b72ff6
Signer #1 certificate MD5 digest: 40490c2e0b280e29ba5e46205272e3dc
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048
Signer #1 public key SHA-256 digest: ca871f06fa7ffaa5beda2179a2278a0474d98e6b5e11d9aab2dfb590d8e57292
Signer #1 public key SHA-1 digest: 90ff0ddf5a0881ea080558b3b585dd0352342d8e
Signer #1 public key MD5 digest: 78d923a60c0963a38de1ee05b4556031
Also, from poking around in Sparrow APK in Droid Studio Hedgehog, Rigol's SDK is v29 but they target v25. Not sure why, maybe some of their hardware can't run droid above v25, or maybe due to some deprecation in v29 they still write for v25 in the v29 SDK. Not sure exactly. Studio also throws up a boat load of warnings about bad whitespacing, and one URI error for the URL in manifeat for schema reference. The URL does not seem to exist on internet, so maybe Rigol has a hosts entry for it in their SDK machine?

[Fungus]

There's also a difference between INSTALLING vs SIDE-LOADING an APK. I believe the Rigol APK's are side loaded.

There's a script /rigol/shell/do_extract.sh that installs the .apk

[Randy222]

There's also a difference between INSTALLING vs SIDE-LOADING an APK. I believe the Rigol APK's are side loaded.

There's a script /rigol/shell/do_extract.sh that installs the .apk

Installs, or just copies files out of the GEL(zip) and places them onto a filesystem?

[Fungus]

There's a script /rigol/shell/do_extract.sh that installs the .apk

Installs, or just copies files out of the GEL(zip) and places them onto a filesystem?

I'm not an Android expert but it looks like an install to me:

Code: [Select]

...
UPDATE_DSO=$UPDATE_SOURCE/app/Sparrow.apk

####################################################################################
# Scope APK install. return if failed  You can install WITHOUT VERSION CHECKING
####################################################################################
if [ -f $UPDATE_DSO ]; then
echo pm install -r $UPDATE_DSO
pm install -r $UPDATE_DSO  >/dev/null 2>&1

#check if success
if [ $? -ne 0 ]; then
#restore when install failed
cp $UPDATE_BAKUP/* $UPDATE_TARGET/ -R 
echo 'Upgradation failed'
rm $UPDATE_FLAG
sync
exit 2
fi
fi

echo "OK"


[Randy222]

They dev/null the install stdout? Why?
If the check fails and cp rollback happens, wouldn't it be nice to have the install log?

[shapirus]

They dev/null the install stdout? Why?

So that the hackers can have fun finding and fixing it, it seems.

[Randy222]

Did a little tuning for SSH and startup script.

Once you get SSH working with keys (as written up already), the ssh session is missing ANDROID_SYSTEM and ANDROID_DATA env variables.
Variables are ANDROID_SYSTEM=\system and ANDROID_DATA=\data
I set "AcceptEnv ANDROID_SYSTEM ANDROID_DATA" in sshd_config file (you need to remount /system as rw to edit that file).
I then pass along the variables in Putty.

Next is to STOP the scope and to turn off CH1 during boot-up. After re-reading thread posts I figured it out.
So, in start script (/rigol/shell/) I make some mods around the insmod of the touchscreen driver. Not really sure why they put a sleep 20 before loading ts driver focaltech_ts.ko
So, I comment out that sleep 20 and add a sleep 10 after the ts driver, then this line below "sleep 10" , echo ":STOP;CHANnel1:DISPlay 0" |toybox nc -q 2 localhost 5555

Now the unit boots a smidge faster and it will rest in a no-channel STOP mode (the way it should be).

I could not find any properties key values that would set Channel or Run state.

[AceyTech]

Without schematic need reverse engineering at hardware and software level.
Read RK3399 datasheet
https://www.rockchip.fr/RK3399 datasheet V1.8.pdf
Check if USB required pins are not used for alternative functions (maybe are unused or used for something else)
Route that to USB port.
Make required initialization in android OS and that's all.

Thanks! That's what I thought too.  I've read thru several datasheets and schematics from various RK3399 SBC vendors.  Rigol most likely used a reference design from Rockchip., and I wish I could get my hands on the one they used in this design, especially with schematics..  I've been out of the biz long enuf to lose all my old industry contacts.

Clearly, the USB B port in the back is routed directly, as it's already in use as a USB device, and implemented as USBTMC.  What I was suggesting is changing that port to a 3.1 host.  I haven't opened mine yet, but Dave's teardown pics show the protection diodes(on the back) for that port.

[AceyTech]

A linux boot USB and using ddrescue would be my approach, but there are also live droid tools that can copy block level.
Of if you just want files, maybe tar-zip / and place the output file on a large USB stick.

So, did you find that these DHO scopes boot from USB?  'cuz I have a super cheap M.2 drive and USB adapter that gets ~1GBps transfers that I would prefer to use to boot from.  Sure would beat the TF speed of 10-11.

[AceyTech]

I do wish that we had 1-2 more native USB ports on these to plug devices into without going through a hub.

I'm sure you can find a hub small enough to glue to the front if you need more ports...  I'm happy with just a WiFi dongle.

I see your point, but again, I was saying without a hub.  It looks "fiddly" to me to have a bunch of cables and adapters hanging off and besides, cheap USB connectors have a finite amount of mating cycles.  -verify this claim by looking in your junk box.

There's absolutely no need for USB sticks when you have WiFi working and I find a stylus works better than a mouse.

Well, there are other devices that people like to plug into these other than WiFi; like kybd/mouse, audio, Bluetooth, etc. I've even seen people using thermal cameras and SDRs.  -Even tho' the latter are probably not that important to have plugged all the time.

BTW: I have a couple 5-in-1 USB-C "docks" (i.e., hubs) that have SDCard/USB/HDMI, and interestingly, one of them makes my scope reboot when I plug it in. -without anything peripherals plugged into it.  And it doesn't freak out any other devices I've plugged it into.  Funky.

[Randy222]

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.

[zelea2]

I've written a small C program to dump the scope FRAM.
You can use the kernel /dev/i2c devices to do that. FRAM sits on bus 4 at slave address 0x50
You must first write 2 bytes specifying the start address and then you can read/write from the file descriptor.

I have found no evidence that the scope model, serial or MAC are stored in the FRAM.
The Key.data (I'm still on the old firmware) is though.
At address 0x100 you have a header of 6 words, next the CRC32 of the file and then from 0x11C-0x1B0
the entire Key.data file

The FRAM is mostly empty except the 0x800-0x12F0 region which I presume holds all the calibration data.

[Fungus]

I have found no evidence that the scope model, serial or MAC are stored in the FRAM.

FRAM is only for storing the current state of the device for power-off. It gets written to every time you twist a knob so it has to be something that can't ever wear out.

(cue all the "flash can do that too!" replies)

The model, serial and MAC are stored in /rigol/data/vendor.bin

[Randy222]

I see auklet.so changes a lot from 01.02.00.00 to 01.02.00.02

But I went looking for "lic" and "Key.data"

Note sure this helps.
You can see where RKey.data is in the v01.02.00.02 so file, maybe hunt that down in Ghidra.

In the older FW, is the key used an AES key? Is that key perhaps part of the keypair used to sign the APK's ?

Code: [Select]

[roott@localhost DHO]# strings libscope-auklet.01.02.so |grep lic
_ZN8CApiBase14licenseChangedEv
_ZN14CApiHorizontal14licenseChangedEv
_ZThn8_N14CApiHorizontal14licenseChangedEv
_ZN11CApiUtility14licenseChangedEv
_ZThn8_N11CApiUtility14licenseChangedEv
_ZN7CApiRef14licenseChangedEv
_ZThn8_N7CApiRef14licenseChangedEv
_ZN11CApiTrigger14licenseChangedEv
_ZThn8_N11CApiTrigger14licenseChangedEv
_ZN7CApiBus14licenseChangedEv
_ZThn8_N7CApiBus14licenseChangedEv
_ZN10CApiSearch14licenseChangedEv
_ZThn8_N10CApiSearch14licenseChangedEv
.lic
[%s][%s][%d]: ************USB-TMC Application Watcher - init_netlink E ************
[%s][%s][%d]: ************USB-TMC Application Watcher - init_netlink X ************
[%s][%s][%d]: ************USB-TMC Application Watcher************
[%s][%s][%d]: ************USB-TMC Application Watcher - do while loop - netlink_sd = %d ************
[roott@localhost DHO]# strings libscope-auklet.01.02.so |grep lic |wc -l
18

///////////////////\\\\\\\\\\\\\\\\\\\\

[roott@localhost DHO]# strings libscope-auklet.01.02.02.so |grep lic
_ZN8CApiBase14licenseChangedEv
_ZN14CApiHorizontal14licenseChangedEv
_ZThn8_N14CApiHorizontal14licenseChangedEv
_ZN11CApiUtility14licenseChangedEv
_ZThn8_N11CApiUtility14licenseChangedEv
_ZN7CApiRef14licenseChangedEv
_ZThn8_N7CApiRef14licenseChangedEv
_ZN11CApiTrigger14licenseChangedEv
_ZThn8_N11CApiTrigger14licenseChangedEv
_ZN7CApiBus14licenseChangedEv
_ZThn8_N7CApiBus14licenseChangedEv
_ZN10CApiSearch14licenseChangedEv
_ZThn8_N10CApiSearch14licenseChangedEv
.lic
../../../../src/cpp/scope/api/license/license.cpp
[%s][%s][%d]: ************USB-TMC Application Watcher - init_netlink E ************
[%s][%s][%d]: ************USB-TMC Application Watcher - init_netlink X ************
[%s][%s][%d]: ************USB-TMC Application Watcher************
[%s][%s][%d]: ************USB-TMC Application Watcher - do while loop - netlink_sd = %d ************
[roott@localhost DHO]# strings libscope-auklet.01.02.02.so |grep lic |wc -l
19

///////////////////\\\\\\\\\\\\\\\\\\\\

[roott@localhost DHO]# strings libscope-auklet.01.02.02.so |grep lic > 2.txt
[roott@localhost DHO]# strings libscope-auklet.01.02.so |grep lic > 1.txt
[roott@localhost DHO]# diff 1.txt 2.txt
14a15
> ../../../../src/cpp/scope/api/license/license.cpp

///////////////////\\\\\\\\\\\\\\\\\\\\

[roott@localhost DHO]# strings libscope-auklet.01.02.so |grep Key.data
Key.data
[roott@localhost DHO]# strings libscope-auklet.01.02.so |grep Key.data |hexdump
0000000 654b 2e79 6164 6174 000a               
0000009
[roott@localhost DHO]# strings libscope-auklet.01.02.02.so |grep Key.data
RKey.data
[roott@localhost DHO]# strings libscope-auklet.01.02.02.so |grep Key.data |hexdump
0000000 4b52 7965 642e 7461 0a61               
000000a

[smithnerd]

There are two new public functions in the new libscope-auklet.so, which appear to be relevant to the license changes:

method.CApiLicense.generate_something
method.CApiLicense.xorEncrypt

Plus a few private ones. xorEncrypt is trivial, but 'generate_something' looks quite interesting.

[Randy222]

There are two new public functions in the new libscope-auklet.so, which appear to be relevant to the license changes:

method.CApiLicense.generate_something
method.CApiLicense.xorEncrypt

Plus a few private ones. xorEncrypt is trivial, but 'generate_something' looks quite interesting.

I find it in Ghidra, but I can't follow the assembly code that well. But I getting it slowly. Here's the C function of the assembly.

So what does this function do?

Code: [Select]

void _ZN11CApiLicense18generate_somethingEm(long *param_1,undefined8 param_2,long param_3)

{
  undefined *puVar1;
  undefined8 uVar2;
  ulong uVar3;
  undefined *puVar4;
  long lVar5;
  long lVar6;
  long lVar7;
  ulong uVar8;
  long lVar9;
 
  *param_1 = 0;
  param_1[1] = 0;
  param_1[2] = 0;
  if (param_3 == 0) {
    return;
  }
  puVar1 = (undefined *)FUN_00271b60(param_3);
  lVar9 = 0;
  puVar4 = puVar1 + param_3;
  *param_1 = (long)puVar1;
  param_1[1] = (long)puVar1;
  param_1[2] = (long)puVar4;
  if (puVar4 <= puVar1) goto LAB_0037a56c;
  do {
    *puVar1 = (char)lVar9;
    param_1[1] = (long)(puVar1 + 1);
    while( true ) {
      if (param_3 + -1 == lVar9) {
        return;
      }
      puVar1 = (undefined *)param_1[1];
      puVar4 = (undefined *)param_1[2];
      lVar9 = lVar9 + 1;
      if (puVar1 < puVar4) break;
LAB_0037a56c:
      lVar5 = *param_1;
      lVar6 = (long)puVar1 - lVar5;
      uVar8 = lVar6 + 1;
      if ((long)uVar8 < 0) {
        uVar2 = FUN_0027ec50(param_1);
        lVar9 = *param_1;
        if (lVar9 != 0) {
          param_1[1] = lVar9;
          FUN_00273f60(lVar9);
        }
                    /* WARNING: Subroutine does not return */
        FUN_00b1036c(uVar2);
      }
      if ((ulong)((long)puVar4 - lVar5) < 0x3fffffffffffffff) {
        uVar3 = ((long)puVar4 - lVar5) * 2;
        if (uVar8 <= uVar3) {
          uVar8 = uVar3;
        }
        if (uVar8 != 0) goto LAB_0037a5a4;
        lVar7 = 0;
      }
      else {
        uVar8 = 0x7fffffffffffffff;
LAB_0037a5a4:
        lVar7 = FUN_00271b60(uVar8);
      }
      *(undefined *)(lVar7 + lVar6) = (char)lVar9;
      if (0 < lVar6) {
        FUN_0027fef0(lVar7,lVar5,lVar6);
      }
      *param_1 = lVar7;
      param_1[1] = (long)((undefined *)(lVar7 + lVar6) + 1);
      param_1[2] = lVar7 + uVar8;
      if (lVar5 != 0) {
        FUN_00273f60(lVar5);
      }
    }
  } while( true );
}

[zelea2]

I've updated my tool to be able to generate options for the new RKey.data file:
https://github.com/zelea2/rigol_vendor_bin
The only difference between the Key.data and RKey.data is that the later is XORed with a vector of incremented bytes then xxtea decrypted as before.
The AES keys are changed but we don't need to understand how. I haven't even tested it yet because I'm at work and my scope at home connected on my localnet.

I was able to print my new AES key because in the end I found a very nice environment to test functions in the libscope-auklet.so library.
Initially I wanted to run all my tests on a linux PC but that turned out almost impossible because all of the other library dependencies and symbol versioning.
In the end I've used the scope itself with 'adb root/push/pull/shell' commands.

First I've installed on my linux machine the latest Android NDK (not SDK) then I've made a working directory where I could compile my programs:

Code: [Select]

<NDK>/build/tools/make_standalone_toolchain.py --arch arm64 --install-dir working_dirIn my test program I first call dlopen to load "libscope-auklet.so" (I also do export LD_LIBRARY_PATH= so the program can find it) and then you can
call any exported function from that library and don't worry about signatures.
I call the CApiLicense constructor and finally the getLicenseKey and print them to stdout. I've also dumped the CApiLicense structure which is 440 bytes long
but I haven't bothered with what all fields represent.
The function which deletes and replaces the old Key.data with RKey.data is CApiLicense::init and I've checked by running it twice that is generates the same new file
so the new AES key (as the old one) must be somehow linked to your particular scope.

I haven't even tested this and my scope is still on v1.1 - probably someone else will beat me until I get home 

[AndyBig]

I haven't even tested this and my scope is still on v1.1 - probably someone else will beat me until I get home 

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):

Code: [Select]

brainpoolP256r1;0405B21204BBA6FF16B9110FD458F4B2EF5A8484B7B46A259BCA90D66BC425BD5E960DFDEB0F6D368EFDB0FB64B43D93FF4FB554D33EB74D0006E5D09A54791EF2

[Randy222]

so the new AES key (as the old one) must be somehow linked to your particular scope.

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?
From Android Studio it appears Rigol (or the hands-on folks using the Android SDK) used a default "debug" key for system. With 1,000's, maybe 10's 1,000's, of DHO out there, unique key management for each device would be very problematic.

I am perhaps wrong about it.