Giter VIP home page Giter VIP logo

Comments (6)

canyie avatar canyie commented on July 28, 2024

已较长时间未复现出该问题,基本确认该问题已被修复。

from pine.

 avatar commented on July 28, 2024

已较长时间未复现出该问题,基本确认该问题已被修复。

Crash again on Android device cuz "Invalid monitor state ForwardingAddress" error.
This fatal error may held with loadClass function which dex never run dex2oat function.
This crashes went away but new came, may link with @fastNative annotated java method hooked.
tombstone
native: #5 pc 000fa8d7 /apex/com.android.runtime/lib/libart.so (art::ClassLinker::LoadClass(art::Thread*, art::DexFile const&, art::dex::ClassDef const&, art::Handleart::mirror::Class)+930)

from pine.

canyie avatar canyie commented on July 28, 2024

@lianglixin Can you provide more detailed call stack information?

from pine.

 avatar commented on July 28, 2024

@lianglixin Can you provide more detailed call stack information?

已定位并解决,这个是HOOK框架的一个小BUG,如果HOOK了某些Runtime的方法,并频繁调用这些方法,会造成无法预料的后果。(非常隐秘,没法频繁复现)
栈追溯是没用的,因为这种问题非常隐秘,非必定出现。部分调用不频繁的方法可能一直没问题,部分调用比较多的方法可能几分钟就出问题。
具体栈追溯只有一行:Didn't find oat method index for virtual method,这一行是在art runtime art_method.cc里面,咋一看是Method Index被改变导致oat文件与dex文件里面的Method不符合,实际上不然。禁用OAT编译无效(特别是在安卓10环境上)。而剩余堆栈信息则是各线程运行到check point直接崩溃,没有有价值的堆栈信息,也让人头疼。
不过,我一旦解除Runtime的hook,这个问题就不会再复现,仔细查看Runtime的对应方法实现源码,发现只要调用了ArtMethod的invoke方法,则会非常容易出现这个问题。
治标不治本的解决方法是把要hook的方法强行标记为Static,并且调用链包含这个方法的所有方法也必须标记为Static(例如某类的equals,会调用Object的hashCode方法,那么需要把这些方法全部标记为static,包括Object的hashCode)。彻底的解决方法是在任何multidex的应用里面禁用jit-compile,对于Runtime的所有已编译为oat的方法使用Inline hook(不要修改ArtMethod的内容,不要尝试禁用dex2oat或者删除dex2oat)。对于部分未compile的方法,入口点有问题,hook稳定跑崩,目前无任何解决办法(改系统源码太复杂)。
开始踩坑以为是kAccCompileDontBother的问题,后面发现根本不是,解析oat文件并inline hook以后即可解决问题。无root环境暂无简单的解决方法(安卓10以后限制了oat文件的增删查改),如果有,可以和我交流

from pine.

 avatar commented on July 28, 2024

@lianglixin Can you provide more detailed call stack information?

此外,非Runtime方法可以直接hook runtime_options.GetOrDefault函数,image_dex2oat_enabled_ = runtime_options.GetOrDefault(Opt::ImageDex2Oat);将此设置为false。
而Runtime方法不要直接禁用库加载,在64位库上必定会遇到随机崩溃的问题,没找到解决方法,只能使用inline hook oat来解决。在判断是hook runtime的方法时,主动允许生成oat文件,否则在64位环境会遇到很奇怪的随机崩溃问题。
目前的临时且彻底的免ROOT解决方法是替换libart.so,hook系统运行环境,将libart.so的所有关联库使用shellcode从内存卸载并重新关联自己的libart.so,缺点是需要自己实现Zygote和ioctl,跟VMOS差不多(相比VMOS更节省内存,且是完全的原生通信)。

from pine.

canyie avatar canyie commented on July 28, 2024

@lianglixin 啊这…… 能提供下hook了哪些方法吗?

from pine.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.