Hacking the Rigol DHO800/900 Scope

[AndyBig]

By the way, the login/password for the "Network Settings" page is admin/rigol

[AndyBig]

I was able to take screenshots in .png, but remote control did not work, despite the fact that I inserted all the necessary permissions into the manifest (seemingly) and moved the application to /system/priv-app . One of the permissions needed for remote access is never granted to the application:

Code: [Select]

  Requires MANAGE_MEDIA_PROJECTION in order to grant projection permission
And I haven't been able to do anything about it yet.
Plus there is no permission to implement touch events:

Code: [Select]

  InputDispatcher: Asynchronous input event injection permission denied.

[Fungus]

That the server pushes the picture with 1280x800 size is certain.

It's an HTML canvas with that size defined in the code.

[shapirus]

Code: [Select]

  InputDispatcher: Asynchronous input event injection permission denied.

Where are you seeing these logs?

[shapirus]

So I made the scope unbootable when trying to make this damn app run under "system" user. I hate android for not letting me have full control over the device I own.

Anyway, is there any way to enter some recovery mode to mount a partition and change files? There's no network connection at this stage, and adb over USB isn't working either. In fact, there's no activity whatsoever when I connect the scope via the USB port on the rear to my computer, the computer doesn't see any new connected USB device at all.

I'm now going to take out the SD card and mount the partition manually in a card reader, but it'd be nice to be able to do this without taking the scope apart.

[ebastler]

I hate android for not letting me have full control over the device I own.

I think you have already achieved far more control over the device than Rigol ever intended to give you.

[AndyBig]

It's an HTML canvas with that size defined in the code.

There the video encoder itself is adjusted to a resolution of 1280x800.

Code: [Select]

03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: Rkvpu_Enc_ComponentInit(1321): use vpuapi.
03-23 15:25:52.444 241 1640 E ROCKCHIP_VIDEO_ENC: ConvertOmxAvcLevelToAvcSpecLevel(1093): ConvertOmxAvcLevelToAvcSpecLevel: 512
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: Rkvpu_Enc_GetEncParams(1547): encode params init settings:
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: width = 1280
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: height = 800
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: bitRate = 4096000
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: framerate = 30
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: format = 10
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: enableCabac = 0,
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: cabacInitIdc = 0,
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: intraPicRate = 59,
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: profileIdc = 66,
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: levelIdc = 31,
03-23 15:25:52.444 241 1640 I ROCKCHIP_VIDEO_ENC: rc_mode = 1,


Where are you seeing these logs?

logcat command in console

So I made the scope unbootable when trying to make this damn app run under "system" user. I hate android for not letting me have full control over the device I own.

Anyway, is there any way to enter some recovery mode to mount a partition and change files? There's no network connection at this stage, and adb over USB isn't working either. In fact, there's no activity whatsoever when I connect the scope via the USB port on the rear to my computer, the computer doesn't see any new connected USB device at all.

I'm now going to take out the SD card and mount the partition manually in a card reader, but it'd be nice to be able to do this without taking the scope apart.

Oh, fellow failure ) I also killed the loading of the oscilloscope by trying to make the application system using the modperms.sh script from Randy222 )
Then I connected to the hardware UART and through it in the console I restored the original file /system/etc/permissions/platform.xml

[shapirus]

So I've been failing so far.

None of the following in platform.xml seems to work:

Code: [Select]

    <assign-permission name="android.permission.INJECT_EVENTS" uid="u0_a32" />
    <assign-permission name="android.permission.MANAGE_MEDIA_PROJECTION" uid="u0_a32" />
    <assign-permission name="android.permission.ACCESS_SURFACE_FLINGER" uid="u0_a32" />

    <system-user-whitelisted-app package="com.rigol.webcontrol" />

The app still lacks the required permissions. It runs under the "u0_a32" user. I still think there must be a way to make it run under "system" user, maybe by first installing it as a non-system app and then converting to system.

...but wait, the com.rigol.scope app needed system permissions to take screenshots as well, right? How was that fixed? Was the whitelist entry in platform.xml enough for it?

p.s. I fixed the boot issues by mounting the respective fs on the SD card directly in a card reader. Yes I had to remove the back lid of the scope and take the card out for this. Maybe I will inspect the boot failure logs more closely and try to understand what I did wrong, and maybe there's a way to do it right.
What I did is I tried to change the user id to 1000 in whatever files (and they were appops.xml, packages.list, packages.xml under /data/system) contained the "10032" user id that the app was installed for as a non-system app.

[AndyBig]

...but wait, the com.rigol.scope app needed system permissions to take screenshots as well, right? How was that fixed? Was the whitelist entry in platform.xml enough for it?

For screenshots (READ_FRAME_BUFFER and ACCESS_SURFACE_FLINGER permissions), just move the application to /system/priv-app . This is obviously not enough for the MANAGE_MEDIA_PROJECTION permission. I do not know why it is so.

We would need to make our own Android assembly, signed with our own key. Then we will have full control over system applications. But I have no experience and no knowledge in assembling Android or Linux systems

[shapirus]

