简介

明文攻击主要利用大于 12 字节的一段已知明文数据进行攻击,从而获取整个加密文压缩包的数据。也就是说,如果我手里有一个未知密码的压缩包和压缩包内某个文件的一部分明文(不一定非要从头开始,能确定偏移就行),那么我就可以通过这种攻击来解开整个压缩包。

条件

1.完整的明文文件

2.明文文件需要被相同的压缩算法标准压缩(也可理解为被相同压缩工具压缩)

3.明文对应文件的加密算法需要是 ZipCrypto Store

ZIP的加密算法大致分为两种ZipCrypto和AES-256,各自又分Deflate和Store。

ZipCrypto Deflate
ZipCrypto Store
AES-256 Deflate
AES-256 Store

ZipCrypto算是传统的zip加密方式。只有使用ZipCrypto Deflate/Store才可以使用 ZIP已知明文攻击进行破解。

使用7Zip打开压缩包,即可看到加密算法

或者通过7Zip的命令行工具

1
7z l -slt yourfile.zip

利用

一般在CTF中,考法是比较固定的,题目一般是一个加密的压缩包,但是不对目录加密,可以看到里面的文件,通过其他条件获取到里面的其中一个文件,然后实施明文攻击,这种攻击不在赘述,我们来研究一下根据一部分文件数据如何进行明文攻击

条件

实现这种明文攻击的条件如下

至少已知明文的12个字节及偏移,其中至少8字节需要连续。

明文对应的文件加密方式为ZipCrypto Store

该方法对于ZIP加密的算法有要求,明文对应的文件加密方式需要为ZipCrypto Store。经大佬测试,Winrar(v5.80)、7zip(v19.00)默认状态下加密使用的就是AES256算法,直接排除。360压缩(v4.0.0.1220)、好压(v6.2)使用的是ZipCrypto,不固定使用Store或Deflate。不过一般不用担心怎么制作一个可以明文攻击的压缩包,直接检查压缩包的加密类型即可。

制作ZipCrypto Store压缩包使用360压缩-自定义,压缩方式选择存储,加密时选择ZIP经典加密即可。

工具

bkcrack

在Github下载对应操作系统release即可

bkcrack常用参数:

1
2
3
4
5
-c 提取的密文部分
-p 提取的明文部分
-x 压缩包内目标文件的偏移地址 部分已知明文值
-C 加密压缩包
-o offset -p参数指定的明文在压缩包内目标文件的偏移量

明文攻击

明文.txt中存放连续8字节以上的十进制明文即可

附加明文需要4字节以上的十六进制明文

1
bkcrack -C 加密压缩包 -c 明文攻击文件 -o 明文偏移量 -p 明文.txt -x 附加明文偏移量 附加明文(16进制)

解密压缩包,已获得key,长度为24位

1
bkcrack -C 加密压缩包 -c 明文攻击文件  -k key -D 加密压缩包

破解密码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
bkcrack.exe -k key -r 明文密码长度 字符选项

明文密码长度,写法支持如下
<min>..<max>
<min>..
..<max>
<max>

字符选项
?l:小写字母,包含 abcdefghijklmnopqrstuvwxyz
?u:大写字母,包含 ABCDEFGHIJKLMNOPQRSTUVWXYZ
?d:数字,包含 0123456789
?s:特殊字符,包含 !"#$%&'()*+,-./:;<=>?@[\]^_{|}~
?a:字母和数字,等同于 ?l?u?d,即 abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
?p:可打印的ASCII字符,等同于 ?l?u?d?s,即abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!"#$%&'()*+,-./:;<=>?@[\]^_{|}~
?b:所有字节,包含 0x00 - 0xff(所有可能的字节值)

同时支持指定-b 自己指定字符集,语法为
bkcrack.exe -k 55a37839 cabb7ffe cf3806aa -l 16.. -b 0123456789abcdef

明文密码制作key

1
bkcrack --password 明文密码

多线程

1
-j, --jobs <count>          Number of threads to use for parallelized operations

但是经过测试,还是不指定多线程,使用单线程总体表现更好,CPU都给我干满了。

案例1 txt

单文本文件压缩包

flag.txt

image-20240714163121651

1
2
# 已知明文
*lag{16e3********************74f6********

把连续八字节的明文放在txt中

74f6转为16进制37346636

然后尝试明文攻击,大概半个小时

1
bkcrack -C flag_360.zip -c flag.txt -p plain1.txt -o 1 -x 29 37346636

image-20240714163134114

然后可以解密

1
bkcrack -C flag_360.zip -c flag.txt -k b21e5df4 ab9a9430 8c336475 -d flag.txt

有时会遇到解出来的文件会有乱码的问题

可以使用密钥改密码,然后自行解压

1
2
# 把flag_360.zip改密码为123456,并另存为new.zip
bkcrack -C flag_360.zip -k b21e5df4 ab9a9430 8c336475 -U new.zip 123456

案例2 png

压缩包内含有图片

image-20240714163158126

根据PNG图片结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
0000h: 89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52 ; 塒NG........IHDR
0010h: 00 00 00 CE 00 00 00 CE 08 02 00 00 00 F9 7D AA ; ...?..?....鶀?
0020h: 93 00 00 00 09 70 48 59 73 00 00 0A 75 00 00 0A ; ?...pHYs...u...
0030h: 75 01 4A 25 DD FD 00 00 0C 91 49 44 41 54 78 9C ; u.J%蔟...慖DATx?
0040h: ED 9D D9 96 DC 2A 0C 45 A9 AC FC FF 2F D7 7D 70 ; 頋贃?.E┈?/讅p
0050h: C7 97 66 10 9A 98 CF 7E C8 EA 54 95 6D 86 83 24 ; 菞f.殬蟸汝T昺唭$
0060h: 04 B6 3F DF EF 37 00 D0 9F 3F B3 0B 00 6E 01 52 ; .?唢7.袩??.n.R
0070h: 03 83 F8 3B BB 00 AB F2 F9 98 0E 47 58 92 01 A9 ; .凐;?鶚.GX??

89 50 4E 47 0D 0A 1A 0A 是PNG文件头
00 00 00 0D 描述IHDR头部的大小,一般都是0D,13字节
49 48 44 52 是Chunk Type Code, 这里Chunk Type Code=IHDR
00 00 00 CE 00 00 00 CE 08 02 00 00 00 描述了Chunk Data,它是可变长度数据,00 00 00 0D 定义了长度为13个Bytes,所以,这里,你看到是13个字节)
F9 7D AA 93 是对IHDR的CRC校验

