Hacking the Rigol DHO800/900 Scope

[Randy222]

Try adding a whitelisted system entry after the one in /etc/permissions/platform.xml, add "com.rigol.scope"

Unfortunately, it didn't help. First I just pasted <system-user-whitelisted-app package="com.rigol.scope" /> into /etc/permissions/platform.xml and rebooted the oscilloscope. But the application still launched under the account of a regular user, and the system denied him access to the API when he tried to take a screenshot. I then rebuilt the application adding the system userid and tried to install it, but the installation failed with INSTALL_FAILED_SHARED_USER_INCOMPATIBLE error, same as before.
This method doesn't work.

So, dig some more, look at "ro.control_privapp_permissions=log", I think that's in build.prop   see --> https://source.android.com/docs/core/permissions/perms-allowlist
Then see if that log spits up a perms issue, which you can likely fix in an xml file.

[norbert.kiszka]

Even if You change executable uid? Have You tried to make "ugly" move with uid 0?

If you tell me how to do this, I'll try

I found previously at some forum about sudo and su in Android, but I dont see it in my bookmarks and history. Too much using incognito browser for almost everything...

However, when I googled for phrase "android sudo", I found this:



BTW. Currently Im doing hacking with completly different approach - more complicated at the beginning but will be easier later. I managed to run other U-boot (Grub doesnt work unless loaded by U-boot) and couple different Linux distros - somehow its not stable - not at all. By now, it works only on HDMI and internal LCD is blank (no backlight). Now I have idea to make dual-boot with original U-boot and use original kernel from this Android (never tried this before) - I will try it later.

[Randy222]

Even if You change executable uid? Have You tried to make "ugly" move with uid 0?

If you tell me how to do this, I'll try

I found previously at some forum about sudo and su in Android, but I dont see it in my bookmarks and history. Too much using incognito browser for almost everything...

However, when I googled for phrase "android sudo", I found this:



BTW. Currently Im doing hacking with completly different approach - more complicated at the beginning but will be easier later. I managed to run other U-boot (Grub doesnt work unless loaded by U-boot) and couple different Linux distros - somehow its not stable - not at all. By now, it works only on HDMI and internal LCD is blank (no backlight). Now I have idea to make dual-boot with original U-boot and use original kernel from this Android (never tried this before) - I will try it later.

The util you found appears to be a way to "root" an otherwise locked Android, like most phones are.

We can SSH in as root.
We can also be root using adb.


We have root access to the DHO system, we can change anything on the system.

What we don't have is, a private key used to sign everything. Android however is flexible, we can still run stuff that is not signed by system key, but those apps become "restricted".

[shapirus]

Since we have root and physical access to storage, we can modify everything. This includes modifying the mechanism that verifies the apk signature to decide whether to allow it to run as a system app. I wonder how feasible this would be. Food for thought.

[ebastler]

Since we have root and physical access to storage, we can modify everything. This includes modifying the mechanism that verifies the apk signature to decide whether to allow it to run as a system app. I wonder how feasible this would be. Food for thought.

That's what I was wondering about. If applications get signed with a (non-available) private key, the signature must be checked (when starting the app) against a public key that is somewhere in the Android system. Is it known where that key resides, and can it be replaced?

[AndyBig]

However, when I googled for phrase "android sudo", I found this:

I know how to get root in the terminal. But I don’t know how to make the application run as root. Well, as far as I understand, the root and the system are different entities. Once the application is rooted, it will be able to access all resources, but it will still be limited in API calls.

So, dig some more, look at "ro.control_privapp_permissions=log", I think that's in build.prop   see --> https://source.android.com/docs/core/permissions/perms-allowlist
Then see if that log spits up a perms issue, which you can likely fix in an xml file.

Honestly, I don't see the point in digging that deep. All the same, the application will not work under the system account, and a method to bypass the restrictions has already been found

That's what I was wondering about. If applications get signed with a (non-available) private key, the signature must be checked (when starting the app) against a public key that is somewhere in the Android system. Is it known where that key resides, and can it be replaced?

Looks like this is the key - https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5357267/#msg5357267

[Randy222]

Since we have root and physical access to storage, we can modify everything. This includes modifying the mechanism that verifies the apk signature to decide whether to allow it to run as a system app. I wonder how feasible this would be. Food for thought.

That's what I was wondering about. If applications get signed with a (non-available) private key, the signature must be checked (when starting the app) against a public key that is somewhere in the Android system. Is it known where that key resides, and can it be replaced?

