Hacking the Rigol MSO5000 series oscilloscopes

[mrpackethead]

firewall log files will be interesting to look at and see what is coming and going.   You've got a device thats esssneitally open with a linux stack on it, on the inside of your network..  could be used for any number of things..

[nctnico]

Give it a manual IP and leave the gateway IP blank, it can't call home that way.

You might think that but there are several ways to generate network traffic and get the gateway anyway.

[tv84]

Just for reference.

[rgwan]

I've heard that Rigol adds High-Resolution to Acquire Mode for new firmware version. If this feature is available on your scope, Then congratulations!

I would like to post some other hack on appEntry. BTW, we have a u-boot dump without tear it down, analyzing it is little troublesome. Althrough we know how to interrupt autoboot, but how to check in u-boot it still remains a mystery.

[mrpackethead]

I've heard that Rigol adds High-Resolution to Acquire Mode for new firmware version. If this feature is available on your scope, Then congratulations!

I would like to post an SPI Flash dump on this thread and some other hack on appEntry. BTW, we have a u-boot dump without tear it down (In fact, the u-boot itself contains a command to switch between NOR and NAND Flash, because they share several pins), analyzing it is little troublesome. Althrough we know the u-boot passphrase, but how to check in u-boot it still remains a mystery.

I would suggest that you dont' post that here,   posting that probably will get you banned, however its ok, to post it somewhere else and post a link to it.     

[Rerouter]

Or better yet, rely on PM's to share it,

[oliv3r]

I've heard that Rigol adds High-Resolution to Acquire Mode for new firmware version. If this feature is available on your scope, Then congratulations!

I would like to post an SPI Flash dump on this thread and some other hack on appEntry. BTW, we have a u-boot dump without tear it down (In fact, the u-boot itself contains a command to switch between NOR and NAND Flash, because they share several pins), analyzing it is little troublesome. Althrough we know the u-boot passphrase, but how to check in u-boot it still remains a mystery.

Not sure why this information would get you banned. U-Boot is GPL software for one. Secondly the software is already being shared via the forum.

Now, what are you talking about with NAND flash and NOR flash being shared via the same pins? So lets first assume this is possible, now, u-boot SPL (or the FSBL; calling it only FSBL for now) is being read via the bootrom. The bootrom uses the BOOT_MODE pins to configure the BootROM to boot from qspi SPI NOR flash. It happily reads the FSBL into the OCM (or via XIP even) and starts to execute the FSBL. U-boot is then loaded, but has no knowledge of the QSPI flash and only has the NAND pinmux set and loads the files from NAND.

What is special here, and I'm sure they can hack this into their u-boot, is that the SPL does have QSPI support, but u-boot regular does not. Because of that, I think they are using the vivado FSBL, as doing this with plain u-boot requires some hacks, as it does not support this.

Now, looking at Table 2-4, MIO-at-a-Glance; page 52 of the Zynq-7000 TRM (UG585) we see that the QSPI pins are part of pins 2 through 13, and the nand flash is 24 through 40. So there is no overlap. Now you also speak of SRAM and NOR. Yes, the zynq can boot via NOR flash, like nand, but not SPI, parallel NOR flash. Also confusingly the zynq supports SRAM, now I know the difference between the two, but some of the texts I found make it sound like there is also NOR based SRAM, which confuses me. So I think, for now, that it's either/or.

Reason I bring this up is because there are 2 SRAM chips connected to the zynq (top 2 chips via snake-trace). So it could be that these are connected to the PS via these pins 40 - 53 or they are part of the FPGA. Can't see that yet ... and don't know what the purpose would be of this yet. I don't see any linux configuration for it (but I may have glanced over it). I strongly believe it is part of the FPGA and is used as some sort of buffering mechanism for the big data stream.

As for the extracted data, please do feel free to send it to me in a PM

Edit: I was wrong. The NAND pins are indeed shared. I was looking at, what turns to be out, just the text field which was put RIGHT of the pins. Super annoying.

This does make things more interesting.

So, while we cannot touch u-boot, but it's quite likely, that neither can rigol. As they cannot access it from linux nor u-boot due to the pin-sharing with nand.

