软件安全与逆向分析 https://wechat2rss.xlab.app/feed/021e3a28dfa435253d1b5610e6678205ea0919b6.xml 分享最前沿的软件安全与逆向分析技术与资讯。包括Windows、macOS、iOS、Android、Linux等平台。 (wechat feed made by @ttttmr https://wechat2rss.xlab.app) (软件安全与逆向分析) https://wx.qlogo.cn/mmhead/Q3auHgzwzM7Gka279vlRGZfQGVKG8Oy8HvZaSibRVWYqwI8g4X7tsbA/0 软件安全与逆向分析 https://wechat2rss.xlab.app/feed/021e3a28dfa435253d1b5610e6678205ea0919b6.xml 安卓完美云手机内测镜像已发布，支持以下机型 https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485396&idx=1&sn=4f20dc5e303adf9d75bd57d448d9b57d 原创 非虫 2026-08-24 16:39 湖北

  • Rock 5b开发板

  • OrangePi 5Plus开发板

  • OrangePi 6Plus开发板

  • 明钒MS-R1迷你主机

  • 苹果M1 MacMini

  • 苹果M1 Max笔记本

  • 苹果M4 MacMini

  • 苹果M4 MacMini Pro

  • 苹果M4 Macbook Air笔记本

  • NVIDIA DGX Spark迷你主机

支持的机型可选不止这些，但目前手上能测试的环境就这些。

理论上绝大多数3588开发板（私板不支持，无驱动无法制作基座），所有CIX P1开发板，苹果M全系电脑都支持。

以后更新支持机型列表。

跳转微信打开

]]> Mon, 24 Aug 2026 16:39:00 +0800 安卓完美云手机首个内测镜像发布，第一季课 https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485391&idx=1&sn=3abc2e4ca0fd3ae4ba72c19e1f7fd50f 有学员反馈，多多云机这个名字已经有厂家在使用了，重新给安卓云手机想了个好听的名字：蜚卓通 对子机型可以取名如（口嗨）： 蜚星通、蜚米通、蜚菊通、蜚空通、蜚加通、蜚我通、蜚想通、蜚尼通。 云机课程第一季方案篇已完结！课程6折优惠还有一天！ 马上就会开始第二季更新。现更新Pixel6的完美机型镜像，给课程学员内测使用找找Bug。 注意：镜像运行支持在RK3588、CIX P1开发板，苹果M全系列电脑上运行。DGX Spack理论支持，待学员测试反馈给我后我同步一下。所有云机学员不得对外分发镜像，否则视为放弃后面课程视频更新与代码发放！ 一枚程序，一个镜像，方为天地！ 非虫 2026-08-19 15:32 湖北

有学员反馈，多多云机这个名字已经有厂家在使用了，重新给安卓云手机想了个好听的名字：蜚卓通

对子机型可以取名如（口嗨）：

蜚星通、蜚米通、蜚菊通、蜚空通、蜚加通、蜚我通、蜚想通、蜚尼通。

云机课程第一季方案篇已完结！课程6折优惠还有一天！

马上就会开始第二季更新。现更新Pixel6的完美机型镜像，给课程学员内测使用找找Bug。

注意：镜像运行支持在RK3588、CIX P1开发板，苹果M全系列电脑上运行。DGX Spack理论支持，待学员测试反馈给我后我同步一下。所有云机学员不得对外分发镜像，否则视为放弃后面课程视频更新与代码发放！

一枚程序，一个镜像，方为天地！

跳转微信打开

]]> Wed, 19 Aug 2026 15:32:00 +0800 安卓完美云手机首个内测镜像发布，第一季课程完结！ https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485387&idx=1&sn=a9bef45ddde395ea734f92178dd4b89e 安卓完美云手机首个内测镜像发布，第一季课程完结！ 原创 非虫 2026-08-19 15:25 湖北

安卓完美云手机首个内测镜像发布，第一季课程完结！

有学员反馈，多多云机这个名字已经有厂家在使用了，重新给安卓云手机想了个好听的名字：蜚卓通

对子机型可以取名如（口嗨）：

蜚星通、蜚米通、蜚菊通、蜚空通、蜚加通、蜚我通、蜚想通、蜚尼通。

云机课程第一季方案篇已完结！课程6折优惠还有一天！

马上就会开始第二季更新。现更新Pixel6的完美机型镜像，给课程学员内测使用找找Bug。

注意：镜像运行支持在RK3588、CIX P1开发板，苹果M全系列电脑上运行。DGX Spack理论支持，待学员测试反馈给我后我同步一下。所有云机学员不得对外分发镜像，否则视为放弃后面课程视频更新与代码发放！

一枚程序，一个镜像，方为天地！

跳转微信打开

]]> Wed, 19 Aug 2026 15:25:00 +0800 安卓完美云手机支持功能列表 https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485381&idx=1&sn=67d8e3d0cbea6c384da7e6633613a24c 安卓云手机功能模型 原创 非虫 2026-08-04 17:19 湖北

安卓云手机功能模型

本文列举安卓云手机各项功能的当前状态和版本范围。

多多完美云机的实现方案为更通用的跨平台实现方案。不采用任何国内已知的如Cuttlefish/AVD/Redroid/LXC/Waydroid等方案。

完美云机课程共30小节三个阶段。每个阶段10小节。目前第一阶段更新大半，本月会更新完第一阶段，现在报名优惠6折价格。第二阶段开更7折优惠，第三阶段开更8折优惠，完结恢复原价，发布课程全套代码。在这里承诺课程永远不会降价，把云机实现兑现给每个真实有需求的朋友。

注意这是高端课程，课程就算半价也是过W的。

声明：多多云机于我个人而是，目标是为安全逆向分析与木鱼沙箱动态分析提供后端技术赋能与安全分析所使用，但它的能力远不止于此。支持现在主流的电商出海业务。但注意不支持任何黑灰产，找我买成品镜像的请绕道！做国内任何黑灰产项目的请绕道！云手机所有功能无任何功能虚假宣传与不良引导，更无任何黑灰产业功能暗示。

完美云机课程完结时，会提供成套的项目代码与文档。方便学习交流与二次定制。

 接下来列举出来的功能列表基本涵盖了安卓完美云手机的所有能力了。后面课程更新时，可能会有个别项根据项目更新需要进行能力调整，但整体变化不会太大，特别在意个别功能的可联系我确认。

功能列表

每项功能分别标记当前实现状态，以及个人版和企业版的提供范围。

环境与设备信息模拟

 注意：以下能力非常特殊，只能用于合法自动化测试与安全分析相关等场景。

环境模拟覆盖应用和系统可读取的位置、网络、设备身份、电量、时间与传感器状态，如表1-1所示。

功能

说明

已实现

个人版

企业版

GPS模拟

设置经纬度、高度、速度、卫星数和时间

✅

✅

✅

定位数据模拟

注入标准定位数据

✅

✅

✅

Wi-Fi功能模拟

设置Wi-Fi开关、连接状态和网络信息

✅

✅

✅

Wi-Fi列表模拟

提供可配置的热点名称、频段、信号强度和安全类型

✅

✅

✅

真实系统指纹信息

提供对应系统的完整信息

✅

✅

✅

CPU与内存信息

提供对应设备的CPU和内存信息

✅

✅

✅

显示信息

提供分辨率、密度、刷新率、方向和显示尺寸

✅

✅

✅

电量变化模拟

调整电量、充放电状态、电源连接和电池在位状态

✅

✅

✅

时间与区域模拟

设置系统时间、自动时间、时区、语言区域和时间制式

✅

✅

✅

传感器模拟

模拟加速度、磁场、陀螺仪和铰链角度

✅

✅

✅

震动模拟

设置震动时长、幅度和停止状态

✅

✅

✅

温度信息

提供温度、阈值和系统热状态

✅

✅

✅

自动电量模型

按时间自动充电、放电并变化电量和充电状态

✅

✅

✅

完整传感器数据

提供全部传感器的连续数据

❌

✅

✅

动态温度模型

根据运行负载变化温度和性能状态

❌

✅

✅

宿主触觉反馈

将云手机震动反馈到宿主设备

❌

✅

✅

GPS路线连续播放

按时间序列播放位置、速度和卫星变化

❌

❌

✅

卫星原始数据

提供卫星原始测量和导航数据

❌

❌

✅

表1-1 环境设备能力

SIM、短信与电话

 注意：以下能力非常特殊，只能用于合法自动化测试与安全分析相关等场景。

通信模拟覆盖卡状态、移动网络、短信、呼叫和蜂窝数据等系统电话能力，如表1-2所示。

功能

说明

已实现

个人版

企业版

SIM模型

提供模拟手机号、卡状态、运营商和移动网络信息

✅

✅

✅

电话模型

模拟网络信号、来电、接听、保持、拒接和挂断

✅

✅

✅

短信模拟

模拟接收文本短信和PDU短信

✅

✅

✅

蜂窝数据模拟

模拟移动数据注册、连接和断开

✅

✅

✅

动态修改SIM号码

在运行中更新模拟SIM号码

❌

✅

✅

模拟短信外发

使用透传SIM向真实号码发送短信

❌

❌

✅

模拟电话外呼

使用透传SIM拨打真实电话

❌

❌

✅

云手机互拨

在云手机模拟号码间双向通话

❌

❌

✅

eSIM

下载、切换和管理eSIM

❌

❌

✅

电话数据控制

批量管理通话记录、通讯录和订阅数据

❌

❌

✅

完整电话服务

提供系统电话、短信、SIM和移动数据所需的完整服务

✅

✅

✅

表1-2 通信模拟能力

系统与运行

宿主能力按编译、系统补丁和云手机运行三个阶段分别记录，如表1-3所示。

功能

说明

已实现

个人版

企业版

安卓系统

运行安卓15、安卓16和安卓17

✅

✅

✅

macOS编译、补丁与运行

在Apple Silicon Mac上编译项目、制作系统补丁和运行云手机

✅

✅

✅

RK3588开发板编译、补丁与运行

在RK3588开发板上编译项目、制作系统补丁和运行云手机

✅

✅

✅

CIX P1开发板编译、补丁与运行

在CIX P1开发板上编译项目、制作系统补丁和运行云手机

✅

✅

✅

Linux arm64编译、补丁与运行

在Linux arm64设备上编译项目、制作系统补丁和运行云手机

✅

✅

✅

Linux x86_64 PC编译与补丁

在Linux x86_64 PC上编译项目和制作系统补丁

✅

✅

✅

Linux x86_64 PC运行

在Linux x86_64 PC上运行ARM64云手机

❌

❌

❌

云手机Docker部署

使用Docker部署和运行云手机服务

✅

✅

✅

CPU硬件加速

使用宿主CPU硬件能力运行云手机

✅

✅

✅

实例多开

同时运行多个数据与状态相互独立的云手机实例

✅

✅

✅

实例生命周期

创建、启动、查看、暂停、恢复、重启、停止、重置和删除实例

✅

✅

✅

窗口与后台运行

提供窗口显示、窗口缩放和后台运行

✅

✅

✅

启动状态检查

检查系统启动、设备连接、显示、资源和运行状态

✅

✅

✅

浏览器远程使用

提供低延迟画面、音频和输入控制

❌

✅

✅

多显示器与折叠屏

提供多显示器、折叠状态和连续窗口布局

❌

✅

✅

应用虚拟显示

按应用创建和管理独立虚拟显示

❌

✅

✅

首次启动时间

设置首次启动时间和设备激活时间

❌

✅

✅

一键新机

一次操作重建身份、数据和运行状态

❌

❌

❌

表1-3 系统运行能力

应用与分身

应用能力覆盖安装、调试、数据隔离、分身运行和文件交换，如表1-4所示。

功能

说明

已实现

个人版

企业版

应用安装

安装单包和多包安卓应用

✅

✅

✅

国外常见App使用

安装和运行海外社交、电商、内容与工具类常见应用

✅

✅

✅

应用分身

在系统分身空间中启用或停用指定应用

✅

✅

✅

分身独立数据

主应用与分身应用使用独立账号和数据

✅

✅

✅

分身同时运行

同时启动和运行主应用与分身应用

✅

✅

✅

应用调试

提供命令行、日志、文件传输和端口转发

✅

✅

✅

文件上传下载

在宿主与云手机之间上传和下载文件

✅

✅

✅

锁屏控制

设置或清除锁屏密码、锁定屏幕和密码解锁

✅

✅

✅

表1-4 应用分身能力

图形、显示与媒体

图形与媒体能力覆盖画面渲染、输入、音频、视频编解码和相机数据，如表1-5所示。

功能

说明

已实现

个人版

企业版

GPU加速

使用宿主GPU加速图形显示和三维应用

✅

✅

✅

分辨率与密度

设置分辨率、显示密度、旋转方向和尺寸

✅

✅

✅

键盘与鼠标

提供按键、文本、鼠标和基础触控输入

✅

✅

✅

截图

按实例生成截图

✅

✅

✅

屏幕录像

录制云手机屏幕视频

✅

✅

✅

音频播放

提供媒体、听筒和通话音频播放

✅

✅

✅

音量控制

读取和设置不同场景的音量

✅

✅

✅

软件编解码

使用软件完成音视频编解码

✅

✅

✅

硬件视频解码

提供H.264和H.265硬件解码

✅

✅

✅

相机枚举与参数

提供前置、后置、广角和多摄像头信息

✅

✅

✅

硬件视频编码

提供H.264硬件编码

✅

✅

✅

麦克风输入

将宿主麦克风和音频输入设备接入云手机

❌

✅

✅

完整多点触控

提供多指手势、压力和连续触点轨迹

❌

✅

✅

相机预览与采集

提供预览、拍照、录像、RAW和图像分析

❌

❌

✅

相机透传

将宿主内置摄像头或USB摄像头画面传入云手机

❌

❌

✅

虚拟相机

将图片或视频作为虚拟相机画面

❌

❌

✅

表1-5 图形媒体能力

网络与连接

网络能力同时覆盖应用访问网络和实例管理连接，如表1-6所示。

功能

说明

已实现

个人版

企业版

IPv4与IPv6

提供IPv4和IPv6网络访问

✅

✅

✅

独立管理网络

将设备管理网络与应用网络分离

✅

✅

✅

端口转发

将宿主端口映射到云手机

✅

✅

✅

网络限速

分别设置上传和下载速率

✅

✅

✅

网络延迟

设置固定延迟和延迟范围

✅

✅

✅

网络抓包

开始、停止、查询和定时保存网络抓包

✅

✅

✅

HTTP代理

设置和清除系统全局HTTP代理

✅

✅

✅

调试连接

为每个实例提供独立的调试和维护连接