Apps need to be installed before they can run.
The permission "allow apps from unknown sources" means sig verify is skipped, but the apk still needs to be signed. Non trusted apps will be limited in various ways. Example, the only way for app to run with all the system priveleges is for the app to be signed with trusted system key. A self signed app cannot use shared user android.uid.system, Android won't allow that, etc.

Having the public key does not help at all. But I wonder if we can install another pub key into trusted area of Android, for android.uid.system? I suspect not.

The Rigol droid is kinda old, they are using many deprecated siwtches. See --> https://developer.android.com/guide/topics/manifest/manifest-element#uid

[ebastler]

Apps need to be installed before they can run.

Ok, so replace "checked when starting the app" by "checked when installing the app". But the check is still performed by the local Android instance, by verifying the signature against some (public) key which exists locally, right? So the idea was to replace that key with one where we have both, the private key for signing and the public one for checking.

The permission "allow apps from unknown sources" means sig verify is skipped, but the apk still needs to be signed. Non trusted apps will be limited in various ways. Example, the only way for app to run with all the system priveleges is for the app to be signed with trusted system key. A self signed app cannot use shared user android.uid.system, Android won't allow that, etc.

That was not what I meant.

But I wonder if we can install another pub key into trusted area of Android, for android.uid.system?

That was what I meant! 

 

[Randy222]

However, when I googled for phrase "android sudo", I found this:

I know how to get root in the terminal. But I don’t know how to make the application run as root. Well, as far as I understand, the root and the system are different entities. Once the application is rooted, it will be able to access all resources, but it will still be limited in API calls.

So, dig some more, look at "ro.control_privapp_permissions=log", I think that's in build.prop   see --> https://source.android.com/docs/core/permissions/perms-allowlist
Then see if that log spits up a perms issue, which you can likely fix in an xml file.

Honestly, I don't see the point in digging that deep. All the same, the application will not work under the system account, and a method to bypass the restrictions has already been found

That's what I was wondering about. If applications get signed with a (non-available) private key, the signature must be checked (when starting the app) against a public key that is somewhere in the Android system. Is it known where that key resides, and can it be replaced?

Looks like this is the key - https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5357267/#msg5357267

The Rigol apps are chown'd root:root. The manifest only states to use shared user id of "android.uid.system". This is for perms reasons, and, apps with same shared uid can share data. I am not sure what data is shared between the Rigol apps and others. However, to get that level of shared user perms of "system" (inherited) the app's MUST be signed with same private key that signed the droid (rom).

You can perhaps replace that shared uid in manifest for all the Rigol apps, but from there I am not sure what breaks or not. The app-priv logging switch should log perms requests that fail, allowing you to see what the issue is after moving app away from shared uid of "system".

[Randy222]

Apps need to be installed before they can run.

Ok, so replace "checked when starting the app" by "checked when installing the app". But the check is still performed by the local Android instance, by verifying the signature against some (public) key which exists locally, right? So the idea was to replace that key with one where we have both, the private key for signing and the public one for checking.

The permission "allow apps from unknown sources" means sig verify is skipped, but the apk still needs to be signed. Non trusted apps will be limited in various ways. Example, the only way for app to run with all the system priveleges is for the app to be signed with trusted system key. A self signed app cannot use shared user android.uid.system, Android won't allow that, etc.

That was not what I meant.

But I wonder if we can install another pub key into trusted area of Android, for android.uid.system?

That was what I meant! 

There are ways to bypass sig checking of pm, MAGISK
But that whole process is for non-rooted droids. Most droids are locked and don't allow the permission "allow install of apps from unknown sources". In thise cases the hackers figured out a way to still install a non-trusted app. But that does not escape the security controls around android.uid.system and the keys used to signed the system. It only allows the install of a self-signed app, which we are already doing, because the DHO is a root'd device, already open to us using root.

The whole security model with how Android runs, even root is restricted.

[AndyBig]

The Rigol apps are chown'd root:root.

How did you determine this? I couldn't see any evidence anywhere that Rigol's applications run under root. All files they create are owned by the system.

The manifest only states to use shared user id of "android.uid.system". This is for perms reasons, and, apps with same shared uid can share data. I am not sure what data is shared between the Rigol apps and others. However, to get that level of shared user perms of "system" (inherited) the app's MUST be signed with same private key that signed the droid (rom).

Yes, I know. This is discussed throughout the last few pages of the topic
I think that Rigol's applications do not exchange any common data with each other. At least I didn't see any signs of it.

