一、目标
上篇文章里面,我们跑出来的结果有点不对头,多个一个 ABC。
这次我们试试用 LoadSo的方式来排查下问题。
二、步骤
我们先用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 ,看看正确的结果是什么。
这样一步一步向真实靠拢。
三、总结
假到真时真亦假,安全对抗的时候就是比拼耐心,互相给对方挖坑埋雷。挖的坑要深点,雷要迷惑性强点。偶尔可以给对方一个甜头,让他以为搞定收工。实际后面还有千转百绕。
最后谁坚持不住放弃了,谁就输了。
那些花半秒钟就看透事物本质的人,和花一辈子都看不清事物本质的人,注定是截然不同的命运。
关注微信公众号,最新技术干货实时推送
文章作者 奋飞
上次更新 2021-05-20
许可协议 奋飞安全原创,转载请注明出处。