SideStories和HideStories

FunJni
在分析Apk的时候难免去分析So层，大多数native层都需要IDA调试，特别是分析数量很多的Apk的时候。我之前就想着，能不能对各种Naitive层进行监听。Apk放进去就可以实现自动化分析，包括调用了哪些方法，每个Java类里面保存了哪些数据。做了什么事情。特别是分析设备指纹的时候，Apk会采集非常多的设备信息。但是这些设备信息，无从下手，不知道应该从哪里改起，加上很多Apk都有混淆，分析起来是一件很费劲的事情。我们完全可以把一些关键信息，进行快速序列化，保存起来，对里面的东西直接搜索我们需要的内容即可即可 。
现在市面上有很多Java层的自吐工具，比如Hook，Java层的常见加密信息，以实现自吐，现在很多大厂基本都不会走Java层基础加密，大多数都是自己实现的加密方式，Java层最多只能算是辅助作用。几年之前还很好用，现在看起来有点鸡肋 。那么有没有什么比较好的分析Native的工具呢？
现在市面上常见的hook基本就是Frida和Xposed占大头，Frida常见的分析工具，比如Frida 的Jnitrace，Unidbg之类的 就很好用，根据Unidbg 的实现逻辑，targetSdk版本号检测，或者检测某个字符串的Hash的返回值 。
检测Frida的方法就更多了，各种反调试都是可以检测出来，比如文件，端口号，特征都是常见的anti点。
但是针对Xposed的检测却很难，需要先拿到Classloader，和一些特征才能判断是否被注入。特别是Lsposed，在Hunter里面也只能通过检测Libart的CRC，内存文件和本地文件的指令累加，判断是否相等，以检测Libart是否被修改，但是这种方式一般大厂也不敢轻易去上，很容易SIGN11。Lsposed因为是系统层注入，加上命名空间，还有本身Lsp的Classloader被隐藏了，在应用层很难去拿到比较好的特征点。这篇文章主要是介绍一下之前几年搞的各种小工具，做了个合计 。也方便各位以后能快速对各种Apk进行分析 。这篇文章读下来也会有不少收获 。
另外代码会开源，还希望各位老板多多start ！
主要功能&使用方式：
第一版本我只做了6个功能 。
Java内存序列化
JNIEnv监听，支持全量监听，防止动态下发SO绕过
libc String处理函数监听
JNIEnvRegisterNative监听
Linker加载CallBack监听
Java方法调用全量监听
第一版本算是搭了个架子，后面有时间的话会慢慢完善 。当然也欢迎各位大佬进行push和pull ，有好的建议可以在issues提想法 。
使用的话也很简单，Xposed模块，先选择需要Hook的Apk ，内存序列化和Native层Hook只能选一个 。如果没开启内存序列化的话，会弹窗。
推荐根据自己的需求去Hook指定的So 。比如libaaa.so ，只需要输入libaaa或者libaaa.so  即可，如果需要Hook监听多个So的话可以用|分割  。
如 libaaa.so|libbbb.so 即可 。下面会分别介绍一下具体的实现过程，不然只看代码学习效率很低。下面主要是一些实现的细节 。
Xposed如何HookNaive层并且兼容5-13
这个很简单，直接把So注入即可，不同版本调用的api不同 。具体代码如下 。
public static void LoadSoForPath(String path, Object object) {
    try {
        CLog.e(load so path ->   + path);
        if (Build.VERSION.SDK_INT >= 28) {
            String nativeLoad = (String) XposedHelpers.callMethod(Runtime.getRuntime(), nativeLoad, path, object);
            CLog.e(nativeLoad == null ?  : nativeLoad);
        } else {
            String doLoad = (String) XposedHelpers.callMethod(Runtime.getRuntime(), doLoad, path, object);
            CLog.e(doLoad == null ?  : doLoad);
        CLog.i(load so for path success +path);
    } catch (Throwable e) {
        CLog.e(load so for path  + e.getMessage());
第一个参数是SO路径，这块有一个细节，卡住了不少人，就是这个方法的参数2，他是一个Classloader，这Classloader 表示当前注入So的Classloader ，在Native层不同的Classloader的作用域是不一样的，跟Dex一样，每个SO也是有属于自己的Classloader，因为Xposed的Classloader和当前进程Context的Classloader是不一样的。
如果你用当前进程的Context的Classloader进行注入，他会找不到Xposed加载的类，因为Classloader不一样 ，会一直提示class not find ，导致无法在Naitive层注册一个Native方法 。解决办法也很简单，直接用XposedHook类的.class.getClassLoader()即可 。
还有就是如何自动化区分被HookApk是64位还是32位。这块代码里面都会很详细的介绍和实现逻辑 ，具体参考代码。
Java内存序列化：
什么是Java内存序列化，就是讲Java层整个虚拟机的全部Java实例转换成JSON字符串，保存到本地 。这个也是我经常用的功能之一 。
他有什么作用？比如一个很简单的CASE场景，我想知道一个大厂Apk设备指纹都保存在哪些Java类里面 ？都保存了什么东西 ？
直接让软件运行30秒以后( 这个时间可以根据自己的业务场景去控制)，扫描一下内存即可  。遍历的时间和Apk的大小有关系，Apk越大保存的对象越多，耗时越长 。
获取内存实例，实现原理也很简单，之前文章介绍过如何获取 https://bbs.kanxue.com/thread-269094.htm
这个Api是一个隐藏api  ，目前只做了 android 9- 11支持 。9-11是系统自带Api , 其他版本需要自己实现，我尝试在 5 - 9实现发现稳定性存在问题，所以在XposedJni里面做了判断，所以这个功能只有9-11支持 。
代码如下：
private void startSerialization(Context context) {
    try {
        //手动触发gc,清空多余实例
        System.gc();
        final File file = new File(/data/data/
                + mTagPackageName + / + mProcessName + _MemorySerializationInfo.txt);
        if (file.exists()) {
            file.delete();
        file.createNewFile();
        //子线程和主线程共享数据
        ThreadUtils.runOnNonUIThread(() -> {
            ArrayList