Hacking the Rigol MSO5000 series oscilloscopes

[demoss]

Hello! Yep, now i have MSO5072 with full functions! Thanks a lot!
But i have a question, from what device or file rigol read information about model, serial,firmware,hardware... When we press "About" botton?
And else... How i can enable ssh permanently ? I need rewrite ssh and sshd config or \ and /etc/init.d script's?

[thm_w]

Hello! Yep, now i have MSO5072 with full functions! Thanks a lot!
But i have a question, from what device or file rigol read information about model, serial,firmware,hardware... When we press "About" botton?
And else... How i can enable ssh permanently ? I need rewrite ssh and sshd config or \ and /etc/init.d script's?

Press the Print button top right and search through the thread. https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2245083/#msg2245083

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?

Makes no sense to spend effort on this, IMO, when you can get a decent logic analyzer for ~$100 that can be used with open source pulseview. Or dedicated CAN analyzers are probably available as well.

[comeau]

I already have tools for analyzing CAN messages. However, there is a real benefit to having the device input signals, CAN bus analog signal shape and CAN messages all on the same device. Synchronizing the inputs/outputs and messages takes time and slows down the process. Also, 12V logic analyzers are rarer and more expensive so I need the scope for I/O even if I had a logic analyzer for the CAN bus. Basically, the scope is sometimes the best tool for the job. I'm not trying to find a new tool. I just want to improve the tool that I'm using. I want to see every trigger condition that is present in the buffer.
Is it practical to add this function to the scope, maybe not. Either way I'll learn something.

[comeau]

I didn't see it posted here, or couldn't find it:
To cross-compile a binary for the MSO5000 you just need to follow the directions to install the toolchain found here: https://www.acmesystems.it/arm9_toolchain
You'd be using the arm-linux-gnueabi-gcc command version.

[macboy]

I already have tools for analyzing CAN messages. However, there is a real benefit to having the device input signals, CAN bus analog signal shape and CAN messages all on the same device. Synchronizing the inputs/outputs and messages takes time and slows down the process. Also, 12V logic analyzers are rarer and more expensive so I need the scope for I/O even if I had a logic analyzer for the CAN bus. Basically, the scope is sometimes the best tool for the job. I'm not trying to find a new tool. I just want to improve the tool that I'm using. I want to see every trigger condition that is present in the buffer.
Is it practical to add this function to the scope, maybe not. Either way I'll learn something.

It's unclear what you want to do. Is the CAN Decode event table not good enough? You can also export this to .csv file then import into a spreadsheet for more detailed analysis on a computer. What about the waveform recording? This can record many separately triggered waveforms ("frames") into the memory buffer, and you can then go back and view each frame, I assume with decoding if desired. The manual describes waveform recording as capturing on an interval, but you need to interpret that as re-arming the trigger on that interval. Then, when the trigger fires (which could be some condition on the CAN bus), a waveform/frame is recorded. The trigger is re-armed after the delay which can be set as low as 10 ns (effectively nil for CAN).

[EJC]

Thanks so much to everyone who worked on this!!!  So happy to get my MSO5074 unlocked, AWESOME!
For anyone looking for the instructions/correct patch in this giant thread like I was, here is the patch for FW 01.03.02.02, taken from stmcore's post:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4685945/#msg4685945

Instructions I followed:
-Freshly formatted 16GB Nextech USB to FAT32
-Unzipped "01.03.02.02_patch.zip" onto USB (loose files into root directory)
-put USB in scope, do local upgrade (Utility->System->Help->Local Upgrade)
-press keys when prompted on scope
-don't panic when screen goes black for a minute
-re-calibrate unit (Utility->System->SelfCal)
-reboot and enjoy all the sweet sweet bandwidth!

[mosafet]

For anyone looking for the instructions/correct patch in this giant thread like I was, here is the patch for FW 01.03.02.02, taken from stmcore's post:

00.01.03.03.00 is the latest firmware AFAIK

[core]

Thanks so much to everyone who worked on this!!!  So happy to get my MSO5074 unlocked, AWESOME!
For anyone looking for the instructions/correct patch in this giant thread like I was, here is the patch for FW 01.03.02.02, taken from stmcore's post:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4685945/#msg4685945