ok I've given up for now. Nothing of what I have tried was successful.

It seems to be clear where in the decompiled sources the image/video size is set -- the trick is to search for hex representation of the numbers, that is, 0x320 and 0x500, and change them to 0x258 and 0x400, and likewise for the 1920x1080 video recording. However, it's impossible to test it until we find a way to run the recompiled app as a system app with all the permissions required to use system api.

[AndyBig]

It seems to be clear where in the decompiled sources the image/video size is set -- the trick is to search for hex representation of the numbers, that is, 0x320 and 0x500, and change them to 0x258 and 0x400, and likewise for the 1920x1080 video recording. However, it's impossible to test it until we find a way to run the recompiled app as a system app with all the permissions required to use system api.

Well it's easy to find. Encoder parameters are configured in the file smali\com\rigol\webcontrol\VideoEncoder\VideoEncoderManager.smali in the setUpByJson function. It parses the JSON received from the web page with the encoder parameters - image size and quality. The size is compared with three options - 1080, 720 and 480 (vertical). If one of these options is sent in the parameter, then the corresponding size is set, otherwise the default size is set to 1280x800. And since the value of this parameter is sent as zero (from the script on the assets\control.html page), the encoder is set to the default size. So you just need to change these default values in the screenshot.

[shapirus]

That's exactly what I did. That part is easy. The difficult part is to run this apk with the system user permissions.

[AndyBig]

The difficult part is to run this apk with the system user permissions.

Yes, I don’t have any ideas on this either.

[AceyTech]

So I made the scope unbootable when trying to make this damn app run under "system" user. I hate android for not letting me have full control over the device I own.

Anyway, is there any way to enter some recovery mode to mount a partition and change files? There's no network connection at this stage, and adb over USB isn't working either. In fact, there's no activity whatsoever when I connect the scope via the USB port on the rear to my computer, the computer doesn't see any new connected USB device at all.

I'm now going to take out the SD card and mount the partition manually in a card reader, but it'd be nice to be able to do this without taking the scope apart.

You could connect a USB -> Serial to the internal console pins and then drop to a shell then get root via SU.   That'll let you do quite a bit of stuff.
I know that doesn't help with having to open your case., sorry.

[shapirus]

You could connect a USB -> Serial to the internal console pins and then drop to a shell via SU.  That'll let you do quite a bit of stuff., YMMV.
I know that doesn't help with having to open your case., sorry.

Yeah, and once I open the case, it's much easier (for me) to access the SD card directly.

[AceyTech]

I know that doesn't help with having to open your case., sorry.

Yeah, and once I open the case, it's much easier (for me) to access the SD card directly.

Yeah, I hear ya.  I got so tired of opening my case, I use kapton tape and one screw to hold my DHO closed now.   I might expand my SD card slot 'fin hack' for access to those console pins..

[shapirus]

ok I've given up for now.

Of course I had not, whom was I trying to fool?

I knew it was possible.

I managed to disable the signature verification subsystem altogether.

Now we can run anything signed with an arbitrary key with system privileges.

