一、目标

一、目标

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

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

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

二、步骤

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

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

main
1:main

然后创建 /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,然后 补齐了 AppLogReporterandroid/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 ,看看正确的结果是什么。

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

三、总结

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

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

ffshow
1:ffshow

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

100

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

100