白山新闻 （ http://www.yzwxfrp.com ）：usdt套利（www.caibao.it）：剧本小子修养之开发漫衍式扫描工具(一)

USDT自动充值API接口

菜宝钱包（caibao.it）是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台、usdt跑分平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。

剧本小子修养之开发漫衍式扫描工具(一)

0x0 前言

  平时自己都是用单机扫描，然后由于自己结业设计也是基于漫衍式的，以是这次计划先从基本的功效-目录扫描最先着手，将漫衍式手艺应用上去。这里简朴纪录下，像我这种剧本小子，是若何通过一步步学习，开发出自己心仪的工具，成为一名及格的script kid。

0x1 巨人的肩膀

作为一个菜到自闭的剧本小子，先学会模拟，首先就需要参考优异的扫描器设计:

目录扫描:

dirsearch

漫衍式可以参考:

Watchdog

rengine

w11scan

0x2 剖析dirsearch

0x2.1 前期准备

通过查看文档先容，这个工具有几个Features可以关注下的:

• 多线程的实现
• 从IP局限枚举目的(CIDR)
• 处置code!=404的错误页面
• 壮大的Fuzz路径组合功效
• 支持HTTP and Socks署理
• 厚实的响应代码检测
• 厚实的Response过滤规则
• 镇静模式和Debug模式的实现

先正常安装:

git clone https://github.com/maurosoria/dirsearch.git
cd dirsearch

然后用VS code来举行调试(第一次用VS Code):

Python debug configurations in Visual Studio Code

VS Code快捷键:

• F9 符号断点

• F5 暂停/继续

• F11单步骤试

• Shift F11 单步跳出

• Ctrl Shift F5 重启

相关的launch.json

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: 当前文件",
            "type": "python",
            "request": "launch",
            "stopOnEntry": false,
            "program": "${file}",
            "console": "integratedTerminal",
            "args": [
                "-u","http://127.0.0.1/",
                "-e", "php"
            ]
        }
    ]

0x2.2 执行流程剖析

首先是实例Program工具:

入口做了一下3件事

1.加载设置文件,作者重写OptionParser->ArgumentParser,剖析了预界说的参数和默认加载根目录的default.conf,接纳configparser库来剖析

这里有个我想要知道的点，就是用ipaddress库的IPv4Network函数来剖析CIDR名堂的地址。

然则缺省的模式，兼容性不是很好，建议使用非严酷模式:

print(IPv4Network(test, strict=False))

这样就能削减一些贫苦。

2.美化输出, CLIOutput

3.实例Controller工具，最先正式启动程序，吸收了3个变量-根目录,参数，用于美化输出的工具,

选择跟进Controller类,这里有些很好的点可以学习:

这里用的是queue库的Queue(),义务行列，然后可以支持raw剖析好比burp请求的file，快速提取http请求需要的各项参数(作者根据http协议举行剖析的，写了个实现类raw.py)

接下来，这个点不错，就是初始化阶段先检测下，输出效果目录是否可写，实现的话就是挪用自己封装好的FileUtils工具类。

dirsearch的目录字典天生单独写了个文件lib/core/dictionary.py

dirsearch制作字典这个功效照样很壮大的，我们剖析看看。

先正常加载dirsearch/db/dicc.txt作为字典,接着最先天生目录Fuzz列表

天生的焦点的处置函数self.generate():

最终天生的目录列表被放置在self.entries列表。

继续回到Controller类:

这里有个很有意思的内存治理tips:gc.collect,用于释放适才del custom/result的内存空间

下面我们可以跟进去看下这个Requester是怎么实现区分http和https的：

parsed = urllib.parse.urlparse(url) ， urlparse库剖析出协议
...
elif parsed.scheme not in ["https", "http"]: 
...
try:
self.port = int(parsed.netloc.split(":")[1])
except IndexError:
self.port = 443 if self.protocol == "https" else 80 ， 剖析端口
except ValueError:
raise RequestException(
{"message": "Invalid port number: {0}".format(parsed.netloc.split(":")[1])}
) 
...
， Include port in Host header if it's non-standard ， 处置https 使用非443端口的情形
if (self.protocol == "https" and self.port != 443) or (
self.protocol == "http" and self.port != 80
):
self.headers["Host"]  = ":{0}".format(self.port)
...

封装好了焦点的请求工具self.requester,将其尚有天生的路径字典、线程、延时通报给Fuzzer用来初始化self.fuzzer工具。

