Android Root及提供商:一把双刃剑-程序员宅基地

技术标签: Android 漏洞分析基础  android  

摘要

Android Root 是一个自愿、合法获取设备最高权限和完全用户控制设备的过程,为了满足大众需求,一个独一无二的Android Root生态系统已经形成,也促使各种各样的Root提供商提供Root服务。尽管合法,以及许多通过Android系统漏洞的一键root方法,但假如没有控制好,这些利用会被恶意软件作者使用来获取未授权的特权。

为了理解这些风险,我们对许多流行且神秘的Android root提供商做了一项研究,主要关注:1)他们的利用是否被充分的保护.2)他们自己的利用和公开的利用之间的关系。我们发现尽管采用了保护措施和努力,但这些措施会被被我们发现的弱点破坏。从一个大的提供商我们提取了160多个利用二进制,而且还在不停的更新,对应于50多个漏洞族,超过了我们能够找到的公开的利用数量。我们能够确定至少10个设备驱动利用是没有被公开报道过的,除此之外,提供商还改造了一个流行的内核漏洞(futex bug)的89个变异体来覆盖不同版本的Android设备和配置。更糟糕的是,只有很少一些利用程序能够被杀毒软件检测到。

分类和主题描述

D.4.6【操作系统】:安全和保护—攻击性软件。

概述

Security、Measurement

关键字

Android root exploit,root provider

1 介绍

在我们这个时代,用户并没有充分的控制个人智能手机和平板电脑等移动设备。由于用户的越来越多的需求,提供root和越狱服务形成一个独一无二的生态系统。Root和越狱是获取Android和IOS设备上完整特权的一个过程。他们允许用户绕开运营商、操作系统和硬件制造商的限制,随着完全的设备控制,用户可以卸载臃肿软件、享受额外的需要root权限的专业应用提供的功能,或者运行免费或付费应用。

根据设备是否被flash,分为两种root方法:1)软root。2)硬root。前者指的是通过直接运行一个软件来获取root(即,root利用),后者指的是通过更新包或者刷ROM的方式刷入一个su二进制程序。取决于设备类型和操作系统版本,采用不同的root方法,例如,由于许多设备取消了bootloaders,这些设备不能使用硬root方法,类似的的,假如一个特殊的设备没有任何软件或硬件漏洞,则软root也是不可能的。在实践中,像许多其他系统一样,Android设备也有各种各样的漏洞存在于各种组件:内核,驱动,和应用,会在&2做总结。

在本文中,我们将会专注于软root方式,因为一些利用可能被恶意软件使用,因此软root比硬root更加危险。在Android中,这样的root 服务被一些团体提供。个人开发者或黑客经常挖掘漏洞,开发和发布利用工具来会获得名声。然而,由于Android设备的硬件多样性,分散的软件系统版本,以及提供商的定制【34】,对个人来说不大可能为漏洞设计大量的利用来覆盖大范围的设备。因此,出现了提供root的业务【10,8,13】。

有趣的是,大多数商业root提供者都是免费使用的。在Android设备上运行利用来root是用户的自愿行为,例如,通过一键root应用(oneclick app)[10,8,13].不幸的是,攻击者也很容易通过伪装普通用户来获得这样的利用。更糟糕的是,一些大的root 提供商拥有大量的利用方法库,且发明新的利用方法来保持其领先地位。这可能让攻击者有强烈的动机瞄准这些提供商。

在本文中,我们将检查root生态系统来理解下面的高级问题:1)有多少Android漏洞类型和变种是公开存在的,他们和商业提供商的区别。2)究竟有多难滥用root提供商提供的利用。我们将会通过一系列的测量和特征化公开的root利用以及提供商提供的。

论文的贡献如下:

  • 我们通过全面的测量研究android的软root来总结它们的原因和趋势。我们发现:1)大多数公共的Android应用层利用只影响特定类型的设备。2)虽然内核漏洞被认为是最危险的,但在一个设备上开发的利用可能需要通过适配才能工作在另一个设备上。3)随着内核漏洞变得越来越少,设备驱动程序成为发现root利用的主要目标。

  • 我们分析了root提供商为他们利用添加的保护措施。尽管大的提供商会使用更多的保护措施,但我们仍可以识别到系统的弱点和缺陷,这些将会大大的破坏他们的努力。这个结果显示了他们需要更好的安全措施来保护这种危险的行为。

  • 我们利用网上在线利用多样性调查,调查范围涵盖从大的安全公司到个人开发者。我们报告了大的提供商不仅保持“秘密”的利用,同时还花费大量的努力来改造现有的利用。

2 公开的有效的Android Root利用

在本节中,我们试图详尽的收集所有公开已知的android root利用或者漏洞,理解他们的特征。尽管根据报道,root利用已经被恶意软件使用[43,28,19],我们仍然缺乏一个完整的最新的关于他们的信息,在最近的两年,我们没有找到系统性的研究恶意软件是如何使用root利用相关的信息,目前还不清楚哪些利用是目前正在被使用的,哪些更容易被恶意软件使用,哪些可能在将来出现,我们的目标就是通过当前和公开可用的资源来理解这个问题。

数据源和收集方法。我们调查了大量的公共资源包括学术论文[30],研究项目[1],出版书籍[26],以及在线知识库(eg,CVE数据库或论坛帖子,如XDA)[9、6、2、5].搜索条件包括“Android root”,“root exploit”,和“特权提升(privilege escalation)”。基于我们专业的知识,我们尝试收集一个详尽的清单,这个清单是我们最好的努力成果,最终我们收集了一个包含73个利用和漏洞的清单。

在大多数情况下,一个漏洞(CVE编号)映射到一个相应的利用。然而,将在2.2节中描述,我们公开的可用的利用中无法找到一些小的CVEs子集,在许多情况下,相反的情况也是可能的—没有CVE编号但利用是可用的,可能是因为其只针对很少的设备类型。

我们也观察到许多利用需要多个漏洞配合来获取root。例如,主键漏洞(e.g, ANDROID-8219321)只会拿到系统用户特权,所以还需要额外的漏洞来完成root利用[16]。在这种情况下我们认为是两个漏洞。在调查中,我们还发现5个漏洞仅可以获取系统特权,3个漏洞可以从系统特权中获取root权限(我们仍然算他们8个)。此外,一些利用是相互关联,相互转化。当利用可以通过技术细节定位到CVE编号或漏洞时,我们也考虑他们是不同的利用,这种包容性策略更能发现完整的利用和漏洞。

在高级别上,我们我们能够找到足够的有关漏洞和利用的技术描述,虽然他们在细节、清晰度和可利用的源代码或二进制上有显著差异。也许在意料当中,我们发现大部分的利用信息都不是来自学术研究。

很多问题需要回答。我们的目标是通过分析回答下面的问题:

  1. 有多少一般VS特殊的利用存在?直观的说,一些利用比其他更普遍,特别是那些内核漏洞利用。一些利用也许只可能是用于特定供应商。

  2. 利用源代码和二进制是否公开可用?运行这些利用的要求是什么?是否可以通过一个独立的app来使利用工作,e.g,无须用户干预或引导进入恢复模式?

  3. 杀毒软件是否可以识别到这些利用?

2.1 Root利用的影响和覆盖率

