安全的环境是CTF比赛里最舒服的地方——你面对的是一道被精心设计过的虚拟靶题，所有操作都限定在题目附件里，没有任何真实目标牵涉其中。这篇要聊的是美团CTF里那道叫"Boom"的杂项题，它把两条看起来毫不相干的密码线拧在了一起：一条是KeePass的.kdbx数据库文件，另一条是一张看起来人畜无害的图片，而破解这两者的关键词就是hashcat、KeePass、stegpy隐写。这类题在杂项（Misc）里属于典型的"工具链组合题"，它不考验你写代码的能力，考验的是你能不能第一时间认出文件类型、选对工具、选对参数。适合刚入门的CTF玩家，也适合那些看到二进制附件就发懵、习惯性先chaos一遍的老哥。我把自己完整走一遍的流程、参数计算、踩过的坑都整理出来，你可以直接照着复现。

1. 题目背景与整体破解思路拆解

1.1 从附件到突破口：先看清题目给了什么

拿到Boom这道题的附件，通常是一个压缩包，解开之后你会发现里面躺着两类东西：一个后缀是.kdbx的文件，还有一张.png或者.jpg的图片。很多新手第一步就卡住了——这两个文件之间到底什么关系？是独立的两个小题，还是存在先后依赖？我的判断逻辑很直接：先做文件类型指纹识别，看清它们分别是什么，再判断有没有解密依赖。

.kdbx是KeePass密码管理器生成的加密数据库，它内部用AES或者ChaCha20加密，密钥由主密码经过大量迭代派生而来，本身是一个"拿来即用"的加密容器。图片文件则要看它的元数据、二进制尾部有没有附加数据。这两者并列出现，八成是两道关：KeePass里可能藏着下一步的提示或者密码，图片里才是最终flag。也可能是反过来的——图片里藏着KeePass的主密码。这种"谁先谁后"的判断，决定了你整个解题的节奏，急不得。

我一般会把附件都放到一个干净的工作目录，先跑一轮file命令看真实类型，再跑strings扫一遍可打印字符串，很多时候flag的格式提示或者密码暗示就藏在里面。做杂项题最忌讳的就是一上来就狂上工具，先把题目"看"清楚，比什么都强。

1.2 两条独立的密码线：KeePass与stegpy的关系

把附件拆开看，这道题本质上是两个独立的密码恢复问题。第一条线是KeePass数据库：你需要恢复它的主密码才能打开数据库，看到里面存了什么。第二条线是图片隐写：这张图用stegpy做过隐写加密，同样需要密码才能提取出隐藏内容。

两条线的共同点是——都要爆破密码。区别在于工具和策略完全不同。KeePass的爆破要用到hashcat这类专业密码恢复工具，因为它支持从.kdbx里提取出标准哈希，然后把哈希丢给GPU并行运算；而stegpy的隐写解密更像是在一个纯Python工具上做密码字典遍历，速度慢得多，所以密码强度通常不会太高，属于可以穷举的范围。

我判断这道题的设计意图是这样：出题人希望你掌握"从加密容器中正确提取哈希"和"对隐写工具做针对性爆破"这两个核心技能。这两者都不是点一个按钮就完事，中间有参数、有坑。理解了这一点，你的整个解题路径就清晰了：先处理KeePass（因为它可能提供图片的密码），再处理图片拿到flag。当然实际做题时我会两条线并行推进，谁先出结果谁就是突破口。

2. KeePass数据库识别与哈希提取实操

2.1 .kdbx文件的识别与验证

第一步永远是把文件类型确认死。跑一条file database.kdbx，正常会返回类似“KeePass password manager database (KDBX 3.1/4.0)”的信息。如果返回的是“data”或者别的什么，那说明附件可能被二次处理过，比如加了文件头混淆、被压缩、或者被追加了垃圾数据，这时候就要用binwalk或者xxd看它的头部魔数。KDBX 4.0的魔数是0x03D9A29A开头的签名，KDBX 3.x则是另一套签名，记不住没关系，file命令加binwalk -e基本够用。

验证完类型，我会做一次备份。这看起来是废话，但KeePass的哈希提取和后续爆破都是只读操作，理论上不会破坏原文件，可一旦你手抖改了文件，或者用某些工具带--fix之类的参数，就有可能损坏它，导致后面提取不出来。备份一次的成本几乎为零，收益是保命的。

