Hacking the Rigol MSO5000 series oscilloscopes

[S. Petrukhin]

Hey. I just bought one too. I would like to make backup from current firmware and all the data(as i would make image in windows world) before i try this "hack". How can i make backup and later use that backup as a recovery as well? Im not very familiar with linux backup. Thanks in advance.

The backup copy is stored in the scope.
To return everything as it was, just hold down RUN or SINGLE (don't remember exactly) when you turn it on.

[omgoleus]

Hi All! Just joined so I could post, after spending... well, multiple hours reading the history of this amazing journey.

[..]

I also just got a MSO5072 with the mid-May firmware, same number and build timestamp listed above.
I went ahead and used the well-worn ssh enabler, ssh in, use the command line to copy the appEntry file onto a USB stick at /media/sda1 and took it to another computer to do the MD5.
If you have any kind of unix computer (linux or Mac) simply type
$ md5 /Volumes/USB_DRIVE/appEntry
or whatever the appropriate path is for you. md5 should be present by default in most unix-like systems.
MD5 (appEntry) = 783a31ebdc0d4acb7b9dc244155ba1c6
From everything I'm seeing here, it seems like this piece of info should be enough to get the patcher to work? Am I misunderstanding?

Welcome! Unfortunately, just changing the initial MD5 before patching is not enough. The patch also has to fit the binary, and you need to know the MD5 after the patch. If you want to learn a bit more, I encourage you to try and replicate the patch for your binary.  For that, you have to compare the differences between a patched and unpatched appEntry, and replicate the same patch on your newly downloaded appEntry. Then you created the patch file, enter the correct md5, and you are done. :-) I found it well worth learning myself.

OK, well, I've been trying for a few days and could use some pointers. I did quite a bit of searching and learned that although it's (relatively) easy to find the step-by-step instructions and the relevant patch file for your auto-patcher, it's remarkably hard to find anything relevant to making your own patch, in this topic, via searching. I tried searches on "appEntry", "bdiff", "bpatch", "bspatch", "patch file", "patch function", "license check", etc. and after reading a few hundred search results I learned that I need to use a disassembler like IDA or Binary Ninja on appEntry, and then identify the relevant part of code based on the offset address that piskers provided on March 1, 2019. In turn it seems like this would require disassembling that same version (01.01.04.04) and then disassembling the current version and manually finding the analogous function at a different address. And then after identifying the right function in the current version, I'd have to understand Xilinx assembler well enough to know how to modify the code, and then do that, and then save it to disk, and then use bdiff to make a patch. And then the rest is just plugging it into the auto-patcher.

So, does that seem all correct? I have a number of questions about details, but I'll just start with one, because I'm blocked at step zero... Namely, IDA for hobbyists is $365/year and the free cloud version of Binary Ninja won't handle files larger than 15Mb. So I am not sure where to begin with the disassembly. Any pointers for how to get started? I suppose in theory I could buy one of these very expensive software packages, considering that it's still way cheaper than buying the fully upgraded scope, but I am loathe to do that as I am probably not switching careers to a firmware reverse engineer any time soon...

I am making a sincere effort to figure this all out as you have encouraged... but the question "is there a free way to get the software I need" is not answerable in bounded time, since there's no way to prove the negative... so I figured I'd just go ahead and ask

Thanks again for all the help and hard work!

[bmx]

you don't really need binja or ida at this point:
readelf, objdump are your friends

[sb42]

As bmx says, at this point you don't need anything more than a disassembler because the binary still has the same structure.

A simple approach is to take an existing patch, apply it to an appropriate appEntry and diff the asm listings that you obtained with objdump.  This will show you what the patch is doing.  Then look around in your newer appEntry listing and figure out where to make the same changes.  Once you know that, write the replacement byte sequences at the new offsets with a hex editor or gdb and then produce a new binary patch at the end.

When I did a patch for 01.03 I used radare2, but it was more that I wanted an excuse to play with r2 than anything else.   I found it useful that it can search for instruction sequences (/ad), and that it has a convenient write command (you can seek to an offset and say "write a nop here" and it will do the right thing), but I didn't need any of its RE features.

