CN108062474B - 文件的检测方法及装置 - Google Patents

Abstract

本申请公开了一种文件的检测方法及装置，所述方法包括：获取待检测文件；对所述待检测文件的初始源代码进行规范化处理，以生成规范化文本；检测所述规范化文本中是否存在具有预定特征的代码；若存在具有预定特征的代码，则确定所述待检测文件为后门脚本文件。该实施方式提高了后门脚本文件检测的准确度，减小了后门脚本文件检测的误判率。

Description

文件的检测方法及装置

技术领域

本申请涉及计算机软件技术领域，尤其涉及文件的检测方法及装置。

背景技术

随着网络技术的不断发展，网络安全问题越来越被人们所重视。目前，黑客可以采用各种手段对网络进行攻击，其中，一种常见的攻击网站的方法为采用后门脚本文件攻击网站服务器。例如，一些黑客经常采用Webshell(恶意WEB后门脚本)攻击网站服务器。Webshell为一种web入侵的脚本攻击工具，在黑客入侵网站后，会将webshell文件放置在网站服务器的web目录中，与正常的网页文件混在一起。黑客可以用web的方式，通过webshell文件控制网站服务器，包括上传下载文件、查看数据库、执行任意程序命令等。

在现有技术中，一般采用正则规则检测后门脚本文件，具体来说，采用正则规则查找待检测文件中是否包括用于实现恶意目的的恶意代码，将包括恶意代码的文件确定为后门脚本文件。但是，后门脚本文件代码的编写者如果将恶意代码进行变形，就可以将恶意代码所特有的特征隐藏起来，从而躲过正则规则的检测。因此，无法准确地检测出后门脚本文件，增加了后门脚本文件检测的误判率。

发明内容

为了解决上述技术问题，本申请提供了一种文件的检测方法及装置。

根据本申请实施例的第一方面，提供一种文件的检测方法，所述方法包括：

获取待检测文件；

对所述待检测文件的初始源代码进行规范化处理，以生成规范化文本；

检测所述规范化文本中是否存在具有预定特征的代码；

若存在具有预定特征的代码，则确定所述待检测文件为后门脚本文件。

根据本申请实施例的第二方面，提供一种文件的检测装置，所述装置包括：

获取单元，用于获取待检测文件；

处理单元，用于对所述待检测文件的初始源代码进行规范化处理，以生成规范化文本；

检测单元，用于检测所述规范化文本中是否存在具有预定特征的代码；

确定单元，用于在所述规范化文本中存在具有预定特征的代码时，确定所述待检测文件为后门脚本文件。

应用上述实施例，通过将待检测文件的初始源代码进行规范化处理，以生成规范化文本，并检测规范化文本中是否存在具有预定特征的代码，若存在具有预定特征的代码，则确定该待检测文件为用于实现恶意目的后门脚本文件，使用于实现恶意目的后门脚本文件无法躲过检测。提高了后门脚本文件检测的准确度，减小了后门脚本文件检测的误判率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请文件的检测方法的一个实施例流程图；

图2为本申请文件的检测装置所在设备的一种硬件结构图；

图3为本申请文件的检测装置的一个实施例框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

参见图1，为本申请文件的检测方法的一个实施例流程图，该实施例可以应用在服务器中，包括如下步骤：

在步骤101中，获取待检测文件。

一般来说，后门脚本(如，webshell)文件会被黑客放置在服务器中，与正常的文件混在一起。因此，在本实施例中，为了检测出服务器中是否存储有后门脚本文件，需要先获取所有可能为后门脚本文件的文件作为待检测文件。例如，针对webshell文件，一般可以将所有web脚本文件作为待检测文件，待检测文件可以是由各种编程语言描述的文件，例如，C++、PHP、asp、C#、jsp语言等，本申请对待检测文件对应的具体编程语言方面不限定。

在步骤102中，对待检测文件的初始源代码进行规范化处理，以生成规范化文本。

一般来说，为了实现某种功能，编写的代码程序可以有很多种不同的表现形式，这些代码可以通过不同的表现形式实现相同的功能。例如，代码段<？php eval($_POST['op'])；？>与代码段<？php eval($_GET['op'])；？>在编写的表现形式上不同，但最终实现的功能是相同的。

还有一些代码程序也可以包含不同的中间过程(如，赋值，函数调用等中间过程)，因此，表现形式上也不相同，但最终实现的功能也是相同的。例如，<$变量1＝$变量2；$变量2＝3；>和<$变量1＝$变量5；$变量5＝$变量6；$变量6＝3；>具有不同的中间过程，在表现形式上是不同的，但最终实现的功能是相同的。

