1:前情提要
现在做的是一个直播项目,前两天运营反馈,有人录制我们项目的视频发布到其他平台上,当时忽然想起来了加上了虚拟机,和禁止录屏的代码了,为什么又出来了.
第一反应 物理录屏,对 绝壁是这样 绝对是物理录屏,秒回,一点都不带犹豫的.
...天后
打脸来了 万能的x鱼 特么有软件可 打开我们的APP 然后跨过我们的限制 直接录屏,直接怼脸上了,甚至发来了教程和买的APP.狗日的....只能脑补肝代码了.
2.需求分析
虚拟环境分类
- 模拟器(虚拟机,夜神,雷电等)
- 虚拟空间(多开 / 虚拟空间 / 分身等)
2.1 虚拟机
字面意思,软件运行到了虚拟机上,然后通过虚拟机录屏 就可以了
解决方案 : 禁用虚拟机上运行自身APP
2.2 虚拟空间 （四类常见实现方式）
-
宿主/沙箱（Host-based virtualizer）
我们是被这种坑的- 思路：
一个宿主 App（虚拟空间）在自身进程中加载目标 APK（Dex/Resources），并把目标 App 的运行环境映射到宿主进程内（例如 VirtualApp、Parallel Space）。 - 优点：
无需系统权限即可实现，比较常见。 - 缺点：复杂、容易被检测（classloader、maps、proc 信息暴露），处理 native 库和签名较难。
- 思路：
-
多用户/工作配置（System-level / OEM）
- 思路：Android 系统层通过多用户或工作配置（Work Profile）创建独立用户空间，让同一 APK 以不同用户安装。
- 优点：系统级隔离，兼容性最好，难被检测为“跨进程注入”。
- 缺点：
需系统/厂商支持或特殊权限（OEM 实现）。
-
容器/命名空间（Container / Root/Platform）
- 思路：借助 Linux 命名空间（mount、user、pid、net）和 chroot 等创建独立运行环境（通常需要 root 或系统权限）。
- 优点：隔离强，文件系统/进程/网络等均可隔离。
- 缺点：
需要特权，不能在普通应用中使用。
-
注入/Hook（In-process hooking）
- 思路：
通过 Xposed、Frida 等框架，在目标进程注入代码或 hook 系统服务来改变运行时行为。 - 优点：能力强、灵活。
- 缺点：易被安全检测拦截；需要特殊环境（root / magisk / module）。
- 思路：
总结:
- 容器/命名空间和多用户/工作配置这两种方案,需要特殊权限,Root或者定制系统,都Root和定制系统了,后续研究(谁行谁上)
- 注入/Hook Android 高版本禁止对关键代码动态代理 HOOK难度上升,所以此方案越来越少(代码中动态,逻辑也能实现实现禁止,如延时处理禁止录屏)
宿主/沙箱（Host-based virtualizer）现在的虚拟空间常见方案,重点防御
3:梳理后的总结
- 容器/命名空间 (未处理)
- 多用户/工作配置 (未处理)
- 虚拟机-->直接禁止运行在虚拟机上
- 虚拟空间
- HOOK 延时或者接口控制是否可以禁止录屏
- 宿主/沙箱 检测是否运行在沙盒环境内
难点:
虚拟环境检测
