[原创]某游戏作弊样本分析-Android安全-看雪安全社区

[原创]某游戏作弊样本分析

发表于: 2026-8-5 17:32 23822

[原创]某游戏作弊样本分析

mb_nkjfyhkg 活跃值

2026-8-5 17:32

23822

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

**样本：** `Loader.apk`（包名 `com.lethal.visionx`）及其已下载的 `aorus.*` 原生组件  
**方法：** 汇总当前工作区已有的离线 DEX/ELF 静态分析结果；未运行 APK、未访问其远程服务、未对游戏进程实施调试或写入。  
>起因是在某反作弊检测业务的字符串池中发现了so名称，以为是什么牛逼技术，就寻找了一下样本，结果是一份非常简单的样本，甚至分析过程中发现用的注入器都是我开源的

## 1. 摘要

该样本是一个面向 Android UE4 射击游戏的作弊加载器。Java/Kotlin 层承担用户交互、远程依赖更新、许可证认证、运行模式选择和原生库加载；Root 路线则将下载的原生组件部署到目标游戏私有目录，再通过进程附加和远程加载使核心功能库进入游戏进程。
> app打开就自动拉取远程文件，以我对这圈子的了解，然后ida一看字符串基本都是明文，就知道没意思了

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

## 2. 样本与证据

| 项目 | 值 |
| --- | --- |
| APK | `Loader.apk` |
| APK SHA-256 | `74E25ED04A3503C9B3381939888337BE418506F698730593112690C62B2A39D2` |
| DEX SHA-256 | `80BF63AC681A5C78B17B35CD0FCADCC259F5CD3E4728781802AA5CB2CD7D178E` |
| Root 部署器 | `aorus.loader_r`：`478992DBB798EEBA543A9D526653B8729A1AD095C67651649012A3DEC416A822` |
| 注入辅助组件 | `aorus.zygote.arm64`：`37FFDFB9320FFC3CC2961FDBD9369330E13B9BB11627EF59380363F993B2CDC7` |
| 游戏进程核心库 | `aorus.core.so`：`7406E7501DD6E16CA9EBB5C7A725D6C32ED82FC731F866E816204495BBD5E8D8` |

## 3. 总体行为链

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

## 4. Java/Kotlin 层分析

### 4.1 角色与主要组件

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

| 组件 | 静态确认职责 |
| --- | --- |
| `UpdateActivity` | 获取依赖清单、下载和校验更新载荷。 |
| `LoginActivity` | 向认证服务提交许可证与设备标识，并保存认证状态。 |
| `ModeActivity` | 保存游戏、语言和 Root/免 Root 模式选择。 |
| `MainActivity` | 生成配置、识别支持的游戏并触发后续部署或启动。 |
| `HTTPHelper` / `FileHelper` | 网络请求、临时文件写入、复制与 MD5 校验。 |
| `ProcessHelper` | 执行 `su` 相关的特权辅助操作。 |
| `App.App` | Mundo plugin 回调内按私有路径加载核心 SO。 |

### 4.2 远程载荷与更新

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

### 4.3 认证、设备标识与配置

登录逻辑向 `<mark class="encrypted">0d9K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6S2M7r3W2Q4x3X3g2^5P5s2S2^5P5s2S2Q4x3V1k6D9L8$3N6A6L8W2)9$3x3l9`.`.</mark> 发送 `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 就绪，然后调用注入辅助组件定位目标进程。该组件具备下列静态可确认能力：

| 行为 | 风险含义 |
| --- | --- |
| 停止并附加目标进程 | 通过信号与 `ptrace` 控制游戏进程执行。 |
| 读写远程寄存器/内存上下文 | 支持在目标地址空间内安排加载和入口调用。 |
| 远程加载核心库 | 将 `aorus.core.so` 映射为游戏进程内的 `libaorus.so`。 |
| 非标准 JNI 初始化握手 | 仅以特定保留参数调用 `JNI_OnLoad` 时，core 才创建业务初始化线程。 |
| 注入失败处置 | 某些失败分支会终止目标游戏进程，存在可用性影响。 |

### 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` 标识的安全事件链。

登录后可查看完整内容

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！

收藏・1

点赞・3

打赏