简介面向CTF AWD攻防对抗比赛选手的一份实战工具合集内容紧扣比赛项目源码与常见攻防场景既适合刚接触AWD的新手熟悉工具链也适合参赛战队快速搭建一套可用的防守与审计环境。包体共52个文件压缩后约11.89MB主要文件类型包括PHP脚本、Python自动化脚本、DLL防护扩展、Web日志安全分析exe、JS/CSS前端组件、Shell部署脚本及说明文档等内含多个可独立运行的PHP与Python模块能够应对AWD赛场上高频出现的文件篡改、WebShell查杀、日志溯源等需求基本覆盖文件监控、流量与日志审计、漏洞利用链排查、Flag自动提交等环节。整套资源以CTF-AWD项目目录组织附带README、配置模板和规则文件便于按模块查阅和二次修改。目前已有507人学习适合希望借助现成工具减少备赛工作量、快速理解AWD常见防守打法的入门至中级选手。1. AWD开局后拼的是手速工具收集就是你的备战清单AWDAttack With Defense是CTF里最见血的一种赛制每支队伍守着自己的靶机同时要打别人的机器。比分实时跳动开局前30分钟里你既要完成备份、加固、换口令又要盯流量、准备利用脚本。这时候手边要是缺了趁手的工具再好的思路也变不成分数。很多第一次参加AWD的新手不是输在技术上而是输在比赛开始后还在满网找工具。下面把我自己整理、验证和使用工具包的完整过程拆开讲包含工具清单、整理步骤、比赛中的用法以及五个我踩过的坑希望能帮你把工具收集从一次下载变成一套能反复使用的工作流。2. 收集前先懂规则AWD比赛到底需要哪些工具2.1 AWD和解题型CTF的区别攻防对抗与实时计分要理解为什么需要专门收集一套AWD工具先得看清AWD和普通解题型CTF的本质区别。普通CTF给你一道静态题目你拿到附件、源码或一个网址分析漏洞、构造payload、拿到flag整个过程没有人和你对抗。工具使用节奏完全由自己掌控缺了什么可以慢慢查、慢慢装。AWD完全不是这个节奏。比赛开始时每支队伍被下发一套几乎相同的Web应用服务对外开放同时裁判会定期对每台靶机做可用性检查。你既要保证自己的服务一直活着又要利用同一套代码里的漏洞去打别人。更麻烦的是你的对手也在用同样的方式研究你扫描你开放的端口、试探你的上传点、尝试登录你的后台。比分每几分钟刷新一次服务宕机扣分被打穿丢flag扣分只有提交对手的flag才能加回来。这意味着工具包的时间属性非常重要。解题型CTF里你可以在比赛途中临时下载一个工具慢慢研究用法AWD里开局后每一分钟都在计分现找工具等于送分。所以工具收集必须在赛前完成而且必须是一种「拿起来就能跑」的状态不是下载完丢在桌面上就算收集完毕。另一个区别是工具的使用目标。解题型CTF的工具往往围绕「分析」逆向、密码学、隐写、流量分析目标是搞懂一道题。AWD工具的核心是「对抗」加固、监控、权限维持、批量捞flag。分析类工具当然也用但它们的服务对象是在攻击发生之后快速搞清楚对方打进来用了哪条路然后回手打回去。这也是为什么很多体积庞大的CTF通用工具包在AWD里并不好用——里面塞满了逆向题和密码学题的单次性脚本真正需要的那几个命令反而被淹没了。2.2 四大工具模块加固、监控、利用、编码解码根据我自己多次比赛的经验一个称得上完整的AWD工具包应该有四个并列模块按使用环节划分而不是按工具类型划分。第一个模块是加固与防护。比赛下发代码后第一时间要做的事是修掉已知的弱配置。比如把数据库和SSH的默认口令换掉、把危险函数禁用、把上传目录的写入权限收紧、把安装包和临时文件清干净。这些操作可以用一条条命令手动执行但更可取的做法是准备一个加固脚本把常见风险批量处理掉。很多工具包里已经有同类脚本但收集回来后一定要自己读一遍确认它改了什么配置再上机器执行。第二个模块是监控。AWD里你不可能挡住所有攻击但至少要记录攻击者是怎么打进来的。监控包括文件完整性检查、流量抓取、日志实时追踪。常见的做法是开赛后立刻用tcpdump抓包同时用脚本定时对比关键文件hash。这样一旦发现被改了文件能顺着流量和日志倒推攻击路径。第三个模块是漏洞利用。这是拿分的核心包括通用Web漏洞的验证脚本、一句话木马生成器、反弹shell工具、密码爆破命令集合。AWD的Web应用通常是经典漏洞组合SQL注入、命令执行、文件上传、反序列化、弱口令。工具包里要有针对这些漏洞的最小可用利用脚本最好是自己赛前写好的格式统一、依赖干净。第四个模块是编码解码。实战中拿到一个可疑字符串是base64还是hexflag常见格式是flag{...}但中间内容可能被各种方式编码。随波逐流这类CTF编码工具覆盖面广适合当兜底但如果比赛环境网络受限最好准备一个离线可跑的转换脚本集覆盖base64、hex、URL编码、md5识别这几类最常见的需求。另外杂项小工具也值得放几个进去端口扫描、目录扫描、HTTP请求构造、正则提取。它们不直接得分但能让整个攻防链路更顺。2.3 收集优先级的判断按环节排需求按需求定工具在正式动手收集前先画一条时间线开局前30分钟需要什么比赛中段需要什么僵持阶段又需要什么。开局前30分钟需求高度集中在备份和加固上。你需要一个能快速打包源码、导出数据库的脚本一套能修改口令、收紧权限的加固命令以及一个流量监控的启动命令。这一阶段没有攻击动作所有工作都在自己的靶机上完成。比赛进入中段需求转向攻击和捞分。你需要SQL注入的payload模板、命令执行的可写路径探测脚本、文件上传绕过手法对应的验证命令以及一个能批量提取flag并提交的平台交互脚本。这个阶段效率为王工具能不能用、命令是否简短直接影响你能抢到多少个flag。僵持阶段和后期需求转向对抗复盘。当攻击屡屡碰壁时你需要分析流量日志找对方的漏洞利用方式当你的服务开始报错时你需要快速定位是被谁用哪个洞打穿的。这时候流量分析工具和日志检索命令比什么都重要。按这个时间线去安排收集优先级结论很清楚备份和监控类脚本优先级最高因为它们是防守底线漏洞利用POC其次因为它们是主要得分来源编码解码和杂项工具再次因为它们是辅助性需求。很多所谓的CTF工具包体积庞大但里面大量内容是AWD用不上的。我一般只保留「命令行能跑、环境无依赖、单文件可执行」这三大特征的工具图形界面工具除非特别关键否则不往里放。2.4 工具收集的常见来源与整理习惯工具从哪来最常见的是自己历次比赛积累的脚本其次是队友之间的共享再就是从各类CTF公开题解里提取出来的POC。无论来源是什么整理习惯比数量更重要。我习惯为每个工具准备一个条目记录四件事工具名、用途、常用命令、依赖要求。把这些信息写在一个README.md里和工具放在同一个目录下。缺少来源说明或依赖说明的工具宁可不放。比赛现场最怕的不是工具少而是某个关键poc看似能用一跑报错你才发现它的依赖环境根本没标注。从Kali或常见渗透链里捡现成命令也是常见做法比如hydra做弱口令爆破、nmap做端口扫描、sqlmap跑注入。但在AWD中通用工具往往太重、太慢容易被干扰。我的选择是通用工具做兜底真正的高效率放在自己写的小脚本上因为AWD的漏洞场景是同一套代码大家都用对方的防御手段也很接近利用脚本越短越不容易出错。收集完成后用压缩包做版本管理。每场比赛前打一个快照赛后把新增的POC和脚本回收到仓库里。压缩包命名带上日期方便回溯。这样你的工具收集就是一个持续演进的过程而不是一次性资源。3. 把收集到的工具盘活解压整理、依赖自检与备忘手册3.1 解压后的第一件事目录结构梳理拿到一个CTF AWD工具收集的压缩包最忌讳的事就是一股脑解压到桌面然后开始翻找。文件堆在一起没有目录到了赛场上你要从几十个文件名里挑出当前需要的那个光是这个动作就会浪费大量时间。正确的做法是先建立一个干净的目录骨架再按使用环节把工具归档。我常用的一套目录结构长这样awd-toolkit/ ├── 00-checklist/ # 开局检查清单和速查表 ├── 10-defense/ # 备份、加固、监控 ├── 20-exploit/ # 漏洞利用POC与exp ├── 30-crypto/ # 编码解码与密码学工具 ├── 40-analysis/ # 流量分析、日志分析 ├── 50-persistence/ # 权限维持与后门 └── README.md # 工具索引这个结构的核心逻辑是「按使用环节而不是按工具名分类」。开局时只访问 10-defense打起来后集中在 20-exploit被打破后需要 40-analysis权限维持看 50-persistence。每个环节下再按目标和工具名细分。这样做还有一个额外的好处当你发现某个环节缺失工具时能直接看到短板在哪而不是等到比赛时才发现。目录骨架定好后把每个工具的入口命令统一管理起来。比如所有Python脚本都加上python3 xxx.py的包装放到~/bin/下这样你只需要记忆一个简短命令名不用每次翻路径。3.2 离线依赖检查断网环境下的依赖能不能跑AWD比赛网络环境有一个特点比赛网段里的外网访问经常受限你能访问的通常只有比赛平台和同网段的靶机。这意味着平时依赖的pip install、apt install、git clone在比赛现场可能全部失效。工具收集回来如果没做过离线依赖检查到了现场就变成了废包。第一步在本机纯净环境里逐个跑一遍。准备一个全新的虚拟机只装基础系统然后把工具包里的脚本靠上传方式弄进去依次执行。凡是报了ImportError、ModuleNotFound、缺少系统命令的都要记录下来并在工具包的README里补上依赖说明。第二步把依赖也收进压缩包。如果某个Python脚本依赖第三方库就把requirements.txt和对应的wheel包一起放进工具目录。这样即使在离线环境也能通过pip install --no-index --find-links./wheels -r requirements.txt完成安装。更省事的做法是优先选择只依赖标准库的脚本。拿flag提交流程举例我常看见有人用requests.post()但环境里没有requests库最后换成urllib三五行代码搞定还省了依赖问题。我还习惯写一个自检脚本在每场比赛前跑一遍确认关键工具都是可运行状态#!/bin/bash # check_toolkit.sh # 用途开赛前快速检查工具包里的关键工具能不能运行 set -e TOOLKIT_HOME$HOME/awd-toolkit check_cmd() { if command -v $1 /dev/null 21; then echo [OK] $1 else echo [MISSING] $1 fi } echo --- 基础命令检查 --- check_cmd python3 check_cmd curl check_cmd tcpdump check_cmd tshark check_cmd jq echo --- 工具包目录检查 --- for dir in 10-defense 20-exploit 30-crypto 40-analysis 50-persistence; do if [ -d $TOOLKIT_HOME/$dir ]; then echo [OK] $dir 目录存在 else echo [MISSING] $dir 目录缺失 fi done echo --- 关键脚本语法检查 --- for script in $TOOLKIT_HOME/10-defense/*.py $TOOLKIT_HOME/20-exploit/*.py; do if [ -f $script ]; then python3 -m py_compile $script echo [OK] $(basename $script) 语法正常 fi done echo 检查完毕这段脚本的逻辑分三层先检查系统命令是否安装再检查工具包目录是否完整最后对关键Python脚本做语法编译检查。用py_compile而不是直接执行脚本的原因是前者只做语法校验不会触发脚本里的实际业务逻辑避免因为检查动作本身产生副作用。在比赛前把所有脚本统一编译一遍能提前拦截语法错误这类低级事故。3.3 写一份工具速查赛前只看这一页工具收集的最后一步是写速查表。这一步经常被忽略但它的价值不亚于工具本身。收集了二十个工具放到赛场上却想不起来用法等于白搜集。我习惯在00-checklist/目录下放一个README.md格式非常简练只记四类信息工具名一行命令用途一句话说清楚解决什么问题常用命令一个按典型场景写好的示例依赖要求Python版本、第三方库、是否离线可用示例## rce_check.py 用途检测目标URL是否存在命令执行漏洞并尝试写入临时文件 用法python3 rce_check.py -t http://target.com -c id 依赖仅标准库离线可用 注意只在比赛允许的靶机范围内使用速查表不需要面面俱到它只需要回答两个问题这个工具解决什么怎么跑原理和优化留给赛后复盘。写太多反而没人看临场也翻不到重点。这份速查表还有一个作用它是你赛前备战状态的晴雨表。如果某个工具连一句话描述都写不出来说明你对它还不够熟比赛里大概率也用不利索。这时候要么花时间弄明白要么直接丢掉别让它占用你的注意力。4. AWD比赛实战链路备份、通防、拿Flag、反打4.1 开局30分钟备份源码与数据库先上权限维持AWD开局后第一件事永远不是攻击而是备份。平台给每队下发相同的Web应用你需要在防守前拿到一份可恢复的副本。没有备份就直接加固一旦脚本改错或对方把你的代码删掉你连恢复的手段都没有。备份有两个目标源码目录和数据库。源码打包成tar.gz数据库导出成SQL文件。最小命令# backup_web.sh # 用途开局后立即备份源码目录和数据库 # 参数$1为Web目录$2为数据库名 WEB_DIR${1:-/var/www/html} DB_NAME${2:-ctf_db} STAMP$(date %Y%m%d_%H%M%S) tar czf /tmp/web_backup_${STAMP}.tar.gz -C $WEB_DIR . mysqldump -uroot -ppassword $DB_NAME /tmp/db_backup_${STAMP}.sql echo [*] 备份完成: /tmp/web_backup_${STAMP}.tar.gz echo [*] 数据库备份: /tmp/db_backup_${STAMP}.sql参数说明WEB_DIR和DB_NAME是可变参数默认值适配常见部署路径STAMP用时间戳保证每次备份不重名tar打包时用-C指定目录避免压缩包含多级绝对路径给还原操作省事。数据库密码建议直接写在脚本首部比赛时不需要反复输入但赛后记得删除或换掉。备份完成后紧跟着做权限维持和基础加固修改SSH和数据库密码去掉默认账号把Web目录里的可疑文件清理掉尤其是上传目录下的webshell把关键文件权限改成只读在php配置里禁用危险函数。同时启动一个后台流量抓取任务让日志一直记录访问行为。注意备份文件不要只留在本机。如果被对手打穿备份也会被删。条件允许时把备份包传到自己可控的比赛跳板机上或者至少放到/tmp以外的隐蔽路径。4.2 抢分阶段批量获取flag与提交的自动化脚本AWD的得分手段是把对手机器上的flag取回来提交到计分平台。每个队伍守一台机器通常有文件型flag和数据库型flag。手动复制粘贴flag再打开浏览器提交在开局初期还能应付一旦进入混战就完全跟进不了节奏。一个能自动读取flag并提交的脚本是刚需。我用bash写的版本只依赖 curl#!/bin/bash # submit_flag.sh # 用法: ./submit_flag.sh flag字符串或文件路径 # 说明: 支持直接传flag或者传一个文件让它去解析 if [ -f $1 ]; then FLAG$(cat $1 | grep -oE flag\{[^}]\} | head -1) else FLAG$1 fi if [ -z $FLAG ]; then echo [-] 没有提取到flag exit 1 fi # 提交地址和token需要赛前填好 SUBMIT_URLhttp://scoreboard.example.com/submit TOKEN${SUBMIT_TOKEN:-your_token_here} curl -s -X POST \ -d token${TOKEN} \ -d flag${FLAG} \ ${SUBMIT_URL} \ -w HTTP状态码:%{http_code}\n逻辑说明先判断输入是文件还是字符串。如果是文件就通过grep -oE提取flag{...}格式内容如果是字符串就直接使用。然后把token和flag一起POST到计分平台的提交接口-w参数打印HTTP状态码方便确认是否提交成功。参数说明TOKEN从环境变量读取避免硬编码在脚本里。提交地址在赛前填好别到现场才改。这个脚本本身不带循环方便你在攻击脚本里逐个调用。实战中我会在这条基础上再包一层循环把每次攻击得到的flag依次提交。这里的坑有三个一是提交接口是否允许重复提交二是并发提交是否会被平台限制三是token泄露问题。如果提交脚本被对手拿到你的token就废了。所以token不要写在Web可访问的目录里运行时用环境变量传入。4.3 分析流量找漏洞从pcap里挖出攻击者的利用方式AWD的攻防是双向的。当你在看别人流量的时候其他人也在看你的。所以抓到流量后关键是能快速分析对方的手法。tcpdump负责抓tshark负责解析这是最稳的组合。# capture_and_analyze.sh # 用途后台抓流量并在需要时提取HTTP请求中的关键路径 # 场景发现服务异常后快速查看最近的HTTP请求 # 开启后台抓包按大小轮转避免磁盘被写满 tcpdump -i eth0 -w /tmp/awd.pcap -C 50 -W 10 port 80 or port 443 # 分析时提取GET/POST路径和User-Agent tshark -r /tmp/awd.pcap -Y http.request -T fields \ -e ip.src -e http.request.method -e http.request.uri \ -e http.user_agent 2/dev/null | head -50参数说明-C 50表示每个pcap文件超过50MB就轮转-W 10表示最多保留10个文件避免长时间比赛把磁盘写满。-Y http.request是tshark的显示过滤器只保留HTTP请求包-T fields指定只输出特定字段减少噪音。head -50限制输出量先看前五十条了解大致攻击节奏。用这个组合可以快速看出对方是否在扫描你的路径、用什么手法在打。前几轮攻防里抓到的流量往往就是后面几轮对方打别人的模板。你把模板存下来反打其他队伍照样能用。分析流量时要特别注意几个点请求里出现curl、python之类的UA时基本就是被工具扫了URI里出现eval、system、base64关键字时八成是命令执行尝试连续大量相同URI请求时是目录扫描或文件探测。这些特征积累多了你就能在几秒钟内判断出对面是什么水平的队伍。4.4 压制对手合理范围内的流量重放与资源消耗AWD里还存在一种拿分思路让你的对手靶机服务不可用裁判可用性检查扣对方的可用性分变相拉大比分差距。但这不是随便乱打的执行时要非常小心因为如果手段过于激进可能被裁判判定为违规攻击平台。从工具包角度看我建议准备轻量级的请求循环脚本而不要依赖重型DoS工具。重型工具容易误伤平台还可能触发裁判干预。常见做法是写一个循环脚本不断向目标发送大量合法请求消耗对方应用层资源。# press_target.sh # 用途发送大量合法请求消耗目标CPU # 参数目标URL并发数 TARGET${1:-http://victim.example.com/index.php} CONCURRENCY${2:-50} for i in $(seq 1 200); do curl -s -o /dev/null -w req $i: %{http_code} %{time_total}s\n $TARGET if [ $((i % CONCURRENCY)) -eq 0 ]; then wait fi done echo [*] 压力测试完成逻辑说明并发发起指定轮数的HTTP请求%{http_code}和%{time_total}输出响应码和耗时用来判断目标响应变化。关键点在并发数的设置不要用太大值。常见做法是让请求在对方应用层排队而不是去打崩TCP连接。这属于规则允许范围内的对抗行为。注意不是所有AWD比赛都允许资源消耗攻击。参赛前先看清规则若规则没提到默认保守操作。因为一旦裁判判定你攻击比赛平台轻则扣分重则取消比赛资格。另外反打前先确认双方服务是同一个应用版本。AWD里可能对手已经打了补丁或改了代码。直接照搬自己漏洞利用脚本去反打很可能落空。发起反打之前花一两分钟扫一下目标页面的指纹标题、静态文件hash、cookie名。确认版本一致后再动作成功率会显著提升。5. 工具包使用避坑五个真实翻车现场5.1 加固脚本一跑服务直接502现象开局后把收集来的加固脚本在代码目录上一跑原本正常的网站直接502或500裁判检查服务时扣分。原因加固脚本的默认规则太激进。比如把system、exec、passthru函数全部在php配置里禁用但业务代码里恰好有地方用到这些函数。也可能是文件权限改成了只读但应用运行需要写日志或session目录。我见过一个案例加固脚本把整个Web目录下的所有文件chmod 444结果session文件目录写不进去登录功能整个瘫痪。解决在执行任何加固脚本前先看清楚它改了哪些配置。最稳妥的办法是把脚本拆开看把操作分为可逆和不可逆两类。删除安装包、禁用危险函数这类影响大的操作先备份原文件再执行改了配置后立刻用curl -I确认本机服务正常再继续下一步。我的工具包里会放一份回滚脚本包含每个配置文件的原始版本一旦出问题能马上恢复。5.2 WAF规则把正常业务接口拦成403现象给站点上了文件型WAF规则后攻击者没拦住反而把自己的注册、登录、搜索接口打成了403正常业务全部不可用。原因很多WAF规则集用的是通用拦截正则比如只要参数里出现select、union、sleep就拦截。但业务代码里搜索功能恰好有一个参数名是select1于是被误杀。这种误杀在开赛初期很难察觉直到裁判可用性检查报警才暴露。解决WAF上线后立即跑一遍业务核心流程的冒烟测试确认登录、注册、搜索、上传能通。我习惯用一段简单的curl脚本遍历核心接口# smoke_test.sh # 用途WAF/加固后的快速接口连通性检查 BASEhttp://127.0.0.1 for path in /index.php /login.php /register.php /search.php?select1 /upload.php; do code$(curl -s -o /dev/null -w %{http_code} $BASE$path) echo $path - $code done如果某个路径返回403就说明WAF规则过宽需要把该路径加入白名单或调整正则。这个脚本跑一次不到十秒但能避免赛后才发现自己的服务早就打不开的尴尬情况。上线任何防护措施后第一步永远是验证可用性而不是确认拦截效果。5.3 Flag提交脚本被对手拿到反被刷分现象放置在Web目录下的flag提交脚本被对手发现对方读取脚本内容拿到了你的提交token之后用你的token批量提交自己拿到的flag把你们队变成「运输大队」。原因脚本硬编码了token并且放在Web根目录下可以直接访问。攻击者用目录扫描或上传漏洞发现了它直接读取源码秒取token。解决凡是包含token、密码的脚本不要放在Web可访问目录里。放到/tmp或自己的home目录执行时用绝对路径。如果必须放在Web目录里把文件名改成无规律字符串权限设为700。我自己的习惯是token存成环境变量脚本里通过读取环境变量获取绝不在代码里明文出现。5.4 本地能打线上打不动数据包里的Host差异现象本地测试时同一个exp打自己靶场很顺利到了比赛现场打对方靶机时exp一直返回错误无法利用。原因最常见的是目标URL没有写对。比赛环境里每队靶机有自己的访问地址格式通常是http://内网IP:端口而你的exp可能在构造payload时把Host头或Referer写死成了本地测试域名。服务器如果基于Host做路由或校验就会出现「本地能打、线上打不动」的现象。解决exp里所有URL都从命令行参数传入不要硬编码。同时写脚本时顺手打开curl -v或--trace-ascii查看实际发出的数据包。把「先看请求长什么样再怀疑目标」这个习惯固化成肌肉记忆比赛时会省下大量排错时间。5.5 老POC没清理Python2依赖在新环境跑不起来现象工具包里一个看起来很不错的POC运行时直接报ImportError或SyntaxError因为它还是Python2时代的写法而比赛机器上只有Python3。原因收集来的工具没有统一环境标注。POC用了print语句、urllib2、StringIO这类Python2专属写法在新环境里根本无法运行。解决收集工具时就给每个脚本标注Python版本。凡是Python2的脚本要么用2to3转好再入库要么在README里注明需要Python2环境。另一种做法是自检脚本时对所有.py文件做python3 -m py_compile检查把语法问题挡在赛前。我个人的标准是凡是需要额外依赖或老版本解释器的POC一律改造到最小可用版本再收进工具包不能改造的宁可不收。6. 把工具包升级成自己的工作流从收集到沉淀6.1 赛后把exp整理成可复用漏洞库工具收集不能止步于比赛结束。每次AWD都会暴露新的利用手法和防护短板这些经验比工具本身更值钱。我每次赛后必做两件事第一把比赛中成功用过的exp复制到20-exploit/目录文件名改成「漏洞类型_目标描述.py」文件头写清适用环境第二把监控日志里对方利用成功的路径记录下来注明漏洞点方便下次遇到同一套代码时直接参考。这个习惯的效果会在第三、第四次比赛时体现出来。当别人还在翻旧工具包找POC时你可以直接调出上次比赛验证过的exp改一下目标IP就开打。每一场比赛都在为下一场积累弹药工具包逐渐长成自己的漏洞利用手册。6.2 用自动化脚本做工具链自检为了让整个工具包保持随时可用状态我在赛前会跑一遍完整自检。把第3章里那些检查脚本合并成一个入口命令验证所有工具的入口、语法、依赖和核心接口连通性。任何组件出错都能当场发现而不是在比赛开局后才痛苦排查。这个自检流程值得固定下来。AWD赛制的特点是突发性强很多队伍是到现场才开始解压工具包结果缺这缺那开局就输了一半。工具包从收集到自检到复用其实是用一次比赛的经验去养下一个比赛的准备这就是我理解的工作流。以上这些步骤全部做完后工具包就不只是一堆文件而是一套自己的防守手册加攻击手册。比赛时打开它能在一小时内完成别人可能要做很久的备战工作这种复利效应是单纯攒工具比不了的。希望这些经验和踩坑记录能帮到你也祝你在接下来的CTF AWD里准备充分、少陷坑、多拿分。本文还有配套的精品资源点击获取