Unidbg学习笔记（十五）：对抗视角

Unidbg学习笔记（十五）：对抗视角

站在防守方的视角理解检测逻辑，才能在攻击方的角色中有的放矢。这一篇是攻守互换的一篇 —— 你将看到防守方手里有哪些“识破 Unidbg”的牌，以及面对每一张牌时你应该怎么出。

---

上一篇把你留在了哪里

第十四篇我们承认了 Unidbg 的四大结构性缺陷：双重环境冲突、副作用丢失、嵌套限制、DEX 不可执行。

你可能会觉得这是一种“消极的妥协”。但事情还有另一面 —— 正是因为 Unidbg 有这些结构性差异，防守方才能反过来检测它。每一个缺陷，都是一个潜在的检测点。

这一篇我们换个视角：假设你是写反检测代码的人，你会怎么检测 Unidbg?

读完之后你会得到两个收获:

1. 作为攻击方：看到一段反检测代码，你能秒判它的检测点在哪里，然后对症下药
2. 作为防御者：你能为自己的 SDK 设计出更难绕过的检测逻辑

知己知彼，百战不殆。

---

检测的三个评判标准

不是所有检测都“好”。一个理想的检测方法要同时满足三个标准:

1. 准确性

不能误判真机。如果一个检测逻辑会把红米的某个老版本当成 Unidbg，这个检测就不能上线 —— 业务流失比拦不住攻击者更可怕。

理想检测：对 Unidbg 100% 命中，对真机 0% 误判。

实际很难。多数检测要在准确率和拦截率之间做妥协。

2. 易用性

检测逻辑要轻。如果一个检测要做 1000 次系统调用、读 100 个文件，它会拖慢整个 App 启动。

防守方追求“加这段代码不影响业务”。

3. 隐蔽性

不能被一眼看穿。如果你的检测代码长这样:

if (strstr(uname_release, "unidbg") != NULL) abort();

逆向分析者用 IDA 看 5 分钟就发现了。换个 hook，绕过。

理想的检测应该:

• 不出现敏感字符串
• 检测逻辑分散在多个函数里
• 检测结果不立即触发，而是延迟 / 隐藏地影响后续行为

隐蔽性的三段演化

我们不妨沿着“检测代码的隐蔽性”拉一条时间轴，看检测代码是怎么一步步变难绕过的——这条轴也是攻防双方对抗深度的写照。

第一阶段：裸字符串比对。早期的 SDK 里，检测逻辑就是前面那段 strstr("unidbg")，甚至会把 unidbg 直接写在 .rodata 里。逆向用 IDA 一把过，Strings 视图里搜 unidbg 秒命中，然后跟踪交叉引用，找到判断的 if 直接 patch。这个阶段的检测半衰期通常只有几小时，写检测的人但凡稍有对抗经验就不会这样写。

第二阶段：hash 化字符串 + 混淆常量。为了避免字符串裸露，检测代码会把 "unidbg" 提前算成一个 32 位整数（比如 CRC32、DJB2），运行时把 uname.release 也算一遍哈希再比对。代码看起来变成这样:

static const uint32_t FINGERPRINT_HASH = 0x7B31A4F2;

uint32_t h = djb2_hash(uts.release);
if (h == FINGERPRINT_HASH) suspicious = true;

IDA 里搜不到 unidbg 字符串，只能看到一个没头没脑的魔数。不看代码逻辑、不反推 DJB2 的话，根本不知道在比什么。这个阶段的绕过成本从“5 分钟”抬到“30 分钟”——你得识别出 hash 算法、爆破或反推原始字符串，或者直接 Hook 掉比对函数。

第三阶段：分散逻辑 + 延迟触发 + 无声劣化。真正狡猾的防守方会把检测拆成 5-10 个独立的小判断，分布在看似无关的业务代码里，每个判断都只贡献一点“可疑度分数”，最后在一个远离检测点的地方汇总判决。更阴险的是：判决结果不是立刻 abort，而是影响后面的加密密钥——比如把某个 state 异或一个脏数据，于是加密函数还是照跑，但输出是错的。攻击者拿到“看起来对”的结果提交服务端，被拒，回来排查根本不知道错在哪。

第三阶段的检测，逆向起来的成本可能从 30 分钟涨到 3-5 天，因为每个检测点单独看都像“正常的业务校验”，只有你把整个 score 累积链条还原出来才能明白全貌。后面会专门用一节讲这种“叠加防御”的设计思路。

---

六大检测面

下面是我整理的六大检测维度，按“易用性”从高到低排列。

