Android應用安全，防反編譯實踐

最新 08-29

首先，我個人的看法是，真正廣泛對外發布的應用，其代碼無法被真正保護。因為如果有人或者組織，真的願意不計代價投入，最終是可以將你的應用破解，得到源碼的。但這並不意味著應用的安全保護措施就沒有意義，所有的應用安全策略，都是在努力以較小的代價，增加應用的安全性，使潛在攻擊者破解應用需要付出巨大的代價和高昂的成本，讓其破解行為得不償失，主動放棄破解，從而保護我們的應用。以下是個人當下在第一階段學習和實踐的安全策略，做個記錄。

混淆是一種用來隱藏程序意圖的技術，可以增加代碼閱讀的難度，使攻擊者難以全面掌控app內部實現邏輯，從而增加逆向工程和破解的難度，防止知識產權被竊取。

代碼混淆技術主要做了如下的工作：

1、通過對代碼類名，函數名做替換來實現代碼混淆保護；

2、簡單的邏輯分支混淆。

已經有很多第三方的軟體可以用來混淆我們的Android應用，常見的有：

Proguard

DashO

Dexguard

DexProtector

ApkProtect

Shield4j

Stringer

Allitori

這些混淆器在代碼中起作用的層次是不一樣的。Android編譯的大致流程如下：

有的混淆器是在編譯之前直接作用於java源代碼，有的作用於java位元組碼，有的作用於Dalvik位元組碼。但基本都是針對java層作混淆。

在Android中，可以直接使用Proguard進行代碼混淆，方式很簡單，在build.gradle中配置即可，如圖

代碼混淆的好處是：

1、將類、欄位和方法使用短小無意義的名稱進行重命名，使代碼可閱讀性變差，要全面掌控代碼邏輯難度變大；

2、可以優化位元組碼，刪除未使用的指令，使得安裝包體積變小。

其缺陷在於：

1、無法真正保護代碼不被反編譯；

2、在應對動態調試逆向分析上無效；

3、通過驗證本地簽名的機制很容易被繞過。

也就是說，代碼混淆並不能有效的保護應用自身。

理論基礎：

Android中的每個應用都是有一個唯一的簽名。但是這個簽名在之前是可以被偽造，並實現為此打包的。

實踐方法

為了防止應用被二次打包，或者是需要破解我們的apk的操作，在入口處添加簽名驗證，如果發現應用的簽名不正確就立即退出程序。我們可以在應用啟動的時候獲取應用的簽名信息，與正式簽名內容進行比較，若發現簽名不一致，直接退出應用。如圖：

問題點：

如果破解者精通Smali語法，完全可以在對應類的.smali文件中直接修改返回值

如圖：

三、反調試

對外發布的版本是release版本，在其中增加應用調試狀態的檢測，一旦發現應用處於調試狀態，立即採取對應措施。

1、檢測應用是否處於調試狀態

2、驗證apk是否開啟了調試，以及是否有debugger已經連接

3、檢測進程的TracerPid(TracerPid正常情況是0，如果被調試這個是不為0的)

4、檢測應用是不是運行在一台模擬器中

理論基礎：

完整性校驗就是我們用各種演算法來計算一個文件的完整性，防止這個文件被修改。

其中常用的方法就是計算一個文件的CRC32的值或者計算一個文件的哈希值。我們在防止apk被反編譯的方法中也可以採用這種方法。我們知道apk生成的classes.dex主要由java文件生成的，它是整個apk的邏輯實現。所以我們可以對classes.dex文件進行完整性校驗，來保證整個程序的邏輯不被修改。如果我們想要保證整個apk文件的完整性，也可以對整個apk文件進行完整性校驗。下面我們分別來實現對classes.dex文件和apk文件的完整性校驗。

實踐方法

通過對classes的crc值進行對比判斷，可以確定apk是否有被修改。本地的crc值可以自己判斷得出，每個版本發布應用的crc值在掛包時上傳到伺服器，通過介面獲取，然後和本地crc值進行對比。