CN105683988A

CN105683988A - 管理软件补救

Info

Publication number: CN105683988A
Application number: CN201380079177.9A
Authority: CN
Inventors: D·库尔卡尼; S·纳鲁利; R·辛哈; V·克里希纳普尔
Original assignee: McAfee LLC
Current assignee: McAfee LLC
Priority date: 2013-09-27
Filing date: 2013-12-21
Publication date: 2016-06-15
Also published as: US10305929B2; US20160205115A1; US20190238563A1; WO2015047443A1

Abstract

根据一个示例，公开了用于恶意软件和灰色软件补救的系统和方法。例如，该系统可操作以识别具有一些合法行为但也呈现出一些不期望行为的应用。补救引擎被提供以检测在其他方面有用的应用中的恶意软件行为，并且允许运行应用的有用部分同时阻止恶意软件行为。在“治愈”的示例方法中，这可以涉及到修正应用二进制来移除不期望的行为。在“个性化”示例方法中，这可以涉及到通过操作系统插入控制钩来防止某些子例程起作用。

Description

管理软件补救

相关申请的交叉引用

本申请要求2013年9月27日递交于印度专利局的印度临时专利申请No.4389/CHE/2013以及2013年9月27日递交于印度专利局的印度临时专利申请No.4383/CHE/2013的优先权，这两个申请以其全文通过引用方式并入本文。

技术领域

本申请涉及软件安全领域，并且更特别地涉及用于管理软件补救的系统。

背景技术

软件、二进制文件、可执行文件、广告文件、网页、文档、宏、可执行对象以及其它提供给用户的数据(统称为“应用”)可能包括遭遇恶意软件利用的安全性缺陷以及隐私泄漏。如本说明书中通篇使用的，恶意性软件(“恶意软件”)明确地定义为病毒、木马(Trojan)、僵尸、隐匿程式(rootkit)、后门、蠕虫、间谍软件、广告软件、勒索软体、拨号器、有效载荷、恶意性浏览器帮助对象、cookie、记录器、或设计成采取潜在不期望的动作的类似应用或应用的部分，通过非限制性示例的方式潜在不期望的动作包括数据破坏、隐藏数据收集、隐藏通信、浏览器绑架、网络代理绑架或重定向、隐藏跟踪、数据记录、键盘记录、过度或故意障碍移除、通讯录收藏、高级服务的非期望使用以及未经授权的自传播。在一些情况下，恶意软件还可以包括包含导致或使能恶意软件行为的疏忽的安全性缺陷的合法软件。在安全性或隐私威胁类别中还包括“灰色软件”，其是恶意软件的较不严重的形式，诸如半合法应用，包括合法功能，但也包括令人烦恼的、略微有害的或者不期望的行为(包括例如收集隐私数据或高级服务的隐藏使用)，但是尽管如此其不像纯粹的恶意软件那样严重。通常，灰色软件不能向用户公开其收集活动的整个范围或者暗中超越其所述功能。在本说明书中，术语“恶意软件”意图涵盖纯粹的恶意软件和灰色软件二者。“恶意软件行为”被定义为任何将应用定性为恶意软件或灰色软件的行为。一些现有技术的系统被配置成识别和阻止恶意软件，例如通过保存已知恶意软件的数据库。

附图说明

当结合附图来阅读时，根据下面的具体实施方式能够最佳地理解本公开。强调的是，根据行业标准惯例，各特征不是按比例绘制的且仅用于示例说明的目的。事实上，为清晰论述的目的，各特征的尺寸可以任意增加或减少。

图1是根据本说明书的一个或多个示例的分布式补救环境的网络层的图。

图2是根据本说明书的一个或多个示例的补救引擎的功能框图。

图3是根据本说明书的一个或多个示例的客户端设备的框图。

图4是根据本说明书的一个或多个示例的补救客户端软件的流程图。

图5是根据本说明书的一个或多个示例的补救服务器的框图。

图6是根据本说明书的一个或多个示例的提供补救服务器软件的方法的流程图。

图7是根据本说明书的一个或多个示例的更具体地公开了由补救引擎实施的方法的流程图。

图8是根据本说明书的一个或多个示例的与客户端设备处于原位的补救客户端软件的框图。

图9是根据本说明书的一个或多个示例的在应用的示例性生命周期内的补救过程的框图。

具体实施方式

概述

根据一个示例，公开了用于恶意软件和灰色软件补救的系统和方法。例如，该系统可运行以识别具有某些合法行为但是也呈现出某些不期望行为的应用。提供了补救引擎来检测其他有用应用中的恶意软件行为，并且允许应用的有用部分运行，同时阻挡恶意软件行为。在“治愈”的示例方法中，这可以涉及到修改应用二进制来移除不期望的行为。在“个性化”的示例方法中，这可以涉及到通过操作系统插入控制钩(controlhook)以防止特定子例程起作用。

本公开的实施例

下面的公开内容提供了许多不同的实施例或示例，用于实现本公开的不同特征。下面描述组件和布置的具体示例以简化本公开。当然，这些仅为示例，不意在限制。此外，本公开可以在各个示例中重复附图标记和/或字母。该重复仅为简化和清晰的目的，本身不规定所论述的各实施例和/或配置之间的关系。

不同的实施例可以具有不同的优点，且任何特定优点都不是任何实施例所必然要求的。

许多软件生态系统正在从用户自由定位、选择、下载和安装软件的模型转移到严格管理的应用仓库。这种分布模型已经在类Unix操作环境下使用了多年，每个仓库都收容了数千应用。移动设备以及甚至一些桌面式系统现在已经开始采用该模型，并且一些使用“应用商店”作为用于提供不存在“越狱”或类似的非平凡用户干预的应用的独有通道。当前两个最主流的安卓(Android)和iOS应用商店中的应用数量每个都接近一百万。

应用商店模型对于反恶意软件销售商而言呈现了新的挑战。使用严格受控的应用商店，在一些情况下相比于灰色软件可以较少关注仅具有恶意意图的纯粹的恶意软件，灰色软件在用户的设备上请求过多的特权并且可以经由收集隐私的用户数据、滥发通讯录、发送不期望的短消息服务(SMS)消息、访问互联网、访问网络、呼叫、以及SMS日志、对准广告、或对于对准的广告上传数据来盈利。有益地，本说明书的系统和方法提供了辅助用户最少化灰色软件应用中的这种恶意软件行为的工具。

移动应用环境可以为用户提供关于应用请求哪些许可或特权的基本信息，包括对隐私数据的访问权。在许多情况下，用户的唯一的可见选项是或者为应用授权所有请求的特权或者不安装该应用。然而，在一些情况下，该信息可能不足以保护用户免于不期望的或半期望的行为。例如，用户在安装时被告知该应用需要访问互联网，这看起来是该应用的一个合法功能，但是用户不知道的是，除了该合法功能之外，该应用“回拨(phonehome)”并且将隐私数据上载以实现市场营销目的。另一方面，用户可能被告知，该应用请求许可以发送和接收短消息服务(SMS)消息，且甚至虽然用户不明白例如游戏为什么需要访问SMS，用户可能没有技术背景来获知哪些应用合法地要求哪些许可，或者该应用是否超越了对必要许可的合法使用。例如，如果应用对用户的通讯录有访问权，它可以使用该访问权来做有用的以及所期望的事情而使用户受益，或者它可以收集用户的全部联系人并且将它们转送给应用作者的服务器，以实现作者个人的金钱方面的目的，或者通过直接对准广告或者通过将那些通讯录出售给对准的广告商。而且，如果用户确实决定该游戏对于SMS特权没有合法需要，则用户可能没有选择性地仅阻止SMS的选项，因为一些操作环境仅提供了“取得或离开”的方式：或者授权应用正请求的所有许可，或者不安装它。