检测面 1：内存布局检测

检测原理

真机进程有 ASLR （地址空间随机化），每次启动时栈、堆、各 SO 的基地址都不一样。

Unidbg 没有 ASLR。它每次启动:

• 主 SO 的 mmap 段从固定基址开始增长（默认 MMAP_BASE = 0x40000000，会随模块加载向上推进）
• 栈基址固定（默认 STACK_BASE = 0xc0000000）
• 堆从固定地址开始增长

具体常量定义在 unidbg-api/.../memory/Memory.java，ARM32 / ARM64 共用同一组默认值。关键是它们是常量，每次启动一致。

实现示例

void *p = malloc(16);
uintptr_t addr = (uintptr_t)p;

// 真机上 addr 高位字节随 ASLR 浮动
// Unidbg 上 addr 高位字节几乎总是几个固定前缀之一
uint32_t hi = addr >> 24;
if (hi == 0x40 || hi == 0xc0) {
    // 0x40 = MMAP_BASE 起始, 0xc0 = STACK_BASE
    // 命中 Unidbg 默认的 mmap / stack 前缀
    suspicious = true;
}

更精确的版本：多次 malloc + free，统计地址的“分布熵” —— 真机上熵高，Unidbg 上熵很低。

应对

• 方法 A：修改 Unidbg 源码中的基地址定义，让每次启动用不同的随机基址
• 方法 B：Hook 检测函数，直接 patch 返回值
• 方法 C：接受这个差异，但确保 SO 没有真的检测到

应对成本：较低。这是六大检测面里最容易绕过的一个。

检测面 2:JNI 行为检测

检测原理

JNIEnv 提供的函数(FindClass / GetMethodID / CallObjectMethod / ...)在真机的 ART 中行为非常细致 —— 异常、NULL 处理、引用管理、错误码，每一处细节都遵循 JNI 规范。

但 Unidbg 的 AbstractJni 是一个“用户实现”的 mock，实现得再好也很难做到字节级一致。

常见的差异点:

JNI API	真机行为	Unidbg 默认行为
FindClass 找一个不存在的类	设置 NoClassDefFoundError 为 pending exception, 返回 NULL	多数实现直接返回 NULL，不抛异常
GetMethodID 找一个不存在的方法	抛 NoSuchMethodError	多数实现直接返回 NULL
ExceptionCheck 在没异常时	返回 JNI_FALSE	多数实现直接返回 JNI_FALSE，但缺少异常上下文
NewGlobalRef 后引用计数行为	严格按规范	实现可能简化

实现示例

// 故意找一个不存在的类
jclass cls = env->FindClass(env, "com/fake/NotExistingClass");
if (cls != NULL) {
    // 真机这里 cls 应该是 NULL
    // 如果不是 NULL, 说明 AbstractJni 实现有问题
    suspicious = true;
}

// 检查异常状态
if (cls == NULL) {
    if (!env->ExceptionCheck(env)) {
        // 真机这里应该有 NoClassDefFoundError 待处理
        // 没有异常 -> 也是个嫌疑信号
        suspicious = true;
    }
}

应对

要对付 JNI 行为检测，核心是让 Unidbg 的 JNI 实现和真机 ART 在可观察细节上尽量对齐。很多人写 AbstractJni 子类时，只满足了“返回值对”，忘了“副作用对”——而 JNI 规范里恰恰有大量副作用是通过 JNIEnv 内部状态传递的：FindClass 找不到类时“要设置一个 pending exception 状态”，ExceptionCheck 就是读取这个状态，这两个 API 的配合是最常见的检测点。

Unidbg 里 FindClass 的入口在 DalvikVM 系列实现（DalvikVM64 等），它会调用 BaseVM.resolveClass(...)；如果类不存在，需要主动调 vm.throwException(...) 把 NoClassDefFoundError 塞进 pending exception，否则后续 ExceptionCheck 自然就是 false，露馅。

概念上要做的事情大致是这样（伪代码，具体 hook 点取决于你用的 unidbg 版本）：

// 坏实现: 只管返回值, 不管异常状态
//   FindClass 找不到 -> 直接返回 0
//   ExceptionCheck    -> 永远返回 false
//   攻击面: 一对 FindClass("不存在") + ExceptionCheck() 就能识别

// 好实现: 找不到类时显式抛出 NoClassDefFoundError (JNI 规范要求)
DvmClass exCls = vm.resolveClass("java/lang/NoClassDefFoundError");
DvmObject<?> ex  = exCls.newObject(/* 真实的 Throwable 实例或可识别载荷 */);
vm.throwException(ex);   // 把异常压入 BaseVM 内部的 throwable 字段
return 0;                // FindClass 返回 NULL