为了理解一个利用的影响和覆盖率,我们首先尝试确定目标层次,这是因为影响的不同取决于层次,例如,假如一个setuid漏洞程序(在应用程序层)被安装在一个供应商的某款手机中,那么它的影响是有限的,我们将基于Android的体系结构将层次划分为四类:

Linux内核。由于其特权地位,针对Linux内核很自然的实现对一个Android设备的完全控制。特别是,一个内核漏洞会影响所有运行了这个漏洞的内核的设备,例如,TowelRoot(CVE-2014-3153)利用了futex系统调用BUG来获取root访问,这个漏洞影响所有3.14.5以前版本的设备,在这个类别中,我们包含了所有运行在内核中的利用,但不包含下面的内容。

特定于供应商的内核或驱动。不同于运行在几乎每台设备上的主要内核代码,供应商定制的内核(eg,高通Linux内核的定制分支)或者供应商为各种外围设备(eg,相机、声音)提供的设备驱动程序[42],这样的代码运行在内核空间里,并且他们的漏洞也可以导致完全控制设备,考虑到他们是由一个团体制造,可能没有公开审计、有些闭源(eg,特别是设备驱动程序)的特性,他们定制的部分产生漏洞的机会可能很大,我们的调查结果也印证了这一点。然而,由于不是所有的Android 设备都运行相同的一组定制的内核或驱动程序,一个特定于定制设备的利用仅能影响Android设备的一个子集(eg,某些三星设备)。

库层。在库层次的利用主要针对Android库或者被用来支持不同应用的第三方库。例如,在ZergRush利用(CVE-2011-3874)中,libsysutils所使用的卷管理器守护程序(作为root用户运行)被发现有一个栈溢出漏洞,将会导致root权限提升[26]。这样的漏洞库可能产生很大的影响,因为这个库可能被很多个程序包含,只要其中的一个程序以root权限运行,并且使用了漏洞代码,那么一个root利用就可以被成功的构造。ObjectInputStream漏洞(cve-2014-7911)是另外一个例子。

应用程序和应用程序框架。应用层root利用主要包括被setuid使用程序引入漏洞逻辑、系统应用或服务引入。此类利用的影响取决于漏洞是否是第三方程序,到目前为止,大多数都是第三方情况,所以影响有限。一个例子是一个仅出现在XoomFe设备上的漏洞setuid使用程序存在一个命令注入漏洞[21]。两一个例子是某些中兴设备上附带的一个backdoor-like setuid二进制程序(CVE-2012-2949)。

一般来说,从高到低,利用的影响和普遍性的顺序如下:1)内核利用。2)被系统进程使用的库。3)系统程序或服务。4)特定于供应商的设备驱动、应用和程序。

我们不能准确的预测每一个利用影响的设备,因为内核代码和Android系统代码比运营商定制的代码使用的更广泛。此外,内核漏洞的补丁更加难以迅速的推送到用户终端进行更新。

这里写图片描述

层次分解图。如图1所示,在73个利用中,有54个利用是特定于运营商的(浅灰色),有19个一般利用(黑灰色)。特定于运营商的利用包括所有的设备驱动利用和特定于运营商的应用和程序。应用层被发现的利用最多,并且他们中的大多数都是特定于运营商,外部驱动层数量仅次于应用层,但都是特定于供应商,预计内核层和库层利用数量最少,但却非常通用且极其危险。在我们的调查中发现,新内核层利用每年发现的数量也相对稳定—平均每年只有1~2个。

这里写图片描述

时间维度。另一个一个重要维度是时间。具体地说,漏洞的生命周期取决于补丁的版本日期。后来发现,漏洞的生命周期越长,影响越大。另一方面,发现的越早,root利用被开发的越快。图2显示了每年被发现的利用数量,正如我们虽见,在2013年左右,大量的供应商定制的外部驱动层和应用层漏洞被提出。其中一个关键问题是,在许多定制的Android系统上的设备文件的访问权限太弱[42],没有一个应用进程甚至不能打开这些设备文件并发起攻击(without which an app process cannot even open these device files and launch exploits.)。这个时期恰逢Android市场份额和参与的运营商增加。另一方面,内核和库层有一个相对稳定的模式。

显然,随着运营商定制过程中常见错误被修改,特定于供应商的漏洞数量将会下降。然而,它总是很难预测新的趋势和利用的种类,随着用户强烈的需求,我们相信root利用在将来仍将继续存在,例如,在撰写本文时,一个新的命名为PingPong[40]的内核级root利用被宣布。

覆盖范围。从理论上讲,一个内核漏洞将会影响所有在漏洞被引入和被修复之间的所有内核版本,因此最近发现的内核漏洞如TowelRoot(CVE-2014-3155)应该有一个有效的覆盖范围,然而,将会在第三章节中看到,事情通常并不是这样,在实践中,一个内核利用可能取决于系统配置、地址空间布局、编译选项等,因此,为了成功的root一个设备,恶意软件[43]和root提供者通常会试图使用多个利用。

2.2 利用(二进制和源代码)的可用性

在本节中,我们的目标是了解现有的在互联网上公开使用的利用源代码或二进制的可用性,特别是,可用性是恶意作者可以发现和利用这些利用程序的一个直接指标。众所周知,恶意软件已经开始开始嵌入root利用,这些root利用来自公共的资源[43],目前还不清楚有多少这样的利用被定位和滥用。

为了定位利用的源代码和二进制文件,方法是简单的使用相关的关键字包括CVE编号、google Bug ID(eg,ANDROID 3176774)、影响的设备模型和利用的昵称(eg,TowelRoot)。为了确保足够的覆盖率,我们会经过两轮独立的网络搜索。

在73个样例中,我们能定位到源代码或二进制的利用共计68个,仅5个没有任何发现。其中一个因为仅在一个虚拟的研究中描述过所以是不可用的。其他的尽管关联的CVE清楚的表明他们允许任意代码执行,但还是不能定位到资源,我们对于这个不确定问题的根源的一个合理解释,是发现漏洞的人没有公布技术细节或任何概念验证利用程序(POC)。也有可能这些漏洞没有足够的吸引力吸引黑客构建利用。

从理论上讲,二进制程序和源代码对于恶意软件作者来说都是有价值的。一个恶意软件可以直接嵌入这个二进制程序,只要这个二进制文件是独立的块(eg,可执行文件或库),并具有清晰的接口。当然,源代码有许多其他的优点,因为他可以自由的定制和改进。

总的来说,有46个利用的源代码可用,其中18个利用了存在漏洞的文件权限和符号链接攻击[14],这些问题通常是被运营商引入,这些利用主要实现在shell脚本中,其余的都是用C语言编写的(一个使用了java CVE-2014-7911)。另一方面,有22个利用带有可用的二进制文件,主要是一下的格式:1)PC端的脚本可能推送额外的二进制文件到设备中。2)直接在设备上运行的APK。数量分别是10和12个。

我们观察到,尽管源代码通常更有价值,但他也许没有二进制文件健壮,特别是当源代码被提供作为“third-party”概念证明,特别是,为了适应不同设备和模型,需要相当大的迭代和设计工作,例如,仅towelroot二进制文件就需要做三个重大修改才能支持不同的设备。可用的源代码,但仅是概念证明,并且是被其他开发人员编写[4]。总之,恶意软件可能能够整合更多的利用,即使这些利用只有有限的覆盖范围。

