发布原创的syn扫描器－SharpTcpScanner AssemblyFileVersion:1.9.0.0

AssemblyFileVersion:1.9.0.0

2014年5月19日更新1.9.0.0版http://download.csdn.net/detail/laotse/7369863

修正了因多网卡、多虚拟网卡、同网卡绑定多ip、网关等复杂网络结构导致无法使用winpcap模式的问题

增加了调用winpcap发送数据包功能，这样的话win7 win8 win8.1 xp vista这些桌面版操作系统也可以syn扫描了

并且默认首先使用winpcap发送，如果没安装winpcap再转rawsocket方式，推荐之前破解xp-syn的人也装winpcap然后用winpcap来发送吧。

因为有个Socket.IOControl的关系，所以必须以管理员方式运行，否则系统就会不让操作而报错。

顺便说句如果想学习c#如何用winpcap发送的请看这贴 http://blog.csdn.net/laotse/article/details/16983287 本程序就是这么发送的，而监听用的还是socket，因为.net自带的socket相比于用winpcap监听实在省心太多了。

感谢qq3671朋友提供了timeBeginPeriod(1)使得thread.sleep精度突破15毫秒限制的方法，但是我实际测试后发现，只能到1毫秒将近2毫秒的精度，这样即使用了这个方法，每秒也就只有500个左右，量是太少了点，于是决定还是不改了，关于timeBeginPeriod(1)详情，请看http://blog.csdn.net/laotse/article/details/14093869

修正了扫描大量ip后程序崩溃的bug。

加入了一个验证，可以防止扫描中的虚假结果。

另外1.6版及之前版本扫着扫着会崩溃的问题，现已查明是.net本身的一个bug，就是说如果.net的console程序console.writeline或者console.write的量超过2G字节就会使整个程序崩溃，streamwrite也有这个问题，大家可以看看我刚转载的这篇文章http://blog.csdn.net/laotse/article/details/8172632，也可以去百度谷歌下“InternalEncoderBestFitFallback streamwriter”，日的微软社区一管理员都说是.net的问题，反馈m$也不解决。

今后将加入winpcap方式，这样扫描就不限于部分系统了。 

 

使用方法

前言：本程序下面介绍的所有按步骤输入的都可以作为参数，所以下面评论的喜欢批处理的同志也可以按批处理来

规则 SharpTcpScanner.exe 地址集 端口集 阻塞值

比如 C:\SharpTcpScanner.exe -hun:hun.txt 1433 36

或者 C:\SharpTcpScanner.exe 192.168.0.1 1-65535 0

等等

 

1、输入地址集

总体要求输入的为以英文逗号分隔的ip和ip段

可以 192.168.0.1

可以 192.168.0.1,192.168.0.2,192.168.0.3

可以 192.168.0.1-192.168.0.10

可以 192.168.0.1-192.168.0.10,192.168.0.20-192.168.0.30

也可以ip和ip段的混合

可以 192.168.0.1,192.168.0.2-192.168.0.10,192.168.0.20,192.168.0.30-192.168.0.40

 

如果ip和ip段的混合太多了没法手动输入，举个例子，我用最新的纯真ip库把整个南朝鲜的ip段都整合到了一起是这个样子的。

这就没法手动输入了，怎么办？

新建一个叫hun.txt的utf8编码的文本文档，把这些ip段的混合放进去保存在本程序同目录下。

然后在输入地址集的地方输入-hun:hun.txt，这样程序就把这个ip段导入了，代替了手动输入。下面有评论说批处理什么的，本程序不需要批处理，任何功能程序中本来就有，像这样子不比你的批处理好多了？

 

还有一种情况，我已经扫描了一大堆的1433如图

现在我想直接扫描这个列表中的ip的3389端口

怎么导入呢？把:1433替换掉？然后用逗号，然后变成一行？NO！

只需要-in:scanReport.txt，这样子程序就会把这里面的ip给导入了，即使是后面有汉字什么的也没关系，只要文本中有标准ipv4地址，就会被导入（正则匹配的），前提是这个txt要utf8最好。然后就可以在第二步输入3389去这些ip的3389端口啦。

 

第二步输入端口集

可以 80

可以 80-90

可以 80,81,82

可以 80-90,100-110

也可以是端口和端口段的集合 80,81-90,100,1430-1450

 

这样第一步中输入的每一个ip都会扫描第二步中输入的每一个端口。

但是建议只在单个或几个ip下使用多端口，经典用法是扫描一个ip的1-65535，看看开放了哪些端口。

但是如果第一步ip很多，你第二步端口也多个的话，这样结果就混杂在了一起，很不容易分辨啊，你可以试试，所以说大量ip还是单扫一个端口为好。

 

第三步阻塞