注意 DvmClass.newObject(Object value) 只是把任意 Java 对象 wrap 成 DvmObject，它不会真的去走 <init> 构造一个 Throwable。如果检测代码进一步调用 GetObjectClass 然后比较 class name，你需要确保抛出的对象在 getObjectType() / toString() 这些路径上看起来确实像一个 NoClassDefFoundError，必要时自定义一个 DvmObject 子类。

JNI 规范细节：FindClass 失败时设置的 pending exception 是 NoClassDefFoundError（不是 ClassNotFoundException —— 后者是 Java 检查型异常 Class.forName 抛的，JNI 不用）。GetMethodID 失败抛 NoSuchMethodError，GetFieldID 失败抛 NoSuchFieldError。挑错异常类型本身就是个露馅点。

ExceptionCheck 的实现侧也要对齐：在 unidbg 里，pending exception 由 BaseVM 内部的 throwable 字段承载（package-private），ExceptionCheck / ExceptionOccurred 读的就是这个字段。只要你在 FindClass 失败路径上正确调用了 vm.throwException，ExceptionCheck 自然就会返回 true——核心不是 hook ExceptionCheck，而是让"该抛异常的地方真的抛异常"。

除此之外还有一些同类陷阱值得一起修：GetMethodID 找不到方法应该抛 NoSuchMethodError；NewGlobalRef 应该维护引用计数（虽然多数时候检测不到这层，但有的样本会故意 ref/unref 一百次看是否有泄漏）；NewStringUTF 对空串和超长串的 handling 也要对齐。

应对成本是中等持续投入。每次发现一个新检测点都要补一个，但整体可以慢慢完善。经验是：被风控样本坑过一次之后，就把标准的 exception-aware override 做成模板，以后每个新项目都直接套用。

检测面 3：文件描述符检测

检测原理

Linux 的 fd 分配有严格规律:

• fd 0/1/2 是 stdin/stdout/stderr
• 后续 fd 按“最小未占用”分配
• 关闭后立即可被复用
• 进程启动时，某些 fd 已经被框架占用 (logd / binder / ashmem ...)

Unidbg 的 fd 分配可能:

• 不严格按“最小未占用”
• 没有 framework 预占用的 fd
• 复用时机不一样

实现示例

int fd = open("/dev/null", O_RDONLY);
if (fd < 20) {
    // 真机 App 启动后, 第一个 user fd 通常落在 40-80
    // (因为 binder / logd / ashmem / inotify 等已经占了一堆)
    // 如果 fd 太小, 看起来不像真机
    suspicious = true;
}
close(fd);

更狠的检测:

// 列出 /proc/self/fd 下所有 fd 的指向
DIR *dir = opendir("/proc/self/fd");
struct dirent *entry;
int has_logd = 0;
int has_binder = 0;
while ((entry = readdir(dir)) != NULL) {
    // 检查 link 目标里有没有 binder, logd, ashmem
    char target[256];
    char path[64];
    snprintf(path, sizeof(path), "/proc/self/fd/%s", entry->d_name);
    if (readlink(path, target, sizeof(target)) > 0) {
        if (strstr(target, "binder")) has_binder = 1;
        if (strstr(target, "logd")) has_logd = 1;
    }
}
if (!has_binder || !has_logd) {
    suspicious = true;
}

应对

fd 检测的应对分两个层面，一个是抬高起始 fd 号，一个是伪造 binder / logd / ashmem 的 fd。前者是基础消毒，后者是对抗升级版检测。

抬高起始 fd 号最干净的做法是自定义 SyscallHandler（UnixSyscallHandler 是基类），覆盖其分配 fd 的逻辑。Android 真机进程启动后，第一个"业务可见"的 fd 通常落在 40-80 之间（因为 framework 已经占了 binder / logd / ashmem / inotify / eventfd 等十几到几十个 fd，具体数量随 Android 版本和进程类型而异），目标是让 Unidbg 里 open 出来的第一个业务 fd 也落到这个范围：

// 思路示意：在自定义 SyscallHandler 中，启动期先用占位 fd 把 0~N 占掉
public class ShiftedSyscallHandler extends ARM64SyscallHandler {
    private static final int FD_BASE = 60;

