-
-
[讨论]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直播授课