Hacking the HDO1k/HDO4k Rigol 12 bit scope

[Bud]

There's two possibilities here:

a) Rigol used Android's secure boot mechanism to really lock down the firmware and made it very difficult to root/hack.

b) They've said "We'll make a hackable device and let the hackers believe they're fooling us". It's better to only make $100 than have them buy from somebody else.

They've done (b) for a long time now, let's hope this one doesn't bring a change of policy.

It is absurd to say a technology company would intentionally make a hackable device. If that was the case, the hackability would become an engineering Requirement throughout the device's technical documentation, engineering and code writing resources assigned to it, Managers would know about it, Marketing would know about it and would need to perform acrobatics to market it without actually naming it or admitting it exists, support teams would be required to support it, development teams required to NOT harm it and maintain when releasing firmware updates, reports made on its usability and performance, etc etc etc. It is ridiculous to think any company would be involved in this type of conspiracy.

[bob808]

Here's some info regarding RK3399 and Android, and some tools/procedures for flashing it.
http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_RK3399
And from Pine64:
https://wiki.pine64.org/wiki/RK3399_boot_sequence

Might be useful info in there.

edit: also maybe tools like this one: https://github.com/nccgroup/depthcharge
this gets more complicated as you'd need to fuss around with getting a uboot shell and probing around to see the boot configuration/parameters etc.
RK3399 does seem to default to 1500000 baud.
still curious about flash storage chip. maybe on the backside of the pcb?

2nd edit: if running u-boot then /boot partition should have the device tree blob file which can be decompiled into a text dts file and that contains the non-discoverable hardware information. very important file. also quite interesting comparing the one from HDO1K and HDO4K. so dumping boot.img would be very useful.
here's two examples for RK3399:
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
https://gist.github.com/ayufan/fe8172e4f63d8bd01ac2abc182d7aebc
theoretically it could be possible that the application software enables features based on the hardware defined in the dts file. replacing/adapting the dts file on HDO1K might enable HDO4K features in the app. this could could be a way to differentiate between the two models.

[Fungus]

It is absurd to say a technology company would intentionally make a hackable device. If that was the case, the hackability would become an engineering Requirement throughout the device's technical documentation, engineering and code writing resources assigned to it, Managers would know about it, Marketing would know about it and would need to perform acrobatics to market it without actually naming it or admitting it exists, support teams would be required to support it, development teams required to NOT harm it and maintain when releasing firmware updates, reports made on its usability and performance, etc etc etc.

LOL! 

Or... you could just have a quiet word with the guy who does the license code generator to make sure it isn't very difficult to crack, eg. Riglol, and everything else will "just work" - nobody's allowed to touch the license code system.

[EEVblog]

It is absurd to say a technology company would intentionally make a hackable device. If that was the case, the hackability would become an engineering Requirement throughout the device's technical documentation, engineering and code writing resources assigned to it, Managers would know about it, Marketing would know about it and would need to perform acrobatics to market it without actually naming it or admitting it exists, support teams would be required to support it, development teams required to NOT harm it and maintain when releasing firmware updates, reports made on its usability and performance, etc etc etc. It is ridiculous to think any company would be involved in this type of conspiracy.

It's easy to simply be sloppy with protection.
In fact it requires extra engineering effort and hence expense to make a product more secure than not. No need for a grand documented and planed conspiricy at every level of the company.
Or simply do nothing when an exploit is found. Do nothing is pretty easy to do and require zero company resources 

[Martin72]

It also has three more trigger types than the HDO1000 and three more protocol decoding options.

Basically it has the same amount of trigger types.
What it not got are the optional triggers according to the optional decoding types.

CAN-FD, Flexray, LIN, I2S and MIL-1553 are the five optional decoders the hdo1000 didn´t got.

[bob808]

Yeah they'd have costs with keeping up with security. They can give it a low priority.
Curious if secure boot is enabled. If that could be bypassed it could open some possibilities. 

Here's a snippet from the RK3399 firefly board dts file:

Code: [Select]

