窝是如何两小时刷出 11E 美味值的（内附教程（备份

此文仅为专栏备份（

窝是不屑于发这种东西到博客的（

---

连点器？连点器什么的太屑了。果断打开 F12 查看请求。

稍有常识的人就能看出这就是个简单的 post 提交，于是右键复制为 curl，粘贴进 shell。

嗯没有 IP 验证，CSRF 校验固定，没有 Origin/Referer 头验证就能直接提交欸（

于是开始测试 count 最大值，根据 B 站使用 go 的常识判断是 INT64。果然 9223372036854775807 可以过验证，+1 报错。然而页面并没有动静，推断做了最大值校验。辣么，超级无敌提交器就可以上场了！

wrk 本来是个 HTTP 性能测试的开源软件，这里用来提交 114514 个请求给这个 API 端点达到刷数据的效果。

B 站的用户验证实现一直是从 DedeCMS 时代延续下来的，只需要 DedeUserID&SESSDATA cookie 就能完成用户验证。我们尝试编写如下 wrk lua 代码：

wrk.method = "POST" --指定请求方法为 POST

wrk.body   = "count=9223372036854775807&csrf=[Your CSRF Token here]" --我们设定每次提交点击 100 下，CSRF Token 可以在请求/cookie中找到，替换掉 [Your CSRF Token here]

wrk.headers["Content-Type"] = "application/x-www-form-urlencoded" --加上表单头表示表单数据

wrk.headers["Cookie"] = "DedeUserID=[Your UserID]; SESSDATA=[Your SESSDATA]" --同理，在 cookie 中找到

通过这样一段脚本我们就实现了迫真点击 INT64 MAX 下的效果。另存为 bilibili.lua，接下来我们进行请求来验证

wrk -t 1 -c 1 -d 5s -s bilibili.lua https://api.bilibili.com/x/activity/bnj2020/hotpot/increase

发现成功运行并且毫无奇妙 HTTP error，然而并不能看到实际效果。

那就加大线程和链接数量（

只见美味值在 10k qps(query per second/每秒请求数量) 下暴涨，四舍五入一下就是 5kw 啊（

可是发现了不同寻常的 HTTP error code，于是手动 curl 一下：

嘛，IP 高速率请求是容易 412 的，写脚本换个 IP 就好了（

只要我在 20s 内请求的够多，412 就追不上我（

套上循环一下嗯很完美，那就再开三台做个集群好了（

后面的事情你们都知道了（

麻烦把我 11e 的菜还我（

当然，如果你嫌麻烦的话，F12 直接在 increase 请求上右键 copy as powershell，改成 count=50，然后启动 powershell 写下这么一句话：

while(1)

{

复制粘贴到这里

Start-Sleep -s 1

}

就能自动刷美味值了 [doge]

科 技 兴 国