因此，用户可能直到使用了应用之后才知道其功能是否真正有益。到那时，损害可能已经完成。因此，有益的是提前提供一个关于应用做什么的可理解且可控告的模型，并且提供用于辅助用户消除不期望的恶意软件行为同时保留应用的期望功能的工具。

根据一个示例，本说明书的系统提供了一种方法和架构以用于：a)检测可能潜在地伤害用户的应用的实际行为，诸如隐私泄漏或其他恶意软件行为，以及b)在运行期间补救不期望的行为，而不修改应用二进制(applicationbinary)。用户能够修改应用的行为以向着用户的偏好将其个性化。行为控制可以是应用特定的，在安装时配置或者在应用运行的同时基于用户输入来动态地控制。在另一示例中，通过修改应用二进制消除恶意软件行为，来“治愈”不期望的行为。

该实施例背后的一个原理是对可执行指令的深入的静态分析，从而为用户提供对应用行为的人类可读且可控告的报告。分析器可以关于应用使用特权访问隐私数据的方式来执行深入的程序间分析。

然后，行为报告可以用于配置对应用的动态个性化。最后，系统可以在运行时拦截应用的恶意软件行为并且允许用户通过或者阻止不期望的行为或接受该行为来控制和个性化该行为。

根据一个示例，本说明书还提供了补救引擎，该补救引擎拦截应用安装并分析二进制或字节代码数据来检测潜在的恶意软件行为。

根据另一示例，本说明书的系统可以基于例如名称和特征描述来识别应用的公开的意图。该系统可以将应用的公开的意图与补救引擎所确定的真实行为相互关联以识别声称的行为与真实行为之间的任何差异。该系统随后可以基于该差异分配一个评分并且将该应用分类为灰色软件或恶意软件。

图1是根据本说明书的一个或多个示例的分布式补救环境的网络层的图。在该示例中，多个用户132操作多个客户端设备130。每个客户端设备可以连接到IP网络120，诸如互联网、内联网、WAN、LAN、公司网络、安全网络或类似网络。

恶意软件作者170也经由客户端设备130连接到IP网络120。在该说明书通篇中，恶意软件作者170显示为已经生成了基于安卓的应用，名叫“racinggame.apk”。在该示例中，racinggame.apk提供了用于安卓智能手机和平板设备的流行且有娱乐性的赛车游戏。racinggame.apk还可以参与一些恶意软件行为，诸如收集用户132的个人数据、位置数据或通讯录数据，滥发用户132的通讯录，或者以其他方式企图从用户132盈利。

应用商店180被提供且与IP网络120通信耦合。在示例中，恶意软件作者170经由IP网络120将racinggame.apk上载到应用仓库180中。补救服务器110连接到IP网络120并且与补救数据库140通信耦合。补救数据库140可被配置为包括关于补救服务器110先前已经分析的应用的存储数据和程序，包括对应用行为的可控告描述和推荐的补救动作(如果有)。补救数据库110可以包括或者可以连接到声誉数据库，该声誉数据库被配置为提供应用的声誉得分作为补救数据库14所需的数据的部分。在该实施例中，补救数据库140被公开为直接连接到补救服务器110，但是将意识到，其他的配置是可能的，包括补救数据库140可以由第三方来提供，并且可以经由例如应用编程接口(API)来访问。起初，补救数据库140不具有针对racinggame.apk定义的声誉数据或补救程序。

在示例中，用户132操作客户端设备130。“客户端设备”明确地被定义为任何类型的节点或用户设备，通过非限制示例的方式包括计算机、个人数字助理(PDA)、膝上型计算机或电子笔记本、蜂窝电话、IP电话、iPhone^TM、iPad^TM、MicrosoftSurface^TM、Android^TM电话、GoogleNexus^TM、或任何其他设备、组件、元件或能够执行指令且与用户交互的对象。“用户”明确地被定义为个人、实体或能够操作、使用或以其他方式与客户端设备交互的设备。在一些情况下，有益的是具有多个补救服务器110，或者配置补救服务器110来单独地处置多个品类的客户端设备130。例如，在MicrosoftWindows7上可执行的恶意软件有效载荷可能不能在上文列出的其他设备中的任意设备上执行。相反，需要精心制作恶意软件有效载荷以具体地针对特定体系结构。然而，本说明书明确地预期如下情形：单个恶意软件有效载荷可以针对多个客户端设备130平台。例如，恶意软件有效载荷能够以诸如Java的交叉平台语言来实现，并且能够利用多个平台共有的安全脆弱性。

在示例中，用户132-1操作客户端设备130-1，该客户端设备可以是安卓手机。在该示例中，很多个其他用户也可以操作类似配置的安卓手机，并且对应用商店180具有访问权，他们从应用商店180接收可执行对象。恶意软件作者170希望创建针对安卓手机的恶意软件，包括半合法应用，并且可以通过上述示例方法中的一种或者通过任何其它适合的方法来完成。

补救服务器110可以由例如应用商店180的操作员来操作，或者由第三方安全提供商来操作。此外，补救数据库140可以由补救服务器110的操作员来操作，或者可以由第三方来提供。在一般情况下，在本说明书中公开的实体可以是单独的实体或者可以不是单独的实体，这取决于具体的配置。

补救服务器110可以被配置为针对经由应用商店180分布的应用或者针对其它应用提供补救数据或方法。在本说明书中“补救(remediation)”明确地被定义为动作、数据、修正、程序或者被采取以用于有效地防止、阻止、减少、改良或修正应用中的恶意软件行为的其他类似步骤。该术语还可以在该说明书通篇使用作为动词形式“补救(remedy)”或者作为形容词形式“补救的(remedial)”。

图2是根据本说明书的一个或多个示例的补救引擎200的功能框图。在示例中，补救引擎200可以是包含在补救服务器110中或客户端设备130中的软件。在一个示例中，补救服务器110和客户端设备130两者均包括各种补救引擎。例如，客户端设备130可以执行“快速”扫描，其经优化以节约移动设备上的电池电力和稀疏的处理资源，同时仍提供置信度。应用二进制然后可以被传送到补救服务器110以便进行更详细的分析。在一个示例中，补救引擎200防止应用二进制在客户端设备上运行，直到“快速”扫描完成。在另一示例中，补救引擎200防止应用二进制在客户端设备上运行，直到在补救服务器110上完成了全扫描。

