VIVO/iQOO kernel restictions: "Operation not permitted" when executing su or mounting to /system, or bootloops if rooted

[canyie]

Device: iQOO Z1/VIVO X70 PRO/iQOO NEO3, and more
Android version: N/A
Magisk version name: N/A
Magisk version code: N/A, but more serious since 24302

Magisk fails to mount /system on some Vivo/iQOO devices.

01-01 08:17:34.721  root   650   652 E Magisk  : mount tmpfs->/system/bin failed with 1: Operation not permitted
01-01 08:17:34.721  root   650   652 E Magisk  : mount /dev/Qnh/.magisk/mirror/system/bin/AudioSetParam->/system/bin/AudioSetParam failed with 1: Operation not permitted
01-01 08:17:34.721  root   650   652 E Magisk  : mount /dev/Qnh/.magisk/mirror/system/bin/TEST_IServiceManager->/system/bin/TEST_IServiceManager failed with 1: Operation not permitted
01-01 08:17:34.721  root   650   652 E Magisk  : mount /dev/Qnh/.magisk/mirror/system/bin/abb->/system/bin/abb failed with 1: Operation not permitted

According to a bug report from a "Vivo internal staff" who has a device running userdebug build, adb root and manually mount /system works but fails when mounting in Magisk superuser environment. After debugging with him/her/them, we found that the device only allows programs in /system to mount the system partition (move binary that will mount /system to other partitions, and it fails even in adb root environment). I believe that the device has an allowlist and refuses to mount key partitions for programs if their partition is not in the allowlist.

I think the following two solutions may fix it:

1. Reimplement magic mounting logic in rc script language and add it to init.rc.
2. Inject Magisk binaries to /system in magiskinit.

I'm unsure when this problem will be solved, so I opened an issue to track the relevant information.

---

Edit: even successfully mount su to /system/bin/su, executing su will throw an operation not permitted error.

[yujincheng08]

/system/bin/su cannot be executed by other processes so there may be kernel restriction. This issue is hard to fix if no kernel source is available.

[yujincheng08]

Kernel sources of some vivo devices, but unfortunately, there are no ones of relative devices

https://opensource.vivo.com/Project

[canyie]

Update: Kernel source code of iQOO Z1 is currently available!

[jnelson89]

Update: Kernel source code of iQOO Z1 is currently available!

Here are my Device Vivo V5 mt6750 kernel sources which can be helpful for you to fix my problem
https://github.com/Dawn-Blossoms/android_kernel_oppo_mt6750
https://github.com/Power535/android_kernel_common_MT6763

[canyie]

Found something (Chinese) about Vivo's unqine behavior: https://bbs.pediy.com/thread-268165.htm

This points out adding mount to init.rc can work: https://bbs.pediy.com/thread-199415.htm

[jnelson89]

Found something (Chinese) about Vivo's unqine behavior: https://bbs.pediy.com/thread-268165.htm

This points out adding mount to init.rc can work: https://bbs.pediy.com/thread-199415.htm

Can you make a build, to fix this?

[aIecxs]

consider Magisk is systemless-root method (and probably will stay)

[ASIMKHAN222]

Found something (Chinese) about Vivo's unqine behavior: https://bbs.pediy.com/thread-268165.htm

This points out adding mount to init.rc can work: https://bbs.pediy.com/thread-199415.htm

please Guide which Tools we use for unpack or modify System.img to grant root Access

[Fox2Code]

I have though about it a bit, the problem of this issue is Magisk is not marked as a "system process" because it register itself as a service.

Maybe the init system is removing permission from the service processes unless a specific flag is given.

init calling the mount/magisk applet calling the mount syscall should in no way be different of each other.

Maybe a solution would be to make magiskinit sleep in the background until it need to launch magisk itself.

This is to avoid using init.rc services at all cost to not get an unprivileged context from the init process.

[canyie]

