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<HookZzArm32RegisterContext>() {
@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<HookZzArm32RegisterContext>() {
@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<HookZzArm32RegisterContext>() {
@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<HookZzArm32RegisterContext>() {
@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。
