哈哈 赞！！

赞

底层也有数据集合..

健健~

协议解析不是难事 关键是效率问题

是否可以把流镜像到外部服务进行分析不是更好？

@李旭敏 oh?

@Terry 凡事做过一次就不难了，您水的这么概括，一看就是大学教授

@正好五个字 还在研究“镜像”的实现方式，因为肯定是要先筛选再镜像的，具体做法很不明朗

贱贱，哦。贱贱，哦。贱哦，贱哦，贱贱哦。

从tcp拼接http不是gfw的黑科技之一么

健健，你家还缺狗吗，会dir溢出的那种

话说 要怎么才能放到路由器里面？

@insight-labs 在下正是曾在方滨兴校长师门下面壁四年的徒弟之一

@chock 作为一只太空猫，遇到汪星人好怕怕啊喵~

@风情万种 集成好依赖库，然后sdk中交叉编译，放在路由器上就好啦

为什么一定要在路由器上搞？iptables tee模块把流量镜像出来不可以吗，或者直接用Throwing Star LAN Tap嗅探。

@ACGT 答：成本问题，目前WooyunWifi成本已经很高了，如果再给每一个WooyunWifi配一个PC专门来解析流量，“编程上的少许便利并不匹配额外加一台PC所造成的成本（成本大约翻10倍吧）”

@lxj616 谢谢答复。既然考虑成本，有没有考虑过抛弃openwrt，直接用raspberry pi + 无线网卡，成本大概高了一倍，无线性能可能不如路由，但是其他硬件性能和软件环境会好很多吧
https://github.com/xtr4nge/FruityWifi

@ACGT 多谢建议，其实硬件适配性也在考虑范围内的，您可以注意到我PPT里特地提到了“避免类似tshark之类的复杂依赖/编译环境”，也就是说，我目前使用的libnids库（其实依赖也就是libnet、libpcap之类的）可以较轻松地适配到几乎任何Unix系统下，其中当然也包括了x86计算机、树莓派等设备。回到您的上一个问题，其实我本意并不是“非要在路由器上做”，而是“流量解析程序能够放在类似路由器这类的设备上运行，保留这个将来可以调整成本的选择”，如果将来条件允许，还是会把程序放在PC上跑的（把流量镜像出来你还是要有地方解析呀，对吧，早晚会用到流重组工具）。//而如果一开始就打定主意要把流量镜像出来然后在PC上写大框架大代码，将来在成本上就没有周旋的余地了 ：）

当时为了实现解析http，特意组装了个服务器，把能收集的http协议全部收集，还开发了个解析tshark数据的py库，但是得到的数据真实然并卵啊，猝