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]

this patch works, can mount /system after it

• patch vivo do_mount_check

• /system -> /syswxl

• python3 -c "print(hex(int.from_bytes(b'/system', 'big')^int('bdbcbbbab9b8b7', 16)))"

• ./magiskboot hexpatch kernel 0092CFC2C9CDDDDA00 0092CFC2C9CEC0DB00
  https://github.com/wuxianlin/build_magisk_vivo/blob/master/patches/Magisk/patch_vivo_do_mount_check.diff

and on userdebug gsi kernel doesn't prevent execution of su

remounting / could be done from adb root

[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)

[muhammadrafiasyddiq]

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

[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!

[muhammadrafiasyddiq]

gsi or dsu cannot boot / decrypt

[romanovj]

did you able to do it before?

[muhammadrafiasyddiq]

apakah kamu bisa melakukannya sebelumnya?
yess gsi google and stock work fine before now only bootloop

[romanovj]

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

magisk SUU worked on gsi?

[muhammadrafiasyddiq]

yes stock rom fine
but dsu slot bootloop all rom

[romanovj]

just flash gsi into system partition xD

[muhammadrafiasyddiq]

i don't know why keymaster cannot decrypt userdata

[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.