CN104462880A - 应用程序加壳配置方法与装置 - Google Patents

Abstract

本发明涉及一种应用程序加壳配置方法，其包括以下步骤：解析所述应用程序原安装包，获得其内部文件；构造集合所述原安装包与所述内部文件的加壳安装包，使加壳安装包与原安装包具有不同的包名，所述被集合的内部文件中配置有加载模块，该加载模块，用于将被集合的原安装包加载到沙箱运行环境中以运行所述应用程序；安装该加壳安装包。此外，本发明还涉及与该方法相应的一种应用程序加壳配置装置。本发明使得目标应用程序能够运行于沙箱运行环境中，并且能确保系统的安全。

Description

应用程序加壳配置方法与装置

技术领域

本发明涉及计算机软件安全技术领域，尤其涉及一种应用程序加壳配置方法及相应的装置。

背景技术

沙箱是一种按照安全策略限制程序行为的执行环境，目前已经广泛实用于各种操作系统中。以Android为例，一些应用程序，出于实现应用程序固有功能需要之外的目的，特别是商业目的，随意申请系统权限，获取用户隐私数据、执行网络访问、保持设备活动、发送短信行为等。轻则可能导致用户隐私数据泄露，或者占用系统资源，重则可能通过恶意扣费、植入广告、消耗资费、欺诈诱骗等，使用户遭受损失。因此，通过沙箱技术提供的执行环境，由沙箱对系统的资源、权限进行管理，让应用程序于该沙箱中运行，应用程序的访问先经沙箱按安全策略进行审查，由此，形成一种相对于系统本身的隔离运行效果，可以有效地保护系统的安全。对于沙箱中所用到的安全策略，适应各种不同的操作系统有不同的细节考虑，这些有关技术实现的基本知识，均已为本领域技术人员所掌握，恕不赘述。

目前有多种实例来实现沙箱技术。这些实例中，一方面，沙箱技术为了兼容市面的多种应用，一般仅仅通过限定沙箱的安全策略，控制该应用的可执行资源而实现。然而，在安全领域，攻防双方的技术水平此消彼长，传统的仅仅通过限制安全策略的沙箱，有时难以确保能够达到所期望的目的，必须借助于更富技术含量的新方案。另一方面，沙箱技术往往涉及系统底层操作，而在诸如以Android为代表的Unix系的操作系统中，本身有着严格的权限管理，这样，便导致在未获得Root授权的前提下，难以应用沙箱技术去构造沙箱。可以独辟蹊径，去实现免Root环境下的沙箱环境，然而，在这种情况下，往往会引起多方面的一些技术障碍，这些障碍依沙箱的具体实现方式而定。

目前现有技术中，对于这种免Root沙箱，尽管存在理论可能，未见成熟案例。但是，从以上的分析可以看出，要基于免Root环境实现一种更为安全的沙箱技术，需要结合其具体技术原理，来考虑其自身的具体构造以及在必要时考虑对相关应用程序的重构，使得重构后的应用程序可以无缝运行于已经基于系统而保持相对独立的沙箱之中，通过该应用程序在沙箱中的运行，实现应有的安全控制效果。

发明内容

本发明的第一目的在于提供一种应用程序加壳配置方法，以便为免Root沙箱环境配置便于加载运行的应用程序。

本发明的第二目在于提供一种适于构造第一目的所述的方法的应用程序加壳配置装置。

为实现本发明的目的，本发明采取如下技术方案：

本发明的一种应用程序加壳配置方法，其包括以下步骤：

解析所述应用程序原安装包，获得其内部文件；

构造集合所述原安装包与所述内部文件的加壳安装包，使加壳安装包与原安装包具有不同的包名，所述被集合的内部文件中配置有加载模块，该加载模块，用于将被集合的原安装包加载到沙箱运行环境中以运行所述应用程序；

安装该加壳安装包。

较佳的，加壳安装包的包名，由所述原安装包的包名附加前缀构成。

具体的，所述内部文件之一为被集合的原安装包的配置文件的副本，该副本中涉及组件和动作名称处均被附加所述的前缀，所述配置文件的副本特指Androidmanifest.xml文件。

进一步，所述加载模块设置于内部文件之一的代码文件中，该加载模块被配置为采用反射调用机制加载所述被集合的原安装包以运行所述应用程序。所述代码文件特指classes.dex文件。

根据本发明的一个实例所揭示，所述内部文件包括被集合的自原安装包获得的资源文件和/或动态库文件及其相应的目录结构。

具体的，所述资源文件特指Res目录及其下所包含的文件，所述动态库文件特指Lib目录及其下所包含的文件。

较佳的，所述资源文件包括图标文件，且该图标文件基于被集合的自原安装包获得的相应图标文件进行局部修改所得。

具体的，所述被集合的原安装包被置于加壳安装包的Assets目录中。

进一步，所述加载模块被配置为引导沙箱运行环境对所述应用程序的运行进程实施安全监控，以实现该应用程序在沙箱运行环境中的正常运行。

本发明提供的一种应用程序加壳配置装置，其特征在于，包括：

获取单元，用于解析所述应用程序原安装包，获得其内部文件；

构造单元，用于构造集合所述原安装包与所述内部文件的加壳安装包，使加壳安装包与原安装包具有不同的包名，所述被集合的内部文件中配置有加载模块，该加载模块，用于将被集合的原安装包加载到沙箱运行环境中以运行所述应用程序；

安装单元，用于安装该加壳安装包。

相较于现有技术，本发明至少具有如下优点：

1、借助目标应用程序安装包自身的内部文件为该安装包加壳，生成加壳安装包，使加壳安装包具有与原安装包具有不同的包名(PackageName)，原安装包的对应组件和动作便被加壳安装包进行注册，由此，在宿主应用程序安装运行后，再借助反射调用机制去加载安装包的四大组件时，借助相应函数使宿主应用程序的包名与目标应用程序所调度的包名保持一致，在Android系统中，既能使活动组件和服务组件建立与ActivityManagerService的正常通信，又能使活动组件、服务组件以及广播组件等，顺利被PackageManagerService识别，降低现有技术中有关加壳应用程序运行异常的错误率。

2、通过在加壳的宿主应用程序中配置用于反射调用原安装包的加载模块，并且由加载模块建立起原安装包的目标应用程序与沙箱运行环境之间的通信，使得目标应用程序的活动过程可以进一步被沙箱运行环境进行监视，从而对其适用安全策略，以及对其进行资源引用重定向等，确保目标应用程序能被宿主应用程序正常加载并保持正常运行。

3、由于宿主应用程序利用原安装包的Androidmanifest.xml为蓝本，修改包名后，完成了正常的安装注册程序，不必为被反射调用的目标应用程序的各个组件(Activity,Service,Receiver)单独构造主函数入口(ActivityThread.main)和提供LoadedAPK对象，也不必考虑因包名而带来的PackageManagerService校验的程序实现复杂度问题，从而大大提高程序运行效率。

本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1是本发明的应用程序加壳配置方法的流程原理图；

图2是本发明的应用程序加壳配置装置的原理图；

图3是本发明的应用程序免Root运行控制方法的流程原理图；

图4是本发明的应用程序免Root运行控制装置的原理图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

本技术领域技术人员可以理解，这里所使用的“终端”、“终端设备”既包括无线信号接收器的设备，其仅具备无发射能力的无线信号接收器的设备，又包括接收和发射硬件的设备，其具有能够在双向通信链路上，执行双向通信的接收和发射硬件的设备。这种设备可以包括：蜂窝或其他通信设备，其具有单线路显示器或多线路显示器或没有多线路显示器的蜂窝或其他通信设备；PCS(Personal CommunicationsService，个人通信系统)，其可以组合语音、数据处理、传真和/或数据通信能力；PDA(Personal Digital Assistant，个人数字助理)，其可以包括射频接收器、寻呼机、互联网/内联网访问、网络浏览器、记事本、日历和/或GPS(Global Positioning System，全球定位系统)接收器；常规膝上型和/或掌上型计算机或其他设备，其具有和/或包括射频接收器的常规膝上型和/或掌上型计算机或其他设备。这里所使用的“终端”、“终端设备”可以是便携式、可运输、安装在交通工具(航空、海运和/或陆地)中的，或者适合于和/或配置为在本地运行，和/或以分布形式，运行在地球和/或空间的任何其他位置运行。这里所使用的“终端”、“终端设备”还可以是通信终端、上网终端、音乐/视频播放终端，例如可以是PDA、MID(Mobile Internet Device，移动互联网设备)和/或具有音乐/视频播放功能的移动电话，也可以是智能电视、机顶盒等设备。

本技术领域技术人员可以理解，这里所使用的服务器、云端、远端网络设备等概念，具有等同效果，其包括但不限于计算机、网络主机、单个网络服务器、多个网络服务器集或多个服务器构成的云。在此，云由基于云计算(Cloud Computing)的大量计算机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。本发明的实施例中，远端网络设备、终端设备与WNS服务器之间可通过任何通信方式实现通信，包括但不限于，基于3GPP、LTE、WIMAX的移动通信、基于TCP/IP、UDP协议的计算机网络通信以及基于蓝牙、红外传输标准的近距无线传输方式。

