Hacking the Rigol DHO800/900 Scope

[AndyBig]

Apparently there is a way. There are publicly available app signing keys that can be used for testing/developing apps to be installed as system apps. Check this: https://stackoverflow.com/questions/37586255/signing-my-android-application-as-system-app

If I understand it correctly, then signing the apk with one of those keys, instead of a self-signed key, should do the trick.

There are downsides (explained on stackoverflow), but they are hardly applicable in our case.

Damn, at first glance I was even glad that such an opportunity existed However, a more careful reading of the links clarified the situation - these mean the keys that are used to assemble the system by the manufacturer. I very much doubt that Rigol signed his Android build with a test key, which can be taken from the AOSP source code.
I looked at the certificate with which the Sparrow application was signed, and it is slightly different from the test ones.

[Simon]

In Windows adb the same keys

But his were better, because they're from Linux. 

Stop trolling again.

I wrote instructions. I wrote clearly Linux manual. Im not using Windows and I cant check if everything is the same on Windows version. So You think Im worse because I dont have Windows or what?

Again, please stop trolling.

Calm down!

[gabiz_ro]

Since we have root access on scope could be used scope to sign apk by itself?
I see an apk-signer on google play store, but there may be others too.

[AndyBig]

Since we have root access on scope could be used scope to sign apk by itself?
I see an apk-signer on google play store, but there may be others too.

Of course we can, it's not difficult at all. The problem is that we do not know the correct key that needs to be signed so that the application becomes trusted and can run under the system account and have privileged access to system resources. But there is a workaround - since we have root access, we can manually move the installed application to /system/priv-app after installation, which makes the application trusted and gives privileged access.

[shapirus]

Damn, at first glance I was even glad that such an opportunity existed However, a more careful reading of the links clarified the situation - these mean the keys that are used to assemble the system by the manufacturer. I very much doubt that Rigol signed his Android build with a test key, which can be taken from the AOSP source code.
I looked at the certificate with which the Sparrow application was signed, and it is slightly different from the test ones.

It was my impression that the test keys were supported by stock android, universally. Their very purpose is test and development -- so that you can install and test the app you develop as system app on any system without creating your own build of the OS. Of course you can't publish the app signed with them on google play etc.

I may be wrong. Really need an android professional in this topic. I'm sure they are on the forum!

[AndyBig]

Regarding raising rights for a modified application.
What is the essence of the problems? Initially, from the factory, the oscilloscope application - Sparrow.app - was signed by Rigol with the same key with which he signed the Android kernel when assembling it. This allows the application to run under the sysytem account and gives it privileged access to system resources and system API calls. For example, some API calls require such privileged access during the screenshot process. But we don’t know this key, so we have no way to sign the application with it after modification. Because of this, our application runs under the account of an ordinary user and the system denies access to some API calls when taking a screenshot. Our modified application can't take screenshots, yeah. Perhaps there are similar restrictions in some other areas, but I only noticed this.
But I found a description of a workaround online, available if you have root access to the system, and we have it The point of this workaround is to place the application in /system/priv-app. Applications located in this directory are automatically considered trusted and receive privileged access, almost the same as applications running under the system account (and maybe completely the same, I don’t fully understand this).

To do this, we first need to install the application in the usual way, so that during installation a .odex file is created for our application in the /data/app directory (in its own subdirectory, separate for each application, in our case it will be /data/app/com.rigol.scope-1).
Further:

• Stop the work of the com.rigol.launcher application first, and then com.rigol.scope.
• In the /system/priv-app directory we create a directory with the file name of our application, in our case it is /system/priv-app/Sparrow.
• Copy the lib and oat subdirectories with all contents into it from the /data/app/com.rigol.scope-1 directory, recursively including nested subdirectories.
• Copy the file of our modified application - Sparrow.apk - into the same directory (it must be written in advance from the PC somewhere accessible on the oscilloscope, for example in /rigol/data).
• Assign attributes 755 (rwxr-xr-x) to the /system/priv-app/Sparrow directory and all its contents at full depth recursively. I'm actually not sure if this step is necessary, but I was having some kind of glitch until I assigned these attributes. Maybe it was a coincidence.
• Completely delete the /data/app/com.rigol.scope-1 directory with all its contents.
• Reboot the oscilloscope.

That's it, now our application, although it still runs under the account of a regular user, becomes trusted and has privileged access to system APIs. And it can take screenshots again

When updating our application after the next modification, we will need to repeat all this. So I'm thinking of writing a script with all these actions and putting it in /rigol/data. During the next update after the standard installation process, simply drop a new application file into /rigol/data and run this script there, which will do everything necessary. But while we haven’t gotten around to it yet, we need to check a couple more points and test such an installation using a script.