✅

✅

✅

宿主与局域网隔离

提供统一的宿主访问和局域网访问隔离策略

❌

✅

✅

蓝牙通道

在云手机与宿主之间传输蓝牙数据

❌

❌

✅

蓝牙完整功能

提供扫描、配对、低功耗广播和设备数据收发

❌

❌

✅

表1-6 网络连接能力

硬件与安全

硬件能力通过安卓系统标准功能向应用提供，安全能力覆盖设备密钥、认证和完整性状态，如表1-7所示。

功能

说明

已实现

个人版

企业版

定位硬件服务

向系统和应用提供真实设备语义的位置

✅

✅

✅

传感器硬件服务

提供传感器清单和部分传感器数据

✅

✅

✅

灯光硬件服务

提供灯光设备和状态控制

✅

✅

✅

震动硬件服务

提供震动强度、时长和停止控制

✅

✅

✅

温度硬件服务

提供温度、阈值和热状态

✅

✅

✅

NFC基础功能

提供NFC开关、基础通信和卡模拟能力

✅

✅

✅

生物指纹接口

提供系统生物指纹接口和设备信息

✅

✅

✅

硬件级密钥服务

提供设备密钥和密钥证明基础能力

✅

✅

✅

生物指纹认证

提供指纹录入、触摸、认证和密钥授权

❌

❌

❌

NFC完整功能

提供标签读取、点对点通信和安全单元

❌

❌

❌

远程密钥供应

提供完整远程密钥供应服务

❌

✅

✅

应用完整性验收

稳定完成全部应用完整性等级验收

❌

✅

✅

安全单元

提供可用于密钥和交易的安全单元

❌

✅

✅

认证信息集中管理

集中管理设备调试和控制认证信息

❌

✅

✅

表1-7 硬件安全能力

系统镜像、ROM与Root

系统镜像能力覆盖ROM导入、云手机系统制作、镜像维护、Root环境和固件获取，如表1-8所示。

功能

说明

已实现

个人版

企业版

ROM导入

导入主流安卓ROM包、系统镜像和分区目录

✅

✅

✅

ROM转云手机系统

将原厂ROM转换为可运行的云手机系统

✅

✅

✅

多盘运行镜像

将系统、启动和用户数据分开管理

✅

✅

✅

运行镜像打包

创建、拆分、合并和检查运行镜像包

✅

✅

✅

镜像维护

检查、转换、扩容、压缩、修复和回收镜像空间

✅

✅

✅

分区维护

查看、提取、写回和检查系统分区

✅

✅

✅

启动镜像维护

检查、解包、修改和重新封装启动镜像

✅

✅

✅

Root方案

提供KernelSU、Magisk和APatch Root环境

✅

✅

✅

固件获取

查询、下载、续传和缓存已登记固件

✅

✅

✅

表1-8 镜像系统能力

快照与自动控制

实例控制覆盖运行状态保存、设备参数调整、网络控制和电话状态控制，如表1-9所示。

功能

说明

已实现

个人版

企业版

关机快照

创建、加载、删除和查询关机状态快照

✅

✅

✅

运行快照

创建、加载、删除和查询运行中实例快照

✅

✅

✅

快照状态同步

在快照操作中同步系统、磁盘和设备连接状态

✅

✅

✅

设备控制

统一管理设备状态和常用操作

✅

✅

✅

网络控制

控制网络状态、限速、延迟、抓包和端口转发

✅

✅

✅

电话控制

控制短信、来电、接听、保持、拒接、挂断、信号和数据状态

✅

✅

✅

运行控制

控制暂停、恢复、启动、停止、重启、结束和状态查询

✅

✅

✅

表1-9 快照控制能力

平台集成

平台集成用于把单机功能接入浏览器、开发工具和远程管理服务，如表1-10所示。

功能

说明

已实现

个人版

企业版

全量固件查询下载

覆盖全部品牌和系统版本的固件查询与下载

❌

✅

✅

浏览器管理控制台

在浏览器中管理云手机实例

❌

❌

✅

远程控制接口

提供统一的远程设备控制服务

❌

❌

✅

开发工具设备管理

提供设备创建、编辑和图形化管理

❌

❌

✅

表1-10 平台集成能力

真实设备透传

真实设备透传将宿主或外接硬件的现场状态实时提供给云手机，与内置模拟数据分开管理，如表1-11所示。

功能

说明

已实现

个人版

企业版

真实本地Wi-Fi列表透传

将宿主扫描到的本地Wi-Fi列表实时提供给云手机

❌

❌

✅

真实本地Wi-Fi状态透传

将宿主当前Wi-Fi连接和网络切换状态提供给云手机

❌

❌

✅

真实4G模块透传

通过宿主直连4G模块提供真实SIM、运营商、信号、基站和移动数据

❌

❌

✅

真实短信与电话

通过直连4G模块接收和发送短信、接听和拨打电话

❌

❌

✅

真实电话信息透传

提供真实号码、SIM信息、网络注册和通话状态

❌

❌

✅

真实GPS透传

将宿主或外接定位设备的位置、速度、方向、精度和卫星信息实时提供给云手机

❌

❌

✅

表1-11 真实透传能力

可找上面图中二维码联系咨询。

跳转微信打开

]]> Tue, 04 Aug 2026 17:19:00 +0800 安卓最新Root提权漏洞分析与利用 https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485374&idx=1&sn=70e3f7da734cb81e92aedc72e7e58988 原创 非虫 2026-07-30 15:03 湖北

安卓最新Root提权漏洞分析与利用

2026年7月，Linux内核本地提权漏洞GhostLock（CVE-2026-43499）公开完整利用链之后，安卓侧很快出现了面向锁BL机型的公开仓库：JoinChang的ghostlock-oneplus，以及YuKongA面向OPPO Find N5与Find X8的ghostlock-oplus。它们打的不是厂商私有驱动，而是GKI里那条已经存在十余年的futex PI栈UAF。公开仓已有完整实现，下文只谈公开机制与机型差异。

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

安卓本地Root近年常见目标仍是GPU驱动、binder与各类vendor ioctl。GhostLock不一样：缺陷在主线Linux的rtmutex/futex路径，和ColorOS、OxygenOS私有HAL无关。锁着bootloader的OnePlus、OPPO机型之所以能在未解锁状态下拿到root，是因为同一条内核洞被改成了arm64安卓利用链，再接上KernelSU的late-load。

两个仓库的关系如下：

  1. JoinChang/ghostlock-oneplus

    ：面向OnePlus/OPPO/realme等OPlus系锁BL机型的多设备偏移表与完整jailbreak链路，仓库创建于2026年7月12日。

  2. YuKongA/ghostlock-oplus

    ：在同一漏洞与相近代码骨架上，单独补齐OPPO Find N5与Find X8的偏移与构建入口，并显式声明参考了Nebula的CyberMeowfia、JoinChang仓库以及x-spy/CVE-2026-43499-popsicle；仓库创建于2026年7月29日。

漏洞定位与时间线

CVE-2026-43499要点如表1所示。

字段

内容

CVE

CVE-2026-43499，俗称GhostLock

组件

Linux内核kernel/locking/rtmutex.c，经futex优先级继承（PI）路径触发

类型

栈上Use-After-Free，CWE-416

CVSS

kernel.org给出CVSS 3.1：7.8 High，AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

引入

Linux 2.6.39-rc1（约2011年5月），提交8161239a8bcc

修复

主线7.1，提交3bfdc63936dd（rtmutex: Use waiter::task instead of current in remove_waiter）

发现方

Nebula Security（VEGA），Google kernelCTF奖励92337美元

公开分析

Nebula《IonStack part II: GhostLock》，2026年7月7日

安卓侧公开利用

JoinChang、YuKongA等仓库，面向锁BL的OPlus系机型与部分同SoC机型

表1 CVE-2026-43499要点

时间线按公开资料整理如下：

  1. 约2011年：rtmutex PI重写引入错误假设，remove_waiter()始终按current清理waiter。

  2. 2026年4月：主线合入3bfdc63936dd修复。

  3. 2026年5月21日：NVD收录CVE-2026-43499。

  4. 2026年7月7日：Nebula公开完整writeup与通用Linux利用思路；同日前后发行版开始集中发补丁说明。

  5. 2026年7月8日：oss-security出现GhostLock提醒邮件。

  6. 2026年7月12日起：安卓侧锁BL jailbreak仓库陆续公开；YuKongA仓库约两周后补齐Find N5与Find X8。

这里可以看出：

  1. 漏洞本体是通用Linux内核问题，不绑定某一OEM。

  2. 安卓暴露面是开启CONFIG_FUTEX_PI的GKI/OEM内核；JoinChang README写明，安卓GKI 6.12.x在其写作时尚处受影响区间。

  3. 两个GitHub仓库把漏洞利用做成“锁BL拿uid 0并装KernelSU”的工程实现；机型范围由偏移表与栈布局可行性决定，不是CVE影响名单本身。

威胁模型与影响面

对于安卓手机，威胁模型更贴近下面几条：

  1. 攻击者已能在设备上运行本地代码：用户安装的App、调试shell，或其它远程洞拿到的同UID执行能力。

  2. 目标内核仍未合入3bfdc63936dd及其stable回补；内核版本号“看起来很新”不等于已修，要以实际uname -r与厂商OTA为准。

  3. 利用不依赖解锁bootloader，也不要求改写boot分区。公开仓库的目标正是：锁BL状态下拿到root，再靠ksud late-load装上KernelSU。

  4. 成功后常见结果是：写掉selinux_enforcing、把当前进程凭据切到init_cred，或走UMH路径让内核以uid 0执行用户态载荷。

厂商品牌上，公开仓库当前主要覆盖OnePlus、OPPO，以及同SoC验证过的Xiaomi 17。realme等OPlus系机型在JoinChang的“不可行”表里也有条目，说明作者尝试过提取偏移，但栈布局不兼容。不要把“仓库名带了OnePlus”理解成“只有一加受影响”——洞在内核，仓库只是现成适配清单。

缺陷成因

Nebula的分析把成因说得很直白：remove_waiter()最初只服务“线程自己阻塞、自己清理”的慢路径，于是一律操作current。Requeue-PI却通过rt_mutex_start_proxy_lock()让另一个线程代劳入队与回滚。此时current是发起FUTEX_CMP_REQUEUE_PI的requeuer，真正的waiter对象躺在睡眠线程自己的内核栈上。

出错路径可以压缩成：

waiter线程：持有f_pi_chain，再FUTEX_WAIT_REQUEUE_PI(f_wait -> f_pi_target)
owner线程：持有f_pi_target，再阻塞在f_pi_chain
主线程：FUTEX_CMP_REQUEUE_PI(f_wait -> f_pi_target)
  代理入队检测到死锁，返回-EDEADLK
  remove_waiter()清掉current->pi_blocked_on
  waiter任务自己的pi_blocked_on仍指向即将弹出的栈帧
  栈帧回收后形成栈UAF

后续任意一次会走PI链的操作，例如sched_setattr()，都可能顺着悬空指针去解引用已经返回用户态的栈帧。触发后没有紧迫的竞态窗口：waiter可以先回到用户态，攻击者再慢慢安排栈回收与伪造。

修复同样直接：在remove_waiter()及相关路径里，一律用waiter->task取代current去持锁、出队、清空pi_blocked_on。lockdep原先只检查“有没有持有某把pi_lock”，并不核对“持的是不是waiter所属任务的那把”，所以这类错误能藏很久。

从栈UAF到受控写

通用Linux链（Nebula / CyberMeowfia）与安卓仓共享同一起点：悬空的rt_mutex_waiter。后续差异主要在“如何把可控字节铺回那块栈”，以及“把有限写原语接到什么目标上”。

Nebula在x86通用环境里的轮廓是：

  1. 用prefetch一类侧信道摸KASLR与physmap。

  2. 触发GhostLock，留下悬空pi_blocked_on。

  3. 用prctl(PR_SET_MM_MAP)等大块栈本地缓冲覆盖旧waiter帧，伪造rt_mutex_waiter。

  4. PI链上的rb_erase给出受约束的指针写，常见写入目标是inet6_protos[IPPROTO_UDP]一类函数表。

  5. 再接控制流劫持与后续提权。

安卓公开仓把栈回收换成了更贴近手机环境的pselect6路径。JoinChang README写明：pselect6会把fd_set拷到内核栈上的stack_fds；在合适的编译栈布局下，这块缓冲区与已释放的rt_mutex_waiter重叠，攻击者就能把伪造的task、lock等字段写进用户可控区。随后PI链walk时的红黑树再平衡，把受控值写到选定的内核地址。

安卓侧原语链可以写成：

三futex死锁触发GhostLock
  waiter任务悬空pi_blocked_on
  pselect6把可控fd_set铺回同一栈深
  伪造rt_mutex_waiter
  PI写原语（受约束的内核写）
  关闭SELinux enforcing，或改凭据，或建立更稳的读写原语
  可选：ksud late-load安装KernelSU

公开仓给出的两条Root路径，按设备能力自动选择：

  1. UMH路径（优先，需C ashmem且能拿到静态miscdevice偏移）：先用PI写把misc fops拐到伪造表，再经configfs与pipe物理内存读写把selinux_enforcing写成单字节0，最后向system_unbound_wq注入work，让内核执行/data/local/tmp/... --umh拿到uid 0。这条路少改活着的task_struct凭据，也能绕开部分seccomp对perf_event_open的限制。Rust ashmem的GKI 6.12上miscdevice在堆上分配，地址不稳定，通常走不通。

  2. 直接PI写路径（回退）：先写selinux_enforcing，再把task->cred指到init_cred，随后装KernelSU，并视需要处理策略副作用。

还有bootstrap模式：App上下文先做不依赖perf的Write 1，再经本机mini-adb连回自己，在更宽松的shell上下文跑完整链。这是为了躲开App侧seccomp，不是第二条漏洞。

栈布局决定机型能不能打

CVE在很多内核上都在，但公开安卓利用能不能打通，取决于编译器给do_select/pselect栈帧排出来的布局。JoinChang把可行性写成硬规则：在NFDS=320时，stack_fds前半是用户可控位图；rt_mutex_waiter的task与lock字段必须落在可控区。waiter起始word超过3，通常就没有安全的PSELECT_SHIFT可调。

同一内核版本号、不同SoC分支，因为PGO/LTO/BOLT画像不同，栈布局可以完全不一样。所以“同为6.12”不等于都能打；反过来，6.6上只要布局合适、偏移齐备，也能成。YuKongA仓库里的Find N5与Find X8，正是6.6.118安卓15 GKI分支上的成功适配。

