comment出的还可以，里面有很多小细节的坑，学习一下。HCoin就比较难受，对此类型题目无思路。
NoWafUpload
这个题目是我以前出在SCTF2018上面的简版，不过被一些地方坑了一下。
当时一直在用python print然后进入管道，然后再用linux的md5命令
这个时候会多出一个\x0a，导致一直算不对，换为sys.stdout.write输出就好了
import zlib
import hashlib
import sys
from struct import pack
def dec_(file_):
f = open(file_,'r').read()
f = f[48:]
tmp = ''
for i in f:
tmp += chr(ord(i) ^ ord("\f"))
f = zlib.decompress(tmp)
return f
def enc_(file_):
f = open(file_,'r').read()
data_dec_len = pack('<Q',len(f))
f = zlib.compress(f)
tmp = ''
for i in f:
tmp += chr(ord(i) ^ ord("\f"))
m2 = hashlib.md5()
m2.update(tmp)
md5_ = m2.hexdigest()
data_enc_len = pack('<Q',len(tmp))
enc_data = md5_ + data_dec_len + data_enc_len + tmp
return enc_data
#print dec_('sdfasgerwtytc.php')
print enc_('test.php')comment
git泄露
console里面可以看到一些提示: 程序员GIT写一半跑路了,都没来得及Commit :)
借此也聊一下git的一些工具以及它们的原理，从目前的测试工具来看，BugScanTeam团队的GitHack应该是最稳的。
先铺垫一下基础，先初始化一个git init没有任何东西的GIT目录
然后只git add一个文件，这里并没有git commit
在这里要区分三个概念词：版本库、工作区、暂存区(stage)，更详细的内容可以看这篇文章
盗图一张:
提交一个文件的时候是分为git add、git commit两步的
当git add的时候，是把文件临时放在临时区stage中
当git commit的时候，是把临时区stage的所有内容提交到当前分支
当然这两个在objects目录都会生成一个对象文件，来存储数据。
可以看下当前目录结构为如下:
├── HEAD
├── config # 存放git的一些信息
├── description
├── hooks
├── index
├── info
│ └── exclude
├── objects # 存放对象文件
│ ├── 0c
│ │ └── 14454dd8d472ef27843ac8c86bdba161c27a03
│ ├── info
│ └── pack
└── refs
├── heads
└── tags其中index的内容其中就包含了一些当前版本下的文件信息以及对应的objects目录下的对象文件
对于git中的对象，推荐阅读此文
它包含了Blob对象（用来存储文件内容）、Tree对象（表示内容之间的目录层次关系）、Commit对象（相关的描述信息）
接下来进行git commit，多出了0c、31两个目录
对象用zlib解压即可看到内容
f = open("14454dd8d472ef27843ac8c86bdba161c27a03","r").read()
import zlib
print zlib.decompress(f)可以看到下面是新生成了一个tree对象、commit对象
看下commit对象内容，可以找到tree对象的一些信息
再通过git ls-tree 31d459查看到tree对象里面存放的内容，即一些目录结构，以及对应的Blob对象的object id，也就是通过tree我们可以找到对应文件的object id。
所以获取源码的整个过程就是 commit -> tree -> blob
***
接下来我们再多添加一个文件，进行git add、git commit操作
├── objects
│ ├── 0c
│ │ └── 14454dd8d472ef27843ac8c86bdba161c27a03
│ ├── 2b
│ │ └── ccc291c71cc92898645cdc8990056027108580
│ ├── 31
│ │ └── d459eb83ed7f3d9195b2bd24d4e2cbdc7e299c
│ ├── 85
│ │ └── 66ddc152da79a3e2fd4a00123aeea397e574c4
│ ├── 8e
│ │ └── 63e6627218b1e455a5ae4bc45135316cf39055
│ ├── 98
│ │ └── 0411cbd21c224e546111360d20775d62c33349
│ ├── info
│ └── pack这下新增了2b、85、98三个目录，分别代表着blob、tree、commit
看下commit的内容
可以看到上面的tree是指向了85/66ddc1，然后parent是指向了8e6366的commit，也就是上一次的commit内容
下面就讲下Git使用过程中的几种情况，以及对应如何去恢复代码
1、当年git泄露漏洞特别火，lijiejie师傅写了一个利用工具，流传大江南北。
因为index是存储工程中最新状态的文件，所以它就是获取了其中的blob的objects的hash，然后去得到文件，最后解压得到源码。
2、rip系列工具，当初在做P师傅出的XDCTF2015代码审计全解时候学习到的
对于获取其他的分支、tag，都可以从/.git/refs/heads、/.git/refs/tag里面拿到最新的commit对象id，然后就是顺着这个可以爬到parent commit
假设获取master，最新的commit的object id可以在/.git/refs/heads/master获取到
3、具有场景型，协同合作时，远程代码有更新，即本地代码不是最新版本。为了避免出现版本冲突可以使用git stash将这部分暂存起来，然后便可以执行git pull，暂存的内容便会存放到/.git/refs/stash，此处我并未使用git commit
╭─l3m0n@l3m0ndeMacBook-Pro ~/work/tools/src_tools/test/demo/.git/refs ‹dev›
╰─$ cat stash
e0945bc49106ac493f0d8c3b32370374b2d36a28
所以通过上面的commit我们依旧能够通过 commit -> tree -> blob 这种模式得到源码
4、使用了git reset --hard HEAD回滚时候
这个时候可以获取一下/.git/logs/HEAD文件，它会记录所有历史
比如上面便是reset之前的commit id
5、git gc，会打包object生成pack文件。但是有种情况便是git push失败的时候，一般push时候会打包一下，但是失败的时候并不会解压出来
这个场景的话，便可以获取/.git/objects/info/packs得到pack文件名
使用git verfy-pack -v xxx.idx可以看到一些内容信息
使用git unpack-objects < xxx.pack便可恢复
注入坑
这里就可以找一下stash留下的object恢复一下，便可以看到源码
printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" | cat - f569f235780f24c42b60f50d528a03f7238c80 | gunzip
比较明显的二次注入，但是坑就在他是换行的，没法多行注释，一下子没想起这个梗，一直都是#注入导致很蛋疼。
创建一个CATEGORY为aaa',content=user(),/*，然后留言回复*/#，便可回显注入
因为用的是mysql->query，也可以也能用%00截断一下，aaa',content%3d(user()),bo_id%3d'1'%3b%00%23a
还有一种就是利用DUPLICATE KEY，payload: ',content=database(),bo_id='1' ON DUPLICATE KEY UPDATE category='
参考文章
https://blog.csdn.net/zssureqh/article/details/53056095
https://www.cnblogs.com/lianghe01/p/5846525.html
https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013745374151782eb658c5a5ca454eaa451661275886c6000
https://ring0.me/2015/05/recover-code-from-corrupt-git-repo/
https://www.jianshu.com/p/fbc9eca95e26
464
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
