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

隨著Android 市場的擴大，各類盜版、破解、打包黨紛紛湧現，其使用的手法無非是apk _> smali ->修改程式碼 ->重打包簽名，為對抗此類技術，廣大程式設計師挖掘了Android平臺特有的保護技術：簽名校驗
 
 
1、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)分段了仍然不好，因為數字還是在，通過對比，還是比較 容易發現規律的，所以需要對數值進行加密處理，再儲存。加密隨便採用一個自定義的對稱加密演算法， 再將加密後的密文寫到程式中，準備使用時，進行解密。
 
雖然做了以上猥瑣的操作，還是會被幹掉的 因為本地是小朋友們的地盤，遲早會發現啊，那咋整？放到伺服器去啊。
 
3、伺服器校驗
 
伺服器校驗即將本地的程式資訊，傳輸到伺服器進行校驗，然後返回一段核心程式碼進行執行（這裡不是一個簡單的校驗結果，也是防本地修改；同時也不建議伺服器下發校驗資訊，本地校驗，原理同）
 
 
 
首先本地取一些相關資訊，然後使用非對稱演算法進行加密，此處的資訊一般很小，減輕伺服器壓力。
 
將加密結果傳送到伺服器端，伺服器處理好後，下發特定的核心程式碼，然後動態載入執行
 
客戶端執行程式碼，校驗成功。
 
 
此種方法相對比較完善，但仍然存在繞過的可能性
非對稱演算法需要用到公鑰加密與解密。因此存在一種中間人的可能性
 
首先將客戶端的公鑰取出來，替換掉自己的公鑰。
 
然後傳輸到中間人處時，中間人用自己的金鑰解密，得到明文，再用原來的公鑰加密發到伺服器，接收資料同
 
因此有必要對中間人的證書鏈進行驗證。
 
 
 
以上三種校驗方式相輔相成，目前而言，採用第二種的已經比較多了。第三種方式已見到一些APK在使用。第一種基本上相當於沒穿
--------------------- 
作者：wulianghuan 
來源：CSDN 
原文：https://blog.csdn.net/wulianghuan/article/details/22497621 
版權宣告：本文為博主原創文章，轉載請附上博文連結！