2.3 Exploit 需求

即使一个利用的源代码或二进制文件被找到,仍需要理解运行他们的要求。例如,一个利用也许需要一个adb shell setup 通过一个PC链接—因为只有作为shell 用户运行的进程可以执行这个利用。一个利用也许需要用户交互(eg, 引导进入恢复模式至少触发漏洞)。

为了理解利用的要求,我们执行了两个步骤:1)定位利用作者或者其他相关的人发表的技术报告或教程[21]。2)假设1)不可用,我们尝试阅读利用的源代码或脚本,通常它们会包含这些信息,事实证明这两个步骤可以覆盖大部分利用。

从利用的技术细节和源代码,我们能够确定以下主要的需求(从最严格到最宽松):

  • 需要用户交互。这类情况不多,一个例子是要求用户下载一个APP并且手动终止安装[7]。一个是需要用户至少一次引导进入恢复模式[18].另外一个要求用户手动把设备设置到”battery saving”模式[12]。最后一个要求用户打开一个运营商特定的app并且点击一个按钮[15]。直观的说,这类利用无法被恶意软件用来自动化root。
  • 需要使用adb shell通过PC链接。对于这类利用,需要adb shell链接,因为下面一些最常见的原因:1)利用可以成功修改local.prop中的一项设置,adb shell 可以通过这项设置获取root.2)利用需要写入一个文件,这个文件属于shell组和group-writable(不是全局可写的)[14]。3)利用的目标是adb守护进程,这就需要攻击继承以shell用户权限运行。例如,Rage Against the Cage 利用[11]的目标是adb守护进程未检测setuid()的返回值漏洞。
  • Reboot。通常来说,许多root利用需要至少一次重启。例如,一个动态连接符攻击将允许攻击者删除一个弱权限系统中的文件,eg,/data/sensors/AMI304_Config.ini,目的是在同一位置的受保护文件设置一个link,eg,/data/locat.prop。重启后,关联的初始化脚本试图改变原始文件的权限(i.e,/data/sensors/AMI304_Config.ini),使之改变成全局可写,实际上就是改变了linked 文件的权限(i.e,/data/local.prop)。
  • 无须任何权限。这类利用没有什么硬性的要求,但是,其中一些需要某些Android权限,比如READ_LOGS,目的是为了把拥有该权限的进程放置到特定用户组。如果利用有多个要求,我们只算最严格的那个(e.g,一个利用既需要abd shell 又需要重启,我们将它归为adb shell 类别)。总结的结果如图3.其中6个需要和用户交互,17个需要通过PC 链接的adb shell,6个需要用户重启设备,其余的44个没有任何硬性的要求,其中5个需要特定的android权限,大多数利用都是特定于运营商,而一般利用共计19个,其中有4个利用归为“Adb shell”,15个归为“无须任何权限”。

这里写图片描述

联想到共有68个利用有源代码和二进制文件,其中39个有效利用仅需要reboot、权限或无任何需求,这些利用可能被恶意软件使用,在后台静默的获取root权限。

3 Root 利用的适配

Vspace0.03in Android 因碎片化而出名,这是由于运营商和供应商定制[34]。一方面大量定制的Android设备的可用性,允许更大的市场占有率,两一方面,Android设备的多样性使之很难编写出工作在不同应用/内核配置和设置的设备上的健壮的root利用。

众所周知,许多利用程序需要适配才能跨设备运行。事实上,我们有理由相信正是由于需要适配,所以恶意软件作者不能够直接使用某些利用(e.g, zergrush 和 mempodroid)[28]。

通常,一个利用需要特定的环境才能运行。CPU、内核版本、OS版本的差异也许会导致运行失败。基于利用的内存破坏,需要了解一些关键数据结构的相对和绝对内存地址,这正是为什么需要进行适配的理由。例如,在CVE-2014-4322中,一个内核符号的地址被用来确定不同设备上的不同。需要注意,暴力方法在这里是行不通的,因为这可能会导致系统由于跳转到不可预知的地址而崩溃,极少情况下,诸如Exynosabuse,改进也许不是必须的,这种利用可以通过一个漏洞设备驱动访问任意物理内存并覆盖内核数据来获取root权限,这不像使用一个硬编码的静态地址那样,利用可以从内核空间开始的位置搜索来定位目标内核符号。当然,允许整个内核空间可访问的特殊漏洞很难出现,并且即使出现可能也局限于特定的设备类型,一般情况下,内核利用需要大量的适配,下面通过案例的研究来证明。

3.1 CVE-2014-3153 (Futex bug)

据报道,futex漏洞会影响2014年6月3日之前所有的内核版本,并首次使用在TowelRoot中,它最初被设计用来root Verizon Galaxy S5,后来修改后可以覆盖更多的设备,包括ATT Galaxy S5,Galaxy S4 Active,Nexus5 。尽管它声称,使用一个内核漏洞可以使之工作在许多Android 设备上,但一个硬件平台和内核版本的轻微变动,都可能导致这种高精度利用的失败。为了能够覆盖更多的设备,它增加了一个额外的功能来修改图5中不同的利用变量,我们将解释其中的一个关键变量,系统调用,详情如下。
这里写图片描述

系统调用变量使攻击者可以在四种可能的可以利用的系统调用中,选择一个来执行利用的一部分(The system call variable specifies one of the four possible system calls utilizable to carry out part of the exploit.)。过程是攻击设置一个内核堆上的指针来指向一个内核栈地址,这个内核栈地址会被一个系统调用重写。像图5中显示的,一个攻击者需要向一个系统调用传入恶意参数,这些参数将会被复制到内核中,并期望它们最终落在内核栈的目标地址。根据确定的内核版本的配置,有两个难点:1)目标堆栈地址可能相对于栈基址是变化的。2)恶意函数调用的参数可以达到的深度也可能是变化的。我们在图中展示了这些障碍。在第一种情况下,系统调用sendmmsg()的参数可以成功的覆盖到目标堆栈地址上。第二种情况,由于选择了错误的系统调用,参数无法命中目标地址。在第三种情况下,相同的系统调用sendmmsg,由于内核版本差异,到达的深度不同错过了目标地址。由于上述困难,towelroot建议使用者尝试不同的系统调用集合其他变量,希望命中目标地址。

4 Root提供商简介

正如之前提到的,存在大量的root提供者,范围涵盖个人开发到大型企业。在本节中,我们的目标是研究他们的以下方面:1)调查不同类型的root提供商,并了解他们如何运作。2)描述他们对危险的root利用所提供的保护强度。3)评估所选取提供商的利用,并了解这些利用和对应的公开可用的利用之间的关系。

这里写图片描述

通常情况下,小型提供商和大型提供商在提供可用资源上的差异主要原因就是上述几个方面。表1列出了很多受欢迎的root提供商,他们都包含了最新最大的利用方案。我们证实了大的提供商虽然提供了一套更全面的利用,但即使是现在,相应的保护措施却远远不够。事实上,我们已发现了严重的弱点,这允许我们可以从大的提供商提取和研究大部分利用的二进制文件。

我们深入的研究了9个提供商中的7个,为了安全考量我们不会公布他们的名字,如表2所示。
这里写图片描述

