Hacking the Rigol MSO5000 series oscilloscopes

[oliv3r]

so far, rough diff is:

app.img:

shell/start.sh          # add -average_filter option to appEntry
shell/send_mail.sh  # finally! add model/version/serial/date to the body 
resource/scpi/MEAsure.xml # cmd id + 1??
bunch of other xml, hlp or hex files
appEntry (of course)
default/precision.hex
K160_TOP.bin

(edit) many many changes in appEntry, hard to diff, but so far, no change about our prefered start option.

system.img:

/etc/passwd                 #we already knew that
/etc/init.d/rcS              # remove echo ++ Starting ftp daemon
/etc/inittab                  # swap shell on ttyPS0 from /bin/ash to /bin/login, huh?
+/etc/passwd.root       # this is the old one
- /lib/firmware/rtfwifi/rtl{8812,8192}*.bin # bye bye

I wonder how it compares to the MS07000 firmware

The change from ash to login is so that you have to log in using the serial shell. While it makes sense, it's annoying :p

as for the wifi; I don't think they had the kernel module; so the firmware's didn't do much anyway.

[rgwan]

Well, that proved that the 1.1.2.4 version firmware isn't the new firmware that Rigol solved this three issues.

[rgwan]

But one interesting thing is they haven't disabled sshd yet. Although my worries come true, I still don't know why they don't disable it.

[Rerouter]

However, what if it is NOT a hacked firmware, but the actual firmware from the device. Just extracted from. Like in this case u-boot. I don't see how that would be wrong?

That's something I would like clarification on as well, my guess is no, because "copyright" but I'm curious because over on the siglent side of the fence I have been typo patching. does nothing to bypassing features, just fixes typos that where present that broke a few existing commands.

[tv84]

I did a search for all types of start options and here is a list:

Code: [Select]

-notrace_ch     servtrace.cpp
-notrace_digi   servtrace.cpp
-notrace_eye    servtrace.cpp
-notrace_dx     servtrace.cpp
-notrace_la     servtrace.cpp
-log_trace      servtrace.cpp
-log_ch         servtrace.cpp
-log_la         servtrace.cpp
-log_eye        servtrace.cpp
-no_trace       tracethread.cpp  (trace not running)
-debug
-fullopt
-novcal             (calibration??)
-no_cfg         cdsophy.cpp
-noprivacy      servdso_session.cpp
-default        servdso_session.cpp (default settings)
-nonv
-ds8000         
-log_id         dsoengine_trace.cpp
-no_horiplay    dsoengine_playback.cpp
-log_engine     dsoengine_playback.cpp
-log_adc_cal    cdsorecengine_adc.cpp
-log_hori       cdsorecengine_hori.cpp
-noinit         cplatform.cpp
-no_autoplay    cdsoautostopengine.cpp
-log_afe        chcal.cpp
-average_filter cdsorecengine_ch.cpp
-peak_compress  horiunit.cpp
-wait_assert    iphyccu.cpp
On the right is the source code module that (I think) relates to it.

If anyone wants to do experiments and share their discoveries...


ATTENTION: use at your own risk; you may brick your scope!

[Noy]

 -DS8000

[oliv3r]

-DS8000

But what about DS9000! That would be over 9000 easy!

Code: [Select]

USB device disconnected
DS7000Update.GEL
MSO8
DS8000Update.GEL
MSO5
DS5000Update.GEL
MSO9
DS9000Update.GEL
media
RIGOL TECHNOLOGIES,DS1000Z,SPARROW,201212

Looks like appEntry even borrows some code from the faithful sparrow line of devices!

For me, that's the trigger to get a MSO5000 now

There will be others based on the zynq platform; but there won't be a cheaper variant. Rigol may 'upgrade' the ancient DS1000Z series (DS3000?) or whatever but I doub't they'll do anything cheaper then the MSO5k. So I think Rigol wants the hacker/cheap market with the good old DS1000Z and the MSO5000 series is the first one up after that.