[AndyBig]

It was my impression that the test keys were supported by stock android, universally. Their very purpose is test and development -- so that you can install and test the app you develop as system app on any system without creating your own build of the OS. Of course you can't publish the app signed with them on google play etc.

No, the point of test keys is that they sign the kernel and application assembly at the testing stage. These are just known working keys as an example from Google. After everything has been debugged and tested, before release the kernel and all applications are re-signed with their own vendor key. Google strongly recommends doing this, and I am sure that Rigol did just that.
I even looked at the certificate (open, of course) that signed the original application - the certificate data, although very slightly, differs from those that come with AOSP. Rigol changed the email address in the certificate, leaving everything else as it was in test keys

Code: [Select]

Verifies
Verified using v1 scheme (JAR signing): false
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Verified using v3.1 scheme (APK Signature Scheme v3.1): false
Verified using v4 scheme (APK Signature Scheme v4): false
Verified for SourceStamp: false
Number of signers: 1
Signer #1 certificate DN: EMAILADDRESS=hexiaohua@rigol.com, CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US
Signer #1 certificate SHA-256 digest: f48e7189aac174df7fd19acf58b6d15832760fcf25ac0a6d4bcd5fc1974d4c03
Signer #1 certificate SHA-1 digest: df345a93532e902ff6291668c20ad69da3b72ff6
Signer #1 certificate MD5 digest: 40490c2e0b280e29ba5e46205272e3dc
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048
Signer #1 public key SHA-256 digest: ca871f06fa7ffaa5beda2179a2278a0474d98e6b5e11d9aab2dfb590d8e57292
Signer #1 public key SHA-1 digest: 90ff0ddf5a0881ea080558b3b585dd0352342d8e
Signer #1 public key MD5 digest: 78d923a60c0963a38de1ee05b4556031
-----BEGIN CERTIFICATE-----
MIIECzCCAvOgAwIBAgIUINzTdl44KGbN5zrMwq1QEIADPRMwDQYJKoZIhvcNAQEF
BQAwgZQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQH
DA1Nb3VudGFpbiBWaWV3MRAwDgYDVQQKDAdBbmRyb2lkMRAwDgYDVQQLDAdBbmRy
b2lkMRAwDgYDVQQDDAdBbmRyb2lkMSIwIAYJKoZIhvcNAQkBFhNoZXhpYW9odWFA
cmlnb2wuY29tMB4XDTIwMDcxMDAzNDg1OVoXDTQ3MTEyNjAzNDg1OVowgZQxCzAJ
BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFp
biBWaWV3MRAwDgYDVQQKDAdBbmRyb2lkMRAwDgYDVQQLDAdBbmRyb2lkMRAwDgYD
VQQDDAdBbmRyb2lkMSIwIAYJKoZIhvcNAQkBFhNoZXhpYW9odWFAcmlnb2wuY29t
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtmIPvmnFTAd95RNbqCLS
iOKrilEABcW8rtBCu70ofoOpOWLX5R2NBPWtYtOq+y4EF/dJddUVxOeOdTBngW8J
GfQiU7rqxxzWrskXh437KZYmcnAJxrEQkM7lBifPIYhihlmGCRVMM1eBZRdaRHjA
bSsM7flBMPhM8tpEX3g7kIoKa0NFrb+Z4206WrWX+0tIsvo8yA92pyqcwh4p2Ayx
cUnNWRnQdRU5iunuQmR5IS1uvryVyxYVX4T+WK5bQsupeXuwnTuCHSkJP2WMc5lE
6FZ7B1RcS7Lk+KQQ67S7TaqKp/iMgKM1l99Q74KaYoYvAhoNO6S7PAvZs/4DWnRu
5QIDAQABo1MwUTAdBgNVHQ4EFgQUyFB6a1gMxXBZ8LVszL0IQhTz5KkwHwYDVR0j
BBgwFoAUyFB6a1gMxXBZ8LVszL0IQhTz5KkwDwYDVR0TAQH/BAUwAwEB/zANBgkq
hkiG9w0BAQUFAAOCAQEAovdgpHN5gi9BMTNspmart0EH8fG4aqNWGZUxEM/dsR9K
+aP7rA3MyKwzjxNzaH8tg9TOD6zaWAZIkNtPXCVkTp+9XEp7WE1fP0xcqZpJoxTI
bydPrvXvfk819xCivXttmsK0WgvBPfnM0V6ARMKpCTSzZsSLkEpBS8Z+3/2gWG07
q1fbiblpv1YxH+cEhA8gE2rbIWX/EleJxYFGFY6fUBi4ENHG3Wrbpgnmw9WWXuNs
NfbAlbwqA5blWu16rFpQUrkjqaF7FbChBjnvdGPOU+gcSmwAmH3M8bzxnfdGdW+2
kRz3p/JLF8ypivfkdUqYIW69cwuygcvlhbKaK31wtA==
-----END CERTIFICATE-----

