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 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 also has three more trigger types than the HDO1000 and three more protocol decoding options.
&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;
};
};
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
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.
keys leak because someone didn't pay attention...
For sure Rigol's marketing and sales departments knows about the stuff hobbyists do with their equipment.
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!
any guesses for the ssh password?
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
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
setenv bootargs console=ttyS1,115200 console=tty0 root=PARTUUID=${uuid} rw rootwait smsc95xx.macaddr="${usbethaddr}"
Is it allowed here to publicly look at the decompiled dts text file?
none of them
would have been to easy
but i does ask for a password so I'm guessing password auth is not deactivated