一般可以认为,PNG的前16字节为

1
89504E470D0A1A0A0000000D49484452

如果知道图片的长宽,甚至还能获得更多明文字节,但是16字节已经满足最低12字节的破解需求,所以尝试破解。

注意写入数据要转化为十进制

image-20240714160746686

image-20240714160637238

大概五分钟,然后解密即可

案例3 zip

zip里还有zip

image-20240714163815599

zip的文件结构应该还是比较熟悉的,除了经典的文件头,zip里面的文件名会在压缩包里明文存放,偏移量为30

里面有一个明文breakthroughentry.txt+flag.txt.zip的压缩包,可以尝试明文攻击

猜测里面有两个文件,一个是breakthroughentry.txt,另一个是flag.txt

有两种可能,需要猜两个文件谁在前面,因为只有第一个文件才能确定这个文件名在这个压缩包的偏移量30处

不过都试一遍即可

1
bkcrack.exe -C zip_guessinteger.zip -c breakthroughentry.txt+flag.txt.zip -o 30 -p plain1 -x 0 504B0304

image-20240714164253304

爆破之后验证一下,确实是breakthroughentry.txt在前

image-20240714164439269

案例4 exe

EXE文件

image-20240714163221724

很多的EXE文件,在第64字节开始,会有连续的64字节的固定数据

称为DOS存根(不绝对,因为此处可以修改)

1
0E1FBA0E00B409CD21B8014CCD21546869732070726F6772616D2063616E6E6F742062652072756E20696E20444F53206D6F64652E0D0D0A2400000000000000

尝试破解

1
bkcrack.exe -C nc64.zip -c nc64.exe -o 64 -p plain1 -x 0 4D5A

image-20240714161131224

案例5 pcapng

image-20240714164848914

Block Type 始终为 0A0D0D0A;Block Total Length 是小端存储的 Header长度,显然不会超过 64KB,所以高两位都是 00;Byte-Order Magic 在小端机器上始终为4D3C2B1A;Major Version 目前只有 0100;Minor Version 目前只有 0000。

其实蓝色部分也是可以猜出来的:Section Length 是可选字段,大多数软件(比如 WireShark)在保存 pcapng 时会写入-1(即 8 个字节的 FF)。

压缩包如下

image-20240714172803860

根据上面的研究,可以构造一个plain文件

image-20240714172855904

然后可以结合文件头,尝试明文攻击

1
bkcrack.exe -C secertpcapng.zip -c secert.pcapng -o 6 -p plain -x 0 0A0D0D0A

案例6 xml

xml文件是网站中很常见的配置文件,一般由<?xml version="1.0" encoding="UTF-8"?>开头

image-20240714174022668

image-20240714174029544

写好plain文件

image-20240714174107886

尝试使用xml常见的头部进行明文攻击

1
bkcrack.exe -C xml.zip -c 123/web.xml -o 0 -p plain

image-20240714174152770

据此,很多有固定开头的文件格式都可以作为明文攻击的切入点

比如

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
*.html
<!DOCTYPE html>

robots.txt
User-agent: *

*.xml
<?xml version="1.0" encoding="UTF-8"?>

*.svg
<svg version="1.0"
<svg version="1.1"

*.docx

当然,这些都不绝对,比如svg开头还有很多种类等等。

案例7 doxs、xlsx

由于网上没有找到这两个文件的详细文件格式讲解,尝试在一部分文件中找规律,不过本质和压缩包类似。

有时docs、xlsx文件中会存在大量的连续的0,只需要其中的12个,偏移量可以尝试。

image-20240714180034588

于是尝试用连续的12字节的0来明文爆破,因为目标中连续的0很多,所以偏移量可以试。

image-20240714180424050

尝试攻击

1
bkcrack.exe -C xlsx.zip -c 1.xlsx -o 64 -p plain

image-20240714180333834

除了连续的0,还发现在有的docx、xlsx文件中,在偏移量30起,都是[Content_Types].xml,类似压缩包中的文件名位置,虽然他俩本来也就是个压缩包格式。应该也可以利用这点明文攻击,但是可能跟docx、xlsx的版本有关

1
bkcrack.exe -C xlsx.zip -c 1.xlsx -o 30 -p plain

image-20240714181111831

另外一种是在30偏移量处的内容为docProps/PK,加上文件头也达到了爆破的最低要求。

参考

https://www.freebuf.com/articles/network/255145.html

https://flandre-scarlet.moe/blog/1685/

https://www.freebuf.com/articles/database/355244.html

https://blog.csdn.net/Rick66Ashley/article/details/130015948

https://ctf-wiki.org/misc/picture/png/

https://blog.csdn.net/u013943420/article/details/76855416

https://www.cnblogs.com/cunren/p/15575159.html