每日一问 | android hidden api 不是禁用反射，以及如何突破，「元反射」不行了？

优秀啊！这是直接在java层通过unsafe去操作natvie内存了？照这么说，是不是可以写一个inline hook for Java了？另外补充一个，dalvik.system.VMDebug下还  ...查看更多

优秀啊！这是直接在java层通过unsafe去操作natvie内存了？照这么说，是不是可以写一个inline hook for Java了？另外补充一个，dalvik.system.VMDebug下还有个叫allowHiddenApiReflectionFrom的方法可以在vm.isJavaDebugable==true下使用，关闭单个类的访问权限检查

大佬

Unsafe 整出来的内存不能运行的，不过 Android 有 mmap 的 java binding 所以用 unsafe 整 native inline hook 也是完全是可以的（不过获取符号时  ...查看更多

Unsafe 整出来的内存不能运行的，不过 Android 有 mmap 的 java binding 所以用 unsafe 整 native inline hook 也是完全是可以的（不过获取符号时候就需要用 java 进行 ELF 解析比较痛苦）。甚至也可以做 java hook 的（替换 artmethod 的 entrypoint）。

有纯java实现的mmap？不过我看现在网上很多提到用mmap的，都是在native层实现的啊，那也还是避免不了使用jni，用了jni，那再用unsafe就没意义了。。不知道java.nio.File  ...查看更多

有纯java实现的mmap？不过我看现在网上很多提到用mmap的，都是在native层实现的啊，那也还是避免不了使用jni，用了jni，那再用unsafe就没意义了。。不知道java.nio.FileChannel行不行？它有个map方法，由FileChannelImpl来实现（http://aospxref.com/android-12.0.0_r3/xref/libcore/ojluni/src/main/java/sun/nio/ch/FileChannelImpl.java#984），看了下对应的底层代码，是用mmap来实现的（http://aospxref.com/android-12.0.0_r3/xref/libcore/ojluni/src/main/native/FileChannelImpl.c#FileChannelImpl_map0）

有:https://cs.android.com/android/platform/superproject/+/master:libcore/luni/src/main/java/android/s  ...查看更多

有:https://cs.android.com/android/platform/superproject/+/master:libcore/luni/src/main/java/android/system/Os.java;drc=bacbadbc61a48e90cb5976040e7e0695bb75b69a;l=474 但是没有 mprotect 所以 hook 还是很麻烦

原来这里还有直接提供api啊，学到了👍，至于没有提供mprotect函数，那不做inline hook也可以啊，只做java hook。YAHFA的方案native代码比较少，我感觉可以试一下。不过  ...查看更多

原来这里还有直接提供api啊，学到了👍，至于没有提供mprotect函数，那不做inline hook也可以啊，只做java hook。YAHFA的方案native代码比较少，我感觉可以试一下。不过好像它的方案不支持像sandhook那样的动态hook，只能预先编译好代码，如果要在java层添加支持，那动态的jit compile也是个难题

做 art hook 这里有一个先例：https://weishu.me/2017/03/20/dive-into-art-hello-world/ ，简单改一下可以变成类似 yahfa 那种形式。没  ...查看更多

做 art hook 这里有一个先例：https://weishu.me/2017/03/20/dive-into-art-hello-world/ ，简单改一下可以变成类似 yahfa 那种形式。没懂你说的动态 hook 具体指什么，像 xposed 那样？

像 xposed 那种的话我自己有在维护一个：https://github.com/canyie/pine/ 。真要做的话，用纯 java 写一个 elf 解析器解析到 libc.so 里一些关键函数  ...查看更多

像 xposed 那种的话我自己有在维护一个：https://github.com/canyie/pine/ 。真要做的话，用纯 java 写一个 elf 解析器解析到 libc.so 里一些关键函数的地址，用汇编处理一下寄存器和跳转然后编译成机器码，Os.mmap 申请到 executable memory 往里填，然后找一个不用的方法改它的 entrypoint 然后调用这个方法可以实现调用 native function。不过这种活工作量太大稳定性上不去没人想做

感谢指路！👍我去学习一下。是的，就是动态生成类之后调用jit_compile_method这一步。你说的 "汇编处理一下寄存器和跳转然后编译成机器码" 是指在java层做动态编译吗？还能这样？  ...查看更多

感谢指路！👍我去学习一下。是的，就是动态生成类之后调用jit_compile_method这一步。你说的 "汇编处理一下寄存器和跳转然后编译成机器码" 是指在java层做动态编译吗？还能这样？

不需要啊。。像 epic 那样写好汇编编译好然后写在 java 代码里就好

👍感谢解惑！

终于等到了

惭愧😭本来还想找一下java层有没有其他可行的方法，结果找了好久都找不到，流下了没有技术的泪水😭