另外还有kernel_phys_load：bootloader决定的内核物理装载地址，不能从boot.img直接推出来。写错不会必然panic，写会落到无关RAM上，表现为“跑了没效果”。公开仓要求按机型填表，或在已有root的同型号机器上从/proc/iomem读取。

两个仓库的机型覆盖

两仓支持范围以各自README为准，摘要如表2、表3。状态会随作者更新变化，动手前请再对一下仓库当前表格。

设备

SoC

内核线索

状态

OnePlus Ace 6T（PLR110）

SM8845

6.12.38，多build已列

已验证

OnePlus 15（CPH2749）

SM8850

6.12.23

已验证

Xiaomi 17（pudding）

SM8850

6.12.23

已验证

OnePlus 15T（PLZ110）

SM8845

与Ace 6T同内核线索

偏移已提，待真机确认

OnePlus 13（IN2060）

SM8750

6.6.89，需PSELECT_SHIFT=-2

偏移已提，UMH路径有公开线索

表2 JoinChang/ghostlock-oneplus支持摘要

JoinChang明确标为不可行的例子包括：OPPO Find X9 Ultra（栈SP差与Ace 6T相反）、OPPO Find X7与多款realme 6.1分支（waiter落在word 13）、OnePlus 13R/Ace 5、OPPO Pad 5，以及非OPlus的iQOO Z9（且5.15 waiter结构不兼容）。这些条目说明：洞可能仍在，但当前这条pselect叠栈打法在这些编译产物上走不通。

设备

SoC

内核线索

说明

OPPO Find N5（PHK110）

SM8750

6.6.118-android15-8-...-ab15114928-4k

按uname -r选偏移表

OPPO Find X8（PKB110）

MT6991

6.6.118-android15-8-...-ab15099304-4k

同上；天玑平台单独适配

表3 YuKongA/ghostlock-oplus支持摘要

两仓差异可以概括成：

  1. JoinChang覆盖更广，带可行性筛查、UMH与直接PI写双路径、bootstrap、多SoC的kernel_phys_load表，以及从boot.img批量抽kallsyms/BTF偏移的工具链。

  2. YuKongA收窄到Find N5与Find X8两条已验证内核，启动时读uname -r，不匹配直接拒绝；构建与安装脚本更轻，并写明继承Apache-2.0与上游参考列表。

  3. 两者都把“提权”和“持久Root框架”拆开：没有ksud时，W1/W2仍可能拿到uid 0，但KernelSU不会装上，su也不持久。

检测与缓解

真正有效的修复只有内核补丁。上游关键提交是3bfdc63936dd；各stable分支另有回补，NVD与发行版公告里能看到6.1、6.6、6.12、6.18、7.0等线的修复版本门槛。安卓侧不能只看AOSP安全公告月份，还要看OEM是否把对应GKI/vendor内核推进到已回补版本。JoinChang写作时点名的6.12.23、6.12.38，仍低于当时公开资料里常见的6.12.86一类修复门槛；具体以设备OTA与内核changelog为准。截至成稿，未看到OnePlus/OPPO就该CVE单独发布的中文用户公告可引用，仍应以内核版本与厂商安全更新频道为准。

临时缓解都有代价：

  1. 用seccomp挡住FUTEX_LOCK_PI、FUTEX_WAIT_REQUEUE_PI、FUTEX_CMP_REQUEUE_PI及其time64/变体。能切断触发面，但会弄坏依赖优先级继承互斥量的工作负载。

  2. 限制不可信本地代码执行，收紧侧载与调试接口。对锁BL手机上的恶意App模型，这比“指望用户别点安装”更实在，但挡不住已经拿到代码执行的攻击者。

  3. Nebula还讨论过RANDOMIZE_KSTACK_OFFSET对栈帧重叠的干扰：它会抬高利用难度，不是完整修复。安卓公开仓按机型实测栈布局，说明在目标编译产物上重叠仍可稳定发生。

尽快装厂商内核OTA。补丁到位前，别把来路不明的“一键Root”包当常规工具。两仓已把偏移提取办法公开到“只需boot.img”的程度，适配成本会继续下降，回补越慢，锁BL机型上的现成利用越多。

参考资料

跳转微信打开

]]> Thu, 30 Jul 2026 15:03:00 +0800 安卓GKI内核模块开发编译工具包开发与使用 https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485369&idx=1&sn=0cc7abb85722c7d8533cd09b91355b26 原创 非虫 2026-07-26 20:08 湖北

安卓GKI内核模块开发编译工具包开发与使用

本文介绍dddk（Droid DDK）的设计思路与实现细节，讲解如何在ddk的基础上实现x86_64与ARM64双架构原生编译加速，覆盖Android 13到Android 17全部GKI内核版本，以及通过GitHub Actions一键编译内核模块

作者：非虫

目录

  1. 从ddk到dddk的演进动机

  2. 整体架构与配置设计

  3. 原生编译加速的实现

  4. Android 17支持的关键细节

  5. dddk命令行工具使用

  6. 在GitHub Actions中编译内核模块

  7. 镜像构建流水线

  8. 总结

1 从ddk到dddk的演进动机

做过安卓内核模块开发的人都知道，编译一个.ko需要完整的内核源码树、匹配的工具链和正确的内核构建配置。Ylarod/ddk项目解决了环境搭建的问题，把AOSP Clang工具链和预编译好的内核源码打包到Docker镜像里，开发者拉取镜像后执行make即可得到.ko文件。

但在实际使用中遇到了几个瓶颈。

第一个问题是架构限制。原版ddk只提供x86_64镜像，在ARM64服务器（如GitHub Actions的ubuntu-24.04-arm Runner或云厂商的ARM实例）上需要通过QEMU模拟运行x86_64容器，编译速度慢到无法接受。对于拥有ARM64构建机的团队，硬件资源完全被浪费。

第二个问题是工具链选型。原版直接使用AOSP预编译的Clang工具链，但AOSP Clang仅发布x86_64版本。在ARM64宿主机上，即使容器本身是ARM64的，也无法直接使用AOSP Clang。

第三个问题是版本覆盖。随着Android版本快速迭代，GKI内核从5.10一路演进到6.18。原版ddk支持的目标版本有限，缺少Android 16和Android 17的支持。Android 17引入了6.18内核和Rust 1.91.1工具链，构建环境发生了较大变化。

第四个问题是CI集成。原版缺少开箱即用的GitHub Actions集成方案，项目组想在CI里自动编译内核模块，需要自行编写复杂的工作流。

dddk（Droid DDK）就是在这些需求驱动下的重新实现。核心思路是用Android NDK替代AOSP Clang作为交叉编译工具链，实现x86_64和ARM64宿主机的原生编译支持，同时覆盖从Android 13到Android 17的全部GKI内核版本。

2 整体架构与配置设计

dddk的架构分为四层，如下所示：

+----------------------------------------------------+
|           dddk 命令行工具 (scripts/dddk)             |
|         统一入口, 支持 docker/local 双模式            |
+----------------------------------------------------+
|                 Docker 镜像层                        |
|      builder, toolchain, ddk, ddk-min               |
+----------------------------------------------------+
|               构建系统 (build/)                      |
|      build-droid-ddk.py + mapping.json              |
+----------------------------------------------------+
|             GitHub Actions 工作流                    |
|      release.yml / publish-prebuilts.yml            |
+----------------------------------------------------+

2.1 mapping.json作为构建配置的单一事实源

整个项目的核心配置集中在mapping.json中，它定义了三类信息。

第一类是目标矩阵。每个构建目标由Android版本、Clang版本、Rust版本、NDK版本和支持的宿主平台组成：

{
"android":"android17-6.18",
"clang":"clang-r584948c",
"rust":"rust-1.91.1",
"ndk":"r29",
"platforms":["linux-amd64","linux-arm64"]
}

第二类是平台配置。每个宿主平台的工具链类型、NDK下载地址、Rust安装方式等：

{
"linux-arm64":{
"toolchainKind":"android-ndk",
"ndks":{
"r29":{
"url":"https://github.com/SnowNF/ndk-aarch64-linux/releases/...",
"root":"r29",
"bin":"toolchains/llvm/prebuilt/linux-x86_64/bin"
}
},
"rust":{
"kind":"rustup",
"version":"1.91.1"
}
}
}

第三类是镜像仓库，支持Docker Hub、GHCR和CNB三个镜像源：

{
"registry":{
"droid-ddk":{
"github":"ghcr.io/feicong/droid-ddk",
"docker":"docker.io/fsx199/droid-ddk",
"cnb":"docker.cnb.cool/feicong/droid-ddk/droid-ddk"
}
}
}

所有构建脚本、Dockerfile、CI工作流和dddk命令行工具都从这一个文件读取配置。新增一个内核版本，只需在mapping.json的matrix数组中加一条记录。

2.2 支持的GKI目标版本

dddk当前覆盖9个目标版本，横跨Android 13到Android 17，如表1所示。

dddk目标

ACK源码分支

NDK

Rust

android13-5.15android13-5.15-lts

r25c

无

android14-5.15android14-5.15-lts

r25c

无

android14-6.1android14-6.1-lts

r25c

无

android15-6.1android14-6.1-lts

r25c

无

android15-6.6android15-6.6-lts

r25c

无

android16-6.6android15-6.6-lts

r25c

无

android16-6.12android16-6.12-lts

r29

1.82.0

android17-6.12android16-6.12-lts

r29

1.82.0

android17-6.18android17-6.18-lts

r29

1.91.1

表1 dddk支持的GKI目标版本

其中android15-6.1、android16-6.6和android17-6.12是三个"跨代"目标，用于设备升级了Android大版本但仍使用上一代内核的场景。选择目标时以设备uname -r输出中的ACK代际和内核版本为准。

3 原生编译加速的实现

3.1 用NDK替代AOSP Clang

AOSP预编译的Clang工具链只有x86_64版本。要在ARM64宿主机上原生编译ARM64内核模块，需要一套能在ARM64上运行、输出ARM64目标代码的交叉编译工具链。

Android NDK天然满足这个需求。NDK中的Clang本身就是交叉编译器，支持多种目标架构。Google官方发布的NDK包含x86_64宿主版本，社区项目SnowNF/ndk-aarch64-linux提供了ARM64宿主版本。

dddk的解法是x86_64宿主机使用Google官方NDK，ARM64宿主机使用SnowNF ARM64 NDK。两者的Clang版本、头文件和链接器完全一致，区别仅在于宿主二进制文件的架构。

映射关系在mapping.json的platforms节中定义：

{
"linux-amd64":{
"toolchainKind":"android-ndk",
"ndks":{
"r25c":{
"url":"https://dl.google.com/android/repository/android-ndk-r25c-linux.zip",
"sha256":"769ee342ea75f80619d985c2da990c48b3d8eaf45f48783a2d48870d04b46108"
},
"r29":{
"url":"https://dl.google.com/android/repository/android-ndk-r29-linux.zip",
"sha256":"4abbbcdc842f3d4879206e9695d52709603e52dd68d3c1fff04b3b5e7a308ecf"
}
}
},
"linux-arm64":{
"toolchainKind":"android-ndk",
"ndks":{
"r25c":{
"url":"https://github.com/SnowNF/ndk-aarch64-linux/releases/download/0.0.1/android-ndk-r25c-aarch64-linux.tgz"
},
"r29":{
"url":"https://github.com/SnowNF/ndk-aarch64-linux/releases/download/0.0.2/android-ndk-r29-linux-aarch64.tar.gz"
}
}
}
}

Android 13到15使用NDK r25c，Android 16和17使用NDK r29。

3.2 NDK作为内核编译工具链的适配

NDK虽然自带Clang，但内核构建系统默认按AOSP Clang的目录布局寻找工具。使用NDK需要显式指定每一个工具的路径。dddk通过环境变量完成这个映射：

# dddk脚本中的NDK工具链配置
export CC="$CLANG_PATH/clang"
export LD="$CLANG_PATH/ld.lld"
export AR="$CLANG_PATH/llvm-ar"
export NM="$CLANG_PATH/llvm-nm"
export OBJCOPY="$CLANG_PATH/llvm-objcopy"
export OBJDUMP="$CLANG_PATH/llvm-objdump"
export STRIP="$CLANG_PATH/llvm-strip"
export HOSTCC="$CLANG_PATH/clang"
export HOSTCXX="$CLANG_PATH/clang++"
export CLANG_TRIPLE=aarch64-linux-gnu-
export CROSS_COMPILE=aarch64-linux-gnu-
export ARCH=arm64
export LLVM=1
export LLVM_IAS=1

Docker镜像的Toolchain层（ddk-toolchain/Dockerfile）中，NDK被下载后，其Clang目录通过符号链接统一到/opt/droid-ddk/toolchain/bin：

RUNset -eux; \
    toolchain_bin="/opt/droid-ddk/ndk/${NDK_ROOT}/toolchains/llvm/prebuilt/linux-x86_64/bin"; \
mkdir -p /opt/droid-ddk/toolchain; \
ln -s "$toolchain_bin" /opt/droid-ddk/toolchain/bin

这样上层的DDK镜像和dddk命令行都通过/opt/droid-ddk/toolchain/bin访问工具链，无需关心底层是AOSP Clang还是NDK。

3.3 Ubuntu 26.04构建环境适配

dddk的基础构建镜像（ddk-builder）基于Ubuntu 26.04。这个选择带来了一些兼容性问题需要处理。

第一个问题是libxml2版本冲突。Ubuntu 26.04自带libxml2 2.14，而部分旧版内核的构建脚本依赖libxml2 2.9的API。Builder镜像单独编译了一份libxml2 2.9.14放在/opt/droid-ddk/compat/lib，通过LD_LIBRARY_PATH注入：

RUNset -eux; \
    curl --retry 3 -fsSL "$LIBXML2_COMPAT_URL" -o /tmp/libxml2.tar.xz; \
cd /tmp/libxml2-2.9.14; \
    ./configure --prefix=/opt/droid-ddk/compat \
      --without-python --without-lzma --without-iconv \
      --disable-static; \
    make -j"$(nproc)"; make installENV LD_LIBRARY_PATH=/opt/droid-ddk/compat/lib

第二个问题是宿主编译器兼容性标志。Android 14的6.1内核在新版Clang下会出现incompatible-pointer-types-discards-qualifiers编译错误。dddk为这些目标设置了额外的HOSTCFLAGS：

{
"android":"android14-6.1",
"hostCFlags":"-Wno-error=incompatible-pointer-types-discards-qualifiers -DUSE_PKCS11_ENGINE"
}

这些标志在mapping.json中按目标配置，构建脚本自动读取并传入。

3.4 原生编译与模拟编译的性能对比

