CrackMe-014

Start

0x01 信息收集

image20210822110125109.png

VB:

image20210822110207044.png

VB Decompiler:

image20210822113055142.png

两个窗体,关键逻辑在CrackmeV20a的窗体中Command1_Click,这里反编译还是有问题的,所以用OD进行分析:

image20210822113707310.png

0x02 流程分析

直接VB断点81 6C 24,程序比较简单,只有三个jmp,随便输入Serial,点击Check it,断在第二个jmp的位置:

image20210822113844543.png

往下走来到push ebp,这里应该就是该按钮事件的回调函数了:

image20210822114203267.png

先取Serial长度,比较该字符串长度是否等于9,不等于则跳转到弹出失败的位置:

image20210822212103851.png

image20210822212212392.png

得到Serial为固定长度9

image20210822212435165.png

往下这个跳转默认不实现那就不管它:

image20210822212855152.png

调用Mid截取字符串,取第一个字符,转成ASCII码:

image20210822213059554.png

image20210822213150144.png

往下对该字符进行比较,这里比较0x30和0x39应该就是判断是否是数字型字符串:

image20210822213349220.png

最后在0x3038AD的位置进行判断:

image20210822213526720.png

继续往下跟的时候发现并没有对整个Serial进行判断,也没有最终Serial的判断,直接来到调用失败的rtcMsgBox的位置,可以看到弹出弹窗之后有一个jmp用来跳过提示成功的弹窗:

image20210822215756357.png

image20210822215854596.png

直接找调用,这个jg指令就是跳到弹出正确Serial弹窗的位置:

image20210822220000046.png

image20210822220029055.png

该指令跳过了中间一大串的无意义判断,也就是我前面大致分析了的那一段指令,说明CM是没有根据算法生成的Serial,只需要保证输入的Serial长度为9即可,后面分析的第一个字符是否为数字型已经被jmp指令跳过了,后面的一系列判断也就不成立了

0x03 Path

Patch方式就是将jg指令nop掉,然后修改第一条nop指令为jmp 0x403AA4:

image20210822220205984.png

Result:

image20210822220422773.png

image20210822220548064.png

image20210822221045728.png

image20210822221100006.png

ps: 该CM中用到的816C24断点在CM13中也试过,发现在40开头的地址中找不到,然后跑到0F开头的地址去找,找到了一大堆,然后发现并不是真正想要的按钮事件的断点,后面查了一下发现跟VB的编译环境有关,在VB中,编译分为P-code伪代码编译,以及Native本地编译,像CM13中的就是P-code伪代码编译的,所以就算通过OD看指令也是无法直接看到代码真正的位置的,所以在OEP的位置也就搜索不到VB的特征值了,而CM14中应该是用的Native本地编译的,所以可以通过OEP搜索二进制字符串找到VB的按钮事件特征

End

avatar