首页
社区
课程
招聘
[讨论]CrackMe大赛第五组CL队设计和破解思路
发表于: 2009-10-16 22:38 6208

[讨论]CrackMe大赛第五组CL队设计和破解思路

2009-10-16 22:38
6208

CrackMe设计思路:
为了防爆破,对注册成功的窗口WndProc函数体进行了加密。
由于采用异或加密的方式已经被广泛采用,所以没有使用异或直接对函数体加密,
而采用了一个256字节的交换表,对函数中的字节码进行了随机的交换。
接着用一个8字节的Key,不停循环对这个交换表进行了异或加密。
这样解密时只需要知道Key就可以间接解密出函数体了。
不过由于我的设计上的失误,导致无法从反汇编代码中得知Key的长度为8字节,对此我表示抱歉。

CrackMe破解思路:
首先脱壳,OEP为004C88D9,脱壳后查看0040181C处函数的汇编代码,可知程序算法大致如下:
将用户名和密码经过一些运算,得到一个8字节的Key,
再使用该Key,对一个256字节的数组循环做异或操作,从而解密出一个交换表。
再对一个处理过的函数的前256字节,按照交换表中的顺序重新排列,
并计算CRC32值,用来确认用户名和序列号是否正确。

所以,先从程序中提取出这个256字节的数组和被处理过的函数:

//被异或加密的交换表
const BYTE btEncodedChangeTable[256] = {
//       0     1     2     3     4     5     6     7     8     9     a     b     c     d     e     f
/*0*/    0xA5, 0x80, 0x21, 0xEF, 0x5F, 0x8B, 0x13, 0x44, 0xDE, 0x33, 0xD6, 0x9A, 0x05, 0x0E, 0x2E, 0x59, 
/*1*/    0x2A, 0x78, 0xA3, 0xEC, 0xB2, 0xD9, 0x5C, 0xCE, 0xD2, 0xAE, 0x83, 0x6D, 0x09, 0xA0, 0x1B, 0xF8, 
/*2*/    0xC1, 0x6B, 0xDC, 0xE0, 0xA1, 0xE4, 0x9F, 0x97, 0x85, 0x9B, 0xBA, 0x36, 0x6A, 0x2C, 0x39, 0x7C, 
/*3*/    0x79, 0xE6, 0xA4, 0x78, 0x37, 0xED, 0xF7, 0xCA, 0x16, 0xF3, 0x71, 0x2B, 0xC6, 0xD1, 0x38, 0x1C, 
/*4*/    0x12, 0x7F, 0x32, 0x24, 0xAA, 0x15, 0x81, 0x8C, 0x5C, 0xC8, 0x5B, 0x5B, 0x1F, 0xC5, 0x54, 0x77, 
/*5*/    0x56, 0x13, 0x55, 0x69, 0x07, 0x95, 0xE9, 0x6A, 0xF2, 0x66, 0x4A, 0xD9, 0x54, 0x2E, 0x09, 0xB9, 
/*6*/    0x33, 0xC4, 0xB2, 0xE5, 0x3D, 0x08, 0x92, 0x8B, 0x73, 0xCA, 0x10, 0xA6, 0x6F, 0xF9, 0x59, 0xFC, 
/*7*/    0x6A, 0xBE, 0x6F, 0x21, 0xC9, 0x30, 0x2D, 0xD3, 0xBF, 0xD7, 0x6B, 0xF4, 0x1A, 0xBE, 0xF0, 0x25, 
/*8*/    0x5F, 0xEB, 0xEA, 0xB2, 0x94, 0x02, 0x05, 0x1D, 0xA7, 0x22, 0x91, 0x34, 0xBE, 0x6A, 0xBE, 0xEF, 
/*9*/    0x99, 0xA4, 0x1D, 0x73, 0xCE, 0x75, 0xA1, 0xBE, 0x42, 0x12, 0x1A, 0x93, 0xF8, 0x8D, 0xC1, 0x99, 
/*a*/    0xA3, 0xCB, 0xE9, 0x91, 0xAF, 0x6F, 0xBC, 0x14, 0x54, 0x8B, 0x94, 0x0B, 0x83, 0x70, 0xE2, 0x60, 
/*b*/    0x4E, 0xAB, 0x3A, 0xAA, 0x32, 0x4E, 0x50, 0x71, 0x24, 0x04, 0x19, 0xDE, 0x59, 0xB2, 0x8B, 0x9B, 
/*c*/    0x6E, 0x17, 0xFA, 0x11, 0xDD, 0xC1, 0x1A, 0x87, 0xEE, 0x43, 0xAB, 0x54, 0x5D, 0xA6, 0xCA, 0xF1, 
/*d*/    0x7F, 0x03, 0xE0, 0xC1, 0xE5, 0x5F, 0xFF, 0xFA, 0xC0, 0x4F, 0xAE, 0x29, 0xC2, 0x03, 0xE4, 0x79, 
/*e*/    0x23, 0xCC, 0x9E, 0x7C, 0xE8, 0x21, 0x3C, 0xDD, 0x31, 0xCD, 0xC3, 0xA8, 0x1D, 0x7F, 0x02, 0x5C, 
/*f*/    0xDD, 0xBA, 0xB1, 0xD7, 0x2A, 0xAC, 0x9D, 0x38, 0x20, 0xB9, 0x3D, 0x86, 0x45, 0x3A, 0x7F, 0x41
};

