基於NDK的Android防破解& Android防破解 【轉載】

兩篇防破解文章轉載

基於NDK的Android防破解：http://blog.csdn.net/bugrunner/article/details/8634585

Android防破解：http://blog.csdn.net/xfzheng_yeah/article/details/8915816

基於NDK的Android防破解

Android程序防破解是發佈app時一個很須要考慮的問題，一般的作法是對代碼加入混淆干擾以增長破解難度。但即使如此，混淆操做以後的java代碼仍然能夠被經過各類方法進行破解。在基於NDK的Android中含有相應的main.cpp來做爲應用程序的入口，於是在這裏進行一些防破解較驗，相應的破解難度就會增大很多（相對於java代碼）。

在Android整個導出過程當中，生成.dex階段是整個打包發佈操做的基礎，包括相應的java源代碼、外部庫文件均會被編譯連接到.dex文件中，而其中關於代碼的任何改動後從新生成.dex，其均會與原始文件均會有所不一樣，於是就可經過對.dex文件進行MD5較驗而作爲app是否被破解的依據。

基本流程：

1. 打包發佈階段（只進行一次）：在打包生成過程獲得.dex以後計算該.dex文件的MD5串，並將其寫入到NDK工程的main.cpp中，做爲最終版本較驗的標準串。該過程能夠加入到Ant自動化打包發佈中，做爲生成.dex的後續階段。
2. 動態運行階段（每次啓動進行）：在main.cpp的程序啓動入口處添加動態的.dex MD5計算，並與代碼中存儲的標準MD5串進行比較，若二者不匹配則說明程序已經被破解，即刻退出。

階段1:　計算.dex文件的MD5串並將其寫入到對應的main.cpp中，相應的ant操做大致以下（並不完整以）。

生成dex對應的MD5，並將其存儲到一個文件中：

 

<target name="predexmd5"depends="dex">
        <exe cexecutable="${dexmd5tool}" failonerror="true">
           <arg value="${dexmd5tempfile}" />
           <arg value="${dex-ospath}"/>
       </exec>
</target>

從外部文件中讀入相應的MD5串，並存儲到一個ANT的變量：

 

<target name="dexmd5" depends="predexmd5">
        <loadfile srcfile="${dexmd5tempfile}"property="dexmd5sign"/>
</target>

將.dex文件的MD5串寫入到main.cpp中：

<targetnametargetname="setmaincpp" depends="dexmd5">
        <replace file="${maincppfile}"token="Ant_DexMD5Sign" value="${dexmd5sign}"/>
</target>

其中使用的dexmd5tool是一個自實現的外部exe，主要實現對任意文件計算其相應的MD5並將串值保存到一個指定的文件。這裏須要MD5串以文件形式進行保存主要是以便在ant中打該文件並讀入其中的字符串到ant變量中（並無找到其它方法直接將相應的MD5碼寫入到ant變量中去，於是作這樣的婉轉實現）。將MD5串向main.cpp中寫入主要就是利用ant的字符串替換機制來實現便可。

更新完main.cpp以後須要利用NDK對工程進行從新編譯（主要是重編譯這裏有改動的C++代碼，該步必須進行）

調用NDKbuikd來完成相應的重編譯工做：

<targetnametargetname="ndkbuild" depends="setmaincpp">
        <exec executable="${basedir}/ndkbuild.bat" failonerror="true">
        </exec>
</target>

Ndkbuild.bat中的相關內容即如同Eclipse中配置的編譯參數同樣： X:/cygwin/bin/bash.exe --login -c "cd/cygdrive/XXX/XXX/Android/jni && $NDK/ndk-build"

階段２:　對dex計算相應的MD5並在main.cpp中進行啓動時較驗。

這裏須要在app每次啓動運行中動態獲得當前apk包中的.dex文件並進行MD5的計算與較驗。這裏直接實現並不太容易，於是藉助於了一個第三方包libzip（https://github.com/julienr/libzip-android），它能夠以.so的形式鏈入到NDK工程中，並將指定的zip包（apk包）解壓縮，將其中的全部文件以二進制的方式返回。如此一來就能夠運行時獲得當前apk包的dex的二進制流；將計算binary的MD5代碼也一併加入到該工程中便可以完成在main.cpp中啓動時動態較驗.dex的MD5值。

若當前apk包中的.dex文件MD5碼與main.cpp中存儲的MD5碼（階段1獲得）匹配，程序合法運行；不然，較驗不經過認爲已經被修改過，直接退出。

 

 

 

Android防破解

 

愈來愈多的我的和機構都在爲第三方進行開放企業級的APP，這種類型的APP，開發者很是關心本身的APP會不會被破解，從而直接影響本身的收入。

最近對這個話題也比較感興趣，看到 BugRunner於2013年3月份發表的《基於NDK的Android防破解》（http://blog.csdn.net/bugrunner/article/details/8634585），想了幾個方面。

 

很是認同，基於NDK，比JAVA更難反編譯，更難破解，可是他這個方案其實有不少問題：

一、NDK只是做爲一個入口點，檢查MD5，若是不一致就退出運行。  若是直接調用原先的ACTIVITY做爲入口點，顯然就沒法阻止了。並且這個並不難實現。

二、NDK之因此難以反編譯，很大程度是彙編低級語言的可讀性不好，可是若是隻是一個入口點這麼簡單的程序，反編譯以後，實際上是很容易修改的。更況且在本方案中，只是進行md5數值的比對。

 

對於一個商業價值較大的來講，這個增長破解的代價仍是過低了。

 

若是但願增長破解難度，能夠從如下幾個方面考慮：

一、核心的比對驗證算法應該是基於NDK，在JAVA這一側竟可能多的進行比較比對，甚至是隨機繼續調用。若是SO文件不存在，是不能運行下去的。

二、這個比對函數，不能是固定的，不然反編譯後定位到一個地方，就很容易替換全部的地方。能夠採用屢次比對的思路，好比設計若干個比對函數，每一個比對算法是不同，基於時間，基於文件系統某個文件，MD5檢驗，聯網，短信驗證等等。不知足任何一個均是失敗的。

三、在服務器一側，必須記錄客戶端的行爲，好比活躍用戶數，用戶的分佈，這個是頗有效的檢查辦法。使用不少APP的統計工具均可以作到，一旦在某個區域，活躍用戶數增長，能夠斷定被盜版了。

四、在服務器和客戶端之間，須要有必定的聯繫，結合NDK算法。好比一週內，必須和服務器通信一次，服務器能夠返回給客戶端一些簡單的命令，也能夠高級的命令，好比APP安裝時間，上次運行時間，一些業務統計數據，甚至自我銷燬數據等功能。

 

 

 

所以，雙方既然在一塊兒合做，出發點首先不能影響客戶端的性能和功能，在檢查方法上不能簡單依賴技術，更可能是一些業務上的指標更容易體現是否被盜版。