文章总结： 本文深入分析人脸注入黑产工具在相机链路的三个换帧点及一种启动链托管方式，包括进程内Hook、系统相机服务写帧、HAL/Provider代理及启动链托管，揭示工具接管画面交付环节的技术原理，为风控检测提供对抗思路与检测方向。
综合评分： 85
文章分类： 红队,渗透测试,安全研究

风控检测_人脸注入，镜头也会说谎

原创

qianlan
qianlan

帅仔回忆录

2026年9月20日 18:15
浙江

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

引子：一门生意的最后一道工序

风控系列第二篇文章。

支付账户实名认证、网约车司机核身、直播平台身份检查等流程，都可能要求用户对着手机镜头眨眼或转头。业务方希望确认操作的人就在镜头前；想冒用身份、代人完成核验或批量运营账号的人，则需要让 App 看到另一张脸。围绕这道关口，黑产售卖人脸注入工具：它们试图把准备好的画面送进业务 App，让这段画面看起来像摄像头正在拍摄。

换脸软件可以把一张照片做成会眨眼、会转头的视频，但视频文件并不会自动出现在刷脸页面里。核验时，App 等待的是手机相机持续送来的画面。人脸注入工具补上的就是这最后一段路：让素材进入相机链路，替代镜头此刻采集的内容。卖家可以交付一个可安装的软件、定制的 boot.img 与配套软件，也可以交付一台已经改好的手机。交付形式决定买家需要动手多少；工具在哪一层接管画面，则决定它影响哪些 App、留下什么痕迹。

本文分析了十几款人脸注入黑产工具。沿着画面从镜头到 App 的路径看，它们在三处位置动手：目标 App 进程、系统相机服务、相机硬件接口（Provider）。还有一类工具不增加换帧位置，而是把 Provider 代理的部署和运行写进开机流程。这就是下文的三处换帧点，加上一种启动链托管方式。

文章依据工具代码、固件镜像和隔离设备实验展开。代码显示具备某项能力、实验中观察到替代画面、通过真实业务核验，是三种不同强度的结论；本文不把商品宣传当作实测结果。先看正常情况下，一帧画面怎样从镜头走到 App。

一、一条可以被接管的管道

业务 App 打开相机时，并不是直接从传感器拿像素。光先被传感器采集，经 ISP 处理成图像数据；HAL/Provider 对接具体硬件，cameraserver 管理相机设备与会话，画面再经缓冲队列交给 App，最后由人脸 SDK 读取。App 拿到的是链路末端交付的画面。

这像城市供水：传感器和 ISP 是水源与初级处理，HAL/Provider 把不同硬件的输出接入系统，cameraserver 负责调度，BufferQueue 把画面送到消费端。水龙头只接收管网送来的水；同样，App 只接收上游送来的画面。只要有人能控制其中一处交付环节，就可能让下游收到另一段画面。

┌┄ 硬件层｜手机内部 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐
┆ ① 传感器：采集光信号 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
┆ ② ISP/驱动：形成图像数据 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
└┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ 图像数据
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ▼
┌┄ 系统软件层｜相机链路 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐
┆ ③ HAL/Provider：组织[ARTICLE_v2.1.md](ARTICLE_v2.1.md)采集结果 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
┆ ④ cameraserver：管理设备与会话 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
┆ ⑤ BufferQueue：向消费端交付缓冲 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;┆
└┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ 共享图像缓冲及其句柄用于交付环节
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ▼
┌┄ 应用层｜业务 App ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐
┆ ⑥ Camera API / 人脸 SDK：读取并处理画面 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;┆
└┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘

正常相机链：从手机硬件层，经系统软件层到 App 和人脸 SDK

总图｜硬件采集画面，系统软件逐站交付，业务 App 在末端读取。共享图像缓冲及其句柄用于部分交付环节；后文沿用这张底图标出各类工具的控制点。

这也是人脸注入工具的切入点：它们有的改接 App 的画面入口，有的在系统相机服务或 Provider 一侧改写交付内容，还有的把代理的部署放进开机流程。下面按控制位置讲述：前三类是换帧位置，第四类是第三类代理的启动与托管方式。类别三和类别四可以出现在同一套商品里，并非互斥技术：

离业务 App 最近的是类别一。它不改系统里的公共相机链，而是改变目标 App 接收画面的方式。

二、类别一：把用户家的水龙头换掉

具体来说，钩子进入目标 App 自己的进程，动手的位置是相机输出目标和预览回调，包括 Surface、SurfaceTexture、ImageReader 等。它主要影响被选中的 App，线索也集中在目标进程和工具安装包；系统相机链本身仍在运行。输出目标如何被改接、替代画面又从哪里来，下面按步骤展开。