1. Pull /system/framework to a computer
2. Deodex the /system/framework/services.jar component (I used https://github.com/jareddantis/simple-deodexer, as it's simple indeed, and I didn't want to install any full blown IDE: it deodexed everything, but we only need services.jar)
3. Decompile the deodexed services.jar using e.g. apktool
4. Modify the methods responsible for signature verification in smali/com/android/server/pm/PackageManagerService.smali, basically we need to make the methods compareSignatures, compareSignaturesCompat, and compareSignaturesRecover unconditionally return zero, credits to https://xdaforums.com/t/guide-superusermod-disable-signature-verification-nougat-mm.3549952/, the new code to put there can be found there as well.
5. Recompile services.jar using apktool.
6. Replace the original /system/framework/services.jar with the patched version, remove /system/framework/oat/arm64/services.odex, and, just in case, remove the respective cache file in /data/dalvik-cache/arm64
7. Reboot (I actually had to power cycle the scope)
8. Ready to install and use self-signed apps. For webcontrol I had to not only pm uninstall it (with both "--user 0" and without it), but also remove it from /system/app/Webcontrol.

Needless to say, keep a backup of the sd card image handy and know how to restore (by mounting the respective fs and restoring individual files -- usually there's no need to restore the whole image) when things go wrong.

Now, my webcontrol streams a 1024x600 picture, as it should. Picture quality is better than the original 1280x800, but it's still lossy: I believe it uses jpeg/mpeg or some other lossy compression algorithm. I will try (and encourage others to try) to find where it may be configured to have a proper lossless picture. Stream rate is currently below 2 Mbit/s, so there's plenty of headroom not to require any compression at all.

Attached (as zip, to avoid the forum's image format conversion) is an example of the webcontrol stream. You can clearly see the compression artifacts.

p.s. we may not need the stock webcontrol app at all. I haven't searched yet, but there must be better android apps for screen sharing which we could potentially install.

[Mechatrommer]

Yeah, I hear ya.  I got so tired of opening my case I use kapton tape and one screw now.

so dont close it.. screw in some pcb spacers on 2 bottom enclosure's screws, those will make as a good stand...

[AndyBig]

I managed to disable the signature verification subsystem altogether.

Now we can run anything signed with an arbitrary key with system privileges.

1. Pull /system/framework to a computer
2. Deodex the /system/framework/services.jar component (I used https://github.com/jareddantis/simple-deodexer, as it's simple indeed, and I didn't want to install any full blown IDE: it deodexed everything, but we only need services.jar)
3. Decompile the deodexed services.jar using e.g. apktool
4. Modify the methods responsible for signature verification in smali/com/android/server/pm/PackageManagerService.smali, basically we need to make the methods compareSignatures, compareSignaturesCompat, and compareSignaturesRecover unconditionally return zero, credits to https://xdaforums.com/t/guide-superusermod-disable-signature-verification-nougat-mm.3549952/, the new code to put there can be found there as well.
5. Recompile services.jar using apktool.
6. Replace the original /system/framework/services.jar with the patched version, remove /system/framework/oat/arm64/services.odex, and, just in case, remove the respective cache file in /data/dalvik-cache/arm64
7. Reboot (I actually had to power cycle the scope)
8. Ready to install and use self-signed apps. For webcontrol I had to not only pm uninstall it (with both "--user 0" and without it), but also remove it from /system/app/Webcontrol.

Wow that's cool! We should also think about automating this process with a script

Now, my webcontrol streams a 1024x600 picture, as it should. Picture quality is better than the original 1280x800, but it's still lossy: I believe it uses jpeg/mpeg or some other lossy compression algorithm. I will try (and encourage others to try) to find where it may be configured to have a proper lossless picture. Stream rate is currently below 2 Mbit/s, so there's plenty of headroom not to require any compression at all.

No, the video is encoded in H.264/AVC format. You can try giving it a higher stream rate.

p.s. we may not need the stock webcontrol app at all. I haven't searched yet, but there must be better android apps for screen sharing which we could potentially install.

I tried the scrcpy recommended everywhere, but it slows down when the picture starts to change frequently across most of the screen - for example, when a signal with a large amplitude jumps without synchronization.

[Fungus]

I hate android for not letting me have full control over the device I own.

The Android system is designed to prevent rootkits and other forms of subversion. 

[shapirus]

The Android system is designed to prevent rootkits and other forms of subversion. 

I prefer that the OS only provides the means, but lets me decide what to prevent. Never ever should software authors impose their thinking on the user or think that they know better what's good for the user.

[AndyBig]

I killed the system on my oscilloscope by replacing the /system/framework/services.jar file with a modified one Now the system is in an endless reboot loop.
shapirus and the modified system.jar does not need to be signed? Or is it still necessary?

[shapirus]

I killed the system on my oscilloscope by replacing the /system/framework/services.jar file with a modified one Now the system is in an endless reboot loop.
shapirus and the modified system.jar does not need to be signed? Or is it still necessary?

No it doesn't. It worked just fine for me. Probably your decompilation/patching/rebuilding steps weren't quite right, or the tools you used.

Here's my version (patched), you can decompile and run diff to compare against yours, or try to use it, as it must be portable: all scopes are the same (within the same fw version). Don't forget that the respective odex file has to be removed.

md5sum: 84b5e4323b782f43c347d5d842f00a31
sha256sum: 12853ad6308327e6273d7c77bd5751f3bad15413a28c5c670a6714044a4703ce

[AndyBig]

No it doesn't. It worked just fine for me. Probably your decompilation/patching/rebuilding steps weren't quite right, or the tools you used.

Here's my version (patched), you can decompile and run diff to compare against yours, or try to use it, as it must be portable: all scopes are the same (within the same fw version). Don't forget that the respective odex file has to be removed.

md5sum: 84b5e4323b782f43c347d5d842f00a31
sha256sum: 12853ad6308327e6273d7c77bd5751f3bad15413a28c5c670a6714044a4703ce

Understood. Thanks for the file, I'll try it later when I get some sleep
And I’ll try to understand what went wrong with my modification. Maybe some tool really didn’t work like that - deodex or apktool.

[shapirus]

An interesting thing is that control.html accepts query parameters "size" and "rate", which can take the values of "1080p" or "720p", and "Extra", "High", or "Low", respectively, and they do get passed to the respective websocket server that does the actual streaming when the websocket session starts, and there is some logic in the server code to switch size and bit rate accordingly (below the lines where the default size constants are set), but for some reason it does not work at all -- it always sets the values to default. Maybe I will try to untangle the spaghetti of conditions and gotos in the smali code to see why, but before that I'll try to change the default bitrate to different values to see if that works at all.

The above was referring to web control, which shares the scope screen interactively.

As far as the screen recording goes, I think we already have the highest bitrate it can do. The encoder itself supports bitrate values up to 40000000 (10000000 was another value that I saw somewhere), but if I change the default value of 6000000 to a higher one, it doesn't result in the increase of the output file size or the video quality. If I make it lower, however (say 500000), then yes the quality drops, so we know that this parameter isn't ignored.