文件修复方法及装置与流程

本申请涉及数据处理领域，具体而言，涉及一种文件修复方法及装置。

背景技术：

随着互联网安全意识的提升，应用程序提供商在发布某些软件之前，需要对该软件的应用程序包进行漏洞扫描，然而，程序员在开发过程中为了某些防止黑客逆向分析保护的程序，或者某些有意躲避漏洞扫描工具识别的恶意程序会对延迟符号(lazy_symbol)表中的函数符号名进行混淆，这些函数符号名会在反汇编中被引用。

如果在这里混淆了函数符号名，特别是系统API(Application Programming Interface，应用程序编程接口)的符号名，将导致漏洞扫描工具无法识别出系统调用，从而无法检测出相关的漏洞，降低了漏洞扫描的有效性及安全性。

针对上述的问题，目前尚未提出有效的解决方案。

技术实现要素：

本申请实施例提供了一种文件修复方法及装置，以至少解决由于现有技术中函数符号名被混淆造成的无法检测出文件漏洞的技术问题。

根据本申请实施例的一个方面，提供了一种文件修复方法，包括：获取待检测的目标文件；在确定所述待检测的目标文件是具有预定格式的可执行文件的情况下，从所述待检测的目标文件中提取延迟符号表，其中，所述延迟符号表中包含函数符号名以及索引号；依据所述延迟符号表中的索引号，获取与所述索引号对应的原始符号名；比对所述函数符号名和所述原始符号名是否相同；在所述函数符号名和所述原始符号名不相同的情况下，修正所述函数符号名，得到修复后的所述待检测的目标文件。

根据本申请实施例的另一方面，还提供了一种文件修复装置，包括：第一获取单元，用于获取待检测的目标文件；提取单元，用于在确定所述待检测的目标文件是具有预定格式的可执行文件的情况下，从所述待检测的目标文件中提取延迟符号表，其中，所述延迟符号表中包含函数符号名以及索引号；第二获取单元，用于依据所述延迟符号表中的索引号，获取与所述索引号对应的原始符号名；处理单元，用于比对所 述函数符号名和所述原始符号名是否相同，以及在所述函数符号名和所述原始符号名不相同的情况下，修正所述函数符号名，得到修复后的所述待检测的目标文件。

在本申请实施例中，采用获取待检测的目标文件；在确定待检测的目标文件是具有预定格式的可执行文件的情况下，从待检测的目标文件中提取延迟符号表，其中，延迟符号表中包含函数符号名以及索引号；依据延迟符号表中的索引号，获取与索引号对应的原始符号名；比对函数符号名和原始符号名是否相同；在函数符号名和原始符号名不相同的情况下，修正函数符号名，得到修复后的待检测的目标文件的方式，通过获取索引号对应的原始符号名，在函数符号名和原始符号名不相同的情况下修正函数符号名，达到了对被混淆的待检测的目标文件进行修复，使得漏洞扫描工具能够对被混淆的待检测的目标文件进行漏洞扫描的目的，从而实现了增强文件安全性以及漏洞扫描的有效性的技术效果，进而解决了由于现有技术中函数符号名被混淆造成的无法检测出文件漏洞的技术问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本发明实施例的一种运行文件修复方法的计算机终端的硬件结构框图；

图2是根据本申请实施例的一种可选的文件修复方法的流程示意图；

图3是根据本申请实施例的另一种可选的文件修复方法的流程示意图；

图4是根据本发明实施例的一种可选的文件修复装置的结构示意图；

图5是根据本发明实施例的另一种可选的文件修复装置的结构示意图；

图6是根据本发明实施例的一种可选的提取单元的结构示意图；

图7是根据本发明实施例的又一种可选的文件修复装置的结构示意图；

图8是根据本发明实施例的一种可选的第一获取单元的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例 仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