//被加密的函数
const BYTE btEncodedFunction[270] = {
//       0     1     2     3     4     5     6     7     8     9     a     b     c     d     e     f
/*0*/    0x00, 0x6A, 0xBA, 0x1A, 0x66, 0x66, 0x00, 0xC9, 0x8C, 0x8C, 0x3C, 0x54, 0x4C, 0x00, 0x8D, 0x00, 
/*1*/    0x00, 0x00, 0x00, 0x60, 0x74, 0x6A, 0xBA, 0x00, 0xC6, 0x21, 0x81, 0x28, 0x24, 0x00, 0x54, 0x0D, 
/*2*/    0x00, 0xB9, 0x68, 0x89, 0x00, 0x8B, 0x00, 0xFF, 0x83, 0x24, 0xE8, 0xE8, 0x63, 0x00, 0x18, 0x4C, 
/*3*/    0x33, 0x00, 0x6A, 0x83, 0x00, 0xE8, 0x2F, 0x83, 0xE8, 0x50, 0x14, 0x56, 0x54, 0x8B, 0xFF, 0xD2, 
/*4*/    0x66, 0x66, 0x33, 0x00, 0xC4, 0x24, 0xFA, 0x00, 0x24, 0x00, 0x89, 0x0D, 0x24, 0x20, 0x51, 0x00, 
/*5*/    0x00, 0x10, 0x79, 0x20, 0x66, 0x6D, 0x00, 0x66, 0x00, 0x54, 0x00, 0x00, 0x00, 0x3A, 0x00, 0xF1, 
/*6*/    0x01, 0xB9, 0x00, 0x18, 0x24, 0x66, 0x8E, 0x00, 0x8D, 0x55, 0xB9, 0x66, 0x0A, 0x4C, 0x00, 0x89, 
/*7*/    0xBA, 0x81, 0x89, 0x6A, 0x89, 0xB9, 0x4F, 0x28, 0x4D, 0x00, 0x51, 0x89, 0x9F, 0x4C, 0x56, 0x4C, 
/*8*/    0xD0, 0x6A, 0x00, 0x60, 0xE9, 0x0E, 0xFF, 0x50, 0xDF, 0x89, 0x83, 0x00, 0x83, 0x24, 0xB9, 0x24, 
/*9*/    0x20, 0x8B, 0x4C, 0x24, 0x16, 0x00, 0x81, 0x4C, 0x89, 0x62, 0xBA, 0x66, 0x00, 0x00, 0x4C, 0x60, 
/*a*/    0x8B, 0x9C, 0x66, 0x54, 0x74, 0x00, 0x24, 0xD7, 0x6F, 0x00, 0x01, 0x00, 0x51, 0x24, 0x01, 0x66, 
/*b*/    0x00, 0xC1, 0x52, 0x00, 0x54, 0x89, 0x89, 0x6C, 0x66, 0x00, 0xA8, 0x89, 0xE1, 0x00, 0x00, 0xBA, 
/*c*/    0x89, 0x66, 0x4C, 0x14, 0x98, 0x0A, 0x24, 0x89, 0xBF, 0x08, 0x00, 0xFF, 0x4C, 0x6A, 0xE8, 0x25, 
/*d*/    0x0C, 0x54, 0x00, 0x4C, 0x6A, 0x20, 0x57, 0x01, 0x68, 0x4C, 0x08, 0x14, 0x0C, 0x24, 0xC4, 0x00, 
/*e*/    0xBA, 0x24, 0xEC, 0x4C, 0x68, 0x24, 0x89, 0x74, 0x26, 0x4C, 0x00, 0x66, 0xB9, 0x1E, 0x24, 0x54, 
/*f*/    0x68, 0x08, 0x00, 0x24, 0x66, 0x50, 0xF1, 0xBA, 0x22, 0xFF, 0x1C, 0x24, 0x24, 0x89, 0x89, 0x24, 
/*10*/   0x54, 0x24, 0x08, 0x52, 0x56, 0xFF, 0xD7, 0x5F, 0x5E, 0x33, 0xC0, 0x83, 0xC4, 0x20
};