原生编译和QEMU模拟编译的性能差距很大。如表2所示，以编译一个典型的内核模块为例。

场景

耗时

x86_64 Runner加x86_64镜像（原生）

约30秒

ARM64 Runner加ARM64镜像（原生）

约30秒

ARM64 Runner加x86_64镜像（QEMU模拟）

5分钟以上

表2 原生编译与模拟编译耗时对比

双架构原生支持让ARM64 Runner不再是二等公民，CI矩阵可以自由选择宿主架构。

4 Android 17支持的关键细节

Android 17带来了两个重要变化，分别是6.18内核分支和Rust内核模块支持的升级。

4.1 新内核分支android17-6.18

Android 17引入了android17-6.18-lts分支，使用最新的Clang clang-r584948c（来自main-kernel-2026分支）和NDK r29。这是截至目前ACK支持的最新内核版本。

4.2 Rust工具链的双平台安装

从Android 16的6.12内核开始，GKI引入了Rust内核模块支持。Android 17进一步将Rust版本从1.82.0升级到1.91.1。

x86_64和ARM64宿主机上的Rust工具链安装方式不同。

x86_64宿主机使用AOSP预编译的Rust工具链，从platform/prebuilts/rust-toolchain/linux-x86仓库下载归档包，与AOSP Clang类似的分发方式：

# build-droid-ddk.py中的Rust预构建下载
url = f"https://android.googlesource.com/{repo}/+archive/refs/heads/{branch}/{archive_path}.tar.gz"

ARM64宿主机因为AOSP不提供ARM64版本的预编译Rust，需要通过rustup在线安装：

# ARM64 Rust安装流程
curl --proto '=https' --tlsv1.2 -fsSL https://sh.rustup.rs | sh -s -- -y --no-modify-path
rustup toolchain install 1.91.1 --profile minimal --component rust-src,rustfmt
cargo +1.91.1 install bindgen-cli --version 0.72.1 --locked

这里有一个不明显但关键的细节，即bindgen与CLANG_PATH的冲突。dddk的CLANG_PATH环境变量指向NDK的Clang目录，但bindgen-cli在检测到CLANG_PATH是一个目录（而非文件路径）时会行为异常。解法是为ARM64创建一个wrapper脚本，在调用bindgen前清除CLANG_PATH：

#!/bin/sh
unset CLANG_PATH
exec /opt/droid-ddk/.cargo/bin/bindgen "$@"

这个wrapper放在/opt/droid-ddk/bin/bindgen，PATH优先级高于cargo安装的原始bindgen。

4.3 CFI整数规范化配置

Android 16和17的6.12内核还需要启用CFI_ICALL_NORMALIZE_INTEGERS配置项，否则CFI（控制流完整性）检查会在模块加载时触发保护。构建脚本中对应的处理如下：

# build-droid-ddk.py中的内核配置
if android_branch in ("android16-6.12", "android17-6.12"):
    run(f"{scripts_config} --file {config_file} -e CFI_ICALL_NORMALIZE_INTEGERS")

需要注意的是，这里使用CFI_ICALL_NORMALIZE_INTEGERS而不是带CONFIG_前缀的完整名，因为scripts/config工具会自动添加前缀。

5 dddk命令行工具使用

dddk是一个独立的Bash脚本，安装后作为统一入口管理所有操作。

5.1 安装dddk

在Linux宿主机上执行以下命令安装：

curl -fsSL https://raw.githubusercontent.com/feicong/droid-ddk/main/host/install.sh | sudo bash

安装脚本将dddk放到/usr/local/bin/dddk。首次运行时会引导选择运行模式（docker或local）和镜像源（docker、github或cnb）。配置保存在~/.droid-ddk/目录下。

5.2 基本工作流

安装完成后，通过以下命令完成首次环境准备：

# 更新dddk脚本和mapping.json
dddk update
# 查看所有可用目标
dddk list-all
# 拉取目标镜像
dddk pull --target android17-6.18
# 查看已拉取的镜像
dddk list

5.3 编译内核模块

模块目录至少需要包含源码文件和一个Kbuild兼容的Makefile：

my-driver/
  my_driver.c
  Makefile

Makefile内容如下：

obj-m += my_driver.o

编译、清理和进入构建环境的命令：

MODULE_DIR="$PWD/my-driver"
TARGET=android17-6.18
dddk build --target "$TARGET" --module "$MODULE_DIR"
dddk build --target "$TARGET" --module "$MODULE_DIR" -- -j8 V=1
dddk clean --target "$TARGET" --module "$MODULE_DIR"
dddk shell --target "$TARGET" --module "$MODULE_DIR"

--module参数将模块目录挂载到镜像内的/build，执行与镜像内核构建目录匹配的标准Kbuild命令。生成的.ko文件直接写入模块目录。

5.4 使用.ddk-version固定目标

在项目根目录创建.ddk-version文件可以省去每次输入--target：

echo android17-6.18 > .ddk-version
dddk pull
dddk build --module "$PWD/my-driver" -- -j8
dddk clean --module "$PWD/my-driver"

目标解析的优先级为：--target命令行参数优先于.ddk-version文件，.ddk-version文件优先于DDK_TARGET环境变量。

5.5 传递环境变量和自定义make参数

# 传递内核配置
dddk build -t android17-6.18 --env CONFIG_FOO=y -e CONFIG_BAR=n
# 传递make参数，双横线之后的参数传给make
dddk build -t android17-6.18 -- CFLAGS=-O2 V=1
# 生成编译数据库，用于clangd代码补全
dddk compdb android17-6.18

5.6 Docker模式与Local模式

dddk支持两种运行模式。

Docker模式是默认模式，通过Docker容器运行编译，无需在宿主机安装任何工具链。镜像包含完整的编译环境。

Local模式直接在宿主机上使用本地安装的工具链编译，适合已经部署好DDK环境的服务器或需要更快编译速度的场景。配置后通过DDK_ROOT环境变量（默认/opt/droid-ddk）定位工具链和内核源码。Local模式下的目录布局如下：

/opt/droid-ddk/
  ndk/              NDK工具链
  rust/             Rust工具链
  src/              内核源码
    android13-5.15/
    android17-6.18/
    ...
  kdir/             内核构建输出
    linux-amd64/
      android17-6.18/
    linux-arm64/
      android17-6.18/

Local模式对CI环境或构建服务器特别有用，避免每次构建都拉取数GB的Docker镜像。

6 在GitHub Actions中编译内核模块

dddk提供了feicong/android-kernel-build-action@v2 Action，用于在GitHub Actions中编译内核模块。

6.1 基本用法

工作流分为两个Job，先上传模块源码为Artifact，再调用Action编译：

name:BuildKernelModule
on:
push:
branches: [main]
workflow_dispatch:
jobs:
upload-module:
runs-on:ubuntu-24.04
steps:
-uses:actions/checkout@v6
-uses:actions/upload-artifact@v7
with:
name:hello-ko
path:path/to/hello-ko
build-module:
needs:upload-module
runs-on:ubuntu-24.04
steps:
-uses:feicong/android-kernel-build-action@v2
with:
tag:android17-6.18
arch:aarch64
module-path:hello-ko
module-name:hello-ko

模块目录需要包含Makefile和同名.c源文件。编译完成后输出Artifact名为Image-TAG-ARCH，其中的模块文件名为TAG_MODULE_NAME.ko。

6.2 多目标矩阵编译

如果需要同时编译多个内核版本的模块，可以使用矩阵策略：

jobs:
upload-module:
runs-on:ubuntu-24.04
steps:
-uses:actions/checkout@v6
-uses:actions/upload-artifact@v7
with:
name:hello-ko
path:drivers/hello-ko
build-module:
needs:upload-module
runs-on:ubuntu-24.04
strategy:
fail-fast:false
matrix:
target:
-android14-6.1
-android15-6.6
-android16-6.12
-android17-6.18
steps:
-uses:feicong/android-kernel-build-action@v2
with:
tag:${{matrix.target}}
arch:aarch64
module-path:hello-ko
module-name:hello-ko

这样一次Push就能自动产出四个内核版本的.ko文件。

6.3 使用ARM64 Runner加速

如果仓库有ARM64 Runner可用，可以利用原生编译避免模拟开销：

build-module:
needs:upload-module
runs-on:ubuntu-24.04-arm
steps:
-uses:feicong/android-kernel-build-action@v2
with:
tag:android17-6.18
arch:aarch64
module-path:hello-ko
module-name:hello-ko

dddk镜像同时发布x86_64和ARM64版本，Action会根据Runner架构自动拉取匹配的镜像。

7 镜像构建流水线

dddk的镜像构建本身也完全自动化。理解这个流水线有助于需要自建私有镜像的场景。

7.1 四层镜像体系

dddk的镜像采用四层结构，如表3所示。

镜像

基础镜像

内容

droid-ddk-builder

Ubuntu 26.04

gcc、make、flex、bison、libelf-dev、libssl-dev等构建依赖

droid-ddk-toolchain

droid-ddk-builder

NDK和Rust工具链，按目标版本分tag

droid-ddk

droid-ddk-toolchain

内核源码加完整kdir，用于高级开发和调试

droid-ddk-min

droid-ddk-toolchain

内核源码加精简kdir，满足绝大多数模块编译需求

表3 dddk镜像层次结构

droid-ddk-builder层与目标版本无关，所有目标共用。droid-ddk-toolchain层每个目标版本有独立的tag，例如droid-ddk-toolchain:android17-6.18。精简镜像droid-ddk-min的内核构建输出仅包含modules_prepare的结果加上补齐的头文件和构建文件，体积显著小于完整镜像。

7.2 预构建产物管理

内核源码和kdir构建输出以.tar.zst归档的形式存储在GitHub Release（tag prebuilts-v1）中。Dockerfile通过--mount=type=bind从prebuilts目录读取归档并解压：

RUN --mount=type=bind,source=prebuilts,target=/mnt/prebuilts,readonly \
set -eux; \
    tar -xf "/mnt/prebuilts/src/src.${ANDROID_VER}.tar.zst" -C /opt/droid-ddk/src; \
    tar -xf "/mnt/prebuilts/kdir/${artifact_platform}/kdir.${ANDROID_VER}.tar.zst" \
        -C "/opt/droid-ddk/kdir/${artifact_platform}"

publish-prebuilts.yml工作流负责在ARM64和x86_64 Runner上分别编译内核并打包上传归档。release.yml工作流则从归档构建最终的Docker镜像。整个流程为：先发布预构建产物，然后构建builder镜像，接着在两个平台上并行构建toolchain镜像并合并manifest，最后在两个平台上并行构建ddk和ddk-min镜像并合并manifest。

每个目标版本的镜像都发布为多架构manifest，docker pull时自动选择匹配的架构。镜像同时推送到Docker Hub（docker.io/fsx199/droid-ddk）和GHCR（ghcr.io/feicong/droid-ddk）。

7.3 本地构建镜像

如果需要修改基础环境或添加自定义依赖，可以在本地构建：

# 构建builder镜像
make -C docker builder
# 构建特定目标的toolchain镜像
make -C docker toolchains VER=android17-6.18
# 构建DDK镜像，需要先准备prebuilts
make -C docker build VER=android17-6.18
# 构建精简镜像
make -C docker build-min VER=android17-6.18

8 总结

dddk在原版ddk的基础上解决了三个核心问题。

第一是原生编译加速。用Android NDK替代AOSP Clang，实现x86_64和ARM64双架构原生编译，消除QEMU模拟带来的数倍性能损失。

第二是Android 17全版本覆盖。从Android 13的5.15内核到Android 17的6.18内核，覆盖9个GKI目标版本，包括Rust内核模块编译支持。

第三是CI开箱即用。提供feicong/android-kernel-build-action@v2 Action和完整的镜像构建流水线，一段YAML即可在GitHub Actions中编译内核模块。

项目地址：https://github.com/feicong/droid-ddk

安装命令：

curl -fsSL https://raw.githubusercontent.com/feicong/droid-ddk/main/host/install.sh | sudo bash

跳转微信打开

]]> Sun, 26 Jul 2026 20:08:00 +0800 我有一机，可破万检！它叫多多云机，简称多云 https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485364&idx=1&sn=f53b2f0bbd5c09b9c67c5dbdd7214594 多多完美云机的实现方案为更通用的跨平台实现方案 原创 非虫 2026-07-18 15:09 湖北

多多完美云机的实现方案为更通用的跨平台实现方案。不采用任何国内已知的如Cuttlefish/AVD/Redroid/LXC/Waydroid等方案来实现。

目前完美云机课程早鸟半价优惠活动，截至到本月25日结束。有兴趣的朋友要快来了！

本云机的目标是为安全逆向分析与木鱼沙箱动态分析提供后端技术赋能。不参与任何黑灰产业务，找我买成品镜像的请绕道！

声明：以下演示为多多云机真实效果，无任何功能作假与不良引导，更无任何黑灰产业功能暗示。

目前完美云机课程早鸟半价优惠活动，截至到本月25日结束。有兴趣的朋友要快来了！

云机购课咨询加WX：feicongcn

跳转微信打开

]]> Sat, 18 Jul 2026 15:09:00 +0800 来了！你要的安卓完美云手机方案 https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485290&idx=1&sn=0c8ca70d2b65f48d62f2d07a90b058ae 一款个人认为目前最完美的安卓云手机方案。 原创 非虫 2026-07-14 11:42 湖北

一款个人认为目前最完美的安卓云手机方案。

这是一款个人认为目前最完美的安卓云手机方案。因为它：

  • 解决了安装部署挑硬件问题，支持全系列ARM64的开发板与电脑

  • 支持macOS/Linux平台，甚至一些Win平台也可以

  • 支持本地部署云部署与Docker容器化

  • 支持GPU图形加速

  • 支持多个安卓最新全版本系统

  • 支持全球几乎所有安卓安卓机型定制

  • 支持实例多开与App多开

  • 完美机型可登Play商店与过环境检测

  • 只要硬件IO允许无任何多开限制

运行要求

  • 启动内存不能低于4096MB，宿主可探测物理内存低于4GB时直接失败。

  • 系统可用空间不能低于50GB。

云机效果

课程云机会支持全球多款机型。动图演示为云机型号Pixel6的安卓15版本。

感受GPU加速，无卡顿（动画无加速）

cpu-z检测处理器

Hunter环境检测全绿

Duck Detector环境检测全绿

Play商店登际

课程对比

提供镜像机型

基础版本提供8台课程云机镜像：

机型Android版本说明
Pixel 615 / 16 / 17官方Pixel factory image定制
Pixel 915 / 16 / 17官方Pixel factory image定制
Samsung S25 Ultra16三星机型定制
xxx16xxx机型定制

