文献阅读20180915

文献阅读

文章

1. Understanding Android App Piggybacking: A Systematic Study of Malicious Code Grafting

其实这篇文章读的有点点迷糊，Piggybacking的程序指的是其中一个应用程序可能会捎带另一个应用程序以包含恶意负载的程序，他的意思是搭载了恶意负载啊

这篇文章是构建了<原生,重打包>应用对的数据集。然后进行相似性的分析。分析是完全相同的应用，还是类似的应用，还是添加了某些还是删除了某些方法。分析的指标：

1. identical - 包括签名和实现在内的给定方法在两个应用程序中完全相同。
2. similar - 给定的方法在两个应用程序之间略微改变（在指令级别），即具有相同签名但具有不同内容的方法。
3. new - 在搭载应用程序中添加了一个方法，即app2中存在方法但app1中不存在。
4. deleted： 当一个方法包含在搭载应用程序中时，已从运营商代码中删除该方法，即方法存在于app1中但不存在于app2中。

然后就是怎么分析代码的问题了。直接分析太多了，他是把一个方法的code映射成字符串（映射规则是自定义的）。然后分析映射成的字符串的相似性。方法就是这样的，下面的文章内容是对他们数据集的分析，证明他们的分析的数据集是可靠的。

映射的一个例子：

应该是这个网站可以看映射的规则：https://ssebuild.cased.de/nightly/soot/javadoc/index.html。

2. RepDroid: An Automated Tool for Android Application Repackaging Detection

这篇文章是根据构建应用程序运行时的UI布局组图（LGG）的动态跟踪来设置检测的标志（文章中称为birthMark）

直观地，两个功能等同的重新包装克隆应该向最终用户提供类似的体验（视觉呈现，用户交互等）。此外，考虑到静态分析无法精确分析加密代码，我们采用动态方法比较两个应用程序的UI跟踪，以检测应用程序市场中的重新打包（图3）：

每个应用程序的胎记都从其执行跟踪中提取。胎记是基于运行时布局及其转换构建的图，其被命名为布局组图（LGG）。

一对重新包装的应用程序的特征在于它们相似的胎记，即它们的LGG之间在某个阈值之间的相似性得分。只要主要功能和视觉信号保持不变，我们就能够检测到重新包装。

Android应用程序重新打包攻击可以分为三类[13]，懒惰攻击，业余攻击和恶意软件。懒惰的攻击者经常在不更改其代码的情况下进行一些简单的更改，例如重新打包具有不同作者姓名的应用程序。因此，它无法更改运行时UI。因此，我们的方法可以有效地检测此类攻击。业余攻击者不仅应用自动代码混淆，还会更改，添加或删除一小部分功能。如果攻击影响应用运行时UI，则可以更改LGG。

恶意软件攻击者将一些恶意负载插入到原始程序中，但仍然使重新打包的应用程序看起来和行为与原始应用程序类似，以利用原始应用程序的流行度。

在重打包的时候他们可能会添加一些视图并将其颜色设置为与背景颜色相同。但是，据我们所知，还没有用于混淆的布局保留转换工具。因此，如果攻击者想要进行此类攻击，他们必须修改布局XML文件，这对重新打包应用程序来说是一个很大的负担。

这个是动态的分析界面的layout,那能不能只分析对应于布局的XML文件，将XML文件中的布局构成树结构然后分析两颗树的相似性，就是XML文件中的FramView ,ListOut等等的遍历，然后给他加权处理。

文章中提到其他的一些方法：找到感兴趣的方向之后再看看是不是自己需要的再看：

