软件安装包的加固保护方法和装置

1.一种软件安装包的加固保护方法，包括：
提取软件安装包中的全局配置文件和可执行文件，其中，所述软件安装包为安卓软件安装包，所述全局配置文件为manifest文件，所述可执行文件为dex文件；
解析所述可执行文件，得到第一代码；
将保护代码插入所述第一代码中得到第二代码，并对所述第二代码进行加密处理，完成对所述dex文件的加密，从而得到修改后的可执行文件；
按照所述保护代码的入口点修改所述全局配置文件；
将修改后的全局配置文件和所述修改后的可执行文件重新打包生成加固安装包；以及对所述加固安装包进行签名。
2.根据权利要求1所述的方法，其中，
所述保护代码包括对所述可执行文件进行加壳和解壳的代码。
3.根据权利要求2所述的方法，其中，
所述保护代码还包括解壳触发代码和和反编译工具的崩溃代码；
将保护代码插入所述第一代码中得到第二代码包括：
在所述第一代码中的每一类的代码中置入解壳触发代码和反编译工具的崩溃代码，所述解壳触发代码被执行时，调用所述解壳的代码对该类进行解密。
4.根据权利要求1至3中任一项所述的方法，其中，对所述第二代码进行加密处理包括：
抽取所述第二代码的至少一部分进行重构；
植入用于解密所述重构的代码的链接库，所述链接库在解密过程中由java本地接口加载。
5.根据权利要求1至3中任一项所述的方法，其中，按照所述保护代码的入口点修改所述全局配置文件包括：
检查所述全局配置文件是否配置有应用节点标签；
若是，按照所述保护代码的入口点修改所述应用节点标签；
若否，新建应用节点标签，并按照所述保护代码的入口点配置新建的应用节点标签。
6.根据权利要求1至3中任一项所述的方法，其中，在提取软件安装包中的全局配置文件和可执行文件之前还包括：
接收由用户上传的所述软件安装包和设置的加固参数。
7.根据权利要求1至3中任一项所述的方法，其中，对所述加固安装包进行签名包括：
下发所述加固安装包，由用户使用其身份标识对所述加固安装包进行签名；或者利用用户上传的身份标识对所述加固安装包进行签名。
8.一种软件安装包的加固保护装置，包括：
文件提取模块，配置为提取软件安装包中的全局配置文件和可执行文件，其中，所述软件安装包为安卓软件安装包，所述全局配置文件为manifest文件，所述可执行文件为dex文件；
解析模块，配置为解析所述可执行文件，得到第一代码；
加密模块，配置为将保护代码插入所述第一代码中得到第二代码，并对所述第二代码进行加密处理，完成对所述dex文件的加密，从而得到修改后的可执行文件；
配置模块，配置为按照所述保护代码的入口点修改所述全局配置文件；
打包模块，配置为将修改后的全局配置文件和所述修改后的可执行文件重新打包生成加固安装包；以及
签名模块，配置为对所述加固安装包进行签名。
9.根据权利要求8所述的装置，其中，所述加密模块还被配置为：
在所述第一代码中的每一类的代码中置入解壳触发代码和和反编译工具的崩溃代码；
抽取所述第二代码的至少一部分进行重构；
植入用于解密述重构的代码的链接库，所述链接库在解密过程中由java本地接口加载。
10.根据权利要求8或9所述的装置，其中，所述配置模块还配置为：
检查所述全局配置文件是否配置有应用节点标签；
若是，按照所述保护代码的入口点修改所述应用节点标签；
若否，新建应用节点标签，并按照所述保护代码的入口点配置新建的应用节点标签。
11.根据权利要求8或9所述的装置，还包括：
获取模块，配置为接收由用户上传的所述软件安装包和设置的加固参数。

