CN106709289A

CN106709289A - 一种对可执行文件进行加固的方法和装置

Info

Publication number: CN106709289A
Application number: CN201611129918.1A
Authority: CN
Inventors: 吴乐
Original assignee: Beijing Qihoo Technology Co Ltd
Current assignee: Beijing Qihoo Technology Co Ltd
Priority date: 2016-12-09
Filing date: 2016-12-09
Publication date: 2017-05-24
Anticipated expiration: 2036-12-09
Also published as: CN106709289B

Abstract

本发明公开了一种对可执行文件进行加固的方法和装置。其中方法包括：将可执行文件中的N个待加密的函数按次序存储，其中，N为大于一的自然数；为每个待加密的函数选择对应的加密方法；依次对N个待加密的函数进行加密，其中，对第一个待加密函数，以该待加密函数对应的加密方法进行加密；对第M个待加密函数，以该待加密函数对应的加密方法进行加密后，再以第M‑1个函数所使用的所有加密方法，按所述第M‑1个函数所使用加密方法的次序进行加密；其中，M为大于一的自然数。该技术方案既能够选择较少的加密方法，还通过加密手段的复杂化使得得破解的可能性大大降低，对可执行文件进行加固的效率高，效果好。

Description

一种对可执行文件进行加固的方法和装置

技术领域

本发明涉及计算机安全领域，具体涉及一种对可执行文件进行加固的方法和装置。

背景技术

一般地，为了能够保护可执行文件中的代码不被攻击者逆向破解，通过为可执行文件加壳可以实现防止攻击者逆向我们代码逻辑的目的，加壳的手段一般是给可执行文件的部分或者全部进行加密。但是目前而言，加密方法往往是单层次的，这样很容易被破解者找到应对手段，不能满足需求。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的对可执行文件进行加固的方法和装置。

依据本发明的一个方面，提供了一种对可执行文件进行加固的方法，包括：

将可执行文件中的N个待加密的函数按次序存储，其中，N为大于一的自然数；

为每个待加密的函数选择对应的加密方法；

依次对N个待加密的函数进行加密，其中，对第一个待加密函数，以该待加密函数对应的加密方法进行加密；

对第M个待加密函数，以该待加密函数对应的加密方法进行加密后，再以第M-1个函数所使用的所有加密方法，按所述第M-1个函数所使用加密方法的次序进行加密；其中，M为大于一的自然数。

可选地，所述将可执行文件中的N个待加密的函数按次序存储包括：

将该N个待加密的函数按次序存储至可执行文件中的同一代码区段。

可选地，该方法还包括：

获取该N个待加密的函数在所述可执行文件执行时被调用的先后顺序，使该N个待加密的函数的存储次序与该N个待加密的函数在所述可执行文件执行时被调用的先后顺序一致。

可选地，该方法在所有步骤之前还包括：

将所述可执行文件转换为二进制形式。

可选地，该方法还包括：

向加固后的可执行文件添加解密逻辑。

可选地，所述解密逻辑包括：

与各待加密方法对应的解密方法。

可选地，所述解密逻辑包括：

在可执行文件被加载后，在需要调用所述代码区段中被加密的函数时，以该函数对应的解密方法对所述代码区段进行解密。

可选地，所述可执行文件为安卓安装包中的可执行文件。

可选地，所述方法还包括：

对安卓安装包进行解包，得到至少一个可执行文件；

将加固后的可执行文件打包到对应的安装包中。

依据本发明的另一方面，提供了一种对可执行文件进行加固的装置，包括：

待加密函数预处理单元，适于将可执行文件中的N个待加密的函数按次序存储，其中，N为大于一的自然数；

加密方法选择单元，适于为每个待加密的函数选择对应的加密方法；

加密单元，适于依次对N个待加密的函数进行加密，其中，对第一个待加密函数，以该待加密函数对应的加密方法进行加密；对第M个待加密函数，以该待加密函数对应的加密方法进行加密后，再以第M-1个函数所使用的所有加密方法，按所述第M-1个函数所使用加密方法的次序进行加密；其中，M为大于一的自然数。

可选地，所述待加密函数预处理单元，适于将该N个待加密的函数按次序存储至可执行文件中的同一代码区段。

可选地，所述待加密函数预处理单元，还适于获取该N个待加密的函数在所述可执行文件执行时被调用的先后顺序，使该N个待加密的函数的存储次序与该N个待加密的函数在所述可执行文件执行时被调用的先后顺序一致。

可选地，该装置还包括：

可执行文件转换单元，适于将所述可执行文件转换为二进制形式。

可选地，该装置还包括：

解密单元，适于向加固后的可执行文件添加解密逻辑。

可选地，所述解密逻辑包括：

与各待加密方法对应的解密方法。

可选地，所述解密逻辑包括：