Well partially true; if you disable NAND, you can freely access SPI Flash again. As linux is running from nand, re-muxing it runtime; impossible

So in u-boot; there is sf probe, which could free the nand mux and force the spi mux, but that requires patches to u-boot, which are probably complex.

That said, loading a u-boot that does have SPI Flash support (and disables nand) is also possible. I don't know if we can do a switcheroo however So my guess, is they intended the SPI flash to be written at the factory once, and never be updated.

[rgwan]

I can 100% sure that the SPI Flash contains FSBL, a Zynq bit (will be overridden by the boot progress) and a U-Boot image because there's no any Zynq boot image in the NAND Flash.

So far I know the boot progress (by analyzing SPI image) is: Zynq bootrom->QSPI FSBL(XIP)->load U-boot image from SPI Flash into 0x01000000->jump to U-boot->U-boot switch the pinmux to NAND Flash->U-Boot reads env->U-boot executes env->Linux.

About the QDR SRAM controlled by Zynq, I think it is used to handle the phosphor process. Because the phosphor process needs huge random access to the framebuffer, it is reasonable to use QDR SRAM.

So, our team thinks that acquire and some DSP function is processed by K7, and plotting is processed by Zynq PL.

[rgwan]

Our team got two MSO5072, one MSO5074. But none of them shipped with 1.1.2.4 version firmware.

My scope is on the way to my college. Estimated arrival time is around Jan.1 2018. If my scope shipped with 1.1.2.4 version firmware and it solves all issues I have mentioned before, I would like to share all my research.

BTW, Rigol have replied me about the crash issue, fft issue, and high resolution issue. They said that they are solved in the latest firmware, about two or three days we can get the final result.

To mrpackethead: you have successfully forced me to buy one prematurely, my hack will be available soon. Since you're so energetic, why not ask Rigol for the source of Linux, U-Boot, and some kernel module! In fact, their proprietary driver is also said GPL in the module descriptor. I don't see any contribution in this thread by you, you have said that you just want the principle of the hack, but even a tarball troubles you, so don't make yourself like a sage anymore. Do you know an old saying "The brave man attacks the braver man"?

[BravoV]

rgwan, you have too much inbox stuff, get me some space.

Rgwan just passed the post count (above me at 5) limit to be able to use forum's PM feature.

[wulfman]

My new scope will be here on the 3rd. 

[oliv3r]

I can 100% sure that the SPI Flash contains FSBL, a Zynq bit (will be overridden by the boot progress) and a U-Boot image because there's no any Zynq boot image in the NAND Flash.

So far I know the boot progress (by analyzing SPI image) is: Zynq bootrom->QSPI FSBL(XIP)->load U-boot image from SPI Flash into 0x01000000->jump to U-boot->U-boot switch the pinmux to NAND Flash->U-Boot reads env->U-boot executes env->Linux.

About the QDR SRAM controlled by Zynq, I think it is used to handle the phosphor process. Because the phosphor process needs huge random access to the framebuffer, it is reasonable to use QDR SRAM.

So, our team thinks that acquire and some DSP function is processed by K7, and plotting is processed by Zynq PL.

Yes, you are right; I was wrong
So i haven't anaylized their FSBL; but I'm curious as to the setting of the boot_mode register, as that will answer the XIP question. I am not sure why they'd use XIP, it would make far more sense to use the normal OCM method. Especially when they change there mux.

So what I think they did:

BootROM loads FSBL into OCM and jumps to FSBL that is compiled with SPI flash support
FSBL enables DRAM, loads u-boot from QSPI flash into DRAM and jumps to u-boot

U-Boot knows nothing of SPI flash, but enables NAND flash as it does not know anything about SPI flash.

Hopefully there are no GPIO's to enable/disable pins ... (CS, power enable etc)

However QPSI CS0 pin is 'pin 1' and NAND CS0 pin is at 'pin 0' so at least those should not overlap ...

[mrpackethead]

Not sure why this information would get you banned. U-Boot is GPL software for one. Secondly the software is already being shared via the forum.

