某游戏作弊样本分析：Java 层与 Root 路线

样本： Loader.apk（包名 com.lethal.visionx）及其已下载的 aorus.* 原生组件
方法： 汇总当前工作区已有的离线 DEX/ELF 静态分析结果；未运行 APK、未访问其远程服务、未对游戏进程实施调试或写入。

起因是在某反作弊检测业务的字符串池中发现了so名称，以为是什么牛逼技术，就寻找了一下样本，结果是一份非常简单的样本，甚至分析过程中发现用的注入器都是我开源的

1. 摘要

该样本是一个面向 Android UE4 射击游戏的作弊加载器。Java/Kotlin 层承担用户交互、远程依赖更新、许可证认证、运行模式选择和原生库加载；Root 路线则将下载的原生组件部署到目标游戏私有目录，再通过进程附加和远程加载使核心功能库进入游戏进程。

app打开就自动拉取远程文件，以我对这圈子的了解，然后ida一看字符串基本都是明文，就知道没意思了

核心库包含游戏内叠加层、ESP、雷达、和 Silent 瞄准相关逻辑；同时具备针对目标反作弊模块安装内联 Hook、转发或覆盖部分系统调用返回值的框架。

2. 样本与证据

3. 总体行为链

Loader APK
  -> 下载并校验独立原生组件
  -> 许可证认证与目标游戏/模式选择
  -> Root：特权部署 -> 注入器 -> 目标游戏进程内 core
  -> 免 Root：Mundo 虚拟化 -> plugin 回调 -> 私有 core 加载
  -> core 等待 UE4 与反作弊模块 -> 叠加/瞄准功能与 Hook 初始化

4. Java/Kotlin 层分析

4.1 角色与主要组件

DEX 中的 com.lethal.visionx 业务类形成了加载器的控制平面：

4.2 远程载荷与更新

UpdateActivity 会访问 https://xxxxxxx，从清单中读取下载地址与 MD5，处理包括 Root 部署器、注入辅助组件和核心库在内的独立依赖。文件先以 .part 临时文件写入，校验后再作为正式依赖使用。

4.3 认证、设备标识与配置

登录逻辑向 c0eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6S2M7r3W2Q4x3X3g2^5P5s2S2^5P5s2S2Q4x3V1k6D9L8$3N6A6L8R3`.`. 发送 key 和 hwid 字段。许可证会保存到 app_config/license 及 /license.txt，地区或 locale 信息也会进入本地状态。

模式选择结果会与游戏、语言一同写入配置。支持的目标包含 Delta Force 区域变体，此外还存在其他射击游戏的分支。配置文件是原生 core 的直接输入，而不仅是前端 UI 状态。

4.4 Root 与免 Root 分流

Root 分支通过 su 准备工作目录、复制下载组件并启动原生部署器；代码还会尝试改变 Android 的 untrusted-touch blocking 设置。此分支的目的在于为后续进入目标游戏私有目录和进程注入建立权限条件。

免 Root 分支使用 Mundo/LSPlant 虚拟化 SDK。它把 aorus.core.so 复制到自身私有目录并重命名为 libaorus.so，随后通过 MetaActivityManager.launchApp 启动目标应用；在 plugin 上下文回调中调用 System.load()。静态结果能确认核心库在受控容器流程中被加载，但不能仅凭此证明其最终映射到目标游戏的哪个 PID。

4.5 APK 自保护与反分析边界

APK 的 MundoSupervisorProvider 会在常规 Application 启动前加载 libmsaoaidsec.so。该库实现 DEX CRC 门控、受保护的 NAOP 载荷映射、私有符号解析和主进程反分析检查；已确认的检查包括 TracerPid、暂停线程、特定 Frida 线程/FD/ELF 痕迹，以及 ART 函数入口的简化跳板特征。

外层库还具备受运行时门控的 MAGISKTMP、x86 Dalvik 缓存和 APK/Split 安装布局检查。应注意：这些是加载器 APK 自身的保护和环境对抗能力，不能与后续 aorus.* 对游戏反作弊的干预行为混为同一模块或同一目的。

5. Root 权限下的分析

5.1 特权部署

Root 部署器以 /data/local/tmp/aorus-loader 为工作目录，读取配置中的目标包名和许可证字段，并验证目标应用的数据目录存在。随后将配置、字体、注入辅助组件和核心库写入目标游戏的 aorus-files 子目录。

5.2 目标进程控制与库加载

部署器可启动目标 UE4 游戏或等待其 UI 就绪，然后调用注入辅助组件定位目标进程。该组件具备下列静态可确认能力：

5.3 可选隐藏与取证对抗

若 Root 工作目录存在 spoof.txt，部署器会启用内存映射和 linker 列表隐藏相关选项。注入组件包含对已加载段进行远程重映射、以及处理 linker/NativeBridge solist 记录的路径，其目的是降低核心库在常规 /proc/<pid>/maps 或链接器枚举中的可见性。

5.4 core 的游戏作弊功能

核心库被成功加载后，会等待 libUE4.so 以及按目标包名选择的反作弊库，再读取配置并进入 DFM 的 UE4 类处理分支。可确认的游戏功能包括：

• ImGui 图形叠加层与菜单；
• 实体遍历、玩家/AI 过滤、距离和状态过滤；
• 雷达、方框、文本和计数等 ESP 类绘制；
• 基于 FOV 的候选目标选择；
• AASilent/Silent 路径中的目标坐标和旋转计算，以及对游戏内部回调输出的替换。

5.5 反作弊模块干预

对于 com.xxxx，core 选择 libanogs.so；对于 com.xxxxx，则选择 libtersafe.so。两条路线共用一套 Hook 框架：在目标反作弊模块就绪后，core 为动态入口、固定入口及函数表项建立候选 Hook，成功时将目标函数开头改写为跳转至 core 回调的指令序列。

统一回调会保存调用上下文，进入中央系统调用分发器；监听器可要求覆盖返回值，否则走直接系统调用桥。已确认的显式处理范围包括文件/路径检查、ptrace、内存映射与权限、跨进程内存读写、seccomp 及网络连接等类别。

com.xxxx 的 anogs 分支还具有更强的交叉证据：core 的内联改写会覆盖 anogs 用于 CRC32 自校验的函数首部，相关完整性差异可进入以 bad_sc 和 vap_2.5 标识的安全事件链。

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。