CN104392169B - 一种Native API函数重构方法和装置 - Google Patents

Abstract

本发明提供了一种Native API函数重构方法和装置，通过自定义实现Native API函数，并将所述Native API函数封装为静态库lib文件，并保存于本地。在应用程序运行时可以通过从静态库lib文件对应的本地存储位置中直接调用自定义Native API函数，实现应用程序的相关功能。由于Native API函数是保存于本地，恶意程序无法知道Native API函数的存储地址，也就无法对其进行非法监听、拦截或篡改等操作。此外，由于Native API函数是静态库lib文件，逆向工程分析人员无法知道静态库的接口位置，也就无法对自定义实现的Native API函数进行拦截或篡改，从而从根本上杜绝了在应用层上对API函数的跟踪拦截，大大提高了应用程序的安全性。

Description

一种Native API函数重构方法和装置

技术领域

本发明涉及计算机技术安全领域，特别涉及一种Native API函数重构方法和装置。

背景技术

随着WINDOWS API(WINDOWS Application Programming Interface，WINDOWS应用程序编程接口)编程的广泛普及和应用，越来越多的应用程序可以通过调用WINDOWS API函数来完成相应的功能。目前，应用程序在实现具体功能时，在应用层，首先需要加载与功能相关的DLL(Dynamic Link Library，动态链接库)，然后根据GetProcAddress函数获取DLL中WINDOWS API函数的起始地址，根据这些起始地址调用对应的WINDOWS API函数，这些WINDOWS API函数通常会最终调用较低级的Native API函数，这些Native API函数最终完成对驱动层的访问。

在实现本发明的过程中，发明人发现现有技术至少存在以下问题：在应用层上，恶意程序(比如利用钩子HOOK技术的程序)可以预先处理GetProcAddress函数，以得到相关的API函数(通常可以包括WINDOWS API函数或者Native API函数)的起始地址，并获取API函数的内容或对API函数的内容进行修改。因此，在应用层上，恶意程序均可以非法监听、拦截或篡改API函数中的内容，从而使得应用程序存在较大的安全隐患。

因此，如何避免应用程序在调用API函数时，被恶意程序非法监听、拦截，甚至篡改API函数中的内容，进而解决应用程序存在的安全隐患，是计算机技术安全领域亟需解决的一个问题。

发明内容

为此，需要提供一种Native API函数重构的技术方案，用以解决现有技术中调用API函数的过程中容易被恶意程序预先处理，使得应用程序存在较大的安全隐患的问题。

为实现上述目的，发明人提供了一种Native API函数重构方法，所述方法包括如下步骤：

自定义实现Native API函数；

将所述Native API函数封装为静态库lib文件，并保存于本地；其中所述静态库lib文件位于自定义代码段中。

作为Native API函数重构方法的一种可实施方式，自定义实现Native API函数的方法基于系统类型；所述系统类型包括32位系统或64位系统。

作为Native API函数重构方法的一种可实施方式，所述自定义实现Native API函数的方法基于系统类型具体包括：

当所述系统类型为32位系统时，自定义实现32位系统的Native API函数并将其保存于所述自定义代码段中的第一指定位置；或，

当所述系统类型为64位系统时，自定义实现64位系统的Native API函数并将其保存于所述自定义代码段中的第二指定位置。

作为Native API函数重构方法的一种可实施方式，所述自定义实现64位系统的Native API函数还包括整合操作，所述整合操作包括指令整合和堆栈整合；

所述指令整合包括设置寄存器ECX指令和设置寄存器EDX指令，所述寄存器ECX和寄存器EDX用于存储调用自定义实现64位的Native API函数的参数；

所述堆栈整合具体包括：

在调用自定义实现64位系统的Native API函数前将当前堆栈的栈顶指针ESP及栈底指针EBP的初始值保存至静态局部变量中；

在调用完自定义实现64位系统的Native API函数后，将当前堆栈的栈顶指针ESP及栈底指针EBP的值替换为初始值。

作为Native API函数重构方法的一种可实施方式，所述方法还包括：

对自定义实现的Native API函数进行虚拟化操作。

