设计

背景/Background¶

默认阅读者已对相关领域有一定了解

端口扫描器在今天也有非常多的分支了, 面向不同的用户不同的场景不同的环境.

有专注于端口开放情况的MX1014(TCP), masscan(SYN), 无法解决漏报问题或者功能太过单一
有传统的老牌全能扫描器nmap, 功能强大但最强的地方不是端口探测, 而是传输层的各种手法
有自定义传输层协议的扫描器sx, naabu, 类似go版本的nmap
以及这两年很火的各种红队向扫描器:fscan, kscan, yasso等等, 功能较多, 但缺乏打磨
内网网段探测扫描器, netspy, 功能较为单一, 需要多上传一个文件反而麻烦

还有非常多的针对各种独特领域的扫描器.

而gogo的定位则是自动化引擎, 包含网段探测, 端口探测, 指纹识别与poc验证功能.但抛弃了各种服务弱口令爆破的功能.

网段探测, 端口发现, 指纹识别与poc验证实际上是一条流水线上的工作, 逻辑上前后连续一致, 不会带来多大的性能负担.而各种服务的弱口令则引入了不一致性, 需要新增很多配置参数, 引入很多库, 引入各种各样的代码.因此, 弱口令爆破这一块, 将由独立的工具实现.

如果想深入了解gogo, 需要理解gogo面临的问题, 以及gogo的设计理念与解决方案, 也就是设计与细节两章.也许能理解到为何gogo是为红队而设计的.这个世界不需要更多的缝合怪, 我们关注的重点应该是对细节打磨与对功能的再创新.

本文将描述gogo需要解决的问题, 以及解决的方案.

取舍

gogo的设计之初是为了内网场景, 为此做出了大量的取舍与妥协.虽然现在的gogo在外网场景下也能起到不错的效果, 但并非最优的解决方案.后续将会使用其他工具/工具链提供外网场景的解决方案.

架构/Architecture¶

gogo的核心能力架构:

任务生成器(Generator). 通过多个命令行参数, 可控制gogo生成目标队列的细节. 以实现更高效率的扫描或规避防护设备。
信息收集器 (Collector). 在尽可能少发包的情况下, 收集到更多的基本信息, 并允许从目标中提取需要的数据.
指纹模块 (Finger). 通过自定义的指纹DSL实现覆盖绝大多数场景与需求的指纹识别因为.
端口插件 (Plugin). 允许编写go语言插件拓展gogo对复杂端口的探测能力.
轻量级nuclei引擎 (Poc Engine). 通过兼容大部分nuclei poc的规则继承最强大的poc社区.

设计哲学/Design Philosophy¶

gogo的定位始终是自动化引擎，而不是全能扫描器。漏洞扫描功能只是为了方便自动化，而非主要功能。

作为自动化引擎，gogo帮助人们自动完成99%的复杂工作，使人们能够将注意力集中在更有价值的事情上。

在使用gogo时，你可能会体验到其独特的设计。

设计目标¶

快：尽可能保证最大兼容性的情况下，最快速度完成任务。
可控：工具应该作为手与脑的衍生，提供丰富的参数和控制选项。
可拓展：需要可拓展的同时又要避免重复造轮子, gogo并不打算把世界上的所有poc重新实现一遍。
可处理：数据分析应该经可能的交给计算机去做, 人类并不适合做复杂数据的分析。

重要

类似工具的开发需要投入大量时间和经验来打磨细节。

实现这样的工具并不是实现功能即可, 需要大量时间与经验打磨其细节

快¶

在对一些常见的扫描器调研之后以及对编程, 网络的原理学习之后, 能直到并发扫描并非是线程数越高越好。要达到快还有很多限制条件以及对应的解决方案。

并发¶

提高线程数是最常见的解决方案，例如早期的扫描器多为单线程或者使用10到20个线程，例如御剑和一些使用Python开发的简单扫描器。尽管它们支持多线程，但对高线程数的支持不佳。原因可能是当时协程的概念还没有被广泛应用，或者是生态中没有简单的解决方案。使用系统的多线程API会带来许多额外的性能消耗，如在内核层和用户层之间切换、不断还原和保存线程堆栈、使用各种锁导致的性能损耗等等。

需要在内核层与用户层不断切换
不断还原与保存高达4M的线程堆栈
为了线程安全使用的各种锁带来的耗时 ...

以及一些我尚不知道的性能消耗, 导致多线程的应用很难进行数百甚至数千线程的并发。

