ITKeyword,专注技术干货聚合推荐

注册 | 登录

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

laotse 分享于

2021腾讯云限时秒杀,爆款1核2G云服务器298元/3年!(领取2860元代金券),
地址https://cloud.tencent.com/act/cps/redirect?redirect=1062

2021阿里云最低价产品入口+领取代金券(老用户3折起),
入口地址https://www.aliyun.com/minisite/goods

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毫秒貌似也只能用这种野蛮的方式了,他们也都是这么做的。

      

AssemblyFileVersion:1.9.0.0 2014年5月19日更新1.9.0.0版http://download.csdn.net/detail/laotse/7369863 修正了因多网卡、多虚拟网卡、同网卡绑定多ip、网关等复杂网络结构导致无法使用winpc

相关阅读排行


相关内容推荐

最新文章

×

×

请激活账号

为了能正常使用评论、编辑功能及以后陆续为用户提供的其他产品,请激活账号。

您的注册邮箱: 修改

重新发送激活邮件 进入我的邮箱

如果您没有收到激活邮件,请注意检查垃圾箱。