本文同时发布于吾爱破解论坛和我在 GitHub 上的博客。
更新：此方法没有失效！出错原因是我发错链接了！现已改正链接！
曾经，123 盘允许设置中文提取码，一些分享者会把提取码设置成如“投币自取”这样来求投币。但是，现在 123 盘不再允许设置这样的提取码，也不能在提取文件页面输入中文，导致这些文件无法被提取。本文将对网站进行逆向来去除这个限制。注意：本文所做的逆向工作旨在解决 123 盘的一个设计漏洞，所有内容仅供学习交流使用。
我们以 刷机包“DotOS5.2_R15X_K1_DianJi.zip” 为例，其提取码是 点赞投币。如有需要，你可以直接到文末获取我转存的该文件，分享链接不设提取码。
1. 使用解析站
解析站没有提取码输入限制。但是现在解析站解析完文件不能下载（因为要登录计费），因此此方法无效。
2. 修改请求包+Cookie
浏览器打开提取页，打开 DevTools，转到网络页面，输入提取码并确认。网站发出请求 /api/validateSharePwd，负载中的 sharePwd 就是提取码。使用 Burp Suite 拦截这个包并修改请求中的提取码，服务器返回成功，但浏览器页面变为空白。转到 DevTools 的“应用程序”页，选择“Cookie”，发现有一个字段就是 sharePwd_XXXXXX，说明服务器最终是通过前端设置的 Cookie 来授权显示提取页面的。考虑修改此 Cookie。将 点赞投币 进行 URL 编码后填入，然后……
我也不知道会发生什么因为我当时没进行 URL 编码然后得到了 400（逃
3. 调试前端源码
在记事本中输入 点赞投币 然后粘贴进输入框。页面直接开始验证提取码并弹出“提取码不能为空”，并且提取码消失了。在撰写本文时，粘贴操作不再触发验证但是仍然无法粘贴进去。
用 DevTools 的“审查元素”功能找到输入框然后在控制台执行 $0.value="点赞投币"，成功填入。但是点击“提取文件”时再次出现上述情况。由此说明网页不是简单的增加在输入框处进行了输入限制。
我们在“网络”选项卡中找到 validateSharePwd 请求，检查其发起程序，如图：
发起程序
一般来说网络请求函数才需要 await，因此我们进入 await 前的函数，也就是 J，这个函数应该负责生成请求，其中就会读取提取码。如图：
代码1
其中变量 t 就是我们需要的提取码，同时下方的 Cookie 相关代码验证了第 2 点中设置 Cookie 的猜想。按下 Ctrl+F 搜索，输入 t，勾选“全词匹配”，向上查找，我们在上面几行发现了如下代码：
代码2
此时真相大白：验证码中的中文被正则过滤掉了。我们决定使用调试器强制修改变量值。在图示位置，也就是提取码长度校验之后下断点。输入提取码 1111 提取，发现断点在输入文本时被触发了。这解释了上方强制修改文本框 value 失败的原因：提取码是在输入时被存入变量的，而不是点击提取按钮时读取，直接修改文本框不会触发这个函数，即使触发，中文也会被过滤。将中文字粘贴进去同样会被过滤。此时在调试器中双击变量 t 的值，将其改为 "点赞投币"，继续运行程序，然后点击提取按钮。然后提取成功！
代码3
但遗憾的是，在撰写本文时，我们无法再次重现这一状况，而是得到了“提取码错误”，说明管理员对此有所察觉并修复了这一漏洞。我们尝试进行最后的挣扎：将下方的 n.code 由 -1 改为 0，假装提取码正确并成功设置 Cookie。但页面转为空白页说明服务器不接受该提取码。同样地，上文提到的所有方法最终都需要服务器解析，因此全部失效。
更新：此方法没有失效！
4. 结语
只能说是出于幸运，或者是之前没人试过这种方法，我无意中发现了这个漏洞并成功提取了我想要的文件。或许正是我无意中的一次尝试促使管理员发现了这个漏洞。但是，封堵此漏洞后，
网站的设计漏洞还是没有解决：任何人都无法再提取那些设置了中文提取码的文件。而有些文件的分享者已经永久失联了，不可能再回来把提取码改成“合法”的提取码了。我们敦促 123 盘工作人员在看到本文后尽快合理解决此问题。
下面，我将提取并转存的文件以无提取码方式分享出来，也许正好能帮到一些有缘人：DotOS5.2_R15X_K1_DianJi.zip
5. 神秘大佬的指点
来自涛之雨大佬：其实只要在链接后面加上 ?pwd=点赞投币 就可以了。
（以后会不会修不知道）
[复制链接]
发表于 2025-12-5 23:24
发表于 2025-12-16 21:13
|
发表于 2025-12-19 23:43