[Claus1]

Thanks for the hack. It worked. However my Rigol still displays model number under system information as MSO5074. Is it correct? Shouldn't it change to MSO5354?

[Noy]

Its correct.
I thought about something:  is eye and jitter measurment not functioning HW wise in MSO5000 or is it only "deactivated" in the appentry to be higher class scope only function? Could it simply be reactivated (patch to activate another "if" statement in appentry or something else)? I would like to do "simple" eyemeasurments and thought i can use persistent + pass/fail for this but it looks i cant make a fully custom masks for example for SDIO or so.
So any idea how it can be done? With siglent SDS2000x it looks like fully custom masks are drawable for pass fail? Looks like this in the flyer..
We can play doom on MSO5k why we cant add new features / additional scripts for something tike this?
Or is the issue that we can not talk to the measurment peripherals?

[omgoleus]

As bmx says, at this point you don't need anything more than a disassembler because the binary still has the same structure.

A simple approach is to take an existing patch, apply it to an appropriate appEntry and diff the asm listings that you obtained with objdump.  This will show you what the patch is doing.  Then look around in your newer appEntry listing and figure out where to make the same changes.  Once you know that, write the replacement byte sequences at the new offsets with a hex editor or gdb and then produce a new binary patch at the end.

When I did a patch for 01.03 I used radare2, but it was more that I wanted an excuse to play with r2 than anything else.   I found it useful that it can search for instruction sequences (/ad), and that it has a convenient write command (you can seek to an offset and say "write a nop here" and it will do the right thing), but I didn't need any of its RE features.

This is super helpful and so far it's going well. Quick sanity check: I ran objdump on the April and May versions of appEntry and then ran diff between the two files.

The objdump files were about 100 MB, which seems reasonable. But then the diff output was 186MB... the files are almost completely different. Is this normal for two subsequent versions of appEntry to be almost completely different by that indicator?

[tv84]

Thanks for the hack. It worked. However my Rigol still displays model number under system information as MSO5074. Is it correct? Shouldn't it change to MSO5354?

It's correct. The model only changes if you change the model, not if you do BW upgrades.

Regarding eye/jitter: Those were tested by Sighound and the machine simply doesn't have the horsepower to do such a thing! Not even the DS7000.

[Cerebus]

This is super helpful and so far it's going well. Quick sanity check: I ran objdump on the April and May versions of appEntry and then ran diff between the two files.

The objdump files were about 100 MB, which seems reasonable. But then the diff output was 186MB... the files are almost completely different. Is this normal for two subsequent versions of appEntry to be almost completely different by that indicator?

If you inspect the two files you're diffing manually, you'll probably find that there's something significantly different near the beginning that's throwing diff off and causing it to lose sync in an unrecoverable way. Try different diff options and you'll probably be able to find a combination that gives a short, sensible diff of the two files. It may be as simple as passing diff the '--minimal' option, or  paradoxically the opposite the '--speed-large-files' option.

[sb42]

This is super helpful and so far it's going well. Quick sanity check: I ran objdump on the April and May versions of appEntry and then ran diff between the two files.

The objdump files were about 100 MB, which seems reasonable. But then the diff output was 186MB... the files are almost completely different. Is this normal for two subsequent versions of appEntry to be almost completely different by that indicator?

The diff should be a few dozen lines long if you're comparing listings for the same appEntry binary, before and after applying the patch:

Code: [Select]

% diff -u ae.s ae-mod.s | diffstat
 ae-mod.s |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

If you compare two different builds (and I think there may be two of them floating around for the latest firmware version?), diff will likely be thrown off by all the symbol address differences.

[Gall]

Namely, IDA for hobbyists is $365/year and the free cloud version of Binary Ninja won't handle files larger than 15Mb.

There is Ghidra. Completely free and even better than IDA in some aspects. https://ghidra-sre.org/

[omgoleus]

This is super helpful and so far it's going well. Quick sanity check: I ran objdump on the April and May versions of appEntry and then ran diff between the two files.

The objdump files were about 100 MB, which seems reasonable. But then the diff output was 186MB... the files are almost completely different. Is this normal for two subsequent versions of appEntry to be almost completely different by that indicator?

