Hacking the Rigol MSO5000 series oscilloscopes

[BRZ.tech]

In the RIGOL models below, you can use the Rotary Encoder (ALPS EC12E2424407) PTH assembly, perhaps suitable for adaptation to the MSO5000.

This ALPS EC12E2424407 model can be found easily.

Datasheet:
https://www.farnell.com/datasheets/1685514.pdf

MSO1074Z-S:
https://www.eevblog.com/forum/testgear/rigol-ds1054z-rotary-encoder-mod/msg737852/#msg737852

MSO4000:
https://www.eevblog.com/forum/testgear/rigol-mso4000-and-ds4000-tests-bugs-firmware-questions-etc/msg951428/#msg951428

DS1054Z:

[oliv3r]

So much exiting stuff happening here!

Okay so I'm pretty new to the MSO5000 club, but I think it was a pretty good purchase. I do embedded firmware for off-highway vehicles professionally. I really would like to expand the CAN decode/trigger to the search function. An alternative goal would be to store things in the same file format (.arb/.ref/.bin etc) that it reads or have a converter on the scope. Has anybody made any serious effort for tweaking the firmware? I noticed that there was a repo on gitlab that had the appEntry file. https://gitlab.com/riglol/rigolee/firmware/-/tree/MSO5000/firmware/rootfs/rigol?ref_type=heads
I popped it open in Ghidra, but before I go down the rabbit hole of teaching myself Ghidra/RE, does anybody know of an active project to reverse the source code for this?

You'd have to 'patch' the firmware with your features, Would be a big pain, but sure, possible yes.

OR, write a whole new GUI application that does all that and more Would be perfect. Someone tried to do this once on one of the older rigols. Was it related to http://codenaschen.de/tichyblog/index.php?action=blog&entry=10_Rigol%20DS1052e%20Homebrew%204%20All ? i don't remember ... was an EEVBlog thread about it as well afaik.

But with regards with Ghidra, don't bother, read below

So, this is it! I was able to reverse-engineer and understand how the license keys check works. And I'm glad to present this Fully automatic license activator.
Use it carefully. Trying to switch off your device during activation may brick it.

Usage:
python rigol_kg.py 192.168.1.1

Amazing!! very cool,

I guess the keygen way of inserting the info into the FRAM is bad. I have suggested doing it with official SCPI way.

@DrMefistO probably is looking into it...

can't wait for V2 which uses scpi commands instead

But modifying the FRAM is ereased with a 'factory reset', I suppose you could go the extra mile and replace the 'vendor.bin' or whatever it was called as well? Food for thought for V3?

Anyway, during your RE work, did you try to google for some of the strings? There's a roomer that the actual software was leaked ...

Accidentally posted something here that was intended for https://www.eevblog.com/forum/testgear/another-low-cost-la-probe-for-rigol-mso5000-by-oliv3r/ sorry for the noise

[std]

For a more high quality fan replacement, you can use the Noctua NF-A8 FLX, 80mm fan. It is dead silent and has a six year warranty.
https://noctua.at/en/products/fan/nf-a8-flx

Thank you for suggestion. 
Received the Xilence XF037, connected it to the power supply, and realized it’s impulsive to believe different people from Youtube without doing an engineering check of specs. The Xilence XF037 has a low RPM (1500) and its airflow is not even comparable to a stock fan. That's why I didn't install it.

Well, ordered Noctua NF-A8 FLX, 80mm from Chinese. (Almost $20 for a fan to be a 20-fold overpayment, if not 40). Still don’t know what the airflow of the standard Rigol fan, but Noctua promise higher RPM with airflow than Xilence. 


If take into account that I also need to change Rigol DS1054 fan, C1-99 oscilloscope fan, and also 120mm CPU fan began to creak somehow, this flutter in eggsfans will bring me to bankruptcy ))

[std]

When updating completed I reboot my MSO5000, and it "not working". The progressbar changing from 0 to 100% and nothing is changed. What I need to do, please help.

In a rare case when scope does not boot, press "Single" key at the very beggining of the boot phase and press "Restore defaults" or "Upgrade firmware" to re-apply the original Fw.

A lot of time has passed.
1. Before flashing the oscilloscope, be sure to perform settings reset to factory defaults from the menu. This has been confirmed several times and if you reset the settings (in the menu) before flashing, you do not get into reboot freezing problem. (Remember that settings reset changes probe divider).
2. Oscilloscope is sensitive to USB Flash Drive. My old 2Gb/8Gb flash drives was not accepted, only the new Samsung one. I haven’t checked, but perhaps it possible to check before; from the oscilloscope menu you can try to view flash drive file system.