发明人还提供了一种Native API函数重构装置，所述装置包括实现单元，封装单元以及存储单元；

所述实现单元用于自定义实现Native API函数；

所述封装单元用于将所述自定义实现Native API函数封装为静态库lib文件；其中，所述静态库lib文件位于可执行应用程序自定义代码段中；

所述存储单元用于将静态库lib文件保存于本地。

作为Native API函数重构装置的一种可实施方式，实现单元自定义实现NativeAPI函数基于系统类型；所述系统类型包括32位系统或64位系统。

作为Native API函数重构装置的一种可实施方式，所述实现单元自定义实现Native API函数基于系统类型具体包括：

当所述系统类型为32位系统时，实现单元用于自定义实现32位系统的Native API函数，存储单元用于将自定义实现32位系统的Native API函数保存于所述自定义代码段中的第一指定位置；或，

当所述系统类型为64位系统时，实现单元用于自定义实现64位系统的Native API函数，存储单元用于将自定义实现64位系统的Native API函数保存于所述自定义代码段中的第二指定位置。

作为Native API函数重构装置的一种可实施方式，所述装置还包括整合单元，所述整合单元包括指令整合模块和堆栈整合模块，所述指令整合模块用于设置寄存器ECX指令和设置寄存器EDX指令，所述寄存器ECX和寄存器EDX用于存储调用自定义实现64位的Native API函数的参数；所述堆栈整合模块用于在调用自定义实现64位的Native API函数前将当前堆栈的栈顶指针ESP及栈底指针EBP的初始值保存到静态局部变量中，并在调用完自定义实现64位的Native API函数后，将当前堆栈的栈顶指针ESP及栈底指针EBP的值替换为初始值。

作为Native API函数重构装置的一种可实施方式，所述装置包括虚拟化单元，所述虚拟化单元用于对自定义实现的Native API函数进行虚拟化操作。

区别于现有技术，上述技术方案通过自定义实现Native API函数，并将所述Native API函数封装为静态库lib文件，并保存于本地。在应用程序运行时可以通过从静态库lib文件对应的本地存储位置中直接调用自定义Native API函数，实现应用程序的相关功能。由于Native API函数是保存于本地，恶意程序无法知道Native API函数的存储地址，也就无法对其进行非法监听、拦截或篡改等操作。此外，由于Native API函数是静态库lib文件，逆向工程分析人员无法知道静态库的接口位置，也就无法对自定义实现的NativeAPI函数进行拦截或篡改，从而从根本上杜绝了在应用层上对API函数的跟踪拦截，大大提高了应用程序的安全性，因而在计算机技术安全领域具有广阔的前景。

附图说明

图1为本发明一实施方式所述的Native API函数重构方法的流程图；

图2为本发明一实施方式所述的实现64位系统的Native API函数方法的流程图；

图3为本发明一实施方式所述Native API函数重构装置的结构示意图。

附图标记说明：

1、实现单元；

2、封装单元；

3、存储单元；

4、整合单元；41、指令整合模块；42、堆栈整合模块；

5、虚拟化单元。

具体实施方式

为详细说明技术方案的技术内容、构造特征、所实现目的及效果，以下结合具体实施例并配合附图详予说明。

请参阅图1，本发明一实施方式所述的Native API函数重构方法的流程图；所述方法可以应用于电子设备上，对Native API函数进行重构，具体包括以下步骤：

首先为步骤S1自定义实现Native API函数。自定义实现就是通过自己编写的方式来实现Native API函数。应用程序在执行的过程中，往往需要调用WINDOWS API函数来实现应用程序的相关功能，在调用这些函数时上容易被HOOK到，进而被监听、拦截或篡改，给应用程序带来很大的安全隐患。因而需要对这些API函数进行重构，避免在调用这些API函数时被HOOK到，而在实际应用中一方面WINDOWS API函数的种类较多，不容易被重构，另一方面应用程序所调用的WINDOWS API函数最终会调用较低级的Native API函数以完成相应的功能，因此选择通过自定义实现Native API来实现应用程序的相关功能。