本领域技术人员应当理解，本发明所称的“应用”、“应用程序”、“应用软件”以及类似表述的概念，是业内技术人员所公知的相同概念，是指由一系列计算机指令及相关数据资源有机构造的适于电子运行的计算机软件。除非特别指定，这种命名本身不受编程语言种类、级别，也不受其赖以运行的操作系统或平台所限制。理所当然地，此类概念也不受任何形式的终端所限制。

本发明以下即将描述的一种方法和装置所实施的应用场景，是安装在移动终端上的基于Android操作系统的运行环境。

为了说明本发明的实施，本发明试图结合计算机程序的静态和动态两个方面进行描述，所谓静态方面，是指程序安装包、文件、数据库等存储于媒介的存储对象；所谓动态方面，是指被调入内存中执行的动态对象，包括但不局限于进程、线程、所用到的数据等。鉴于计算机软件技术的这些特点，不应将本发明所述及的各个方法、步骤、子步骤、装置、单元、模块等，孤立地理解为仅静态或仅动态的方面，本领域技术人员对此应当知晓。故而，本领域技术人员应当能够依据本发明有关静态的表述而将其对应到动态的进程活动，或者依据本发明有关动态的进程活动对应到其静态的表现形式，建立起静态与动态两方面的必然性关联，以此为基础来理解本发明。

本领域技术人员应当知晓，本发明是基于免Root提权而提出的，然而，提权操作只是Android系统所实施的权限管理控制，本发明也当然地适用于已经Root提权的Android操作系统中。

本发明是基于沙箱原理而提出的，故而，本领域技术人员得以结合公知的沙箱实现原理来理解本发明的实施。沙箱的作用是为目标应用程序的提供相对封闭的运行环境，使应用程序对系统的资源访问，借助沙箱安全策略的应用，而被限制在规定的范围之内。因而，本发明的实质在于提供一种沙箱实例，从两个方面来实现，第一方面是提供构造目标应用程序的解决方案，第二方面是提供与前者相应的运行控制方案。这两个方面可以被集成到一个沙箱实现软件中，利用其第一方面的实现对目标应用程序进行加工，进而利用其第二方面的实现，为目标应用程序提供安全的沙箱运行环境。

有鉴于此，本发明的应用程序加壳配置方法，主要体现沙箱实例的第一方面，用于加工适配于相应的沙箱运行环境的目标应用程序，在如图1所示的实例中，该方法包括如下步骤：

S11、解析所述应用程序原安装包，获得其内部文件。

这里所称的应用程序，即前文所称的目标应用程序。由于本发明基于免Root需求而提出，根据Android固有的原理，所述目标应用程序一般为用户自行安装的第三方应用。

本发明可以通过接管安装器，来实现对第三方应用的安装控制。具体而言，可以由用户通过本发明提供的沙箱应用程序下载并安装该第三方应用而获得所述原安装包，或者，也可由该沙箱应用程序从/data/app中获取相应安装包文件。对于已装应用，可以本发明处理完毕之后，诱导用户卸载旧应用，安装新应用。

解析应用程序的原安装包的手段，为本领域技术人员所熟知。安装包APK文件本质上是利用ZIP压缩技术结合签名技术实现的压缩包，因此，一方面可以通过解压技术释放其内部文件，另一方面还可通过Apktool之类的工具软件获取其内部文件(在这种情况下其代码文件会被反向为.smali文件)。本领域技术人员均能娴熟地利用这些公知技术在一个给定目录中对原安装包进行处理，从而通过内存操作(非文件操作)的方式来获得其中的内部文件。

Android安装包的内部文件，参阅下表所示：

表1 APK文件内部的文件结构

本发明通过解析所述目标应用程序的原安装包，可以获得表中所附的目录和文件，在此基础上，参照实现作为宿主应用程序的加壳安装包，详见后一步骤。

S12、构造集合所述原安装包与所述内部文件的加壳安装包。

以下先结合表1对本发明构造所述加壳安装包所需的内部文件进行介绍。

表1所列的各种属于安装包的内部文件中，MATA-INF目录是在对其他文件打包后签名而生成的，因此，后续生成加壳安装包时，会有加壳安装包自身的签名而产生相同的目录结构和文件，故而原安装包的相应目录结构和文件不会被置入加壳安装包中。

res\目录及其下包含的资源，是目标应用程序运行过程中需引用的资源，目标应用程序在运行时可以通过ID进行访问。因而，可以结合程序实现的难度考虑，而考虑是否将其中的部分资源文件置入后续的加壳安装包中。本实施例关注其中的主图标文件例如icon.png文件，该文件即目标应用程序的主图标文件，目标应用程序的安装包正常安装时，会在桌面显示该图标文件作为其快捷图标。本实施例中，对该图标的图样进行局部修改，例如为其图样右下角附加一锁头样式，使其成为带特定标记的图标，并将修改后的图标文件作为加壳安装包的图标文件，存放于加壳安装包的res\目录下。由此，加壳安装包安装后，用户可以通过其图标认知该程序已被进行沙箱防护。当然，也可以考虑将res\目录下的其它资源文件作为构造加壳安装包的内部文件引入，但在后续反射调用该目标应用程序时，需进行资源引用重定向，以便目标应用能够正常引用到正确资源。

assets\目录用于存放广义的资源文件，例如安装包文件、字体文件等不可压缩的文件，可以通过路径来访问该目录中的资源。本实施例中，不将原安装包的assets\目录的文件引入，是为了减小加壳安装包的体积，在加壳安装包的assets\目录中，存放将被反射调用的目标应用程序的原安装包。

resources.arsc文件主要是建立对安装包所指向的应用程序的索引，在本实施例中也不在加壳安装包中使用原安装包的同名文件。

lib\目录下的文件，主要是存放.so动态库文件，该原安装包的动态库文件是否被一同集合到加壳安装包中，同理，可以结合程序实现复杂度加以考虑，按需选用。本实施例中不考虑将其移置于加壳安装包中。

Androidmanifest.xml文件，是安装包中较为重要的全局配置文件，其负责向系统注册Android系统的四大组件，以及向系统申请权限等。在加壳安装包中，将其作为需要加入加壳安装包的重要内部文件进行考虑，但是，作为本发明实现的关键，对该配置文件进行修改。修改的内容主要是因应加壳安装包的包名不同于目标应用程序的包名，故而，加壳安装包中的Androidmanifest.xml文件以原安装包的同名文件为蓝本，将其中涉及包名的字符串，修改成加壳安装包的包名。具体涉及有关四大组件(Activity,Service,Broacast Receiver,Content Provider)及相关动作(Action)的声明中对包名的引用处。本发明的推荐实施例中，是在原安装包的包名基础上附加前缀，例如，原安装包的包名是com.apk，则加壳安装包的包名可以是apphost.com.apk。诚然，本领域技术人员可以灵活改变这一改名规则，只要在程序运行过程中可以构造利用逆向规则将两个包名建立对应进而实现重定向即可。由此，加壳安装包在系统中安装运行宿主应用程序之后，以Androidmanifest.xml向系统注册各个组件和申请系统权限，以此便建立了各个组件的入口，使经反射调用的目标应用程序的各个组件均可以结合所述逆向规则而被ActivityManagerService调用，而不必为所述各个组件构造ActivityThread和提供相应的LoadedAPK对象，省去运行上下文环境的程序实现环节。同理，反射调用所导致的PackageManagerService对各大组件是否合法注册进行校验的问题，也将因Androidmanifest.xml的注册结合所述的逆向规则而被克服。

classes.dex为安装包中的代码文件(二进制代码可执行文件)。在本发明中，将被预构造的同名文件所替换，但该同名文件与其他文件一起被集合到所述加壳安装包中。本发明所提供的classes.dex，植入有加载模块stub()，通过该加载模块，可以进一步启动一监控模块，该监控模块用于监控经反射调用的整个目标应用程序的活动过程，因此，监控模块先于所述目标应用程序而加载。该监控模块便是沙箱运行环境的实现者，负责实现两方面的功能，一方面通过监控目标应用程序对资源的访问，这一资源包括原安装包res\、assets\的资源，也包括涉及包名调用的Intent，还包括系统资源等广义资源。通过对资源引用进行重定向，使目标应用程序进程能够实现对正确资源的正常引用。具体而言，如果相关资源是被反射调用的原安装包的资源，则通过反射调用机制调用该原安装包的资源供引用，实现重定向。如果是系统资源或者指向宿主应用程序的已安装资源，则可允许其默认引用保证其正常引用关系。如果是I/O操作，也可以藉此进行重定向。需要注意的是，当这种广义资源引用涉及宿主应用程序与目标应用程序之间的包名差异时，如前所述，应当利用所述的逆向规则来确保目标应用程序所引用的资源正确无误。另一方面通过监控目标应用程序对系统资源的访问，例如是否请求发送短信息，来依据安全策略确定是否允许其操作，当不允许这种实施这种行为是，可以向相关调用指令返回自定义数据，例如返回空值，从而确保能杜绝一些非法操作。

所述监控模块的技术实现，采用Hook技术，利用钩子函数对相关调用指令的入口点进行监视，截获此一调用指令，转向执行相应的钩子函数，由该钩子函数依据沙箱自身逻辑来应答该调用指令，从而达到前述的目的。