可选地，所述可执行文件为安卓安装包中的可执行文件。

可选地，所述装置还包括：

解包单元，适于对安卓安装包进行解包，得到至少一个可执行文件；

打包单元，适于将加固后的可执行文件打包到对应的安装包中。

由上述可知，本发明的技术方案，将可执行文件中的多个待加密的函数按次序存储，在为每个函数选择对应的加密方法的基础上，在具体加密时，对每个函数按次序递进，使用不同层次的加密方法进行加密。该技术方案既能够选择较少的加密方法，还通过加密手段的复杂化使得得破解的可能性大大降低，对可执行文件进行加固的效率高，效果好。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本发明一个实施例的对可执行文件进行加固的方法的流程示意图；

图2示出了根据本发明一个实施例的对可执行文件进行加固的装置的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

图1示出了根据本发明一个实施例的一种对可执行文件进行加固的方法的流程示意图，如图1所示，该方法包括：

步骤S110，将可执行文件中的N个待加密的函数按次序存储，其中，N为大于一的自然数。

步骤S120，为每个待加密的函数选择对应的加密方法。具体地，每个加密方法可以是一种加密算法或加密函数。

步骤S130，依次对N个待加密的函数进行加密，其中，对第一个待加密函数，以该待加密函数对应的加密方法进行加密；对第M个待加密函数，以该待加密函数对应的加密方法进行加密后，再以第M-1个函数所使用的所有加密方法，按第M-1个函数所使用加密方法的次序进行加密；其中，M为大于一的自然数。

例如，FUNC1、FUNC2、FUNC3为三个待加密的函数。FUNC1对应的加密函数为E1，FUNC2对应的加密函数为E2，FUNC3对应的加密函数为E3。那么在加密时：

1)对FUNC1函数的函数体用加密函数E1进行加密：

Encrypt_func1＝E1(FUNC1_body)；

2)对FUNC2函数的函数体先用加密函数E2加密，再用加密函数E1加密:

Encrypt_func2＝E1(E2(FUNC2_body))；

3)对FUNC3函数的函数体先用加密函数E3加密，再用加密函数E2加密，最后用加密函数E1加密:

Encrypt_func3＝E1(E2(E3(FUNC3_body)))；

可见，图1所示的方法，将可执行文件中的多个待加密的函数按次序存储，在为每个函数选择对应的加密方法的基础上，在具体加密时，对每个函数按次序递进，使用不同层次的加密方法进行加密。该技术方案既能够选择较少的加密方法，还通过加密手段的复杂化使得得破解的可能性大大降低，对可执行文件进行加固的效率高，效果好。

在本发明的一个实施例中，上述方法中，将可执行文件中的N个待加密的函数按次序存储包括：将该N个待加密的函数按次序存储至可执行文件中的同一代码区段。例如上面的三个函数FUNC1、FUNC2、FUNC3可以被存储到下面这样的section(代码区段)中：

FUNC1_body
	FUNC2_body
FUNC3_body

而对这三个函数进行了如上述的加密后，section中存储的数据为：

E1(FUNC1_body)
	E1(E2(FUNC2_body))
E1(E2(E3(FUNC3_body)))

在本发明的一个实施例中，上述方法还包括：获取该N个待加密的函数在可执行文件执行时被调用的先后顺序，使该N个待加密的函数的存储次序与该N个待加密的函数在可执行文件执行时被调用的先后顺序一致。

这样的存储顺序既使得函数的调用变得方便，也方便对函数进行解密，同时代码也美观大方。

在本发明的一个实施例中，上述方法在所有步骤之前还包括：将可执行文件转换为二进制形式。

也即是说，本实施例在进行上述处理的过程中，也是对二进制形式的函数体进行处理。

在本发明的一个实施例中，上述方法还包括：向加固后的可执行文件添加解密逻辑。具体地，解密逻辑包括：与各待加密方法对应的解密方法。

可执行文件中的代码想要被系统正确地运行，就必须在运行前对要运行的代码进行解密，否则直接运行加密后的代码指令是会让可执行文件崩溃的。

通常，对可执行文件进行加固可以通过对可执行文件进行加壳来实现，普通的壳都会在可执行文件被执行前，对可执行文件进行比较完全的解壳，这样，在内存中会存在一份完全解密后的可执行文件。这样一来，攻击者只要在内存中找出完全解密后的可执行文件，就可以将其读取出来，这样就获取到了一份完全解密后的可执行文件了。这个从内存中读取解密后可执行文件的过程叫做dump。解密后的可执行文件一旦被dump出来，攻击者就可以非常容易的对可执行文件中的代码进行逆向，那么代码逻辑就暴露给了攻击者。