反汇编器220接收应用二进制210，诸如racinggame.apk，并且例如根据字节代码来构建程序逻辑的模型。应用二进制还可以包括汇编指令、脚本、宏、以及其他可执行对象，通过非限制示例的方式。反汇编器220还分析环境应用知识230，包括例如，可用的描述、评论、串或其他可用于引导或补充反汇编进程的描述性材料。这得到了应用逻辑模型(ALM)250，该ALM被提供给行为启发与规则引擎(BHRE)280。在示例中，构建程序逻辑的输入是对主操作系统中的应用编程接口调用的语义进行编码的数据库。编码可以捕获例如输入、输出、对API功能的描述、以及API处置的数据的信息敏感度。

ALM250可以对存储器中的应用逻辑进行建模以识别恶意行为，例如，通过逐句通过该模型。ALM250可以包括数据流结构以及控制流结构。

数据流结构可以将数据对象的生命周期表示为它们经过程序逻辑从它们被定义的点到它们被使用的所有地点，经过同一程序单元的不同模块以及外部程序单元。数据流结构可以在数据流移动和变换时从程序的不同部分识别出数据流，以识别出数据正去向何方。例如，“日历”或“通讯录”数据流可以被配置为推导数据是否正被泄漏到互联网地址。敏感调用也可以被追溯回到用户接口元件、交互或启动这些调用的后台进程。

ALM250可以包括用于执行数据流分析的规则。规则引擎260将规则应用于ALM250并且识别潜在的恶意行为。示例的规则可以表示如下。

<Rule>

在一个示例中，关于被补救引擎230视为可疑的行为，规则将陈述性说明提供给BHRE280。BHRE280可以试图验证应用二进制210中的这些行为的存在。当在数据库260中没有指定规则时，BHRE280可以假设一组缺省规则，这些缺省规则可以在BHRE280内部，目标是对恶意软件的典型的不良行为进行编码。这样还可以允许补救引擎200适应演进的恶意软件，因为BHRE280能够随着恶意软件行为变化和演进而对新规则编码。

在一些实施例中，期望补救引擎200随恶意软件演进而随时间演进。规则数据库260提供了实现这种演进的手段。在一些情况下，规则可以不限于指定所谓的“灰色软件”或“黑色软件”模式。相反，规则可以指定从企业视角而言不期望的应用行为。例如，企业可以出于安全性担忧而选择限制应用访问摄像机。

在该情况下，规则指定来自具有“红色”安全性敏感度的子系统的读操作到任何子系统的写操作的任意数据流匹配该规则。规则可以是类属的，类似于上述规则，或者可以是专门针对子系统的，例如特殊规则可以明确地被配置为用于检测通讯录的数据泄漏。可以通过运行单个规则或多个规则以及然后处理结果来导出特定行为。

在另一示例中，规则引擎260可以将一起工作的两个不同应用的数据流表示链接以实现任务。规则引擎260可以将由其他应用使用来实现有用功能的共同的应用列入白名单。例如，可以将由其他应用使用来合法地获得对通讯录的访问权的通讯录应用列入白名单。

启发式行为可以既通知个性化规则240又被个性化规则240通知，该个性化规则240可以是用于个性化应用的一组结构化规则或命令，包括阻止或限制恶意软件行为。类似地，规则数据库260可以将规则提供给BHRE280并且从BHRE280接收更新。规则数据库260可以包括例如，先前定义规则的数据库，并且可用于为已知的子例程或行为定义规则。个性化规则240还可以接收个性化规则数据242。

一般地，个性化规则240可以从两个源导出规则。首先，规则可以从个性化规则数据242导出，该个性化规则数据242可以通过输入用户偏好来提供。个性化规则240还可以从分析所发现的行为来导出规则。

BHRE280可以包括使能将明确的代码序列识别为执行给定功能的规则或者使其能识别出某些规则序列通常与既定动作相关联的规则。通过非限制示例的方式，BHRE280执行的示例方法的伪代码可以包括以下：

通过另一示例，[定义-使用？]([definition-use？])创建的伪代码包括以下：

在该实施例中还示出了平台API智能270和全球威胁智能(GTI)290。

如本文所描述的，通过非限制示例的方式，GTI可以是提供基于社区输入、手动检查、历史数据和声誉的白名单、黑名单智能的外部智能数据库。在一些情况下，GTI290可以在应用二进制层级提供恶意软件指定，或者可以提供更细分的指定，诸如将某些子例程指定为已知的恶意软件。在子例程层级的恶意软件的指定可以特别地用于识别灰色软件，因为灰色软件可以贮存在以其他方式合法的应用中。GTI290还可以从BHRE280接收更新或贡献，或者更广泛地从补救引擎200接收更新或贡献。

BHRE280、个性化规则240和个性化引擎780(图7)代表应用提供了有价值的信息。该信息可以通过非限制示例的方式包括：

a.分析器基于程序分析发现应用很可能呈现的行为；

b.针对命名应用的众包个性化；

c.应用在运行时呈现的以及当个性化被激活时的行为。

可以将该信息提供给GTI290，以使得补救服务器110根据社区输入以及针对特定应用所呈现的行为的用户社区的占优偏好来获知特定应用的静态行为和动态行为二者。该知识可以由“众包”连续地产生并且用于提供改进的用户体验。

平台API智能270可以是具有关于针对平台的应用编程接口(API)的智能的数据库，在该示例中平台是安卓，但是还可以是任何其它适合的平台。在示例中，平台API智能270包括扩展标记语言(XML)或其他适当的建模语言的平台API语义的表示。这可以使BHRE280能够确定特定API的重要性或敏感度，以及关于某些API元件的输入和输出的详细信息，包括子例程。那些行为可选地与用户输入组合且变换成控制配置。BHRE280然后可以修正二进制，或者将控制钩插入以拦截某些API调用从而控制应用二进制210的行为。

关于平台API智能270，本文还公开了一种代表平台API的关键语义的方法以使得补救引擎200可以更有效地确定应用正在做什么。

在示例中，可用的API可以以XML格式表征如下。

对象“API名称”(APIName)提供了API被引用的名称。对象“类别”(Category)指示API的类型，诸如其是从系统读取信息，已经读取或者写磁盘访问，或者提供例如消息框。

对象“敏感度”(Sensitivity)代表了在可能有恶意软件行为的上下文中API的敏感度。例如，其是否读取包含可能隐私信息的位置，或者其是否访问诸如通讯录、位置、SMS、电话、电子邮件或互联网的资源。在示例中，敏感度可以被分配数值，诸如1至5，或者颜色值，诸如对于最敏感对象为红色，对于不太敏感对象为橙色，对于略微敏感对象为黄色，对于具有极少敏感度或无敏感度的问题为绿色。贡献于加权敏感度的因素可以通过非限制示例的方式包括隐私、数据泄漏可能性、以及金融敏感性。

在示例中，还可以列出并描述API调用的参数。还可以提供返回值以及描述性关键词，关键词可划分成名词和动词。

在该示例中，补救引擎200被公开为整体式的以及高度集成的引擎，但是应当意识到其它配置是可能的，而且在更广义的意义上，本文公开的任何逻辑块可以由第三方提供，例如经由API，或者通过其它手段。此外，甚至在集成企业内，本文公开的不同的逻辑块可以由运行单独的服务的单独的机器来执行。因此，应当意识到，图2的逻辑框图主要被提供作为示例的补救引擎200中所见的逻辑元件的示例，并不意在暗示或要求特定的物理布置。

