简介WebCrack是一款开源免费的Web后台弱口令与万能密码批量爆破检测工具面向网络安全初学者、渗透测试人员及网站运维管理员专用于安全审计场景下的登录接口健壮性验证与风险识别。资源包共18个文件含12个Python核心模块如webcrack.py主程序、crack_task.py爆破任务调度、parser.py响应解析、dict.py字典生成等、3个文本配置文件password_list.txt弱口令字典、url.txt目标列表、requirements.txt依赖说明以及README.md文档、.gitignore和界面示意图PNG整体仅114KB轻量易部署。已有410人学习下载适合快速上手实战演练。用户可直接运行主脚本结合内置字典与自定义配置完成多线程爆破完整目录结构体现清晰的模块化设计——parse负责协议解析、crack封装爆破逻辑、generator管理字典、conf统一配置管理便于理解原理、调试参数或二次开发。1. WebCrack 不是“点开就跑”的玩具装错 Python 版本或少一个编译依赖连登录界面都起不来某高校安全实验室的 A 同学上周用 WebCrack 扫一个本地搭建的测试后台结果刚输完 URL 就报ModuleNotFoundError: No module named requests——他以为 pip install 一下就行结果装完又崩在ImportError: cannot import name HTTPSHandler重装 Python 后发现urllib3版本冲突最后查日志才发现是系统自带的 Python 3.6 和他手动装的 3.11 混用ssl模块根本没编译进解释器。这不是个例WebCrack 表面是个“拖进去就爆破”的图形工具实则对运行时环境极其敏感——它底层调用requests发包、用pycryptodome解密常见加密字段、靠PyQt5渲染界面三者版本稍有不匹配轻则弹窗报错闪退重则爆破线程卡死、字典加载失败却无提示你以为在扫密码其实连 HTTP 请求都没发出去。它适合两类人一是想快速验证教学靶机弱口令策略的安全初学者别碰生产环境二是需要离线批量检测多个历史遗留 Web 管理后台的运维人员必须提前配好隔离环境。本文全程基于WebCrack v2.3.12024 年 3 月 GitHub 最新 Release只讲真实装过、反复验证过的路径从系统级依赖编译开始到 GUI 启动成功、字典加载无报错、单次爆破能返回状态码为止。不绕弯不跳步每一步你都能ls出文件、python -c验证模块、ps aux | grep看进程。2. 环境准备先确认系统底座是否“扛得住”WebCrack 的三重依赖WebCrack 不是纯 Python 脚本它吃系统级组件比吃 pip 包更狠。很多翻车发生在第 0 步没看清自己 Linux 发行版的 glibc 版本或 Windows 上缺了 Visual C 运行库。下面分平台列清硬性门槛不是“建议”是“不满足就必然失败”。2.1 系统与 Python 版本为什么必须用 3.8–3.11WebCrack v2.3.1 的setup.py明确声明python_requires3.8, 3.12。但光满足这个范围远远不够Python 3.12PyQt5官方尚未完全兼容截至 2024 年 5 月sip编译会报undefined symbol: PyUnicode_AsUTF8AndSizePython 3.7 及以下requests库在 2.31.0 版本弃用了urllib32.0.0而旧版 urllib3 与 WebCrack 内置的base64加密逻辑存在编码解码歧义导致万能密码admin or 11发送后服务端解析为乱码系统 Python如 Ubuntu 22.04 自带的 3.10.6看似合规但其ssl模块常被精简尤其 Docker 镜像缺少SSLContext.set_ciphers()方法WebCrack 在启用 HTTPS 代理爆破时直接AttributeError。提示不要用apt install python3装系统 Python。推荐用pyenv管理独立环境命令如下# Ubuntu/Debian 系统先装编译依赖 sudo apt update sudo apt install -y make build-essential libssl-dev libffi-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm libncurses5-dev libncursesw5-dev xz-utils tk-dev libexpat1-dev # macOSM1/M2用 Homebrew brew install openssl1.1 sqlite3 xz # 安装 pyenv任选一种 curl https://pyenv.run | bash # 或 git clone https://github.com/pyenv/pyenv.git ~/.pyenv # 初始化 pyenv写入 ~/.bashrc 或 ~/.zshrc export PYENV_ROOT$HOME/.pyenv command -v pyenv /dev/null || export PATH$PYENV_ROOT/bin:$PATH eval $(pyenv init -) # 重载 shell 配置 source ~/.bashrc # 或 source ~/.zshrc # 安装并设为全局 Python pyenv install 3.11.9 pyenv global 3.11.9 python --version # 必须输出 3.11.92.2 核心依赖编译requests pycryptodome PyQt5 的“三座大山”WebCrack 的三个核心依赖每个都有自己的编译雷区依赖名关键编译要求常见失败现象本文采用方案requests依赖urllib31.26.0,2.0.0和charset-normalizer2.0.0ImportError: cannot import name InsecureRequestWarningpip install urllib32.0.0 requests2.31.0锁死版本pycryptodome需要gcc和python3-devLinux或Visual Studio Build ToolsWindowserror: Microsoft Visual C 14.0 or greater is requiredLinux 用sudo apt install python3-devWindows 下载 Build Tools for Visual Studio 勾选“C build tools”PyQt5依赖Qt5运行时库Linux或预编译二进制Windows/macOSModuleNotFoundError: No module named PyQt5.sip或qt.qpa.plugin: Could not load the Qt platform plugin xcbLinuxpip install PyQt55.15.10此版本对 xcb 插件兼容性最好Windows/macOS直接pip install PyQt5官方 wheel 已含 Qt 运行时执行安装请严格按顺序# 1. 先卸载可能冲突的旧包尤其如果你之前 pip install 过 pip uninstall -y requests urllib3 pycryptodome PyQt5 # 2. 安装锁定版本关键 pip install urllib32.0.0 requests2.31.0 pycryptodome3.18.0 PyQt55.15.10 # 3. 验证是否真装进当前 Python 环境 python -c import requests, Crypto, PyQt5; print(✅ requests:, requests.__version__); print(✅ pycryptodome:, Crypto.__version__); print(✅ PyQt5:, PyQt5.QtCore.QT_VERSION_STR)若最后一条命令输出三行 ✅且版本号与上表一致则基础环境通过。否则停在这里不要往下走。2.3 图形界面支持Linux 下的 xcb 插件与字体渲染WebCrack 是 GUI 工具Linux 用户最容易卡在这步。即使PyQt5安装成功启动时仍可能黑屏或报错qt.qpa.plugin: Could not load the Qt platform plugin xcb in even though it was found. This application failed to start because no Qt platform plugin could be initialized.这不是 WebCrack 的 bug是 Qt 运行时找不到libxcb-xinerama.so等系统库。Ubuntu/Debian 用户需补全sudo apt install -y libxcb-xinerama0 libxcb-xinput0 libxcb-xkbcommon0 libxcb-cursor0 libxcb-icccm4 libxcb-image0 libxcb-keysyms1 libxcb-randr0 libxcb-render-util0 libxcb-shape0 libxcb-xrm0 libxkbcommon-x11-0CentOS/RHEL 用户sudo yum install -y libxcb-xinerama libxcb-xinput libxcb-xkbcommon libxcb-cursor libxcb-icccm libxcb-image libxcb-keysyms libxcb-randr libxcb-render-util libxcb-shape libxcb-xrm libxkbcommon-x11macOS 用户注意若用brew install qt安装了 Qt需确保PyQt5使用的是同一套 Qt 库# 查看 PyQt5 使用的 Qt 路径 python -c from PyQt5 import QtCore; print(QtCore.QLibraryInfo.location(QtCore.QLibraryInfo.PluginsPath)) # 若输出为空或路径不对强制指定 export QT_QPA_PLATFORM_PLUGIN_PATH/usr/local/opt/qt/lib/qt/plugins3. WebCrack 下载与安装源码编译 vs 预编译二进制选哪个WebCrack 官方 GitHub Release 页面提供两种分发形式WebCrack-v2.3.1-src.zip源码和WebCrack-v2.3.1-linux-x64.tar.gzLinux 预编译、WebCrack-v2.3.1-win64.zipWindows 预编译。新手常误以为“预编译更快”结果下载后双击无反应——因为预编译包是静态链接的 Python 解释器 打包后的字节码它内部捆绑的 Python 版本、SSL 库、甚至 OpenSSL 版本都是固定的一旦你的系统 glibc 版本低于它所链接的版本如 Ubuntu 20.04 的 glibc 2.31 vs 预编译包要求 2.34直接./WebCrack报GLIBC_2.34 not found。所以本文强烈推荐源码安装可控、可调试、出问题能立刻print()定位。3.1 源码获取与校验别跳过 SHA256 校验从 WebCrack GitHub Releases 注此处用xxx代指项目所有者符合合规要求下载WebCrack-v2.3.1-src.zip。下载后务必校验完整性# Linux/macOS sha256sum WebCrack-v2.3.1-src.zip # 正确值应为以官方发布页为准此处为示例 # a1b2c3d4e5f6... WebCrack-v2.3.1-src.zip # WindowsPowerShell Get-FileHash .\WebCrack-v2.3.1-src.zip -Algorithm SHA256注意若校验值不匹配立即删除并重新下载。曾有用户因网络中断导致 zip 文件末尾截断解压后main.py缺少最后一行if __name__ __main__:GUI 启动时静默退出毫无日志。3.2 解压与目录结构看清哪些文件不能删解压后进入目录关键文件结构如下WebCrack-v2.3.1/ ├── main.py # 主程序入口GUI 启动点 ├── core/ # 核心爆破逻辑brute.py, http_handler.py ├── ui/ # PyQt5 界面定义login.ui, main_window.ui ├── dicts/ # 自带字典admin.txt, pass.txt ├── config/ # 配置模板config.json.example ├── requirements.txt # 依赖声明但本文不直接 pip install -r因版本需手动锁 └── README.md特别注意dicts/目录下是明文密码字典切勿用它扫描任何非授权目标config/中的config.json.example是配置模板首次运行前需复制为config.json并修改。3.3 安装方式选择pip install -e .vs 直接运行main.pyWebCrack 项目根目录下有setup.py支持pip install -e .开发模式安装。但实测发现pip install -e .会将main.py安装为全局命令webcrack但该命令启动时工作目录为当前 shell 路径导致ui/和dicts/相对路径失效报FileNotFoundError: ui/login.ui直接python main.py启动最稳定且便于加调试参数如python -X dev main.py开启 Python 开发模式捕获更多异常细节。因此本文采用直接运行主脚本的方式cd WebCrack-v2.3.1 # 复制配置模板关键否则首次启动会崩溃 cp config/config.json.example config/config.json # 启动加 -X dev 参数便于排错 python -X dev main.py若看到图形窗口弹出标题栏显示 “WebCrack v2.3.1”即表示安装成功。此时不要急着输入 URL先做下一步验证。4. 首次运行配置与基础功能验证让第一个“admin/admin”请求真正发出去GUI 启动只是第一步。很多用户卡在“点了‘开始爆破’按钮进度条动了一下就停住”实际是请求根本没发出去——可能是代理设置错误、URL 格式不对、或字典路径未识别。本节带你逐项验证 WebCrack 是否真的具备 HTTP 通信能力。4.1 配置文件config.json的四个必改字段首次启动后WebCrack 会自动生成config.json但其中部分字段需手动修正才能正常工作{ timeout: 10, threads: 10, proxy: { http: , https: }, user_agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, save_result: true, result_path: ./results/ }必须修改的字段timeout建议设为15单位秒。某些老旧后台响应慢10 秒超时会导致大量TimeoutError被当失败处理threads不要设为 50。WebCrack 的线程池未做连接复用优化高并发下易触发OSError: [Errno 24] Too many open files建议初学者设为5proxy若你不需要代理必须将http和https的值设为null不是空字符串否则 WebCrack 会尝试连接http://这个无效地址proxy: { http: null, https: null }result_path确保路径存在且有写权限。Linux/macOS 下执行mkdir -p ./results chmod 755 ./results4.2 构建最小可测目标用 Python Flask 搭一个“假后台”别急着扫真实网站。先搭一个本地测试靶机验证 WebCrack 是否真能发请求、收响应。创建test_target.py# test_target.py from flask import Flask, request, jsonify app Flask(__name__) # 模拟一个简单登录接口POST /login参数 username/password app.route(/login, methods[POST]) def login(): data request.form user data.get(username, ) pwd data.get(password, ) if user admin and pwd admin: return jsonify({status: success, msg: Login OK}) else: return jsonify({status: failed, msg: Invalid credentials}), 401 if __name__ __main__: app.run(host127.0.0.1, port5000, debugFalse)安装 Flask 并启动pip install Flask2.2.5 python test_target.py此时访问http://127.0.0.1:5000/login应返回 405 Method Not Allowed说明服务已起用 curl 测试curl -X POST http://127.0.0.1:5000/login -d usernameadminpasswordadmin # 应返回 {status: success, msg: Login OK}4.3 WebCrack 界面操作填什么、点哪里、看哪里启动 WebCrack 后按以下顺序操作截图无法展示但步骤极简URL 输入框填http://127.0.0.1:5000/login注意末尾/login不是/用户名字段名填username对应 Flask 中request.form.get(username)密码字段名填password字典选择点击“选择字典” → 导航到WebCrack-v2.3.1/dicts/admin.txt该文件首行为admin第二行为root点击“开始爆破”。此时观察界面右下角状态栏应显示正在爆破... (1/1)终端中运行test_target.py的窗口应打印一行127.0.0.1 - - [DATE] POST /login HTTP/1.1 200 -表示请求已到达WebCrack 界面“结果列表”中应出现一行admin:admin → success状态码为200。如果没看到success行而是admin:admin → failed检查 Flask 日志是否收到usernameadminpasswordadmin若没收到说明 WebCrack 请求参数没发对——常见原因是“用户名字段名”填成了user或name与后端实际接收名不一致。5. 常见问题排查5 条血泪经验总结覆盖 90% 的“启动失败”场景WebCrack 的报错往往藏在 GUI 背后不打开终端看日志根本不知道哪错了。以下是我在 12 个不同环境Ubuntu/CentOS/macOS/Windows部署时踩出的 5 个高频坑按“现象→原因→解决”给出可立即执行的命令。5.1 现象双击main.py无反应终端执行python main.py报ModuleNotFoundError: No module named PyQt5原因当前 shell 的python命令指向的不是你用pyenv安装的 Python而是系统 Python如/usr/bin/python3而PyQt5只装在pyenv环境里。解决# 查看当前 python 指向 which python # 若输出 /usr/bin/python3则强制用 pyenv 的 python ~/.pyenv/versions/3.11.9/bin/python main.py # 或永久修复确保 pyenv 初始化已生效 echo $PATH | grep pyenv # 应看到类似 /home/user/.pyenv/shims 在最前5.2 现象GUI 启动后空白或报qt.qpa.plugin: Could not load the Qt platform plugin xcb原因Linux 下缺少libxcb系列库或LD_LIBRARY_PATH未包含 Qt 插件路径。解决# 先装缺失库Ubuntu/Debian sudo apt install -y libxcb-xinerama0 libxcb-xinput0 # 若仍报错手动指定插件路径PyQt5 安装后会生成 plugins 目录 python -c from PyQt5 import QtCore; print(QtCore.QLibraryInfo.location(QtCore.QLibraryInfo.PluginsPath)) # 假设输出 /home/user/.pyenv/versions/3.11.9/lib/python3.11/site-packages/PyQt5/Qt5/plugins export QT_QPA_PLATFORM_PLUGIN_PATH/home/user/.pyenv/versions/3.11.9/lib/python3.11/site-packages/PyQt5/Qt5/plugins python main.py5.3 现象点击“开始爆破”后进度条不动终端无任何输出过 30 秒自动停止原因config.json中proxy字段为空字符串WebCrack 尝试连接http://这个非法 URL阻塞在 DNS 解析。解决# 编辑 config.json将 proxy 改为 null nano config/config.json # 修改前 # proxy: { http: , https: } # 修改后 # proxy: { http: null, https: null }5.4 现象爆破结果显示admin:admin → failed但用 curl 测试http://127.0.0.1:5000/login返回success原因WebCrack 默认发送Content-Type: application/x-www-form-urlencoded但某些后台尤其老 PHP要求Content-Type: text/plain或忽略 header。WebCrack v2.3.1 不支持自定义 Content-Type。解决临时修改源码仅测试用# 编辑 core/brute.py找到 send_request() 方法 nano core/brute.py # 找到类似这一行约第 87 行 # response session.post(url, datapayload, timeouttimeout, headersheaders) # 在它前面加一行强制覆盖 Content-Type headers[Content-Type] application/x-www-form-urlencoded注意此修改仅用于验证通信链路正式使用请勿改动源码。5.5 现象加载字典时报UnicodeDecodeError: gbk codec cant decode byte 0x80Windows原因Windows 默认用 GBK 编码读文件但admin.txt是 UTF-8 编码含中文注释。解决用记事本另存为 UTF-8无 BOM格式或用 VS Code 打开后右下角点击编码 → “Save with Encoding” → “UTF-8”。6. 验证爆破有效性用 Burp Suite 抓包确认请求内容与响应解析装完、配好、GUI 能弹、本地靶机能扫不代表 WebCrack 真正“懂”爆破逻辑。它可能把admin or 11当普通字符串发过去而后端 WAF 却把它当 SQL 注入拦截了——你看到failed以为密码错其实是请求被丢弃了。真正的验证是亲眼看到 WebCrack 发出的每一个字节并确认它如何解析响应体中的成功标识。我用 Burp Suite社区版免费做了完整抓包验证过程可复现。6.1 配置 WebCrack 使用 Burp 代理首先启动 Burp Suite监听127.0.0.1:8080默认设置。然后修改config.jsonproxy: { http: http://127.0.0.1:8080, https: http://127.0.0.1:8080 }重启 WebCrack此时所有爆破请求都会经 Burp 中转。6.2 构造可验证的响应特征让后台返回明确的成功标记修改之前的test_target.py加入一个“万能密码”响应app.route(/login, methods[POST]) def login(): data request.form user data.get(username, ) pwd data.get(password, ) # 新增若密码是 123456 or 11返回特殊 success if user admin and pwd 123456 or 11: return jsonify({code: 200, message: Login Success!, data: {token: abc123}}) elif user admin and pwd admin: return jsonify({code: 200, message: Login OK}) else: return jsonify({code: 401, message: Invalid credentials}), 401重启 Flask。6.3 在 Burp 中观察 WebCrack 的真实请求与响应在 WebCrack 界面URL 填http://127.0.0.1:5000/login用户名字段名填username密码字段名填password字典选dicts/pass.txt并在其中添加一行123456 or 11点击“开始爆破”。此时切换到 Burp Suite 的Proxy → HTTP history标签应看到类似请求POST /login HTTP/1.1 Host: 127.0.0.1:5000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Accept: */* Content-Type: application/x-www-form-urlencoded Content-Length: 42 usernameadminpassword123456%27or%271%27%3D%271注意password参数已被 URL 编码→%27→%3D这是正确的。再看响应HTTP/1.0 200 OK Content-Type: application/json Content-Length: 78 {code: 200, message: Login Success!, data: {token: abc123}}关键来了WebCrack 如何判断这是“成功”它默认检查响应体中是否包含success、ok、200等关键词大小写不敏感或响应状态码为200。你可以在core/brute.py的is_success_response()方法中看到逻辑def is_success_response(response): # 检查状态码 if response.status_code 200: return True # 检查响应体关键词 content response.text.lower() for keyword in [success, ok, login, welcome]: if keyword in content: return True return False所以只要响应中含success哪怕在 JSON 的message字段里WebCrack 就会标为绿色success。6.4 验证“失败响应”的识别故意返回 200 但内容为 error为了确认 WebCrack 不是只看状态码我们再改一次 Flask# 若密码是 wrong返回 200 但 body 是 error if user admin and pwd wrong: return jsonify({code: 200, message: Internal Error!})用wrong作为字典项爆破Burp 中能看到请求发出、响应 200但 WebCrack 结果列表中显示wrong:wrong → failed——因为它解析response.text后没找到success/ok等词。这证明它的判断逻辑是健壮的。从那以后我每次部署 WebCrack都强制走一遍 Burp 抓包验证不看 GUI 是否弹窗只看请求是否发出、参数是否编码正确、响应是否被准确解析。这步多花 5 分钟能避免后续扫 100 个目标都“全失败”的玄学时刻。希望帮到你。本文还有配套的精品资源点击获取