-
Nice.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.
So with these edits, you installed a self-signed Sparrow APK with shared_user of System in the manifest (with no other edits in the APK) and it installs and runs as "system" ?
Can you share a "ps |grep scope" -
Nice.
Nah I didn't touch Sparrow yet. I only modified Webcontrol, but otherwise yes, everything's exactly as you wrote.
So with these edits, you installed a self-signed Sparrow APK with shared_user of System in the manifest (with no other edits in the APK) and it installs and runs as "system" ?
Can you share a "ps |grep scope"Code: [Select]rk3399_rigol:/ # ps|grep webcontrol
system 1254 233 1626840 84304 SyS_epoll_ 7649856b84 S com.rigol.webcontrol
rk3399_rigol:/ # ps -n|grep webcontrol
1000 1254 233 1626840 84304 SyS_epoll_ 7649856b84 S com.rigol.webcontrol
There should be no difference with Sparrow or any other app.
Regarding the security implications, yes, of course, you wouldn't want to disable signature verification on an arbitrary android device. In this case, however, provided that the scope isn't reachable from public network, and the local network (as well as anyone who can have physical access to it) is trusted, it's a "who cares?" situation. -
So it seems that hitting the Default button twice reverts the scope to an 814. So basically the hack is not permanent. Anyone else found this?
No matter how much I pressed the "Default" button, my 814, converted to 914, remained 914
Which permission(s) did you add to the Template?
I don’t remember exactly now. It seems that I left the same ones that were in your script, but I also duplicated them for the webcontrol application, changing the script accordingly.So with these edits, you installed a self-signed Sparrow APK with shared_user of System in the manifest (with no other edits in the APK) and it installs and runs as "system" ?
Yes, that's right. After hacking using the method discovered by Shapirus, self-signed applications with shared_user of System in the manifest are normally installed and launched under UID 1000. Modified applications like Sparrow and Webcontrol work for me this way.
Can you share a "ps |grep scope" -
Adding the 924'S' version showed the function generator up, but when I went into it, there menu was there, but no waveform, so I'm going to assume the function generator is hardware based. To cut a long story short, it (temporarily) bricked my scope (no waveform, menu in the bottom left was not responding, etc.).
function generator and logic analyzer button down there are hardware based. maybe you want to read through dho800/900 teardown thread and this hack thread to get the whole idea... and maybe you also would like to follow my threads about development of the 2 "replica" hardwares... ymmv.
https://www.eevblog.com/forum/testgear/rigol-dho804-bode-plot
https://www.eevblog.com/forum/testgear/low-cost-compatible-rigol-pla2216-logic-probe-for-dho900-(and-hacked-dho800)
and a bit of advice. if possible dont mess with interfaces randomly, the situation will be "undefined" (i would not dare) and unlikely have anything to do with any of the dho800/900 hack discussions, it will be on your own adventure
cheers.
-
I remember someone decompiling libscope-auklet.so into what looked like C code -- any hint what was the software that could do that? I tried objump from linux binutils (binutils-aarch64-linux-gnu), but it produces raw assembler code which is on a harder side to understand, and besides it crashes halfway through. Need something else.
-
I remember someone decompiling libscope-auklet.so into what looked like C code -- any hint what was the software that could do that? I tried objump from linux binutils (binutils-aarch64-linux-gnu), but it produces raw assembler code which is on a harder side to understand, and besides it crashes halfway through. Need something else.
IDA, Ghidra. -
I remember someone decompiling libscope-auklet.so into what looked like C code -- any hint what was the software that could do that? I tried objump from linux binutils (binutils-aarch64-linux-gnu), but it produces raw assembler code which is on a harder side to understand, and besides it crashes halfway through. Need something else.
IDA, Ghidra.
Both will generate what I'd call "pseudo" C code for the purposes of easier analysis than assembler. Don't expect to be able to edit and recompile the complete app from it, though. -
It's C++, not C.
-
It's interesting. I tried to search where the preset probe ratio multipliers could be defined and couldn't find them neither in Sparrow.apk, nor in libscope-auklet.so. I thought it would have been an array of values, but no, at least, nothing matching the numbers I searched for.
Has anyone found them yet?
It's so lame that it doesn't allow to simply enter an arbitrary multiplier.
update: LOL, as usual, I found it *literally* 1 minute after I posted this. It's in sparrow.apk. Will try to add the multiplier I needed tomorrow. It appears to be in smali_classes2/com/rigol/scope/cil/ServiceEnum$ProbeX.smali, and they define floating point numbers as strings, unless it's decorative and the actual numbers are defined elsewhere. -
I decided to write here about how much money it cost me to upgrade the DHO814 model to DHO924...(full hardware compliance)... All components were purchased on aliexpress.... The amount is indicated along with the cost of delivery to the Czech Republic...The memory chips installed were all three identical K4B4G1646E
3× K4B4G1646E-BMA - 10€
2× TP1282 - 6€
1× MPM3630 - 2€
1× DC3 IDC JTAG-50Pin - 0.29€
Total Cost. 18.29€😉😉😉😉
-
The memory chips installed were all three identical K4B4G1646E
But have we ever found an answer to the question of what those extra memory chips were needed for? -
and they define floating point numbers as strings, unless it's decorative and the actual numbers are defined elsewhere.
These value strings are simply strings to display in the select list. For real configuration, completely different values are passed to the libscope-auklet.so library. I can’t say for sure right now, but it seems there are something like enum values, which are passed to the library API when the divisor changes. -
I must be blind. All working now, just running a calibration, but seems I now have a DHO924S masquerading as a 804.
Thanks for sharing, this is a very interesting observation! I can confirm the presence of freezes several months ago (I no longer remember the firmware version). Just like you, I modified my vendor.bin to 924S. As far as I can remember now, pressing the “defolt” button helped me get out of the “stupor”... This all happened with AWG turned on. Unfortunately, I cannot confirm or deny the change in the model name to “814”; this was a very long time ago.... Since then, I have made many additions to my scope (see my post above), including moving the configuration resistor, to change HW....I tried to force the hang now and it didn't work! The question that interested me is whether this behavior is caused by the lack of missing components on the board (possibly ddr chips), or is it due to something else?..... mmmmm, this interested me extremely..... Thank you for sharing your experience!!!
Thank you, and a huge thanks to everyone who helped me to get this working
***** ADDENDUM *****
Something interesting just happened. Adding the 924'S' version showed the function generator up, but when I went into it, there menu was there, but no waveform, so I'm going to assume the function generator is hardware based. To cut a long story short, it (temporarily) bricked my scope (no waveform, menu in the bottom left was not responding, etc.). I double pressed the default button on the front of the scope and it came back to life, but my 804, that was transformed to a 924S was now masquerading as a 814. So it seems that hitting the Default button twice reverts the scope to an 814. So basically the hack is not permanent. Anyone else found this?
-
and why i didnt hang my scope by activating, running, playing, bode plotting with AFG? (before and after resistor config hack, DDR3L always missing until today) afaik there is no feedback signal on my replica AFG board to tell the scope or FW that the board presents or not.
-
and why i didnt hang my scope by activating, running, playing, bode plotting with AFG? (before and after resistor config hack, DDR3L always missing until today) afaik there is no feedback signal on my replica AFG board to tell the scope or FW that the board presents or not.
The question that interested me is whether this behavior is caused by the lack of missing components on the board (possibly ddr chips), or is it due to something else?..... mmmmm, this interested me extremely..... Thank you for sharing your experience!!!
I wonder if this is where the system is looking for the hardware AFG...(From @s2084's modified HW8)
Does anyone have the console log output from a real 924S?
Reason I ask:HW12
HW8 -Mod
-
Any idea how/where the pull-down menu (the one that's opened with win-N using a keyboard) is disabled? Is it somewhere in the system or is it in com.rigol.scope? I wonder if it's possible to reenable it.
-
No, this is definitely not in com.rigol.scope, because even if you disable autorun of com.rigol.scope, this top curtain still does not open by swiping from the launcher.
-
No, this is definitely not in com.rigol.scope, because even if you disable autorun of com.rigol.scope, this top curtain still does not open by swiping from the launcher.
Might (or not) be in com.rigol.launcher, as it has this in its AndroidManifest.xml:Code: [Select]<uses-permission android:name="android.permission.DISABLE_STATUS_BAR"/>
But I've not been able to find any code that uses this permission so far. -
Might (or not) be in com.rigol.launcher, as it has this in its AndroidManifest.xml:
And it doesn’t work with the launcher autorun disabled either
-
I wonder if this is where the system is looking for the hardware AFG...(From @s2084's modified HW8)
i managed to get an "older" version of IDA and disassemble afg_gpio.ko... looks like another can of worm of 5 bits config resistor? but am struggling to learn ARM ASM code here... not sure whats those "0x7A" to "0x7E" representing... i need to sleep now, hopefully will continue this afternoon
(Attachment Link)
Does anyone have the console log output from a real 924S?
Reason I ask:
(Attachment Link) HW12 (Attachment Link) HW8 -Mod
...
-
I wonder if this is where the system is looking for the hardware AFG...(From @s2084's modified HW8)
(Attachment Link)
Does anyone have the console log output from a real 924S?
Reason I ask:
(Attachment Link) HW12 (Attachment Link) HW8 -Mod
i managed to get an "older" version of IDA and disassemble afg_gpio.ko... looks like another can of worm of 5 bits config resistor? but am struggling to learn ARM ASM code here... not sure whats those "0x7A" to "0x7E" representing... i need to sleep now, hopefully will continue this afternoon...
The following is the logical pseudocode for a few key functions:
int gpio_afg_init()
{
set GPIO_122 Label is afg__in1
set GPIO_122 Output Low
set GPIO_123 Label is afg__in2
set GPIO_123 Output Low
set GPIO_124 Label is afg__in3
set GPIO_124 Output Low
set GPIO_125 Label is afg__in4
set GPIO_125 Output Low
set GPIO_126 Label is afg__in5
set GPIO_126 Output Low
}
ssize_t gpio_afg_drv_write(file *file, const int8 *buf, size_t len, loff_t *f_pos)
{
1.copy user data to core.
_arch_copy_from_user(*DB,*buf ,len);
2.write GPIO value.
write GPIO_122(afg__in1) is DB[0] bit value.
write GPIO_123(afg__in2) is DB[1] bit value.
write GPIO_124(afg__in3) is DB[2] bit value.
write GPIO_125(afg__in4) is DB[3] bit value.
write GPIO_126(afg__in5) is DB[4] bit value.
}
ssize_t gpio_afg_drv_read(file *file, int8 *buf, size_t len, loff_t *f_pos)
{
1.read DB from GPIO value.
read DB[0] from GPIO_122(afg__in1) bit value.
read DB[1] from GPIO_123(afg__in2) bit value.
read DB[2] from GPIO_124(afg__in3) bit value.
read DB[3] from GPIO_125(afg__in4) bit value.
read DB[4] from GPIO_126(afg__in5) bit value.
2. copy core DB to user.
_arch_copy_to_user(buf, DB,len);
}
The following is the logical pseudocode for a few key functions.
It is still unclear how the RK3399 GPIO_122~GPIO_126 corresponds to the pins of the AD9744 DAC, and you need to explore. Good luck!
-
The following is the logical pseudocode for a few key functions.
It is still unclear how the RK3399 GPIO_122~GPIO_126 corresponds to the pins of the AD9744 DAC, and you need to explore. Good luck!
I'm pretty sure that the AFG board gets the 14 bit DAC data from the FPGA.
My Hypothesis: The GPIO's you identified might be to/from AFG board. (to set gain, offsets, etc..?) -
The following is the logical pseudocode for a few key functions.
It is still unclear how the RK3399 GPIO_122~GPIO_126 corresponds to the pins of the AD9744 DAC, and you need to explore. Good luck!
I'm pretty sure that the AFG board gets the 14 bit DAC data from the FPGA. The GPIO's you identified might be for setting gain, offsets, etc..?
I imagine that afg_gpio.ko driver just provides module status detection, or other configurations, and the specific 14-bit data is transmitted through the FPGA, since it only has 5-bit data. -
The following is the logical pseudocode for a few key functions:
so the RK3399 pins 122-126 are set as output, and then later stage gpio_afg_drv_read read them as if they are input? hmm confusing...
see attached my attempt rev eng afg pins interface. so far there are only 3 unknown pins UP0, UP1, UP4 (pin 10 on smaller interface and pin 22 and 28 on larger interface) red arrowed in pcb picture and highlighted green on the connector diagram. i didnt bother to check to where they are connected. probably to FPGA, or RK, or to other passive/semi components before going to either one of them. the ultimate reference provided by you still unclear about them, UP0 seems near some inductor, resistors and cap network, not sure what it is, on my UTG962 AWG, there is some kind of protection mechanism to cut off output in case AFG output is exposed to excessive external DC, so i'm guessing UP0 is probably it.
I imagine that afg_gpio.ko driver just provides module status detection, or other configurations, and the specific 14-bit data is transmitted through the FPGA, since it only has 5-bit data.The following is the logical pseudocode for a few key functions.
I'm pretty sure that the AFG board gets the 14 bit DAC data from the FPGA. The GPIO's you identified might be for setting gain, offsets, etc..?
It is still unclear how the RK3399 GPIO_122~GPIO_126 corresponds to the pins of the AD9744 DAC, and you need to explore. Good luck!
My Hypothesis: The GPIO's you identified might be to/from AFG board. (to set gain, offsets, etc..?)
anyway lets assume just for sake of simplicity those 3 are connected directly to RK and being read or written by afg_gpio.ko, there are still 2 GPIOs unknown... so.. fwiw ymmv...
nomenclature:
DB = DAC digital input
CLK = DAC clock
REL = relays control
AFG OFFSet and AMPLitude signal will only present when we install the 2 missing opamps TP1282 (i used OPA2350). later finding.. pin 28 will be low for 4ms each time bode plot feature is started and then goes back high forever until bode plot is restarted again...
-
It's probably more like RK_out <--> AFG_inThe following is the logical pseudocode for a few key functions:
so the RK3399 pins 122-126 are set as output, and then later stage gpio_afg_drv_read read them as if they are input? hmm confusing...
With RK and AFG being their own IC's.
They probably just labled the gpio pins to designate their use, like "these pins goto AFG in"
You can read the state of any gpio state, does not matter of they they are in or out pins, or digital or analog.
If someting reads the pin states (digi), then that's usually to verify what they are because it's possible some parts of the code somewhere could have changed them.