提前封装好请求工具，利便统一设置请求参数和署理，只需要传入署理列表就行了如proxy,proxylist,

Fuzzer内里对线程做了一个最小值的判断，就是线程数目不能大于路径字典的长度，否则取路径字典长度作为线程数。(这个编程可以注重一下，可以制止内存占用太大)

前面流程主要是做了初始化各个参数和焦点工具，下面进入准备流程:

这个start函数，我们逐一剖析一下:

line 1:self.setupScanners

可以看到主要是组织了一些路径传入Scanner，返回一个工具，我们查看下Scanner使用这些路径做了什么。

这些路径就是:

url  basepath   随机字符串
url  basepath   随机字符串   .
url  basepath   随机字符串   传入的后缀1
url  basepath   随机字符串   传入的后缀2

line2:self.setupThreads()

可以看到主要的事情函数是thread_proc,他通过自写线程平安next函数去取内容，然后丢进scan去请求。

可以看到这里会在scan的时刻举行，获取之前随机字符串封装起来Scanner，然后举行相似度的判断，

知足的话，且status_code 不为404的话，就会放进去matchCallbacks，后面就是输出讲述了。

0x2.3 设计头脑剖析

浏览整体的项目结构:

>:tree -L 3 -c

├── CHANGELOG.md
├── CONTRIBUTORS.md
├── Dockerfile
├── README.md
├── db
│   ├── 400_blacklist.txt
│   ├── 403_blacklist.txt
│   ├── 500_blacklist.txt
│   ├── dicc.txt
│   └── user-agents.txt
├── default.conf
├── dirsearch.py
├── lib
│   ├── __init__.py
│   ├── __pycache__
│   │   ├── __init__.cpython-37.pyc
│   │   └── __init__.cpython-39.pyc
│   ├── connection //详细请求的优化
│   │   ├── __init__.py
│   │   ├── __pycache__
│   │   ├── request_exception.py
│   │   ├── requester.py
│   │   └── response.py
│   ├── controller
│   │   ├── __init__.py
│   │   ├── __pycache__
│   │   ├── banner.txt
│   │   └── controller.py
│   ├── core //这个是真正的焦点
│   │   ├── __init__.py
│   │   ├── __pycache__
│   │   ├── argument_parser.py
│   │   ├── dictionary.py
│   │   ├── fuzzer.py
│   │   ├── path.py
│   │   ├── raw.py
│   │   ├── report_manager.py
│   │   └── scanner.py
│   ├── output //输出美化
│   │   ├── __init__.py
│   │   ├── __pycache__
│   │   ├── cli_output.py
│   │   └── print_output.py
│   ├── reports //输出差异类型的库
│   │   ├── __init__.py
│   │   ├── __pycache__
│   │   ├── base_report.py
│   │   ├── csv_report.py
│   │   ├── json_report.py
│   │   ├── markdown_report.py
│   │   ├── plain_text_report.py
│   │   ├── simple_report.py
│   │   └── xml_report.py
│   └── utils //工具类的库
│       ├── __init__.py
│       ├── __pycache__
│       ├── default_config_parser.py
│       ├── file_utils.py
│       ├── random_utils.py
│       └── terminal_size.py
├── logs
│   ├── DO_NOT_DELETE_THIS_FOLDER.txt
│   ├── errors-21-03-02_16-22-46.log
│   └── errors-21-03-02_16-23-01.log
├── reports
│   ├── 127.0.0.1
│   │   ├── _21-03-02_16-22-46.txt
│   │   └── _21-03-02_16-23-01.txt
│   └── DO_NOT_DELETE_THIS_FOLDER.txt
├── requirements.txt
└── thirdparty //第三方库

整个项目划分为了5个文件夹:

• 1.db文件夹，存放路径和黑名单的列表

