●概述：
Google成立的Open Handset Alliance負責維護開發Android，12月份安全公告列出47漏洞散落於多項元件與架構，駭客可由近端或遠端進行探勘，藉此獲得高級權限且任意執行程式碼，並獲得隱私資料，另因APP代碼要在Android裝置執行，須先編譯然後打包成Android能識別並執行的應用程式套件APK(Android application package)，有效的APK為archive檔案格式，APK內包含被編譯的代碼DEX(Dalvik Executable)、resources、assets、憑證、清單，APK檔基於ZIP格式，與JAR檔案構造相似，Janus漏洞利用Android特性，攻擊者若插入惡意code至簽章證明之DEX，甚可藉system權限隨意執行程式，Google已就相關版本軟體研製安全更新，但多數用戶須等待製造商(OEMs)修補檔尚需數月，顯有大批智慧機仍處風險之中。
●編註：
(1)bypass用戶驗證：囿於Framework瑕疵，駭客能從本機器啟動惡意程式，刻意迴避對用戶之互動式驗證要求。
(2)遠端execute arbitrary code：在Media framework、Qualcomm components俱存同質性弱點，駭客可藉特製檔案造成代碼執行，且擁有系統程序之權限。
(3)本機execute arbitrary code：在system、Kernel components、MediaTek components、NVIDIA components，啟動惡意程式即可執行代碼，亦提升至系統程序之權限。
(4)殊值關注者為system存在Janus漏洞，源於單個檔案同時是APK和DEX形式，同時具備雙性質的的二元特性，如同羅馬神話的雙面神Janus，故以此命名。
駭客能注入惡意程式至APP且無須變更簽章，歸咎於Android處理APK安裝的方式，在APK簽章方案v1 (JAR signing)，其概念為保護APK局部，就如同ZIP metadata，因核驗程序處理大量資料結構時，Android檢查APK內簽章，若吻合才繼續編譯app到DEX檔準備執行，然對簽章涵蓋範圍外資料棄而不顧，擴大了受攻擊面，加諸JAR signing需進行解壓縮，耗掉時間與記憶體，前述缺失在v2已改良，而舊版Android 5和6版內apps仍使用APK簽章方案v1安裝更新檔，其程序能操縱APK archive，安裝過程中智慧機會檢查APK header資訊，判斷是否內含壓縮後的DEX code，若然，便據以反組譯該code並執行，否則就比照常態APK檔來運作，產生後果卻是DEX檔與常態APP code竟同時發生作用，卻對有效性毫無影響。故駭客僅須外加code至APK檔，即可更改Android app代碼卻不影響簽章，鑒於缺乏完整性檢查機制，致使惡意碼被編譯到DEX格式且塞入APK archive，還能帶有簽章證明，Janus漏洞讓安裝流程將好壞code皆付諸執行，且先從被加工的DEX表頭開始，後果就是散布惡意更新檔，看似如同原版APP所為，而一般逆向工程工具沒法揪出注入碼，真假難辨的特徵讓人們更容易受害，且更新過之APP繼承本尊早已獲得權限(可能是system)，可預測運用Janus漏洞之散播媒介，包括中間人介入未加密的HTTP連線、spam、第三方app商店、社交工程等手段，另自Android 7以後採用APK簽章方案v2，則不受影響。