1. adb shell magisk su -c mount xxx /system # Operation not permitted
2. adb root && adb shell mount xxx /system # OK
3. adb root && adb shell sh -c mount xxx /system # Operation not permitted
4. adb shell su # Operation not permitted
5. adb shell magisk su # OK
6. adb shell cp /system/bin/echo /data/local/tmp/su && adb shell /data/local/tmp/su # Operation not permitted
7. adb shell cp /sbin/su /sbin/suu && adb shell /sbin/suu # OK
8. adb root && adb shell cp /system/bin/mount /sbin && adb shell /sbin/mount # Operation not permitted

According these tests, I think the kernel:

1. Prevent binary named "su" from being executed
2. Prevent mounting to /system if the process's grandparent process is not init (in other words, the process is not created by a init's direct child process)
3. Prevent mounting to /system if the program path is not in allowlist

If so, there must be some weird restrictions in their kernel.

[Fox2Code]

As magisk is directly in the init process it can mount according to theses 3 rules.

Making magisk daemon handle mount/unmount could be a workaround.

Also hex-patching the kernel could also be a viable solution, like what's already done with Samsung defex.

[canyie]

Yes but we still have another issue (apps cannot execute any binary named "su") so I tend to patch the kernel, but I cannot find anything about this weird behavior in their kernel source code. I will upload the source code to github.

[Fox2Code]

Well, making libsu prefer using magisk su rather than su could be a workaround.
Sure apps requiring su would not work, but at least apps using libsu could still get access to root.

[aIecxs]

does it affect symlinks?

[Fox2Code]

@aIecxs actually su is already a symlink to magisk, so yes it does affect symlinks.

[canyie]

Uploaded the kernel source code to https://github.com/canyie/iQOO-Z1-kernel
Also, source code of iQOO neo3's kernel is available at https://opensource.vivo.com/Project

[canyie]

Trying to execute any binary named "su" in Twoyi (an android container that interprets syscalls and run another Android system on an android device) or even in TWRP will also throw an operation not permitted error. So this may be a hardware restriction, wanna know why they did strange things to their devices 🤔

[Fox2Code]

@canyie it's really common for most TWRP recoveries to use stock kernel to work properly on a device.
I still think focusing on analyzing the kernel source code to resolve the issue is the best idea.
I already made a pull request to libsu to help workaround the su issue. -> topjohnwu/libsu#104

[Fox2Code]

The "Prevent mounting to /system if the program path is not in allowlist", maybe it's possible to get magisk daemon to be in the allow list by using LD_PRELOAD on a program on the allow list, the mount and sh applets seems to be on the allow list.

[yujincheng08]

@Fox2Code you got a vivo device? are you sure mount is allowed? as far as we tested, mount still produces EPERM.

but the mount issue can be easily bypassed. i hv done one. the core issue is su. we read the kernel source and nothing helped. so we assume there're some hardware constraints.

[Fox2Code]

@yujincheng08 nah, I'm just theorizing, if I didn't had so many problems in my life and the money I would probably just buy one to try to fix the bug, unfortunately I need to take care of my life first.

[romanovj]

actually there are requirements for unblocking su execution

read fs/vrr.c in https://github.com/vivo-source-mirror/Y53s

no blocking SU on LOS20 pre rooted userdebug gsi (vivo y31 2021), but it's become blocked after renaming /system/xbin/su

from source:

noused notrace void set_rs_s_u(void)
{
#if !(defined(RS_IS_ENG_BUILD) || defined(BBK_FOR_NET_ENTRY))
/* /system/xbin/su must exist! */

There'are also list of files yo search
check_string g_eng_mode_files

to unblock SU it's should be enough to have some files in firmware or find how to patch kernel here

[muhammadrafiasyddiq]

A iQOO 9 Pro (Android 11, kernel 5.10.66) user reported that even after he/she/they flashed a GKI kernel which was compiled from Google's source code, as soon as an app process got root permission (uid=0), the process would be killed. This behavior persisted no matter SELinux status. Tried to change SELinux policy to prevent anyone from sending SIGKILL to the root process, issue persisted. This prevented the user from using KernelSU, but Magisk and Magica worked.
What a f**king thing Vivo did!

probably killed by kernel itself, in my kernel there are task_in_vivo_white_list task_in_vivo_critical_list

which is called by "check_hung_task"

I don't if it's related

I Rebuild kernel Vivo Y21s su Can exec And mount Working but
kernel have many bug because missing driver

[romanovj]

Patch for su (if only execution blocked).
__do_execve_file –> do_execve_su_check_internal and do_execve_common_file_check

Both compare two symbols with s and u

Search for ( . - any symbol, I used radare2 /x command)
.fc.0171....0054....4039.fd.0171....0054
In founded strings (should be two-three hits) replace first fc with fd, then hexpatch kernel. (su -> wu)

For mount (see above universal patch for /system ).

do_mount –> vrr_do_mount_check_before_mount –> do_mount_check

patch vrr_do_mount_check_before_mount make it always immediately return 1

You should do it manually.
Search patterns in radare2
1f150071................61018052
1f150071........................61018052
085040b9....0034....4039
That's how it looks like after r2ghidra and manually naming some notexported functions.
vrr_do_mount_check_before_mount.txt

asm
vrr_do_mount_check_before_mount_asm.txt

[romanovj]

Successfully patched different kernel, use radare2 to find address
SU:
/x .fc.0171....0054....4039.fd.0171....0054
should be two hits, replace first fc with fd

Mount/remount
/x 085040b9....0034....4039
one hit, replace 0034 with 0035
(if you're unlucky then use another combinations to find and patch vrr_do_mount_check_before_mount(see above) or just apply patch only for /system (see in posts above)

[romanovj]

Successfully patched different kernel, use radare2 to find address SU: /x .fc.0171....0054....4039.fd.0171....0054 should be two hits, replace first fc with fd
Mount/remount /x 085040b9....0034....4039 one hit, replace 0034 with 0035 (if you're unlucky then use another combinations to find and patch vrr_do_mount_check_before_mount(see above) or just apply patch only for /system (see in posts above)

faced bug after you patch

ok!

[romanovj]

did you able to do it before?

[romanovj]

so my patches worked on stock rom, but bootloops on gsi, right?

magisk SUU worked on gsi?

[romanovj]

just flash gsi into system partition xD

[romanovj]

for tests you should

1. patch boot with stable magisk 24.3+ and try to boot

2. apply my SU patches and try to boot

3. apply "mount /system" patch (VIVO/iQOO kernel restictions: "Operation not permitted" when executing su or mounting to /system, or bootloops if rooted #5148 (comment)) and try to boot

4. If everything is fine then bug is caused by my ugly patching of vrr_do_mount_check_before_mount. You can patch it differently.
   Find 3 instructions
   /x 085040b9....0034....4039

In my case it's
085040b9680e003408a04039

ldr w8, [x0, #0x50]
cbz w8, #0x1d0
ldrb w8, [x0, #0x28]

replace 'cbz w8' with 'b'
cbz w8, #0x1d0 -> b #0x1d0

convert it back

085040B97300001408A04039

Final patch for me
085040b9680e003408a04039 -> 085040B97300001408A04039

[AarifZ]

Successfully patched different kernel, use radare2 to find address SU: /x .fc.0171....0054....4039.fd.0171....0054 should be two hits, replace first fc with fd

Mount/remount /x 085040b9....0034....4039 one hit, replace 0034 with 0035 (if you're unlucky then use another combinations to find and patch vrr_do_mount_check_before_mount(see above) or just apply patch only for /system (see in posts above)

Thank you very much this helped a noob like me to get magisk-26.4 with su working on my Vivo v15

• I've patched /x .fc.0171....0054....4039.fd.0171....0054 (2 hits)
• /x 085040b9....0034....4039 (1 hit)
• and mount /system by /system -> /syswxl
  using stock boot image and then magisk patched it.

My Notes:

• Failed to boot when I used Hex edtior pro app for kernel its better to use magisk's hexpatch kernel also stock recommend.
• Magisk_patched didn't boot maybe I left vbmeta checked or something on it.
• Limitation is that even though its rooted some binaries cant be executed unless selinux is set permissive or moved to system and perm_set 0 2000 0755 u:object_r:system_file:s0 example for frida or similar tools

[romanovj]

@AarifZ actually it's possible to patch kernel with radare2, I'm just too lazzy to write how to and to lazzy to write script for automation

oo+

then it's become possible to write
https://book.rada.re/basic_commands/seeking.html
https://book.rada.re/basic_commands/write.html

[AarifZ]

@romanovj ah seems good maybe someone can fuse the magisk tools and radare2 and some script to make a Boot.img patcher for these devices and throw exception for unsupported kernels. only automation I know is tasker unfortunately possible but not feasible here.
I thought vivo will be as easy as any oppo but after Preloader auth these kernel restrictions lol spent 2 days trying everything ported Twrp tried GSI etc.,, nothing helps everything Bootloops or Twrp fails mounting many partitions , after browsing across xda found magisk suu it worked so after reading the thread few times and following your guide was able to root it definitively. cant thank you enough and everyone's contributions to this thread.

[Adeyoelabbb]

Thank you everyone, can you please easy way to access su after rooting samsung galaxy via magisk?
Thanks

[K11MCH1]

@AarifZ actually it's possible to patch kernel with radare2, I'm just to lazzy to write how to and to lazzy to write script for automation

oo+

then it's become possible to write https://book.rada.re/basic_commands/seeking.html https://book.rada.re/basic_commands/write.html

Is this still for devices with released kernel source, or can be used with closed source?
Asking cause I'm iQOO 11 owner.

[romanovj]

@AarifZ actually it's possible to patch kernel with radare2, I'm just to lazzy to write how to and to lazzy to write script for automation
oo+
then it's become possible to write https://book.rada.re/basic_commands/seeking.html https://book.rada.re/basic_commands/write.html

Is this still for devices with released kernel source, or can be used with closed source? Asking cause I'm iQOO 11 owner.

you don't need sources for hexpatching

[dxkf177]

Device: iQOO Z1/VIVO X70 PRO/iQOO NEO3, and more
Android version: N/A
Magisk version name: N/A
Magisk version code: N/A, but more serious since 24302

Magisk fails to mount /system on some Vivo/iQOO devices.

01-01 08:17:34.721  root   650   652 E Magisk  : mount tmpfs->/system/bin failed with 1: Operation not permitted
01-01 08:17:34.721  root   650   652 E Magisk  : mount /dev/Qnh/.magisk/mirror/system/bin/AudioSetParam->/system/bin/AudioSetParam failed with 1: Operation not permitted
01-01 08:17:34.721  root   650   652 E Magisk  : mount /dev/Qnh/.magisk/mirror/system/bin/TEST_IServiceManager->/system/bin/TEST_IServiceManager failed with 1: Operation not permitted
01-01 08:17:34.721  root   650   652 E Magisk  : mount /dev/Qnh/.magisk/mirror/system/bin/abb->/system/bin/abb failed with 1: Operation not permitted

According to a bug report from a "Vivo internal staff" who has a device running userdebug build, adb root and manually mount /system works but fails when mounting in Magisk superuser environment. After debugging with him/her/them, we found that the device only allows programs in /system to mount the system partition (move binary that will mount /system to other partitions, and it fails even in adb root environment). I believe that the device has an allowlist and refuses to mount key partitions for programs if their partition is not in the allowlist.

I think the following two solutions may fix it:

1. Reimplement magic mounting logic in rc script language and add it to init.rc.
2. Inject Magisk binaries to /system in magiskinit.

I'm unsure when this problem will be solved, so I opened an issue to track the relevant information.

---

Edit: even successfully mount su to /system/bin/su, executing su will throw an operation not permitted error.

[AarifZ]

Device: iQOO Z1/VIVO X70 PRO/iQOO NEO3, and more
Android version: N/A
Magisk version name: N/A
Magisk version code: N/A, but more serious since 24302
Magisk fails to mount /system on some Vivo/iQOO devices.

01-01 08:17:34.721  root   650   652 E Magisk  : mount tmpfs->/system/bin failed with 1: Operation not permitted
01-01 08:17:34.721  root   650   652 E Magisk  : mount /dev/Qnh/.magisk/mirror/system/bin/AudioSetParam->/system/bin/AudioSetParam failed with 1: Operation not permitted
01-01 08:17:34.721  root   650   652 E Magisk  : mount /dev/Qnh/.magisk/mirror/system/bin/TEST_IServiceManager->/system/bin/TEST_IServiceManager failed with 1: Operation not permitted
01-01 08:17:34.721  root   650   652 E Magisk  : mount /dev/Qnh/.magisk/mirror/system/bin/abb->/system/bin/abb failed with 1: Operation not permitted

According to a bug report from a "Vivo internal staff" who has a device running userdebug build, adb root and manually mount /system works but fails when mounting in Magisk superuser environment. After debugging with him/her/them, we found that the device only allows programs in /system to mount the system partition (move binary that will mount /system to other partitions, and it fails even in adb root environment). I believe that the device has an allowlist and refuses to mount key partitions for programs if their partition is not in the allowlist.
I think the following two solutions may fix it:

1. Reimplement magic mounting logic in rc script language and add it to init.rc.
2. Inject Magisk binaries to /system in magiskinit.

I'm unsure when this problem will be solved, so I opened an issue to track the relevant information.

Edit: even successfully mount su to /system/bin/su, executing su will throw an operation not permitted error.

If done hexpatch installing selinux permissiver in magisk help fix many module issues which aren't executing or having issues.

[depesh1977]

I have Y81,android 8.1 on hand. I faced the same situation.
/x .fc.0171....0054....4039.fd.0171....0054
It doesn't find anything.Maybe there should be another mask there.
kernel posted to the cloud there

[AarifZ]

Have you tried mtksu? @depesh1977

[depesh1977]

Have you tried mtksu? @depeshIt doesn't work for me.

[1q23lyc45]

Vivo Y52s 5G (PD2057C) FuntouchOS 10 MTK6853
Using MagickBoot to patch the kernel resulted in a bootloop. So I used Radare2 to directly modify it, and the modification was successful. Both Stock ROM and GSI can boot successfully.

Only applicable to kernels with compilation time less than September 17, 2024 (tutorial release time) and kernel version 4. x. If the device has a 5. x kernel, please directly flash GKI.

0x73 > 0x77 (su > wu)
First, Enter this command to open the kernel using radare2 : r2 kernel
Second,

[0x00000000]> /x .fc.0171....0054....4039.fd.0171....0054

There should be several hits. For example:

[0x00000000]> /x .fc.0171....0054....4039.fd.0171....0054
0x003e2e7c hit0_0 3fcd017141010054080540391fd50171e1000054
0x00674bb0 hit0_1 3fcd0171c1000054090540393fd5017161000054
0x00674c3c hit0_2 3fcd017161010054080540391fd5017101010054
[0x00000000]>

Write down the hexadecimal digits in the first column. Third, run oo+.

Then, run s <The first hexadecimal digit> ; pd 2, for example, s 0x003e2e7c;pd 2, At this point, the first line contains assembly code starting with cmp, such as cmp w9, 0x73. Copy it to clipboard. Enter "wa" then paste, and edit 0x73 to 0x77, and press enter.

Finally, Perform the same operation on the other hexadecimal addresses noted above, then enter q to exit.

Bug: Magisk Daemon still cannot boot up and can only be manually started using the adb root;adb shell /sbin/magisk --daemoncommand.