    @Override
    protected int getMinFd() {        // UnixSyscallHandler 上的 protected 方法
        // 也可以在初始化阶段把 0..FD_BASE-1 注册为占位 FileIO
        return FD_BASE;
    }
}

具体方法名 / 可见性需对照你使用的 unidbg 版本，核心思路是"业务 fd 从 60 开始"，而不是依赖某个固定 API。

伪造 binder/logd 的 fd link则需要同时做两件事：（1） 在 IOResolver 里为 /dev/binder、/dev/logd、/dev/ashmem 返回一个虚拟的 ByteArrayFileIO，让它们“开起来有 fd”；（2） 拦截 /proc/self/fd/<n> 和 /proc/self/fd/ 目录读取请求，让 readlink 和 opendir 看到正确的 link 目标。核心代码示意:

// 启动时提前"占用"几个低号 fd, 模拟 framework 已经用掉
private void preOccupyFds(Emulator<?> emulator) {
    String[] fakes = {"/dev/binder", "/dev/logd", "/dev/ashmem", "/dev/null"};
    for (String path : fakes) {
        emulator.getSyscallHandler().open(emulator, path, O_RDONLY);
    }
}

// IOResolver 里处理 /proc/self/fd/N 的 readlink
@Override
public FileResult<AndroidFileIO> resolve(Emulator<?> emulator, String path, int oflags) {
    if (path.startsWith("/proc/self/fd/")) {
        int fd = Integer.parseInt(path.substring("/proc/self/fd/".length()));
        String target = getFakeLink(fd);  // 返回 "socket:[12345]" 或 "/dev/binder" 等
        return FileResult.success(new ByteArrayFileIO(oflags, path, target.getBytes()));
    }
    return null;
}

注意起始 fd 号不能抬得过高（比如抬到 200），那样反而会露馅——真机上第一个业务 fd 大致落在 40-80 之间（具体数值跟 Android 版本、进程类型都相关），太整齐或太高都异常。这也是为什么经验值是 60，而不是 10 或 500。

这是个持续不断打补丁的过程。检测者可以升级花样(读 fd 的 fstat 信息看设备号,statfs 看文件系统类型)，每升级一次，我们就得补一段 mock。应对成本：中等到高，但好消息是所有 patch 都可以复用，做一次沉淀进库，后续项目直接引用。

检测面 4:uname 检测

检测原理

uname 系统调用返回内核信息。Unidbg 的默认实现返回:

sysname: Linux
release: 1.0.0-unidbg
version: ...
machine: aarch64

release 字段里直接出现 unidbg 字符串 —— 防守方写一行 grep 就能检测。

实现示例

struct utsname uts;
uname(&uts);
if (strstr(uts.release, "unidbg") != NULL) abort();

太简单了对吧？也太容易绕过。

应对

• 在 SyscallHandler 里覆盖 uname，返回真机一样的 release
• 或者直接 hook libc 的 uname 函数

应对成本：极低。这是六大检测面里最弱的一个，几乎所有有经验的攻击者都默认绕过了。

教训：默认值就是检测点。任何 Unidbg 默认返回的“看起来像测试值”的字符串，都会成为攻击面。

检测面 5：时间特征检测

检测原理

模拟执行远慢于真机执行。

• 真机上 1000 次 AES 加密可能用 2ms
• Unidbg 上同样的操作可能用 200ms （慢 100 倍）

防守方可以做“时间一致性检查”:

struct timespec t1, t2;
clock_gettime(CLOCK_MONOTONIC, &t1);

// 跑一段已知"应该很快"的代码
volatile int sum = 0;
for (int i = 0; i < 100000; i++) sum += i;

clock_gettime(CLOCK_MONOTONIC, &t2);

long ns = (t2.tv_sec - t1.tv_sec) * 1000000000L + (t2.tv_nsec - t1.tv_nsec);

// 真机上这段循环不到 1ms (1000000 ns)
// Unidbg 上可能要 50-200 ms
if (ns > 10000000) {   // 10 ms
    suspicious = true;
}

更狡猾的版本：连续两次 clock_gettime，如果差值是 0 （说明时间被 hook 固定了），也是嫌疑信号:

clock_gettime(CLOCK_MONOTONIC, &t1);
clock_gettime(CLOCK_MONOTONIC, &t2);
if (t2.tv_nsec == t1.tv_nsec && t2.tv_sec == t1.tv_sec) {
    // 时间没动 -> 时间被固定了
    suspicious = true;
}

应对