根据一个非限制的示例，个性化规则240可以包括用于个性化一个或多个应用的规则。个性化规则可以被提供为结构化XML或者以任何其它适合的格式，如下：

在前述的应用中，XML对象“(多个)策略”(Policies)指示对象包括针对诸如racinggame.apk的一个或多个应用的策略，每个由“PackageName”对象来标识，诸如在该示例中的“com.software.racinggame”和“walkingtexter”。每个包(package)都包括一个或多个策略，由“策略”(Policy)对象标识出，其可以标识“行为”(诸如SMS泄漏、国际移动设备标识(IMEI)泄漏、通讯录泄漏、位置泄漏或类似物)。策略还可以包括“目的地”(Destination)对象，指示例如泄漏的信息被传送到哪里，以及“DestinationStatus”，其可以包含该目的地的声誉。例如，如果目的地是已知的恶意软件作者，则目的地状态可以被指定为“有害(Harmful)”，而如果目的地是合法的，则状态可以为“无害(Harmless)”。对于未知的目的地，状态可以是“未知(Unknow)”。若干其它目的地的级别以及变体也是可能的，包括例如“灰色软件”、“可疑”、“广告软件”或其它类似的指定。

最后，提供“动作”字段以指示设备(诸如运行补救客户端软件322(图3)的客户端设备130)作为对应用的具体行为的响应而采取何种动作。例如，“StopAndNotify”指示补救客户端软件322阻止行为且将企图的恶意软件行为通知用户。“ProceedAndNotify”相反可以指示补救客户端软件322允许继续进行该行为但也通知用户，在一些实施例中包括给予用户交互式选项来阻止来自该包的同一类型的未来行为。许多其它类型的动作可供该对象使用，包括简单的“Stop”和“Proceed”命令，以及采取其它补救动作诸如模拟输入(包括提供模拟的GPS坐标、模拟通讯录、或模拟网络通信量)的命令，或者修正子例程以改变非期望行为的命令。

在示例中，补救引擎200根据补救引擎200向GTI290提供更新的设备上分析来提供闭环分析，这反过来将数据提供给补救引擎200。

图3是根据本说明书的一个或多个示例的客户端设备130的框图。客户端设备130由处理器310控制，处理器310与存储器元件320通信耦合。在示例中，处理器310经由总线370与其它系统元件通信耦合。通过非限制示例的方式，那些元件可以包括网络接口340以及存储设备350以及用户接口360，在一些情况下存储设备350可以是一系列的存储器元件320。明确意图是，上述任意元件能够以硬件、软件、固件或它们的任意组合来实现。

处理器310被配置为例如经由可执行软件或固件指令来控制客户端设备130。“处理器”在本文明确地定义为提供可编程逻辑的硬件、软件或固件的任意组合，通过非限制示例的方式包括微处理器、数字信号处理器、现场可编程门阵列、可编程逻辑阵列、专用集成电路或虚拟机处理器。

在一些实施例中，存储器320可以是相对低延迟的易失性存储器，并且可以包括主存储器、高速缓存、片上存储器、L1存储器、L2存储器或类似存储器。注意的是，在该实施例中，处理器310被描绘成与存储器320为直接存储器访问布置，但是在其它实施例中，存储器320可以经由系统总线370、经由某些其它总线或者经由某些其它手段来与处理器310通信。此外，虽然存储器320和存储设备350在该示例中被描绘为物理上的或概念上的单独的设备，应当意识到，在一些实施例中，存储器320和存储设备350可以共享物理设备，该物理设备可以或者可以不划分成分离的存储器区域。因此，应当意识到，此处所公开的布置仅为示例，不是限制。相反，明确意图是，即使存储器和存储设备分开来讲，除非明确指出否则它们也可以实施在单一物理设备或逻辑设备中。

在该示例中，网络接口340包括任意通信介质，无论是模拟的、数字的，还是混合信号的，其被配置成将客户端设备130与其它计算设备通信耦合。通过非限制示例的方式，网络接口130可以包括WiFi、以太网、火线、光纤、USB、串行接口、蜂窝网络、数字PCS网络、2G数据网络、3G数据网络、4GWiMAX、或4GLTE数据网络。相比而言，WiFi驱动器980被公开为一系列高带宽数据网络。

用户接口360被明确地定义为被配置成使用户能够与客户端设备130交互(无论是否是实时)的硬件、软件或固件的任意组合。在示例中，通过非限制示例的方式，用户接口360可以包括键盘、鼠标、显示监控器、扬声器、麦克风、触摸敏感显示器，这些可以充当组合输入/输出设备，以及摄像机。用户接口360可以包括软件服务，诸如图形用户接口，包括征求来自用户的输入或确认的实时对话框。

存储设备350被公开为非易失性存储器介质的示例，其可以是一系列存储器320。在一些实施例中，存储器320和存储设备350可以是单独的设备，存储器320是相对低延迟的易失性存储器设备，而存储器350是相对高延迟的非易失性存储器设备。存储设备350还可以是另一种设备，诸如硬盘驱动器、固态驱动器、外部存储设备、独立磁盘冗余阵列(RAID)、网络附接存储设备、光学存储设备、磁带驱动器、备用系统或上述的任意组合。许多其它配置也是可能的，并且意在被涵盖在本说明书的宽泛范围之内。

在一些示例中，存储设备350可以是有形的、非易失性存储介质，其中存储有可执行指令，这些可执行指令可操作以提供补救引擎200或其适当的部分，以及补救客户端的其它方面。在操作中，那些指令可以从存储器320运行。存储器320还可以具有处于执行状态的其它应用或可执行对象，诸如运行应用324。存储设备350还可以包括可执行对象，其可以处于休眠状态或静态。补救客户端322可以被配置为在运行应用324和存储的应用352上根据本文所公开的方法来操作。在一些实施例中，补救引擎200是补救客户端322的子例程。

图4是根据本说明书的一个或多个示例的补救客户端软件的流程图。在框410中，补救客户端322提取应用，诸如例如识别“racinggame.apk”作为需要补救分析的应用。提取可以包括简单地识别应用，或者可以包括提取感兴趣的部分来分析。在框420中，补救客户端322将提取的对象发送到补救服务器110。

在框430中，补救客户端322从补救服务器110接收补救数据。这可以包括例如内置补救行为的修正后的二进制，或者可以包括用于补救应用行为的命令。例如，补救服务器110可以发送包括补救命令的XML文件，如结合图2所公开的。

在框440中，客户端设备130按照从补救服务器110接收到的补救数据行动。在一些情况下，该动作可以简单地将原始应用二进制替换成由补救服务器110提供的修正后的应用二进制。在另一示例中，按照补救数据行动包括将补救客户端322配置成与应用二进制的操作相结合地采取规定的动作，诸如提供模拟数据或者选择性地否决某些特权。例如，如果发现racinggame.apk滥发SMS通讯录，则补救客户端软件322可以选择性地撤回其SMS许可，但是允许其它全部许可。另一方面，如果racinggame.apk因一些合法功能而要求访问SMS，但是通过发送垃圾SMS消息而滥用其SMS特权，则可以插入操作系统钩以选择性地仅阻止来自SMS的某些子例程，或者可以提供防火墙规则或类似规则以便或者阻止racinggame.apk发送SMS至指定地址(列入黑名单)，或者允许racinggame.apk仅发送SMS至规定的地址(列入白名单)。这些仅通过示例的方式提供，且应当注意，响应于从补救服务器110接收到补救数据，可以采取许多其它的动作。