根据本申请实施例，还提供了一种文件修复方法的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请实施例一所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在计算机终端上为例，图1是本申请实施例的一种文件修复方法的计算机终端的硬件结构框图。如图1所示，计算机终端10可以包括一个或多个(图中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输装置106。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算机终端10还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

存储器104可用于存储应用软件的软件程序以及模块，如本申请实施例中的文件修复方法对应的程序指令/模块，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的漏洞检测方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移 动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端10的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

在上述运行环境下，本申请提供了如图2所示的文件修复方法。图2是根据本申请实施例一的文件修复方法的流程图。

如图2所示，该文件修复方法可以包括如下实现步骤：

步骤S202，获取待检测的目标文件。

本申请上述步骤S202中，待检测的目标文件可以为应用程序包中的文件，应用程序包可以为iOS应用包，文件修复装置可以对应用程序包进行解压缩，以获得上述待检测的目标文件。其中，该应用程序包可以是请求装置发送至文件修复装置的，该请求装置可以是手机客户端，也可以是计算机，本实施例对此不作限制。

步骤S204，在确定待检测的目标文件是具有预定格式的可执行文件的情况下，从待检测的目标文件中提取延迟符号表，其中，延迟符号表中包含函数符号名以及索引号。

本申请上述步骤S204中，文件修复装置在解压缩得到上述待检测的目标文件之后，可以对待检测的目标文件是否为具有预定格式的可执行文件进行判断。

以具有预定格式的可执行文件是MACH-O(Mach Object文件格式的缩写)文件为例，文件修复装置判断待检测的目标文件是否为MACH-O文件的方法可以包括：读取待检测的目标文件的前4个字节中的字符；判断待检测的目标文件的前4个字节是否为MACH-O文件格式定义的魔数(32位平台为0xFEEDFACE、64位平台为0xFEEDFACF)；若是，则确定待检测的目标文件是MACH-O文件，反之则确定待检测的目标文件不是MACH-O文件。

进而，在确定待检测的目标文件是具有预定格式的可执行文件的情况下，文件修复装置可以从待检测的目标文件中提取延迟符号表。其中，延迟符号表可以包括函数符号名以及索引号。

仍以具有预定格式的可执行文件是MACH-O文件为例，在确定待检测的目标文件是MACH-O文件的情况下，文件修复装置可以从待检测的目标文件中提取lazy_symbol 表，lazy_symbol表中包括函数符号名(也称引用的符号名)和索引号，其中，文件修复装置如何从待检测的目标文件中提取延迟符号表后续实施例中会进行详细说明，此处不做赘述。

步骤S206，依据延迟符号表中的索引号，获取与索引号对应的原始符号名。

本申请上述步骤S206中，文件修复装置在提取延迟符号表之后，可以依据延迟符号表中的索引号，获取与索引号对应的原始符号名。由于现有技术中，某些有意躲避漏洞扫描工具识别的恶意程序会对延迟符号表中的函数符号名进行混淆，也就是说延迟符号表中的函数符号名是可以被修改的，本申请的文件修复方法，即是利用不可修改的索引号，获取索引号对应的原始符号名，由于索引号不可修改，那么则认为上述原始符号名未被修改过，进而，利用原始符号名对被修改过的函数符号名进行修正。

仍以具有预定格式的可执行文件是MACH-O文件为例，文件修复装置可以使用Xcode(开发苹果应用程序的开发工具，由苹果公司提供)自带的工具dyldinfo命令：dyldinfo–lazy_bind<目标文件名>，从待检测的目标文件中获取动态链接库名称、引用的符号名等。

需要说明的是，dyldinfo–lazy_bind命令由苹果公司提供，该dyldinfo–lazy_bind命令可以输出MACH-O文件中的lazy绑定的相关信息：如地址偏移、索引号、动态链接库名称、函数符号名，原理是dyldinfo命令会根据索引号获取其对应的原始符号名称。

步骤S208，比对函数符号名和原始符号名是否相同。

本申请上述步骤S208中，文件修复装置在获取到与索引号对应的原始符号名之后，将函数符号名与原始符号名进行比对，判断函数符号名和原始符号名是否相同。

步骤S210，在函数符号名和原始符号名不相同的情况下，修正函数符号名，得到修复后的待检测的目标文件。

本申请上述步骤S210中，在比对出函数符号名和原始符号名不相同的情况下，文件修复装置可以利用原始符号名对函数符号名进行修正。可选地，比对函数符号名和原始符号名是否相同；在函数符号名和原始符号名不相同的情况下，修正函数符号名，可以包括：重复执行以下操作，直到遍历完所有函数符号名：将第i个函数符号名与第i个原始符号名进行比较；若第i个函数符号名与第i个原始符号名不相同，则将第i个函数符号名修改为第i个原始符号名，其中，i为自然数。

仍以具有预定格式的可执行文件是MACH-O文件为例，文件修复装置将从 lazy_symbol表中获取到的函数符号名记为lst；将从获取到的与索引号对应的原始符号名记为dst；遍历lst，lst[i]所指向的函数符号名不等于dst[i]所指向的原始符号名，则认为该待检测的目标文件的函数符号名被混淆处理过，然后修改该待检测的目标文件中lst[i]所指向的函数符号名为dst[i]把指向的原始符号名，其中，lst[i]表示lst中的第i个函数符号名，dst[i]表示dst中第i个原始符号名。

在函数符号名和原始符号名不相同的情况下，文件修复装置修正函数符号名，进而得到修复后的待检测的目标文件。由于本实施例的文件修复方法对被混淆的函数符号名进行了修正，因此修复后的待检测的目标文件不会出现因函数符号名被混淆而导致的漏洞扫描工具无法识别出系统调用，从而无法检测出相关的漏洞的问题。

由上可知，本申请上述实施例一所提供的方案，通过获取索引号对应的原始符号名，在函数符号名和原始符号名不相同的情况下修正函数符号名，达到了对被混淆的待检测的目标文件进行修复，使得漏洞扫描工具能够对被混淆的待检测的目标文件进行漏洞扫描的目的，从而实现了增强文件安全性以及漏洞扫描的有效性的技术效果，进而解决了由于现有技术中函数符号名被混淆造成的无法检测出文件漏洞的技术问题。

作为一种可选的实现方式，上述步骤S208，比对函数符号名和原始符号名是否相同；步骤S210，在函数符号名和原始符号名不相同的情况下，修正函数符号名，可以包括：

步骤S10，重复执行以下操作，直到遍历完所有函数符号名：将第i个函数符号名与第i个原始符号名进行比较；若第i个函数符号名与第i个原始符号名不相同，则将第i个函数符号名修改为第i个原始符号名，其中，i为自然数。

本申请上述步骤S10中，文件修复装置可以对函数符号名和原始符号名进行一一对比，由于在一个延迟符号表中，函数符号名和原始符号名的数量均为多个，因此文件修复装置可以从第1个函数符号名开始与第1个原始符号名进行比对，若第1个函数符号名与第1个原始符号名不相同，则将第1个函数符号名修改为第1个原始符号名，再将第2个函数符号名与第2个原始符号名进行比对，以此类推，直到将多个函数符号名与原始符号名一一比对并修正完毕。

需要说明的是，上述仅是示例性地对文件修复装置如何比对函数符号名和原始符号名是否相同的方法进行说明，文件修复装置也可以采用逆序的顺序比对函数符号名和原始符号名，还可以采用预定的顺序比对函数符号名和原始符号名，均应在本实施例的保护范围之内。

作为一种可选的实现方式，确定待检测的目标文件是具有预定格式的可执行文件，包括：

步骤S20，读取待检测的目标文件的前n个字节中的字符，n为大于0的整数。

本申请上述步骤S20中，文件修复装置可以对具有预定格式的可执行文件进行修复，那么首先，文件修复装置在获取到待检测的目标文件之后需要判断待检测的目标文件是否为具有预定格式的可执行文件。可选地，文件修复装置可以读取待检测的目标文件的前n个字节中的字符。

以具有预定格式的可执行文件是MACH-O文件为例，文件修复装置判断待检测的目标文件是否为MACH-O文件的方法可以为读取待检测的目标文件的前4个字节中的字符，进而通过该前4个字节中的字符进行判断。

步骤S22，判断字符是否为具有预定格式的可执行文件对应的魔数，其中，魔数用于指示文件类型。

本申请上述步骤S22中，文件修复装置在读取了待检测的目标文件的前n个字节中的字符之后，可以判断该字符是否为具有预定格式的可执行文件对应的魔数。很多类型的文件，其起始的几个字节的内容是固定的(或是有意填充，或是本就如此)，根据这几个字节的内容就可以确定文件类型，因此这几个字节的内容被称之为魔数。由于不同类型的文件具有其对应的魔数(也称魔术字)，因此本实施例的文件修复装置即是通过判断待检测的目标文件的前n个字节中的字符是否为具有预定格式的可执行文件对应的魔数，来判断待检测的目标文件是否为具有预定格式的可执行文件。

仍以具有预定格式的可执行文件是MACH-O文件为例，文件修复装置通过判断待检测的目标文件的前4个字节中的字符是否为MACH-O文件格式定义的魔数，来判断待检测的目标文件是否为MACH-O文件(32位平台对应的魔数为0xFEEDFACE、64位平台对应的魔数为0xFEEDFACF)；若是，则确定待检测的目标文件是MACH-O文件，反之则确定待检测的目标文件不是MACH-O文件。

步骤S24，若字符为魔数，则确定待检测的目标文件是具有预定格式的可执行文件。

本申请上述步骤S24中，文件修复装置通过判断待检测的目标文件的前n个字节中的字符是否为具有预定格式的可执行文件对应的魔数，在待检测的目标文件的前n个字节中的字符为该具有预定格式的可执行文件对应的魔数的情况下，确定待检测的目标文件是具有预定格式的可执行文件。

作为一种可选的实现方式，从待检测的目标文件中提取延迟符号表，可以包括：

步骤S30，对待检测的目标文件进行解析，确定延迟符号表在待检测的目标文件中的偏移量。

本申请上述步骤S30中，文件修复装置为了从待检测的目标文件中提取延迟符号表，首先需要对待检测的目标文件进行解析，确定延迟符号表在待检测的目标文件中的偏移量。具体地，文件修复装置可以依据待检测的目标文件的文件头最终确定延迟符号表在待检测的目标文件中的偏移量。

以待检测的目标文件为MACH-O文件为例，MACH-O文件可以包括加载命令区、数据区以及具有第一长度的文件头，上述的加载命令区即为Load command，数据区可以按照segment来划分，segment中又包含了多个section。

示例性地，MACH-O文件的文件头格式可以包括：

其中，文件头后面就是load command区，然后根据文件头的ncmds和sizeofcmds字段可以定位后续所有的load command数据，进而确定延迟符号表的偏移量。

步骤S32，基于偏移量提取延迟符号表。

本申请上述步骤S32中，文件修复装置通过获取到的延迟符号表的偏移量从待检测的目标文件中提取延迟符号表。

可选地，待检测的目标文件包括加载命令区、数据区以及具有第一长度的文件头；其中，上述步骤S30，对待检测的目标文件进行解析，确定延迟符号表在待检测的目标文件中的偏移量，可以包括：

步骤S40，依据具有第一长度的文件头遍历加载命令区，在数据区中确定延迟符号表的偏移量。

本申请上述步骤S40中，文件修复装置可以依据文件头中的内容定位后续所有的加载命令区的数据，进而，文件修复装置可以依据遍历加载命令区，在数据区中确定延迟符号表的偏移量。

以待检测的目标文件为MACH-O文件为例，MACH-O文件的Load command格式可以包括：

其中，load_command中的命令类型cmd和整个命令长度这两个信息是固定格式，都占据了前8个字节。

例如，LC_SEGMENT这条命令，结构如下：

其中，load command里面除了LC_SEGMENT这个命令，还有LC_ID_DYLIB、LC_DYLD_INFO、LC_SYMTAB等其余20余种command，每个command都有自己的功能，在此不再赘述。

在LC_SEGMENT里面，根据LC_SEGMENT的结构的fileoff、nsects可以定位和遍历所有的segment。由此可知，具体section个数由segment结构中的nsects决定。

作为一种可选的实现方式，如图3所示，上述步骤S40，依据具有第一长度的文件头遍历加载命令区，在数据区中确定延迟符号表的偏移量，可以包括：

步骤S302，将距离待检测的目标文件的起始位置第一长度处确定为第一个加载命令区的起始位置。

本申请上述步骤S302中，由于待检测的目标文件的结构由具有第一长度的文件头、加载命令区以及数据区组成，并且加载命令区就在具有第一长度的文件头之后，因此文件修复装置首先可以将距离待检测的目标文件的起始位置第一长度处确定为第一个加载命令区的起始位置。假设文件头的长度为3字节，那么文件修复装置则将距离待检测的目标文件的起始位置3字节的地方，确定为第一个加载命令区的起始位置。

步骤S304，根据具有第一长度的文件头中的ncmds字段,确定加载命令区的个数。

本申请上述步骤S304中，文件修复装置在确定了第一个加载命令区的起始位置后，需要确定加载命令区的个数，通常加载命令区有多个(20多个)，文件修复装置通过文件头的ncmds字段来确定加载命令区的个数。

步骤S306，根据第一个加载命令区的起始位置以及加载命令区的个数，确定数据区的起始位置。

本申请上述步骤S306中，文件修复装置在确定了第一个加载命令区的起始位置以及加载命令区的个数之后，可以根据第一个加载命令区的起始位置以及加载命令区的个数，确定每个加载命令区的起始位置，由于数据区就在最后一个加载命令区之后，因此文件修复装置可以确定数据区的起始位置。

以待检测的目标文件为MACH-O文件为例，MACH-O文件的数据区可以按照segment来划分，segment中又包含了多个section，其中，section的结构可以包括：

步骤S308，从数据区的头结构中获取延迟符号表的偏移量以及延迟符号表的字节数。

本申请上述步骤S308中，文件修复装置在确定数据区的起始位置之后，在数据区的头结构中，获取延迟符号表的偏移量以及延迟符号表的字节数，以待检测的目标文件为MACH-O文件为例，在数据区的头结构(Section Header)中，第56字节偏移处的4个字节为节类型，如果等于0x7则表示为S_LAZY_SYMBOL_POINTORS，即延迟符号(lazy symbol)的节头，第40字节偏移的4个字节为延迟符号表在Mach-O文件的偏移，第36字节偏移的4个字节为延迟符号表的大小(字节数)。

步骤S310，在距离数据区的起始位置的偏移量处，确定延迟符号表的起始位置。

本申请上述步骤S310中，文件修复装置在获取延迟符号表的偏移量以及延迟符号表的字节数之后，可以在距离数据区的起始位置的偏移量处，确定延迟符号表的起始位置，进而根据延迟符号表的字节数获取延迟符号表。

其中，基于偏移量提取延迟符号表，包括：根据延迟符号表的起始位置以及延迟符号表的字节数，提取延迟符号表。

下面，以待检测的目标文件为MACH-O文件，从lazy_symbol(延迟符号)表中获取函数符号名以及索引号的过程进行示例性说明：

步骤A、从待检测的目标文件的起始位置跳到0x1c偏移，即为Load Command起始位置。

其中，自Load Command起始位置起读取8个字节，前4个字节为加载命令类型，后4字节为该结构的大小。

步骤B、如果加载命令类型为0x1，即为LC_SEGMENT命令，继续读取48个字节，为段(Segment)结构。

步骤C、继续读取68个字节，即为节头(Section Header)结构。

其中，在节头(Section Header)结构中，第56字节偏移处的4个字节为节类型，如果等于0x7则表示为S_LAZY_SYMBOL_POINTORS，即延迟符号(lazy symbol)的节头，第40字节偏移的4个字节为延迟符号表在MACH-O文件的偏移，第36字节偏移的4个字节为延迟符号表的大小(字节数)。

步骤D、从延迟符号表偏移开始读取延迟符号表中的数据，读取长度为上述延迟符号表的大小。

其中，延迟符号表中每4个字节表示一个符号。

可选地，读取符号表(Symbols)和字符串表(String)：在解析Load Command时，如果类型为0x2，即为LC_SYMTAB命令，然后继续读取16字节，在第0字节偏移的4字节为符号表偏移；在第8字节偏移的4字节为字符串表偏移。

读取动态符号表(Dynamic Symbol)：在解析Load Command时，如果类型为0xB，即为LC_DYSYMTAB命令，然后继续读取72字节，在第48字节偏移的4字节为动态符号表的文件偏移地址。

步骤E、获取函数符号名。

其中，函数符号名的获取方法如下：

a)将某函数符号名在延迟符号表中的索引号记为index，然后读取动态符号表(Dynamic Symbol)的index位置的值记为index2；

