EEVblog #1146 - New Low Cost Rigol MSO5000 Oscilloscope

[mrpackethead]

Of course that assumes they really want to secure it, which I think they probably do.

Anything above the DS1054Z already requires you to open it up and use a JTAG programmer to hack it. Only the base models are hackable with a simple keygen.

That's enough of an impediment to prevent the majority of people from doing it even if the instructions are widely available.

So what is required to have a go to hack it.

I'm thinking a JTAG interface compatible with the CPU it uses so you can dump the flash chip. From there the OS can be analyzed.

From what i read in the bootloader, it seems its running on a Zync SOC, with the Xilinx variant of linux.    If i had that hardware, id use the secure bootloader, so reading the flash won't be particulally helpful as it woudl be AES256 encrypted.     

Did dave do a tear down? would be interesting to know whats actually inside it.

[TheSteve]

Well you won't know until you try it.

[ResistorRob]

I have a dumb question. Does this do Bode Plots like the Siglent 1104X-e?

[mrpackethead]

 That is true.

I'm heading to the US soon, i might pick one up while i'm thiere, because they are much much cheaper in the USA, than downunder.

[Fungus]

So what is required to have a go to hack it.

The first thing you need is two 'scopes with different options.

One to figure out the exact chips on the board and the available test/JTAG points, the other to figure out what's different between the two.

[0xdeadbeef]

I'm puzzled that the common opinion here seems to be that the mere existence of a JTAG port means that you can read out the flash. Even back in early Atmel 8bit microcontrollers 20 years ago, there were mechanisms to prohibit reading of flash ("fuses"). Every microcontroller nowadays should have means to disable JTAG in production and/or disable read access to RAM and flash through JTAG. If Rigol didn't prohibit reading out the flash in the past, you can choose if this was due to incompetence or a "don't care" policy. Anyway, either can change.

After prohibiting reading out the flash, the next logical step is encrypting firmware images. Sothe bootblock decrypts the image while reading. And since you can't read out the bootblock, you can't access the key for decoding. When an RSA/AES encryption with sufficient key length is used, this approach is pretty much bullet proof.

The only hope then would be to find a weakness in the specific microcontroller to circumvent the flash read protection. The "chip tuning" industry managed to find such flaws in several automotive processors, but obviously this is nothing you can rely on.

[mikeselectricstuff]

I'm puzzled that the common opinion here seems to be that the mere existence of a JTAG port means that you can read out the flash. Even back in early Atmel 8bit microcontrollers 20 years ago, there were mechanisms to prohibit reading of flash ("fuses"). Every microcontroller nowadays should have means to disable JTAG in production and/or disable read access to RAM and flash through JTAG. If Rigol didn't prohibit reading out the flash in the past, you can choose if this was due to incompetence or a "don't care" policy. Anyway, either can change.

After prohibiting reading out the flash, the next logical step is encrypting firmware images. Sothe bootblock decrypts the image while reading. And since you can't read out the bootblock, you can't access the key for decoding. When an RSA/AES encryption with sufficient key length is used, this approach is pretty much bullet proof.

The only hope then would be to find a weakness in the specific microcontroller to circumvent the flash read protection. The "chip tuning" industry managed to find such flaws in several automotive processors, but obviously this is nothing you can rely on.

We're not talking about flash on an MCU here, but a seperate flash chip, which may be accessable using boundary scan port on the device connected to it.
If the flash is connected to an FPGA, you could load a bitstream into the FPGA to read the flash and spit it out serially

[nctnico]

After prohibiting reading out the flash, the next logical step is encrypting firmware images. Sothe bootblock decrypts the image while reading. And since you can't read out the bootblock, you can't access the key for decoding. When an RSA/AES encryption with sufficient key length is used, this approach is pretty much bullet proof.

I'm wondering if Rigol is allowed to use AES encryption on the firmware. There might be export restrictions. I'm pretty sure the NSA and similar security agencies will want to examine the firmware for any hidden forms of cyber attack.

[Fungus]

I'm puzzled that the common opinion here seems to be that the mere existence of a JTAG port means that you can read out the flash. Even back in early Atmel 8bit microcontrollers 20 years ago, there were mechanisms to prohibit reading of flash ("fuses"). Every microcontroller nowadays should have means to disable JTAG in production and/or disable read access to RAM and flash through JTAG. If Rigol didn't prohibit reading out the flash in the past, you can choose if this was due to incompetence or a "don't care" policy. Anyway, either can change.

Sure, but this isn't a fixed-function microcontroller that gets programmed once at the factory.

These devices are firmware upgradable. The chips used on them work by reading their code from an external flash memory chip at power-on and they need a way to rewrite the contents of those chips during upgrades/patches.