在框450中，应用利用补救选项来运行。在一个示例中，这可以包括简单地运行修正后的二进制。在另一示例中，这可以包括利用修正后的许可来运行应用二进制。在又一示例中，这可以包括运行补救客户端软件322作为后台进程以选择性地实时修正应用二进制的行为。

图5是根据本说明书的一个或多个示例的补救服务器110的框图。在该示例中，补救服务器110由处理器510控制。存储器520与处理器510通信耦合。补救服务器110的其它系统组件经由系统总线570连接到处理器510。补救服务器110还可以包括存储设备550和网络接口540。处理器510可以类似于图3的处理器310。同样，存储器520可类似于存储器320，存储设备550可以类似于存储设备350，网络接口540可类似于网络接口340。

在该示例中，网络接口540可被配置成将补救服务器110与IP网络120通信耦合。在一些情况下，存储设备550可以包括补救数据库140，而在其它情况下，补救数据库140可以单独提供。

存储器520可以在其中存储有补救服务器软件522，该补救服务器软件可以包括例如可操作以提供如本文所描述的补救服务器功能的可执行代码和数据。在一些示例中，存储器520可以包括可操作以提供补救引擎200的可执行软件指令。存储设备550可以是包括可操作以提供补救引擎200的软件指令的存储副本的非易失性有形存储介质。

图6是根据本说明书的一个或多个示例提供补救服务器软件522的方法的流程图。在框610中，补救服务器110从客户端设备130接收诸如应用二进制的可执行对象来进行分析和可能的补救。

框620、630和640代表在一些实施例中由补救引擎200实施的操作。在框620中，补救引擎200对可执行对象进行反汇编以识别潜在有害的逻辑、子例程或行为。在框630中，补救引擎200以更加期望的方式重建逻辑。在框640中，补救引擎200构建行为模型，其可以用如上所述的XML来构造。值得注意的是，在一些情况下，框630和框640中仅一个是必要的。在该说明书中，当补救引擎重建实际的应用二进制时，其可以包括改变行为或者插入操作系统控制钩，这称为“治愈”应用。相反，当补救引擎200使用外部控制来修正应用，这在此称为“个性化”应用行为。在一些情况下，应用可以既经过治愈，又经过个性化，在其它情况下，应用或者经过治愈或者经过个性化，在另外的情况下，两者均不是必要的。

在框650中，补救服务器110提供补救数据给客户端设备130。通过非限制示例的方式，这可以包括发送治愈后的二进制到客户端设备130，发送个性化规则240到客户端设备130，或者两者。在框660中，该方法完成。

图7是更加具体地公开了根据本说明书的一个或多个示例由补救引擎200实施的方法700的流程图。在方法700中，在框710中，补救引擎200查询声誉数据库(该声誉数据库可以包含在补救数据库140中)来判定诸如racinggame.apk的应用二进制是否具有现有的声誉。

通过示例的方式，提供三种可能的声誉：在框712中，racinggame.apk可以具有作为“良好”应用的声誉，意思是它没有呈现出恶意软件行为。在框714中，作为另一极端，racinggame.apk被已知为恶意软件。作为中间情况，在框716中，racinggame.apk可疑。该情况对于尚未经过分析且因此尚未具有声誉的任何应用可以为缺省情况。该指定还可以表明，应用包括至少一些尚未完全理解或者尚未完全补救的一些行为。在该情况下，控制传递到应用管理器740，应用管理器740可以是离散逻辑块或物理设备，或者其可以是补救引擎200的被配置为处理可疑应用的逻辑上指定的部分。应用管理器200还可以包括深入分析，包括通过人类操作员进行分析，以便更充分地探索应用二进制的功能。框716还可以提供到框722的路径，如下面所述，在该路径中，可以向用户呈现对关于应用的可用信息的描述以及呈现安装应用的机会。

在框712中，如果应用被指定为“良好”，则用户可以被提示是否要安装该应用。注意的是，因为现有的补救数据可能已经从补救数据库140取回，所以该提示仍会涉及到来自补救客户端软件322的操作。例如，补救数据可以包括在其请求的许可下应用能够做什么的普通文本描述，而不是没有任何上下文的许可请求隐晦列表。已经被呈现了该列表后，用户则可以选择安装应用或者不安装。在框720中，如果用户选择安装该应用，则在框762中，安装该应用，并且在框790中，该方法完成。

在框714中，如果应用被识别为恶意软件，则在框722中，用户具有不安装该应用或者无论如何都安装该应用的选项。在示例中，当补救引擎322为用户提供了选择是否安装应用的选项时，还可以提供对已知的恶意软件行为的描述，以及提议的补救动作，包括治愈应用以及个性化应用。在一个示例中，用户可以选择仅仅不安装应用，且在框792中方法完成。在另一示例中，用户选择继续进行安装。在该情况下，用户可以选择补救选项，或者仅一个补救选项可用，在该情况下，将采取一个补救动作。在框750中，如果个性化可供用户使用和选择，则个性化引擎780可将应用个性化。个性化引擎762可以是单独的逻辑方法或设备，或者可以是补救引擎200中的被配置为处理个性化的逻辑部分。在一个示例中，个性化引擎780可以包括个性化规则240或者从个性化规则240接收信息，并且可以包括BHRE280的部分。

在框730中，如果治愈可由用户使用和选择，则在框760中，将应用提供给修正引擎760。修正引擎760可以是单独的逻辑方法或设备，或者可以是补救引擎200中的被配置为处理治愈的逻辑部分。在示例中，补救引擎200可以包括平台API智能270、GTI290和BHRE280的部分。

从框760或782继续，包括治愈和/或个性化的应用可以安装到客户端设备130上。在框790中，方法完成。

图8是根据本说明书的一个或多个示例的客户端设备130位于原位的补救客户端软件322的框图。在该示例中，用户132提供输入到用户配置810，用户配置810被配置为存储用户偏好。用户配置810可以包括文本文件、二进制文件、或寄存器设置中的一个或多个，这仅通过非限制示例的方式给出。在示例中，补救客户端322创建空白或缺省的配置文件，其可以是格式化的XML文本文件。用户配置810还可以包括个性化规则240。操作系统840可以提供核、库、调度以及其他服务。控制钩842可以插入操作系统840中并且被配置为拦截特定的命令或消息。这些可以通过补救客户端322来调节，根据需要，补救客户端322既可以从用户配置810读，还可以写入用户配置810。控制钩842还可以以每个应用为基础记录作为目标的行为的活动。然后可以将该记录的活动呈现给用户132，并且基于此用户132也能够后来决定配置。控制钩842可以基于特定的行为而插入操作系统堆栈的“应用架构”层级的子系统中。例如，要控制SMS/调用行为，控制钩842可以插入系统的电话管理器中。控制钩842还可以插入以用于控制诸如用于控制位置服务的位置访问位置管理器的其他系统。