这里需要补充的是：术语“钩子”涵盖了用于通过拦截在软件组件之间传递的函数调用、消息、或事件来改变或增加操作系统、应用程序、或其他软件组件的行为的技术。而处理这种被拦截的函数调用、事件或消息的代码就被称为钩子hook函数。钩子通常用于各种目标，包括对功能进行调试和对功能进行扩展。其示例可以包括在键盘或鼠标事件传递到应用程序之前拦截它们，或者拦截系统调用(system call)、或者系统函数行为、函数执行结果等，以监视或修改应用程序或其他组件的功能等等。本实施例即可采用钩子hook函数接管所述应用程序运行时所需的安装自校验操作。

准备好上述的内部文件和原安装包后，本发明进一步将上述选定的内部文件和原安装包进行打包，打包后再行签名，即完成所述加壳安装包的构造，原安装包位于加壳安装包的assets\目录中，成为加壳安装包的附带资源。进一步可通过下一步骤安装该加壳安装包，从而安装宿主应用程序。

考虑到所生成的加壳安装包的文件将大于原安装包，本发明进而可以对加壳安装包中的代码文件进行压缩，生成压缩文件和用于还原所述压缩文件为代码文件的附加文件，这一压缩过程同理适用于所述原安装包中。只要后续安装过程中依据逆向算法，利用附加文件对所述压缩文件在内存中进行还原，即可使宿主应用程序和目标应用程序实现正常运行。经过压缩的安装包，其增量接近于零甚至小于零，因此效率较高。

S13、安装该加壳安装包。

如前所述，本发明的实施场景之一，未获Root权限，因此，这种场景中，并不能通过本发明实现静默安装。这种情况下，本发明优先通过调用系统安装器，以启动安装界面，指导用户完成该加壳安装包的安装。

根据计算机程序的模块化思维，本发明进而可以依据上述应用程序加壳配置方法而提供一种应用程序加壳配置装置，具体请结合图2并参阅如下说明。

本发明的应用程序加壳配置装置，由获取单元11、构造单元12以及安装单元13构成，各单元实现的功能如下：

所述的获取单元11，用于解析所述应用程序原安装包，获得其内部文件。

这里所称的应用程序，即前文所称的目标应用程序。由于本发明基于免Root需求而提出，根据Android固有的原理，所述目标应用程序一般为用户自行安装的第三方应用。

本发明可以通过接管安装器，来实现对第三方应用的安装控制。具体而言，可以由用户通过本发明提供的沙箱应用程序下载并安装该第三方应用而获得所述原安装包，或者，也可由该沙箱应用程序从/data/app中获取相应安装包文件。对于已装应用，可以本发明处理完毕之后，诱导用户卸载旧应用，安装新应用。

解析应用程序的原安装包的手段，为本领域技术人员所熟知。安装包APK文件本质上是利用ZIP压缩技术结合签名技术实现的压缩包，因此，一方面可以通过解压技术释放其内部文件，另一方面还可通过Apktool之类的工具软件获取其内部文件(在这种情况下其代码文件会被反向为.smali文件)。本领域技术人员均能娴熟地利用这些公知技术在一个给定目录中对原安装包进行处理，从而获得其中的内部文件。需要强调的是，本发明所称获得其内部文件，推荐以公知的内存操作的方式而获得，而非指文件操作。

Android安装包的内部文件，同理参阅表1。本发明通过解析所述目标应用程序的原安装包，可以获得表1中所附的目录和文件，在此基础上，参照实现作为宿主应用程序的加壳安装包，详见构造单元的说明。

所述的构造单元12，用于构造集合所述原安装包与所述内部文件的加壳安装包。

以下先结合表1对本发明构造所述加壳安装包所需的内部文件进行介绍。

表1所列的各种属于安装包的内部文件中，MATA-INF目录是在对其他文件打包后签名而生成的，因此，后续生成加壳安装包时，会有加壳安装包自身的签名而产生相同的目录结构和文件，故而原安装包的相应目录结构和文件不会被置入加壳安装包中。

res\目录及其下包含的资源，是目标应用程序运行过程中需引用的资源，目标应用程序在运行时可以通过ID进行访问。因而，可以结合程序实现的难度考虑，而考虑是否将其中的部分资源文件置入后续的加壳安装包中。本实施例关注其中的主图标文件例如icon.png文件，该文件即目标应用程序的主图标文件，目标应用程序的安装包正常安装时，会在桌面显示该图标文件作为其快捷图标。本实施例中，对该图标的图样进行局部修改，例如为其图样右下角附加一锁头样式，使其成为带特定标记的图标，并将修改后的图标文件作为加壳安装包的图标文件，存放于加壳安装包的res\目录下。由此，加壳安装包安装后，用户可以通过其图标认知该程序已被进行沙箱防护。当然，也可以考虑将res\目录下的其它资源文件作为构造加壳安装包的内部文件引入，但在后续反射调用该目标应用程序时，需进行资源引用重定向，以便目标应用能够正常引用到正确资源。

assets\目录用于存放广义的资源文件，例如安装包文件、字体文件等不可压缩的文件，可以通过路径来访问该目录中的资源。本实施例中，不将原安装包的assets\目录的文件引入，是为了减小加壳安装包的体积，在加壳安装包的assets\目录中，存放将被反射调用的目标应用程序的原安装包。

resources.arsc文件主要是建立对安装包所指向的应用程序的索引，在本实施例中也不在加壳安装包中使用原安装包的同名文件。

lib\目录下的文件，主要是存放.so动态库文件，该原安装包的动态库文件是否被一同集合到加壳安装包中，同理，可以结合程序实现复杂度加以考虑，按需选用。本实施例中不考虑将其移置于加壳安装包中。

Androidmanifest.xml文件，是安装包中较为重要的全局配置文件，其负责向系统注册Android系统的四大组件，以及向系统申请权限等。在加壳安装包中，将其作为需要加入加壳安装包的重要内部文件进行考虑，但是，作为本发明实现的关键，对该配置文件进行修改。修改的内容主要是因应加壳安装包的包名不同于目标应用程序的包名，故而，加壳安装包中的Androidmanifest.xml文件以原安装包的同名文件为蓝本，将其中涉及包名的字符串，修改成加壳安装包的包名。具体涉及有关四大组件(Activity,Service,Broacast Receiver,Content Provider)及相关动作(Action)的声明中对包名的引用处。本发明的推荐实施例中，是在原安装包的包名基础上附加前缀，例如，原安装包的包名是com.apk，则加壳安装包的包名可以是apphost.com.apk。诚然，本领域技术人员可以灵活改变这一改名规则，只要在程序运行过程中可以构造利用逆向规则将两个包名建立对应进而实现重定向即可。由此，加壳安装包在系统中安装运行宿主应用程序之后，以Androidmanifest.xml向系统注册各个组件和申请系统权限，以此便建立了各个组件的入口，使经反射调用的目标应用程序的各个组件均可以结合所述逆向规则而被ActivityManagerService调用，而不必为所述各个组件构造ActivityThread和提供相应的LoadedApk对象，省去运行上下文环境的程序实现环节。同理，反射调用所导致的PackageManagerService对各大组件进行是否合法注册的校验的问题，也将因Androidmanifest.xml的注册结合所述的逆向规则而被克服。

classes.dex为安装包中的代码文件(二进制代码可执行文件)。在本发明中，将被预构造的同名文件所替换，但该同名文件与其他文件一起被集合到所述加壳安装包中。本发明所提供的classes.dex，植入有加载模块stub()，通过该加载模块，可以进一步启动一监控模块，该监控模块用于监控经反射调用的整个目标应用程序的活动过程，因此，监控模块先于所述目标应用程序而加载。该监控模块便是沙箱运行环境的实现者，负责实现两方面的功能，一方面通过监控目标应用程序对资源的访问，这一资源包括原安装包res\、assets\的资源，也包括涉及包名调用的Intent，还包括系统资源等广义资源。通过对资源引用进行重定向，使目标应用程序进程能够实现对正确资源的正常引用。具体而言，如果相关资源是被反射调用的原安装包的资源，则通过反射调用机制调用该原安装包的资源供引用，实现重定向。如果是系统资源或者指向宿主应用程序的已安装资源，则可允许其默认引用保证其正常引用关系。如果是I/O操作，也可以藉此进行重定向。需要注意的是，当这种广义资源引用涉及宿主应用程序与目标应用程序之间的包名差异时，如前所述，应当利用所述的逆向规则来确保目标应用程序所引用的资源正确无误。另一方面通过监控目标应用程序对系统资源的访问，例如是否请求发送短信息，来依据安全策略确定是否允许其操作，当不允许这种实施这种行为是，可以向相关调用指令返回自定义数据，例如返回空值，从而确保能杜绝一些非法操作。所述监控模块的技术实现，采用Hook技术，利用钩子函数对相关调用指令的入口点进行监视，截获此一调用指令，转向执行相应的钩子函数，由该钩子函数依据沙箱自身逻辑来应答该调用指令，从而达到前述的目的。