b)在符号表(Symbols)的index2位置读取前4字节值，记为offset；

c)将字符串表偏移加上offset，即可得到函数符号名偏移，拿这个偏移值从MACH-O文件读取以0x00为截至的若干字节，即为函数符号名。

至此，文件修复装置从lazy_symbol(延迟符号)表中获取函数符号名以及索引号。

可选地，本实施例的文件修复方法还可以包括：

步骤S50，若第i个函数符号名与第i个原始符号名不相同，则确定待检测的目标文件被混淆。

本申请上述步骤S50中，文件修复装置不但可以对待检测的目标文件进行修复，还可以在确定待检测的目标文件被混淆时进行提示。即，文件修复装置在判断出第i个函数符号名与第i个原始符号名不相同的情况下，则确定待检测的目标文件被混淆(函数符号名被修改)，进而输出提示消息。

步骤S52，输出提示消息，提示消息用于指示待检测的目标文件被混淆。

本申请上述步骤S52中，文件修复装置在确定待检测的目标文件被混淆之后，可以输出用于指示待检测的目标文件被混淆的提示消息，用于标记该待检测的目标文件。 同时，文件修复装置也可以在该待检测的目标文件添加用于指示待检测的目标文件的标识信息，本实施例对此不做限定。

作为一种可选的实现方式，上述步骤S201，获取待检测的目标文件可以包括：