使用前提：门槛取决于钩子怎样进入目标 App。虚拟容器路线无需 Root，目标 App 要在容器内运行；LSPosed 模块路线依赖已 Root、装有相应框架的设备，也有重打包目标 App 或借免 Root 容器承载的变体。钩子就位后，画面替换主要发生在 App 进程内。

┌┄ 接管范围｜选定的目标 App 进程 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐
┆ ① LSPosed 模块或虚拟容器使钩子进入进程 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;┆
┆ ② Camera API 输出目标：App 原 Surface → 模块替身 Surface &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;┆
└┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;┌──────────────────┴──────────────────┐
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;▼ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ▼
┌┄ 真实相机路径 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐ &nbsp; ┌┄ 素材供帧路径 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐
┆ 传感器 → HAL → cameraserver &nbsp; &nbsp; ┆ &nbsp; ┆ ③ 素材 → MediaCodec 解码 &nbsp; &nbsp; &nbsp; &nbsp;┆
┆ 真实帧 → 模块替身 Surface &nbsp; &nbsp; &nbsp; ┆ &nbsp; ┆ → App Surface/ImageReader &nbsp; &nbsp; &nbsp; ┆
┆ 不进入 App 原接收面 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆ &nbsp; ┆ ④ 人脸 SDK 读取替代帧 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
└┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘ &nbsp; └┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘
例外：Camera1 字节回调可在真帧到达后原地覆盖。

类别一：目标 App 进程内 Hook 的工作顺序

图一｜接管点在选定的目标 App 进程内。蓝色真实帧被改接到替身，橙色素材帧经解码后送到 App 的接收面，最终由人脸 SDK 读取；Camera1 字节回调的原地覆盖是图外例外。本图解释静态样本中的设计路径，不代表已验证业务通过。

两条投递路线，取舍相反

钩子怎么装进目标 App，有两条成熟的商业路线：

容器路线的代表 VCamera 长得就像一个普通的“应用多开”工具：主界面列出手机上已装的应用，一键克隆进自控空间运行；素材界面提供真实相机、本地视频、网络流（HLS/RTSP 等）、图片四种模式；带广告与应用内购买变现——从外观上看与正规多开应用无异。

两者是同一个 Hook 面上的两种取舍：容器免 Root，但需要克隆目标 App；常规 LSPosed 模块需要 Root，却可作用于原版 App。重打包或容器承载的变体也可能在无 Root、未解锁 bootloader 的设备上运行，因此不能只凭这两类环境信号排除进程内替帧。

钩子进入进程之后，类别一的动作就沿着目标 App 的生命周期展开：取得 Context → 装钩子 → 相机打开时换掉生产者 → 素材帧灌进去。下面按顺序展开。

步骤一：App 启动——取得 Context，全链的起点

Instrumentation.callApplicationOnCreate 在这份 Hook 清单里并不显眼，却是样本取得 Application Context 的起点。模块随后用 Context 创建悬浮窗、访问跨进程配置、创建 MediaCodec、读取自身包资源。它在类别一里的作用，类似类别四中负责拉起部署脚本的 call_usermodehelper：让后续动作有了执行入口。

步骤二：装钩子——静态 17 处与级联 10 处

这份样本的钩子不是一次装完的。Camera2 打开相机后才会返回具体的 CameraDevice，随后又创建 CameraCaptureSession；模块要拿到这些运行时对象，才能确认实际使用的实现类。于是它把安装工作拆成两批：

┌┄ 目标 App 进程｜Hook 分阶段安装 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐
┆ ① App 启动：按已知类静态安装 17 处 Hook &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;┆
┆ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;↓ openCamera 回调出现 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
┆ ② 取得运行时对象及其实际类 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
┆ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;↓ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
┆ ③ 按实际类级联安装 10 处会话相关 Hook &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;┆
└┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘

这说明样本的一部分 Hook 目标要到运行时才能确定；仅数 APK 中预先列出的钩子点，可能低估其覆盖范围。不同设备或 App 触发的具体实现类也可能不同。类别二针对系统相机服务中的函数，类别三则包裹 Provider 接口，它们与这类 App 进程内的级联安装并不是同一种做法。

步骤三：相机打开——换掉生产者，而不是改写像素

理解类别一的关键，是分清两种听起来差不多、其实完全不同的做法：

就地覆盖：真实帧照常送到 App 手里，攻击者在字节数组上把内容改掉；
生产者替换：相机输出改送模块的替身对象，App 原本的接收面则由素材帧填充；在这条路径上，真实帧不再到达 App。

样本的实际做法是后者。以 Camera2 为例，模块 hook 了 CaptureRequest.Builder 的三个方法，语义环环相扣：removeTarget 把 App 原本的输出 Surface 从捕获请求里摘掉，addTarget 换上模块自己的 Surface，build 定型请求。请求一旦定型，相机输出的真实帧流向替身、从未到达 App；App 那边的 Surface 改由 MediaCodec 用素材填充。Camera1 侧同理：setPreviewTexture 的入参被换成一个 fake_SurfaceTexture，真实相机的预览被导向替身纹理。整条链上唯一的就地覆盖，是 Camera1 的 onPreviewFrame(byte[], Camera) 字节回调——那条路径确实是真帧到达后原地改写。