另外，用于实现恶意目的的恶意代码会具有一些预定的特征，这些预定特征是恶意代码所特有的，如果检测到一段代码具有上述的预定特征，则可以确定这段代码为用于实现恶意目的的恶意代码。所以，很多黑客可以通过将用于实现恶意目的的恶意代码的表现形式进行变形，增加一些中间过程，从而将恶意代码所特有的特征隐藏起来。例如，参见以下带有恶意代码所特有的特征的代码段：

可以将上述带有恶意代码所特有的特征的代码段进行变形，得到如下代码段：

从而隐藏了恶意代码所特有的特征。

在本实施例中，可以先将待检测文件的初始源代码进行规范化处理，消除一些冗余的中间过程，从而生成对应的规范化文本。一般来说，用于实现恶意目的的恶意代码所特有的预定特征在规范化文本中无法隐藏，因此，通过对隐藏了上述预定特征的源代码进行规范化处理后，可以使上述预定特征显现出来。

在本实施例中，由前述内容可知，不同的代码可以实现相同的功能，因此，对于一种可由代码实现的功能来说，均可以对应一种最简化和规范的表现形式，即规范化表现形式。采用规范化表现形式的代码为规范化代码，包括的代码均为规范化代码的文本为规范化文本，将任意非规范化代码转换成规范化代码的处理为规范化处理。

例如，代码段<？php eval($_POST['op'])；？>对应的规范化代码段为<？php eval($_VAR[”])；？>，对代码段<？php eval($_POST['op'])；？>进行规范化处理，可以得到规范化代码段<？php eval($_VAR[”])；？>。

又例如，对<$变量1＝$变量2；$变量2＝3；>和<$变量1＝$变量5；$变量5＝$变量6；$变量6＝3；>进行规范化处理，均可以得到<$变量1＝3；>。

再例如，初始源代码段

经过规范化处理后，可以得到规范化代码如下：

<？php

$_GET['dyn_func']($_GET['argument'])；

？>

在本实施例中，可以通过如下方式对待检测文件的初始源代码进行规范化处理。首先，生成待检测文件的初始源代码对应的Opcode(Operation code，中间语言操作码)。其中，Opcode是一种计算机能够识别的机器语言，为一种用二进制表示的中间代码，用于指定要执行的操作，每段源代码均对应唯一的Opcode。生成待检测文件的初始源代码对应的Opcode，实质上是将人能够识别的代码转换成计算机能够识别的机器语言，以方便对待检测文件的初始源代码进行规范化处理。

具体地，因为，每种不同的语言对应不同的处理方法，所以，需要先确定待检测文件的初始源代码对应的程序语言。待检测文件的初始源代码对应的程序语言可以是C++、PHP、asp、C#或jsp等，本申请对此方面不限定。然后，获取该程序语言对应的词法分析器。词法分析器可以对源代码程序进行扫描，按照语言的词法规则识别各类单词，并产生相应单词的属性字。采用上述词法分析器对初始源代码进行词法分析，可以将初始源代码由字符序列转换成对应的单词Token序列，并生成Token序列对应的Opcode。

其中，Token序列为脚本语言的一种结构化、规范化的中间态表示，例如，以PHP代码而为例，假设，初始的源代码如下：

那么将初始的源代码转换为Token序列后，结果如下：

variable$dyn_func

operator＝

variable$_get

operator[

string'dyn_func'

operator]

operator；

variable$argument

operator＝

variable$_get

operator[

string'argument'

operator]

operator；

variable$dyn_func

operator(

variable$argument

operator)

operator；

接着，对Opcode进行回溯简化处理，以获取规范化Opcode。其中，规范化Opcode是最简化的Opcode，所对应的代码为规范化代码。回溯简化处理即为通过回溯的方式将Opcode转换成规范化Opcode的处理。具体地，可以先采用回溯的方法获取上述Opcode中赋值与函数调用的传递过程对应的代码段。然后，将上述传递过程对应的代码段替换为直接赋值或函数调用的代码段，以获取规范化Opcode。

在本实施例中，赋值与函数调用的传递过程为一种中间过程，例如，<$变量1＝$变量5；$变量5＝$变量6；$变量6＝3；>，那么<$变量5＝$变量6；$变量6＝3；>，即为赋值的中间传递过程。同理，函数调用的传递过程类似。将上述传递过程对应的代码段替换为直接赋值或函数调用的代码段，即为将冗余的传递过程抵消掉，从而将代码段进行化简。例如，<$变量1＝$变量5；$变量5＝$变量6；$变量6＝3；>，其中，<$变量5＝$变量6；$变量6＝3；>为赋值的中间传递过程，将传递过程对应的代码段替换为直接赋值或函数调用的代码段后，可以得到<$变量1＝3；>。

最后，生成规范化Opcode对应的源代码，以生成规范化文本。

