awa

awa

一、vivo root限制:

 

1.vivo及iqoo在早期就引入了相当激进的反root机制，这可以追溯到baseline 3.x时期，3.x内核版本到4.x，这些反root嵌入进内核，需要对内核进行逆向才能去除，操作复杂，难度较大，暂不做讨论。如有需要解除早期反root或者有使用apatch root方案的需求，建议找酷安@酷狗贼 。

 

2.gki时期。自从gki标准引入后，从5.x开始算作gki1-gki2的过渡时期，简单说gki要求内核不允许内嵌厂商私有定制的功能和驱动，比如上文所述的vivo系反root功能，在通用内核标准下不合规，所以vivo为了遵循规范，将反root功能移出内核，但并没有停止反root，他们开发了一个安全模块，目前叫vr.ko，它存在于vendorboot分区内。在gki标准下，vendorboot用于存放厂商私有定制的驱动和功能，它以ramdisk形式分别（可选）服务正常启动和recovery模式（也包含userspace fastboot实现也就是fastbootd模式），向通用内核提供启动所需的驱动（ko），挂载（fastab）和rc脚本等（用于初始化启动环境），而只要内核（boot分区内）启动，就从vendorboot拉取驱动，这时候vr.ko作为vivo定制的反root、安全模块则被加载。insmod成功后，vr会在已加载驱动列表中隐藏自身，所以开机以后，实际上看不到这个ko。

 

3.经过长期的研究，gki时期的反root对抗（kernelsu项目早在两年前有开启vivo设备相关的issue，但最终都没有一个好的解决方案），于2026年初，@酷狗贼 尝试在5.1+的机器中修改vr.ko，消除其运行过程中的部分权能，以达到不击杀root进程的表现，但是这套方案没有彻底阻止vr运行，vr是一个相当庞大的模块，有厂商的插桩测试和回报机制，会遍历内核链表检测钩子改动，所以到这个阶段都是治标不治本。2026年二月年关左右，我联系到酷狗贼并加入对vivo反root机制的研究，并最终完全移除了vr.ko。直到此时，这个问题才算彻底解决。

 

以下有几点补充兼注意事项（如果你想手动摸一遍这套流程）：

1.vendorboot.img只能由Linux版本的magiskboot工具解包，必须是magisk官方项目的magiskboot，这可以在Android构建的magisk app内找到，libmagiskboot.so，就是linux构建的magiskboot。使用手机的终端（如mt管理器）运行./magiskboot unpack vendorboot.img，就可以得到解包后的ramdisk.cpio。ramdisk.cpio内的lib/modules/包含待加载的驱动ko。

在5.10到6.1期间，lib/modules/下包含两套驱动，一套是官方内核ko，在这之下还有一套子目录包含通用内核的适配驱动，比如lib/modules/6.1-gki，这里面就是6.1 gki内核会加载的驱动，当然这里面也包含一套vr.ko。2.接下来移除vr.ko。在lib/modules/下和lib/modules/xxx-gki/下，通常都会有modules.load、modules.dep、modules.softdep、modules.load.recovery等清单，这些清单告诉内核启动时需要加载哪些ko，我们需要在这些清单里把vr.ko有关的行删干净，注意！必须是引用vr.ko或者直接vr.ko的全部删干净，一旦有遗留则一定不开机。至于vr.ko本身，想不想删都无所谓，放在那它只要不加载就没影响。但是如果你没删干净list清单，那包炸的，甚至可能你fastbootd都进不去，recovery也进不去（这有可能是module.load.recovery没删干净）。怎么改cpio内的文件就不用我教了，自己去翻magisk的官方文档。以及重新打包vendorboot，把解包命令换成repack就好了。

 

接下来还会提供一份更简单的方法，不想看原理的可以直接往下跳了。

 

二.官方内核机制：

 