这个判断不是从架构图推出来的，样本日志自己证明了它。模块里存在成组的防自扰逻辑：“SurfaceTexture 与替身相同则跳过”“StateCallback 与自己的回调相同则跳过”“检测到相机重复”。如果它只做就地覆盖，根本不会创建自己的纹理和回调对象，也就无须防止钩子装到自己头上——只有在生产者替换模型下，这些代码才有存在的理由。

“帧被改”还是“生产者被换”，留下的是两类不同的来源线索：前者的异常发生在系统相机链路（见类别二、三）；后者还涉及 App 的 Surface 由 MediaCodec 而非相机填充，帧与物理传感器状态是否自洽也成为值得关注的方向。

步骤四：灌素材——怎么变成“相机帧”

一段 MP4 不能直接当相机帧用，中间隔着一条完整的格式管线。样本的做法：

解封装：MediaExtractor 读出素材的 mime、宽高与 rotation-degrees；
解码：MediaCodec 解出原始帧，先尝试设定 COLOR_FormatYUV420SemiPlanar 色彩格式，设备不支持则回落——样本日志明写“only support COLOR_FormatI420 and COLOR_FormatNV21”；
按目标分发：输出走两条独立管线——NV21 供预览回调与 ImageReader 消费，JPEG 供 takePicture 静态抓拍。这也解释了样本为什么把 ShutterCallback 和三个 PictureCallback 一并 hook：抓拍和预览在 Android 里本就是两条路；
音轨同步：四组音频播放对象由配置项控制，还处理了“多个播放器并存”的互斥。攻击者清楚，在视频通话与直播场景里，“只有画面没有声音”本身就是破绽。

ImageReader.newInstance 出现在 hook 清单里的动机也在这条管线上：App 创建 ImageReader 时指定的格式、尺寸、maxImages 决定了模块能不能把解码帧塞进去。如果 App 要 JPEG 而解码器出的是 NV21，必须在创建那一刻改掉参数，否则后面无帧可写。这是一次格式协商，不是可有可无的点缀。

样本侧写：VCAM Pro+ 2.2

VCAM Pro+ 2.2（com.nqcmod.tool，越南语商业模块，2026 年 7 月构建，纯 Java、零 native 载荷）是本文所分析样本中 hook 面最完整的类别一工具。它定位到 27 个 hook 目标，按层分组：

买家拿到的是一个其貌不扬的模块 APK：主界面负责选素材、配开关，运行期的控制全靠一个悬浮球——在目标 App 里就能实时开关模块、切换图片模式、调整旋转，不必回到主界面；销售走 Zalo 私域群，自建授权服务器，按“Pro+”“超级 VIP Pro”这类分级命名定价。

模块自身未设置包名过滤，作用域由操作者在 LSPosed 中选择，一次配置可覆盖多个 App。素材与配置落在外部存储固定目录，目录名 /DCIM/TreoLive/ 与 Shopee 静默模式一起，指向直播挂机等核验之外的场景。

这个样本还有工程质量上的弱点：配置经一个导出且无权限保护的 ContentProvider 跨进程分发，设备上其他 App 可以读写它的开关与素材；AES/HMAC 密钥放在客户端，Hook 侧又未见 license 校验。三者叠加，授权约束较弱，也增加了配置被其他应用改写的可能。代码能力不能直接证明实际业务效果。

能力边界与暴露面

VCAM Pro+ 2.2 这个样本的能力边界很清楚：纯被动播放本地文件，未见活体对抗或网络帧来源，作用范围限于勾选的作用域内 App；样本代码没有显示针对交互式与炫彩活体的应答能力。hook 清单里没有任何 androidx.camera 目标，对 CameraX 应用是否生效未经验证。

它的暴露面也不只在系统深处；安装包与目标 App 进程都可能留下线索：

一句话收束：类别一部署门槛较低，痕迹主要留在业务进程及工具安装包里。

三、类别二：在 cameraserver 的出水口改水

类别一需要选定要作用的 App。类别二则转向 Android 常规相机链路中的公共服务 cameraserver：在所分析的样本中，载荷进入这个进程，在输出缓冲交付前改写像素，因而可能影响多个相机客户端。在供水比喻里，它是市政总管；改动发生在总管内，痕迹和故障风险也集中在这里。

使用前提：设备必须 Root。附加 cameraserver、向它的地址空间写入、让它“自己”执行装载器，都是对系统进程的 ptrace 操作，普通应用权限无法触碰；SELinux Enforcing 下附加还会被直接拒绝，工具必须能临时切换 Permissive——这同样要 Root。商业形态因此以“软件＋卡密”为主：卖家不碰设备，买家自备一台已 Root 的手机。

