Hacking the Rigol MSO5000 series oscilloscopes

[TopLoser]

Help? Been there done that....

rigol-uboot>bollocks
Unknown command 'bollocks' - try 'help'
rigol-uboot>help
Invalid input(hxh)

LOL they removed the 'help' command to make the binary smaller (or remove it to please the user lol)

ok, so then i'll just have to get the info from an older u-boot manual.
until now, i had to do all this from memory :p

I just went though a list of 'standard uboot commands and quite a few work as expected. BDINFO and VERSION churn out some info, but HELP and PRINTENV are very much absent.

[tv84]

So, the zynq.bit parsing is below:

Code: [Select]

00000000 - FFFFFFFF             Padding
00000004 - FFFFFFFF             Padding
00000008 - FFFFFFFF             Padding
0000000C - FFFFFFFF             Padding
00000010 - FFFFFFFF             Padding
00000014 - FFFFFFFF             Padding
00000018 - FFFFFFFF             Padding
0000001C - FFFFFFFF             Padding
00000020 - 000000BB             Bus width auto detect, word 1
00000024 - 11220044             Bus width auto detect, word 2
00000028 - FFFFFFFF             Padding
0000002C - FFFFFFFF             Padding
00000030 - AA995566             Sync Word (BPI/SPI Mode)
00000034 - 20000000             T1 - 00000000  NOP      (1x)
00000038 - 30022001 00000000    T1 W 00000001  TIMER
00000040 - 30020001 00000000    T1 W 00000001  WBSTAR
00000048 - 30008001 00000000    T1 W 00000001  CMD      NULL - No Operation
00000050 - 20000000             T1 - 00000000  NOP      (1x)
00000054 - 30008001 00000007    T1 W 00000001  CMD      RCRC - Reset CRC
0000005C - 20000000             T1 - 00000000  NOP      (2x)
00000064 - 30026001 00000000    T1 W 00000001  FALL_EDGE
0000006C - 30012001 02003FE5    T1 W 00000001  COR0
00000074 - 3001C001 00000000    T1 W 00000001  COR1
0000007C - 30018001 0373B093    T1 W 00000001  IDCODE
00000084 - 30008001 00000009    T1 W 00000001  CMD      SWITCH - Switch CCLK Frequency
0000008C - 20000000             T1 - 00000000  NOP      (1x)
00000090 - 3000C001 00000401    T1 W 00000001  MASK
00000098 - 3000A001 00000501    T1 W 00000001  CTL0
000000A0 - 3000C001 00000000    T1 W 00000001  MASK
000000A8 - 30030001 00000000    T1 W 00000001  CTL1
000000B0 - 20000000             T1 - 00000000  NOP      (8x)
000000D0 - 30002001 00000000    T1 W 00000001  FAR
000000D8 - 30008001 00000001    T1 W 00000001  CMD      WCFG - Write Config Data
000000E0 - 20000000             T1 - 00000000  NOP      (1x)
000000E4 - 30004000             T1 W 00000000  FDRI
000000E8 - 500D621C             T2 W 000D621C
00358964 - 20000000             T1 - 00000000  NOP      (2x)
0035896C - 30008001 0000000A    T1 W 00000001  CMD      GRESTORE - Pulse GRESTORE Signal
00358974 - 20000000             T1 - 00000000  NOP      (1x)
00358978 - 30008001 00000003    T1 W 00000001  CMD      DGHIGH/LFRM - Last Frame Write
00358980 - 20000000             T1 - 00000000  NOP      (100x)
00358B10 - 30008001 00000005    T1 W 00000001  CMD      START - Begin Startup Sequence
00358B18 - 20000000             T1 - 00000000  NOP      (1x)
00358B1C - 30002001 03BE0000    T1 W 00000001  FAR
00358B24 - 3000C001 00000501    T1 W 00000001  MASK
00358B2C - 3000A001 00000501    T1 W 00000001  CTL0
00358B34 - 30000001 E3AD7EA5    T1 W 00000001  CRC
00358B3C - 20000000             T1 - 00000000  NOP      (2x)
00358B44 - 30008001 0000000D    T1 W 00000001  CMD      DESYNC - Reset DALIGN Signal
00358B4C - 20000000             T1 - 00000000  NOP      (400x)

The IDCODE = 0373B093 corresponds to the Xilinx Zynq-7015. The same as in the DS7000.

The decrypted scripts (CORRECTED) are attached. In order to correctly decrypt them, we must set the IV = AES_KEY.

Code: [Select]

<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
The file /tmp/env.bin is protected by a CRC-32 (ISO-HDLC) in it's first 4 bytes. cfger tests this CRC before doing anything.