The chips aren't potted so the worst case is that you have to solder little wires onto the chip and sniff the data when it boots (it's usually a serial bus, eg. SPI).

[Fungus]

I'm wondering if Rigol is allowed to use AES encryption on the firmware. There might be export restrictions. I'm pretty sure the NSA and similar security agencies will want to examine the firmware for any hidden forms of cyber attack.

I'm sure it would be easier to sniff the Ethernet/USB bus for malicious traffic than try to reverse engineer the firmware.

(Ethernet/USB is the only way an oscilloscope could really "attack" anything)

[0xdeadbeef]

We're not talking about flash on an MCU here, but a seperate flash chip, which may be accessable using boundary scan port on the device connected to it.
If the flash is connected to an FPGA, you could load a bitstream into the FPGA to read the flash and spit it out serially

Ah, OK, in my field of work (automotive/engine control), external flash hasn't been used since ages. So i must admit didn't think of this approach. Still, I would think in the 21st century someone came up with an approach to prevent an attack on the flash, specifically if the device is Linux based and the flash contains a file system. Like you could use an encrypted file system and store the decryption key in protected microcontroller flash or whatever.

[Fungus]

Like you could use an encrypted file system and store the decryption key in protected microcontroller flash or whatever.

Sure, they could do all that (and more besides)

But it's weird that they didn't put the same level of protection in the DS1000Z as in the DS1000Z 'Plus' models.

[nctnico]

I'm wondering if Rigol is allowed to use AES encryption on the firmware. There might be export restrictions. I'm pretty sure the NSA and similar security agencies will want to examine the firmware for any hidden forms of cyber attack.

I'm sure it would be easier to sniff the Ethernet/USB bus for malicious traffic than try to reverse engineer the firmware.

No. Inspecting the firmware is the only way because there might be specific triggers involved. Think about the scope examining a USB stick and network traffic first to look for company names. A crapload of information is broadcasted on networks so there is no need to send anything in order to collect initial data.

[Fungus]

No. Inspecting the firmware is the only way because there might be specific triggers involved. Think about the scope examining a USB stick and network traffic first to look for company names. A crapload of information is broadcasted on networks so there is no need to send anything in order to collect initial data.

The NSA has no way to broadcast some "typical" traffic at an oscilloscope?

And, (b) If you were a boss at Rigol, would you risk being caught doing something like that? It would be the end of the company.

I think the only way an attack of this sort would be attempted would be on a specific shipment that was destined for a particular company. Keep as low a profile as possible. In that case examining the "public" firmware wouldn't do you any good.

And, (c) If I were going to do something this risky I'd do it in hardware, not software. Examining the firmware wouldn't give any clues.

[nctnico]

No. Inspecting the firmware is the only way because there might be specific triggers involved. Think about the scope examining a USB stick and network traffic first to look for company names. A crapload of information is broadcasted on networks so there is no need to send anything in order to collect initial data.

The NSA has no way to broadcast some "typical" traffic at an oscilloscope?

And, (b) If you were a boss at Rigol, would you risk being caught doing something like that? It would be the end of the company.

Doing a firmware analysis is infinitely easier than stabbing around in the blind trying to hit something. And if you are worried about b): Huawei and ZTE still exist.

[Martin72]

Hi there,

Batronix (Germany) sells the MSO5074 for 1069€, a Options Bundle (excluding Bandwith) for 713€ - With a look on the technical data of this newbie, appx 1800€ seems not too expensive.
Compare it with my former favorite, RTB2004, it´s a little bit more than half the price of it (2200€ for 70Mhz plus optionbundle).
Therefore I think I will give the new Rigol a try....or should I wait....
Actual, Batronix offer the 1000Z Models with all Options including, maybe this will happen too for the MSO5000, but when...
I did a request for it by Batronix, also I ask them for the missing HiRes Mode, if there is a Firmware Update in Progress.
First answer, they will ask Rigol…

Martin

[simone.pignatti]

is anybody interested on the logic channels (adding the logic probe)?

[0xdeadbeef]

I'd wait at least until there's either a free options bundle or it's clear whether there will be a hack. Since 70MHz bandwidth is a bit of a joke and the prizes for the frequency upgrades are crazy.
Besides, given that all other Rigol scopes including the DS7000 currently get all the decoders for free, the MSO5000 line seems less attractive.
E.g. currently the price difference between an MSO5014 with options bundle and a DS7014 with (free) options bundle is less than 600€.

Anyway, while the 8GS/s sample rate is really tempting, I guess you'll be happier with the RTB in the long run. Rigol has a bad history regarding firmware updates etc. and the magnified low voltage scales make it even worse compared to the 10bit sampling of the RTB. I personally hate that both, DS5000 and RTB2000 don't have a probe detection/supply. I mean I could live without probe supply, but a scope without probe detection feels like going back to the middle ages.

