用C写漏洞扫描工具，何编核心就三件事：抓包、漏洞改包、工具看回显。何编别想太复杂，漏洞先把一个最简单的工具HTTP请求发出去再说。

我最早写这类工具是何编为了测自己搭的靶机。当时用Python写了个脚本，漏洞跑起来内存直接爆了，工具因为要同时开几百个线程去扫端口。何编换成C之后，漏洞用epoll加非阻塞socket，工具同样一台机器能扛住两千个并发连接。何编这不是漏洞语言优劣的问题，是工具控制粒度的问题——C让你直接管内存和文件描述符，没有运行时在中间替你“做主”。

先搞定socket通信

漏洞扫描工具的本质就是“发数据、收数据、判断数据”。C里最裸的方式是用socket()建连接，connect()发起，send()和recv()收发。一个最简的TCP连接大概长这样：

int sock = socket(AF_INET, SOCK_STREAM, 0); struct sockaddr_in target; target.sin_family = AF_INET; target.sin_port = htons(80); inet_pton(AF_INET, "192.168.1.1", &target.sin_addr); connect(sock, (struct sockaddr*)&target, sizeof(target));

连上之后，构造HTTP请求字符串直接send()过去。注意要手动加\r\n，C不会帮你补协议格式。收数据用recv()循环读，直到返回0或出错。

协议解析是脏活

真正的麻烦在解析响应。比如判断一个目录遍历漏洞，你要看返回的HTML里有没有root:x:0:0这种特征。C里没有现成的字符串分割函数，得自己写。我习惯用strstr()找关键标记，再用memcpy()把匹配段抠出来。注意别用strcpy()，缓冲区溢出能让你扫别人的时候先把自己扫崩。

写SQL注入检测时，我会构造' OR '1'='1这样的payload，然后对比正常请求和注入请求返回内容的长度差异。C里用strlen()算长度，差几个字节都可能是注入点。但别只看长度，有些WAF会返回固定长度的拦截页面，得结合状态码和特定字符串一起判断。

多线程不能蛮干

用pthread开线程池比每个目标开一个线程靠谱。我一般开CPU核心数×2的线程，每个线程从任务队列里取目标。队列用互斥锁加条件变量控制，别用忙等待——while(1){ if(task)break;}这种写法能把CPU吃满。

还有个坑：DNS解析在C里是阻塞的。getaddrinfo()一卡就是几秒，整个线程都停住。解决办法是提前把所有域名解析成IP存到数组里，或者用getaddrinfo_a()做异步解析。后者文档少，但真能省时间。

内存管理决定工具能不能跑完

扫描一万个URL，每个响应平均10KB，就是100MB。如果忘了free()，跑一半就OOM。我的习惯是每个请求处理完立刻释放响应缓冲区，只保留判断结果（比如“存在漏洞”或“不存在”）。用Valgrind跑一遍，看到“definitely lost”就改。

字符串拼接也别用strcat()反复追加，O(n²)的复杂度在大量请求下很致命。用snprintf()一次性格式化，或者自己维护一个动态缓冲区，按2倍容量扩容。

实际案例：一个目录扫描器

我写过最实用的一个工具是目录爆破。字典文件里放常见路径，每个线程取一个路径拼到目标URL后面，发GET请求，看返回码。200和403都值得关注，301/302要跟进Location头。C里读字典用fgets()逐行读，配合strtok()去掉换行符。注意strtok()不是线程安全的，多线程下用strtok_r()。

这个工具跑在树莓派上，用交叉编译的ARM二进制，一晚上能扫完十万条路径。换成Java或者Go，内存至少多占三倍。C的代价是代码量翻倍，但换来的控制力在渗透测试场景里很值。

最后说一句：别用C写复杂的漏洞利用框架。协议解析和加密部分用C写就是自虐，OpenSSL的API能把你逼疯。C适合写扫描器、爆破器这类“发请求-收响应-做判断”的重复劳动工具。真要做漏洞利用，Python加pwntools组合更省命。