看我如何绕过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:结论

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