Skip to content

Commit

Permalink
README: Issue warning about limited magisk support
Browse files Browse the repository at this point in the history
  • Loading branch information
schnatterer committed Apr 17, 2024
1 parent eb4d2a1 commit da0cd81
Showing 1 changed file with 4 additions and 0 deletions.
4 changes: 4 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,9 +1,13 @@
rooted-graphene
===


GrapheneOS over the air updates (OTAs) patched with Magisk using [avbroot](https://github.com/chenxiaolong/avbroot) allowing for AVB and locked bootloader *and* root access.
Provides its own OTA server for [Custota](https://github.com/chenxiaolong/Custota) magisk module.

> ⚠️ OS and root work in general. However, zygisk does not (and [likely never will](https://github.com/topjohnwu/Magisk/pull/7606)) work, leading to magisk being easily discovered by other apps and lots of banking apps not working.
KernelSU support is work in progress.

This comment has been minimized.

Copy link
@pixincreate

pixincreate May 6, 2024

Can you elaborate this? GrapheneOS enforces signature verification, so supporting KernelSU through LKM is not likely possible. From what I know, the only way is to patch the kernel.

This comment has been minimized.

Copy link
@schnatterer

schnatterer May 6, 2024

Author Owner

I tried patching boot.img with ksud, magiskboot and avbroot --prepatched . This did not cause problems with AVB and booted fine. Unfortunately, no root either. Not sure what went wrong. Any ideas?

Next try would be to patch rooted AnyKernel into boot.img. Will be difficult to determine the closest match of existing kernel version with AnyKernels automatically. Not impossible, though.

You think this could work? Other approaches?

This comment has been minimized.

Copy link
@pixincreate

pixincreate May 7, 2024

From what I know, GrapheneOS modifies Kernel heavily. Using a different kernel results in bootloop (from my previous experience).

Patching the kernel might not work given that signature will(?, not sure) get modified.

One solution that is bound to work is to build the kernel from scratch. That would take a lot of time though.

here are some references related to the topic that you might have missed:

chenxiaolong/avbroot#267
chenxiaolong/avbroot#266
chenxiaolong/avbroot#248

This comment has been minimized.

Copy link
@schnatterer

schnatterer May 7, 2024

Author Owner

Thanks for pointing these out!
So currently your solution is running Magisk and zygisk via your own fork of magisk?

This comment has been minimized.

Copy link
@pixincreate

pixincreate May 7, 2024

That, yes. I'm maintaining a version of Magisk that is always in sync with upstream. But modules like Shamiko will not work as they're known to enforce signature verification.

Patching the kernel might not work given that signature will(?, not sure) get modified.

BTW, do you have any thoughts on this? I assume this is not possible.

This comment has been minimized.

Copy link
@schnatterer

schnatterer May 10, 2024

Author Owner

From reading the resources you mentioned above, I presume that the OTA signatures used in AVB are different to the signatures used in the kernel. So these are not re-signed by avbroot and hence would have to be compiled from scratch. But this is also more of a guess.

Especially the info that parts of kernelSU are closed makes me very suspicious.
The only think I really need root for is backup, for which I use this script.

I'm actually considering to try to re-implement this with shinzuku API and as system app. Dont know if that's possible, but I agree that getting rid of root is a huge plus for security.

As I own the private key anyway I still could go the reccommend way of rooting with graphene, if need be.

This comment has been minimized.

Copy link
@pixincreate

pixincreate May 10, 2024

Yes, kernel has to be compiled from scratch with KernelSU to get SU. I prefer installing Magisk instead given the ease of access and installation as opposed to KernelSU.

Thanks for the script. I presume it only backs up the app and not the data?

I'm actually considering to try to re-implement this with shinzuku API and as system app. Dont know if that's possible, but I agree that getting rid of root is a huge plus for security.

Script?

I actually had plans to develop an app to expose root to apps from adbroot and integrate that to my fork of Shizuku which I gave up due to time constraints. I think I re-think about it, ;)

This comment has been minimized.

Copy link
@schnatterer

schnatterer May 11, 2024

Author Owner

Thanks for the script. I presume it only backs up the app and not the data?

It does back up the data as well, that's the whole point 😄
It does so by accessing the folders of the apps directly. This will probably result in these scripts always needing root.
So, in theory a combination of a userdebug build of graphene (granting adb root) and Shizuku might work. Still, requires a custom build of graphene 😐
As I dont have a lot of time on my hands, I'll likely wait for graphene's own backup tool that might turn up this year.

This comment has been minimized.

Copy link
@pixincreate

pixincreate May 11, 2024

That makes sense. Given time constraints, we cannot always maintain the repo in the long run and it makes to wait Graphene to build their own reliable backup tool.
I also want an automatic call recorder though.

PS: I'm currently relying on SwiftBackup and BCR.


## Usage

## Initial installation of OS
Expand Down

0 comments on commit da0cd81

Please sign in to comment.