Hacking the Rigol DHO800/900 Scope

[AceyTech]

I wonder how difficult it is to disassemble an apk, change something in it and compile it back so that it works. Has anyone done this? Is this even feasible?

First, I'm -by no means- an expert.  And, I probably should have waited for someone else to reply.  But, since I'm also interested in this topic, and come from a similar bkgd as you:  (Embedded micro work & Android is a black hole)  I think it's very feasible, but It's hard to tell if any of the Android dudes want to take this on.

I did a little bit of hacking years ago on Android and recall that you can "unWrap" APKs with common compression tools, as they're generally just Zip files with APK extension.

Then it's a matter of modifying the files and re-packing it.  The challenge is re-signing it so the OS doesn't reject your app.

I did a search in this topic here for APK and Sign(Signing) because I remember some discussion about this, and found you have been one of the ones talking about this exact subject.
 
FWIW; I'm wondering if it might be prudent to try to make something that applies patches to the app(s) or functions after boot rather than patching the main app., That way it might survive updates.  I dunno., maybe one of the wicked Android hackers can chime in as to the level of effort.

Research Topics:
Decompile/Recompile
APK Extension

[Randy222]

This link is the decompiled Sparrow APK for FW 00.01.02.00.02.

Edit at will, rebuild with Gradle in Android Studio. Will it run on the DHO? TBD.


https://easyupload.io/plxok2

My local MD5 of the zip before being uploaded to Easy.
9b0c488110104fffe30b5d39aaa0ea99  Sparrow.apk_Decompiler.com.zip

I am not sure signing matters much, you can enable the Android setting "allow install of apps from unknown sources".

I also notice now Rigol has two downloads for 00.01.02.00.02, one for DHO800 and one for DHO900. Hmmm, in the past they were the same download. I cannot download them, you need a login, so if someone can check their hashes to see if they are same or different, that would be great.

[Fungus]

I wonder how difficult it is to disassemble an apk, change something in it and compile it back so that it works.

It's just a zip file. Unzip it, patch it, zip it up again!

All APKs are signed though, so the question is: Will the 'scope accept/run it? ie. Can you self-sign it and persuade the 'scope to run it?