• 2.lib文件夹，作为library作用的存在，存放项目运行的主要的代码

  (1) 子Connection文件夹

  • Requester.py:为每一个目的分配一个Requester工具，利便设置种种用于请求的参数、(cookie, useragent...)、重试频率的实现、可以通过ip或者域名的方式去确立底层的tcp毗邻(通过重写url，host->ip,给requests.get()),请求的类方式是request，真正后端请求引用的是成熟的requests库来发包。

  • Response.py:

    这个头脑也很棒，基于

    self.status = status
        self.reason = reason
        self.headers = headers
        self.body = body

    这四个参数，然后封装了基础方式，__hash__,获取redirect之类的,利便其他挪用。

  (2)子Controller文件夹

  • banner.txt:logo标志

  • controller.py: 组织函数初始化设置种种请求参数，为目的初始化requester工具、

    Fuzzer工具(主要是通报requester工具、爆破字典、效果匹配字典作为参数来实例化fuzzer工具)、后面就是挪用fuzzer.start()去执行扫描。这个文件立马许多函数的作用都是对程序起一个整体控制的作用，好比整体暂停、整体执行，然后内里就有一些为整体控制提供的一些函数来利便挪用。

  (3)子core文件夹:

  • argument_parser.py: 吸收和磨练输入的参数,先剖析default.conf设置文件，然后后面在剖析下令行参数，写的对照细腻，用了OptionGroup将参数举行分类,值得学习。

    1.mandatory 强制性需要传输的参数

    2.dictionary 路径字典的设置

    3.general 通例的参数，用于调控请求

    4.request http请求需要设置的参数

    5.connection 主要是对request更深条理的参数自界说

  • dictionary.py： 这个焦点就是generate 函数，就是实现种种规则天生字典，然则这里也有一些对照有意思的函数，通过使用thread.lock实现了线程平安的可以凭证索引来取值的列表的nextWithIndex函数，要是换做我来写的话，我可能接纳queue来做，然则这样很不利便，好比我想reset，我只需要直接让self.currentIndex=0就行了,后面设计进度条也很利便。

  • fuzzer.py: 焦点是start函数,首先就是self.setupScanners()用于后面比对错误页面(着实蛮细腻的，就是每种请求名堂都市有一个scanner，好比.xxx xxx xxx/ xxx.php都市凭证请求的名堂差异天生差其余scanner来削减误报)，接着就是setupThreads分配好自界说的线程个数，启动线程，焦点work函数thread_proc, 通过threading.Event来统一调控(self.play()设置event为True,让多个线程同时启动，而不是像以前那样for循环来举行start，显得很有序)，同时也利便实现统计线程数目，

  • path.py: 存储路径的请求状态和返回内容

  • raw.py: 从原生的raw http协议包提取各个参数出来用来初始化请求

  • report_manager.py: 输出讲述治理类，主要是利便挪用多种输稀奇式，做了一层治理作用的封装去调剂种种类型的讲述类。

  • scanner.py: 焦点就是凭证相似度识别不存在页面的实现，其中引入了sqlmap的一个DynamicContentParser方式，这种引入第三方库的头脑是值得学习的。

  （4）子output文件夹

  • cli_output.py、print_output.py: 镇静模式用print，非镇静模式就用cli，我看了下两者的区别就是, print模式将许多cli模式的函数内容替换为了pass，只保留了最基础的乐成的路径的输出信息。

  (5)子reports文件夹:

  • base_report.py: 作为一个基类的存在，声明和实现了一些方式，在确立保留的目录的时刻思量了window和linux的区别。
  • plain_text_report.py: 焦点是generate函数，组合了输出效果成字符串，这种输出蛮有意思的，不停flush缓冲区的内容，确保内容写入到文件，不会泛起由于内存中止导致数据丢失。

  (6)子utils文件夹:

  • file_utils.py:封装了os.path的文件操作类
  • random_utils.py:天生随机字符串
  • terminal_size: 主要作用是在终端实现window和linux的兼容，美化输出。

0x2.4 学习讲述输出的实现

上面执行流程剖析没有详细剖析讲述输出，是由于我以为这个点可以拎出来学习一下。

dirsearch实现的是动态保留效果,就算突然中止了也会保留之前的扫描效果。

我那时在写MorePing的时刻，为了实现这个效果:

程序执行就多开了个讲述的线程，然后主函数扫描完成将效果存入到result_queue,然后讲述的线程一直在执行，用一个不优雅的变量充当信号量，去获取result_queue的值,程序暂停时,信号量被重置为0,线程就退出了。

然则当我看完dirsearch的实现，我发现dirsearch的设计更精练:

这个功效指向点:在多线程的主事情函数(就是焦点的函数，去请求url然后获取效果的thread_proc)中的当发现存在知足matchCallbacks的路径时就会举行讲述的存储。

这里先用addPath将扫描效果存起来,然后挪用了save去保留。

这里就很有意思,可以看到这里的outputs列表着实就是

默认的话就是plain_text_report,

挪用storeData方式将这些存入了一个pathList列内外(这里作者没线程平安的错误，保证了执行addPath是线程平安的)。