步骤S60，接收请求装置发送的应用程序包。

本申请上述步骤S60中，文件修复装置获取到的应用程序包可以为请求装置发送至文件修复装置的，该请求装置可以是手机客户端，也可以是计算机，该应用程序包可以是基于iOS系统生成的数据包，也可以是基于Mac OS系统生成的数据包，本实施例对此不做限定。

步骤S62，对应用程序包进行解压缩，得到待检测的目标文件。

本申请上述步骤S62中，文件修复装置在接收到请求装置发送应用程序包之后，可以对应用程序包进行解压缩，进而得到上述待检测的目标文件。

其中，在待检测的目标文件是具有预定格式的可执行文件的情况下，待检测的目标文件为可执行文件，请求装置为基于iOS系统的设备或基于Mac OS系统的设备，具有预定格式的可执行文件为MACH-O文件，魔数为0xFEEDFACE或者0xFEEDFACF。

在本申请实施例中，采用获取待检测的目标文件；在确定待检测的目标文件是具有预定格式的可执行文件的情况下，从待检测的目标文件中提取延迟符号表，其中，延迟符号表中包含函数符号名以及索引号；依据延迟符号表中的索引号，获取与索引号对应的原始符号名；比对函数符号名和原始符号名是否相同；在函数符号名和原始符号名不相同的情况下，修正函数符号名，得到修复后的待检测的目标文件的方式，通过获取索引号对应的原始符号名，在函数符号名和原始符号名不相同的情况下修正函数符号名，达到了对被混淆的待检测的目标文件进行修复，使得漏洞扫描工具能够对被混淆的待检测的目标文件进行漏洞扫描的目的，从而实现了增强文件安全性以及漏洞扫描的有效性的技术效果，进而解决了由于现有技术中函数符号名被混淆造成的无法检测出文件漏洞的技术问题。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施 例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