而后进入步骤S2将所述Native API函数封装为静态库lib文件，并保存于本地。自定义实现Native API函数后，需要对自定义实现的Native API函数进行封装处理，方便应用程序直接从封装库中调用。常用的封装方法是将函数封装为静态库和动态库两种形式，动态库在应用程序运行时才被调用，一定程度上节省了内存空间，然而由于动态库并不存储于应用程序的代码段中，在调用时应用程序与动态库之间需要进行一定的交互，交互频繁就使得函数接口容易暴露，一旦恶意程序获悉函数接口，就可在应用程序调用动态库函数时对其进行HOOK。静态库在编译过程中就保存于应用程序的代码段(自定义代码段)中，在调用静态库函数时无需与外界进行交互，所有的调用均在应用程序代码段内部完成，这就避免了函数接口暴露，且应用程序和静态库是自定义实现，且存储于本地，恶意程序无法知道应用程序的存储位置，也就无法得知静态库lib文件的存储位置，从而进一步增强了调用Native API函数的安全性。

上述技术方案通过自定义实现Native API函数，并将所述Native API函数封装为静态库lib文件，并保存于本地。在应用程序运行时可以通过从静态库lib文件对应的本地存储位置中直接调用自定义Native API函数，实现应用程序的相关功能。由于Native API函数是保存于本地，恶意程序无法知道Native API函数的存储地址，也就无法对其进行非法监听、拦截或篡改等操作。此外，由于Native API函数是静态库lib文件，逆向工程分析人员无法知道静态库的接口位置，也就无法对自定义实现的Native API函数进行监听、拦截或篡改，从而从根本上杜绝了在应用层上对API函数的跟踪拦截，大大提高了应用程序的安全性，因而在计算机技术安全领域具有广阔的前景。

为了扩大自定义实现的Native API函数的适用范围，提高自定义实现的NativeAPI函数在不同运行环境下的兼容性，所述自定义实现Native API函数方法基于系统类型；所述系统类型包括32位系统或64位系统。所述自定义实现Native API函数的方法基于系统类型具体包括：

当所述系统类型为32位系统时，自定义实现32位系统的Native API函数并将其保存于所述自定义代码段中的第一指定位置。对于32位系统，不管系统的版本如何，如WIN8，WIN7，WINXP等，它们的Native API函数均保持一致，简言之，就是所调用Native API函数并不差别，因而在自定义实现32位系统的Native API函数时也无需进行预设处理，只需自定义编写完成后将其封装为静态库lib文件并保存于所述自定义代码段中的第一指定位置。自定义代码段即为自定义实现的应用程序代码段，当需要调用自定义实现的32位系统Native API函数时，只需从应用程序代码段的第一指定位置调用即可。

当所述系统类型为64位系统时，首先进入步骤S3自定义实现64位系统的NativeAPI函数并将其保存于所述自定义代码段中的第二指定位置。当需要调用自定义实现的64位系统Native API函数时，只需从应用程序代码段的第二指定位置调用即可。通过将自定义实现32位系统的Native API函数和64位系统的Native API函数分别存储于应用程序代码段的不同位置，提升了调用Native API函数的效率。

由于不同系统版本的Native API函数存在一定的差别，因而需要对自定义实现的64位系统的Native API函数作一定的预设处理。具体地，所述不同系统版本的Native API函数存在一定的差别表现为：WIN8系统和其他版本系统(如WIN7，WINXP，WIN2003)存在差别，下面以Native API函数中的ZwGetContextThread函数为例对WIN8系统和其他版本系统(如WIN7，WINXP，WIN2003)存在的差别作进一步说明：

对于WIN8系统的ZwGetContextThread函数的反汇编代码如下：

77E5FAD8>B816000000 MOV EAX，16

77E5FAE3 64:FF15 C0000000 CALL DWORD PTR FS:[C0]

77E5FAED C2 1400 RETN 14

而对于其他版本系统(如WIN7、WINXP、WIN2003、WIN2000等)的ZwGetContextThread函数的反汇编代码如下：

比较得知，对于WIN8系统的ZwGetContextThread函数与其他版本系统的差别在于少了如下3条指令：

XOR ECX， ECX

LEA EDX， DWROD PTR SS:[ESP+4]

