前言

25年下旬到26年上半年，这段时间我分析了不少的加固厂商的frida检测，最初的目的就是想看每个厂商的frida检测原理 ，因为我觉得frida检测过掉之后，后面的签名校验啊 ，算法分析，脱壳啊什么的都是时间的问题了。

分析的厂商包括但不限于：梆梆，爱加密， 娜迦，360，ShadowSafetyProtect，新百度加固。

目前来看国内市面上的加固无非就是梆梆和爱加密了，这两家是我遇到的最多的。

国外厂商包括：DexProtector，BShield，Appdome

其中DexProtector与BShield使用的都挺多的

BShield也是我目前所有分析过的厂商中最难最复杂的一个。

梆梆

先说梆梆吧，梆梆给我的感觉就是技术更新挺快的，不足的就是有些检测方式并不稳定，梆梆就给更新上去了。这个情有可原，因为安卓版本的原因，有些检测点在不同的安卓版本中是存在差异的，可能测试的不是太完全吧。

其次梆梆的代码写的很规范，以至于分析起来并不是很困难，梆梆几乎把所有检测到的异常都给映射了一个错误码，根据这个错误码就可以找到大部分的关键逻辑。

分析过程中也学到了不少知识点：自定义linker，asm内联，原子指令，elf文件解析，api间接调用，字符串动态释放，inline hook，svc call。

其中这里的自定义linker严格意义上来说是不准确的，更准确的形容是内存释放so文件。

这一点和pe文件内嵌pe文件很相似。

爱加密

爱加密采用的架构是双so模式，一个主so和一个副so，在一些旧版本中，主so是不负责检测的，其作用是负责提供检测函数供副so调用。

原因是爱加密带有vm虚拟化技术，这个给放到了副so中进行处理，所以在副so执行前会调用主so提供的检测函数。

当然这个好像是旧架构。新架构是在主so里面也添加了主动检测机制。

爱加密没有采用内存释放so文件的架构，因为用不到，本身就是已经是双so架构了，在内存释放so无非就是套娃了。

DexProtector

这个加固是国外厂商，frida检测本身并不是很厉害，这个厂商主要是在内存校验上下了很多功夫，主要so文件中，大部分检测都与内存校验有关。

架构同样采用了内存释放so文件的形式，但释放的并不是完整的so文件， 把elf头给抹去了。

这个保护并不难，因为代码写的很规范，比梆梆还规范，并且没有任何混淆，只要有时间有耐心，绝对能分析出原理的。

BShield

这个厂商的frida检测分析难度我给他排到第一位，检测原理很常见，难在检测点不好找，因这个厂商的保护采用的架构太复杂了且是c++开发的，这需要分析者对c++的std库有一定的了解，不然分析起来很是痛苦，该保护并没有使用到内存释放so文件，反而释放的是一段shellcode。

还有一方面的原因，是因为这个保护架构是全局上下文模式，全局共享一个状态机，且没有任何错误码而言，

中间稍有处理不细致，整个架构就会走向错误分支。

还没完，当你以为把前面的所有埋点都给处理好之后，在最后的一步还会给你埋雷，这个雷巨大，大到你要重新分析，这个雷埋的很早，如果前面你没处理的话，那么你是痛苦的，因为你觉得把所有点都分析完毕了，根本就没有耐心在重头分析了。只会在后面错误分支里一直撞头，最后心态爆炸，放弃分析。

这个也是我感到最牛逼的攻击方式，心里攻击，开发人员仿佛已经看到了你在最后崩溃无奈的样子。

分析了那么多，给我的感受是啥呢，我大致总结一下：

1.保护的架构模式，这个是最重要的，如果保护的架构模式一开始就漏洞百出，错误百出，那么无疑这个架构是失败的，即使最后成功上线，也无济于事。

2.分析过程中的耐心，这个是最最最最最重要的，一定要有耐心，我是有执念的，我在分析之前就给自己下了目标：
我一定要在代码中找到检测的原理，检测点的藏身之处。
这个也是给我分析的动力，我喜欢这个过程，也更喜欢这个结果，有种：我终于发现你了的感觉，hhhhhhh。

3.从开发角度而言，主动抛出错误码显然是不合理的，相对更好的做法应该是主动埋雷，延时引爆，给分析者统统炸炸炸炸炸炸懵逼。

最后

分析这些也就图一乐，收拾收拾进厂了。

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