And this is already enough for the key to become completely different I tried to sign the application with test keys, but as expected, it did not give anything.

Really need an android professional in this topic. I'm sure they are on the forum!

Agree! I would really like an experienced Android developer to join the discussion.

[Randy222]

The matching pub key appears to be located in otacerts.zip on the filesystem.
I added my own pub key to that zip and was attempting to do an OTA install of edited APK, but when it boots in recovery I can't find any navigation keys to move the menu.

It's about impossible to reload the Sparrow apk using the android.uid.system shared user, the apk must be signed with a key that matches the pub key in the android.uid.system keystore. I cannot find a way to add a key to that keystore.

There is however some further hacking that can cause pm install to skip sig verify, but it's very convoluted and appears to need recovery mode, which I cannot navigate.


As a side note, I was curious to see what Rigol had done with Sparrow. My scope is v00.01.02.00.00, I removed Sparrow and took Sparrow from a 00.01.02.00.02 GEL file and installed that. Installs just fine, but the only change that I notices was the whole RKey.data stuff. Nothing else appears to have changed, the scope runs exactly as it did before. I ran the zelea2 util to regen keys on the existing 914 vendor.bin.

[Randy222]

Damn, at first glance I was even glad that such an opportunity existed However, a more careful reading of the links clarified the situation - these mean the keys that are used to assemble the system by the manufacturer. I very much doubt that Rigol signed his Android build with a test key, which can be taken from the AOSP source code.
I looked at the certificate with which the Sparrow application was signed, and it is slightly different from the test ones.

It was my impression that the test keys were supported by stock android, universally. Their very purpose is test and development -- so that you can install and test the app you develop as system app on any system without creating your own build of the OS. Of course you can't publish the app signed with them on google play etc.

I may be wrong. Really need an android professional in this topic. I'm sure they are on the forum!

android.uid.system has a keystore. apps running in context of android.uid.system (uid 1000) need to be signed with a private key that matches a pub key inside that keystore. Unless Rigol gives you their private key used for signing, there is no way to do it. Their SDK signs Android, and the android.uid.system belongs to the compiled/signed Android OS.

https://android.stackexchange.com/questions/208523/how-androids-permissions-mapping-with-uids-gids-works

[Randy222]

Since we have root access on scope could be used scope to sign apk by itself?
I see an apk-signer on google play store, but there may be others too.

Of course we can, it's not difficult at all. The problem is that we do not know the correct key that needs to be signed so that the application becomes trusted and can run under the system account and have privileged access to system resources. But there is a workaround - since we have root access, we can manually move the installed application to /system/priv-app after installation, which makes the application trusted and gives privileged access.

In the Android model, only apps that run under same shared context (uid) can share data between the apps.
That said, if you park an app in app-priv running in some other uid context, that app still can't share data with other apps.
Does Sparrow apk need to share data with other apps and vice-versa? Might not be.

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

We won't be able to sign an edited APK to run under android.uid.system, but we can likely allow the app to do everything it needs to do. I wonder if the whitelisted permission allows the app to share data with other apps. Not 100% clear to me.

[norbert.kiszka]

In the Android model, only apps that run under same shared context (uid) can share data between the apps.
That said, if you park an app in app-priv running in some other uid context, that app still can't share data with other apps.
Does Sparrow apk need to share data with other apps and vice-versa? Might not be.

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

We won't be able to sign an edited APK to run under android.uid.system, but we can likely allow the app to do everything it needs to do. I wonder if the whitelisted permission allows the app to share data with other apps. Not 100% clear to me.

Android is based on Linux kernel and there are uid and gid. This second one is a id of a group. Anyway, I dont know how much its used, but it is.

[AndyBig]

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

We won't be able to sign an edited APK to run under android.uid.system, but we can likely allow the app to do everything it needs to do. I wonder if the whitelisted permission allows the app to share data with other apps. Not 100% clear to me.

I looked at this file and found that it requires you to assign specific permissions to applications. For example:

Code: [Select]

    <assign-permission name="android.permission.UPDATE_APP_OPS_STATS" uid="audioserver" />
    <allow-in-power-save package="com.android.providers.downloads" />
I didn't find an example of how to put just the application name there.

[AndyBig]