收集方法和结果。我们收集了三个主要类别的信息:1)关于每个提供商的公共信息,e.g,他们声称支持的设备数量,是一个PC端的程序或者是一个独立的Android APP,结果已显示在表1. 2)利用的信息,包括二进制的位置(e.g.,远程服务器端或本地)和他们的数量。3)root提供商为了利用不被逆向工程和被其他人滥用所采用的防御措施。通过这些信息可以粗略苹果有价值的利用被用于恶意目的的提取难度。2)和3)中收集的信息需要通过逆向过程来了解提供商的内部运作机制。

这里写图片描述

Root 提供商(指其产品)的架构。从我们研究的所有提供商中,我们得到了一个共性的架构,如图6所示。Root服务通常是通过一个PC端的程序或一个独立的一键root Android App提供。前者可以通过ADB接口控制一个设备,这种方式既可以利用ADB-related的利用,像“rage against the cage”,还可以实用其它的利用直接在Android设备上启动。而后者—Android App可以独立操作来执行root利用。

主要的程序逻辑包含了三个关键步骤:

STEP1:收集设备信息,如机型、内核和Android版本、硬件平台等等。

STEP2:基于STEP1收集到的信息,从远程服务器和本地存储获取适当的利用。

STEP3:在设备上执行选择的利用来获取Root权限。

利用的数量。这里我们主要关注可以通过Android app 直接启动的利用,因为他们一旦被攻击者偷取,更可能被滥用。在表2中,我们列出了每个提供者可以被定位的利用二进制文件数量。令人惊讶的是,最大的提供商包含了上百个。另外,这个数量仅是一个保守数字,因为还有一些我们没有找到的(章节5将会描述定位利用的详细细节)。这样的数量明显高于我们可以在公共资源找到的数量,这也强调了被攻击者攻击的风险。注意,我们按照发现的利用数量对表进行了排序,所以并不对应于表1,而且,我们也没有提供供应商的名字。

我们意识到,不同的提供者可能采用不同的方式把它们的利用组织到二进制文件中。一个二进制文件可以对应一个利用或者利用的变体,因此,简单的计算利用的数量可能是由误差的。在章节6,我们提供了一个对利用更全面的分析,而且和公开可用的利用做了对比。

保护措施。正如我们预期的一样,我们观察到,拥有更多利用的大的root提供商更倾向于采用更强的保护措施来保护他们的产品,更小的提供商则通常没有保护措施。例如,在表2中,提供商1和2不仅保护了Android 端的一键root APP,而且也引入了防探测和加密来保护他们的利用(通常是在native代码中)来防止利用被偷取和滥用。另外,也对从远程存储检索利用的通道进行了加密。相比之下,提供者6和7只提供了一些基本的保护措施,这看上去很容易被绕过。在这项研究中我们还发现了一些大的提供商整合了小提供商的应用程序或者直接利用他们的二进制文件,这个发现再次反应了缺乏保护措施的小的提供者通常是个人爱好者。不幸的是,正如我们将要在5.1章节中展示的,大型提供商提供的看似强大的防御措施,实际上基于我们发现的几个严重弱点,这些防御措施很快被我们瓦解。

PC-side VS Device-side 保护措施。要意识到PC-side程序和独立的Android app包含了读取设备信息和从远程服务器检索利用的功能,这是很重要的,因为,只要有一个保护不力,程序逻辑可能被暴漏,利用程序被恶意检索。

有趣的是,我们观察到保护强度的确不一致。与PC相比,Android的历史要短的多,这导致商用级别的保护方法很少,e.g.,VM-based 保护措施。我们调查发现大多数供应商提供的Android app保护措施比PC端弱的多,尽管他们会添加一些保护措施,并希望这些措施足够强大(e.g., ProGuard)。另一方面,提供者3采用了一种更强大的叫做“梆梆”的保护方案来保护Android app,但确没有任何保护措施保护他的PC程序。结果总结在表2. 其中“N/A”的情况表明我们并没有研究它,因为我们从另一端已经成功的逆向。

除了上面的观察结果,还有一些软件保护不一致的可能。首先,老版本和新版本的相同软件可能实现了相同代码功能,但强保护措施可能只存在于新版本。例如,我们观察到一个提供商的旧版本的Android 一键root app 明显弱于新版本的保护。其次,在极少情况下,一些root提供者可能互相共享代码,然而其中的一个版本别的弱。我们观察到的案例中两个提供商是合作关系。

5 保护机制的案例研究

供应商彼此的竞争力纯粹是由其包含的利用的多样性和质量决定,他们应该是高度安全的,无论是个人黑客或者是大公司提供的产品。我们希望看到保护他们代码的最佳实践。然而,即使的确采用了强大的保护措施,我们也识别了一些关键的(和一些明显的)缺陷,这将大大的削弱起效能。最后,我们能够抓取几乎所有的提供者提供的二进制文件。在本节中,根据利用的数量,我们将供应商分为三类。从每一个类别中我们将选取一个具有代表性的供应商进行研究,旨在找到他们保护措施的缺点和弱点。

正像在章节4中描述的那样,root过程分成三步。通过逆向可以知道每一步是怎么执行的,这将很容易偷取所有利用文件,并在任何获取root权限的恶意软件中运行他们。即使是最困难的提供者只花了一个研究生,这个研究生并不是一个专业的黑客,大约一个月的兼职工作来完成,这远远低于每个高敏感root服务的预期。作为参考,专业的赛门铁克研究小组花了大约6个月来分析出Stuxnet的基本结构和行为[27],这个病毒是一个国家支持的恶意软件用来攻击工业控制系统。在剩下的部分,我们将描述不同的root提供商的保护方法和每一个阶段的弱点的细节 。

5.1 大型root提供商

提供者P1(我们引用表2中的提供者n记为Pn)是当前最大的提供者,拥有超过一百对各利用二进制。其root服务是由PC-side程序和Android app构成。P1架构的最关键部分是一个在线利用商店。为了更新服务,P1只需往商店中添加新的利用即可。对于一个给定的设备,只尝试下载一个选择的子集。

保护方法.
STEP 1:提供设备信息。P1使用标准加密算法在发送到远程服务器前对收集的设备信息(Android设备model和内核版本)进行加密。类似的保护措施也被其他大的root提供者使用来保护他们的在线利用商店。

STEP 2:获取利用。接收到加密的设备信息后,P1服务器首先返回一个文件,其中包含了利用描述符的数组,每个描述符中包含了关于一个特定利用的复杂信息,包括一个内部利用的标识符,一个下载链接和评论,如受影响的设备。关联的利用就可以基于他的描述符来获取。同样,描述符文件也像STEP 1一样进行加密。除此之外,每个文件URL被编码成一个随机的字符串来防止彻底的爬取。P2中也发现使用类似的“描述符文件机制”,只是格式不同。

STEP 3:应用利用。P1把每一个利用封装到一个独立的Linux动态共享对象文件(.so)中。这些库文件导出来一个公共入口点接口,因此可以通过一个统一的方式一个接一个的被执行,每次当PC-side或Android app运行时,就会下载这些文件。很明显这些文件必须被保护以防被偷取滥用我们遇到了以下一些防御措施:1)通过冗余指令混淆代码[33],并且通过一个定制的过程重新布置ELF文件来破环文件头以防反汇编(加壳)。2)对实际的利用代码添加花指令。3)大多数常量字符串被加密。4)每个利用文件都有篡改检测机制以确保利用尽可以被真正的P1产品(自己的Android app)启动,防篡改机制是基于app的签名和包名。