ADD ESP， 4

而对于64位系统而言，除了ZwGetContextThread函数之外的其他Native API函数同样存在类似的差异，即WIN8系统与其他版本系统的Native API函数存在着少了如上3条指令的差别。为了增强自定义实现的64位系统Native API函数的兼容性，使得无论系统是什么样的版本，都能很好地调用自定义实现的64位系统Native API函数，完成相应的功能，因而需要对自定义实现的64位系统Native API函数进行整合操作，所述整合操作包括指令整合和堆栈整合。如图2所示，因而在步骤S3后可以进入步骤S4设置寄存器ECX指令和设置寄存器EDX指令，所述寄存器ECX和寄存器EDX用于存储调用自定义实现64位的Native API函数的参数。在64位系统中，对于除WIN8以外的其他版本系统，在进行Native API函数调用时需要用到寄存器ECX和寄存器EDX中存储的两个参数，才可完成API函数的调用；而对于WIN8系统而言，在进行Native API函数调用时无需用到寄存器ECX和寄存器EDX中存储的两个参数，因而无需设置寄存器ECX指令和设置寄存器EDX指令，即使设置了寄存器ECX指令和设置寄存器EDX指令，也不会对WIN8系统的Native API函数造成影响。为了使得自定义实现64位系统的Native API函数在指令方面得以统一，因而在自定义实现64位系统的NativeAPI函数在指令方面采用除WIN8之外的其他版本系统的指令设置方式，也即设置寄存器ECX指令和设置寄存器EDX指令。这样，自定义实现64位系统的Native API函数不仅能够兼容除WIN8以外的其他版本系统环境下的调用，而又不影响WIN8系统环境下的调用，从而使得自定义实现64位的Native API函数在指令方面得以整合统一。

而对于堆栈整合方面，以ZwGetContextThread函数为例，从上述反汇编代码中易得，WIN8与其他版本的系统相比较，少了以下一条指令：

ADD ESP，4

简言之，除WIN8以外的其他版本系统的Native API函数与WIN8系统的Native API函数相比较，需要进行平衡堆栈操作，上述指令“ADD ESP，4”用于平衡堆栈，4为平衡堆栈的值，尽管对于不同的Native API函数所平衡堆栈的值有所差异，但对于除WIN8以外的其他版本系统的Native API函数均需要进行平衡堆栈操作。而对于WIN8系统而言，无需进行平衡堆栈操作，但是即使进行了平衡堆栈操作，也不会对Native API函数的调用产生影响。因而为了兼容除WIN8以外的其他版本系统，堆栈整合包括平衡堆栈操作，具体包括：

首先进入步骤S5在调用自定义实现64位系统的Native API函数前将当前堆栈的栈顶指针ESP及栈底指针EBP的初始值保存至静态局部变量中；

而后进入步骤S6在调用完自定义实现64位系统的Native API函数后，将当前堆栈的栈顶指针ESP及栈底指针EBP的值替换为初始值。

由于Native API函数在被调用后，栈顶指针ESP及栈底指针EBP的值往往会发生变化，如果未对栈顶指针ESP及栈底指针EBP的初始值进行保存的话，每次调用完成后，由于需要进行平衡堆栈操作，就需要将栈顶指针ESP及栈底指针EBP的值恢复为初始值，一旦在计算过程中恢复的栈顶指针ESP及栈底指针的值发生错误，也就是说与初始值不一致，则会造成堆栈被破坏，甚至应用程序崩溃的严重后果。因而通过在调用Native API函数前将堆栈的栈顶指针ESP及栈底指针EBP的初始值保存至静态局部变量中，并在调用完成后对顶指针ESP及栈底指针EBP予以恢复初始值的方式，避免了除WIN8以外的其他版本系统的NativeAPI函数在调用前后进行平衡堆栈时容易发生错误的问题。

为了增强自定义实现的Native API函数调用时的安全性，防止逆向分析人员或恶意程序获悉自定义实现的Native API函数的存储地址。在步骤S2之后还可以进入步骤S7对自定义实现的Native API函数进行虚拟化操作。所述虚拟化操作可以通过虚拟化软件来完成的，具体的，所述虚拟化步骤包括：

