Hacking the Rigol DHO800/900 Scope

[Mechatrommer]

The following is the logical pseudocode for a few key functions:

so the RK3399 pins 122-126 are set as output, and then later stage  gpio_afg_drv_read read them as if they are input? hmm confusing...

You can read the state of any gpio state, does not matter of they they are in or out pins, or digital or analog.
If someting reads the pin states (digi), then that's usually to verify what they are because it's possible some parts of the code somewhere could have changed them.

ok, so if reading is only to verify output pin's state (whether its outputtting HI or LO), then its not to verify whether AFG HW exists or not. correct? btw, i managed to rev eng the pin interface is due to FPGA is outputting valid AFG signal naked on bright day even if no AFG HW presents, and i didnt manage to hang anything during the process. so maybe people who reported hanging their dso while playing with AFG GUI did something else to cause the hang? maybe they activate bode plot? and hence dso struggled to find signal on CH1 and CH2?

[shapirus]

In testing, was able to uninstall system app com.rigol.scope, and reinstall it (Sparrow.apk), the OEM stuff.

I did edit, repack, resign, and zipalign.
pm install did not complain about any signature stuff, but I did get a failed install due to missing "NativeLibs". I do believe I can fix this problem by editing manifest to not call for "extractNativeLibs".
I need to investigate further.

I'm hitting this exact issue now, when trying to install a rebuilt Sparrow.apk:

Code: [Select]

Failure [INSTALL_FAILED_INVALID_APK: Failed to extract native libraries, res=-2]

