陈仲凯1. 为什么需要定时保存hashcat破译进度
在密码破解的实际操作中，hashcat的破译过程往往需要持续数小时甚至数天。我遇到过太多次因为系统崩溃、断电或人为误操作导致进度丢失的情况。特别是在使用GPU集群进行大规模破解时，这种意外中断带来的损失更为严重——你可能已经跑了72小时，结果因为一个意外又要从头开始。
hashcat默认会在正常退出时自动保存进度（生成.restore文件），但这远远不够。现实情况中，我们经常遇到：
- 系统突然断电或死机
- 远程SSH连接意外断开
- 人为误操作强制终止进程
- 显卡驱动崩溃导致进程异常退出
这些情况下，.restore文件要么不会生成，要么内容不完整。通过定时自动保存进度，我们可以将损失控制在最近一次保存的时间点内。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. hashcat进度保存的核心机制
2.1 restore文件的工作原理
hashcat的.restore文件实际上是一个状态快照，记录了以下关键信息：
code复制会话名称 | 哈希类型 | 攻击模式 | 当前字典位置
已尝试的组合数 | 恢复点时间戳 | 硬件配置指纹
这个文件采用二进制格式存储，不能直接编辑。当使用--restore参数时，hashcat会读取这些信息并从中断处继续。
2.2 自动保存的触发条件
hashcat在以下情况会自动生成/更新.restore文件：
- 正常退出（Ctrl+C或收到TERM信号）
- 每完成一个字典区块（约每5-10分钟）
- 使用--session参数时定期保存
但问题在于：这些自动保存点间隔可能过长，且无法应对意外崩溃。
3. 实现定时自动保存的三种方案
3.1 使用Linux定时任务+信号通知
这是最可靠的方案，适合Linux服务器环境。具体步骤：
- 创建监控脚本
/usr/local/bin/hashcat_monitor.sh：
bash复制#!/bin/bash
PID=$(pgrep -f "hashcat.*--session")
if [ -z "$PID" ]; then
exit 0
fi
# 每15分钟发送USR1信号强制保存
while kill -USR1 $PID 2>/dev/null; do
sleep 900
done
- 设置可执行权限并创建systemd服务：
bash复制chmod +x /usr/local/bin/hashcat_monitor.sh
- 创建
/etc/systemd/system/hashcat-save.service：
code复制[Unit]
Description=Hashcat Auto-Save
[Service]
ExecStart=/usr/local/bin/hashcat_monitor.sh
Restart=always
[Install]
WantedBy=multi-user.target
- 启动服务：
bash复制systemctl daemon-reload
systemctl enable --now hashcat-save
关键点：USR1信号会强制hashcat立即保存进度而不中断当前任务，比直接kill更安全。
3.2 Windows下的计划任务方案
对于Windows用户，可以通过PowerShell脚本实现类似功能：
- 创建
HashcatAutoSave.ps1：
powershell复制$hashcat = Get-Process hashcat -ErrorAction SilentlyContinue
if (!$hashcat) { exit }
# 发送Ctrl+C等效信号
$sig = @"
[DllImport("kernel32.dll")]
public static extern bool GenerateConsoleCtrlEvent(int dwCtrlEvent, int dwProcessGroupId);
"@
Add-Type -MemberDefinition $sig -Name NativeMethods -Namespace Kernel32
[Kernel32.NativeMethods]::GenerateConsoleCtrlEvent(0, $hashcat.SessionId)
Start-Sleep -Seconds 5 # 等待保存完成
# 重新启动hashcat（假设使用--restore参数）
Start-Process "hashcat.exe" -ArgumentList "--restore"
- 创建计划任务，设置每20分钟运行一次该脚本。
注意：此方法会短暂中断进程，适合可以容忍短暂停顿的场景。
3.3 使用screen/tmux会话持久化
对于命令行环境，可以结合终端复用器实现自动保存：
bash复制# 使用tmux创建持久会话
tmux new -s hashcat_session
hashcat --session mytask -a 3 ?l?l?l?l?l?l
# 在另一个终端中设置定时保存
while true; do
tmux send-keys -t hashcat_session C-c
sleep 300
tmux send-keys -t hashcat_session "hashcat --restore" Enter
done
这种方法虽然原始，但在任何SSH环境下都能工作，不需要root权限。
4. 高级配置与优化技巧
4.1 调整hashcat的保存频率
在hashcat命令中添加这些参数可以优化保存行为：
code复制--restore-file-path /mnt/backup/ # 自定义保存位置
--restore-disable # 禁用自动保存（配合外部脚本时使用）
--session-save-frequency 10 # 每10分钟保存一次（仅限某些版本）
4.2 多备份策略
为防止.restore文件损坏，建议实现轮转备份：
bash复制#!/bin/bash
# 每天零点创建时间戳备份
cp /path/to/hashcat.restore "/backup/hashcat_$(date +%Y%m%d).restore"
# 保留最近7天的备份
find /backup -name "hashcat_*.restore" -mtime +7 -delete
4.3 监控脚本增强版
以下脚本增加了邮件报警和状态检查：
bash复制#!/bin/bash
PID=$(pgrep -f "hashcat.*--session")
[ -z "$PID" ] && exit 0
# 检查上次保存时间
LAST_SAVE=$(stat -c %Y /path/to/hashcat.restore 2>/dev/null || echo 0)
NOW=$(date +%s)
DIFF=$((NOW - LAST_SAVE))
if [ $DIFF -gt 1800 ]; then # 超过30分钟未保存
echo "Hashcat not saving properly!" | mail -s "Alert" admin@example.com
kill -USR1 $PID
fi
5. 常见问题排查
5.1 restore文件无效的情况
症状：恢复后hashcat重新开始破解
可能原因：
- 硬件配置变更（如更换GPU）
- hashcat版本不一致
- 原始命令参数改变
解决方案：
bash复制# 查看.restore文件兼容性
strings hashcat.restore | grep -E "version|device"
5.2 保存过程中的性能影响
强制保存会导致hashcat暂停工作1-3秒（取决于字典大小）。建议：
- 在业务低峰期执行保存
- 避免使用机械硬盘存储.restore文件
- 对大字典使用--restore-disable配合外部脚本
5.3 分布式环境下的特殊处理
当使用多节点破解时，每个节点需要独立保存进度。推荐方案：
- 主节点通过SSH向各worker发送保存信号
- 使用共享存储（NFS）集中管理.restore文件
- 定期合并各节点进度：
bash复制hashcat --restore --outfile-format 1-15 merged.out *.restore
6. 实际案例：百万级密码破解的保存实践
在某次企业渗透测试中，我们需要破解一个包含200万条NTLM哈希的列表。配置如下：
- 8台GPU服务器（每台4×RTX 4090）
- 预计耗时约96小时
- 使用组合攻击模式（?l?l?l?l?d?d?d）
实施方案：
- 每台服务器运行独立的hashcat实例
- 通过Ansible批量部署保存脚本（每20分钟保存）
- 使用inotifywait监控.restore文件变化并同步到NAS
- 每天凌晨3点执行完整性校验
结果：
- 在第52小时遭遇机房断电
- 通过恢复机制，仅损失18分钟进度
- 最终比预计时间提前7小时完成全部破解
关键配置片段：
bash复制# inotify监控脚本
inotifywait -m -e close_write /hashcat/ |
while read path action file; do
rsync -avz /hashcat/*.restore nas:/backup/
done