这里需要补充的是：术语“钩子”涵盖了用于通过拦截在软件组件之间传递的函数调用、消息、或事件来改变或增加操作系统、应用程序、或其他软件组件的行为的技术。而处理这种被拦截的函数调用、事件或消息的代码就被称为钩子hook函数。钩子通常用于各种目标，包括对功能进行调试和对功能进行扩展。其示例可以包括在键盘或鼠标事件传递到应用程序之前拦截它们，或者拦截系统调用(system call)、或者系统函数行为、函数执行结果等，以监视或修改应用程序或其他组件的功能等等。本实施例即可采用钩子hook函数接管所述应用程序运行时所需的安装自校验操作。

准备好上述的内部文件和原安装包后，本发明进一步将上述选定的内部文件和原安装包进行打包，打包后再行签名，即完成所述加壳安装包的构造，原安装包位于加壳安装包的assets\目录中，成为加壳安装包的附带资源。进一步可通过下一安装单元安装该加壳安装包，从而安装宿主应用程序。

考虑到所生成的加壳安装包的文件将大于原安装包，本发明进而可以对加壳安装包中的代码文件进行压缩，生成压缩文件和用于还原所述压缩文件为代码文件的附加文件，这一压缩过程同理适用于所述原安装包中。只要后续安装过程中依据逆向算法，利用附加文件对所述压缩文件在内存中进行还原，即可使宿主应用程序和目标应用程序实现正常运行。经过压缩的安装包，其增量接近于零甚至小于零，因此效率较高。

所述的安装单元13，用于安装该加壳安装包。

如前所述，本发明的实施场景之一，未获Root权限，因此，这种场景中，并不能通过本发明实现静默安装。这种情况下，本发明优先通过调用系统安装器，以启动安装界面，指导用户完成该加壳安装包的安装。

安装该加壳安装包后，其中的Androidmanifest.xml中的文件便完成向系统的注册，宿主应用程序所使用的包名虽与目标应用程序的包名不同，但后续可通过利用所述逆向规则实现的程序克服，故宿主应用程序能够通过ActivityManagerService找到经反射调用而运行的目标应用程序的组件的入口，并且，目标应用程序的组件也能顺利通过系统PackageManagerService的查验，程序实现难度大减，而且应用程序的运行效率也将大大提高。

为体现本发明沙箱实例的第二方面，本发明进而提供一种应用程序免Root运行控制方法，该方法主要用于体现所述宿主应用程序的运行过程，以及其运行过程中对目标应用程序的加载运行过程。本领域技术人员应当知晓，依据沙箱实现原理，本发明的免Root运行控制方法用于控制本发明的加壳配置方法所构造的宿主应用程序与目标应用程序的运行，因此，本发明的免Root运行控制方法的具体实现细节中，当然需适应所述宿主应用程序的具体实例做适应性的匹配，因此，上述加壳配置方法所衍生的诸多变化实例，当然地导致该免Root运行控制方法的适应性调整，而这些调整手段也当然地为本领域技术人员所应熟知。

参阅图3，本发明的应用程序免Root运行控制方法，具体包括如下步骤：

S21、反射调用与宿主应用程序具有不同包名的作为宿主应用程序附带资源的安装包，以加载该安装包所实现的目标应用程序。

结合前述关于应用程序加壳配置方法的描述可知，宿主应用程序即指所述加壳安装包安装后的程序，而所述安装包即指存放于加壳安装包的assets\目录下的应用程序原安装包。安装后，宿主应用程序反射调用的目标应用程序的安装包，属于宿主应用程序的附带的已安装资源文件。反射调用该安装包，即意味着运行所述目标应用程序。

本发明所采用的反射机制可以为Java反射机制，Java反射机制是在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法；这种动态获取信息以及动态调用对象的方法的功能即为JAVA语言的反射机制。

在本发明推荐的一个实例中，所述宿主应用程序将首先找到其安装后的由其assets携带的安装包APK文件，然后通过一个代理组件(Activity)去执行APK中的Activity，从而实现对目标应用程序的反射调用。宿主应用程序实施反射调用首先需要通过类加载器来实现，具体是通过DexClassLoader()来实现。利用这一类加载器来实现对安装包中的活动组件的调用是本领域技术人员所掌握的手段，恕不赘述。程序实现时，可通过一个Proxy方法来让宿主应用程序接管目标应用程序的执行，一旦被接管以后，目标应用程序所有的执行均通过proxy实现，且Context也变成了宿主程序的Context。宿主应用程序其实就是个空壳，它只是把原安装包apk加载到自己的内部去执行。这种情况下，尽管宿主应用程序已经采用目标应用程序的Androidmanifest.xml向系统注册，由于运行上下文环境context可能不同，仍可能会导致出现资源访问上的困难，有时甚至会发现不能访问安装包中的资源的情况。而这种困难的程度，取决于前述应用程序加壳配置方法中，被构造到加壳应用程序中的资源的多寡，也关系到包名不同的问题。不管如何，本领域技术人员可以借助后续揭示的方式加以克服。

目标应用程序的运行将涉及到对资源的引用，这种引用的处理技巧虽为本领域技术人员所知晓，但也较为繁杂，因此本发明将尽量通过示例辅助本领域技术人员快速理解本发明所提供的若干实例。

诚然，如果目标应用程序要访问的资源已经被已安装的宿主应用程序注册到系统中，例如前文所述的主图标文件，则其对资源的引用将非常直接，通过对宿主应用程序的已安装资源的调用即可满足目标应用程序的资源访问。除此之外，则需要附加一些额外考虑。

如果由于构造加壳安装包导致宿主应用程序的Context不能被目标应用程序正常访问，可以考虑改进这一问题，向原安装包借用资源。由于目标应用程序安装包APK没有安装，因此就无法通过宿主应用程序的Context去取得APK中的资源，比如图片、文本等。APK在被加载运行时所采用的上下文是宿主应用程序的上下文，用别人的Context是无法得到自己的资源的。由此可知，宿主应用程序除了要能加载应用程序中的各组件外，还要为应用程序构造其所需的运行环境。

Android应用程序在运行的过程中，是通过一个称为AssetsManager资源管理器来读取打包在APK文件里面的资源文件的。应用程序的每一个Activity组件都关联一个ContextImpl对象，这个ContextImpl对象就是用来描述activity组件的运行上下文环境的。调用这个ContextImpl对象的成员函数init来执行初始化Activity组件运行上下文环境的工作，其中就包括创建用来访问应用程序资源的Resources对象和AssetsManager对象的工作。其中，ContextImpl.init函数就定义在文件frameworks/base/core/java/android/app/ContextImpl.java中。ContextImpl.init函数中的参数packageInfo指向的是一个loadedApk对象，这个loadedApk对象描述的是当前正在启动组件所属的Apk。用来访问应用程序资源的Resources对象是通过调用参数packageInfo所指向的是一个loadedApk对象的成员函数getResources来创建的。由此可知，为了创建Resources对象，以提取或访问应用程序资源，如果出于访问安装包Apk中的资源的需要，本实施例还可以分别为应用中的各组件构建一个loadedAPK对象。

同理，适应具体的加壳安装包的配置，根据需要，可以考虑对资源Resources类的构造函数中的成员变量mResource、mAssets进行修改，以在启动各所述组件时通过所述mResource、mAssets来调取相应的资源。

同理，也可考虑对资源管理器AssetsManager中的AssetsPath函数进行修改，修改后的所述AssetsPath函数指向所述目标应用程序安装包中的资源文件(通常指assets\)，以在启动各所述组件时通过所述AssetsManager调取所述AssetsPath函数来获取所述资源文件中的对应资源。

其中，Resources类的构造函数定义在文件frameworks/base/core/java/android/content/res/Resources.java中。因为Resources类的构造函数将参数assets所指向的一个AssetManager对象保存在成员变量mAssets中，即mAssets＝assets，使得Resources类的构造函数可以通过mAssets来访问应用程序的资源。因此，本实施例可通过对资源类的构造函数中的成员变量mAssets进行修改，来实现通过mAssets调取应用程序所需的资源。诚然，上述有关安装包中资源的访问的实现方式也采用反射机制来实现。

当然，本实施例还可对资源管理器AssetsManager中的AssetsPath函数进行修改，如通过AssetsManager对象的成员函数addAssetsPath来添加指定的应用程序资源文件路径(如：路径为/data/app/com.qihoo.box-1.apk)到AssetsPath函数中。由于addAssetsPath是隐藏API我们无法直接调用，所以只能通过反射机制来实现。

如前所述，还需要在加载模块中实现类加载器，以加载各所述组件中的相应加载类。可采用如下方式实现：一种方式是将所述应用程序的路径添加到类加载器中的路径列表pathList中，构造根据所述应用程序路径查找加载类的类加载器；另一种方式是对类加载器中的成员变量进行修改，构造首先用super找加载类的类加载器。由于利用类加载器动态加载应用程序的技术已为本领域技术人员所熟知，故此处仅给出示例性说明，恕不赘述。