Static Birthmarks ：DroidMOSS [5]将模糊散列应用于app的每个方法作为指纹。基于两个指纹的编辑距离，他们计算相应应用的相似度。 DNADroid [8]为每个类别的应用程序中的每个方法构建程序依赖图（PDG），并通过VF2子图同构图比较图形。 AnDarwin [9]是另一种也使用PDG的工具。与DNADroid相比，AnDarwin计算PDG语义向量的局部敏感散列（LSG），从而提高了检测的可扩展性。 Juxtapp [10]使用k-gram的操作码和特征哈希来确定两个应用程序之间的相似性，并检测Android应用程序的重用。 PiggyApp [11]是一个可扩展的工具，用于检测搭载的应用程序。它应用模块解耦技术来找到比较的主要部分。它还通过解耦的主模块的语义特征提高了检测效率。 Centroid [12]构造每种方法的3D控制流图（3d-CFGs）并计算这些图的质心。然后，它定义质心差异度以测量应用之间的相似性。 Viewdroid [13]根据特定的Android API生成视图特征图，这是一个基于UI的Android应用程序胎记。为了测量图之间的相似性，它使用VF2子图同构算法。

Dynamic Birthmarks：Android API。与Viewdroid相比，它生成应用程序执行跟踪，即API调用序列，而不是视图。此外，通过测试工具Monkey在应用程序运行期间收集跟踪。工作[17]在UIAutomator的帮助下定位UI信息。它计算由相应活动创建的每个视图中的某些选定属性的频率，并将其上的向量构造为应用的胎记。为了计算应用程序之间的相似性，它使用E2LSH来查找每个应用程序中所有活动的近邻，并应用匈牙利算法来查找最近邻居中导致最高相似性得分的活动对。

Similar App Detections还有一些关于检测类似应用程序的相关工作。与应用程序重新打包不同，如果两个应用程序共享许多共同特征，即使它们是依赖开发的，它们彼此相似[29]。麦克米兰等人。 [29]通过使用语义层的概念来检测密切相关的应用程序（CLAN）来计算相似性指数。他们引入了一个与语义空间相关的新抽象，它被建模为API类和包的现有继承层次结构。 Thung等。 [30]基于CLAN检测类似的应用程序。他们使用协作标记来模拟系统，而不是API调用。 Linares等。 [31]提出了一种方法，通过分析五个语义存档来检测Android（CLANdroid）中的类似应用程序：标识符，Android API，意图，权限和传感器。

文章中自己指出的存在的一些问题：

1. 有趣的是，我们发现一些新注入的组件带有空实现。执行组件时，它将重用其父类的实现。不幸的是，这种间接性常常在简单的静态分析方法中被忽略，从而无法分析注入组件的实际实现。
2. 相对于原生的APP在搭载恶意程序的代码中是存在更多的重复组件。

3. Leveraging Information Asymmetry toTransform Android Apps into Self-Defending Code Against Repackaging Attacks

我们发现开发人员和攻击者之间存在着独特的信息不对称。利用这种不对称性，我们新的自防御代码（SDC）方法在编译时加密部分应用程序代码，并在运行时动态解密密文代码。与以前的工作不同，关键来自信息不对称和应用程序的校验和。重新打包应用程序后，更改的校验和将使应用程序异常运行，进一步暴露重新打包。信息不对称是通过保护密钥免受攻击。

针对于重打包应用的防止方法：

方法1：许可证保护机制（包括APK文件大小，MD5哈希/校验和和签名）。一个代表性的机制是Google Play提供的许可服务[2]。通过在运行时使用许可证验证库（LVL）查询Google Play，应用程序可以获取当前用户的许可状态，然后决定是否允许进一步使用。但是，受LVL保护的应用仍然可以重新打包。

方法2： App review process. 也就是说应用在上传到应用市场之前是有检测和审批流程的，但是数量巨大，人工检测不切实际。

方法3：混淆技术：混淆技术只会增加对应用程序进行逆向工程的难度，但不能阻止攻击者重新打包。

方法4： 检测技术： Android市场的管理者会比较其市场和/或其他市场中的应用，以检测重新打包的应用。检测需要同时找到至少两个“相似”的应用程序。自动检测是可能产生误报漏报的。

本文中的方法是一种自我保护的方法，其实就是因为自我保护机制使得重打包的应用在运行时产生异常。这个自我保护机制也就是自防御代码（SDC）。

但是这种方法能够使用存在一定的前提条件：

