認識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呀。