Hacking the HDO1k/HDO4k Rigol 12 bit scope

[bosav]

yes, it is indeed a typo - the build date is also "2023/10/18 18:14:32"

It's weird that there is no Key.data file - given build numbers/dates, I would expect this should be from the same image

[Veteran68]

Progress -- many thanks for the foolproof instructions, Veteran68! I compiled the program, pushed it over to the scope and ran it, and captured both, the fram.bin file and the console output.

However, the binary file does not have the same data at offsets 0x011C and 0x01C4. The text file starts with a first data block which is indeed the same data that shows up at 0x011C in the binary file, but has 388 bytes (0x184), not 148.

Code: [Select]

id:091d data[184]:
C7 00 EE 86 54 DA 36 3D 18 10 53 F9 16 C3 D9 A0 A8 07 2E B0 2D A1 D8 65 82 46 54 F9 75 AD 25 98
...

Any recommendation what should go into the key.data file? Thank you!

My key.data file that lives in /rigol/data matches exactly the 148 bytes starting at offset 0x11C and also the 148 bytes starting at offset 0x01C4 in the fram.bin file generated on my scope. I not only eyeballed them, but selected each block of data and ran a CRC-32 on it inside HxD. All 3 blocks of 148 bytes matched.

But my hardware version is 3.

Interesting, you have one of the rare HW version 3 in a DSO1074 then. When others posted HW v3 they had the DSO1072. I wonder if HW v3 changed how the keys work? I hope not.

[bosav]

tried running it as well, just like Veteran68 -- I have two blocks at the same offsets, matching the key.data

[ebastler]

Success!

I first tried to generate a 148-byte key.data file from the FRAM data at 0x11C, but the Go program rejected that as "invalid format". But then noticed that voltsandjolts had indeed shown a Key.data file which is 388 bytes long (like that first block in my FRAM dump):

My scope had key.data in /rigol/data

Code: [Select]

D:\adb>adb shell ls -l /rigol/data
total 992
-rwxrwxrwx 1 system system    388 2023-01-09 18:58 Key.data

So I generated a Key.data from those 388 FRAM bytes, pushed it over to the scope and gave it to the Go script as well. And bingo -- valid codes for the memory and 200 MHz bandwidth options!

Thank you all for your quick help and practical support -- I would have been stumped without you! 

It leaves some interesting questions about versions... Is there a second flavor of key.data files (which is however also accepted by the Go script)? Maybe a 128 byte vs. 256 byte net key length, plus whatever checksums?  Is the difference linked to the hardware versions 2 vs. 3?  voltasandjolts, what hardware version does your scope have?

[voltsandjolts]

 

Is the difference linked to the hardware versions 2 vs. 3?  voltasandjolts, what hardware version does your scope have?

v2

[Veteran68]

Is the difference linked to the hardware versions 2 vs. 3?  voltasandjolts, what hardware version does your scope have?

v2

Very odd then. So the key difference of 148 bytes vs 388 bytes is not tied to hardware version 2 vs 3, nor apparently to a difference in FW or Android build. I assume then that the header contains an indicator to the app what size the key is. I wonder if it's a regional thing, maybe a different crypto algorithm is used in different parts of the world?

Let's see (assuming everyone's country is set correctly):

ebastler: Germany, HW3, 388 byte key
voltsandjolts:  UK, HW2, 388 byte key
bosav: Netherlands, HW2, 148 byte key
me:  US, HW2, 148 byte key

Nope, not seeing an obvious pattern there in terms of NA vs Europe or EU vs non-EU.

[ebastler]

Yes, it's strange indeed. I searched for other references to hardware version 3, and thm_w is the only other owner of a v3 I came across here. All other DHO1074 models reported were v2, while the DHO1072 identifies as v9.

Hardware-wise, TurboTom's scope (with a similar calibration date) comes from a time where Rigol had to heavily improvise with litte patch/piggyback boards, presumably due to component shortages. Maybe there was an incompatible substitution which resulted in a small batch of "version 3" units? My scope is of the same vintage as others seen in the Black Friday sale, with a January 2023 calibration date. I'll wait a bit longer, until my Amazon return window expires end of January, until I open it up for a curious look inside.

Regarding the different key.data sizes -- no idea what's behind that. It seems that the key length is neither related to the firmware history nor the hardware version. So what could it be? And even more obscure, why was the key.data file missing entirely on my unit?

[sizziff]

.... while the DHO1072 identifies as v9.

my 1072 has a hardware version 1

[TurboTom]

Happy New Year everyone! 

And let me add mine to the "key length collection": DHO1074 HW2, bought at the BF sales from Amazon Germany (Rigol Europe), Key length 148 byte, Cal certificate date Jan 13, 2023