(I don't know the answer to that part...)

Ref: https://developer.android.com/studio/publish/app-signing

Another problem with that is that it would have to be re-done for every firmware update.

[AceyTech]

I wonder how difficult it is to disassemble an apk, change something in it and compile it back so that it works.

It's just a zip file. Unzip it, patch it, zip it up again!

All APKs are signed though, so the question is: Will the 'scope accept/run it? ie. Can you self-sign it and persuade the 'scope to run it?

(I don't know the answer to that part...)

Ref: https://developer.android.com/studio/publish/app-signing

Another problem with that is that it would have to be re-done for every firmware update.

Wow, that sounds very familiar...    But much more brief than my blathering. 

[gabiz_ro]

I also notice now Rigol has two downloads for 00.01.02.00.02, one for DHO800 and one for DHO900. Hmmm, in the past they were the same download. I cannot download them, you need a login, so if someone can check their hashes to see if they are same or different, that would be great.

Where?
Give a link
On int.rigol.com is same DHO800_DHO900(Software)Updatev00.01.02.00.02 for both

[axantas]

I also notice now Rigol has two downloads for 00.01.02.00.02, one for DHO800 and one for DHO900. Hmmm, in the past they were the same download. I cannot download them, you need a login, so if someone can check their hashes to see if they are same or different, that would be great.

Where?
Give a link
On int.rigol.com is same DHO800_DHO900(Software)Updatev00.01.02.00.02 for both

I do not understand that strategy of Rigol EU with this mandatory login for a firmware download...

here it is also available without login
https://www.rigolna.com/firmware/

[ebastler]

I do not understand that strategy of Rigol EU with this mandatory login for a firmware download...

I don't think there is a strategy behind that, just incompetence...

When I try to download firmware from the DHO900 product page, that fails because the link is plainly broken. (It's a malformed address, which appends a full URL on the international site directly to the rigol.eu URL.) When I try the same from the DHO800 product page or the rigol.eu support page, the link goes to some address which expects an XML file with a key -- maybe meant for online updates downloaded directly by the scope? So that fails because the required parameters are not provided.

I don't know what's going on with Rigol and firmware updates. Their numbering scheme and inconsistency of calendar dates has been a mess for a long time, and now URLs seem a challenge too...

[AceyTech]

Well, I just tested downloads of:
800/900 firmware from the 'all firmware' page @axantas shared, and
from the downloads tab via DHO800 and the DHO900 specific pages

NO broken links for me. All three links pointed to the same file "DHO800_DHO900(Software)Updatev00.01.02.00.02.zip" and were each 96.9MB in size once downloaded.

BTW: If you want a laugh, check out the DM3058/DM3068 version number!


Incidentally, I couldn't find any links for 800 or 900 specific FW as @Randy222 mentioned, only 800/900 combo.

[ebastler]

Well, I just tested downloads of:
800/900 firmware from the 'all firmware' page @axantas shared, and
from the downloads tab via DHO800 and the DHO900 specific pages

NO broken links for me.

That's good. It's Rigol's European site which we were discussing, and where things are currently broken. I think Rigol would be doing themselves a favor if they adopted one global firmware repository, instead of all the triplicate work (and often inconsistency) at the US and EU sites.

I do not understand that strategy of Rigol EU with this mandatory login for a firmware download...

here it is also available without login
https://www.rigolna.com/firmware/

[AndyBig]

But, since I'm also interested in this topic, and come from a similar bkgd as you:  (Embedded micro work & Android is a black hole)  I think it's very feasible, but It's hard to tell if any of the Android dudes want to take this on.

Well, in general, I work quite closely with embedded microelectronics, but I’m familiar with Android only as a user and have the most superficial knowledge of development for it

I did a search in this topic here for APK and Sign(Signing) because I remember some discussion about this, and found you have been one of the ones talking about this exact subject.

Yes, I also did a little searching for information on this issue and realized that this is in principle possible. The only problem is that you can only compile back SMALI, which is essentially a kind of assembler. So you don’t have to dream about changes at the Java level

It's just a zip file. Unzip it, patch it, zip it up again!

All APKs are signed though, so the question is: Will the 'scope accept/run it? ie. Can you self-sign it and persuade the 'scope to run it?

(I don't know the answer to that part...)

Ref: https://developer.android.com/studio/publish/app-signing

Another problem with that is that it would have to be re-done for every firmware update.

You don’t just need to unzip and then archive, you need to decompile and then compile back, and this is more difficult
Regarding signing the application - as I understand after reading several articles and topics on forums, this is not a problem. You can sign with a signature you created yourself; there are tools for this.
The most important thing is that after decompilation, changes and compilation, the application remains working

[Houseman]

i'm working on to make both AFG and LA to work now, still in progress...

Oh thats cool! I will look forward to hearing about your results
In addition to this hardware, it looks like you also need to solder 2 missing memory chips onto the main board of the oscilloscope. Presumably this memory is needed for LA, but as far as I know, no one has yet tested this in practice.

any specific steps how to do that? i didnt follow this thread closely sorry.

1. Download the files /rigol/data/vendor.bin and /rigol/data/Key.data from the oscilloscope using ADB:
adb pull /rigol/data/vendor.bin
adb pull /rigol/data/Key.data
2. Using this program - https://github.com/zelea2/rigol_vendor_bin - change the oscilloscope model to DHO914S or DHO924S in the vendor.bin file:
rigol_vendor_bin.exe -M DHO924S
3. Using the same program, generate all possible options using the Key.data file:
rigol_vendor_bin.exe -o
For convenience, you can direct the program output to a file so that all generated options are saved in it:
rigol_vendor_bin.exe -o >>options.txt
4. Load the vendor.bin file back into the oscilloscope:
adb push vendor.bin /rigol/data/
5. Reboot the oscilloscope.
6. Send the DHO900-BODE and DHO900-BW15T25 options from those generated in step 3 via the SCPI interface.

Aren't both option at point 6 already available on a DHO900S series by default?
By upgrading the DHO914S into a 924S isn't just the bandwith to be increased?
So can I just increase in my DHO914S the BW without modifying the vendor.bin?
regards and thanks

[AndyBig]

1. Download the files /rigol/data/vendor.bin and /rigol/data/Key.data from the oscilloscope using ADB:
adb pull /rigol/data/vendor.bin
adb pull /rigol/data/Key.data
2. Using this program - https://github.com/zelea2/rigol_vendor_bin - change the oscilloscope model to DHO914S or DHO924S in the vendor.bin file:
rigol_vendor_bin.exe -M DHO924S
3. Using the same program, generate all possible options using the Key.data file:
rigol_vendor_bin.exe -o
For convenience, you can direct the program output to a file so that all generated options are saved in it:
rigol_vendor_bin.exe -o >>options.txt
4. Load the vendor.bin file back into the oscilloscope:
adb push vendor.bin /rigol/data/
5. Reboot the oscilloscope.
6. Send the DHO900-BODE and DHO900-BW15T25 options from those generated in step 3 via the SCPI interface.

Aren't both option at point 6 already available on a DHO900S series by default?
By upgrading the DHO914S into a 924S isn't just the bandwith to be increased?
So can I just increase in my DHO914S the BW without modifying the vendor.bin?
regards and thanks

I don’t remember exactly about BODE, but it seems that it was initially either not available at all or available as a trial option.
Yes, now you can simply change the BW without changing the oscilloscope model, to do this, just skip steps 2, 4 and 5.
If the oscilloscope is flashed with the latest firmware 00.01.02.00.02, then you need to load the RKey.dat file from the oscilloscope instead of Key.dat.
Recently, zelea2 added to its utility another way to unlock all options available for a given model - https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5323313/#msg5323313

PS: I keep getting confused about the correct spelling of this longest version of Rigol's firmware )

[Veteran68]

You don’t just need to unzip and then archive, you need to decompile and then compile back, and this is more difficult

At it's most elemental level, patching does not require decompilation and recompilation. Certainly when it's possible to get compilable source code from a binary distribution, such as when Java archives include the original source,  that's great but it's pretty rare. When you can get an approximation of original source through decompilation with tools such as Ghidra or IDA, it's not so that it can be recompiled, but only to help follow the code in a higher level language than assembler. But in most cases you're disassembling to assembler code and reading that to understand what the code is doing, therefore strong knowledge of assembler is necessary for effective RE.

Sometimes just following the logic is enough to understand the algorithm in order to create a key generator, in which case no patching or updating the binary is required. Otherwise, patching data or opcode bytes directly in the binary (e.g. to jump over a validation check) is done to alter or short-circuit the logic to achieve your goal. There is no compiling of source code happening here.

I did a great deal of software reverse engineering back in the 90's and early 00's in both personal and professional contexts, leveraging tools like Periscope and SoftICE as well as IDA, OllyDbg, and others to RE and patch code. It was generally easier back then before methods like encryption, signing, anti-debug tricks, etc. were commonly employed that made RE more difficult, though seldom impossible.

[AndyBig]

You don’t just need to unzip and then archive, you need to decompile and then compile back, and this is more difficult

At it's most elemental level, patching does not require decompilation and recompilation. Certainly when it's possible to get compilable source code from a binary distribution, such as when Java archives include the original source,  that's great but it's pretty rare. When you can get an approximation of original source through decompilation with tools such as Ghidra or IDA, it's not so that it can be recompiled, but only to help follow the code in a higher level language than assembler. But in most cases you're disassembling to assembler code and reading that to understand what the code is doing, therefore strong knowledge of assembler is necessary for effective RE.

Sometimes just following the logic is enough to understand the algorithm in order to create a key generator, in which case no patching or updating the binary is required. Otherwise, patching data or opcode bytes directly in the binary (e.g. to jump over a validation check) is done to alter or short-circuit the logic to achieve your goal. There is no compiling of source code happening here.

I did a great deal of software reverse engineering back in the 90's and early 00's in both personal and professional contexts, leveraging tools like Periscope and SoftICE as well as IDA, OllyDbg, and others to RE and patch code. It was generally easier back then before methods like encryption, signing, anti-debug tricks, etc. were commonly employed that made RE more difficult, though seldom impossible.

I'm not talking about analysis, but about changing the application. Decompile, modify and compile back.
With the help of Ghidra, by the way, you can also modify programs, but to a very limited extent. Although I once tinkered with the firmware of a 3D printer (for which there were no sources) and managed to modify it very significantly, adding my own compiled functions to the binary and redirecting calls in the firmware to them instead of native functions

[Veteran68]

I'm not talking about analysis, but about changing the application. Decompile, modify and compile back.

I'm not just talking about analysis, either. "Patching" is by definition changing the application. I've modified hundreds of binaries through patching, and not decompiling/recompiling, which was the point of my post. In most cases decompiling/recompiling isn't an option, patching is the only viable way to change the app.

[AndyBig]

I'm not talking about analysis, but about changing the application. Decompile, modify and compile back.

I'm not just talking about analysis, either. "Patching" is by definition changing the application. I've modified hundreds of binaries through patching, and not decompiling/recompiling, which was the point of my post. In most cases decompiling/recompiling isn't an option, patching is the only viable way to change the app.

In a binary without decompilation, you can change only very slightly. For example, replace the call to the license check function with unconditional truth. But redoing the algorithm for how a function works is a big challenge.
I want to be able to change the operation of the application without regard to the restrictions imposed by the already compiled binary

[zrq]

You can checkout what we did for patching the application on the sibling thread for DHO1000. Although I don't see why it's necessary except you want to fix bugs yourself.

[Aleksandr]

So guys the chips are installed, I filmed the whole process

https://youtu.be/tC4oR421hfM

https://youtu.be/HyH9DJBt6K0

Did anything work out? Is there any result? Look forward to.

[Randy222]

I commenting on past few posts.

1) Two seperate FW's, perhaps the same, need login. --> https://supportint.rigol.com/SUPPORTS/software-firmware-download.html
2) You cannot just unpack an APK and edit. An APK is a package set of compiled goods along with some other text files.
3) I provided the decompiled APK, tons of .java source files to edit if you like

If we are wanting the source of the C libraries (.so files), then I need to see if I can get that.

One test is to hexedit or Ghidra edit one non-significant byte in the auklet.so library, then swap it out on the DHO, see what happens. The auklet.so appears to be where all the functions are for doing scope stuff.

An APK should have file that contains all the hashes of the files in an APK for intergrity, and then the APK itself is signed so that Andoid device knows it's from a trusted source. Again, we can install apps from unknown sources.

[shapirus]

Although I don't see why it's necessary except you want to fix bugs yourself.

To change the channel color palette, for example, and maybe make other UI customizations.

[gabiz_ro]

1) Two seperate FW's, perhaps the same, need login. --> https://supportint.rigol.com/SUPPORTS/software-firmware-download.html

view page source and get links
https://download.rigol.com/cn/Firmware/Digital%20Oscilloscope/DHO800%26DHO900/DHO800_DHO900(Software)Updatev00.01.02.00.02.zip
Same firmware

[AndyBig]

3) I provided the decompiled APK, tons of .java source files to edit if you like

As I understand from reading on the Internet, compiling .java files after decompilation is a very bad idea. You need to modify and compile SMALI files.

[Houseman]

Sorry distubing You AndyBig, I cannot access via adb the oscope (DHO914S).
Upgrading older DHO800 to 924 was easy enough, now it seems connection failure to the device.
Do I need to extra enable something on the oscope?
BTW I can see all 6 options visible (5 in Forever state - BandWidth is Limited) and FW is 00.01.00 built on 2023/07/21
Will try to upgrade to the latest and the retry.
Any help appreciated
Regards

[ebastler]

Try port 55555 (five digits).

[Houseman]

  Yeah, that works....
Sorry