-
-
[翻译]Things You May Not Know About Android (Un) Packers(2018 NDSS)（Packer）
-
2022-3-15 16:50
-
Things You May Not Know About Android (Un) Packers: A Systematic Study based on Whole-System Emulation(2018 NDSS)（Packer）
一、前言
最近在学习研究Android方面的壳方面相关知识，在阅读大量文献，总结整理后，有一天突然发现整理的笔记丢失了很多，因此突然觉得可以将自己整理的阅读笔记分享出来，大家可以一起交流学习，本系列将研究翻译Android近些年的加壳和脱壳方面的文章，希望能给大家提供一些帮助。
二、翻译
1.摘要
本文问题：很少人研究Android加壳的独特特性
本文工作：
1 2 3 | （1）本文报告第一个对主流Android打包程序的系统研究，并试图理解其安全影响（2）本文开发了基于全系统仿真的Android 打包框架DroidUnpack（3）与现有工具相比，该框架依赖于Android运行时的内在特征，进一步使虚拟机检查能够精确地恢复隐藏代码 |
2.介绍
由于恶意程序和良性程序都利用打包技术来隐藏代码，这导致分析程序的难度加大
（1）打包技术理解
本文调查了广泛的Android打包，并从安全影响方面描述了使用这些打包的应用程序
本文主要针对哪些方面的问题:
1 2 3 4 5 6 7 8 | 今天的Android打包程序如何使用，是否被恶意软件作者滥用？Android恶意软件对打包程序的利用有多广泛？Android应用中有哪些不同的商业包装和定制包装，分别如何随时间变化？Android打包程序是如何工作？Android 打包程序与传统打包的区别？在应用程序中应用包装程序有什么安全影响？恶意开发者很容易利用商业服务打包恶意软件和剽窃应用？Android打包程序一直在进化，如何进化，未来趋势是什么？今天的解包程序表现如何？在最先进的封隔器存在情况，是否仍然有效？ |
但是发现目前没有一种现有技术能够执行跨Java和本机代码分析
（2）研究和发现
为了解决上面的问题，本文开发了一个基于系统仿真的Android打包分析框架DroidUnPack
DroidUnPack被设计最低级别监视并重构java层执行，可以在Native层和java层两者捕捉写后执行的解包行为
在这个分析框架中，我们对数据集进行研究：
1 2 3 4 | Android打包程序被恶意软件开发者严重滥用Android商业包装器很容易用来打包恶意软件和剽窃应有，是的检测这些应用变得更加困难一些打包者给打包程序引入严重的安全漏洞，会导致数据泄露和任意代码执行Android打包随着过去一些年新行为的发展，导致一些最先进的拆包也失效 |
（3）本文的贡献
1.我们设计并实现一个DroidUpPack的新工具，可以从Android系统的多个层次自动重构语义视图，并通过四个不同的分析器可靠地捕获打包行为
2.我们从2010到2015对所以主流Android打包程序和大量应用程序进行首次大规模研究，我们研究揭示对包装技术及其生态系统的新理解和见解
（4）本文结构
本文第三节介绍了Android包装的独特性
本文第四节阐述了DroidUnPack的涉及与实现
本文第五节描述了我们大规模研究的研究方法
本文第六节阐述了我们的研究和发现
本文第七节对之前的相关研究进行了综述
3.Android打包程序的特点
本节中我们描述了Android和传统PC之间影响研究的三个主要差异：
（1）系统、运行时和应用程序
Android的系统架构和运行时和传统PC有很大不同
Dalvik虚拟机：安装时dexopt工具会优化输入Dex字节码并创建odex文件，以提高运行时效率，执行时DVM启动字节码解释器，将dex代码转换成目标体系结构的本机代码
ART虚拟机：ART采用提取编译AOT，会生成机器码，通过dex2oat将输入的dex可执行文件转换为oat文件
应用程序运行时库（libdvm.so）或libart.so解释或编译Java组件以生成和启动本机指令
（2）解包技术
与PC端不一样是，Android包含native和Java组件的场景，根本上说，缺乏监视java级别行为的能力
Android的解包程序不都原生，一般分为三种类型：
1 2 3 | 基于签名的内存转储解包器，如Kisskiss基于hook的内存转储解包器DexHunterDalvik数据结构转储和Dex文件组件拆包为AppSpear |
存在问题：
所有Android解包程序都依赖Java级别的信息，而不是打包程序的内在性质，即原始代码将被动态生成，然后执行，导致不能检测和分析以前未知的打包技术和理解native层发生的事情，以及Java与native交互
（3）Android系统
Android系统本来只能从google市场下载，但是恶意应用利用打包技术，绕过市场的安全审查，渗透到生态系统中
Android商业包装服务是免费提供给用户的
4.DroidUnPack系统
（1）关键理念
为了解决Android中检测和分析解包行为的独特挑战：
1 2 | 在最低级别监控应用程序的行为，这样我们不会错过任何与解包相关的行为重构Java级执行，为了精确检测和更好理解解包行为 |
为了捕获内在特征，我们在native代码监视应用程序的执行，标记污点内存区域，以及代码执行发生本机和Java级别，通过这种方式我们可以检测和分析发生某个级别和两者结合的拆包行为
采用全系统仿真的方法，运行android系统和感兴趣的应用程序在一个仿真器，可以很容易监视应用程序发起的内存读写，通过native执行重构Java执行，可以可靠检测拆包代码的执行
（2）DroidUnPack
我们选择在DoroidScope上构建DroidUnPack，DroidScope是一个基于QEMU和dvm的动态检测框架，支持在Linux和DVM端进行指令跟踪，不支持ART，不能恢复ART中的高级代码语义
重建运行Android应用程序的ART视图:
我们开发几个工具来研究打包的Android程序:
1 2 3 4 | （1）隐藏代码提取器精确地识别和转储包含隐藏DEX、OAT方法的内存区域（2）多层解包检测器发现多层中间发生的迭代解包操作（3）自修改代码检测器检测到一个更隐秘的解包行为，该行为故意清除以前的可执行代码（4）JNI Inspector 搜索通过JNI接口进行的敏感API调用 |
（3）重构语义视图
语义视图包括两个不同层次的视图：os视图和art视图，依赖DroidScope来恢复os级视图
我们修改了DroidScope来支持art级别语义的重构，我们设法恢复应用程序名称、编译和解释的Java方法
应用程序名称:
应用程序名称在Android应用程序解包是起到重要作用
编译Java方法:
1 2 3 | 我们进一步恢复从Dex代码中预编译的本机函数的相应Java方法名、偏移量和大小hook函数ArtMethodDroidunPack遍历每一个oatClass类，然后迭代OatMethodHeader，找到相应的OatMethod代码大小 |
解释Java代码:
我们通过在libart中hook DoCall函数，然后从每个ArtMethod追踪到相应的DexFile，还获得了ArtMethod的dex方法索引，从而提取它的名称、偏移量、大小和字节码指令
（4）代码行为分析
在DroidUnPack的独特功能支持下，我们启用四个代码分析器来理解Android打包器的行为
隐藏的OAT/DEX代码提取：
1 2 3 4 | 我们可以在运行时提取打包的可执行代码程序计数器pc检查当前运行的函数func是ArtMethod::Invoke()还是DoCall()，如果是，进一步获取内存区域memmethod，该区域包含将要执行的编译或解释的Java方法截取内存写操作，以获取修改后的内存地址，然后拿出数据启用JavaScript，会跳过Webview执行的行为，防止出现误报 |
自修改代码检测：
1 2 | 自修改代码是一种特定类型的解包，除了引入解密的新代码，还会修改以前启动的可执行文件通过收集每个执行的基本块区域memcode，所有的这些代码块的聚合含Memcode表示之前执行的代码，检测到memmehtod则表明存在自我修改 |
多层拆包检测：
1 | 针对于可能出现的多层代码层数 |
Java native接口检测：
1 | DroidUnPack可以可靠的检测每个JNI调用的入口和出口，并推断边界，进一步检测Java和native层进行的所有调用，DroidUnPack 专注于检测本地组件通过JNI调用的敏感 Android API调用 |
Discussion：
1 2 3 | 数据压缩和编码技术：数据压缩和编码不算封装技术支持Android版本：DroidUnPack基于DroidScope构建，支持Android4.2 和Android 5.2模拟检测：DroidUnPack使用一种基于仿真的方法，如果应用程序检测到模拟器存在时隐藏所有行为，系统将无法进行任何自动行为分析 |
5.研究方法
（1）数据集和设置
1 2 3 4 5 6 7 8 9 10 | 数据集1 阿里 、apkprotect、百度、Bangcle、ijiami、奇虎、腾讯等数据集2 实现5个具有代表性的应用程序，将它们作为参考，与打包对比，利用数据集1的打包程序生成打包程序数据集3 为了研究恶意软件中的打包技术，从VirusTotal中收集了恶意软件，其中至少50%被标记为恶意软件数据集4 最近的5个恶意程序 Android.Malware.at plapk.a, Android.Troj.at fonefee.b,candy corn, braintest and ghostpush数据集5 我们收集了在主流学术和行业安全会议上发表的三个最先进的Android解包程序 |
（2）方法论
数据集：数据集部分描述用于回答特定问题集的数据示例
挑战和解决方案：挑战和解决方案列出了在研究期间要解决的所有技术挑战及我们提出的解决方案
详细分析：详细分析部分描述了为了探究答案而要执行的建议分析
局限性：限制部分将详细讨论我们的分析可能存在的限制
<1>问题1
1 2 3 | Android包装程序(包括商业包装服务)是否被恶意软件作者滥用?Android恶意软件对打包程序的利用有多广泛?Android应用中有哪些不同的商业包装和定制包装?分布如何随时间变化? |
挑战和解决方案:
1 2 3 4 | 需要了解恶意软件样本中Android打包程序的存在: 我们利用DroidUpPack中的多层解包检测能力来理解包装的存在商用包装器在不同版本中都具有强大而稳定的特征： 我们依靠这些特征来识别不同商业包装者的存在 |
详细分析：
1 2 3 | 第一组问题 我们使用DroidUpUnPack执行数据集中的所有恶意样本，并记录不同包装器的存在和使用情况 然后我们提取每个样本的创建时间，并研究了不同年份的分布情况 |
局限性：
1 | 我们只收集了6个打包程序的签名，且不完整，但是我们认为这六种是最受欢迎和代表性的 |
<2>问题2
1 2 3 4 5 | Android打包程序是如何工作的?这跟传统包装有很大区别吗?应用Android打包程序对应用程序的安全影响是什么?恶意开发者是否很容易利用商业包装程序并打包他们的恶意软件或剽窃的应用程序?问题2主要关于Android打包的详细行为和影响 |
数据集：
为了解事实，我们利用数据集2进行研究，利用数据集4研究商业包装者的恶意软件和剽窃辩护
挑战和解决方案：
挑战1：我们需要将打包代码的行为和原始代码分离
1 | 通过DroidUnPack运行良性和打包应用来进行对比，记录其行为 |
挑战2：充分理解Java层、Native层、JNI层的交互
1 2 3 | Java级别，我们使用DroidUnPack中隐藏代码提取器来打包Dex代码，并使用工具FlowDroid进一步执行静态分析Native级别，我们检索os级视图，利用DroidUnPack自修改代码检测器和多层解包检测器来观察解包行为JNI交互，DroidUpPack中的JNI检查器被用来监视通过JNI发生的一切，特别是敏感API调用 |
详细分析：
1 2 | 为了了解商业封隔的安全影响，我们使用1DroidUpPack提取隐藏代码，并通过静态分析工具和人工调查添加封隔器代码为了进一步打衡量打包对恶意软件检测的影响，我们将打包的恶意软件样本提交给VirusTotal |
局限性：
1 | 我们分析中涉及人类对行为的调查，可能一些行为没有引起我们的注意，被忽略 |
<3>问题3
1 2 | Android打包是否在发展，如何发展?这种发展的未来趋势是什么？ |
数据集：
1 | 我们选择数据集2和数据集3在内的所有示例来实现此目的 |
挑战和解决方案：
1 | 不可避免的是打包程序必须在执行原始代码之前执行解包过程，解包层数是最近几年发现的作为进化的标志 |
分析：
1 | 我们通过执行所有打包的恶意软件样本来考虑拆包层的数量，并利用DroidUpPack的多层拆包检测来收集不同年份的层分布信息，可以分析行为的进化 |
局限性：
1 | 与PC的打包对比，我们目前的测量绝不是全面和完整 |
<4>问题4
1 2 3 | 现在的Android解包程序表现如何？在最先进的封装器隔离存在情况下，它们是否有效？关于当前Android解包程序的性能 |
数据集：
1 | 我们利用数据集5，测试有效性使用数据集2和数据集3 |
挑战和解决方案：
1 | 理解当前Android解包程序的设计和基本限制。解决这一挑战的方法是通过研究文献和源代码，以便完全理解这些解包者 |
分析：
1 | 我们对每个解包器的基本设计和局限性进行了手工分析 |
局限性：
1 | 三款Android解包工具都是最先进的工具，但可能还存在其他独特设计并分享不同见解的工具 |
6.我们的发现
（1）问题1：高水平情况
研究人员利用打包技术逃避检测、并渗透Android生态系统中
<1>问题1.1：Android打包程序是否被恶意软件作者滥用？
Android打包程序被恶意软件作者滥用，在恶意软件中普遍存在
恶意开发者广泛利用打包技术来隐藏恶意
<2>问题1.2：Android应用中有哪些不同的商业包装和定制包装？
打包程序的分布趋势
<3>问题1.3：分布如何随时间变化？
Android商业打包程序越来越多被恶意软件滥用，其中商业包装程序比例越来越高，而个人定制打包程序的比例在逐渐下降
1 2 3 | 总结 研究Android打包技术对于恶意软件分析是十分有益的，也是很必要的 虽然定制包装机仍然占主导地位，但是随着商业包装程序越来越受欢迎，我们需要关注商业包装程序 |
（2）问题2：Android打包程序独特的包装技术
<1>问题2.1：Android打包程序是如何工作的？这跟传统包装程序有很大区别吗？
具有很大差异，我们总结了六种常见的打包程序特征：
1 2 3 4 | 通过JNI恢复应用程序上下文Native/Dex 混淆多层打包程序拆包预编译AOT |
<2>问题2.2：应用Android打包程序对应用程序的安全影响是什么？
Android打包程序会导致严重的安全漏洞和数据泄漏，我们的研究总结应用程序存在严重的组件劫持漏洞和信息泄露问题
组件劫持漏洞：可以去进一步提取组件的信息，查看漏洞情况
信息泄露漏洞：商业打包程序添加代码到原始代码中，会导致信息泄漏的问题，腾讯打包程序就收集了敏感的用户数据，可以通过FlowDroid来发现信息漏洞
影响：奇虎打包存在组件劫持的漏洞
<3>问题2.3 恶意开发者是否很容易利用商业服务打包他们的恶意软件和剽窃应用？
恶意开发者很容易利用商业包装程序来打包，逃避检测
除了apkprotect，很多包装商都在提供在线服务
恶意软件检测较难，打包恶意软件检测更难：
1 2 | 奇虎在恶意软件检测表现较好，阿里检测也不错，VT表现较差Android打包程序在剽窃检测上比较难检测 |
（3）问题3：Android Packers的发展
<1>问题3.1 Android打包程序是否在不断发展，如何发展？这种发展的未来趋势是什么？
Android打包程序发展趋势不断增加，表现为：拆包的层数和特征行为
拆包的层数:
1 | Android定制包装程序正在快速发展 |
行为:
1 | 随着拆包器的不断出现，打包也在不断发展，以及Android版本的更新，新的打包技术发展，如何解决识别新的打包程序，需要考虑 |
未来的演变趋势:
Android打包正在快速发展，未来的Android打包技术将进一步限制推进几个方向
1 2 3 | 如何恢复语义信息Android包装策略越来越复杂，多层如何检测，如何快速脱取Android打包技术最终转向基于仿真的打包技术，可能击败DroidUpPack在内的现有解包程序 |
（4）问题4 Android解包
<1>问题4.1 今天的Android解包程序表现如何？最先进的封包器存在，是否有效？
今天的解包程序并没有像预期的那样正常工作
最先进的解包程序有严重的设计限制，它们不能处理先进的Android1打包程序，目前分类
1 2 3 | 通过签名找到dex文件进行内存转储修改DVM，hook重要函数，找回dex文件修改DVM，将Dalvik数据结构在空中转储，然后组装回Dex文件 |
我们挑选三个最先进的解包器和DroidUpPack进行比较:
设计选择:
1 2 3 4 | Kisskiss遵循一个传统拆封过程，被编译到一个单独程序，通过ptrace来附加和访问目标应用程序的内存，根据内存映射，最后执行内存转储DexHunter是基于对现有打包器保护设计，通过定制Dalvik和ART运行时的类加载器，然后保证odex的所有类都被初始加载、正确定位、然后提取AppSpear采用基于Dalvik的字节码提取和DEX重组技术，一旦主活动被解释或新的DEX被加载，AppSpear提取内部的DDS来重组恢复DEX文件DroidUpPack通过利用整个系统仿真技术，监测在覆盖程序代码区域上的执行来检测打包的应用程序，并依赖Android运行时的内在特征，来恢复隐藏代码 |
局限性:
1 2 3 4 5 | 不能在系统的多层次上拥有完整的视图，也不能以完整方式检测未知的打包器Kisskiss存在限制，对于拥有反调试和内存中混淆，难以解包DexHunter通过hook来定位内存，可是关键函数libc反调试，可以导致无效，多层解包和自修改代码会导致错误的代码转存，dexHunter必须在类加载时触发hook来转储AppSpear只能针对Dalvik，并不能针对ARTDroidUpPack只能针对执行代码，这样一些未执行的代码就很难去应对，可以根据主动调用解决 |
实验:
1 2 3 | 我们设计实验在Android 4.3和Android 4.4模拟器，DexHunter和Kisskiss有两个数据集，收集自修改恶意软件样本Kisskiss表现不好，不能拆包，针对6个包装器DexHunter可以针对指纹，但是只使用腾讯封装器 |
7.相关工作
（1）包装和拆包技术
传统的PC端，已经对运行打包程序进行了充分研究：
1 2 3 4 | Polyunpack对静态反汇编的二进制代码及其执行轨迹进行了差异分析，并通过观察差异来发现潜在的隐藏代码Renovo应用了整个系统仿真来解包，并能够在指令级跟踪程序的执行。它检测内存写入和执行，以检测未打包的代码，它可以解决多层解包问题，并为每个检测层创建代码转储Omniunpack还在页面粒度上监视内存写入和执行。它的目的是提供一个高效和有弹性的拆封器，因此依赖于操作系统中的内存保护机制来实现检测Eureka也进行了粗粒封隔器分析。它首先监视系统调用以搜索写入和执行的内存，然后依靠启发式识别和提取解密代码 |
Android的拆包：
1 2 3 | Kisskiss利用ptrace访问应用程序内存，并基于启发式搜索隐藏的DEX代码DexHunter针对封装器使用的反调试机制，在Dalvik VM和ART运行时对类加载函数进行了测试AppSpear更进一步，将所有发现的隐藏类拼接在一起，重新组装成一个完整的程序 |
Android的打包：
1 2 3 | Bayer等人[17]研究了经常被恶意软件作者使用的现成包装器Ugarte-Pedrero等人提出了一种相当全面的测量方法，以了解封隔器的复杂性我们的研究重点是解释进化的包装和拆封技术，适应了新的Android环境 |
（2）Android应用程序分析
我们做了很多工作来深入分析应用程序行为：
1 2 | （1）Ded [22]， DroidSIFT [41]， CHEX [28]， PEG [18]， FlowDroid [15]， DroidSafe[24]和AppAudit[38]练习静态数据流分析，以识别Android应用中的特定代码（2）TaintDroid[21]、DroidScope[39]、CopperDroid[35]、VetDroid[42]进行动态污染分析检测运行时可疑行为 |
8.总结
本文针对商业包装者，对现有进行研究，开发DroidUpPack，完整的系统仿真Android解包，精确恢复代码
打包会引入各种严重漏洞，找到证据来证明定制包装程序的流行和快速发展
看雪招聘平台创建简历并且简历完整度达到90%及以上可获得500看雪币～
|
|
|---|---|