在步骤103中，检测规范化文本中是否存在具有预定特征的代码。

在本实施例中，首先，获取预定的检测规则，该检测规则中包括对上述预定特征的描述。其中，上述预定特征为用于实现恶意目的的恶意代码所特有的特征。因此，预定的检测规则可以用于检测恶意代码。具体来说，由于不同语言的恶意代码所特有的特征不同，所有，用于检测恶意代码的检测规则也不相同，需要先确定待检测文件的初始源代码对应的程序语言。然后获取与该程序语言对应的检测规则。

接着，采用上述检测规则从规范化文本中查找与上述预定特征匹配的代码。在一种实现方式中，可以将上述检测规则的程序加载到内存中，执行上述检测规则的程序，从而从规范化文本中查找与上述预定特征匹配的代码。若查找到与上述预定特征匹配的代码，则确定上述规范化文本中存在具有上述预定特征的代码。

在步骤104中，若存在具有预定特征的代码，则确定待检测文件为后门脚本文件。

在本实施例中，如果待检测文件中存在用于实现恶意目的的恶意代码，则可以确定该待检测文件为后门脚本文件。

应用上述实施例，通过将待检测文件的初始源代码进行规范化处理，以生成规范化文本，并检测规范化文本中是否存在具有预定特征的代码，若存在具有预定特征的代码，则确定该待检测文件为用于实现恶意目的后门脚本文件，使用于实现恶意目的后门脚本文件无法躲过检测。提高了后门脚本文件检测的准确度，减小了后门脚本文件检测的误判率。

应当注意，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。相反，流程图中描绘的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

下面结合一个完整的文件的检测方法应用实例，对本申请方案进行示意性说明。

应用场景可以为：对服务器A中的文件进行检测，以判断服务器A中是否存在webshell文件。

具体来说，首先，从服务器A中获取所有可能为webshell的文件(如，web脚本文件等)作为待检测文件。然后，针对每个待检测文件，确定初始源代码对应的程序语言，并获取该程序语言对应的词法分析器。采用该词法分析器对待检测文件的初始源代码进行词法分析，以将该初始源代码由字符序列转换成对应的单词Token序列，并生成Token序列对应的Opcode。以实现将每个待检测文件中的初始源代码均翻译成对应的Opcode。

接着，针对每个待检测文件，采用回溯的方法获取待检测文件对应的Opcode中赋值与函数调用的传递过程对应的代码段，并将该传递过程对应的代码段替换为直接赋值或函数调用的代码段，以将由初始源代码翻译而得到的Opcode转换成规范化Opcode。再将规范化Opcode翻译成对应的规范化源代码，从而完成对待检测文件的初始源代码进行规范化处理的过程，并生成了规范化文本。

最后，针对每个待检测文件，根据待检测文件的初始源代码对应的程序语言，获取用于检测该程序语言恶意代码的检测规则。采用上述检测规则检测规范化文本，以确定规范化文本中是否包括用于实现恶意目的的恶意代码。包括恶意代码的规范化文本所对应的待检测文件即为webshell文件。

可见，应用上述方案，通过对待检测文件的初始源代码进行规范化处理，获得待检测文件对应的规范化文本，从而使得包含有隐藏恶意代码的webshell文件中的恶意特征显现出来，并通过检测规则检测出webshell文件。提高了webshell文件检测的准确度，减小了webshell文件检测的误判率。

与本申请文件的检测方法的实施例相对应，本申请还提供了文件的检测装置的实施例。

本申请文件的检测装置的实施例可以应用在设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图2所示，为本申请文件的检测装置201所在设备200的一种硬件结构图，设备200包括处理器202、内存203、网络接口204、非易失性存储器205以及内部总线206，其中，处理器202、内存203、网络接口204以及非易失性存储器205相互之间可以通过内部总线206进行通信。除了图2所示的处理器202、内存203、网络接口204、非易失性存储器205以及内部总线206之外，实施例中装置所在的设备200通常根据该设备的实际功能，还可以包括其他硬件，图2中不再一一示出。

参见图3，为本申请文件的检测装置的一个实施例框图。

该装置包括：获取单元301，处理单元302，检测单元303，确定单元304。

其中，获取单元301，用于获取待检测文件。

处理单元302，用于对待检测文件的初始源代码进行规范化处理，以生成规范化文本。

检测单元303，用于检测规范化文本中是否存在具有预定特征的代码。

确定单元304，用于在规范化文本中存在具有预定特征的代码时，确定所述待检测文件为后门脚本文件。

在一个可选的实现方式中，处理单元302可以包括(图3中未示出)：

第一生成子单元，用于生成上述初始源代码对应的中间语言操作码Opcode。

