Hacking the Rigol DHO800/900 Scope

[shapirus]

So in a nutshell, what is the current state?

- do the previously made hacks (applied onto an older firmware) stop working when firmware is upgraded?
- it seems that it's currently not possible to hack a scope with the latest FW, correct?

[AndyBig]

There is no AES operation in CApiLicense::getLicenseKey (which reads RKey.data)  just bytes scrambling.
AES_decrypt is only called in CApiLicense::verifyOption

I'm not talking about the AES key, but specifically about the key that decodes RKey.data

So in a nutshell, what is the current state?

- do the previously made hacks (applied onto an older firmware) stop working when firmware is upgraded?
- it seems that it's currently not possible to hack a scope with the latest FW, correct?

Yes, the previously received options stop working and it is not yet possible to generate new ones for the latest firmware. But it is still possible to upgrade the oscilloscope model number.

[shapirus]

Yes, the previously received options stop working and it is not yet possible to generate new ones for the latest firmware.

What kind of options?

But it is still possible to upgrade the oscilloscope model number.

Interesting. Is it different from the options that you mentioned above? Actually let's put it this way: the (only) things that I am after are unlocking a DHO804 into 100MHz, or whatever is achievable, bandwidth, and (I saw somewhere that it was possible earlier) into 50M/25M/10M memory depth. Is this still possible?
My scope is still in transit, so I'm now kind of gathering info and preparing for what can be expected. I ordered it around the time new FW was released, so it will very likely have an older FW, but it may as well come with the latest one, who knows.

[Randy222]

v00.01.02.00.00 still works like the older 01.01's

Do the hacks as we know them break with anything newer than v00.01.02.00.00 ?

[tv84]

You don't just have to know how to encrypt it, you have to know what to put in it.

The same for decrypt (start, end, algo, key, IV, mode, etc). Please, don't continue this road.

[AndyBig]

What kind of options?

I meant options (keys) to unlock additional features. For older firmware they could be generated and received by the oscilloscope. In the latest firmware, previously generated options are no longer accepted, since their generation requires another, new key, which is still unknown.

Interesting. Is it different from the options that you mentioned above? Actually let's put it this way: the (only) things that I am after are unlocking a DHO804 into 100MHz, or whatever is achievable, bandwidth, and (I saw somewhere that it was possible earlier) into 50M/25M/10M memory depth. Is this still possible?
My scope is still in transit, so I'm now kind of gathering info and preparing for what can be expected. I ordered it around the time new FW was released, so it will very likely have an older FW, but it may as well come with the latest one, who knows.

No, no additional features can be unlocked in the latest firmware. You will not be able to generate an option to increase bandwidth or increase memory depth. But it remains possible to force the oscilloscope to consider itself not a DXO804 with a 70 MHz bandwidth, but, for example, a DXO914 with a 125 MHz bandwidth and full memory depth, or a DXO924 with a 250 MHz bandwidth. To do this, simply use a special utility to change the oscilloscope model in the vendor.bin file.

[Pinkus]

But since nobody knows what Rigol will come up with in the future, it is better to make a 1:1 backup of the SD card first. Then run your scope with the new SD card so you always have the untouched original.

[shapirus]

But it remains possible to force the oscilloscope to consider itself not a DXO804 with a 70 MHz bandwidth, but, for example, a DXO914 with a 125 MHz bandwidth and full memory depth, or a DXO924 with a 250 MHz bandwidth. To do this, simply use a special utility to change the oscilloscope model in the vendor.bin file.

Who cares how the scope identifies itself?
What really matters is not what it considers itself to be, but whether the increased bandwidth and memory depth will actually work, when it thinks that it's a more advanced model. Will they, with the updated vendor.bin?

But since nobody knows what Rigol will come up with in the future, it is better to make a 1:1 backup of the SD card first. Then run your scope with the new SD card so you always have the untouched original.

Yeah it goes without saying, this is precisely what I'm planning to do.

[ebastler]

Who cares how the scope identifies itself?
What really matters is not what it considers itself to be, but whether the increased bandwidth and memory depth will actually work, when it thinks that it's a more advanced model. Will they, with the updated vendor.bin?

Yes, these will work. And as a little added benefit, you also get triggers and decoding for the CAN and LIN protocols.

There is one cosmetic "side effect": A control box for the digital channels will be displayed in the bottom line of the screen, but these will of course be non-working. Some users also experienced a functional side effect earlier -- namely small voltage offsets in some channels which the self-calibration could not remove -- but I believe this has been resolved with the more recent firmware versions. 

[Fungus]

But since nobody knows what Rigol will come up with in the future, it is better to make a 1:1 backup of the SD card first. Then run your scope with the new SD card so you always have the untouched original.

No need. A firmware update is just a UNix .tar of the the contents of the /rigol folder with /rigol/data excluded.

There's even a shell command "/rigol/build_gel.sh" to make your own .gel file from your current setup.

(which I'm guessing is the reason why there's so many "unofficial" firmwares out there - they made it too damn easy for any random employee to create one from whatever internal version they happen to have - "Here, try this and see if it helps...")

Firmware downgrades work just fine. There's a matching "/rigol/do_update.sh" if you want to see the process, it's just "kill all the running tasks then tar -xvf and reboot"

Having said that: The trick is not to rush to install it on day 1. Let others find out for you... 

