简介Git_Extract.zip是一套面向Git目录泄露场景的Python3工具包专为安全专家、渗透测试人员及开发工程师设计用于从Web公开目录中快速检测并提取意外暴露的.git目录通过模拟Git命令还原提交记录、分支结构及文件内容从而评估源代码、账号口令、数据库连接信息等敏感数据的外泄风险。压缩包共10个文件包含5个py脚本、4个pyc编译文件及1个markdown说明文档整体仅13KB轻量便携py文件承担索引解析、对象提取等核心逻辑pyc作为运行时辅助模块md提供使用步骤与原理讲解目录结构清晰便于按需复用。已有942人学习/下载可应用于渗透测试和应急响应两个主要场景。该工具既能充当泄露取证利器也能用于日常安全巡检帮助识别因服务器配置不当或.gitignore疏漏造成的隐患结合其生成的扫描日志与报告可快速定位暴露源头为后续清理.git目录、更新访问控制策略提供明确依据同时日志输出也有利于审计追踪。掌握后能直接提升Web安全审计与Git仓库防护的实战能力并加深对版本控制安全边界的理解。1. Git_Extract.zip从残缺的 .git 目录里把源码完整挖出来接手一个只剩.git目录的项目工作区文件被清空或根本没拿到这种场景在数据恢复、安全评估甚至团队交接时经常碰到。Git_Extract.zip 这类工具包就是为这个场景准备的它把 Git 对象数据库里的 blob、tree、commit 重新解压、关联、落盘还原出接近原样的源码目录。它解决的不是“git clone 一份新仓库”而是“手里只有 .git 碎片时如何把历史内容和文件路径捞回来”。适合开发者在本地仓库损坏后自救也适合安全测试人员在评估 git 目录泄露影响时快速估算暴露面还适合运维从老旧的裸备份里抢救代码而不需要去猜当时提交了什么。2. 提取前先搞懂 Git 对象模型blob、tree、commit 怎么把源码串起来2.1 Git 对象不是文件是内容寻址的“黑匣子”很多人第一次打开.git/objects会懵里面全是以两个十六进制字符命名的目录目录里是 38 个字符的文件名合起来是一个 40 位的 SHA1 哈希。Git 的存储不是按“文件名 → 内容”组织的而是按“内容 → 哈希”组织的。你把一段文本丢进去Git 先算出这段文本的哈希再以哈希为文件名存下来这段内容就叫一个对象。对象之间有四种类型blob 存文件内容、tree 存目录结构、commit 存一次提交的快照引用、tag 存标签注解。blob 不知道自己在哪个目录下是 tree 对象把“路径 文件模式 哈希”串起来的。所以提取源码的本质就是从 commit 找到顶层 tree从 tree 找到子 tree 和 blob一路递归把哈希还原成路径和内容。理解这一点后面写脚本不会跑偏。2.2 先用 git cat-file 和 git fsck 摸清仓库伤情缺了多少对象一目了然拿到一个残缺.git目录我一般不会直接跑提取脚本先做“伤情评估”。首先看仓库的基本结构是不是还在ls .git检查HEAD、refs/heads、objects这些关键路径是否齐全。然后进到仓库根目录.git的上一级执行下面的命令确认对象库里到底存了什么东西# 进到 .git 所在仓库的根目录 cd /path/to/repo # 查看对象数量和类型分布确认对象库不是空的 git count-objects -v # 查看 HEAD 指向哪个引用以及引用是否存在 git symbolic-ref HEAD cat .git/HEAD # 对最新提交做完整性检查missing 会直接列出缺失的对象 git fsck --full --no-reflogs --unreachable 21 | head -50git count-objects -v输出的count是松散对象数量size-pack是 pack 文件的体积如果两个都是 0这仓库基本是空壳。git fsck会报两类关键信息missing blob hash表示某个文件内容丢了dangling commit hash表示有提交不在任何分支上但对象还在。这两类对象恰恰是提取脚本最有价值的猎物missing 决定了恢复上限dangling 决定了你能多找回多少历史。这一步花两分钟能省掉后面排错两小时。2.3 对象缺失与 pack 文件提取难度的分水岭在哪里伤情评估还看一个关键分水岭对象是松散存储还是打包存储。松散对象是objects/xx/yyyy…两级目录存的单个 zlib 压缩文件提取简单解压即可。但 Git 为了省空间会把成千上万个对象打成一个 pack 文件压缩格式复杂里面对象还可能用 delta 差分编码——存的是“和另一个对象的差异”不是完整内容。自己解析 pack 的 delta 链很容易翻车业界通用做法是依赖 git 自身的 plumbing 命令而不是写一个独立的 pack 解析器。判断方式是看.git/objects/pack/下有没有.pack和.idx文件idx是索引记录每个对象的 SHA1 在 pack 里的偏移量。如果只有松散对象恭喜你提取脚本可以写得很简单如果有一堆 pack 文件优先考虑用git cat-file --batch-all-objects这类命令批量导出而不是硬啃二进制格式。后面第四章的脚本会分别给出这两条路的处理方式。3. 手写 Python 脚本提取 Git 对象最小复现路径与核心参数3.1 zlib 解压松散对象从 objects 目录提取单个文件的脚本松散对象的物理格式很直接先 zlib 解压得到的数据分为两部分头部是type size\x00后面才是真实内容。下面这段脚本是提取流程的地基输入对象文件的完整路径输出类型和内容import zlib, os, sys def read_loose_object(obj_path): 读取 .git/objects 下的松散对象返回 (类型, 原始内容) with open(obj_path, rb) as f: compressed f.read() # 整个文件是 zlib 压缩的解压后才能看到文本头部 data zlib.decompress(compressed) # 头部以 \x00 结尾前面是 bblob 123 或 btree 456 这样的文本 header, _, content data.partition(b\x00) obj_type, size_str header.split(b ) declared_size int(size_str) if declared_size ! len(content): print(f[警告] 大小不符: 声明 {declared_size}, 实际 {len(content)}, filesys.stderr) return obj_type.decode(), content这里的关键参数是partition(b\x00)Git 对象头部和内容之间用 NUL 字节分隔不能直接按空格拆分因为文件名里可能含空格。另一个细节是declared_size的校验——如果解压出来的内容长度和头部声明不一致说明对象文件损坏或被截断这种对象就算解出来也是坏的应该在后续流程里标记出来而不是直接落盘。这个脚本只处理松散对象遇到objects/pack下的文件会解压失败异常信息是zlib.error: Error -5 while decompressing data看到这个报错就知道碰到 pack 文件了。3.2 解析 tree 对象还原目录结构把 20 字节哈希映射回真实文件名拿到 blob 只是拿到内容还得知道它叫什么、在哪个目录。tree 对象的二进制结构是紧凑的模式 文件名\x0020 字节 SHA1每个条目固定这样重复。模式是100644普通文件、100755可执行文件、40000子目录、120000符号链接等。写一个解析函数来遍历它def parse_tree(content): 解析 tree 对象内容返回条目列表: [(模式, 文件名, 对象哈希hex), ...] items [] i 0 while i len(content): # 模式与文件名之间是一个空格 space content.index(b , i) mode content[i:space].decode() # 文件名以 \x00 结束之后紧跟 20 字节的二进制 SHA1 nul content.index(b\x00, space) name content[space 1 : nul].decode() sha_bin content[nul 1 : nul 21] items.append((mode, name, sha_bin.hex())) i nul 21 return items注意循环步进是nul 21而不是nul 20SHA1 是 20 字节但\x00本身占 1 字节这个偏移算错会直接导致解析错位后续所有路径全部乱掉。文件名我直接.decode()默认 UTF-8遇到不规范仓库可能抛异常稳妥做法是加errorsreplace参数保证流程不中断。拿到条目后递归思路就清晰了遇到模式为40000的条目用它的哈希继续读 tree 对象并进入子目录遇到100644或100755用哈希读 blob 并写文件遇到120000内容是目标路径的文本提取后保留为软链接或写成文本文件都得看你的目的。3.3 pack 文件怎么办先解索引再取对象的处理路径如果对象在 pack 里上面两段脚本都不适用。我不建议自己写 delta 解压常见做法是让 git 自己把对象喂给你。下面这段用git cat-file把对象库里的所有对象枚举出来并导出配合前面的解析函数就能工作# 假设已经在仓库根目录 # 1. 用 batch-all-objects 枚举对象哈希和类型 git cat-file --batch-all-objects --batch-check%(objectname) %(objecttype) %(objectsize) objects.txt # 2. 按类型过滤出所有 tree 对象的哈希准备重建目录 awk $2 tree {print $1} objects.txt tree-hashes.txt # 3. 按类型过滤出所有 blob 对象按哈希导出内容 awk $2 blob {print $1} objects.txt | head -20 | \ xargs -I {} git cat-file -p {} sample-content.txt用管道把哈希喂给git cat-file -pGit 会自动在松散对象和 pack 文件里查找并输出完整内容。这里有个性能参数值得调--batch-all-objects在几十万对象的仓库上会跑几十秒配合--buffer能减少 I/O 损耗awk过滤后如果有十万级哈希要导建议别用xargs挨个调换成一段 Python 直接调用git cat-file --batch保持长连接吞吐量能差一个数量级。至于 pack 的 delta 链git 在cat-file内部已经解开了你拿到的一定是完整内容这就是为什么“让 git 干重活”是省心方案。4. 用现成工具包批量提取典型目录结构、参数设定与验收方法4.1 拿到 Git_Extract 工具包后的第一件事先看目录结构和 README自己写脚本适合练手真要抢救数据用现成的工具包更稳。这类工具的目录结构大同小异拿到手先别急着跑花两分钟看清单典型文件作用使用注意README.md环境要求、依赖、运行示例先确认 Python 版本要求3.8 以上居多extract_git.py核心脚本对象遍历、树重建、文件落盘可能需要--source指定.git路径parse_pack.pypack 文件解析辅助模块有些实现依赖git命令纯 Python 的会慢requirements.txt第三方依赖清单多数实现只用标准库有依赖反而要警惕sample/带缺口的样例仓库用样例先跑通流程再上真实数据我一般会先执行python extract_git.py --help看参数列表再拿 sample 目录里的残缺仓库试跑一遍。这一步能排除 80% 的环境问题比如 Windows 下路径分隔符、Python 的 zlib 是否正常、git 是否在 PATH 里。最重要的是确认工具包的运行模式——有的工具只提取当前 HEAD 指向的提交有的会遍历所有 refs 和 reflog前者快但会漏历史后者慢但完整这个选择直接决定恢复率。4.2 典型参数怎么设--source、--branch、--include-all 背后的取舍我见过的主流提取脚本参数高度相似下面是一个有代表性的调用方式# 场景 A只要最新提交的文件树速度快适合明确知道要找哪次代码 python extract_git.py \ --source /path/to/.git \ --output /path/to/recovered \ --branch main # 场景 B完整恢复所有可达和不可达对象适合仓库损坏后的全量抢救 python extract_git.py \ --source /path/to/.git \ --output /path/to/recovered \ --include-all \ --threads 4几个参数的经验值--source必须指向.git目录本身而不是外层工作区指向错了脚本会找不到objects。--branch默认是 HEAD但残缺仓库的 HEAD 可能指向一个不存在的分支这时候显式指定refs/heads/main或某个具体的 commit 哈希更可靠。--include-all的含义是连同 dangling commit、reflog 里的对象一起提取文件数量和耗时都可能翻倍我建议先不开启跑一次拿到主分支代码后如果发现缺关键提交再开启做增量。--threads设 4 到 8 就够zlib 解压是 CPU 密集型线程开太多反而因为 GIL 和磁盘竞争而变慢。4.3 提取结果怎么验收用 git fsck 和文件 diff 做双重校验提取脚本跑完目录里出现了文件树不代表成功。第一层校验是把恢复出来的目录变成一个真正的 Git 仓库再做完整性检查# 进入恢复结果目录初始化为仓库 cd /path/to/recovered git init -q # 把所有文件加入并提交此时会重新计算对象哈希 git add -A git commit -qm recovered # 对比原始仓库关键文件如果恢复完整相同的文件内容哈希值必然一致 # 用 diff 校验单个重要文件 diff /path/to/original/config.yml /path/to/recovered/config.yml echo MATCH这里有个底层逻辑Git 对象是内容寻址的同样的文件内容必然产生同样的 blob 哈希。所以校验不需要逐个文件比对内容只要对比恢复出的文件在新仓库里的哈希和原始仓库里的哈希是否一致即可。批量做法是跑git ls-tree -r HEAD | sha256sum和原始仓库的git ls-tree -r commit | sha256sum对比能快速发现整体差异。如果两边对不上优先把 diff 结果喂回提取脚本看是遗漏了某个 tree 条目还是 blob 解压出错而不是手工去翻文件。5. Git 提取的踩坑记录4 个高频坑及其排查路径5.1 现象解压报错invalid zip archive: could not find EOCD工具包根本跑不起来原因你下载的 Git_Extract.zip 本身是坏的。EOCDEnd of Central Directory是 zip 文件末尾的目录结束标记缺失说明文件被截断、下载工具把 404 错误页存成了 zip或者文件在传输中被改动。这和 Git 无关纯粹是压缩包没到位。解决先看文件大小和页面标注的字节数对比再用unzip -t Git_Extract.zip或 7-Zip 的“测试”功能做完整性校验。网络不稳定的环境我习惯用支持断点续传的下载工具重拉一次拉完立刻执行sha256sum和源站对比。这个坑提醒我拿到任何 zip 包第一件事就是测试压缩包完整性而不是直接解压。5.2 现象提取出的中文文件名全部乱码代码内容也是乱码原因分两层第一层是 Git 本身存文件名和内容都是原始字节如果提交时用了 UTF-8提取时就必须按 UTF-8 解码第二层是 Windows 下 zip 工具默认用 GBK 解压中间过一道手就全乱了。另外git cat-file -p在终端显示中文路径时会转义成八进制序列比如\346\265\213这是core.quotepath在作怪。解决在脚本里统一指定errorsreplace并在写出文件时显式指定encodingutf-8命令行里临时关掉转义再操作# 让 git 直接输出原始 UTF-8 路径而不是转义后的八进制 git -c core.quotepathfalse cat-file -p HEAD^{tree}真正稳妥的做法是彻底绕开终端编码让 Python 脚本直接操作对象文件并自己写磁盘路径。遇到历史遗留的 GBK 编码仓库只能先按 UTF-8 解失败的再按 GBK 回退没有一劳永逸的参数。5.3 现象对象解压时报zlib.error: Error -5或内容 SHA1 对不上原因松散对象文件在传输或拷贝中被截断或者objects/xx目录下的文件被人为改过。Error -5 表示解压出的数据不完整属于物理损坏SHA1 对不上则更隐蔽——数据能解压但内容和哈希不一致说明文件被修改过。解决先用git fsck --full定位所有坏对象再判定坏的是不是当前提取路径上的必需对象。如果是必需对象看能不能从其他备份或远程仓库补齐如果是悬空对象直接跳过不影响主流程。我在脚本里会加一段校验解压完算一次sha1(obj_type b size b\x00 content)和文件名的哈希比对不一致就写入错误清单。这个校验成本极低但能避免把坏数据误当成恢复成果交给别人。5.4 现象提取出大量小文本文件内容是一行 URL——git lfs 指针文件原因仓库用了 Git LFSLarge File Storage大文件实体不在.git/objects里而是一个指针文本存在对象库中真实内容在 LFS 服务器上。指针文本长这样version https://git-lfs.github.com/spec/v1加一行oid sha256:哈希加一行size 字节数。提取脚本遇到这种文件解出的“内容”只是引用。解决识别oid sha256:前缀然后分两条路走。有网络权限时用git lfs fetch --all配合git lfs checkout把实体拉下来替换指针没有网络时只能把指针文件原样保留在恢复报告里标记这批文件“仅恢复引用”。实践中我遇到过一个仓库一半资源走 LFS提取脚本跑完看着文件都在一构建全部失败排查好久才发现是 LFS 指针。所以拿到含大文件的仓库先看一眼git lfs ls-files心里有数再定提取策略。6. 进阶收尾验证恢复结果是一次值得投入的“建设性检查”6.1 用 git log 和 git diff 验证提交历史没有断点提取完成、文件落盘之后别急着交差把恢复出的目录初始化成仓库补一次提交再看历史连续性。git log --all --oneline --graph | head -30 git diff --stat HEAD~1 HEAD | tail -20git log --graph能粗略看出提交链是否完整如果只有孤零零一条线说明只恢复了一个提交的快照如果分支合并图正常说明 commit、tree、blob 三者关联完整。git diff --stat则用于抽查最近一次改动是否符合预期。我遇过一次恢复结果“看起来完整”提交历史却断了的情况git fsck没报错但 reflog 里有五次提交的哈希拿不到对应 commit 对象最终只能恢复出最后一个版本。从那以后我建立了一个习惯——凡是涉及 Git 数据恢复第一件事永远是先跑git fsck --full看“伤情报告”再决定走哪条路。6.2 构建一次胜过十次自查用依赖安装和编译验证恢复质量最后一道验证是把恢复出的源码当正常项目跑一遍。常见的做法是检查依赖清单文件在不在、版本对不对然后直接构建Node 项目跑npm ci npm run buildPython 项目用pip install -r requirements.txt后跑测试Java 用 Maven 打包。构建失败的原因各有不同缺文件会报模块找不到LFS 指针会报文件格式错编码问题会在编译期直接抛异常。这些报错信息比任何自查脚本都准确。更重要的是给这次恢复定一个“验收标准”源码能构建出可用制品才算是真正提取成功。我自己的教训是提取脚本跑完不校验就交付结果对方一编译发现全是乱码双方都难受。现在我会把git fsck的输出、恢复文件数、构建结果三样一起放进交付说明里问题在哪一步、缺了什么对象都一目了然省掉来回拉扯。Git 提取这件事的终点不是文件出现在磁盘上而是你能确认它和原仓库在内容层面等价——做到这一点才算真正把这个标题里“Extract”的价值兑现了。希望帮到你。本文还有配套的精品资源点击获取