Hacking the Rigol DHO800/900 Scope

[ebastler]

DHO bloat, not needed, at least from my testing, scope runs a-ok after disabling stuff.

Does that reduce the boot time noticeably?

[Randy222]

DHO bloat, not needed, at least from my testing, scope runs a-ok after disabling stuff.

Does that reduce the boot time noticeably?

Not that I noticed. On my DHO there are several sleep commands in the start-rigol-app script, which seems to account for almost 50% of the boot time. I think Rigol has to slow the sequence for the various hardware components to be 100% available for next piece.
The bloat packages don't use much if any cpu, but they do take up ram.
My rule is, if not needed then it's gone.

[Randy222]

If that's the case, then I suspect there are little to no buyers of option lics, so to kill off the user generated lics they just modify the lic process in a new FW.

I would like to remind you that there are still no purchasable options for this series.
If you think about it a little, apparent contradictions resolve themselves.

Due to the way they rolled out the 800/900, their intent was most likely to have pay-for options.
Otherwise it would have been very easy to remove the functions that import option strings, and remove functions that read lic files.

[shapirus]

On my DHO there are several sleep commands in the start-rigol-app script, which seems to account for almost 50% of the boot time. I think Rigol has to slow the sequence for the various hardware components to be 100% available for next piece.

This sounds like there's potential for improvement. If we can identify what components it has to wait for, then probably the sleeps can be rewritten into loops (with small delays between iterations) with polling the respective parts to check if they're ready.
Or, just reduce the sleeps until the scope begins to fail to boot properly

[zelea2]

None of the apk sizes match!

I have figured out what is happening: the upgrade fails no matter what file I supply to the scope.
If you do the upgrade from the interface everything seems to work, no errors, scope reboots and comes back with the previous version.
If I do it manually:
rk3399_rigol:/rigol # shell/do_update.sh DHO800_DHO900_Update.GEL 1
still no error message but when I examine /data/logs/tools_log/gel_update_logs.txt I get

Code: [Select]

pm install -r /mnt/tmp/app/Webcontrol.apk
/mnt/tmp/shell/do_extract.sh: line 157:  1909 Aborted                 pm install -r $UPDAT
pm install -r /mnt/tmp/app/Launcher.apk
/mnt/tmp/shell/do_extract.sh: line 165:  1915 Aborted                 pm install -r $UPDAT
pm install -r /mnt/tmp/app/Sparrow.apk
/mnt/tmp/shell/do_extract.sh: line 195:  1923 Aborted                 pm install -r $UPDAT
cp: pmapService: Text file busy
Upgradation failed

That is their upgrade script that fails I haven't done anything.
When the upgrade fails for any reason the old applications are restored.
I have tried to kill pmapService as they do in their script. That didn't make any difference.
Then I've killed all the rigol processes:

Code: [Select]

system    1097  235   1757788 115484 SyS_epoll_ 7c14699b84 S com.rigol.launcher
system    1176  235   3716012 441924 futex_wait 7c1464acf0 S com.rigol.scope
system    1247  235   1593224 99152 SyS_epoll_ 7c14699b84 S com.rigol.launcher:Watchdog
system    1261  235   1625108 100360 SyS_epoll_ 7c14699b84 S com.rigol.webcontrol

but they come back with new PIDs.
Also when I try

Code: [Select]

rk3399_rigol:/rigol # pm uninstall com.rigol.launcher
Aborted

I need to get to the bottom of which script launches the Rigol apps so I can edit it.
Editing /rigol/shell/start_rigol_app.sh had no effect it's probably copied somewhere else.





 

[Randy222]

None of the apk sizes match!

I have figured out what is happening: the upgrade fails no matter what file I supply to the scope.
If you do the upgrade from the interface everything seems to work, no errors, scope reboots and comes back with the previous version.
If I do it manually:
rk3399_rigol:/rigol # shell/do_update.sh DHO800_DHO900_Update.GEL 1
still no error message but when I examine /data/logs/tools_log/gel_update_logs.txt I get

Code: [Select]

pm install -r /mnt/tmp/app/Webcontrol.apk
/mnt/tmp/shell/do_extract.sh: line 157:  1909 Aborted                 pm install -r $UPDAT
pm install -r /mnt/tmp/app/Launcher.apk
/mnt/tmp/shell/do_extract.sh: line 165:  1915 Aborted                 pm install -r $UPDAT
pm install -r /mnt/tmp/app/Sparrow.apk
/mnt/tmp/shell/do_extract.sh: line 195:  1923 Aborted                 pm install -r $UPDAT
cp: pmapService: Text file busy
Upgradation failed

