第一篇：Python3实现ICMP远控后门(上)
第二篇：Python3实现ICMP远控后门(上)_补充篇
在上两篇文章中，详细讲解了ICMP协议，同时实现了一个具备完整功能的ping工具，完整的代码发布在https://github.com/qiyeboy/LuLunZi/blob/master/NetWork/ping.py中。本次讲的是嗅探，为什么要讲嗅探呢？和ICMP后门有什么关系呢？本篇的干货有点多。。。
第一节 ICMP后门结构
设计的ICMP后门采用的是典型的C/S结构，分为客户端和服务端，根据客户端和服务端的位置又分为正向连接和反向连接。对于TCP和UDP后门来说，正向和反向连接是有很大区别的，反向连接的目的之一就是为了规避正向连接时防火墙拦截端口绑定的问题。下面先讲一下正向连接和反向连接的概念。早期采用的是正向连接，现在更常见的是反向连接。
正向连接
正向连接时，server位于受控端，拥有公网ip，同时监听端口，等待连接。正向连接为什么逐渐被淘汰了呢？有几点原因，首先受控端的server程序需要绑定端口，容易被主机上的防火墙拦截发现，例如下图的情景。
接着是由于随着连接的控制端增多，受控端负载过大，易被发现，而且不适合大规模控制。最后是假如受控端是在内网中，正向连接就失去作用。
反向连接
反向连接就很好的规避了正向连接中的问题，受控端可以有公网ip，也可以没有，需要控制端拥有一个公网的主机即可，一般都是用VPS。
ICMP协议和TCP，UDP协议有很大的区别，ICMP没有端口的概念，就是说它不是通过端口来识别ICMP发送与接收进程的，也就没有端口绑定被拦截的问题，也避开了通过端口反查进程的检测手段。
正是ICMP协议没有端口的概念，也就无法直接建立两台主机上ICMP应用程序的通信，记住我说的是应用程序。大家肯定会疑问ping不就可以吗？其实ping本质上是位于系统内核。下面通过一张图来说明操作系统对icmp的处理。
假如用我写的ping.py程序，在受控端ping控制端，ICMP请求包通过网络传到控制端，在控制端的系统内核中，就直接生成ICMP响应返回给受控端的ping.py，根本不会由控制端的ping.py响应。也就是说ping.py本质上是ICMP协议的客户端，而不是服务端，服务端始终是主机的系统内核来完成了。
为难的地方也就出现了？服务端不受控制，那我们如何完成受控端应用程序和控制端应用程序的通信呢？其实不一定让两者直接通信，可以间接通信，只要受控端和控制端知道互相发送的内容不就可以了，这就是下一节的知识点。
第二节 “嗅探”黑科技
嗅探不知道大家熟不熟悉？大家肯定用过wireshark抓包吧，这就是嗅探的典型应用。虽然受控端发来的ping包，无法直接发给控制端的ping.py，但是控制端可以通过嗅探的方式抓取传输过来的ping包，获取里面的内容，然后主动发响应包给受控端，同理受控端也是如此。ICMP后门的通信结构就变成了下图所示的样子。