riru-core模块是专为安卓系统打造的手机root模块,原理是通过替换会被Zygote加载的libmemtrack.so从而实现Zygote注入,而安卓应用进程都是从Zygote fork的,注入了Zygote也就等同于注入了接下来会启动的游戏,也就可以轻松实现修改了。然后hook掉Zygote.nativeForkAndSpecialize函数监听app启动。
软件特色构建
在 Android Studio 或命令行执行 gradle task :riru-core:assembleMagiskRelease,zip 会被存到 release。
档案结构
riru模块是magisk模块(magisk模块文档)。
另外,当前唯一需要的文件(文件夹)是/data/adb/riru/modules/。riru将检查它是否存在并加载/system/lib(64)/libriru_.so。
关于预制
该模板将prefab功能用于本地依赖项。预制支持是从agp4.0添加的,但只能在更高版本上正常使用。如果您不能或不愿意使用apg4.1,则可以注释掉与预制件有关的零件build.gradle并riru.h从rikkaapps/riru中复制。
常见问题为什么要做出 Riru 呢?
因为 libmemtrack.so 只有一个,如果有人想用替换 libmemtrack 的套路来做点什么别人就做不了。所以就制造了 Riru 来占下 libmemtrack 但是提供了模块这样的东西。
如何注入合子过程?
在v22.0之前,我们使用替换将由zygote加载的系统库(libmemtrack)的方法。但是,这似乎会引起一些奇怪的问题。可能是因为libmemtrack被其他东西使用了。
然后,我们找到了一种超级简单的方法,即“本地桥梁”(ro.dalvik.vm.native.bridge)。特定的“so”文件将由系统自动“dlopen-ed”和“dlclose-ed”。这是从这里来的。
她怎么工作呢?
简而言之,替换一个会被 zygote 进程加载的共享库。
首先要找到那个共享库,而且那个共享库要越简单越好,所以就盯上了只有 10 个导出函数的 libmemtrack。 然后就可以自己提供一个叫 libmemtrack 并且也提供了原来的函数们的库,这样就可以进去 zygote 进程也不会发生爆炸。(然而现在看来选 libmemtrack 也不是很好)
接着如何知道自己已经在应用进程或者系统服务进程里面。 JNI 函数 (com.android.internal.os.Zygote#nativeForkAndSpecialize & com.android.internal.os.Zygote#nativeForkSystemServer) 会在应用进程或者系统服务进程被 fork 出来的时候被调用。 所以只要把这两个函数换成自己的。这部分很简单,只要 hook jniRegisterNativeMethods 因为所有 libandroid_runtime 里面的 JNI 方法都是通过这个注册,然后就可以再调用 RegisterNatives 来替换它们。
同类软件精选
用户最爱