[0xV01D]_Release Echo_writeUp

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() 解压数据。

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

text 复制代码

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 对象后，出现如下结构：

text 复制代码

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 高层命令。

命令：

bash 复制代码

git show 1d8be508f5788a85edb1e0b3a8d08242f075ed0b:daily_note.txt

结果：

text 复制代码

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>`	快速找出被"清理"或篡改的内容