运行应用820可以包括恶意软件行为。在一些情况下，运行应用820可以包括来自补救服务器110的修正，可以启用或辅助控制钩842。补救客户端322还可以提供如本文所述的个性化，包括通过从用户配置810读取个性化规则240以及经由控制钩842来实施个性化规则。可以将适当的活动或错误记录在活动日志850中。

图9是根据本说明书的一个或多个示例的应用的示例性生命周期内的补救过程的框图。在框920中，用户将应用安装在客户端设备130上。在框950中，补救引擎200分析应用，包括接收来自分析云910的支持，这可以包括例如补救服务器110。在该示例中，补救引擎200可以驻存在分析云910中，且客户端设备130可以包括补救客户端软件322。在框952中，补救客户端322更新从分析云910接收到的配置数据，并且在框930中，配置数据可用于写入控制配置，例如，该控制配置可以包含在用户配置810中、个性化规则240中或者治愈后的应用820中。

在框930中，用户132发动个性化后或治愈后的应用。在框960中，补救客户端322可以为用户132呈现人类可读或可控告的行为表示，例如，经由图形用户接口或者经由活动日志850。这可以包括以下选项，通过非限制示例的方式。

a.SMS–用户132可以选择通过应用来允许或阻止发送SMS到特定号码。补救客户端322还可以检测应用何时试图发送SMS消息至高级号码并且阻止该行为。用户可以配置要阻止哪些号码以及允许哪些号码，通过列入白名单或者列入黑名单。

b.位置–补救客户端322可以被配置为检测应用何时捕获位置数据以及将位置数据转送到互联网地址。用户132可以配置补救客户端322来或者阻止应用对位置服务的访问或者通过返回错误位置来使位置模糊。在一些实施例中，错误位置可以显然地无用，诸如纬度0、经度0。在其他情况下，位置可以从预备列表选择，或者随机地生成以表现为合理的。在又一实施例中，用户132可以选择将位置精度从精细改成粗略。

c.通讯录–补救客户端322可以检测应用何时访问通讯录以及将通讯录数据发送到互联网地址。用户132可以配置补救客户端322以阻止应用访问通讯录，或者通过返回空白列表或者通过提出异常，或者用132可以允许访问通讯录，但是阻止将通讯录转送到互联网地址。在又一实施例中，用户132可以配置补救客户端322来允许访问通讯录，但是阻止转送通讯录信息至已知的恶意软件互联网地址，例如由GTI290所确定的恶意软件互联网地址。

d.SD卡–补救客户端322可以虚拟化对SD卡的访问，以使得应用或者被给予只读访问权、只写访问权、读写访问权或者无访问权。补救客户端322还可以提供对仅包含SD卡的一部分的“虚拟盘”的访问权，以使得应用不能安装、读或写SD卡的其他部分。

e.屏幕触摸输入–补救客户端322可以禁止在屏幕中的可能定位了广告或其他非期望链接的某些区域上接收输入。用户132还可以配置屏幕的这些区域以仅在用户接收到询问他是否真正想要点击屏幕的该区域的确认对话之后才登记触摸。确认对话可以经由控制钩842插入。

f.频率–可以对不过于频繁使用某些服务的应用的访问加条件。例如，可以允许应用在长的间隔内发送少量的文本消息，但是在同一天内不能发送五十个消息。

所使用的具体策略可以被配置为，当这些钩活跃时从架构API提供预期的返回值以使得应用不检测到错误状态。这将确保应用继续以其他方式正常地起作用，而不会崩溃或表现异常。

补救客户端322可以基于API语义来根据API行为标签构建人类可读和可控告的消息。例如，补救客户端322可以包括消息的库存模板(stocktemplateofmessages)，并且可以基于个性化规则240来填入适合的名词和动词。示例的消息可以基于如下模板：“该应用从你的<名词：SMS输入框><动词：读><名词：SMS数据>并且<动词：发送>它们到<名词：网站>。”。最终消息可以是“该应用从你的SMS输入框读取SMS数据并且发送它们到网站”。

在框980中，补救客户端软件322可以基于从用户132接收到的输入来更新用户配置810。这些然后可以提供给控制配置930。

在框940中，应用可以调用特定平台API。在框942中，控制钩可以用于改变API针对该特定调用或者针对应用整体的行为。在框970中，一些控制钩可以征求用户输入，并且用户输入可以提供针对用户配置810的更新。控制钩还可以提供结果给控制配置930。

前面概述了若干实施例的特征，以使得本领域技术人员可以更好地理解本公开的方面。本领域技术人员应当意识到，它们可以轻易地使用本公开作为设计或修改用于实施相同目的和/或实现本文介绍的实施例的相同优点的其他过程和结构。本领域技术人员还应当认识到，这些等同构造不偏离本公开的精神和范围，而且可以对此做出各种改变、替代和改动而不偏离本公开的精神和范围。

本公开的特定实施例显然可以包括片上系统(SOC)中央处理器(CPU)包。SOC代表了集成电路(IC)，其将计算机或其他电子系统的各组件集成到单一芯片上。其可以包括数字信号、模拟信号、混合信号以及射频功能：所有这些都可以设置在单个芯片基板上。其他实施例可以包括多芯片模块(MCM)，多个芯片定位在单一电子封装内并且被配置为彼此通过电子封装紧密地交互。在其它各个实施例中，数字信号处理功能可以实现于专用集成电路(ASIC)、现场可编程门阵列(FPGA)以及其他半导体芯片中的一个或多个硅核中。

在示例的实现方式中，本文概述的处理活动的至少一些部分还可以用软件来实现。在一些实施例中，这些特征中的一个或多个特征可以通过设置在所公开的附图元件之外的硬件来实现，或者以任何适合的方式固化以实现预期的功能。各个组件可以包括能够协调从而实现本文概述的操作的软件(或往复式软件)。在其他实施例中，这些元件可以包括任何适当的算法、硬件、软件、组件、模块、接口或便于其操作的对象。

另外，与所描述的微处理器相关联的组件中的一些可移除，或者以其他方式固化。在一般的意义上，附图中描绘的布置可以在其表示上更具有逻辑性，而物理体系结构可以包括各种置换、组合和/或这些要素的混合。必需要注意的是，不计其数的可能的设计配置能够用于实现本文概述的操作目标。因此，相关联的基础结构具有各种替代布置、设计选择、设备可能性、硬件配置、软件实现方式、装备选项等。

任何适当配置的处理器组件能够执行与实现本文详述的操作的数据相关联的任意类型的指令。本文公开的任何处理器可以将元件或物品(例如，数据)从一种状态或事物变换成另一种状态或事物。在另一示例中，本文概述的一些活动可以由固定逻辑或可编程逻辑(例如，由处理器执行的软件和/或计算机指令)来实现，并且本文标识的元件可以为可编程处理器、可编程数字逻辑(例如，现场可编程门阵列(FPGA)、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)、包括数字逻辑的ASIC、软件、代码、电子指令、闪速存储器、光盘、CD-ROM、DVDROM、磁卡或光卡、适合存储电子指令的其他类型的机器可读介质或者它们的任何适合的组合中的某种类型。在操作中，处理器可以基于特定需要而将信息适当地存储在任何适合类型的非暂态存储介质(例如，随机存取存储器(RAM)、只读存储器(ROM)、现场可编程门阵列(FPGA)、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)等)、软件、硬件、或者任何其他适合的组件、设备、元件或对象中。此外，基于特定的需要和实现方式，在处理器中跟踪、发送、接收或存储的信息可以提供在任何数据库、寄存器、表格、高速缓存、队列、控制列表、或存储结构中，所有这些可以在任何适合的时间帧引用。本文论述的任何存储器项目应当解释为涵盖在广义术语“存储器”内。类似地，本文描述的任意可能的处理元件、模块和机器应当解释为涵盖在广义术语“微处理器”或“处理器”内。