有人说你这个扫描器不如哪个哪个快，我大笑，这人不懂，syn扫描程序想让他快太容易了，难的是怎么让他慢下来，因为网络设备处理能力远低于cpu制造syn封包的速度。

即使在人人百兆带宽的南朝鲜服务器肉鸡上，都没法敞开了去扫，表面看每秒几万，那是程序！那是cpu制造的个数！cpu制造出来封包但网络设备发不出去都给丢弃了，把网关给堵了，给炸掉线了，有毛用？

记住一点，当你在用syn扫描时，等于别人在对你的网关进行synflood攻击。

发送速度多少才是合理的？

比如网关每秒可以发送100个syn接受100个，那么syn发送速度每秒95个最好！以此推论。

 

还有就是不要以为同样是100兆带宽，为什么这个就可以很快的扫，那个就没结果？

还是网络设备！如果这个电脑虽然是100兆带宽，但是他的网关是个家用小路由器，那么他带宽就算1G你都不能扫，因为小路由器处理不过来，你随便一扫就把他路由器给搞死机了。（路由器往往等于arm处理器+linux的小计算机）

只有他网关的网络设备能够处理大量syn封包才行。

 

阻塞值就是为这个来的，目的就是在大量没法无限制的发送syn封包扫描的情况下，通过降低发送速度来进而把本来不可以syn扫描的环境变成可以syn扫描。

阻塞设多少合适这个完全没法由程序来判断，因为即使在pc上好多时候你都不知道给你提供网络连接的是什么设备。比如在南朝鲜肉鸡上，网关是什么设备？如果是192.168.0.1或者192.168.1.1这种，几乎确定是个小路由器，一般都是南朝鲜国产iptime牌的，可以ie直接192.168.0.1，他们一般都不设密码可以进去改。如果网关是个公网ip，那是什么设备？不知道，只知道肯定是个交换机或者路由器。

所以就得手动实验。如何确定？

举个例子，一台机器，我用他扫整个南朝鲜ip段的1433，第一次阻塞我设的10，扫描后得到了6万结果。

第二次还扫这个段1433，阻塞值我设的20，得到11万结果。第三次还扫这个段1433，阻塞我设的30，得到了12万左右。

那么就可以确定30保守了，因为用30和20的结果基本一样，发送速度低于了网络设备处理速度，需要加速。

而10就属于发送过快，网络设备发不出、收不到一些封包，所以得到结果少，你可以试试用5得到的结果会更少甚至直接扎掉线。

最后这样试验了几次，发现这个机器和网络环境阻塞用22比较合适，因为低于22结果少，高于22的话扫描结果和22几乎一样但是扫描速度慢。

于是找到了22这个速度和结果的平衡点，那么以后在扫描的话不用考虑一律输入22就对了。

总之阻塞越大，扫描越慢，扫描结果越多越准确。

反之阻塞越小，扫描越快，扫描结果越少，越会漏掉。

但是话说回来了，瘦死的骆驼比马大，syn扫描即使再慢也比tcp快，我还做了一个tcpscanner进行标准tcp扫描，并且模拟半连接加入连接超时优化到最优啦，同样是扫整个南朝鲜1433，直接开1024线程，结果好几天才扫完，但是syn我把阻塞设到了36，也不过6、7个小时就完了。所以说能syn的还是要syn，tcp怎么折腾都是没法扫巨量的。

顺便说下南朝鲜ip总共有IP地址：112258818个，这是2012年11月10日纯真ip库的结果。

纯真ip合并程序请看此贴 http://blog.csdn.net/laotse/article/details/24787719 

现在大家知道阻塞和降速的意义了，但是为什么我说难就难在如何降速呢。

这就是劳什子的windows不是实时系统计时器不精确的问题了

比如说System.Threading.Thread.Sleep(1);意思就是线程休息1毫秒对吧。不对！他休息了15毫秒。windows计时器精度底线就是15毫秒。这样通过计时器每隔一段时间发送一个syn的想法就不能用了，因为这样最快15毫秒才能发一个，一秒才发66个，这种速度是绝对不能接受的。15毫秒这个界限直到我现在用的win8.1 x64依然如此，你可以试试，无论.net哪个timer都这样，因为win api就这样。

Thread.Sleep(new TimeSpan(9999)); 0.9999毫秒，不起作用，相当于没这句

Thread.Sleep(new TimeSpan(10000)); 整1毫秒，按15毫秒来。

就差一个timespan，结果就是天壤之别。

这个问题是操作系统决定的，没法逾越。

于是就只有靠歪门邪道来降低处理速度了，那就是加入空循环，让cpu进行大量无效运算拖慢cpu，于是cpu处理发送syn就变慢了，发送速度就降下来了，但是这样致使cpu一个核一直100%，所以说syn扫描想快容易想慢难，在windows下想快于15毫秒貌似也只能用这种野蛮的方式了，他们也都是这么做的。