实施例2

根据本申请实施例，还提供了一种用于实施上述方法实施例的装置实施例，本申请上述实施例所提供的装置可以在计算机终端上运行。

图4是根据本申请实施例的文件修复装置的结构示意图。

如图4所示，该文件修复装置可以包括第一获取单元402、提取单元404、第二获取单元406以及处理单元408。

其中，第一获取单元402，用于获取待检测的目标文件；提取单元404，用于在确定所述待检测的目标文件是具有预定格式的可执行文件的情况下，从所述待检测的目标文件中提取延迟符号表，其中，所述延迟符号表中包含函数符号名以及索引号；第二获取单元406，用于依据所述延迟符号表中的索引号，获取与所述索引号对应的原始符号名；处理单元408，用于比对所述函数符号名和所述原始符号名是否相同，以及在所述函数符号名和所述原始符号名不相同的情况下，修正所述函数符号名，得到修复后的所述待检测的目标文件。

由上可知，本申请上述实施例二所提供的方案，通过获取索引号对应的原始符号名，在函数符号名和原始符号名不相同的情况下修正函数符号名，达到了对被混淆的待检测的目标文件进行修复，使得漏洞扫描工具能够对被混淆的待检测的目标文件进行漏洞扫描的目的，从而实现了增强文件安全性以及漏洞扫描的有效性的技术效果，进而解决了由于现有技术中函数符号名被混淆造成的无法检测出文件漏洞的技术问题。