在2021年的今天, Go提供了简单可靠方便的高并发解决方案, 可以在1C1G的低配VPS上实现数千个goroutine的调度。只需要使用Go关键字, 就能随意的实现数千个协程的并发, 协程的调度将由go进行, 不再需要系统调度的大量无用消耗。

当然, go的协程终归还是有栈协程, 并且协程调度也不是无损, 为了减少这个消耗, 我们可以采用复用协程池的方式尽可能地减少消耗.

网络¶

TCP拥塞控制

都学过TCP拥塞控制但是这个拥塞控制是针对每一条TCP信道自身的, 不会影响到其他TCP信道.因此只有在传输大数据的时候, 才会有性能影响.对于端口扫描这样的场景, 每条TCP信道并不会有非常多的数据交互, 因此不受TCP拥塞控制影响.但是网络拥塞会确确实实的影响到扫描准确率.这是因为刚才提到的路由器的问题, 在路由的过程中, 网络拥塞每个TTL的时间就会增加.

所以判断网络是否拥塞, 可以判断TTL耗时的变化.

路由器的Tail drop

在测试扫描的过程中, 有几次把家里的华为路由器打挂直接重启了.

后来才知道, 扫描的限制可能不来自代码, 也不来自系统, 而是路由器.如果路由器网络拥塞了, 会采用Taildrop(当网络设备的缓冲区已满时, 新到达的数据包会被丢弃)来告诉客户端的TCP拥塞了, 启用拥塞控制, 慢点发包.而如果负载再大一点, 路由器可能会直接重启.重启这种问题主要发生在家用路由器上, 企业级路由器面对几千的并发还是没有任何问题的.

TCP keep-alive

http1.1中, 实现了keep-alive, 不再需要每次http重写建立一次握手, 浪费大量资源.

因此在http端口扫描, 指纹识别, 以及打poc的过程中, 都可以利用这个keep-alive长连接.

但是对于TCP端口, 则不适用这个keep-alive, 因为某些服务, 只有第一个包正确了才会返回对应的信息, 否则要么server主动断开连接, 要么不再返回信息.所以每个TCP端口扫描都建议重新建立连接.

time-wait

time-wait状态代表着TCP连接已经关闭, 但是fd还被占用, 等待可能的后续数据处理, 防止有包迷失在网络中被污染下一个使用这个端口的fd.

如果不能正确的处理这个问题, 可能导致fd与端口资源耗尽.

系统限制¶

为了尽可能保证兼容性, gogo选择尽量不依赖第三方库。目前, gogo已经在Linux低版本内核（最低测试到2.x）、BSD、各种版本的MIPS和ARM架构以及Windows Server 2003等操作系统上进行了测试运行, 覆盖了绝大多数的使用场景。尽管有些系统没有被测试过, 但它们也很有可能兼容gogo。如需在这些系统上使用, 可以手动编译gogo并进行测试。

go.sum中可以看到有些递归的依赖, 实际上并没有调用到相关函数, 因此在编译的时候会自动跳过。

系统线程调度

Windows的线程调度性能显然不如Linux, 不只是并发控制, 还有TCP堆栈以及其他各种各样的消耗。

在使用Windows进行扫描的时候, 经常出现导致网络崩溃并且需要好几分钟才能恢复、产生大量的漏报、识别不到http协议或者只能建立TCP握手等等问题。

在Windows进行扫描遇到了非常多的问题, 最终只能降低线程数妥协Windows。

有不少人反馈Mac上也存在类似的问题, 明明内存与CPU都没有使用, 操作系统缺莫名卡顿甚至崩溃重启. 同样可能是因为内核的并发调度导致的.

最大FD限制

老版本的Linux默认的FD限制为1024, 部分新版本的Linux发行版改成了65535, 如果要修改FD限制, 需要root权限指定limits-n 65535修改.

Windows中也有类似的限制, 默认大概是5000, 需要通过注册表修改, 不幸的是Windows大部分情况根本跑不到4000网络就崩溃了。

65535最大端口数限制

每个系统可用的端口都只有65535个, 而在http扫描的时候, 部分语言存在端口占用问题。例如, go的复用连接池会默认启用keep-alive, 导致端口被长时间占用。类似的问题也存在于其他一些语言, 比如C#。

在开发过程中以上的坑几乎都踩过, 并花费了一些时间去寻找合适的解决办法, 并最终将其武器化/自动化积累在gogo之中。

可控¶

gogo几乎将一个阶段的逻辑, 每个细节的控制都封装成了一个一个命令行参数, 这也是gogo存在一定入门门槛的原因。

