【Android源码 栏目提醒】:本文主要为网学会员提供“Android应用的恶意代码注入 - 毕业设计”,希望对需要Android应用的恶意代码注入 - 毕业设计网友有所帮助,学习一下!
Android 应用的恶意代码注入摘要:本文分析了
Android 应用文件和
Android 系统广播机制的特点,介绍了一种基于 SDK 的
Android 应用恶意代码注入的方法,并且用该方法测试了 30 款
Android 应用,通过实验说明了
Android 应用软件缺少防止恶意注入的安全机制。
关键词:信息安全;代码注入;恶意软件;
Android 。
Malicious Code Injection for
Android Applications【Abstract】 This paper analyzes the vulnerability of the apk file format and the broadcastfunctionality of
Android OS introduces a malicious code injecting method based on
Android SDK andtests thirty applications with this method to demonstrate that the
Android application lacks protectionagainst malicious code injection .【Key words】Information Security Code Injection Malware
Android.0. 引言 2011 年 3 月,黑客通过将名为“DroidDream”的恶意代码注入到多款应用中并上传到
Android 市场,最终导致超过一万用户下载并安装使用了带有恶意代码的软件。
尽管 Google通过远程方式清除了这些终端上的应用,并将超过 50 款带有“DroidDream”的应用下架,但是从此之后“DroidDream”的各类变体不断出现,严重威胁着
Android 生态体系。
这类应用的特点是:将已注入恶意代码的应用伪装成正常应用,应用安装后,恶意代码通过一定条件触发执行,完成进一步的恶意行为1。
由于对
Android 平台发布的时间较短,黑客能够利用的漏洞有限,所以通过注入恶意代码并伪装成正常应用进行发布和传播仍是他们使用的主要方式。
网秦发布的 2012 年第二季度
Android 手机安全报告显示,约有八成的恶意样本是将恶意代码注入到系统应用、游戏或桌面壁纸等应用中的。
由此可见,对
Android 应用恶意代码注入方式的研究对现阶段
Android 平台的安全防护具有重要的意义。
1.
Android 恶意代码注入的原理
Android 程序能够被恶意注入,根本上是
Android 应用文件的自身特点和系统的某些功能能够被攻击者利用,以下将就这两方面详述。
1.1
Android 应用 APK 文件的特性 在
Android 系统中,所有的应用格式都被加以后缀名 apk,其实质上是 zip 格式的文件,用户用 pc 上的解压缩软件打开 apk 文件就可以看到它的结构,不过其中各类文件都是经过编译的,直接打开无法浏览其内容。
但是通过互联网可以轻易地获得
Android 平台各类逆向工具来反编译 apk,进而得到 apk 中包含的以 dex 为后缀的源程序字节码文件,程序所需的各类资源文件,签名文件,以及关键的程序描述文件 AndroidManifest.xml2。
1.2 AndroidManifest.xml 文件的重要作用 AndroidManifest.xml 文件存在于每一个 apk 中,描述了
Android 系统运行该应用所必须的全局配置信息。
在这些信息中,对代码注入最有价值的有三处:第一,程序使用的各类组件的声明,包括 Activity,BroadcastReceiver 和 Service 等;第二,程序的入口点,一般是包含
android.intent.action.MAIN的 Activity;第三,程序使用受保护 API 或订阅特定广播消息时所需权限的声明。
通过分析 AndroidManifest.xml 文件提供的这些信息,可以获得代码注入的两种思路:替换原程序的入口点或者使用 BroadcastReceiver 使恶意代码在接收到特定消息的时候触发,并开启其他 Service 或 Activity 执行恶意行为,而这两种选择都只要在 AndroidManifest.xml 中修改或添加相应组件,并声明所需权限即可。
事实上,替换原程序入口点正是恶意代码“DroidDream”所采用的注入手段1,本文不再赘述;而另一种设想的可行性,还需要
Android 系统广播机制的支持。
1.3
Android 系统的广播机制
Android 系统的广播机制,从抽象层面可描述为软件设计模式中的“观察者模式”,也可以理解为分布式模型中的“消息发布者-订阅者”模型3,如图 1 所示: 系统广 播 系统广播 应用二 动态注册,订阅系统广播 应 用 应用一 一 的 广 播 返回结果 查 应用三 应用程序安装信息 询 应用程序安装信息 … 静态注册,订阅应用一的广播 图1
Android 系统的广播机制 其中广播消息发布者包括系统本身和应用程序,广播消息的订阅者则是各类应用软件,而广播消息则对应于
Android 系统的 intent。
intent 中封装了动作信息和其他数据信息, 由动作信息包括当前已完成的动作或者下一步将要执行的动作。
Android 系统广播的 intent一般封装当前已完成的动作3,如“ACTION_BOOT_COMPLETED”;由应用程序广播的 intent 。
一 般 包 含 下 一 步 将 要 执 行 的 动 作 , 如 “ ACTION_CALL ” 订 阅 广 播 的 应 用 需 要 注 册BroadcastReceiver 和其中的 IntentFilter 组件,IntentFilter 对广播消息进行筛选,只有满足条件的 intent 才会被应用接收。
BroadcastReceiver 的注册方式有动态和静态两种,动 态 注 册 的 BroadcastReceiver 由 ActivityManagerService 直 接 管 理 ,ActivityManagerService 接收到对应的 intent 就直接发送到订阅的应用;静态注册有关信息则由 PackageManager 维护,在需要时查询并向 ActivityManagerService 提供订阅者信息,然后再由其发布。
静态注册和动态注册最重要的区别是:在
Android3.1 的版本之前,静态注册的 BroadcastReceiver 即使在程序处于未运行状态时,仍然可以接收广播;而动态注册则只有程序启动并运行完注册相关的代码之后才能接收广播,并且程序退出之后,动态注册的 BroadcastReceiver 也将被解除注册,不能再接收广播。
当订阅者完成 BroadcastReceiver的注册之后,如果接收到符合条件的 intent,就会执行相应的回调函数4。
除上述特点之外,
Android 系统广播通路的开放性很高,广播的生产者可以产生系统全局的广播,广播的订阅者只需要从中选择自身关注的消息,而广播生产者和订阅者之间没有依存关系,它们完全不知道对方的存在。
这种机制从一定程度上为系统的实现和应用的开发提供了较高的扩展性和灵活性5,但是如果从攻击者的角度分析,由生产者发布的广播,尤其是系统广播,由于其面向全局,并且广播产生的时机稳定,无疑成为了恶意代码触发条件的很好选择。
虽然
Android 系统要求特定的广播订阅需要一定权限,但是这些权限的声明完全由订阅者声明,攻击者只要在 AndroidManifest.xml 中注册组件的同时声明相应的权限即可,并且订阅的有优先级也可以由订阅者制定6,这就为恶意攻击提供了更大的操作空间。
通过上述分析可知,如果恶意代码通过广播消息驱动的模式设计,并以静态注册的方式在 AndroidManifest.xml 中声明相应组件、订阅的广播和权限,那么在接收到订阅的广播之后,恶意代码就会被触发开始执行恶意行为,这在理论上是可行的。
其行为模式如图 2 所示: 图2 恶意代码的行为模式1.4 恶意代码注入的危害 在恶意代码被触发之后,可以启动其他恶意组件,例如:攻击者可以设计启动一个Activity 欺骗用户,诱使用户输入隐私信息;或者启动 Service 是恶意程序长时间在系统 “DroidDream”恶意程序就是启动 Service 之后,利用驻留,进行持续的监听和破坏行为。
系统漏洞提升自身权限并进行进一步的破坏1。
2.
Android 恶意代码注入的实现2.1 恶意代码的注入点 通过原理部分的分析,可以得到恶意代码组件和权限声明的注入点就是AndroidManifest.xml 文件,然而恶意代码实现的源代码部分也需要一个注入点,这就需要结合
Android 逆向技术来进一步分析。
在目前
Android 平台的开源逆向工具中,有一部分工具,例如 apktool,可以将 apk 中dex 格式的程序源代码部分反编译成为类汇编的 smali 代码,用户可直接修改 smali 代码以及 apk 的其他内容,包括资源文件和 AndroidManifest.xml,然后经过重新打包签名的 apk可以继续安装使用2,国内很多程序汉化工作就是以类似的方式进行。
分析上述的逆向手段,可以得出源代码的注入点就是 smali 代码。
只要将应用文件和恶意代码文件分别逆向得到各自的 smali 代码和 AndroidManifest.xml,在应用的 smali 代码中加入恶意代码的部分,同时修改 AndroidManifest.xml 中的对应条目就完成了恶意代码的注入。
2.2 恶意代码注入的过程 将上述的思想整理、细化,就可以得到完整的恶意代码注入过程,如图 3 所示: 图3 恶意代码的注入过程 针对上述过程,本文使用
Android2.3 系统和
Android SDK,举例说明一个简单的恶意代码的设计和注入方式,而对于其中的逆向,重新打包和签名的步骤,由于已有大量相关书籍文献,本文不再详述。
2.2.1 恶意代码的编写根据前文描述设计思路,恶意代码由订阅系统广播的 BroadcastReceiver 组件 Service 组件构成,BroadcastReceiver 收到系统广播之后启动 Service。
因此,恶意代码应包含两个类,InjectingReceiver 和 InjectingService , 其 中 使 用 BroadcastReceiver 组 件 的InjectingReceiver 类主体代码如下: public void onReceiveContext context Intent intent Intent mIntent new Intentcontext InjectingService.class context.startServicemIntent 在本例中,InjectingReceiver 订阅了
android.intent.action.BOOT_COMPLETED这个系统广播,因此在收到此广播之后 onReceive 回调函数将会执行,启动 InjectingService。
2.2.2 恶意代码的注入的实现本例以一个简单的应用 targetApp 作为目标注入代码,这个应用只包含一个入口 Activity,其 AndroidManifest.xml 主体部分如下:在注入恶意代码之后,AndroidManifest.xml 主体部分将变为:最后将反编译过的恶意代码按照 AndroidManifest.xml 中声明的路径加入到反编译后的目标应用代码中,就完成了代码注入的工作。
将 targetApp 重新打包、签名、安装,重新启动手机,可以发现 InjectingService 已经开始运行了,如图 4 所示: 图4 恶意代码注入的运行结果 从图 4 中可以看到 InjectingService 使用的是 targetApp 的进程。
这是由于
Android系统是以应用为基本单位分配进程空间,从注入后的 AndroidManifest.xml 文件中可以发现InjectingService 被注入到了 targetApp 的应用空间中,所以 InjectingService 也一定是运行在 targetApp 的进程中,即使将 InjectingService 声明为远程服务,它的远程服务进程也依赖于 targetApp 的进程。
因此,图所示的结果是符合预期的,至此代码注入已经完成。
3.
Android 恶意代码注入的实验和结果分析 根据上一节叙述的代码注入流程,进一步进行实验。
应用样本软件来自
Android Play,包括非安全防护类的系统软件和应用软件两类,共 30 款。
实验用恶意代码依然沿用上述设计,包括 InjectingReceiver 和 InjectingService,但是 InjectingReceiver 增加了监听系统电量变化和连接、断开电源的系统广播。
根据 Google 提供的 2012 年 10 月最新的市场占有率,选取前四位的
Android 系统版本作为实验测试环境,
Android4.0 分别为
Android2.3,和
Android2.2 以及
Android2.1 及之前的版本。
实验设备分别为 HTC G7,HTC G8,摩托罗拉 ME525,三星 P6200。
实验结果如表 1 所示: 表1
Android 应用恶意代码注入实验结果测试系统 测试设备 应用数量 成功注入 恶意代码运行情况 实验说明
Android G7 12 12 InjectingService 能够触发执行,当手机 应用安装到 2.3 作为存储设备与 PC 连接后或外存卡被卸载 外存 后,服务会被终止
Android P6200 8 8 代码只有在用户运行应用并且没有强制退 应用安装到 4.0 出时能被触发运行,如果应用被强制退出, 系统内存 InjectingService 也终止
Android ME525 6 6 InjectingService 能够触发执行,当手机 应用安装到 2.2 作为存储设备与 PC 连接后或外存卡被卸载 外存 后,服务会被终止
Android G8 4 4 InjectingService 被正常触发运行 应用安装到 2.1 系统内存 从实验结果可以看出,随着
Android 的不断升级,部分新的系统约束和新增的功能确实 表会削减注入的恶意代码对系统和用户的威胁。
2 中列举了两点对恶意代码注入有较大影响的升级变化: 表2
Android 系统的部分升级及其对恶意代码注入的影响 起始版本 系统变化 对恶意代码注入的影响
Android 2.2 应用可以安装在外存卡上,但是将收不到系 被注入的应用如果被安装在外存卡 统的“启动完成”广播,并且当移动设备作 上,恶意代码将有可能失效或者被 为存储设备与 PC 连接时或外存卡被卸载时, 中断运行。
7 运行于外存卡上的应用将被终止 。
Android 3.1 应用程序增加了“停止态”。
首次安装未被 被注入的恶意代码将无法脱离用户 执行和被强制终止的程序都处于“停止态” 自动触发,并且即使被触发,也有 , 此期间它们无法接收订阅的广播。
直到程序 可能被中断运行。
被用户执行,“停止态”结束,应用恢复对 7 订阅广播的接收 。
表 从试验的结果分析, 2 中描述的两点变化减少了恶意代码的触发条件,增加其持续运行的难度,同时使用户更多的介入系统和应用的管理授权。
然而,从实验中恶意代码成功注入的应用数量来看,
Android 的不断升级,还是没有办法改变
Android 的应用程序本身缺乏保护机制的局面,特别是程序中基于 SDK 开发的部分。
即使开发者对源程序进行混淆,应用依然可以被轻易地逆向编译和修改,由于应用的入口点、使用的组件和权限声明都集中在 SDK 开发的部分,而且
Android 应用的签名机制也不能禁止这些被修改过的程序继续被安装使用,因此
Android 恶意注入的技术要求和成本都是较低的,而这也是
Android 应用恶意注入不断出现的重要原因。
4. 结论 本文分析了
Android 系统的相关原理,结合实例介绍了基于 SDK 的
Android 应用恶意代码注入的方法,并用该方法作为实验手段,对一些
Android 应用进行了恶意代码注入的测试,实验说明:Google 对
Android 系统的不断升级在一定程度上完善了系统广播机制的安全性,提高了系统的防止恶意代码自动触发的能力,但是
Android 应用中,基于 SDK 开发的程序部分仍然缺少防止恶意注入的保护机制,这个问题是目前
Android 应用恶意代码注入不断出现的重要原因。
参考文献1 Lookout Mobile Security. Complete DroidDream-lookout Mobile Security Technical Tear DownOL. 2011.http:// lookoutmobilesecurity.org2 NOLAN G. Decompiling AndroidM. New York. Apress 20123 杨丰盛. Anroid 技术内幕:系统卷M. 北京. 机械工业出版社. 20114 CHIN E FELT A P GREENWORD K et al. Analyzing Inter-Application Communication in AndroidA.Proceedings of the 9th Annual Symposium on Network and Distributed System Security. MobiSys 2011C. 20115 邓平凡. 深入理解
Android:卷IM. 北京. 机械工业出版社. 20116 ENCK W OCTEAU D MCDANIEL P et al. A Study of
Android Application SecurityA. Proceedings of the20th USENIX Security Symposium. USENIX Security ’11C. 20117 Google Inc.
Android Platform OverviewOL.2012. http://source.
android.com/source/overview.html