Unidbg模拟执行某段子so实操教程(二) LoadSo对比

一、目标

上篇文章里面，我们跑出来的结果有点不对头，多个一个 ABC。

这次我们试试用 LoadSo的方式来排查下问题。

参考：借鸡生蛋之SandHook的使用(一)

二、步骤

我们先用Android Studio 4.0 来编译一个so

打开AS，然后用向导创建一个 Native C++ 工程。

然后创建 /xxx/app/src/main/jniLibs/armeabi-v7a 目录，把我们要分析的 libnet_crypto.so 复制进去

调用下试试

仿照 Jadx分析的结果，把 com.ixxixx.network.NetCrypto 类创建好

package com.ixxixxx.network;

public class NetCrypto {
    // static {
    public static void loadso(){
        try {
            System.loadLibrary("net_crypto");
        }catch(Throwable ex){
            ex.printStackTrace();
        }
        native_init();
    }


    public static native byte[] decodeAES(byte[] bArr, boolean z);

    public static native byte[] encodeAES(byte[] bArr);

    public static native String generateSign(byte[] bArr);

    public static native String getProtocolKey();

    public static native void native_init();

    public static native boolean registerDID(byte[] bArr);

    public static native void setProtocolKey(String str);

    public static native String sign(String str, byte[] bArr);
}

编译一下，没问题，编译通过。

跑一下

java.lang.ClassNotFoundException: Didn't find class "com.ixxixx.common.base.BaseApplication" on path: DexPathList

找不到 BaseApplication 这个类，我们也把他补齐

public class BaseApplication extends Application {

    private static Context context;

    public void onCreate() {
        super.onCreate();
        BaseApplication.context = getApplicationContext();
    }

    public static Context getAppContext() {
        return BaseApplication.context;
    }
}

再运行一下，直接跑起来了，结果正常 v2-1ff7402d2b4fa9a4c39b3853262f18fd

这下尴尬了

我们之前用unidbg跑的出来的结果不正常，多一个 ABC，现在直接LoadSo跑出来的结果是对的？为什么？

我们回忆一下，用Unidbg跑的时候，首先补齐了 BaseApplication，然后补齐了 AppLogReporter 和 android/os/Debug→isDebuggerConnected()

说明 Unidbg跑的时候被 so识别出来了不是真实环境， isDebuggerConnected 是判断程序有没有被调试器连接，这个好验证呀，我们在调试模式下跑一下 LoadSo就行了。

java.lang.ClassNotFoundException: Didn't find class "cn.xiaochuankeji.tieba.common.debug.AppLogReporter" on path

果然不出所料，在调试模式下，不仅结果输出 v2-ABC1ff7402d2b4fa9a4c39b3853262f18fd , 而且还提示 AppLogReporter 类不存在。

真相只有一个 so在执行过程中，判断是否是真实环境，比如是否被调试，是否是真机，如果发现环境不对，就在结果中加入ABC。

那好吧，可以收工了，还是按照昨天计划的玩法，Unidbg跑出结果之后，把 ABC 过滤掉。

继续分析

这次的so比较良心，也就加了个 ABC，而且长度和真实签名不一样，我们一眼都能看出来。

这要是让李老板来设计，发现环境不对之后，返回同样长度的签名串，到服务器也可以验证，这个是灰度用户，然后给他返回假数据。那就比较棘手了。

所以正好继续拿这个so练练手，再分析分析，以后遇到类似的情况，也知道如何排雷了。

先把 AppLogReporter 类补齐，然后再用 SandHook 来hook这个 isDebuggerConnected。

补齐 AppLogReporter

import android.util.Log;

public class AppLogReporter {
    public static void reportAppRuntime(String str, String str2) {
        String strOut = str + " ---- " + str2;
        Log.i("ZYDBG", strOut);

    }
}

Hook isDebuggerConnected ,直接返回 False

@HookClass(Debug.class)
public class OsDebug {
    @HookMethodBackup("isDebuggerConnected")
    static Method onIsDebuggerConnectedBackup;

    @HookMethod("isDebuggerConnected")
    public static boolean onIsDebuggerConnected() throws Throwable {
        boolean rc = (boolean)SandHook.callOriginByBackup(onIsDebuggerConnectedBackup,null);
        Log.e("ZYDBG OsDebug", "hooked isDebuggerConnected success rc= " + rc );
        return Boolean.FALSE;
    }

}

继续调试状态下运行，结果还是带 ABC 的

这是为什么呢？我们看看 Logcat

I/ZYDBG: runtiem ---- traced

原来又被发现 traced ,这时我们回想一下，Unidbg跑的时候 reportAppRuntime 函数的输出是 "invalid application name: izxxyxx"

这个so还真是不错，反Unidbg的样本。搞错了还会用 reportAppRuntime 来提示我们错在哪？

敲黑板，留作业

那么正好给大家留个作业，把这个so的反Unidbg和反调试部分，分析清楚，最后用Unidbg跑出正确的结果。

方法就是 LoadSo和Unidbg两个工程互相对照。比如 Unidbg里面跑的时候调用了 getSimpleName 来获取名称，我们模拟的时候就随便写了个 izxxyxx,被发现了。那么就在 LoadSo 这个工程里面来 hook getSimpleName ，看看正确的结果是什么。

这样一步一步向真实靠拢。

三、总结

假到真时真亦假，安全对抗的时候就是比拼耐心，互相给对方挖坑埋雷。挖的坑要深点，雷要迷惑性强点。偶尔可以给对方一个甜头，让他以为搞定收工。实际后面还有千转百绕。

最后谁坚持不住放弃了，谁就输了。

那些花半秒钟就看透事物本质的人，和花一辈子都看不清事物本质的人，注定是截然不同的命运。

关注微信公众号，最新技术干货实时推送