2019.7.16 重置最终版
前后断断续续2个月摸鱼时间，终于有点拿得出手的产品了。

笔者最近玩一个山寨手游 使用了Fake Location作为模拟定位软件，对其中反检测功能的实现原理颇为感兴趣
反检测在java层和native层都做了常见API的hook，该软件也没有使用xposed的迹象，想必是注入dex和so的了。
但是该游戏有ptrace保护。年少的笔者非常想知道他是怎么绕过ptrace保护注入进程实现hook功能的。
这项技术叫做zygote注入。其优势在于不借助常规hook框架（Xposed），就可以实现java层的hook并load so。
并且会对逆向分析造成更多的麻烦，因为没有使用标准Xposed API。

第一步 先康康他用root权限干了些什么  
inject -P zygote -l initzygote.so
向zygote进程中注入initzygote.so文件，解决了目标进程被ptrace保护的问题。

linux的zygote和fork机制：
zygote 孵化器是 Android 应用进程的模板，通过其 fork 出来。
在fork()时，子进程和父进程暂时共享父进程的内存空间，通过COW机制管理。
而我们在fork前注入zygote的so和dex，会存在于之后的每一个新进程中实现hook功能。

1. Fake软件使用了非xposed的hook库
2. 通过zygote注入loader So 反射加载dex，在插件dex里加载Hook用so和java hook代码
3. 这样做的好处是可以绕过常见xposed检测，又可以对APP进行自定义加固（xposed真的不行）
4. 根据关键词发现，fake使用的hook框架为YAHFA+ELFHOOKER，笔者将继续学习模仿，整合一个自己的APP框架。

这个是7.0以上so文件安全性 关于namespace的问题
使用了Nougat_dlfunctions 的fake_dlfcn也没有用
只能从initzygote.so里抠代码出来 居然可以 奇怪
分析代码 关键点 ```c    while ( !handle && i <= 1 )
{
    dlerror();
    handle = dlopen(0, 1);
    error = dlerror();
    if ( error )
        LOGD( "BCINJECT.native failed to load %s: %s", paths[i], error);
    if ( handle )
        LOGD( "BCINJECT.native Android runtime loaded from %s", paths[i]);
    else
        ++i;
} ```
乍一看非常奇怪 怎么第一个参数可以是NULL呢 随便google一下没有找到答案
于是开始dlopen分析源码 [参考dlopen分析文章](https://blog.csdn.net/SweeNeil/article/details/83744843)   [参考函数文档](https://www.xuebuyuan.com/1912632.html)

第一个参数fileName为空时，handle指向当前进程镜像的全局符号表。
handle类似迭代器指针，每调用一次指向下一个模块。
在Android中，符号表首部的应该就是jvm相关 libart或libdvm。
所以我们可以获取到JavaVM 从而获取到JNIEnv*

插件加载的目录归属用户 需要与目标进程的用户相同
如果是zygote注入 归属root用户 system_server 归属system用户 以此类推

可惜YAHFA对于XPosed的没有什么兼容（有其他魔改框架 BudHook等）
示例如下 ```java public class HookMain {
public static void hookAll(final Object context) {
    Log.e(TAG, "enter hookAll");
    init();
    doHookItemDefault(HookMain.class.getClassLoader(), Hook_ActivityThread_handleBindApplication.class.getName(), null);
} }

public static void hook(Object thiz, Object data) {
    Log.e(TAG, "in handleBindApplication " + String.valueOf(data));
    try {

        Class AppBindData = Class.forName("android.app.ActivityThread$AppBindData", false,
                thiz.getClass().getClassLoader());
        ApplicationInfo applicationInfo = (ApplicationInfo) ReflectUtil.getField(data, AppBindData, "appInfo");
        String packageName = applicationInfo.packageName.equals("android") ? "system" : applicationInfo.packageName;
        String processName = (String) ReflectUtil.getField(data, AppBindData, "processName");
        Log.e(TAG,packageName +" ,"+processName);

        backup(thiz, data);
    } catch (Exception e) {
        Log.e(TAG, Log.getStackTraceString(e));
    }
    return;
}

public static void backup(Object thiz, Object data) {
    Log.w(TAG, "handleBindApplication should not be here");
    return;
} } } ``` 这样就可以成功注入每一个进程，hook到handleBindApplication，拿到第一个Classloader，其他问题随之迎刃而解，YAHFA方便的hook配置甚至可以插件化，暂且不表。

至此我们已经成功模仿了fake location实现的java层和native层hook
可以做出一个不依赖Xposed框架的hook工具，可以绕开常见检测（也可以修改epic特征 美团就会检测epic）
如果要整合进自己的产品 需要更多安全保护
之后的计划
1.ollvm环境搭建
2.空白混淆加强修改（方法名加长）
3.检测自身是否被hook 反调试