4 不对，你会发现还是不能调用 VMRuntime.setHiddenApiExemptions

楼下 @回家的诱惑 已经回复得很清晰了。android.jar 本质就是使用 stub 而已，这种方法我自己也在用 https://github.com/LSPosed/LSPosed/tree/ma  ...查看更多

楼下 @回家的诱惑 已经回复得很清晰了。android.jar 本质就是使用 stub 而已，这种方法我自己也在用 https://github.com/LSPosed/LSPosed/tree/master/hiddenapi-stubs。但是这种方法依然不能访问 hiddenapi-flags.csv 中标注 blacklist 的方法，也就是说你的方法依然不能调用 setHiddenApiExemptions。

在用的话到这里就可以了，没必要再往下突破，调用不了是你权限不够。android.jar 本质就是compileOnly

再往下就不是技术了，耍小聪明和官方思想对着干没必要，要用到哪个api直接提给官方就完了

。。你可以自己测试一下，用链接的方式调用和用反射调用有什么区别，链接能调用到的 api 反射也可以，反之反射不可以的 api 链接也不行。

你这不是知道么，能直接调用的为什么还用反射。使用反射调用系统api以后的新系统适配会很难，只在运行的时候报错

你在说什么？直接调用和反射调用是同一个效果那说明直接调用也会被 hidden api 策略限制，根本不是什么权限问题，题目要求的就是突破限制，你可以用 adb 关掉限制再试一下是不是同一个效果；另外如  ...查看更多

你在说什么？直接调用和反射调用是同一个效果那说明直接调用也会被 hidden api 策略限制，根本不是什么权限问题，题目要求的就是突破限制，你可以用 adb 关掉限制再试一下是不是同一个效果；另外如果你使用的 api 在某个版本被移除了，反射调用的话扔隐藏直接调用也会，而且直接调用扔的是 Error 更难处理，你 catch Exception 是抓不到的

我是有系统权限的，隐藏api随便调用。如果你使用的 api 在某个版本被移除了，提升sdk的时候使用这种方式在编译时就会发现，直接报错编译不过了，而使用反射调用报错会更加隐蔽。这个方案是我从6.0适配  ...查看更多

我是有系统权限的，隐藏api随便调用。如果你使用的 api 在某个版本被移除了，提升sdk的时候使用这种方式在编译时就会发现，直接报错编译不过了，而使用反射调用报错会更加隐蔽。这个方案是我从6.0适配到12总结出来最快的适配方式，只要保证第一次测试运行正常，之后的适配都是少量的。而我总结出来突破的办法就是有权限你就用，没权限你就别用，非要用只能去找谷歌反馈不要隐藏，因为系统在人家手里，思想需要保持一致。如果不从根本或者思想上去解决带来问题的原因，列举出来的解决办法不都是小聪明么，投机取巧，在这个系统上能用，更新就没法用了，这是很多骚操作应用适配超慢的原因。我们暂时还无法相互理解，但是在经历一段时间的适配之后，相信总会保持一致的

你在做系统开发，隐藏 api 限制当然是随便关，往后也就没有意义因为没有限制就已经离题了。至于链接编译，你只适配一个系统版本当然可以，但是如果新版本删了你要的 api 同时要求不升 sdk 不重新编译  ...查看更多

你在做系统开发，隐藏 api 限制当然是随便关，往后也就没有意义因为没有限制就已经离题了。至于链接编译，你只适配一个系统版本当然可以，但是如果新版本删了你要的 api 同时要求不升 sdk 不重新编译就能工作呢？更进一步，如果厂商乱改给你删了你怎么适配？这些才是做第三方 app 开发容易遇到的场景。

我是做系统【插件】的，指用户拿到手机 root 之后我们通过替换系统文件等方式把自己的代码注入进到一系列进程然后在这些别人的进程里面干活，和你那种不同之处就是没有别人系统的源码，更别提换一个 andr  ...查看更多

我是做系统【插件】的，指用户拿到手机 root 之后我们通过替换系统文件等方式把自己的代码注入进到一系列进程然后在这些别人的进程里面干活，和你那种不同之处就是没有别人系统的源码，更别提换一个 android.jar 。工作要求是，同一份代码，完全不可控的环境（用户可能购买任何牌子的手机），直接兼容运行正常。我印象比较深刻的一个就是，我们只对高版本系统开启某个兼容措施，后面有人反馈有个低版本的系统也需要，后面追查发现这个系统确实是低版本的，但是偷偷把高版本才有的一个 commit 给 cherry pick 了过来，你说这种事情单纯做系统的能遇到吗

完全偏题。题目问的就是普通 app 就是想用目前有没有什么方案。而你又是说自己有系统权限又是劝人不要用的。你说得对，系统更新可能就没法用了，但是题目问的就是非要用的时候啊。并且 SDK，system-  ...查看更多

