This all sounds so lame it must be intentional Even pricing-wise the base 70 MHz model is more expensive than Keysight DSOX1000. Hackability as a marketing feature
I wouldn't be surprised! That's where EEVBLOG does a wonderful (and totally free) job for these manufacturers.
I wouldn't be surprised! That's where EEVBLOG does a wonderful (and totally free) job for these manufacturers.
To be honest at first I wanted to pull the trigger on this Rigol, but the logic probe wasn't in stock anywhere (Batterfly/Batronix et al) and also I was worried the FW is crap, which we now know from Dave's video it is.
So without the hack I would end up with the most overpriced 70 MHz scope with crappy FW and even with the hack it would be crappy, probably even more bugs in the unlocked functionalities. Also lack of 50 Ohm kind of put me off.
Crosschecking with brainstorm "special" information, those who want a flavor of the MSO5000 files can look at this
msg.
They shouldn't be much different.
Don't take rigol for SuperSmart. 3 years ago my looking into the DS2000 revealed they are SuperDumb. Look up my "Project Yaigol" post for details. Stealing from each other and blind copying without understanding how it is supposed to work seems to be a norm in that"industry".
root:$1$qC.CEbjC$SVJyqm.IG.gkElhaeM.FD0:0:0:root:/root:/bin/sh
user: root
pass: root
I can now confirm that the super secret password for the Rigol 5000 series oscilloscope is: root
With an open SSH interface and the password for the root account getting access to the file system became very easy.
login as: root
root@192.168.2.134's password:
<root@rigol>cd /
<root@rigol>df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 31.0M 21.9M 9.1M 71% /
devtmpfs 213.6M 0 213.6M 0% /dev
none 100.0M 284.0K 99.7M 0% /tmp
/dev/ubi6_0 85.1M 69.6M 15.6M 82% /rigol
/dev/ubi1_0 37.2M 276.0K 35.0M 1% /rigol/data
/dev/ubi12_0 516.6M 67.3M 444.6M 13% /user
<root@rigol>ls
bin home lost+found proc sys usr
checkapp lib media rigol tmp var
dev licenses mnt root ubifs-util
etc linuxrc opt sbin user
<root@rigol>
I have now extracted the 66.7 MB firmware.gel file from the oscilloscope.
Can you get me a memdump? /dev/mem
I will try to dump the memory
I think I am going to need some help with the RAM dump since Linux have made copying the RAM more difficult in newer versions.
For those playing along at home the scope report the Linux version as “3.12.0-xilinx”
Any suggestions how to dump the RAM over SSH?
I think I am going to need some help with the RAM dump since Linux have made copying the RAM more difficult in newer versions.
For those playing along at home the scope report the Linux version as “3.12.0-xilinx”
Any suggestions how to dump the RAM over SSH?
Can't you insert the USB drive and execute "cp /dev/mem" to the USB drive? Don't worry if it gives you an error as long as it copies something "big".
BTW, what is the FW version of your scope?
I completely forgot that the scope had a USB port. How nice of Rigol to give us an open SSH interface, simple password and a convenient USB port. It is almost like they have rolled out the red carpet for us.
The scope reports FW version 00.01.01.02.03
Im quite suprized. They certainly dont' seem to have made too much effort 'so far' to secure things.
With a little bit of work I got a 448 MB memory dump
I completely forgot that the scope had a USB port.
It's the problem with these advanced equipments that should only be connected to the internet! They also have USB interface... beware SEC Consult!
I completely forgot that the scope had a USB port.
It's the problem with these advanced equipments that should only be connected to the internet! They also have USB interface... beware SEC Consult!
LOL. Yeah another one security risk that will end the world...
Im quite suprized. They certainly dont' seem to have made too much effort 'so far' to secure things.
Why? A large part of their business is built on hacking.
I bet sales of the DS1054Z paid for a lot of the development of that ASIC.
Indeed, there are a ton of similarities with that post against what I did a few days ago, thanks for sharing @tv84
Im quite suprized. They certainly dont' seem to have made too much effort 'so far' to secure things.
Why are you surprised? According to Dave a lot of functionality needs at least some attention. Securing things usually is last on the list. Get the product out first. Rigol can always choose to plug holes in later firmware releases if necessary.
Indeed, there are a ton of similarities with that post against what I did a few days ago, thanks for sharing @tv84
So, cfger is indeed the encryptor/decryptor of the shell scripts. It uses AES encryption.
<root@rigol>./cfger -h
-r name:read the value of name
-i file:read model,version,date to file
-c name value: compare bwtween the value of name with value
-s name value: set the value of name
-t file: remove the all zero of the file
-d input output: decrypt the input to output by aes
-e input output: crypt the input to output by aes
-h : show this help information
Enjoy:
.data:000196D4 AES_KEY DCD 0xFECFD8BA ; DATA XREF: sub_B174+34o
.data:000196D8 dword_196D8 DCD 0xC4B5AABB
.data:000196DC dword_196DC DCD 0xBFD4D8C3
.data:000196E0 dword_196E0 DCD 0xDDBEFDCA
Any idea why scripts are encrypted. I'm assuming that they have to be decrypted before they are executed?
Indeed, there are a ton of similarities with that post against what I did a few days ago, thanks for sharing @tv84
So, cfger is indeed the encryptor/decryptor of the shell scripts. It uses AES encryption.
<root@rigol>./cfger -h
-r name:read the value of name
-i file:read model,version,date to file
-c name value: compare bwtween the value of name with value
-s name value: set the value of name
-t file: remove the all zero of the file
-d input output: decrypt the input to output by aes
-e input output: crypt the input to output by aes
-h : show this help information
Enjoy:
.data:000196D4 AES_KEY DCD 0xFECFD8BA ; DATA XREF: sub_B174+34o
.data:000196D8 dword_196D8 DCD 0xC4B5AABB
.data:000196DC dword_196DC DCD 0xBFD4D8C3
.data:000196E0 dword_196E0 DCD 0xDDBEFDCA
Here are the 2 scripts decrypted with AES-CBC.
AES_KEY: BAD8CFFEBBAAB5C4C3D8D4BFCAFDBEDD
What would be interesting to know, is if the AES_KEY is the same for all machines, or if each one is unique.
I'm curious as to why Rigol went to the effort of encrypting these scripts, but then left the AES key 'lying around'. That is odd.
Looking at these scripts, they essentially just check that some files are valid, ( Checking a CRC ) and then copying them to an appropriate place.. Its useful perhaps to know where the files are copied to, but i'm wondering if theres anything else to learn from that...
Im quite suprized. They certainly dont' seem to have made too much effort 'so far' to secure things.
Why? A large part of their business is built on hacking.
I bet sales of the DS1054Z paid for a lot of the development of that ASIC.
Majority of income comes from sales of units to education and large organisations don't care about the hack.