越来越多的个人和机构都在为第三方进行开放企业级的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安装时间，上次运行时间，一些业务统计数据，甚至自我销毁数据等功能。
因此，双方既然在一起合作，出发点首先不能影响客户端的性能和功能，在检查方法上不能简单依赖技术，更多是一些业务上的指标更容易体现是否被盗版。