软件安装包的加固保护方法和装置\n技术领域\n[0001] 本发明涉及数据安全领域，特别是涉及一种软件安装包的加固保护方法和装置。\n背景技术\n[0002] 安卓(Android)平台发展迅速，已经逐渐成为了移动终端的最普及的操作系统，同时基于其中的软件应用数目也十分巨大，与其他移动终端操作系统相比，安卓系统为应用开发者提供了更多的功能接口，其中很多系统底层接口，提高了系统的可扩展性，但同时也为恶意软件提供了便利，针对安卓系统的木马等恶意软件也更容易被实现，目前已有的针对安卓系统的恶意软件可以通过伪装的方式，骗取用户安装并授予一定的权限，之后滥用这些权限在后台执行一些特定行为，包括窃取用户隐私骗取资费等行为。然而与之并生的安全问题却始终没有得到良好的解决，安全威胁越来越多，且威胁程度也在逐步加深，无论对开发者还是用户都带来了不良的影响。\n[0003] 而且对于一些正常的安卓系统应用，也存在通过非法拷贝、逆向工程、反编译、调试、破解、二次打包、内存截取等手段来威胁安卓系统的安全，不仅危害了使用用户，也给正常应用开发者造成严重的损害。\n[0004] 基于以上问题，现有技术中出现了多种安卓应用的安全加固方法，通过对安卓应用进行加密、防反编译、防代码混淆等加固措施，然而由于加固方法所采用的方案不同，加固的效果也不同，有些加固后并不能达到防止暴力破解的效果，例如现有的一种加固方法首先加密原程序包的可执行文件dex，然后在提取四大组件信息生成代理的dex文件，程序执行时动态解密原程序dex，然而这样的加密方式，加密包和原包分离，原包仅为加密文件，可以轻易地通过内存转存实现程序的破解，加固效果有限。\n发明内容\n[0005] 鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的软件安装包的加固保护装置和相应的软件安装包的加固保护方法。\n[0006] 本发明一个进一步的目的是要提高软件安装包的加固效果，防止内存分割。\n[0007] 本发明另一个进一步的目的是要提高加固后软件安装包的兼容性和可靠性。\n[0008] 依据本发明的一个方面，提供了一种软件安装包的加固保护方法。该软件安装包的加固保护方法包括：提取软件安装包中的全局配置文件和可执行文件；解析可执行文件，得到第一代码；将保护代码插入第一代码中得到第二代码，并对第二代码进行加密处理；按照保护代码的入口点修改全局配置文件；将修改后的全局配置文件和可执行文件重新打包生成加固安装包。\n[0009] 可选地，保护代码包括对可执行文件进行加壳和解壳的代码。\n[0010] 可选地，保护代码还包括解壳触发代码和和反编译工具的崩溃代码；将保护代码插入第一代码中得到第二代码包括：在第一代码中的每一类的代码中置入解壳触发代码和反编译工具的崩溃代码，解壳触发代码被执行时，调用解壳的代码对该类进行解密。\n[0011] 可选地，对第二代码进行加密处理包括：抽取第二代码的至少一部分进行重构；植入用于解密重构的代码的链接库，链接库在解密过程中由java本地接口加载。\n[0012] 可选地，按照保护代码的入口点修改全局配置文件包括：检查全局配置文件是否配置有应用节点标签；若是，按照保护代码的入口点修改应用节点标签；若否，新建应用节点标签，并按照述保护代码的入口点配置新建的应用节点标签。\n[0013] 可选地，在提取软件安装包中的全局配置文件和可执行文件之前还包括：接收由用户上传的软件安装包和设置的加固参数。\n[0014] 可选地，在生成加固安装包之后还包括：对加固安装包进行签名。\n[0015] 可选地，对加固安装包进行签名包括：下发加固安装包，由用户使用其身份标识对加固安装包进行签名；或者利用用户上传的身份标识对加固安装包进行签名。\n[0016] 可选地，软件安装包为安卓软件安装包，全局配置文件为manifest文件，可执行文件为dex文件。\n[0017] 根据本发明的另一个方面，还提供了一种软件安装包的加固保护装置。该软件安装包的加固保护装置包括：文件提取模块，配置为提取软件安装包中的全局配置文件和可执行文件；解析模块，配置为解析可执行文件，得到第一代码；加密模块，配置为将保护代码插入第一代码中得到第二代码，并对第二代码进行加密处理；配置模块，配置为按照保护代码的入口点修改全局配置文件；打包模块，配置为将修改后的全局配置文件和可执行文件重新打包生成加固安装包。\n[0018] 可选地，加密模块还被配置为：在第一代码中的每一类的代码中置入解壳触发代码和和反编译工具的崩溃代码；抽取第二代码的至少一部分进行重构；植入用于解密述重构的代码的链接库，链接库在解密过程中由java本地接口加载。\n[0019] 可选地，配置模块还配置为：检查全局配置文件是否配置有应用节点标签；若是，按照保护代码的入口点修改应用节点标签；若否，新建应用节点标签，并按照保护代码的入口点配置新建的应用节点标签。\n[0020] 可选地，上述软件安装包的加固保护装置还包括：获取模块，配置为接收由用户上传的软件安装包和设置的加固参数。\n[0021] 可选地，上述软件安装包的加固保护装置还包括：签名模块，配置为对加固安装包进行签名。\n[0022] 可选地，上述软件安装包的加固保护装置配置为对安卓软件安装包进行加固保护，其中，全局配置文件为manifest文件，可执行文件为dex文件。\n[0023] 本发明的软件安装包的加固保护方法和装置由于将保护代码直接插入可执行文件的代码内，相应修改全局配置文件的程序入口，实现了可执行文件的重构，从而在程序运行时，首先执行保护代码，以进行相应解密处理，直接对可执行文件进行处理，增加了可执行文件防护的灵活度，进一步提高了软件安装包的安全性。\n[0024] 进一步地，本发明的软件安装包的加固保护方法，每一类的代码中置入解壳触发代码和和反编译工具的崩溃代码，在每一类运行时，单独对运行的类进行解密，可以有效防止破解工具进行内存截取(dump)。\n[0025] 上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。\n[0026] 根据下文结合附图对本发明具体实施例的详细描述，本领域技术人员将会更加明了本发明的上述以及其他目的、优点和特征。\n附图说明\n[0027] 通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：\n[0028] 图1是根据本发明一个实施例的软件安装包的加固保护装置的示意图；\n[0029] 图2是根据本发明一个实施例的软件安装包方法的示意图；\n[0030] 图3是根据本发明一个实施例的软件安装包加固方法的流程图；\n[0031] 图4是图3中所示的重新生成apk文件包的可选流程图；\n[0032] 图5是根据本发明一个实施例的软件安装包加固方法中程序类加载的示意图。\n具体实施方式\n[0033] 在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。\n各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。\n[0034] 图1是根据本发明一个实施例的软件安装包的加固保护装置100的示意图。软件安装包的加固保护装置100一般性地可包括：文件提取模块110、解析模块120、加密模块130、配置模块140、打包模块150、获取模块160、签名模块170。以上模块可以根据本实施例的软件安装包的加固保护装置100的功能进行灵活配置，在一些可选情况下，可以配置以上模块的一个或多个，并不要求同时配置所有模块。\n[0035] 文件提取模块110提取软件安装包中的全局配置文件和可执行文件；对于安卓系统的软件安装包而言，全局配置文件为Manifest.xml，可执行文件为dex文件。\n[0036] 在Android系统上，一个可以安装、运行的应用，需要打包成Android系统的APK文件格式。APK是Android application package file的缩写，简称APK文件，即Android安装包，也可以理解为Android终端上安装的应用软件。APK文件其实是ZIP文件格式，但后缀名被修改为apk，通过Unzip等工具解压可以看到其内部的文件结构，如表1所示：\n[0037] 表1\n[0038]\n[0039] Android安装包(APK文件)一般通过Android应用市场下载、安装到手机上，也可以通过USB数据线等数据线接口或无线数据传输的方式从PC安装。Android上的病毒、木马和其他恶意软件想要进入用户的手机，也必须打包成APK的形式。反过来说，如果不是一个合法的APK文件，它就无法安装到用户手机上，也就不会对用户产生危害。基于这一点，杀毒引擎就可以把查杀的目标集中到对APK文件的扫描上，从而大大提高扫描的效率。\n[0040] 那么，Android安装包(APK文件)中的哪些信息可以作为扫描的重点，针对此问题本申请进行了分析，具体如下：\n[0041] 1)包名\n[0042] Android操作系统通过APK的包名(package name)对各个安装的APK进行管理。“包名”源自于Java的package的概念，按照Java的package的命名风格，例如某个Android安装包的包名是com.qihoo360.mobilesafe。Android系统要求每个应用都声明一个唯一的包名。如果要安装的APK的包名和当前手机上某个已有的应用的包名重复了，那么Android系统会拒绝安装。Android平台下的恶意软件也需要声明一个包名，因此，包名就可以作为识别恶意软件的一个重要特征。\n[0043] 2)数字签名\n[0044] 出于安全性的目的，Android系统要求每个APK都要包含数字签名(digital signature)。Android系统在安装APK文件的时候会检查APK内部各文件的数字签名是否与其预先设定的数字签名一致，如果不一致，或者没有数字签名，则认为文件已被篡改，拒绝该APK的安装和运行。Android平台下的恶意软件也不例外，所以APK文件的数字签名也可以作为识别恶意软件的一个重要特征。\n[0045] 3)AndroidManifest.xml中列出的各模块的入口信息\n[0046] AndroidManifest.xml是每个APK文件所必需的全局描述文件，里面列出了Android安装包中应用的每个模块的入口信息。在Android系统中，只有在\nAndroidManifest.xml中列出了的模块，才能够被系统调用。Android平台下的木马，往往会伪装成正常的应用或游戏来诱骗用户安装，其中有很多木马就是寄生在一个正常的应用或游戏中，用户运行它的时候，看上去是原来的软件或游戏，但寄生在其中的木马模块在合适的时机就被激活，从而感染用户的手机。而因为Android系统要求所有的模块都要在AndroidManifest.xml中列出，这就为寻找寄生的木马提高了重要线索。因此，AndroidManifest.xml中列出的各模块的信息，也是识别恶意软件的重要特征。\n[0047] 4)Dex文件和ELF文件\n[0048] Android应用通常是用Java语言开发的，它用Android开发工具编译之后变成了二进制的字节码(byte code)，这些字节码被打包成classes.dex文件，由Android平台的Dalvik虚拟机来解释执行。为了能够调用Android系统功能，Android系统提供了一套运行环境(Android Framework)，Android应用调用系统各功能都是通过调用Android Framework的库来实现的。\n[0049] 另一方面，Android系统也支持应用程序通过JNI或者native executable直接运行。此时应用执行的是直接在CPU上运行的二进制机器码，不需要经过虚拟机解释，可以直接调用Android库如libc、WebKit、SQLite、OpenGL/ES等来调用系统各功能。如果Android应用要通过JNI或者native executable运行，就需要将要执行的代码编译成ELF文件格式。\nELF是Executable and Linkable Format的缩写，是Android/Linux操作系统中可执行程序、共享库的文件格式。\n[0050] 每一个安卓软件安装包(apk)都包含一个清单(Manifest)文件，也就是AndroidManifest.xml，它存储在项目层次中的最底层。清单可以定义应用程序及其组件的结构和元数据。AndroidManifest.xml包含了组成应用程序的每一个组件(活动、服务、内容提供器和广播接收器)的节点，并使用目的过滤器和权限来确定这些组件之间以及这些组件和其他应用程序是如何交互的。它还提供了各种属性来详细地说明应用程序的元数据(图标或者主题)以及额外的可用来进行安全设置和单元测试顶级节点。\n[0051] manifest标签包含了一些节点(node)，它们定义了应用程序组件、安全设置和组成应用程序的测试类。下面列出了一些常用的manifest节点标签：\n[0052] 应用节点标签(application)，清单内一般只包含一个application节点。\napplication节点使用各种属性来指定应用程序的各种元数据(包括标题、图标和主题)。\napplication节点还可以作为一个包含了活动、服务、内容提供器和广播接收器标签的容器，用来指定应用程序组件。\n[0053] 活动节点标签(activity)，应用程序显示的每一个活动(Activity)都要求有一个activity标签。\n[0054] 服务节点标签(service)，service标签和activity标签一样，应用程序中使用的每一个服务类(Service)都要创建一个新的service标签。\n[0055] 内容提供者标签(provider)，provider标签用来说明应用程序中的每一个内容提供器。\n[0056] 接收器标签(receiver)，通过添加receiver标签，可以注册一个广播接收器(Broadcast Receiver)，而不用事先启动应用程序。广播接收器就像全局事件监听器一样，通过在声明中注册一个广播接收器，可以使这个进程实现完全自动化。如果一个匹配的数据传输(Intent)被广播了，则应用程序就会自动启动，并且注册的广播接收器也会开始运行。\n[0057] 用户权限标签(uses-permission)，作为安全模型的一部分，uses-permission标签声明了那些由用户定义的权限，而这些权限是应用程序正常执行所必需的。\n[0058] 许可标签(permission)，许可标签在可以限制访问某个应用程序组件之前，需要在清单中定义一个permission标签。可以使用permission标签来创建这些权限定义。\n[0059] 检测类(instrumentation)，instrumentation类提供一个框架，用来在应用程序运行时在活动或者服务上运行测试。它们提供了一些方法来监控应用程序及其与系统资源的交互。\n[0060] 在本发明的一种优选实施例应用于Android系统中时，可执行文件包括Dex文件，Dex文件主要是APK中的classes.dex文件，即Dalvik Executable(Dalvik虚拟机可执行文件)。公知的是，Dalvik是用于Android平台的Java虚拟机。Dalvik虚拟机(Dalvik VM)是Android移动设备平台的核心组成部分之一。它可以支持已转换为.dex(即Dalvik Executable)格式的Java应用程序的运行，.dex格式是专为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。Dalvik经过优化，允许在有限的内存中同时运行多个虚拟机的实例，并且每一个Dalvik应用作为一个独立的Linux进程执行。独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。虚拟机的线程机制，内存分配和管理，等等都是依赖底层操作系统而实现的，一般包含在apk文件里的dex文件会在运行时被优化，优化后的文件将被保存在缓存中。\n[0061] 可执行文件还可以包括扩展名为.jar的文件。Android安装包中的JAR文件其实就是Dex文件，只不过其扩展名为.jar。\n[0062] 根据以上对安卓程序安装包的分析，AndroidManifest.xml描述了应用的名字、版本、权限、引用的库文件等信息，因此，安卓系统在运行程序时首先需要解压apk文件，然后获取编译后的androidmanifest.xml文件中配置信息，执行dex程序。Apk文件在打包过程中，把所有的字节码文件转成dex文件(classes.dex)然后使用安卓打包工具将dex文件，资源文件以及AndroidManifest.xml文件组合成一个应用程序包(APK)\n[0063] 文件提取模块110从软件安装包中提取出全局配置文件和可执行文件。\n[0064] 解析模块120解析可执行文件，得到可执行文件的第一代码，以供后续进行加固处理。\n[0065] 加密模块130将保护代码插入第一代码中得到第二代码，并对第二代码进行加密处理。在第一代码中的每一类的代码中置入解壳触发代码和和反编译工具的崩溃代码；抽取第二代码的至少一部分进行重构；植入用于解密述重构的代码的链接库，链接库在解密过程中由java本地接口加载。\n[0066] 现有的安卓加固方法的加固流程为加密原程序包的dex文件，解析原程序包manifest.xml，提取组件信息生成代理的dex文件；在执行上述加固的程序时，需要解密原程序dex，并用使用加固中编译的优化工具将其镜像到内存。现有技术中优化工具和原程序包是完全分离的，虽然原程序包为加密文件，但是需要一次性还原dex，所以可以通过内存截取进行程序破解，而且优化工具也可以通过对UPX源代码修改进行脱壳。\n[0067] 在本实施例的软件安装包的加固保护装置应用于安卓系统的软件安装包时，对dex文件的重构，将dex文件各个节数据修改重组后重定位并生成新dex，由于直接对dex进行处理，可以增加dex防护的灵活度，如对dex进行内存分割重组，可有效防止内存dump等。\n[0068] 配置模块140按照保护代码的入口点修改全局配置文件，对于安卓程序安卓包，可以检查全局配置文件(AndroidManifest.xml)是否配置有应用节点标签(application)；若是，按照保护代码的入口点修改应用节点标签；若否，新建应用节点标签，并按照保护代码的入口点配置新建的应用节点标签。在进行解析时，根据全局配置文件的应用节点标签，会首先执行保护代码，以对该类的程序进行解密。由于对每类的代码分别可以植入保护代码，因此，不需要一次性全部还原全部dex，仅在该类被加载时，才需要还原该类的执行代码，实现了内存分割。\n[0069] 打包模块150配置为将修改后的全局配置文件和可执行文件重新打包生成加固安装包，完成整个加固流程。\n[0070] 另外，获取模块160还可以接收由用户上传的软件安装包和设置的加固参数。由于加固后的软件安装包可以可能无法被静态和动态扫描，有可能会被一些恶意代码利用，因此需要首先对上传的软件安装包进行安全扫描，保证不对恶意程序进行加固处理，此时需要获取相关开发信息和加固参数。\n[0071] 本实施例中提供的针对Android软件安装包的安全扫描，并不是对Android系统中的所有文件进行扫描，而是通过扫描Android安装包来进行安全检测。由于Android上的病毒、木马和其他恶意软件想要进入用户的手机，需要打包成Android安装包的形式。反过来说，如果不是一个合法的Android安装包，它就无法安装到用户手机上，也就不会对用户产生危害。具体的扫描方式，可以根据上述对Android安装包的文件结构分析进行，例如对包名、数字签名、AndroidManifest.xml中列出的各模块的入口信息、Dex文件和ELF文件进行安全检测，在确认其安全性后再允许进行加固措施。\n[0072] 扫描Android安装包的一种可选流程为：\n[0073] 从Android安装包中提取出指定的特征信息；指定的特征信息即指上述列举的各项重要特征，如包名、版本号、数字签名、AndroidManifest.xml中列出的各模块的入口信息、Dex文件和ELF文件、Android安装包目录下各文件的MD5值等。\n[0074] 在预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录；\n其中，安全识别库中包含特征记录及特征记录对应的安全级别，每条特征记录中包含单个特征信息或特征信息的组合；\n[0075] 将查找到的特征记录对应的安全级别进行输出，例如包含在Android安装包的安全检测结果中显示；当查找出的安全级别低于预设的安全级别，则安装包的上传者提示安全检测结果，并提示无法进行加固。\n[0076] 签名模块170用于对加固安装包进行签名。签名的信息有两种，一种是将加固后的程序安装包下发给用户，由用户自行进行签名，另外一种也可以获取用户的信息，在加固后直接进行签名，签名的方式可以由用户自行决定。\n[0077] 本发明实施例还提供了一种软件安装包的加固保护方法，该软件安装包的加固保护法可以由以上实施例介绍的任意一种软件安装包的加固保护装置来执行，以提高软件安装包的安全性。图2是根据本发明一个实施例的软件安装包方法的示意图，如图所示，该软件安装包包括以下步骤：\n[0078] 步骤S202，提取软件安装包中的全局配置文件和可执行文件；\n[0079] 步骤S204，解析可执行文件，得到第一代码；\n[0080] 步骤S206，将保护代码插入第一代码中得到第二代码，并对第二代码进行加密处理；\n[0081] 步骤S208，按照保护代码的入口点修改全局配置文件；\n[0082] 步骤S210，将修改后的全局配置文件和可执行文件重新打包生成加固安装包。\n[0083] 其中保护代码可以包括对可执行文件进行加壳和解壳的代码，具体地可以例如解壳触发代码和和反编译工具的崩溃代码，相应地步骤S206加入代码的流程可以包括：在第一代码中的每一类的代码中置入解壳触发代码和反编译工具的崩溃代码，解壳触发代码被执行时，调用解壳的代码对该类进行解密。其中对第二代码进行加密处理包括：抽取第二代码的至少一部分进行重构；植入用于解密重构的代码的链接库，链接库在解密过程中由java本地接口(Java Native Interface，简称JNI)加载。\n[0084] 在本实施例的软件安装包的加固保护方法应用于安卓系统的软件安装包时，对dex文件的重构，将dex文件各个节数据修改重组后重定位并生成新dex，由于直接对dex进行处理，可以增加dex防护的灵活度，如对dex进行内存分割重组，可有效防止内存dump等。\n[0085] 步骤S208的一种可选流程为：检查全局配置文件是否配置有应用节点标签；若是，按照保护代码的入口点修改应用节点标签；若否，新建应用节点标签，并按照述保护代码的入口点配置新建的应用节点标签。对于安卓程序安卓包，可以检查全局配置文件(AndroidManifest.xml)是否配置有应用节点标签(application)；若是，按照保护代码的入口点修改应用节点标签；若否，新建应用节点标签，并按照保护代码的入口点配置新建的应用节点标签。在进行解析时，根据全局配置文件的应用节点标签，会首先执行保护代码，以对该类的程序进行解密。由于对每类的代码分别可以植入保护代码，因此，不需要一次性全部还原全部dex，仅在该类被加载时，才需要还原该类的执行代码，实现了内存分割。\n[0086] 在步骤S202之前还可以接收由用户上传的软件安装包和设置的加固参数。另外[0087] 由于加固后的软件安装包可以可能无法被静态和动态扫描，有可能会被一些恶意代码利用，因此需要首先对上传的软件安装包进行安全扫描，保证不对恶意程序进行加固处理，此时需要获取相关开发信息和加固参数，用于对软件安装包进行安全扫描，对恶意文件及时处理。\n[0088] 对上传的软件安装包进行安全扫描的一种可选流程为：\n[0089] 从Android安装包中提取出指定的特征信息；指定的特征信息即指上述列举的各项重要特征，如包名、版本号、数字签名、AndroidManifest.xml中列出的各模块的入口信息、Dex文件和ELF文件、Android安装包目录下各文件的MD5值等。\n[0090] 在预置的安全识别库中查找与指定的单个特征信息或其组合相匹配的特征记录；\n其中，安全识别库中包含特征记录及特征记录对应的安全级别，每条特征记录中包含单个特征信息或特征信息的组合；\n[0091] 将查找到的特征记录对应的安全级别进行输出。\n[0092] 当查找出的安全级别低于预设的安全级别，则安装包的上传者提示安全检测结果，并提示无法进行加固。\n[0093] 生成加固安装包之后还需要对加固安装包进行签名。签名的方式可以下发加固安装包，由用户使用其身份标识对加固安装包进行签名；或者可以利用用户上传的身份标识对加固安装包进行签名。\n[0094] 图3是根据本发明一个实施例的软件安装包加固方法的流程图，在进行安卓安装包加固时依次执行以下步骤：\n[0095] 步骤S302，通过网页服务接收用户的访问，用户可以通过访问安全加固的网页进行相关测试加固；\n[0096] 步骤S304，接收上传的apk文件包以及加固参数；\n[0097] 步骤S306，解析apk文件包并提取manifest、dex等数据信息；\n[0098] 步骤S308，重构dex，修改manifest，重新生成apk文件包；\n[0099] 步骤S310，重新签名加固后的apk文件包。\n[0100] 在以上步骤中，S308是加固的核心步骤，图4是图3中所示的重新生成apk文件包的可选流程图，在进行apk加固时，依次执行以下步骤：\n[0101] 步骤S402，获取manifest需要修改的数据节点信息，查看manifest是否配置有应用节点标签(application)，以进行相应的处理，将加固程序的入口点加入应用节点标签，使应用从加固程序启动；\n[0102] 步骤S404，修改资源数据使之与manifest的节点数据一致；\n[0103] 步骤S406，对原包dex文件进行处理，具体地，可以将原包的dex解析为代码，将保护代码插入dex的解析代码中，保护代码的入口点已经在步骤S402中在manifest中进行了注册；\n[0104] 步骤S408，植入保护模块，该保护模块为用于解码的JNI层的.so的动态链接库的代码，同样植入dex包；\n[0105] 步骤S410，完成对dex文件进行加密。\n[0106] 其中，由于未加固的dex文件的安全性太弱，将核心代码植入保护模块可以实现程序在运行过程中实现脱壳，保护模块放入JNI内，利用JNI可以构造Java的类或执行Java层的方法获取属性等操作。\n[0107] 由于本实施例的软件安装包加固方法，通过在dex中置入代码进行加密，没有改变apk文件的本身结构，提高了兼容性。\n[0108] 由于对程序中的类进行分别处理，可以实现在加载的过程中，仅解密加载类，防止出现对整个内存截取。图5是根据本发明一个实施例的软件安装包加固方法中程序类加载的示意图，如图，每一类分别进行加密，在安卓系统加载该类时，对该类进行解密，例如某个安装包中有两个类，第一程序类和第二程序类，当系统加载第一程序类时，钩取该类中关键点，JNI可以对第一程序类进行解密并传回给dex进行加载，类似地当系统加载第二程序类时，钩取该类中关键点，JNI可以对第二程序类进行解密并传回给dex进行加载，此时内存中不存在所有的dex，因此无法进行内存截取。\n[0109] 本实施例的软件安装包加固方法可以实现二次或者多次加壳，在执行时进行动态脱壳，相比于现有技术只有一次加壳明显更具有安全优势，而现有技术更容易被破解。\n[0110] 另外，为了防止破解通过同时加载所有类来进行破解，可以判断所有类的列表中是否有超过阈值的类被加载(例如同时加载70％以上的类时)，可以消除最先解密类的数据，保证内存不会出现全部的数据，防止被内存截取。\n[0111] 本实施例的技术方案，将保护代码直接插入可执行文件的代码内，相应修改全局配置文件的程序入口，实现了可执行文件的重构，从而在程序运行时，首先执行保护代码，以进行相应解密处理，直接对可执行文件进行处理，增加了可执行文件防护的灵活度，进一步提高了软件安装包的安全性。\n[0112] 而且，本实施例采用云端加固方式，开发者可以直接从开放平台首页(例如dev.360.cn)进入加固保页面，在网页上点击“上传应用”。一键上传，自动加固，应用可以在后台完成安全监测和保护；接着点击“下载应用”，把下载的加固包重新签名，即可将最安全的产品分发到各个应用市场。另外，本实施例的页面上还可以提供签名工具，或者允许用户上传签名秘钥在完成加固后自动进行签名。\n[0113] 进一步地，在每一类的代码中置入解壳触发代码和和反编译工具的崩溃代码，在每一类运行时，单独对运行的类进行解密，可以有效防止破解工具进行内存截取(dump)。\n[0114] 在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。\n[0115] 类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。\n[0116] 本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。\n[0117] 此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。\n[0118] 本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的客户端模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的软件安装包的加固保护装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。\n这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。\n[0119] 应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。\n[0120] 至此，本领域技术人员应认识到，虽然本文已详尽示出和描述了本发明的多个示例性实施例，但是，在不脱离本发明精神和范围的情况下，仍可根据本发明公开的内容直接确定或推导出符合本发明原理的许多其他变型或修改。因此，本发明的范围应被理解和认定为覆盖了所有这些其他变型或修改。\n[0121] 本发明实施例还提供了A1.一种软件安装包的加固保护方法，包括：\n[0122] 提取软件安装包中的全局配置文件和可执行文件；\n[0123] 解析所述可执行文件，得到第一代码；\n[0124] 将保护代码插入所述第一代码中得到第二代码，并对所述第二代码进行加密处理；\n[0125] 按照所述保护代码的入口点修改所述全局配置文件；\n[0126] 将修改后的全局配置文件和可执行文件重新打包生成加固安装包。\n[0127] A2.根据A1所述的方法，其中，\n[0128] 所述保护代码包括对所述可执行文件进行加壳和解壳的代码。\n[0129] A3.根据A2所述的方法，其中，\n[0130] 所述保护代码还包括解壳触发代码和和反编译工具的崩溃代码；\n[0131] 将保护代码插入所述第一代码中得到第二代码包括：\n[0132] 在所述第一代码中的每一类的代码中置入解壳触发代码和反编译工具的崩溃代码，所述解壳触发代码被执行时，调用所述解壳的代码对该类进行解密。\n[0133] A4.根据A1至A3中任一项所述的方法，其中，对所述第二代码进行加密处理包括：\n[0134] 抽取所述第二代码的至少一部分进行重构；\n[0135] 植入用于解密所述重构的代码的链接库，所述链接库在解密过程中由java本地接口加载。\n[0136] A5.根据A1至A4中任一项所述的方法，其中，按照所述保护代码的入口点修改所述全局配置文件包括：\n[0137] 检查所述全局配置文件是否配置有应用节点标签；\n[0138] 若是，按照所述保护代码的入口点修改所述应用节点标签；\n[0139] 若否，新建应用节点标签，并按照所述保护代码的入口点配置新建的应用节点标签。\n[0140] A6.根据A1至A5中任一项所述的方法，其中，在提取软件安装包中的全局配置文件和可执行文件之前还包括：\n[0141] 接收由用户上传的所述软件安装包和设置的加固参数。\n[0142] A7.根据A1至A6中任一项所述的方法，其中，在生成加固安装包之后还包括：\n[0143] 对所述加固安装包进行签名。\n[0144] A8.根据A7所述的方法，其中，对所述加固安装包进行签名包括：\n[0145] 下发所述加固安装包，由用户使用其身份标识对所述加固安装包进行签名；或者[0146] 利用用户上传的身份标识对所述加固安装包进行签名。\n[0147] A9.根据A1至A8中任一项所述的方法，其中，\n[0148] 所述软件安装包为安卓软件安装包，所述全局配置文件为manifest文件，所述可执行文件为dex文件。\n[0149] 本发明实施例还提供了B10.一种软件安装包的加固保护装置，包括：\n[0150] 文件提取模块，配置为提取软件安装包中的全局配置文件和可执行文件；\n[0151] 解析模块，配置为解析所述可执行文件，得到第一代码；\n[0152] 加密模块，配置为将保护代码插入所述第一代码中得到第二代码，并对所述第二代码进行加密处理；\n[0153] 配置模块，配置为按照所述保护代码的入口点修改所述全局配置文件；\n[0154] 打包模块，配置为将修改后的全局配置文件和可执行文件重新打包生成加固安装包。\n[0155] B11.根据B10所述的装置，其中，所述加密模块还被配置为：\n[0156] 在所述第一代码中的每一类的代码中置入解壳触发代码和和反编译工具的崩溃代码；\n[0157] 抽取所述第二代码的至少一部分进行重构；\n[0158] 植入用于解密述重构的代码的链接库，所述链接库在解密过程中由java本地接口加载。\n[0159] B12.根据B10或B11所述的装置，其中，所述配置模块还配置为：\n[0160] 检查所述全局配置文件是否配置有应用节点标签；\n[0161] 若是，按照所述保护代码的入口点修改所述应用节点标签；\n[0162] 若否，新建应用节点标签，并按照所述保护代码的入口点配置新建的应用节点标签。\n[0163] B13.根据B10至B12中任一项所述的装置，还包括：\n[0164] 获取模块，配置为接收由用户上传的所述软件安装包和设置的加固参数。\n[0165] B14.根据B10至B13中任一项所述的装置，还包括：\n[0166] 签名模块，配置为对所述加固安装包进行签名。\n[0167] B15.根据B10至B14中任一项所述的装置，配置为对安卓软件安装包进行加固保护，其中，所述全局配置文件为manifest文件，所述可执行文件为dex文件。