As long as people don't attach hacked firmware files or keys onto my server I don't care what they publish.

Cause dave said so?   No problems with the thread or discussion though ( or links )

[Martin72]

I've heard that Rigol adds High-Resolution to Acquire Mode for new firmware version. If this feature is available on your scope, Then congratulations!

It´s not the only issue got to be fixed and also I wonder why this "update" isn´t avaible for download anywhere on their sites.
The "new" firmware seems to be a preliminary one, comes with "newer" 5000s out of stock, but isn´t the "final" version worth to be uploaded as an upgrade.
Maybe it is avaible when you choose online upgrade on scope.

[TopLoser]

I've heard that Rigol adds High-Resolution to Acquire Mode for new firmware version. If this feature is available on your scope, Then congratulations!

It´s not the only issue got to be fixed and also I wonder why this "update" isn´t avaible for download anywhere on their sites.
The "new" Firmware seems to be preliminary, comes with "newer" 5000s out of stock, but isn´t the "final" version worth to be uploaded as an upgrade.

Just ask your dealer, they will give you a link to it. I got one very quickly.

[Martin72]

Hm ?

I thought, new updates will be present on the regular rigol sites…..
You got a new update ? What does the "changes" say ?

Martin

[TopLoser]

Hm ?

I thought, new updates will be present on the regular rigol sites…..
You got a new update ? What does the "changes" say ?

Martin

Single file, no 'changelog'
https://www.dropbox.com/s/7xhvif1n0ayrzju/DS5000Update%20prelim.GEL?dl=0

[rgwan]

so does anyone tested out the three issues I mentioned before on scope shipped with new firmware?

[2N3055]

Also can someone confirm you can do math on math?

[bmx]

so far, rough diff is:

app.img:

shell/start.sh          # add -average_filter option to appEntry
shell/send_mail.sh  # finally! add model/version/serial/date to the body 
resource/scpi/MEAsure.xml # cmd id + 1??
bunch of other xml, hlp or hex files
appEntry (of course)
default/precision.hex
K160_TOP.bin

(edit) many many changes in appEntry, hard to diff, but so far, no change about our prefered start option.

system.img:

/etc/passwd                 #we already knew that
/etc/init.d/rcS              # remove echo ++ Starting ftp daemon
/etc/inittab                  # swap shell on ttyPS0 from /bin/ash to /bin/login, huh?
+/etc/passwd.root       # this is the old one
- /lib/firmware/rtfwifi/rtl{8812,8192}*.bin # bye bye

[TopLoser]

Also can someone confirm you can do math on math?

Math on math
Math on math on math
Math on math on math on math

[justanothername]

should it be:
/rigol/appEntry $PowerOn  -run -fullopt &
or
/rigol/appEntry $PowerOn  -run -average_filter -fullopt &
?

I tried with -average_filter but can't find any difference. Anyway, I can't find the hi-res mode, there is a "fine" switch in the channel settings, but without any effect on the signal.

[bmx]

I tried with -average_filter but can't find any difference. Anyway, I can't find the hi-res mode, there is a "fine" switch in the channel settings, but without any effect on the signal.

I think they added this option to put the average filter by default since it's really ugly without averaging. Look at all their videos, it's always averaging, with color gradient.

[justanothername]

I tried with -average_filter but can't find any difference. Anyway, I can't find the hi-res mode, there is a "fine" switch in the channel settings, but without any effect on the signal.

I think they added this option to put the average filter by default since it's really ugly without averaging. Look at all their videos, it's always averaging, with color gradient.

Well, averaging is disabled after startup, even with this option in the shell script.

[oliv3r]

Not sure why this information would get you banned. U-Boot is GPL software for one. Secondly the software is already being shared via the forum.

As long as people don't attach hacked firmware files or keys onto my server I don't care what they publish.

Cause dave said so?   No problems with the thread or discussion though ( or links )

Righ, so a link is fine; still sharing the file, which I was after.

However, what if it is NOT a hacked firmware, but the actual firmware from the device. Just extracted from. Like in this case u-boot. I don't see how that would be wrong?