前言

我研究安卓软件的逆向技术也不过短短三年多的时间，但是也是接触到了不少逆向技术和工具或框架，要说哪个逆向工具对我影响最大，那frida确实是当之无愧，我刚接触这一块的时候就开始用frida对一些简单的app进行一些逆向分析的操作了，到现在frida依然是我搞安卓逆向最习惯使用的工具。从以前对frida运行原理的一知半解到现在的略有所知，我对frida的钦佩之情不减反增，frida集注入、读写内存、hook等多个功能于一身，并且还支持了使用js来编写frida脚本，在功能全面的同时还大幅降低了使用者的门槛。但是俗话说得好，木秀于林，风必摧之，到现在安全加固厂商针对frida的检测手段已经数不胜数了，这无疑是将使用frida的门槛越提越高。

摆脱frida检测的通用方法

在各种frida特征检测技术盛行之下，我们作为frida的使用者反而成为了这场安全攻防游戏中的弱势者。在这种困境之下留给我们的选择似乎只剩下两种，其一是魔改frida，将frida的常见特征抹去，这样一来针对frida特征的检测就会失效，这方面的项目其实很多了，但是frida暴露的特征是相当多的，谁也不敢说100％把frida的特征全抹去了，如果安全加固厂商手上有还未公之于众的frida特征，而这些特征恰好没有被抹去，那魔改frida去其特征这条路就会直接失败，我觉得这是十分麻烦的。其二是放弃frida，不再使用frida，这是非常难以做出的决定，但是这是躲避frida检测最彻底的方法，与其继续坚持使用frida让自己成为这场攻防战争中需要时刻躲避检测的弱势方，还不如一不做二不休直接不再使用frida。

替代frida的方案

正如我前言所说frida的功能其实是十分全面的，要想全部替代实现这些功能是很麻烦而且也没必要，其实关键的两个功能实现了即可应对大部分业务需求，这两个功能即是注入与hook。

frida的在安卓平台上的注入技术

以下均为我个人的理解，如有错误之处，还望指出。
frida在安卓平台上有两种注入方式，其一是spawn模式，以这种方式注入app时，frida会率先注入zygote，然后再拉起app进程进行注入，这种方式能够让frida在最早的时机注入app，但是坏处是可能会被app检测到zygote进程被注入过的痕迹。其二是attach模式，即app打开后再附加上app的进程进行注入，以这种方式注入app的时机注定会比前者慢上许多，但是好在没有注入zygote进程，暴露的特征比前者少那么一点。这两种注入模式其实都是依赖ptrace系统调用。

为什么选择ptrace注入

既然frida的注入底层也是依赖ptrace，那我们也直接使用ptrace注入算了，不过我觉得大部分业务其实对注入时机的早晚都不关注，因此便没要注入zygote了，而是待app启动后直接附加app的进程再注入即可，而且关于ptrace注入app进程的项目其实是有很多了。至于关于ptrace的检测问题，我觉得是无伤大雅，比起直接用frida注入，ptrace注入本身其实是特征不算多了，而且大部分ptrace注入的特征可以通过加载内核模块而抹去，我也写了几个kpm内核模块来辅助对app进程的ptrace注入，如ptrace_helper、NoHooker，前者用于抹去ptrace注入的一些文件特征，后者可以用于防止app进程自身hook dlopen相关系列函数，让我们能够顺利通过这些函数将自己的so注入到app进程中执行。
我之前将Zygisk-Il2CppDumper的注入方式改为ptrace注入，即PtraceIl2cppDumper,也取得了不错的效果，详情见我上一篇帖子。

frida在安卓平台上的hook技术

frida本身是依赖inline-hook技术实现了native hook，在此基础之上通过frida-java-bridge实现了java hook。

对frida hook技术的平替

native hook

安卓平台上inline hook的项目其实是很多的，除了frida之外，Dobby便是最常用的native hook框架，不过其在inline-hook的实现上，我个人觉得比起frida略显不足，因为frida不仅支持对任意函数进行hook，还支持对单条汇编指令的hook，而dobby则是适用于hook函数的情形，不太支持对单条汇编指令的hook(或者说是不够稳定),而且在需要同时hook大量函数情况下，dobby可能也没有frida这么稳定。但总的来说dobby在只需hook数量不是很多的native函数的情况下是能够完全替代frida的。
但是实际很多场景都是需要同时hook大量函数，比如在搞unity游戏逆向的时候，往往需要同时hook大量函数来迅速找到一些是会被调用的函数来做突破口，在类似这种场景下除了使用frida难道就没有其他办法了吗，并非如此。

内核hook技术的运用

基于ebpf技术对用户态程序进行hook的项目其实也已经有很多了，如stackplz,完全可以在ebpf程序中通过uprobe来hook用户态程序的指定函数，依靠uprobe来进行hook也比一般的inline-hook稳定，我也简单写了一个kpm内核模块Kernel-Trace，基于uprobe实现了对对大量用户态函数同时进行简单hook的支持，这个项目目前还有些问题，还望各位大佬不吝赐教。

综上所述，在大多数场景下，dobby结合内核hook技术进行使用就已经能够在native hook这一方面对frida进行替代。

java hook

理论上通过dobby也能够实现frida-java-bridge的效果，而摆脱使用frida，但由于我还没试过，也不清楚能不能够实现，所以这块是个待填的坑......

结语

其实对frida的替代计划很久以前就在我心里萌芽，时至今日才算是略有所成，虽然离完美替代肯定是还有很远的距离，但我目前的想法是先在对unity游戏的逆向及修改过程中实现去frida化，至于如何实现java hook暂时被搁置了。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课