一、前言
不论是APK代码抽取加固还是热更新，亦或是Xposed/frida hook，都离不开ArtMethod这个结构体。
但该结构体从andorid 4.4开始一直到现在的9.0，或多或少都会update，这导致之前版本的脱壳或者热更新都需要实时适配……想想，还是针对该结构体进行一个总结，总结过程当中会顺便介绍一些常见的框架使用到该结构体的部分。
主要做个人的一个总结，有些地方可能表述不清……
目的：一方面是进行个人总结，加深印象，另一方面便于以后查询适配。
适用于：了解hook原理基础。
二、Method与ArtMethod
谈到ArtMethod还是提下4.4之前Method。
因为本次是针对ArtMethod做各版本总结，这里简单列出对比，方便过渡。
针对Method结构体，不得不谈谈xposed，还有第一代指令抽取加固方式。实际就是找到Method 中的 insns指令码字段（加固时是在dex文件，hook则直接获取函数指针得到该指令码字段），然后运行时替换。
而ArtMethod，是ART下的产物。其结构较于Method发生了变化，当dex2oat的时候，还会有多种方法内联优化。而方法内联会改变原本的方法分布和调用流程，对加固、热修复、hook，实际上都有一定的影响。当然，这个是后话，就不再赘述。
三、ArtMethod结构
先给出ArtMethod结构主要的字段。
英文是源码，中文是个人注释。
版本：android-9.0.0_r30：
class ArtMethod {
…………
protect:
// Field order required by test "ValidateFieldOrderOfJavaCppUnionClasses".
// The class we are a part of.
//GCroot添加在N，实际是个指针，这个字段即是表明所属类，一般用喜闻乐见的uint32_t代替
GcRoot declaring_class_;
// Access flags; low 16 bits are defined by spec.
// Getting and setting this flag needs to be atomic when concurrency is
// possible, e.g. after this method's class is linked. Such as when setting
// verifier flags and single-implementation flag.
//可以理解为该函数的标志位，如函数为public,private,static,native等。
//这个字段java2native，xposed hook的标志位。
//值得一提的是，9.0以后的Hid API，对应函数GetHiddenApiAccessFlags，不是这个，但是看到这里，可以考虑如何修改hide标志位
std::atomic access_flags_;
/* Dex file fields. The defining dex file is available via declaring_class_->dex_cache_ */
// Offset to the CodeItem.
//加固代码替换点。
//里面指向code_item指针,code_item存储的实际是dex当中的字节码.其用处本来是适配dalvik解释器，即无法编译成机器码的，用解释器来执行。
//
uint32_t dex_code_item_offset_;
// Index into method_ids of the dex file associated with this method.
//主要作为寻址替换用
uint32_t dex_method_index_;
/* End of dex file fields. */
// Entry within a dispatch table for this method. For static/direct methods the index is into
// the declaringClass.directMethods, for virtual methods the vtable and for interface methods the
// ifTable.
uint16_t method_index_;
// The hotness we measure for this method. Not atomic, as we allow
// missing increments: if the method is hot, we will see it eventually.
//方法被记录的频率热度，用在Android N+混合编译部分，根据该值来判断是否使用JIT编译。
uint16_t hotness_count_;
// Fake padding field gets inserted here.
// Must be the last fields in the method.
//没错，这个Fields9.0地址又改了，需适配，在下面详细介绍每个字段
struct PtrSizedFields {
// Depending on the method type, the data is
// - native method: pointer to the JNI function registered to this method
// or a function to resolve the JNI function,
// - conflict method: ImtConflictTable,
// - abstract/interface method: the single-implementation if any,
// - proxy method: the original interface method or constructor,
// - other methods: the profiling data.
//这个字段顾名思义，根据方法类型，会充当不同作用，是不是可以理解为以前几个指针的复合……
void* data_;
// Method dispatch from quick compiled code invokes this pointer which may cause bridging into
// the interpreter.
void* entry_point_from_quick_compiled_code_;
} ptr_sized_fields_;
…………
｝
上面是最新的9.0的结构。以下重点介绍几个版本改动处，原因，以及适配点。
前面的结构几乎没有变化，但是要开始谈论，还是得溯源到5.0……
5.0地址在runtime/mirror/art_method.h中。
关键结构：
class ArtMethod {
…………
protect:
HeapReference declaring_class_;
HeapReference> dex_cache_resolved_methods_;
HeapReference> dex_cache_resolved_types_;
uint32_t access_flags_;
uint32_t dex_code_item_offset_;
uint32_t dex_method_index_;
uint32_t method_index_;
struct PACKED(4) PtrSizedFields {
void* entry_point_from_interpreter_;
void* entry_point_from_jni_;
void* entry_point_from_quick_compiled_code_;
#if defined(ART_USE_PORTABLE_COMPILER)
void* entry_point_from_portable_compiled_code_;
#endif
} ptr_sized_fields_;
static GcRoot java_lang_reflect_ArtMethod_;
｝
……
这个时候，还存在entry_point_fromjni，entry_point_frominterpreter，关键在于这两个字段的被广泛用于hook（frida,xposed）、加固以及热更新（所以版本更新就得适配了……）
下面重点介绍下PtrSizedFields结构，其版本做过多个改变，实际上是进行了精简，不过还是需要适配……
5.0：
struct PACKED(4) PtrSizedFields {
void* entry_point_from_interpreter_;
void* entry_point_from_jni_;
void* entry_point_from_quick_compiled_code_;
#if defined(ART_USE_PORTABLE_COMPILER)
void* entry_point_from_portable_compiled_code_;
#endif
} ptr_sized_fields_;
6.0：
struct PtrSizedFields {
void* entry_point_from_interpreter_;
void* entry_point_from_jni_;
void* entry_point_from_quick_compiled_code_;
} ptr_sized_fields_;
7.0：
struct PtrSizedFields {
ArtMethod** dex_cache_resolved_methods_;
void* dex_cache_resolved_types_;
void* entry_point_from_jni_;
void* entry_point_from_quick_compiled_code_;
} ptr_sized_fields_;
8.0：
struct PtrSizedFields {
ArtMethod** dex_cache_resolved_methods_;
void* data_;
void* entry_point_from_quick_compiled_code_;
} ptr_sized_fields_;
9.0：
struct PtrSizedFields {
void* data_;
void* entry_point_from_quick_compiled_code_;
} ptr_sized_fields_;
简单谈一下几个关键字段的作用与各版本改变，可以对照之上的看：
uint32_t access_flags_：标志位，常见的 Hook方案，将待hook的java函数修改为native函数，就是修改该标志位。
uint32_t dex_code_item_offset_：最终可得到code_item地址，里面存储这方法指令。但需先获取dex头地址
entry_point_from_jni_：用于存储jni方法信息。非jni方法的entrypoint_from_jni_是无用的，所以很多hook框架将该字段作为原方法信息备份地址，如xposed,frida都是将原方法保存到entry_point_from_jni_。但android 7.0也就是N后，该字段被用于保存方法的profile,这个又和hotness_count_相关，及混合编译，有兴趣可以去看源码，所以这个字段不能作为原方法保存地址。而且在8.0以后，entry_point_from_jni_同样被移除了……
entry_point_from_interpreter_：通过interpreter方式调用方法 解释执行入口。android 7.0，entrypoint_from_interpreter_已经被移除，非jni方法的执行通过entrypoint_from_quick_compiled_code_进行分发。
entry_point_from_quick_compiled_code:
这里就是常见的ART Hook方法为，替换方法的入口点，替换后的入口点，会重新准备栈和寄存器，执行hook的方法。注意，这里指向的是汇编代码，运行的是已经预处理过的机器码。
从上面就可以很清晰的看到一个7.0之前的hook流程：获取函数的入口，得到函数结构体，替换accessflags将方法native化，保存原函数信息在entry_point_fromjni，替换entry_point_from_quick_compiled_code。调用被hook的方法时，首先会跳转替换的方法，然后跳转到entry_point_fromjni所指向的原方法。
当然，每个版本的hook方式不同，有些会采用机器码执行，有些会采用解释器执行，同样的加固原理也不同。
这边可以发现两种指令抽取加固原理：
替换dex_code_itemoffset对应的code_item，不改变原方法属性
改变原方法属性，直接替换entry_point_from_quick_compiled_code。
通过artmethod关键结构，可以发现，这都是可行的操作。
但这里仅从原理角度分析可行，但实际环境适配与汇编代码编写，都是需要处理的，因为Android N的混合编译，垃圾回收修改，会导致的诸多问题，而7.0以后的适配，实际也就是针对原函数存放地址的适配，只能简略提一提，不多提。
忽然想到，现在的vm加固，若采用ARM 虚拟化保护，需要制定汇编解释器，将原始函数转换成字节码，保存原始函数的寄存器以及堆栈信息，然后在运行当中，然后用自定义解释器解析，这一部分又是一块需要大量实验和适配的地方……当然只是闲扯一句。
以上，实际深入了解ArtMethod结构后，会对以往版本的hook、代码抽取加固技术等有一个更清晰的认识，通过源码理解字段的作用和功能，也可以帮助产品进行适配，不至于在版本更新时，无从下手。
原文作者：deff
原文链接：https://bbs.pediy.com/thread-248898.htm
转载请注明：转自看雪学院
更多阅读：
[原创]编译libc.so过time函数反调试
IE VBScript 漏洞之CVE-2018-8174
IE VBScript 漏洞之CVE-2014-6332
[原创]如何调试xxProtect
[原创]源码简析之ArtMethod结构与涉及技术介绍