-
-
[原创]第三题 crackMe 分析
-
2017-10-30 11:51
-
运行了下crackMe，随意输入验证码，没有任何提示，只能调试。 
打开ida，开始调试程序，程序直接退出，程序应该又做反调试，先静态分析下。
ida反编译文件，发现入口被修改，先搜索一下关键字看看有没有一些发现，通过搜索CrackMe找到了验证验证码部分的代码，因该是处理消息的函数：
函数对
WM_CLOSE(16),WM_INITDIALOG(272),以及
WM_COMMAND(273)进行了处理。最下面GetDlgItemTextA就是获取用户输入的验证码，但在分析前需要处理下 反调试的逻辑。
对话框创建过程中有很多判断，只要命中就回退出，可以尝试在消息
WM_INITDIALOG的处理过程中打上断点，运行，可以看出程序是在这里退出的。逐个分析这些函数，发现反调试的手段很多：
1. 通过windows api IsDebuggerPresent， CheckRemoteDebuggerPresent等判断进程是否被调试；
2. 通过查看进程之间的关系，查看父进程名称判断进程是否被调试；
3. 通过一些特殊的标志位判断；
4. 通过编译进程，查看当前是否存在调试工具；
还有很多没看懂的方法，但对与该程序都会导致其退出或者抛出异常，
WM_INITDIALOG只是判断了三个条件，
WM_COMMAND下还有几处用到了一些其他的判断调试。
对与api调用可以通过hook调用函数，修改返回值绕过验证，其他的可以直接修改程序的判断逻辑。但CrackMe程序对api调用有做空指针判断，所以我这里偷懒直接修改函数名称，让程序无法调用这些api。
修改方法：hexview找到需要修改的字符串或者指令序列，找到后F2或者右击修改区域选择编辑，修改后F2保存，然后在edit->Patch program->Apply patches to input file,保存到文件中。
修改后，重新调试，可以看到程序能正常起来了，输入验证码，然后单补调试，可以发现sub_120D267，sub_120D96A也做了校验，按照上面的方法对程序做一些修改重新调试，需要重点观察sub_120DB27，这是验证的入口：
静态分析sub_120DB27代码，发现这是个strncmp方法，比较的长度为0x40，第一个参数是固定的，通过计算上面的计算得到，第二个参数还看不出来，因为测试中输入 的验证码为1234567890，往上分析函数：
v10= sub_120D794((int)v23); ==> v10 = strlen(v23); 这个计算变量v21的长度，固定是0x40；
String存的是输入框的验证码。
v11 = &String + sub_120D794((int)&String); ==> v11 指向验证码最后的位置；
v12 = sub_120D794((int)v23); ==> 0x40
可以看出函数sub_120DB27第二个参数是指验证码后64位，也就是说输入框需要输入>=64位的字符串，且以v23结尾.
打开程序，输入183920f00e15a0433ee3a8fc90dd9ac164c4142ccf63ca189a8f645ec96ff8de：
随意添加头部，输入111111183920f00e15a0433ee3a8fc90dd9ac164c4142ccf63ca189a8f645ec96ff8de：
[培训]二进制漏洞攻防（第3期）；满10人开班；模糊测试与工具使用二次开发；网络协议漏洞挖掘；Linux内核漏洞挖掘与利用；AOSP漏洞挖掘与利用；代码审计。
|
|
|---|---|