[Houseman]

Me too. 
Had the unglory brilliant idea today to flash latest firmware MSO5000(ARM)Update v01.03.02.02 from here: https://www.rigolna.com/firmware/and now I am lost into the 100% progress bar frozen state.
Have tried pressing single button at boot without effort...
No options appears
Please help

[skander36]

Have tried pressing single button at boot without effort...

That is very unlikely ...
Start presing repeating imediatelly after start button is pressed..
You will see the menu.

[Houseman]

Yeah, You are right, thanks. I started pressing it before the power button repeatedly. Now it is upgraded at least... but with all options gone...
I have the 01_03_00_03.bspatch, it's 2 years old. Will navigate through the forum to see if there are any news relative to this patch.
Thank You

[skander36]

The latest is 01.03.03.00
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4821650/#msg4821650
This is I'm using now.

[oliv3r]

Yeah, You are right, thanks. I started pressing it before the power button repeatedly. Now it is upgraded at least... but with all options gone...
I have the 01_03_00_03.bspatch, it's 2 years old. Will navigate through the forum to see if there are any news relative to this patch.
Thank You

There was a keygen just a few posts ago ... :p

[vishay]

Hi, I need some help. I updated my oscilloscope with a patch from "trixy" (thanks), from firmware 00.01.03.03.00. All options became available and I also managed to make a self-cal without any problems. After that, I did not check the oscilloscope and used it extremely rarely, measuring signals mainly up to 1 MHz. Next, with the built-in generator, I set a rectangular pulse with a maximum frequency of 15 MHz and saw the following picture (is this such a bad oscillator or an oscilloscope channel ? An oscilloscope with a frequency of 350 MHz cannot normally display a 15 MHz rectangle ?). Yesterday I tried to do auto-calibration and it stops at 6% giving an error. Today I turned on the oscilloscope again and turned on self-cal 30 minutes later (and it's a miracle) it was completed successfully. I repeated the test again with the measurement of the rectangular signal, but the picture did not change, the signal was also strongly distorted. Can anyone tell if this is normal or not? What could be the problem? Can anyone do the same experiment?

[skander36]

It is correct.

[macboy]

Vishay,
What you see is normal. The deficiency is with the generator, it can't produce the very high frequencies needed for fast edges. If you want to see the real limit of the scope, then you need a signal with very fast edges. Search the forum for Leo Bodnar Pulser for an example of a device.

The manual clearly states to warm up the scope before starting the auto cal, so that failure was expected as well.

[JCS666]

Or this https://tinyurl.com/2aaek95c

[ivonenand]

Hi Guys,
I just updated my 5074 to 01.03.03.00 and patched it. I now have all options, including the deep memory option (2RL, 200Mpots Deep Memory Option). For some reason though, I don't think I'm actually getting this option. The most I see in the horizontal division is 20-25Mpts, with only CH 1 enabled. For example:

10ms/div, 200MSa/s, 20Mpts
5ms/div, 500MSa/s, 25Mpts
2ms/div 1GSa/s, 20Mpts

Is this normal? Shouldn't I be getting 200Mpts?

Regards,
Ivo

[skander36]

There is the 200 M option in the aquire menu?

LE - If you leave it on Auto, the scope will allocate only the right amount of memory. You can force using all memory by choosing manually the value.

[gbix]

I was able to parse sysvendor.bin

The block with the model has additional fields

Does anyone know what these fields are?
Can anyone post their sysvendor.bin file for statistics?

thx!

[tv84]

Does anyone know what these fields are?
Can anyone post their sysvendor.bin file for statistics?

Here's a full parsing example.

You can't parse another guy's sysvendor.bin without knowing it's own XXTEA key.

[gbix]

Does each device have a unique key?

Do you have a link to this project? May be its project by @DrMefistO?
I seem to have missed this one)))The example is incomplete. There is also data after the model number, serial number and mac address

[DrMefistO]

Hi,

As I saw during RE, firmware only uses FRAM to load a key, and doesn't use sysvendor.bin, as before. Or I haven't found that. By the way, I tried to patch sysvendor.bin previously, but the oscillo doesn't load it from there.
SCPI commands don't allow to change FRAM, I haven't found any available command for that.

[gbix]

Hi,

As I saw during RE, firmware only uses FRAM to load a key, and doesn't use sysvendor.bin, as before. Or I haven't found that. By the way, I tried to patch sysvendor.bin previously, but the oscillo doesn't load it from there.
SCPI commands don't allow to change FRAM, I haven't found any available command for that.

Do you tried usb drive with crypted key "RIGOL TECHNOLOGIES,DS1000Z,SPARROW,201212" for SCPI commands as for other some models?

