利用 Frida 和 QBDI 动态分析 Android Native 的各项函数

开发
这篇文章将介绍如何通过充分利用Frida和QBDI来更好地理解Android Native 的各项函数。

[[343697]]

由于可以检索应用程序代码的Java表示形式,因此通常认为Android应用程序的逆向工程比较容易。攻击者就是通过了解这些代码版本,收集应用程序信息,来发现漏洞的。如今,大多数Android应用程序编辑器已经意识到了这一点,并尽力使反向工程不再那么容易。由于Java本地接口(Java Native Interface,简称JNI),攻击者通常依靠集成混淆策略或将敏感函数从Java / Kotlin端转移到本机代码。但是,当他们决定同时使用两者时(即,混淆的本机代码),逆向工程过程变得更加复杂。结果,静态查看本机库的反汇编结果非常繁琐且耗时。幸运的是,运行时检查仍然是可能的,并且提供了一种便捷的方法来有效地掌握应用程序的内部机制,甚至避免混淆。JNI(Java Native Interface) Java本地接口,又叫Java原生接口。它允许Java调用C/C++的代码,同时也允许在C/C++中调用Java的代码。可以把JNI理解为一个桥梁,连接Java和底层。其实根据字面意思,JNI就是一个介于Java层和Native层的接口,而Native层就是C/C++层面。

由于针对常规调试器的保护在流行的应用程序中非常普遍,因此使用动态二进制工具(DBI)框架(例如Frida)仍然是进行全面检查的理想选择。从技术上讲,在其他强大函数中,Frida允许用户在本机函数的开头和结尾插入自己的代码,或替换整个实现。但是,Frida在某些时候缺乏粒度,特别是在以指令规模检查执行情况时。在这种情况下,Quarkslab开发的DBI框架QBDI可以帮助Frida在调用给定的本机函数时确定已执行了代码的哪些部分。

首先,我们必须正确设置测试环境。我们假设设备已经植根并且Frida服务器已经在运行并且可以使用。除了Frida,我们还需要安装QBDI。我们可以从源代码编译它或下载Android的发行版,使用说明可以直接从官方页面检索到。解压缩后,我们必须将共享库libQBDI.so推送到设备上的/ data / local / tmp中。除此之外,我们还可以注意到在frida-qbdi.js中定义的QBDI绑定,该文件负责提供QBDI函数的接口。换句话说,它充当QBDI和Frida之间的桥梁。

请注意,必须先关闭SELinux,否则由于某些限制规则,Frida无法将QBDI共享库加载到内存中。这将会显示一条明确的错误消息,告诉用户权限被拒绝。在大多数情况下,仅使用root特权运行此命令行即可完成此工作: 

  1. setenforce 0 

现在我们已经具备了基于Frida和QBDI编写脚本的所有要求。

跟踪本机函数

在对JNI共享库执行反向工程时,始终值得检查JNI_OnLoad()。确实,此函数在库加载后立即调用,并负责初始化。它能够与Java端进行交互,例如设置类的属性,调用Java函数以及通过几个JNI函数注册其他本机方法。攻击者通常依靠这些属性来隐藏一些敏感的检查和秘密的内部机制。

接下来,让我们假设我们要分析一个流行的Android应用程序,比如Whatsapp,其软件包名称为com.whatsapp,这是当前Android上最广泛的即时消息解决方案。它嵌入了一堆共享库,其中一个是libwhatsapp.so。不过要注意的是,该库并不位于常规的lib /目录中,因为在运行时存在一种解压缩机制,该机制可将其从存档中提取出来,然后将其加载到内存中,我们的目标是弄清楚它的初始化函数在做什么。