当然, 绝大多数情况下, 用不到这些复杂的参数, 但在需要的时候, 你一定能从gogo中找到解决办法。同时, gogo也提供了便捷的workflow, 将一些常用的参数组合封装为了workflow, 仅需要一个参数即可调用复杂的扫描逻辑。

这种一切流程与细节可控的设计, 也是我认为的工件化核心。工件可以设计的很复杂, 因为在我们的工作完成后, 去组合这些参数的并不是人, 而是一个自动化/半自动化引擎。我们既不想把所有的代码都写到引擎内部, 理论上也不能实现这一点, 又需要让引擎充分去控制每个细节。那只能在工件的设计上下文章.将一切可能发生的情况都变成一个个命令行参数。

如果做不到这一点, 就算写出了一个一把梭工具, 实际上也只是浮于表面的好用, 既无法迭代, 也无法判断是否为工具导致的问题。因为工具一旦产生漏报, 对人类来说, 这个信息是不存在, 而非错误, 无法进行Debug。

而实现了可控的工具, 我们才能将其称之为工件。它只是把锤子, 但能锤一切样子的钉子。

可拓展¶

为了满足可拓展性, xray采用了强依赖go-cel解释器编写poc, 导致poc很难移植, 因此放弃了xray的poc。部分python poc框架, 例如pocsuite则是直接采用python编写代码, 更难迁移到其他平台。goby提供了一个图形化的poc生成工具, 方便了不少, 不过并不开源。

因此最终poc上选择了兼容nuclei, 好在nuclei的社区是目前最活跃的漏洞分享社区, 囊括了绝大部分可能用得到的漏洞。

gogo也在尽可能在其他地方追求可拓展性。目前可通过配置文件拓展的功能有很多, 可见拓展编写

而为了在实战中快速迭代并投入使用, gogo以yaml配置作为低代码解决方案, gogo绝大部分能力都来自templates仓库中各种配置文件。

gogo以去代码化拓展的解决方案实现在实战中开发, 在实战中成长, 在实战中迭代的理想目标。

可处理¶

gogo保存到文件的格式默认采用了JSON的格式化保存, 并在JSON上做了一层deflate压缩。JSON原本并不是一个允许流式传输的格式, 所以gogo也做了一些特殊的优化, 以做到结果的实时输出(满4k输出一次), 并实时查看扫描进度(任务没完成也可以-F, 会尝试自动修复dat)。

为了应对可能出现的各种奇怪的场景, 在使用gogo时, 可能需要来回多次对gogo的扫描结果再次扫描, 或者导入到其他工具中。gogo提供了一个强大的输出/输出逻辑, 可以自由的控制输入与输出的格式, 并导出为合适的格式给其他工具或者辅助人工进行数据的二次分析。

将gogo落地的场景非常多, 为了应对这些复杂的场景, gogo也设计了一套并不简单的解决方案, 输入与输出都需要通过大量参数控制其结果。

不过一旦熟悉了gogo的输出与输出控制, 能节省很多数据来回上传下载的时间。

大部分情况下, gogo都推荐保存.dat文件.在workflow中也都设置了自动保存到dat。推荐这么做的理由如下：

防止命令行窗口被关掉, 扫描记录丢失
Webshell场景下不一定能拿到实时的输出
保存的文件是可以被后续的扫描复用的
支持--hf生成带有迷惑性质的文件名, 对于不熟悉该工具的人, 这样的二进制内容并有伪装性质的输出格式也许能起到一些伪装作用。

也正是考虑到gogo落地到不同的场景, 做出了一些妥协, 比如, 默认情况下输出无着色器、存在.sock.lock在无交互式的情况下确认进度、默认输出文件是通过deflate流式压缩的等等。

其他¶

除了上面的开发原则, gogo还有一些特殊的设计与优化。

去依赖

gogo通过几个月时间尽可能去掉了能去掉的依赖。

这是gogo目前所有的依赖

github.com/M09ic/go-ntlmsspv1.2.10-0.20221207030820-de2792a93fef
github.com/chainreactors/filesv0.2.4
github.com/chainreactors/ipcsv0.0.9
github.com/chainreactors/logsv0.6.1
github.com/chainreactors/parsersv0.2.9-0.20221210155102-cc0814762410
github.com/jessevdk/go-flagsv1.5.0
github.com/panjf2000/ants/v2v2.5.0
sigs.k8s.io/yamlv1.3.0

go-ntlmssp是我修改后的版本, 降低对版本的需求, 修复了一些bug, 不依赖任何第三方仓库。