PS: To those who already downloaded the scripts, sorry. Must download again.

[photon]

For the record, this scope is not being hacked. It is currently open as Rigol currently wishes. Change the title from "Hacking" to "EEVblog Promoting". Nothing is free.

[oliv3r]

I'm sorry I wasn't clear, but they are two commands
so

Code: [Select]

setenv bootdelay 3
followed by

Code: [Select]

save
without the save, nothing happens. You basically just set the bootdelay variable to read '3 save' and after a reboot it's gone (reset, without the save)

Ok cool... well it made no difference so I tried the Linux way:

Code: [Select]

/rigol/tools/cfger -s "bootdelay 5"
flash_eraseall /dev/mtd0
nandwrite -p /dev/mtd0 /tmp/env.bin

That made no difference either, countdown is still instantaneous.

Hmm, I doubt cfgver is checking anything in that file, like filtering bootdelay, so it could be, that they removed it from the binary.

In any case, we _can_ get in if needed, so that's a win. I am curious that, next time your in u-boot, what "echo $bootdelay" will say. It should yield the 5 you saved, if not, we did something wrong with the cfgver tool (or whatever it was, I forget)

[oliv3r]

Would it be possible to hack it so it boots faster?

I mean, what's it doing for a whole minute? That's an eternity.

At some point, I do see a few 'useless' things that can be sped up if done in parallel (some tasks in the scripts say cost 8s for example)

That said, they are using a QT stack on a relative slow CPU, so that won't go much faster, and any init the application (the GUI) does, well we can't speed that up without the source code

[oliv3r]

Help? Been there done that....

rigol-uboot>bollocks
Unknown command 'bollocks' - try 'help'
rigol-uboot>help
Invalid input(hxh)

LOL they removed the 'help' command to make the binary smaller (or remove it to please the user lol)

ok, so then i'll just have to get the info from an older u-boot manual.
until now, i had to do all this from memory :p

I just went though a list of 'standard uboot commands and quite a few work as expected. BDINFO and VERSION churn out some info, but HELP and PRINTENV are very much absent.

Its just bizare that they disabled printenv ... or help. It may be that in old u-boot versions it was a subcommand of 'env' so 'env print' but even so ... it just makes our job a little harder, not impossible The first thing I need to do is cook up a new dtb that exposes the SPI flash memory to linux

[oliv3r]

So, the zynq.bit parsing is below:

Code: [Select]

00000000 - FFFFFFFF             Padding
00000004 - FFFFFFFF             Padding
00000008 - FFFFFFFF             Padding
0000000C - FFFFFFFF             Padding
00000010 - FFFFFFFF             Padding
00000014 - FFFFFFFF             Padding
00000018 - FFFFFFFF             Padding
0000001C - FFFFFFFF             Padding
00000020 - 000000BB             Bus width auto detect, word 1
00000024 - 11220044             Bus width auto detect, word 2
00000028 - FFFFFFFF             Padding
0000002C - FFFFFFFF             Padding
00000030 - AA995566             Sync Word (BPI/SPI Mode)
00000034 - 20000000             T1 - 00000000  NOP      (1x)
00000038 - 30022001 00000000    T1 W 00000001  TIMER
00000040 - 30020001 00000000    T1 W 00000001  WBSTAR
00000048 - 30008001 00000000    T1 W 00000001  CMD      NULL - No Operation
00000050 - 20000000             T1 - 00000000  NOP      (1x)
00000054 - 30008001 00000007    T1 W 00000001  CMD      RCRC - Reset CRC
0000005C - 20000000             T1 - 00000000  NOP      (2x)
00000064 - 30026001 00000000    T1 W 00000001  FALL_EDGE
0000006C - 30012001 02003FE5    T1 W 00000001  COR0
00000074 - 3001C001 00000000    T1 W 00000001  COR1
0000007C - 30018001 0373B093    T1 W 00000001  IDCODE
00000084 - 30008001 00000009    T1 W 00000001  CMD      SWITCH - Switch CCLK Frequency
0000008C - 20000000             T1 - 00000000  NOP      (1x)
00000090 - 3000C001 00000401    T1 W 00000001  MASK
00000098 - 3000A001 00000501    T1 W 00000001  CTL0
000000A0 - 3000C001 00000000    T1 W 00000001  MASK
000000A8 - 30030001 00000000    T1 W 00000001  CTL1
000000B0 - 20000000             T1 - 00000000  NOP      (8x)
000000D0 - 30002001 00000000    T1 W 00000001  FAR
000000D8 - 30008001 00000001    T1 W 00000001  CMD      WCFG - Write Config Data
000000E0 - 20000000             T1 - 00000000  NOP      (1x)
000000E4 - 30004000             T1 W 00000000  FDRI
000000E8 - 500D621C             T2 W 000D621C
00358964 - 20000000             T1 - 00000000  NOP      (2x)
0035896C - 30008001 0000000A    T1 W 00000001  CMD      GRESTORE - Pulse GRESTORE Signal
00358974 - 20000000             T1 - 00000000  NOP      (1x)
00358978 - 30008001 00000003    T1 W 00000001  CMD      DGHIGH/LFRM - Last Frame Write
00358980 - 20000000             T1 - 00000000  NOP      (100x)
00358B10 - 30008001 00000005    T1 W 00000001  CMD      START - Begin Startup Sequence
00358B18 - 20000000             T1 - 00000000  NOP      (1x)
00358B1C - 30002001 03BE0000    T1 W 00000001  FAR
00358B24 - 3000C001 00000501    T1 W 00000001  MASK
00358B2C - 3000A001 00000501    T1 W 00000001  CTL0
00358B34 - 30000001 E3AD7EA5    T1 W 00000001  CRC
00358B3C - 20000000             T1 - 00000000  NOP      (2x)
00358B44 - 30008001 0000000D    T1 W 00000001  CMD      DESYNC - Reset DALIGN Signal
00358B4C - 20000000             T1 - 00000000  NOP      (400x)