实现本文描述的功能的全部或部分的计算机程序逻辑以各种形式实施，包括但绝不限于源代码形式、计算机可执行形式、以及各种中间形式(例如，由汇编器、编译器、链接器或定位器所生成的形式)。在示例中，源代码包括以各种编程语言实现的一系列计算机程序指令，诸如对象代码、汇编语言或诸如用于各种操作系统或操作环境的OpenCL、Fortran、C、C++、JAVA或HTML高级语言。源代码可以定义并且使用各种数据结构和通信消息。源代码可以为计算机可执行形式(例如，经由解译器)，或者源代码可以被转换(例如，通过翻译器、汇编器或编译器)成计算机可执行形式。

在上述实施例的论述中，电容器、缓冲器、图形元件、互连板、时钟、DDR、摄像机传感器、分压器、电感器、电阻器、放大器、开关、数字核、晶体管和/或其他组件能够容易地替换、取代或以其他方式修改以便于适应特定的电路需要。而且，应当注意，互补电子器件、硬件、非暂态软件等的使用提供了同等可行的实现本公开教导的选项。

在一个示例中，附图中的任意数量的电路可以实现在相关联的电子器件的板上。板可以是普通的电路板，其能够容纳电子器件的内部电子系统的各组件，并且进一步提供用于其他外围设备的连接器。更具体而言，板能够提供电连接，通过该电连接系统的其他组件能够进行电通信。基于特定的配置需要、处理需求、计算机设计等，任何适合的处理器(包含数字信号处理器、微处理器、支持芯片组等)、存储器元件等能够适当地与板耦合。诸如用于音频/视频显示器的外部存储设备、附加传感器、控制器以及外围设备的其他组件可以作为插入卡附接到板上，或者集成到板本身上。在另一示例中，附图中的电路可以实现为独立模块(例如，具有被配置为执行特定应用或功能的关联组件或电路的设备)或者实现为电子设备的专用硬件的插入式模块。

注意的是，通过本文提供的若干示例，可以以两个、三个、四个或更多的电气组件的形式来描述交互。然而，这仅为了清晰和示例的目的而进行。应意识到，系统能够以任何适当的方式固化。沿着类似的设计可选方案，附图中所示的组件、模块和元件中的任何可以组合成各种可能的配置，所有这些都清楚地位于本说明书的宽泛范围内。在一些情况下，通过仅参考有限数量的电气元件，可以更容易描述给定一组流程的一个或多个功能。应当意识到，附图中的电路及其教导易于进行尺度调整并且能够适应大量的组件以及更加复杂/精致的布置和配置。因此，提供的示例不应限制范围或者抑制潜在应用于多种其他体系结构的电路的广义教导。

若干其他的改变、替代、变动、改动和修改可以由本领域技术人员确定，旨在本公开涵盖所有这样的改变、替代、变动、改动和修改落入随附权利要求范围内。为助于美国专利商标局(USPTO)以及另外辅助在本申请上发布的任何专利的任意读者解释随附于此的权利要求，申请人希望提请注意，申请人：(a)不旨在任意随附的权利要求在其申请日存在时援引35U.S.C.的112节的第六(6)段，除非在特定权利要求中具体使用了用语“用于…的手段”或“用于…的步骤”；以及(b)不旨在通过说明书中的任何陈述以任何否则不反映在随附权利要求中的方式限制本公开。

示例性实施例的实现方式

在示例1中公开了一种客户端设备，包括：

处理器；

网络接口；以及

存储器，其上存储有应用二进制和可操作以进行以下操作的可执行指令：

接收针对所述应用二进制的补救数据；以及

通过插入操作系统钩以选择性地强制执行对系统服务的访问许可来个性化所述应用二进制，其中选择性地强制执行是基于所述补救数据的。

在示例2中公开了如示例1所述的客户端设备，其中所述系统服务是从由地理位置、电子邮件、短消息服务、电话、通讯录、互联网访问、摄像机、触摸屏、麦克风和扬声器构成的组中选择的。

在示例3中公开了如示例1-2所述的客户端设备，其中所述补救数据包括个性化规则。

在示例4中公开了如示例3所述的客户端设备，其中所述个性化规则包括识别所述应用二进制中的一个或多个恶意软件行为的结构化数据以及针对所识别出的每个恶意软件行为的补救动作。

在示例5中公开了如示例3或4所述的客户端设备，其中所述个性化规则包括针对所述应用二进制的恶意软件声誉。

在示例6中公开了如示例1-5所述的客户端设备，其中所述指令进一步可操作以基于用户配置来选择性地强制执行访问许可。

在示例7中公开了如示例6所述的客户端设备，其中所述用户配置包括可操作以提供交互式用户输入的指令。

在示例中公开了一种补救服务器，包括：

处理器；

网络接口；以及

存储器，其上存储有可执行指令，这些可执行指令能够操作以进行以下操作：

接收应用二进制；

创建所述应用二进制的应用逻辑模型；以及

基于所述应用逻辑模型来创建针对所述应用二进制的个性化规则。

在示例9中公开了如示例8所述的补救服务器，其中所述可执行指令进一步能够操作以进行以下操作：

反汇编所述应用二进制；

检测所述应用二进制中的恶意软件行为；以及

通过插入或移除指令以改良所述恶意软件行为以及重新编译所述应用二进制来治愈所述应用二进制。

在示例10中公开了如示例8或9所述的补救服务器，其中创建个性化规则包括：从平台API智能数据库接收应用编程接口(API)智能。

在示例11中公开了如示例8-10所述的补救服务器，其中创建个性化规则包括从全球威胁智能数据库接收威胁智能。

在示例12中公开了如示例8-11所述的补救服务器，其中创建个性化规则包括对所述应用二进制执行启发式分析。

在示例13中公开了如示例8-12所述的补救服务器，其中所述应用逻辑模型包括结构化文本，所述结构化文本被配置为包含代表应用编程接口(API)元件的文本对象。

在示例14中公开了至少一个计算机可读存储介质，其上存储有可操作以补救应用二进制的可执行指令，包括可操作以进行以下操作的指令：

接收针对所述应用二进制的声誉；

如果所述声誉是恶意软件，则基于用户配置输入而选择性地安装所述应用二进制；以及

通过与个性化引擎同时运行所述应用来个性化所述应用。

在示例15中公开了如示例14所述的计算机可读存储介质，其中所述指令进一步能够操作以进行以下操作：

如果所述声誉是恶意软件，则将应用二进制提供给补救服务器；以及