完全偏题。题目问的就是普通 app 就是想用目前有没有什么方案。而你又是说自己有系统权限又是劝人不要用的。你说得对，系统更新可能就没法用了，但是题目问的就是非要用的时候啊。并且 SDK，system-API，test-API 都是很稳定的实现，只是普通 app 不能用而已，系统 app 还是可以用的并且有稳定性保证（但是这可不是你说的 apk 权限问题，appops 哪有这种权限的控制，这是 zygote fork 时候的一个参数决定的）。像`setHiddenApiExemptions` 是 system-api 这个级别，虽然是隐藏API，但已经不会改了。你都知道查 csv 了这点不会不知道吧？ 而且拿个 framework.jar 来调用的方法早烂大街了，谷歌在 Android 9 开始就是为了封杀这种方法搞的 hidden api restriction。 至于什么理解不理解，我和 @canyie 都是玩魔法的，甚至想在 java 里面调用 Os.mmap 来运行汇编代码，所以对不起，永远不可能理解。

最后一起回复一下子吧，我适配mtk和高通两个平台，从6.0适配到12,。android.jar是基于aosp生成的，总是提到厂商乱改，厂商是可以乱改，改的都是方法内部和增加api，随便删api厂商也没  ...查看更多

最后一起回复一下子吧，我适配mtk和高通两个平台，从6.0适配到12,。android.jar是基于aosp生成的，总是提到厂商乱改，厂商是可以乱改，改的都是方法内部和增加api，随便删api厂商也没这魄力，有的就自己开发系统了，不搞什么**UI。framework,jar是很早的方案不错，也正是因为它具有的稳定性，所以一直延续至今，framework,jar的方式说白就是变成Dalvik调用，就是普通调用的方式，官方原有的限制该在还是在，普通app调用黑名单级别api直接崩溃，放到system/app下或者shareUid为system的可以调用。好，你非要用，那可以去提官方豁免api。玩魔法，其实不就是小聪明么？把操作想得那么高级没必要，完全没必要。搞技术还是要脚踏实地，今天这骚明天那个骚，骚一个方案换一个公司，骚一个方案换一个项目。维护一个项目久一点，之后看看能不能理解。非要用非要用，连个权限都没有，怎么就非得用

但是偷偷把高版本才有的一个 commit 给 cherry pick 了过来，这和替换android.jar的原理那更像了，后来又提了个问题，https://www.wanandroid.com/we  ...查看更多

但是偷偷把高版本才有的一个 commit 给 cherry pick 了过来，这和替换android.jar的原理那更像了，后来又提了个问题，https://www.wanandroid.com/wenda/show/20867，使用隐藏接口的，把我回答的compileOnly形式依赖，改变成implementation功能实现了。

看题，不要讨论什么不应该。题目要求就是去绕过，你一直在说让谷歌开放，就像有题不答非要问为什么出这种题。至于没有权限，那是两回事，要用权限限制的都不在本进程，同一个进程随便调用（不然系统自己在应用进程跑  ...查看更多

看题，不要讨论什么不应该。题目要求就是去绕过，你一直在说让谷歌开放，就像有题不答非要问为什么出这种题。至于没有权限，那是两回事，要用权限限制的都不在本进程，同一个进程随便调用（不然系统自己在应用进程跑的代码怎么用），而且我的东西使用前提就是用户 root 手机，不 root 跑来用会被我拉黑。然后你说 implementation，那个 commit 是在 art 虚拟机里面的，难道我把 art 那一堆 c++ 还有汇编复制过来编译一份？

而且如果是 java api 的话，因为 classloader 会先向父 loader 请求加载类，实际访问到的还是系统那个，然后还是会触发 hidden api 限制机制。我们实际遇到的问题是，a  ...查看更多

而且如果是 java api 的话，因为 classloader 会先向父 loader 请求加载类，实际访问到的还是系统那个，然后还是会触发 hidden api 限制机制。我们实际遇到的问题是，art 虚拟机里调用一个来自未初始化类的静态方法应该首先触发类初始化，而 art 虚拟机采取的方案是把所有未初始化类的静态方法的入口点设置为一个跳板，触发类初始化，然后把这些静态方法的入口点设置成真正的（这个过程叫做 fixup）。而高版本里 art 给类加了一个状态，导致已经初始化过的类仍然可能再次触发这个 fixup 过程导致静态方法入口被重设。这个问题是与高版本的兼容性问题，是因为高版本做了修改为了兼容它所以不得已而为之，不是我们自己需要，更谈不上什么 implementation。

root没有hidden api限制

注入进其他进程，其他进程的限制。

神仙打架奥

我也没懂