┌┄ 控制与素材｜位置随工具家族而异 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐
┆ 控制 App → 向系统服务内载荷发送命令 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;┆
┆ 视频/网络流 → 解码或共享帧池 → 替代帧 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;┆
└┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ 控制与替代帧进入系统相机服务
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ▼
┌┄ 系统软件层｜cameraserver ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐
┆ ① 载荷进入相机服务 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
┆ ② 接管输出缓冲交付点 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
┆ 真实 HAL 帧 → ③ 在同一输出缓冲中改写像素 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
┆ 缓冲沿原相机链继续交付 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
└┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ ④ 缓冲沿原路径交付
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ▼
┌┄ 应用层｜业务 App ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐
┆ BufferQueue → Camera API → 人脸 SDK 读取已改写帧 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
└┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘

类别二：cameraserver 内写帧的工作顺序

图二｜真实相机链路先产出缓冲；载荷在 cameraserver 的交付点把替代像素写入其中，缓冲随后沿原路径进入 App。图中小素材块只表示替代帧来源，具体解码位置因工具家族而异。

整个动作分四步：把载荷送进总管 → 在闸口下钩 → 帧到写像素 → 应答活体挑战。

步骤一：七步把载荷送进总管

注入器 vcplax 以 Root 权限对 cameraserver 执行一次经典的进程注入，控制流已由真实二进制的反汇编闭合：

从进程信息定位 cameraserver；
附加（ptrace）目标，等待其进入可控状态；
保存目标线程的寄存器现场；
按本地/远端模块基址，换算远端加载器函数的地址；
把载荷路径与初始化参数写进目标地址空间；
改程序计数器，让目标“自己”执行 dlopen 装载与 init 调用；
恢复寄存器与执行现场，解除附加。

结果是载荷库进入系统相机服务。SELinux Enforcing 下附加会被拒绝，样本因此在注入前临时 setenforce 0、完成后切回；这段切换和进程附加行为仍可能留下审计记录。载荷就位后在进程内注册随机命名的 Binder 控制端点，供控制 App 下发播放、停止、动作区间、颜色和开关等命令。

步骤二：下钩点选在“回收闸口”

库（libvc.so）用 ShadowHook 覆盖了 Camera3OutputStream::returnBufferCheckedLocked——输出缓冲“回收检查后、交付上层前”的最后一道闸。选在这里的理由很实际：在闸内侧改写像素再放行，上层拿到的是同一块已改写的缓冲，不用换 Surface、不用改 API、不用碰任何 App。样本同时覆盖该函数的三个 ABI 变体，以兼容不同 Android 版本的 C++ 签名与参数布局，另 hook Camera3Device 的初始化与断开两个时机做状态管理。

步骤三：写入像素——写帧是一门脏活

真正把像素写进去的过程充满工程细节：

从 stream buffer 相关对象回退固定偏移，还原出 GraphicBuffer 对象——这是对目标版本对象布局的硬编码假设；
识别缓冲格式：NV21、flexible YUV、JPEG/BLOB、YV12 以及部分厂商私有布局，各走各的写法；
lock/lockYCbCr 取得平面指针与 stride，逐行写入——stride 错一个字节，画面就是斜纹；
unlock 交还，缓冲继续沿原路交付。

fence 同步、色彩空间或旋转处理不一致，都可能造成花屏、错色、撕裂或延迟；压缩或受保护的缓冲若不能按此方式映射，样本的 CPU 写帧路径就不适用。这些细节解释了适配成本：C++ 符号名、函数签名、对象布局可能随 framework 版本变化，一处假设失效就可能黑屏或崩溃。样本覆盖三个 ABI 变体、处理五种以上像素格式，正是这类成本的物证。

步骤四：应答挑战——对抗活体的“素材菜单”

替帧只解决“画面进来”，活体挑战还要“画面答对”。这一家族的对抗手段像一份点菜菜单：

受控实验曾观察到完整作用态：注入库进入映射、系统相机消费替代视频、悬浮窗里一点，画面中的人头就转过去。但同样要写清楚边界：动作时间片、取色、推流是可验证的功能，“已通过某项活体”不是——动作起止不连续、头部动力学突变、压缩噪声整体复位，仍是服务端可利用的检测面。

同一替换点的两条工程路线

两条路线换的是同一个帧，选的是不同的工程重心：前者把复杂度压进系统进程，后者把解码留在外面、只用共享内存递帧。“多品牌共用一份核心库”是这门生意供应链形态的直接证据——壳、授权系统、UI 可以换，native 核心是货架商品。

