Hacking the HDO1k/HDO4k Rigol 12 bit scope

[egonotto]

Hello,

perhaps the glitch is due to the fact that there are only 256 MS and the memory is therefore overwritten.

Best regards
egonotto

[zrq]

This is probably too good to be true. (I know you are going to say Nyquist bla bla, but forgive me for this time).

Achieved by frida hooking _ZN11CApiLicense18check_BandWidthOptE7OptType and installing :SYST:OPT:INST HDO1000-BW2T8
-> this will fail the AC amplitude SPC, so not necessary useful.

[TurboTom]

I've seen the same glitch when I configured my DHO1074 as DHO4204. I guess that the second ADC may be expected/configured to sample at a phase delay, and thus the memory contents is "interpreted" with this phase incontinuity which the single ADC of course won't provide. But if the 250MSa configuration works satisfactorily, who would complain ? 

[Martin72]

Nyquist bla bla

Harry is like Gandalf...

[TurboTom]

This is probably too good to be true. (I know you are going to say Nyquist bla bla, but forgive me for this time).

Achieved by frida hooking _ZN11CApiLicense18check_BandWidthOptE7OptType and installing :SYST:OPT:INST HDO1000-BW2T8

-> this will fail the AC amplitude SPC, so not necessary useful.

Why? Single channel may just work. But this would require us to get the 50Ohm input branch going reliably. The fun thing would be that in this case, FFT could be used up to this frequency as well. 

[ebastler]

This is probably too good to be true. (I know you are going to say Nyquist bla bla, but forgive me for this time).
Achieved by frida hooking _ZN11CApiLicense18check_BandWidthOptE7OptType and installing :SYST:OPT:INST HDO1000-BW2T8

Maybe the sweet spot would be the 400 MHz bandwidht option, which could still be used in two-channel mode?

The DHO4000 lets the user select between 20 MHz, 200 MHz and full bandwidth filters in the frontend, according to the user manual. This would be very useful in an upgraded DHO1000 too, so one can switch the filters to 200 MHz when using more than two channels. Is this already enabled by your hack, or could you add it?

[ebastler]

I just tried the default SPC again, and seemingly the offset is gone ??
Another undesirable side effect is after the _Z20API_GetProductSeriesv patch, the bandwidth options are no longer accepted. I tried all different combinations but none of them worked. It should be easy to patch though.

The 500 Mpts doesn't seem to work. There is always a glitch on the waveform, likely caused by corruption of memory, but 250Mpts seems to look fine. (uninstall the RLU option to avoid using the nonexistent memory).

Achieved by frida hooking _ZN11CApiLicense18check_BandWidthOptE7OptType and installing :SYST:OPT:INST HDO1000-BW2T8
-> this will fail the AC amplitude SPC, so not necessary useful.

Just wondering -- what is the current state of affairs regarding this very promising hacking approach? In my understanding:

• 50 Ohm terminators can be enabled from the GUI, are active, and are included in the auto-calibration. (Is the calibration reproducible now? Seems it went wrong initially?)
• Advanced decoders and triggering, as well as power analysis (?), can be enabled.
• 800 MHz and presumably also 400 MHz bandwidth can be enabled. Is the selectable front-end bandwidth from the DHO4000 (20 MHz, 200 MHz, full bandwidth) available too?
• 500 MPts memory does not work, presumably because it is not installed and/or requires the second ADC channel. 250 MPts do work.

Is that about right? Any comments on the questions above would be appreciated!

[zrq]

I'm sorry but unfortunately, I have to lower your guys expectation. I only meant to show what is possible, give all the hints and encourage others to take this job or even find a better way for hacking these scopes. If someone can try to follow what I posted and do more investigation, it would be nice.
I don't have enough time to maintain a patched version of the Auklet.apk as I have a >130% day job. Especially this will need to be adapted to every future firmware revision. Rigol did hackers a great favor: not obfuscating the java code and not striping symbols in the native binary, but this can change at anytime, if our hacking got above their radar. Also I'm afraid of legal issues too, particularly when living in countries with better enforced IP laws, posting on a forum without using Tor and really don't want to be kicked back to China.

Just wondering -- what is the current state of affairs regarding this very promising hacking approach? In my understanding:

• 50 Ohm terminators can be enabled from the GUI, are active, and are included in the auto-calibration. (Is the calibration reproducible now? Seems it went wrong initially?)