在需要虚拟化的Native API函数的代码中写入所述虚拟化软件的宏定义文件；在需要虚拟化的Native API函数的代码内加入一对保护宏，所述保护宏包括初始保护宏和结束保护宏，所述初始保护宏和结束保护宏分别位于所述Native API函数的代码的初始位置和结束位置；用虚拟化软件运行上述Native API函数的代码，从而生成相应的虚拟化程序文件。经过虚拟化软件处理后，逆向工程分析人员或恶意程序利用相关软件对编译的二进制进行反汇编处理后，并不能得到Native API函数代码，得到的是Native API函数虚拟化后的程序文件代码，因而无从得知虚拟化后的程序文件的用途，更无从获悉Native API函数的存储地址，从而进一步提高了自定义实现的Native API函数的安全性，进而保证了应用程序的安全。

上述技术方案通过自定义实现Native API函数，并将所述Native API函数封装为静态库lib文件，并保存于本地。且对64位系统的Native API函数进行整合处理，实现了WIN8以及其他版本系统的Native API函数在调用时的统一。并且可以对自定义实现的Native API函数的代码进行虚拟化处理，使得逆向工程分析人员或恶意程序无法获悉自定义实现的Native API函数的存储地址，也就无法对自定义实现的Native API函数进行监听、拦截或篡改，从而从根本上杜绝了在应用层上对API函数的跟踪拦截，大大提高了应用程序的安全性，因而在计算机技术安全领域具有广阔的前景。

请参阅图3，为本发明一实施方式Native API函数重构装置的结构示意图。所述装置包括实现单元1，封装单元2以及存储单元3；

所述实现单元1用于自定义实现Native API函数；

所述封装单元2用于将所述自定义实现Native API函数封装为静态库lib文件；其中，所述静态库lib文件位于可执行应用程序自定义代码段中；

所述存储单元3用于将静态库lib文件保存于本地。

在使用Native API函数重构装置对Native API函数进行重构时，首先实现单元1自定义实现Native API函数，自定义实现就是通过自己编写的方式来实现Native API函数；而后封装单元2将所述Native API函数封装为静态库lib文件，常用的封装方法是将函数封装为静态库和动态库两种形式，动态库在应用程序运行时才被调用，一定程度上节省了内存空间，然而由于动态库并不存储于应用程序的代码段中，在调用时应用程序与动态库之间需要进行一定的交互，交互频繁就使得函数接口容易暴露，一旦恶意程序获悉函数接口，就可在应用程序调用动态库函数时对其进行HOOK，静态库在编译过程中就保存于应用程序的代码段(自定义代码段)中，在调用静态库函数时无需与外界进行交互，所有的调用均在应用程序代码段内部完成，这就避免了函数接口暴露；而后存储单元3将静态库lib文件保存于本地。由于应用程序和静态库是自定义实现，且存储于本地，恶意程序无法知道应用程序的存储位置，也就无法得知静态库lib文件的存储位置，从而进一步增强了调用Native API函数的安全性。

上述技术方案通过自定义实现Native API函数，并将所述Native API函数封装为静态库lib文件，并保存于本地。在应用程序运行时可以通过从静态库lib文件对应的本地存储位置中直接调用自定义Native API函数，实现应用程序的相关功能。由于Native API函数是保存于本地，恶意程序无法知道Native API函数的存储地址，也就无法对其进行非法监听、拦截或篡改等操作。此外，由于Native API函数是静态库lib文件，逆向工程分析人员无法知道静态库的接口位置，也就无法对自定义实现的Native API函数进行监听、拦截或篡改，从而从根本上杜绝了在应用层上对API函数的跟踪拦截，大大提高了应用程序的安全性，因而在计算机技术安全领域具有广阔的前景。

为了扩大自定义实现的Native API函数的适用范围，提高自定义实现的NativeAPI函数在不同运行环境下的兼容性，所述自定义实现Native API函数方法基于系统类型；所述系统类型包括32位系统或64位系统。所述自定义实现Native API函数的方法基于系统类型具体包括：