还有个小细节：如果题目附件里.kdbx文件很小，只有几KB，别怀疑，这很正常——里面可能只存了一条记录甚至只是一段提示。真正的价值在于里面的内容，不在于大小。我见过有人看到文件小就以为文件损坏了，白白浪费十几分钟。

2.2 keepass2john提取哈希的关键细节

KeePass本身不直接给你哈希，需要借助工具从数据库文件里把"验证哈希"提取出来。最常用的就是keepass2john，它是John the Ripper工具套件的一部分，也有独立的Python封装版本。基本命令是：

keepass2john database.kdbx > keepass.hash

执行完看一眼输出文件，正常内容长这样：

database:$keepass$*2*60000*0*<一串base64>*<一串base64>*<一串base64>*<一串base64>*<一串base64>

这里面的字段每个都有含义，理解它们对后面的爆破很重要。第一个2表示数据库使用的加密算法是AES（版本号），紧跟着的60000是密钥派生的迭代次数，也就是KDF rounds。这个数字直接决定了你爆破的难度——迭代次数越高，每秒能尝试的密码数就越少。如果出题人用的是KDBX 4.0并且设了很高的迭代次数（比如几十万甚至上百万），那爆破速度会断崖式下降，这时候就必须重新审视策略，是不是密码强度其实很低、只是迭代次数拖了后腿。

注意：如果你用的是较新版本的keepass2john，可能需要在命令后加上-k或者留意它对KDBX 4.0的支持情况。旧版本工具提取KDBX 4.0有时会失败，报错或者输出空文件，这时候换用最新的John源码编译版本，或者找Python版的脚本。

提取完成后用cat看一眼，如果只有文件名加冒号后面空空如也，说明提取失败，别急着往下走，先解决提取问题。这一步是整个流程的地基，地基歪了后面全白费。

2.3 为什么要提取哈希而不是直接暴力

有人会问，既然我有hashcat，为什么不直接对.kdbx文件本身做爆破，非要提取哈希？原因在于效率。KeePass文件是一个完整的加密容器，里面有头部、校验、加密数据块，每次验证密码都要把整个文件读进来、解析头部、派生密钥、解密并校验，这一套流程开销极大。而提取出来的哈希是"最小验证单元"，它只保留了验证主密码所需的核心数据，hashcat可以拿它在GPU上高强度并行计算，每秒的尝试次数能提升好几个数量级。

打个比方，直接对文件爆破就像每进一次门都要把整栋楼走一遍；提取哈希则相当于只拿门锁的密码校验值去试，省掉了所有无关步骤。这就是为什么专业密码恢复流程里，"提取哈希"永远是第一步。

另外，提取哈希还有个附带好处：它把密码验证和文件解密解耦了。即使你后面把哈希跑出来了，原始.kdbx文件也没有被任何暴力过程触碰过，密码一旦恢复，你再用KeePass客户端正常打开即可，数据完整性完全没问题。

3. hashcat掩码爆破核心参数与实战

3.1 攻击模式选择：字典还是掩码

hashcat支持多种攻击模式，最常用的两种是字典攻击（-a 0）和掩码攻击（-a 3）。选哪个，取决于你对密码特征的判断。字典攻击适合你手上有高质量字典、密码看起来像常见词组或泄露密码的情况；掩码攻击适合密码有固定格式、可以用字符集描述的情况，比如纯数字、固定前缀、特定长度。

Boom这道题的关键线索往往藏在别处——可能是图片的元数据里、可能是某个文件名里、也可能题目描述里就暗示了"6位数字"或者"小写字母加数字"。拿到线索后，判断密码的结构，就能决定用掩码。如果密码是6位纯数字，掩码就是?d?d?d?d?d?d，搜索空间10的6次方，一百万种组合。如果密码是4位小写字母，掩码就是?l?l?l?l，搜索空间26的4次方，约45万种。

我的选择原则是：能确定结构就用掩码，结构不确定但怀疑是常见弱密码就用字典，两者都吃不准就先上小字典快速排除，再补掩码。不要一上来就上超大字典，特别对KeePass这种慢哈希，浪费时间。

3.2 掩码与字符集的参数计算

哈希模式必须选对。KeePass在hashcat里的模块编号是13400，这个记牢：

字符集的对应关系：?l是小写字母a-z，?u是大写A-Z，?d是数字0-9，?s是特殊符号。还可以自定义字符集，用-1参数指定，比如你确定密码只包含abc123这几个字符，就可以定义-1 abc123，然后掩码用?1?1?1?1?1?1，这样搜索空间大幅缩小。