[mm1]

DHO1104  Cal date 2022/10/16   Key Data 148 bytes Purchased NA.

[ebastler]

Happy New Year everyone! 

And let me add mine to the "key length collection": DHO1074 HW2, bought at the BF sales from Amazon Germany (Rigol Europe), Key length 148 byte, Cal certificate date Jan 13, 2023

That's the exact same calibration date as my DHO1074, by the way. Also bought via Amazon Germany (from Rigol Europe) during the BF sale -- but, as mentioned, with HW version 3 and a 388-byte key (provided in FRAM only).

I would love to understand Rigol's logistics... I did double-check the serial number on my calibration certificate, an reassuringly it actually is the same number as in my scope.

As mentioned earlier, I am not quite ready to break the warranty sticker until my "right to return, no questions asked" expires at the end of January. I will definitely look inside then and compare with your photos of the V2 hardware with its multiple piggyback boards.

[TurboTom]

I guess the multiple replacements for the voltage regulators in the HW2 version aren't a big deal. But both the Network PHY (Motorcomm vs. Microchip) as well as the USB hub (TI vs. Microchip) are "piggybacked" in HW2 units which probably requires alternative drivers. It's well possible that in HW3, only one of these chips has been changed or they used even a different type... I'm already quite curious what you will find in your DHO1074 when you go and take a look. 

[bastl_r]

My DHO1074 is HW 2 and calibration at 2023/03/28.
Bought at BF from Batronix.

[thm_w]

HW3 388 byte key.data was present

I guess the multiple replacements for the voltage regulators in the HW2 version aren't a big deal. But both the Network PHY (Motorcomm vs. Microchip) as well as the USB hub (TI vs. Microchip) are "piggybacked" in HW2 units which probably requires alternative drivers. It's well possible that in HW3, only one of these chips has been changed or they used even a different type... I'm already quite curious what you will find in your DHO1074 when you go and take a look. 

Maybe can tell from lsusb:

Code: [Select]

rk3399_rigol:/ $ lsusb
Bus 001 Device 002: ID 0424:2734  (Microchip hub)
Bus 002 Device 002: ID 0424:5734  (Microchip hub)
Bus 001 Device 001: ID 1d6b:0002  (root hub 2.0)
Bus 002 Device 001: ID 1d6b:0003  (root hub 3.0)
Bus 001 Device 003: ID 0424:274e  (Microchip ethernet?)
Some interesting stuff here but I think only the pwm_fan can be controlled easily

Code: [Select]

rk3399_rigol:/ $ lsmod
Module                  Size  Used by
...
usb_gpib               21937  0
afe_rms_gpio            2864  0
dac_gpio                3724  1
pwm_fan                 8647  2
beeper_gpio             3684  0
focaltech_ts           75050  0
ilitek_ts              37389  0
spi2afe_gpio            5530  1
...

[the Chris]

DHO1074, HW2, Cal-Date 28-03-2023. Bought directly via Rigol online store prior to christmas.

[the Chris]

HW 2, 148 bytes key.data

Maybe can tell from lsusb:

Here is mine:

Code: [Select]

Bus 003 Device 002: ID 0451:8027   (Texas Instruments USB 3.0 2-Port Hub)
Bus 004 Device 002: ID 0451:8025   (Texas Instruments USB 3.0 2-Port Hub)
Bus 003 Device 001: ID 1d6b:0002   (root hub 2.0)
Bus 004 Device 001: ID 1d6b:0003   (root hub 2.0)
Bus 003 Device 003: ID 046d:c077   (my attached Logitech Mouse)

So they changed the USB 3.0 hub, it seems.

rk3399_rigol:/ $ lsmod

Code: [Select]

Module                  Size  Used by
usbtmc_dev             41918  2
libcomposite           60749  1 usbtmc_dev
usb_gpib               21937  0
afe_rms_gpio            2864  0
dac_gpio                3724  1
pwm_fan                 8647  2
beeper_gpio             3684  1
focaltech_ts           75050  0
ilitek_ts              37389  0
spi2afe_gpio            5530  1
xdma                   99943  2
pcie_rockchip          20793  0
spi2pll_gpio            5142  1
fpga_gpio               3859  0
hdcode_gpio             2304  0
motorcomm              17303  0
...

[voltsandjolts]

I briefly have access to two units:

DHO1074  HWv2  Cal'd OCT22 148 byte key

DHO1074  HWv2  Cal'd JAN23 388 byte key

Also including reports from others here, it seems they increased key size to 388 bytes around January 2023 and it's not related to hardware version.

[ebastler]

Yes (20 M, 250 M and full, after doing patch 3) and yes [50 Ohm inputs work] (but with the amplitude problem).