在程序运行过程中，如前所述，需要考虑所述利用逆向规则来规避宿主应用程序与目标应用程序包名差异的问题。可以将逆向规则实现为一个供调度的函数，结合本发明所述的监控模块所实现的有关资源重定向的方面，对相关可能涉及包名引用的调用指令进行监控，当出现包名引用时，便可调度前述利用逆向规则实现的函数来修改所引用的包名，从而使两者建立一一对应关系，实现资源的正常引用。这里所称的调用的指令，也即监控模块利用钩子函数所挂钩的指令，包括诸如startActivity、startService、loadClass、sentBroacast、bindServer等。通常这些指令利用意图即Intent进行参数传递，而Intent中包含对包名的引用，这种情况下，钩子函数即发挥其作用，对包名进行修改，使这些调用指令能够调用到正确的资源。例如，目标应用程序要调用其自身的一个Activity,在Intent中包含活动组件com.apk.activty，通过startActivity来调用，钩子函数截获这一调用指令，然后利用所述逆向规则所实现的函数，将其包名进行修改，对应到已经注册的活动组件apphost.com.apk.activity，由此便可由宿主应用程序做进一步去反射调用目标应用程序的相应组件。诚然，尽管包名不同，宿主应用程序在反射调用时，其进行类加载时，也会遵守同一规则去调用正确的目标应用程序中的资源。

以上也顺便揭示了后续即将揭示的监控模块所实现的一方面功能，故而后续有关监控模块的功能实现的介绍将被简化。

S22、由宿主应用程序调用监控模块，对目标应用程序的活动进行监控。

作为一个沙箱实例，使目标应用程序运行于沙箱运行环境中，通常通过所述加载模块先于所述目标应用程序的反射调用而优先调用一监控模块。这一监控模块便是前文所称的监控模块。

如前所述，该监控模块便是沙箱运行环境的核心实现者，负责实现两方面的功能，一方面如前所述通过监控目标应用程序对资源的访问，对资源引用进行重定向，使目标应用程序进程能够实现对正确资源的正常引用。具体而言，如果相关资源是被反射调用的原安装包的资源，则通过反射调用机制调用该原安装包的资源供引用，实现重定向。如果是系统资源或者指向宿主应用程序的已安装资源，则可允许其默认引用保证其正常引用关系。如果是I/O操作，也可以藉此进行重定向。例如，上述有关对目标应用程序的安装包的资源进行的引用，既可以通过对上述的AssetsManager的修改来实现，也可以通过监控具体调用资源的具体调用指令，利用Hook技术来实现。另一方面通过监控目标应用程序对系统资源的访问，例如是否请求发送短信息，来依据安全策略确定是否允许其操作，当不允许这种实施这种行为时，可以向相关调用指令返回自定义数据，例如返回空值，从而确保能杜绝一些非法操作。所述监控模块被注册为服务进程，以钩子函数关联目标应用程序活动进程的调用指令以实现对所述目标应用程序的活动监控。所述监控模块利用钩子函数对相关调用指令的入口点进行监视，截获此一调用指令，转向执行相应的钩子函数，由该钩子函数依据沙箱自身逻辑来应答该调用指令，从而达到前述的目的。涉及到监控模块对于监视活动的处理，尤其是安全控制方面，将在后文中给出更为具体的实例进行说明。

S23、当监控到目标应用程序需要调用未匹配的资源时，重定向相关调用指令的资源引用，以为该目标应用程序的运行提供正确资源。

这里所称的未匹配的资源，参照前述，不应局限理解为构造于宿主应用程序加壳安装包中的res\和assets\的资源，应理解为包括这两个目录的资源在内的资源和系统资源，以及目标应用程序原安装包内部的包括res\、assets\在内的一切可能被进程调用的资源。尤其是对于目标应用程序原安装包中的资源，因为原安装包未被安装，当相关调用指令直接对其实施调用时，如果不加反射调用或者Hook处理，通常会被理解为错误访问。

所称重定向相关调用指令的资源引用，主要是指在目标应用程序进程运行过程中实现的重定向，包括在该进程运行过程中可能发生的借助钩子函数利用AssetsManager的成员变量而实现的对原安装包的资源重定向处理，包括在进程运行过程中可能发生的对所述原安装包中的资源的引用的直接给定数值的重定向，包括如前所揭示的涉及包名差异的调度上的重定向等。如果不加以这种干预，该安装包中的个别资源可能由于未经安装或因包名差异而会被误认为是所述进程的错误访问，包括在进程运行过程中可能发生的对通知栏服务(NotificationManager)和动画函数(OverridePendingTransition)的调用的屏蔽处理(利用钩子函数对其调用指令返回空值即可)，以及包括对未经授权(依据沙箱安全策略、规则等)资源的访问的调用指令的重定向处理(可以向其返回诸如空值、虚假数值之类的自定义数据)等。故而，这里所称的“重定向”，应为广义的理解，是指依据沙箱实现逻辑而归纳的一切确保进程正常运行的基于钩子函数实现的安全技术手段。

可以看出，借助本发明的应用程序免Root运行控制方法，可以通过宿主应用程序正常调用目标应用程序并确保目标应用程序的正常运行。

相应的，请参阅图4，本发明进一步提供一种装置辅以实现一种应用程序免Root运行控制装置，其包括调用单元21、监控模块22以及处理单元23。

所述的调用单元21，用于反射调用与宿主应用程序具有不同包名的作为宿主应用程序附带资源的安装包，以加载该安装包所实现的目标应用程序。

结合前述关于应用程序加壳配置方法的描述可知，宿主应用程序即指所述加壳安装包安装后的程序，而所述安装包即指存放于加壳安装包的assets\目录下的应用程序原安装包。安装后，宿主应用程序反射调用的目标应用程序的安装包，属于宿主应用程序的附带的已安装资源文件。反射调用该安装包，即意味着运行所述目标应用程序。

同理，本发明所采用的反射机制可以为Java反射机制，Java反射机制是在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法；这种动态获取信息以及动态调用对象的方法的功能即为JAVA语言的反射机制。

在本发明推荐的一个实例中，所述宿主应用程序将首先找到其安装后的由其assets携带的安装包APK文件，然后通过一个代理组件(Activity)去执行APK中的Activity，从而实现对目标应用程序的反射调用。宿主应用程序实施反射调用首先需要通过类加载器来实现，具体是通过DexClassLoader()来实现。利用这一类加载器来实现对活动组件的调用的技术为本领域技术人员所掌握，恕不赘述。程序实现时，可通过一个Proxy方法让宿主应用程序接管目标应用程序的执行，一旦被接管以后，目标应用程序所有的执行均通过proxy实现，且Context也变成了宿主程序的Context。宿主应用程序其实就是个空壳，它只是把原安装包apk加载到自己的内部去执行。这种情况下，尽管宿主应用程序已经采用目标应用程序的Androidmanifest.xml向系统注册，由于运行上下文环境context可能不同，仍可能会导致出现资源访问上的困难，有时甚至会发现不能访问安装包中的资源的情况。而这种困难的程度，取决于前述应用程序加壳配置方法中，被构造到加壳应用程序中的资源的多寡，也关系到包名不同的问题。不管如何，本领域技术人员可以借助后续揭示的方式加以克服。

目标应用程序的运行将涉及到对资源的引用，这种引用的处理技巧虽为本领域技术人员所知晓，但也较为繁杂，因此本发明将尽量通过示例辅助本领域技术人员快速理解本发明所提供的若干实例。

诚然，如果目标应用程序要访问的资源已经被已安装的宿主应用程序注册到系统中，例如前文所述的图标，则其对资源的引用将非常直接，通过对宿主应用程序的已安装资源的调用即可满足目标应用程序的资源访问。除此之外，则需要附加一些额外考虑。

如果由于构造加壳安装包导致宿主应用程序的Context不能被目标应用程序正常访问，可以考虑改进这一问题，向原安装包借用资源。由于目标应用程序安装包APK没有安装，因此就无法通过宿主应用程序的Context去取得APK中的资源，比如图片、文本等。APK在被加载运行时所采用的上下文是宿主应用程序的上下文，用别人的Context是无法得到自己的资源的。由此可知，宿主应用程序除了要能加载应用程序中的各组件外，还要为应用程序构造其所需的运行环境。

Android应用程序在运行的过程中，是通过一个称为AssetsManager资源管理器来读取打包在APK文件里面的资源文件的。应用程序的每一个Activity组件都关联一个ContextImpl对象，这个ContextImpl对象就是用来描述activity组件的运行上下文环境的。调用这个ContextImpl对象的成员函数init来执行初始化Activity组件运行上下文环境的工作，其中就包括创建用来访问应用程序资源的Resources对象和AssetsManager对象的工作。其中，ContextImpl.init函数就定义在文件frameworks/base/core/java/android/app/ContextImpl.java中。ContextImpl.init函数中的参数packageInfo指向的是一个loadedApk对象，这个loadedApk对象描述的是当前正在启动组件所属的Apk。用来访问应用程序资源的Resources对象是通过调用参数packageInfo所指向的是一个loadedApk对象的成员函数getResources来创建的。由此可知，为了创建Resources对象，以提取或访问应用程序资源，如果出于访问安装包Apk中的资源的需要，本实施例还可以分别为应用中的各组件构建一个loadedAPK对象。

同理，适应具体的加壳安装包的配置，根据需要，可以考虑对资源Resources类的构造函数中的成员变量mResource、mAssets进行修改，以在启动各所述组件时通过所述mResource、mAssets来调取相应的资源。

同理，也可考虑对资源管理器AssetsManager中的AssetsPath函数进行修改，修改后的所述AssetsPath函数指向所述目标应用程序安装包中的资源文件(通常指assets\)，以在启动各所述组件时通过所述AssetsManager调取所述AssetsPath函数来获取所述资源文件中的对应资源。

