Hacking the Rigol MSO5000 series oscilloscopes

[srjaynes49]

The reason I loath "modified sine-wave" inverters:  the crappy wave-form is from a fairly expensive portable inverter with built-in Glass-Mat battery .  It can product 400 watts of crappy 120 volts.  The SMOOTH sine-wave is from my Xantrex 2.0 Pro 2KW inverter.  Cleaner than my local utility!  The Xantrex inverter is accompanied by FOUR 105 Ahr golf-cart batteries and is installed in my 5th wheel trailer with five 100 watt solar panels and associated charge controller, etc.  I HAVE powered my MSO5000 from the Xantrex's output and it is of course happy as a clam.  I won't subject the MSO5000 to the crappy 120 volt "modified sine-wave" inverter's output.

 [attach=2][attach=1]

[mabl]

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.

[omgoleus]

I'm not sure if it's too subtle or if I read it and not figured that was it.

"Easy way".

I'm continuing to fine-tooth-comb my re-reading and caught this...
But the license generator from r***n doesn't really seem to exist? Or, I noticed that some of their posts have apparently been deleted, was this license generator posted and then deleted?

[tv84]

Or, I noticed that some of their posts have apparently been deleted, was this license generator posted and then deleted?

No, such a thing was never made public.

[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