Hopefully I did not derail the thread with my unexpected "no key.data, and the relevant FRAM content is 388 bytes long" adventure...

I am curious -- has anybody explored the apk-based hack any further, and been able to figure out what stands in the way of fully calibrated 50 Ohm inputs?

[tv84]

AFAIR, it's totally irrelevant the key size because the licensing algorithm is totally messed up.

As such, as long as the key string has sufficient bytes to be used as an 128-bit AES key, you're good to go. Of course the sizes you report are perfectly OK for that.

I will repeat this for the n-th time  : the licensing is based on ECC asym crypto but implemented as AES sym crypto...  That's why any script kid can generate these licenses.

[ixtern]

Hi
I am new here.
Got my DHO1074 few days ago. It came with 00.02.04 firmware and hardware version 2. I have updated it to the latest 00.02.12.

Next I've upgraded it according to the instructions from here. Upgrade was successful although adb pull command for me must be little different:
As "./adb pull /rigol/data/Key.data" returned: "adb: error: failed to get feature set: more than one device/emulator\"
I used "./adb -s 192.168.1.22:55555 pull /rigol/data/Key.data" where 192.168.1.22 is the IP address of my scope.

Screenshot was taken with UltraSigma software.

Best regards for all.

[the Chris]

Welcome ixtern.

The error message you got should only occur if you have more than one adb device connected. It could have been your mobile or the scope itself if attached via USB alongside the ethernet connection. If you don't have any adb device connected via USB, opening the connection via "adb connect IP:55555" should establish the connection while registering it, making the only choice of communication for the computer you are running the adb on.

Best wishes,
Christian

[the Chris]

Welcome ixtern.

The error message you got should only occur if you have more than one adb device connected. It could have been your mobile or the scope itself if attached via USB alongside the ethernet connection. If you don't have any adb device connected via USB, opening the connection via "adb connect IP:55555" should establish the connection while registering it, making the only choice of communication for the computer you are running the adb on.

Best wishes,
Christian

Hmmm... this should have been an edit, not a self-quote, to add a paragraph. Edited for clarity, I wanted to add:

Anyway, specifying the specific device in each command is obviously possible as well in case there is a second device which you do not want to remove for reasons.

[ixtern]

Welcome ixtern.

The error message you got should only occur if you have more than one adb device connected. It could have been your mobile or the scope itself if attached via USB alongside the ethernet connection. If you don't have any adb device connected via USB, opening the connection via "adb connect IP:55555" should establish the connection while registering it, making the only choice of communication for the computer you are running the adb on.

Best wishes,
Christian

I think you are right. Perhaps I had scope connected by USB too.

At the time of upgrade I executed command:
/adb devices

List of devices attached
192.168.1.22:55555      device
emulator-5562   offline

Best regards,

[ausey00]

Hi all. Have done a lot of reading but still not building a full picture of the state of unlocking the HDO4k series.

If I purchased a new 4204, would I be able to unlock memory, decoders and bandwidth?
If so, is there a brief write up somewhere? I'm not seeing it...

Also while I'm here. Do the SE active probes work with HDO series?

Ta!
Austin

[ebastler]

If I purchased a new 4204, would I be able to unlock memory, decoders and bandwidth?
If so, is there a brief write up somewhere? I'm not seeing it...

Also while I'm here. Do the SE active probes work with HDO series?

I'll chime in as a former DHO1000 owner. The firmware is identical for the two scope series (but with different options supported/enabled), so "upgradability" should be the same.

At the moment, it is possible to generate unlock keys to enable bandwidth, memory and -- to the extent Rigol offers them officially -- decoder upgrades. However, for the smaller siblings (DHO800 and 900) Rigol has just released new firmware which uses a different security scheme, possibly via a proper public/private key implementation. So far, no key generator for this new scheme has been published.

There is an alternate hacking approach for the DHO800, which makes it think it's a DHO900; but that does not apply to the DHO4000, which is already the top-of-the-line model. So if Rigol decide to switch to the new security scheme in an upcoming firmware release, the DHO4000 would no longer be hackable (unless someone breaks the new scheme and makes this public).

Regarding probes, I assume "SE" refers to Rigol's single-ended active probes, rather than to a particular series named "SE"? The scope's datasheet lists all supported probes: https://www.batronix.com/files/Rigol/Oszilloskope/DHO4000/DHO4000_DataSheet_en.pdf, pages 5 ff.

Edit:

Hacking instructions for the DHO800/900 (old approach):
https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5148330/#msg5148330
https://youtu.be/watch?v=Az9lXMGV_jM

DHO4000-specific notes, but less detailed:
https://www.eevblog.com/forum/testgear/hacking-the-hdo1khdo4k-rigol-12-bit-scope/msg4793000/#msg4793000