a.）信息不对称的存在。攻击者不能知道源代码中包含的所有信息，而且重打包的成本低于重新开发目标应用程序的成本。他们假设攻击者只知道编译的代码，而不是源代码。还假设，如果重新打包成本超过重新开发，攻击者宁愿重新开发目标应用程序。非对称信息是一种开发人员知道但是攻击者不知道的非对称信息

b.）可以利用信息不对称来使重新打包的应用程序异常运行(一直在说信息的不对称，到底是啥？）

c.）信息不对称不应该损害合法应用程序。

还有一个缺点就是他是在恶意活动发生时让程序崩溃，并不能在恶意活动发生前阻止活动的发生，这样的话其实就恶意活动已经发生了然后你再让程序崩溃，然后在去检测原因，这样其实损失已经造成了，因为恶意活动已经发生了。

SDC利用应用程序的校验和作为加密一段代码的密钥的一部分。重新打包应用程序后，将更改校验和，这将使解密无法恢复原始代码。运行错误解密的代码将自动让应用程序异常运行，这可以通过我们确保重新打包的方法来捕获。另外，由于解密密钥也部分地来自信息不对称，因此攻击者无法弄清楚密钥。SDC的设计方式如下：

这个将代码加密的过程最终还是判断的是encrypt(加密后是否与之前加密的相等，不相等的话就解析不出encr_code)来，导致这个变量不可用，但是我要是知道这里用的变量是encr_code的话其实就可以把那些加密全部省去，然后直接使用这个变量。

在运行过程中，当触发SDC段时，将计算应用程序的校验和。具有正确校验和的原始应用程序将使应用程序照常运行。但是，具有不同校验和的重新打包应用程序将使解密无法恢复原始校验和，这将进一步让应用程序异常运行。

也就是说他的这个方法是原始的应用程序检验和作为加密密码，只有一个，并且不变。

开发人员可能会加密程序中的某些代码，使攻击者难以阅读或修改，并隐藏应用程序内的密钥。当包含所有代码的应用程序暴露给攻击者时，可以找到密钥。然后他就使用了很多的SDC段，每一个SDC段都有自己的一个秘钥，进行多次加密，然后让他找不全所有的SDC段，这样做的话就能够提高触发SDC段的概率，但是工作量变大了。

这种用法一旦别人知道了那就是在if段进行的加密，这样的话就存在一定的问题。然后他是对if块中的语句，和程序中的常量来加密的，攻击者肯定是可以看出来的，因为每一段if块都是这样的，然后通过动态执行我猜应该是可以解出这些变量的值的。能不能对if语句段进行加密和混淆，让他看不出这里是if的语句。（关于代码的加密和混淆还需要看相关文章）

攻击者可以构建运行环境（例如，特殊模拟器）来运行app并观察在环境中运行的任何代码的执行。

这篇文章给出了两个SDC的实现方式，第一种需要定制安卓的虚拟机系统，也就是说当用户用的安卓没有定制时就不可以。第二种交Twin_SDC,说是通过安卓本机来实现代码块的解密，具体的没有太看懂。

4. Evaluation of Resource-Based App Repackaging Detection in Android

我们根据不同资源文件类型的个别分数尝试重新打包检测。我们使用18种文件类型作为特征向量，评估了具有这些特征的几个分类器，并发现通过分别考虑不同类型的文件来提高该方法的有效性。在最好的情况下，使用非优化的随机森林分类器，我们实现了0.9919的F-度量，大大改善了基于单一分数的方法。

其使用的方法是计算所有资源文件的哈希值，包括APK所有的文件（图形，文本，布局和多媒体内容，classes.dex，库文件和清单文件）

Jressim（A，B）= |HA∩HB| / |HA∪HB|，Jressim就是它的相似性得分。HA,HB分别为A和B的哈希值。

这篇文章中给出了一些相似性的计算公式：

后面的改进就是根据文件类型对文件先进行分类，以类别作为特征，然后使用随机森林对应用进行分类，得到分类的结果。

这篇文章的做法其实就是使用机器学习来分类，实现一个分类器，这样的话其实需要找到足够多并且准确的数据集作为训练的特征。文章中找了1000多对应用作为数据集。他说这篇文章中给出了数据集：Li, L., Li, D., Bissyand?, T.F., Lo, D., Klein, J., Le Traon, Y.: Ungrafting malicious code from piggybacked Android apps.Technical report, SnT, University of Luxembourg (2016)，网址是这个：https://github.com/serval-snt-uni-lu/Piggybacking/tree/master/data，但是里面但是只看到了APP的hash值。然后这个数据集在文章1中也提到了。

其他常见的检测方法

解析目录结构

2012年，Li S提出采用文件目录结构对应用相似性进行评估[13]，用树结构表示应用的文件结构，计算树之间的距离，由此得到应用之间的距离，该方法可以检测重打包应用、嵌入已知恶意代码应用。但是，该方法会有较高的误判率，因为不考虑应用的程序代码信息，对包含代码的classes.dex文件并没有解压分析，只计算资源文件信息，得到的信息量太过匮乏。

基于Dalvik字节码

DroidMoss基于Dalvik字节码，分别提取了官方市场和第三方市场上应用的作者信息和代码，然后计算散列值比较重打包应用的变化。DroidMoss的缺点是需要有官方应用作为参照，一旦无法区分官方应用和第三方应用，该方法将会失效。

一种新的距离指标设计的最近邻搜索算法

一种新的距离指标设计的最近邻搜索算法并实现了PiggyApp，克服了可拓展性的限制，可以用于成对比较，其算法复杂度减少到O(nlogn)，该系统提出了一种Manifest App的概念，能够自动嵌入水印和提取水印，该概念指的是受保护应用的伴侣应用，如果应用程序在虚拟机上运行的时候，伴侣程序可以触发应用程序显示水印。PiggyApp采用了自动测试生成技术来产生Manifest App，所以整个过程完全自动化，不需要用户的参与。PiggyApp提供了指纹技术来提取有用的特征，并将这些有用的特征转化为特征向量，提出通过线性数值搜索算法来度量应用之间的相似度。

More

随后更多的学者参与其中，提出了很多的检测方案。例如基于依赖关系图[16, 17]，基于控制依赖图[18-20]，基于系统调用图[21-23]，基于函数调用图[24, 25]，基于图着色算法[26]。目前也有很多的代码相似性检测的系统，比如JPlag[27]，Moss，Sim[28]，YAP3[29]等，这些系统大部分采用的属性计数和结构分析相结合的方案。

广告对于重打包分析的影响

有的时候一个重打包的应用可能植入了很多的广告，通过代码植入的，然后这样的话就会导致重打包应用和非重打包应用有很大的差别，这样的话其实也可以通过给定阈值来分析，去除资源后的目录签名与带资源的目录签名各自给一个影响因子，综合给出判定阈值。

在之前的前一篇文章中提到过,在原始的APP中加入广告也是重打包的一种方式.一个方法的,不可能是十全十美,总会是在各种权衡下找到一个最优值.在这里,我们需要提取出Android的资源来做判断.我们想一想,一个ANDROID的广告,不管是弹框的,内嵌的,不知道还是一个条幅跑出来的.你能看的见的,这些Activity都是资源,假设一个APP被嵌入了太多的广告,这样必然会影响我们的判断准确性.所以,在判断的过程中,想要提高准确性,广告的去留是一个需要慎重考虑的因素.

数据集

1. 这个文章给出了一组公共库，其实在做检测的时候公共库还是有影响的：Li Li, Tegawendé F. Bissyandé, Jacques Klein, Yves Le Traon, An Investigation into the Use of Common Libraries in Android Apps, The 23rd IEEE International Conference on Software Analysis, Evolution, and Reengineering (SANER 2016), 2016 [[pdf]文章给出了公共库，已经star
2. Androzoo这是一个由数个市场（包括Google Play，appchina，anzhi），开源存储库（包括F-Droid）和研究人员数据集（如MalGenome数据集）：来源于文章Kevin Allix, Tegawend´e F Bissyand´e, Jacques Klein, and Yves Le Traon. Androzoo: Collecting millions of android apps for the research community. In The 13th International Conference on Mining Software Repositories (MSR), Data Showcase Track, pages 468–471.ACM, 2016.这篇文章也可以看一下，应该是也有数据集，到时候可以看一下。

乱七八糟的想法

1. 对于UI的组件的布局一般是没有问题的，而且这样的话是避免广告的影响，而且读取相同名字的XML的组件的布局，然后取比较序列的相似度就可以UI的相似性。

2. 构建程序依赖图，就是把源码全部解出来，然后取分析谁调用了谁，这种方法的话难度太大了。

3. 其实不用分析相似性，可以看成是分类，通过某种指标将应用程序分类，聚成一类的看做重打包

4. 文章3中的SDC方法是可以加密代码的对吧，使用程序的校验和来加密某一段程序，重打包之后就会程序的校验和就会发生改变，然后恰好程序运行时若是正好调用了这部分代码，然后由于解密的时候解密错误，发生异常，程序就会报出错误，就会运行异常发生崩溃。这样的就能知道这是异常应用了。最好就是加在很多的地方，然后就出问题的地方会比较多，然后重打包的话其实一般是添加恶意代码，我们不需要知道恶意代码是什么，然后他要想把加密的东西去除，也要查找所有的代码，因为他不知道我们在哪里添加了加密的东西。然后加密密码攻击者也是不能获得的。而且为了混淆我们也可以使用不同的代码来做。

   代码混淆和代码加密技术

   这样还有一个问题就是重打包测试者也会测到，然后测到哪个位置后有加密的然后去删除，但是这样也是增加了难度。其实上面的想法已经有人在做了，开发人员可能会加密程序中的某些代码，使攻击者难以阅读或修改，并隐藏应用程序内的密钥。当包含所有代码的应用程序暴露给攻击者时，可以找到密钥。

5. 遵循与基于资源的重新包装检测相同的直觉，并对图像文件应用感知散列以检测类似的图片。它侧重于将布局文件表示为树布局哈希并搜索类似的布局结构。其实这个方法是搜索布局文件并表示成树结构然后计算哈希值，求哈希值之间的相似性。

6. 是不是能够遍历类，有哪些类是共有的，有哪些类是不一样的，有哪些呀是新的，有哪些是删除的，然后给出一个相似性的公式，就和文章1中的一样。或者是别的，比如说遍历到的UI布局，或者是权限的申请。关于UI布局和权限的申请还需要读几篇相关的文章。

   总结一下吧，文章看的稀里糊涂的，刚开始看安卓的东西，一上来看的文章也都是IEEE的文章，创新性都比较强，看起来有些吃力，这两周起步的也比较晚，看的文章也不多，看完之后的想法也是乱七八糟的，先记下来，还是多看看文章，然后在回来看这些想法。

基础知识

Android中的文件

1. .so文件是动态链接库。
2. Java源文件通过Java编译器生成CLASS文件，再通过dx工具转换为classes.dex文件。
   DEX文件从整体上来看是一个索引的结构，类名、方法名、字段名等信息都存储在常量池中，这样能够充分减少存储空间，相较于Java字节码文件更适合手机设备。
3. dex是Android平台上(Dalvik虚拟机)的可执行文件, 相当于Windows平台中的exe文件, 每个Apk安装包中都有dex文件, 里面包含了该app的所有源码, 通过反编译工具可以获取到相应的java源码。
4. Manifest文件中存储了文件的权限。

工具

1. 开源静态分析工具Androguard
2. soot是一个相当官方的，能够进行java代码分析的工具。当然，.apk文件也可以进行分析。
3. DroidMoss可以用于检测第三方应用市场的 恶意软件，可以作为辅助对比工具使用
4. DNADroid专注于执行应用程序代码的成对相似性比较以检测重新打包的应用程序。