[Randy222]

So, I would like to get a summary, correct me if I am wrong here.

The newer FW's perhaps 01.02.00.01 and beyond (please verify the version that changes things) uses different key data methods for license keys. So, this means license keys generated prior to this FW version won't work?

That leads me to these questions:

1) If you upgrade to the latest FW, you'll need to somehow get new license/options keys from Rigol? (for those who bought options)? This process works how? Do you just email them, is there some user portal you goto?
2) Can you still generate options-lics using the poted rigol tool using the new "key data" file from the new FW's ?

[AndyBig]

So, I would like to get a summary, correct me if I am wrong here.

The newer FW's perhaps 01.02.00.01 and beyond (please verify the version that changes things) uses different key data methods for license keys. So, this means license keys generated prior to this FW version won't work?

That's right.

That leads me to these questions:

1) If you upgrade to the latest FW, you'll need to somehow get new license/options keys from Rigol? (for those who bought options)? This process works how? Do you just email them, is there some user portal you goto?
2) Can you still generate options-lics using the poted rigol tool using the new "key data" file from the new FW's ?

1) Only owners of licensed options can answer this
2) No, options that work for the latest firmware cannot yet be generated using this new RKey.data file.

[Fungus]

1) If you upgrade to the latest FW, you'll need to somehow get new license/options keys from Rigol? (for those who bought options)? This process works how? Do you just email them, is there some user portal you goto?

I don't think Rigol has sold options for these yet.

Maybe they're about to start selling them, hence this change...

(They'll have to be cheap though, otherwise people will simply buy a DHO900...  )

[Randy222]

Who would buy options if the latest FW is still very buggy?
1st step for Rigol is, fix the issues and release a stable FW.

[Fungus]

Who would buy options if the latest FW is still very buggy?
1st step for Rigol is, fix the issues and release a stable FW.

What's "unstable" about it? I've never seen the slightest instability.

Edit: And bugs are very few and no showstoppers, just a handful of annoyances with simple workarounds.

(ie. Nothing like "decoding doesn't work" or anything like that, more like "it doesn't remember a certain setting if I power it off and on again" level of bug)

[Martin72]

1st step for Rigol is, fix the issues and release a stable FW.

Even after the first firmware update, my rigol no longer crashed - at least that's what I mean by "stable" firmware.

[Randy222]

1st step for Rigol is, fix the issues and release a stable FW.

Even after the first firmware update, my rigol no longer crashed - at least that's what I mean by "stable" firmware.

I meant stable, as in when you advance a FW version it reduces bugs and/or does not bring back old bugs and/or does not introduce new bugs.

I don't see any new feature in 01.02.xx.xx FW's, only a changelog file that says "fix this" "fix that".
Perhaps I missed it, has there been any Rigol fix for the FFT issue?

All he features/specs per model number, should be working 100% bug free. The bug list should become reduced with each new FW released.

800 is a bit less complicated than the 900 series, but same principles still apply.

[Martin72]

No scope model in this world is or will ever be 100% bug-free.
What's more, it's a very inexpensive scope - you can't expect the development department to sit down and fix every annoying bug, the budget isn't there for that.
With bugs, a distinction must be made between functionally relevant and just "annoying" bugs.
Rigol and other manufacturers will generally ensure that their cheap products are stable, anything else is more of a bonus.
I wouldn't want to get my hopes up with the FFT.
The bug with the faulty window coefficients has been around forever and the lack of features such as average and peak hold will probably not be rectified either, as even the largest scope, the Stationmax , only has rudimentary FFT features.
As of now the scope is stable and has some nice new features, if you want something else you have to buy a scope somewhere else.

[S2084]

I think it turned out quite neatly. (LA port)

[ebastler]

Looks nice and tidy!

So, does the LA fully work without the extra RAM installed on the main board, or did you add that too? (Has it ever been clarified what that extra RAM is for -- LA, AWG or something else?)

[gabiz_ro]

Just populating those missing RAM chips will not be enough.
Android OS must be aware of this and is not like a config file where you declare available RAM.
I think is on bootloader stage or preloader maybe.
So we need to find a way to extract all from sdcard not what is found until now and compare between models with more or less RAM

One quick test method will be to put an sdcard image on card from model with more RAM in one with less it may work but who know if OK or not work at all.

[ebastler]

How do you know that thus RAM is under Android OS control? Is that known?

[S2084]

Yes, obviously LA works without installing additional memory... Unfortunately, I can’t check its operation yet, due to the lack of an LA adapter, as soon as I get one, I’ll definitely check everything.  At the moment I am emulating the connection of an LA adapter by connecting the two rightmost pins of the LA connector (pin detect + pin gnd).  In any case, I will install additional memory, I assume that next week the two SKhynix H5TQ2G63FFR memory chips I ordered will arrive to me, they will be immediately installed on the board.  I will show the entire installation process with all the checks and measurements of all voltages and signals on the installed chips in a video on my YouTube channel https://youtube.com/@stepan.koshman

[S2084]

I'm sure this is not true!... This memory is not used in android os!... it is needed for FPGA.

[gabiz_ro]

Will be usefull if someone with model with more RAM will post some hardware info gathered by some hardware info software.
Then we can compare with less RAM models hardware info.

Indeed, looks like this is used by Xilinx chip.