而上述实施例中对可执行文件进行的加固则不会出现该问题，这是由于在解密时，可以不对整个可执行文件进行完全解密。具体地，在本发明的一个实施例中上述方法中的解密逻辑包括：在可执行文件被加载后，在需要调用代码区段中被加密的函数时，以该函数对应的解密方法对代码区段进行解密。

这样在内存中不会存在完全解密的该代码区段。具体地，依然以FUNC1、FUNC2、FUNC3这三个函数的加密为例，在解密时：

1)运行FUNC1函数前，利用解密函数D1对整个section进行解密：

解密函数D1是和加密函数E1相对应的，利用解密函数D1对可以对FUNC1函数的函数体进行解密：

FUNC1_body＝D1(E1(FUNC1_body))；

而与此同时，对FUNC2和FUNC3函数的函数体都利用D1进行了处理：

E2(FUNC2_body)＝D1(E1(E2(FUNC2_body)))；

E2(E3(FUNC3_body))＝D1(E1(E2(E3(FUNC3_body))))；

这样一来，FUNC2和FUNC3函数的第一层加密就被解密了。

2)在运行FUNC2函数前，利用解密函数D2对整个section进行解密：

解密函数D2是和加密函数E2相对应的。利用解密函数D2对FUNC2函数的函数体进行解密：

FUNC2_body＝D2(E2(FUNC2_body))；

与此同时，对FUNC1和FUNC3函数利用解密函数D2进行处理：

D2(FUNC1_body)；

这样对FUNC1，又利用D1对其进行了加密；

而对FUNC3：

E3(FUNC3_body)＝D2(E2(E3(FUNC3_body)))；

这样一来，FUNC3函数的第二层加密也被解密了。

3)在运行FUNC3函数之前，利用解密函数D3对整个section进行解密：

解密函数D3和加密函数E3相对应。利用解密函数D3对FUNC3函数的函数体进行解密：

FUNC3_body＝D3(E3(FUNC3_body))

同时，对FUNC1和FUNC2函数利用解密函数D3进行处理：

D3(D2(FUNC1_body))；

这样一来，又对FUNC1做了一层加密；

D3(FUNC2_body)；

这样一来，也对FUNC2函数进行了加密。

可见，无论是FUNC1、FUNC2、FUNC3中哪个函数在运行，其余两个函数都处于被加密的状态。也就是说，在可执行文件的执行过程中，不存在可执行文件被完全解密的时间点，也就不会被攻击者一次dump出一个完全解密的可执行文件。

在本发明的一个实施例中，上述方法中，可执行文件为安卓安装包中的可执行文件，例如安卓虚拟机执行DEX文件DEX(Dalvik VM executes)中的Dalvik VM是安卓系统中的虚拟机，DEX文件可以在安卓应用的运行时动态加载。

在本发明的一个实施例中，上述方法还包括：对安卓安装包进行解包，得到至少一个可执行文件；将加固后的可执行文件打包到对应的安装包中。

在上述实施例中由于对可执行文件进行了加固处理，还需进一步将其与安卓安装包的其他文件，例如安卓资源文件、安卓配置文件等一同打包为完整的安卓安装包。其中，可执行文件、安卓资源文件等可以是开发者分别提供的，例如在一个开发团队内部，由不同的项目组提供不同类别的文件，最后由安全组对可执行文件进行加密和全部文件的打包；也可以由专门的安全服务提供方对开发者提供的未加固安卓安装包进行解包处理，对其中的可执行文件进行加固后重新进行打包。

图2示出了根据本发明一个实施例的一种对可执行文件进行加固的装置的结构示意图，如图2所示，对可执行文件进行加固的装置200包括：

待加密函数预处理单元210，适于将可执行文件中的N个待加密的函数按次序存储，其中，N为大于一的自然数。

加密方法选择单元220，适于为每个待加密的函数选择对应的加密方法。

加密单元230，适于依次对N个待加密的函数进行加密，其中，对第一个待加密函数，以该待加密函数对应的加密方法进行加密；对第M个待加密函数，以该待加密函数对应的加密方法进行加密后，再以第M-1个函数所使用的所有加密方法，按第M-1个函数所使用加密方法的次序进行加密；其中，M为大于一的自然数。

可见，图2所示的装置，将可执行文件中的多个待加密的函数按次序存储，在为每个函数选择对应的加密方法的基础上，在具体加密时，对每个函数按次序递进，使用不同层次的加密方法进行加密。该技术方案既能够选择较少的加密方法，还通过加密手段的复杂化使得得破解的可能性大大降低，对可执行文件进行加固的效率高，效果好。

在本发明的一个实施例中，上述装置中，待加密函数预处理单元210，适于将该N个待加密的函数按次序存储至可执行文件中的同一代码区段。