其中，Resources类的构造函数定义在文件frameworks/base/core/java/android/content/res/Resources.java中。因为Resources类的构造函数将参数assets所指向的一个AssetManager对象保存在成员变量mAssets中，即mAssets＝assets，使得Resources类的构造函数可以通过mAssets来访问应用程序的资源。因此，本实施例可通过对资源类的构造函数中的成员变量mAssets进行修改，来实现通过mAssets调取应用程序所需的资源。诚然，上述有关安装包中资源的访问的实现方式也采用反射机制来实现。

当然，本实施例还可对资源管理器AssetsManager中的AssetsPath函数进行修改，如通过AssetsManager对象的成员函数addAssetsPath来添加指定的应用程序资源文件路径(如：路径为/data/app/com.qihoo.box-1.apk)到AssetsPath函数中。由于addAssetsPath是隐藏API我们无法直接调用，所以只能通过反射机制来实现。

如前所述，还需要在加载模块中实现类加载器，以加载各所述组件中的相应加载类。可采用如下方式实现：一种方式是将所述应用程序的路径添加到类加载器中的路径列表pathList中，构造根据所述应用程序路径查找加载类的类加载器；另一种方式是对类加载器中的成员变量进行修改，构造首先用super找加载类的类加载器。由于利用类加载器动态加载应用程序的技术已为本领域技术人员所熟知，故此处仅给出示例性说明，恕不赘述。

在程序运行过程中，如前所述，需要考虑所述利用逆向规则来规避宿主应用程序与目标应用程序包名差异的问题。可以将逆向规则实现为一个供调度的函数，结合本发明所述的监控模块所实现的有关资源重定向的方面，对相关可能涉及包名引用的调用指令进行监控，当出现包名引用时，便可调度前述利用逆向规则实现的函数来修改所引用的包名，从而使两者建立一一对应关系，实现资源的正常引用。这里所称的调用的指令，也即监控模块利用钩子函数所挂钩的指令，包括诸如startActivity、startService、loadClass、sentBroacast、bindServer等。通常这些指令利用意图即Intent进行参数传递，而Intent中包含对包名的引用，这种情况下，钩子函数即发挥其作用，对包名进行修改，使这些调用指令能够调用到正确的资源。例如，目标应用程序要调用其自身的一个Activity,在Intent中包含活动组件com.apk.activty，通过startActivity来调用，钩子函数截获这一调用指令，然后利用所述逆向规则所实现的函数，将其包名进行修改，对应到已经注册的活动组件apphost.com.apk.activity，由此便可由宿主应用程序做进一步去反射调用目标应用程序的相应组件。诚然，尽管包名不同，宿主应用程序在反射调用时，其进行类加载时，也会遵守同一规则去调用正确的目标应用程序中的资源。

以上也顺便揭示了后续即将揭示的监控模块所实现的一方面功能，故而后续有关监控模块的功能实现的介绍将被简化。

所述的监控模块22，被配置为由宿主应用程序加载，对目标应用程序的活动进行监控。

作为一个沙箱实例，使目标应用程序运行于沙箱运行环境中，通常通过所述加载模块先于所述目标应用程序的反射调用而优先调用一监控模块22。这一监控模块22便是前文所称的监控模块22。

如前所述，该监控模块22便是沙箱运行环境的核心实现者，负责实现两方面的功能，一方面如前所述通过监控目标应用程序对资源的访问，对资源引用进行重定向，使目标应用程序进程能够实现对正确资源的正常引用。具体而言，如果相关资源是被反射调用的原安装包的资源，则通过反射调用机制调用该原安装包的资源供引用，实现重定向。如果是系统资源或者指向宿主应用程序的已安装资源，则可允许其默认引用保证其正常引用关系。如果是I/O操作，也可以藉此进行重定向。例如，上述有关对目标应用程序的安装包的资源进行的引用，既可以通过对上述的AssetsManager的修改来实现，也可以通过监控具体调用资源的具体调用指令，利用Hook技术来实现。另一方面通过监控目标应用程序对系统资源的访问，例如是否请求发送短信息，来依据安全策略确定是否允许其操作，当不允许这种实施这种行为时，可以向相关调用指令返回自定义数据，例如返回空值，从而确保能杜绝一些非法操作。所述监控模块22被注册为服务进程，以钩子函数关联目标应用程序活动进程的调用指令以实现对所述目标应用程序的活动监控。所述监控模块22利用钩子函数对相关调用指令的入口点进行监视，截获此一调用指令，转向执行相应的钩子函数，由该钩子函数依据沙箱自身逻辑来应答该调用指令，从而达到前述的目的。涉及到监控模块22对于监视活动的处理，尤其是安全控制方面，将在后文中给出更为具体的实例进行说明。

所述的处理单元23，被配置为当监控到目标应用程序需要调用未匹配的资源时，重定向相关调用指令的资源引用，以为该目标应用程序的运行提供正确资源。

这里所称的未匹配的资源，参照前述，不应局限理解为构造于宿主应用程序加壳安装包中的res\和assets\的资源，应理解为包括这两个目录的资源在内的资源和系统资源，以及目标应用程序原安装包内部的包括res\、assets\在内的一切可能被进程调用的资源。尤其是对于目标应用程序原安装包中的资源，因为原安装包未被安装，当相关调用指令直接对其实施调用时，如果不加反射调用或者Hook处理，通常会被理解为是错误访问。

所称重定向相关调用指令的资源引用，主要是指在目标应用程序进程运行过程中实现的重定向，包括在该进程运行过程中可能发生的借助钩子函数利用AssetsManager的成员变量而实现的对原安装包的资源重定向处理，包括在进程运行过程中可能发生的对所述原安装包中的资源的引用的直接给定数值的重定向，包括如前所揭示的涉及包名差异的调度上的重定向等。如果不加以这种干预，该安装包中的个别资源可能由于未经安装或因包名差异而会被误认为是所述进程的错误访问，包括在进程运行过程中可能发生的对通知栏服务(NotificationManager)和动画函数(OverridePendingTransition)的调用的屏蔽处理(利用钩子函数对其调用指令返回空值即可)，以及包括对未经授权(依据沙箱安全策略、规则等)资源的访问的调用指令的重定向处理(可以向其返回诸如空值、虚假数值之类的自定义数据)等。故而，这里所称的“重定向”，应为广义的理解，是指依据沙箱实现逻辑而归纳的一切确保进程正常运行的基于钩子函数实现的安全技术手段。

利用本发明的监控模块22，可以实现更为强大的沙箱运行环境的构建。以下结合一具体实例，来进一步补充对本发明中的监控单元的说明。

所述监控模块22可以从一后台沙箱HOOK框架中获取对应于特定的事件行为的挂钩插件(钩子函数)，利用该挂钩插件挂钩并监控目标应用的特定事件行为从而实现对目标应用程序进程的活动的监控。所述的后台沙箱HOOK框架，在云端进行集中管理，向各终端进行分发。其中，云端主要构造有Java挂钩插件库和Native挂钩插件库。监控模块22需要挂钩具体事件行为时，通过远程插件接口向后台沙箱HOOK框架发送请求，获得针对特定事件行为的HOOK函数，即所述的挂钩插件，借此建立对特定事件行为的监控捕获和处理。

进而，运行中的宿主应用程序将进一步加载所述位于指定目录中的目标应用。如前所述，对目标应用程序的调用，是利用公知的Java反射调用机制实现的。目标应用程序被加载时，已被监控模块22利用挂钩插件建立了监控，因此，目标应用程序的一切事件行为均在监控模块22的监控范围之内。目标应用程序的安装包是完整未经修改的，因此，目标应用程序被宿主应用程序加载后，能够完全合法、正常地运行，实现目标应用程序原本能实现的所有功能。

由于监控模块22与目标应用程序的加载，均为宿主应用程序进程所驱动，同为宿主应用程序进程的一部分，且监控模块22先于目标应用程序加载，因而，运行中的监控模块22即建立了对目标应用程序一切事件行为的监控。目标应用程序运行过程中产生的任何事件行为，其事件消息均会被监控模块22捕获并进行相应的处理。

目标应用程序产生的特定事件行为被监控模块22捕获，实质上是触发特定事件行为时，所产生的事件消息被监控模块22中相应的挂钩插件(钩子函数)所捕获。捕获该事件消息，即可知晓该事件的意图，继而可以进行后续的处理。

对特定事件行为进行处理由所述处理单元23实施，需要获取事件行为处理策略。在这一子步骤中，可以进一步借助系统服务来实现人机交互功能。为了实现人机交互效果，本发明预先将一交互模块注册为系统服务，宿主应用程序可以通过其交互接口与该交互模块通信，从而实现宿主应用程序对用户指令或预设指令的获取。

如前所述，事件行为策略的获取方式非常灵活多样，通过构造一策略生成装置来执行，以下列举几种为本发明所择一或任意组合使用的策略：

(1)监控模块22捕获特定事件行为后，通过宿主应用程序内建的交互接口，向所述交互模块发送请求，由交互模块向用户界面弹窗问询用户处理策略，该弹窗界面可以直接告知用户有关事件行为的内容及其风险，由用户选择相应的选项作为处理策略。用户选择相应选项并确定后，交互模块获得针对该特定事件行为的处理策略，将其反馈给监控模块22，监控模块22即可根据该用户指令所产生的处理策略对目标应用程序的相应事件行为进行下一步的处理。