利用 Frida

  1. /** * frida -Uf com.whatsapp --no-pause -l script.js */function processJniOnLoad(libraryName) { 
  2.     const funcSym = "JNI_OnLoad"
  3.     const funcPtr = Module.findExportByName(libraryName, funcSym); 
  4.  
  5.     console.log("[+] Hooking " + funcSym + "() @ " + funcPtr + "..."); 
  6.     // jint JNI_OnLoad(JavaVM *vm, void *reserved); 
  7.     var funcHook = Interceptor.attach(funcPtr, { 
  8.         onEnter: function (args) { 
  9.             const vm = args[0]; 
  10.             const reserved = args[1]; 
  11.             console.log("[+] " + funcSym + "(" + vm + ", " + reserved + ") called"); 
  12.         }, 
  13.         onLeave: function (retval) { 
  14.             console.log("[+]\t= " + retval); 
  15.         } 
  16.     });}function waitForLibLoading(libraryName) { 
  17.     var isLibLoaded = false
  18.  
  19.     Interceptor.attach(Module.findExportByName(null"android_dlopen_ext"), { 
  20.         onEnter: function (args) { 
  21.             var libraryPath = Memory.readCString(args[0]); 
  22.             if (libraryPath.includes(libraryName)) { 
  23.                 console.log("[+] Loading library " + libraryPath + "..."); 
  24.                 isLibLoaded = true
  25.             } 
  26.         }, 
  27.         onLeave: function (args) { 
  28.             if (isLibLoaded) { 
  29.                 processJniOnLoad(libraryName); 
  30.                 isLibLoaded = false
  31.             } 
  32.         } 
  33.     });}Java.perform(function() { 
  34.     const libraryName = "libwhatsapp.so"
  35.     waitForLibLoading(libraryName);}); 

首先,借助Frida提供的便捷API,我们可以轻松地挂接我们要研究的函数。但是,由于Android应用程序中嵌入的库是通过System.loadLibrary()动态加载的,该函数在后台调用了本机android_dlopen_ext(),因此我们需要等待将目标库放入进程的内存中。使用此脚本,我们可以只访问函数的输入(参数)和输出(返回值),也就是说,我们位于函数层。这是非常有限的,仅凭这一点基本上还不足以准确掌握内部的情况。因此,在这种精确的情况下,我们希望在较低级别上彻底检查该函数。

利用 Frida 和 QBDI

QBDI提供的导入函数可以帮助我们克服以上的问题,实际上,该DBI框架允许用户通过跟踪执行的指令来执行细粒度的分析。这对我们非常有用,因为我们可以深入了解我们的目标函数。

这样做的想法是,不是让JNI_OnLoad()在常规启动期间运行,而是在基本块/指令范围内通过有条件的上下文来执行它,以便确切地知道已执行了什么。由于我们可以将这两个DBI框架结合在一起,因此可以在我们之前编写的Frida脚本的基础上集成这一全新的部分。

但是,我们使用的Interceptor.attach()函数只允许我们定义onEnter和onLeave回调。它意味着真正的函数总是被执行,而不管你的条目回调应该做什么。因此,初始化函数将执行两次:首先通过QBDI执行,然后正常执行。这是有问题的,因为根据情况不同,可能会出现一些意外的运行时错误,因为这个函数只需要调用一次。

幸运的是,我们可以利用Frida的拦截器模块带来的另一个函数,该函数包括替换本机函数的实现。这样做,我们能够设置QBDI上下文,执行检测的函数并像往常一样无缝地将返回值转发给调用方,以防止应用程序崩溃,该技术旨在使过程足够稳定以恢复正常执行。

然而,我们仍然面临一个问题,初始函数已被我们自己的新实现完全覆盖。换句话说,该函数的代码不是原始代码,而是由Frida早些时候进行检测的。因此,在我们的代码中,我们必须在使用QBDI执行该函数之前恢复到真正的版本。

修改脚本后,processJniOnLoad()函数如下所示:

初始化

现在让我们编写负责在QBDI上下文中执行该函数的函数,首先,我们需要初始化一个VM,实例化它的相关状态(通用寄存器),并分配一个伪堆栈,该堆栈将在函数执行期间使用。然后,我们必须将QBDI的上下文与当前上下文进行同步,也就是说,将实际CPU寄存器的值放入将要使用的QBDI。现在我们可以决定要检测代码的哪些部分。我们可以显式定义一个任意地址范围,也可以要求DBI检测函数地址所在模块的整个地址空间。为方便起见,在本示例中将使用后者。

回调函数设置

我们必须指定所需的回调函数的种类,接下来,我们要跟踪已执行的每条指令,因此我要放置一条预指令代码回调,这意味着将在位于目标模块中的每个已执行指令之前调用我的函数。

此外,我们还可以添加几个事件回调函数,以便在执行转移到QBDI未检测到的部分代码中或从中返回时通知该事件。当代码与其他模块(例如系统库)(libc.so,libart.so,libbinder.so等)进行交互时,此函数非常有用。请注意,根据您要监视的内容,其他几种回调类型可能会很有帮助。

函数调用

