Repository navigation
Conversation
vivo X Fold5 (V2436A / PD2436), SM8650, OriginOS 6 / Android 16, firmware PD2436E_A_16.1.17.12.W10.V000L1, kernel 6.1.145-android14-11-maybe-dirty. Offsets extracted from this firmware's own boot.img / xbl_config.img / uefi.img, then validated on the device. The multicast_waiter route completes the whole chain (uid 0 -> kernelsu.ko -> enforcing restored); 15 of the 22 runs that reached the route stage finished. Two values are not the defaults: - heap.prepare_max_attempts = 1. On this device, if the first prepare_kernel_page screen needs a retry the run has never succeeded (0/4), and it wedges the whole device until the watchdog reboots it. Bailing out after one attempt fails cleanly in userspace in about 1.4s instead. - fallback.to = "none". select_stack is unreachable on this kernel build (see YuKongA#112), and I don't have enough tcp_zerocopy data here to rely on it. kernel_phys_offset is left out on purpose: it was derived correctly at runtime in every validated run. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
这台设备不在内置列表里，我做了一份 profile 并在真机上验证通过。
设备是 vivo X Fold5（V2436A / PD2436），高通 SM8650，OriginOS 6 / Android 16，固件
PD2436E_A_16.1.17.12.W10.V000L1，内核6.1.145-android14-11-maybe-dirty，Bootloader 未解锁。偏移从固件的
boot.img/xbl_config.img/uefi.img提取，然后在真机上验证。multicast_waiter路线可以走通完整链路：拿到 uid 0、加载kernelsu.ko、最后把 SELinux 恢复为 enforcing。真正进入 route 阶段的运行共 22 次，其中 15 次完成。两个设定值
heap.prepare_max_attempts设为 1。这台设备上有一个比较稳定的规律：第一次
prepare_kernel_page筛选分页就通过时，成功率约八成（15 成 3 败）；需要进入重试prepare_kernel_page的运行失败率较高，目前为止一次都没有成功（0 成 4 败）。失败的形式表现为整机卡死，约二十秒后设备自动重启。所以在这台设备上继续重试的代价比较高：不能增加 root 成功率，却增加了重启的概率。设为 1 之后，第一次没通过就直接退出，耗时约 1.4 秒，设备不受影响，重新运行一次即可。这样跑了 3 次会话，3 次都稳定拿到 root，其中 2 次触发了这个提前退出后重试，没有重启。
不过我不确定这个字段原本是否适合这样用，它看起来更像一个调参项。如果你认为不该这样写，改回 12 不影响这份 profile 的其他部分。
fallback.to = "none"。select_stack在这个内核构建上几何不可用（+pgo +bolt +lto，#112 有反汇编层面的结论）；tcp_zerocopy我跑过几次，但样本不足，不做判断。因此没有保留 fallback。kernel_phys_offset（0x80000000）没有写死，每次运行它都被正确推导出来。有一处需要 maintainer 注意
6.1.145-android14-11-maybe-dirty这个内核 release 至少有三台设备在跑，而且 SoC 并不同：我只在 X Fold5 上验证过。按目前精确匹配
uname -r的选择方式，这个文件合入后另外两台也会加载它。我自己遇到过一次类似的情况：十月初用了一份地址距离正确 offset 偏移 0x20 / 0x40 的 profile，能拿到 root、KernelSU 也正常加载，但
vr.ko没有被中和，运行几分钟后 UI 冻结。当时的现象和 exploit 不稳定几乎无法区分，排查了两天才定位到是 profile 不对。所以我担心另外两台设备用上这份之后会遇到类似的情况。它不会直接报错，而是看起来像成功了，然后在别处出问题。目前 profile 似乎是按
uname -r索引的，而这个在我这里并不唯一。可能需要添加其他的判断逻辑。或者改成只放文档、留给需要的人自行导入。关于 vr_guard
这份 profile 带了
recommend_vr_guard、vr_guard.tracepoint_funcs和offset.vr_sys_exit_tp。我看到 dev 版说明里提到要移除 vr.ko 逻辑，后续交给插件系统。插件接口出来之后应该可以直接迁移，不影响这次合并。更多运行数据和日志在 #354。需要
boot.img，或者成功 root 后的dmesg和 KernelSU 初始化序列，我都可以提供