一、方针

2023年了,MD5现已是最根底的签名算法了,但假如你还仅仅对输入做了简略的MD5,肯定会被同行们嘲笑。加点盐(salt)是一种根本的提升,但在这个工作形势严峻的年代,仅仅加盐肯定不够了。

今天咱们就来讲一讲魔改的MD5,让这个算法巨大上起来。

1、菜卷

最简略的魔改办法便是改动MD5的初始参数,

     context->state[0] = 0x67452301;
     context->state[1] = 0xEFCDAB89;
     context->state[2] = 0x98BADCFE;
     context->state[3] = 0x10325476;

把这四个参数修正一下就行了。通过修正这些参数,咱们能够改动MD5的运算成果。但这种办法实在太简略了,卷不起来。

接下来,咱们要介绍更高档的卷法。

2、肉卷

md5会进行64轮运算,每轮运算都会用到一个常量,组成一个常量表K。

K原始值的计算方式是 2^32 * |sin i |,然后取其整数部分。

那么有理想的同学就能够更改这个K值,比方把 sin改成 cos或许tan之类的,这样就能够卷起来了。

3、卷中卷

//F,G,H,I四个非线性改换函数
#define F(x,y,z) ((x & y) | (~x & z))
#define G(x,y,z) ((x & z) | (y & ~z))
#define H(x,y,z) (x^y^z)
#define I(x,y,z) (y ^ (x | ~z))
//x循环左移n位的操作
#define ROTATE_LEFT(x,n) ((x << n) | (x >> (32-n)))

要真正卷起来,咱们需求改动MD5中的四个非线性改换函数F、G、H、I。咱们能够加上异或或许 减少操作,整个算法就换了个相貌。这种高档卷法能够忽悠住老板,让算法巨大上起来。

咱们今天的方针是测验复原一个魔改之后的MD5算法,通过这次实践来了解算法复原的根本办法。

这个样本咱们的入参是字符串:“1677038066553”

返回值是32个字符:“DD89CA684D91818B970710F75A75743D”

二、步骤

第一步

咱们需求用Unidbg跑通算法,比起上古时期用ida调试的前辈,Unidbg的呈现直接把算法复原的难度降了一个数量级。

第二步

咱们需求把成果Z通过反向推导一步一步回到原始输入A。这种办法叫做倒果为因,是逆向剖析的一种根本套路。

咱们假定这个样本是MD5或许是魔改的MD5,咱们能够用以下几种办法来复原算法:

1、调试断点

2、条件断点

3、数据打印

4、Trace内存读写

5、Trace代码

1、调试断点

逆向剖析是经验科学,尽管有一些根本套路,可是还是以试为主,先用IDA翻开 libnative-lib.so,从 Exports 导出表里边找到导出函数Java_com_littleq_cryptography_md5_MainActivity_sign

这个函数的开端地址在0x1234, 结束地址在0x12B4,可是主要的代码逻辑在函数sub_A3C里边, 咱们先在sub_A3C函数的结尾下个断点试试,

