Am not developer but yesh
Am not developer but yesh
Try magisk stable with the kernel zip attached to this post:My employer recently made us switch to Microsoft authenticated apps on our mobile devices. After hiding Magisk stable 24300 and denying all the Microsoft apps, I was able to run programs like Outlook and Team without root being detected. I had the initial 2.4 kernel running too.
Today, those app started to detect root and would not run. I dont know what changed to cause root to get detected.
I upgraded to Magisk Canary 24313 and can hide root from those apps again. Unfortunately, I when I tried to flash original Kiri 2.4, the Google logo just appeared and then went out.
Are there any workarounds to get this kernel running with Magisk Canary 24313? Is there a test version of the kernel that might work with Magisk Canary?
thanks,
If I use Magisk stable then root gets detected by the Microsoft apps.Try magisk stable with the kernel zip attached to this post:
If you disabled verity/verification vbmeta flags you will have no trouble using magisk canary. If your vbmeta flags are enabled canary will not work as far as I'm aware.
If you didn't disable the flags while updating each month, they are enabled.If I use Magisk stable then root gets detected by the Microsoft apps.
I have Magisk Canary currently installed and have it hid and deny list is enabled. I need to research how to determine the state of the verity/verification vbmeta flags.
Are you saying that if these flags are disable then I can use Kiri 2.4 with Magisk canary?
Thanks for the clarification. I am running Magisk Canary and can hide root from my corporate overlords. I didnt use an vbmeta flag options when I flashed the Magisk Canary via fastboot.If you didn't disable the flags while updating each month, they are enabled.
Disabling them requires a full wipe.
Yes, canary with this kernel works fine if the flags are disabled.
Magisk changed the way verity is handled during the canaries and that's why things will change. It has nothing to do with the kernel itself.
I upgraded to Magisk Canary 24313 and can hide root from those apps again. Unfortunately, I when I tried to flash original Kiri 2.4, the Google logo just appeared and then went out.
If you disabled verity/verification vbmeta flags you will have no trouble using magisk canary. If your vbmeta flags are enabled canary will not work as far as I'm aware.
avb
key from fstab
entries, so if you don't have verity disabled, when the system tries to mount vendor_dlkm
, it looks for the hashtree described in vbmeta
, but it doesn't exist, and even if it did, it would no longer match the the descriptor.fstab
entries from within the kernel, it seems we'll be forced to either disable verity or patch vendor_dlkm
(though I suppose it could be shipped with the hashtree already appended) and vbmeta
.vbmeta
does not require you to wipe your data.You don't disable the vbmeta flags when flashing a boot.img, but when updating your phone via the factory images for example. Or just issue the command via fastboot for the current firmware you're on.Thanks for the clarification. I am running Magisk Canary and can hide root from my corporate overlords. I didnt use an vbmeta flag options when I flashed the Magisk Canary via fastboot.
I am going to hold off on doing a full wipe. I did a flash-nowipe earlier today to bring my phone back to life after it got borked.
Sad to now be running a stock kernel!
The issue is Magisk no longer strips theavb
key fromfstab
entries, so if you don't have verity disabled, when the system tries to mountvendor_dlkm
, it looks for the hashtree described invbmeta
, but it doesn't exist, and even if it did, it would no longer match the the descriptor.
I posted a workaround on the issue in the Magisk repo, but it currently isn't trivial to apply. Unless there's some way to modify thefstab
entries from within the kernel, it seems we'll be forced to either disable verity or patchvendor_dlkm
(though I suppose it could be shipped with the hashtree already appended) andvbmeta
.
The upside is patching the hashtree descriptor invbmeta
does not require you to wipe your data.
Edit: mis-read due to already being half asleep.Can I use your modified vendor_dlkm and vbmeta images for the May update to flash them to my Pixel 6 Pro?
If I understand thing correctly, this would like me Flash Kiri 2.4 without wiping my phone.
I'm on Pixel 6 (oriole, not Pro), so mine will be different from yours. I'll try to package up my workaround in the next few days to make it a bit easier to apply, assuming I can generate the hashtree on-device.Can I use your modified vendor_dlkm and vbmeta images for the May update to flash them to my Pixel 6 Pro?
If I understand thing correctly, this would like me Flash Kiri 2.4 without wiping my phone.
avbtool
and distilled the modifications to vbmeta
to the bare minimum. It does not patch the authentication block or sign the image. Generating FEC codes is optional. You can find the build in the git repo:vbmeta
from stock and vendor_dlkm
from the kernel. Both will be patched in place.fec
binary here. It's optional, but long term, it's probably advisable.SP2A.220505.002
and Kirisakura 2.4.0, both for oriole, from the alpha02 build:b47cf7b49c4b38374bf45ee3fb6e8fe6531ec42d9a5caf4ce7e63929a7cbc5b5 vendor_dlkm.img
2139e200534f75f2d159aeea6b74e3526a7008a57235a7d934c1bffcf74eb0c9 vbmeta.img
Do I run hashtreepatcher directly on my Pixel 6 Pro or some other way?
adb push hashtreepatcher /data/local/tmp
adb push fec /data/local/tmp
adb push vendor_dlkm.img /data/local/tmp
adb push vbmeta.img /data/local/tmp
adb shell
cd /data/local/tmp
chmod +x hashtreepatcher
chmod +x fec
./hashtreepatcher vendor_dlkm.img vbmeta.img
exit
adb pull /data/local/tmp/vendor_dlkm.img vendor_dlkm-patched.img
adb pull /data/local/tmp/vbmeta.img vbmeta-patched.img
This is super helpful.Code:adb push hashtreepatcher /data/local/tmp adb push fec /data/local/tmp # optional adb push vendor_dlkm.img /data/local/tmp adb push vbmeta.img /data/local/tmp adb shell cd /data/local/tmp chmod +x hashtreepatcher ./hashtreepatcher vendor_dlkm.img vbmeta.img exit adb pull /data/local/tmp/vendor_dlkm.img vendor_dlkm-patched.img adb pull /data/local/tmp/vbmeta.img vbmeta-patched.img
been trying to get this thing to boot for three days, i finally got the device to boot with these instructions but without touchscreen response .Code:adb push hashtreepatcher /data/local/tmp adb push fec /data/local/tmp # optional adb push vendor_dlkm.img /data/local/tmp adb push vbmeta.img /data/local/tmp adb shell cd /data/local/tmp chmod +x hashtreepatcher ./hashtreepatcher vendor_dlkm.img vbmeta.img exit adb pull /data/local/tmp/vendor_dlkm.img vendor_dlkm-patched.img adb pull /data/local/tmp/vbmeta.img vbmeta-patched.img
Once I pull the modified files then do I flash them via Fastboot?
Code:fastboot flash vbmeta vbmeta-patched.img fastboot flash vendor_dlkm vendor_dlkm-patched.img
fastbootd
for vendor_dlkm
:fastboot reboot fastboot
Just confirming that line 2 is this for Pixel 6P
Do I need to rename fec-arm64 to fec?Code:adb push fec-arm64 /data/local/tmp
fec
and it must be in your working directory when you call hashtreepatcher
. You can tell if it worked if the output doesn't have all zeroes for the FEC fields.vendor_dlkm
a second time, be sure to push a fresh copy, as hashtreepatcher
will happy keep appending more and more hashtree footers to the file. I have no idea if that affects anything, but it will at least keep getting needlessly larger.fastbootd
only for vendor_dlkm
.been trying to get this thing to boot for three days, i finally got the device to boot with these instructions but without touchscreen response .
went to unlock the phone, touchscreen is unresponsive. phone isnt frozen, it just doesnt respond to touch.
vendor_dlkm
didn't flash properly. Be sure to install it from fastbootd
(which I see you did), or just update the zip with the patched one and let some kernel manager flash it.no problems on my end using magisk 27001 and 2.2.0 on march stable firmware.So do you believe Magisk will work on the March update on P6 Pro? I got into a bootloop but maybe I made a mistake like using the older boot.img file. Looking for some reason it did not work for me.
Thanks,
Mark