-
-
[讨论]CrackMe大赛第五组CL队设计和破解思路
-
发表于: 2009-10-16 22:38
-
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去还原被加密的函数，就可以进行爆破了。
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！
