search

chenxiaolong / avbroot

Sign (and root) Android A/B OTAs with custom keys while preserving Android Verified Boot
GNU General Public License v3.0
507 stars 42 forks source link

[Question] What are the limitations? #127

Closed pixincreate closed 4 months ago

pixincreate commented 1 year ago

Quick Intro:

I want to use this on my daily driver Bluejay. Due to lack of time to experiment with stuff, I want to get it right the first / second time itself.
I'm currently using GrapheneOS with bootloader locked.

I prefer applying patches to the Official GrapheneOS over building from scratch and planning to use KernelSU given that it provides better hiding features compared to Magisk.

Questions

I'm still calculating the things since I cannot take holidays to fix my phone if anything goes wrong...

chenxiaolong commented 1 year ago

As long as you keep OEM Unlocking enabled, the worst that could happen is you have to unlock the bootloader and reflash. Unless a module does something dumb and modifies an actual partition (which I've never seen because the whole point of modules is "systemless" modifications), even a factory reset from recovery mode is sufficient to get back to a clean state.

It's very hard to actually permanently brick a device when OEM Unlocking is enabled.

Regarding modules, there isn't really a difference between how they behave with the bootloader locked vs unlocked. If a module causes trouble, you can most likely use KernelSU's safe mode mechanism to remove the bad module: https://kernelsu.org/guide/rescue-from-bootloop.html#brick-by-modules. Magisk also supports a similar feature.

restore backups from apps like Swift

Regarding this specifically, I'd avoid backing up and restoring system apps (anything bundled with the OS). For certain system apps, if you back up the data from a previous OS version and restore in a newer OS version, even if the difference is only a normal monthly security update, certain data migration code will be skipped and may cause crashes. This is true in general--not just with an avbroot setup.

pixincreate commented 1 year ago

Gotcha, this clarified most of the things but still have small questions remaining in my head.

chenxiaolong commented 1 year ago

How are they going to survive OTA updates? I'm aware that you made CustOTA for handling this but that needs me to have my own server that downloads the patched OTA, right? and not that it downloads official GOS update patch it on device before installation.

That's correct. Custota is just an alternative to adb sideload if you want to have your own server with patched OTAs.

As for the modules, there's nothing special you have to do for them to survive OTA updates. They live on the /data partition. All you have to do for updates is flashing your newly patched OTA.

To install KernelSU, what changes have to be done? Yesterday I was talking to some of the bluejay community people and they said that I need to modify the existing kernel and cannot use the generic kernel which felt true since the device went bootloop after trying to flash it.

Do you have more details about what they said?

If they're referring to extracting the boot image, replacing just the kernel part, and then repacking the boot image, then avbroot will automatically do that.

Can this by bypassed by forcing (sideloading) another OTA that has the updated boot image?

Not on Pixel devices anymore. They use the same kernel for both booting into regular Android and recovery mode. If the boot image gets broken, it's no longer possible to boot into recovery for sideloading, so the only option is unlocking the bootloader and using fastboot flash.

OnePlus devices still have a separate recovery partition, so it's possible on those devices.

pixincreate commented 1 year ago

Do you have more details about what they said?

I unlocked the bootloader yesterday just to get KernelSU working on my phone. Kernel version on my phone is 5.10.187 and tried 3 methods to get KernelSU (Used AnyKernel3 5.10.177 since 187 is unavailable and I assumed it should work since in the installation via recovery section of kernel, it was mentioned that different sub-levels mean nothing but same kernel) working on my phone and all of them resulted in device getting into bootloop (I'm unsure whether I'm missing anything or not, still).
I tried getting help in the midnight just to learn that:

Not on Pixel devices anymore. They use the same kernel for both booting into regular Android and recovery mode. If the boot image gets broken, it's no longer possible to boot into recovery for sideloading, so the only option is unlocking the bootloader and using fastboot flash.

That's sad and a pain in the ass to have a backup for safety all the time

chenxiaolong commented 1 year ago

Thanks for the info!

Just rebuilding GOS kernel will break ABI, so GKI build of KernelSU won't boot

Oh, I see. I didn't know that. Yeah, you would definitely need to build the GOS kernel with KernelSU patches yourself then.

Have to deisable vbmeta-verification (I have no idea what it is)

When you build your own kernel/boot image, it will no longer match the boot image checksum in GOS's vbmeta.img. Normally, with an unlocked bootloader, people work around this by completely disable AVB:

fastboot flash --disable-verification vbmeta vbmeta.img
fastboot flash boot boot.img

With avbroot, this is not necessary because it will re-sign boot and vbmeta properly using your own key.

pixincreate commented 1 year ago
chenxiaolong commented 1 year ago

Disabling vbmeta-verification will again wipe the wholedevice, right?

It shouldn't. Only flipping the bootloader state between locked and unlocked will trigger a wipe.

Do you have any idea why some of the core GOS features get vanished (secure spawning and alikes) all of a sudden? When this happens, Security & Privacy tab in settings combines together. (I believe this is off-topic, feel free to ignore)

No worries about off-topic stuff! I've never seen that before. If I had to guess, it might be some sort of communication issue between some system apps. Some of the options shown in Settings come from other preinstalled apps (using a mechanism called "Settings slices").

pixincreate commented 1 year ago

Thanks for shedding some light on this. Factory resetting the device actually brought back the GOS specific changes. Can the changes be reverted without resetting? I guess yes, which I need to figure it out.

pixincreate commented 8 months ago

Another question, is root working properly with Zygisk for folks who are using avbroot?

pascallj commented 8 months ago

Another question, is root working properly with Zygisk for folks who are using avbroot?

I'm not using GrapheneOS, but Zygisk is the default and root is working fine in my case. Or am I misunderstanding you?

pixincreate commented 8 months ago

Cool. Magisk works fine on GrapheneOS but not Zygisk. It is completely broken.

cawilliamson commented 4 months ago

@pixincreate Did you ever get this setup working on Graphene?

I'm not opposed to building my own kernel to make this work but just curious how folks are directly applying the patches, re-signing the kernel, etc? :)

pixincreate commented 4 months ago

@pixincreate Did you ever get this setup working on Graphene?

I'm not opposed to building my own kernel to make this work but just curious how folks are directly applying the patches, re-signing the kernel, etc? :)

I'm maintaining my of version of Magisk that has GrapheneOS specific changes made.
Getting KernelSU to work is a pain as I would have to compile the kernel from scratch which is what I do not intend to do given time constraints.

I'm not using avbroot either given my time constraints and maintainence requirements.