The diff should be a few dozen lines long if you're comparing listings for the same appEntry binary, before and after applying the patch:

Code: [Select]

% diff -u ae.s ae-mod.s | diffstat
 ae-mod.s |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

If you compare two different builds (and I think there may be two of them floating around for the latest firmware version?), diff will likely be thrown off by all the symbol address differences.

Yes, I'm comparing the two builds of the latest numerical firmware version, the April build that is available at the firmware download site, and the May build that comes with new scopes.

I ran diff with the -d option that said something like "try very hard to find a minimal set of differences". It ran for six hours!!! but the output was exactly the same. So I think it's the different symbol addresses as you said, and not something near the beginning like Cerebus said.

Thanks for the sanity check, I will continue when I have time...

In case anyone is interested
https://www.dropbox.com/s/pckpka9kqjmqfo3/ae.gz.aes-128?dl=0
use the familiar BAD key

[omgoleus]

Following up... here's the diff from the unpatched objdump to the objdump of the patched appEntry, starting with the April build:

Code: [Select]

appEntry: file format ELF32-arm-little       | appEntryAprilPatched: file format ELF32-arm-little
   c6958: 01 00 00 0a beq #4 <_ZN16searchEventT |    c6958: 00 00 a0 e1 mov r0, r0
   c7210: 88 00 00 1a bne #544 <_ZN16searchEven |    c7210: 88 00 00 ea b #544 <_ZN16searchEven
   c744c: 23 00 00 0a beq #140 <_ZN16searchEven |    c744c: 00 00 a0 e1 mov r0, r0
  18c210: b3 00 00 0a beq #716 <_ZN5QListIPN8me |   18c210: 00 00 a0 e1 mov r0, r0
  18c22c: 1a 00 00 1a bne #104 <_ZN5QListIPN8me |   18c22c: 00 00 a0 e1 mov r0, r0
  3997d0: 71 00 00 0a beq #452 <_ZN12CIRQListen |   3997d0: 00 00 a0 e1 mov r0, r0
  3997ec: 06 00 00 1a bne #24 <_ZN12CIRQListene |   3997ec: 00 00 a0 e1 mov r0, r0
  44c6a4: 03 00 00 1a bne #12 <_ZN7MemFileD1Ev+ |   44c6a4: 00 00 a0 e1 mov r0, r0
  44c6a8: a9 ff ff eb bl #-348 <_ZN7MemFileD1E |   44c6a8: 01 00 a0 e3 mov r0, #1

sb42, your example showed six changes; this has nine, a group of three and then a group of six. I'm guessing that the difference is that I used the patch file from typoknig that includes the phone-home patch: https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3024342/#msg3024342

The md5 checks out before and after the patch, as per that patchfile. Seems like I'm on the right track.

Next I'll see if I can find the corresponding lines in the objdump from the May build. This is where it gets tricky!

[sb42]

sb42, your example showed six changes; this has nine, a group of three and then a group of six. I'm guessing that the difference is that I used the patch file from typoknig that includes the phone-home patch: https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3024342/#msg3024342

Sounds about right

The md5 checks out before and after the patch, as per that patchfile. Seems like I'm on the right track.

Next I'll see if I can find the corresponding lines in the objdump from the May build. This is where it gets tricky!

Yup, this is the fun part

[omgoleus]

The md5 checks out before and after the patch, as per that patchfile. Seems like I'm on the right track.

Next I'll see if I can find the corresponding lines in the objdump from the May build. This is where it gets tricky!

Yup, this is the fun part

OK, so here's the lineup of the lines-to-be-patched from the April build and the May build of 01_03_00_01:

Code: [Select]

   c6958: 01 00 00 0a beq #4 <_ZN16searchEventTable16sigCurrEventTimeEi+0x3650>
   c7210: 88 00 00 1a bne #544 <_ZN16searchEventTable16sigCurrEventTimeEi+0x4124>
   c744c: 23 00 00 0a beq #140 <_ZN16searchEventTable16sigCurrEventTimeEi+0x41cc>
  18c210: b3 00 00 0a beq #716 <_ZN5QListIPN8menu_res8RDsoViewEED1Ev+0x104d8>
  18c22c: 1a 00 00 1a bne #104 <_ZN5QListIPN8menu_res8RDsoViewEED1Ev+0x10290>
  3997d0: 71 00 00 0a beq #452 <_ZN12CIRQListener10sigHandlerEi+0x2dac>
  3997ec: 06 00 00 1a bne #24 <_ZN12CIRQListener10sigHandlerEi+0x2c1c>
  44c6a4: 03 00 00 1a bne #12 <_ZN7MemFileD1Ev+0x2344>
  44c6a8: a9 ff ff eb bl #-348 <_ZN7MemFileD1Ev+0x21e0>



Code: [Select]

   c6958: 01 00 00 0a beq #4 <_ZN16searchEventTable16sigCurrEventTimeEi+0x3650>
   c7210: 88 00 00 1a bne #544 <_ZN16searchEventTable16sigCurrEventTimeEi+0x4124>
   c744c: 23 00 00 0a beq #140 <_ZN16searchEventTable16sigCurrEventTimeEi+0x41cc>
  18c1c8: b3 00 00 0a beq #716 <_ZN5QListIPN8menu_res8RDsoViewEED1Ev+0x104d8>
  18c1e4: 1a 00 00 1a bne #104 <_ZN5QListIPN8menu_res8RDsoViewEED1Ev+0x10290>
  399770: 71 00 00 0a beq #452 <_ZN12CIRQListener10sigHandlerEi+0x2dac>
  39978c: 06 00 00 1a bne #24 <_ZN12CIRQListener10sigHandlerEi+0x2c1c>
  44c644: 03 00 00 1a bne #12 <_ZN7MemFileD1Ev+0x2344>
  44c648: a9 ff ff eb bl #-348 <_ZN7MemFileD1Ev+0x21e0>



That worked surprisingly well.
For the benefit of future generations, rather than giving verbal step-by-step instructions I'll just include the bash script I used to get this comparison. This should serve as completely comprehensible instructions for anyone comfortable with the Unix command line while not making it *too* easy for a beginner to get themselves into deep trouble. Edit: see my newer message for the complete version of this shell script and some info about it, as well as the final patch itself. https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3344172/#msg3344172

[bmx]

add a pinch of c++filt, and you're set

[mabl]

BTW, you can SCP your patched binary for testing to /tmp and mark it executable. appEntry runs from everywhere. That prevents any chance of bricking the device. 

[omgoleus]

add a pinch of c++filt, and you're set

Huh, interesting idea, would make it more pleasant for sure... but doesn't seem to work? Any idea why?

Code: [Select]

(base) omgoleus@slick-biscuit 01_03_00_01_May % c++filt <appEntryApril_diffpre
01 00 00 0a beq #4 <_ZN16searchEventTable16sigCurrEventTimeEi+0x3650>
88 00 00 a bne #544 <_ZN16searchEventTable16sigCurrEventTimeEi+0x4124>
23 00 00 0a beq #140 <_ZN16searchEventTable16sigCurrEventTimeEi+0x41cc>
b3 00 00 0a beq #716 <_ZN5QListIPN8menu_res8RDsoViewEED1Ev+0x104d8>
a 00 00 a bne #104 <_ZN5QListIPN8menu_res8RDsoViewEED1Ev+0x10290>
71 00 00 0a beq #452 <_ZN12CIRQListener10sigHandlerEi+0x2dac>
06 00 00 a bne #24 <_ZN12CIRQListener10sigHandlerEi+0x2c1c>
03 00 00 a bne #12 <_ZN7MemFileD1Ev+0x2344>
a9 ff ff eb bl #-348 <_ZN7MemFileD1Ev+0x21e0>


[omgoleus]

BTW, you can SCP your patched binary for testing to /tmp and mark it executable. appEntry runs from everywhere. That prevents any chance of bricking the device. 

Huh wow, that's kind of amazing, I didn't think of that. If you execute it at the command line does it simply take over from the currently running instance, or do you have to kill the process first?

