聲明：本文所討論之技術僅用於學習交流之用，請不要用來破壞他人手機安全和做違法的事情，否則，一切後果自負。
回顧漏洞新聞：
http://bluebox.com/corporate-blog/bluebox-uncovers-android-master-key/
1. 漏洞原理
漏洞的關鍵點在於，Android假設一個APK包中的文件是不會重名的。可實際上Zip格式是允許一個Zip文件包含具有相同文件命的文件。（注意，這裏的文件名，包括這個文件在Zip包裏的相對路徑）。
Android在安裝應用時，會抽取APK包中每個文件，進行簽名驗證。但如果碰到了相同文件名的文件，則只會校驗第二個文件，而忽略第一個文件。
另外在應用運行前會釋放classes.dex到/data/dalvik-cache/目錄生成優化過的odex文件，然後再運行。這個階段如果APK裏有兩個classes.dex，就只會抽取第一個classes.dex進行優化，而忽略第二。
好了，說到這，相信讀者應該明白怎麼利用這個漏洞了吧。
2. 攻擊分析
如果我們將一個APK包中放入兩個classes.dex文件。第一個classes.dex是被我們篡改過的惡意dex文件；第二個classes.dex是原來這個APK中的classes.dex文件。那麼在簽名驗證時，就會驗證原來的classes.dex，因此通過驗證；而執行時，卻執行了被篡改過的第一個classes.dex。
3. 攻擊步驟
a) 找個你想攻擊的APK，抽取出其classes.dex保存
b) 反編譯 classes.dex，修改之，重新生成新的classes.dex，更名爲classes.dey
c) 用7z打開原APK包，刪除其中的classes.dex，保存退出7z。
d) 依次將classes.dey和保存的classes.dex，通過7z塞入APK，然後保存退出7z
e) 用UltraEdit編輯修改過的APK，查找“classes.dey”，修改爲“classes.dex”（共有兩處），然後保存。
f) 大功告成。
4. 總結
a) 這個漏洞可以攻擊幾乎所有的APK應用。利用該漏洞修改過的APK，能依然保留原簽名，可以通過Android的簽名驗證，並能執行惡意代碼。
b) 如果手機裏的一些應用是APK + odex形式存在的。很不幸，這個漏洞無法攻擊這部手機上的這些應用。因爲這個APK裏沒有classes.dex，無法借屍還魂。
c) 如果手機裏有Settings.apk（非APK + odex形式），取出來修改下，再安裝覆蓋，就能拿到System權限。因爲Settings是system uid。
最後再強調下，別幹壞事，否則後果自負。畢竟目前市面上99%的手機都未打該漏洞的補丁。