认识APK伪加密

今儿我儿砸@朋朋给我发了道crypto，是一个1.rar文件，直接打开里面有一个加密了的key.txt，于是我想可能是爆破密码或者是已知明文攻击（2015XDCTF里用到）就问他题目是怎么来的，他于是又发了张图片来，我放到stegsolve里发现图片文件尾部有附加文件，应该是直接抠出来的。

rar文件放到winhex里没看出什么所以然来（其实我忽略了文件头啊= =文件头是PK啊。。）既然不是用爆破，又没有提示，还有密码挡着，我就暂时没辙了。。过了一会儿他跟我说直接修复一下压缩包就行，试了一下果然可以。以下放图

图中上面为修复后导出的无密码文件，下面是源文件。

Google了一下原理，发现利用的是APK伪加密，换句话说就是这个文件其实是个APK（Android Packege file）文件，从其文件头PK可以看出来，而APK文件又是基于ZIP的file format。网上有些文章中写道由于在Windows和Android系统下读取APK文件是有区别的，区别在于APK文件的Central Directory 部分Header里有个位置叫做General purpose bit flags，“其中如果第0位置为1，则表示 Zip 文件的 Central Directory 是加密的，若果使用传统的解压缩软件打开这个Zip文件，在解压该部分 Central Directory 文件时，需要输入密码”

//来自博文https://www.deamwork.com/archives/my-past-ctf.orz6）

关于这个值的含义我们做了测试，其实在Windows\winRAR环境下以偶数形式出现时（00,02,04…）表示为文件没有密码，而以奇数形式出现时则需要输入密码；而在Android环境下不会读到这个位置，所以对于该环境下的编译没有影响。//不过这句话还没有深究。。。

之后我们提取出key.txt文件重新压缩为ZIP文件，与进行过APK伪加密的题目文件进行对比，发现关键处Hex是一致的，不一致的部分推测会根据APK加密工具写法不同而改变。

By the way, 图中可见有两处不同，第一处当然是General purpose bit flags，第二处我们尝试单独删除掉那个1A但是并没有消去密码，而且似乎对文件没有影响。（是因为加在了文件尾？）

总结：关于带密码的压缩文件类CRPTO题目目前有三类思路: 1、APK伪加密（文件头为PK），2、已知明文攻击（要有已知未加密文件），3、ARPR爆破

CTF坑漫漫，但还是要坚持下去，成为the bee's knee呀。