I am very curious what it will look like on the scope screen when I kill appEntry... lol
 

[bmx]

$ objdump ... file | sed ... | awk ... | whatever ... | c++filt

   c6958:       01 00 00 0a     beq     #4 <searchEventTable::sigCurrEventTime(int)+0x3650>
   c7210:       88 00 00 1a     bne     #544 <searchEventTable::sigCurrEventTime(int)+0x4124>
   c744c:       23 00 00 0a     beq     #140 <searchEventTable::sigCurrEventTime(int)+0x41cc>
  18c210:       b3 00 00 0a     beq     #716 <QList<menu_res::RDsoView*>::~QList()+0x104d8>
  18c22c:       1a 00 00 1a     bne     #104 <QList<menu_res::RDsoView*>::~QList()+0x10290>
  3997d0:       71 00 00 0a     beq     #452 <CIRQListener::sigHandler(int)+0x2dac>
  3997ec:       06 00 00 1a     bne     #24 <CIRQListener::sigHandler(int)+0x2c1c>
  44c6a4:       03 00 00 1a     bne     #12 <MemFilqe::~MemFile()+0x2344>
  44c6a8:       a9 ff ff eb     bl      #-348 <MemFile::~MemFile()+0x21e0>

[simogi]

Good evening,

I just bought a 5000 series rigol, which hasn't arrived yet by the way.

And I came across this forum.

I have read a few things but I have some doubts.

Obviously they are easy doubts.

The rigol will have a linux distribution for ARM how do you use objdump etc. on linux x86 or x64 (should you use a cross-compiled )?

Another question, since there is the option to allow backup (I saw "backup.doc" among your files)
isn't it easier to download everything and decrypt the root pass in passwd? (always with the method given by you "hashcat64.exe")

Regards

Simogi

[omgoleus]

$ objdump ... file | sed ... | awk ... | whatever ... | c++filt

   c6958:       01 00 00 0a     beq     #4 <searchEventTable::sigCurrEventTime(int)+0x3650>
   c7210:       88 00 00 1a     bne     #544 <searchEventTable::sigCurrEventTime(int)+0x4124>
   c744c:       23 00 00 0a     beq     #140 <searchEventTable::sigCurrEventTime(int)+0x41cc>
  18c210:       b3 00 00 0a     beq     #716 <QList<menu_res::RDsoView*>::~QList()+0x104d8>
  18c22c:       1a 00 00 1a     bne     #104 <QList<menu_res::RDsoView*>::~QList()+0x10290>
  3997d0:       71 00 00 0a     beq     #452 <CIRQListener::sigHandler(int)+0x2dac>
  3997ec:       06 00 00 1a     bne     #24 <CIRQListener::sigHandler(int)+0x2c1c>
  44c6a4:       03 00 00 1a     bne     #12 <MemFilqe::~MemFile()+0x2344>
  44c6a8:       a9 ff ff eb     bl      #-348 <MemFile::~MemFile()+0x21e0>

I piped that same text into c++filt and it didn't do what you're showing. Looking at the documentation, as well as your example, it does not appear that there should be any special tricks or command line options needed; it should take this objdump text as input and spit out a demangled output.

Edit: I figured it out. Mac OS X comes with objdump from llvm and also c++filt that claims to be gnu. Neither of them work. However, if I install gnu binutils with homebrew, then the new gnu versions both work. 

Also, the version of grep in Mac OS X has had a bug for ten years that hasn't been fixed: https://unix.stackexchange.com/questions/8892/trouble-with-grep-o-regex
yikes! careful if you're doing Unix development on a Mac!

Thanks!

[omgoleus]

Woot, at the stroke of midnight the beast came to life!
This was my hand-edited appEntry running out of /tmp. I have to say, I was a little disappointed. when I did kill -9 of the appEntry process, nothing happened... It should be cool like in Tron when they shut down the Master Control Program...

The patch file and patch.txt for the May build of firmware 01.03.00.01 is attached. These are used with mabl's autopatcher. They are based on the version of the patch in this message from typoknig which includes the patch to disable phone-home.

Here's the contents of the patch.txt file:

Code: [Select]

