唐河企业网站制作怎么样,抖音seo排名软件哪个好,网站免费优化工具,深圳注册公司需要哪些材料和流程一、目标
2023年了#xff0c;MD5已经是最基础的签名算法了#xff0c;但如果你还只是对输入做了简单的MD5#xff0c;肯定会被同行们嘲笑。加点盐#xff08;salt#xff09;是一种基本的提升#xff0c;但在这个就业形势严峻的时代#xff0c;仅仅加盐肯定不够了。
…一、目标
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,#0x110var_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, #0x110var_B0
.text:00000000000011E4 E5 43 01 91 ADD X5, SP, #0x110var_C0
.text:00000000000011E8 E6 03 01 91 ADD X6, SP, #0x110var_D0
.text:00000000000011EC E7 C3 00 91 ADD X7, SP, #0x110var_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 address0x40001234, arguments[unidbg0xfffe1640[libandroid.so]0x640, 1853170425, 2008362258]x00xbffff690(-1073744240) x10x0 x20x4 x30xbfffed20 x40x40230200 x50x402302c0 x60x1 x70xbffff708 x80x0 x90x0 x100x1 x110x0 x120x8 x130x8 x140x8x150x8 x160x40228d70 x170x40177ddc x180x8 x190x4cf3a208 x200x400012b8 x210x0 x220x68ca89dd x230x3d74755a x240x72e737bb x250xddf5ac1 x260xd0d5adc6 x270x8b81914d x280xf7100797 fp0xbffff680
LRRX0x400011d4[libnative-lib.so]0x11d4
SP0xbffff570
PCRX0x400011d8[libnative-lib.so]0x11d8
nzcv: N0, Z1, C1, V0, 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 address0x40001234, arguments[unidbg0xfffe1640[libandroid.so]0x640, 1853170425, 2008362258]x00xbffff690(-1073744240) x10xffffffffffffffff x20x40 x30x400012bb x40xbffff5d0 x50xbffff5c0 x60xbffff5b0 x70xbffff5a0 x80x0 x90x0 x100x1 x110x0 x120x8 x130x8 x140x8
LRRX0x400011d4[libnative-lib.so]0x11d4
SP0xbffff570
PCRX0x400011f8[libnative-lib.so]0x11f8
nzcv: N0, Z1, C1, V0, EL0, use SP_EL0
start 0xb08*[libnative-lib.so*0x011f8]*[5bfdff97]*0x400011f8:*bl #0x40000764这个时间点入参都已经准备好了我们来一个一个看看这些入参。
mx7-----------------------------------------------------------------------------
[10:40:26 646]x7unidbg0xbffff5a0, md5d6c164ca9ef531557fc14e1bf7173663,
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 address0x40001234, arguments[unidbg0xfffe1640[libandroid.so]0x640, 1853170425, 2008362258]x00x40004000 x10xbffff690 x20x0 x30x1 x40x0 x50x1 x60x0 x70x0 x80xfffe0a70 x90x3002 x100x0 x110x1 x120x3 x130x40003018 x140x40003028x150x1 x160x40228910 x170x0 x180x17 x190xfffe1640 x200xbffff708 x210x0 x220x0 x230x0 x240x0 x250x0 x260x0 x270x0 x280x0 fp0xbffff6f0
LRRX0x40001280[libnative-lib.so]0x1280
SP0xbffff690
PCRX0x40000a3c[libnative-lib.so]0xa3c
nzcv: N0, Z0, C1, V0, EL0, use SP_EL0
start 0x34c*[libnative-lib.so*0x00a3c]*[ff8304d1]*0x40000a3c:*sub sp, sp, #0x120traceWrite 0xbffff5d0 0xbffff5d8
Set trace 0xbffff5d0-0xbffff5d8 memory write success.
c
[11:41:41 656] Memory WRITE at 0xbffff5d8, data size 1, data value 0x0, PCRX0x40001168[libnative-lib.so]0x1168, LRnull
[11:41:41 657] Memory WRITE at 0xbffff5d0, data size 8, data value 0x0, PCRX0x4000116c[libnative-lib.so]0x116c, LRnull
[11:41:41 661] Memory WRITE at 0xbffff5d8, data size 1, data value 0x0, PCRX0x401b48cc[libc.so]0x648cc, LRRX0x401b48c8[libc.so]0x648c8traceWrite 就是监控写内存命令。
看上去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, #0x110var_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,#0x110var_A8]
.text:000000000000116C FF 33 00 F9 STR XZR, [SP,#0x110var_B0]
.text:0000000000001170 7D FD FF 97 BL sub_7640x116c 的指令 STR XZR 是写入 没错但是看上去不像是写入数据而是把 SP,#0x110var_B0 这个地址的数据清零。
那我们重来一次(Unidbg的优点就是可以无限重放比真机调试App方便了不知道多少倍。)
这次往前一点点在 0x114C 下断点。
断下来之后每s单步一次之后就去查看 m0xbffff5d0。
最后发现跑完 0x1170 , 0xbffff5d0内存的值就改变成了 DD89CA68 。 这说明 0xbffff5d0 是 sub_764 函数去写的。
debugger break at: 0x40001170 Function64 address0x40001234, arguments[unidbg0xfffe1640[libandroid.so]0x640, 1853170425, 2008362258]x00xbffff5d0(-1073744432) x10x9 x20x9 x30x400012b8 x40xdd89ca68 x50xe6cd8e62 x60x24523012 x70x29b9c389 x80x40 x90x40318041 x100xbffff5e0 x110x40 x120x3d5ebb2b x130x6450c165 x140xfc63b7e7x150x49ac16b x160xac6af723 x170xf3d1564b x180x18 x190x4cf3a208 x200x400012b8 x210x0 x220x68ca89dd x230x3d74755a x240x72e737bb x250xddf5ac1 x260xd0d5adc6 x270x8b81914d x280xf7100797 fp0xbffff680
LRnull
SP0xbffff570
PCRX0x40001170[libnative-lib.so]0x1170
nzcv: N0, Z1, C1, V0, EL0, use SP_EL0
start 0xa80*[libnative-lib.so*0x01170]*[7dfdff97]*0x40001170:*bl #0x40000764不过回到 0x1170,我们发现了一串熟悉的数字 x40xdd89ca68 好吧我们的问题又变成了 x4的值是怎么算出来的
三、总结
首先要习惯看Arm汇编一步一步单步调试然后熟悉寄存器的变化。特别对一些关键数字要敏感。
要掌握Unidbg的基础调试命令。
常见的加密算法要熟悉一下在开发环境里多调试几遍熟悉它的算法流程。 1:ffshow
多方分别是非之窦易开一味圆融人我之见不立。
