用途与实际影响
这项功能怎样使用
为什么需要它
图片查看器可能忽略尾部字节，但分享平台可能重新编码整张图，把尾部丢掉。把“封面能打开”和“保险库仍完整”混成一件事，会让损坏的载体看起来一切正常。
举个实际例子
“把这份已经加密的文件放在这张封面图片后面，再取出来确认没有改变。”工具建立载体并提取，比较密文大小与哈希；如果准备经过会压缩图片的平台，先明确这种传递方式不保证保留载荷。
最后我会得到什么
得到携带密文的图片文件，以及提取后的 vault.recovered.enc 或本人指定路径；成功取回需要字节一致。没有重新提供密码时只能证明密文保留，不能证明里面内容已恢复。
正常时
密文被追加并可从完整载体中提取，取回字节与原密文一致。
发现问题时
图片重编码、转存或尾部长度异常时，外观可能仍正常，但提取失败或哈希不符。
入口不可用或证据不足时
不是带本工具标记的载体、文件不可读或目标不明确时停止，不猜图里藏了什么。
从哪里开始
在本机 vault-tool 使用 hide，把已有密文与封面图片写成新的载体；取回时用 unhide 指定独立输出路径。
需要准备什么
- 已有密文和封面图片
- 新载体及提取文件的保存位置
从开始到拿到结果
- 1
选定已有密文和封面
这是给密文加图片载体，先确认密文本身已生成且另有恢复条件。
- 2
写入并取回
工具把密文附在图片字节后，再从载体提取到独立文件。
- 3
比较密文字节
核对原密文与提取物完全相同；图片能打开不等于密文可恢复，重编码也可能破坏尾部。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
图片尾部追加与密文提取已实现关键规则与设计选择
这里是文件尾部封装，不是像素级隐写，也不增加一道加密。
传递原文件与发送经过图片压缩的照片不同。
应保留独立密文副本，不能只靠封面显示正常判断恢复。
本模块用到的名词
- carrier（文件载体）
- 携带另一段数据的完整文件；这里靠保留文件尾部字节实现。
- steganography（隐写）
- 本工具使用这个命名，但实现是图片尾部追加，不应让读者误以为修改像素或不可检测。
- re-encoding（重新编码）
- 图片平台或软件重新生成图像字节，可能保留外观却删除追加密文。
专业定义
不改照片像素来藏字；用完整图片文件携带已有密文，并验证可原样取回。
解决什么
防止把图片外观当作密文完整性证据，以及把载体封装说成新的加密算法。
当前怎样实现
- hide_in_image 顺序写入封面原字节、密文、8 字节长度和尾标 VLTSTEG1；不解密密文、不修改像素或加入新的密码派生。
- extract_from_image 从文件末尾检查标记和长度，再截取对应载荷；标记错误或长度范围不成立时拒绝。
- CLI（命令行工具） hide 使用当前工具的 vault.enc；--cover 选封面，--out 指定载体。unhide 的默认输出为 vault.recovered.enc，避免默认覆盖原维护库。
- 扩展名、查看器能显示和实际图片格式有效是不同问题；实现没有对所有图片软件、社交平台或重编码器做兼容保证。
- 应对提取结果检查尺寸和 SHA-256，必要时再由本人用正确凭据实际打开；两步分别证明密文保全和内容可恢复。
执行流程
- 1
明确已有密文、封面与输出路径。
- 2
把密文和长度标记追加到封面字节之后。
- 3
用 unhide 提取到独立路径。
- 4
比较原密文与取回密文的字节或哈希。
- 5
如需确认内容恢复，再由本人本地提供对应凭据；不把图片外观当验收。
边界
- 没有证明所有 JPEG/PNG 查看器均接受载体，或所有平台传递后仍能恢复。
- 坏载体不能凭原来的图片外观补回丢失密文。
- 本功能不自动上传、分享或公开任何图片。
失败与恢复
- 只是普通封面，没有尾标
- 拒绝提取，不把任意尾部字节当成保险库。
- 载体被截断或长度超出范围
- 报告载体不完整，保留原文件，不输出伪造恢复成功。
- 图片仍可显示但提取哈希不符
- 密文保全未通过，应回到独立原密文副本，而不是继续尝试猜密码。
真实入口
E:\Projects\Tools\vault-tool\vault_tool.pyhide_in_image、extract_from_image 与命令行参数
E:\Projects\Tools\vault-tool\test_vault_tool.py载体往返、普通封面与错误输入回归
如何验证
- 本轮虚构载体为 65,619 B，取回的密文哈希与原 65,536 B 容器一致；普通封面被拒绝。
- 该结果只证明这组原样文件的封装与提取，没有实际分享平台或图片重编码验收。
与其他模块的关系
这里保存和取回的是已经加密的字节；密码、内容查看和远端备份仍由各自模块承担。