t猫xsign unidbg逆向
加密流程来源于看雪一位大佬的分享
findcrypt & findhash
既然已经知道用到了HMAC-SHA1
算法了,那就先用findcrypt
和findhash
找找
findcrypt
可以看到base64的常量
查看引用
sub_99BE0
应该就是进行base64编码的地方了
findhash
不知道出了什么问题,没有找到hash常量。于是看了下findhash
的代码
发现是在.text
或text
这两个segment里进行搜索,但是so里没有这两个segment。
尝试用frida_dump
来dump内存中的so,再看看它的segment
多了几个segment,其中有个是.text&ARM.extab
,对比一下base64函数
可以看到segment
信息被修复了。既然如此,修改一下findhash的代码
if 'text' in (idc.get_segm_name(seg)).lower()
然后重新打开ida调用下findhash
发现sub_9AECE
和sub_9B1E0
都包含了SHA1
的常量,分别下断点测试后发现调用的是sub_9B1E0
sub_9B1E0
查看引用
sub_9A0E0
可以看到HMAC
的常量。
base64 & hmac-sha1
hook一下base64和hmac函数的参数
public void hook_b64() {
IHookZz hookZz = HookZz.getInstance(emulator);
hookZz.enable_arm_arm64_b_branch();
hookZz.wrap(module.base + 0x99BE0 + 1, new WrapCallback() {
@Override
public void preCall(Emulator> emulator, HookZzArm32RegisterContext ctx, HookEntryInfo info) {
Pointer input = ctx.getPointerArg(0);
byte[] inputHex = input.getByteArray(0, ctx.getR1Int());
System.out.println("b64 input: " + Hex.encodeHexString(inputHex));
// System.out.println(Hex.encodeHexString(inputHex));
Pointer output = ctx.getR2Pointer();
ctx.push(output);
}
@Override
public void postCall(Emulator> emulator, HookZzArm32RegisterContext ctx, HookEntryInfo info) {
Pointer output = ctx.pop();
byte[] outputHex = output.getByteArray(0, ctx.getR0Int());
System.out.println("b64 output: " + Hex.encodeHexString(outputHex));
}
});
hookZz.disable_arm_arm64_b_branch();
}
public void hook_hmac() {
IHookZz hookZz = HookZz.getInstance(emulator);
hookZz.enable_arm_arm64_b_branch();
hookZz.wrap(module.base + 0x9a0e0 + 1, new WrapCallback() {
@Override
public void preCall(Emulator> emulator, HookZzArm32RegisterContext ctx, HookEntryInfo info) {
Pointer input = ctx.getPointerArg(3);
byte[] inputHex = input.getByteArray(0, ctx.getR1Int());
Inspector.inspect(inputHex, "hmac input");
Pointer r2 = ctx.getR2Pointer();
String key = r2.getString(0);
System.out.println("hmac key: " + key);
Pointer output = ctx.getR0Pointer();
ctx.push(output);
}
@Override
public void postCall(Emulator> emulator, HookZzArm32RegisterContext ctx, HookEntryInfo info) {
Pointer output = ctx.pop();
Pointer pointer = output.getPointer(16);
byte[] outputHex = pointer.getByteArray(0, ctx.getR0Int());
Inspector.inspect(outputHex, "hmac output");
}
});
hookZz.disable_arm_arm64_b_branch();
}
第一次hmac
base64
第二次hmac
cyberchef测试一下
说明没有经过魔改。
白盒AES
根据base64输入的长度,猜测它就是AES的输出,由于其长度为80,再加上填充算法的原因,AES输入的长度应该在70-79之间。接下来的目标就是从第一次hmac的输出找到AES的输入,另外还需要找到AES的key和iv(如果有)。
分析AES输入
对第一次hmac的输出进行traceRead,看看谁对它进行了读取
emulator.traceRead(0xbffff168L, 0xbffff168L+20);
可以看到是在libc.so
进行了读操作,打开unidbg-android/src/main/resources/android/sdk23/lib/libc.so
看看
调用了memcpy
函数,那就hook一下
public void hook_memcpy() {
IHookZz hookZz = HookZz.getInstance(emulator);
hookZz.enable_arm_arm64_b_branch();
hookZz.wrap(module.findSymbolByName("memcpy"), new WrapCallback() {
@Override
public void preCall(Emulator> emulator, HookZzArm32RegisterContext ctx, HookEntryInfo info) {
UnidbgPointer output = ctx.getPointerArg(0);
UnidbgPointer input = ctx.getR1Pointer();
int length = ctx.getR2Int();
String hex = Hex.encodeHexString(input.getByteArray(0, length));
System.out.println("src: " + input + ", dst: " + output + ", data: " + hex);
}
});
hookZz.disable_arm_arm64_b_branch();
}
继续对0x402cd4f8
进行读跟踪
跳转过去看看
下断点看看函数的输入输出
r2应该是buffer,存储返回值的,blr下断点,c执行到返回处,看看原r2的数据
就做了个byte转hex的操作。
对0x402db090进行读跟踪
还是在libc.so
的memcpy
进行读取,看看之前hook的记录
此次memcpy之后还有几次memcpy,并且后面连接了一些字符
可以发现是hmac的key,此时字符串的长度是73,符合之前提到的AES输入的长度要求,我们可以合理推断它就是AES的输入。
对最后一次写入的地址0x4043a000进行读跟踪
跳转过去
下个断点看看
可以看到后面进行了填充。
设置AES输入和iv
已经知道是白盒AES,那我们接下来要做些准备工作,把输入设置到一个分组,把iv设置为0。
在此处bt看看调用栈
hook看看函数入参
而0x49=73
正是字符串的长度。
那就hook函数改一下入参
public void set_input() {
IHookZz hookZz = HookZz.getInstance(emulator);
hookZz.enable_arm_arm64_b_branch();
hookZz.wrap(module.base + 0x6A864 + 1, new WrapCallback() {
@Override
public void preCall(Emulator> emulator, HookZzArm32RegisterContext ctx, HookEntryInfo info) {
UnidbgPointer r2 = ctx.getR2Pointer();
UnidbgPointer input = r2.getPointer(0);
String str = "everhu";
input.write(str.getBytes());
r2.setInt(4, str.length());
System.out.println("set aes input: " + str);
}
});
hookZz.disable_arm_arm64_b_branch();
}
地址已经改变了
可以看到AES的输入已经变成一个分组
接下来找找iv,分析一下汇编指令
0x6AE72
处r1加载了输入的地址,0x6AE82
处加载输入的数据,0x6AE84
处r1和r2进行了异或,由此猜测r2是iv,r2是在0xAE7A
从lr加载的。
下断点看看
方便后续的dfa,把iv设为0,选择了偷懒的方式,直接patch 0x6AE84
的语句,改为nop,相当于没有进行异或。
public void set_iv() {
emulator.getMemory().pointer(module.base + 0x6AE84).write(new byte[] {0x00, (byte) 0xbf});
}
重新hook看看base64的输入,也就是AES的结果看看
查找state
继续分析异或之后的操作,0x6AE8A
将异或后的结果存到了r2处的地址,下断点看看
数据存入了0x402dabc0,对其进行读跟踪
0x6AFD0
读取数据到r5之后,0x6AFE2
又将其存到了r3。
下断点看看地址
对0xbffff028进行读跟踪
发现了9轮读取,看来这就是AES的state,看看汇编
下断点看看
发现地址对不上
同时进行读跟踪和下断点
重新在0x6bb12
下断点
确实是在这进行读取。
DFA
接下来进行DFA攻击,函数在0x6bb12进行了16*9
次数据读取,由于DFA需要在第8轮列混淆和第9轮列混淆之间进行操作,因此在第16*8
次读取时随机修改一个字节。
public void dfa() {
emulator.attach().addBreakPoint(module.base + 0x6bb12, new BreakPointCallback() {
@Override
public boolean onHit(Emulator> emulator, long address) {
Arm32RegisterContext ctx = emulator.getContext();
if (count == 16 * 8) {
UnidbgPointer r3 = ctx.getR3Pointer();
r3.setByte(randInt(0, 16), (byte) randInt(0, 0xff));
System.out.println("dfa");
}
count += 1;
return true;
}
});
}
和正确结果对比,发现有4个字节不同,说明操作是对的。
接下来就是去掉多余的输出,调整打印的格式,多次调用。
public static void main(String[] args) {
Logger.getLogger("com.github.unidbg.linux.ARM32SyscallHandler").setLevel(Level.ERROR);
TMall test = new TMall();
test.call_init();
// test.hook_memcpy();
test.hook_b64();
// test.hook_hmac();
test.set_input();
test.set_iv();
test.callXSign();
test.dfa();
for (int i=0; i<16; i++) {
test.count = 0;
test.callXSign();
}
}
之后就比较简单了,调用JeanGrey/phoenixAES和SideChannelMarvels/Stark即可还原出key。