李_涛1. 为什么选Pikachu练爆破：靶场定位与爆破模块拆解
先聊点实在的。很多人一提到暴力破解，脑子里全是"拿Burp Suite挂字典一顿打"的画面，但真到了实战环境里，你会发现爆破远不是"点个Start Attack"那么简单。Web登录的防爆破机制已经从最早的"无限制尝试"进化到了验证码、Token、账号锁定、IP限速、行为分析层层叠叠。想在真实业务里练手既不合规也不现实，这时候一个设计得当的靶场就是最好的训练场。
Pikachu（皮卡丘靶场）在国内网络安全圈子里口碑一直很稳，它跟DVWA那种"一个漏洞类型一个页面"的做法不太一样。DVWA更像一套标准试卷，每道题对应一个漏洞类型；Pikachu则把常见的Web安全漏洞串联成了一套"渗透测试剧情"，从暴力破解、XSS、SQL注入到CSRF、越权、文件上传、RCE，覆盖得相当全。它的暴力破解模块不是孤立的，而是嵌在"用户登录-会话管理"这个真实链路里，练爆破的时候还会顺带理解HTTP请求结构、Cookie机制、验证码逻辑，这是纯刷题型靶场给不了的。
具体到爆破这个主题，Pikachu里埋了几个不同难度的口子。最基础的"基于表单的暴力破解"就是一个裸奔的登录框，用户名密码全靠POST提交，没有任何防护，适合新手理解爆破的基本原理和Burp Suite的Intruder模块用法。往上走还有带验证码的登录、基于Token的登录，这些都是实际业务里最常见的防爆破场景。把这些模块逐个打下来，你对爆破的理解就不只是"拿字典撞库"，而是会去思考服务端到底靠什么防你、这些防护各自有什么绕过思路。
这篇文的定位很明确：面向已经装了Burp Suite、但还没系统练过爆破的入门到进阶选手。我会从环境搭建讲起，到Burp Suite抓包配置，再到字典构造思路、验证码与Token绕过、结果判定技巧，最后补上我实际测试中踩过的坑。全部操作都在本地靶场进行，不会涉及任何真实目标。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 搭建一个能稳定复现爆破场景的Pikachu环境
2.1 PHPStudy + Pikachu部署要点
Pikachu是PHP写的，最省事的跑法是PHPStudy套件。网上搜"pikachu靶场下载"能找到GitHub仓库和国内镜像，把压缩包解压后放进PHPStudy的网站根目录（默认是C:\phpstudy_pro\WWW，如果你改了安装路径就对应调整），然后启动Apache和MySQL两个服务，浏览器访问http://127.0.0.1/pikachu-master/就能看到初始化界面。
这里有两个非常容易踩的坑。第一个是PHP版本。Pikachu是老项目了，代码里用了不少PHP 5时代的写法，你如果直接用PHP 7.4以上的高版本，某些页面会报Deprecated警告甚至直接Fatal error。我实测下来PHP 5.6是最稳的，PHP 7.0也能跑，但部分模块的显示会有点小问题。PHPStudy自带的版本切换很方便，启动前先到"设置-php版本"里切到5.6，别图省事用新版。
第二个坑是数据库初始化。Pikachu里的漏洞模块很多是要连库的，比如SQL注入、越权操作、登录认证，它把这些功能的测试账号都写在初始化SQL里。访问首页后会有一个"初始化"按钮，点它就会自动建库建表。如果你点了初始化之后提示连接失败，九成是MySQL的root密码不是默认的root。Pikachu的配置文件在inc/connect.inc.php里，打开这个文件把数据库用户名和密码改成你自己的，再重新初始化就通了。
2.2 开工前检查：PHP扩展、路径和访问权限
环境跑起来只是第一步，爆破实验要抓包，得确保Target地址能被Burp Suite正常代理访问。本地靶场走127.0.0.1，Burp默认的代理端口是8080，如果你浏览器挂了代理还是访问不了，先检查一下PHPStudy的端口配置——Apache默认80端口，如果被IIS或者别的服务占了，就会变成8080或别的端口，访问地址要跟着变。
还有PHP扩展的问题。Pikachu部分模块依赖php_curl和php_mbstring，PHPStudy默认开启的扩展不全，你打开某些页面会报"Call to undefined function curl_init()"之类的错。在PHPStudy面板里找到"扩展"选项卡，把curl、mbstring、gd这几个勾上，重启Apache，基本就能跑全。
最后说一个很多人忽略的点：目录权限。Pikachu有些功能会写入临时文件（比如验证码图片、上传模块的临时目录），如果目录权限不够，页面会白屏或者报权限错误。Windows下一般是没这问题的，但如果你是拿虚拟机里的Linux跑的（实战中很常见），记得给Pikachu目录加写权限，chmod -R 755起步，chmod -R 777省心但别在真实服务器上这么干。
环境这块总结一句话：PHP 5.6 + MySQL root密码改对 + curl扩展开启，这三件事做到位，Pikachu的爆破模块就能稳定复现了。
3. 爆破实操：Burp Suite + 自定义字典的完整链路
3.1 抓包定位登录请求
环境就绪后，打开Pikachu首页，找到"暴力破解"菜单，先点进"基于表单的暴力破解"这个子模块。页面就是一个用户名加密码的登录框，提交之后会返回"登录失败"或"登录成功"。我们要做的第一件事不是猜密码，而是搞清楚登录请求长什么样。
打开Burp Suite，确认代理监听的是127.0.0.1:8080，浏览器挂上这个代理（Firefox的FoxyProxy或Chrome的SwitchyOmega都行，本地调试用最简单的配置就可以）。然后在Pikachu页面里随意输入一组测试账号，比如用户名填admin，密码填123456，点登录，回到Burp的HTTP history里找那条POST请求。你会看到类似这样的结构：
http复制POST /pikachu-master/vul/burteforce/bf_form.php HTTP/1.1
Host: 127.0.0.1
Content-Type: application/x-www-form-urlencoded
Cookie: PHPSESSID=xxxxxxxxxxxxxxxxxxxxxx
username=admin&password=123456&submit=Login
这里的关键信息就三个：请求的URL、POST参数名（username和password）、以及提交方式。爆破的原理就是无限次重放这个请求，每次替换参数值，然后根据响应内容判断哪一组账号密码是对的。先把这条请求完整发给Burp的Intruder模块（右键→Send to Intruder），后面所有操作都在Intruder里做。
这里我要特别提醒一点：登录页面如果是GET请求带参数（比如?username=admin&password=123），那说明后端大概率把参数放在URL里处理，你在Intruder里标记参数的方式一样，但要注意URL编码问题。Pikachu的爆破模块用的都是POST方式，所以重点掌握POST即可。
3.2 字典构造策略：弱口令、默认口令、规则变形
爆破的成败，一半靠字典。很多人上来就挂一个几十GB的超级大字典跑，跑得慢不说，命中率往往还很低。我的建议是准备两套字典：一套是"精准打击"用的常用弱口令，另一套是"规则变形"用的基础字典。
先看Pikachu里管理员账号的规律。你点初始化之后，其实网站里已经暗示了测试账号的存在（提示信息都在页面源码里），比如admin/admin123这种。但我们的目标是练习"在完全不知道账号密码的情况下，构造出能碰中的字典"。最稳妥的做法是先在本地建一个账号列表：
- 用户名维度：
admin、administrator、root、test、pikachu、manager、system - 密码维度：
123456、password、admin、admin123、root、pikachu、test、12345678、qwerty、666666、1qaz2wsx、P@ssw0rd、admin@123
排列组合下来也就几十条请求，Intruder几秒钟跑完，速度快、命中率高。如果你想要更系统化的字典，可以基于真实密码库（比如常见的top100弱口令列表）做前缀后缀变形：在admin后面加年份、加特殊符号，在pikachu后面加123、加@。实战中最常见的弱口令不是随机的，而是"默认密码+简单后缀"的组合。
Burp Suite的Intruder里有个Payload Processing功能，可以自动做变形处理，比如给每个密码列表的词追加123、替换a为@、大小写互换等。这样你只需准备一份很小的基础词表，就能生成成百上千的变体，比手动维护大字典高效得多。我实测过，Pikachu的爆破模块用这种"小字典+规则变形"的方式，基本几十秒内就能出结果。
3.3 Intruder配置与结果判定
爆破请求发到Intruder后，先到Positions页签。默认情况下Burp会把所有参数都标成payload位置，这里我们要手动清空（点"Clear §"），然后只给username和password这两个值打上标记。注意：如果你同时标记两个位置，Burp默认使用Cluster bomb模式，会对两个字典做笛卡尔积组合，请求数量会膨胀得非常快（比如10个用户名乘100个密码就是1000条请求）。如果只想固定一个用户名去跑密码，那就只标记password一个位置，Payload类型选Simple list即可。
Payloads页签里把准备好的字典内容粘贴进去。如果你跑的是Cluster bomb模式，就要分别配置两个payload集合：第一个集合放用户名，第二个放密码。Options页签里可以设置线程数，本地靶场线程开到10到20都没问题，但如果目标有防爆破策略，线程数要降下来，后面我会细说。
全部配置好后点"Start Attack"，Burp会弹出结果窗口，每一行代表一次请求，包含状态码、响应长度、响应时间等。判定成功的关键是：看响应内容而不是只看状态码。Pikachu的登录成功和失败返回的页面长度和内容有明显差异，成功时会跳转或返回包含用户名信息的页面，失败时通常是"用户名或密码不存在"这类提示。你在结果窗口里点开任意一条请求看Response，对比一下长度异常的条目（通常是最长的那个），十有八九就是成功的那一条。
我在实际测试中发现一个很有用的技巧：先故意用一个确定错误的密码发一条请求，记录Response的长度和内容特征，然后在Intruder结果里按长度排序，凡是长度明显不同的条目都值得点开看一遍。这个"基线对比法"在后面处理验证码和Token场景时同样适用。
4. 越过"防爆破"机制：验证码、Token、锁定策略
4.1 验证码复用漏洞
Pikachu的爆破模块里有一个"带验证码的登录"，这个模块设计得非常典型。第一次打开页面时，验证码图片加载出来，你输入正确的账号密码和验证码才能登录。但如果验证码的校验逻辑只存在于第一步——也就是验证码只在登录请求时校验一次，且服务端短时间内不更新，那么爆破就有了可乘之机。
具体操作是：先用Burp抓到带验证码的登录请求，注意看Cookie里的PHPSESSID。Pikachu早期版本的验证码是跟Session绑定的，同一个Session内验证码不会自动变化（除非你频繁刷新页面）。所以你可以这么做：先在浏览器里打开登录页面，用Burp截取验证码图片响应，人工识别出验证码，然后立刻把这条请求发到Intruder，固定验证码参数值不变，只爆破用户名和密码，在Session没过期之前持续跑。
这里的关键点在于：验证码是用来防人的，但服务端如果只验证"验证码对不对"而不管"这个验证码是给哪个会话发的"，那它就形同虚设。
如果你遇到的是那种每次刷新都会更换验证码的站点，思路就要转向"打码平台"或"OCR识别"了，但Pikachu这个模块没必要上这么重的方案，理解"验证码复用"这个漏洞点就够了。等到真实渗透测试里，这种验证码与Session未绑定的问题依然常见，很多内部系统都是这个路子。
4.2 Token失效时机
Pikachu里还有一个"基于Token的登录"，这个模块的思路更接近现代Web安全实践。服务端在返回登录页面时，会给表单里塞一个隐藏字段token，比如：
html复制<input type="hidden" name="user_token" value="8f7a2e6b1d3c4f5a">
登录请求必须带上这个token，服务端校验通过才继续验证账号密码。这个机制的目的，是防止攻击者构造一个固定的登录请求反复提交——因为token每次刷新页面都会变化，你从Burp history里拿到的旧token，过几秒再重放就可能失效。
但Token机制有一个经典的绕过条件：token是否随每个请求动态更新。如果服务端只在首次生成token时不更新（比如把token存在Session里，验证通过后不刷新），那你只需要在浏览器打开页面时抓一次token，然后用Burp固定这个token值去爆破就行。Pikachu的这个模块恰恰就是这种设计——它的token生成逻辑是"每次请求登录页时生成新token"，但如果你不刷新页面，token就一直有效。所以正确的爆破姿势是：
- 浏览器打开登录页，Burp抓取GET请求的响应，提取
user_token的值。 - 把带这个token的POST登录请求发到Intruder。
- 固定token参数，只爆破账号密码。
- 在token过期前（Pikachu里过期时间默认比较长），把结果跑完。
这个例子最重要的是帮你建立一种判断力：遇到Token防爆破的站点，不要慌，先看它是"静态Token"还是"动态Token"。动态Token（每次请求都变）对爆破的防护效果很强，除非你能在请求之间先获取新Token（比如通过JavaScript解析），否则基本只能放弃爆破这条路。而大量老旧系统用的是静态Token，这就是突破口。
4.3 爆破速率与触发锁定
Pikachu的模块里没有特别强的账号锁定机制，但真实业务场景中，连续输错密码5次就可能锁定账号，或者触发IP临时封禁。靶场里虽然不锁，但练习时要有意识地控制爆破速率。
Burp Intruder的Options里有个Request Engine设置项，可以调线程数和请求间隔。本地靶场随便跑，但如果你将来在授权测试中遇到有锁定策略的目标，聪明的做法是：
- 调低线程数，比如1到3个并发。
- 在Payload Processing里给每组密码加延时（比如请求完成后Sleep 2秒）。
- 采用"小字典分批"策略，每次只跑20个密码，观察响应变化，如果出现"账号锁定"或"验证码错误"提示，立即停。
另外要注意，很多系统的锁定策略是"按账号锁定"而不是"按IP锁定"。你如果用大量用户名去撞一个固定密码，可能会把所有测试账号都锁死。反过来，用少量用户名配大量密码，则可能撞到锁定策略的阈值。我在授权测试中习惯的做法是：先看目标有没有注册接口，如果有，注册一个全新账号来测试爆破，这样不会影响真实用户，也避免误锁他人。
5. 爆破实战中反复踩到的坑与判定技巧
5.1 响应长度对比不是万能
前面我建议用"响应长度异常"来判断爆破成功，但这个方法在部分场景下会失灵。比如有些系统的登录失败和成功都返回同样的页面模板，只是某个字段值不同；或者页面里动态拼接了随机广告、时间戳，导致每次响应长度都在变。这时候按长度排序会看到一大片均匀分布的结果，根本分辨不出来。
我的替代方案是：在Intruder的Settings里添加一个Grep-Match规则，比如匹配"登录成功"、"欢迎"、"错误"，或者反过来匹配"失败"、"不存在"。Burp会自动在响应里检索这些关键词并打勾，结果窗口里一眼就能看到哪条请求命中了。Pikachu的爆破模块返回信息很直白，用这个功能会有奇效。
还有一个更进阶的判断方法：看响应时间。如果某个用户名的密码每次都正确/错误，服务端处理时间会有细微差异（比如密码校验通过后还要查数据库、加载个人信息）。在本地靶场这个差异不明显，但在真实系统的测试中，响应时间异常点往往才是成功登录的特征——因为多了一堆查询逻辑。
5.2 编码与特殊字符问题
爆破字典里如果包含特殊字符，比如@、#、空格、中文密码，很容易踩编码的坑。Pikachu的表单提交默认是application/x-www-form-urlencoded，中文和特殊字符会被URL编码后在网络中传输。你在Intruder的Payload里写的是原始字符，Burp会自动处理编码，但要确认Payload Encoding的选项是开启状态。
另一个坑是大小写敏感。服务端校验密码是区分大小写的，Admin123和admin123是完全不同的两串。如果你在Payload Processing里做了大小写变形，记得确认变形后的结果真的发送出去了，可以在Burp的Request预览里看实际发出的内容。
还有一个我踩过好几次的坑：字典文件如果是从Windows记事本里创建的，默认带BOM头（UTF-8 BOM），这个不可见字符会悄悄跟在第一行词条后面，导致第一条请求永远失败。用VS Code或Notepad++这类工具另存为UTF-8无BOM格式能彻底解决。这个问题在Linux下用命令行生成字典时不会有，但Windows用户真的要当心。
5.3 线程数与超时设置
很多新手点Start Attack之后看着上下翻飞的请求记录觉得很像回事，但跑完一看全是超时或者连接重置。这不代表目标防御强，多半是你的线程数开太高了，或者Burp的Timeout设置太短。
Pikachu跑在本地，理论上开50个线程也不会有问题，但如果你在Linux虚拟机里跑靶场，偶尔会遇到Apache默认MaxRequestWorkers参数限制，8090端口下并发一高就返回503 Service Unavailable。这种时候不要急着怪靶场，先把线程降到5试试，基本就能稳定跑完。
Burp的Timeout设置在Options→Connections→Timeout，默认好像是30秒，本地几乎不可能超时，但如果你把靶场部署在远程VPS上，网络波动会导致部分请求超时。超时的请求不会出现在Intruder结果里，你会看到一个莫名其妙的"请求总数对不上"。我的建议是：跑爆破任务的过程中，不要同时开浏览器刷视频或下载大文件，Burp本身很吃内存，代理链路上再有其他流量，结果准确性会大打折扣。
6. 爆破练习中容易被忽略的几个细节
聊到这儿，基础的爆破流程已经跑通了。但我还想补充几个实战中会反复遇到的细节，这些在纯教程帖里很少被提到，却能直接影响你的效率。
第一个是关于Cookie的处理。Pikachu的登录请求是带Session Cookie的，在Intruder里爆破时，Burp默认会把当前Session的Cookie原样带上。但有些系统在登录成功后会给客户端设置新的Cookie，如果你跑的字典里有几组正确密码，后面所有请求可能会携带"登录后的新Cookie"，导致响应内容全部变成"已登录"状态，干扰判断。这种情况的应对方法是在Intruder的Settings里把Update Content-Length打开，并且留意是否需要在每次请求前重新获取Cookie。
第二个是Content-Length头的自动更新。Burp Intruder在处理POST请求时，如果payload长度和原始请求不一致，会自动更新Content-Length头，但如果你导入的请求格式有误，某些情况下这个功能会失效，导致服务端认为请求体不完整而返回400错误。配置好payload之后，最好先在Repeater里手动测试一条实际发送的请求，确认服务端正常返回后再去跑Intruder。这个"先单条验证、再批量爆破"的习惯，关键时刻能救命。
第三个是字典的去重。如果你把从网上找的字典直接粘贴进Intruder，里面可能有大量重复词条，白白浪费请求次数。写个简单的命令行去重：
bash复制sort -u dict.txt -o dict_unique.txt
wc -l dict.txt dict_unique.txt
去重后再导入，跑出来的结果干净得多。不要小看这个动作，一个十亿级别的去重字典和不去重的字典，爆破时间能差出好几倍。
第四个是关于爆破对象的选择。Pikachu的爆破模块有几个子页面，除了表单登录，还有"基于HTTP Basic认证"的爆破。这个模块绕不开一个概念——HTTP Basic认证。它的原理是浏览器弹出登录框，账号密码以Base64编码后放在Authorization头里。用Burp抓包后你会发现，认证信息长这样：
http复制Authorization: Basic YWRtaW46YWRtaW4xMjM=
YWRtaW46YWRtaW4xMjM=就是admin:admin123的Base64编码。爆破这种认证类型，需要先在Intruder里把Payload设置成"用户名:密码"的格式，然后添加一个Payload Processing规则进行Base64编码，再填入Authorization头的值位置。Pikachu这个模块很适合练习"非表单类认证"的爆破思路，很多内网设备、路由器管理后台用的就是这种认证方式。
7. 从靶场到实战：个人经验与边界提醒
最后，我想以一个做了几年安全测试的人的身份聊几句经验，而不是教程式的收尾。
靶场爆破练的是"术"，但真正值钱的是"道"——也就是你知道什么时候该爆破、什么时候不该爆破。在我接触过的真实授权测试里，暴力破解往往不是第一选择。一个稍微像样的系统，配了验证码＋账号锁定＋短信二次验证，你的字典再大也只是给别人日志添几行记录。真正的渗透测试优先找逻辑漏洞、找未授权接口、找Session固定问题，爆破只在确认目标防护薄弱时才作为备选方案。
所以我的建议是：Pikachu的爆破模块值得好好练，但它只是Web安全链路里的一小环。练完爆破之后，把Pikachu的XSS、SQL注入、CSRF、越权模块都过一遍，你会发现这些漏洞类型之间是有关联的——比如SQL注入有时候能直接替代爆破拿到用户密码，XSS能偷到管理员Cookie从而绕过登录。靶场存在的意义不是让你学会某个单一攻击手法，而是建立一种"从整体看目标"的思维。
个人操作层面的心得再补一条：练习时给Burp Suite单独开一个项目文件，每次练完导出Burp的状态，方便后续复盘。我见过太多人爆破跑完了，结果窗口一关，连"当时是怎么配置的"都忘了。把经典的验证码绕过流程、Token绕过流程整理成自己的笔记，下次遇到类似场景直接照搬思路，比临时翻教程高效得多。
安全这条路的底线也必须守住。靶场是靶场，公网是公网，未经授权的测试行为在任何时候都是违法的。Pikachu这类靶场的意义，就是让我们在完全合法可控的环境里把技术练成熟，而不是等到真实场景里用惨痛教训来学习。
这篇文章里所有的操作步骤、字典构造思路、防爆破绕过方法，我都建议你亲手在Pikachu上复现一遍。跑通一次"表单爆破→验证码绕过→Token绕过"的完整链路，你对Web认证机制的理解会比看十篇教程都深。动手吧，遇到跑不通的地方，回头检查HTTP请求结构、Session状态和编码问题，这三板斧能解决九成以上的卡壳。