(I was thinking of getting a DS1000Z last year after being quite happy with my really old DS1052E, and a DS1054Z at work. I was in the 'hmm they are quite old platforms, I wonder when rigol will release an upgrade to these aging platforms. So it turns out to be the MSO5k series. And while I'd prefer to wait for a v2 hardware version (who knows what bugs linger in the current one) I think this is as good as it'll get for the next 10 years anyway in the low-budget end).

[EddyCurrent]

Luckily, the MSO5000 is not the first platform, which operates their Phoenix chip. I guess, they already made improvements in the first issue of MSO5000 (improved cooling of analog frontend e.g.) compared to MSO7000. This lowers risk of purchasing a buggy hardware. By the way, my first post on EEVblog plus I ordered a MSO5000 as well 

[tv84]

Interesting piece of code:

Code: [Select]

    deb_msg(&v7, "servrecord_spy.cpp", 120, "void servRecord::disable_xxx(servRecord::RecordState)");
    QMessageLogger::debug(&v6);
    v3 = sub_43774(&v6, "servrecord_spy.cpp");
    v4 = sub_4F428(v3);
    v5 = sub_43774(v4, "stat:");
    sub_4F428(v5);
    result = QDebug::~QDebug(&v6);

[mrpackethead]

Spy as in spy on what you are doing and send it somewhere?

Interesting piece of code:

Code: [Select]

    deb_msg(&v7, "servrecord_spy.cpp", 120, "void servRecord::disable_xxx(servRecord::RecordState)");
    QMessageLogger::debug(&v6);
    v3 = sub_43774(&v6, "servrecord_spy.cpp");
    v4 = sub_4F428(v3);
    v5 = sub_43774(v4, "stat:");
    sub_4F428(v5);
    result = QDebug::~QDebug(&v6);

[Rerouter]

doesn't quite read that way to me unless it ties into a much larger function, looks more like a thread hook to request a status string??

sub_43774 looks to be what pushes out a message and returns the value.

[mrpackethead]

Any guess's as to what -ds8000 does?  I'll give this a whirl in a few weeks, but curious to kno...

I did a search for all types of start options and here is a list:

Code: [Select]

-notrace_ch     servtrace.cpp
-notrace_digi   servtrace.cpp
-notrace_eye    servtrace.cpp
-notrace_dx     servtrace.cpp
-notrace_la     servtrace.cpp
-log_trace      servtrace.cpp
-log_ch         servtrace.cpp
-log_la         servtrace.cpp
-log_eye        servtrace.cpp
-no_trace       tracethread.cpp  (trace not running)
-debug
-fullopt
-novcal             (calibration??)
-no_cfg         cdsophy.cpp
-noprivacy      servdso_session.cpp
-default        servdso_session.cpp (default settings)
-nonv
-ds8000         
-log_id         dsoengine_trace.cpp
-no_horiplay    dsoengine_playback.cpp
-log_engine     dsoengine_playback.cpp
-log_adc_cal    cdsorecengine_adc.cpp
-log_hori       cdsorecengine_hori.cpp
-noinit         cplatform.cpp
-no_autoplay    cdsoautostopengine.cpp
-log_afe        chcal.cpp
-average_filter cdsorecengine_ch.cpp
-peak_compress  horiunit.cpp
-wait_assert    iphyccu.cpp
On the right is the source code module that (I think) relates to it.

If anyone wants to do experiments and share their discoveries...


ATTENTION: use at your own risk; you may brick your scope!

[rgwan]

Finally, I got the scope. Its firmware version is 1.1.2.3. So, I have to wait for new firmware...

[Swap_File]

This won't help rgwan, but if anyone is looking for specific versions of the firmware:

Reply #396 has a copy of 1.1.2.3
Reply #445 has a copy of 1.1.2.4
Reply #386 has a modified copy of 1.1.2.3 that you can apparently downgrade to from 1.1.2.4

[rgwan]

New bug found, signal generator frequency rounding off error. It causes non-synchronous between two channels.

For example, you can't output 1MHz and 12MHz by this scope and get a stable display on a scope, because the frequency of "12MHz output" / 12 does not exactly equal "1MHz output", in some scenario it will cause low-frequency oscillation.

[oliv3r]

Happy New Year all,

and with the new year I present to you the GEL unpacker and firmware analysis repo

https://gitlab.com/riglol/rigolee

[mrpackethead]

Nice work Oliver.

[bmx]

@Oliv3r, thanks for the qspi push, but could you fix the missing / at col2 line 1 in qspi_unpack.sh and remove the -eu also?

[tv84]

Has anyone done a bandwidth sweep with -fullopt and -ds8000 simultaneously?

[mrpackethead]

Has anyone done a bandwidth sweep with -fullopt and -ds8000 simultaneously?

What are you thinking might happen?     I need some high speed signal generators it seems.

[tv84]

I need some high speed signal generators it seems.

Precisely that.

[mrpackethead]

I need some high speed signal generators it seems.

Precisely that.

I'll get my scope mid next week,  though i'll not be in teh lab. ( picking it up in teh US, on my way home )..
Can we restore the scope if we brick it yet?

[tv84]

I need some high speed signal generators it seems.

Precisely that.

I'll get my scope mid next week,  though i'll not be in teh lab. ( picking it up in teh US, on my way home )..
Can we restore the scope if we brick it yet?

You have to do it with uboot, via serial port (requires open the box). Or JTAG...

First thing is do a NAND dump.

[mrpackethead]

I need some high speed signal generators it seems.

Precisely that.

I'll get my scope mid next week,  though i'll not be in teh lab. ( picking it up in teh US, on my way home )..
Can we restore the scope if we brick it yet?

You have to do it with uboot, via serial port (requires open the box). Or JTAG...

First thing is do a NAND dump.

I'm ok, with opening the box.

[nimish]

Anyone played around with trying to make the fullopt stuff permanent? Tried Radare2 but I am not that great with it and appEntry is huge.