买家侧的形态也高度雷同：libvc 家族是多款按卡密售卖的“虚拟相机”应用——顶峰APEX、VcamPro、离线版、三疯硬改 Ultra 等，包名与图标分别伪装成音乐播放器、知名厂商应用等日常工具，打开后是素材选择与动作片段控制界面；CHMP4/VOLCAM 家族同样是伪装包名，改走在线授权。对使用者而言，它们看起来都只是“一个能放视频当相机画面的小应用”，真正的注入动作由随包的 native 组件在幕后完成。

暴露面与故障半径

破绽集中在总管身上：cameraserver maps 里的非系统路径与已删除 ELF、ShadowHook 跳板、随机 Binder 服务的注册者归属、SELinux 切换窗口、相机服务的异常重启。最后一条值得展开：停止不等于卸载——删除落盘文件不会从已运行的 cameraserver 里卸掉 inline hook，工具自己的恢复手段就是重启相机服务换回干净进程再注入。所以“相机服务重启”既是它的日常，也是防守方可以关联的事件信号。

故障半径同样在总管上：cameraserver 是公共服务，对象布局错误、缓冲越界、死锁，影响的不只是核验 App——扫码、视频通话、系统相机可能一起断流。控制点越公共，爆炸半径越大。

四、类别三：注册一家假水厂

类别二要进入总管并适配内部函数，framework 升级可能使适配失效。类别三改在 Provider 一侧接手：所分析的代理先连接真实 Provider，再以相机 Provider 的服务身份面向 cameraserver，把真实设备变成自己的上游。它影响该 Provider 的客户端，痕迹主要留在服务注册与供应关系上。用供水比喻说，就是注册一家假水厂，把真水厂变成上游，在画面交出前改写内容。

使用前提：代理是用户态进程，在受控实验中由 root 权限拉起并注册。商业交付还可以把代理与定制 boot.img、配套软件打包，或预装进整机；这时它同时属于类别三的换帧方式和类别四的托管方式。解锁 bootloader、替换 boot 镜像还会改变设备启动链状态，卸载控制 App 不会自动恢复。

┌┄ 准备阶段｜用户态 Provider 代理 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐
┆ ① 代理连接真实厂商 Provider，保留其采集能力 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;┆
┆ ② 代理以 Provider 身份面向 cameraserver &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;┆
└┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ 相机请求经代理转发，结果回程经过代理
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ▼
┌┄ 帧回程｜代理内部 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐
┆ 真实 Provider → ③ 代理包裹 Session / Callback &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;┆
┆ 素材帧 ───────→ ④ 改写输出缓冲中的像素 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
└┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ ⑤ 结果继续交付
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ▼
┌┄ 上层相机链 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐
┆ cameraserver → BufferQueue → App / 人脸 SDK &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;┆
└┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘

类别三：Provider 代理的工作顺序

图三｜代理先连接真实 Provider，再以相机 Provider 身份面向 cameraserver；相机结果经代理回程时，输出缓冲被改写，随后继续交付给 App。三个房间表示三个不同的运行角色。

按发生顺序展开：注册代理 → 包裹会话与回调 → 在结果回程改写像素。部署完成后，供帧通道提供素材，反馈通道尝试应答活体挑战。

步骤一：先接真水厂，再挂自己的牌

代理的注册动作只有两步，顺序却不可颠倒：

getService 取得真实厂商 Provider——镜头枚举、参数协商、请求调度这些苦活继续交给真水厂；
registerAsService 以相机 Provider 身份注册服务——在所分析的样本中，随后重新绑定的 cameraserver 从代理取得 Provider 接口。

先 getService 是为了保留真实 Provider 的接口对象，使代理能把硬件工作转给上游，自己主要负责包裹回调与改写画面。这也决定了兼容性成本落在厂商 HAL 接口版本、缓冲格式和固件行为上。样本代理链接 Provider 2.4–2.7、Device 3.2–3.7 的接口族，显示出跨版本适配的意图。

步骤二：三层包裹与回程写帧

代理对 cameraserver 传来的 Device、Session、Callback 各包一层代理对象：下行调用原样转发，**上行 capture result 先经代理再交 cameraserver**。写帧发生在回程里，五步：

截获 capture result 与输出缓冲的 native_handle；
native_handle_clone 克隆句柄，经 importBufferNoValidate 导入；
GraphicBufferMapper 的 lock/lockYCbCr 把缓冲映射成可写像素地址；
按宽高、裁剪区、stride、旋转、镜像与 UBWC 压缩配置写入解码帧；
unlock，调用原 Callback 把结果照常交给 cameraserver。

对上层而言，相机枚举与请求接口表面上仍按预期工作，因为真实 Provider 仍承担硬件侧工作；但回程画面已被代理改写，不能因此推断帧的来源和时序也正常。

步骤三：供帧与反馈——五条数据管道

这一类不是只有“视频文件替换相机”一条路，而是把不同数据按用途分流成五条管道：