现在我们准备通过QBDI调用目标函数,当然,我们需要传递预期的参数,在我们的例子中是一个指向JavaVM对象的指针和一个空指针。然后,我们可以根据使用的调用约定在特定的QBDI寄存器或虚拟堆栈上检索返回值。这个值必须从我们之前编写的本机替换函数中被转发和返回。否则,应用程序很可能会因为对JNI版本的检查不满意而停止运行,JNI_OnLoad()应该返回JNI版本。

我们可以选择使用QBDI的CPU恢复真正的CPU上下文。

  1. const qbdi = require("/path/to/frida-qbdi");qbdi.import();function qbdiExec(ctx, funcPtr, funcSym, args, postSync) { 
  2.     var vm = new QBDI(); // create a QBDI VM 
  3.     var state = vm.getGPRState(); 
  4.     var stack = vm.allocateVirtualStack(state, 0x10000); // allocate a virtual stack 
  5.     state.synchronizeContext(ctx, SyncDirection.FRIDA_TO_QBDI); // set up QBDI's context 
  6.  
  7.     vm.addInstrumentedModuleFromAddr(funcPtr); 
  8.  
  9.     var icbk = vm.newInstCallback(function (vm, gpr, fpr, data) { 
  10.         var inst = vm.getInstAnalysis(); 
  11.         console.log("0x" + inst.address.toString(16) + " " + inst.disassembly); 
  12.         return VMAction.CONTINUE
  13.     }); 
  14.     var iid = vm.addCodeCB(InstPosition.PREINST, icbk); // register pre-instruction callback 
  15.  
  16.     var vcbk = vm.newVMCallback(function (vm, evt, gpr, fpr, data) { 
  17.         const module = Process.getModuleByAddress(evt.basicBlockStart); 
  18.         const offset = ptr(evt.basicBlockStart - module.base); 
  19.         if (evt.event & VMEvent.EXEC_TRANSFER_CALL) { 
  20.             console.warn(" -> transfer call to 0x" + evt.basicBlockStart.toString(16) + " (" + module.name + "@" + offset + ")"); 
  21.         } 
  22.         if (evt.event & VMEvent.EXEC_TRANSFER_RETURN) { 
  23.             console.warn(" <- transfer return from 0x" + evt.basicBlockStart.toString(16) + " (" + module.name + "@" + offset + ")"); 
  24.         } 
  25.         return VMAction.CONTINUE
  26.     }); 
  27.     var vid = vm.addVMEventCB(VMEvent.EXEC_TRANSFER_CALL, vcbk); // register transfer callback 
  28.     var vid2 = vm.addVMEventCB(VMEvent.EXEC_TRANSFER_RETURN, vcbk); // register return callback 
  29.  
  30.     const javavm = ptr(args[0]); 
  31.     const reserved = ptr(args[1]); 
  32.  
  33.     console.log("[+] Executing " + funcSym + "(" + javavm + ", " + reserved + ") through QBDI..."); 
  34.     vm.call(funcPtr, [javavm, reserved]); 
  35.     var retVal = state.getRegister(0); // x86 so return value is stored on $eax 
  36.     console.log("[+] " + funcSym + "() returned " + retVal); 
  37.     if (postSync) { 
  38.         state.synchronizeContext(ctx, SyncDirection.QBDI_TO_FRIDA); 
  39.     } 
  40.     return retVal;} 

最终,此脚本必须使用frida-compile进行编译,以便正确包含包含QBDI绑定的frida-qbdi.js。官方文档页对编译过程进行了详细说明。

生成一个覆盖文件

具有包含已执行的所有指令的跟踪是很有必要的,但对于反向工程来说并不方便。事实上,我们不能一眼就分辨出整个执行过程中的路径。为了正确地呈现捕获的轨迹,在反汇编器中集成可能是一个好主意。这样,人们就可以准确地看到全部的路径。然而,大多数反汇编器本身并没有提供这样的选项。对我们来说幸运的是,各种插件都提供了这样的选项。在本例中,我们使用Lighthouse和Dragondance分别用于IDA Pro和Ghidra。这些插件可以通过导入drcov格式的代码覆盖文件来轻松配置,DynamioRIO使用这种格式存储关于代码覆盖率的信息。

drcov格式非常简单:除了标头字段外,还必须指定描述进程的内存布局的模块表,为每个模块分配一个惟一的ID。此后,就有了所谓的基本块表。该表包含执行期间已命中的每个基本块,一个基本块由三个属性定义:它的开始(相对)地址,它的大小和它所属模块的ID。