• Hook 时间函数，不返回固定值而是返回模拟的合理流逝
• 上一篇讲过的 counter++ 模式：每次调用递增一个看起来合理的纳秒数
• 如果检测的是“代码执行速度”，还要计算“如果真机跑这段代码会用多久”，然后让 hook 返回的时间符合这个预期

private long monoNsCounter = 1000000000L;

@Override
public int handleSyscall(int NR, ...) {
    if (NR == 113) {  // clock_gettime
        // 每次调用 +50ns (模拟真机的合理流逝)
        monoNsCounter += 50;
        // 写入用户传入的 timespec
        ...
    }
}

应对成本：中高。你需要“预测”真机时间流逝的合理速率，这本身就有不确定性。

检测面 6:Unicorn 引擎指纹

检测原理

这是六大检测面里最难绕过的一个。

Unicorn / KVM / 真实 ARM CPU 在执行某些“边缘指令”时，行为有微小差异:

• FPCR / FPSR 状态位的更新（特别是异常标志位 IOC/DZC/OFC/UFC/IXC 的累积行为）
• NZCV 在边界条件下的设置
• 某些罕见指令的支持情况（ARMv8.3 的 PAC* 系列、ARMv8.5 的 BTI、各种 SVE/SME 指令）
• 内存屏障的实际可观察效果 (DMB / DSB / ISB)
• 自修改代码的 i-cache / d-cache 一致性
• 系统寄存器读写（MRS/MSR 访问 ID_AA64* 等特性寄存器）

防守方可以构造一段"在真机上能跑、但在 Unicorn 上行为不同"的代码:

// 触发一次浮点异常, 检查 FPSR 是否按规范更新累积标志位
double a = 0.0 / 0.0;
uint32_t fpsr;
asm volatile("mrs %0, fpsr" : "=r"(fpsr));
if ((fpsr & FPSR_IOC) == 0) {
    // 真机会置位 IOC (Invalid Operation Cumulative)
    // Unicorn 老版本可能不更新这个 bit
    suspicious = true;
}

或者直接读特性寄存器，看 PAC / BTI 等扩展是否被声明支持：

// 读 ID_AA64ISAR1_EL1 检查 PAC 支持
// Unicorn 对 PAC 指令长期按 NOP 处理, 而真机会真正做指针签名校验
// 一段先 PACIA 再篡改高位再 AUTIA 的序列, 真机会触发异常或返回非法指针,
// Unicorn 上则平稳通过

应对

• 这是几乎无解的检测面
• 修改 Unicorn 的实现成本极高，而且新检测可以持续涌现
• 唯一的对策：遇到这一类样本就别用 Unidbg 了，Frida 真机方案没有这个问题

应对成本：极高 / 不可行。

但好消息是 —— 这一类检测也很难实施:

• 防守方需要深入理解 ARM 指令集和 Unicorn 实现差异
• 检测代码本身很容易暴露意图，逆向时很显眼
• 一个可绕过的检测换一个不可绕过的检测，可能只是延迟问题被发现的时间，而不是阻止它被绕过

所以实际生产环境里，Unicorn 指纹检测很罕见。多数样本停在前五个检测面。

---

攻防博弈的全景视图

把六大检测面按“易用性 vs 应对成本”画一张图，你会看到:

检测面	易用性	应对成本	实战频率
内存布局	高	低	中
JNI 行为	中	中	高
fd 检测	中	中	中
uname	极高	极低	极高 （但都被绕过了）
时间特征	中	中高	中
Unicorn 指纹	极低	极高	低

注意“实战频率”那一列：易用性高的检测往往也是最常用的。但因为容易绕过，它们的实际拦截率很低。

真正能拦住人的检测，是那些“易用性中等、应对成本中等、防守方愿意持续投入”的检测 —— 比如 JNI 行为细节、fd 一致性。这些是攻击者会卡的地方。

一个常见的现象：叠加防御

防守方很少只用一种检测。实战中通常是叠加多个检测:

int score = 0;
score += check_uname();              // 1 分
score += check_memory_layout();      // 1 分
score += check_fd_strangeness();     // 2 分
score += check_jni_behavior();       // 2 分
score += check_timing();             // 2 分
score += check_unicorn_fingerprint();// 5 分

if (score >= 5) {
    return FAKE_RESULT;   // 不是 abort, 而是返回假结果
}

注意最后一行：不是直接 abort，而是返回假结果。这是更阴险的设计 —— 攻击者拿到的“成功结果”实际上是假的，提交给服务端会被拒绝，但攻击者根本不知道哪里出了错。

应对叠加防御的关键:

