程序没有加壳，可以直接跟踪调试。

首先通过断Messagebox找到程序各个判断的地方，改掉验证字符长度，验证字符输入和验证CRC的分支后我们发现程序最后跳进了0x004044C8

继续跑，程序直接异常了

重新打开程序，对这个地址下断，根据看内存的值可以判断这里是一个16B的数组

而最后程序会跳到这个数组里执行代码

通过对程序的分析，可以知道里面有一个CRC48校验

要构造出能弹出Win的shellcode不难，但碰不上CRC校验。所以此路不通。

要构造出CRC校验，就只能用10B完成弹出Win的任务，然后用剩下的6B满足CRC校验。然而，当时的寄存器中也并没有存放”Win”的地址，光是call Messagebox 和push 字符串地址就占掉了10B了。所以，光靠这10B想完成任务也是行不通的。

因此可以肯定：这10B最终将跳转到其他的地方执行代码，而剩下的6B是根据这10B和CRC校验反推出来的。

那么我们就得找其他的地方是否可以执行出弹出带”Win”的Messagebox代码，作者是否留下了什么线索或漏洞。

线索一:这个exe的资源节是可执行的！！！

众所周知，正常编译出的exe的资源节没有执行权

然而，这个exe的4个节区都是可读可写可执行。这说明了数据区和资源区是可以在运行中修改数据并且可以执行代码的!

简单观察可以发现：资源节中4个字节为一组，第4个字节固定是FF，明显有规律。

但是，这里很明显有不符合规律的数据出现在了资源里面

这个地址是：0x1A390h + 2000h + 400000h = 41C390h

在Debug里面反汇编就能看出这里是一段弹出messagebox的代码。

显然，那10B应该跳到这里来！

如果觉得查看程序各节的权限，属于高难度技术手段，还有更简单的线索二：

线索二：用肉眼看一看这个程序的资源

这个程序没有什么其它资源，基本上就是图标了。用工具提取icon资源区图标，看看！

这里其他图片都没有彩色的点，这里却有彩色的点

有彩色点的图片是Icon的第6张

找到资源icon的第6个图标资源区，注意这个

根据上下格式这里有一段二进制和正常的icon数据不同(正常的格式4字节一组第4字节为FF)，这也说明了为什么图片上有莫名的斑点

这里可以拿到文件地址 1A390h 

程序没有开启随机基址 基址位置 0x00400000h

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课