由于我们能够在每个基本块的开头放置一个回调,因此我们可以确定这些值,从而生成我们自己的文件。现在,我们需要检索基地址和所有已执行的基本块的大小,而不是按指令规模工作。实际上,我们必须定义一个类型为BASIC_BLOCK_NEW 的QBDI事件回调函数,该函数负责收集此类信息。每当QBDI将要执行一个新的基本程序块时,我们的函数都会被调用,到目前为止尚不知道。在本示例中,我们不仅要打印有关此基本块的一些有趣的值,还要创建一个代码覆盖率文件,以后可以在反汇编器中将其导入。但是,在Frida脚本的上下文中,我们无法操作文件。结果,我们必须停止使用frida命令行实用程序,并直接依赖于Frida提供的消息传递系统从底层Python脚本运行我们的JS脚本。这样做使我们能够在JS和Python端之间进行通信,然后对所需的文件系统执行所有操作。

  1. var vcbk = vm.newVMCallback(function (vm, evt, gpr, fpr, data) { 
  2.     const module = Process.getModuleByAddress(evt.basicBlockStart); 
  3.     const base_addr = ptr(evt.basicBlockStart - module.base); // address must be relative to the module's start 
  4.     const size = evt.basicBlockEnd - evt.basicBlockStart; 
  5.     send({"bb": 1}, getBBInfo(base_addr, size, module)); // send the newly discovered basic block to the Python side 
  6.     return VMAction.CONTINUE;});var vid = vm.addVMEventCB(VMEvent.BASIC_BLOCK_NEW, vcbk); 

请注意,getBBInfo()函数仅在发送消息之前先序列化有关基本块的信息。显然,Python端必须处理此类消息,将与执行相关的内容保留在内存中,并最终以上述正确的格式相应地生成代码覆盖文件。如果一切顺利,由于其相应的代码覆盖插件,可以将输出文件加载到IDA Pro或Ghidra中。所有已执行的基本块都将突出显示,现在我们可以更清楚地遵循执行流程,而只关注代码的相关部分。

总结

Java/Kotlin逆向工程的易用性使得Android应用程序开发人员可以使用C/ c++来实现某些漏洞层面的操作。因此,本文所讲的方法就是要让逆向工程师逆向的过程变得很困难。因此,将QBDI与Frida一起使用是一个非常好的选择,尤其是在研究那些本机函数时。这种组合确实提供了一种方法,可以弄清一个函数在不同层次上的作用,即函数、基本块和指令规模。此外,还可以利用QBDI的执行传输事件来解析对系统库的外部调用,或者跟踪内存访问,然后了解执行的总体情况。为了有效地协助反向工程师,可以将收集的信息明智地集成到一些现有的面向反向工程的工具中,以完善其静态分析。除了生成执行流程的直观表示之外,从运行时获取此类反馈对于其他与安全相关的目的(如模糊测试)也很有价值。还值得注意的是,如果函数很重要,Frida和QBDI都可以提供C / C ++ API。

本文翻译自:https://blog.quarkslab.com/why-are-frida-and-qbdi-a-great-blend-on-android.html如若转载,请注明原文地址:

 

责任编辑:姜华 来源: 嘶吼网
相关推荐

2021-01-16 16:07:51

RustAndroid Nat内存

2017-05-11 21:30:01

Android动态代理ServiceHook

2020-09-21 09:58:01

Frida

2009-11-16 16:43:24

PHP数组删除

2010-03-04 09:51:07

Linux动态库

2020-10-28 14:58:21

漏洞uTorrent协议层

2023-10-30 11:45:44

FridaC++函数

2009-11-16 10:16:24

PHP文件上传

2023-10-24 07:22:22

Nginx运维管理

2016-11-23 16:48:20

react-nativandroidjavascript

2010-07-14 14:31:27

POP3和IMAP4

2022-01-19 08:00:00

静态代码动态代码开发

2011-08-23 14:46:59

云计算

2009-12-18 10:39:50

路由器关键技术

2015-09-22 09:50:36

FacebookAndroid

2020-09-22 10:05:14

AsyncRAT

2015-10-10 16:02:36

React NativAndroid

2023-02-13 14:01:32

2021-03-08 00:11:02

Spring注解开发

2021-03-18 22:06:01

数据分析编程语言大数据
点赞
收藏

51CTO技术栈公众号