• 不要试图“全部绕过”，只绕过让你拿到正确结果的那几个
• 用第十三篇讲的“标准答案对比法”快速发现“返回了假结果”的情况
• 一旦怀疑结果是假的，从最高分的检测面开始排查

---

攻防博弈的启示

写在最后，几条心法。

1. 检测和绕过是无限博弈

每一个检测点都可以被绕过。每一个绕过都可能引入新的检测点。这是一个无限游戏，不存在“最终胜利”。

这句话听上去像废话，但它决定了你对这件事的心态——如果你把目标定成“一次性搞定，永远不用再碰”，你会在第三次被新版检测打趴下后就把样本砸了；如果你把目标定成“维护一套基础补环境库，每次新样本出现时迭代其中几个 override”，这件事就变成了可持续的工程问题。Unidbg 社区里那些能持续产出成果的团队，心态都是后者——他们把“补环境”当成和“升级依赖”一样的常规维护，而不是一场决战。

接受这个现实，你才能保持长期的耐心。

2. 低成本检测容易绕过，高成本检测难以实施

uname 检测易写易绕，Unicorn 指纹难写难绕。实战中防守方倾向于用大量低成本检测叠加，而不是少数高成本检测。

这是防守方的理性选择。写一个 Unicorn 指纹检测要懂 ARM 指令集边缘行为，还要专门做真机对比测试，可能花一个资深工程师两周时间；而写 10 个 uname/fd/JNI 级检测一个下午就能搞定，哪怕单点绕过成本只有 5 分钟，累积起来也足够让大部分爬虫望而却步。

这意味着你作为攻击者，主要工作是逐个排查 + 大量补丁，而不是攻克一两个高难度检测点。思路要从“找到关键检测然后一击必杀”转成“建立 100 个小 patch，保证 AbstractJni/SyscallHandler/IOResolver 三件套开箱就能扛住常见检测组合”。

3. 防守方的真正武器不是技术，而是流程

最难绕过的检测不是某段代码，而是服务端的行为验证:

• 客户端必须完成特定的事件序列（启动 → 进入页面 A → 在页面 A 停留 N 秒 → 点击按钮 → 触发签名）
• 客户端必须产生特定的 telemetry 上报（页面埋点、曝光日志、心跳包）
• 客户端必须在特定时间窗口内响应（签名请求的间隔分布要符合人类操作节奏）
• 服务端用机器学习模型判断客户端行为模式

这些检测不在 SO 里，你逆向再深也找不到。它们在服务端的风控模型里，分析人员甚至不会直接看到。你能观察到的只是“请求被拒”，然后慢慢试——这也是为什么第十四篇里我们反复强调“业务副作用”比算法本身更难复现。

应对这类检测，你已经超出了 Unidbg 的范畴——需要在 Frida 真机上做完整的行为模拟，或者干脆放弃自动化，去模拟真实用户的操作时序。这时候混合方案就出场了：Unidbg 负责算签名（拿得到确定性结果），真机环境负责产生“看起来像人”的 telemetry 和事件流，两者配合起来上传，才能骗过服务端的行为模型。

4. Unidbg 是工具，不是终极答案

经过 15 篇，我希望你已经明白：Unidbg 在算法分析、批量调用、补环境验证这些事上几乎无可替代，但它不能也不应该解决所有反检测问题。

一个有经验的逆向工程师手上会有一套完整的工具链：IDA 用来静态分析、Unidbg 用来算法还原和批量调用、Frida 用来真机动态验证、Burp/mitmproxy 用来网络流量分析、Jadx 用来看 Java 层逻辑。每个工具都有它的甜蜜点，也有它的盲区。真正的专业性，是在拿到一个样本的 30 分钟内，判断出这个样本应该用哪个工具切入，而不是“我最擅长 Unidbg，所以什么样本都先上 Unidbg”。

工具的价值不在于“它能做什么”，而在于“使用者知道它适合做什么”。

下一篇我们回归实战，讲 Console Debugger —— Unidbg 的交互式调试环境。这是算法分析的核心武器，学会它你就有了一个完全可控、无抗干扰的 GDB。

---

小结

检测面	原理	应对成本
内存布局	Unidbg 无 ASLR	低
JNI 行为	AbstractJni 实现细节差异	中
fd 检测	fd 分配规律不同	中
uname	默认 release 字段	极低
时间特征	执行慢 / 时间被固定	中高
Unicorn 指纹	罕见指令行为差异	极高

最重要的一句话:

攻防是无限博弈。你不会赢得所有战斗 —— 但你需要赢得这一场。