go-flags这个库只依赖go自身的sys, 不会引入额外的依赖。

ants用作协程池复用与控制, 依赖也比较少, 并且因为没用到这个库的高级功能, 它的依赖在编译时会被自动去掉。

chainreactors的几个仓库则是一些需要复用的通用代码, 基本上只使用原生的go重写了大部分需要导入第三方库的功能。引入了少数的几个库也经过文件大小, 兼容性的评估。

yaml库只在go generate时生效, 实际上打包编译时不会编译到二进制文件中.

目前对gogo体积影响top10的包(当然实际体积不是这些包相加, go的编译优化本身也能进行压缩)：

8.2 MB runtime
6.9 MB net/http
2.9 MB reflect
2.9 MB crypto/tls
2.5 MB net
1.7 MB syscall
1.7 MB math/big
1.4 MB github.com/jessevdk/go-flags
1.3 MB crypto/x509
1.1 MB encoding/json

除了go-flags可以再进行优化, 其他基本都已经到理论极限。

目前去掉调试信息与符号表之后编译出来的体积约5M, 通过upx压缩后在2M左右。是目前同类工具的最小状态, 也是在没有黑魔法情况下的极限了。

正是通过这些优化, gogo对操作系统没有任何兼容性问题, 我遇到过最低的windows2000以及一些超低版本的Linux, 甚至银行内部的sun/bsd之类的超老机器上也能正常运行gogo, 在这些系统上保证了全量的功能。

对系统的占用

gogo的内存消耗主要来自goroutine自身的栈, 已经尝试通过复用goroutine减少这个开销。通过几个版本的针对性优化, 基本能在超低性能的机器(1C 512M内存跑4000并发)上正常运行.

在64位的机器上, gogo每多1000个并发, 多占用约50M内存, 并通过生成器以及实时的数据同步配上go本身的垃圾回收, 不会随着目标数量增加以及运行时间导致内存的无限线性增长。这也是gogo能让扫描A段成为可能的核心原因之一。

gogo对CPU的性能消耗并不小, 但也远远优于同类工具。在云上单核机器上测试, nmap 100个thread就能将CPU长时间占满, 其他的go写的同类工具性能表现略好于nmap。gogo大概会在5-20%之间波动, 偶尔会超过50%。后续将会有几个版本专门针对CPU性能进行优化。

免杀

很长一段时期, gogo因为内部使用, 可以无视所有杀软。但在长时期的对抗中, 有不少防守方捕获到了样本, 并对其进行人工或者沙箱的分析。现在已经能被卡巴斯基, Windows defender, 核晶模式下的360等杀软识别。

后续作为一个公开的工具, 也不会在免杀上做进一步的对抗, 可能需要使用者自行免杀。

一些妥协

gogo其实在历史上添加过一些功能, 但因为各种原因已经被删除：

曾经内部使用时期, gogo是有key的, 并且在输出key的时候会获取环境变量回传到云函数上。用来确认gogo被分析、被捕获的情况。也是这个办法那段时间抓了不少沙箱信息。
gogo曾经支持自动回传结果到云函数, 公开版本可能会被误认为后门, 也去掉了
gogo曾经支持--eip, 排除指定的ip扫描, 但因为这么做需要维护一个较大的hash表, 并且如果输入的--eip较大, 导致ip展开消耗较多内存而删除。但现在找到了解决办法, 后续版本会重构后添加回来。
gogo曾经支持--arp以及-parp, 通过arp协议进行启发式探测, 或者获取mac地址。但因为构造arp包需要依赖gopacket提供的rawsocket, 会在低版本操作系统上无法运行。icmp协议实际上也会发送arp包, 实际上与arp有重复, 因此去掉了arp功能。
gogo曾经能将host带到每个插件的扫描中, 但因为产生了更多的问题, 决定坚持其内网为主的定位, 仅在nucleiscan与hostscan中会带上host。

其他还有一些在漏洞识别, 指纹识别上做的妥协, 会在介绍相关功能时介绍.

Feature¶

gogo经过接近两年的实战打磨, 自认为已经在用户体验上做到了我们的最大可能。但随着功能越来越复杂, 还是有不小的学习成本。

启发式扫描¶

在nmap, masscan那个年代, 对内网的扫描很少会超过C段, 更别说A段这种在当时几乎不可能完成的任务。

现在的扫描器, 或者相关特化的工具netspy都没有很好的实现, 只停留在勉强能用的阶段。

