-
-
[原创]小菜花的Riru原理浅析和源码阅读
-
2021-11-8 14:49
-
一，引言
因为最近在研究在svc bypass，frida脚本就随便写了
落地到生产环境，首先用的是xposed + inlinehook，就是用xposed hook runtime的loadLibrary，当发现目标so load的时候，就开始主动load我们的inlinehook so，inlinehook so中的逻辑就是，对目标so进行svc指令内存扫描，然后对扫描到的svc地址进行hook操作
那么问题来了，这个inlinehook so的load时机如何选：
1，after loadLibrary(目标so)，这个时机的话，目标so在dlopen中都执行完init和init_arrary了，如果检测放在init中刚好人家检测完，你才注入inlinehook so，那时机就太晚了。
2，before loadLibrary(目标so)，这个时机的话，你inlinehook so工作原理就是需要在内存中扫描目标so然后再hook，此时目标so还没加载，根本拿不到地址没发扫描啊，所以这个时机也不行。（ps：或许主动去getSymFromLinker(find_libraries)，然后主动调用find_libraries去加载链接目标so？这个思路是写文章的时候想到的，未进行尝试，因为就想玩riru，手动狗头（ps：find_libraries是笔者阅读源码android8.1选取的装载了so却没执行init函数的一个时机））
综上所述，两个时机都不太行
那么来看 https://bbs.pediy.com/thread-268256.htm ，该文章选取的注入frida-gadget的时机点是com_android_internal_os_Zygote_nativeForkAndSpecialize，该函数是fork应用程序进程的，这个时机就比较好，fork好应用程序进程，咱们就开始hook linker的find_libraries，等目标so加载链接好之后，就开始扫描内存，对svc address进行hook操作
一切就是这么的顺其自然，嗯，大致就这个思路吧。
要对nativeForkAndSpecialize进行动手，首先应该想到的是magisk的riru模块了，riru模块提供了下面三个函数的注入时机
- nativeForkAndSpecialize
- nativeSpecializeAppProcess
- nativeForkSystemServer
提供了pre和post函数，就可以随便玩了。那么开始动手搞riru模块开发，本着多多学习的原则，来看下riru源码和原理，
看源码是为了更好的cv，看原理是为了知其所以然，然后达到一个理所当然的状态。
二，Magisk
看riru之前，肯定要看下Magisk了，因为riru属于magisk模块，需要大致知道magisk是咋回事。
先来看下magisk官方文档：https://topjohnwu.github.io/Magisk/guides.html
关键点看下来就是：
1，magisk会在两个时机执行post-fs-data.sh和service.sh
2, system.prop会被magisk加载作为系统属性
3，没特殊设置的话，magisk会挂载模块内的system文件夹，这里是存放replace/inject files的
三，Riru
Riru原理
老规矩，先来git看下readme: https://github.com/RikkaApps/Riru
其实这里就已经把riru原理介绍完了，大致总结下就是：
1，注入原理：动了ro.dalvik.vm.native.bridge，可以被系统自动dlopen特定so文件
2，hook原理：hook了android_runtime的jniRegisterNativeMethods对关键jni函数做了替换（ps：系统启动的时候先启动init进程，init进程再启动zygote进程，而zygote进程会创建java虚拟机，并为其注册jni方法）
注入原理
那么来详细看下注入原理的由来：https://blog.canyie.top/2020/08/18/nbinjection/，大致总结下就是：
1，作者分析源码的时候发现，在startVM函数流程中Runtime::Init会加载native bridge
2，LoadNativeBridge会dlopen了一个特定的so
3，这个特定的so的由来是系统属性ro.dalvik.vm.native.bridge的值
4，有特殊情况native bridge的so会被系统卸载掉，所以直接当个loader去load其他的so比较好
riru zip包分析
从git上下载riru release包解压下来看看
这几个脚本文件相对生疏一点，回过头来看下magisk文档
再打开这些脚本文件看下大致内容：
util_functions.sh 是搞了一些funtion ui_print
verify.sh 是校验文件完整性的
update-binary和customize.sh都是做一些安装过程准备的，涉及一些检查环境，解压，删除文件啥的
稍微关键点的是，搞了个文件夹，移动了一下文件，记住这个$(magisk --path)/.magisk/modules/riru-core目录，来设备中看下大致长啥样
这下清晰多了，文件结构就和上文Magisk Modules介绍的一摸一样，那么根据上文介绍的magisk情况，可以明确的是：
1，system.prop会被magisk加载作为系统属性，当前system.prop的内容为
ro.dalvik.vm.native.bridge=libriruloader.so，嘿，这不注入原理和上面说的对应上了。
2，magisk会在两个时机执行post-fs-data.sh和service.sh，打开看下这两个文件有没有啥关键信息
稍微关键点的好像就这句了：
flock "module.prop" unshare -m sh -c "/system/bin/app_process -Djava.class.path=rirud.apk /system/bin --nice-name=rirud riru.Daemon $(magisk -V) $(magisk --path) $(getprop ro.dalvik.vm.native.bridge)&"
那就来源码rirud riru.Daemon看下干了嘛
private void onRiruLoad() {
allowRestart = true;
Log.i(TAG, "Riru loaded, reset native bridge to " + DaemonUtils.getOriginalNativeBridge() + "...");
DaemonUtils.resetNativeBridgeProp(DaemonUtils.getOriginalNativeBridge());
Log.i(TAG, "Riru loaded, stop rirud socket...");
serverThread.stopServer();
var loadedModules = DaemonUtils.getLoadedModules().toArray();
StringBuilder sb = new StringBuilder();
if (loadedModules.length == 0) {
sb.append(DaemonUtils.res.getString(R.string.empty));
} else {
sb.append(loadedModules[0]);
for (int i = 1; i < loadedModules.length; ++i) {
sb.append(", ");
sb.append(loadedModules[i]);
}
}
if (DaemonUtils.hasIncorrectFileContext()) {
DaemonUtils.writeStatus(R.string.bad_file_context_loaded, loadedModules.length, sb);
} else {
DaemonUtils.writeStatus(R.string.loaded, loadedModules.length, sb);
}
}大致看了下，好像就是搞了个socket 暴露了一些api用来进程通信了然后还有一些环境操作，比如riru load之后把native bridge设置会原来的，那就大致先这样吧。
riru loader源码分析
回过头来看system.prop的native bridge的libriruloader.so，根据riru/src/main/cpp/CMakeLists.txt可知，其入口为riru/src/main/cpp/loader/loader.cpp，关键代码如下
__used __attribute__((constructor)) void Constructor() {
if (getuid() != 0) {
return;
}
std::string_view cmdline = getprogname();
if (cmdline != "zygote" &&
cmdline != "zygote32" &&
cmdline != "zygote64" &&
cmdline != "usap32" &&
cmdline != "usap64") {
LOGW("not zygote (cmdline=%s)", cmdline.data());
return;
}
LOGI("Riru %s (%d) in %s", riru::versionName, riru::versionCode, cmdline.data());
LOGI("Android %s (api %d, preview_api %d)", android_prop::GetRelease(),
android_prop::GetApiLevel(),
android_prop::GetPreviewApiLevel());
constexpr auto retries = 5U;
RirudSocket rirud{retries};
if (!rirud.valid()) {
LOGE("rirud connect fails");
return;
}
std::string magisk_path = rirud.ReadMagiskTmpfsPath();
if (magisk_path.empty()) {
LOGE("failed to obtain magisk path");
return;
}
BuffString<PATH_MAX> riru_path;
riru_path += magisk_path;
riru_path += "/.magisk/modules/riru-core/lib";
#ifdef __LP64__ riru_path += "64";#endif riru_path += "/libriru.so";
auto *handle = DlopenExt(riru_path, 0);
if (handle) {
auto init = reinterpret_cast<void (*)(void *, const char *, const RirudSocket &)>(dlsym(
handle, "init"));
if (init) {
init(handle, magisk_path.data(), rirud);
} else {
LOGE("dlsym init %s", dlerror());
}
} else {
LOGE("dlopen riru.so %s", dlerror());
}
#ifdef HAS_NATIVE_BRIDGE auto native_bridge = rirud.ReadNativeBridge();
if (native_bridge.empty()) {
LOGW("Failed to read original native bridge from socket");
return;
}
LOGI("original native bridge: %s", native_bridge.data());
if (native_bridge == "0") {
return;
}
original_bridge = dlopen(native_bridge.data(), RTLD_NOW);
if (original_bridge == nullptr) {
LOGE("dlopen failed: %s", dlerror());
return;
}
auto *original_native_bridge_itf = dlsym(original_bridge, "NativeBridgeItf");
if (original_native_bridge_itf == nullptr) {
LOGE("dlsym failed: %s", dlerror());
return;
}
int sdk = 0;
std::array<char, PROP_VALUE_MAX + 1> value;
if (__system_property_get("ro.build.version.sdk", value.data()) > 0) {
sdk = atoi(value.data());
}
auto callbacks_size = 0;
if (sdk >= __ANDROID_API_R__) {
callbacks_size = sizeof(NativeBridgeCallbacks<__ANDROID_API_R__>);
} else if (sdk == __ANDROID_API_Q__) {
callbacks_size = sizeof(NativeBridgeCallbacks<__ANDROID_API_Q__>);
} else if (sdk == __ANDROID_API_P__) {
callbacks_size = sizeof(NativeBridgeCallbacks<__ANDROID_API_P__>);
} else if (sdk == __ANDROID_API_O_MR1__) {
callbacks_size = sizeof(NativeBridgeCallbacks<__ANDROID_API_O_MR1__>);
} else if (sdk == __ANDROID_API_O__) {
callbacks_size = sizeof(NativeBridgeCallbacks<__ANDROID_API_O__>);
} else if (sdk == __ANDROID_API_N_MR1__) {
callbacks_size = sizeof(NativeBridgeCallbacks<__ANDROID_API_N_MR1__>);
} else if (sdk == __ANDROID_API_N__) {
callbacks_size = sizeof(NativeBridgeCallbacks<__ANDROID_API_N__>);
} else if (sdk == __ANDROID_API_M__) {
callbacks_size = sizeof(NativeBridgeCallbacks<__ANDROID_API_M__>);
}
memcpy(NativeBridgeItf, original_native_bridge_itf, callbacks_size);
#endif}大致总结下就是：
1，从magisk_path/.magisk/modules/riru-core/lib下dlopen libriru.so，如果有init sym的话执行之
2，如果原来有native bridge的话就和rirud进程通信获取一下，然后仿照源码逻辑操作一波
riru.so 源码分析
接下来看libriru.so, 根据riru/src/main/cpp/CMakeLists.txt可知，其入口为riru/src/main/cpp/entry.cpp，关键代码如下
extern "C" [[gnu::visibility("default")]] [[maybe_unused]] void// NOLINTNEXTLINEinit(void *handle, const char* magisk_path, const RirudSocket& rirud) {
self_handle = handle;
magisk::SetPath(magisk_path);
hide::PrepareMapsHideLibrary();
jni::InstallHooks();
modules::Load(rirud);
}正好和上面libriruloader.so中的操作对应，执行libriru.so的init函数
hide::PrepareMapsHideLibrary
先来看hide::PrepareMapsHideLibrary(), 就是从libriruhide.so获取了下riru_hide_func，先记住这个riru_hide_func，下面会用到
void PrepareMapsHideLibrary() {
auto hide_lib_path = magisk::GetPathForSelfLib("libriruhide.so");
// load riruhide.so and run the hide LOGD("dlopen libriruhide");
riru_hide_handle = DlopenExt(hide_lib_path.c_str(), 0);
if (!riru_hide_handle) {
LOGE("dlopen %s failed: %s", hide_lib_path.c_str(), dlerror());
return;
}
riru_hide_func = reinterpret_cast<riru_hide_t *>(dlsym(riru_hide_handle, "riru_hide"));
if (!riru_hide_func) {
LOGE("dlsym failed: %s", dlerror());
dlclose(riru_hide_handle);
return;
}
}jni::InstallHooks()
接着看jni::InstallHooks()
void jni::InstallHooks() {
XHOOK_REGISTER(".*\\libandroid_runtime.so$", jniRegisterNativeMethods)
if (xhook_refresh(0) == 0) {
xhook_clear();
LOGI("hook installed");
} else {
LOGE("failed to refresh hook");
}
// 省略多行代码
}来看XHOOK_REGISTER这个宏定义
#define XHOOK_REGISTER(PATH_REGEX, NAME) \
if (xhook_register(PATH_REGEX, #NAME, (void*) new_##NAME, (void **) &old_##NAME) != 0) \
LOGE("failed to register hook " #NAME "."); \再来看个宏和函数
#define NEW_FUNC_DEF(ret, func, ...) \
using func##_t = ret(__VA_ARGS__); \
static func##_t *old_##func; \
static ret new_##func(__VA_ARGS__)
NEW_FUNC_DEF(int, jniRegisterNativeMethods, JNIEnv *env, const char *className,
const JNINativeMethod *methods, int numMethods) {
LOGD("jniRegisterNativeMethods %s", className);
auto newMethods = handleRegisterNative(className, methods, numMethods);
int res = old_jniRegisterNativeMethods(env, className, newMethods ? newMethods.get() : methods,
numMethods);
/*if (!newMethods) { NativeMethod::jniRegisterNativeMethodsPost(env, className, methods, numMethods); }*/ return res;
}这样一来，new_jniRegisterNativeMethods和old_jniRegisterNativeMethods就有了（ps：和va核心io那里的写法很像吧，大佬们优雅的写法如出一辙）
该来看关键点handleRegisterNative了
适配下版本，比较下method的name和signature，替换下函数指针，hook原理就来了，点开看下nativeForkAndSpecialize_r代码如下：
jint nativeForkAndSpecialize_r(
JNIEnv *env, jclass clazz, jint uid, jint gid, jintArray gids, jint runtime_flags,
jobjectArray rlimits, jint mount_external, jstring se_info, jstring se_name,
jintArray fdsToClose, jintArray fdsToIgnore, jboolean is_child_zygote,
jstring instructionSet, jstring appDataDir, jboolean isTopApp, jobjectArray pkgDataInfoList,
jobjectArray whitelistedDataInfoList, jboolean bindMountAppDataDirs,
jboolean bindMountAppStorageDirs) {
nativeForkAndSpecialize_pre(env, clazz, uid, gid, gids, runtime_flags, rlimits, mount_external,
se_info, se_name, fdsToClose, fdsToIgnore, is_child_zygote,
instructionSet, appDataDir, isTopApp, pkgDataInfoList,
whitelistedDataInfoList,
bindMountAppDataDirs, bindMountAppStorageDirs);
jint res = ((nativeForkAndSpecialize_r_t *) jni::zygote::nativeForkAndSpecialize->fnPtr)(
env, clazz, uid, gid, gids, runtime_flags, rlimits, mount_external, se_info, se_name,
fdsToClose, fdsToIgnore, is_child_zygote, instructionSet, appDataDir, isTopApp,
pkgDataInfoList,
whitelistedDataInfoList, bindMountAppDataDirs, bindMountAppStorageDirs);
nativeForkAndSpecialize_post(env, clazz, uid, is_child_zygote, res);
return res;
}这就是pre和post函数的由来了。
替换了目标函数的函数指针后，返回新的JNINativeMethod[]，再由真正的old_jniRegisterNativeMethods去注册jni函数，这样就完成了hook注入，riru完成暴露了自己的api
modules::Load(rirud)
接下来就开始加载基于riru开发的模块（modules::Load(rirud)）了
LoadModule(id, path, magisk_module_path)
先看LoadModule(id, path, magisk_module_path);如下所示dlopen和init来了
hide::HideFromMaps()
再看hide::HideFromMaps();往下跟一下关键点就到了riruhide.so的riru_hide和do_hide
void HidePathsFromMaps(const std::set<std::string_view> &names) {
if (!riru_hide_func) return;
LOGD("do hide");
riru_hide_func(names);
// cleanup riruhide.so LOGD("dlclose");
if (dlclose(riru_hide_handle) != 0) {
LOGE("dlclose failed: %s", dlerror());
return;
}
}module.onModuleLoaded()
再看module.onModuleLoaded()就是riru模块提供的另一个api了，在riru提供的开发模块中可以看到注释介绍
static void onModuleLoaded() {
// Called when this library is loaded and "hidden" by Riru (see Riru's hide.cpp)
// If you want to use threads, start them here rather than the constructors
// __attribute__((constructor)) or constructors of static variables,
// or the "hide" will cause SIGSEGV
}至此，riru模块加载原理的来龙去脉就根据源码看完了。。。
四，参考文献
Riru原理浅析和EdXposed入口分析：https://bbs.pediy.com/thread-263018.htm
and
上面提到的所有链接
[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