在本发明的一个实施例中，上述装置中，待加密函数预处理单元210，还适于获取该N个待加密的函数在可执行文件执行时被调用的先后顺序，使该N个待加密的函数的存储次序与该N个待加密的函数在可执行文件执行时被调用的先后顺序一致。

在本发明的一个实施例中，上述装置还包括：可执行文件转换单元，适于将可执行文件转换为二进制形式。

在本发明的一个实施例中，上述装置还包括：解密单元，适于向加固后的可执行文件添加解密逻辑。

在本发明的一个实施例中，上述装置中，解密逻辑包括：与各待加密方法对应的解密方法。

在本发明的一个实施例中，上述装置中，解密逻辑包括：在可执行文件被加载后，在需要调用代码区段中被加密的函数时，以该函数对应的解密方法对代码区段进行解密。

在本发明的一个实施例中，上述装置中，可执行文件为安卓安装包中的可执行文件。

在本发明的一个实施例中，上述装置还包括：解包单元，适于对安卓安装包进行解包，得到至少一个可执行文件；打包单元，适于将加固后的可执行文件打包到对应的安装包中。

需要说明的是，上述各装置实施例的具体实现方式与前述对应方法实施例的具体实施方式相同，在此不再赘述。

综上所述，本发明的技术方案，将可执行文件中的多个待加密的函数按次序存储，在为每个函数选择对应的加密方法的基础上，在具体加密时，对每个函数按次序递进，使用不同层次的加密方法进行加密。该技术方案既能够选择较少的加密方法，还通过加密手段的复杂化使得得破解的可能性大大降低，对可执行文件进行加固的效率高，效果好。

需要说明的是：

在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的对可执行文件进行加固的装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

本发明的实施例公开了A1、一种对可执行文件进行加固的方法，其中，该方法包括：

为每个待加密的函数选择对应的加密方法；

A2、如A1所述的方法，其中，所述将可执行文件中的N个待加密的函数按次序存储包括：

A3、如A1所述的方法，其中，该方法还包括：

A4、如A1所述的方法，其中，该方法在所有步骤之前还包括：

将所述可执行文件转换为二进制形式。

A5、如A1所述的方法，其中，该方法还包括：

向加固后的可执行文件添加解密逻辑。

A6、如A5所述的方法，其中，所述解密逻辑包括：

与各待加密方法对应的解密方法。

A7、如A6所述的方法，其中，所述解密逻辑包括：

A8、如A1-A7中任一项所述的方法，其中，所述可执行文件为安卓安装包中的可执行文件。

A9、如A8所述的方法，其中，所述方法还包括：

对安卓安装包进行解包，得到至少一个可执行文件；

将加固后的可执行文件打包到对应的安装包中。

本发明的实施例还公开了B10、一种对可执行文件进行加固的装置，其中，该装置包括：

B11、如B10所述的装置，其中，

所述待加密函数预处理单元，适于将该N个待加密的函数按次序存储至可执行文件中的同一代码区段。

B12、如B10所述的装置，其中，所述待加密函数预处理单元，还适于获取该N个待加密的函数在所述可执行文件执行时被调用的先后顺序，使该N个待加密的函数的存储次序与该N个待加密的函数在所述可执行文件执行时被调用的先后顺序一致。

B13、如B10所述的装置，其中，该装置还包括：

B14、如B11所述的装置，其中，该装置还包括：

解密单元，适于向加固后的可执行文件添加解密逻辑。

B15、如B14所述的装置，其中，所述解密逻辑包括：

与各待加密方法对应的解密方法。

B16、如B15所述的装置，其中，所述解密逻辑包括：

B17、如B10-B16中任一项所述的装置，其中，所述可执行文件为安卓安装包中的可执行文件。

B18、如B17所述的装置，其中，所述装置还包括：

Claims

1.一种对可执行文件进行加固的方法，其中，该方法包括：

为每个待加密的函数选择对应的加密方法；

2.如权利要求1所述的方法，其中，所述将可执行文件中的N个待加密的函数按次序存储包括：

3.如权利要求1所述的方法，其中，该方法还包括：

4.如权利要求1所述的方法，其中，该方法在所有步骤之前还包括：

将所述可执行文件转换为二进制形式。

5.如权利要求1所述的方法，其中，该方法还包括：

向加固后的可执行文件添加解密逻辑。

6.如权利要求5所述的方法，其中，所述解密逻辑包括：

与各待加密方法对应的解密方法。

7.如权利要求6所述的方法，其中，所述解密逻辑包括：

8.如权利要求1-7中任一项所述的方法，其中，所述可执行文件为安卓安装包中的可执行文件。

9.如权利要求8所述的方法，其中，所述方法还包括：

对安卓安装包进行解包，得到至少一个可执行文件；

将加固后的可执行文件打包到对应的安装包中。

10.一种对可执行文件进行加固的装置，其中，该装置包括：