此处需要说明的是，上述第一获取单元402、提取单元404、第二获取单元406以及处理单元408对应于实施例一中的步骤S202至步骤S210，四个模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例一所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在实施例一提供的计算机终端10中，可以通过软件实现，也可以通过硬件实现。

可选地，所述处理单元408用于执行以下步骤比对所述函数符号名和所述原始符 号名是否相同，以及在所述函数符号名和所述原始符号名不相同的情况下，修正所述函数符号名：重复执行以下操作，直到遍历完所有函数符号名：将第i个函数符号名与第i个原始符号名进行比较；若所述第i个函数符号名与所述第i个原始符号名不相同，则将所述第i个函数符号名修改为所述第i个原始符号名，其中，i为自然数。

可选地，如图5所示，文件修复装置还可以包括确定单元502。

其中，所述确定单元502用于执行以下步骤确定所述待检测的目标文件是所述具有预定格式的可执行文件：读取所述待检测的目标文件的前n个字节中的字符，n为大于0的整数；判断所述字符是否为所述具有预定格式的可执行文件对应的魔数，其中，所述魔数用于指示文件类型；若所述字符为所述魔数，则确定所述待检测的目标文件是所述具有预定格式的可执行文件。

此处需要说明的是，上述确定单元502对应于实施例一中的步骤S20至步骤S24，该模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例一所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在实施例一提供的计算机终端10中，可以通过软件实现，也可以通过硬件实现。

可选地，如图6所示，提取单元404可以包括解析模块602和提取模块604。