That is their upgrade script that fails I haven't done anything.
When the upgrade fails for any reason the old applications are restored.
I have tried to kill pmapService as they do in their script. That didn't made any difference.
Then I've killed all the rigol processes:

Code: [Select]

system    1097  235   1757788 115484 SyS_epoll_ 7c14699b84 S com.rigol.launcher
system    1176  235   3716012 441924 futex_wait 7c1464acf0 S com.rigol.scope
system    1247  235   1593224 99152 SyS_epoll_ 7c14699b84 S com.rigol.launcher:Watchdog
system    1261  235   1625108 100360 SyS_epoll_ 7c14699b84 S com.rigol.webcontrol

but they come back with new PIDs.
Also when I try

Code: [Select]

rk3399_rigol:/rigol # pm uninstall com.rigol.launcher
Aborted

I need to get to the bottom of which script launches the Rigol apps so I can edit it.
Editing /rigol/shell/start_rigol_app.sh had no effect it's probably copied somewhere else.

It seems Android loads up the Rigol APK packages. Maybe in the past the start script did it, but I see a am start command commented out.

The start script appears to sequence peripherals like touchscreen, wifi driver if you want, screen brightness property, TZ, etc. It also increments a boot counter.


PID's will be assigned, so they different each boot.

How are you on the droid? Just ADB?
adb connect
adb shell
su -

now re-run the update script, it should run a-ok.

What's those lines in that script? Was your copy trncated, or does it really say "$UPDAT" ?

And "upgradation" is a real word, but most just say "upgrade". 

[zelea2]

It seems Android loads up the Rigol APK packages. Maybe in the past the start script did it, but I see a am start command commented out.

now re-run the update script, it should run a-ok.

What's those lines in that script? Was your copy trncated, or does it really say "$UPDAT" ?

And "upgradation" is a real word, but most just say "upgrade". 

That's the chinese "upgradation"  which is not working !!!

Yes the line was longer I've truncated it when I've paste it:
... Aborted                 pm install -r $UPDATE_DSO > /dev/null 2>&1

I'm on ssh as root (better than adb). I've tried it via adb root too ... same failure.

You are right, Android starts those apps. How do I disable them because the update script still fails. I'm stuck.

[Randy222]

It seems Android loads up the Rigol APK packages. Maybe in the past the start script did it, but I see a am start command commented out.

now re-run the update script, it should run a-ok.

What's those lines in that script? Was your copy trncated, or does it really say "$UPDAT" ?

And "upgradation" is a real word, but most just say "upgrade". 

That's the chinese "upgradation"  which is not working !!!

Yes the line was longer I've truncated it when I've paste it:
... Aborted                 pm install -r $UPDATE_DSO > /dev/null 2>&1

I'm on ssh as root (better than adb). I've tried it via adb root too ... same failure.

You are right, Android starts those apps. How do I disable them because the update script still fails. I'm stuck.

Well, I mentioned it before. Why they dump stdout and err to dev/null is nuts.
edit that and just replace /dev/null with "/rigol/data/pm_logs.txt" so you can go back and see what the err is.

When you in on ssh, what do you get from
echo $ANDROID_ROOT
echo $ANDROID_DATA

If blank then you need to export them before doing things in ssh.

export ANDROID_ROOT=/system ANDROID_APP=/data

pm disable [package name]
that will disable them, just reboot. Then enable them after.
I showed pm a few posts back.

[zelea2]

export ANDROID_SYSTEM=/system ANDROID_APP=/data

