Start
0x01 信息收集
VB：
VB Decompiler:
两个窗体，关键逻辑在CrackmeV20a的窗体中Command1_Click，这里反编译还是有问题的，所以用OD进行分析：
0x02 流程分析
直接VB断点81 6C 24，程序比较简单，只有三个jmp，随便输入Serial，点击Check it，断在第二个jmp的位置：
往下走来到push ebp，这里应该就是该按钮事件的回调函数了：
先取Serial长度，比较该字符串长度是否等于9，不等于则跳转到弹出失败的位置：
得到Serial为固定长度9
往下这个跳转默认不实现那就不管它：
调用Mid截取字符串，取第一个字符，转成ASCII码：
往下对该字符进行比较，这里比较0x30和0x39应该就是判断是否是数字型字符串：
最后在0x3038AD的位置进行判断：
继续往下跟的时候发现并没有对整个Serial进行判断，也没有最终Serial的判断，直接来到调用失败的rtcMsgBox的位置，可以看到弹出弹窗之后有一个jmp用来跳过提示成功的弹窗：
直接找调用，这个jg指令就是跳到弹出正确Serial弹窗的位置：
该指令跳过了中间一大串的无意义判断，也就是我前面大致分析了的那一段指令，说明CM是没有根据算法生成的Serial，只需要保证输入的Serial长度为9即可，后面分析的第一个字符是否为数字型已经被jmp指令跳过了，后面的一系列判断也就不成立了
0x03 Path
Patch方式就是将jg指令nop掉，然后修改第一条nop指令为jmp 0x403AA4:
Result:
ps: 该CM中用到的816C24断点在CM13中也试过，发现在40开头的地址中找不到，然后跑到0F开头的地址去找，找到了一大堆，然后发现并不是真正想要的按钮事件的断点，后面查了一下发现跟VB的编译环境有关，在VB中，编译分为P-code伪代码编译，以及Native本地编译，像CM13中的就是P-code伪代码编译的，所以就算通过OD看指令也是无法直接看到代码真正的位置的，所以在OEP的位置也就搜索不到VB的特征值了，而CM14中应该是用的Native本地编译的，所以可以通过OEP搜索二进制字符串找到VB的按钮事件特征
Comments NOTHING