file_to_patch=/rigol/appEntry
file_to_patch_md5sum=783a31ebdc0d4acb7b9dc244155ba1c6
patch_file=mayBuildPatch.bspatch
after_patch_md5sum=7e39040bfb086c666be3e7cc87dd73b0

I'm also attaching the final version of my shell script that uses objdump and diff to find the difference between the original and patched version of an older executable, and then figures out what file offsets need to be hex-edited in the newer executable to manually recreate the patch. Doing this in a shell script was way more complicated than doing it manually and in fact I made the patch and then went back and spent a full day making a shell script to recreate exactly what I did manually... but for me, this feels better than writing out step-by-step instructions. It only took so long because (repeating what I said before) the included version of various command line utilities on Mac... kind of suck...

If you want to use this script, be sure to read the comments carefully. I refer to gobjdump and gsed for the gnu versions, gnu would probably be the default versions if you're on Linux, so you'd have to fix that. Also I use associative arrays and the syntax is slightly different in zsh versus bash4 but I included both in comments. Also note that this script just finds the file offsets you need to edit; you have to do the editing yourself with a hex editor. I had to draw the line somewhere!

I'd like to thank the people in the last few days of messages who offered help... you can see who they are by scrolling back. I probably could have got it to work simply based on the info that already existed in the thread, but it would have taken a lot longer and involved a lot more trial and error and a lot more anxiety about flying blind and worrying that I was going to brick my scope. I especially want to observe, for the benefit of anyone else thinking about doing this from scratch, that the most useful piece of information was sb42 telling me the number of lines of diff to expect between patched and unpatched and clarifying my misunderstanding about diff between different versions. A close second was bmx and sb42 pointing me in the direction of objdump rather than a full reverse engineering tool.

Finally, mabl you were totally right that this was rewarding to figure out!

For completeness, here's the instructions for someone who just wants to patch:
1. In this message mabl posted the "auto patcher".
2. Download that and rename it to remove the .txt (Make sure you actually remove the .txt extension, don't be fooled by your stupid gui.)
3. Check the "About" menu on your scope to see what version and build of firmware you have. If you have a new scope as of the date of this message it probably has 01.03.00.01 with a build date of May. For that version/build you can use the patch file and patch.txt attached to this message. Otherwise you have to search.
4. Follow the instructions in mabl's message. You will know it works because the screen will turn white with text and give you some "hit any key" prompts.
5. If it doesn't get to that screen, it's probably because you're using too large of a flash drive or it's formatted wrong or the file still has a .txt extension.
6. If the black on white text tells you that it worked, it takes a pretty long time (1 minute) for anything else to happen. that's normal.
7. If it got that far but then the licenses don't show up, then you'll have to do some deeper troubleshooting.
8. If your scope becomes non-functional try turning it off and then back on again. If that doesn't work, then you will have to use the "secret menu" and restore the firmware. This is not that hard, but you'll have to search through the thread if it comes to that.
9. At the present time the collective wisdom of this community seems to agree that it is impossible to permanently brick your scope. Restoring firmware via secret menu is the worst case scenario.
10. I think, maybe, you're supposed to use the scope's menus to run its auto-calibration routine once you've done the upgrade?

[calippo]

Hello guys, I know I am not the first and I won't be last asking this... so try to understand.... probably some of you went already through the pain of reading this massive thread... 

Is there a comprehensive tutorial or sticky post that collects all steps to update the fw in order to unlock all the features of the MSO5074 I am planning to buy?

Again, my apologies to ask again, but due the lack of the sticky post on page #1... is quite hard to find where to start or a proper howto. 

Cheers mates and stay safe!

[omgoleus]

Hello guys, I know I am not the first and I won't be last asking this... so try to understand.... probably some of you went already through the pain of reading this massive thread... 

Is there a comprehensive tutorial or sticky post that collects all steps to update the fw in order to unlock all the features of the MSO5074 I am planning to buy?

Again, my apologies to ask again, but due the lack of the sticky post on page #1... is quite hard to find where to start or a proper howto. 

Cheers mates and stay safe!

See my message above yours, I edited it to include everything you need.