管道分流的工程含义是控制、供帧、反馈各走各的通道。控制 App 与代理并非同一个进程，帧源也可以独立更换；业务 App 仍通过相机接口接收画面。

步骤四：活体对抗变成主动工程

类别一的 VCAM Pro+ 样本未显示交互式与炫彩活体应答能力；这一组 Provider 代理及配套工具则尝试用动作检索和实时反馈回应挑战：

挑战提示、反馈、素材调整与供帧构成的概念闭环

挑战反馈闭环｜① App 显示动作或光照提示；② 反馈环把可见提示与画面状态传给控制端；③ 控制端选择片段或调整画面；④ 供帧模块把结果送回 App 的相机画面。虚线表示反馈，实线表示供帧。这是多种样本能力的概念组合，不表示每款工具都具备完整闭环，更不表示已通过真实业务核验。

动作预索引：ActionScanner 用 MediaPipe 人脸关键点把长视频预先切成五类动作（张嘴、眨眼、点头、左转、右转）的最佳片段，抽取 yaw/pitch/张口度/眨眼指标、按自适应阈值选段——把随机挑战翻译成可检索的答案库；
取色反馈环：fast_color 经 SurfaceFlinger 的 captureDisplay 截屏取色；控制端自己打开前摄，在 640×480 画面上检测人脸轮廓与关键点、经 UDP 送给代理；配合代理的光照/亮度/对比度/伽马/旋转/缩放命令族，形成一个由操作者调节的实时反馈环；
跨设备中继：这是一对配合使用的普通外观 Android 应用。发送端 KIMA 自身没有相机权限、不含任何注入代码，负责把选好的照片或循环视频渲染到 1280×720 画布上，以 30fps 的 JPEG 帧流（帧头带魔数与平移/缩放参数）经 TCP 推出。接收端 FaceGate 带预览界面，校验帧头后向多个下游客户端广播；收款走 USDT、客服在 Telegram。两者用同一把 AOSP 平台密钥签名，指向同一个固件生态。FaceGate 的宣传界面写着“HOOK CAMERA”“kernel module”，代码里却未见对应实现。这些样本能证明画面生产端与接收端可以分离，不能单凭它们证明存在异地真人实时参与。

配套能力：设备身份变成派生函数

画面伪造之外，同一控制端还负责“设备是真的”这半件事：单个 seed 经 HMAC-SHA256 按标签派生十二项格式合法的身份字段——序列号、SoC serial、boot ID、Wi-Fi/蓝牙 MAC（正确设置本地管理位）、Android ID、双 IMEI（结合 TAC 并补齐 Luhn 校验位）、MEID、modem 序列号、存储标识。切换模板即切换整机人格；身份伪造与画面伪造协同工作，“内容是真的”和“设备是真的”两个假设同时失效。

受控实验显示：一台满负荷的饮水机

实验对象是一套按整机售卖的 K60 改机工具包：交易包含定制 boot、HAL 代理、一个包名仿冒知名美颜相机应用的控制 App，以及接收桌面帧的 USB 外设配件；动作素材的预索引与取色反馈都由控制 App 完成。

在匹配设备（Redmi K60、原厂 Android 15）上的受控实验里：代理以 root 注册为系统相机 Provider、cameraserver 重新枚举、身份字段被整体改写而硬件证明面仍报“未锁/未验证”；装入控制 App 后，系统相机确实消费了替代画面——然后卡了：预览帧推进率约 2.4 帧/秒，代理接近占满一个 CPU 核。“系统级供应者”的外观下是一台满负荷的饮水机。这次实验中的低帧率与高负载说明该样本尚未达到流畅预览，也为观察其运行状态提供了线索。

暴露面：从进程移到供应关系

这一类的线索主要在 Provider 的供应关系和代理运行状态上：服务名的注册来源、HAL 二进制的路径/签名/Build ID、cam_hal_ctrl 等 IPC 与 FIFO/共享文件、相关服务的重启，以及代理的负载与帧时序。这些信息主要需要系统侧或厂商侧的观察能力。

五、类别四：把假水厂写进市政规划

类别三的代理是用户态进程，停止运行后替帧也会停止。类别四回答的是怎样让它持续在场：把代理的部署、认证与拉起写进设备的开机流程。即使运行中的代理被清除，后续启动仍可能重新部署它。这种方式继承类别三的影响范围，并在启动链和镜像上增加痕迹。在所分析的样本中，内核并不直接换帧；换帧的仍是用户态代理，内核负责保存载荷、认证、启动和监护。

使用前提：设备需解锁 bootloader，并刷入含载荷的定制 boot 镜像。卖家可以交付 boot.img 与配套软件供买家部署，也可以交付已刷好的整机。后一种情况下，买家无需自己执行 Root 或刷机；对设备而言，BL 解锁状态和非官方 boot 镜像不会因卸载控制 App 而消失。

