[0xV01D]_Release Echo_writeUp

电脑小菜&

866人浏览 · 2026-05-27 16:49:29

电脑小菜& · 2026-05-27 16:49:29 发布

CTF 题解复盘：Release Echo (Git 底层对象解析与历史泄露)

📌 题目基本信息

题目名称：Release Echo
题目分类：Misc / Git 泄露 / 取证
Key Takeaway：在 Git 中，只要提交过，历史就不会被真正抹除（除非被 GC 回收）。删除文件只改变了当前树状结构的指针，敏感信息依然安静地躺在 .git/objects 目录中。
Flag：0xV01D{HISTORY_REMEMBERS}

🕵️‍♂️ 解题流程复盘

第一步：识别乱码与文件类型

现象：拿到一个文件，用文本编辑器打开全是乱码（包含生僻汉字、不可见字符等）。
分析：将文件拖入十六进制编辑器（如 HxD），发现文件头为 78 01。
结论：78 01 是 Zlib 压缩数据的特征头（Deflate 算法，最快压缩级别）。这说明文件不是普通文本，而是经过 Zlib 压缩的二进制数据。

第二步：解压并识别 Git Commit 对象

动作：使用 Python 的 zlib.decompress() 解压数据。

现象：解压后出现明文内容：

tree 49c4d64d595fb618b44947a1fdec4187ce505f3e
parent 1d8be508f5788a85edb1e0b3a8d08242f075ed0b
author CTF Builder <ctf@example.local> 1779008512 +0300
committer CTF Builder <ctf@example.local> 1779008512 +0300

clean release notes

结论：这是 Git 内部的 Commit 对象。
关键线索：
1. 存在 parent，说明这不是初始提交，有历史版本。
2. 提交信息 clean release notes（清理发布说明），强烈暗示当前版本删除了敏感信息，敏感信息在 parent 指向的历史版本中。

第三步：解压并识别 Git Tree 对象

动作：顺着 parent 的哈希值，找到并解压历史版本的 Commit 对象，进而找到其指向的 Tree 对象并解压。

现象：解压 Tree 对象后，出现如下结构：

100644 README.md␀[20字节二进制乱码]
100644 daily_note.txt␀[20字节二进制乱码]

分析：这是 Git Tree 对象的标准格式（文件模式文件名 \0 20字节的SHA1二进制哈希）。乱码是因为 40 位的 16 进制哈希被以原始二进制形式存储了，文本编辑器无法正常解析。
结论：历史版本中存在 daily_note.txt，这就是被“清理”掉的文件。

第四步：穿透底层，直接提取文件

动作：如果继续手动解析，需要将二进制乱码转回 40 位 16 进制哈希，再去 objects 目录找对应的 Blob 文件解压，非常繁琐。既然已经处于一个完整的 .git 目录下，直接使用 Git 高层命令。

命令：

git show 1d8be508f5788a85edb1e0b3a8d08242f075ed0b:daily_note.txt

结果：

release note
flag: 0xV01D{HISTORY_REMEMBERS}

🧠 核心知识点总结

1. Git 底层存储结构 (The Git Object Model)

Git 是一个内容寻址文件系统，其核心是四种对象：

Blob：存储文件内容（纯数据）。
Tree：存储目录结构（类似目录，指向 Blob 或子 Tree）。
Commit：存储快照信息（指向一个顶层 Tree，包含作者、时间、提交信息及父提交）。
Tag：标签（本题未涉及）。

它们的关系是：Commit -> Tree -> Blob。

2. Git 对象的压缩存储

Git 为了节省空间，所有对象（无论多小）都会使用 Zlib 进行压缩后存储在 .git/objects/ 目录下。

常见 Zlib 文件头：78 01 (最快压缩), 78 9C (默认压缩), 78 DA (最大压缩)。看到这些头，应立刻联想到 Git 对象。

50 4B 03 04 = ZIP
1F 8B 08 = gzip
44 49 52 43 = Git index
89 50 4E 47 = PNG

3. Tree 对象中的二进制哈希

在 Tree 对象中，子对象的 SHA-1 哈希是以 20 字节的原始二进制 形式紧接在文件名后面的 \0 之后存储的，而不是我们常见的 40 位十六进制字符串。这是手动解析 Tree 时最容易卡住的地方。

4. Git 的“不可变”特性与安全风险

Git 的设计理念是：一旦创建，对象不可修改。
当你在仓库中“删除”一个文件并提交时，Git 只是创建了一个新的 Tree 对象，这个新 Tree 里不再指向那个文件的 Blob。但是，旧的 Commit、旧的 Tree、以及那个文件的 Blob 依然安然无恙地躺在 .git/objects 目录里。

风险：开发者常常误以为 git rm 并提交后，文件就彻底消失了。如果将 .git 目录意外暴露（如网页源码泄露 .git），攻击者可以通过回溯历史提交，轻松找回已删除的密码、密钥和配置文件。
正确做法：如果必须从历史中彻底抹除敏感文件，需要使用 git filter-branch 或 BFG Repo-Cleaner 重写历史，并强制垃圾回收 (git gc --prune=now)。

🛠️ 常用工具与命令备忘

场景	命令 / 工具	说明
识别文件类型	`file <filename>` / HxD	查看是否为 Zlib 压缩数据
手动解压 Git 对象	`python -c "import zlib; print(zlib.decompress(open('file','rb').read()))"`	快速在命令行查看解压内容
查看 Git 对象类型	`git cat-file -t <hash>`	返回 commit / tree / blob
查看 Git 对象内容	`git cat-file -p <hash>`	格式化打印对象内容（自动将二进制哈希转为16进制）
直接提取历史文件	`git show <commit_hash>:<filepath>`	最常用取证命令，跳过繁琐的底层解析，直接看指定提交的文件内容
对比两个版本的差异	`git diff <hash1> <hash2>`	快速找出被“清理”或篡改的内容