frida基于bug的Stalker跟踪检测和修复

前言

Stalker 是 Frida 内部的一个模块用于动态追踪目标程序的执行流程，也就是当我们需要知道：

• 函数是怎么调用的？
• 指令是怎么一步步执行的？
• 分支是怎么跳转的？
• 有哪些函数是频繁被调用的？

的时候，会用到Stalker.follow跟踪线程将要执行的指令，可以对指令动态插桩修改。对莫名其妙的反调试行为来说，是一个通用的兜底窥探方案。

stalker跟踪检测

关于stalker参考官方文档： af4K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6X3M7X3W2V1j5g2)9J5k6i4u0W2i4K6u0r3k6r3!0U0M7#2)9J5c8Y4y4@1j5h3I4C8k6i4u0Q4x3V1j5`.

注： 这个检测手段仅对于在开启Stalker.follow跟踪的线程生效

• 原理：stalker会对执行过的内存地址(block->real_start)存储的指令会进行缓存，当再次进入要执行同一个地址的指令的时候，通过比对内存和缓存中的指令来确定是否需要重编译block来确保执行到正确的原指令 - 本应该是如此，但是正如标题所说，这个检测依赖当前frida-gum项目的stalker的重编译bug，而这个bug就出现在比对和重编译上，导致了当执行同一个内存地址的block时候，实际指令都是在跟第一次编译后的缓存block的原指令快照进行比对。所以这样的后果就是显而易见的，初次执行该内存地址的指令会一直存在于stalker的"阴影中"，下面我会用一个测试例子来说明这个现象。

以上的场景说明存在简化，实际的问题路径在下面对应的代码:

1. 指令比对
2. block重编译

通过下面一个例子来验证这个问题

• 为了利用上面这个bug，我们可以简单的实现两个函数，一个函数(add_99_func)是对传递的第一个参数+99，另一个函数(empty_func)是不做任何操作直接返回原参数。

• 使用mmap来创建指定内存块用于复写和执行指令

• frida测试脚本

setImmediate(() => {
    Interceptor.attach(
        Module.getExportByName('libdl.so', 'android_dlopen_ext'), {
            onEnter(args) {
                this.filename = args[0].readCString()
                console.error(`[android_dlopen_ext] ${this.filename}`)
            },
            onLeave(retval) {
                const filename: string = this.filename
                if(filename.includes('libtest_frida.so')) {
                    attachMmapExec(Process.findModuleByName(filename)!)
                }
            },
        }
    )

    function attachMmapExec(mod: Module) {
        console.error(`[attachMmapExec] ${JSON.stringify(mod)}`)
        const target = mod.getExportByName("Java_com_example_frida_1stalker_1recompile_1fix_MainActivity_mmapExec")
        Interceptor.attach(target, {
            onEnter(args) {
                console.log(`[mmap_exec] follow => tid[${Process.getCurrentThreadId()}]`)
                Stalker.follow(Process.getCurrentThreadId(), {
                    transform(iterator: StalkerArm64Iterator) {
                        let inst
                        while((inst = iterator.next()) !== null) {
                            // console.log(`[${Process.getCurrentThreadId()}] ${inst}`)
                            iterator.keep()
                        }
                    }
                })
            },
            onLeave(retval) {
                Stalker.unfollow()
                console.error(`[mmap_exec] unfollow => tid[${Process.getCurrentThreadId()}]`)
            },
        })
    }
})

• 通过对于同一个内存块进行来回按照empty_func，add_99_func的顺序来写入对应的的汇编来执行（假设传递的count=1）：

1. 第一次执行empty_func(1)的时候返回值是1（首次编译，缓存根据empty_func生成的插桩指令）
2. 通过比对指令，第二次进行了重编译，执行add_99_func(1)返回100 (第一次重编译，缓存根据add_99_func生成的插桩指令，但是指令快照却是empty_func)
3. 第三次执行，预期是执行empty_func(1)返回1，但实际却因为快照是第一次编译的指令（empty_func），所以误认为指令没变动，所以执行了第一次重编译的插桩代码add_99_func，导致了此时会返回100。
4. 第四次执行，预期是执行add_99_func(1)返回100，实际上也是执行了add_99_func(1)，但是错误的又重编译一次
5. ...接下来的都会是执行add_99_func(1)的结果

以下展示了三种测试结果用于说明：

1. 正常无frida-stalker跟踪现象

2. 使用原版frida-stalker跟踪现象

3. 使用修复的frida-stalker后的跟踪现象

编译修复frida-server

拉取源项目和合并修改

编译

参考官方文档： 899K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6X3M7X3W2V1j5g2)9J5k6i4u0W2i4K6u0r3k6r3!0U0M7#2)9J5c8X3u0#2K9h3I4V1K9h3&6Y4i4K6u0r3i4K6t1K6j5%4u0G2M7%4x3`.

测试

修复的测试结果如上图

资源链接

1. 代码仓库
2. 测试app代码
3. so库实现
4. frida注入脚本
5. 编译的arm64测试apk

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