安全性缺陷。不幸的是,存在很多的缺陷大幅削弱了P1采用的强保护措施。我们强调如下:

  • 通过不同渠道获取的相同Android app采用了不一致的保护措施。在研究P1一段时间后,我们意识到实际上有两种方法来获取他们的Android app:1)从官方网站上下载或直接从其他第三方应用市场(Google play禁止此类app)。2)从PC-side程序的下载缓存中获取副本。这可能是因为PC-side如果什么都没有检测到,就会自动下载和安装app到链接的设备。
    令人惊讶的是,两种驱动获取的app在移动设备上的行为相同,但他们的保护措施却有天壤之别。从官方网站下载的app对主要的“Classes.dex”进行了加密和加壳。这是一种有效的商业解决方案(如,梆梆)。通过电脑程序,相比之下不包含任何保护。考虑到Android倾向于只有小的变化也会进行程序更新,如果核心的加密逻辑在将来的版本中是相同的,攻击者可以在很长一段时间内滥用它,不断的提取提供者开发的新的利用。这个缺陷可以有效的暴露所有的在STEP 1和STEP 2中使用的加密算法。

  • Device-side和PC-side的保护强度差异。类似在章节4中所讨论的,P1的不受保护的Android app 免于处理PC-side程序的保护措施,如anti-debug。与之相反的,在P3中不受保护的PC-side程序时我们忽略了其严密保护的Android app。

  • 遗漏了关键功能的名字进行转换。提供商通常采用标准的加密和压缩算法(e.g., AES)来保护他们的代码和数据。然而如果这样的模糊逻辑遗漏了未转换的函数和变量名(e.g.,一个函数被命名为”md5”或者一个变量被命名为”AESKey”),这将被立即识别出算法和反向混淆。这种形式的泄漏即存在于P1的SMALI和AEM native代码中也存在于其他root提供者,这大大削弱了他们的保护措施。这个缺陷影响P1的所有三个步骤。

  • 基于签名和包名的篡改检测机制在许多提供者的利用文件都可以发现。但是,检测仅在开始时检测一次,这使得它很容易被绕过—修改条件跳转指令就可以让其工作在任何情况下。分散的重复的篡改检测可以提高STEP 3中的保护水平。

为了验证所有P1中的保护措施被成功的绕过,我们开发了一个概念验证的Android 恶意软件,它可以在一些测试机中获取和运行root利用以及成功的获取root权限,设备类型包括HTC One V和索尼爱立信ST18I。理论上,这个恶意软件可以利用P1的所有能力,因为它可以使用所有当前以及将来被P1维护的利用,只要过程一样。虽然我们不能涵盖通过PC-side程序启动的利用,但他们也可以使用同样的方式被下载和使用。

5.2 中型root提供商

在本节,我们选择研究P4,一个受欢迎的中型提供商。不同于P1, P4的所有利用存储在本地。虽然有一些本地存储保护措施,但整体上比P1的保护弱的多。我们只花了三天时间就获取了P4所有的利用,并且绕过了保护措施,这将在下面描述。

保护方法
STEP 1 : 提供的设备信息。因为所有的P4利用的都存储在本地,不需要发送设备信息到任何远程服务器。所有的设备信息在本地收集,然后被用于指导选择适当的利用。

STEP 2: 获取利用。当一个特定的利用被认定适合当前设备,P4将从本地存储中获取它。在这个过程中有两个层次的保护措施:首先,在Android app内部,app使用了基于MD5的名字转换过程把一个内部的利用名字映射到相应的本地存储中的模糊文件名。其次,实际的利用二进制文件使用了GZIP进行压缩,所以没有任何文件后缀。

STEP 3:应用利用。P4的利用都是ELF可执行文件。类似于P1,每个利用二进制文件也有基于包名的篡改检测机制,此外,尽管没有加壳和模糊技术,但所有的字串都进行了加密,并且没有有意义的函数名。

安全性缺陷

  • 对device-side app疏于保护。不像P1,甚至从P4官网上下载的原始APK也只有很少的保护措施—仅对一些基本的类和函数名进行混淆。SMAIL代码的主体仍具有高度可读性,并且给出了详细的功能和STEP1和STEP2中加密/解密逻辑。例如,引用字符串如“MD5”没有被加密,这将大大加快逆向进程。

  • ELF二进制文件打开了调试输出。二进制文件会把界面的字符串(e.g.,漏洞设备的驱动路径)直接打印到控制台。显然,开发者不小心忘记关闭调试选项,这个错误大幅简化了定位字符串解码任何和篡改检测程序。STEP3中的保护措施也大大的被削弱。不幸的是,除了P4,我们也在其他的提供商利用二进制程序中发现了敏感的调试输出。

5.3 小型root提供商

小型提供商通常仅有device-side Android app。此外,他们通常包含一些高度专业化的的利用。在我们的调查中,P6和P7被归为小型提供商,他们的Android app简单的执行native利用二进制文件,并且整个过程没有任何保护。对于二进制文件,虽然有些保护措施,如代码混淆和篡改检测,但他们都是原始的很容易被发现和绕过。有趣的是,缺乏有效的防御使得大的root提供商获取小提供商的利用并直接继承到自己的产品中,我们在两个大的提供商中观察到了这种情况。

6 利用的特征和案例研究

如表2所示,一些顶级的root提供商提供了更宽泛的root利用选择。在本节,我们会分析167个独一无二的root利用,这些利用程序是通过一些方法论,从最大的root提供商P1收集来的。

利用程序收集方法论 。从P1的在线数据库中下载利用程序,我们需要向P1的远程服务器提供足够的不同种类设备模型(参见图6)。因为没有大量的真实设备,我们借助于在线资源和公开可用的factory images[42] 。通过爬虫抓取了一些类似的网站后,我们收集了5742套设备信息和2458个独特的手机型号,这些手机的内核版本覆盖了2.6.32.9到3.10.30,Android版本覆盖了2.3.4到5.0.2 。收集到的列表涵盖了所有的主流手机厂商,如三星、HTC和索尼。收集到的这些信息可以帮助我们下载167个独特的利用二进制程序。注意到大的提供商声明支持超过10000或20000个Android设备模型,因此我们获得的利用程序可能远小于实际的数量。尽管如此,仅仅从2458个手机型号中就获取了167个独特的利用样本仍然让人印象深刻。

6.1 分析

利用程序家族。我们假设这些利用二进制程序对于攻击者来说有很高的价值,因为数量上远大于可以从公开渠道获取到的利用数量。然而,有一个重要的问题,很多二进制程序可能只是添加了简单的变化或者只是同一个核心利用程序的多个适配。为了进行公平的比较,我们需要一种方法将这些利用程序归类到不同家族。幸运的是从P1服务器返回的解密描述文件,正如5.1节提到的,有一个内部命名方案来识别每个利用程序。内部命名的一个例子是exploit98-3.2-v1,其中“98”用来对利用类型进行编号,“3.2”是一个特定的内核版本,“v1”表示该利用的第一次迭代变化。在命名方案的基础上,我们估计存在59个不同的家族,数量上仍超过37个公共可用的。从命名方案来看,我们可以估计当前P1的利用家族达到数百个。

