基于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是否被破解的依据。

基本流程：

打包发布阶段（只进行一次）：在打包生成过程得到.dex之后计算该.dex文件的MD5串，并将其写入到NDK工程的main.cpp中，作为最终版本较验的标准串。该过程可以加入到Ant自动化打包发布中，作为生成.dex的后续阶段。
动态运行阶段（每次启动进行）：在main.cpp的程序启动入口处添加动态的.dex MD5计算，并与代码中存储的标准MD5串进行比较，若两者不匹配则说明程序已经被破解，即刻退出。

阶段1:　计算.dex文件的MD5串并将其写入到对应的main.cpp中，相应的ant操作大体如下（并不完整以）。

生成dex对应的MD5，并将其存储到一个文件中：

[html] view plain copy

<targetname="predexmd5"depends="dex">
<execexecutable="${dexmd5tool}"failonerror="true">
<argvalue="${dexmd5tempfile}"/>
<argvalue="${dex-ospath}"/>
</exec>
</target>

从外部文件中读入相应的MD5串，并存储到一个ANT的变量：

[html] view plain copy

<targetname="dexmd5"depends="predexmd5">
<loadfilesrcfile="${dexmd5tempfile}"property="dexmd5sign"/>
</target>

将.dex文件的MD5串写入到main.cpp中：

[html] view plain copy

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

其中使用的dexmd5tool是一个自实现的外部exe，主要实现对任意文件计算其相应的MD5并将串值保存到一个指定的文件。这里需要MD5串以文件形式进行保存主要是以便在ant中打该文件并读入其中的字符串到ant变量中（并没有找到其它方法直接将相应的MD5码写入到ant变量中去，因而做这样的婉转实现）。将MD5串向main.cpp中写入主要就是利用ant的字符串替换机制来实现即可。

更新完main.cpp之后需要利用NDK对工程进行重新编译（主要是重编译这里有改动的C++代码，该步必须进行）

调用NDKbuikd来完成相应的重编译工作：

[html] view plain copy

<targetnametargetname="ndkbuild"depends="setmaincpp">
<execexecutable="${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更难反编译，更难破解，但是他这个方案其实有很多问题：

1、NDK只是作为一个入口点，检查MD5，如果不一致就退出运行。 如果直接调用原先的ACTIVITY作为入口点，显然就无法阻止了。而且这个并不难实现。

2、NDK之所以难以反编译，很大程度是汇编低级语言的可读性很差，但是如果只是一个入口点这么简单的程序，反编译之后，其实是很容易修改的。更何况在本方案中，只是进行md5数值的比对。

对于一个商业价值较大的来说，这个增加破解的代价还是太低了。

如果希望增加破解难度，可以从以下几个方面考虑：

1、核心的比对验证算法应该是基于NDK，在JAVA这一侧竟可能多的进行比较比对，甚至是随机继续调用。如果SO文件不存在，是不能运行下去的。

2、这个比对函数，不能是固定的，否则反编译后定位到一个地方，就很容易替换所有的地方。可以采用多次比对的思路，比如设计若干个比对函数，每个比对算法是不一样，基于时间，基于文件系统某个文件，MD5检验，联网，短信验证等等。不满足任何一个均是失败的。

3、在服务器一侧，必须记录客户端的行为，比如活跃用户数，用户的分布，这个是很有效的检查办法。使用很多APP的统计工具都可以做到，一旦在某个区域，活跃用户数增加，可以判定被盗版了。

4、在服务器和客户端之间，需要有一定的联系，结合NDK算法。比如一周内，必须和服务器通讯一次，服务器可以返回给客户端一些简单的命令，也可以高级的命令，比如APP安装时间，上次运行时间，一些业务统计数据，甚至自我销毁数据等功能。

因此，双方既然在一起合作，出发点首先不能影响客户端的性能和功能，在检查方法上不能简单依赖技术，更多是一些业务上的指标更容易体现是否被盗版。

Android防破解

更多相关文章

随机推荐