当所述系统类型为32位系统时，自定义实现32位系统的Native API函数并将其保存于所述自定义代码段中的第一指定位置。对于32位系统，不管系统是什么样的版本，如WIN8，WIN7，WINXP等，它们的Native API函数均保持一致，简言之，就是所调用Native API函数并不差别，因而在自定义实现32位系统的Native API函数时也无需进行预设处理，只需自定义编写完成后将其封装为静态库lib文件并保存于所述自定义代码段中的第一指定位置。自定义代码段即为自定义实现的应用程序代码段，当需要调用自定义实现的32位系统Native API函数时，只需从应用程序代码段的第一指定位置调用即可。

当所述系统类型为64位系统时，首先进入步骤S3自定义实现64位系统的NativeAPI函数并将其保存于所述自定义代码段中的第二指定位置。当需要调用自定义实现的64位系统Native API函数时，只需从应用程序代码段的第二指定位置调用即可。通过将自定义实现32位系统的Native API函数和64位系统的Native API函数分别存储于应用程序代码段的不同位置，提升了调用Native API函数的效率。

由于不同系统版本的Native API函数存在一定的差别，因而需要对自定义实现的64位系统的Native API函数作一定的预设处理。具体地，所述不同系统版本的Native API函数存在一定的差别表现为：WIN8系统和其他版本系统(如WIN7，WINXP，WIN2003)存在差别，下面以Native API函数中的ZwGetContextThread函数为例对WIN8系统和其他版本系统(如WIN7，WINXP，WIN2003)存在的差别作进一步说明：

对于WIN8系统的ZwGetContextThread函数的反汇编代码如下：

77E5FAD8 > B8 16000000 MOV EAX， 16

77E5FAE3 64:FF15 C0000000 CALL DWORD PTR FS:[C0]

77E5FAED C21400 RETN 14

而对于其他版本系统(如WIN7、WINXP、WIN2003、WIN2000等)的ZwGetContextThread函数的反汇编代码如下：

比较得知，对于WIN8系统的ZwGetContextThread函数与其他版本系统的差别在于少了如下3条指令：

XOR ECX，ECX

LEA EDX，DWROD PTR SS:[ESP+4]

ADD ESP，4

而对于64位系统而言，除了ZwGetContextThread函数之外的其他Native API函数同样存在类似的差异，即WIN8系统与其他版本系统的Native API函数存在着少了如上3条指令的差别。为了增强自定义实现的64位系统Native API函数的兼容性，使得无论系统是什么样的版本，都能很好地调用自定义实现的64位系统Native API函数，完成相应的功能，因而所在装置还包括整合单元4，所述整合单元4用于对自定义实现的64位系统Native API函数进行整合操作，所述整合单元4包括指令整合模块41和堆栈整合模块42，所述指令整合模块41用于设置寄存器ECX指令和设置寄存器EDX指令，堆栈整合模块4用于在调用自定义实现64位系统的Native API函数前将当前堆栈的栈顶指针ESP及栈底指针EBP的初始值保存至静态局部变量中，在调用完自定义实现64位系统的Native API函数后，将当前堆栈的栈顶指针ESP及栈底指针EBP的值替换为初始值。

在64位系统中，对于除WIN8以外的其他版本系统，在进行Native API函数调用时需要用到寄存器ECX和寄存器EDX中存储的两个参数，才可完成API函数的调用；而对于WIN8系统而言，在进行Native API函数调用时无需用到寄存器ECX和寄存器EDX中存储的两个参数，因而无需设置寄存器ECX指令和设置寄存器EDX指令，即使设置了寄存器ECX指令和设置寄存器EDX指令，也不会对WIN8系统的Native API函数造成影响。为了使得自定义实现64位系统的Native API函数在指令方面得以统一，因而在实现单元1自定义实现64位系统的Native API函数在指令方面采用除WIN8之外的其他版本系统的指令设置方式，也即指令整合模块41设置寄存器ECX指令和设置寄存器EDX指令。这样，自定义实现64位系统的NativeAPI函数不仅能够兼容除WIN8以外的其他版本系统环境下的调用，而又不影响WIN8系统环境下的调用，从而使得自定义实现64位的Native API函数在指令方面得以整合统一。