高级版与企业版在基础版本8台云机基础上，额外提供以下镜像：

机型Android版本说明
Pixel 6 Pro16官方Pixel factory image定制
Pixel 716官方Pixel factory image定制
Pixel 815 / 16 / 17官方Pixel factory image定制
xxx16xxx机型定制
xxx16xxx机型定制
xxx16xxx机型定制

视频课程中讲解的某米、某加、OPPO等国产机型会讲完整创建思路和关键实现，但不提供现成镜像，需要学员按课程流程自行创建。

以下是不同版本提供的内容。

对比项个人版高级版企业版备注
课程播放视频✅✅✅全套视频3年播放
云机管理程序✅✅✅云机cdh补丁创建启动云机
云机踩坑文档✅✅✅云机踩坑配置文档包含核心日志
云机配置代码✅✅✅课程相关云机机型配置代码
云机桥接代码✅✅✅云机fishbridge控制管理代码
安卓15云机✅✅✅定制好的多款安卓15云机
安卓16云机✅✅✅定制好的多款安卓16云机
安卓17云机✅✅✅定制好的多款安卓17云机
8台基础课程云机✅✅✅Pixel6 15/16/17、Pixel9 15/16/17、S25Ultra 16、NothingPhone4a 16
高级扩展云机❌✅✅Pixel6Pro 16、Pixel7 16、Pixel8 15/16/17、NothingPhone3a/2a/3 16
云机永久使用✅✅✅定制好的云机本地或云端无任何限制使用
半年程序更新✅✅✅云机管理程序更新，课程全阶段结束时算起
云机管理源码✅✅✅相关配套代码课程结束时发布，不提供更新
项目SKILLS✅✅✅所有SKILL除核心两个
全套云机代码❌✅✅课程外其它机型配套代码
云机踩坑日志❌✅✅定制踩坑记录日志与截图
核心SKILLS❌✅✅可以创建全新机型的SKILL
全套项目内容❌✅✅项目所有代码文档日志脚本以zip打包
项目提交更新❌❌✅项目Git仓库直接拉人，以年为单位提供维护更新
多套国产云机❌❌❌视频讲解完整创建流程，不提供定制好的镜像，需要自行创建

  • 课程个人版相关程序与代码在课程全阶段结束时提供一份更新完整版本打包发布，不提供代码文档后续更新。

  • 课程高级版包含课程内与课程外全部本项目的代码文档与日志打包发布，不提供代码文档后续更新。

  • 企业版本包含课程高级版全部内容，并提供一年代码与文档维护更新，维护时间从本系列全部课程结束购买企业版服务时间算起。

FAQ

问：本方案是基于redroid还是lxc还是AVD还是CVD？

答：这些方案都不是，本课程采用另一种全新更完美的技术方案。

问：课程中讲的方案支持哪些安卓设备定制？

答：理论现有的安卓设备都支持。

问：你这个云机与其它XX相比如何？

答：本项目的目标是星辰大海，不对标任何其它云手机项目。

问：有些风控会检测安卓系统的全部文件时间戳与哈希，你这个云手机可以过这些检测？

答：有方法。课程会讲解方案，以及会提供项目代码。

问：课程中会讲解哪些安卓型号的定制？

答：官方Pixel与国产某米某加与三星等主流机型。

问：课程的云手机是否支持XX的风控过检测？

答：课程不提供任何过风控的答疑。也不做任何过目标检测的服务。虽然云机很强，但风控是一个安全体系。不只是设备端一个点的检测。我能保证的是尽可能让云机帖近真实安卓手机效果。

问：小白可以学习这个课程吗？

答：小白不适合。云机系统定制需要有一定的开发与逆向工程基础。在学习全系列课程内容前，最少需要先看安卓系统定制与安卓安全开发与逆向分析全套课程。

问：学这个课程能获得什么？

答：可以得到：

全套云手机无保留实现思路以及方案的特点实现方式与多开部署方法。
节省时间Token与少踩坑，节省时间。课程中会把所有的踩坑记录与学员全部分享。
多款已经实现好的云手机镜镜直接无限制使用。
多款云手机特点与Bug处理方法与定制全过程。
全部云手机过程的profile文档与核心知识点的代码。
云手机管理器与镜像长达半年功能新增与Bug修正支持。

问：学这个课程不能获得什么？

答：以下场景：

支持国产系统自主研发，虽然讲解了国产某些型号的全部过程，但由于我国法律法规，不直接提供部分国产定制好的镜像。国产云机镜像产物，学员在学习完本系列课程后可完全自主100%定制实现。
不提供任何华为设备的云手机化。虽然本课程方案支持。
不提供全部（课程中讲的会全部提供）的云手机项目的代码与文档。完整项目的文档代码与更新服务可另外商定。
不提供过脸部验证、视频通话、语音通话、GPS定位等高风险功能支持。本项目云手机如果引入这些功能，也不会是主要的卖点。如果学员有这方面需求，可以在课程方案基础上自行定制（方案原理上完全支持），或者寻求其它方案。
不提供云手机定制服务。学员提出的需求如果是云手机自身功能限制需求，可考虑完善后提供给学员二进制使用。

问：每节课程多少时间？

答：视频信息密度高，每集内容30分钟左右。

问：是否可以试用一下课程的云手机，看皇不是想要的，再决定是否购买课程？

答：在看了上面的介绍后，无法确定是否对你有用的话，那通常就不太适合你了。

问：课程中的方案是否可以开源或商业化？

答：不支持对本项目的方案进行开源。但支持你对方案的商业化，但不包括课程或视频录制。具体情况，每个学员会签署相关的电子保密协议。

问：全套课程与云机的售价是多少？

答：提供30小节共三季的视频课程，以及全套课程相关的项目代码与镜像。价格方面目前开更早鸟半价。但由于课程内容质量与商业价值，价格还是会破万的。课程在本月25日正式开始更新。更新频率与我其它课程更新频率一样。

问：最后问一下怎么购买？

答：联系购买加微信： feicongcn

跳转微信打开

]]> Tue, 14 Jul 2026 11:42:00 +0800 最新Linux的本地提权漏洞分析 https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485280&idx=1&sn=1fcdc3c1ef0b8299952a470ef99300d9 最新Linux的本地提权漏洞分析 原创 非虫 2026-06-27 13:04 湖北

最新Linux的本地提权漏洞分析

2026年6月25日，JFrog Security Research公开了DirtyClone（CVE-2026-43503）。它不是一个全新的内核原语，而是DirtyFrag修复链上的回归绕过：__pskb_copy_fclone()在克隆skb时丢掉了SKBFL_SHARED_FRAG，于是esp_input()把一张仍然挂着文件页缓存的页误判成普通网络缓冲区，最后在原地解密时把数据写回了页缓存。

从NVD的变更记录看，这也不是单点失误，而是一组frag-transfer helper在转移frag描述符时都可能把共享标记弄丢；DirtyClone公开利用的是其中最直接的__pskb_copy_fclone()克隆路径。

文件页缓存
  -> TEE/dup to local克隆
  -> `__pskb_copy_fclone()`
  -> `SKBFL_SHARED_FRAG`丢失
  -> `esp_input()`
  -> 原地decrypt
  -> 页缓存被改写

1 漏洞成因

DirtyFrag原本已经补过一次：只要skb带着外部共享页，esp_input()就应该先走skb_cow_data()，再做解密。DirtyClone的问题在于，__pskb_copy_fclone()先复制frag描述符，再把剩余的shinfo交给skb_copy_header()，但后者只处理gso相关字段，不会把skb_shinfo()->flags里的SKBFL_SHARED_FRAG带过去。结果是，页还在，标记没了，skb_has_shared_frag()就会返回false。

再往下看，问题就变成了典型的“看起来不共享，实际上还共享”。esp_input()依据错误的标记跳过COW，后续的IPsec原地解密直接落在页缓存页上。磁盘文件本身没有被改，改动只停在内存里的page cache里，所以文件完整性监控和重启后的磁盘校验都看不见这个状态。

2 利用链

DirtyClone的PoC没有重新发明写原语，而是把DirtyFrag里已经验证过的seq_hi控字节技巧接了回来。大致流程是：

只读打开`/usr/bin/su`
  -> 把目标页塞进ESP包
  -> 用`TEE`或等价的`nft dup to local`在内核里复制该包
  -> 复制后的`skb`丢标记
  -> `esp_input()`原地写回
  -> 反复48次，覆盖`su`前192字节
  -> 执行被污染的`su`得到root

这里真正可控的是每个4字节word。PoC通过XFRM状态里的seq_hi携带目标word，再配合AES-CBC的IV和封装方式，让解密结果写成想要的字节。目标文件通常选/usr/bin/su，因为只要把它的前192字节换成一个极小的setuid(0)+execve("/bin/sh")ELF，下一次执行时就能拿到root。

PoC里用的是TEE，本质上只要能走到nf_dup_ipv4()并触发__pskb_copy_fclone()，思路就成立。

3 Ubuntu24.04上的现实约束

Ubuntu24.04和更高版本默认启用了AppArmor对非特权user namespace的限制。也就是说，标准的unshare(CLONE_NEWUSER|CLONE_NEWNET)起手式不再像Debian、Fedora那样顺手，PoC想拿到CAP_NET_ADMIN会被默认策略卡住。JFrog公开的代码也明确提到，在Ubuntu上需要放开kernel.apparmor_restrict_unprivileged_userns，或者让目标进程落在允许userns的AppArmor配置里。

所以，Ubuntu24.04不是“没有这个洞”，而是默认把最常见的利用起点收紧了。对普通本地用户来说，它更像是把标准打法从“开箱即用”变成了“还得先过一层系统策略”。

4 补丁与缓解

主线修复在2026年5月21日合入，首个修复标签是v7.1-rc5。真正稳妥的处理只有升级内核，并确认发行版回补链路完整。临时缓解只能缩小面：保留Ubuntu的userns限制，尽量别让普通用户获得CAP_NET_ADMIN，同时避免xt_TEE、esp4、esp6这类触发面自动加载。

参考资料

跳转微信打开

]]> Sat, 27 Jun 2026 13:04:00 +0800 618活动！公众号粉丝课程半价福利，错过再等一年！ https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485275&idx=1&sn=a0bb00c5be4de8c5c3a47f0013ead5a3 618活动！公众号粉丝课程半价福利，错过再等一年！ 非虫 2026-06-18 08:23 湖北

618活动！公众号粉丝课程半价福利，错过再等一年！

一年一度的618来了！

618今天公众号粉丝福利：

安卓软件开发与逆向分析全四阶段课程8折，送隐私探针课一套与软件安全知识星球一年，相当于半价！

eBPF安全攻防课程全六季课程5折。

Frida源码分析课程全三季课程5折。

安卓系统ROM云手机开发定制全三季课程5折。

安卓隐私探针全三季课程5折。

跳转微信打开

]]> Thu, 18 Jun 2026 08:23:00 +0800 618倒计时！公众号粉丝课程半价福利，错过再等一年！ https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485259&idx=1&sn=0239ffca806016a1894dfaf983a56d2f 618倒计时！课程半价福利 非虫 2026-06-16 20:24 湖北

618倒计时！课程半价福利

一年一度的618来了！

618当天公众号粉丝福利：

安卓软件开发与逆向分析全四阶段课程8折，送隐私探针课一套与软件安全知识星球一年，相当于半价！

eBPF安全攻防课程全六季课程5折。

Frida源码分析课程全三季课程5折。

安卓系统ROM云手机开发定制全三季课程5折。

安卓隐私探针全三季课程5折。

跳转微信打开

]]> Tue, 16 Jun 2026 20:24:00 +0800 Frida17.12.0的功能与变化 https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485254&idx=1&sn=32ca95e377824e9841fd305f7a77e2aa Frida17.12.0发布于2026年6月10日 原创 非虫 2026-06-12 16:14 湖北

Frida17.12.0发布于2026年6月10日。官方发布说明列出的更新集中在四个方向：Gum/GumJS新增代码形状分析接口，Linux注入器调整触发点选择和agent装载路径，Interceptor增加细粒度刷新接口，Windows arm64相关的Stalker和Exceptor修复。

更新范围

17.12.0对应的主要提交如下。

子仓库

提交

更新内容

frida-gum67a1b9c

新增gum_process_find_function_range()

frida-gum5e2fd31

新增GumControlFlowGraph模块

frida-gumb3273ea

在GumJS暴露Process.findFunctionRange()和ControlFlowGraph

frida-gumf04c3e3

调整控制流图公开命名，例如findBlockContaining()和capacity

frida-gum779f9b0

新增gum_interceptor_flush_function()和gum_interceptor_flush_listener()

frida-corea0a8838

eBPF采样不可用时回退到/proc/<pid>/task/<tid>/syscall

frida-core33e5879

按实际bootstrap stub大小筛选触发函数

frida-core880f7ac

采样线程栈，寻找可容纳注入stub的libc调用点

frida-coref0cc3b4

安装和恢复触发点时使用对称写回流程

frida-coref51327f

agent通过/proc/<pid>/fd/<fd>路径装载

frida-core21dc508

捕获libbpf诊断日志并写入错误信息

这些提交覆盖了两个层面。frida-gum侧增加公开API和GumJS绑定，主要供脚本和嵌入式使用；frida-core侧调整Linux注入实现，主要影响frida-server、attach和注入稳定性。

函数范围定位

frida-gum提交67a1b9c新增gum_process_find_function_range()，用于根据函数内部地址查找该地址所在函数的连续代码范围。

头文件中的声明如下：

GUM_API gboolean gum_process_find_function_range(gconstpointer address,
    GumMemoryRange * range);

该接口不要求目标二进制保留符号。实现侧会优先读取平台的unwind信息：POSIX平台通过_Unwind_Find_FDE并解析FDE编码，Windows平台通过RtlLookupFunctionEntry查询运行时函数表。若unwind信息不可用，则退回到符号边界查询。

GumJS侧对应接口是Process.findFunctionRange()。它接收一个NativePointer，返回{ base, size }形式的内存范围；如果无法定位函数范围，则返回null。

官方测试中的调用方式如下：

const f = ptr.strip();
const range = Process.findFunctionRange(f);
send(range !== null);
send(range.base.compare(f) <= 0 &&
    f.compare(range.base.add(range.size)) < 0);

在实际脚本中，ptr可以替换为某个导出函数地址、符号地址，或者任意落在目标函数内部的指令地址。例如：

const openPtr = Module.getGlobalExportByName('open');
const range = Process.findFunctionRange(openPtr);
if (range !== null) {
console.log('base=' + range.base + ', size=' + range.size);
}