从所述补救服务器接收治愈后的应用二进制。

在示例16中公开了如示例15所述的计算机可读存储介质，其中所述指令进一步可操作以抑制所述应用二进制的安装直到从所述补救服务器接收到所述治愈后的应用二进制之后为止。

在示例17中公开了如示例14-16所述的计算机可读存储介质，其中能够操作以基于用户配置输入而选择性地安装所述应用二进制的指令进一步能够操作以进行以下操作：

提供请求确认安装所述应用二进制的交互式用户接口元件；以及

仅在接收到对于所述交互式用户接口元件的肯定回应的情况下，才安装所述应用二进制。

在示例18中公开了如示例17所述的计算机可读存储介质，其中可操作以提供交互式用户接口元件的指令进一步能够操作以随其提供所述应用二进制的行为的可控告的、人类可读描述。

在示例19中公开了如示例14-18所述的计算机可读存储介质，其中能够操作以通过与个性化引擎同时运行所述应用而个性化所述应用进一步能够操作以从用户接口元件接收输入从而选择性地提供对系统服务的访问。

在示例20中公开了如示例19所述的计算机可读存储介质，其中所述系统服务是从由地理位置、电子邮件、短消息服务、电话、通讯录、互联网访问、摄像机、触摸屏、麦克风和扬声器所构成的组中选择的。

在示例21中公开了如示例14-20所述的计算机可读存储介质，其中所述软件指令进一步能够操作以提供补救引擎。

在示例22中公开了如示例21所述的计算机可读存储介质，其中能够操作以提供所述补救引擎的软件指令进一步能够操作以进行以下操作：

反汇编所述应用二进制；

检测所述应用二进制中的恶意软件行为；以及

在示例23中公开了如示例22所述的计算机可读存储介质，其中能够操作以提供所述补救引擎的软件指令进一步能够操作以进行以下操作：

创建所述应用二进制的应用逻辑模型；以及

在示例24中公开了如示例14-23所述的计算机可读存储介质，其中所述软件指令进一步能够操作以利用全球威胁智能服务提供闭环分析。

在示例25中公开了补救应用二进制的方法，包括：

接收针对所述应用二进制的补救数据；以及

在示例26中公开了如示例25所述的方法，进一步包括：

反汇编所述应用二进制；

检测所述应用二进制中的恶意软件行为；以及

Claims

1.一种客户端设备，包括:

处理器；

网络接口；以及

存储器，其上存储有应用二进制和能够操作以进行以下操作的可执行指令：

接收针对所述应用二进制的补救数据；以及

通过插入操作系统钩以选择性地强制执行对系统服务的访问许可来个性化所述应用二进制，其中，选择性地强制执行是基于所述补救数据的。

2.如权利要求1所述的客户端设备，其中，所述系统服务是从由地理位置、电子邮件、短消息服务、电话、通讯录、互联网访问、摄像机、触摸屏、麦克风和扬声器所构成的组中选择的。

3.如权利要求1-2所述的客户端设备，其中，所述补救数据包括个性化规则。

4.如权利要求3所述的客户端设备，其中，所述个性化规则包括用于识别所述应用二进制中的一个或多个恶意软件行为的结构化数据，以及针对所识别出的每个恶意软件行为的补救动作。

5.如权利要求3或4所述的客户端设备，其中，所述个性化规则包括针对所述应用二进制的恶意软件声誉。

6.如权利要求1-5所述的客户端设备，其中，所述指令进一步能够操作以基于用户配置来选择性地强制执行访问许可。

7.如权利要求6所述的客户端设备，其中，所述用户配置包括能够操作以提供交互式用户输入的指令。

8.一种补救服务器，包括：

处理器；

网络接口；以及

存储器，其上存储有能够操作以进行以下操作的可执行指令：

接收应用二进制；

创建所述应用二进制的应用逻辑模型；以及

9.如权利要求8所述的补救服务器，其中，所述可执行指令进一步能够操作以进行以下操作：

反汇编所述应用二进制；

检测在所述应用二进制中的恶意软件行为；以及

10.如权利要求8或9所述的补救服务器，其中，创建个性化规则包括：从平台应用编程接口(API)智能数据库接收API智能。

11.如权利要求8-10所述的补救服务器，其中，创建个性化规则包括从全球威胁智能数据库接收威胁智能。

12.如权利要求8-11所述的补救服务器，其中，创建个性化规则包括对所述应用二进制执行启发式分析。

13.如权利要求8-12所述的补救服务器，其中，所述应用逻辑模型包括结构化文本，所述结构化文本被配置为包含代表应用编程接口(API)元件的文本对象。

14.至少一种计算机可读存储介质，其上存储有可执行指令，所述可执行指令能够操作以补救应用二进制，包括能够操作以进行以下操作的指令：

接收针对所述应用二进制的声誉；

通过与个性化引擎同时运行所述应用来个性化所述应用。

15.如权利要求14所述的计算机可读存储介质，其中，所述指令进一步能够操作以进行以下操作：

如果所述声誉是恶意软件，则将所述应用二进制提供给补救服务器；以及

从所述补救服务器接收治愈后的应用二进制。

16.如权利要求15所述的计算机可读存储介质，其中，所述指令进一步能够操作以抑制所述应用二进制的安装直到从所述补救服务器接收到所述治愈后的应用二进制之后为止。

17.如权利要求14-16所述的计算机可读存储介质，其中，能够操作以基于用户配置输入而选择性地安装所述应用二进制的指令进一步能够操作以进行以下操作：

提供用于请求确认安装所述应用二进制的交互式用户接口元件；以及

18.如权利要求17所述的计算机可读存储介质，其中，能够操作以提供交互式用户接口元件的指令进一步能够操作以随其提供对所述应用二进制的行为的可控告的、人类可读的描述。

19.如权利要求14-18所述的计算机可读存储介质，其中，能够操作以通过与个性化引擎同时运行所述应用而个性化所述应用的指令进一步能够操作以从用户接口元件接收输入从而选择性地提供对系统服务的访问。

20.如权利要求19所述的计算机可读存储介质，其中，所述系统服务是从由地理位置、电子邮件、短消息服务、电话、通讯录、互联网访问、摄像机、触摸屏、麦克风和扬声器所构成的组中选择的。

21.如权利要求14-20所述的计算机可读存储介质，其中，所述软件指令进一步能够操作以提供补救引擎。

22.如权利要求21所述的计算机可读存储介质，其中，能够操作以提供所述补救引擎的软件指令进一步能够操作以进行以下操作：

反汇编所述应用二进制；

检测在所述应用二进制中的恶意软件行为；以及

23.如权利要求22所述的计算机可读存储介质，其中，能够操作以提供所述补救引擎的软件指令进一步能够操作以进行以下操作：

创建所述应用二进制的应用逻辑模型；以及

24.如权利要求14-23所述的计算机可读存储介质，其中，所述软件指令进一步能够操作以利用全球威胁智能服务提供闭环分析。

25.一种补救应用二进制的方法，包括：

接收针对所述应用二进制的补救数据；以及

26.如权利要求25所述的方法，进一步包括：

反汇编所述应用二进制；

检测在所述应用二进制中的恶意软件行为；以及