The IDCODE = 0373B093 corresponds to the Xilinx Zynq-7015. The same as in the DS7000.

The decrypted scripts (full) are attached.

The file /tmp/env.bin is protected by a CRC-32 (ISO-HDLC) in it's first 4 bytes. cfger tests this CRC before doing anything.

That's the same bit as from the MSO7000 thread right? Nice to have it all in one place Not sure what I'm seeing in the zynq bit file, more curious as to whether its possible to do any partial reconfiguration. I know FPGA's support it, just need to know what's needed, as I desperately want to overwrite some bits (like the display unit).

As for the env.bin; a u-boot environment is a \n separated text file, usually with the .cmd extension. It's just a lit of environment variables per line. mkimage will turn this into a .bin file, where the \n's are more or less replaced with \0's and a header is prepended. Part of the header is indeed a checksum (Don't recall if the header is only the checksum).

Anyhow, they basically re-invented the wheel with their cfger, as the fw_printenv and fw_setenv tools do exactly this I think fw_printenv can even do it directly on /dev/mtd0 rather then dumping it locally and modifying it locally. Besides, they should have kept the env in the spi flash; as having it on raw nand storage (as they do now) and writing it (hopefully only during updates) is error prone. Raw flash access (via write) is not wear-leveled, no bit correction preformed etc (but u-boot can't access it otherwise, well not their ancient u-boot version).

[TopLoser]

I'm sorry I wasn't clear, but they are two commands
so

Code: [Select]

setenv bootdelay 3
followed by

Code: [Select]

save
without the save, nothing happens. You basically just set the bootdelay variable to read '3 save' and after a reboot it's gone (reset, without the save)

Ok cool... well it made no difference so I tried the Linux way:

Code: [Select]

/rigol/tools/cfger -s "bootdelay 5"
flash_eraseall /dev/mtd0
nandwrite -p /dev/mtd0 /tmp/env.bin

That made no difference either, countdown is still instantaneous.

Hmm, I doubt cfgver is checking anything in that file, like filtering bootdelay, so it could be, that they removed it from the binary.

In any case, we _can_ get in if needed, so that's a win. I am curious that, next time your in u-boot, what "echo $bootdelay" will say. It should yield the 5 you saved, if not, we did something wrong with the cfgver tool (or whatever it was, I forget)

Seems to be stuck at 1. But I can reliably get into uboot now by streaming crap at the scope at boot time.

rigol-uboot>echo $bootdelay
1

[tv84]

That's the same bit as from the MSO7000 thread right? Nice to have it all in one place

No it isn't. This one is from the MSO5000.

That means the 2 bit files should be the same in 5000 and 7000 !!!!

[oliv3r]

Seems to be stuck at 1. But I can reliably get into uboot now by streaming crap at the scope at boot time.

rigol-uboot>echo $bootdelay
1

that's interesting; as initially it is set to 0. Well I'll dig into this at some point.

Meanwhile, what do you mean with a stream of crap? I know you can set keys to allow interrupts, space is or 'c' are common. CTRL-c also tends to work to interrupt a running bootscript. Is it just random keyboard mashing; is it isolated to an area of button mashing?

[oliv3r]

That's the same bit as from the MSO7000 thread right? Nice to have it all in one place

No it isn't. This one is from the MSO5000.

That means the 2 bit files should be the same in 5000 and 7000 !!!!

I'm not surprised at that at all. I think MS07000 and MSO5000 are more or less the same platform. Not sure I understand the difference in PCB yet however ... I doubt they are using different ASIC's though; maybe yield differences for now; but then, that means if yields get better, there will be even less differences ...

[oliv3r]

<decrypted files>

They are more or less identical, except hashes and so, to the MSO7000 files. No suprise there

[TopLoser]

Meanwhile, what do you mean with a stream of crap? I know you can set keys to allow interrupts, space is or 'c' are common. CTRL-c also tends to work to interrupt a running bootscript. Is it just random keyboard mashing; is it isolated to an area of button mashing?

I just loop output back to input, that does it!

[oliv3r]

Meanwhile, what do you mean with a stream of crap? I know you can set keys to allow interrupts, space is or 'c' are common. CTRL-c also tends to work to interrupt a running bootscript. Is it just random keyboard mashing; is it isolated to an area of button mashing?

I just loop output back to input, that does it!

like shortening RX to TX? that's bizare It must be one of the character (combinations) in there. It IS possible they have set a 'password' as the any-key and it happens to be part of the input lol, like rigolee or dirty :p

[TopLoser]

Meanwhile, what do you mean with a stream of crap? I know you can set keys to allow interrupts, space is or 'c' are common. CTRL-c also tends to work to interrupt a running bootscript. Is it just random keyboard mashing; is it isolated to an area of button mashing?

I just loop output back to input, that does it!

like shortening RX to TX? that's bizare It must be one of the character (combinations) in there. It IS possible they have set a 'password' as the any-key and it happens to be part of the input lol, like rigolee or dirty :p

Scope hacked its own password, how cool is that lol

[asmi]

That's the same bit as from the MSO7000 thread right? Nice to have it all in one place Not sure what I'm seeing in the zynq bit file, more curious as to whether its possible to do any partial reconfiguration. I know FPGA's support it, just need to know what's needed, as I desperately want to overwrite some bits (like the display unit).

There seems to be a lot of myths regarding partial reconfiguration floating around, so please watch this video from Xilinx explaining what PR actually is and how it works: https://www.xilinx.com/video/hardware/partial-reconfiguration-in-vivado.html

[quix]

anyone tried logging in with firmware version 00.01.01.02.04? Build: 2018-11-09 19:49:21

i ordered the mso5074 after reading about the "hack" on hackaday. received it an hour ago, but can't log in over the lan interface & ssh...

[Fungus]

anyone tried logging in with firmware version 00.01.01.02.04? Build: 2018-11-09 19:49:21

i ordered the mso5074 after reading about the "hack" on hackaday. received it an hour ago, but can't log in over the lan interface & ssh...

What did you do to "log in"?

[quix]

IO -> lan settings -> IP
enter that ip into putty, ssh, port 22, entering root and root when asked

Code: [Select]

login as: root
root@192.168.1.109's password:
Access denied

it's connected to my home network. the webinterface of the rigol is working.

also tried termius on the iphone, same error.

[tv84]

anyone tried logging in with firmware version 00.01.01.02.04? Build: 2018-11-09 19:49:21

i ordered the mso5074 after reading about the "hack" on hackaday. received it an hour ago, but can't log in over the lan interface & ssh...

I think now the title of the thread is going to start making sense... 

Gentlemen, start your engines!

[FireBird]

Here's version 00.01.01.02.03. You could put it on a thumb drive and try to downgrade. But maybe someone else would like to try something with 1.2.4 first.

P.S.: Upload will be finished in about 10 minutes.

[wulfman]

Can an older version of firmware be loaded ?

[quix]

Here's version 00.01.01.02.03. You could put it on a thumb drive and try to downgrade. But maybe someone else would like to try something with 1.2.4 first.

P.S.: Upload will be finished in about 10 minutes.

thank you! will try and report

Nope, doesnt work. "Failed to upgrade! Check the upgrade file."

[TopLoser]

Just for kicks I connected my scope using just the serial interface.

Let it boot all the way and then I seem to have access to all the Linux commands without having to enter a username or password.

Looks like I can copy the start.sh file to USB, edit it and then copy it back into the scope.

Trying to use VI in single line mode is a nightmare!!!

[Fungus]

Just for kicks I connected my scope using just the serial interface.

Let it boot all the way and then I seem to have access to all the Linux commands without having to enter a username or password.

Looks like I can copy the start.sh file to USB, edit it and then copy it back into the scope.

Trying to use VI in single line mode is a nightmare!!!

Can you replace /etc/passwd?