Android程序的签名保护及绕过方法

随着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在使用。第一种基本上相当于没穿

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