Magisk
Magisk copied to clipboard
topjohnwu
Don't increase serial counter in prop_info after resetprop
Device: All Android version: All Magisk version name: 65207f96 Magisk version code: 26404
A serial counter indicating prop changes gets increased with resetprop:
clean boot: ro.setupwizard.enterprise_mode 00 00 00 00 resetprop to 1: ro.setupwizard.enterprise_mode 01 00 02 00 resetprop to 0 again: ro.setupwizard.enterprise_mode 00 00 04 00
Any way to have resetprop not increase the serial counter during modification? Or have it reset the serial counter to 00 00 after changes?
This seems like it would be in keeping with the general goal of resetprop, since ro props would never be changed in a normal system, so keeping the counter at zero could prevent some potential undefined behavior on the device. 🤞
I doubt if @topjohnwu will implement this because Magisk has promised not to deal with any hiding issues.
But anyway, our hiding module has fixed this issue.
I doubt if @topjohnwu will implement this because Magisk has promised not to deal with any hiding issues.
But anyway, our hiding module has fixed this issue.
Hello! @yujincheng08, is it possible to contact you, please?
I doubt if @topjohnwu will implement this because Magisk has promised not to deal with any hiding issues.
But anyway, our hiding module has fixed this issue.
That's great news with Shamiko and the props it covers, but any chance of it allowing commandline access to a way to resetprop without increasing the serial counter?
One could also argue that it's not a "hiding" issue per se, it'd just be resetprop functioning closer to its intended purpose? 🙂
Hide some traces introduced by other modules (e.g. PlayIntegrityFix)
Yes, shamiko clean up traces of resetprop used by other modules and users themselves
One could also argue that it's not a "hiding" issue per se, it'd just be resetprop functioning closer to its intended purpose? 🙂
No, as you described in this issue, this is a hide feature. So I think topjohnwu probably wouldn't allow it.
No, as you described in this issue, this is a hide feature. So I think topjohnwu probably wouldn't allow it.
I understand that, but resetprop in itself would also be considered a hide feature (though for research purposes), no?
No, as you described in this issue, this is a hide feature. So I think topjohnwu probably wouldn't allow it.
I understand that, but resetprop in itself would also be considered a hide feature, no?
To be fair, the original intent of resetprop wasn't really related to hiding anything; it was just a simple way to re-set read-only props. Since this issue is essentially a problem with that base functionality, I don't see why @topjohnwu wouldn't consider making the adjustment so that all of the properties related to using resetprop are consistent for the running system.
New Badass Tool - resetprop To be honest, this tool itself deserves a new thread on XDA, as it is super powerful and super cool. "resetprop", originally named "xsetprop", was initially developed by @nkk71 to bypass the crazy tough detections for Safety Net. Developers found method to bypass the check by modifying the kernel source code, which served the need but the solution is far from perfect as it requires the source code to be available and kernel compiling. The tool was originally made to directly modify the system prop database. With seeing the potential of this tool, I contacted @nkk71 and start collaborating together, which brings the original simple tool into a full-fledged, all-in-one prop management tool.
https://xdaforums.com/t/3473445/post-69621730
to bypass the crazy tough detections for Safety Net
R.I.P. resetprop
New Badass Tool - resetprop To be honest, this tool itself deserves a new thread on XDA, as it is super powerful and super cool. "resetprop", originally named "xsetprop", was initially developed by @nkk71 to bypass the crazy tough detections for Safety Net. Developers found method to bypass the check by modifying the kernel source code, which served the need but the solution is far from perfect as it requires the source code to be available and kernel compiling. The tool was originally made to directly modify the system prop database. With seeing the potential of this tool, I contacted @nkk71 and start collaborating together, which brings the original simple tool into a full-fledged, all-in-one prop management tool.
https://xdaforums.com/t/3473445/post-69621730
to bypass the crazy tough detections for Safety Net
R.I.P. resetprop
Seeing as though I'm the actual reason resetprop exists, I would know what its original intended purpose/usage was 😉 (I'm going to assume you didn't know that).
Nice trip down memory lane, though. nkk71 and I actually came up with the idea together and he implemented it with much testing along with me. I really miss that guy 😢.
I'm also the guy that pushed John to get Magisk implemented in the first place, initially based on the su.img from Chainfire's SuperSU. I was doing a rough version of it to get system modifications done without modifying system, and then John created the whole framework and it took off.
So perhaps for sentimental reasons @topjohnwu would be willing to patch this "flaw" in resetprop, even if our current usage differs slightly from the original?
P.S. The three of us actually used to have a group Google Chat where we talked about all this stuff. I remember those days...
P.P.S. @nkk71 was a guy that didn't even really like the attention; he was happy just doing stuff in the background, but when he did something, he was thorough. I actually remember the day he came up with the name resetprop (I think we were chatting on IRC), because he always complained that he wasn't good at naming stuff (John did too, but the name "Magisk" seems to have worked out), but "resetprop" is just the perfect name because it both means re-setprop and reset-prop. Brilliant stuff.
Just for the record, here's the post where @nkk71 actually explains the initial reason for xsetprop (the original name of resetprop): Post in thread '[2016.10.10] suhide v0.55 [CLOSED]'
It was actually originally for MultiROM(!!!), lol. Now there's a real blast from the past...
Glad to see the fixes are being implemented in the forks, and hopefully some pull requests will end up back here when all of the little bugs are worked out. Thanks everyone for the collaboration and making the Android/rooting community what it is today!
Fixed for next Canary by https://github.com/topjohnwu/system_properties/pull/3 and https://github.com/topjohnwu/Magisk/commit/33b7b8b297291b26e3b4928355bd17b458361d25
Thanks to @canyie, @yujincheng08 and @aviraxp! 🙂
https://github.com/chiteroman/android_bionic/commit/9782bbf3a9576ef391ddf755710afa1b9fb2a7cc
👌😁😎