而gogo在很早就集成了根据经验公式的递归下降去发现网段, 并且通过生成器对扫描逻辑解耦, 可以任意组合不同的扫描阶段, 例如：

想绘制一下当前入口点能通的网络拓扑(大约30分钟)
只想看看10段内网里有多个B段被使用了(大约30秒)
只想看看10网段中有多少ip存活(大约30分钟)
想扫描下10段中的资产(看前两阶段存活的资产数量, 大约1-2小时)
不仅想扫描资产, 还想识别下指纹, 探测下漏洞(基本和探测资产时间相同, 采用最小发包原则, 探测指纹与漏洞不会多耗时多少, 大约多20-30%耗时)
我想一口气把10, 172, 192内网全探测了, 并输出报告(看资产数量, 大约1-2小时)
......

当然, 这里的网段可以自定义, 不一定是10。大致可以理解为fscan与netspy的结合, 实际上会更加复杂一点。

用命令行构造这些场景较为复杂, 经过不少朋友试用吐槽后, 添加了workflow, 只需要一个参数即可覆盖绝大多数常见的使用场景.具体的使用说明见仓库中的README.md与设计文档。

便捷的端口配置¶

刚才提到的启发式扫描, 主要是在扫描逻辑上的配置, 而对于具体端口资产, gogo也提供了及其方便的端口预设。

扫描常见的http服务, -p top3或-p top2
扫描数据库-p db
使用多个预设-p top3,db,win
使用多个预设, 同时指定某个区间网段-p top3,db,win,40000-50000
...

通过name与tags的交叉管理, 能快速配置各种使用场景。

如果要添加预设, 可以在github的gogo-template中的port.yaml提交pr。

指纹识别¶

重要

gogo对于指纹识别的态度是尽可能全, 容许少量的误报. 因此部分指纹质量不高, 如果发生了大量误报欢迎提供issue.

gogo的指纹与漏洞都将完全以dsl的方式实现, 即通过yaml配置。

因为并没有找到一个完全能满足我需求的规则库与引擎。gogo重新设计了一套引擎, 而指纹库则选择整合了fofa的规则库, fingerprinthub, kscan, allin中的一部分规则, 以及大量的gogo独有的指纹。

指纹识别看起来简单, 但我们在实战中遇到了一个接一个预期外的问题。指纹识别并不是只匹配关键字就能做好的, 其中包含了大量细节。举几个例子：

某个http站, 访问会通过30x跳转, 但是跳转过去的站是个404页面(默认配置的蓝凌oa)。
某个http站, 直接访问80端口返回的是一个通过js进行跳转的页面, 这种情况指纹匹配不一定能生效。
某个http站, 一访问就会下载文件, 那个文件可能有几百M大小。

如果是非http协议的端口, 那情况就更多了。

某些服务, 建立完握手就会返回banner, 如果你发送了它无法识别的数据, 他就会resetTCP链接(SSH)。
如果对某些服务发送了他无法识别的数据, 他不会断开TCP链接, 但是不再会返回数据(MSSQL)。
某些协议有各种各样的发行版, 每个发行版的banner都不同, 并且没有明显的规律(FTP与TELNET)。

好在nmap已经解决了服务指纹的大部分问题, 只是如果直接使用nmap的指纹库, 过于庞大的指纹库会带来不必要的性能消耗。某些扫描器就直接使用nmap的指纹库, 导致指纹匹配的时间大于扫描的时间。

光是http指纹识别的特殊情况甚至超过了gogo能处理的范围, 如果加上这些功能, gogo不可避免的会变得臃肿, 因此, 部分http指纹识别的功能, 特别是主动指纹探测相关功能, 计划将移植到spray中。只在gogo中保留最基本的主动识别。在内网绝大多数情况, 漏报一两个指纹并不会影响我们的后续操作。

漏洞探测¶

重要

gogo对于漏洞探测的态度与指纹识别不同, gogo追求尽可能少的特征和与发包, 也不关注外网的一些常见漏洞(当然如果有人能整理出一个足够强大的nuclei外网poc库, 可以添加一个外网专用版的分支).

gogo重写了nuclei关于http与network两个模块的dsl引擎, 在兼容nucleiyaml大部分规则的同时, 去掉了大量不必要的功能, 并添加了一些新的功能更.详情请见拓展nucleipoc

目前gogo支持的所有漏洞: https://chainreactors.github.io/wiki/gogo/detail/#_6

