Android安全-代碼安全2-Apk簽名校驗

Android安全-代碼安全2-Apk簽名校驗

隨着Android 市場的擴大，各種盜版、破解、打包黨紛紛涌現，其使用的手法無非是apk _> smali ->修改代碼 ->重打包簽名，爲對抗此類技術，廣大程序員挖掘了Android平臺特有的保護技術：簽名校驗

 

 

一、JAVA代碼本地簽名校驗

Android要求安裝到手機上的APK文件必須有簽名，而理論上開發者的簽名他人是沒法獲得的（證書保護是另一回事），因此比較容易想到的就是執行簽名校驗，驗證本程序的簽名是否爲合法的程序。

 

代碼:

android.content.pm.PackageInfo 這個類

包含有以下字段

public Signature[]  signatures  Array of all signatures read from the package file.

 

經過signature能夠取得證書的HASH值，用於簽名對比:cool:

然而此方法過於簡單，小夥伴們一看，這不就是一個equals麼。 簡單的把smali中的 if-eqz 改爲if-nez就能反轉邏輯啦。

 

所以爲了增長強度，能夠將JAVA代碼轉爲NDK代碼

 

2.NDK層校驗

 

簡單來講，NDK就是用C/C++在Android開發的一組套件，通常來說以so的形式存在，JAVA代碼經過JNI接口來調用，固然也能夠獨立編譯爲具備main入口的可執行程序 

 

NDK的好處是增長了程序的複雜度，由於so經過反彙編，獲得的是ARM代碼，而不是smali這種易重修改、易理解的代碼。修改so難度將大增。

 

在so中校驗程序簽名的方法也相似於JAVA層中代碼,可經過JNI的GetMethodID 取得JAVA類函數，經過Call***Method 來調用 ，詳細使用方式見附件 JNI_Docs.rar.

 

此時，雖然增長了必定的破解難度，但若使用不當，仍然容易被小朋友破解掉滴。

 

 

某APK 在so中實現簽名校驗功能，但在實現中將用於對比的簽名HASH串明文存放在代碼中，編譯後，字符串存放在.rodata段，打開IDA ctrl+x 必定位，就出來啦！，而後使用強大的UE一改掉，就落入魔爪了。

 

因此訥，在so中，必定是不能這樣明文存放滴 ，至少要進行兩次變形。

 

1)分段存放， 將字符串分爲多段， 如：0 3 6 9 .... ； 1 4 7 10 .... ；2  5  8 11 .... 各爲一段， 在實際使用中，再進行拼結

 

2)分段了仍然很差，由於數字仍是在，經過對比，仍是比較 容易發現規律的，因此須要對數值進行加密處理，再保存。加密隨便採用一個自定義的對稱加密算法， 再將加密後的密文寫到程序中，準備使用時，進行解密。

 

雖然作了以上猥瑣的操做，仍是會被幹掉的 由於本地是小朋友們的地盤，早晚會發現啊，那咋整？放到服務器去啊。

 

三、服務器校驗

 

服務器校驗即將本地的程序信息，傳輸到服務器進行校驗，而後返回一段核心代碼進行執行（這裏不是一個簡單的校驗結果，也是防本地修改；同時也不建議服務器下發校驗信息，本地校驗，原理同）

 

 

 

首先本地取一些相關信息，而後使用非對稱算法進行加密，此處的信息通常很小，減輕服務器壓力。

 

將加密結果發送到服務器端，服務器處理好後，下發特定的核心代碼，而後動態加載執行

 

客戶端執行代碼，校驗成功。

 

 

此種方法相對比較完善，但仍然存在繞過的可能性

非對稱算法須要用到公鑰加密與解密。所以存在一種中間人的可能性

 

首先將客戶端的公鑰取出來，替換掉本身的公鑰。

 

而後傳輸到中間人處時，中間人用本身的密鑰解密，獲得明文，再用原來的公鑰加密發到服務器，接收數據同

 

所以有必要對中間人的證書鏈進行驗證。

 

 

 

以上三種校驗方式相輔相成，目前而言，採用第二種的已經比較多了。第三種方式已見到一些APK在使用。第一種基本上至關於沒用對於懂的人。

轉自：http://blog.csdn.net/wulianghuan/article/details/22497621