text:00000000000011D4 E0 07 40 F9                 LDR             X0, [SP,#0x110+var_108]
.text:00000000000011D8 03 00 00 90+                ADRL            X3, aSSSS ; "%s%s%s%s"
.text:00000000000011D8 63 EC 0A 91
.text:00000000000011E0 E4 83 01 91                 ADD             X4, SP, #0x110+var_B0
.text:00000000000011E4 E5 43 01 91                 ADD             X5, SP, #0x110+var_C0
.text:00000000000011E8 E6 03 01 91                 ADD             X6, SP, #0x110+var_D0
.text:00000000000011EC E7 C3 00 91                 ADD             X7, SP, #0x110+var_E0
.text:00000000000011F0 01 00 80 92                 MOV             X1, #0xFFFFFFFFFFFFFFFF
.text:00000000000011F4 02 08 80 52                 MOV             W2, #0x40 ; '@'

这个 0x11D8 很像是格式化字符串。

咱们在Unidbg里边给 0x11D8 下个断点

    Debugger debugger = emulator.attach();
    debugger.addBreakPoint(module.base + 0x11D8);

运行一下,顺利的断下来了

debugger break at: 0x400011d8 @ Function64 address=0x40001234, arguments=[unidbg@0xfffe1640[libandroid.so]0x640, 1853170425, 2008362258]
>>> x0=0xbffff690(-1073744240) x1=0x0 x2=0x4 x3=0xbfffed20 x4=0x40230200 x5=0x402302c0 x6=0x1 x7=0xbffff708 x8=0x0 x9=0x0 x10=0x1 x11=0x0 x12=0x8 x13=0x8 x14=0x8
>>> x15=0x8 x16=0x40228d70 x17=0x40177ddc x18=0x8 x19=0x4cf3a208 x20=0x400012b8 x21=0x0 x22=0x68ca89dd x23=0x3d74755a x24=0x72e737bb x25=0xddf5ac1 x26=0xd0d5adc6 x27=0x8b81914d x28=0xf7100797 fp=0xbffff680
LR=RX@0x400011d4[libnative-lib.so]0x11d4
SP=0xbffff570
PC=RX@0x400011d8[libnative-lib.so]0x11d8
nzcv: N=0, Z=1, C=1, V=0, EL0, use SP_EL0
start + 0xae8
=> *[libnative-lib.so*0x011d8]*[03000090]*0x400011d8:*"adrp x3, #0x40001000"
    [libnative-lib.so 0x011dc] [63ec0a91] 0x400011dc: "add x3, x3, #0x2bb"
    [libnative-lib.so 0x011e0] [e4830191] 0x400011e0: "add x4, sp, #0x60"
    [libnative-lib.so 0x011e4] [e5430191] 0x400011e4: "add x5, sp, #0x50"
    [libnative-lib.so 0x011e8] [e6030191] 0x400011e8: "add x6, sp, #0x40"
    [libnative-lib.so 0x011ec] [e7c30091] 0x400011ec: "add x7, sp, #0x30"
    [libnative-lib.so 0x011f0] [01008092] 0x400011f0: "mov x1, #-1"
    [libnative-lib.so 0x011f4] [02088052] 0x400011f4: "mov w2, #0x40"
    [libnative-lib.so 0x011f8] [5bfdff97] 0x400011f8: "bl #0x40000764"

在Arm汇编里边,调用一个函数之前,会把入参存入到 x0,x1,x2 …​…​

从这段代码能够看出 地址 0x400011f8 会调用 0x40000764 函数,而且传入了 7个参数, 从x0,一直赋值到x7。

Unidbg的调试尽管有些简陋,可是现已够用了,有如此神器在手,你还要啥自行车?

调试指令先把握以下几个:

s 单步步入,便是遇到函数调用会进入。

n 单步步过,遇到函数调用不会进入函数。

c 继续履行

b 下断点

r 取消当前断点

m 检查内存

咱们先 s s s 几下,单步履行到 0x400011f8

debugger break at: 0x400011f8 @ Function64 address=0x40001234, arguments=[unidbg@0xfffe1640[libandroid.so]0x640, 1853170425, 2008362258]
>>> x0=0xbffff690(-1073744240) x1=0xffffffffffffffff x2=0x40 x3=0x400012bb x4=0xbffff5d0 x5=0xbffff5c0 x6=0xbffff5b0 x7=0xbffff5a0 x8=0x0 x9=0x0 x10=0x1 x11=0x0 x12=0x8 x13=0x8 x14=0x8
LR=RX@0x400011d4[libnative-lib.so]0x11d4
SP=0xbffff570
PC=RX@0x400011f8[libnative-lib.so]0x11f8
nzcv: N=0, Z=1, C=1, V=0, EL0, use SP_EL0
start + 0xb08
=> *[libnative-lib.so*0x011f8]*[5bfdff97]*0x400011f8:*"bl #0x40000764"

这个时间点,入参都现已预备好了,咱们来一个一个看看这些入参。

mx7
>-----------------------------------------------------------------------------<
[10:40:26 646]x7=unidbg@0xbffff5a0, md5=d6c164ca9ef531557fc14e1bf7173663,
size: 112
0000: 35 41 37 35 37 34 33 44 00 B3 22 40 00 00 00 00    5A75743D.."@....
0010: 39 37 30 37 31 30 46 37 00 8D 09 40 00 00 00 00    970710F7...@....
0020: 34 44 39 31 38 31 38 42 00 77 12 40 02 00 00 00    4D91818B.w.@....
0030: 44 44 38 39 43 41 36 38 00 1B 17 40 02 00 00 00    DD89CA68...@....
0040: 31 36 37 37 30 33 38 30 36 36 35 35 33 80 00 00    1677038066553...
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
^-----------------------------------------------------------------------------^

能够看到这次调用 函数 0x40000764, 根本便是在组装最终的成果了。

咱们要做的便是找到这些成果生成的方位,来剖析最终成果是如何计算出来的,也便是 Y → Z 的进程。

4、Trace内存读写

现在咱们现已知道了成果Z的方位,下一步便是需求知道谁计算出了Z。

这就需求用到Unidbg的一个强大功用:内存读写监控

这一次咱们先把调试断点下早一点,在 sub_A3C 函数开头就断下来。

debugger break at: 0x40000a3c @ Function64 address=0x40001234, arguments=[unidbg@0xfffe1640[libandroid.so]0x640, 1853170425, 2008362258]
>>> x0=0x40004000 x1=0xbffff690 x2=0x0 x3=0x1 x4=0x0 x5=0x1 x6=0x0 x7=0x0 x8=0xfffe0a70 x9=0x3002 x10=0x0 x11=0x1 x12=0x3 x13=0x40003018 x14=0x40003028
>>> x15=0x1 x16=0x40228910 x17=0x0 x18=0x17 x19=0xfffe1640 x20=0xbffff708 x21=0x0 x22=0x0 x23=0x0 x24=0x0 x25=0x0 x26=0x0 x27=0x0 x28=0x0 fp=0xbffff6f0
LR=RX@0x40001280[libnative-lib.so]0x1280
SP=0xbffff690
PC=RX@0x40000a3c[libnative-lib.so]0xa3c
nzcv: N=0, Z=0, C=1, V=0, EL0, use SP_EL0
start + 0x34c
=> *[libnative-lib.so*0x00a3c]*[ff8304d1]*0x40000a3c:*"sub sp, sp, #0x120"
traceWrite 0xbffff5d0 0xbffff5d8
Set trace 0xbffff5d0->0xbffff5d8 memory write success.
c
[11:41:41 656] Memory WRITE at 0xbffff5d8, data size = 1, data value = 0x0, PC=RX@0x40001168[libnative-lib.so]0x1168, LR=null
[11:41:41 657] Memory WRITE at 0xbffff5d0, data size = 8, data value = 0x0, PC=RX@0x4000116c[libnative-lib.so]0x116c, LR=null
[11:41:41 661] Memory WRITE at 0xbffff5d8, data size = 1, data value = 0x0, PC=RX@0x401b48cc[libc.so]0x648cc, LR=RX@0x401b48c8[libc.so]0x648c8

traceWrite 便是监控写内存指令。

看上去0xbffff5d0这段内存,写入DD89CA68数据的方位是: 0x116c

text:000000000000114C 14 00 00 90+                ADRL            X20, unk_12B8
.text:000000000000114C 94 E2 0A 91
.text:0000000000001154 C4 0A C0 5A                 REV             W4, W22
.text:0000000000001158 E0 83 01 91                 ADD             X0, SP, #0x110+var_B0
.text:000000000000115C 21 01 80 52                 MOV             W1, #9
.text:0000000000001160 22 01 80 52                 MOV             W2, #9
.text:0000000000001164 E3 03 14 AA                 MOV             X3, X20
.text:0000000000001168 FF A3 01 39                 STRB            WZR, [SP,#0x110+var_A8]
.text:000000000000116C FF 33 00 F9                 STR             XZR, [SP,#0x110+var_B0]
.text:0000000000001170 7D FD FF 97                 BL              sub_764

0x116c 的指令 STR XZR 是写入 没错,可是看上去不像是写入数据,而是把SP,#0x110+var_B0这个地址的数据清零。

那咱们重来一次,(Unidbg的长处便是能够无限重放,比真机调试App方便了不知道多少倍。)

这次往前一点点,在 0x114C 下断点。

断下来之后,每s单步一次之后,就去检查 m0xbffff5d0。

最终发现跑完 0x1170 , 0xbffff5d0内存的值就改动成了,DD89CA68。 这说明 0xbffff5d0 是 sub_764 函数去写的。

debugger break at: 0x40001170 @ Function64 address=0x40001234, arguments=[unidbg@0xfffe1640[libandroid.so]0x640, 1853170425, 2008362258]
>>> x0=0xbffff5d0(-1073744432) x1=0x9 x2=0x9 x3=0x400012b8 x4=0xdd89ca68 x5=0xe6cd8e62 x6=0x24523012 x7=0x29b9c389 x8=0x40 x9=0x40318041 x10=0xbffff5e0 x11=0x40 x12=0x3d5ebb2b x13=0x6450c165 x14=0xfc63b7e7
>>> x15=0x49ac16b x16=0xac6af723 x17=0xf3d1564b x18=0x18 x19=0x4cf3a208 x20=0x400012b8 x21=0x0 x22=0x68ca89dd x23=0x3d74755a x24=0x72e737bb x25=0xddf5ac1 x26=0xd0d5adc6 x27=0x8b81914d x28=0xf7100797 fp=0xbffff680
LR=null
SP=0xbffff570
PC=RX@0x40001170[libnative-lib.so]0x1170
nzcv: N=0, Z=1, C=1, V=0, EL0, use SP_EL0
start + 0xa80
=> *[libnative-lib.so*0x01170]*[7dfdff97]*0x40001170:*"bl #0x40000764"

不过回到 0x1170,咱们发现了一串了解的数字x4=0xdd89ca68, 好吧,咱们的问题又变成了 x4的值是怎样算出来的?

三、总结

首先要习气看Arm汇编,一步一步单步调试,然后了解寄存器的变化。特别对一些关键数字要敏感。

要把握Unidbg的根底调试指令。

常见的加密算法要了解一下,在开发环境里多调试几遍,了解它的算法流程。

代码还原小试牛刀(一):魔改的MD5

1:ffshow

多方别离,对错之窦易开;一味圆融,人我之见不立。

Tip:

: 本文的目的只要一个便是学习更多的逆向技巧和思路,假如有人使用本文技能去进行不合法商业获取利益带来的法律责任都是操作者自己承当,和本文以及作者没关系,本文涉及到的代码项目能够去奋飞的朋友们常识星球自取,欢迎加入常识星球一起学习探讨技能。有问题能够加我wx:fenfei331讨论下。

重视微信公众号: 奋飞安全,最新技能干货实时推送