然后挪用Save的话,主要是进去了self.generate()函数,举行了效果的输出

可以看到dirsearch是将扫描出来的路径逐一加入到pathList,然后每次扫描出新的效果的时刻，再重新凭证pathList重新组织新的讲述输出内容，然后在用seek(0)来控制文件指针整体笼罩写入新文件(这样可以制止重复打开文件和关闭文件,比用with open上下文治理来说是有优势的)，来实现动态存储输出效果

0x3剖析Watchdog

下载地址:Watchdog

,

Usdt第三方支付接口

菜宝钱包（www.caibao.it）是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台、usdt跑分平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。

,

根据作者的思绪，部署漫衍式的步骤是:

主节点部署:web 数据库

子节点通过修改:

database.py 中的

engine = create_engine('postgresql://postgres:687fb677c784ce2a0b273263bfe778be@127.0.0.1/src')

为主节点的数据库,然后划分在各个子节点，运行client目录下的xxx_run.py剧本:

client
├── __init__.py
├── database.py
├── portscan
│   ├── NmapScan.py
│   ├── ShodanScan.py
│   ├── __init__.py
│   └── portscan_run.py //这个启动是端口扫描
├── subdomain
│   ├── __init__.py
│   └── oneforall //这个是
├── urlscan
│   ├── __init__.py
│   ├── url_probe
│   └── xray
└── webinfo
    ├── __init__.py
    ├── ipdata.ipdb
    ├── run.py
    └── wafw00f

不难发现,各个剧本都是用While True:来实现持久运行,这里挑选两个模块来剖析一下。

0x3.1 端口扫描模块

def main():
    print('[ ]端口扫描启动')
    while True:
            ，从数据库获取资产
        assets_sql = ReadAssets()
        if not assets_sql:
            time.sleep(30)
        else:
        ， 传入资产的ip值给PortScan
            portscan = PortScan(assets_sql.asset_ip)
            ， 执行
            port_dict, vulns_list = portscan.run()
            if port_dict:
                    ， 写入效果到数据库
                WritePosts(port_dict, assets_sql)

(1)获取待扫描的资产信息:

(2)将IP传入PortScan,初始化，然后执行Run

这个功效代码实现的很粗拙,就是通过shodan获取到开放的端口,然后在挪用Nmap去扫描获取服务指纹。

(3)提交数据库部门:

没什么好讲的。

0x3.2 Xray扫描模块

(1) main 部门:

首先用一个子线程启动了web_main,主要作用是开了个webhook的API用来将xray的效果写入到数据库。

@app.route('/webhook', methods=['POST'])
def xray_webhook():

接着下面同样开了一个子线程xray_main启动xray扫描器,

效果传送到前面的webhookAPI,开了个子历程去运行xray。

(3)启动crawlergo_main爬虫部门:

这里作者用了历程池(emm,感受用的杂乱),不外这里还判断了下Xray的行列巨细来决议是否启动爬虫,来折中由于爬虫大量写入xray的行列的问题，不外这种控制照样不够细腻的,为了code的利便，这样写无可厚非。

这里作者将爬虫返回的新的子域名列表又重新添加到了资产中,而且在写入的数据库的时刻做了去重判断。

0x3.3 简朴剖析

不难看出来,该系统实现的漫衍式的细粒度就是: (差异目的,多个扫描模块, 多个扫描模块去扫描差异目的)

瑕玷:

接纳postgresql作为后端数据库，缺乏高性能，整个系统的读写和写入次数与细粒度的庞漂亮是同级其余,

缺乏调剂系统，完全就是竞争模式去抢占目的，内讧水平对照高(容易导致数据库毗邻数过多数据丢失等情形)，缺乏高可用性，系统整体应该是低效、杂乱的。

PS.笔者没有搭建去测试，静态剖析的代码，推测的效果

尚有代码复用水平有点低, emm, 代码气概蛮萌新的,着实可以还可以继续封装一下。

缺乏节点管控模块, 缺乏异常的详细处置...

...

优点:

作为一款即兴开发的非专业程序员，通过对照暴力的方式联动了多个扫描工具，同时具备优越的界面效果和一定的可用性的"漫衍式"扫描器来说，Watchdog可以说是知足基本要求的,同时一款新生项目是不停生长的，需要给作者时间去逐步改善，造福我们白嫖党ing。

0x4 剖析w11scan

0x4.1 简朴先容