该接口可用于确定函数边界、检查某个Hook点是否位于同一函数内，或者在指令重定位前获取可分析范围。

控制流图接口

frida-gum提交5e2fd31新增GumControlFlowGraph。该模块基于Capstone反汇编函数代码，构建基本块、前驱、后继和支配关系。提交说明中提到，它使用resolver定位函数范围，并通过直接分支发现多段函数，例如热路径和冷路径分离的函数片段。

公开头文件中的主要接口如下：

typedefgboolean(* GumControlFlowGraphFindRangeFunc)(gconstpointer address,
    GumMemoryRange * range, gpointer user_data);
typedefgboolean(* GumFoundDominatingSiteFunc)(gconstpointer site,
    gsize capacity, gpointer user_data);
GUM_API GumControlFlowGraph * gum_control_flow_graph_new(gconstpointer entry,
    cs_arch arch, cs_mode mode, GumControlFlowGraphFindRangeFunc find_range,
    gpointer user_data);
GUM_API GumControlFlowGraph * gum_control_flow_graph_new_for_function(
    gconstpointer entry_point);
GUM_API gboolean gum_control_flow_graph_dominates(GumControlFlowGraph * self,
    gconstpointer a, gconstpointer b);
GUM_API voidgum_control_flow_graph_enumerate_dominating_sites(
    GumControlFlowGraph * self, gconstpointer target,
    GumFoundDominatingSiteFunc func, gpointer user_data);

其中gum_control_flow_graph_dominates()用于判断地址a是否支配地址b。gum_control_flow_graph_enumerate_dominating_sites()会枚举支配目标地址的可写入位置，并给出capacity，表示从该位置开始、不会被其它控制流边落入的连续字节数。

测试用例中构造了一个类似start_thread的短函数，用来验证支配关系和可写入位置。

TESTCASE (single_range_dominators_and_sites)
{
staticconst guint8 code[] = {
0x48, 0x85, 0xc0, 0x74, 0x04, 0xff, 0xd0, 0xeb, 0x03, 0xff, 0xd0, 0x90,
0xc3,
  };
  GumTestCode layout = { code, sizeof (code), NULL, 0 };
  GumControlFlowGraph * cfg;
  GumCollectedSites sites = { { NULL, }, };
  cs_arch_register_x86 ();
  cfg = gum_control_flow_graph_new (code, CS_ARCH_X86, CS_MODE_64,
      gum_test_find_range, &layout);
  g_assert_true (
      gum_control_flow_graph_dominates (cfg, code + 0x00, code + 0x09));
  g_assert_true (
      gum_control_flow_graph_dominates (cfg, code + 0x03, code + 0x09));
  g_assert_false (
      gum_control_flow_graph_dominates (cfg, code + 0x05, code + 0x09));
  gum_control_flow_graph_enumerate_dominating_sites (cfg, code + 0x09,
      gum_test_collect_site, &sites);
}

这段测试说明了接口的判定语义：只有位于所有到达目标路径上的指令才算支配目标；被条件分支绕过的指令不会被当作支配点。

GumJS控制流图用法

frida-gum提交b3273ea把控制流图接口暴露到GumJS。17.12.0最终公开的JS对象包括ControlFlowGraph和BasicBlock。

官方测试中的调用方式如下：

const cfg = newControlFlowGraph(ptr);
const entry = cfg.entryBlock;
send(entry !== null);
send(cfg.blocks.length > 0);
send(cfg.findBlockContaining(entry.start).start.equals(entry.start));
send(cfg.dominates(entry.start, entry.start));
const insns = entry.instructions;
send(insns.length > 0);
send(insns[0].address.equals(entry.start));
send(Array.isArray(entry.successors));
send(Array.isArray(entry.predecessors));
const sites = cfg.enumerateDominatingSites(entry.start);
send(sites.length > 0);
send(sites[0].address.equals(entry.start));
send(typeof sites[0].capacity === 'number');

实际使用时，可以先取一个函数地址，再构建控制流图：

const target = Module.getGlobalExportByName('pthread_create');
const cfg = newControlFlowGraph(target);
console.log('block count=' + cfg.blocks.length);
for (const site of cfg.enumerateDominatingSites(target)) {
console.log('site=' + site.address + ', capacity=' + site.capacity);
}

如果脚本需要检查某个地址属于哪个基本块，可以使用findBlockContaining()：

const block = cfg.findBlockContaining(target);
if (block !== null) {
console.log('block start=' + block.start);
console.log('block end=' + block.end);
console.log('instruction count=' + block.instructions.length);
}

这组接口可用于Hook点筛选、函数内控制流查看、基本块粒度分析等场景。

C层控制流图用法

嵌入Gum或开发原生组件时，可直接使用C接口。

static gboolean
on_site(gconstpointer site, gsize capacity, gpointer user_data)
{
  g_print ("site=%p capacity=%zu\n", site, capacity);
return TRUE;
}
void
inspect_target(gconstpointer target)
{
  GumControlFlowGraph * cfg;
  cfg = gum_control_flow_graph_new_for_function (target);
  gum_control_flow_graph_enumerate_dominating_sites (cfg, target, on_site, NULL);
  gum_control_flow_graph_free (cfg);
}

如果只查询函数范围，可直接使用gum_process_find_function_range()：

GumMemoryRange range;
if (gum_process_find_function_range (target, &range))
{
  g_print ("function range: %p - %p\n",
      (void *) range.base_address,
      (void *) (range.base_address + range.size));
}

Linux注入器触发点采样

17.12.0中，frida-core对Linux的proc-mem注入链路做了多处修改。相关代码位于src/linux/proc-mem-injector.vala。

提交a0a8838增加了采样回退逻辑。优先使用ActivitySampler采样；如果eBPF或perf因为权限限制不可用，则读取/proc/<pid>/task/<tid>/syscall。

privateasyncuint64 discover_trigger (ProcMapsSnapshot maps, RegionLayout region, StackRendezvous rendezvous,
uint64 mmap_impl, uint64 exclude, Cancellable? cancellable) throws Error, IOError {
Gee.List<SampledStack> stacks;
var sampler = new ActivitySampler (pid);
try {
    sampler.start ();
    yield sleep_ms (SAMPLE_WINDOW_MS);
    sampler.stop ();
    stacks = sampler.stacks;
  } catch (Error e) {
    stacks = yield sample_threads_via_proc (maps, cancellable);
  }
return hottest_libc_function (maps, region, rendezvous, mmap_impl, stacks, exclude);
}

提交880f7ac扩展/proc路径的采样内容。修改前只读取线程当前PC；修改后还会读取栈指针附近的若干栈字，形成候选调用帧。

privateuint64[] read_thread_frames (ProcMapsSnapshot maps, uint tid) throws Error {
string contents;
try {
    FileUtils.get_contents ("/proc/%u/task/%u/syscall".printf (pid, tid), out contents);
  } catch (FileError e) {
return {};
  }
string[] fields = contents.strip ().split (" ");
if (fields.length < 2)
return {};
uint64 pc;
if (!uint64.try_parse (fields[fields.length - 1], out pc, null, 0) || pc == 0)
return {};
uint64 sp;
var stack = (uint64.try_parse (fields[fields.length - 2], out sp, null, 0) && sp != 0)
    ? maps.find_mapping (sp)
    : null;
if (stack == null)
returnnewuint64[] { pc };
uint depth = uint.min (STACK_SCAN_DEPTH, (uint) ((stack.end - sp) / 8));
var frames = newuint64[1 + depth];
  frames[0] = pc;
for (uint i = 0; i != depth; i++)
    frames[1 + i] = mem.read_pointer (sp + (uint64) i * 8);
return frames;
}

这段逻辑用于处理多线程目标中的一种情况：线程可能停在很短的syscall wrapper里，当前PC所在函数空间不足以写入bootstrap stub。读取栈上的返回地址后，注入器可在调用链中查找可容纳stub的libc函数作为触发点。

提交33e5879调整了触发函数大小判定方式。修改前使用固定最小长度；修改后先构造实际要写入的stub，再用实际长度筛选候选函数。

privateuint64 trigger_stub_footprint (uint64 sample_target, RegionLayout region, StackRendezvous rendezvous,
uint64 mmap_impl) throws Error {
uint8[] stub = build_trigger_stub (sample_target, rendezvous.cas, mmap_impl, 0, region.total,
    region.entry_offset);
return BOOTSTRAP_OFFSET + stub.length;
}

触发点写入与恢复

提交f0cc3b4调整了触发函数恢复过程。恢复时先让调用者停在触发点入口，再写回stub覆盖区域，最后恢复函数前导指令。

privateasyncvoid restore_trigger (uint64 target, uint8[] original) throws Error, IOError {
  block_callers (target);
  yield sleep_ms (DRAIN_MS);
  mem.write_memory (target + BOOTSTRAP_OFFSET, original[BOOTSTRAP_OFFSET:original.length]);
  restore_prologue (target, original);
}

对应的安装流程也先调用block_callers()，等待短时间后再写入bootstrap。

privateasyncvoid install_bootstrap (uint64 target, uint8[] stub) throws Error, IOError {
  block_callers (target);
  yield sleep_ms (DRAIN_MS);
  mem.write_memory (target + BOOTSTRAP_OFFSET, stub);
  release_callers (target);
}

该修改针对的是多线程进程中触发函数正在被其它线程执行的情况，避免恢复过程中出现半写入的函数前导区域。

Agent装载路径

提交f51327f修改了Linux loader中agent的dlopen()路径。旧路径使用/proc/self/fd/<fd>，新路径改为/proc/<pid>/fd/<fd>。

补丁中的核心代码如下：

staticpid_t
frida_getpid(void)
{
return frida_syscall_0 (SYS_getpid);
}
libc->sprintf (agent_path, "/proc/%d/fd/%d", frida_getpid (), agent_codefd);
ctx->agent_handle = libc->dlopen (agent_path, libc->dlopen_flags, pretend_caller_addr);
if (ctx->agent_handle == NULL)
goto dlopen_failed;

提交说明指出，附加调试器会在动态链接器的库加载事件中读取dlopen()传入的路径。若路径是/proc/self/fd/<fd>，调试器侧解析到的是调试器自己的fd表，而不是目标进程的fd表，可能导致读取失败并让加载线程停在动态链接器断点处。改成/proc/<pid>/fd/<fd>后，目标进程内部和外部观察者解析到同一个对象路径。

libbpf诊断信息

提交21dc508修改了libbpf错误日志处理方式。此前libbpf诊断信息可能直接输出到stderr，这次改为捕获日志并写入抛出的错误信息中。

该修改主要影响失败场景的可观测性。eBPF加载失败时，调用方可从异常消息中看到verifier或权限相关信息，而不是只能依赖外部标准错误输出。

Interceptor刷新接口

提交779f9b0给GumInterceptor新增两个刷新接口。

GUM_API gboolean gum_interceptor_flush_function(GumInterceptor * self,
    gconstpointer function_address);
GUM_API gboolean gum_interceptor_flush_listener(GumInterceptor * self,
    GumInvocationListener * listener);

gum_interceptor_flush()是全局刷新；新增的两个接口分别按函数地址和监听器刷新。源码中的实现会检查当前transaction状态和待销毁任务，只在指定函数或指定listener相关任务仍未完成时返回FALSE。

最小调用方式如下：

if (!gum_interceptor_flush_function (interceptor, target))
  g_print ("target still busy\n");
if (!gum_interceptor_flush_listener (interceptor, listener))
  g_print ("listener still busy\n");

该接口可供原生Gum使用者在卸载单个Hook或释放某个listener前确认相关调用已结束。

Windows arm64修复

17.12.0还包含多项Windows arm64相关修复。发布说明中列出的主要内容包括：

  1. stalker-arm64

    修复远距离backpatch epilog丢失BL的问题。

  2. stalker

    在Windows上检测线程退出，避免继续跟踪进入ntdll线程清理路径。

  3. exceptor

    在Windows arm64上改用RtlRestoreContext()恢复上下文，避免longjmp()处理合成栈帧时终止进程。

  4. CI增加Windows arm64原生任务。

这些修改集中在稳定性修复，不涉及新的脚本API。

公共API文档

17.12.0还补充了Gum和Core的公开API文档。发布说明中列出的Gum文档对象包括Interceptor、Stalker、Exceptor、Module、ModuleMap、ModuleRegistry、MemoryMap、MemoryAccessMonitor和DarwinGrafter。frida-core侧也新增了Vala文档注释注入GIR的相关提交。

这部分更新主要影响文档生成、GObject introspection数据和下游绑定维护。

总结

Frida17.12.0的更新包括以下几类：

  1. Gum新增函数范围定位和控制流图接口，GumJS增加对应的Process.findFunctionRange()和ControlFlowGraph。

  2. Linux注入器调整触发点采样、触发函数大小判断、触发点恢复和agent装载路径。

  3. Interceptor增加按函数和按listener刷新的接口。

  4. Windows arm64相关的Stalker、Exceptor和CI配置得到修复和补充。

  5. Gum和Core补充公开API文档和GObject introspection发布流程。

对脚本使用者来说，直接可用的新接口是Process.findFunctionRange()和ControlFlowGraph。对嵌入Gum或维护Frida集成的人来说，相关接口包括gum_process_find_function_range()、gum_control_flow_graph_*()和新的Interceptor刷新接口。Linux注入器相关修改属于内部实现调整，主要体现在attach和注入失败场景的行为变化。

参考

  1. Frida新闻页：https://frida.re/news/

  2. Frida17.12.0发布页：https://frida.re/news/2026/06/10/frida-17-12-0-released/

  3. frida-gum

    提交67a1b9c、5e2fd31、b3273ea、f04c3e3、779f9b0

  4. frida-core

    提交a0a8838、33e5879、880f7ac、f0cc3b4、f51327f、21dc508

跳转微信打开

]]> Fri, 12 Jun 2026 16:14:00 +0800 gbl_root_canoe隐藏BL状态原理分析 https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485248&idx=1&sn=e754a3facd703701ea34858afd6e024d gbl_root_canoe隐藏BL状态原理分析 原创 非虫 2026-06-11 18:31 湖北

gbl_root_canoe隐藏BL状态原理分析

高通骁龙8Gen5（内部代号 Sun/Canoe）平台的Android设备获取Root权限需要先解锁Bootloader（BL）。解锁BL后，TEE（Trusted Execution Environment）会将设备永久标记为不可信状态，导致银行类应用、支付应用及完整性检测机制（SafetyNet/Play Integrity）识别到设备已解锁而拒绝运行。