(2)在某些已被公认为相对低风险的事件行为发生时，例如对联系人的只读操作行为，或者在用户为本发明设置了自行检索针对特定事件行为所应采取的处理策略时，本发明利用一本地策略数据库检索相应的针对特定事件行为的处理策略。也就是说，该本地策略数据库中，建立了特定事件行为与相应的处理策略之间的关联，并且存储了多种事件行为与相应的处理策略之间对应关系的记录数据，可以供本发明检索使用。本发明从本地策略数据库中获取相应的处理策略后，方能对相应事件行为做下一步的处理。

(3)如果用户为本发明设置了远程获取处理策略的选项，或者默认在本地策略数据库检索不到特定事件行为的具体策略时可以远程获取，又或通过前述第(1)种情况进行交互而在规定时限内得不到用户对弹窗的响应，诸如此类的情况，宿主应用程序均可通过其内建的远程策略接口，向预架构的云端发送请求，获得对应于该特定事件行为的相应的处理策略，并用于后续的处理。

需要指出的是，有关以上三种获取处理策略的方式，可以交叉配合使用，例如，一旦交互模块接收到监控模块22传递的事件消息的特征，即可依照默认设置，参照第(2)种方式先行检索本地策略数据库，获得系统推荐的处理策略(如果不能从本地策略数据库中获得，甚至可以进一步按第(3)种方式从云端策略数据库中获取)。继而，参照第(1)种方式，在弹窗界面设置系统推荐的处理策略为默认选项。如果用户未在规定时限内确认该默认选项，则以系统推荐的处理策略为准执行后续指令；如果用户将之改变为新的默认选项，则向监控模块22返回用户设置的处理策略。可见，人机交互过程是可以更为灵活自由地实现的。

所述的本地策略数据库，可以是云端策略数据库的一个复件，因此，本发明中，设置一个更新步骤，用于下载云端策略数据库用于更新本地策略数据库。

一般情况下，针对特定事件行为的策略可以设置为“拒绝”、“运行”、“询问”三个常见选项，其表征的具体意向为：

拒绝：针对该特定事件行为，向目标应用程序发送事件行为已经执行完毕的虚假消息，以禁止该事件行为实际发生；

运行：针对该特定事件行为不做任何改变，将相应的事件消息直接转送给系统消息机制，允许目标应用程序继续其事件行为；

询问：独立或依附于前述两个选项任意之一，针对该特定事件行为，标记其状态为未知状态，后续重复发生该行为时，需要再行弹窗询问用户。

实际应用中，选项“询问”可被忽略，仅需考虑是否拒绝或允许当前事件行为发生即可。

所述的事件行为，多种多样，具体包括如下几大类型：

(1)终端、联网有关的操作：

获取运营商信息：目标应用程序例如通过getSimOperatorName()函数可以获得移动终端的IMSI，由此可进一步判断运营商的名称，进一步可以向运营商发送约定指令，实现扣费之类的非法目的。监控平台通过挂钩与此相关的消息，便可以对事件行为的捕获。

切换APN操作：同理，目标应用程序通过与APN切换有关的函数实现ANP切换控制的操作，也可被监控模块22通过调用相应的挂钩插件进行监控。

类似的操作，还包括获取手机识别码IME的操作，也与上述同理。

(2)通知栏广告操作：通知栏广告是最易被恶意程序利用的手段，监控模块22通过调用相应的挂钩插件对notify函数产生的事件消息进行监控，也可对其实施监控。

(3)通信操作：

如电话拔打操作，通过startActivity()函数可以监控调用系统拨号界面的事件行为，利用相应的挂钩插件可以对拔打电话操作建立事件行为监控。

短信操作，对应于sendTextMessage()之类的函数，同理，可以借助挂钩插件对这类函数建立事件行为监控。

联系人操作：一般对应于query()、insert()函数，监控模块22利用挂钩插件挂钩此类函数可以实现对此类事件行为的监控捕获。

(4)命令操作：

如SU提权操作或执行命令操作，均需用到Execve()函数，监控模块22通过监控此函数的返回消息，便可实现该类事件行为的监控。

(5)界面及访问操作：

如创造快捷方式的事件行为，则对应于sentBroacast()函数。同理，对于隐藏程序图标的操作，也可对应特定函数监控之。

如HTTP网络访问操作，则对应于sentTo()、write()等函数。

(6)程序操作：

如应用加载操作，指当前目标应用程序加载相关应用的操作，通过对dexClassloader()、loadLibrary()等函数进行挂钩监控，可以实现对此类事件行为的捕获。

又如安装子包，则对应于installPackage()函数。

(7)其它危险操作：

例如，子进程侵入操作、衍生物操作、激活设备管理器操作等，分别对应于。

其中，子进程是指目标应用程序建立的子进程，在目标应用程序创建子进程时，监控模块22将收到相应的消息，而判定其创建子进程的事件行为。由此，监控模块22进一步向该子进程以内联钩子的方式在该子进程中植入监控模块22，后续便可继续对该子进程的事件行为进行监控。因而，无论是目标应用程序的自身进程，还是其创建的子进程，它们直接或间接所触发的事件行为，均能被本发明的监控模块22所监控，实现较佳的主动防御效果更佳。

而所述衍生物，是指目标应用程序自行创建的文件，或者远程下载的文件，通常是指敏感的衍生物，例如安装包。通过挂钩fClose()函数可以捕获该事件。需要指出的是，当监控模块22捕获该事件行为后，可以按照前述的方法，进一步利用远程规则库接口发送请求到云端，由云端利用其黑、白、灰的安全等级行为规则判断该衍生物的安全等级，本发明通过远程规则库接口获得云端判定结果后，进一步弹窗询问用户是否建立对该敏感衍生物的主动防御，由此便可进一步巩固主动防御的效果。

上述的事件行为仅为摘录之用，不能理解为对本发明监控的事件行为的限制。

依据上述的处理策略和上述关于事件行为的说明，本发明的主动防御方法便可对各种事件行为进行相应的处理。以下列举几种典型的应用实例：

(1)对目标应用程序的精细拦截的应用：

部分恶意程序被安装后，在相当长的一段时间内处于正常使用的状态，麻痹用户的安全意识。但是，运行一段长时间之后，该目标应用程序尝试从后台插入一短信引起用户的关注，达到广告和诈骗的效果。对该目标应用程序建立主动防御机制后，本发明如前所述，通过监控模块22中相应的挂钩插件对短信操作函数的监控，一旦目标应用程序产生短信操作的事件行为，便可捕获这一事件行为，继而，监控模块22通过其交互接口通知作为系统服务运行的交互模块，由交互模块向用户界面弹窗示警。用户点选“拒绝”的处理策略后，被逆反馈给监控模块22，其中相应的挂钩插件便能阻该事件行为的实际发生，达到防范风险的目的。

(2)对目标应用程序释放恶意文件的应用。

目标应用程序为一游戏软件，通过检查更新的方式下载并释放恶意子包，并且调用系统功能安装该子包。本发明对该目标应用程序建立了主动防御的沙箱运行环境之后，可以监控到其下载完文件而产生的事件行为，据此通过交互模块弹窗告警。用户指令拒绝之后，监控模块22中相应的挂钩插件便可直接删除该文件，或者仅仅拒绝该文件的安装行为。

本发明中，对于诸如此类的恶意子包，视为敏感衍生物，对衍生物是否存在恶意的判断，可以通过利用预先确定的安全等级进行远程判断。具体而言，当检测到产生衍生物时，将相应的文件或者其签名之类的特征信息通过远程规则库接口发送给云端，并从云端获得其安全等级，如果为黑、灰应用，则在弹窗中建议用户拒绝安装；如果为白应用，则可允许其通行。通过这种方法，便可实现对敏感衍生物的安全防御。如果云端检测不到该衍生物的相关记录，可以要求本方法为其上传该文件，并由云端标示为未知应用，相应的，以灰应用予以标记，以备后用。

(3)对子进程侵入的应用。

被监控的目标应用程序在运行过程中创建子进程，而子进程进一步释放恶意事件行为。监控模块22监控到目标应用程序创建子进程时，即获得子进程的入口，然后向该子进程植入本发明的监控模块22，所有HOOK插件(挂钩插件)都会被以内联钩子的方式加载到该子进程中并初始化好实现挂钩，以便建立对该子进程的事件行为的监控。由此，可以看出，无论是由目标应用程序进程直接触发的事件行为，还是由目标应用程序进程所创建的子进程所触发的间接事件行为，均能被监控模块22成功监控。

由上述的分析可见，本发明的应用程序免Root运行控制方法及其相应的装置所建构的沙箱运行环境，具有高效的可行性。

为便于本领域技术人员进一步实现本发明，以下进一步揭示云端服务器与终端设备如何相互配合实现安装包安全等级判断的相关内容：

如前所述，由客户端通过远程规则库接口发送到云端服务器的特征信息，包括：Android安装包的包名，和/或，版本号，和/或，数字签名，和/或，Android组件receiver的特征，和/或，Android组件service的特征，和/或，Android组件activity的特征，和/或，可执行文件中的指令或字符串，和/或，Android安装包目录下各文件的MD5值(签名)。