其中，解析模块602，用于对所述待检测的目标文件进行解析，确定所述延迟符号表在所述待检测的目标文件中的偏移量；提取模块604，用于基于所述偏移量提取所述延迟符号表。

此处需要说明的是，上述解析模块602和提取模块604对应于实施例一中的步骤S30至步骤S34，该模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例一所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在实施例一提供的计算机终端10中，可以通过软件实现，也可以通过硬件实现。

可选地，所述待检测的目标文件包括加载命令区、数据区以及具有第一长度的文件头；其中，所述解析模块602用于执行以下步骤对所述待检测的目标文件进行解析，确定所述延迟符号表在所述待检测的目标文件中的偏移量：依据所述具有第一长度的文件头遍历所述加载命令区，在所述数据区中确定所述延迟符号表的偏移量。

可选地，所述解析模块602用于执行以下步骤依据所述具有第一长度的文件头遍历所述加载命令区，在所述数据区中确定所述延迟符号表的偏移量：将距离所述待检测的目标文件的起始位置所述第一长度处确定为第一个加载命令区的起始位置；根据所述具有第一长度的文件头中的ncmds字段,确定所述加载命令区的个数；根据第一个加载命令区的起始位置以及加载命令区的个数，确定所述数据区的起始位置；从所 述数据区的头结构中获取所述延迟符号表的偏移量以及所述延迟符号表的字节数；在距离所述数据区的起始位置的所述偏移量处，确定所述延迟符号表的起始位置。

其中，所述提取模块604用于执行以下步骤基于所述偏移量提取所述延迟符号表：根据所述延迟符号表的起始位置以及所述延迟符号表的字节数，提取所述延迟符号表。

下面，以待检测的目标文件为MACH-O文件，从lazy_symbol(延迟符号)表中获取函数符号名以及索引号的过程进行示例性说明：

步骤A、从待检测的目标文件的起始位置跳到0x1c偏移，即为Load Command起始位置。

其中，自Load Command起始位置起读取8个字节，前4个字节为加载命令类型，后4字节为该结构的大小。

步骤B、如果加载命令类型为0x1，即为LC_SEGMENT命令，继续读取48个字节，为段(Segment)结构。

步骤C、继续读取68个字节，即为节头(Section Header)结构。

其中，在节头(Section Header)结构中，第56字节偏移处的4个字节为节类型，如果等于0x7则表示为S_LAZY_SYMBOL_POINTORS，即延迟符号(lazy symbol)的节头，第40字节偏移的4个字节为延迟符号表在MACH-O文件的偏移，第36字节偏移的4个字节为延迟符号表的大小(字节数)。

步骤D、从延迟符号表偏移开始读取延迟符号表中的数据，读取长度为上述延迟符号表的大小。

其中，延迟符号表中每4个字节表示一个符号。

可选地，读取符号表(Symbols)和字符串表(String)：在解析Load Command时，如果类型为0x2，即为LC_SYMTAB命令，然后继续读取16字节，在第0字节偏移的4字节为符号表偏移；在第8字节偏移的4字节为字符串表偏移。

读取动态符号表(Dynamic Symbol)：在解析Load Command时，如果类型为0xB，即为LC_DYSYMTAB命令，然后继续读取72字节，在第48字节偏移的4字节为动态符号表的文件偏移地址。

步骤E、获取函数符号名。

其中，函数符号名的获取方法如下：

a)将某函数符号名在延迟符号表中的索引号记为index，然后读取动态符号表(Dynamic Symbol)的index位置的值记为index2；

b)在符号表(Symbols)的index2位置读取前4字节值，记为offset；

c)将字符串表偏移加上offset，即可得到函数符号名偏移，拿这个偏移值从MACH-O文件读取以0x00为截至的若干字节，即为函数符号名。

至此，文件修复装置从lazy_symbol(延迟符号)表中获取函数符号名以及索引号。

可选地，所述处理单元408，还用于若所述第i个函数符号名与所述第i个原始符号名不相同，则确定所述待检测的目标文件被混淆。

可选地，如图7所示，文件修复装置还可以包括：输出单元702。

其中，输出单元702，用于输出提示消息，所述提示消息用于指示所述待检测的目标文件被混淆。

此处需要说明的是，上述输出单元702对应于实施例一中的步骤S52，该模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例一所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在实施例一提供的计算机终端10中，可以通过软件实现，也可以通过硬件实现。

可选地，如图8所示，所述第一获取单元402可以包括：接收模块802和解压缩模块804。