Instructions I followed:
-Freshly formatted 16GB Nextech USB to FAT32
-Unzipped "01.03.02.02_patch.zip" onto USB (loose files into root directory)
-put USB in scope, do local upgrade (Utility->System->Help->Local Upgrade)
-press keys when prompted on scope
-don't panic when screen goes black for a minute
-re-calibrate unit (Utility->System->SelfCal)
-reboot and enjoy all the sweet sweet bandwidth!

Why don't you try to install the latest firmware and patch (00.01.03.03.00) ?
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4856702/#msg4856702

[EJC]

Oh my scope came with 01.03.02.02 and that is the only one available for download from rigolcanada.com where I bought the scope.  Just assumed it was the latest 
I'll have to look into that thank you!

Edit:  Got 01.03.03.00 from Rigol.eu and patched!  Thanks guys 

[comeau]

I already have tools for analyzing CAN messages. However, there is a real benefit to having the device input signals, CAN bus analog signal shape and CAN messages all on the same device. Synchronizing the inputs/outputs and messages takes time and slows down the process. Also, 12V logic analyzers are rarer and more expensive so I need the scope for I/O even if I had a logic analyzer for the CAN bus. Basically, the scope is sometimes the best tool for the job. I'm not trying to find a new tool. I just want to improve the tool that I'm using. I want to see every trigger condition that is present in the buffer.
Is it practical to add this function to the scope, maybe not. Either way I'll learn something.

It's unclear what you want to do. Is the CAN Decode event table not good enough? You can also export this to .csv file then import into a spreadsheet for more detailed analysis on a computer. What about the waveform recording? This can record many separately triggered waveforms ("frames") into the memory buffer, and you can then go back and view each frame, I assume with decoding if desired. The manual describes waveform recording as capturing on an interval, but you need to interpret that as re-arming the trigger on that interval. Then, when the trigger fires (which could be some condition on the CAN bus), a waveform/frame is recorded. The trigger is re-armed after the delay which can be set as low as 10 ns (effectively nil for CAN).

No, the CAN Decode table is insufficient for two reasons. 1) The CAN decode doesn't work if you zoom out very far even though the sample rate is adequate or even the waveform is saved in memory 2) The event table shows all events, not just certain events.
The idea is to trigger off a very infrequent analog event, then look at how that analog event is related to selected CAN messages in time. So for instance nothing happens for 2 minutes, Ch1 goes high for 20ms, when was the last 0x18EAFFBE message? For SPI this is easy, you use the search function. The search function doesn't work for CAN. That's the problem.
As an aside I tried using PulseView and found it to be worse than using the scope. It just didn't work very well, missed frames, couldn't handle partial frames etc.
Please keep in mind I'm not asking for advice on how to use the scope, I just wanted to know if anybody was actively reversing the firmware.

[demoss]

How does one enable this mystical 500MHz mode?

I won't go into details because the benefits are residual compared to the possible headaches when executing the procedure wrongly. I leave that as homework for the ones who are not faint of heart.

But, as general knowledge, I'll add the following:

These equipments keep their config in a FRAM memory. In that FRAM, among other possible things, usually there are the following params (specific to the unit):
- E_CFG_MODEL_RAW
- E_CFG_SN_RAW
- E_CFG_MAC
- ECC Public key of the scope
- Option's licenses

These fields are replicated in the sysvendor.bin, Key.data and the *.LIC files (for "external" consumption).

So, to change the Model, you just have to change the contents of the param E_CFG_MODEL_RAW, in the FRAM, and the scope will adjust everything else accordingly.

Hello, has anyone managed to make these changes as well?  Did you manage to work with Fram?  If someone has repeated this feat, can you write or direct me?  I'll be with the device soon and want to give it a try.

[Vancouver_Kid]

Thanks so much to everyone who worked on this!!!  So happy to get my MSO5074 unlocked, AWESOME!
For anyone looking for the instructions/correct patch in this giant thread like I was, here is the patch for FW 01.03.02.02, taken from stmcore's post:
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4685945/#msg4685945

Instructions I followed:
-Freshly formatted 16GB Nextech USB to FAT32
-Unzipped "01.03.02.02_patch.zip" onto USB (loose files into root directory)
-put USB in scope, do local upgrade (Utility->System->Help->Local Upgrade)
-press keys when prompted on scope
-don't panic when screen goes black for a minute
-re-calibrate unit (Utility->System->SelfCal)
-reboot and enjoy all the sweet sweet bandwidth!