在vivo 5.x到6.1之间、4.x之后、6.6之前这个阶段，都有上文所述的“两套驱动，分别给官方内核和gki内核”这种驱动分类的机制，那么在这种情况下，官方内核和gki通用内核需要分清楚自己该加载哪一套驱动，于是vivo给官核引入了一个机制，vermagic验证。vermagic存在于kernel内部和ko，它是一个标志类的东西，这边引用如下：

"Linux 标准路径里，`finit_module` / `init_module` 进入 **`load_module`** 后，会从 ELF **`.modinfo`** 读取 **`vermagic=`**，与内核 **`.rodata` 内嵌的一条期望字符串** 比较（实现上常见为 `strcmp` 族 + 可选「跳过首段至空格」的变体，取决于 `load_info` 中的标志位）。不匹配则本次加载返回错误

 

vivo 该期望串在样本上形如：

6.1.145-android14-11-maybe-dirty SMP preempt mod_unload modversions vivo aarch64"

 

那么vivo的官方内核只认vermagic符合该格式的ko，而gki内核（包括kernelsu、lkm ko！！）通常不包含“vivo”字段，这就区分了两种内核分别加载的驱动。这也可以解释为什么vivo官方内核无法加载kernelsu lkm。以及顺便提一嘴，gki通用内核那一份驱动有很多是跟官核不一样的，比如zram.ko，这就能解释为什么vivo的机器刷了通用内核系统内的内存压缩功能会失效，因为两套zram.ko，通用内核加载的那一套不包含vivo的私有算法，它体积上都小很多。那如果需要使用官方内核的kernelsu，则需要逆向内核修改这方面验证或者给kernelsu lkm的ko在编译期就加上“vivo”的vermagic。

 

在6.6以后，两套ko机制不存在了。

这时候不得不说很多人关心的，内核签名问题。由于6.6以下的gki2机型的vendorboot存在两套驱动，vivo官方内核需要从vermagic和签名两个方面判断ko是否需要加载，那“过签”我们需要同时去除这两层验证，实测开机时第一轮insmod就会出错，内核panic（比如说官方内核加载了不属于官核的ko或者重复加载一个ko），这种insmod紊乱的现象就会导致不开机，所以说在5.1-6.1，最高到天玑9300设备上，如果想“过签”，就需要切换到通用内核（因为通用内核不会去加载带vivo的那一套官核驱动，所以能正常开机）。但是现在通用内核问题也很多，由于兼容性原因，会卡顿、死机重启、实测下来打开微信会很高概率因为一个叫zcache的ko的问题诱发panic重启，但在官方内核上就不存在这种问题。

 

不出意外的话从天玑9400/9500开始，lib/modules/下只有一套ko，官方内核也可以直接加载ksu、lkm，这是vivo合规化的表现。再者理论上官方内核也可以过签刷第三方驱动。如果手里有已解锁的vivo 天玑9400/9500机器，有意愿者可以联系我验证研究，暂时无偿帮忙测试ksu/过签

 

三、补充说明和sakisu：

 

目前实测来看，6.1的机器在升级到originos5以后，使用apatch方案会导致内核不启动，6.6及以上暂时没有测试，不清楚什么情况。所以说vivo系列诸多限制的情况下，最好的内核级方案还是kernelsu系，为此，我在resukisu的基础上开发了sakisu（https://github.com/XingChenRS/SakiSU/tree/dev），它提供了适配vivo特性的lkm ko，即选择init_boot修补时会有弹窗：选择适配本机的kmi，这时只需要选择带vivo后缀的kmi（比如6.1 android13 vivo）就可以完美适配vivo官方内核。更重磅的是一键vr移除，在开启vivo功能的情况下，选择vendorboot会自动识别、去除上文所述的vr.ko再重新打包，这时候只需将修补完成的vendorboot刷入设备，反root限制就没有了。vivo功能的反root和lkm适配互不依赖，实测移除vr可以支持5.4（所谓的加假5系、gki1.0）到6.12，只要你能解bl锁，ksu就唾手可得。5.4系、只要有vendorboot分区的机器都可以试试用sakisu修补，去除vr之后用apatch、skroot等内核级方案也不影响。