┌┄ 启动链｜定制 boot / kernel ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐
┆ ① boot 携带代理载荷与启动逻辑 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;┆
┆ ② 开机时部署组件、准备运行环境 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
┆ ③ 拉起并监护用户态代理 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
└┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ 只负责部署与运行，不直接修改相机帧
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ▼
┌┄ 系统软件层｜用户态 Provider 代理 ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐
┆ ④ 代理在结果回程改写输出缓冲 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
┆ 真实 Provider → 代理 → cameraserver → App / 人脸 SDK &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ┆
└┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┘

类别四：启动链托管 Provider 代理的工作顺序

图四｜boot/kernel 负责携带载荷、开机部署、拉起与监护；实际换帧仍由系统软件层的用户态 Provider 代理完成。虚线是启动与控制关系，不表示内核直接修改相机帧。

按刷机—开机—运行的顺序：载荷随刷机进入 boot，开机时内核拉起脚本完成编排，运行期由被改造的完整性机制负责监护。

步骤一：载荷藏进 boot 镜像

定制 boot 镜像内嵌了三个载荷：HAL/Provider 代理（3.3MB 的 ARM64 可执行体）、fast_color 取色守护、以及一个 TensorFlow Lite JNI 库（配合动作识别）。两种藏法：

免 Root 版——“免 Root”指买家零操作：一切已预装固件。载荷以明文 ELF 直接保存在 boot 镜像的固定偏移，离线扫描可以直接 carve 出来；
改造版：相同偏移保存的是高熵封装（实测熵约 7.99 bit/byte，接近随机数据），启动期由内核里的 fw_deploy 模块释放——针对明文 ELF 的离线字符串扫描对它失效，但部署路径、进程与启动行为依然会产生可检测面。

步骤二：开机脚本的编排

内核经 call_usermodehelper 拉起内嵌脚本，脚本的完整动作序列：

等待 sys.boot_completed；
读取 SoC serial，设置代理的授权环境变量；
在控制 App 私有目录创建 cam_stream FIFO 与固定大小的 color_thumb 文件；
修正属主、权限与 SELinux 上下文；
stop/start 厂商 camera-provider 服务；
杀死 cameraserver → 启动代理 → 再杀一次 cameraserver；
启动 fast_color 取色守护，并把代理进程放进前台 cpuset 保住调度优先级。

第 6 步的反复重启服务，是为了让后续相机会话在代理就绪后重新取得 Provider 接口。这里的重点不是“内核写帧”，而是让系统相机服务在开机过程中转向用户态代理，无需逐个修改目标 App。

步骤三：运行期监护——dm-verity 从守门员变成监护人

另一款整机固件包样本 Y700（Android 16，同样按预装整机售卖）走得更远：dm-verity 扩展里加入了 proxy auth OK/FAILED 与心跳/再质询逻辑。dm-verity 本应是 Android 完整性校验的守门员——在这里被改造成代理的监护人：开机时校验代理的“授权”，运行期靠心跳确认代理活着。完整性机制为攻击组件站岗，是这一类在工程上最刺眼的反转。持久化的后果也直接：恢复出厂未必清除被替换的 boot；可信恢复通常需要用官方全量镜像重建 Verified Boot 信任。

营销与事实：内核相机并不在内核里换帧

这类工具的宣传话术是“内核级注入”“内核相机”，但所分析样本没有给出内核直接换帧的证据。样本内核里那些看似可疑的符号，逐个核对后各有出处：fake_inject_* 是上游 Linux EDAC 内存错误测试字段；kp_* 是 slab 调试结构 kmem_obj_info 的普通成员；v4l2_*replace 是标准 V4L2 控制/事件队列辅助函数；QBUF/DQBUF 是视频子系统的常规操作。要证实“内核直接替帧”，还需要定位帧路径新增调用、追踪缓冲在交付前被改写，或在移除用户态代理后仍观察到替帧。现有材料不支持这一结论。

类别三与类别四到底差在哪

两者常被混为一谈，因为类别四的设备上跑的就是类别三的代理。差别不在“谁换帧”，而在“谁保证换帧者在场”：

区分两者，要看代理由谁拉起，以及 boot 中是否包含载荷与认证逻辑。类别四是类别三代理的一种托管方案，并非另一处换帧点；其额外线索落在启动链上，包括 AVB/Verified Boot 状态、boot/内核镜像、非官方 dm-verity 扩展和部署目录的开机重建。

六、三处换帧点与启动链托管：商业形态对照

下表把三个换帧位置和一种托管方式放在一起比较。类别三与类别四可以叠加在同一商品里：同一台预装整机既由 Provider 代理换帧，也由启动链负责拉起代理。

三处换帧位置与启动链托管关系总览

