最近在学习研究Android方面的壳方面相关知识,在阅读大量文献,总结整理后,有一天突然发现整理的笔记丢失了很多,因此突然觉得可以将自己整理的阅读笔记分享出来,大家可以一起交流学习,本系列将研究翻译Android近些年的加壳和脱壳方面的文章,希望能给大家提供一些帮助。
本文问题:很少人研究Android加壳的独特特性
本文工作:
由于恶意程序和良性程序都利用打包技术来隐藏代码,这导致分析程序的难度加大
本文调查了广泛的Android打包,并从安全影响方面描述了使用这些打包的应用程序
本文主要针对哪些方面的问题:
但是发现目前没有一种现有技术能够执行跨Java和本机代码分析
为了解决上面的问题,本文开发了一个基于系统仿真的Android打包分析框架DroidUnPack
DroidUnPack被设计最低级别监视并重构java层执行,可以在Native层和java层两者捕捉写后执行的解包行为
在这个分析框架中,我们对数据集进行研究:
1.我们设计并实现一个DroidUpPack的新工具,可以从Android系统的多个层次自动重构语义视图,并通过四个不同的分析器可靠地捕获打包行为
2.我们从2010到2015对所以主流Android打包程序和大量应用程序进行首次大规模研究,我们研究揭示对包装技术及其生态系统的新理解和见解
本文第三节介绍了Android包装的独特性
本文第四节阐述了DroidUnPack的涉及与实现
本文第五节描述了我们大规模研究的研究方法
本文第六节阐述了我们的研究和发现
本文第七节对之前的相关研究进行了综述
本节中我们描述了Android和传统PC之间影响研究的三个主要差异:
Android的系统架构和运行时和传统PC有很大不同
Dalvik虚拟机:安装时dexopt工具会优化输入Dex字节码并创建odex文件,以提高运行时效率,执行时DVM启动字节码解释器,将dex代码转换成目标体系结构的本机代码
ART虚拟机:ART采用提取编译AOT,会生成机器码,通过dex2oat将输入的dex可执行文件转换为oat文件
应用程序运行时库(libdvm.so)或libart.so解释或编译Java组件以生成和启动本机指令
与PC端不一样是,Android包含native和Java组件的场景,根本上说,缺乏监视java级别行为的能力
Android的解包程序不都原生,一般分为三种类型:
存在问题:
所有Android解包程序都依赖Java级别的信息,而不是打包程序的内在性质,即原始代码将被动态生成,然后执行,导致不能检测和分析以前未知的打包技术和理解native层发生的事情,以及Java与native交互
Android系统本来只能从google市场下载,但是恶意应用利用打包技术,绕过市场的安全审查,渗透到生态系统中
Android商业包装服务是免费提供给用户的
为了解决Android中检测和分析解包行为的独特挑战:
为了捕获内在特征,我们在native代码监视应用程序的执行,标记污点内存区域,以及代码执行发生本机和Java级别,通过这种方式我们可以检测和分析发生某个级别和两者结合的拆包行为
采用全系统仿真的方法,运行android系统和感兴趣的应用程序在一个仿真器,可以很容易监视应用程序发起的内存读写,通过native执行重构Java执行,可以可靠检测拆包代码的执行
我们选择在DoroidScope上构建DroidUnPack,DroidScope是一个基于QEMU和dvm的动态检测框架,支持在Linux和DVM端进行指令跟踪,不支持ART,不能恢复ART中的高级代码语义
重建运行Android应用程序的ART视图:
我们开发几个工具来研究打包的Android程序:
语义视图包括两个不同层次的视图:os视图和art视图,依赖DroidScope来恢复os级视图
我们修改了DroidScope来支持art级别语义的重构,我们设法恢复应用程序名称、编译和解释的Java方法
应用程序名称:
应用程序名称在Android应用程序解包是起到重要作用
编译Java方法:
解释Java代码:
我们通过在libart中hook DoCall函数,然后从每个ArtMethod追踪到相应的DexFile,还获得了ArtMethod的dex方法索引,从而提取它的名称、偏移量、大小和字节码指令
在DroidUnPack的独特功能支持下,我们启用四个代码分析器来理解Android打包器的行为
隐藏的OAT/DEX代码提取:
自修改代码检测:
多层拆包检测:
Java native接口检测:
Discussion:
数据集:数据集部分描述用于回答特定问题集的数据示例
挑战和解决方案:挑战和解决方案列出了在研究期间要解决的所有技术挑战及我们提出的解决方案
详细分析:详细分析部分描述了为了探究答案而要执行的建议分析
局限性:限制部分将详细讨论我们的分析可能存在的限制
挑战和解决方案:
详细分析:
局限性:
数据集:
为了解事实,我们利用数据集2进行研究,利用数据集4研究商业包装者的恶意软件和剽窃辩护
挑战和解决方案:
挑战1:我们需要将打包代码的行为和原始代码分离
挑战2:充分理解Java层、Native层、JNI层的交互
详细分析:
局限性:
数据集:
挑战和解决方案:
分析:
局限性:
数据集:
挑战和解决方案:
分析:
局限性:
研究人员利用打包技术逃避检测、并渗透Android生态系统中
Android打包程序被恶意软件作者滥用,在恶意软件中普遍存在
恶意开发者广泛利用打包技术来隐藏恶意
打包程序的分布趋势
Android商业打包程序越来越多被恶意软件滥用,其中商业包装程序比例越来越高,而个人定制打包程序的比例在逐渐下降
具有很大差异,我们总结了六种常见的打包程序特征:
Android打包程序会导致严重的安全漏洞和数据泄漏,我们的研究总结应用程序存在严重的组件劫持漏洞和信息泄露问题
组件劫持漏洞:可以去进一步提取组件的信息,查看漏洞情况
信息泄露漏洞:商业打包程序添加代码到原始代码中,会导致信息泄漏的问题,腾讯打包程序就收集了敏感的用户数据,可以通过FlowDroid来发现信息漏洞
影响:奇虎打包存在组件劫持的漏洞
恶意开发者很容易利用商业包装程序来打包,逃避检测
除了apkprotect,很多包装商都在提供在线服务
恶意软件检测较难,打包恶意软件检测更难:
Android打包程序发展趋势不断增加,表现为:拆包的层数和特征行为
拆包的层数:
行为:
未来的演变趋势:
Android打包正在快速发展,未来的Android打包技术将进一步限制推进几个方向
今天的解包程序并没有像预期的那样正常工作
最先进的解包程序有严重的设计限制,它们不能处理先进的Android1打包程序,目前分类
我们挑选三个最先进的解包器和DroidUpPack进行比较:
设计选择:
局限性:
实验:
传统的PC端,已经对运行打包程序进行了充分研究:
Android的拆包:
Android的打包:
我们做了很多工作来深入分析应用程序行为:
本文针对商业包装者,对现有进行研究,开发DroidUpPack,完整的系统仿真Android解包,精确恢复代码
打包会引入各种严重漏洞,找到证据来证明定制包装程序的流行和快速发展
(
1
)本文报告第一个对主流Android打包程序的系统研究,并试图理解其安全影响
(
2
)本文开发了基于全系统仿真的Android 打包框架DroidUnpack
(
3
)与现有工具相比,该框架依赖于Android运行时的内在特征,进一步使虚拟机检查能够精确地恢复隐藏代码
(
1
)本文报告第一个对主流Android打包程序的系统研究,并试图理解其安全影响
(
2
)本文开发了基于全系统仿真的Android 打包框架DroidUnpack
(
3
)与现有工具相比,该框架依赖于Android运行时的内在特征,进一步使虚拟机检查能够精确地恢复隐藏代码
今天的Android打包程序如何使用,是否被恶意软件作者滥用?
Android恶意软件对打包程序的利用有多广泛?
Android应用中有哪些不同的商业包装和定制包装,分别如何随时间变化?
Android打包程序是如何工作?
Android 打包程序与传统打包的区别?在应用程序中应用包装程序有什么安全影响?
恶意开发者很容易利用商业服务打包恶意软件和剽窃应用?
Android打包程序一直在进化,如何进化,未来趋势是什么?
今天的解包程序表现如何?在最先进的封隔器存在情况,是否仍然有效?
今天的Android打包程序如何使用,是否被恶意软件作者滥用?
Android恶意软件对打包程序的利用有多广泛?
Android应用中有哪些不同的商业包装和定制包装,分别如何随时间变化?
Android打包程序是如何工作?
Android 打包程序与传统打包的区别?在应用程序中应用包装程序有什么安全影响?
恶意开发者很容易利用商业服务打包恶意软件和剽窃应用?
Android打包程序一直在进化,如何进化,未来趋势是什么?
今天的解包程序表现如何?在最先进的封隔器存在情况,是否仍然有效?
Android打包程序被恶意软件开发者严重滥用
Android商业包装器很容易用来打包恶意软件和剽窃应有,是的检测这些应用变得更加困难
一些打包者给打包程序引入严重的安全漏洞,会导致数据泄露和任意代码执行
Android打包随着过去一些年新行为的发展,导致一些最先进的拆包也失效
Android打包程序被恶意软件开发者严重滥用
Android商业包装器很容易用来打包恶意软件和剽窃应有,是的检测这些应用变得更加困难
一些打包者给打包程序引入严重的安全漏洞,会导致数据泄露和任意代码执行
Android打包随着过去一些年新行为的发展,导致一些最先进的拆包也失效
基于签名的内存转储解包器,如Kisskiss
基于hook的内存转储解包器DexHunter
Dalvik数据结构转储和Dex文件组件拆包为AppSpear
基于签名的内存转储解包器,如Kisskiss
基于hook的内存转储解包器DexHunter
Dalvik数据结构转储和Dex文件组件拆包为AppSpear
在最低级别监控应用程序的行为,这样我们不会错过任何与解包相关的行为
重构Java级执行,为了精确检测和更好理解解包行为
在最低级别监控应用程序的行为,这样我们不会错过任何与解包相关的行为
重构Java级执行,为了精确检测和更好理解解包行为
(
1
)隐藏代码提取器精确地识别和转储包含隐藏DEX、OAT方法的内存区域
(
2
)多层解包检测器发现多层中间发生的迭代解包操作
(
3
)自修改代码检测器检测到一个更隐秘的解包行为,该行为故意清除以前的可执行代码
(
4
)JNI Inspector 搜索通过JNI接口进行的敏感API调用
(
1
)隐藏代码提取器精确地识别和转储包含隐藏DEX、OAT方法的内存区域
(
2
)多层解包检测器发现多层中间发生的迭代解包操作
(
3
)自修改代码检测器检测到一个更隐秘的解包行为,该行为故意清除以前的可执行代码
(
4
)JNI Inspector 搜索通过JNI接口进行的敏感API调用
我们进一步恢复从Dex代码中预编译的本机函数的相应Java方法名、偏移量和大小
hook函数ArtMethod
DroidunPack遍历每一个oatClass类,然后迭代OatMethodHeader,找到相应的OatMethod代码大小
我们进一步恢复从Dex代码中预编译的本机函数的相应Java方法名、偏移量和大小
hook函数ArtMethod
DroidunPack遍历每一个oatClass类,然后迭代OatMethodHeader,找到相应的OatMethod代码大小
我们可以在运行时提取打包的可执行代码
程序计数器pc检查当前运行的函数func是ArtMethod::Invoke()还是DoCall(),如果是,进一步获取内存区域memmethod,该区域包含将要执行的编译或解释的Java方法
截取内存写操作,以获取修改后的内存地址,然后拿出数据
启用JavaScript,会跳过Webview执行的行为,防止出现误报
我们可以在运行时提取打包的可执行代码
程序计数器pc检查当前运行的函数func是ArtMethod::Invoke()还是DoCall(),如果是,进一步获取内存区域memmethod,该区域包含将要执行的编译或解释的Java方法
截取内存写操作,以获取修改后的内存地址,然后拿出数据
启用JavaScript,会跳过Webview执行的行为,防止出现误报
自修改代码是一种特定类型的解包,除了引入解密的新代码,还会修改以前启动的可执行文件
通过收集每个执行的基本块区域memcode,所有的这些代码块的聚合含Memcode表示之前执行的代码,检测到memmehtod则表明存在自我修改
自修改代码是一种特定类型的解包,除了引入解密的新代码,还会修改以前启动的可执行文件
通过收集每个执行的基本块区域memcode,所有的这些代码块的聚合含Memcode表示之前执行的代码,检测到memmehtod则表明存在自我修改
针对于可能出现的多层代码层数
DroidUnPack可以可靠的检测每个JNI调用的入口和出口,并推断边界,进一步检测Java和native层进行的所有调用,DroidUnPack 专注于检测本地组件通过JNI调用的敏感 Android API调用
DroidUnPack可以可靠的检测每个JNI调用的入口和出口,并推断边界,进一步检测Java和native层进行的所有调用,DroidUnPack 专注于检测本地组件通过JNI调用的敏感 Android API调用
数据压缩和编码技术:数据压缩和编码不算封装技术
支持Android版本:DroidUnPack基于DroidScope构建,支持Android4.
2
和Android
5.2
模拟检测:DroidUnPack使用一种基于仿真的方法,如果应用程序检测到模拟器存在时隐藏所有行为,系统将无法进行任何自动行为分析
数据压缩和编码技术:数据压缩和编码不算封装技术
支持Android版本:DroidUnPack基于DroidScope构建,支持Android4.
2
和Android
5.2
模拟检测:DroidUnPack使用一种基于仿真的方法,如果应用程序检测到模拟器存在时隐藏所有行为,系统将无法进行任何自动行为分析
数据集
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解包程序
数据集
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解包程序
Android包装程序(包括商业包装服务)是否被恶意软件作者滥用?
Android恶意软件对打包程序的利用有多广泛?
Android应用中有哪些不同的商业包装和定制包装?分布如何随时间变化?
Android包装程序(包括商业包装服务)是否被恶意软件作者滥用?
Android恶意软件对打包程序的利用有多广泛?
Android应用中有哪些不同的商业包装和定制包装?分布如何随时间变化?
需要了解恶意软件样本中Android打包程序的存在:
我们利用DroidUpPack中的多层解包检测能力来理解包装的存在
商用包装器在不同版本中都具有强大而稳定的特征:
我们依靠这些特征来识别不同商业包装者的存在
需要了解恶意软件样本中Android打包程序的存在:
我们利用DroidUpPack中的多层解包检测能力来理解包装的存在
商用包装器在不同版本中都具有强大而稳定的特征:
我们依靠这些特征来识别不同商业包装者的存在
第一组问题
我们使用DroidUpUnPack执行数据集中的所有恶意样本,并记录不同包装器的存在和使用情况
然后我们提取每个样本的创建时间,并研究了不同年份的分布情况
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入!
最后于 2022-3-15 16:51
被随风而行aa编辑
,原因: