这次最终找回了密码：7 位小写字母。原始 ZIP 可以正常打开，完整 TXT 已提取，另外生成的去密码副本也通过了完整 CRC 检查和解密内容的逐字节比对，原文件没有改动。

最后一轮搜索在 M1 Max 的 CPU 上用了 29.3738 秒，检查了 5,481,468,352 个候选后命中。但整个探索远不止这半分钟。此前我试过密码变体、纯数字枚举，又拿着文本预览反复尝试已知明文攻击，其中一轮 175 个位置组合就花了约 32 分钟，全都失败。

密码找回后，我又在确认过的正确偏移上做了已知明文攻击，不输入已知密码或内部状态，也独立恢复出了相同状态，全文解密一致。前期的问题确实出在位置搜索上；枚举突然变快，则是因为我终于开始检查每个错误候选到底浪费了多少计算。下面只记录方法和匿名实验数据，不保留真实文件内容、密码或内部密钥。

最近一段时间，我在 M1 Max 上连续试了两个刚开放权重的 MiniMax 模型：负责视频与音频联合生成的 H3，以及负责音乐生成的 Music 3。

这台机器是 64GB 统一内存、24 核 GPU。参数看起来不差，但面对几十 GB 的模型，“能不能跑”仍然不是看一眼内存容量就能回答的问题。权重能不能装下、运行时有没有 Apple Silicon 路径、真正生成一次要等多久、最后的东西值不值得留下，都是不同的问题。

我也不想为了抢一个“首跑”去下载几十 GB，再花半天证明某个尚未成熟的转换根本不能用。所以这次的过程有不少等待：先看上游实现，找社区量化，等别人给出 Mac 实测，确认有退路以后才动手。两个模型最后都跑通了。然后，我把 51GB 左右的权重删了。