Apparently it should go well if I set android:extractNativeLibs="true" in AndroidManifest.xml (https://github.com/iBotPeaches/Apktool/issues/1626). Is that what you did to fix it or there's some other way?

It looks somewhat strange.

update: adding the "-p" argument to zipalign fixed the issue. As usual, found the solution 1 minute after posting, but hopefully this will help someone who comes here from a search results page.

[shapirus]

Having some progress



Alas, the added multipliers don't work (yet). Might be because they really require a modification of the .so, after all, which is also suggested by the fact that changing those floating point numbers presented as strings does not lead to the change of the actual multipliers, unfortunately (but then what are those strings used for?)

[souldevelop]

It's interesting. I tried to search where the preset probe ratio multipliers could be defined and couldn't find them neither in Sparrow.apk, nor in libscope-auklet.so. I thought it would have been an array of values, but no, at least, nothing matching the numbers I searched for.

Has anyone found them yet?

It's so lame that it doesn't allow to simply enter an arbitrary multiplier.

update: LOL, as usual, I found it *literally* 1 minute after I posted this. It's in sparrow.apk. Will try to add the multiplier I needed tomorrow. It appears to be in smali_classes2/com/rigol/scope/cil/ServiceEnum$ProbeX.smali, and they define floating point numbers as strings, unless it's decorative and the actual numbers are defined elsewhere.

I'm interested in probe magnification modifications, maybe I can see if there's any information available in .so.

[AndyBig]

Apparently it should go well if I set android:extractNativeLibs="true" in AndroidManifest.xml (https://github.com/iBotPeaches/Apktool/issues/1626). Is that what you did to fix it or there's some other way?

Yes, that's exactly how I fixed it. But thanks for your method, I think it is more correct.

Alas, the added multipliers don't work (yet). Might be because they really require a modification of the .so, after all, which is also suggested by the fact that changing those floating point numbers presented as strings does not lead to the change of the actual multipliers, unfortunately (but then what are those strings used for?)

To set or save the value of the probe divider, it is not the value of the divider that is sent to .so, but its serial number from 0 (corresponds to 0.0001) to 30 (corresponds to 50000.0). Therefore, adding some other values to the application will not do anything without modifying the .so library.

[shapirus]

To set or save the value of the probe divider, it is not the value of the divider that is sent to .so, but its serial number from 0 (corresponds to 0.0001) to 30 (corresponds to 50000.0).

I figured that much too, but haven't yet found where those numbers are accepted and processed in the .so. There are some functions having the "ProbeRatio" substring in their names, but ghidra did not disassemble their bodies -- in the .c file it produced they seem to be calling themselves, which is weird. Maybe the actual code should be inside them, maybe not.

p.s. even if we figure that out, then recompiling the .so is going to be a much more difficult job than the same with .apk, and I'm not sure if even possible.

[AndyBig]

To set or save the value of the probe divider, it is not the value of the divider that is sent to .so, but its serial number from 0 (corresponds to 0.0001) to 30 (corresponds to 50000.0).

I figured that much too, but haven't yet found where those numbers are accepted and processed in the .so. There are some functions having the "ProbeRatio" substring in their names, but ghidra did not disassemble their bodies -- in the .c file it produced they seem to be calling themselves, which is weird. Maybe the actual code should be inside them, maybe not.

p.s. even if we figure that out, then recompiling the .so is going to be a much more difficult job than the same with .apk, and I'm not sure if even possible.

The conversion of the divisor from the index to the real value occurs in libscope-auklet.so in the function CApiVertical::ApiChannel_SetProbeRatio (see screenshot). The index value is taken from address 0xd203f8, where there is an array of 31 16-byte values (see screenshot). Each value represents 8 bytes of real value and 8 bytes of decimal power. For example, the first index contains the 16-byte value 0x0100000000000000FCFFFFFF00000000, which means 1 (0100000000000000) multiplied by 10 to the power of -4 (FCFFFFFF00000000).
The real address of this array in the libscope-auklet.so file is 0x00C1F3F8 (see screenshot).

[shapirus]

At least it should be possible to replace certain multipliers that I don't need (like 50000x) with those I do need by editing the .so directly.

But if we find a way to recompile it, then it'll open a whole lot of new possibilities. If not from C code, then at least it should be possible to recompile it from assembler.

p.s. what did you use for decompilation? Ghidra gave me only this:

Code: [Select]

void _ZN12CApiVertical24ApiChannel_SetProbeRatioEj(void)

{
  _ZN12CApiVertical24ApiChannel_SetProbeRatioEj();
  return;
}

either it couldn't do its job, or I didn't use it the right way.

[AndyBig]

At least it should be possible to replace certain multipliers that I don't need (like 50000x) with those I do need by editing the .so directly.

But if we find a way to recompile it, then it'll open a whole lot of new possibilities. If not from C code, then at least it should be possible to recompile it from assembler.

No, it’s almost impossible to recompile the library But you can change existing values in it. If you really bother, I think you can even enter a user-specified divisor value, but this is a lot of work both in .so and in .app .

[AndyBig]

p.s. what did you use for decompilation? Ghidra gave me only this:

Code: [Select]

void _ZN12CApiVertical24ApiChannel_SetProbeRatioEj(void)

{
  _ZN12CApiVertical24ApiChannel_SetProbeRatioEj();
  return;
}

either it couldn't do its job, or I didn't use it the right way.

That's what I used Ghidra There are two functions with the same name, one is in your code quote, and it already calls the second, a screenshot of which I showed.
IDA, by the way, also decompiles quite well. In some places even better than Ghidra.

[Randy222]

The following is the logical pseudocode for a few key functions:

so the RK3399 pins 122-126 are set as output, and then later stage  gpio_afg_drv_read read them as if they are input? hmm confusing...

You can read the state of any gpio state, does not matter of they they are in or out pins, or digital or analog.
If someting reads the pin states (digi), then that's usually to verify what they are because it's possible some parts of the code somewhere could have changed them.

ok, so if reading is only to verify output pin's state (whether its outputtting HI or LO), then its not to verify whether AFG HW exists or not. correct? btw, i managed to rev eng the pin interface is due to FPGA is outputting valid AFG signal naked on bright day even if no AFG HW presents, and i didnt manage to hang anything during the process. so maybe people who reported hanging their dso while playing with AFG GUI did something else to cause the hang? maybe they activate bode plot? and hence dso struggled to find signal on CH1 and CH2?

Well, in kernel debug folder there's the gpio stuff, it holds states of pins, but only info captured from a KLM. Some pins not listed are still addressable from cli, but I just don't know what the outcome is by changing pin states, a bad change could perhaps cause damage.
If RK pin is RK_out and they go to AFG_in pins, that might suggest the RK is configuring the AFG using five 1bit words, or maybe one 5bit word. Not sure how the functionality is. Maybe a 5bit word is a scaling factor from 1 to 32*16*8*4*2 ?  If an 800 series runs as a 900, do you get an AFG freq panel to punch in a freq? Sure, it won't do anything but you can monitor the gpio pins to see if there's any relevance.

[Mechatrommer]

If RK pin is RK_out and they go to AFG_in pins, that might suggest the RK is configuring the AFG using five 1bit words, or maybe one 5bit word. Not sure how the functionality is. Maybe a 5bit word is a scaling factor from 1 to 32*16*8*4*2 ?

another possibility is those 5 pins are connected to FPGA to tell FPGA what to do to output to AFG, not directly to AFG module.

If an 800 series runs as a 900, do you get an AFG freq panel to punch in a freq? Sure, it won't do anything but you can monitor the gpio pins to see if there's any relevance.

i spent a fair amount of time doing this, you can see in attachments earlier. but anything in between my finger press on GUI and those exposed interface pins are a black box to me, in other word i dont know. so i dont want to speculate one of many possibilities. but based on souldevelop's report, those 5 pins are configured as output, so i have a doubt those 5 pins checking are responsible to detect AFG presence or not and cause the dso to hang. thats the matter of discussion right now imho. whatever those 5 pins do, as long as its not for status checking (AFG presence), is not my concern atm. ymmv.

ps: for the past few many hours, i tried to install everything (android studio, apktool, jadx decompiler, bluestacks) to look for what the FW does, where the FW calls to the afg_gpio.ko but not yet success, all i see are bunch of java import and export  nonsense stuffs

[shapirus]

Does anyone know if it's possible to calibrate/fine-tune the internal reference oscillator? There is some "ADC Clock" in the Debug section of the Utility menu, but it doesn't seem to affect anything.

I know I shouldn't have, but I bought a GPSDO and now I know that this extra "1" is there, and it will never be possible to forget about it now.

[AndyBig]

ps: for the past few many hours, i tried to install everything (android studio, apktool, jadx decompiler, bluestacks) to look for what the FW does, where the FW calls to the afg_gpio.ko but not yet success, all i see are bunch of java import and export  nonsense stuffs

The .apk application does not access the hardware directly, but only through the libscope-auklet.so library.

I know I shouldn't have, but I bought a GPSDO and now I know that this extra "1" is there, and it will never be possible to forget about it now.

I think that this is an error in the master quartz oscillator and nothing can be done about it.

[Mechatrommer]

ps: for the past few many hours, i tried to install everything (android studio, apktool, jadx decompiler, bluestacks) to look for what the FW does, where the FW calls to the afg_gpio.ko but not yet success, all i see are bunch of java import and export  nonsense stuffs

The .apk application does not access the hardware directly, but only through the libscope-auklet.so library.

yeah, jadx cant open *.so, only ida, but asm @ and # thing, link or reference? or whatever they are not helping either. i dont see how Sparrow.apk (mostly GUI related i see and "this" class) correlates, links or make calls to libscope-auklet.so anyway, whats obvious is... i'm not an android nut... maybe i need more time.. here just filling time while waiting for my pcb to arrive...

[Veteran68]

yeah, jadx cant open *.so, only ida,

jadx only decompiles JVM applications. Shared libraries (.so) are native code, typically written in lower level languages like C/C++ or even ASM.

[Mechatrommer]

Ghidra is quite good! analyzing code took very long time, but its worth it, iirc yesterday i wasnt patient enough i didnt realize what it was... i think AFG presence check not yet implemented (HasAFG) and "read afg state" only return the 5 bits pin output of 0x7A-0x7E... i think i'm starting to catching up here to be a code digger... just a show off!

[AndyBig]

i dont see how Sparrow.apk (mostly GUI related i see and "this" class) correlates, links or make calls to libscope-auklet.so anyway, whats obvious is... i'm not an android nut... maybe i need more time.. here just filling time while waiting for my pcb to arrive...

Interaction with the library is implemented in the file com\rigol\scope\cil\API.java. All interaction is reduced to requesting and recording values of different types by identifiers.
For example, this is how the maximum bandwidth of an oscilloscope is requested:

Code: [Select]

API.getInstance().UI_QueryInt32(11, MessageID.MSG_APP_UTILITY_BW);
This is how a line with the system version is requested:

Code: [Select]

API.getInstance().UI_QueryStr(11, MessageID.MSG_MISC_SYSTEM_VERSION);
This is how the G1 (AFG) indicator on the panel lights up and goes out:

Code: [Select]

API.getInstance().UI_PostInt32Int32(11, MessageID.MSG_APP_UTILITY_LED, ServiceEnum.PanelLed.G1_LED_WHITE.value1, 1);
API.getInstance().UI_PostInt32Int32(11, MessageID.MSG_APP_UTILITY_LED, ServiceEnum.PanelLed.G1_LED_WHITE.value1, 0);
And this is how the command is given to turn off the hardware:

Code: [Select]

API.getInstance().UI_PostInt32(11, MessageID.MSG_HARDWARE_POWERDOWN, 1);
And so on. There are many hundreds of these identifiers.

[Mechatrommer]

what is the firmware version out from factory nowadays for dho800 and dho900? is older key.data still relevant for rigol_vendor_bin? or is there newer rigol_vendor_bin that works on RKey.data?

[AndyBig]

or is there newer rigol_vendor_bin that works on RKey.data?

It's been around for a long time.

[Mechatrommer]

or is there newer rigol_vendor_bin that works on RKey.data?

It's been around for a long time.

because the rigol_vendor_bin i downloaded and applied few weeks ago works on key.data.. i'll look again for newer instruction. thanks.

[AndyBig]

or is there newer rigol_vendor_bin that works on RKey.data?

It's been around for a long time.

because the rigol_vendor_bin i downloaded and applied few weeks ago works on key.data.. i'll look again for newer instruction. thanks.

https://github.com/zelea2/rigol_vendor_bin/releases

[jackcheng]

or is there newer rigol_vendor_bin that works on RKey.data?

It's been around for a long time.

because the rigol_vendor_bin i downloaded and applied few weeks ago works on key.data.. i'll look again for newer instruction. thanks.

https://github.com/zelea2/rigol_vendor_bin/releases

Read the post for a long time. I found this rigol_vendor_bin github repo work fine. But I can't find where it is from? how the hack process is found ? For example how he know the 2 xxtea keys and how he know the vendor.bin is encryped by twice?

[mrisco]

A little preview

[AndyBig]

Read the post for a long time. I found this rigol_vendor_bin github repo work fine. But I can't find where it is from? how the hack process is found ? For example how he know the 2 xxtea keys and how he know the vendor.bin is encryped by twice?

The author disassembled and examined the application and libraries. A lot of hard work indeed.