基于我们从针对各个层次的公共利用获得的知识的基础上,我们分析了P1的利用二进制程序和它们的逻辑,eg,系统调用和它们的参数,我们把大部分利用家族分成了2大类:20个家族属于利用内核层漏洞,比较有代表性的就是类似futex(CVE-20147-3153)和perf_event_open(CVE-2013-2094),它们使用存在漏洞的系统调用,37个家族属于驱动层,特征是操作存在漏洞的设备文件,例如像/dev/exynos men等。其余的两个很难去分类。在内核层,我们已经确定了17个家族是可以映射到公开可用的利用,但无法完全分析其余3个。根据利用描述,我们无法从公共资源找到影响最严重的设备。对于驱动层的利用,我们确认其中的22个家族已经公开,但令人惊讶的是,经过我们的讨论,其余的15个是潜在的新的利用。有趣的是,我们没有遇到任何应用层的利用家族。

新的驱动层利用。我们确定了37个家族是驱动利用,所有的驱动层利用都有标准的行为,首先使用open()打开一个以/dec/file形式的漏洞设备文件,接下来在设备文件上调用ioctl()或其他系统调用。我们以内核内置的驱动或特定的提供商设备驱动对设备文件进行了区分,尽管其中许多利用可以匹配现存的利用,但我们发现15个利用家族,它们使用了10个存在漏洞的独特设备名。我们在P1的利用描述文件描述的受影响设备上,能够找到独特的设备文件名。受影响的设备包括流行的品牌如三星以及一些发售不到一年的新设备。出于安全因素我们不公布这些漏洞设备文件名。有趣的是,最近的一次研究[42],暗示了设备提供商定制的Android设备中引入了大量存在漏洞的驱动(至今还未发现root利用)。在我们的研究中,我们发现这样的漏洞是可以导致root提权的。回顾一下,因为最新的OS安全技术,现在内核利用程序越来越难以实现,自然把目标瞄准驱动层来开发利用程序。

适配。在P1的数据库中最显著的利用家族是一个包含89个变体的家族。通过逆向工程,我们已经去认定这个家族实现了对CVE-2014-3153的利用,正是著名的futex内核漏洞。这也证实了§3小节中所述的利用需要进行适配。为了理解为什么会有这么多变体,我们分析了这89个利用对应的内核版本,共发现了14个不同的内核版本。即使对于相同的内核版本,P1会根据内核的“构建信息”(e.g.[#1 SMP PREEMPT Wed May 15 23:25:44 KST 2013])来应用不同的变体。这个结果在表3中进行了总结,P1已经覆盖了绝大多数被Android使用的主要Linux内核版本。像“3.4.0”这样流行的内核版本存在更多的变体。除了对内核版本的适配,从利用的描述中,我们也可以看到一些变体是专门为特定的设备制造商设计例如三星和华为。其余的利用记载没有很多变体,e.g.,42的家族只有一个二进制文件。

这里写图片描述

总而言之,我们对P1的大规模利用工程印象深刻,这将是极其困难的工作并且个人是无法完成的这些资源和工程工作。我们相信类似CVE-2015-3636这样的高危内核级漏洞也具有相同价值,并且也需要大量的适配工作。据报道,root利用影响最多的Android设备例如三星Galaxy S6和HTC(M9),这个列表仍然在增长。

增加新利用程序的时间线。正像前面说明的,大型商业root提供商的利用程序大部分和对应的利用程序公开时间点重合。一个重要的指标显示供应商的竞争力是从原始利用被首次公布到利用被纳入到root工具的时间,尽管没有全面的数据,但我们确实有一个独特的关于PingPong root利用的数据,这个利用在2015年5月被首次公布。两到三个月后同样的利用被纳入到P1中。我们注意到PingPong在技术上是很复杂的。令人印象深刻的是供应商在短时间内就完成了利用程序的逆向工程、开发、测试和测试工作。事实上,该公司在全部相关的技术细节和任何可用的POC代码被公布之前就已经完成了上述工作。这证明商业提供商完全有能力并且非常迅速,这也是他们可能成为攻击者目标的另一个原因。

6.2 对抗先进的安全机制

从167个P1利用程序中的109个利用程序,我们观察了对SELinux安全机制的处理,SELinux是基于先进的Android安全机制例如SEAndorid[37]和Knox[17]。为了支持细粒度的访问控制,SELinux引进了“安全上下文”的概念,一个作为root用户运行的进程仍然会受到“上下文”的策略影响。这有效的消除了传统Linux上强大的root用户能力。但是在AOSP中,SELinux策略在Android4.4及以下版本默认采取permissive模式(在permissive模式下,SELinux只会将违反策略的行为记录下来,但不会阻止),除了一些定制的厂商如三星,这意味SELinux实际上是“禁用”状态。此外,即使SELinux策略被配置为enforcing模式,直到Andorid 5.0(AOSP)才完全实现,内核层利用通过覆盖相关的数据结构仍然可以很容易破环SELinux,SELinux有效运作是基于以下的假定:内核是完全无损的。具体的说,几乎在所有的109个利用攻击中,它们不仅会重写uid,还会重写sid和osid,这样安全上下文的效果被修改成初始状态(“init”),这种状态很特殊可以访问几乎所有的系统资源。接下来,它们修改/proc/self/attr/current,把安全上下文的字符串表述修改成“u:init:s0”。

同样,我们也观察了利用程序修改了Linux“进程的capability”相关的内核数据结构,比如,覆盖为0xffffffff .因为Linux中的进程capabilities和SELinux共享相同的威胁模型,不难想象,它们可以以同样的方式进行对抗。

对比公开的POC源代码,我们很少能够发现在这个级别上对抗额外的SELinux和进程capabilities安全设置。

6.3 反病毒测试

因为root利用非常敏感,可能会被Android恶意软件利用,我们的期望是Android平台的反病毒软件可以识别大多数利用程序,包括root提供商实现的。我们先择了4个反病毒产品作为代表来测试P1的167个利用程序。因为从P1在线数据库中下载的原始利用程序对实际的代码进行了加壳,并添加了防篡改机制,我们为每个利用精心制作了三个不同版本:1)从P1服务器上下载的原始利用程序带有壳和防篡改。2)脱壳后的利用,这将会把实际的利用代码暴露给反病毒产品。3)去掉防篡改机制重新对利用加壳。最后一个版本是非常危险的,因为恶意软件可以自由的利用,在运行时自己脱壳并执行。

为了测试杀毒软件,我们将一个版本的所有利用程序嵌入到自主开发的app中来触发病毒扫描。每次测试一个杀毒软件。如果扫描后提示app可以安全打开,证明这款杀毒软件没能检测到app中的利用程序,我们卸载这款杀毒软件,再安装下一款进行测试。如果扫描后得到警告该app是恶意的,我们会通过一次嵌入一个利用文件,来确定是哪一个利用的子集被检测出来。

这里写图片描述