实现了本发明的方法或装置的客户端，将指定的特征信息上传到服务器(云端)，在服务器预置的规则库中查找与指定的单个特征信息或其组合相匹配的特征记录；其中，所述服务器预置的规则库中包含特征记录及特征记录对应的安全级别，每条特征记录中包含单个特征信息或特征信息的组合；

服务器端规则库中预置了数千条特征记录，其中，第一条特征记录中列出了某种病毒的Android安装包包名，第二条特征记录中列出了某个正常应用的Android安装包版本号及其数字签名的MD5值，第三条特征记录中列出了某个正常应用的Android安装包包名及其receiver特征，第四条特征记录中列出了某种木马的Android安装包包名、版本号及其ELF文件中的特定字符串，等等。

关于安全等级的标识，即黑，白(安全)或者灰(未知，可疑)三种标识，可以进一步地表示为：

安全：该应用是一个正常的应用，没有任何威胁用户手机安全的行为；

危险：该应用存在安全风险，有可能该应用本身就是恶意软件；也有可能该应用本来是正规公司发布的正常软件，但是因为存在安全漏洞，导致用户的隐私、手机安全受到威胁；

谨慎：该应用是一个正常的应用，但是存在一些问题，例如会让用户不小心被扣费，或者有不友好的广告遭到投诉等；当发现这类应用之后，会提示用户谨慎使用并告知该应用可能的行为，但是由用户自行决定是否清除该应用；

木马：该应用是病毒、木马或者其他恶意软件，此处为了简单统称为木马，但并不表示该应用仅仅是木马。

应当理解，云端与客户端之间的配合，可以由本领域技术人员根据本发明所揭示的内容进一步扩充、变换、增删而改善。因而，以上揭示的内容不应理解为实现本发明的方法和装置的限制。

经过测试，本发明相对于现有技术有了较宽广的应用范围和应用效果，以下略加阐述：

由于本发明已经将HOOK框架做成了服务平台，以挂钩插件的方式为终端配置监控模块22，因此，其加载仅需依赖于相应的配置文件，管理高效且易于实现，对技术人员而言，一些简单的函数调用仅需编写配置文件即可实现挂钩插件的配置，HOOK重入、并发性能高。

采用宿主应用程序先后实现对监控模块22和目标应用程序的加载，继而借助监控模块22对目标应用程序的事件行为建立监控，可以实现对Java函数、Native函数的挂钩。

综上所述，本发明使得目标应用程序能够运行于沙箱运行环境中，并且能确保系统的安全。

以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

简要地，本发明的实施例公开了：

A1.一种应用程序加壳配置方法，包括以下步骤：解析所述应用程序原安装包，获得其内部文件；构造集合所述原安装包与所述内部文件的加壳安装包，使加壳安装包与原安装包具有不同的包名，所述被集合的内部文件中配置有加载模块，该加载模块，用于将被集合的原安装包加载到沙箱运行环境中以运行所述应用程序；安装该加壳安装包。

A2、根据A1所述的应用程序加壳配置方法，其特征在于，加壳安装包的包名，由所述原安装包的包名附加前缀构成。

A3、根据A2所述的应用程序加壳配置方法，其特征在于，所述内部文件之一为被集合的原安装包的配置文件的副本，该副本中涉及组件和动作名称处均被附加所述的前缀，所述配置文件的副本特指Androidmanifest.xml文件。

A4、根据A1所述的应用程序加壳配置方法，其特征在于，所述加载模块设置于内部文件之一的代码文件中，该加载模块被配置为采用反射调用机制加载所述被集合的原安装包以运行所述应用程序。

A5、根据A4所述的应用程序加壳配置方法，其特征在于，所述代码文件特指classes.dex文件。

A6、根据A1至5中任意一项所述的应用程序加壳配置方法，其特征在于，所述内部文件包括被集合的自原安装包获得的资源文件和/或动态库文件及其相应的目录结构。

A7、根据A6所述的应用程序加壳配置方法，其特征在于，所述资源文件特指Res目录及其下所包含的文件，所述动态库文件特指Lib目录及其下所包含的文件。

A8、根据A6所述的应用程序加壳配置方法，其特征在于，所述资源文件包括图标文件，且该图标文件基于被集合的自原安装包获得的相应图标文件进行局部修改所得。

A9、根据A1至5中任意一项所述的应用程序加壳配置方法，其特征在于，所述被集合的原安装包被置于加壳安装包的Assets目录中。

A10、根据A1至5中任意一项所述的应用程序加壳配置方法，其特征在于，所述加载模块被配置为引导沙箱运行环境对所述应用程序的运行进程实施安全监控，以实现该应用程序在沙箱运行环境中的正常运行。

另外，本发明的实施例还公开了：

B11.一种应用程序加壳配置装置，其特征在于，包括：获取单元，用于解析所述应用程序原安装包，获得其内部文件；构造单元，用于构造集合所述原安装包与所述内部文件的加壳安装包，使加壳安装包与原安装包具有不同的包名，所述被集合的内部文件中配置有加载模块，该加载模块，用于将被集合的原安装包加载到沙箱运行环境中以运行所述应用程序；安装单元，用于安装该加壳安装包。

B12、根据B11所述的应用程序加壳配置装置，其特征在于，加壳安装包的包名，由所述原安装包的包名附加前缀构成。

B13、根据B12所述的应用程序加壳配置装置，其特征在于，所述内部文件之一为被集合的原安装包的配置文件的副本，该副本中涉及组件和动作名称处均被附加所述的前缀，所述配置文件的副本特指Androidmanifest.xml文件。

B14、根据B11所述的应用程序加壳配置装置，其特征在于，所述加载模块设置于内部文件之一的代码文件中，该加载模块被配置为采用反射调用机制加载所述被集合的原安装包以运行所述应用程序。

B15、根据B14所述的应用程序加壳配置装置，其特征在于，所述代码文件特指classes.dex文件。

B16、根据B11至15中任意一项所述的应用程序加壳配置装置，其特征在于，所述内部文件包括被集合的自原安装包获得的资源文件和/或动态库文件及其相应的目录结构。

B17、根据B16所述的应用程序加壳配置装置，其特征在于，所述资源文件特指Res目录及其下所包含的文件，所述动态库文件特指Lib目录及其下所包含的文件。

B18、根据B16所述的应用程序加壳配置装置，其特征在于，所述资源文件包括图标文件，且该图标文件基于被集合的自原安装包获得的相应图标文件进行局部修改所得。

B19、根据B11至15中任意一项所述的应用程序加壳配置装置，其特征在于，所述被集合的原安装包被置于加壳安装包的Assets目录中。

B20、根据B11至15中任意一项所述的应用程序加壳配置装置，其特征在于，所述加载模块被配置为引导沙箱运行环境对所述应用程序的运行进程实施安全监控，以实现该应用程序在沙箱运行环境中的正常运行。

Claims (10)

1.一种应用程序加壳配置方法，其特征在于，包括以下步骤：

解析所述应用程序原安装包，获得其内部文件；

构造集合所述原安装包与所述内部文件的加壳安装包，使加壳安装包与原安装包具有不同的包名，所述被集合的内部文件中配置有加载模块，该加载模块，用于将被集合的原安装包加载到沙箱运行环境中以运行所述应用程序；

安装该加壳安装包。

2.根据权利要求1所述的应用程序加壳配置方法，其特征在于，加壳安装包的包名，由所述原安装包的包名附加前缀构成。

3.根据权利要求2所述的应用程序加壳配置方法，其特征在于，所述内部文件之一为被集合的原安装包的配置文件的副本，该副本中涉及组件和动作名称处均被附加所述的前缀，所述配置文件的副本特指Androidmanifest.xml文件。

4.根据权利要求1所述的应用程序加壳配置方法，其特征在于，所述加载模块设置于内部文件之一的代码文件中，该加载模块被配置为采用反射调用机制加载所述被集合的原安装包以运行所述应用程序。

5.根据权利要求4所述的应用程序加壳配置方法，其特征在于，所述代码文件特指classes.dex文件。

6.根据权利要求1至5中任意一项所述的应用程序加壳配置方法，其特征在于，所述内部文件包括被集合的自原安装包获得的资源文件和/或动态库文件及其相应的目录结构。

7.根据权利要求6所述的应用程序加壳配置方法，其特征在于，所述资源文件特指Res目录及其下所包含的文件，所述动态库文件特指Lib目录及其下所包含的文件。

8.根据权利要求6所述的应用程序加壳配置方法，其特征在于，所述资源文件包括图标文件，且该图标文件基于被集合的自原安装包获得的相应图标文件进行局部修改所得。

9.根据权利要求1至5中任意一项所述的应用程序加壳配置方法，其特征在于，所述被集合的原安装包被置于加壳安装包的Assets目录中。

10.一种应用程序加壳配置装置，其特征在于，包括：

获取单元，用于解析所述应用程序原安装包，获得其内部文件；

构造单元，用于构造集合所述原安装包与所述内部文件的加壳安装包，使加壳安装包与原安装包具有不同的包名，所述被集合的内部文件中配置有加载模块，该加载模块，用于将被集合的原安装包加载到沙箱运行环境中以运行所述应用程序；

安装单元，用于安装该加壳安装包。