而对于堆栈整合方面，以ZwGetContextThread函数为例，从上述反汇编代码中易得，WIN8与其他版本的系统相比较，少了以下一条指令：

ADD ESP，4

简言之，除WIN8以外的其他版本系统的Native API函数与WIN8系统的Native API函数相比较，需要进行平衡堆栈操作，上述指令“ADD ESP，4”用于平衡堆栈，4为平衡堆栈的值，尽管对于不同的Native API函数所平衡堆栈的值有所差异，但对于除WIN8以外的其他版本系统的Native API函数均需要进行平衡堆栈操作。而对于WIN8系统而言，无需进行平衡堆栈操作，但是即使进行了平衡堆栈操作，也不会对Native API函数的调用产生影响。因而为了兼容除WIN8以外的其他版本系统，堆栈整合模块42在进行平衡堆栈操作时，具体包括：

在调用自定义实现64位系统的Native API函数前将当前堆栈的栈顶指针ESP及栈底指针EBP的初始值保存至静态局部变量中；

在调用完自定义实现64位系统的Native API函数后，将当前堆栈的栈顶指针ESP及栈底指针EBP的值替换为初始值。

由于Native API函数在被调用后，栈顶指针ESP及栈底指针EBP的初始值往往会发生变化，如果未对栈顶指针ESP及栈底指针EBP的初始值进行保存的话，每次调用完成后，由于需要进行平衡堆栈操作，就需要将栈顶指针ESP及栈底指针EBP的值恢复为初始值，一旦在计算过程中恢复的栈顶指针ESP及栈底指针的值发生错误，也就是说与初始值不一致，则会造成堆栈被破坏，甚至应用程序崩溃的严重后果。因而通过在调用Native API函数前将堆栈的栈顶指针ESP及栈底指针EBP的初始值保存至静态局部变量中，并在调用完成后对顶指针ESP及栈底指针EBP予以恢复初始值的方式，避免了除WIN8以外的其他版本系统的Native API函数在调用前后进行平衡堆栈时容易发生错误的问题。

为了增强自定义实现的Native API函数调用时的安全性，防止逆向分析人员或恶意程序获悉自定义实现的Native API函数的存储地址。所述装置还包括虚拟化单元5，所述虚拟化单元5用于对自定义实现的Native API函数进行虚拟化操作。所述虚拟化操作可以通过虚拟化软件来完成的，具体的，所述虚拟化步骤包括：

在需要虚拟化的Native API函数的代码中写入所述虚拟化软件的宏定义文件；在需要虚拟化的Native API函数的代码内加入一对保护宏，所述保护宏包括初始保护宏和结束保护宏，所述初始保护宏和结束保护宏分别位于所述Native API函数的代码的初始位置和结束位置；用虚拟化软件运行上述Native API函数的代码，从而生成相应的虚拟化程序文件。经过虚拟化软件处理后，逆向工程分析人员或恶意程序利用相关软件对编译的二进制进行反汇编处理后，并不能得到Native API函数代码，得到的是Native API函数虚拟化后的程序文件代码，因而无从得知虚拟化后的程序文件的用途，更无从获悉Native API函数的存储地址，从而进一步提高了自定义实现的Native API函数的安全性，进而保证了应用程序的安全。

上述技术方案通过自定义实现Native API函数，并将所述Native API函数封装为静态库lib文件，并保存于本地。且对64位系统的Native API函数进行整合处理，实现了WIN8以及其他版本系统的Native API函数在调用时的统一。并且可以对自定义实现的Native API函数的代码进行虚拟化处理，使得逆向工程分析人员或恶意程序无法获悉自定义实现的Native API函数的存储地址，也就无法对自定义实现的Native API函数进行监听、拦截或篡改，从而从根本上杜绝了在应用层上对API函数的跟踪拦截，大大提高了应用程序的安全性，因而在计算机技术安全领域具有广阔的前景。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括……”或“包含……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的要素。此外，在本文中，“大于”、“小于”、“超过”等理解为不包括本数；“以上”、“以下”、“以内”等理解为包括本数。

