开源Hook框架-whale-实现浅析(1)

0.182字数 1442阅读 1227

Android安全交流群:478084054

whale是lody大神开源的一个Hook框架,支持ART下Java方法的HOOK,也支持native InlineHook。

本文走马观花一下。

whale支持Xposed-Style Method Hook。

Xposed Hook的代码通常这么写:

在whale的java/com/lody/whale/xposed目录中存放的是兼容Xposed风格的代码。

所以,先看一下whale的XposedHelpers.findAndHookMethod和XC_MethodHook的实现源码。

其中,findAndHookMethod用来完成Method Hook,XC_MethodHook对象用于回调。

简单看一下class XC_MethodHook:

重写XC_MethodHook的beforeHookedMethod或者afterHookedMethod,这两个方法相当于是在原方法的调用前后插桩。根据需要,把我们逻辑代码放在这两个函数中就可以了。

重点看一下XposedHelpers.findAndHookMethod。

findAndHookMethod先调用findMethodExact得到要Hook的Method对象,然后调用XposedBridge.hookMethod完成Hook。

getParameterClasses用于获取参数的Class类型:

从getParameterClasses的实现来看,参数类型不仅可以传Class,还可以直接传String。

如:Bundle.class或"android.os.Bundle "。

有了方法名和参数类型,以及实现该方法的clazz,findMethodExact的实现就很简单了:

这里还维护了一个methodCache,用于存储所有已经find过的method。

回到findAndHookMethod,继续跟踪代码,看XposedBridge.hookMethod的实现。

所有已经Hook过的method及其对应的callbacks,全部存储在sHookedMethodCallbacks中,这是一个HashMap。如果该method已经Hook过,那直接把callback回调对象加入到其对应的callbacks集合中就可以了。这样在该method被调用时,callbacks集合中所有回调都会被遍历执行。

如果该method没有被Hook过,那就调用WhaleRuntime.hookMethodNative进行Hook。

这是一个native方法,对应的代码在whale/src/android/art/native_on_load.cc中。

继续跟踪ArtRuntime::HookMethod,完成Hook的关键代码就在这里了。

这里省略了大量细节代码。先抓主干,了解基本原理。

ArtRuntime::HookMethod将被Hook的method设置为native方法,然后将Jni入口点设置为一个closure。这样当该method被调用时,就会执行这里设置的closure。因为被Hook的method已经为native,所以ArtMethod结构中的dex_code_item_offset_成员就没用了,直接清0。

另外,将quick_compiled_code和interpreter的入口点分别设置为quick_generic_jni_trampoline_和artInterpreterToCompiledCodeBridge,这样无论被Hook的方法从解释器执行,还是直接以本地指令的方式执行,最终都会执行Jni入口点,都会执行这里设置的closure。

所以,ArtRuntime::HookMethod执行之后,被Hook方法的执行就由closure接管了,这个closure是由BuildJniClosure构造的,继续跟踪该方法。

这里利用libffi根据原method的参数和返回类型构造一个jni-closure(jni函数相比原Java method会多两个参数,一个是JNIEnv*,另一个是jclass或者jobject)。

libffi是一个开源项目,可以用于动态生成遵守特定调用约定的代码。android系统源码中也有这个库(android/platform/external/libffi)。

当被Hook的method被调用时,就会执行这里构造的closure的callback,也就是FFIJniDispatcher,并将原参数传入。另外,这里创建closure时,还将ArtHookParam*类型的参数param作为userdata传入,所以FFIJniDispatcher被调用的时候,这里的参数param也会作为userdata传入。

看一下FFIJniDispatcher的实现:

FFIJniDispatcher先利用QuickArgumentBuilder将传给原methhod的所有参数存放到一个jobjectArray参数数组中。然后根据原method的返回类型,调用InvokeJavaBridge或InvokeVoidJavaBridge。

继续跟踪ArtRuntime::InvokeHookedMethodBridge:

这里是直接调用java_class_的bridge_method_方法。

java_class_和bridge_method_是在ArtRuntime::OnLoad中初始化的:

而ArtRuntime::OnLoad是被libwhale.so的JNI_Onload方法调用的。

所以,这个bridge_method_就是com/lody/whale/WhaleRuntime的handleHookedMethod方法。

继续看XposedBridge.handleHookedMethod:

beforeHookedMethod和afterHookedMethod的调用就在这里了,相当于在原函数的调用点前后各插了一个桩。

这里的callbacks是通过参数additionalInfo得到的,而参数additionalInfo是早在XposedBridge.hookMethod方法中就创建的,并一路传到了XposedBridge.handleHookedMethod。

再把上面的图重复贴一下:


在XposedBridge.handleHookedMethod中,通过XposedBridge.invokeOriginalMethod来调用原方法,继续跟踪一下:

XposedBridge.invokeOriginalMethod又调用了WhaleRuntime.invokeOriginalMethodNative。

这是一个native方法,对应源码在whale/src/android/art/native_on_load.cc中。

继续ArtRuntime::InvokeOriginalMethod:

ArtRuntime::InvokeOriginalMethod先通过参数拿到原始的method,然后通过java.lang.reflect.Method.Invoke()反射调用。

参数slot是在ArtRuntime::HookMethod方法中创建的,类型是“ArtHookParam*”,param->origin_method_中保存原method对象。

至此,Java method的Hook流程基本上跟踪完了。不过,忽略了很多值得关注和学习的细节,后面笔记再写。

除了Java method的Hook之外,whale还支持对native函数的InlineHook。

whale/include/whale.h:

在built目录下还有编译好的libwhale.so可以直接使用。

看一下WInlineHookFunction的实现:

看一下arm平台下的Hook实现ArmInlineHook:

继续看ArmInlineHook::StartHook:

native层的InlineHook都是通过在目标方法的指令开始处加跳转指令来实现的。

这块很复杂,先不看了。

ArmInlineHook的实现借助了vixl,这是一个arm平台的运行时代码生成库。android系统源码也有这个库(android/platform/external/vixl)。

文/十八垧