美文网首页
t猫xsign unidbg逆向

t猫xsign unidbg逆向

作者: ever_hu | 来源:发表于2022-04-18 10:18 被阅读0次

    t猫xsign unidbg逆向

    加密流程来源于看雪一位大佬的分享

    2591919-18a845cc4f30be83.png

    findcrypt & findhash

    既然已经知道用到了HMAC-SHA1算法了,那就先用findcryptfindhash找找

    findcrypt

    2591919-95eb1479b4668873.png

    可以看到base64的常量

    2591919-6be60f33765685ad.png

    查看引用

    2591919-2ec0cbbdae2a9193.png 2591919-1b409f8c4e5c5e47.png

    sub_99BE0应该就是进行base64编码的地方了

    findhash

    不知道出了什么问题,没有找到hash常量。于是看了下findhash的代码

    2591919-7de05a0fa7ec7d9c.png

    发现是在.texttext这两个segment里进行搜索,但是so里没有这两个segment。

    2591919-0a580e8c7a53bf64.png

    尝试用frida_dump来dump内存中的so,再看看它的segment

    2591919-c99f0afd09a09611.png

    多了几个segment,其中有个是.text&ARM.extab,对比一下base64函数

    2591919-56cbfb2546dcaa45.png

    可以看到segment信息被修复了。既然如此,修改一下findhash的代码

    if 'text' in (idc.get_segm_name(seg)).lower()
    

    然后重新打开ida调用下findhash

    2591919-d88d0c67d16732ae.png

    发现sub_9AECEsub_9B1E0都包含了SHA1的常量,分别下断点测试后发现调用的是sub_9B1E0

    2591919-6d205a900f3c065a.png 2591919-e52199a9bd4c5d27.png

    sub_9B1E0查看引用

    2591919-6cdc423bdc3705fa.png

    sub_9A0E0

    2591919-f13e439033cddd1f.png

    可以看到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

    2591919-d6ca74ff126213bf.png

    base64

    2591919-8666a5cf5407acab.png

    第二次hmac

    2591919-9206a4e32ff200c1.png

    cyberchef测试一下

    2591919-d845ade464ea75ab.png

    说明没有经过魔改。

    白盒AES

    根据base64输入的长度,猜测它就是AES的输出,由于其长度为80,再加上填充算法的原因,AES输入的长度应该在70-79之间。接下来的目标就是从第一次hmac的输出找到AES的输入,另外还需要找到AES的key和iv(如果有)。

    分析AES输入

    对第一次hmac的输出进行traceRead,看看谁对它进行了读取

    emulator.traceRead(0xbffff168L, 0xbffff168L+20);
    
    2591919-99b66462cbedfa98.png

    可以看到是在libc.so进行了读操作,打开unidbg-android/src/main/resources/android/sdk23/lib/libc.so看看

    2591919-aa537161df11cbbc.png

    调用了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();
    }
    
    2591919-30677e2904901b45.png

    继续对0x402cd4f8进行读跟踪

    2591919-70e9b7987fa87298.png

    跳转过去看看

    2591919-c0a7e4fe67982d87.png 2591919-699423b82dad6023.png

    下断点看看函数的输入输出

    2591919-9f39b335b463c661.png 2591919-348751eaf7584b08.png

    r2应该是buffer,存储返回值的,blr下断点,c执行到返回处,看看原r2的数据

    2591919-ebad8c3209be8a56.png

    就做了个byte转hex的操作。

    对0x402db090进行读跟踪

    2591919-9c08ec9eb2029447.png

    还是在libc.somemcpy进行读取,看看之前hook的记录

    2591919-0f745efeebee962b.png

    此次memcpy之后还有几次memcpy,并且后面连接了一些字符

    2591919-11254b1504370440.png

    可以发现是hmac的key,此时字符串的长度是73,符合之前提到的AES输入的长度要求,我们可以合理推断它就是AES的输入。

    对最后一次写入的地址0x4043a000进行读跟踪

    2591919-001ffbbc5c5cd3e3.png

    跳转过去

    2591919-d9247292f124737f.png

    下个断点看看

    2591919-a766a97303fd084f.png 2591919-32e5c1a402b19db6.png

    可以看到后面进行了填充。

    设置AES输入和iv

    已经知道是白盒AES,那我们接下来要做些准备工作,把输入设置到一个分组,把iv设置为0。

    在此处bt看看调用栈

    2591919-932be504391da127.png 2591919-3a291a0212f8b694.png

    hook看看函数入参

    2591919-ccd2d9ea8bc01344.png 2591919-bc1017358282a2d0.png

    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();
    }
    
    2591919-50fa78495ad835ec.png

    地址已经改变了

    2591919-5bf7fc0071c764a9.png

    可以看到AES的输入已经变成一个分组

    接下来找找iv,分析一下汇编指令

    2591919-7c1ad382c55f186c.png

    0x6AE72处r1加载了输入的地址,0x6AE82处加载输入的数据,0x6AE84处r1和r2进行了异或,由此猜测r2是iv,r2是在0xAE7A从lr加载的。

    下断点看看

    2591919-08abfddf904bf941.png 2591919-5ab0790d3d9180c7.png

    方便后续的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的结果看看

    2591919-9380edcc68bf14fd.png
    查找state

    继续分析异或之后的操作,0x6AE8A将异或后的结果存到了r2处的地址,下断点看看

    2591919-2cad04c54b953454.png

    数据存入了0x402dabc0,对其进行读跟踪

    2591919-3db3f4ece899f3e9.png 2591919-bac61eacacf47848.png

    0x6AFD0读取数据到r5之后,0x6AFE2又将其存到了r3。

    下断点看看地址

    2591919-6a2357cf49662c63.png

    对0xbffff028进行读跟踪

    2591919-145ab5f33c69c45d.png

    发现了9轮读取,看来这就是AES的state,看看汇编

    2591919-78336188786175fa.png

    下断点看看

    2591919-f3ddb5ec765208f4.png

    发现地址对不上

    同时进行读跟踪和下断点

    2591919-61f897ece6371f04.png

    重新在0x6bb12下断点

    2591919-bc8234bd82d2844d.png

    确实是在这进行读取。

    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;
            }
        });
    }
    
    2591919-e72276a85e7d67e1.png

    和正确结果对比,发现有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();
        }
    }
    
    2591919-b5b841ab4b48720d.png

    之后就比较简单了,调用JeanGrey/phoenixAESSideChannelMarvels/Stark即可还原出key。

    相关文章

      网友评论

          本文标题:t猫xsign unidbg逆向

          本文链接:https://www.haomeiwen.com/subject/kjtdertx.html