You can perhaps replace that shared uid in manifest for all the Rigol apps, but from there I am not sure what breaks or not. The app-priv logging switch should log perms requests that fail, allowing you to see what the issue is after moving app away from shared uid of "system".

Probably, replacing the user ID android.uid.system with any other one in the webcontrol application will lead to its inoperability, because it requires access to system resources that are only allowed to applications under the system account. I'm not sure about the launcher application, but it is possible that it will not be able to work under a non-system account.

[norbert.kiszka]

One very simple command to copy raw binary data from a serial block device - including SD cards:

Code: [Select]

cp /dev/sdb /home/userHomeDirectory/rawBinaryImageOfFancySDcardFromScope.fancyLongFileExtension
To be less fancy, I can use any graphical file manager in Linux to make exactly same thing.

Does using the cp command on a block device create a file that you can image back to a new block device, and it will boot?

Yes, it will boot. cp does binary copy of a file. dd is more fancy, because it can count block, do skips etc. If You dont need fancy dd options, just a raw copy, cp is good enough and faster. Anyway, You can even use GUI app to do the same as cp does.

Every file is a string of binary data - even text files are binary (but with ASCII contents and mostly new line at the end). Filesystem is also string of binary data - FS driver in operating system reads this and divide in small parts called files.

BTW. Right now Im fighting to exclude kernel and initrd from sd card - this is nowhere in 5 filesystems, but hided somewhere before.

[Randy222]

The Rigol apps are chown'd root:root.

How did you determine this? I couldn't see any evidence anywhere that Rigol's applications run under root. All files they create are owned by the system.

The manifest only states to use shared user id of "android.uid.system". This is for perms reasons, and, apps with same shared uid can share data. I am not sure what data is shared between the Rigol apps and others. However, to get that level of shared user perms of "system" (inherited) the app's MUST be signed with same private key that signed the droid (rom).

Yes, I know. This is discussed throughout the last few pages of the topic
I think that Rigol's applications do not exchange any common data with each other. At least I didn't see any signs of it.

You can perhaps replace that shared uid in manifest for all the Rigol apps, but from there I am not sure what breaks or not. The app-priv logging switch should log perms requests that fail, allowing you to see what the issue is after moving app away from shared uid of "system".

Probably, replacing the user ID android.uid.system with any other one in the webcontrol application will lead to its inoperability, because it requires access to system resources that are only allowed to applications under the system account. I'm not sure about the launcher application, but it is possible that it will not be able to work under a non-system account.

ssh in
ls -al /system/app/Webcontrol/Webcontrol.apk
ls -al /system/app/Launcher/Launcher.apk
ls -al /system/app/Sparrow/Sparrow.apk

does it show root root ? owner:group it belongs to. They are all rw r r (644) perms too.

This does not mean the apk runs as that uid or gid.
However the apk runs (natively, vm, etc), the uid that starts it or calls it up into another running process (like vm in vm host process), that's the uid the apk runs as.

If a.jar is nobody:nobody and I am in as root, I can call java -jar a.jar to run that jar file.

In std Linux, if the APK's are root:root and 644, then we can say "system" uses the read permission to read in the APK.

***************************************

Then do
ps |grep scope
ps |grep launcher
ps |grep webcontrol

notice all those apk packages are running as "system" user. The "system" user loaded and ran those APK's.

And it all makes sense, the actual running APK is not in /system/app or priv-app
Notice the APK directories in /data/app
/data/app/com.rigol.launcher-1/
ls -al /data/app/com.rigol.launcher-1/base.apk

BAM, it's chown'd system:system

I believe the pm install copies the APK and parks it in /data/app as "system" user. From there uid 1000 does whatever it wants with that file (apk). It's also possible that the base.apk gets to /data/app/ during boot (need to verify).
The base.apk has been altered, md5's of the base apk and their corresponding apk in /system/app/ are not the same. I need to copy out the base.apk and take a look at it, compare, etc.

base.apk is smaller by about 105B on my ntfs filesystem. Looking inside the apk's side-by-side, no obvious diffs, each carries the same signature too.

Something got goofy on my DHO, after reinstalll of the Rigol signed Sparrow, it no longer shows as a system app "adb shell cmd package list packages -s"

[AndyBig]

ssh in
ls -al /system/app/Webcontrol/Webcontrol.apk
ls -al /system/app/Launcher/Launcher.apk
ls -al /system/app/Sparrow/Sparrow.apk