比起一些项目直接调用nuclei包, gogo的这种方式去掉了所有的依赖, 并最大程度的实现了nuclei的引擎, 缺点是dsl引擎的版本将会略微落后于nuclei本体。考虑到gogo的使用场景, 这种落后并不影响功能, 因此是可以接受的代价。

绝大多数poc都可以从nuclei中移植poc, 只需要做一些简单修改与测试便可以快速加入到gogo中。不过为了保证poc质量以及内网使用场景, 加入到gogo中的漏洞需要一定的筛选。

nuclei的poc仓库是基于社区的, 这么做的好处是社区活跃poc更新非常快, 但质量上难以把握。在我深入了解使用后, 发现了nuclei-templates存在一些问题：

没有区分poc和exp。在很多yaml中, 提供完整的exp反而会导致更多的漏报与设备告警。
没有坚持最小发包原则。经常能看到用了两三个重复功能的包去判断一个包就能解决的问题。
没有做不同版本的精细适配。很多漏洞不同的版本需要的poc不同, nuclei目前没有提供对应的功能。

如果是poc, nuclei随时能解决大部分问题, 但对于exp来说, nuclei的设计完全不能解决。对于红队场景, 不少人都手握各种oa, cms的0day, 只需要做指纹识别与版本识别, 需要打poc的情况不太多, 打exp更不应该是gogo应该做的事情。

对于漏洞探测来说, gogo需要添加的poc有：

常见设备与服务的默认口令登录（与其在文档中收集设备的默认密码, 不如直接转换成poc, 自动化的帮你爆破）
常见通用组件与应用的RCE
能给红队带来帮助的信息泄露（通常作为后续攻击的前置步骤）

在gogo添加poc时, 通用漏洞与口令爆破始终位于第一优先级。现在的gogo也已经有了约50个poc, 其中包括了近20个默认口令爆破的poc。这些poc就能覆盖到超过一半的内网常见服务了。

因此, gogo的漏洞库不会是一个大而全的漏洞库, 如果有大而全的需求, 可以直接使用nuclei。

gogo想通过集成nuclei的生态, 让维护poc库省力一些, 现在基本处于有人反馈常见什么poc, 就添加对应的poc。

gogo目前完成了nuclei2.5版本的http与network两大模块, 足够能够应对99%的场景。后续gogo将会定期同步nuclei templates的新功能, 持续改进gogo关于漏扫的体验。

外网使用时的缺陷¶

gogo因为其生成器以ip与port进行生成, 可以接受域名类似的输入, 但是实际上还是会解析为ip。因此在外网时, 有些时候不能很好的完成任务。例如输入的http://baidu.com/test

将会获取其host：baidu.com, 丢弃掉端口、目录在内的其他数据。导致非根目录的数据gogo无法正确进行指纹识别。
将会把baidu.com解析到ip, 导致除了hostscan插件之外, 其他的插件扫描时不会带上host。面对cdn的场景非常无力。
如果通过-l输入了多个带域名的目标, 如果多个目标解析到同一个ip, 将连hostscan也无法正确的带上每一个host。

曾经有个版本的gogo将host应用到全局的扫描中, 但出现了更多的问题, 最终去掉了除了nucleiscan与hostscan插件以外的适配。

注意

在外网使用gogo时, 请注意可能产生的漏报。

小结¶

本文介绍了gogo在一些功能上的取舍, 设计以及创新。但实际上还有不少细节我没有一一介绍, 使用者可以在实战中慢慢体会, 也欢迎提出新的需求以及pr。

gogo没有选择成为缝合怪, 每个细节都经过漫长的反复的改动, 最终呈现出来现在的样子。受限于开发者视野的局限, 或许在很多地方还存在缺陷, 但我相信在功能上已经靠近了红队场景的极限。

具体的使用请看入门与--help。

gogo是整个计划版图中发布的第一块拼图, 也是目前最成熟的部分。祝各位用的开心!

其他工件会在整理完成后逐步开放。

gogo的使用较为复杂, 注释与单元测试这方面将会在未来补上.如果有不清晰的用法, 可以在issue中提出, 看到后会及时回复.

未来展望¶

集成到自动化外网信息收集工具, 与图数据库相结合(已经做了一部分)
自动收集结果, 以可视化报告的形式呈现(已经做了一部分)
与webshell, c2工具联动, 实现图形化一键使用(已经做了一部分)
与maitai(暂未公开的代理工具)联动, 实现gogo流量的高性能转发
内网分布式部署, 多点同时扫描
agent化, 特殊网络环境下, 可以只上传tinyagent(通过maitai实现, todo)