[tv84]

An example of parsing for a FRAM beginning (all "fields" are stored in FRAM):

Code: [Select]

00000000 BLOCK0 CRC32
00000004        BLOCK0 size
00000008        BLOCK0 data (0084 - 132 bytes)  Practically all zeros  (0x13 - maybe "Boot times")

00000100        BLOCK1 size + checksum            option:       checksum:     datasize:     checksum:     CRC32:        data:
00000108        Key.dat                           A0 11 00 00 | 60 EE FF FF | 94 00 00 00 | 6C FF FF FF | 1F 37 29 92 | Key.dat
000001B0 lic_COMP  + timer + fail counter  8A 11 00 00 | 76 EE FF FF | 04 00 00 00 | FC FF FF FF | C7 05 DB E7 | 4A 00 02 00
000001C8 lic_EMBD  + timer + fail counter  8B 11 00 00 | 75 EE FF FF | 04 00 00 00 | FC FF FF FF | C7 05 DB E7 | 4A 00 02 00
000001E0 lic_AUTO  + timer + fail counter  8C 11 00 00 | 74 EE FF FF | 04 00 00 00 | FC FF FF FF | C7 05 DB E7 | 4A 00 02 00
000001F8 lic_FLEX  + timer + fail counter  8E 11 00 00 | 72 EE FF FF | 04 00 00 00 | FC FF FF FF | C7 05 DB E7 | 4A 00 02 00
00000210 lic_AUDIO + timer + fail counter  8D 11 00 00 | 73 EE FF FF | 04 00 00 00 | FC FF FF FF | C7 05 DB E7 | 4A 00 02 00
00000228 lic_AERO  + timer + fail counter  90 11 00 00 | 70 EE FF FF | 04 00 00 00 | FC FF FF FF | C7 05 DB E7 | 4A 00 02 00
00000240        sysvendor.bin                     40 08 00 00 | C0 F7 FF FF | 18 01 00 00 | E8 FE FF FF | 64 A2 39 9C | sysvendor.bin

00000800 BLOCK2 CRC32
00000804        BLOCK2 size
00000808        BLOCK2 data (0EC2 - 3778 bytes)  License data most certainly... (if you erase the FRAM, the scope basically recreates most of this area)
Then follows some other structures that I never considered interesting...

All of this was made 5 years ago, so only just my notes...

Regarding SCPI commands for the FRAM: they are real.

Does each device have a unique key?

... The example is incomplete. There is also data after the model number, serial number and mac address

Sure they have. The example is complete and it's similar to yours.  pm me your sysvendor and your XXTEA key and I'll prove it

[tv84]

For the deviant ones that like to see how the little details go, here is a MSO5000 FRAM parsing (up to the best of my investigations in the good ol' days).

There is a Block1 with licensing, sysvendor file and key.dat and there is a Block2 composed of a bunch of zlib structures that store all the settings of the machine. I never pursued all the fieldnames inside this block, as most of them don't have any values.

I would be surprised if current DHO FRAM structures are much different from this one although, with Rigol in tha house, everything is possible...

[Neekeetos]

Has anyone tried to activate 500M option on our scopes?

'BW07T1', 'BW07T2', 'BW07T3' are activated by patch but the option 'BW07T5' is not

[oliv3r]

Has anyone tried to activate 500M option on our scopes?

'BW07T1', 'BW07T2', 'BW07T3' are activated by patch but the option 'BW07T5' is not

search this thread an you willl find your answer :p

For the deviant ones that like to see how the little details go, here is a MSO5000 FRAM parsing (up to the best of my investigations in the good ol' days).

There is a Block1 with licensing, sysvendor file and key.dat and there is a Block2 composed of a bunch of zlib structures that store all the settings of the machine. I never pursued all the fieldnames inside this block, as most of them don't have any values.

I would be surprised if current DHO FRAM structures are much different from this one although, with Rigol in tha house, everything is possible...

I seem to remember, one was a 'copy' of the other, but fram was leading. The scope would take sysvendor.dat if fram was corrupt/missing, but write to sysvendor when fram was modified? Or was sysvendor the 'factory-default' and never written to? It's been a while, but I'm sure it's in the leaked code :p

[Neekeetos]

Has anyone tried to activate 500M option on our scopes?

'BW07T1', 'BW07T2', 'BW07T3' are activated by patch but the option 'BW07T5' is not

search this thread an you willl find your answer :p

This option mentioned twice without explanation on why whould it not work. There is a speculation that we have a bw limiting settings enabled in frontend ic, maybe activating BW07T5 even partially will disable this limit.