does it show root root ? owner:group it belongs to. They are all rw r r (644) perms too.

I apologize, I did not carefully read your message to which I was responding. For some reason I read “Rigol applications are executed under the root account.” I apologize again.

[bkw]

Linux version of the license generator script.

Update: do not use on firmware 00.01.02.00.02 or later.
Instead use https://github.com/zelea2/rigol_vendor_bin

[AndyBig]

Linux version of the license generator script.

Apparently this tool was never updated to work with the latest firmware version 00.01.02.00.02.

[bkw]

Seems to have worked on mine?
Else I wouldn't have offered it.
I updated to the latest firmware before running this.
(directly from the net, via the mis-named "Upgrade" menu option, which does not upgrade anything, it just does firmware update)

My scope was 00.01.01 when I got it this afternoon.
I connected it to my lan via ethernet and the main menu gear icon got a red dot on it after a few minutes.
The "upgrade" menu option updated it to 00.01.02.
After that I wrote that bash script and it worked.

And now that you make me wonder...

The About screen only shows 00.01.02 and not the last part.
I show a build date of only 2023/11/09 when the latest firmware from the web site has dates later than that.
So I just applied 00.01.02.02 via usb... and now the build date says 2024/01/03

....and BW is back to 70M and mem depth back to 25M

...and the keys generated by the tool no longer work.

I guess that answers the question of if Rigol might do something to break existing keys. They absolutely did.

[Fungus]

I just applied 00.01.02.02 via usb... and now the build date says 2024/01/03

....and BW is back to 70M and mem depth back to 25M

...and the keys generated by the tool no longer work.

Old news, there's been a new key generator for ages.

I guess that answers the question of if Rigol might do something to break existing keys. They absolutely did.

Nonsense. At best they were just fiddling with the code preparing to sell official upgrades or something like that.

If Rigol wanted to stop hackers they'd disable ADB to stop people changing vendor.bin or downloading key.dat (which is needed to generate keys).

Changing vendor.bin is the easiest hack and gets you more features than the key generator does.

[AndyBig]

The About screen only shows 00.01.02 and not the last part.

Tap three times on the About menu item

I show a build date of only 2023/11/09 when the latest firmware from the web site has dates later than that.
So I just applied 00.01.02.02 via usb... and now the build date says 2024/01/03

....and BW is back to 70M and mem depth back to 25M

...and the keys generated by the tool no longer work.

I guess that answers the question of if Rigol might do something to break existing keys. They absolutely did.

Yes, Rigol has changed the option checking process in 00.01.02.00.02. But this problem has long been solved by the user Zelea2, here is a tool he developed for a good mood - https://github.com/zelea2/rigol_vendor_bin
And, by the way, I like it better - it’s easier to use and you don’t need to install any programming languages.

[bkw]

Wonerdful!
It worked perfect.
Thank you and wow thank you Zelea

[bkw]

I just applied 00.01.02.02 via usb... and now the build date says 2024/01/03

....and BW is back to 70M and mem depth back to 25M

...and the keys generated by the tool no longer work.

Old news, there's been a new key generator for ages.

The first post doesn't mention this at all.
All else flows from that fact.

[norbert.kiszka]

If Rigol wanted to stop hackers they'd disable ADB to stop people changing vendor.bin or downloading key.dat (which is needed to generate keys).

If they disable ADB, it will be still possible to change it directly on SD card with little more effort (or with easier way with flashing image from other model). So they dont want to waste time for this.

[Mechatrommer]

Yes, Rigol has changed the option checking process in 00.01.02.00.02. But this problem has long been solved by the user Zelea2, here is a tool he developed for a good mood - https://github.com/zelea2/rigol_vendor_bin

i used that tool few days ago on FW 00.01.02.00.02 to change vendor.bin from 804 to 924S. and pushing it and reboot, i got all i need, 250MHz BW all options unlimited forever, bode plot ready and my SN retained yay! (except changes DHO8 to DHO9) no need to do step 3 and 6 in https://www.eevblog.com/forum/testgear/hacking-the-rigol-dho800900-scope/msg5254071/#msg5254071

[shapirus]

bode plot ready

But it lacks hardware support, right? This needs signal generator, which the DHO800 don't have, if I understand correctly.

[ebastler]

bode plot ready

But it lacks hardware support, right? This needs signal generator, which the DHO800 don't have, if I understand correctly.

Mechatrommer is also working on a replica AWG board. (It's a piggyback board that can be added to the DHO800 too.)