&i2c0 {
clock-frequency = <400000>;
i2c-scl-rising-time-ns = <168>;
i2c-scl-falling-time-ns = <4>;
status = "okay";

rk808: pmic@1b {
compatible = "rockchip,rk808";
reg = <0x1b>;
interrupt-parent = <&gpio1>;
interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
#clock-cells = <1>;
clock-output-names = "xin32k", "rk808-clkout2";
pinctrl-names = "default";
pinctrl-0 = <&pmic_int_l>;
rockchip,system-power-controller;
wakeup-source;

vcc1-supply = <&vcc_sys>;
vcc2-supply = <&vcc_sys>;
vcc3-supply = <&vcc_sys>;
vcc4-supply = <&vcc_sys>;
vcc6-supply = <&vcc_sys>;
vcc7-supply = <&vcc_sys>;
vcc8-supply = <&vcc3v3_sys>;
vcc9-supply = <&vcc_sys>;
vcc10-supply = <&vcc_sys>;
vcc11-supply = <&vcc_sys>;
vcc12-supply = <&vcc3v3_sys>;
vddio-supply = <&vcc1v8_pmu>;

regulators {
vdd_center: DCDC_REG1 {
regulator-name = "vdd_center";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <750000>;
regulator-max-microvolt = <1350000>;
regulator-ramp-delay = <6001>;
regulator-state-mem {
regulator-off-in-suspend;
};
};

vdd_cpu_l: DCDC_REG2 {
regulator-name = "vdd_cpu_l";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <750000>;
regulator-max-microvolt = <1350000>;
regulator-ramp-delay = <6001>;
regulator-state-mem {
regulator-off-in-suspend;
};
};

vcc_ddr: DCDC_REG3 {
regulator-name = "vcc_ddr";
regulator-always-on;
regulator-boot-on;
regulator-state-mem {
regulator-on-in-suspend;
};
};
Uses the same RK808 power management chip. I think changing stuff in this file affects for example potential enable lines on certain hardware, if any.

[2N3055]

It is absurd to say a technology company would intentionally make a hackable device. If that was the case, the hackability would become an engineering Requirement throughout the device's technical documentation, engineering and code writing resources assigned to it, Managers would know about it, Marketing would know about it and would need to perform acrobatics to market it without actually naming it or admitting it exists, support teams would be required to support it, development teams required to NOT harm it and maintain when releasing firmware updates, reports made on its usability and performance, etc etc etc. It is ridiculous to think any company would be involved in this type of conspiracy.

It's easy to simply be sloppy with protection.
In fact it requires extra engineering effort and hence expense to make a product more secure than not. No need for a grand documented and planed conspiricy at every level of the company.
Or simply do nothing when an exploit is found. Do nothing is pretty easy to do and require zero company resources 

Right on the money...

Implementing security framework is expensive. And also slows things down. You add several layers of complications to almost every procedure and step.. And you cannot do it half way. If not done right, you spend money and resources, but keys leak because someone didn't pay attention...

[hans]

There's two possibilities here:

a) Rigol used Android's secure boot mechanism to really lock down the firmware and made it very difficult to root/hack.

b) They've said "We'll make a hackable device and let the hackers believe they're fooling us". It's better to only make $100 than have them buy from somebody else.

They've done (b) for a long time now, let's hope this one doesn't bring a change of policy.

It is absurd to say a technology company would intentionally make a hackable device. If that was the case, the hackability would become an engineering Requirement throughout the device's technical documentation, engineering and code writing resources assigned to it, Managers would know about it, Marketing would know about it and would need to perform acrobatics to market it without actually naming it or admitting it exists, support teams would be required to support it, development teams required to NOT harm it and maintain when releasing firmware updates, reports made on its usability and performance, etc etc etc. It is ridiculous to think any company would be involved in this type of conspiracy.

Making it a requirement is 1 step further than being sloppy. Basically all problem escalations have 3 options: do nothing and see how the problem continues to develop (probably worsen). Spend max effort to fix the problem. Or spend max effort to make the problem 'worse'.

All 3 have intent to some degree. Let's not forget that western and asian companies sometimes have cultures and standards to what is generally accepted. Western companies are very IP protective, while we have seen dozens of STM32 clones and whatnot from China.

For sure Rigol's marketing and sales departments knows about the stuff hobbyists do with their equipment. But for the 3-way junction I just mentioned, the outcome could also be: we sell 2 min-spec units that get hacked (say 2x 1000$ cashflow, 2x 500$ profit), sell 1 max-spec unit (1800$ cashflow, 1300$ profit), or potentially sell nothing at all (0$ cashflow, and 0$ profit). If you then the likelihood into account of which scenario is most likely  to will occur, then it may very well be it's a "strategy" to not protect this very well. However, potentially there is protection in place between different lines of products. However as Fungus rightly pointed out: companies aren't going to bother with hacks. So Rigol's pretty safe to ask 3000$ for an entry level model HDO4k, even if it's built on a shared hardware platform with the HDO1k.

Also don't forget that these hacks drive an enormous amount of enthusiasm for a brand, also for people that don't actually need this level of functionality (as discussed recently).. creating lots of hype for a more expensive series because it can be hacked!.

[Fungus]

keys leak because someone didn't pay attention...

Or sometimes because they were 'leaked' on purpose.

Like iPhone prototypes 0that mysteriously get left behind in coffee shops where journalists hang out a few days before the "official" launch.

[Fungus]

For sure Rigol's marketing and sales departments knows about the stuff hobbyists do with their equipment.

Of course Rigol knows about hacking, they even make DS1000Z models that can't be easily hacked so that people can't get free AWGs (ie. all the "Plus" models).

(nb. They can be hacked but you need to open them up and do JTAG things to them, so hardly anybody does it)

Anybody who thinks that hacking isn't condoned/planned by Rigol is living in a dream.

Also there is a fact that I know a bit about how these things are designed and what is and what isn't possible.
....
Implementing security framework is expensive. And also slows things down. You add several layers of complications to almost every procedure and step.. And you cannot do it half way. If not done right, you spend money and resources, but keys leak because someone didn't pay attention...

Ok, please enlighten us as to how it's possible that some Rigol models have good protection and others don't.

Rigol obviously has the "expensive/slow/complicated" framework in place, and it's a system which has no "key" to leak! 

[2N3055]

Ok, please enlighten us as to how it's possible that some Rigol models have good protection and others don't.

Rigol obviously has the "expensive/slow/complicated" framework in place, and it's a system which has no "key" to leak! 

I see, there is misunderstanding.

I'm not contesting an outcome. Some products are easier and some are harder to hack. Even from same manufacturer.

What is being discussed here is a motive.

What you propose is a deliberate plan to use hacking as a marketing strategy.
And I'm telling you it is much simpler than that.

First manufacturers would be VERY happy that nobody hack any scopes and if they would, pretty please, all pay full price for them. I assure you of that.

But products come with different target market in mind. There is hobby market where lowest price is 90% of decision.
And profit margins are tight. So if adding security will increase price even a little bit, they have a choice to make: not to secure it and risk that they will sell mostly the one they make least money from as people will hack it, or they do secure it, but price is a little bigger, and people buy less of least expensive ones (because starting price is more now) and maybe they will sell more of more expensive ones. So if design is such they lower cost as much so can afford to sell the cheapest model and still make money, that is what they do. And if someone also buy legally higher models that is the cream on top.

This long paragraph means: there are products where hacking can be tolerated. There is the whole market segment there. Securing it would mean more cost and disturbance is sales. So they leave it alone. But it is not some strategy that was devised upfront by Machiavelli.  Just capitalism and consequences of that.

As you go up the food chain, there are products that are at the very margin what hobby users can buy, and also beginning of pro range.. There manufacturers still have same decision, and here we know companies won't hack anything and hobby users that would are few. So also no need to optimize.

As you go higher anti hacking makes even less sense because companies don't hack and average Joe won't buy it.

Securing devices makes more sense in pure security context than as an anti hacking measure. Namely, many companies, for security reasons might want a guarantee firmware is original and that no malware is loaded into it. Such stuff. So secure bootloaders, signed images etc. But devices like that come with price tag that can bear that cost.

I hope I explained it well enough.

[dschiedsch]

Hello
After receiving my brand new HDO4204 I started with a little portscan on the ethernet port:

HTTP                 RIGOL Web Control
FTP                   BusyBox ftpd D-Link DCS-932L IP-Cam camera
Port 21 (TCP)    BusyBox ftpd D-Link DCS-932L IP-Cam camera
Port 22 (TCP)    OpenSSH 7.1 protocol 2.0
Port 80 (TCP)
Port 111 (TCP)  rpcbind
Port 5555 (TCP)

ssh is password protected

USB enumerates as IVI device

any guesses for the ssh password?

[Kahooli]

root, orangepi
root, rigol
root, android

Though if I were them I would have tossed an SSH key on there and turned off password auth in config.

[dschiedsch]

none of them
would have been to easy
but i does ask for a password so I'm guessing password auth is not deactivated

[Kahooli]

true, or you'd probably get the standard message Permission denied (publickey).

[Fungus]

any guesses for the ssh password?

CPU is a Rockchip so try 

user: root   
password: rockchip

[bob808]

You could try a dictionary based attack on ssh but you'd need a dictionary that might contain the password. you could generate your own but I wouldn't. unless they used a password that can be found in some password collection/dictionary then you're going to spend a lot of time trying to guess it.

If you can interrupt uboot at startup then there could be interesting info here:
https://cybergibbons.com/hardware-hacking/recovering-firmware-through-u-boot/

The button above the cpu might interrupt uboot but this would need to be checked. LCD might reveal some info this way. or attached monitor on HDMI port.
Also the serial port that Dave probed comes from the CPU (seems to) so that might be interesting to play with. I'd try different baud rates to see if the second part of the boot reveals some info. seems to start at 1.5meg then switch to something else in later stages of the boot. this makes sense since rk3399 defaults to 1.5meg.
Playing with that button while looking at the serial monitor might allow to do stuff. Putty I think supports 1.5meg baud 

edit: 
there's also this interesting bit of info from Dave's posted log:

Code: [Select]

SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit read PBA: 0x1404
SecureInit read PBA: 0x1804
SecureInit read PBA: 0x1c04
SecureInit ret = 0, SecureMode = 0 

securemode=0 seems promising but I have no clue if that means that indeed secure boot is off.

2nd edit:
If you look at the uboot log here:
https://forum.armbian.com/topic/17470-failing-to-boot/
There's some interesting info we could extract. Right where Dave's log stops and the \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 characters start to appear the other user's log continues with this:

Code: [Select]

U-Boot 2020.07-armbian (Nov 27 2020 - 21:56:51 +0100)
SoC: Rockchip rk3399
Reset cause: POR
DRAM:  3.9 GiB
PMIC:  RK808
SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
MMC:   mmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment
In:    serial
Out:   serial
Err:   serial
Model: Helios64
Revision: 1.2 - 4GB non ECC
Net:   eth0: ethernet@fe300000
scanning bus for devices...
Hit any key to stop autoboot:  0
If you get to the second part of the boot with correct baud rate you might be able to stop autoboot.

[2N3055]

Err:   serial
Model: Helios64
Revision: 1.2 - 4GB non ECC


https://wiki.kobol.io/helios64/hardware/

[bob808]

SecureMode = 0 is from Dave's log. The Helios64 log is an example to show what Dave should see on the serial monitor with the correct baud rate, in the second part of the boot where now he gets  \0\0\0\0\0\0\0\0\0\
In that part there's the possibility of interrupting autoboot which would give him a uboot shell. But that's possible by setting the correct baud rate, whatever that is in the case of these oscilloscopes.

[pmaster]

U-Boot, Linux/Android Kernel and possibly BussyBox (based on fingerprint/banner grabbing of port scan) are all GPL licensed component. So the sources need to be made available.
Couldn't and source release for those scopes on Rigols website.
Is there any open source acknowledge delivered with the scopes? (either on paper or digital?)

BTW: having different baud rates on first stage, second sage bootloader and Linux Kernel is not so uncommon. So sharing the full Saleae traces would be awesome.

[bob808]

Yes I was looking at the uboot files for raspberry pi 4 and there's a boot.txt file which contains this line:

Code: [Select]

setenv bootargs console=ttyS1,115200 console=tty0 root=PARTUUID=${uuid} rw rootwait smsc95xx.macaddr="${usbethaddr}"

So baud could be changed at boot. Based on the configuration from this text file there's a script to build the uboot binary file.
I'm really curious about that device tree blob file. Is it allowed here to publicly look at the decompiled dts text file?

[tv84]

Is it allowed here to publicly look at the decompiled dts text file?

Should we use a dark room?    In the past I've posted some parsed .DTS here in the forum.

[bob808]

Some are public info, like the ones I linked a few posts back. But if Rigol didn't make it public yet and it's theoretically their info. They had to build that file according to the hardware setup of the oscilloscope. So that's why I'm asking.

[thm_w]

none of them
would have been to easy
but i does ask for a password so I'm guessing password auth is not deactivated

SSH password for MSO5000 was Rigol201
But DG800 (codeword sardine) used different ones, eg: sardine_uboot

I'm not sure what the codeword for this scope series is, "Centaurus" was mentioned, although that is the name of the ASIC too. Could be some sort of puffin.

[dschiedsch]

I have a saleae logic analyzer and am willing to open the scope to get a probe of the serial interface.
Should have some time the following days.
Will post an update if I get something.