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

news2024/11/26 20:30:44

一、目标

上篇文章里面，我们跑出来的结果有点不对头，多个一个 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 ，看看正确的结果是什么。

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