本领域内的技术人员应明白，上述各实施例可提供为方法、装置、或计算机程序产品。这些实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。上述各实施例涉及的方法中的全部或部分步骤可以通过程序来指令相关的硬件来完成，所述的程序可以存储于计算机设备可读取的存储介质中，用于执行上述各实施例方法所述的全部或部分步骤。所述计算机设备，包括但不限于：个人计算机、服务器、通用计算机、专用计算机、网络设备、嵌入式设备、可编程设备、智能移动终端、智能家居设备、穿戴式智能设备、车载智能设备等；所述的存储介质，包括但不限于：RAM、ROM、磁碟、磁带、光盘、闪存、U盘、移动硬盘、存储卡、记忆棒、网络服务器存储、网络云存储等。

上述各实施例是参照根据实施例所述的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到计算机设备的处理器以产生一个机器，使得通过计算机设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机设备以特定方式工作的计算机设备可读存储器中，使得存储在该计算机设备可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机设备上，使得在计算机设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已经对上述各实施例进行了描述，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改，所以以上所述仅为本发明的实施例，并非因此限制本发明的专利保护范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围之内。

Claims (2)

1.一种Native API函数重构方法，其特征在于，所述方法包括如下步骤：

自定义实现对Native API函数，对所述Native API函数进行重构，自定义实现NativeAPI函数的方法基于系统类型，所述系统类型包括32位系统或64位系统：当所述系统类型为32位系统时，自定义实现32位系统的Native API函数并将其保存于自定义代码段中的第一指定位置；或当所述系统类型为64位系统时，自定义实现64位系统的Native API函数并将其保存于所述自定义代码段中的第二指定位置；

所述自定义实现64位系统的Native API函数还包括整合操作，所述整合操作包括指令整合和堆栈整合；

所述指令整合包括设置寄存器ECX指令和设置寄存器EDX指令，所述寄存器ECX和寄存器EDX用于存储调用自定义实现64位的Native API函数的参数；

所述堆栈整合具体包括：在调用自定义实现64位系统的Native API函数前将当前堆栈的栈顶指针ESP及栈底指针EBP的初始值保存至静态局部变量中；

在调用完自定义实现64位系统的Native API函数后，将当前堆栈的栈顶指针ESP及栈底指针EBP的值替换为初始值；

将所述Native API函数封装为静态库lib文件，并保存于本地；其中，所述静态库lib文件位于自定义代码段中；

对自定义实现的Native API函数进行虚拟化操作。

2.一种Native API函数重构装置，其特征在于，所述装置包括实现单元，封装单元以及存储单元；

所述实现单元用于自定义实现Native API函数，对所述Native API函数进行重构，所述实现单元自定义实现Native API函数基于系统类型；所述系统类型包括32位系统或64位系统：当所述系统类型为32位系统时，实现单元用于自定义实现32位系统的Native API函数，存储单元用于将自定义实现32位系统的Native API函数保存于自定义代码段中的第一指定位置；或当所述系统类型为64位系统时，实现单元用于自定义实现64位系统的NativeAPI函数，存储单元用于将自定义实现64位系统的Native API函数保存于所述自定义代码段中的第二指定位置；

所述装置还包括整合单元，所述整合单元包括指令整合模块和堆栈整合模块，所述指令整合模块用于设置寄存器ECX指令和设置寄存器EDX指令，所述寄存器ECX和寄存器EDX用于存储调用自定义实现64位的Native API函数的参数；所述堆栈整合模块用于在调用自定义实现64位的Native API函数前将当前堆栈的栈顶指针ESP及栈底指针EBP的初始值保存到静态局部变量中，并在调用完自定义实现64位的Native API函数后，将当前堆栈的栈顶指针ESP及栈底指针EBP的值替换为初始值；

所述封装单元用于将所述自定义实现Native API函数封装为静态库lib文件；其中，所述静态库lib文件位于可执行应用程序自定义代码段中；

所述存储单元用于将静态库lib文件保存于本地；

还包括虚拟化单元，所述虚拟化单元用于对自定义实现的Native API函数进行虚拟化操作。