APP加固反編譯技術對比

代次	第一代	第二代	第三代	第四代	第五代
技術路線	dex透明加解密技術	函數級代理技術	so文件加殼技術	代碼混淆和虛擬化技術	安全容器技術
設計思路	對每個或每組可執行文件加殼加密，增加複雜度，讓破解者因爲複雜無法破解，知難而退。				不讓破解者拿到可執行文件及關鍵數據
技術原理	核心思想是把需要保護的dex文件加密後打包到APK中, 在需要使用時先解密dex再加載到內存, 然後刪除解密後的明文文件, 或者直接在內存中動態解密, 不釋放到文件系統。	針對第一代技術可以被dump內存的問題進行的改進, 原理是在內存中只加載一個函數代理模塊, 當APP需要使用某些功能時由該代理模塊去尋找真正實現功能的函數, 找到後調用該函數並且把執行結果返回給APP, 函數代理模塊相對於一箇中間人的角色。	由於java層的保護始終受到java虛擬機的限制, 無法防止自定義java虛擬機的***, 所以第三代技術將保護移動到了更底層的so文件上, 通過將核心代碼封裝到so文件中, 同時對so文件加殼保護, 並且吸取了第一代和第二代技術的優點, 對so文件進行加密和防內存dump處理。	第四代技術將保護主體移動到粒度更細的函數層, 通過自定義編譯器在編譯時對代碼進行混淆和虛擬化保護, 隱藏真實的業務邏輯, 增加了逆向分析的難度。	第五代加固技術的核心理念是讓***無法拿到實體文件，無法在系統中運行任何反編譯工具，自然也就無法破解，從根本上解決APP被破解的問題; 其實現原理是使用加密容器技術，構建一個與操作系統緊密耦合的容器,  讓APP運行在容器中，容器對外物理隔離，容器內白名單運行APP，外界無法直接訪問容器中的APP和so以及配置等文件。
缺點	直接對dex文件進行加解密, 邏輯簡單直接, 容易實現。	解決了內存被dump的問題。	將核心代碼從java層移動到了so層, 提高了破解的難度。	可以針對單個函數進行保護, 配置更靈活。	APP文件始終在加密容器中, ***無法拿到so文件, 自然無法破解, 並且同時兼容前四代技術, 可以配合使用。
缺點	由於dex文件最終需要被解密後加載到內存中, 所以可以通過dump內存獲取明文數據。	技術實現複雜, 兼容性差。 由於該技術仍然使用了java虛擬機執行所有函數, ***者可以通過修改java虛擬機記錄代理模塊找到的所有真實函數, 從而獲取明文代碼。	隨着脫殼技術的發展, 和自動化脫殼技術的出現, 這種防護措施的效果也越來越差。	由於代碼混混淆和虛擬化保護增加了額外的業務邏輯, 導致APP性能下降和體積增大; 並且該技術不能防止程序關鍵校驗邏輯被爆破。	需要在操作系統中安裝容器運行環境, 需要操作系統控制權，必須出廠前部署、或己方技術人員安裝部署。
加固的層次	java層	java層	so層	java層/so層	so層
加固介入的時間點	開發過程中/開發完成後	開發過程中	開發過程中/開發完成後	開發過程中	開發完成後
是否改變IDE環境	不改變	不改變	不改變	需改變IDE環境, 使用第三方的編譯器編譯代碼	不改變
是否影響調試	影響	影響	影響	影響	不影響
***是否可以接觸到文件實體	是	是	是	是	由於所有文件都在容器中, ***無法拿到文件
是否需要安裝OS中間件	不需要	不需要	不需要	不需要	需要安裝OS中間件來運行容器
適用場景	適合獨立APP發佈時增加安全，無需操作系統及設備絕對控制權的場景。如手機的應用、遊戲、或其他單個安裝的軟件。				適合擁有操作系統絕對控制權的場景，或者其他場景比較固定的場景。
安卓應用反編譯	適合	適合	適合	適合	不適合
java/C#應用反編譯	適合	適合	適合	適合	適合、把java應用發佈在容器內
python代碼加密	不適合	不適合	不適合	不適合	適合、把python文件發佈在容器內
單個EXE/DLL加殼加密	適合	適合	適合	適合	適合、把exe文件發佈在容器內
整機保護	不適合	不適合	不適合	不適合	適合
主要廠家	已淘汰	已淘汰	愛加密，幾維、360加固寶、頂象、娜迦	愛加密，幾維、360加固寶、頂象、娜迦	深信達CBS