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

Android安全交流群：478084054
记录一些实现细节。（下面贴代码时，省略了一些无关代码，并且加了一些注释）

一、ArtRuntime::HookMethod对被Hook的method所对应的ArtMethod对象做了什么？

见代码中的注释：

二、关于“原method”的执行。

首先，在ArtRuntime::HookMethod中，会根据原method克隆一个新的method，然后保存到param->origin_method_。

这里的hooked_method相当于原method对应的ArtMethod对象，然后调用ArtMethod::Clone为原method克隆了一个新的method（为了Hook，原来的ArtMethod会被修改，所以克隆一个新的保存起来）。这个新的method随着param参数，最终一路传递到ArtRuntime::InvokeOriginalMethod。

这里可以看到，原method最终是通过JNI调用java.lang.reflect.Method.invoke()反射执行的。

三、ArtMethod::Clone是如何实现的。

分段贴代码：

第1步：先根据原ArtMethod，克隆出一个新的ArtMethod。

第2步：调整access_flags。

这里把非direct方法的访问权限设置为private有什么作用？

（后来想了想，是不是防止后面调用原method时，不要去调用该method可能override的父类方法？）

另外，为什么要去除kAccSynchronized？不去除有什么影响？

（防止阻塞？）

第3步：设置hotness_count和profiling_info。

备注：注释中的“b>”写错了。由GetEntryPointFromJni得到的不是新克隆出来的ArtMethod的profiling_info，而是原方法ArtMethod的profiling_info。

在Android9上，ProfilingInfo结构是这样的：

image014.png

第4步：对于非native方法，将compiled_code入口点设置为art_quick_to_interpreter_bridge。

这里为什么要修改compiled_code入口点？是因为前面阻止了JIT编译，所以该方法不会有compiled_code，所以将compiled_code入口点设置为art_quick_to_interpreter_bridge，由Interpreter解释执行？

第5步：将jni_clone_method转换为Method对象，然后调用setAccessible，取消Java方法调用时的访问权限检查。

最后将java_method返回。

四、ArtRuntime::HookMethod中调用ProfileSaver::ForceProcessProfiles是何意？

是因为“hooked_method.Clone里面修改了hooked_method的profiling_info”，然后调用ProfileSaver::ForceProcessProfiles强制更新到disk？

五、ArtRuntime::HookMethod利用ScopedSuspendAll暂停和恢复VM。

暂停和恢复VM的工作是在ScopedSuspendAll的构造和析构函数中完成的：

实际是调用了art::Dbg::SuspendVM和art::Dbg::ResumeVM。

六、ArtRuntime::InvokeOriginalMethod中对于“GC可能带来的影响”的处理：

这里有一个“param->decl_class_ != decl_class”的比较，先看param->decl_class_是怎么来的：

实际就是原method（被Hook的Java method）对应的ArtMethod数据结构中的declaring_class_成员，然后保存到param，一路传递到ArtRuntime::InvokeOriginalMethod。

然后看decl_class，它是param->hooked_native_method_指向的ArtMethod数据结构中的declaring_class_成员。而param->hooked_native_method_就是原method对应的ArtMethod。

既然param->decl_class_和decl_class都是由原method对应的ArtMethod数据结构中的declaring_class_得到的，那怎么会不一样呢？按lody的注释可知是GC影响的，因为ArtMethod数据结构中的declaring_class_是一个GcRoot reference。

param->decl_class_保存的是ArtMethod以前的declaring_class_，而decl_class是该ArtMethod此刻的declaring_class_。在这期间，由于GC的影响，declaring_class_可能已经发生了变化。

发生这种情况怎么办呢？根据param->hooked_native_method_，也就是原method（被Hook的Java method）此刻对应的ArtMethod重造一个origin_method，然后再执行。

七、关于ArtRuntime::GetCurrentArtThread()的实现

以前是这样实现的：

但可能有的系统中java.lang.Thread类中没有nativePeer这个成员，所以后来lody修正了一下：

如果java_lang_Thread_nativePeer为空，就返回__get_tls()[7/TLS_SLOT_ART_THREAD_SELF/]。

这个是怎么来的呢？看一下art::Thread::Current()的实现就清楚了：

__get_tls的定义在“/bionic/libc/private/__get_tls.h”中：

八、whale还支持“bypass Hidden API Policy”，实现如下：

API-Level在ANDROID_O_MR1(27)以下的，因为没有Hidden API策略，所以直接返回true。否则调用ArtRuntime::EnforceDisableHiddenAPIPolicyImpl。

针对Android P预览版的处理就不看了。

在Android P的Release版上是通过InlineHook art:: hiddenapi::GetMemberActionImpl和art:: hiddenapi::GetMemberActionImpl来实现的。

如果传入的member是可访问的话，这两个函数会返回kAllow。

而被劫持之后，成了下面这样：

无论传入的什么，都返回false。false是0，相当于kAllow。

另外，在ArtRuntime::EnforceDisableHiddenAPIPolicyImpl的开头还有下面这段代码，这是什么意思呢？

我的理解是：java.lang.Object的shadow$klass成员应该是受hiddenapi策略保护的，这里是想先测试一下，如果能够获取shadow$klass的fieldID，说明在当前系统中，没有启动hiddenapi保护，那就直接返回true就可以了，不需要进行InlineHook强行Disable了。

文/十八垧