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:
![]()
[Kernel][08.06.2022][Android 12.1.0]Kirisakura 3.0.1 for Pixel 6/Pro aka "RAVIOLE"
Kirisakura-Kernel for the Pixel 6/Pro Hello everyone, To keep it short: Here is Kirisakura - Kernel for the Google Pixel 6 Pro aka Raven and the Pixel 6 aka Oriole, together Raviole. I would appreciate if everybody that flashes the kernel...forum.xda-developers.com
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 responseCode: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.The issue is Magisk 24303+ no longer stripsNow to my question, if I am on June update, magisk 25 beta installed and rooted, should the 3.0.1 kernel install with FKM successfully even though I still have Verity and verification enabled?
avb
from fstab
, so when the phone boots, first stage mount looks at the fstab
entry for vendor_dlkm
, which references vbmeta
, so it looks at the hashtree descriptor for vendor_dlkm
in vbmeta
and tries to setup a verity device using those values, but vendor_dlkm
for the kernel is different from stock, so those values are incorrect, mounting fails, and the device bootloops.avb
in the fstab
entry and mounts the partition directly.vbmeta
, then AK3 will run Hashtree Patcher on your vbmeta
and vendor_dlkm
partitions, updating the hashtree descriptor in vbmeta
and appending the hashtree and FEC data to the vendor_dlkm
partition.