一、目标
最近在模拟执行某个so的时候发现了一个奇怪的错误,在执行到call_object_method的时候失败,仔细看了一下,发现这个so首先获取了 Activity类的getPackageManager方法 的jmethodID,然后用一个 Application类 的对象去调用这个jmethodID。
简单的解释就是 A类的对象中调用B类的方法?
二、分析
猜测是这样的: Application和Activity类中都有getPackageManager方法,而且功能都是一样的,所以为了优雅,google工程师就把这两个jmethodID的地址设置成一样的,这样造成了Application类的对象可以调用Activity类的getPackageManager。
这个猜测是不对的,jmethodID相同的真实原因是 : Application 和 Activity 都是 ContextWrapper 的子类, getPackageManager 是 ContextWrapper 里的方法,获取的两个 jmethodid 自然是一样的。 感谢@葫芦娃

我们赶紧证明一下:

好了,现在我们只要拿到Application的对象,然后也去调用Activity类的getPackageManager,跑到这个call_object_method,
AndroidNativeEmu就罢工了。

三、总结
开动脑筋,神奇的抵抗方式总是有的……
硬广一下, 奋飞的朋友们 的知识星球里有 全网唯一一个AndroidNativeEmu实操教程。 ε=ε=┌( >_<)┘

关注微信公众号,最新技术干货实时推送