全篇对照图｜蓝色实线是相机画面从硬件经 Provider、cameraserver 到 App 的交付方向。①在 App 进程内改接画面入口，②在 cameraserver 内改写输出，③由 Provider 代理在结果交出前改写；它们是三处不同的换帧点。④位于启动链，红色虚线只表示它部署并维持③的代理，不表示 boot 直接处理图像帧。三个换帧点是不同工具的可选位置，并非一张画面必须依次经过三次替换。

“真实帧是否流向 App”说明前三处换帧点的关键差别：所分析的类别二、三样本在真实帧产生后改写像素；类别一的主要路径则把真实帧导向替身，由素材填充 App 的接收面，Camera1 字节回调是例外。类别四沿用类别三的换帧方式。

货架上的样本长什么样

文中引用的样本与配套商品，从按卡密售卖的应用到预装整机：

| 类别 | 样本 | 买家拿到的是什么 |
| — | — | — |
| 一 | VCamera | “应用多开”式工具应用：把目标 App 克隆进自控空间运行，内置真实相机/本地视频/网络流/图片四模式素材界面；广告＋应用内购买变现 |
| 一 | VCAM Pro+ 2.2 | LSPosed 模块 APK：勾选目标 App、选素材，悬浮球实时控制；Zalo 私域销售、分级定价，直播挂机场景专用目录 |
| 二 | libvc/vcplax 家族（顶峰APEX、VcamPro、离线版、三疯硬改 Ultra 等） | 卡密激活的“虚拟相机”应用：包名图标伪装成音乐播放器、知名厂商应用；多品牌共用同一份注入核心 |
| 二 | CHMP4/VOLCAM 家族 | 同上模式，注入器自带解码器、走在线授权；两个品牌主程序仅 25 字节差异 |
| 三 | K60 改机工具包 | 整机：定制 boot＋HAL 代理＋包名仿冒美颜相机应用的控制 App＋USB 接帧配件 |
| 配套帧源 | KIMA＋FaceGate | 跨设备帧流组合，本身不是 Provider 代理：发送端渲染发帧，接收端转发；“kernel module”是宣传用语，样本代码未见对应实现 |
| 四 | K60 改造版／Y700 固件包 | 预装整机：前者在 boot 内封装载荷，后者加入代理认证与监护；买家无需自行部署 |

这些是不同控制深度的商业形态，并非同一产品依次升级的历史。样本货架上既有进程内模块，也有系统服务工具、Provider 代理和预装整机；同一商品还可能同时包含换帧组件、启动托管和远端帧源。

从痕迹看，这些工具把异常留在不同位置：类别一偏向目标 App 进程，类别二在系统相机服务，类别三涉及 Provider 的供应关系，类别四又增加启动链变化。控制位置不同，观察位置也随之改变。

七、这门生意不只卖换帧

前面三处换帧点解决的是“画面怎样进入 App”。样本和商品界面还显示，卖家在围绕这条链路打包素材、控制端、设备环境与售后：

素材与挑战应答：预录动作片段、屏幕取色和人脸位置反馈，让操作者能够按提示切换或调整画面。这些功能说明工具尝试回应活体挑战，不等于它已经通过真实业务核验。
声音与其他媒体：VCAM Pro+ 样本内置四组音轨播放对象，并处理多播放器互斥，表明它考虑了视频通话和直播中的声音体验。这里能确认的是素材音轨播放，样本分析未见接管麦克风采集的证据。
设备环境与持续运行：K60 工具包能按同一 seed 生成多项设备身份字段，预装固件则负责在开机时部署代理。两者补的是换帧之外的环境和运行问题。
商品包装与销售：伪装包名、同一份 libvc.so 被多个品牌复用、卡密激活和私域售后，显示核心能力可以被反复包装；宣传中的“内核相机”仍需与实际代码分开看。
更多使用场景：TreoLive 目录、轮播素材和 Shopee 静默模式表明，部分工具同时瞄准直播挂机等场景，卖点不只是一轮人脸核验。

从一张能动的“假脸”到 App 里看似实时的相机画面，中间还需要素材、供帧、换帧和部署接力。

结语：画面从哪里来

三处换帧点改变的是画面进入 App 的位置；启动链托管解决的是代理如何持续在场。同一件商品可以把换帧、供帧和托管组合起来，因此不能仅凭画面像真人、Camera API 正常返回，就认定镜头前确有本人。

这门生意出售的是对画面交付链的控制。要理解一款工具，先看它在哪一站接手画面，再看它如何供帧、由谁拉起，以及痕迹留在何处。

感谢阅读～

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：帅仔回忆录 qianlan
qianlan《风控检测_人脸注入，镜头也会说谎》

Tags: 渗透测试红队

你可能错过

鼎信安全 | 网络安全一周资讯

长亭科技获2026年度CCF科技成果进步奖

奇安信亮相第23届中国—东盟博览会

中年失业第 100 天：老婆终于说出了那句话