被处理的函数有270字节,而且只出了了前面的256字节,
也就是说,函数末尾的14字节没有处理,所以以这14字节作为突破点。

004C8161   .  52               PUSH EDX                                 ;  ntdll.KiFastSystemCallRet
004C8162   .  56               PUSH ESI
004C8163   .  FFD7             CALL EDI
004C8165   .  5F               POP EDI                                  ;  kernel32.7C82F23B
004C8166   .  5E               POP ESI                                  ;  kernel32.7C82F23B
004C8167   .  33C0             XOR EAX,EAX
004C8169   .  83C4 20          ADD ESP,20
004C816C      EB 10            JMP SHORT _CrackMe.004C817E
...
004C817E   >  C2 1000          RETN 10

接下来观察对这个被加密的函数的引用部分(地址:0040175C),发现这是一个窗口类的WindowProc。
所以断定该函数有4个参数,是一个stdcall函数,并观察该函数末尾,可以看到“RETN 10”,印证了这一猜想。
从“RETN 10”指令向上观察,看到了“ADD ESP,20”,由此证明,该函数的开头没有“PUSH EBP”、“MOV EBP,ESP”等指令,
而是以“SUB ESP,20”开头。也就是说,该函数的开头前3字节为“83 EC 20”。

根据算法得知,程序才用的是交换函数的字节码方式进行的变换,没有修改字节码原有的值,
所以在交换后的函数字节码中,一定存在这3个字节码。

查看被处理的函数,发现在0x28、0x33、0x37、0x8a、0x8c和0x10b这六处出现了0x83,所以不从0x83开始分析。
再检查0xEC,发现只有0xE2这一个位置出现了0xEC,所以从0xEC开始入手。
在被异或加密过的乱序表中,找到下标同样为0xEC的位置,该处被加密前的值应该为0x01,
所以对应的那一位Key为0x9E^0x01 = 0x9F,Key的位置为0xE2%8 = 2,所以得出Key[2] == 0x9F。

接下来根据已知的这一位Key,解密部分交换表:


然后查看0x20在函数中出现的位置,发现该字节码出现在:0x4D、0x53、0x90、0xD5和0x10D,
由于只处理了前256字节,所以0x10D不用考虑,只剩下4处,比0x83出现次数少,所以以0x20为线索继续。

分别假设0x20出现在上面的四处位置,并解密出对应的交换表,
如果某个假设与前面解密出来的那一部分有重复的值,则可以断定这个假设是错误的。
理由:这是一个交换表,对256字节的数据进行交换,交换后依然是256字节,
      如果存在重复的值,则交换后的数据将存在空缺的字节位置。

首先假设0x4D处的值原本应位于0x02处,解密部分交换表如下:(过程略,下同)


发现了0xAD这一个字节出现了两次,所以该假设不成立。

接下来假设0x53处的值原本应位于0x02处,解密部分交换表如下:


暂时未发现重复值,所以该假设可能为正确的,继续尝试其余两种假设。

假设0x90处的值原本应位于0x02处,解密部分交换表如下:


发现了0xC4这一个字节出现了两次,所以该假设不成立。

最后假设0xD5处的值原本应位于0x02处,解密部分交换表如下:


发现0x2D重复出现,所以该假设也被推翻。

只剩下一种假设没有被推翻,所以该假设为正确的,由此计算出Key[3] == 0x6B
根据这两字节已经确定的Key,解密出的部分交换表如下:


接下来对位于原函数第一字节的0xEB机器码也按照上面的方法进行排除,排除掉所有错误的假设,
也可以得到唯一一个正确的假设,并计算出Key[4] == 0xBE

至此已经计算出了3位密钥,分别是
Key[2] == 0x9F
Key[3] == 0x6B
Key[4] == 0xBE

有了这3位密钥,就可以继续计算其他几位的密钥了。
这里直接写了一个程序,完成其余几位Key的计算。
这个程序会利用已知的3位Key,再利用上面的方法推导出一位Key,然后穷举其余4位Key。
穷举4位Key,在Intel Core2 T5550上大约耗时9分钟左右。
(程序见附件,是VC2008的C++控制台程序)

至此该CrackMe的Key已被全部计算和穷举出来了,利用这个Key去还原被加密的函数,就可以进行爆破了。


[培训]内核驱动高级班,冲击BAT一流互联网大厂工作,每周日13:00-18:00直播授课

上传的附件:
收藏
免费 7
支持
分享
最新回复 (1)
雪    币: 291
活跃值: (10)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
2
可惜呀,不然应能拿到奖的
楼主不仅CrackMe设计的好,文章也写的好,学习了
2009-10-16 23:20
0
游客
登录 | 注册 方可回帖
返回
//