I couldn't get enough time to investigate this, so far it seems the SPC doesn't fully solve the offset issue. The 50 Ohm offset can be removed, but the 1 MOhm path shows a 13 mV offset at 100 mV/div. Sorry I have to strike this out again, maybe it's my fault, I was messing with DrvChannel_SetScale.

• Advanced decoders and triggering, as well as power analysis (?), can be enabled.

Also didn't have time to try. Power analysis seems functional.

• 800 MHz and presumably also 400 MHz bandwidth can be enabled. Is the selectable front-end bandwidth from the DHO4000 (20 MHz, 200 MHz, full bandwidth) available too?

I have roughly tested the bandwidth with a VCO, what I can say for sure is the bandwidth is certainly beyond 200 MHz. If only API_GetProductSeries is patched, there will be a serious problem that if the bandwidth limit is enabled, it can never be disabled. (hint: DrvChannel_SetBandLimit)

• 500 MPts memory does not work, presumably because it is not installed and/or requires the second ADC channel. 250 MPts do work.

Yes this is what I observed.

If someone is going to look into this deeper, try reading the references to DevSystem_GetProductSeries might be helpful. Simply patching it out for 4000 will not work as it will mess up with the acquisition.

[ebastler]

Thank you for the update, zrq. I understand your concerns, and you are obviously under no obligation to any of us.

Personally I'm not the right guy to take over -- I lack any Android development experience, and diving into it is not what I would enjoy doing as a hobby. So I'll keep my fingers firmly crossed that someone with the right expertise, interest in an upgraded DHO1000, and some spare time will come forward. I am happy to buy them a fews pizzas, coffee or whatever it takes!

[x33yp]

Wow in the last 2 months there's been awesome headway by zrq and many others
I really do hope someone will release some patch file the smali or something so we know what to change.
It seems based on all the comments like the safest way to modify it is an separate APK with the hacks applied.
Really looking forward to what you guys find in the next few months

[Dennis Frie]

Code: [Select]

echo "127" > /sys/devices/platform/pwm_fan/hwmon/hwmon5/pwm1does it lower the speed?

Nice, this indeed works fine (just need to "su" first).

You force the fan speed at each startup by adding a command at the end of the /rigol/shell/start_rigol_app.sh file.
You can do it this way:

Code: [Select]

echo 'su -c "sleep 10; echo 63 > /sys/devices/platform/pwm_fan/hwmon/hwmon5/pwm1" &' >> /rigol/shell/start_rigol_app.sh

Note that the main app starts after this scripts and overwrite the fan speed, hence the "sleep 10" and the "&" so that this commands actually executes after the main app has set the fan speed.

Trying to play with the FAN, I've noticed the hwmon5 directory is gone. Seems like it's moved to hwmon1 instead of hwmon5. Replacing hwmon5 with hwmon1, everything works as expected.
Adding the line to start_rigol_app.sh works like a charm, appreciated.

The sound is much more pleasant with the lower fan speed. Time will tell, if temperature is a concern.

Tested on DHO1074 with FW 2.12

[TurboTom]

Works a treat, fan RPM can be reduced considerably without obvious excessive silicon temperatures. But the noise reduction (at least from a disturbance point of view) can be considered only marginal. The main source of the noise is the commutation noise of the dual fans in the scope which appear to be of decent quality, but are unfortunately the "thick" server type variety and hence inherently not the quitest.

And then there's the slight RPM interference of the dual fan arrangement which also contributes to the "annoyance level"  .

Whatsoever, the fan speed reduction definitely is an improvement, but to really silence the scope, my take is that the fans would need to be replaced.


P.S. Funny enough, on my scope the directory was "hwmon0" 

[lownoise]

Whatsoever, the fan speed reduction definitely is an improvement, but to really silence the scope, my take is that the fans would need to be replaced.


Agreed
I replaced the original Fans Protechnic MGA6012MR-O15 (60x15) with Noctua NF-A6x25 - they fit 1:1 without any problems.
I have also fitted silicone frames under the fans.
The airflow and temperatures are the same, but the noise level is pleasantly quiet now

[Randy222]

Most "fellas" interested in Rigol's DHO 800/900/1k/4k may have followed the other thread about the broken FlatTop FFT window function. I wrote a small basic (yes, really!  ) program that calculates the correct window file -- the windows executable is attached. Here's how to replace the broken file:

You need to have the ADB toolkit downloaded on your PC and the simplest way is to have the newly generated window file placed in the same directory.



Now your scope should restart and activate the new FFT FlatTop window file.

This step-by-step walkthrough was probably "Kindergarten" for many but it may help those who never ever typed on a unix terminal... 

How do you run the exe? Just run it w/o any arguments and it creates a hex file on my Windows PC? I run it and all I see is "Processing File Position"

[TurboTom]

Yes, just run it (you can use a command window) and it generates the parameters file in the same directory where the EXE is located. The counter runs up to one million (2^20) since that's the number of coefficients that are generated. It takes quite some time since the coefficients are calculated with four parametrized trigonometric values each. The numbers in the file are 32 bit float, little endian, simply merged one after another, hence the size is 4x2^20 byte. Good luck!

[Randy222]

Yes, just run it (you can use a command window) and it generates the parameters file in the same directory where the EXE is located. The counter runs up to one million (2^20) since that's the number of coefficients that are generated. It takes quite some time since the coefficients are calculated with four parametrized trigonometric values each. The numbers in the file are 32 bit float, little endian, simply merged one after another, hence the size is 4x2^20 byte. Good luck!

I gonna dump it onto a DHO800.
Thanks. 

[Dennis Frie]

The signature checks are very annoying, now getting this for modified package name.

Code: [Select]

