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<ArtField>和art:: hiddenapi::GetMemberActionImpl<ArtMethod>来实现的。
如果传入的member是可访问的话，这两个函数会返回kAllow。
而被劫持之后，成了下面这样：
无论传入的什么，都返回false。false是0，相当于kAllow。
另外，在ArtRuntime::EnforceDisableHiddenAPIPolicyImpl的开头还有下面这段代码，这是什么意思呢？
我的理解是：java.lang.Object的shadow$klass成员应该是受hiddenapi策略保护的，这里是想先测试一下，如果能够获取shadow$klass的fieldID，说明在当前系统中，没有启动hiddenapi保护，那就直接返回true就可以了，不需要进行InlineHook强行Disable了。
文/十八垧
网友评论