其中，接收模块802，用于接收请求装置发送的应用程序包；解压缩模块804，用于对所述应用程序包进行解压缩，得到所述待检测的目标文件；其中，在所述待检测的目标文件是所述具有预定格式的可执行文件的情况下，所述请求装置为基于iOS系统的设备或基于Mac OS系统的设备，所述具有预定格式的可执行文件为MACH-O文件，所述魔数为0xFEEDFACE或者0xFEEDFACF。

此处需要说明的是，上述接收模块802和解压缩模块804对应于实施例一中的步骤S60至步骤S62，该模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例一所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在实施例一提供的计算机终端10中，可以通过软件实现，也可以通过硬件实现。

在本申请实施例中，采用获取待检测的目标文件；在确定所述待检测的目标文件是具有预定格式的可执行文件的情况下，从所述待检测的目标文件中提取延迟符号表， 其中，所述延迟符号表中包含函数符号名以及索引号；依据所述延迟符号表中的索引号，获取与所述索引号对应的原始符号名；比对所述函数符号名和所述原始符号名是否相同；在所述函数符号名和所述原始符号名不相同的情况下，修正所述函数符号名得到修复后的所述待检测的目标文件的方式，通过获取索引号对应的原始符号名，在函数符号名和原始符号名不相同的情况下修正函数符号名，达到了对被混淆的待检测的目标文件进行修复，使得漏洞扫描工具能够对被混淆的待检测的目标文件进行漏洞扫描的目的，从而实现了增强文件安全性以及漏洞扫描的有效性的技术效果，进而解决了由于现有技术中函数符号名被混淆造成的无法检测出文件漏洞的技术问题。

实施例3

本申请的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于保存上述实施例一所提供的文件修复方法所执行的程序代码。

可选地，在本实施例中，上述存储介质可以位于计算机网络中计算机终端群中的任意一个计算机终端中，或者位于移动终端群中的任意一个移动终端中。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：获取待检测的目标文件；在确定所述待检测的目标文件是具有预定格式的可执行文件的情况下，从所述待检测的目标文件中提取延迟符号表，其中，所述延迟符号表中包含函数符号名以及索引号；依据所述延迟符号表中的索引号，获取与所述索引号对应的原始符号名；比对所述函数符号名和所述原始符号名是否相同；在所述函数符号名和所述原始符号名不相同的情况下，修正所述函数符号名，得到修复后的所述待检测的目标文件。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：重复执行以下操作，直到遍历完所有函数符号名：将第i个函数符号名与第i个原始符号名进行比较；若所述第i个函数符号名与所述第i个原始符号名不相同，则将所述第i个函数符号名修改为所述第i个原始符号名，其中，i为自然数。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：读取所述待检测的目标文件的前n个字节中的字符，n为大于0的整数；判断所述字符是否为所述具有预定格式的可执行文件对应的魔数，其中，所述魔数用于指示文件类型；若所述字符为所述魔数，则确定所述待检测的目标文件是所述具有预定格式的可执行文件。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：对所述待检测的目标文件进行解析，确定所述延迟符号表在所述待检测的目标文件中的偏移量；基 于所述偏移量提取所述延迟符号表。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：依据所述具有第一长度的文件头遍历所述加载命令区，在所述数据区中确定所述延迟符号表的偏移量。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：将距离所述待检测的目标文件的起始位置所述第一长度处确定为第一个加载命令区的起始位置；根据所述具有第一长度的文件头中的ncmds字段,确定所述加载命令区的个数；根据第一个加载命令区的起始位置以及加载命令区的个数，确定所述数据区的起始位置；从所述数据区的头结构中获取所述延迟符号表的偏移量以及所述延迟符号表的字节数；在距离所述数据区的起始位置的所述偏移量处，确定所述延迟符号表的起始位置。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：根据所述延迟符号表的起始位置以及所述延迟符号表的字节数，提取所述延迟符号表。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：若所述第i个函数符号名与所述第i个原始符号名不相同，则确定所述待检测的目标文件被混淆；输出提示消息，所述提示消息用于指示所述待检测的目标文件被混淆。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：接收请求装置发送所述应用程序包；对所述应用程序包进行解压缩，得到所述待检测的目标文件；其中，在所述待检测的目标文件是所述具有预定格式的可执行文件的情况下，所述待检测的目标文件为可执行文件，所述请求装置为基于iOS系统的设备或基于Mac OS系统的设备，所述具有预定格式的可执行文件为MACH-O文件，所述魔数为0xFEEDFACE或者0xFEEDFACF。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的订单信息的处理装置， 可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

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