Failure [INSTALL_FAILED_SHARED_USER_INCOMPATIBLE: Package couldn't be installed in /data/app/com.riglol.scope-1: Package com.riglol.scope has no signatures that match those in shared user android.uid.system; ignoring!]

https://stackoverflow.com/questions/17222535/create-system-application

Update: I made it! repacking the patched apk with a changed package name (also changed provider names) in the manifest, then also change the android:sharedUserId="org.riglol" rather the system uid, repack and resign, adb push install and then it should work! just note that you need to use
am start -n com.riglol.scope/com.rigol.scope.MainActivity
to invoke the correct activity after changing the package name.
50 Ohm with UI, 500Mpts memory and all the advanced decoding seems available!
There is even some weird mechanism to let the scope start the patched app instead of the normal scope app by default on the next boot,  , so it can be a untethered hack.

I'd like to post more details, but not tonight, I need sleep for tomorrow's day job.

I've now decompiled the Auklet.apk, added a few "upgrades" and recompiled it again. So far so good. Browsing the newly compiled apk-file using jadx shows, that the changes are as expected 
The apktool and jadx works like a charm by the way.
However, I'm a bit stuck with the certificates.

I've changed the following in the Manifest, but that's not enough;
android:sharedUserId="org.riglol"
package="com.riglol.scope"

I've tried adding "riglol" to all provider fields in the manifest, but no luck. Still get the "Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES error

I'm a bit stock on the "Provider", "resign" and "package name". Care to add a few hints  ? Have you gone through Zipalign and sign to get around the certificate error? I've tried to zipalign and sign with a new keystore with the changes to the manifest, but ends up with the error "INSTALL_FAILED_INVALID_APK: Failed to extract native libraries, res=-2]

On a sidenote, to verify that I can start an application through the adb I tested the help-menu, using the same style you suggested, works perfect
$ am start -n com.rigol.floatbrowser/com.rigol.floatbrowser.MainActivitycom.riglol.scope/com.rigol.scope.MainActivity

[zrq]

The signature checks are very annoying, now getting this for modified package name.

Code: [Select]

Failure [INSTALL_FAILED_SHARED_USER_INCOMPATIBLE: Package couldn't be installed in /data/app/com.riglol.scope-1: Package com.riglol.scope has no signatures that match those in shared user android.uid.system; ignoring!]

https://stackoverflow.com/questions/17222535/create-system-application

Update: I made it! repacking the patched apk with a changed package name (also changed provider names) in the manifest, then also change the android:sharedUserId="org.riglol" rather the system uid, repack and resign, adb push install and then it should work! just note that you need to use
am start -n com.riglol.scope/com.rigol.scope.MainActivity
to invoke the correct activity after changing the package name.
50 Ohm with UI, 500Mpts memory and all the advanced decoding seems available!
There is even some weird mechanism to let the scope start the patched app instead of the normal scope app by default on the next boot,  , so it can be a untethered hack.

I'd like to post more details, but not tonight, I need sleep for tomorrow's day job.

I've now decompiled the Auklet.apk, added a few "upgrades" and recompiled it again. So far so good. Browsing the newly compiled apk-file using jadx shows, that the changes are as expected 
The apktool and jadx works like a charm by the way.
However, I'm a bit stuck with the certificates.

I've changed the following in the Manifest, but that's not enough;
android:sharedUserId="org.riglol"
package="com.riglol.scope"

I've tried adding "riglol" to all provider fields in the manifest, but no luck. Still get the "Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES error

I'm a bit stock on the "Provider", "resign" and "package name". Care to add a few hints  ? Have you gone through Zipalign and sign to get around the certificate error? I've tried to zipalign and sign with a new keystore with the changes to the manifest, but ends up with the error "INSTALL_FAILED_INVALID_APK: Failed to extract native libraries, res=-2]

On a sidenote, to verify that I can start an application through the adb I tested the help-menu, using the same style you suggested, works perfect
$ am start -n com.rigol.floatbrowser/com.rigol.floatbrowser.MainActivitycom.riglol.scope/com.rigol.scope.MainActivity

Provider means the "provider" entries in the manifest XML, it have to be changed to avoid conflict with the original app that is not uninstalled.
Resigning the APK means aligning and signing with a tool like https://github.com/patrickfav/uber-apk-signer .
Also in my understanding, many of the model series dependent behavior is in the .so native binary where the heavy lifting is done, so patching only the smali with jadx would not be sufficient.

[Dennis Frie]

Got it. Changing android:extractNativeLibs="false" to android:extractNativeLibs="true" did the trick. The other changes to the manifest, signing etc. was all correct .
I'm now able to install the recompiled application and run it. I will not be able to do further testing over Christmas, but one step further.

Uninstalling using .\adb uninstall com.riglol.scope and reinstalling the same re-compiled apk again works fine

Seems like there's some references to a few options not officially available. I wonder if they work

Code: [Select]

    @Override // com.rigol.scope.data.BaseParam
    public void readAll() {
        super.readAll();
        readInfo();
        read(ServiceEnum.OptType.OPT_COMP);
        read(ServiceEnum.OptType.OPT_EMBD);
        read(ServiceEnum.OptType.OPT_AUTO);
        read(ServiceEnum.OptType.OPT_FLEX);
        read(ServiceEnum.OptType.OPT_AUDIO);
        read(ServiceEnum.OptType.OPT_AERO);
        read(ServiceEnum.OptType.OPT_EYE);
        read(ServiceEnum.OptType.OPT_JITTER);
        read(ServiceEnum.OptType.OPT_RTSA);
        read(ServiceEnum.OptType.OPT_CM_USB);
        read(ServiceEnum.OptType.OPT_CM_ENET);
        read(ServiceEnum.OptType.OPT_CM_MIPI);
        read(ServiceEnum.OptType.OPT_RLU);
        read(ServiceEnum.OptType.OPT_UPA);
        read(ServiceEnum.OptType.OPT_BW7T10);
        read(ServiceEnum.OptType.OPT_BW7T20);
        read(ServiceEnum.OptType.OPT_BW10T20);
        read(ServiceEnum.OptType.OPT_BW2T4);
        read(ServiceEnum.OptType.OPT_BW2T8);
        read(ServiceEnum.OptType.OPT_BW4T8);
        syncData(MessageID.MSG_LICENSE_CHANGED, true);
    }

[DigitalDeath]

Is there some place where the instructions for the hack are available?
I have Rigol DHO1074 and wanted to do the hack but I can’t figure out where to find the files and instructions for the hack.

Thanks in advance.

[Dennis Frie]

If you look at reply #457 there's a pretty well documented approach to unlocking all options available for your model.

Changing the application to unlock features only available on the 4000 series is still ongoing, but zrq did some  great work so far.

[DigitalDeath]

Thank you very much 😊

[DigitalDeath]

I was reading the reply and wanted to ask you something. Does that reply apply also to the Rigol DHO1074?

[ebastler]

I was reading the reply and wanted to ask you something. Does that reply apply also to the Rigol DHO1074?

Please read the next four posts or so as well which follow #457.

[DigitalDeath]

I see. Thanks for the clarification. I really appreciate it 😊