Batronix (Germany) sells the MSO5074 for 1069€, a Options Bundle (excluding Bandwith) for 713€ - With a look on the technical data of this newbie, appx 1800€ seems not too expensive.
Compare it with my former favorite, RTB2004, it´s a little bit more than half the price of it (2200€ for 70Mhz plus optionbundle).
Therefore I think I will give the new Rigol a try....or should I wait....

[Fungus]

Anyway, while the 8GS/s sample rate is really tempting, I guess you'll be happier with the RTB in the long run. Rigol has a bad history regarding firmware updates etc. and the magnified low voltage scales make it even worse compared to the 10bit sampling of the RTB. I personally hate that both, DS5000 and RTB2000 don't have a probe detection/supply. I mean I could live without probe supply, but a scope without probe detection feels like going back to the middle ages.

The lack of probe detection is one of the reasons I think this 'scope might not be too hard to hack, ie. in a professional environment the missing features mean a hacked DS5000 still won't compete with other mid-range Rigol scopes.

It would kill their DS2000 range, yes, but maybe Siglent/Keysight already did that and this is Rigol's Siglent/Keysight killer.

[Martin72]

In our testfield, most of the scopes are from Lecroy with the ability of Auto-Detection.
If I use a suitable probe, it´s a nice feature - Otherwise I´ll set the gain manually, it takes a few seconds more to do that.
Or are there another benefits I don´t know them until now ?
It seems, it´s very important to have this.

@0xdeadbeef :

The RTB is my favorite, but for private actions it´s too expensive ( for me).

Martin

Edit:

is anybody interested on the logic channels (adding the logic probe)?

I won´t use them even it would be included.

[Martin72]

E.g. currently the price difference between an MSO5014 with options bundle and a DS7014 with (free) options bundle is less than 600€.

Oh, haven´t seen this offer (DSO 7000 with all options for free), did a reply to Batronix a few minutes before with a mark to this - With all options included the price would be hot for the 5000 series.
70Mhz BW I don´t care about it, more important would be the fix of an missing Hi-Res Mode.
Even my Siglent Scope have an enhanced resolution mode, Rigol have to fix it for the 5000/7000 series.
What I like on our LeCroy scopes are the displaying of PWM Signals "slow" and the free choosable measuring gate - I´m curious about it, if the Rigol have this too.

[mrpackethead]

After prohibiting reading out the flash, the next logical step is encrypting firmware images. Sothe bootblock decrypts the image while reading. And since you can't read out the bootblock, you can't access the key for decoding. When an RSA/AES encryption with sufficient key length is used, this approach is pretty much bullet proof.

I'm wondering if Rigol is allowed to use AES encryption on the firmware. There might be export restrictions. I'm pretty sure the NSA and similar security agencies will want to examine the firmware for any hidden forms of cyber attack.

AES encryption is a publiclly available algorithm, so, not sure how export restrictions stop anything.   The Xilinx chipset that is running the CPU is made in Taiwan.    The NSA last time i looked did'nt have much power in taiwan.

[mrpackethead]

We're not talking about flash on an MCU here, but a seperate flash chip, which may be accessable using boundary scan port on the device connected to it.
If the flash is connected to an FPGA, you could load a bitstream into the FPGA to read the flash and spit it out serially

Ah, OK, in my field of work (automotive/engine control), external flash hasn't been used since ages. So i must admit didn't think of this approach. Still, I would think in the 21st century someone came up with an approach to prevent an attack on the flash, specifically if the device is Linux based and the flash contains a file system. Like you could use an encrypted file system and store the decryption key in protected microcontroller flash or whatever.

If they have encrypted the data on the flash. ( which is stock standard for how you protect your IP ), then being able to read it,  wont' help you.  You would need the private keys to decode it.   if they are using eFUSEs then they probably have blown the fuse so you cna't read the eFUSE registers either.

[0xdeadbeef]

Hm, why would you think that I didn't get what encryption is for? Actually you seem to repeat more or less what I wrote. Sometimes you wonder...

Still, I would think in the 21st century someone came up with an approach to prevent an attack on the flash, specifically if the device is Linux based and the flash contains a file system. Like you could use an encrypted file system and store the decryption key in protected microcontroller flash or whatever.

If they have encrypted the data on the flash. ( which is stock standard for how you protect your IP ), then being able to read it,  wont' help you.  You would need the private keys to decode it.   if they are using eFUSEs then they probably have blown the fuse so you cna't read the eFUSE registers either.

[Fungus]

If they have encrypted the data on the flash. ( which is stock standard for how you protect your IP ), then being able to read it,  wont' help you.  You would need the private keys to decode it. 

I find no flaws in that logic, but...  is it the case?