最后的结果如表4所示,令人失望的是没有任何一款杀毒软件检测出加壳后的利用程序。这可能是由于root提供商对利用程序添加了自定义混淆实现,所以没有别识别出来。然而,即使是脱壳的利用,也只有趋势科技可以识别出167个利用中的13个。值得一提的是,高危漏洞futex和PingPong的利用程序都没有被杀毒软件检测到。这和§2.4小节中的结果不一致,在§2.4小节中提到公开的PingPong利用程序使劲上是可以被趋势科技探测到的。这表明:1)P1的PingPong root 利用完全不同于公开的。2)趋势科技使用了某种基于特征码检测方法,这种方法不能有效的检测出相同利用的变种。总的来说,结果表明,Android平台上的先进杀毒软件并不能有效的防护root利用。更糟糕的是,加壳和混淆更容易免杀。

7 相关工作

Android病毒分析。到目前为止,没有证据表明,哪个单一的恶意软件嵌入了大量的root利用,可能是因为实现工程上的挑战,e.g.,许多利用程序需要适配后才能在特定的设备模型上工作。在我们的研究中,提供了一个潜在的威胁警告,恶意软件可以利用root提供商的逻辑来实现这一目标。

Android root利用和防御。当缺少Android root利用的全面特征时,尖端研究表明,root利用的确会被恶意软件滥用[44 , 43]。正像Android 恶意软件基因组计划中描述的[43],1260个恶意样本中,有36.7%已经嵌入了至少一个root利用。

Root提供商在计算机历史上处于一个独特的位置,它们可以合法的收集和分发大量的root利用。在实践中,理论上,所有的商业root提供商应该为他们的root利用程序提供足够的保护,但在实践中,不幸的是,只要其中一个提供商没能做好防护,恶意攻击之就可以成功的“偷取”完全的工程,进行适配,测试不同的Android设备上进行测试。

随着Android的发展安全性方面已经改善了很多。SeAdnroid被证明可以有效的防范用户级应用的root利用[37]。研究建议使用类似系统调用等动态行为来检测root利用[44,29,35]。不幸的是,没有任何一种方法是可靠的。例如,想TowelRoot和PingPongRoot 都不会受到SeAndroid的影响,因为这些它们直接利用了内核层的漏洞。此外,更昂贵的动态分析技术需要root特权操作,这限制了他们的适用性,更不用说他们对电池寿命的影响。

8 讨论和结论

结论。本文,第一次,解开了神秘的root提供商面纱。我们发现他们不仅努力的引进和适配利用来覆盖更多的设备,而且挖掘新的利用来保持竞争力。然而,这些完善的利用程序没有被很好的保护,如果落入不怀好意的人手中,是极其危险的。这也可能引发公共政策/法律来讨论是否应该监管这些公司生产免费分发的最新利用。

鸣谢
……

引用

[1] Android Vulnerabilities – All vulnerabilities. http://androidvulnerabilities.org/all.html.
[2] Beating up on Android. http://titanium.immunityinc.com/infiltrate/ archives/Android_Attacks.pdf.
[3] Contagio minidump. http://contagiominidump.blogspot.com.
[4] CVE-2014-3153 aka towelroot. https://github.com/timwr/CVE-2014-3153.
[5] Don’t Root Robots: Breaks in Google’s Android Platform. https://jon.oberheide.org/files/bsides11- dontrootrobots.pdf. [6] Exploit DB database. https://exploit-db.com/.
[7] How To Root An AT&T HTC One X. http://rootzwiki.com/topic/26320-how-to-rootan-att-htc-one-x-this-exploit-supports-185/.
[8] iRoot, Retrieved on May 10, 2015. http://www.mgyun.com/m/en.
[9] It’s Bugs All the Way Down. http://vulnfactory.org/.
[10] One Click Root for Android, Retrieved on May 10, 2015. http://www.oneclickroot.com/.
[11] Rage Against the Cage. http://stealth.openwall. net/xSports/RageAgainstTheCage.tgz.
[12] Razr Blade Root. http://vulnfactory.org/public/razr_blade.zip.
[13] Root Genius, Retrieved on May 10, 2015. http://www.shuame.com/en/root/.
[14] Root the Droid 3. http://vulnfactory.org/blog/ 2011/08/25/rooting-the-droid-3/.
[15] [Root] ZTE z990g Merit (An avail variant). http://forum.xdadevelopers.com/showthread.php?t=1714299.
[16] [Root/Write Protection Bypass] MotoX (no unlock needed). http://forum.xda-developers.com/motox/orig-development/root-write-protectionbypass-motox-t2444957.
[17] Samsung Knox. https://www.samsungknox.com/.
[18] TacoRoot. https://github.com/CunningLogic/TacoRoot.
[19] Virus Profile: Exploit/MempoDroid.B. http://home.mcafee.com/virusinfo/virusprofile. aspx?key=1003986.
[20] VirusTotal. https://www.virustotal.com/.
[21] Xoom FE: Stupid Bugs, and More Plagiarism. http://vulnfactory.org/blog/2012/02/18/xoomfe-stupid-bugs-and-more-plagiarism/.
[22] D. Arp, M. Spreitzenbarth, M. Hubner, H. Gascon, and K. Rieck. DREBIN: Effective and Explainable Detection of Android Malware in Your Pocket. In NDSS, 2014.
[23] A. Averbuch, M. Kiperberg, and N. Zaidenberg. Truly-Protect: An Efficient VM-Based Software Protection. Systems Journal, IEEE, 2013.
[24] C. Collberg, C. Thomborson, and D. Low. A Taxonomy of Obfuscating Transformations. Technical report, The University of Auckland, 1997.
[25] C. S. Collberg and C. Thomborson. Watermarking, Tamper-proffing, and Obfuscation: Tools for Software Protection. IEEE Trans. Softw. Eng., 2002.
[26] J. J. Drake, Z. Lanier, C. Mulliner, P. O. Fora, S. A. Ridley, and G. Wicherski. Android Hacker’s Handbook. Wiley, 2014.
[27] N. Falliere, L. O. Murchu, and E. Chien. W32.Stuxnet Dossier. Technical report, Symanetic, 2011.
[28] D. Guido and M. Arpaia. The Mobile Exploit Intelligence Project. Blackhat EU, 2012.
[29] Y. J. Ham, W.-B. Choi, and H.-W. Lee. Mobile Root Exploit Detection based on System Events Extracted from Android Platform. In SAM, 2013.
[30] X. Hei, X. Du, and S. Lin. Two Vulnerabilities in Android OS Kernel. In ICC, 2013.
[31] C. Kruegel, W. Robertson, F. Valeur, and G. Vigna. Static Disassembly of Obfuscated Binaries. In Proc. of USENIX Security Symposium, 2004.
[32] M. Lindorfer, M. Neugschwandtner, L. Weichselbaum, Y. Fratantonio, V. van der Veen, and C. Platzer. Andrubis - 1,000,000 Apps Later: A View on Current Android Malware Behaviors. In BADGERS, 2014.
[33] C. Linn and S. Debray. Obfuscation of Executable Code to Improve Resistance to Static Disassembly. In CCS, 2003.
[34] OpenSignal. Android Fragmentation Visualized. http://opensignal.com/reports/2015/08/androidfragmentation/, 2015.
[35] Y. Park, C. Lee, C. Lee, J. Lim, S. Han, M. Park, and S.-J. Cho. RGBDroid: A Novel Response-Based Approach to Android Privilege Escalation Attacks. In LEET, 2012.
[36] R. Rolles. Unpacking Virtualization Obfuscators. In WOOT, 2009.
[37] S. Smalley and R. Craig. Security Enhanced (SE) Android: Bringing Flexible MAC to Android. In NDSS, 2013.
[38] J. I. Torrey. HARES: Hardened Anti-Reverse Engineering System. Technical report, Assured Information Security, Inc., 2015.
[39] T. Wang, Y. Jang, Y. Chen, S. Chung, B. Lau, and W. Lee. On the Feasibility of Large-Scale Infections of iOS Devices. In Proc. of USENIX Security Symposium, 2014.
[40] W. Xu. Ah! Universal Android Rooting is Back. Blackhat, 2015.
[41] J. Zeng, Y. Fu, K. A. Miller, Z. Lin, X. Zhang, and D. Xu. Obfuscation Resilient Binary Code Reuse Through Trace-oriented Programming. In CCS, 2013.
[42] X. Zhou, Y. Lee, N. Zhang, M. Naveed, and X. Wang. The Peril of Fragmentation: Security Hazards in Android Device Driver Customizations. In IEEE Security and Privacy, 2014.
[43] Y. Zhou and X. Jiang. Dissecting Android Malware: Characterization and Evolution. In IEEE Security and Privacy, 2012.
[44] Y. Zhou, Z. Wang, W. Zhou, and X. Jiang. Hey, You, Get Off of My Market: Detecting Malicious Apps in Official a

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/txx_683/article/details/54614590