Hi EJC, thank you for summarizing but can you further clarify what what features and apparent BW we are gaining by doing what you have summarized?

[mwb1100]

The MSO5000 hack enables: 350MHz bandwidth, arbitrary waveform generator, increases memory depth to 200Mpts, and all serial decodes

[Papa58]

Thank you Vancouver_Kid
Couple of questions I am hoping you can help with.

1) I believe the latest patch is 01_03_03_00
2) Do I need to do a back up before I follow you programing instructions. Almost seems to simple.
3) All three files only total 132kB. Do we need 32g USB stick? There seems to be some questions about which ones will actually work. Do you have a recommendation for the one you used.

Thank you for posting the very good instructions. My machine will be here in a few days. Really looking forward to putting it through some tests.

Thank you..
David

[thermotto]

Everything was fine here too.

I will use my previous upgrade post, updated for v00.01.03.00.03 -> v00.01.03.03.00.

Steps I've followed :

Thanks everybody !

Thanks for outlining the steps! I have successfully upgraded my new MSO5074.

[mironex]

Everything was fine here too.

I will use my previous upgrade post, updated for v00.01.03.00.03 -> v00.01.03.03.00.

Steps I've followed :

1. Backup everything just in case (optional but recommended)
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2757356/#msg2757356
- get and unzip the first script file, put DS5000Update.GEL on USB stick, then Utility/Help/Local upgrade
- wait until 100%, then turn off/on
- repeat for the second script

2. Install the official firmware v00.01.03.03.00; I have used the above link from rigol.eu
- get the official firmware and unzip
- same steps like above, with the firmware file of course

3. Hack
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg4821650/#msg4821650
- get and unzip the file 01_03_03_00.zip and put the three files on USB stick
- same steps like above
- there will be some messages on the screen. You will be asked to press a key, two times. At the end the oscilloscope will reboot, just wait.
- all the options will be activated

4. Calibration - very important
- remove the input probes
- Utility/System/SelfCal
- then turn off/on

Thanks everybody !

I have 2 questions:
1. Where could I find procedure to recover from this backup  ?
Which scenarios could require this?
2. How could I recover firmware to original in case when I need to send oscilloscope to service  ?
3. What about my original additional license? Could I use it after recovering to original firmware?

Thanks :-)
M.S.

[thm_w]

I have 2 questions:
1. Where could I find procedure to recover from this backup  ?
Which scenarios could require this?
2. How could I recover firmware to original in case when I need to send oscilloscope to service  ?
3. What about my original additional license? Could I use it after recovering to original firmware?

Thanks :-)
M.S.

Its all in this thread. But if there is any issue, press "Single" during boot, load the stock Rigol FW that is unmodified, hit reset to defaults. Everything should be back to stock so you can send in for service.

[BitBug]

Anybody have any issues with their "Scale" encoder jumping/glitching around?

I have one of the earlier 5074s... Just started getting very "touchy" lately when scaling-up or down... Just wondering if the newer firmware did a better job of de-bouncing the encoder output?

BB

[w.v.s.]

Anybody have any issues with their "Scale" encoder jumping/glitching around?

I have one of the earlier 5074s... Just started getting very "touchy" lately when scaling-up or down... Just wondering if the newer firmware did a better job of de-bouncing the encoder output?

BB

I think I've read about issues with the quality of the encoders. So I would rather consider it as an hardware issue of the encoders. If you ask about software de-bouncing in the firmware, you could just give a later version a try.

[beatman]

The encoders are no good.I change both on 1054 and 5104 and is far better the response.The stock pots is smd i by 24 clicks through hole encoders cut and bend carefully  the legs and solder on place.Two years now run the scopes flawlessly.

[BitBug]

The encoders are no good.I change both on 1054 and 5104 and is far better the response.The stock pots is smd i by 24 clicks through hole encoders cut and bend carefully  the legs and solder on place.Two years now run the scopes flawlessly.

Wouldn't happen to have the part numbers you replaced them with, would you ?  ...I guess I'll need a quality "upgrade"... 

BB

[DrMefistO]

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

[tv84]

Now you just have to replace the loading of the FRAM's pubkey with the correct SCPI command. That makes life easier and the code simpler.

[DrMefistO]

I'm doing so, but using fram tool.

[tv84]

I'm doing so, but using fram tool.

Definitely not so elegant or failure proof.