gbl_root_canoe实现BL解锁与TEE状态隐藏、在获得Root权限的前提下，利用GBL（Generic Bootloader）加载机制中的一个行为漏洞，将经过精准二进制修补的ABL（Android Bootloader，即高通UEFI启动应用）注入efisp分区，使设备在启动链的早期就切换到「假回锁」状态，让TEE、内核及Android框架层均认为BL处于已锁状态，从而绕过完整性检测，同时保留通过SuperFastboot进行刷写的能力。

高通ABL启动链基础

在骁龙8Gen5平台上，设备上电后的启动顺序大致如下：

PBL（片上只读）
  └──> XBL / SBL（一次性可编程，高度受保护）
         └──> ABL（efisp 分区，UEFI 应用层）
                └──> Linux Kernel

ABL是整个链条中唯一同时满足「可被刷写替换」与「可访问 Verified Boot 决策逻辑」两个条件的组件。高通将 ABL 以 UEFI Firmware Volume（FV）格式打包，内部包含若干 PE32 格式的 EFI 应用，其中最核心的是LinuxLoader.efi，负责执行 AVB（Android Verified Boot）校验、决定 BootState，并最终引导内核。

ABL的验证由 GBL 负责。GBL 会从 efisp 分区读取并校验 ABL。这里存在一个关键行为：GBL 读取的分区名是通过一个可写的 UTF-16 字符串 "efisp" 指定的。这个字符串位于 ABL 二进制的数据段，可以在 PC 端修改——这就是本方案漏洞利用的起点。

efisp分区名替换

patch_abl_gbl是整个方案中最简洁的一步：

int32_tpatch_abl_gbl(char* buffer, int32_t size) {
char target[]      = { 'e',0, 'f',0, 'i',0, 's',0, 'p',0 };
char replacement[] = { 'n',0, 'u',0, 'l',0, 'l',0, 's',0 };
int32_t target_len = sizeof(target);
for (int32_t i = 0; i < size - target_len; ++i) {
if (memcmp(buffer + i, target, target_len) == 0) {
memcpy(buffer + i, replacement, target_len);
return0;
        }
    }
return-1;
}

这段代码在ABL二进制中扫描 UTF-16 编码的字符串"efisp"，将其就地替换为"nulls"。

作用：修补后的ABL被刷入efisp分区。当这个被修改过的 ABL 在运行时试图按照原来的逻辑从 efisp 分区加载「下一个 EFI」时，它会因找不到名为"nulls" 的分区而静默跳过，从而阻止原始 ABL被递归再次加载，避免了加载链的无限循环。

这一补丁之所以可行，根本原因在于GBL对ABL的完整性校验发生在加载阶段，而不是在ABL运行期间对其自身数据段进行持续校验。一旦GBL完成校验并将控制权移交给被修改的 ABL，后者就能自由运行，包括引导一个与原始执行路径完全不同的自定义EFI载荷。

ABL 二进制的提取：从镜像到 PE32

在对ABL进行修补之前，需要从abl.img（或运行中设备的 abl_a/abl_b 分区）中提取出可操作的 PE32 二进制。这项工作由extractfv完成。

extractfv 实现了一个递归多层扫描器，逻辑如下：

abl.img（原始 flash 镜像）
  └── deep_scan()
        ├── 扫描 MZ 头 → 提取 PE32 文件
        ├── 扫描 BMP 图片（可选）
        ├── 扫描 LZMA 压缩块（0x5D 0x00 0x00 魔数）→ 解压后递归 deep_scan()
        └── 扫描 EFI Firmware Volume（_FVH 签名）→ 递归进入 FV 解析

其中最关键的是 FV 解析路径。高通 ABL 将核心 LinuxLoader.efi 封装在一个标准 UEFI Firmware Volume 内，该 FV 内部包含若干 FFS（Firmware File System）文件，PE32 节（EFI_SECTION_PE32）可能直接存在，也可能经过 LZMA 压缩封装在 EFI_SECTION_COMPRESSION 中。

extractfv 能够处理所有这些变体：

  • try_lzma_decompress()

    ：使用 liblzma 解压 LZMA 压缩块

  • calc_pe_real_size()

    ：通过解析 PE 头部的节表精确计算真实文件大小，避免提取多余数据

  • parse_pe_info()

    ：识别 ARM64 架构与 EFI_APP/EFI_DRIVER 子系统，用于过滤

默认模式下，extractfv 提取最大的 PE32 文件，输出为 LinuxLoader.efi，这就是后续 ABL 修补的输入。

修补AVB验证绕过

提取出LinuxLoader.efi后，patch_abl工具对其进行一系列精确的二进制修补。所有修补逻辑都在 PatchBuffer()中协调执行，目标是VerifiedBoot.c中的LoadImageAndAuthVB2 函数的编译产物。

整个修补分为以下几个层次。

启动状态锚点定位（补丁3）

int16_t Original[] = {
-1, 0x00, 0x00, 0x34, 0x28, 0x00, 0x80, 0x52,
0x06, 0x00, 0x00, 0x14, 0xE8, -1, 0x40, 0xF9,
0x08, 0x01, 0x40, 0x39, 0x1F, 0x01, 0x00, 0x71,
0xE8, 0x07, 0x9F, 0x1A, 0x08, 0x79, 0x1F, 0x53
};

这是一个包含 8 条 ARM64 指令的字节序列，对应源码中以下逻辑的编译产物：

// VerifiedBoot.c 约 1887 行
if (AllowVerificationError) {
    BootState = ORANGE;  // CBZ + MOVZ #0x28
} else {
    BootState = GREEN;   // B + (其他赋值)
}

模式中的 -1 表示该字节是通配符（随编译版本变化的寄存器编号）。匹配到这个模式后：

  1. 从第一个字节的低 5 位提取锁状态寄存器编号（lock_register_num）

  2. 记录该模式在文件中的偏移（anchor_offset）

  3. 对匹配到的 CBZ Wn, <label> 指令进行修补：将其目标寄存器替换为 WZR（寄存器 31，零寄存器），使分支永远不成立，从而跳过 ORANGE 路径

这一步是后续所有数据流追踪的基础锚点。

反向数据流追踪（补丁4）

定位到锚点后，find_ldrB_instructio_reverse 从锚点地址向前反向扫描，追踪 lock_register_num 寄存器值的来源：

// 从锚点向前追踪，最多 8 次寄存器-栈溢出弹跳
while (now_offset >= 0) {
    DecodedInst d = decode_at(buffer, now_offset);
if (d.type == INST_PACIASP) break; // 遇到函数边界，停止
// 处理 64 位栈溢出：LDR Xt,[SP,#imm] → 追踪对应的 STR
if (d.type == INST_LDR_X_IMM && d.rn == 31 && d.rt == current_target) { ... }
// 处理字节级栈溢出：LDRB Wt,[SP,#imm] → 追踪对应的 STRB
if (d.type == INST_LDRB_IMM && d.rn == 31 && d.rt == current_target) { ... }
// 找到真正的数据来源：LDRB Wt,[Xn,#off]（从全局变量加载）
if (d.type == INST_LDRB_IMM && d.rt == current_target && d.rn != 31) {
// 找到了！触发 source_callback
    }
}

找到源头 LDRB Wt, [Xn, #off]（即 AllowVerificationError = IsUnlocked()）后，source_callback 将其改写为：

write_instr(buffer, now_offset, encode_movz_w(current_target, 1));
// 原: LDRB Wt, [Xn, #off]   ← 读取 IsUnlocked() 返回值
// 改: MOV Wt, #1             ← 硬编码 AllowVerificationError = TRUE

这一修改的深层含义：AllowVerificationError = TRUE 不仅跳过了 AVB 校验失败时的拒绝启动逻辑，还阻止了 UpdateRollbackIndex 标志被置位。由于回滚版本更新（TZ_UPDATE_ROLLBACK_VERSION）和 TZ 软熔断（TZ_BLOW_SW_FUSE_ID）都只在 UpdateRollbackIndex == TRUE 时执行，这一补丁同时防止了 TZ 对设备的永久性标记。

正向数据流追踪（补丁5）

找到源头后，track_forward_patch_strb 从该源指令向后正向扫描，追踪寄存器值的消费点。追踪引擎使用 LocSet 数据结构维护一个「活跃数据位置集合」，处理寄存器间拷贝、32/64 位栈溢出与重载：

// LocSet 追踪的操作类型：
// - LOC_REG:   当前在某个寄存器中
// - LOC_STK64: 已溢出到栈上（64 位）
// - LOC_STK8:  已溢出到栈上（8 位）
// 当发现 STRB Wt, [Xn, #imm]，且 Wt 在 LocSet 中时：
write_instr(buffer, off, strb_with_reg(d.raw, 31));
// 原: STRB Wt, [Xbase, #off]   ← 写入 Data.IsUnlocked = AllowVerificationError
// 改: STRB WZR, [Xbase, #off]  ← 强制写入 0

Data.IsUnlocked 是 KMRotAndBootState 结构体的成员，该结构体通过 KeyMasterSetRotAndBootState() 传递给 TEE。TEE 用 IsUnlocked 的值参与 ROT（Root of Trust）摘要计算：

RotDigest = SHA256(PublicKey || IsUnlocked)

如果IsUnlocked = 1 到达 TEE，TEE 的 ROT 与出厂预期不符，会拒绝释放 FBE（File-Based Encryption）数据加密密钥，导致用户数据完全不可访问。补丁 5 强制写入 0，确保 TEE 收到的 ROT 信息与未解锁状态一致，数据分区正常解密。

cmdline状态字符串修补（补丁2）

int32_tpatch_adrl_unlocked_to_locked(char* buffer, int32_t size, uint64_t load_base) {
// 在二进制中定位 ADRP+ADD 指令对序列
// 第一对加载 "unlocked" 字符串地址
// 第二对加载 "locked" 字符串地址
// 第三对加载 "androidboot.vbmeta.device_state" 字符串（确认上下文）
// 将第一对 ADRP+ADD 的目标寄存器改为第二对的寄存器
// 效果：两者都指向 "locked"
uint32_t new_adrp = adrp_with_rd(b0.raw, xa);
uint32_t new_add  = add_with_reg(b1.raw, xa);
    write_instr(buffer, i,     new_adrp);
    write_instr(buffer, i + 4, new_add);
}

这一补丁修改内核启动参数中 androidboot.vbmeta.device_state 的值，从 unlocked 改为 locked。Android 框架层（如 Google Play Services、SafetyNet/Play Integrity）通过读取这个属性判断 BL 状态，如果不修改该字符串，即便 TEE 认为设备已锁，Android 层面仍会探测到解锁状态，银行类应用等将无法运行。

定位方式完全依赖编译器保留的字符串：通过 ADRP+ADD 指令对（高通 AARCH64 ABI 下加载页对齐全局地址的标准方式）来找到加载目标字符串的代码位置，无需知道任何固定偏移。

OPPO/OnePlus警告屏去除定制补丁

针对OPPO/一加设备，patch_warning负责去除开机时的「橙色状态」警告界面：

boolpatch_warning(char* buffer, int32_t size, int32_t global_var_offset) {
// 1. 通过字符串 "Orange State\n" 定位警告代码
int32_t warn_off = find_warning_offset(buffer, size, 0);
// 2. 向上搜索控制是否显示警告的 CBZ 指令
for (int32_t i = warn_off - 4; i >= max_search_range; i -= 4) {
if (d.type == INST_CBZ_W) {
// 3. 反向追踪该 CBZ 的判断值来源
            find_ldrB_instructio_reverse(buffer, size, i, d.rt, &offset, empty_source_callback);
// 4. 确认来源是锁状态全局变量（与前面记录的 global_var_offset 匹配）
if (offset != global_var_offset) continue;
// 5. 将 CBZ Wt 改为 CBZ WZR（永远不成立，跳过警告显示）
            write_instr(buffer, i, change_rt(&d, 31));
        }
    }
}

关键点在于第4步的确认：只对来源是「锁状态全局变量」的 CBZ 进行修改，不盲目 NOP 掉所有 CBZ，从而避免破坏其他功能逻辑。

ARM64 指令引擎

上述所有修补逻辑都依赖一个轻量级的ARM64指令解码与编码引擎，支持 20+ 种指令类型：

指令类别

覆盖类型

内存访问

LDRB/STRB（立即数/前索引/后索引）、LDR/STR（32/64 位）

寄存器操作

MOV X/W、MOVZ W

地址计算

ADRP、ADD X（含 LSL#12）

条件分支

CBZ/CBNZ（32/64 位）、B.cond

无条件跳转

B、BL

特殊指令

PACIASP（函数边界标记）、NOP、RET

所有指令使用统一的 DecodedInst 结构表示，解码采用优先级表（priority table）驱动，避免编码空间重叠带来的歧义。编码辅助函数支持原地修改：

uint32_tadrp_with_rd(uint32_t raw, uint8_t new_rd);  // 替换 ADRP 的目标寄存器
uint32_tadd_with_reg(uint32_t raw, uint8_t new_reg);  // 替换 ADD 的 Rd 和 Rn
uint32_tstrb_with_reg(uint32_t raw, uint8_t new_rt);  // 替换 STRB 的 Rt
uint32_tencode_movz_w(uint8_t rd, uint16_t imm16);    // 构造 MOVZ Wd, #imm16
uint32_tchange_rt(DecodedInst* inst, uint8_t new_rt); // 通用 Rt 替换
uint32_tchange_to_b(uint32_t raw);                    // CBZ/CBNZ 转为无条件 B

自定义SuperFastboot

修补后的ABL在efisp分区加载自身时不再递归加载原始efisp，而是执行项目自带的 LinuxLoader.efi（即 SuperFastboot 载荷）。

ELF注入机制

elf_inject工具将修补后的 ABL.efi 嵌入 loader.elf（SuperFastboot 的未链接 ELF 二进制）中：

// loader.elf 中预留了一个占位符节区
__attribute__((section(".abl_placeholder"), used))
unsignedint dist_ABL_efi_len = 16;
__attribute__((section(".abl_placeholder"), used))
unsignedchar dist_ABL_efi[] = "ABL_PLACEHOLDER!";

elf_inject 扫描 ELF 的节表，找到包含 "ABL_PLACEHOLDER!" 的节区，将其替换为实际的 ABL.efi 数据，同时正确更新节大小、程序头（Phdr）的 FileSiz/MemSiz 字段以及节表偏移（e_shoff），确保输出的 ELF 结构合法。

运行时启动逻辑

LinuxLoader.efi的LinuxLoaderEntry 启动入口实现了以下决策树：

LinuxLoaderEntry()
  ├── ReadAllowUnlockValue() → 检测 OEM Unlock 开关
  │     └── 若未开启（或读取失败）→ 直接加载内嵌的 ABL.efi，普通启动
  ├── WaitForVolumeDownKey(3000ms) → 等待音量减键
  │     ├── 按下音量减 → 进入 SuperFastboot 模式
  │     ├── 按下音量加 → 进入 Recovery（扩展功能）
  │     └── 超时无输入 → 加载内嵌 ABL.efi，普通启动
  └── FastbootInitialize() → 启动 Fastboot 服务

BootEfiImage() 通过标准的 gBS->LoadImage() + gBS->StartImage() UEFI 调用链式启动内嵌的 ABL.efi。这意味着整个引导链实际上是：

GBL → 修补后的 ABL（SuperFastboot 壳）
         └──[用户无操作]──> 原始 ABL.efi（内嵌于壳中，继续正常引导）
         └──[按音量减]────> Fastboot 服务（SuperFastboot 模式）

SuperFastboot 的关键能力

SuperFastboot 基于高通 QcomModulePkg 的 FastbootLib，在假回锁状态下提供了原生 Fastboot 所不具备的能力：

  • fastboot flashing unlock

     / unlock_critical：BL 解锁操作，不触发数据清除

  • fastboot flashing lock

    ：重新锁定 BL，触发数据清除

  • fastboot flash <partition> <file>

    ：全分区刷写

  • fastboot boot xxx.efi

    ：临时启动任意 EFI 文件（无需刷写）

fastboot flashing unlock 不触发数据清除的原因：高通 ABL 在处理解锁命令时会检查当前 BootState。由于此时 ABL 已被修补（BootState=GREEN，IsUnlocked=0），设备表现为已锁状态，执行解锁操作时不满足触发数据清除的条件判断，因此跳过了清除流程。

工具链与构建流程

整个方案由多个独立工具组成，通过 make 驱动的构建系统统一编排：

gbl_root_canoe/
├── submodules/
│   ├── ablfvextractor/   extractfv — ABL 固件卷解包工具（C，依赖 liblzma）
│   ├── patcher/          patch_abl — ABL 二进制修补工具（C，无依赖）
│   ├── elflinker/        elf_inject — ELF 载荷注入工具（C）
│   └── uefi/edk2/        LinuxLoader.efi — SuperFastboot 载荷（UEFI/EDK2）
└── targets/
    ├── toolkit_linux/    Linux PC 工具包构建目标
    ├── toolkit_windows/  Windows PC 工具包构建目标（MinGW 交叉编译）
    └── magisk_module/    Magisk 模块构建目标（Android NDK 交叉编译）

使用方法

在PC电脑上依次执行：

1. extractfv abl.img -o ./build/
        → 提取 LinuxLoader.efi（ABL 核心 PE32）
2. patch_abl LinuxLoader.efi ABL.efi
        → 执行所有补丁，输出修补后的 ABL.efi
3. elf_inject loader.elf ABL.efi ABL_with_superfastboot.efi
        → 将修补后的 ABL 嵌入 SuperFastboot 壳，输出最终文件
4. fastboot flash efisp ABL_with_superfastboot.efi
        → 刷入 efisp 分区

Magisk模块版本将以上步骤封装为设备端脚本，在已Root的设备上通过Root管理器（KernelSU/Magisk/APatch）直接执行，免去PC操作。

整体效果

方案在几个层面保证了跨设备、跨 ABL 版本的鲁棒性：

字符串锚定而非地址硬编码 所有代码位置均通过编译器保留的字符串常量（"unlocked"、"locked"、"androidboot.vbmeta.device_state"、"Orange State\n"、"Your device has been unlocked"）动态定位。字符串在 ABL 重编译后地址会变化，但内容不会变化，ADRP+ADD 寻址模式也不会变化。

指令模式匹配而非固定字节序列 启动状态锚点（Original[]）使用带通配符的模式而非精确字节序列，通配符覆盖随编译器寄存器分配变化的字段（低 5 位寄存器编号），只匹配控制流结构固定的部分。

数据流追踪适应编译器优化 补丁 4/5 的反向/正向追踪引擎能够跟踪寄存器值经过多层栈溢出（STR Xt,[SP,#imm]/LDR Xt,[SP,#imm]）和字节溢出（STRB Wt,[SP,#imm]/LDRB Wt,[SP,#imm]）之后的最终位置，最多支持 8 次「弹跳」，应对编译器激进优化下的寄存器重用和溢出重排。

函数边界保护 所有追踪都以 PACIASP（ARM 指针认证指令，同时也是高通 ABL 中标记函数入口的约定）作为硬性停止条件，防止追踪越过函数边界误改其他函数的代码。

分级失败处理 补丁分为「关键」（失败则中止并返回 false）、「重要但非关键」（失败打印警告继续）、「可选」（失败静默忽略）三个级别。这确保了在 cmdline 字符串补丁失败的 ABL 版本上，设备仍能正常启动，只是状态字符串暴露，不会因补丁失败导致砖机。

经过以上所有补丁和载荷注入后，设备的状态：

项目

状态

TEE BootState

GREEN（已锁，TEE 正常释放 FBE 密钥）

androidboot.vbmeta.device_statelocked

用户数据

完整可访问

SafetyNet / Play Integrity

基础级别通过（取决于设备其他因素）

Fastboot 能力

完整，含解锁/锁定/刷写/临时启动

OTA 兼容性

需 OTA 前降级 ABL 版本，或模块脚本自动处理

BL 解锁状态

维持未解锁（物理意义上），或可通过 SuperFastboot 二次解锁

本方案的本质是：在 GBL 校验之后、内核启动之前的 UEFI 空间内，通过精确的二进制修补让 ABL 的安全状态决策输出与未解锁状态保持一致，从而在不触碰 xBL 及 TEE 的前提下，实现了对 AVB 和设备状态上报机制的完全控制。

当然，这种补丁方式已经有了更优雅的升级版本，基于GBL启动链Hook技术勾住每一个需要补丁的地方，动态补丁兼容性更好。

具体细节与使用方法点击阅读原文下载：高通8Gen5的gbl解锁隐藏技术实现原理分析.pdf

阅读原文

跳转微信打开

]]> Thu, 11 Jun 2026 18:31:00 +0800 横跨近半年的高通8Gen5漏洞利用时间线 https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485242&idx=1&sn=f04c9172f016a16174e7b9f6cca6c4b1 高通GBL漏洞利用从本年2月底公开后，利用手法与工具也在不但更新变化。 原创 非虫 2026-06-10 15:56 湖北

