回顾

本系列文章到这里就已经到尾声了，在第二章时，我给大家介绍了很多相关的知识，这些知识是学习本系列文章的基础。接着在第三章中，我介绍了目前流行的相似度识别方案，并针对网上没开源的方案进行简单模拟实现。之后在第四章中，我介绍了一些代码混淆的方案，这些方案只是给大家个引子，希望大家能够举一反三，想出更多更好的方案。

分析

现在我们已经能够把代码混淆得面目全非了，但是怎么才能知道它的混淆效果了呢？一般做法有两种，一是人工分析，二是通过工具自动化分析。

人工分析很难有个衡量标准，所以这里我打算使用工具自动化分析。在第三章中，我介绍了一些相似度分析工具，这里我就用那三个相似度分析工具进行分析，并比较。

接下来使用的混淆工具，都进行了随机混淆处理，也就是说两次分别处理的应用，混淆效果是不一样的，而后面的分析结果，除重打包是基于处理前后的应用外，其它都是基于两次分别处理的应用。

下面是开源中国的测试结果：

	基于代码流	基于变量计数	基于API序列
重打包	92.414%	98.317%	99.991%
加密字符串	80.703%	98.635%	99.880%
反射属性	79.878%	97.770%	91.986%
反射方法	69.122%	94.892%	76.282%
指令替换	92.718%	99.802%	100%
代码乱序	86.923%	100%	100%
重构方法	73.614%	95.752%	99.857%
重构并合并方法	74.938%	93.792%	98.704%
重构到本地方法	84.638%	97.053%	80.781%
使用全部	38.593%	72.844%	57.539%

我们看到反射调用的效果基本都比较不错，但反射调用对效率影响非常大，这里是5%左右的随机转换得出的结果，如果比例更高，效果更明显。

这里的测试并没给出花指令，我们说过，代码乱序实际也是花指令的一种，这里也可以看到花指令对于基于代码流的方式有比较大的影响，而对基于变量与基于API序列看似没影响，实际是由于代码乱序所用的指令比较特殊，如果换成其它花指令，影响肯定是会有的。

这里只对开源中国进行测试，有兴趣的可以测下其它应用，不过如果是比较大的应用的话，基于代码流的测试可能会失败，这一般是内存不足的原因。