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）。
文/十八垧