高通GBL漏洞利用从本年2月底公开后，利用手法与工具也在不但更新变化。当前3月就录制了这个漏洞的两集视频，这次录制相关视频第3集时，整理了全部的时间线给大家。

知识星球我也传一份高清的。

https://t.zsxq.com/5VaKz

跳转微信打开

]]> Wed, 10 Jun 2026 15:56:00 +0800 使用木鱼沙箱跟踪分析kpm与ko模块 https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485237&idx=1&sn=61044ac4cc7070f7e4984a2326a9a905 木鱼沙箱一个全网独有的功能，就是支持参KernelPatch的KPM模块，与安卓GKI内核的ko模块进行动态跟踪 原创 非虫 2026-06-09 11:33 湖北

木鱼沙箱一个全网独有的功能，就是支持参KernelPatch的KPM模块，与安卓GKI内核的ko模块进行动态跟踪分析。并生成指令级别的日志跟踪记录。主打攻破闭源与OLLVM混淆的内核模块。

PDF报告中带了trace日志，方便手动分析与接入AI分析。

下面是ko模块的。

下面是ko的trace日志。

目前木鱼沙箱限安卓软件开发与逆向分析全阶段学员内部免费使用。

点击阅读原文下载wuwa ko的PDF报告。

阅读原文

跳转微信打开

]]> Tue, 09 Jun 2026 11:33:00 +0800 木鱼沙箱软件分析平台全新开启内测 https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485228&idx=1&sn=f944f8c1869663aa2746f888ec286963 木鱼分析沙箱新版本重磅内测来袭 原创 非虫 2026-05-30 14:43 湖北

木鱼分析沙箱新版本重磅内测来袭

木鱼的目标是对安卓与iOS移动系统软件实现全方位的穿透分析，做安全分析从业员样本分析路上的瑞士军刀。

沙箱功能

  1. APK静态与动态分析

  2. XAPK静态与动态分析

  3. 自动化逆向分析

  4. APP网络协议分析

  5. APP威胁分析平台

沙箱报告

  •  APP基本信息

  •  APP风险打分

  •  APP证书信息

  •  APP概要信息

  •  APP权限

  •  APP组件信息

  •  APP第三方SDK与壳信息

  •  APP第三方SDK密钥提取

  •  JAVA API调用分析

  •  系统调用分析

  •  运行时截图

  •  Native进程执行流程图

  •  运行时行为规则

  •  APP标签与识别

  •  网络请求识别

  •  威胁分析分布（domain, email, mobile）

  •  分析环境打包与部署

  •  Linux Docker环境部署支持

  •  分析报告支持主题样式

  •  分析报告支持pdf

  •  分析报告支持html

  •  L1规则引擎

  •  L2规则引擎

  •  L3规则引擎（正在完善）

  •  L4规则引擎（正在完善）

  •  脱壳功能（正在完善）

  •  隐私合规检测规则（正在完善）

  •  风控SDK识别与行为分析（正在完善）

  •  32位app支持

  •  样本图云功能

  •  分析环境支持制作ROM包刷机

  •  自动抓HTTPS包

  •  Flutter动态分析支持

  •  Hiddern API检测

  •  MITRE检测支持

  •  CVE检测支持

  •  支持所有OLLVM混淆识别

  •  XPosed插件Hook点分析支持(正在测试更多样本)

  •  LSPosed插件Hook点分析支持

  •  Zygisk插件Hook点分析支持(部分支持，正在完善)

  •  Native代码Hook点分析支持(正在完善)

  •  Native代码presets

  •  Golang开发的APP支持

  •  C#开发的APP支持（目前部分）

  •  H5/Web开发的APP支持（目前部分）

  •  网络地图炮（目前部分）

  •  活动名对应截图

  •  分析环境设备信息修改与模拟（正在完善）

  •  跟踪分析ko功能（正在接入）

  •  跟踪分析kpm功能（正在接入）

  •  Flutter抓包支持

  •  威胁情报平台对接

  •  火焰图支持

目前限定安卓软件安全开发与逆向分析全阶段学员内测。后期也没有公开免费卷国内安全从业者同行的打算。

跳转微信打开

]]> Sat, 30 May 2026 14:43:00 +0800 解决一个安卓15/16调试APK运行adb jdwp无输出的问题 https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485221&idx=1&sn=896b232e993d35f05c40f2d4f54cdb3b 解决一个安卓15/16调试APK运行adb jdwp无输出的问题 原创 非虫 2026-05-14 15:35 湖北

解决一个安卓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起来。然后测试，发现成功了！

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

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

    跳转微信打开

    ]]>     Thu, 14 May 2026 15:35:00 +0800     有意思的官方杀同人安卓投屏多窗口融合模式 https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485211&idx=1&sn=de7f359c8d7861e8b1124667a40341b6 有意思的官方杀同人安卓投屏多窗口融合模式 原创 非虫 2026-05-13 15:42 湖北

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

    上一篇《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)的预览版，欢迎在评论里聊一聊各自的使用体验。

    跳转微信打开

    ]]>     Wed, 13 May 2026 15:42:00 +0800     三大Root框架通杀检测与反检测方法分析 https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485204&idx=1&sn=0cf8c32c11363b3fab82419058605ad5 最近比较流行通杀！前面讲过两篇Linux的通杀漏洞，这次轮到安卓了。 原创 非虫 2026-05-12 12:21 湖北

    最近比较流行通杀！前面讲过两篇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的身份充当查询者，覆盖以下四组访问关系：

    检测点

    source

    target

    class

    perm

    严重级

    通用脏策略

    system_server

    system_server

    process

    execmem

    WARNING

    Magisk binder

    untrusted_app

    magisk

    binder

    call

    WARNING

    KernelSU binder

    untrusted_app

    ksu

    binder

    call

    WARNING

    LSPosed file read

    untrusted_app

    lsposed_file

    file

    read

    DANGER

    正向控制（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服务函数的钩子，覆盖检测器可能用到的所有入口。各目标的角色如下：

    目标符号

    作用

    security_read_policy

    给应用UID返回干净policy副本，绕开当前dirty策略

    security_load_policy

    标记"外部load"以识别脏策略加载

    sel_write_load

    计数/sys/fs/selinux/load写入次数

    sel_write_access

    拦截/sys/fs/selinux/access，命中Root类型即返回-EINVAL

    sel_write_context

    拦截/sys/fs/selinux/context，未在干净策略中出现即返回-EINVAL

    security_setprocattr

    或selinux_setprocattr

    过滤procattr current一侧，防止从/proc/self/attr/current绕开

    context_struct_compute_av

    把应用UID的policydb参数替换成干净副本

    string_to_context_struct

    同上，用于上下文字符串到context_struct的转换

    selinux_complete_init

    SELinux首次就绪时触发干净策略快照

    selinux_policy_commit

    每次新策略生效后维护first_policy并刷新快照

    辅助符号则按需通过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方案的对照：

    维度

    KernelSUselinux_hide

    APatch KPM

    入口替换方式

    		kallsyms_lookup_name("write_op")

    +ksu_patch_text

    KPM框架的hook_wrap

    备份策略来源

    内核内部backup_sepolicy，构造时机早于Root域追加

    用security_read_policy+security_load_policy运行时重建

    覆盖入口

    		SEL_CONTEXT

    、SEL_ACCESS、setprocattr current

    同上，并额外覆盖compute_av、string_to_context等更深层入口

    适用平台

    与KernelSU一同合入

    任何能加载KPM的内核，无需源码改动

    总体上，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，但返回值已经接近一份干净策略，命中率自然随之下降。

    参考资料

    跳转微信打开

    ]]>     Tue, 12 May 2026 12:21:00 +0800     iOS虚拟手机可以玩窗口化融合的越狱插件 https://mp.weixin.qq.com/s?__biz=MzU3MTY5MzQxMA==&mid=2247485193&idx=1&sn=5b53423ee611f250baca7a2181283108 iOS虚拟手机可以玩窗口化融合的越狱插件 原创 非虫 2026-05-09 12:11 湖北

    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的启动与窗口化，那是否可以实现安卓系统上那样的“多开”功能？欢迎大家在评论区讨论。

    阅读原文

    跳转微信打开

    ]]>     Sat, 09 May 2026 12:11:00 +0800