写在前面的话

仅以此系列献给喜欢我CSDN的小伙伴们

申明

此文禁止转载，谢谢合作

序言

在开头说这会是一个系列，那就说明我有很多话要说。从最简单的介绍到问题的提出，解决方案的构思以及整个系统的架构实现测试都会在这个系列里一一说明。如果你还在迷茫该怎么去深入一个问题，一点点解决，那我尽力会通过这个系列让你有一点点感悟。如果你已经一览众山小，那么请给我多多提出建议。

不管你是何种程度的程序员，我的目的只有一个，这是写给大家看的东西。会用最简单最直白的方式表达，如果你不理解，一定是我的问题，你可以及时告诉我，我会努力把所有问题描述的简单易懂。

在安卓平台，重打包问题是Android多年的顽疾。基本上大部分的恶意软件的流入是通过重打包。

如果你对移动端不了解，或者对这个问题不熟悉，那么你可能会问什么是重打包？

我们可以举个简单的例子。你从不同的平台下载了两个看似一模一样的APP，但是其中有一个APP可能除了正常的功能外或许还秘密的在后台不被人发现的进行着某些活动。

比如说点击明明点击某个确定按钮，但是附带的发送了一条短信到移动服务商定制了某些服务，并且在后台拦截了服务商发来的提示短信。你本来以为一切都是正常的，但是某天查话费的时候，突然发现话费少了一大笔，没有收到任何服务商的通知，总哑巴吃黄连有苦说不出的感觉。

上面这个例子是重打包的典型案例。

下面是一些重打包常用的手段列举：

1.在原始的APP中加入了广告，这是最简单的一种手段

2. 修改了原始的APP，在保证了其用户体验完全相同的情况下以及不被用户发现的情况下偷偷增加了某些功能

3. 直接重写并且模仿了整个APP，并且增加了一些相应的功能。

看完这些有人会问这样的问题？你怎么识别出原始的APP和重打包的APP，你怎么知道不是作者本人修改的而是其他人修改的。

对于这个问题我们需要了解一点Android的APP是怎么发布到我们的市场上去的。

每个app的开发者要把自己的APP发布到网上让大家都能使用它必须申请一个账号并且缴纳一定的费用便可以将自己的APP上传到想要的市场上去。

当然，比较正式的官网会做一些安全监测，保护用户的安全。但是这个措施不是总有效的。

其次，Android的开发者众多，每天增加的APP数目是惊人的

最后，Android的APP是很容易被反编译破解的。

这些问题的存在导致了重打包这个顽疾可以长期存在。

既然存在了这么久一定会有一些解决办法，那现在都有些什么解决办法？

最早出现的解决办法就是根据代码的特征。逻辑是这样的，重打包一定实现了原始APP没有实现的功能，我只要检测出这些多余的代码就可以看出这个APP有没有经过重打包可是现在的问题是，重代码的角度出发来解决问题，面临的最重要的挑战操作码的数量巨大，必然会产生庞大的计算复杂度。加上要检测如此众多的APP，必然会捉襟见肘。

这个时候有人会说，为了扩大影响范围，一般重打包软件的制作者会选择一些受欢迎的APP来进行处理，这样感染的速度最快。我们在检测的时候比如说只针对前10000万个，建立一个原始APP的数据库。通过签名对比很容易就可以找到重打包的APP

事实真的是这样的，根据签名比较来实现真的靠谱么。这样就可以避免计算复杂度了么。想想怎么去找到10000个APP中的原始APP，重google play 上下载的可以算是原创的么。第三方市场为数如此众多，真的可以有效的减少时间复杂度么。

有什么的新方案么？

这就是今天以及以后我将要解决的问题。——基于资源来检测

你或许可能会问？这样靠谱么？

首先我们先来解决一个问题？在Android中什么是资源

在Android中，一个Activity可以看成资源，service，receiver，provider这些组件都可以看成资源。一张图片，一个字符串，id, xml文件这些都可以看成资源。并且就算现在的一些加固技术仍不能改变一些资源。这就确保了我们检测的可靠性。

既然理论上是可行，这样从资源这个比代码更加宏观的角度来看问题，把问题切割的更大，时间复杂度就降下来了。其次，更加可靠。

思路是这样，我们把APP分解。因为我们可以通过Intent来得到这个APP之间组件的调用关系。一个Activity从大方向上来看就是有一个个的组件构成的，组件的调用关系可以通过intent很快的确认。每一个APP都被我们拆分成一个个的图。其次，我们把每个节点细化，比如一个Activity上可能有一些组件，组件可能绑定了相关的事件。

听着有点晕，看看下面这图，或许我们可能就会比较容易理解：

我们要实现的就是可以有效识别新增加的组件A7，或者是在原始的APP上新增加的某个事件。比如向上文所说的那样，可以识别出改变了的按钮功能。

在未来的这个系列中我们就一点点来说明怎么通过资源来解决重打包问题。