这里有个计算习惯我推荐你养成：先算出搜索空间大小，再结合hashcat当前硬件速度估算时间。比如6位纯数字是100万种，如果你机器跑KeePass每秒1万次，那理论上100秒跑完；如果每秒只有1000次，那就是1000秒，约17分钟。心里有数了，就不会干等的时候慌。

提示：KeePass的迭代次数直接拖慢速度，看到60000这样的rounds，心里要有个预期，它比MD5、NTLM这类无迭代哈希慢几个数量级。

3.3 命令组装与运行观察

把参数拼起来，一条典型的命令是：

hashcat -m 13400 -a 3 keepass.hash ?d?d?d?d?d?d -O -w 3

逐项解释：-m 13400指定KeePass模式，-a 3是掩码攻击，keepass.hash是哈希文件，?d?d?d?d?d?d是6位数字掩码。-O是启用优化内核，能提升速度，但会限制最大密码长度（一般够用，短密码不受影响）。-w 3是工作负载档位，3代表高负载，适合桌面独显长时间跑；如果是笔记本或者共享机器，建议用-w 2避免过热。

运行起来后，hashcat会先做一轮自检，如果哈希格式有问题会直接报错退出，比如提示"Token length exception"或者"Signature mismatch"，这就是格式不匹配。自检通过后开始跑，界面会实时显示进度、速度（H/s）、预计剩余时间。你要盯的是几件事：速度是否正常、是否有报错、进度百分比是否在动。一旦出现Status...........: Cracked，说明密码出来了，hashcat会把它显示在结果区，同时可以用hashcat -m 13400 keepass.hash --show复查已破解的记录。

如果跑完一圈显示Exhausted而不是Cracked，说明掩码范围不对，密码结构判断错了。这时候别急着重跑更大的范围，回头检查线索——是不是密码位数估计错了？是不是包含了大写或者符号？是不是其实该用字典？重新定位比盲目扩大搜索空间高效得多。

拿到KeePass主密码后，用KeePass客户端打开.kdbx，里面通常存着一条记录，字段可能写着"图片密码"或者直接就是一段提示。这就是第二条线的钥匙。

4. stegpy隐写提取与密码爆破

4.1 stegpy的加密原理与识别方法

stegpy是一个Python写的隐写工具，跟那些只做无损LSB藏数据的工具不同，它支持用密码对隐藏数据进行加密后再嵌入图片。也就是说，就算你发现图片里藏了东西，没有密码也提取不出来。它的工作原理大致是：用密码经过密钥派生函数生成密钥，对要隐藏的数据做加密，然后把密文按位嵌入到图片像素的最低有效位里。

识别图片是否被stegpy处理过，可以从几个方向入手。第一，看文件大小和图片分辨率是否匹配——如果一张分辨率不高的图却有异常大的文件体积，说明多出来的空间可能藏了数据。第二，用binwalk扫，看有没有可疑的附加段。第三，直接拿stegpy去尝试提取，如果它提示需要密码，那就是确认了。stegpy的提取命令通常是：

stegpy hidden.png

如果图片没有加密，它会直接提取；如果需要密码，它会提示输入，或者用-p参数指定。注意，stegpy和普通LSB隐写工具（比如各种CTF里常见的那些）不是一回事，它的加密机制意味着你必须走密码恢复这条路，不能靠简单的位分析绕过。

4.2 爆破脚本编写与性能优化

stegpy本身没有内置爆破功能，你需要自己写脚本去遍历密码字典。核心思路就是循环尝试每个候选密码，捕获异常，直到成功。因为stegpy是纯Python实现的，速度不快，所以密码不可能太复杂，通常就是几百到几万次的量级。

一个可用的爆破脚本框架大致是这样：

import subprocess wordlist = ["123456", "password", "admin888"] # 换成你的候选集 image = "hidden.png" for pwd in wordlist: try: result = subprocess.run( ["stegpy", image, "-p", pwd], capture_output=True, text=True, timeout=5 ) if result.returncode == 0 and "flag" in result.stdout.lower(): print(f"[+] 密码找到: {pwd}") print(result.stdout) break except subprocess.TimeoutExpired: continue