I already have those in my /system/etc/profile
export ANDROID_DATA=/data
export ANDROID_ROOT=/system
(it's _ROOT not _SYSTEM)
together with my favorite aliases

pm disable [package name]
that will disable them, just reboot. Then enable them after.

That did the trick pm disable com.rigol.scope stopped it no need to reboot.

Now the upgrade shows no error but I end up with the same old Sparrow.apk

Code: [Select]

# ll /mnt/tmp/app/Sparrow.apk
36840716 2024-01-03 20:11 /mnt/tmp/app/Sparrow.apk
# pm install -r /mnt/tmp/app/Sparrow.apk
Success
# ll /rigol/app/Sparrow.apk
36898060 2024-02-02 05:25 /rigol/app/Sparrow.apk
# ll /system/app/Sparrow/Sparrow.apk
37148630 2023-08-23 11:40 /system/app/Sparrow/Sparrow.apk

If I just copy the APK by hand (after I stop the service) instead of pm install would that break anything?

[AceyTech]

DHO bloat, not needed, at least from my testing, scope runs a-ok after disabling stuff.
The default build only has the Android Demo package disabled, but we can disable more.

Disabling does appear to be boot persistent (can likely ditch printspooler) NOTE: proxyhandler seems to be needed for wifi connection to work.

I'm all for debloating to speed up the boot time. Drives me nuts! waiting for a piece of test gear to boot.

But, can you ditch the printspooler service and still print?  I think I saw someone printing from his scope last week.

[Randy222]

export ANDROID_SYSTEM=/system ANDROID_APP=/data

I already have those in my /system/etc/profile
export ANDROID_DATA=/data
export ANDROID_ROOT=/system
(it's _ROOT not _SYSTEM)
together with my favorite aliases

pm disable [package name]
that will disable them, just reboot. Then enable them after.

That did the trick pm disable com.rigol.scope stopped it no need to reboot.

Now the upgrade shows no error but I end up with the same old Sparrow.apk

Code: [Select]

# ll /mnt/tmp/app/Sparrow.apk
36840716 2024-01-03 20:11 /mnt/tmp/app/Sparrow.apk
# pm install -r /mnt/tmp/app/Sparrow.apk
Success
# ll /rigol/app/Sparrow.apk
36898060 2024-02-02 05:25 /rigol/app/Sparrow.apk
# ll /system/app/Sparrow/Sparrow.apk
37148630 2023-08-23 11:40 /system/app/Sparrow/Sparrow.apk

If I just copy the APK by hand (after I stop the service) instead of pm install would that break anything?

Yes. My mistake. I fixed it in post.

MD5 all the Sparrow.APK's, match them back to GEL zips.

But hint, as related to pm installs, keep an eye on base.apk
I only find these Rigol enabled packages in this location.

Code: [Select]

adb shell cmd package list packages -f
package:/data/app/com.rigol.scope-1/base.apk=com.rigol.scope
package:/data/app/com.rigol.webcontrol-1/base.apk=com.rigol.webcontrol
package:/data/app/com.rigol.launcher-1/base.apk=com.rigol.launcher

[Randy222]

DHO bloat, not needed, at least from my testing, scope runs a-ok after disabling stuff.
The default build only has the Android Demo package disabled, but we can disable more.

Disabling does appear to be boot persistent (can likely ditch printspooler) NOTE: proxyhandler seems to be needed for wifi connection to work.

I'm all for debloating to speed up the boot time. Drives me nuts! waiting for a piece of test gear to boot.

But, can you ditch the printspooler service and still print?  I think I saw someone printing from his scope last week.

Correct.
If you need to print then keep the spooler.
If you need wifi then keep that proxy item.

Otherwise disable.

[zelea2]

I have made a backup of my scope before any upgrade. My scope then was at firmware version 1.1 and these are the backup files:

Code: [Select]

37148630 Jan 31 13:19 /system/app/Sparrow/Sparrow.apk                                     
36898060 Jan 31 13:25 /rigol/app/Sparrow.apk
9739f00ca56a2fa07816c97894c08591 /system/app/Sparrow/Sparrow.apk
95fe9524be73bd7fd14384be474eff0e /rigol/app/Sparrow.apk

Today after the scope has been upgraded the about screen says version 1.2 but the above files are the same and md5sum is still as recorded.

Where is the actual update stored on this scope?

[Randy222]

I have made a backup of my scope before any upgrade. My scope then was at firmware version 1.1 and these are the backup files:

Code: [Select]

37148630 Jan 31 13:19 /system/app/Sparrow/Sparrow.apk                                     
36898060 Jan 31 13:25 /rigol/app/Sparrow.apk
9739f00ca56a2fa07816c97894c08591 /system/app/Sparrow/Sparrow.apk
95fe9524be73bd7fd14384be474eff0e /rigol/app/Sparrow.apk

Today after the scope has been upgraded the about screen says version 1.2 but the above files are the same and md5sum is still as recorded.

Where is the actual update stored on this scope?

Actual update appears to be copied out from GEL into tmp dir for install.

Can you MD5 the Sparrow APK's from the GEL files. Do any Sparrow.apk on droid filesystem match those in your GEL files?

Also noted, FW1 vs FW2 might have exact same Sparrow.apk, but the GEL archive has many other files in it that may have changed. So just because FW version changed, that alone does not mean that the Sparrow.apk has changed.

[Randy222]

DHO bloat, not needed, at least from my testing, scope runs a-ok after disabling stuff.
The default build only has the Android Demo package disabled, but we can disable more.

Disabling does appear to be boot persistent (can likely ditch printspooler) NOTE: proxyhandler seems to be needed for wifi connection to work.

I'm all for debloating to speed up the boot time. Drives me nuts! waiting for a piece of test gear to boot.

But, can you ditch the printspooler service and still print?  I think I saw someone printing from his scope last week.

In the start script, they sleep 10 after booting FPGA, guessing it needs some time to boot, and needs to be up before all the gpio driver stuff happens.

After the touchscreen driver is loaded (kinda last bit of loading devices/drivers in script) I have to do a sleep 15 before sending scpi commands. It appears the rigol packages takes some time to fully load up. If you send scpi too soon they either don't apply or the scope app crashes.

My boot time testing results:
45sec for scope to boot where it enters Run state (no screen yet)
+4sec (49) to have scope screen w/ touch
+2sec (51) for the scpi commands to take effect

So, I believe initial test/teardown boot tests were around 58sec boot. Now I have it to 49sec. 9sec faster.
Noted, this is with short list of packages disabled, and I also have in my start script an added line to insmod the 8188eu.ko wifi driver.

[zelea2]

Can you MD5 the Sparrow APK's from the GEL files. Do any Sparrow.apk on droid filesystem match those in your GEL files?

Code: [Select]

GEL v1.1:                 5b37a8772770865d3f80b9440d665005  Sparrow.apk  size 36816140
GEL v1.2 and GEL v1.2.2:  65ad4627e45b8de6ea3fc5aac95943d6  Sparrow.apk  size 36840716

Can anyone please check the MD5 sums on their /system/app/Sparrow/Sparrow.apk and /rigol/app/Sparrow.apk

I'm definitely on new firmware because my Key.data has been replaced by RKey.data. /mnt/bak and /mnt/tmp are erased at every boot so the question is still open
where is the actual code for com.rigol.scope stored?

Also when you are using the SCPI Panel control and send a string like ":SYST:OPT:INST DHO800-BW7T15@3EFC1...." do you get any reply from the scope
(like invalid license) because I'm not getting any reply back.

[Randy222]

Can you MD5 the Sparrow APK's from the GEL files. Do any Sparrow.apk on droid filesystem match those in your GEL files?

Code: [Select]

GEL v1.1:                 5b37a8772770865d3f80b9440d665005  Sparrow.apk  size 36816140
GEL v1.2 and GEL v1.2.2:  65ad4627e45b8de6ea3fc5aac95943d6  Sparrow.apk  size 36840716

Can anyone please check the MD5 sums on their /system/app/Sparrow/Sparrow.apk and /rigol/app/Sparrow.apk

I'm definitely on new firmware because my Key.data has been replaced by RKey.data. /mnt/bak and /mnt/tmp are erased at every boot so the question is still open
where is the actual code for com.rigol.scope stored?

Also when you are using the SCPI Panel control and send a string like ":SYST:OPT:INST DHO800-BW7T15@3EFC1...." do you get any reply from the scope
(like invalid license) because I'm not getting any reply back.

adb shell cmd package list packages -f
package:/data/app/com.rigol.scope-1/base.apk=com.rigol.scope
package:/data/app/com.rigol.webcontrol-1/base.apk=com.rigol.webcontrol
package:/data/app/com.rigol.launcher-1/base.apk=com.rigol.launcher

[zelea2]

adb shell cmd package list packages -f
package:/data/app/com.rigol.scope-1/base.apk=com.rigol.scope

Finally! So all updates go to /data

Code: [Select]

# ll /data/app/com.rigol.scope-1/base.apk
36840716 2024-02-02 06:54 /data/app/com.rigol.scope-1/base.apk

Which is the same file as Sparrow.apk from GEL v1.2.2 - mystery solved

[Randy222]

adb shell cmd package list packages -f
package:/data/app/com.rigol.scope-1/base.apk=com.rigol.scope

Finally! So all updates go to /data

Code: [Select]

# ll /data/app/com.rigol.scope-1/base.apk
36840716 2024-02-02 06:54 /data/app/com.rigol.scope-1/base.apk

Which is the same file as Sparrow.apk from GEL v1.2.2 - mystery solved

Not sure it's an stored "update" in that sense.
It's likely the result from the droid processing via the pm install.

It's been awhile since I did dev work for droid OS, but I believe pm relies heavily on the apk manifest to do the actual install.

Much of the Rigol coding I have seen (from just this 800/900 FW stuff) seems to indicate that they are using old levels of SDK stuff. I thought I saw some references to Eclipse too.
Using the shared uid of "system" along with long list of perms definitions, and parking the apk in /data , is an old way of doing things.
My hedgehog droid studio makes many call-outs to deprecated coding, even for the target level of droid, and I only opened Sparrow.apk, didn't even look at the other stuff.

[0xACE]

Some of what I saw in the de-compiled `Sparrow.apk` UI code looked like Compose (relatively new) vs XML (older). I would expect there are different teams working on different parts of the scope and they might have different tooling.

Additionally, they are running Android 7 which is, as we say here in the north east, wicked old.

[Randy222]

Some of what I saw in the de-compiled `Sparrow.apk` UI code looked like Compose (relatively new) vs XML (older). I would expect there are different teams working on different parts of the scope and they might have different tooling.

Additionally, they are running Android 7 which is, as we say here in the north east, wicked old.

Smali and Kotlin too.
I see a lot of XML throughout.
Pics just from Sparrow

Rigol is building on v10 (API 29.Q), but targets v7 (API 25.N_MR1) <-- 9 revs behind the latest available.

Why not run a newer droid and code in a better API? My guess is, leave the dev platform alone as long as it can make the code for the products.

[zelea2]

Also when you are using the SCPI Panel control and send a string like ":SYST:OPT:INST DHO800-BW7T15@3EFC1...." do you get any reply from the scope
(like invalid license) because I'm not getting any reply back.

Can someone try this and let me know?

I've noticed a change in CApiLicense::verifyOption function for the newer firmware: it now expects 56 bytes instead of 48 as previously.
Then they call RString::remove to remove 8 of these bytes before calling AES_decrypt. The AES_set_decrypt_key seems to be
identical as before. The encrypted bytes must be the same (48) because the AES only does 16 bytes at a time.
So there is definitely a format change for the option strings.

[Randy222]

Also when you are using the SCPI Panel control and send a string like ":SYST:OPT:INST DHO800-BW7T15@3EFC1...." do you get any reply from the scope
(like invalid license) because I'm not getting any reply back.

Can someone try this and let me know?

I've noticed a change in CApiLicense::verifyOption function for the newer firmware: it now expects 56 bytes instead of 48 as previously.
Then they call RString::remove to remove 8 of these bytes before calling AES_decrypt. The AES_set_decrypt_key seems to be
identical as before. The encrypted bytes must be the same (48) because the AES only does 16 bytes at a time.
So there is definitely a format change for the option strings.

Which 8 bytes get removed?
I might be wrong, but I think the task at-hand is to retrieve the value obtained from AES_set_decrypt_key

[zelea2]

Which 8 bytes get removed?
I might be wrong, but I think the task at-hand is to retrieve the value obtained from AES_set_decrypt_key

We already know that. The AES key is the decryption of RKey.data starting at offset 16 (what comes after "brainpoolP256r1;")
The problem is that the option string has changed, it now has 16 extra characters (8 extra bytes)

I would like to experiment with various option strings (using the new key) but whatever SCPI option command I send to the scope I get no reply.
Is this the normal way when the option license doesn't match or do I still have a bad update?
If you're on firmware v1.2 it's not that hard to put a ":SYST:OPT:INST DHO800-RLU@0000000000000000000000000000000000000" string in your web
interface and let me know the output (if any)

[Silver_Is_Money]

I'm sort of a casual Linux user with rudimentary skills.  Does upgrading a Rigol DHO804 to a higher level require upper echelon computer hacking skills, or can us children of a lesser god accomplish it without trashing a $400+ initial investment?