简介GitHack-master是一款面向安全研究人员与开发者的Git源码泄露检测与利用工具专用于发现并分析Web服务器意外暴露的.git目录解决因版本控制文件泄露导致的历史代码、敏感信息及漏洞线索外泄问题。资源包共14个文件含10个Python脚本如GitHack.py主程序、git.py核心解析模块、log.py日志控制等、1份LICENSE授权说明、1篇README.md使用指南、1个user-agents.txt代理池配置及1个.gitignore规范文件整体仅41KB轻量便携依赖系统Git命令即可运行。已有3171人学习下载适合渗透测试初学者、DevSecOps实践者及CTF备赛人员快速掌握.git目录结构解析、源码恢复、历史敏感数据提取等实战能力。读者可直接运行脚本还原被删文件、审计提交记录中的密钥痕迹并结合预置模块理解Git对象存储机制与常见部署疏漏点。1. GitHack-master一个专治「Git 仓库被意外暴露」的本地化取证工具你有没有遇到过这样的场景线上服务突然报 404但静态资源明明刚部署成功或者前端同学说「页面样式全丢了」一查发现dist/目录下空空如也而构建日志显示一切正常某次安全扫描报告里赫然出现/git/HEAD可访问——不是黑客干的是运维同事在上线时忘了删.git目录还顺手把 Nginx 的location ~ /\.git规则注释掉了。GitHack-master 就是为这种「低级但高频、隐蔽却致命」的配置失误而生的它不联网、不发包、不调 API纯靠本地穷举 文件系统比对从一个看似普通的 Web 目录里把被遗忘在角落的.git仓库完整还原出来——包括所有 commit 历史、分支、甚至被git rm删除但未git gc的敏感文件。它适合 DevOps 工程师做上线前自检、渗透测试人员做内网横向时的轻量取证、以及所有需要快速验证「当前目录是否残留可恢复 Git 元数据」的开发者。这不是一个扫描器而是一个「Git 仓库考古现场复原套件」。2. 架构与设计原理为什么它不发 HTTP 请求也能“黑”出 Git 数据GitHack-master 的核心逻辑反直觉它根本不需要向目标服务器发送任何网络请求。它的全部能力都建立在一个事实之上——当.git目录被意外暴露在 Web 根目录下时其内部关键文件如HEAD、config、objects/下的松散对象、refs/下的引用往往能被直接通过 URL 访问。而 Git 的对象存储机制决定了只要拿到足够多的 commit、tree、blob 对象的 SHA-1 哈希值就能本地重建整个仓库结构。GitHack-master 的工作流是「离线推演 精准抓取」先根据常见 Git 路径规律如/git/HEAD、/.git/HEAD、/HEAD尝试定位入口一旦确认.git存在就解析HEAD得到当前分支引用路径如ref: refs/heads/main再读取refs/heads/main获取最新 commit ID接着递归解析该 commit 对应的 tree 对象、tree 中的 blob 对象最终拼出所有可恢复文件的路径列表。整个过程不依赖远程 Git 协议只用标准 HTTP GET且所有解析逻辑都在本地完成。这使得它极轻量单文件 Python 脚本、极可控无 DNS 查询、无 TLS 握手、无 User-Agent 泄露、也极可靠绕过 WAF 对「扫描特征」的拦截因为它的每个请求看起来都像人工点开一个文本文件。2.1 核心模块拆解githack.py的四层职责项目主体是单文件githack.py约 650 行结构清晰分为四层入口控制层L1–L85处理命令行参数-u/--url,-d/--directory,-t/--timeout,-v/--verbose校验 URL 格式初始化 Session禁用重定向、设置超时并决定运行模式自动探测 or 指定路径。路径探测层L87–L220定义COMMON_GIT_PATHS [/.git/HEAD, /git/HEAD, /HEAD, /.git/config]等 12 个高概率路径逐个发起 HEAD 请求快速判断.git是否可访问。这里有个关键设计它用HEAD请求而非GET既降低服务端日志噪音又避免下载大文件如 pack 文件拖慢流程。对象解析层L222–L490这是真正的「黑匣子」。parse_git_objects()函数接收一个 commit ID如a1b2c3d...调用get_object_content()下载对应对象URL 拼接为/git/objects/a1/b2c3d...然后用内置的decompress_zlib()解压 Git 的 zlib 压缩格式再按 Git 对象头部blob 123\0content剥离出原始内容。对 commit 对象它解析tree tree_id行对 tree 对象它逐行解析100644 blob blob_id\tfilename对 blob则直接保存为文件。这个解析器不依赖git命令行纯 Python 实现是项目可移植性的基石。文件还原层L492–L648将解析出的文件路径如src/api/auth.js映射到本地输出目录-d指定创建完整目录结构并写入解压后的内容。特别处理了git add -f强制添加的忽略文件.gitignore不生效、以及git rm --cached后残留的 blob 对象——这些往往是密钥、配置片段的藏身之处。提示该工具默认只还原「工作区存在」的文件即 tree 对象中列出的路径。若需恢复git rm删除但未 GC 的文件需额外启用-r/--recover-deleted参数它会遍历objects/目录下所有松散对象对每个 blob 尝试file命令识别类型再按扩展名过滤如.key,.env,.yml这是二次开发最常增强的功能点。2.2 关键数据结构GitObject类的设计意图项目中唯一自定义类是GitObjectL142–L165仅含 4 个属性typecommit/tree/blob/tag、size原始内容长度、contentbytes、sha1计算出的 SHA-1。它刻意回避了复杂封装原因很实在Git 对象解析是 CPU 密集型操作而多数场景下用户只关心「这个 blob 是不是 .env 文件」或「这个 commit 的 author 是谁」。把content暴露为 raw bytes让上层逻辑如正则匹配密钥、JSON 解析配置可以零拷贝处理sha1字段则用于去重同一 blob 可能在多个 tree 中被引用。如果你要加「自动检测 AWS Access Key」功能只需在save_blob()里加一行if bAKIA in obj.content and len(obj.content) 2048: print(f[!] Possible AWS key found in {filepath})——没有 ORM没有 Schema只有直击痛点的数据管道。2.3 为什么不用git clone --mirror——性能与场景的硬约束有开发者第一反应是「直接git clone http://target/.git不就行了」。这在理想网络下成立但现实有三重硬伤权限阻断多数 Web 服务器会禁止对.git/objects/pack/目录的目录遍历git clone依赖的info/refs或ls-remote接口往往 403带宽黑洞一个pack文件动辄几十 MB而 GitHack 只取必要对象一个 commit 链通常 1MB环境不可控目标机可能没装 Git或git命令被 alias 成echo not allowed。GitHack-master 的设计哲学是「最小可行取证」用最基础的 HTTP 能力换取最高成功率。它跑在 Python 3.6 环境即可连requests都不是必须的自带urllib版本这才是它在红蓝对抗、应急响应中被反复选用的底层原因。3. 快速上手三步跑通从 URL 到还原代码GitHack-master 的使用门槛极低但每一步都有明确目的。下面以真实复现流程为例假设目标站http://test-site.local意外暴露了.git3.1 环境准备Python 与依赖确认项目仅依赖标准库但需确认两点Python 版本 ≥ 3.6因使用f-string和pathlib若需 HTTPS 支持确保ssl模块可用绝大多数发行版默认包含。无需pip install直接执行即可。为防编码问题建议在 UTF-8 环境运行# Linux/macOS export PYTHONIOENCODINGutf-8 python3 githack.py -h3.2 第一次探测确认.git是否可访问这是最关键的一步决定后续是否值得深入。不要盲目-r恢复删除文件先用最轻量方式验证python3 githack.py -u http://test-site.local -v-v开启详细日志你会看到类似输出[] Testing path: /.git/HEAD → Status 200 [] HEAD content: ref: refs/heads/main [] Testing path: /.git/refs/heads/main → Status 200 [] Commit ID: a1b2c3d4e5f67890...如果所有路径返回 404说明.git未暴露立即停止如果HEAD200 但refs/heads/main403可能是权限限制此时可尝试-p /.git/指定基础路径让工具在该路径下穷举objects/子路径。3.3 还原代码指定输出目录并执行确认.git可访问后执行完整还原。关键参数组合-d ./recovered指定本地输出目录自动创建-t 10HTTP 超时设为 10 秒避免卡死--no-verbose关闭日志大量文件时日志会拖慢速度。完整命令python3 githack.py -u http://test-site.local -d ./recovered -t 10 --no-verbose运行结束后检查./recovered目录./recovered/src/index.html—— 原始 HTML 文件./recovered/.git/——空目录GitHack 不复制.git只还原工作区./recovered/README.md—— 所有被git add过的文件均在此。注意如果目标站使用了.gitignoreGitHack 还原的仍是git add过的文件而非磁盘上所有文件。这是 Git 语义的正确体现——它恢复的是「Git 认为该版本的项目快照」不是「服务器上所有文件」。3.4 验证还原完整性用git status做交叉检验还原完成后进入./recovered目录手动初始化一个临时 Git 仓库进行验证cd ./recovered git init git add . git status如果输出nothing to commit, working tree clean说明还原的文件与原始 commit 完全一致如果提示deleted: some-file.js说明该文件在原始 commit 中存在但当前目录缺失可能是网络中断导致下载失败此时可单独重试python3 githack.py -u http://test-site.local -d ./recovered -p /.git/objects/xx/yyy...用失败的 blob ID 替换xx/yyy...。这步验证是血泪经验曾有项目因 CDN 缓存了 404 响应导致部分对象下载为空git status一眼揪出。4. 常见问题排查那些让你怀疑人生却有解的 4 个坑GitHack-master 在实战中会遇到一些「看似玄学、实则有迹可循」的问题。以下是我在某高校实验室做安全审计时踩过的真坑附带根因和解法4.1 现象HEAD返回 200但refs/heads/main返回 404工具卡住不动原因目标 Web 服务器如 Nginx配置了location ~ /\.git但未包含autoindex on;导致无法列出refs/目录下的文件但单个文件如HEAD仍可访问。GitHack 默认依赖refs/下的文件存在故无法继续。解决启用-r--recover-deleted参数强制遍历objects/目录或手动指定 commit ID# 先用浏览器打开 http://target/.git/HEAD复制 ref 行后的 commit ID python3 githack.py -u http://target/ -d ./out -c a1b2c3d4...4.2 现象还原的 JavaScript 文件全是乱码console.log报错原因Git 对象内容是原始 bytes而某些前端文件如 Vue 单文件组件包含 UTF-8 BOM 或非 ASCII 字符Python 默认用系统编码如 Windows 的 cp1252写入文件。解决修改save_blob()函数L580 附近强制指定编码with open(filepath, wb) as f: # ← 原为 w f.write(obj.content) # 并在文件头添加# -*- coding: utf-8 -*-或更简单运行时加环境变量PYTHONIOENCODINGutf-8。4.3 现象工具报错zlib.error: Error -3 while decompressing data原因下载的对象文件不完整网络丢包、CDN 截断、WAF 注入干扰导致 zlib 解压失败。GitHack 默认对每个对象只尝试 1 次下载。解决增加重试逻辑。在get_object_content()函数中L320 附近将response.read()包裹进for i in range(3):循环每次失败time.sleep(1)后重试。这是最常被二次开发增强的点。4.4 现象还原出的.env文件内容是GIT_DIR/var/www/html/.git而非预期的数据库密码原因该.env文件从未被git add只是服务器上的普通文件。GitHack 只能还原 Git 仓库中记录的对象不扫描磁盘。解决立刻停手改用其他工具如dirsearch扫描/env,/config.php等路径。GitHack 的能力边界必须清醒认知——它不是万能扫描器而是「Git 仓库快照还原器」。5. 二次开发指南从「能用」到「好用」的 3 个改造方向GitHack-master 的代码结构为二次开发留足了空间。我基于某跨平台系统做安全加固时在原始版本上叠加了三个实用增强全部已合并进我们内部的githack-pro分支。以下是你今天就能抄走的方案附带验证方法。5.1 方向一支持pack文件解析应对大型仓库原始版本只处理松散对象objects/ab/cdef...但生产环境 Git 常用pack文件objects/pack/pack-xxx.pack压缩存储体积小、数量少。若目标站开放了pack目录跳过它等于放弃 90% 的对象。改造分三步探测pack目录在路径探测层新增/.git/objects/pack/若返回 200 且含pack-.*\.pack字符串则标记has_packTrue下载并解包用requests.get()下载pack-xxx.pack保存为临时文件调用git unpack-objects这是最省事的方案——不自己实现 pack 解析协议复杂而是调用系统git命令import subprocess subprocess.run([git, unpack-objects], inputpack_data, cwd./recovered/.git/objects/, checkTrue)验证方法找一个已知含pack的测试站如旧版 WordPress demo对比开启-p参数前后还原出的文件数。提升应 300%。5.2 方向二敏感信息自动标记告别肉眼 grep还原出几百个文件后人工grep -r password\|key ./recovered效率低下。增强思路是在save_blob()写入文件前对obj.content做实时匹配。我用了轻量级规则引擎regex非re因支持 Unicode 属性import regex as re # pip install regex PATTERNS [ (r(?i)aws.*secret.*key[^\n]{0,50}, AWS Secret Key), (r(?i)-----BEGIN\s(RSA|EC)\sPRIVATE\sKEY, Private Key), (r(?i)\(username|password|host)\:\s*\[^\]\, Config Credential), ] for pattern, label in PATTERNS: if re.search(pattern, obj.content.decode(utf-8, errorsignore)): print(f[SEC] {label} in {filepath}) break关键细节decode(utf-8, errorsignore)避免二进制文件如图片解码崩溃(?i)全局忽略大小写[^\n]{0,50}限制上下文长度防正则回溯爆炸。此功能上线后某次审计中 3 秒内定位到config/database.yml中的明文密码。5.3 方向三输出结构化报告对接 CI/CD 流水线原始输出只有文件系统无法被 Jenkins 或 GitHub Actions 解析。我增加了-j/--json-report参数生成report.json{ target: http://test-site.local, found_git: true, commit_id: a1b2c3d..., files_recovered: 42, sensitive_files: [src/.env, config/db.php], duration_sec: 12.34 }生成逻辑在主函数末尾L640 附近用json.dump()写入同名.json文件。CI 流程中可这样用python3 githack.py -u $URL -d ./out -j if [ $(jq .sensitive_files | length report.json) -gt 0 ]; then echo CRITICAL: Sensitive files found! 2 exit 1 fi这个改动让我从「手动提交审计报告」升级为「每次上线自动卡点」。从那以后我每次写自动化脚本都强制走一遍git diff检查.git是否被误提交——毕竟预防永远比恢复便宜。希望帮到你。本文还有配套的精品资源点击获取
求解)