回溯子单元，用于对上述Opcode进行回溯简化处理，以获取规范化Opcode。

第二生成子单元，用于生成规范化Opcode对应的源代码，作为规范化源代码。

在另一个可选的实现方式中，第一生成子单元配置用于：确定初始源代码对应的程序语言，获取上述程序语言对应的词法分析器，采用词法分析器对初始源代码进行词法分析，以将初始源代码由字符序列转换成对应的单词Token序列，并生成Token序列对应的Opcode。

在另一个可选的实现方式中，所述回溯子单元配置用于：采用回溯的方法获取上述Opcode中赋值与函数调用的传递过程对应的代码段，将传递过程对应的代码段替换为直接赋值或函数调用的代码段，以获取规范化Opcode。

在另一个可选的实现方式中，检测单元303配置用于：获取预定的检测规则，该检测规则中包括对上述预定特征的描述。采用该检测规则从规范化文本查找与上述预定特征匹配的代码。在查找到与上述预定特征匹配的代码时，确定规范化文本中存在具有预定特征的代码。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

应当理解，上述装置可以预先设置在服务器中，也可以通过下载等方式而加载到服务器中。上述装置中的相应模块单元可以与服务器中的模块单元相互配合以实现文件的检测方案。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (6)

1.一种文件的检测方法，其特征在于，所述方法包括：

获取待检测文件；

对所述待检测文件的初始源代码进行规范化处理，以生成规范化文本；所述规范化文本中无法隐藏恶意代码特有的预定特征；

检测所述规范化文本中是否存在具有预定特征的代码；

若存在具有预定特征的代码，则确定所述待检测文件为后门脚本文件；

所述对所述待检测文件的初始源代码进行规范化处理，以生成规范化文本，具体包括以下处理：

生成所述初始源代码对应的中间语言操作码Opcode，具体包括：采用词法分析器对所述初始源代码进行词法分析，将所述初始源代码由字符序列转换成对应的单词Token序列，并生成所述Token序列对应的Opcode；

对所述Opcode进行回溯简化处理，以获取规范化Opcode，具体包括：采用回溯的方法获取所述Opcode中赋值与函数调用的传递过程对应的代码段，将所述传递过程对应的代码段替换为直接赋值或函数调用的代码段，以获取规范化Opcode；

生成所述规范化Opcode对应的源代码，以生成规范化文本。

2.根据权利要求1所述的方法，其特征在于，所述生成所述初始源代码对应的Opcode，还包括：

确定所述初始源代码对应的程序语言；

获取所述程序语言对应的词法分析器。

3.根据权利要求1所述的方法，其特征在于，所述检测所述规范化文本中是否存在具有预定特征的代码，包括：

获取预定的检测规则，所述检测规则中包括对所述预定特征的描述；

采用所述检测规则从所述规范化文本中查找与所述预定特征匹配的代码；

若查找到与所述预定特征匹配的代码，则确定所述规范化文本中存在具有预定特征的代码。

4.一种文件的检测装置，其特征在于，所述装置包括：

获取单元，用于获取待检测文件；

处理单元，用于对所述待检测文件的初始源代码进行规范化处理，以生成规范化文本；所述规范化文本中无法隐藏恶意代码特有的预定特征；

检测单元，用于检测所述规范化文本中是否存在具有预定特征的代码；

确定单元，用于在所述规范化文本中存在具有预定特征的代码时，确定所述待检测文件为后门脚本文件；

所述处理单元，在用于对所述待检测文件的初始源代码进行规范化处理，以生成规范化文本时，具体用于进行以下处理：

生成所述初始源代码对应的中间语言操作码Opcode，具体包括：采用词法分析器对所述初始源代码进行词法分析，将所述初始源代码由字符序列转换成对应的单词Token序列，并生成所述Token序列对应的Opcode；

对所述Opcode进行回溯简化处理，以获取规范化Opcode，具体包括：采用回溯的方法获取所述Opcode中赋值与函数调用的传递过程对应的代码段，将所述传递过程对应的代码段替换为直接赋值或函数调用的代码段，以获取规范化Opcode；

生成所述规范化Opcode对应的源代码，以生成规范化文本。

5.根据权利要求4所述的装置，其特征在于，所述处理单元在用于生成所述初始源代码对应的Opcode时，还用于：

确定所述初始源代码对应的程序语言；

获取所述程序语言对应的词法分析器。

6.根据权利要求4所述的装置，其特征在于，所述检测单元配置用于：

获取预定的检测规则，所述检测规则中包括对所述预定特征的描述；

采用所述检测规则从所述规范化文本中查找与所述预定特征匹配的代码；

在查找到与所述预定特征匹配的代码时，确定所述规范化文本中存在具有预定特征的代码。

Images