凭证作者的安装文档和形貌,应用到了celery漫衍式框架,然后数据缓冲接纳了redis,数据存储使用了mongodb数据库。

这个架构我是以为很不错的，系统的主要义务是识别给定url的指纹，以是焦点功效部门作者的代码量是对照少的，系统的亮点应该是漫衍式的处置部门, 即celery的使用部门可以值得我们去学习，(PS.前端也很心旷神怡呀，够精练，够有趣)

先看下整体目录结构:

├── Dockerfile
├── LICENSE
├── README.md
├── __init__.py
├── app
├── backup
├── celery_config.py
├── cms
├── config.py
├── dockerconf
├── docs
├── manage.py
├── requirements.txt
├── static
├── templates
├── test.py
├── whatcms.py
└── xun

0x4.2 剖析流程

下面的剖析流程,我并没有去调试代码,而是凭证docker搭建好系统，凭证功效点去确定入口,然后逐步跟就行。

先看下启动该系统时发生的历程:

可以看到划分启动了redis和mogond数据库,然后启动了许多whatcms的celery的work历程

感受这种启动子历程方式不是很优雅,我可能会思量用supervisord来举行worker历程的治理

这里是新建一个义务,我们抓包剖析出静态代码所对应的地方。

w11scan/app/views.py 163行

将义务插入到数据库,后台着实在事情的,主要是上面的一条语句挪用子worker节点来事情:

from cms.tasks import buildPayload
...
buildPayload.delay(item, str(insertid))

worker部门如下:

可以看到导入了cms.tasks模块,cms/tasks.py,装饰器有三个函数otherscan、buildPayload、singscan:

可以看到流程就是:前端提交义务->挪用work执行buildPayload->组织指纹规则fuzz请求->输出效果到mongodb数据库。

这里作者有个有意思的地方,就是用了redis来作为缓存存储了url的状态

这样的利益是,若是是相同目的的话,这样不会举行重复的同时扫描(保证即时性)

然则等整个状态扫描完成时，redis会删除这个标志，以是可以再次扫描(可用即时性)

0x4.3 简析优瑕玷

不足:

1.虚伪的节点行使率(这让我怎么抄作业? 剧本小子第一个不平)

2.缺乏浅易安装的节点安装功效,思量设置好mongodb的权限为只读,防止子节点控制焦点数据库，这个设计需要考量平安性。

3.celery自然支持优先级调剂,这个工具不支持,参考 https://www.coder.work/article/372059

4.义务细粒度依然是一个目的->一个worker处置->发生大量的request请求,很容易被BanIP

other issue:https://github.com/w-digital-scanner/w11scan/issues

优点:

代码写的很规范, 注释也很清晰, 整体架构也简朴，让人很容易读懂整个程序，不至于泛起一些对照低级的语句(给人胶水的感受)。

没有庞大的大型结构, 异常适合新手作为入门工具去学习漫衍式。

使用了优异的celery框架, 处置了繁琐的信息交互(下发义务,竞争处置...),提高了整体的稳固性。

0x5 剖析reNgine

这个工具属于的设计头脑虽然并不少见, 然则能维护好一个类似pipe line的功效，而且提供了

官方文档:https://rengine.wiki/, 一键化，准时维护，准时更新，有自己的社区,我以为是一个乐成吃螃蟹的作品。

虽然这个工具并没有说明自己具备漫衍式能力,然则从它的设计上来看,就是接纳了celery框架来写的实现的单机漫衍式,改改就能酿成真正意义上的漫衍式了。

下面是笔者对该工具的剖析历程。

目录结构:

├── CHANGELOG.md
├── CONTRIBUTORS.md
├── Dockerfile
├── LICENSE
├── Makefile
├── README.md
├── _config.yml
├── certs
│   ├── Dockerfile
│   └── entrypoint.sh
├── config
│   └── nginx
├── dashboard
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── models.py
│   ├── templates
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── docker-compose.dev.yml
├── docker-compose.setup.yml
├── docker-compose.yml
├── docker-entrypoint.sh
├── fixtures
│   └── default_scan_engines.yaml
├── make.bat
├── manage.py
├── notification
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── forms.py
│   ├── migrations
│   ├── models.py
│   ├── static
│   ├── templates
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── reNgine
│   ├── __init__.py
│   ├── celery.py
│   ├── definitions.py
│   ├── init.py
│   ├── settings.py
│   ├── tasks.py
│   ├── urls.py
│   ├── validators.py
│   └── wsgi.py
├── requirements.txt
├── scanEngine
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── forms.py
│   ├── migrations
│   ├── models.py
│   ├── static
│   ├── templates
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── secret
├── secrets
│   └── certs
├── startScan
│   ├── __init__.py
│   ├── admin.py
│   ├── api
│   ├── apps.py
│   ├── migrations
│   ├── models.py
│   ├── static
│   ├── templates
│   ├── templatetags
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── static
│   ├── assets
│   ├── bootstrap
│   ├── custom
│   ├── img
│   └── plugins
├── staticfiles
├── targetApp
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── forms.py
│   ├── migrations
│   ├── models.py
│   ├── static
│   ├── templates
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── templates
│   └── base
└── tools
    ├── OneForAll
    ├── Sublist3r
    ├── amass
    ├── aquatone
    ├── config
    ├── default_settings.yaml
    ├── dirsearch
    ├── get_dirs.sh
    ├── get_urls.sh
    ├── massdns
    ├── scan_results
    ├── subjack_fingerprint.json
    ├── takeover.sh
    └── wordlist

这里着实目录结构不是很庞大,前端的一个大功效着实就是对应了一个文件夹。

我关注的主要是带有scan字样的文件夹。

0x5.1 剖析流程

startScan/views.py 91line:

start_scan_ui扫描最先

我们这里跟进doScan函数,这里代码很长,分块来剖析:

接着剖析yaml的设置,来加载对应的工具,挺暴力的。

好比下面这个子域名扫描模块部门中代码中挪用amass工具:

加载对应工具，让其自身输出效果文件到效果文件夹。

这个else设计导致了没设施复用之前的域名扫描效果了。

这里主要联系是凭证taskid来的而不是凭证domain来的,也就是说,你不能执行完一个task之后,在执行其他扫描，复用这个task，要么你必须一个task包罗你想要两个task完成的功效

要否则你在插入的数据库的时刻就会导致由于缺乏对应的字段导致失败的

获取子域名存储完之后,httpx读取获取到的子域名txt举行存活性判断。

接着就是截图之类的...完成了subdomain的模块,若是我们还同时选中了目录扫描模块的话。

最终扫描完成走到最后:

0x5.2 实现扫描进度

这个工具前端能够实时展示当前的扫描进度，我那时写的x7scan为了写这个进度可是折腾了良久,以是这里分出来一节,用来学习别人是怎么实现更新进度的。

凭证状态应用差其余button样式。

可以看到这里的进度的动态显示,主要就是行使

{% widthratio scan_history.scanactivity_set.all|length scan_history.scan_type.get_number_ofs_steps|add:4  100 %}

django的模本运算,扫描的效果集长度/(步骤 4) *100 获适合前的提高

scan_history.scanactivity_set.all反向查询获取scanactivity的条数

程序的话,默认会确立4个属于示意状态的Activity,这就是为什么 4。

步骤着实就是扫描器的焦点5个挪用功效点:

0x5.3 优瑕玷剖析

由于笔者对django一无所知,以是许多代码浏览不来, 整个项目的变量统一接纳蛇形名堂, 但注释对照少，笔者读起来照样异常吃力，而且这种celery的框架要是想调试也很贫苦,以是这里纰谬代码作评价。

作为一个用户的角度来简朴说说:

瑕玷:

对照显著一点就是效果不能复用，尚有就是若是同时有太多扫描(发生大量子域名)，文件读取(txt)也就是读写I/O会占用异常多的内存,系统很容易泛起溃逃的情形,尚有就是细粒度照样对照大的问题(它原本就不是漫衍式扫描工具,没需要苛求这个,然则想提高速率的话,可以自己多开一个worker docker,数目和你CPU差不多就行了)

尚有许多issue(xss破绽之类的):https://github.com/yogeshojha/rengine/issues

...

优点:

界面写的很专心,系统调低线程的话整体运行照样很稳固的,再者有人不停维护,会越来越优异的。

尚有支持yaml设置各个tools的详细参数设置,看作者写的代码,可以看出来作者写的蛮疲劳的。

...

0x6 总结与展望

  本文简朴地剖析了几款的主流工具的事情流程,明晰了工具作者的基本头脑，着实与我心目中架构的头脑照样不太一致的,稀奇是细粒度这一方面,我会针对细粒度的划分做一些性能的小测试。

保佑自己毕设在最先code之前,能够把这个小工具作为前胃菜完结吧,真的是太忙了Orz.

0x7 参考链接

Python 使用VS Code举行调试