[Question] Is patching possible?

[heckarman]

So, I daily drive GrapheneOS with unlocked bootloader and rooted with Magisk.
Is it possible to patch the OTA without actually changing the avb_custom_key? I would want to use the key given by GrapheneOS given that wiping data and stuff is a huge pain (at least, in my case) if I signed the OTA with my own custom key.

Or is it possible that I patch the OTA with my own key (of course, I'm not willing to lock the bootloader as it wipes the data and it takes me a day to set it up) to install KernelSU properly, and receive OTA from Official GrapheneOS in future?

Or am I missing anything here? I'm aware that this repo i.e., avbroot is not a small project but rather gigantic learning library on its own. So asking.

Thanks in advance.

[heckarman]

Or if I somehow manage to lock the bootloader with my custom key with kernelSU (given that it is better than Magisk in terms of security and the likes), can I patch the ota automatically with GitHub CI (I believe it is possible and easier to implement) such that every OTA generated is published as a release and the system updater fetches the new release from the release section rather than checking from official grapheneOS (This might require core level change, so I might go with Custota and point it to github release if that's supported similar to how obtanium work)?

[heckarman]

I might be thinking a bit too much, but yeah. If what I said above works, at least to some extent, I can create a single workflow file that patches the ota by taking in 3+ params for adding root which by default takes in KernelSU or Magisk depending on the scenario.

[chenxiaolong]

So, I daily drive GrapheneOS with unlocked bootloader and rooted with Magisk.
Is it possible to patch the OTA without actually changing the avb_custom_key? I would want to use the key given by GrapheneOS given that wiping data and stuff is a huge pain (at least, in my case) if I signed the OTA with my own custom key.

I might not be fully understanding what you're asking here. Given that your bootloader is currently unlocked, all verification is disabled (and avb_custom_key is ignored). There wouldn't really be a point in adding avbroot to the mix with this setup, but it definitely would boot just fine.

Or is it possible that I patch the OTA with my own key (of course, I'm not willing to lock the bootloader as it wipes the data and it takes me a day to set it up) to install KernelSU properly, and receive OTA from Official GrapheneOS in future?

As soon as you make any modifications, like flashing a KernelSU boot image, you can't use the official OTAs anymore. The incremental OTAs will likely fail to install and the full OTAs from GrapheneOS' website would overwrite the kernel with what GrapheneOS ships.

Or if I somehow manage to lock the bootloader with my custom key with kernelSU (given that it is better than Magisk in terms of security and the likes), can I patch the ota automatically with GitHub CI (I believe it is possible and easier to implement) such that every OTA generated is published as a release and the system updater fetches the new release from the release section rather than checking from official grapheneOS (This might require core level change, so I might go with Custota and point it to github release if that's supported similar to how obtanium work)?

Yep, this would likely work quite well. I'm not sure if Github releases can store files as large as a GrapheneOS OTA, but the Actions workflow could always upload the result to some other server.

I'm biased since I wrote Custota, but I'd definitely recommend it if you want automatic updates from a custom OTA server. GrapheneOS' builtin updater hardcodes the URL and TLS certificate for certificate pinning. If you want to use the builtin updater, you'd have to modify the source code, build a new apk, and then use a Magisk/KernelSU module to override the original apk.

[heckarman]

I might not be fully understanding what you're asking here. Given that your bootloader is currently unlocked, all verification is disabled (and avb_custom_key is ignored). There wouldn't really be a point in adding avbroot to the mix with this setup, but it definitely would boot just fine.

Yea, I had plans to lock bootloader after gaining root. But I'm still not sure whether I'll be able to install modules after locking the bootloader and all.

I also wanted to know if its possible to patch GrapheneOS kernel with kernelSU because I've no idea how.

As soon as you make any modifications, like flashing a KernelSU boot image, you can't use the official OTAs anymore. The incremental OTAs will likely fail to install and the full OTAs from GrapheneOS' website would overwrite the kernel with what GrapheneOS ships.

Yep, this would likely work quite well. I'm not sure if Github releases can store files as large as a GrapheneOS OTA, but the Actions workflow could always upload the result to some other server.

I'm biased since I wrote Custota, but I'd definitely recommend it if you want automatic updates from a custom OTA server. GrapheneOS' builtin updater hardcodes the URL and TLS certificate for certificate pinning. If you want to use the builtin updater, you'd have to modify the source code, build a new apk, and then use a Magisk/KernelSU module to override the original apk.

Looking at this, I feel like, I can actually implement this through a workflow. Disable the system updater and install Custota (although I don't like its name, lol) and set the server to github releases that looks for new releases often.

[chenxiaolong]

Yea, I had plans to lock bootloader after gaining root. But I'm still not sure whether I'll be able to install modules after locking the bootloader and all.

Yep, Magisk/KernelSU modules have no signature verification or any other type of checking. They'll install just fine in a locked bootloader setup.

I also wanted to know if its possible to patch GrapheneOS kernel with kernelSU because I've no idea how.

I think it's most likely possible. I'm not aware of any GrapheneOS-specific changes that would break it. That said, this isn't something I've personally tried either.

although I don't like its name, lol

😂 I suck at naming things. It's a portmanteau of "custom OTA".

[heckarman]

Yep, Magisk/KernelSU modules have no signature verification or any other type of checking. They'll install just fine in a locked bootloader setup

I'm afraid regarding installing modules day PI fix and etc that might end up device being bricked. Again, I haven't tried avbroot given the fact that backing up and restoring data is a huge pain for me.

I think it's most likely possible. I'm not aware of any GrapheneOS-specific changes that would break it. That said, this isn't something I've personally tried either

After Magisk devs openly said straight onto the face that they don't want to support GrapheneOS, I wanted to try KetnelSU bit couldn't find any documentation or any info on how I can patch an existing kernel in a way similar to patching boot img for Magisk to install kernelSU rather then replacing existing kernel with the ones provided by KernelSU as or results in device being bricked.

I'll try to spend this weekend patching boot IMG with avbroot to install kernelSU.

I would want to name it is System Updater if I use it in the near future 😅

[chenxiaolong]

I'm afraid regarding installing modules day PI fix and etc that might end up device being bricked.

https://kernelsu.org/guide/rescue-from-bootloop.html#rescue-by-pressing-volume-down would probably help if a module were to cause issues. I believe Magisk has the exact same feature too.

how I can patch an existing kernel in a way similar to patching boot img

This would be incredibly difficult (if it's even possible at all). If the prebuilt kernels they provide aren't compatible, then compiling the GrapheneOS kernel from source with KernelSU integrated is probably the only way to do it.

[heckarman]

If the prebuilt kernels they provide aren't compatible, then compiling the GrapheneOS kernel from source with KernelSU integrated is probably the only way to do it.

I mean, I really have no idea on compiling a kernel from source. Probably I should look for some YouTube tutorials or any documentation's for that. I immorally thought of patching the kernel right away since the prebuilt kernel given by KernelSU is not compatible with GrapheneOS that causes bootloop

[probablypablito]

Just tried this today (GrapheneOS with avbroot + KernelSU). It seems that KernelSU doesn't work on GrapheneOS, at least with the default kernel. I went through the process twice, once patching boot.img manually using ksud and another patching using the KernelSU app on the phone directly. Neither worked. I'll look into compiling the kernel (and I'll publish it if I manage to automate it), but it definitely seems like a learning experience 🥲

[chenxiaolong]

Yep, KernelSU's kernel module method will never work on GrapheneOS because GrapheneOS requires all kernel modules to be signed: GrapheneOS/kernel_common-6.1@7995bde. To make the kernel trust your own signing key, you have to compile the kernel yourself. At that point, it makes the most sense to just apply KernelSU's patches and avoid using a module.