# BotGuard-Android Phase 1 MVP 检测后专家团测评报告
> 评审日期：2026-07-15
> 评审对象：BotGuard-Android Phase 1 MVP（4 模块 37 项检测，27 Kotlin 文件 + 16 JSON 资源）
> 评审范围：检测能力覆盖度、代码质量、架构合理性、误报/漏报风险、用户体验
---
## 评审团阵容
| 序号 | 专家身份 | 评审维度 | 评分 |
|:---:|---------|---------|:---:|
| E1 | 安全研究专家 | 威胁模型覆盖度 / IoC 质量 / 攻击面 | 7.5/10 |
| E2 | Android 底层开发专家 | API 使用 / 权限模型 / 系统集成 | 7.0/10 |
| E3 | 恶意软件分析专家 | 检测逻辑 / 反规避能力 / FP/FN 率 | 6.5/10 |
| E4 | 软件架构专家 | 模块化 / 可扩展性 / DI 设计 | 8.0/10 |
| E5 | 质量保障专家 | 测试覆盖 / 异常处理 / 边界条件 | 6.0/10 |
| E6 | 用户体验专家 | 报告可读性 / 动作可执行性 / 引导 | 7.5/10 |
**综合评分：7.1 / 10** — MVP 达标，核心检测能力可用，但存在多处需在 Phase 2 优先修复的问题。
---
## E1 · 安全研究专家评审
### 1.1 威胁模型覆盖度
**亮点：**
- 覆盖了 Android 僵尸网络四大核心维度：行为审计（A5）、应用审计（A2）、持久化审计（A3）、环境检测（A6），维度划分逻辑清晰
- 6 个僵尸网络家族 IoC（Kimwolf / Vo1d / BTMOB / Rafel / Anubis / Cerberus）覆盖了 2023-2025 年最活跃的移动端僵尸网络
- MITRE ATT&CK Mobile 框架映射 18 项技术，每个 Finding 都关联了 ATT&CK ID，可追溯攻击链
**问题：**
| 编号 | 问题 | 严重性 | 说明 |
|:---:|------|:---:|------|
| S-01 | **C2 通信检测缺失** | 🔴 高 | 4 个模块均未实际执行网络流量到 C2 IP/域名的匹配。A5-05 虽检测异常流量，但未与 IoCLoader 的 `isC2Ip()` / `isC2Domain()` 联动。IoCLoader 实现了查询接口，但没有任何模块调用它 |
| S-02 | **DNS 检测缺失** | 🟠 中 | 未检测 DNS 请求是否指向已知 DGA 域名。IoCLoader 已加载 `dga-patterns.json`，但无模块使用 `loadDgaPatterns()` |
| S-03 | **网络连接审计缺失** | 🟠 中 | 未检测当前活跃的 TCP 连接是否指向可疑 IP。`/proc/net/tcp` 和 `/proc/net/tcp6` 是无 Root 也能读取的，但未被利用 |
| S-04 | **VPN 隧道检测缺失** | 🟡 低 | 僵尸网络（如 Kimwolf）使用 Tor 代理隐藏 C2 通信，但未检测 VPN 服务和 Orbot 代理 |
| S-05 | **IoC 与检测模块脱节** | 🔴 高 | IocLoader 的 `isMaliciousProcess()` / `isMaliciousFile()` 方法已实现，但 A5-06（CPU 异常）解析出进程名后未调用 `isMaliciousProcess()`，A3-10（tmp 残留）硬编码了 Kimwolf 文件名而非查询 IoC |
### 1.2 IoC 数据质量
**亮点：**
- 家族 IoC 结构完整：包含进程名、C2 域名、文件路径、Socket、下载器 IP、持久化机制、ADB 端口、Tor 代理等 10 个维度
- 白名单体系完善：系统应用白名单（50+）、无图标应用白名单（25+）、高耗电应用白名单（30+）
**问题：**
- IoC 数据为静态 JSON，无更新机制。Phase 2 需接入在线威胁情报源（VirusTotal / AbuseIPDB / OTX）实现动态更新
- C2 IP 黑名单仅 1 个 JSON 文件，缺少 CIDR 网段匹配能力
### 1.3 改进建议
| 优先级 | 建议 | 预期收益 |
|:---:|------|---------|
| P0 | 新增 A1 网络审计模块：读取 `/proc/net/tcp` + 联动 IoCLoader 匹配 C2 IP/域名 | 检出率 +25% |
| P0 | A5-05/A5-06 检测结果联动 IocLoader 查询 | IoC 利用率 0% → 100% |
| P1 | A3-10 改用 `IocLoader.isMaliciousFile()` 替代硬编码 | 消除维护重复 |
| P2 | DNS 查询审计：解析 `/proc/net/udp` 或使用 `DnsResolver` | 补全 DGA 检测闭环 |
---
## E2 · Android 底层开发专家评审
### 2.1 API 使用正确性
**亮点：**
- 三种运行模式（NO_ROOT / ADB / ROOT）的分层设计合理，无 Root 模式下仅使用公开 API
- `Settings.Global` / `Settings.Secure` 读取方式正确
- `DevicePolicyManager.getActiveAdmins()` 和 `Settings.Secure.ENABLED_ACCESSIBILITY_SERVICES` 解析逻辑正确
- Verified Boot 状态检测通过 `ro.boot.verifiedbootstate` 属性，覆盖 green/yellow/orange/red 四种状态
**问题：**
| 编号 | 问题 | 严重性 | 说明 |
|:---:|------|:---:|------|
| D-01 | **`queryBroadcastReceivers` 用法错误** | 🔴 高 | A2-02 隐藏图标检测中使用 `pm.queryIntentActivities(launcherIntent, 0)` 查询全局 Activity 列表，然后用 `it.activityInfo.packageName == pkg.packageName` 匹配。但 `queryIntentActivities` 返回的是所有注册了 MAIN+LAUNCHER 的 Activity，不是特定包的。正确做法应使用 `pm.getPackageInfo(pkg.packageName, GET_ACTIVITIES)` 检查该包自身的 Activity |
| D-02 | **`GET_SIGNATURES` 已废弃** | 🟠 中 | A2-04 签名检测中 `GET_SIGNATURES` 在 API 28+ 已废弃，应使用 `GET_SIGNING_CERTIFICATES`。代码中对 API 28+ 使用了 `signingInfo`，但 import 中仍引入了 `GET_SIGNATURES` |
| D-03 | **`executeCommand` 权限问题** | 🟠 中 | A5/A3/A6 模块中使用 `Runtime.getRuntime().exec("sh -c ...")` 执行 `dumpsys` 等命令。在非 Root 应用中，`dumpsys batterystats` 等命令需要 shell 权限，普通应用进程无法执行。ADB 模式需要通过 ADB 连接而非应用内 exec |
| D-04 | **`NetworkStatsManager` 权限缺失** | 🟠 中 | A5-05 无 Root 模式下使用 `NetworkStatsManager.querySummaryForDevice()`，需要 `PACKAGE_USAGE_STATS` 权限（特殊权限，需用户在设置中手动授权）。代码中捕获了 `SecurityException` 但未引导用户授权 |
| D-05 | **`scanContext.onProgress` 未实际推送** | 🟡 低 | ScannerImpl 中 `onProgress` 回调为空 `{ _, _ -> }`，进度推送实际通过 Flow 的 `FindingDetected` 事件实现，但 `FindingDetected` 中 `findings.size` 是总数量而非当前序号 |
| D-06 | **`readFile("/system/etc/init")` 读取的是目录** | 🟡 低 | A3-09 `checkSystemPersistence` 中 `readFile("/system/etc/init")` 试图读取一个目录路径，`File.readText()` 会抛出异常。应改为遍历 `/system/etc/init/` 目录下的 `.rc` 文件 |
### 2.2 权限模型
**亮点：**
- 三层权限模型清晰：NO_ROOT（公开 API）/ ADB（shell 命令）/ ROOT（系统文件）
- 每个检测项标注了所需运行模式
**问题：**
- 未在 AndroidManifest.xml 中声明 `PACKAGE_USAGE_STATS` 和 `QUERY_ALL_PACKAGES` 权限
- `QUERY_ALL_PACKAGES` 在 Android 11+ 需要声明 `<queries>` 或申明合理用途，否则 Play Store 审核会拒绝
- A2 模块遍历所有已安装应用（`getInstalledPackages`），在 Android 11+ 需要处理包可见性限制
### 2.3 改进建议
| 优先级 | 建议 | 预期收益 |
|:---:|------|---------|
| P0 | 修复 D-01：A2-02 改用 `getPackageInfo` + `GET_ACTIVITIES` 检查包内 Activity | 修复误判逻辑 |
| P0 | 修复 D-06：遍历 `/system/etc/init/*.rc` 而非读目录 | 修复崩溃 |
| P1 | ADB 模式改为通过 ADB 连接执行命令，而非应用内 `Runtime.exec` | 功能可用性 |
| P1 | 声明 `QUERY_ALL_PACKAGES` 并在 Play Store 描述中说明安全工具用途 | 合规性 |
| P2 | 引导用户授权 `PACKAGE_USAGE_STATS` 权限 | 流量检测可用 |
---
## E3 · 恶意软件分析专家评审
### 3.1 检测逻辑评审
**亮点：**
- A2-01 高危权限组合检测定义了 8 种组合，覆盖了无障碍劫持、短信窃取、勒索、间谍软件等主要威胁
- A3-02 无障碍服务检测精确解析了 `ENABLED_ACCESSIBILITY_SERVICES` 格式（`ComponentName` 用 `:` 分隔）
- A3-10 `/data/local/tmp` 检测包含 ELF 文件头校验（`\u007fELF`），不是仅看文件名
- A6-06 Frida 检测覆盖 4 个维度：端口扫描（27042）、进程名、文件路径、内存映射
**问题：**
| 编号 | 问题 | 严重性 | 说明 |
|:---:|------|:---:|------|
| M-01 | **A5-04/05/06 无 Root 模式几乎无效** | 🔴 高 | A5-04 电池异常、A5-05 流量异常、A5-06 CPU 异常在 NO_ROOT 模式下只有 A5-05 有降级逻辑（NetworkStatsManager），但该逻辑不完整（`bucket.txBytes > 100MB` 后无后续动作）。A5-04 和 A5-06 在 NO_ROOT 模式下直接返回空列表。这意味着最常见的用户场景（普通手机无 Root）下，8 项行为检测只有 4 项可用 |
| M-02 | **A2-05 动态代码加载检测方式不可靠** | 🟠 中 | 通过检查 Application 类名是否包含 "DexClassLoader" / "Tinker" 等字符串来判断。但 Application 类名是开发者自定义的，恶意软件完全可以用任意类名。真正的检测应解析 DEX 文件或检查 `DexClassLoader` 的实际调用 |
| M-03 | **A2-07 非官方来源检测实际未生成 Finding** | 🟠 中 | `checkNonOfficialSource` 方法中注释说"仅做记录，不生成 Finding"，意味着 A2-07 实际不产出任何检测结果，9 项应用审计只有 8 项有效 |
| M-04 | **A2-04 签名检测在 API 28+ 几乎无效** | 🟠 中 | 代码注释说"自签名不一定是恶意，先不添加 Finding"，导致签名检测在 Android 9+ 设备上不产出任何结果 |
| M-05 | **dumpsys 输出解析正则脆弱** | 🟠 中 | A3-04/05/06/08 依赖解析 `dumpsys` 文本输出，但不同 Android 版本的输出格式差异很大。例如 A3-05 的正则 `JOB.*?u0a(\d+).*?period=(\d+)` 在 Android 12+ 的 JobScheduler 输出格式中可能不匹配 |
| M-06 | **无规避检测能力** | 🟡 低 | 恶意软件可以检测到 BotGuard 正在扫描（通过包名检测），然后暂时降低活动以规避检测。当前无反规避机制 |
| M-07 | **A2-09 服务导出检测可能大量误报** | 🟡 低 | 检查 `exported=true && permission==null` 会命中大量正常应用（如微信、QQ 的某些跨进程服务），白名单过滤不完整 |
### 3.2 误报/漏报评估
**误报风险评估：**
| 模块 | 误报风险 | 原因 |
|:---:|:---:|------|
| A5 | 🟢 低 | 设置检测项（A5-01/02/03/07/08）基于系统 API，误报率极低 |
| A2 | 🟠 中 | 权限组合检测会命中大量正常应用（如银行 App 有无障碍+网络），白名单不完整 |
| A3 | 🟠 中 | 电池白名单、开机自启检测可能命中正常应用（闹钟、运动追踪等） |
| A6 | 🟢 低 | Root/Frida/Xposed 检测基于文件系统和属性，误报率低 |
**漏报风险评估：**
| 模块 | 漏报风险 | 原因 |
|:---:|:---:|------|
| A5 | 🔴 高 | NO_ROOT 模式下 50% 检测项不可用；无网络流量 IoC 匹配 |
| A2 | 🟠 中 | 签名检测和非官方来源检测实际不产出结果；动态加载检测方式不可靠 |
| A3 | 🟡 低 | 持久化检测覆盖较全面，主要受限于运行模式 |
| A6 | 🟢 低 | 环境检测项较为可靠 |
### 3.3 改进建议
| 优先级 | 建议 | 预期收益 |
|:---:|------|---------|
| P0 | A5-05 无 Root 模式实现完整流量检测：引导用户授权 `PACKAGE_USAGE_STATS` 后按 UID 查询流量 | NO_ROOT 可用率 50% → 75% |
| P0 | A2-07 和 A2-04 要么产出 Finding 要么从 9 项中移除 | 消除"名义检测项" |
| P1 | A2-05 改为检查 DEX 文件中是否包含 `DexClassLoader` 引用（解析 classes.dex 字符串表） | 检测准确率 +40% |
| P1 | dumpsys 解析增加版本适配层，按 `Build.VERSION.SDK_INT` 选择不同正则 | 兼容性 +30% |
| P2 | 新增反规避检测：检查是否有应用监听 BotGuard 包名 | 反规避能力 |
---
## E4 · 软件架构专家评审
### 4.1 架构设计
**亮点：**
- 多模块 Gradle 架构清晰：`app` / `core` / `modules(a2/a3/a5/a6)` / `feature-scan` / `feature-report` / `data-ioc` / `di`，职责边界明确
- `ScanModule` 接口设计优秀：`moduleId` / `moduleName` / `priority` / `scan(context)` 四要素简洁但足够，新增模块只需实现接口 + 注册 DI
- `ScanPriority` 枚举遵循 NIST SP 800-86 易失性优先原则，VOLATILE → RUNNING → PERSISTENT → ENVIRONMENT 的执行顺序合理
- `RiskScore` 三维模型（severity × urgency × confidence）+ 情报加倍 + 链加分的设计有深度，区分了"严重但不确定"和"轻微但确定"的场景
- `ScannerImpl` 使用 Kotlin Flow 推送扫描进度，支持协程异步执行，UI 层可实时更新
- Hilt DI 配置集中在 `BotGuardModule`，模块注册清晰
**问题：**
| 编号 | 问题 | 严重性 | 说明 |
|:---:|------|:---:|------|
| A-01 | **ScannerImpl 硬编码 Context** | 🟠 中 | `ScannerImpl` 使用 `lateinit var androidAppContext` + `setContext()` 设置 Context，而非通过 Hilt 注入。这违反了 DI 原则，且 `lateinit` 在未设置时会崩溃 |
| A-02 | **白名单数据重复定义** | 🟠 中 | A2AppModule 和 A3PersistenceModule 各自硬编码了系统应用前缀白名单（`systemAppPrefixes`），而 IocLoader 也有 `isSystemApp()` 方法。三处白名单数据不同步 |
| A-03 | **executeCommand 在三个模块中重复实现** | 🟡 低 | A5BehaviorModule、A3PersistenceModule、A6RootEnvModule 各有一个完全相同的 `executeCommand` 私有方法。应提取到 `core` 层的 `ShellExecutor` 工具类 |
| A-04 | **Finding 的 riskScore 是计算属性** | 🟡 低 | `Finding.riskScore` 每次访问都会创建新的 `RiskScore` 对象，在排序和分组场景下可能被重复调用多次。建议缓存或使用 `val` |
| A-05 | **IoC 数据未与检测模块解耦** | 🟡 低 | IocLoader 是独立的 data 模块，但检测模块没有通过 DI 注入它，而是直接硬编码文件名查询。应通过接口注入 |
### 4.2 可扩展性
**亮点：**
- 新增检测模块只需 3 步：实现 `ScanModule` 接口 → 创建模块 build.gradle.kts → 在 `BotGuardModule` 中注册
- `ScanResult` / `Finding` / `RiskScore` 数据模型设计前向兼容，新增字段不影响已有模块
- JSON 导出格式完整，包含设备信息、模块结果、ATT&CK 映射，可对接外部 SIEM
**问题：**
- 检测模块之间无数据共享机制。例如 A6 检测到 Root 后，A3 应该知道可以执行更多检测项，但目前各模块独立运行，无法获取前序模块的结果
- 无插件化机制，新增检测项必须修改模块代码并重新编译
### 4.3 改进建议
| 优先级 | 建议 | 预期收益 |
|:---:|------|---------|
| P1 | ScannerImpl 通过 Hilt 注入 `@ApplicationContext Context` | DI 规范化 |
| P1 | 白名单统一到 IocLoader，各模块通过 DI 注入 | 消除数据重复 |
| P2 | 提取 `ShellExecutor` 到 core 层 | 代码复用 |
| P2 | ScanContext 增加 `previousFindings: List<Finding>` 字段，让后续模块可获取前序结果 | 模块协作 |
| P3 | Finding 的 riskScore 改为 `lazy` 或构造时计算 | 性能微优化 |
---
## E5 · 质量保障专家评审
### 5.1 测试覆盖
**亮点：**
- `RiskScoreTest.kt` 有 15+ 用例，覆盖了三维评分、情报加倍、链加分、边界值
- `test_core.py`（PC 端）有 20+ 用例
- `DetectionModuleTest.kt` 有 A2 模块的检测测试
**问题：**
| 编号 | 问题 | 严重性 | 说明 |
|:---:|------|:---:|------|
| Q-01 | **检测模块测试覆盖率极低** | 🔴 高 | 4 个检测模块（A5/A2/A3/A6）共 37 项检测，但只有 A2 有部分测试。A5、A3、A6 模块无任何单元测试 |
| Q-02 | **无集成测试** | 🔴 高 | 无端到端扫描测试，无法验证 4 模块联合运行的正确性 |
| Q-03 | **无模拟恶意样本测试** | 🟠 中 | 缺少使用已知恶意应用样本（如 Anubis APK）进行检测验证的测试 |
| Q-04 | **异常处理过于宽泛** | 🟠 中 | 所有模块使用 `catch (e: Exception)` 吞掉所有异常，导致检测失败时无法定位问题。应至少记录日志 |
| Q-05 | **`executeCommand` 无超时控制** | 🟠 中 | `Runtime.exec` 后 `waitFor()` 无超时，如果命令挂起会导致整个扫描卡死 |
| Q-06 | **ScannerImpl 的 `itemsScanned` 等于 `itemsFlagged`** | 🟡 低 | `ModuleResult.itemsScanned` 设为 `findings.size`，但实际扫描的项数应该大于等于发现数。例如 A2 扫描了 100 个应用但只发现 5 个问题，`itemsScanned` 应为 100 |
### 5.2 代码质量
**亮点：**
- Kotlin 代码风格一致，命名规范（camelCase 变量 / PascalCase 类）
- 每个检测项都有详细的 KDoc 注释，包含判定条件、排除规则、ATT&CK 映射
- Finding 的 severity/urgency/confidence 在 init 块中做了范围校验（1-5）
**问题：**
- 本次评审中发现并修复了 5 处 `attAttackId` 拼写错误（应为 `attAckId`），说明编译检查未覆盖全部模块
- A5 模块有重复 import（`NetworkCapabilities`），说明 lint 规则未严格执行
- 部分代码缩进不一致（A3 模块中 `attAckId` 的缩进层级不统一）
### 5.3 改进建议
| 优先级 | 建议 | 预期收益 |
|:---:|------|---------|
| P0 | 为 A5/A3/A6 模块补充单元测试，至少覆盖无 Root 模式下的检测项 | 测试覆盖 25% → 70% |
| P0 | `executeCommand` 增加 `waitFor(timeout)` 和超时中断 | 防止卡死 |
| P1 | 异常处理增加日志记录（Timber / Android Log） | 可调试性 |
| P1 | CI 中增加 `--all-modules` 编译检查，确保所有模块可编译 | 防止拼写错误 |
| P2 | 使用 Robolectric 编写集成测试，模拟完整扫描流程 | 端到端验证 |
---
## E6 · 用户体验专家评审
### 6.1 报告质量
**亮点：**
- `SimpleReportGenerator` 生成的简版报告包含：总体状态、统计计数、Top 3 问题、按优先级排序的建议动作
- 建议动作按 P1-P5 优先级分级：P1 断网 → P2 卸载 → P3 撤销权限 → P4 监控 → P5 定期扫描
- 每个 Finding 包含 `recommendedActions` 列表，给出具体的设置路径（如"设置 → 安全 → 设备管理应用"）
- JSON 导出格式完整，包含设备信息和 ATT&CK 映射，可对接专业安全工具
**问题：**
| 编号 | 问题 | 严重性 | 说明 |
|:---:|------|:---:|------|
| U-01 | **技术术语过多** | 🟠 中 | Finding 描述中大量使用技术术语（"DexClassLoader" "ATT&CK T1417" "dm-verity"），普通用户难以理解。需要两层报告：简版（用户可读）+ 详细版（安全人员可读） |
| U-02 | **无风险解释** | 🟠 中 | 报告只给出风险等级和分数，但不解释"为什么这个行为是危险的"。用户看到"异常后台流量：UID 10042"不知道这意味着什么 |
| U-03 | **A5-05 输出 UID 而非应用名** | 🟠 中 | 流量异常检测输出 "UID $uid"，用户不知道 UID 对应哪个应用。应通过 `PackageManager.getPackagesForUid()` 转换为包名 |
| U-04 | **建议动作缺少"一键操作"** | 🟡 低 | 建议动作是文字描述（"设置 → 安全 → 设备管理应用"），用户需要手动导航。Phase 2 可考虑直接跳转到对应设置页面的 Intent |
| U-05 | **无扫描历史** | 🟡 低 | 无扫描结果历史记录功能，用户无法对比前后两次扫描的变化 |
### 6.2 引导设计
**亮点：**
- 三种运行模式分层，无 Root 用户也能使用基础检测
- 设备信息收集完整（厂商、型号、Android 版本、SDK 级别、Build 指纹）
**问题：**
- 无 Root 模式下用户不知道哪些检测项被跳过了，可能产生"已扫描 = 安全"的错觉
- 缺少首次使用引导（解释为什么需要某些权限、如何开启 ADB 模式等）
### 6.3 改进建议
| 优先级 | 建议 | 预期收益 |
|:---:|------|---------|
| P1 | 简版报告增加"白话解释"字段，将技术描述翻译为用户语言 | 可读性 +50% |
| P1 | A5-05 将 UID 转换为应用名输出 | 用户可操作性 |
| P2 | 报告中标注"已检测 N 项 / 共 37 项"，让用户知道覆盖率 | 透明度 |
| P2 | 建议动作增加"跳转到设置"按钮（Intent） | 操作便利 |
| P3 | 增加扫描历史记录（Room 存储） | 可追踪性 |
---
## 综合评估矩阵
### 检测能力矩阵
| 模块 | 总项数 | NO_ROOT 可用 | ADB 可用 | ROOT 可用 | IoC 联动 | 实际有效 |
|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
| A5 行为审计 | 8 | 5 | 8 | 8 | ❌ | 5/8 |
| A2 应用审计 | 9 | 7 | 7 | 7 | ❌ | 7/9 |
| A3 持久化审计 | 12 | 6 | 10 | 12 | ❌ | 6/12 |
| A6 Root环境 | 8 | 6 | 7 | 8 | N/A | 6/8 |
| **合计** | **37** | **24** | **32** | **35** | **0/37** | **24/37 (65%)** |
> "实际有效"列表示在最常见的 NO_ROOT 模式下，真正能产出检测结果的项目数。
### Phase 2 优先修复路线图
**P0 · 紧急修复（影响核心功能）**
1. 新增 A1 网络审计模块 — 读取 `/proc/net/tcp` + 联动 IocLoader 匹配 C2 IP/域名
2. A5-05/A5-06 检测结果联动 IocLoader — 让 IoC 数据真正发挥作用
3. 修复 D-01：A2-02 隐藏图标检测逻辑错误
4. 修复 D-06：A3-09 读取目录而非文件
5. A5-05 无 Root 模式实现完整流量检测
6. A2-07/A2-04 产出实际 Finding 或移除
**P1 · 重要改进（影响检测质量）**
7. 白名单统一到 IocLoader，消除三处重复
8. ScannerImpl 通过 Hilt 注入 Context
9. 为 A5/A3/A6 补充单元测试
10. executeCommand 增加超时控制
11. dumpsys 解析增加 Android 版本适配
12. 简版报告增加"白话解释"字段
13. A5-05 UID 转换为应用名
**P2 · 优化提升（改善用户体验和可维护性）**
14. 提取 ShellExecutor 工具类
15. ADB 模式改为通过 ADB 连接执行
16. 声明 QUERY_ALL_PACKAGES 权限
17. 引导用户授权 PACKAGE_USAGE_STATS
18. 建议动作增加"跳转设置"按钮
19. 异常处理增加日志
20. 扫描历史记录（Room）
---
## 结论
BotGuard-Android Phase 1 MVP 达到了 MVP 验收标准：4 模块可运行、<2 分钟完成、5 级风险分级、UI+JSON 双输出、离线可用、无 Root 可用。架构设计清晰，代码注释完善，检测项覆盖了僵尸网络的主要持久化和行为特征。
但存在三个核心短板需要在 Phase 2 优先解决：
1. **IoC 数据与检测模块脱节** — 6 个家族的 IoC 数据已加载但未被任何检测模块使用，这是最大的功能缺口
2. **NO_ROOT 模式检测覆盖率不足** — 37 项中仅 24 项（65%）在无 Root 模式下有效，而这是最常见的用户场景
3. **网络层检测完全缺失** — 僵尸网络的核心行为是 C2 通信，但当前无任何网络连接/DNS/流量内容的 IoC 匹配
修复 P0 问题后，预计检测覆盖率可从 65% 提升至 85%+，IoC 利用率从 0% 提升至 100%。