这段脚本的关键点有几个。第一，用subprocess调用stegpy而不是自己重写解密逻辑，省事且准确。第二，timeout必须加，防止某个密码卡住导致脚本hang死。第三，判断成功的条件要灵活——stegpy解密成功通常会输出隐藏数据，你可以用是否包含flag或者返回码来判断。如果stegpy版本对错误密码是抛出异常而不是返回非零码，那你还要在循环里try/except捕获它打印的报错信息。

如果密码空间是纯数字，比如4到6位，那就用itertools.product或者range生成，别去下载大字典。自己生成既快又能控制范围：

for i in range(1000000): pwd = f"{i:06d}" # 尝试 pwd

生成的时候注意补零，f"{i:06d}"保证不足6位前面补0，避免漏掉000123这种。

4.3 拿到flag与二次验证

密码一旦爆破成功，stegpy会把隐藏内容输出到终端，通常就是flag，格式一般是flag{...}或者题目指定格式。拿到之后别急着交，做两件事验证：一是确认真实性，看看格式对不对、有没有被截断；二是检查有没有多层隐写——有些题会在图片里藏多层数据，第一层提取出来的是一段提示，提示你还有第二层。

我遇到过的情况是，第一层提取出来是一串base64，解码后又是另一张图片的路径提示，需要继续套娃。所以拿到结果后，习惯性地看看输出内容是直接的flag、还是编码过的字符串、还是新的文件名。Boom这道题按设计应该是单层，但养成这个检查习惯能帮你应对更多变种。

注意：stegpy提取时如果输出乱码，可能是密码错误、或者提取的是加密后的原始字节。确认密码正确的情况下，试试把结果保存成文件再用file判断类型。

5. 常见问题与排查技巧实录

5.1 KeePass哈希提取失败的几种情况

提取这一步坑最多，我整理了一张速查表：

最常见的坑是工具版本。keepass2john这个工具在不同John版本里行为不一致，有的对KDBX 4.0支持不完整，提取出来的哈希hashcat认不了。解决办法是直接去John的官方仓库拉最新源码自己编译，或者用Python的keepass2john.py脚本，它对4.0的支持通常更新得及时。

另一个坑是路径问题。很多人用相对路径跑工具，结果输出文件跑到别的目录去了，或者文件名里有特殊字符导致重定向失败。我的习惯是全程用绝对路径，输出文件也写到明确的位置，跑完马上ls -la确认文件存在且非空。

5.2 hashcat跑不动或跑得慢的排查

hashcat跑不动，第一反应看报错信息。如果提示"CL_EXEC_BUILD"或者涉及OpenCL的，说明GPU驱动或者OpenCL运行时没装好。hashcat有两种后端，一种走GPU（OpenCL/CUDA），一种走CPU。如果GPU环境有问题，可以用--force强制跑，或者显式指定-D 1用CPU，但CPU跑KeePass会非常慢，只适合小搜索空间。

速度慢的另一个常见原因是迭代次数高。前面提到的60000这个rounds，如果题目用的是几十万甚至更高的迭代，那速度自然会掉。这时候策略比蛮力重要——把搜索空间压到最小。比如确认是4位数字就绝不跑5位，确认只含小写就跑?l不跑?a。

还有个玄学问题：hashcat显示的速度是"当前"速度，会随温度、功耗墙波动。跑一会儿速度掉了，可能是显卡过热降频。这时候降低工作负载档位反而整体更稳。

5.3 stegpy爆破解密失败的坑

stegpy爆破失败的排查思路跟hashcat不太一样，它是脚本层面的事。第一，确认你调用的stegpy版本和出题人用的是同一个大版本，不同版本的默认加密参数可能有差异，导致同一个密码解不出同样的数据。第二，确认密码字典覆盖了正确密码，位数、大小写、字符集都要考虑进去。第三，确认脚本判断成功的逻辑没写错——有的版本解密成功是静默返回，不打印任何东西，只把数据写进了输出文件，这时候你判断stdout就永远为假。

我特别想强调判断逻辑这一点。写爆破脚本最容易犯的错，就是把"成功条件"写死成某种特定输出。稳妥的做法是：先手动用几个明显错误的密码跑一遍stegpy，观察它的报错长什么样、返回码是什么，然后反过来把这些特征当成"失败标志"，剩下的情况就都算成功。这样比猜成功条件可靠得多。

还有一点，子进程调用要注意编码。stegpy输出的隐藏数据可能包含二进制字节，用text=True可能会因为解码错误抛异常。遇到这种情况，去掉text=True，用capture_output=True拿字节流，自己判断里面有没有b'flag'这种特征串。