看我如何绕过android P的Restrictions on non-SDK interfaces（限制反射调用系统私有方法）

0x1:背景

android P出了个新特性，限制了对hidden field 和 method 的 反射调用，那组件化这些是不是都快要挂了。我第一感觉应该是可以绕过的，于是马上研究了下，详情可以看
https://developer.android.com/preview/restrictions-non-sdk-interfaces.html
限制私有api的调用，这意味着目前几乎所有的组件化框架和多开这些都会失效，这些框架都反射调用了大量的私有系统api，android P目前给了大家一个过渡的时间，用了私有api的暂时不会奔溃，只是在logcat都会给出现warning，比如：

Accessing hidden field Landroid/os/Message;->flags:I (light greylist, JNI). Accessing hidden method Landroid/app/ActivityThread;->currentActivityThread()Landroid/app/ActivityThread; (dark greylist, reflection)

但之后的版本，就会出更严格的限制，使用这些api直接回抛Error，比如：NoSuchFieldError和NoSuchMethodError

0x2:源码分析

https://android.googlesource.com/platform/art/+/d7fbc0eb824e495b940dd739404d945a35f01fd3%5E%21/#F2(感谢武华第一时间给我发了代码diff)
这个提交是处理hidden API的情况的，我们需要的代码差不多就在这里面了。通过逆向思维，我们查找打印出warning的关键字Accessing hidden method ，可以定位到函数在https://android.googlesource.com/platform/art/+/master/runtime/hidden_api.h

// Issue a warning about method access. inline void WarnAboutMemberAccess(ArtMethod* method, AccessMethod access_method) REQUIRES_SHARED(Locks::mutator_lock_) { std::string tmp; LOG(WARNING) << "Accessing hidden method " << method->GetDeclaringClass()->GetDescriptor(&tmp) << "->" << method->GetName() << method->GetSignature().ToString() << " (" << HiddenApiAccessFlags::DecodeFromRuntime(method->GetAccessFlags()) << ", " << access_method << ")"; }

接着查找函数引用，找到上层函数ShouldBlockAccessToMember,

// Returns true if access to `member` should be denied to the caller of the // reflective query. The decision is based on whether the caller is in boot // class path or not. Because different users of this function determine this // in a different way, `fn_caller_in_boot(self)` is called and should return // true if the caller is in boot class path. // This function might print warnings into the log if the member is greylisted. template<typename T> inline bool ShouldBlockAccessToMember(T* member, Thread* self, std::function<bool(Thread*)> fn_caller_in_boot, AccessMethod access_method) REQUIRES_SHARED(Locks::mutator_lock_) { DCHECK(member != nullptr); Runtime* runtime = Runtime::Current(); if (!runtime->AreHiddenApiChecksEnabled()) { // Exit early. Nothing to enforce. return false; } Action action = GetMemberAction(member->GetAccessFlags()); if (action == kAllow) { // Nothing to do. return false; } // Member is hidden. Walk the stack to find the caller. // This can be *very* expensive. Save it for last. if (fn_caller_in_boot(self)) { // Caller in boot class path. Exit. return false; } // Member is hidden and we are not in the boot class path. // Print a log message with information about this class member access. // We do this regardless of whether we block the access or not. WarnAboutMemberAccess(member, access_method); // Block access if on blacklist. if (action == kDeny) { return true; } // Allow access to this member but print a warning. DCHECK(action == kAllowButWarn || action == kAllowButWarnAndToast); // Depending on a runtime flag, we might move the member into whitelist and // skip the warning the next time the member is accessed. if (runtime->ShouldDedupeHiddenApiWarnings()) { member->SetAccessFlags(HiddenApiAccessFlags::EncodeForRuntime( member->GetAccessFlags(), HiddenApiAccessFlags::kWhitelist)); } // If this action requires a UI warning, set the appropriate flag. if (action == kAllowButWarnAndToast || runtime->ShouldAlwaysSetHiddenApiWarningFlag()) { Runtime::Current()->SetPendingHiddenApiWarning(true); } return false; }

到这里，已经不用再跟踪上层应用了，这个逻辑已经很清楚了，有兴趣的可以自己继续跟踪上去。

0x3:如何绕过

• 方法一：
  我们的目的就是让ShouldBlockAccessToMember这个函数返回false，这样就能绕过限制了。

runtime->AreHiddenApiChecksEnabled这里是个很关键的开关，当开关是false的时候，会不检查私有函数的调用。在
https://android.googlesource.com/platform/art/+/master/runtime/runtime.h
我们找到了这个函数的逻辑：

 bool AreHiddenApiChecksEnabled() const { return do_hidden_api_checks_; }

do_hidden_api_checks_是个全局变量，继续查找do_hidden_api_checks_ 的引用，可以发现有个SetHiddenApiChecksEnabled的函数，

void SetHiddenApiChecksEnabled(bool value) { do_hidden_api_checks_ = value; } 

因此，如何让do_hidden_api_checks_赋值为false很明显了，直接调用这个函数SetHiddenApiChecksEnabled(false)即可，不过找到这个函数地址也是有点小难度的，要找到Runtime这个实例的基地址加上SetHiddenApiChecksEnabled的函数偏移才行，这个偏移只能硬编码，而且从 Android N 开始，谷歌对NDK调用私有API的行为做了限制，意味着通过dlopen系统库和dlsym函数符号找到函数地址已经失效了，不过我们还是可以通过一些特别的手段解决这个问题的，这里就不继续深入了，有兴趣的可以私下找我探讨。

• 方法二：这个方法是比较简单粗暴的，我们的目的是让ShouldBlockAccessToMember这个函数返回false，因此直接通过hook这个函数修改返回结果为false即可，我这边已经通过简单的demo绕过了这个warning。关键实现代码如下

void* (*oldShouldBlockAccessToMember)(void* p0,void* p1,void* p2,void* p3) = NULL; bool* myShouldBlockAccessToMember(void* p0,void* p1,void* p2,void* p3) { LOGE("myShouldBlockAccessToMember"); return false; } extern "C" __attribute__((constructor)) void hookinit() { LOGE("#---------- Start hookinit ---------------#"); unsigned long ShouldBlockAccessToMember = (long)base + 0x2af41c+1; MSHookFunction((void *)ShouldBlockAccessToMember, (void *)myShouldBlockAccessToMember, (void**)&oldShouldBlockAccessToMember); LOGE("==hook ShouldBlockAccessToMember ok") LOGE("#---------- End hookinit ---------------#"); } 

0x4:结论

实际上无论谷歌怎么限制，主要不是在内核层限制，在自己的进程空间里面限制的话，理论上都是可以绕过的。