傳統app加固技術經歷了四代變更,保護級別每一代都有所提升,但其固有的安全缺陷和相容性問題始終未能得到解決。下一代加固技術"虛機源碼保護"適用代碼類型更廣泛,保護級別更高,相容性更強,堪稱未來級別的保護方案。 ...
傳統App加固技術,前後經歷了四代技術變更,保護級別每一代都有所提升,但其固有的安全缺陷和相容性問題始終未能得到解決。而下一代加固技術—虛機源碼保護,適用代碼類型更廣泛,App保護級別更高,相容性更強,堪稱未來級別的保護方案。
第一代加固技術—動態載入
第一代Android加固技術用於保護應用的邏輯不被逆向與分析,最早普遍在惡意軟體中使用,其主要基於Java虛擬機提供的動態載入技術。 其保護流程是: 開發階段中將程式切分成載入(Loader)與關鍵邏輯(Payload)兩部分,並分別打包;第二代加固技術—不落地載入
相對第一代加固技術,第二代加固技術在APK修改方面已經完善,能做到對開發的零干擾。開發過程中不需要對應用做特殊處理,只需要在最終發佈前進行保護即可。而為了實現這個零干擾的流程,Loader需要處理好Android的組件的生命周期。 主要流程: 1)Loader被系統載入。 2)系統初始化Loader內的StubApplication。 3)StubApplication解密並且載入原始的DEX文件(Payload)。 4)StubApplication從原始的DEX文件(Payload)中找到原始的Application對象,創建並初始化。 5)將系統內所有對StubApplication對象的引用使用替換成原始Application,此步驟使用JAVA的反射機制實現。6)由Android系統進行其他組件的正常生命周期管理。
相容性 方案A透明加密方案由於其需要攔截系統的IO函數,這部分會使用inline hook或者got hook等技術,其會帶來一定的相容性問題 方案B的不落地載入方案由於其調需要調用系統內部的介面,而這個介面並不導出,各個廠商在實現時又有各自的自定義修改,導致該方案存在相容性問題。 缺陷與對抗 第二代加固技術在應用啟動時要處理大量的加解密載入操作,會造成應用長時間假死(黑屏),用戶體驗差。 在加固技術實現上沒有本質區別,雖然能防止第一代加固技術文件必須落地被覆制的缺陷,但是也可以從以下方面進行對抗: 例如記憶體中的DEX文件頭會被清除,用於防止在dump文件中被找到;DEX文件結構被破壞,例如增加了一些錯誤的數據,提高恢復的成本。 但是Payload被載入之後,在記憶體中是連續的,利用gdb等調試工具dump記憶體後可以直接找到Payload,進行簡單的處理之後可以恢復出100%的Payload文件。 和第一代加固技術的對抗方法一樣,不落地載入也無法對抗自定義虛擬機。只需對上述的關鍵函數進行攔截然後將對應的記憶體段寫出去,即可恢復Payload。註意,由於IO相關的函數被攔截,所以無法直接調用read/write等函數進行直接的讀寫,需要使用syscall函數進行繞過。 雖然廠商會自己實現可能上述函數,從而繞過上述函數的攔截。但是Android的類載入器必須能找到對於的結構體才能正常執行,攻擊者可以以類載入器做為起點,找到對應的Payload在記憶體中的位置。
第三代加固技術—指令抽離
由於第二代加固技術僅僅對文件級別進行加密,其帶來的問題是記憶體中的Payload是連續的,可以被攻擊者輕易獲取。第三代加固技術對這部分進行了改進,將保護級別降到了函數級別。 主要的流程是:發佈階段將原始DEX內的函數內容(Code Item)清除,單獨移除到一個文件中。第四代加固技術—指令轉換/VMP
第三代加固技術在函數級別的保護,使用Android虛擬機內的解釋器執行代碼,帶來可能被記錄的缺陷,第四代加固技術使用自己的解釋器來避免第三代的缺陷。而自定義的解釋器無法對Android系統內的其他函數進行直接調用,必須使用JAVA的JNI介面進行調用。其主要實現由兩種: A.DEX文件內的函數被標記為native,內容被抽離並轉換成一個符合JNI要求的動態庫。 動態庫內通過JNI和Android系統進行交互。相容性 第四代VMP加固技術一般配合第三代加固技術使用,所以第三代的所有相容性問題,指令轉換/VMP加固也存在。 缺陷與對抗 不論使用指令轉換/VMP加固的A方案或者B方案,其必須通過虛擬機提供的JNI介面與虛擬機進行交互,攻擊者可以直接將指令轉換/VMP加固方案當作黑盒,通過自定義的JNI介面對象,對黑盒內部進行探測、記錄和分析,進而得到完整DEX程式。