As a side note, I was curious to see what Rigol had done with Sparrow. My scope is v00.01.00.00.00, I removed Sparrow and took Sparrow from a 00.01.02.00.02 GEL file and installed that. Installs just fine, but the only change that I notices was the whole RKey.data stuff. Nothing else appears to have changed, the scope runs exactly as it did before. I ran the zelea2 util to regen keys on the existing 914 vendor.bin.

Starting from version 00.01.02.00.00, the calibration process has been changed. Calibration data is recorded in a different format and is larger in size. And starting with this version, the problem of vertical channel shift when upgrading an oscilloscope from DHO800 to DHO900 has gone away.

[Randy222]

As a side note, I was curious to see what Rigol had done with Sparrow. My scope is v00.01.00.00.00, I removed Sparrow and took Sparrow from a 00.01.02.00.02 GEL file and installed that. Installs just fine, but the only change that I notices was the whole RKey.data stuff. Nothing else appears to have changed, the scope runs exactly as it did before. I ran the zelea2 util to regen keys on the existing 914 vendor.bin.

Starting from version 00.01.02.00.00, the calibration process has been changed. Calibration data is recorded in a different format and is larger in size. And starting with this version, the problem of vertical channel shift when upgrading an oscilloscope from DHO800 to DHO900 has gone away.

Sorry, that was my mistake. My 804 came with 00.01.02.00.00
I fixed my post.

[Randy222]

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

We won't be able to sign an edited APK to run under android.uid.system, but we can likely allow the app to do everything it needs to do. I wonder if the whitelisted permission allows the app to share data with other apps. Not 100% clear to me.

I looked at this file and found that it requires you to assign specific permissions to applications. For example:

Code: [Select]

    <assign-permission name="android.permission.UPDATE_APP_OPS_STATS" uid="audioserver" />
    <allow-in-power-save package="com.android.providers.downloads" />


Scroll down near end of file, there's a system app whitelisted permission. Just add another line there for com.rigol.scope
I didn't find an example of how to put just the application name there.

[Randy222]

In the Android model, only apps that run under same shared context (uid) can share data between the apps.
That said, if you park an app in app-priv running in some other uid context, that app still can't share data with other apps.
Does Sparrow apk need to share data with other apps and vice-versa? Might not be.

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

We won't be able to sign an edited APK to run under android.uid.system, but we can likely allow the app to do everything it needs to do. I wonder if the whitelisted permission allows the app to share data with other apps. Not 100% clear to me.

Android is based on Linux kernel and there are uid and gid. This second one is a id of a group. Anyway, I dont know how much its used, but it is.

The only thing Android has in common with linux distros is the kernel source code. After that Android looks and runs very different than everything else.
Android uses 1000-9999 for priveleged UID, where as in all linux distros (RH, debian, slack, etc etc) they use the 1000-9999 for low priv UID.

[AndyBig]

Scroll down near end of file, there's a system app whitelisted permission. Just add another line there for com.rigol.scope

Oh yes, I found it.

Code: [Select]

<!-- These are the packages that are white-listed to be able to run as system user -->
     <system-user-whitelisted-app package="com.android.settings" />
As far as I understand, it may allow the application to run under the system account even if the application is not signed with a system key. I'll have to try it, thanks

[AndyBig]

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.

[AndyBig]

I found how to remove an LA I don’t need from the bottom panel and, after digging deeper into the code, I figured out how to enable the date and time display

[ebastler]

I found how to remove an LA I don’t need from the bottom panel and, after digging deeper into the code, I figured out how to enable the date and time display

 

Any chance you can get the info boxes for CH1..4 to display the probe divider setting? Only possible if the information is available to the display routine, I guess.

Edit: I hope you are keeping good records of all the changes you make. For a future new firmware, I assume you have to manually re-do them all over, right?

[norbert.kiszka]

But the application still launched under the account of a regular user

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

[shapirus]

FWIW, com.rigol.scope runs under uid 1000, whereas the processes run by root run under uid 0.

[Randy222]

FWIW, com.rigol.scope runs under uid 1000, whereas the processes run by root run under uid 0.

Android is the red-head linux.
https://android.stackexchange.com/questions/208523/how-androids-permissions-mapping-with-uids-gids-works

[AndyBig]

Any chance you can get the info boxes for CH1..4 to display the probe divider setting? Only possible if the information is available to the display routine, I guess.

At the moment, I don’t see such a possibility yet Although I would like to have it myself.

Edit: I hope you are keeping good records of all the changes you make. For a future new firmware, I assume you have to manually re-do them all over, right?

Yes, that’s right, for the new firmware version you will have to make all the changes again. Although it’s not necessary to do everything manually I try to mark all my changes in the source code with a comment so that later it’s easy to find them all

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

[Randy222]

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?