智能推荐

hdoj Be the Winner 2509 (NIM博弈)_hduojbe the winner-程序员宅基地

文章浏览阅读326次。Be the WinnerTime Limit: 2000/1000 MS (Java/Others) Memory Limit: 32768/32768 K (Java/Others)Total Submission(s): 2713 Accepted Submission(s): 1484Problem DescriptionLet's consider m_hduojbe the winner

unity 手游虚拟摇杆代码参考-程序员宅基地

文章浏览阅读3.2k次。手游 摇杆_摇杆代码

memlock过低导致的数据库性能问题(r6笔记第10天)-程序员宅基地

文章浏览阅读824次。今天在一台备库机器上准备搭建active data guard ,在主库上做配置的时候,发现主库的反应有些慢,主要的感觉就是敲命令的时候似乎都有些停顿。带着疑问查看了下数..._memlock limit is less than 64mb

推荐几本shell学习的书 (r9笔记第98天)-程序员宅基地

文章浏览阅读180次。周末整理了一下书架,一来书架上实在是放不下东西了,四层书架,两层在闺女的触及范围之内,所以直接拿胶带封住,留下两层勉强可用。二来书架已经不是放书的地儿,生活用品已..._shell 书籍 推荐 杨建荣

PE文件格式_pe工具的文件扩展名-程序员宅基地

文章浏览阅读1.2k次。PE文件格式分析及修改(图)12009-01-09 14:08PE 的意思是 Portable Executable(可移植的执行体)。它是 Win32环境自身所带的执行文件格式。它的一些特性继承自Unix的Coff(common object file format)文件格式。“Portable Executable”(可移植的执行体)意味着此文件格式是跨Win32平台的_pe工具的文件扩展名

Bluetooth MESH探究 --- (7) BLE core spec之为什么BLE能有更低功耗_ble 为什么功耗低-程序员宅基地

文章浏览阅读3.6k次。BLE与其它蓝牙协议最典型的区别就是BLE是专门为低功耗、低复杂度以及低成本设备设计。那么,BLE是通过什么方法做到更多功耗的呢? 对于蓝牙设备甚至可以说对于所有无线通信设备来说,最大的功耗就来自于射频电路部分。比如,对于TI CC2540芯片来说,RF处于接收状态的电流为19.6mA,RF处于发射状态的电流为24mA,而RF处于sleep状态的电流仅为0.9uA。所以,如果能够最大限度地_ble 为什么功耗低

随便推点

纳什博弈论-程序员宅基地

文章浏览阅读1.5k次。纳什博弈论的原理与应用   1950年和1951年纳什的两篇关于非合作博弈论的重要论文,彻底改变了人们对竞争和市场的看法。他证明了非合作博弈及其均衡解,并证明了均衡解的存在性,即著名的纳什均衡。从而揭示了博弈均衡与经济均衡的内在联系。纳什的研究奠定了现代非合作博弈论的基石,后来的博弈论研究基本上都沿着这条主线展开的。然而,纳什天才的发现却遭到冯·诺依曼的断然否定,在此之前他还受到爱因斯坦的冷遇。但是骨子里挑战权威、藐视权威的本性,使纳什坚持了自己的观点,终成一代大师。要不是30多年的严重精神病折_纳什博弈论

ios注意事项-程序员宅基地

文章浏览阅读177次。1.tableview顶部留白问题当cell的类型是plaint类型时,直接设置self.automaticallyAdjustsScrollViewInsets=NO;应该就可以的当cell的类型是group类型时,此时要去掉tableView顶部的空白需要两步:1.设置tableView的tableHeaderView高度为0.5;self.MenuTable.tableHea

数据结构——不带头节点的单链表_不带图节点的单链表类的成员函数-程序员宅基地

文章浏览阅读403次。作者:小琛欢迎转载,请标明出处单链表的概念概念:**链表是一种物理存储结构上非连续、非顺序,逻辑上连续的结构。**是通过链表中的指针链 接次序实现的。如下图:单链表的实现鉴于后续的面试和oj题目类型,这里实现不带头节点的单链表Plist.h#ifndef _LIST_H__#define _LIST_H__#include <stdio.h>#include &l..._不带图节点的单链表类的成员函数

Cento7配置网络及代理_centos7网卡不支持代理-程序员宅基地

文章浏览阅读528次。1、配置网络编辑网卡配置文件[root@localhost yum.repos.d]# vim /etc/sysconfig/network-scripts/ifcfg-eno16777736TYPE=EthernetBOOTPROTO=noneDEFROUTE=yesIPV4_FAILURE_FATAL=noIPV6INIT=yesIPV6_AUTOCONF=yesIPV6_..._centos7网卡不支持代理

input输入框赋值、取值_input框赋值取值-程序员宅基地

文章浏览阅读3.9k次。目录htmleasyuilayui自己做个记录,在对页面进行修改,开发的时候,总是去查资料html<input id="cpno" name="cpno" value="" />js: 赋值: $('#cpno').val( "CSDN有限公司"); -------方式1 $('#cpno').val("setValue", "CSDN有限公司"); -------方式..._input框赋值取值

如何有效预防CC攻击?_怎么防止被c&c攻击-程序员宅基地

文章浏览阅读348次。CC攻击也是属于流量型攻击中的一种,大部分的高防机房,是可以承受住大量的DDOS攻击的,这些防护主要来源于硬防。CC攻击可以算的上是DDOS攻击的一个升级版,如果想要抵御CC攻击可没有抵御DDOS攻击那么简单,单靠硬防还是不够的,必须要配合人工进行策略调控才可以防御住。CC攻击基本上都是针对端口的攻击,所以网站遇到CC攻击的几率会更大一些。在攻击模式上与一般的流量型攻击是差不多的,主要是通过伪装成正常的用户不停的对网站进行访问,从而导致服务器资源耗尽,无法正常的被访问。那么我们应该怎么去预防CC攻击呢?_怎么防止被c&c攻击

推荐文章

热门文章

相关标签