恶意文件的检测方法、装置、设备及存储介质与流程

本申请涉及计算机
技术领域：
：，特别涉及一种恶意文件的检测方法、装置、设备及存储介质。
背景技术：
：：恶意文件是指包含有程序设计者出于攻击意图所编写的一段程序的文件。恶意文件能够在网络中传播，计算机能够从网络中接收到恶意文件。当计算机运行恶意文件时，会根据恶意文件包含的程序，执行信息窃取、感染或者勒索等恶意操作，极大地影响网络系统的安全性。有鉴于此，恶意文件的检测技术成为本领域的研究热点。基于虚拟化运行环境的动态行为检测是一种新型的恶意文件检测技术。这一检测技术的优势在于能够发现未知的新的恶意文件。这一技术的基本原理是利用虚拟化技术生成一个和用户主机类似的虚拟化运行环境，例如一个虚拟机。在虚拟化运行环境中设置钩子函数，钩子函数用于拦截预定的应用编程接口(applicationprogramminginterface，api)调用。在虚拟化运行环境中运行测试文件(即待检测的文件)，通过钩子函数获取待检测文件在运行过程中的一系列api调用，从而得到测试文件的动态行为。进一步根据得到的测试文件的动态行为判断测试文件是否是恶意文件。目前的检测技术存在应用的局限性。例如从使用场景上看，目前的虚拟化技术只能运行于支持微软视窗操作系统(windows)操作系统的检测设备中，否则测试文件无法运行而无法实现检测。技术实现要素：本申请实施例提供了一种恶意文件的检测方法、装置、设备及存储介质，能够一定程度上解决现有恶意文件检测技术的局限性。第一方面，提供了一种恶意文件的检测方法，在该方法中，检测设备获取测试文件，所述测试文件为基于第一操作系统运行的可执行文件；所述检测设备在虚拟运行环境中运行所述测试文件，所述虚拟运行环境是基于容器技术生成的；所述检测设备获取所述测试文件在运行过程中调用的第一api序列，所述第一api序列中包括至少一个api，所述第一api序列包括的api为第一api集合中的api，所述第一api集合包括所述虚拟运行环境提供的软件运行所需的多个api，所述第一api集合中的api的标识与第二api集合中的api的标识相同，所述第二api集合包括所述第一操作系统提供的软件运行所需的多个api；所述检测设备在第二操作系统中执行第二api序列，所述第二api序列中包括至少一个api，所述第二api序列包括的api为所述第二操作系统中的api，所述第二api序列中的第一api与所述第一api序列中的第一api具有映射关系，所述第二操作系统是基于所述检测设备的计算机指令集架构的操作系统；所述检测设备基于所述第一api序列被调用过程中所述测试文件的行为特征，判断所述测试文件是否为恶意文件。本申请实施例通过基于容器技术生成的虚拟运行环境，模拟出兼容测试文件的操作系统提供的运行环境。测试文件调用了虚拟运行环境提供的api后，检测设备将虚拟运行环境被测试文件调用的api，转换为检测设备的操作系统提供的api，在检测设备的操作系统中执行转换后的api。由于通过执行检测设备的操作系统的api，达到了模拟执行第一操作系统的api的效果。因此，检测设备提供的虚拟运行环境能够兼容测试文件的正常运行，从而摆脱了测试文件对特定架构或平台的依赖(即测试文件要求检测设备必须基于特定的架构或平台)，因此能够一定程度上解决现有恶意文件检测技术的局限性。此外，可以实现了跨平台的恶意程序检测。此外，由于虚拟运行环境是基于容器技术生成的，容器技术可以免去hypervisor以及guestos带来的资源开销，直接利用主机的内核运行。由于容器的镜像的大小远远小于虚拟机的镜像的大小，因此本申请实施例的检测方法更加轻量化，消耗的cpu处理资源更少，占用的内存空间更少。本申请实施例的检测方法在进程级别实现恶意程序的运行，检测速度更快。并且，可以避免虚拟机反复重置带来的耗时和性能开销，避免传统的虚拟机的创建、调度等操作带来的开销。可选地，所述检测设备在第二操作系统中执行第二api序列，包括：所述检测设备根据所述第一api序列中的每个api，分别从所述虚拟运行环境的动态链接库中获取对应的函数，从而获得第一函数序列，所述第一函数序列包括的函数用于实现所述第一api序列中包括的api；所述检测设备根据所述第一函数序列中的每个函数，分别从所述第二操作系统的动态链接库中获取映射的函数，从而生成第二函数序列，所述第二函数序列包括的函数用于实现所述第二api序列中包括的api，所述第二函数序列中的第一函数与所述第一函数序列中的第一函数具有映射关系；所述检测设备在所述第二操作系统的内核中，根据所述第二函数序列执行操作。上述过程提供了一种操作系统模拟的可选实现方式。将虚拟运行环境中实现api的函数封装在动态链接库中，将检测设备的操作系统中实现api的函数封装在另一个动态链接库中。当虚拟运行环境的api序列被调用时，通过依次访问不同的动态链接库，找到检测设备的操作系统提供的功能类似的函数序列。通过执行函数序列，模拟出执行第一操作系统的api序列的效果，从而实现了系统模拟的目的，使得测试文件能够在虚拟运行环境下正常运行，从而摆脱了测试文件对第一操作系统的依赖。可选地，所述第一操作系统为windows操作系统，所述第二操作系统为linux操作系统，所述检测设备根据所述第一api序列中的每个api，分别从所述虚拟运行环境的动态链接库中获取对应的函数，包括：所述检测设备根据所述第一api序列中的每个api，分别从动态链接库dll文件中获取对应的函数；所述检测设备根据所述第一函数序列中的每个函数，分别从所述第二操作系统的动态链接库中获取映射的函数，包括：所述检测设备根据所述第一函数序列中的每个函数以及函数之间的映射关系，分别从共享对象so文件中获取映射的函数。上述过程提供了一种linux操作系统下模拟windows操作系统的可选实现方式。将虚拟运行环境中实现api的函数封装在dll文件，将linux操作系统中实现api的函数封装在so文件中。在测试文件运行的过程中，当虚拟运行环境的api序列被调用时，通过依次访问dll文件以及so文件，找到linux操作系统提供的与windows操作系统功能类似的函数序列。通过执行函数序列，模拟出执行windows操作系统的api序列的效果，从而实现了系统模拟的目的，使得测试文件能够在虚拟运行环境下正常运行，从而摆脱了测试文件对windows操作系统的依赖。如此，即使测试文件是pe文件，而检测设备的操作系统是linux操作系统，利用该方法，能够在linux操作系统下动态检测pe文件，从而摆脱检测pe文件对windows操作系统的依赖，因此基于非x86平台的检测设备能够动态检测基于windows系统运行的测试文件，从而扩展了恶意文件检测技术的使用场景。可选地，所述第一操作系统为linux操作系统，所述第二操作系统为windows操作系统，所述检测设备根据所述第一api序列中的每个api，分别从所述虚拟运行环境的动态链接库中获取对应的函数，包括：所述检测设备根据所述第一api序列中的每个api，分别从so文件中获取对应的函数；所述检测设备根据所述第一函数序列中的每个函数，分别从所述第二操作系统的动态链接库中获取映射的函数，包括：所述检测设备根据所述第一函数序列中的每个函数以及函数之间的映射关系，分别从dll文件中获取映射的函数。上述过程提供了一种windows操作系统下模拟linux操作系统的可选实现方式。通过将虚拟运行环境中实现api的函数封装在so文件，将windows操作系统中实现api的函数封装在dll文件。在测试文件运行的过程中，当虚拟运行环境的api序列被调用时，通过依次访问so文件以及dll文件，找到windows操作系统提供的与linux操作系统功能类似的函数序列。通过执行函数序列，模拟出执行linux操作系统的api序列的效果，从而实现了系统模拟的目的，使得测试文件能够在虚拟运行环境下正常运行，从而摆脱了测试文件对linux操作系统的依赖。如此，即使测试文件是elf文件，而检测设备的操作系统是windows操作系统，利用该方法，能够在windows操作系统下动态检测elf文件，从而摆脱检测elf文件对linux操作系统的依赖，因此基于x86平台的检测设备能够动态检测基于linux系统运行的测试文件，从而扩展了恶意文件检测技术的使用场景。可选地，所述检测设备在第二操作系统中执行第二api序列，包括：所述检测设备获取所述第一api序列中调用的第一类参数，所述第一类参数包括的参数为所述第一api序列中的api的输入参数；所述检测设备在所述第二操作系统中，根据第二类参数执行所述第二api序列，所述第二类参数包括的参数为所述第二api序列中的api的输入参数，所述第二类参数中的第一参数与所述第一类参数中的第一参数具有映射关系。上述过程提供了一种系统模拟的可选实现方式。通过考虑到不同api的输入参数可能具有差异，当虚拟运行环境的api序列中调用了输入参数时，将调用的输入参数映射为检测设备的操作系统的api的输入参数，从而根据合适的参数执行api序列，从而避免执行api序列时出现传入的参数错误的情况。可选地，所述检测设备在第二操作系统中执行第二api序列，包括：所述检测设备获取所述测试文件在运行过程中触发的第一指令序列，所述第一指令序列包括至少一个指令，所述第一指令序列中的每个指令用于指示调用所述第一api序列中的一个api；所述检测设备对所述第一指令序列中的指令进行第一指令转换，根据第一指令转换的结果得到第二指令序列，所述第二指令序列包括至少一个指令，所述第二指令序列中的每个指令用于指示调用所述第二api序列中的一个api，所述第一指令转换用于将所述第一操作系统所基于的指令集中的指令转换为所述检测设备的计算机指令集中的指令；所述检测设备执行所述第二指令序列，以实现所述第二api序列对应的操作。通过这种可选方式，若测试文件是通过指令集a编写的可执行文件，测试设备的cpu是指令集b架构的cpu，测试设备通过进行指令转换，从而将测试文件触发的指令从指令集a中的指令转换为指令集b中的指令。这样，测试设备的cpu能够执行测试文件触发的指令，从而正常运行测试文件。由此可见，该技术手段能够摆脱运行测试文件对特定指令集架构的依赖，从而保证检测恶意文件的方案广泛的应用在各种硬件环境上。可选地，所述第一操作系统为windows操作系统，所述检测设备的计算机指令集架构为进阶精简指令集机器arm架构，所述检测设备对所述第一指令序列中的指令进行第一指令转换，根据第一指令转换的结果得到第二指令序列，包括：所述检测设备将所述第一指令序列中的每个x86指令转换为arm指令，根据转换得到的arm指令得到所述第二指令序列。通过这种可选方式，若测试文件是通过x86指令集编写的可执行文件，测试设备的cpu是arm指令集架构的cpu，测试设备通过进行指令转换，从而将测试文件触发的x86指令转换为arm指令。这样，测试设备的cpu能够执行arm指令，从而正常运行测试文件。由此可见，该技术手段能够摆脱运行测试文件对x86指令集架构的依赖，因此能够保证检测恶意文件的方案广泛的应用在arm硬件环境上。可选地，所述第一操作系统为linux操作系统，所述检测设备的计算机指令集架构为x86架构，所述检测设备对所述第一指令序列中的指令进行第一指令转换，根据第一指令转换的结果得到第二指令序列，包括：所述检测设备将所述第一指令序列中的每个arm指令转换为x86指令，根据转换得到的x86指令得到所述第二指令序列。通过这种可选方式，若测试文件是通过arm指令集编写的可执行文件，测试设备的cpu是x86指令集架构的cpu，测试设备通过进行指令转换，从而将测试文件触发的arm指令转换为x86指令。这样，测试设备的cpu能够执行x86指令，从而正常运行测试文件。由此可见，该技术手段能够摆脱运行测试文件对arm指令集架构的依赖，因此保证检测恶意文件的方案广泛的应用在x86硬件环境上。可选地，所述检测设备在第二操作系统中执行第二api序列之后，所述方法还包括：所述检测设备获取第三指令序列，所述第三指令序列表示执行所述第二api序列后得到的结果，所述第三指令序列中的指令属于所述检测设备的计算机指令集；所述检测设备对所述第三指令序列中的每个指令进行第二指令转换，根据第二指令转换的结果得到第四指令序列，所述第四指令序列中的指令属于所述虚拟运行环境的计算机指令集，所述第二指令转换用于将所述检测设备的计算机指令集中的指令转换为所述第一操作系统所基于的指令集中的指令；所述检测设备将所述第四指令序列输入所述虚拟运行环境。通过这种可选方式，能够将api序列的执行结果转换为与测试文件兼容的形式，返回给虚拟运行环境中运行的测试文件，使得测试文件能够根据之前调用api序列的结果继续运行，持续地表达出动态行为。可选地，所述容器技术包括docker容器技术，所述虚拟运行环境通过docker守护进程启动，所述docker守护进程为所述检测设备基于所述第二操作系统运行的进程。通过这种可选方式，基于docker容器技术，通过docker守护进程启动虚拟运行环境，该虚拟运行环境例如是docker容器的实例。通过使用docker容器，能够具有更轻量化的优势，实现进程级别的恶意文件检测。第二方面，提供了一种恶意文件的检测装置，该恶意文件的检测装置包括至少一个模块，至少一个模块用于实现上述第一方面或第一方面任一种可选方式所提供的恶意文件的检测方法。第二方面提供的恶意文件的检测装置的具体细节可参见上述第一方面或第一方面任一种可选方式，此处不再赘述。第三方面，提供了一种检测设备，该检测设备包括处理器，该处理器用于执行指令，使得该检测设备执行上述第一方面或第一方面任一种可选方式所提供的恶意文件的检测方法。第三方面提供的检测设备的具体细节可参见上述第一方面或第一方面任一种可选方式，此处不再赘述。第四方面，提供了一种检测设备，该检测设备包括网络接口、存储器和与所述存储器连接的处理器，所述网络接口，用于获取测试文件，所述测试文件为基于第一操作系统运行的可执行文件；所述存储器用于存储程序指令；所述处理器用于执行所述程序指令，以使所述检测设备执行以下操作：在虚拟运行环境中运行所述测试文件，所述虚拟运行环境是基于容器技术生成的；获得所述测试文件在运行过程中调用的第一api序列，所述第一api序列中包括至少一个api，所述第一api序列包括的api为第一api集合中的api，所述第一api集合包括所述虚拟运行环境提供的软件运行所需的多个api，所述第一api集合中的api的标识与第二api集合中的api的标识相同，所述第二api集合包括所述第一操作系统提供的软件运行所需的多个api；在第二操作系统中执行第二api序列，所述第二api序列中包括至少一个api，所述第二api序列包括的api为所述第二操作系统中的api，所述第二api序列中的第一api与所述第一api序列中的第一api具有映射关系，所述第二操作系统是基于所述检测设备的计算机指令集架构的操作系统；基于所述第一api序列被调用过程中所述测试文件的行为特征，判断所述测试文件是否为恶意文件。可选地，第四方面提供的检测设备还用于执行上述第一方面中任一种可选方式所提供的恶意文件的检测方法。第四方面提供的检测设备的具体细节可参见上述第一方面或第一方面任一种可选方式，此处不再赘述。第五方面，提供了一种计算机可读存储介质，该存储介质中存储有至少一条指令，该指令由处理器读取以使检测设备执行上述第一方面或第一方面任一种可选方式所提供的恶意文件的检测方法。第六方面，提供了一种计算机程序产品，当该计算机程序产品在检测设备上运行时，使得检测设备执行上述第一方面或第一方面任一种可选方式所提供的恶意文件的检测方法。第七方面，提供了一种芯片，当该芯片在检测设备上运行时，使得检测设备执行上述第一方面或第一方面任一种可选方式所提供的恶意文件的检测方法。附图说明图1是本申请实施例提供的一种网络系统的示意图；图2是本申请实施例提供的一种检测设备的结构示意图；图3是本申请实施例提供的一种检测恶意文件的逻辑功能架构图；图4是本申请实施例提供的一种恶意文件的检测方法的流程图；图5是本申请实施例提供的一种恶意文件的检测方法的流程图；图6是本申请实施例提供的一种恶意文件的检测方法的流程图；图7是本申请实施例提供的一种恶意文件的检测方法的流程图；图8是本申请实施例提供的一种恶意文件的检测方法的流程图；图9是本申请实施例提供的一种恶意文件的检测方法的流程图；图10是本申请实施例提供的一种网络安全的保护方法的流程图；图11是本申请实施例提供的一种企业网络的示意图；图12是本申请实施例提供的一种网络安全的保护方法的流程图；图13是本申请实施例提供的一种网络安全的保护方法的流程图；图14是本申请实施例提供的一种网络安全的保护方法的流程图；图15是本申请实施例提供的一种网络安全的保护方法的流程图；图16是本申请实施例提供的一种虚拟化架构的示意图；图17是本申请实施例提供的一种恶意文件的检测方法的流程图；图18是本申请实施例提供的一种恶意文件的检测装置的结构示意图。具体实施方式为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。本申请中术语“第一”“第二”等字样用于对作用和功能基本相同的相同项或相似项进行区分，应理解，“第一”、“第二”、“第n”之间不具有逻辑或时序上的依赖关系，也不对数量和执行顺序进行限定。本申请中术语“至少一个”的含义是指一个或多个，本申请中术语“多个”的含义是指两个或两个以上，例如，多个第二报文是指两个或两个以上的第二报文。本文中术语“系统”和“网络”经常可互换使用。还应理解，术语“如果”可被解释为意指“当...时”(“when”或“upon”)或“响应于确定”或“响应于检测到”。类似地，根据上下文，短语“如果确定...”或“如果检测到[所陈述的条件或事件]”可被解释为意指“在确定...时”或“响应于确定...”或“在检测到[所陈述的条件或事件]时”或“响应于检测到[所陈述的条件或事件]”。以下，对本申请涉及的技术术语进行介绍。指令集是指处理器可识别的一整套指令。指令集可包括复杂指令集(全称:complexinstructionsetcomputing，缩写:cisc)和精简指令集risc(全称:reducedinstructionsetcomputing，缩写:risc)。x86是微处理器执行的计算机语言指令集。x86指一个英特尔(intel)通用计算机系列的标准编号缩写。x86也标识一套通用的计算机指令集合。x86为cisc。x86的名字来源于1978年推出的intel8086中央处理器。x86架构通常用于指代兼容x86指令集的处理器。x86架构被广泛地应用在个人计算机(personalcomputer，缩写:pc)上。x86平台泛指基于x86架构的硬件设备。该硬件设备上使用了intel或其它兼容x86指令集的处理器。另外，硬件设备通常会安装有微软视窗操作系统(windows)操作系统。例如，硬件设备是x86服务器。arm是一个32位的risc。arm架构通常用于指代兼容arm指令集的处理器。arm架构被广泛地应用在移动终端上arm平台泛指基于arm架构的硬件设备。该硬件设备上使用了兼容arm指令集的处理器。另外，该硬件设备通常会安装有linux操作系统(是一套免费使用和自由传播的类unix操作系统)。可执行文件(executablefile)是指可由操作系统加载执行的文件。可选地，在windows操作系统下，可执行文件包括可移植的可执行(portableexecutable，pe)文件，pe文件包括.exe文件、.sys文件、.com等类型文件。其中，.是文件名和扩展名的间隔符，例如，.exe文件为扩展名为exe的文件。在linux操作系统下，可执行文件包括可执行与可链接格式(executableandlinkableformat，缩写:elf)文件。恶意文件是指包含有程序设计者出于攻击意图所编写的一段程序的文件。恶意文件利用计算机系统的漏洞执行恶意任务，例如窃取机密信息、破坏存储的数据等等。恶意文件往往是可执行文件，例如在计算机系统上执行恶意任务的病毒、蠕虫和特洛伊木马程序。由于恶意文件会对计算机系统安全造成严重破坏。静态检测是指在不运行计算机程序的条件下进行程序分析的方法。例如仅通过分析样本文件的源代码、汇编、语法、结构、过程、接口等来检查样本文件是否为恶意文件。动态行为检测是指模拟测试文件的执行过程，获得测试文件执行过程中产生的行为或行为序列，与已知恶意文件的动态行为特征进行匹配，根据匹配结果判定测试文件是否为恶意文件。时下，很多动态行为检测技术会受到运行环境的制约，具体地，获取到测试文件后，经常会出现由于运行环境不兼容测试文件，使得测试文件无法运行起来，这样就无法监控到动态行为，也就无法检测出恶意文件。动态行为检测通常采用沙箱技术实现。沙箱(sandbox)是一种安全机制，通过提供一个虚拟的运行环境，为执行中的测试文件提供隔离环境。在沙箱中运行的程序不会对硬件产生永久性的影响。可选地，沙箱能够通过主机的真实操作系统来实现，也能够通过虚拟机来实现。为了收集测试文件运行过程中产生的行为或行为序列，需要在沙箱里添加监控程序。在windows操作系统的虚拟机里，通常利用微软公司提供的驱动框架添加监控程序，监控程序监控进程创建、文档创建、注册表修改等行为。操作系统(operatingsystem，缩写:os)是指管理和控制计算机硬件资源与软件资源的计算机程序。操作系统是基本的系统软件，是计算机硬件和其他软件的接口，其他软件要在操作系统的支持下运行。操作系统能够为可执行文件提供运行环境，比如提供软件运行所需的api等。操作系统的内核是一种软件，内核为操作系统的一部分，内核为操作系统的核心。操作系统的内核可用于管理操作系统的各种资源。内核可以理解为应用程序和硬件之间的桥梁，或者说充当应用程序和硬件之间的接口。内核是直接运行在硬件上的软件实体，用于为应用程序提供对计算机硬件的访问。另外内核能够决定一个程序在什么时候对某部分硬件操作多长时间。内核能够提供硬件抽象层、磁盘及测试文件系统控制、多任务等功能。容器(container)技术是一种虚拟化技术。容器技术能够用于生成容器，该容器能够为软件的执行提供虚拟运行环境。容器是一种软件。容器是可执行文件以及可执行文件依赖的资源的打包。容器包含可执行文件运行所需的资源。例如代码、运行环境、系统工具、系统库和设置。容器能够通过镜像创建。相对于虚拟机而言，容器具有更轻量的优势，占用的资源更少，运行速度更快。具体而言，虚拟机会将虚拟硬件、内核(即操作系统)以及用户空间打包在新虚拟机当中，当通过虚拟机运行应用时，虚拟机先需要虚拟一个物理环境，然后构建一个完整的操作系统，再搭建一层运行时刻(runtime)，然后供应用程序运行。而容器通常直接将容器层安装在主机的操作系统之上，容器层例如可以为linux容器(linuxcontainer，lxc)或libcontainer(docker中用于容器管理的包，它基于go语言实现)。其中，容器的内部没有操作系统，容器利用物理机的内核运行，多个容器能够共享物理机的操作系统。由于容器直接利用了主机的内核，免去了构建操作系统的流程以及为容器包含的应用分配独立的操作系统的流程，虚拟化的对象更少，比如说，在一些情况下，构建容器时要为容器独立构建的只有二进制文件与库，库中包含二进制文件依赖的内容，而不需要像虚拟机那样打包完整的操作系统，因此更加轻量化，启动速度极快。此外，容器的管理也具有更便捷的优势。具体地，容器的运行态对应一组标准的管理操作，例如，启动容器、停止容器、暂停容器和删除容器等，能够通过这些标准的管理操作，便捷的管理容器。镜像(image)用于封装运行容器所需的内容，例如程序、库、资源、配置等文件，以及一些配置参数。其中，镜像通常以分层的结构方式进行存储。镜像包括至少一个镜像层(imagelayer)。例如，镜像层是一个只读的模板，该模板用于构建容器。镜像层用于存储应用程序和迁移应用程序。跨平台是软件技术中的术语，是指一个操作系统下开发的应用，放到另一个操作系统下依然能够正常运行。例如，如果在windows操作系统下开发了应用a，该应用a在linux操作系统下依然能够正常运行，可称应用a为跨平台应用。通常情况下，跨平台的应用要满足不依赖于操作系统的条件。应用编程接口(applicationprogramminginterface，api)是操作系统与应用程序之间的通信接口，操作系统为应用程序提供api，应用程序调用api，以指令操作系统执行操作。从技术实质的角度而言，api是一套预先设定的函数。通俗的讲，操作系统可以视为一个服务中心，能为应用程序提供各种服务，会将实现各种服务的指令封装在各个函数中，若应用程序要使用操作系统的某种服务，会调用该服务对应的函数，则操作系统会执行函数对应的操作，从而为应用程序提供服务。由于这种函数的服务对象是应用程序，因此这种函数称之为应用程序编程接口。通过api，能够为应用程序与开发人员提供基于软件或硬件来访问一组例程的能力，同时，免去访问源码以及理解内部工作机制的学习成本，降低了复杂度。docker为由google公司推出的软件容器平台，可实现容器的开发、部署并运行等功能。通过docker，能够方便地创建和使用容器，把自己的应用放入容器。容器还能够进行版本管理、复制、分享、修改，能够通过定制应用镜像来实现持续集成、持续交付、部署。docker一般包含docker客户端(dockerclient)以及docker守护进程(dockerdaemon)。dockerdaemon也称docker引擎(dockerengine)，是用于管理镜像以及容器的守护进程，它是运行在操作系统之上的后台进程。docker客户端能够根据用户的输入操作，触发各种指令，通过各种指令与docker守护进程交互，docker守护进程接收docker客户端的指令，根据docker客户端的指令，创建对应的作业，并执行对应的作业。docker容器(dockercontainer)的实例是docker镜像的运行态。docker容器能够被创建、启动、停止、删除、暂停等。用户输入查看指令(例如可以是dockerps指令)，计算机会响应查看指令，显示主机上运行的docker容器的列表。docker容器具有更轻量化的优势。具体地，虚拟机通常包括虚拟机管理系统(hypervisor)和客户操作系统(guestoperatingsystem，guestos)，hypervisor用于在宿主操作系统上运行虚拟的客户操作系统，并且要对硬件资源进行虚拟化。客户操作系统占用的磁盘空间、cpu和内存都非常大。而docker容器中，使用docker守护进程(dockerdaemon)取代了hypervisor以及guestos。docker守护进程是运行在操作系统之上的后台进程，负责管理docker容器，docker守护进程能够直接与主机的操作系统进行通信，为各个docker容器分配资源，免去了虚拟机通过hypervisor间接通信会带来的开销。另外，hypervisor会对硬件资源进行虚拟化，而docker能够直接使用硬件资源，从而提高了硬件资源的利用率。docker镜像(dockerimage)用于创建docker容器，docker镜像是一个可执行程序包，包含运行docker应用所需的内容，例如包含docker应用的代码、库、环境变量和配置文件。docker镜像能够在装有dockerengine的环境中运行，当docker镜像运行后，会被创建为docker容器，docker容器能够实现对容器外部的软件以及硬件进行屏蔽。可选地，docker镜像包括元数据文件、配置文件以及至少一个镜像层文件。例如，元数据文件是manifest.json文件，元数据文件记录了所有镜像层文件的元数据，例如记录每个镜像层文件的sha256值(哈希值)。配置文件记录docker镜像占用的内存大小、docker镜像包含的指令类型等，镜像层文件是layer(层)文件。动态链接库用于封装应用程序的运行过程依赖的函数以及资源。动态链接库也称共享函数库或共享库，动态链接库中的函数和资源能够由多个应用程序共享。通过动态链接库，有助于避免代码重用和促进内存的有效使用，使得应用程序将每个功能进行模块化。动态链接库通常以测试文件的形式存储在计算机中。可选地，在不同的操作系统中，这种封装有动态链接库的测试文件具有不同的格式，具有不同的称谓。例如，在windows操作系统下，动态链接库封装在dll文件中；在linux操作系统下，动态链接库封装在共享对象(sharedobject，so)文件中。动态链接库是api的一种实现方式。具体地，dll能够封装api的代码，作为api的载体。在执行应用程序的过程中，若应用程序对api触发调用指令，操作系统会访问动态链接库，从动态链接库中得到api的代码，运行代码，以执行对应的操作。例如，操作系统能够提供注册表api，应用程序调用注册表api时，能够访问注册表。而使用该注册表api时所需运行的代码能够存储在动态链接库中。dll文件为windows操作系统中包含动态链接库的测试文件，dll文件包含了windows的程序在windows环境下运行过程中依赖的许多函数和资源。dll文件又称“应用程序拓展”。dll文件的后缀是.dll。例如，dll文件包括kernel32.dll文件、user32.dll文件、gdi32.dll文件，这三个测试文件封装了windows操作系统的api函数。可选地，dll文件存放在系统目录下中，例如存放在c:\windows\system32\目录下。其中，kernel32.dll文件是windows9x/me中重要的32位动态链接库测试文件，属于内核级测试文件。user32.dll是windows用户界面相关应用程序接口，用于包括windows处理，基本用户界面等特性，如创建窗口和发送消息。gdi32.dlll是存放在windows系统测试文件夹中的一个动态链接库，是windows下图形用户界面的应用拓展，通常情况下是在安装操作系统过程中自动创建的。许多应用程序并不是一个完整的可执行文件，这种应用程序会被分割成一些相对独立的动态链接库，即dll文件，放置于系统中。当执行应用程序时，应用程序对应的dll文件就会被调用。其中，一个应用程序可使用多个dll文件，一个dll文件也可能被不同的应用程序使用。ntdll.dll文件为一种dll文件，ntdll.dll文件包含用于调用内核的函数，可以理解为核心的dll文件。在windows操作系统中，当应用程序调用windowsapi时，会访问一系列的dll文件，而对dll文件中函数的调用，最终会定向到ntdll.dll，当调用ntdll.dll文件中的函数后，内核会被调用，执行函数对应的操作。ntdll.dll文件是windows系统从ring3到ring0的入口。位于kernel32.dll和user32.dll中的所有win32api最终都是调用ntdll.dll中的函数实现的。ntdll.dll中的函数使用sysentry进入ring0，函数的实现实体在ring0中。共享对象(sharedobject，so)文件为linux操作系统中包含动态链接库的文件。so文件包括linux操作系统的应用程序在基于linux操作系统运行时依赖的函数。so文件的后缀是.so。so文件是一种二进制的elf文件。so文件也称共享库或共享对象库。以下，示例性介绍本申请实施例提供的恶意文件的检测方法的应用场景。请参见图1，图1是本申请实施例提供的一种恶意文件的检测方法的应用场景的示意图，图1中的网络系统中包括检测设备。可选地，图1所示的场景中还包括云端的分析设备。图1中的网络系统包括数据中心1102，核心办公区、办公区a和办公区b各自的局域网1103。数据中心1102、核心办公区、办公区a和办公区b各自的局域网1103通过交换机与防火墙1105连接。防火墙1105进一步通过路由器1101、网络地址转换(networkaddresstranslation，nat)设备(图中未示出)、网关设备(图中未示出)等等与广域网或者因特网连接。防火墙1105用于将网络系统与广域网或因特网进行隔离，对网络系统与广域网或者因特网之间交互的数据进行安全防护。如图1所示，检测设备的一种可能的部署位置是网络系统的网络出口，即防火墙1105与路由器1101之间，例如检测设备集成在出口防火墙、出口路由器或者旁挂防火墙中。检测设备用于防范来自互联网的恶意测试文件以及恶意的web流量。可选地，检测设备是网关设备、防火墙设备、入侵检测系统(intrusiondetectionsystem，ids)类设备、入侵防御系统(intrusionpreventionsystem，ips)类设备中的任一种。其中，ids类是指依照一定的安全策略，通过软、硬件，对网络、系统的运行状况进行监视，发现各种攻击企图、攻击行为或者攻击结果，以保证网络系统资源的机密性、完整性和可用性。ips类是指监视网络或网络设备的报文传输行为、即时的中断、调整或隔离一些不正常或是具有伤害性的报文传输行为。可选地，检测设备还可以是独立的沙箱设备、或者是集成了沙箱功能的其他设备。例如检测设备可以是安全网关、防火墙等等。其中，独立的沙箱设备通常以旁路的方式部署于企业的互联网出口处，例如企业的区域网通过网关设备或路由器与互联网连接，沙箱设备以旁路的方式与网关设备、或路由器连接。在一种可能的实现方式中，检测设备集成在云端的分析设备中。检测设备通过网络app、开放的服务端口等方式向其他网络设备提供检测服务。在这种情况下，检测设备从网络中的其他网络设备(例如安全网关、防火墙等等)接收测试文件，对测试文件执行本申请实施例所示的检测方法之后，将测试文件是否为恶意文件的检测结果返回给提供测试文件的其他网络设备。以上介绍了恶意文件的检测方法的应用场景，以下示例性介绍本申请实施例提供的检测设备。可选地，该检测设备是图1所示的网络系统中的检测设备。请参见图2，图2是本申请实施例提供的一种检测设备的结构示意图。如附图2所示的检测设备包括至少一个处理器21、至少一个存储器22、网络接口23。处理器21、存储器22和网络接口23通过总线24相互连接。可选地，处理器21是一个通用中央处理器(centralprocessingunit，cpu)、网络处理器(np)、微处理器、或者是一个或多个用于实现本申请方案的集成电路，例如，专用集成电路(application-specificintegratedcircuit，asic)，可编程逻辑器件(programmablelogicdevice，pld)或其组合。可选地，上述pld是复杂可编程逻辑器件(complexprogrammablelogicdevice，cpld)，现场可编程逻辑门阵列(field-programmablegatearray，fpga)，通用阵列逻辑(genericarraylogic，gal)或其任意组合。可选地，处理器21是一个单核处理器(single-cpu)。可选地，处理器21是一个多核处理器(multi-cpu)。可选地，存储器22包括寄存器、易失性存储器(volatilememory)，例如随机存取存储器(random-accessmemory，ram)；可选地，存储器包括非易失性存储器(non-volatilememory)，例如快闪存储器(flashmemory)，硬盘(harddiskdrive，hdd)或固态硬盘(solid-statedrive，ssd)、云存储(cloudstorage)、网络附接存储(networkattachedstorage，nas)、网盘(networkdrive)等；可选地，存储器还包括上述种类的存储器的组合或者其他具有存储功能的任意形态的介质或产品。例如，存储器22包括电可擦可编程只读存储器(electricallyerasableprogrammableread-onlymemory，eeprom)、只读光盘(compactdiscread-onlymemory，cd-rom)或其它光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其它磁存储设备，或者是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其它介质，但不限于此。可选地，存储器22是独立存在，并通过总线24与处理器21相连接。可选地，存储器22和处理器21集成在一起。网络接口23使用任何收发器一类的装置，用于与其它设备或通信网络通信。网络接口23包括有线通信接口，可选地，网络接口23还包括无线通信接口。其中，有线通信接口例如为以太网接口，例如千兆以太网(gigabitethernet，简称ge)接口。可选地，以太网接口是光接口，电接口或其组合。可选地，有线通信接口是光纤分布式数据接口(fiberdistributeddatainterface，简称fddi)接口。可选地，无线通信接口为无线局域网(wirelesslocalareanetworks，wlan)接口，蜂窝网络通信接口或其组合等。总线24用于在上述组件之间传送信息。可选地，总线24分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。例如，总线24是高速串行计算机扩展总线标准(peripheralcomponentinterconnectexpress，简称：pcie)总线、先进微控制器总线架构(advancedmicrocontrollerbusarchitecture，amba)总线通信、缓存一致性系统(huaweicache-coherentsystem，hccs，维护多端口之间业务数据一致性的协议标准)总线或外设部件互连标准(peripheralcomponentinterconnect，简称：pci)总线。可选地，图2中的检测设备还包括输入输出接口25，输入输出接口25用于连接输出设备和输入设备。输入设备和处理器21通信。可选地，输入设备以多种方式接收用户的输入。例如，输入设备是鼠标、键盘、触摸屏设备或传感设备等。输出设备和处理器21通信。可选地，输出设备以多种方式来显示信息。例如，输出设备是液晶显示器(liquidcrystaldisplay，lcd)、发光二级管(lightemittingdiode，led)显示设备、阴极射线管(cathoderaytube，crt)显示设备或投影仪(projector)等。以上示例性介绍了检测设备的硬件结构，以下对检测设备的软件架构进行示例性描述。可选地，检测设备的软件采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构等等。检测设备的软件包括至少一个功能模块，每个功能模块采用软件实现，换句话说，功能模块为检测设备的处理器21读取存储器22中存储的程序代码后生成的。例如，请参见图2，检测设备的软件包括容器221、指令转换模块222和操作系统223。容器221用于提供虚拟运行环境。指令转换模块222用于对容器221和操作系统223之间传输的指令进行转换。例如，容器221向操作系统223发送指令时，指令转换模块222截获指令，对指令进行转换，将转换后的指令发送至操作系统223。又如，操作系统223向容器221发送指令时，指令转换模块222截获指令，对指令进行转换，将转换后的指令发送至容器221。可选地，指令转换模块222设置在容器221之外。可选地，检测设备的软件还包括容器224和指令转换模块225。指令转换模块225设置在容器224之内。指令转换模块225用于对容器224和操作系统223之间传输的指令进行转换。可选地，容器224提供的虚拟环境和容器221提供的虚拟环境不同。例如，容器221提供用于模拟windows操作系统的虚拟运行环境，容器224提供用于模拟linux操作系统的虚拟运行环境，如此，同一台检测设备可以利用容器221和容器224，提供多种虚拟运行环境。下面以检测设备的计算机指令集架构为arm指令集架构为例，对图2所示的软件架构进行举例说明。可选地，图3中docker容器的实例是图2中的容器。请参见图3，例如，图2中的容器221是图3中的docker_1或docker_2。图2中的容器224是图3中的docker_n。其中，docker_1、docker_2、docker_n为3个docker容器的实例。例如，图2中的指令转换模块222是图3中的指令转换进程1或指令转换驱动1。图2中的指令转换模块225是图3中的指令转换进程2或指令转换驱动2。例如，图2中的操作系统223是图3中的linux操作系统，linux操作系统能够基于arm指令集运行。图3中的容器能够实现系统模拟的功能。参见图3，docker_1包含的ntdll.dll、kernel32.dll和行为监控模块，其中，ntdll.dll、kernel32.dll用于进行系统模拟。ntdll.dll、kernel32.dll为虚拟运行环境的动态链接库。行为监控模块用于对测试文件在容器中的动态行为进行监控。可选地，docker实例借助指令转换模块与操作系统进行通信，换句话说，指令转换模块充当docker实例和操作系统之间的通信媒介。以下通过方式一和方式二举例说明。方式一、docker实例的外部设置有指令转换模块。具体地，指令转换模块可以接收docker实例产生的指令，指令转换模块对指令进行转换后，将转换后的指令发送给操作系统。例如，请参见图3，docker_1的外部设置有指令转换进程1或指令转换驱动1，docker_1产生x86指令后，docker_1将x86指令发送给指令转换进程1或指令转换驱动1，指令转换进程1或指令转换驱动1接收x86指令，将x86指令转换为arm指令，发送给linux操作系统。linux操作系统执行arm指令后，将执行结果携带在arm指令，返回给指令转换进程1或指令转换驱动1，指令转换进程1或指令转换驱动1将arm指令转换为x86指令，将x86指令返回给docker_1。如此，docker_1通过指令转换进程1或指令转换驱动1，与linux操作系统进行了通信。通过这种方式，docker实例和指令转换模块有着清晰的角色和分工，系统模拟的功能由docker实例实现，指令转换的功能由指令转换模块实现，从而将系统模拟与指令转换这两种功能解耦开来，方便后续单独对系统模拟的功能进行扩展、升级和更新。方式二、docker实例内部包含指令转换模块。docker实例通过内部的指令转换模块与操作系统进行通信。例如，请参见图3，docker_n的内部设置有指令转换进程2或指令转换驱动2，docker_n中系统模拟的部分产生x86指令后，将x86指令发送给指令转换进程2或指令转换驱动2，指令转换进程2或指令转换驱动2接收x86指令，将x86指令转换为arm指令，docker_n将arm指令发送给linux操作系统。linux操作系统执行arm指令后，将执行结果携带在arm指令，返回给docker_n。docker_n接收到arm指令，通过自身的指令转换进程2或指令转换驱动2将arm指令转换为x86指令，指令转换进程2或指令转换驱动2将x86指令返回给docker_n中操作系统模拟的部分。如此，docker_n通过内部包含的指令转换进程2或指令转换驱动2，与linux操作系统进行了通信。应理解，图2和图3描述的软件架构在检测恶意文件时，仅以上述各功能模块的划分进行举例说明，实际应用中，可选地，根据需要而将上述功能分配由不同的功能模块完成，即将检测设备内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。换句话说，图2和图3中的功能模块能够进行组合或拆分，并不影响检测设备的整体功能。此外，图2和图3提供的软件架构与下述图4提供的方法实施例属于同一构思，其具体实现过程详见方法实施例，这里先不做赘述。以上介绍了检测设备的硬件结构和软件架构，以下示例性介绍检测设备检测恶意文件的方法流程。请参见图4，图4是本申请实施例提供的一种恶意文件的检测方法的流程图，图4以执行主体为检测设备为例进行说明。该方法包括以下步骤401至步骤406。步骤401、检测设备基于容器技术生成虚拟运行环境。可选地，虚拟运行环境和主机的真实运行环境相隔离，使得在虚拟运行环境中运行的测试文件不会对硬件产生永久性的影响。检测设备在虚拟运行环境内部运行测试文件，随后删除运行测试文件所产生的变化。可选地，虚拟运行环境通过容器技术实现，虚拟运行环境是容器的实例。例如，请参见图3，如果基于docker容器技术生成虚拟运行环境，虚拟运行环境通过图3中的docker_1、docker_2或docker_n提供。可选地，在一些实施例中，基于容器的镜像生成虚拟运行环境。例如，基于docker容器技术，通过docker守护进程启动虚拟运行环境，该虚拟运行环境是docker容器的实例。通过使用docker容器的实例，具有更轻量化的优势，实现进程级别的恶意文件检测。应理解，步骤401仅是以生成一个虚拟运行环境的过程为例进行说明，在一些可选地实施例中，检测设备生成多个虚拟环境。检测设备包含数目更多的虚拟运行环境时，每个虚拟运行环境的生成过程可以和步骤401类似。通过生成多个虚拟运行环境，能够并行地对多个样本文件进行检测，从而提高检测效率。此外，可选地，不同虚拟运行环境用于模拟不同的操作系统，例如虚拟运行环境a模拟windows操作系统，虚拟运行环境b模拟linux操作系统，从而适应不同要求的样本文件的运行需求。步骤402、检测设备获取测试文件。可选地，获取测试文件的方式包括多种。例如，检测设备接收用户输入的测试文件。又如，检测设备采集网络中传输的数据流，通过对数据流中包含的报文的载荷进行重组得到数据流携带的文件。又如，检测设备对嵌入了测试文件的父文件进行解析，得到父文件中携带的测试文件。其中，父文件是指嵌入了测试文件的文件。父文件包含测试文件。父文件也称为原始文件，或者根据厂商、标准或场景的不同而具有不同的称谓。例如，父文件是邮件，测试文件是邮件中携带的附件，该附件是可执行文件。检测设备对邮件进行解析，得到邮件中携带的附件。又例如，父文件是word文档，测试文件是word文档中链接的可执行文件，检测设备对word文档进行解析，得到测试文件。测试文件为基于第一操作系统运行的可执行文件。第一操作系统为兼容测试文件的操作系统。例如，测试文件是pe文件，第一操作系统是windows操作系统；例如，如果测试文件是elf文件，第一操作系统是linux操作系统。例如，如果测试文件是exe文件、.sys文件或.com等类型的文件，第一操作系统是指windows操作系统。应理解，可执行文件与操作系统的情况有多种，linux操作系统和windows操作系统是对第一操作系统的举例，可选地，第一操作系统是android操作系统(也称安卓操作系统，为谷歌公司开发的操作系统)、ios操作系统(苹果公司的移动操作系统)、macos操作系统(苹果操作系统)、blackberry操作系统(黑莓操作系统)、unix操作系统(一种多用户、多任务操作系统)或者netware系统(novell公司推出的网络操作系统)中的任一种，相应地，测试文件是基于这些操作系统运行的可执行文件。当然，以上列举的操作系统仅是对第一操作系统的举例，本实施例对第一操作系统的具体类型不做限定。需要指出的是，步骤401所示的生成虚拟运行环境的步骤是一次执行的，而步骤402所示的获取测试文件的步骤是多次执行的。换句话说，不必在每次获得测试文件之前都重新生成虚拟运行环境。步骤401生成虚拟运行环境之后，检测设备对基于虚拟运行环境所模拟的第一操作系统的多个测试文件分别执行步骤402至步骤406所示的流程。步骤403、检测设备在虚拟运行环境中运行测试文件。例如，检测设备将测试文件传入docker容器的实例，向docker容器的实例发送启动运行测试文件的指令。docker容器的实例会响应于启动运行测试文件的指令，运行测试文件，使得测试文件得以在虚拟运行环境中运行。在一些可选地实施例中，检测设备仅生成一种虚拟运行环境，将该测试文件发送至该虚拟运行环境运行。例如，如果要模拟windows操作系统运行测试文件，则生成用于模拟windows操作系统的虚拟运行环境，将测试文件固定发送至该虚拟运行环境。在另一些可选地实施例中，检测设备生成多种虚拟运行环境，执行以下步骤4031至步骤4033所描述的可选流程，将测试文件发送至它需要的虚拟运行环境运行。步骤4031、检测设备确定测试文件的文件类型。可选地，检测设备采用多种方式确定测试文件的文件类型。例如，检测设备根据文件后缀名识别测试文件的文件类型。再例如，检测设备根据文件头部信息识别测试文件的文件类型。具体地，检测设备预先存储有各种文件类型的文件头(或文件)的数据结构。检测设备接收到测试文件后，依次将测试文件的文件头与各种文件类型的文件头的数据结构进行比对，得到测试文件的文件头符合的数据结构，将该数据结构对应的文件类型作为测试文件的文件类型。此外，可选地，检测设备也直接根据后缀名识别测试文件的文件类型。检测设备确定文件类型的其他方式在这里不再一一列举。步骤4032、检测设备根据测试文件的文件类型，确定测试文件需要的虚拟运行环境。可选地，检测设备预先保存文件类型与虚拟运行环境之间的映射关系，通过查询该映射关系，确定测试文件运行需要的运行环境。例如，该映射关系如表1所示。表1文件类型测试文件需要的虚拟运行环境pe文件docker_1elf文件docker_2步骤4033、检测设备在测试文件需要的虚拟运行环境中，运行测试文件。例如，检测设备通过后缀名比对，确定一个测试文件的后缀名为“.elf”，则确定测试文件的文件类型是elf文件，然后在表1中查询获知elf文件需要的运行环境是docker_1，将该测试文件发送给docker_2运行。其中，docker_2用于模拟linux操作系统的运行环境。又例如，检测设备根据测试文件的文件头中的指定字段内容，确定测试文件符合pe文件的文件头的数据结构，因此确定测试文件的文件类型是pe文件。然后检测设备在表1中查询获知pe文件需要的运行环境是docker_1，将该测试文件发送给docker_1运行。其中，docker_1用于模拟windows操作系统的运行环境。步骤404、检测设备获得测试文件在运行过程中调用的第一api序列。例如，如果测试文件为pe格式的文件，测试文件在运行过程中，依次调用createfile()和writefile()两个api，则第一api序列中包括createfile()和writefile()。虚拟运行环境为测试文件提供的软件运行提供多个api。为了与虚拟运行环境所模拟的、兼容测试文件的操作系统为测试文件提供的软件运行所需的多个api区分描述，本申请实施例将虚拟运行环境为测试文件提供的软件运行所需的多个api称为第一api集合。第一api集合中包括多个api。测试文件在虚拟运行环境中运行的过程中，测试文件可能调用第一api集合中的全部api；或者，测试文件调用第一api集合中的部分api，而第一api集合中除部分api之外的其余api没有被测试文件调用。为了将测试文件调用的api与实际执行的api区分描述，本申请实施例将第一api集合中被测试文件调用的一系列api称为第一api序列，将检测设备实际执行的一系列api称为第二api序列。另外，可选地，在运行测试文件的过程中，测试文件仅调用第一api集合中一个api，则第一api序列仅包括这一个api。可选地，随着时间的推移，测试文件先后调用第一api集合中多个api，调用的多个api组成第一api序列，则第一api序列包括多个api。也即是，第一api序列中包括至少一个api，本实施例对第一api序列包括一个api还是包括多个api不做限定。此外，可选地，第一api序列包括多个api，第一api序列中的不同api按照被调用的时间的先后顺序依次排序。例如，如果测试文件首先调用了虚拟运行环境提供的api_1，之后调用了虚拟运行环境提供的api_2，最后调用了虚拟运行环境提供的api_3，则第一api序列表示为(api_1，api_2，api_3)。本申请实施例用第二api集合表示虚拟运行环境所模拟的、兼容测试文件的操作系统为测试文件提供的软件运行所需的多个api。在本实施例中第二api集合是第一操作系统为测试文件提供的软件运行所需的api。第二api集合包括多个api。其中，第一api集合中的api的标识与第二api集合中的api的标识相同。可选地，api的标识是api的名称。api的标识用于标识对应的api。测试文件通过api的标识调用当前运行的运行环境中的api。换句话说，在虚拟运行环境中运行测试文件、以及在第一操作系统中运行测试文件时，测试文件用相同的api标识来调用虚拟运行环境中的api、或者调用第一操作系统中的api。例如，用于写文件的api的标识为writefile()或frwite()。以测试文件为pe格式的文件，第一操作系统为windows操作系统为例，windows操作系统为pe文件提供第一api集合。该第一api集合包括用于写文件的api、用于创建文件的api、用于读取文件的api等等若干api。其中，用于写文件的api的标识为writefile()，用于创建文件的api的标识为createfile()，用于读取文件的api的标识为readfile()。虚拟运行环境为pe文件提供第二api集合。该第二api集合包括用于写文件的api、用于创建文件的api、用于读取文件的api等等若干api。第二api集合中用于写文件的api的标识为writefile()，第二api集合中用于创建文件的api的标识为createfile()，用于读取文件的api的标识为readfile()。在一些可能的实施例中，上述容器的镜像可以由软件提供商提供给用户。软件提供商在打包容器的镜像的过程中，在镜像中封装第一api集合，则检测设备基于镜像生成容器的实例后，容器的实例为其中运行的测试文件提供第一api集合。比如说，要通过容器技术来模拟windows操作系统提供的运行环境，软件提供商在镜像中封装与windows操作系统中的api标识相同的一些api。如果要通过容器技术来模拟linux操作系统提供的运行环境，软件提供商在镜像中封装与linux操作系统中的api标识相同的一些api。步骤405、检测设备在第二操作系统中执行第二api序列。第二操作系统是基于检测设备的计算机指令集架构的操作系统。换句话说，第二操作系统是检测设备上的真实运行环境。例如，检测设备的处理器采用x86架构，第二操作系统是windows操作系统(当然，基于x86架构的操作系统也可以是linux操作系统，这里仅以windows操作系统进行举例说明)。又例如，检测设备的处理器采用arm架构，第二操作系统是linux操作系统(当然，基于arm架构的操作系统也可以是检测设备厂商自开发的操作系统，或者某种特定的windows系列操作系统，如windows10)。为了与前面提到的基于容器技术生成的虚拟运行环境中被调用的api组成的api序列相区别，本申请实施例将真实运行环境(即第二操作系统)中被实际执行的api组成的序列称为第二api序列，将基于容器技术生成的虚拟运行环境中被调用的api组成的api序列称为第一api序列。可选地，第二操作系统既可以与第一操作系统相同，第二操作系统也可以与第一操作系统不同。为了便于理解，本申请实施例以第二操作系统与第一操作系统不同来进行举例说明。在第二操作系统与第一操作系统不同的情况下，第一api序列中的api与第二api序列中的api不同，在第二操作系统与第一操作系统相同的情况下，第一api序列中的api的标识与第二api序列中的api的标识有可能是相同的。在一些实施例中，若第一api序列被调用，检测设备根据第一api序列，确定第二api序列，通过在第二操作系统中执行第二api序列，指令检测设备的硬件执行对应的操作，从而模拟执行第一操作系统的api序列，实现操作系统模拟的效果。第二api序列中包括至少一个api，第二api序列中的api为第二操作系统中的api。第二api序列中的第一api与第一api序列中的第一api具有映射关系。例如，第一操作系统为windows操作系统。第二操作系统为linux操作系统。第一api序列为(createfile()，readfile())。第二api序列为(fcreate()，fread())。第二api序列中的fcreate()和createfile()具有映射关系。第二api序列中的fread()和readfile()具有映射关系。此外，如果第二api序列包括多个api，第二api序列中的不同api按照第一api序列中对应api的先后顺序依次排序。为了简明起见，本申请实施例后续在不至于引入理解困难的情况下用“api+数字”的形式来简化表示上述具体的api，如具体的api为createfile()、readfile()、fcreate()，fread()等等，api可以简化表示为如api_1的形式。例如，如果第一api序列为(api_1，api_2，api_3)。第二操作系统中api_4与api_1具有映射关系，第二操作系统中api_5与api_2具有映射关系，第二操作系统中api_6与api_3具有映射关系，则第二api序列为(api_4，api_5，api_6)。可选地，在一些实施例中，第一api序列中的api与第二api序列中的api之间的映射关系采用这样的方式构建。确定第一操作系统的api的功能，确定第二操作系统的api的功能，获取第一操作系统和第二操作系统的功能类似的api，为功能类似的api建立映射关系。应理解，可选地，使用第二操作系统的多个api来实现第一操作系统的一个api，则在映射关系中，第二操作系统的多个api对应于第一操作系统的一个api。此外，可选地，使用第二操作系统的一个api来实现第一操作系统的一个api，则在映射关系中，第二操作系统的一个api对应于第一操作系统的一个api。本实施例对api之间的映射关系是一对一的关系还是一对多的关系并不做具体限定。例如，在第一操作系统和第二操作系统分别均为计算机设备真实运行的操作系统的情况下，第一api序列中的第一api与第二api序列中的第一api之间的映射关系这样构建：若在第一操作系统中调用与第一api序列中的第一api相同标识的api后，会指令设备执行操作a，若在第二操作系统中调用第二api序列中的第一api后，会指令设备执行操作b，而操作a与操作b相同，可选地，建立第一api序列中的第一api与第二api序列中第一api之间的映射关系。比如说，在windows操作系统下，计算机设备通过调用writefile()这一api，指示执行写文件操作；在linux操作系统下，计算机设备通过调用frwite()这一api，来指令执行写文件操作，那么由于writefile()和frwite()这2个api都是用来指示执行写文件操作的，可建立writefile()和frwite()这两个api之间的映射关系。在一些实施例中，软件提供商在打包容器的镜像的过程中，在镜像中封装第一api集合中的api与第二操作系统中的api之间的映射关系，则检测设备基于镜像生成容器的实例后，容器的实例能够访问第一api集合中的api与第二操作系统中的api之间的映射关系。示例性地，确定第二api序列中的第一api的过程包括：检测设备从第一api序列中确定第一api。检测设备以第一api序列中api的标识为索引，查询api之间的映射关系，得到第二api序列中的第一api的标识。检测设备根据第二api序列中的第一api的标识，确定第二api序列中的第一api。例如，参见下表2，若第一api序列为(createfile()，readfile())，检测设备从第一api序列中确定readfile()。检测设备以readfile()为索引，查询表2，确定第二api序列中的第一api为fread()。依次类推，可选地，通过同理的方式，确定第二api序列中第一api之外的其他api，进一步对确定的api进行排序和组合，得到第二api序列。表2windows操作系统的apilinux操作系统的apiwritefile()frwite()readfile()fread()createfile()fcreate()通过上述方法，本申请实施例实际执行的是第二操作系统中的api，而并没有实际执行第一操作系统中api，实现了达到了模拟出测试文件在第一操作系统中运行过程的效果。例如，参见上表1，通过执行linux操作系统的frwite()，模拟windows操作系统的writefile()的执行过程。通过执行linux操作系统的fcreate()，模拟windows操作系统的createfile()的执行过程。由此可见，虚拟运行环境能够模拟出了第一操作系统为测试文件提供的软件运行所需的api。由于测试文件调用的api的请求能够被响应，实现了操作系统模拟的目的，使得测试文件能够在虚拟运行环境下正常运行，从而摆脱了测试文件对第一操作系统的依赖。可选地，在一些可能的实施例中，对api的调用基于动态链接库实现，相应地，使用第二操作系统的api来模拟第一操作系统的api的过程包括以下步骤一至步骤三。步骤一、检测设备根据第一api序列中的每个api，分别从虚拟运行环境的动态链接库中获取对应的函数，从而获得第一函数序列。测试文件的代码中引用动态链接库中的函数以及资源。在检测设备运行测试文件的过程中，测试文件调用第一api序列后，检测设备访问虚拟运行环境的动态链接库，从动态链接库中得到第一函数序列。其中，第一函数序列包括至少一个函数，第一函数序列中的函数用于实现第一api序列中的api。例如，测试文件为pe格式的文件，测试文件调用的api序列为(createfile()，readfile())，则第一函数序列中的函数是用于实现createfile()的函数或者用于实现readfile()的函数。步骤二、检测设备根据第一函数序列中的每个函数，分别从第二操作系统的动态链接库中获取对应的函数，从而生成第二函数序列。第二函数序列包括至少一个函数，第二函数序列中的函数用于实现第二api序列中的api。例如，如果检测设备的操作系统是linux操作系统，第二api序列中的api是fcreate()，第二函数序列中的函数是用于实现fcreate()的函数。第二函数序列中的第一函数与第一函数序列中的第一函数具有映射关系。例如，用于实现fcreate()的函数与用于实现readfile()的函数具有映射关系。示例性地，确定第二函数序列中的第一函数的过程包括，检测设备从第一函数序列中选取第一函数。检测设备以第一函数序列中的第一函数的标识为索引，查询第一函数序列中的函数的标识与第二函数序列中的函数的标识之间的映射关系，得到第二函数序列中的第一函数的标识。检测设备根据第二函数序列中的第一函数的标识，确定第二函数序列中的第一函数。依次类推，通过同理的方式，确定第一函数序列中其他函数对应的第二函数序列中的函数，例如第一函数序列中第二函数对应的第二函数序列中的第二函数等等。检测设备得到第一函数序列中各函数分别对应的第二函数序列中的函数之后，对得到的若干第二函数序列中的函数进行组合，从而得到第二函数序列。可选地，应理解，使用第二操作系统的多个函数来实现第一操作系统的一个函数，则在函数之间的映射关系中，第二操作系统的多个函数对应于第一操作系统的一个函数。此外，可选地，使用第二操作系统的一个函数来实现第一操作系统的一个函数，则在映射关系中，第二操作系统的一个函数对应于第一操作系统的一个函数。本实施例对函数之间的映射关系是一对一的关系还是一对多的关系并不做具体限定。在一些可能的实施例中，在软件提供商打包容器的镜像的过程中，在镜像中封装第一函数序列中的函数与第二函数序列中的函数之间的映射关系，则基于镜像生成容器的实例后，容器的实例能够访问第一函数序列中的函数与第二函数序列中的函数之间的映射关系。步骤三、检测设备在第二操作系统的内核中，根据第二函数序列执行操作。通过上述实现方式，检测设备将调用虚拟运行环境的动态链接库的过程转换为调用第二操作系统的函数的过程，从而利用第二操作系统提供的函数，来模拟第一操作系统的函数。可选地，在一些实施例中，考虑到不同函数调用的参数可能具有差异，例如参数的编码方式、取值范围等等具有差异。检测设备进一步在不同函数的参数之间进行转换。例如，检测设备获取第一api序列中调用的第一类参数，检测设备在第二操作系统中，根据第二类参数执行第二api序列。其中，第一类参数包括至少一个参数，第一类参数包括的参数为第一api序列中的api的输入参数。第二类参数包括至少一个参数，第二类参数包括的参数为第二api序列中的api的输入参数，第二类参数中的第一参数与第一类参数中的第一参数具有映射关系。例如，第一api序列中的api是createfile()，第一类参数中的第一参数是createfile()中表示文件名的参数。第二api序列中的api是fcreate()，第二类参数中的第一参数是fcreate()中表示文件名的参数。检测设备将第二类参数作为第二api序列的输入参数，执行第二api序列。示例性地，检测设备从第一类参数中确定第一参数。检测设备以第一参数的标识为索引，查询参数之间的映射关系，得到第二类参数中的第一参数的标识。检测设备根据第二类参数中的第一参数的标识，确定第二类参数中的第一参数。依次类推，检测设备通过同理的方式，确定第二类参数中第一参数之外的其他参数，检测设备对确定的参数进行组合，得到第二类参数。第一参数的标识用于标识第一参数。例如第一参数的标识是第一参数的名称。在一些可能的实施例中，软件提供商在打包容器的镜像的过程中，软件提供商在镜像中封装第一类参数中的第一参数与第二类参数中的第一参数之间的映射关系，则检测设备基于镜像生成容器的实例后，容器的实例可以访问第一类参数中的第一参数与第二类参数中的第一参数之间的映射关系。应理解，上述通过动态链接库来获取函数序列是示例说明，在一些可选地实施例中，检测设备将实现api的函数存储在动态链接库之外的其他库文件中，检测设备采用同理的方式，从其他库文件中获取第一函数序列以及第二函数序列。其中，可选地，该其他库文件是静态库。当然，库文件也仅是对实现api的函数的存储方式的一种举例，并不限定必须从库文件中获取实现api的函数。例如，软件提供商预先对容器实例中配置实现api的函数的存储地址，容器实例访问预先设定的存储地址，能够得到第一函数序列以及第二函数序列。可选地，在一些实施例中，测试文件在运行过程中通过调用第一api序列来请求对第一资源集合执行操作，相应地，检测设备执行第二api序列以对第二资源集合执行操作。其中，第一资源集合包括至少一个资源。第一资源集合中的资源为第一api序列中的api操作的对象。第二资源集合包括至少一个资源。第二资源集合中资源为第二api序列中的api操作的对象，第二资源集合中的第一资源与第一资源集合中的第一资源具有映射关系。例如，测试文件在运行过程中，调用readfile()来请求访问windows的文件系统，为了响应测试文件的调用请求，检测设备将windows的文件系统映射为linux的目录a，调用fread()来访问linux的目录a。在这个例子中，第一api序列中的api为readfile()，第一资源集合中的资源为windows的文件系统。第二api序列中的api为fread()，第二资源集合中资源为linux的目录a。又如，测试文件在运行过程中，调用windows中进行网络通信的api_1，以请求通过windows的网络系统进行网络通信。为了响应测试文件的调用请求，检测设备将windows的网络系统映射为linux的协议栈，调用linux中进行网络通信的api_2，以请求通过linux的协议栈进行网络通信。在这个例子中，第一资源集合中的资源为windows的网络系统，第二资源集合中资源为linux的协议栈。依次类推，可选地，测试文件通过调用第一api序列来请求对windows系统管理的输入输出(io)设备执行操作，检测设备执行第二api序列以控制linux系统管理的io设备执行操作。可选地，在一些实施例中，通过进行指令转换，将测试文件触发的指令转换为第二操作系统可执行的指令。可选地，指令转换的过程包括以下步骤a至步骤b。步骤a、检测设备获取测试文件在运行过程中触发的第一指令序列。可选地，在运行测试文件之前，检测设备在磁盘中存储测试文件，此时测试文件中的程序的形态是一堆二进制代码。检测设备接收到对测试文件的测试指令时，会响应于测试指令，读取测试文件中的程序，将程序加载到系统内存中，将系统内存中的程序解释为一条一条的指令，执行指令以实现对应的功能。其中，指令为指挥计算机工作的指示和命令，程序是一系列按一定顺序排列的指令，计算机的工作过程即为执行指令的过程。测试文件调用第一api序列是通过触发第一指令序列实现的。第一指令序列包括至少一个指令，第一指令序列中的每个指令用于指示调用第一api序列中的一个api。第一指令序列中的每个指令属于与虚拟运行环境所模拟的操作系统兼容的计算机指令集。例如，虚拟运行环境用来模拟windows操作系统的运行环境，第一指令序列中的每个指令是x86指令集中的x86指令。虚拟运行环境用来模拟linux操作系统的运行环境，第一指令序列中的每个指令是arm指令集中的arm指令。检测设备接收虚拟运行环境运行测试文件触发的每条指令，得到第一指令序列。例如，如果虚拟运行环境是基于docker容器技术生成的，检测设备接收docker容器的实例中测试文件触发的每条指令，得到第一指令序列。步骤b、检测设备对第一指令序列中的指令进行第一指令转换，根据第一指令转换的结果得到第二指令序列。第一指令转换用于将第一操作系统所基于的指令集中的指令转换为检测设备的计算机指令集中的指令。例如，如果检测设备的计算机指令集为arm指令集，第一操作系统所基于的指令集为x86指令集，则第一指令转换是指将x86指令转换为arm指令的过程。又如，如果检测设备的计算机指令集为x86指令集，第一操作系统所基于的指令集为arm指令集，则第一指令转换是指将arm指令转换为x86指令的过程。第二指令序列包括至少一个指令。第二指令序列中的每个指令用于指示调用第二api序列中的一个api。第二指令序列中的每个指令属于检测设备的计算机指令集，因此，第二指令序列中的每个指令是检测设备的架构可识别、可执行的指令。例如，如果检测设备的计算机指令集为arm指令集，则第二指令序列中的每个指令是arm指令集中的arm指令。如果检测设备的计算机指令集为x86指令集，第二指令序列中的每个指令是x86指令集中的x86指令。检测设备得到第二指令序列后，执行第二指令序列，以实现第二api序列对应的操作。例如，第二指令序列中的每个指令为arm指令，检测设备通过armcpu执行每个arm指令，那么由于linuxapi是通过执行arm指令实现的，执行每个arm指令也就实现了一系列的linuxapi对应的操作。可选地，在一些实施例中，检测设备运行指令转换进程，通过指令转换进程对第一指令序列进行指令转换，得到第二指令序列。可选地，从软件架构的角度来讲，在虚拟运行环境之外部署指令转换进程。例如，可以在docker容器的实例与第二操作系统之间插入指令转换进程，使得指令转换进程部署在docker容器的实例之外。或者，可选地，在虚拟运行环境之内部署指令转换进程。例如，在docker容器的实例中设置指令转换进程。指令转换也称指令翻译。可选地，在一些实施例中，检测设备将第一指令序列切分成若干条微指令，将每条微指令由一段简单的代码来实现，然后将这些代码编译成目标文件，在检测设备上执行目标文件，该目标文件包含第二指令序列。通过指令转换的手段，若测试文件是通过指令集a编写的可执行文件，测试设备的cpu是指令集b架构的cpu，测试设备通过进行指令转换，从而将测试文件触发的指令从指令集a中的指令转换为指令集b中的指令。这样，测试设备的cpu能够执行测试文件触发的指令，从而正常运行测试文件。由此可见，该技术手段摆脱运行测试文件对特定硬件环境的依赖，保证检测恶意文件的方案广泛的应用在各种硬件环境上。可选地，在一些实施例中，检测设备在第二操作系统中执行第二api序列之后，检测设备获取到第三指令序列，检测设备对第三指令序列中的每个指令进行第二指令转换，根据第二指令转换的结果得到第四指令序列。检测设备将第四指令序列输入虚拟运行环境，以使测试文件基于第四指令序列继续运行。例如，如果虚拟运行环境是基于docker容器技术生成的，检测设备将第四指令序列输入至docker容器的实例中，在docker容器的实例中根据第四指令序列继续运行测试文件。第二指令转换用于将检测设备的计算机指令集中的指令转换为第一操作系统所基于的指令集中的指令。例如，如果检测设备的计算机指令集为arm指令集，第一操作系统所基于的指令集为x86指令集，则第二指令转换是指将arm指令转换为x86指令的过程。又如，如果检测设备的计算机指令集为x86指令集，第一操作系统所基于的指令集为arm指令集，则第二指令转换是指将x86指令转换为arm指令的过程。第三指令序列表示执行第二api序列后得到的结果，第三指令序列中的指令属于检测设备的计算机指令集。可选地，第三指令序列对应的指令集和第二指令序列对应的指令集相同。第三指令序列中的指令属于检测设备的计算机指令集。第四指令序列对应的指令集和第一指令序列对应的指令集相同。第四指令序列中的指令属于虚拟运行环境的计算机指令集。例如，如果检测设备的处理器为arm架构的处理器，arm架构的处理器执行arm指令后，得到的结果通常还是arm指令的形式，而虚拟运行环境中的文件需要根据x86指令确定得到的结果。那么，指令转换进程将arm架构的处理器返回的arm指令转换为x86指令，将x86指令输入至虚拟运行环境，以使虚拟运行环境中运行的测试文件得到处理器的反馈，测试文件根据返回的x86指令，能够确定之前调用api的结果，根据调用api的结果继续运行。步骤406、检测设备基于第一api序列被调用过程中测试文件的行为特征，判断测试文件是否为恶意文件。可选地，在一些实施例中，检测设备对虚拟运行环境提供的api进行监控。当监控到第一api序列被调用后，检测设备提取测试文件调用第一api序列过程中的行为特征。检测设备判断行为特征是否满足预先设定的条件。若行为特征满足预先设定的条件，则检测设备确定测试文件为恶意文件。若行为特征不满足预先设定的条件，则检测设备确定测试文件不为恶意文件，即正常文件。可选地，在一些实施例中，检测设备在虚拟运行环境中开始运行测试文件之后，只有将测试文件在虚拟运行环境中当前调用的api转换为第二操作系统中的api并在第二操作系统中实际执行，测试文件才能进一步展现出后续的调用动作，从而获取完整的第一api序列。继而，检测设备根据第一api序列确定测试文件是否为恶意文件。可选地，检测设备对虚拟运行环境提供的api进行监控的实现方式包括多种。例如，软件提供商在基于容器技术设计用于实现虚拟运行环境的程序代码时，采用多种方式使得虚拟运行环境能够输出测试文件调用第一api序列过程中的行为特征。以监控第一api序列的过程为例，例如，软件提供商在设计用于支持虚拟运行环境的第一api集合时，在第一api集合中的部分或者全部api中嵌入一段用于输出信息的程序代码。该程序代码的功能是在被执行时输出所嵌入的api被调用的相关信息。api被调用的相关信息包括但不限于api的标识、传入的参数、被调用的时间等等。可选地，软件提供商在设计第一api集合时，只在部分感兴趣的、对于区分正常异常行为效果较好的api中嵌入上述用于输出信息的程序代码。可选地，上述用于输出信息的程序代码将所嵌入的api被调用的相关信息输出到指定存储空间中，例如输出到指定日志文件中，以便于检测设备读取指定存储空间中的数据后，获得pe文件调用第一api序列的行为特征。换句话说，第一api集合中的api的特点一方面是api的标识与第一操作系统api集合中的api的标识相同，另一方面是在被调用时能够输出被调用的相关信息。以第一操作系统为windows操作系统为例，例如，第一api集合中用于写文件的api为writefile()，该writefile()与windows操作系统的写文件的api名称相同。第一api集合中用于写文件的api为writefile()被调用时，还向日志文件输出被调用的相关信息，相关信息包括writefile()被调用时传入的参数，这些参数例如文件名、文件存储位置、将被写入文件的字符串内容，写入数据相对于文件头的偏移量等等。在另一些实施例中，预先设置日志记录函数，当第一函数序列中的函数被调用时，日志记录函数会记录该第一函数序列中的函数被调用的事件。若检测设备读取日志，发现日志中记录了第一函数序列中的每个函数，检测设备从而确定第一api序列被调用。例如，检测设备对虚拟运行环境提供的用于设置注册表的api进行监控，即对实现regsetvalue()的函数进行监控。当接收到regsetvalue()的函数被调用的事件，检测设备确定用于设置注册表的api被调用。以此类推，检测设备采用这样的监控机制，对虚拟运行环境提供的每个api进行监控。或者，可选地，检测设备采用这样的监控机制，对虚拟运行环境提供的所有api中的关键api进行监控，例如，检测设备对用于设置注册表的api、用于设置文件系统的api、用于控制文件权限的api、用于操作进程的api、用于操作线程的api、用于控制内存的api进行监控。可选地，根据调用第一api序列的过程来提取行为特征的实现方式包括多种。例如，检测设备获取第一api序列中每个api的标识，获取测试文件向每个api传入的参数值，根据每个api的标识以及每个api被传入的参数值，提取行为特征。行为特征用于表示测试文件的一个或多个动态行为。可选地，行为特征的形式是一个序列，该序列由每个动态行为的特征按照发生时间先后的顺序排序而成。文件在虚拟运行环境中的动态行为例如包括进程操作、文件操作、注册表操作、端口访问、释放或加载dll等等中的一个或多个。进程操作包括创建进程、结束进程中的一个或多个；文件操作包括创建文件、修改文件、读取文件、删除文件等中的一个或多个；注册表操作包括创建注册表项、修改注册表项、查询注册表项、删除注册表项等中的一个或多个。应理解，以上描述的被调用的api以及行为特征仅是举例，测试文件在运行过程中如果调用虚拟运行环境提供的其他api，则基于调用其他api过程中的行为特征，判断测试文件是否为恶意文件。例如，可选地，测试文件在运行过程中还调用虚拟运行环境提供的进行网络通信的api、发送短信的api、操作通讯录的api、显示弹窗的api等等，行为特征是网络通信的行为特征、发送短信的行为特征、操作通讯录的行为特征、显示弹窗的行为特征等等。检测设备提取调用其他api的行为特征进行判断的过程，与前文描述的方式同理，在此不做赘述。检测设备获取测试文件的行为特征后，根据获取的行为特征确认测试文件是否为恶意文件。例如，检测设备将上述测试文件的行为特征与预定规则匹配，根据匹配结果确认是否为恶意文件；或者将上述测试文件的行为特征输入预先通过机器学习算法训练生成的分类模型，根据分类模型的输出确认是否为恶意文件；或者通过人工分析上述测试文件的行为特征，确认是否为恶意文件。例如，检测设备通过以上方式获取测试文件的行为特征为{regdeletevalue(参数a)，regsetvalue(参数b)，setwindowshook(参数c)}。上述行为特征表明测试文件先通过regdeletevalue删除杀毒软件启动项，再通过注册表设置函数regsetvalue将自身添加到开机自启动项中，实现系统驻留；再进一步通过setwindowshook函数设置全局钩子，截获用户输入数据，窃取敏感信息。检测设备根据这一系列的行为特征，判断作为测试文件的测试文件为恶意文件。可选地，在一些实施例，为不同的动态行为设置不同的权重，权重表示对应动态行为的威胁程度，例如权重越大，表示威胁程度越大。可选地，检测设备确定行为特征后，获取行为特征对应的动态行为的权重。检测设备根据行为特征以及权重，判定测试文件是否为恶意测试文件。随着apt攻击的持续变化，新的攻击技术如加壳、混淆、加密等方式，也在不断更新，导致传统的基于恶意特征码匹配检测技术已经越来越难以应对。而从恶意文件的实现目的来看，即使恶意文件经过了混淆或加壳，也会触发被感染的机器执行动作，以进行信息窃取、感染或者勒索等恶意行为。而通过上述实施方式，能够利用测试文件在虚拟运行环境中调用的api，抽象出测试文件的动态行为，若甄别出测试文件的动态行为符合恶意文件的动态行为，则判定该测试文件为恶意文件，从而实现了恶意文件的动态检测。本申请实施例提供了能实现跨平台动态检测恶意文件的方案，通过基于容器技术生成的虚拟运行环境，模拟出兼容测试文件的操作系统提供的运行环境。测试文件调用了虚拟运行环境提供的api后，检测设备将虚拟运行环境被测试文件调用的api，转换为检测设备的操作系统提供的api，在检测设备的操作系统中执行转换后的api。由于通过执行检测设备的操作系统的api，达到了模拟执行第一操作系统的api的效果。因此，检测设备提供的虚拟运行环境能够兼容测试文件的正常运行，从而摆脱了测试文件对特定架构或平台的依赖(即测试文件要求检测设备必须基于特定的架构或平台)，因此实现了跨平台的恶意文件检测。此外，由于虚拟运行环境是基于容器技术生成的，容器技术能够免去hypervisor以及guestos带来的资源开销，直接利用主机的内核运行。由于容器的镜像的大小远远小于虚拟机的镜像的大小，因此本申请实施例的检测方法更加轻量化，消耗的cpu处理资源更少，占用的内存空间更少。本申请实施例的检测方法在进程级别实现恶意文件的运行，检测速度更快。并且，能够避免虚拟机反复重置带来的耗时和性能开销，避免传统的虚拟机的创建、调度等操作带来的开销。以下通过图5实施例，对本申请实施例附图4所描述的恶意文件的检测方法进行举例说明。在附图5所示的实施例中，检测设备为基于arm平台的计算机设备。测试文件为pe文件。换句话说，附图5描述的方法流程关于基于arm平台的检测设备如何检测利用windows操作系统进行恶意操作的恶意文件。应理解，图5实施例与图4实施例同理的步骤还请参见图4实施例，在图5实施例中不做赘述。参见图5，图5是本申请实施例提供的一种恶意文件的检测方法的流程图，该方法包括以下步骤501至步骤505。步骤501、检测设备获取一个pe文件，该pe文件是本申请实施例中的测试文件。其中，检测设备是上述实施例中的检测设备的一种具体情况，检测设备的操作系统是linux操作系统。pe文件是上述实施例中的测试文件的一种具体情况，pe文件为基于windows操作系统运行的可执行文件，pe文件的格式为pe格式。步骤502、检测设备在虚拟运行环境中运行pe文件。其中，虚拟运行环境是基于容器技术生成的。第一api集合中包括多个api。第一api集合包括虚拟运行环境提供的软件运行所需的多个api。第一api集合中的api的标识与windowsapi集合中的windowsapi的标识相同。windowsapi集合包括了windows操作系统为测试文件提供的软件运行所需的多个api。windowsapi集合中包括多个windowsapi。步骤503、检测设备获得pe文件在运行过程中调用的第一api序列，第一api序列中包括至少一个api。步骤504、检测设备在linux操作系统中执行第二api序列，第二api序列包括至少一个linuxapi，第二api序列中的第一linuxapi与第一api序列中的第一api具有映射关系。本步骤中，通过执行linuxapi，达到模拟执行windowsapi的效果，从而模拟windows系统为测试文件提供的运行环境，实现操作系统模拟的目的。在windows操作系统下，应用程序是以函数调用的方式来通知操作系统执行相应的功能的，而windowsapi调用过程中涉及的函数通常由系统的动态链接库提供。相应地，可选地，模拟执行windowsapi的流程包括以下步骤(1)至步骤(3)。步骤(1)检测设备根据第一api序列中的每个api，分别从dll文件中获取对应的函数。dll文件由虚拟运行环境提供。例如，虚拟运行环境的动态链接库包括dll文件。在一种可能的实现中，软件提供商在打包容器的镜像的过程中，软件提供商在镜像中封装dll文件，则检测设备基于镜像生成容器的实例后，容器的实例为其中运行的pe文件提供dll文件，使得pe文件可以调用dll文件中的第一函数序列。在一些实施例中，可选地，windows操作系统包括多个dll文件，访问dll文件的过程包括按照一定的顺序依次访问多个dll文件的过程。其中，可选地，最后一个访问的dll文件是ntdll.dll文件。步骤(2)检测设备根据第一函数序列中的每个函数以及函数之间的映射关系，分别从so文件中获取映射的函数。so文件为linux操作系统中包含动态链接库的文件。so文件基于arm平台运行。so文件由虚拟运行环境提供。例如，虚拟运行环境的动态链接库包括so文件。在一种可能的实现中，软件提供商在打包容器的镜像的过程中，软件提供商在镜像中封装so文件，则检测设备基于镜像生成容器的实例后，若第一函数序列被调用后，检测设备能够访问so文件，得到第二函数序列。步骤(3)在linux操作系统的内核中，根据第二函数序列执行操作。示例性地，如果在windows操作系统下，当pe文件调用api：writefile()，会调用到动态链接库kernel32.dll中，然后进一步调用动态链接库ntdll.dll中的函数ntwritefile()，最后在windows系统的内核中执行写文件操作。而在本实施例中，在linux操作系统下运行测试文件的过程中，当pe调用api：writefile()时，检测设备可选地调用so文件中的函数frwite()，根据函数frwite()，在linux内核中完成该操作。通过调用linux操作系统的so文件，能够模拟出windows操作系统上dll文件的调用过程。通过在linux内核中根据函数执行操作，能够模拟出在windows内核中根据函数执行操作的过程。比如在上一段的例子中，通过在linux系统的内核中根据frwite()进行写文件操作，模拟出在windows操作系统的windows内核中根据ntwritefile()进行写文件操作。在一些实施例中，可选地，通过进行指令转换，将测试文件触发的指令转换为linux操作系统可执行的指令。可选地，指令转换的过程包括以下步骤a至步骤b。步骤a、检测设备获取测试文件在运行过程中触发的第一指令序列，第一指令序列中的每个指令为x86指令，第一指令序列中的每个x86指令用于指示调用第一api序列中的一个windowsapi。步骤b、检测设备将第一指令序列中的每个x86指令转换为arm指令，根据转换得到的arm指令得到第二指令序列，第二指令序列包括至少一个arm指令。第二指令序列中的每个arm指令用于指示调用第二api序列中的一个linuxapi。第二指令序列中的每个指令属于arm指令集。之后，检测设备通过armcpu执行第二指令序列中的每个arm指令，以实现第二api序列中每个linuxapi对应的操作，从而通过linuxapi模拟了windowsapi。在一些实施例中，可选地，检测设备在linux操作系统中执行第二api序列之后，检测设备获取到第三指令序列，第三指令序列表示执行第二api序列后得到的结果，第三指令序列中的指令为arm指令。检测设备将第三指令序列中的每个arm指令转换为x86指令，根据转换得到的x86指令得到第四指令序列，第四指令序列中的指令属于x86指令集中的x86指令。检测设备将第四指令序列输入至虚拟运行环境。请参见图3，基于上述方法流程，当得到x86的应用程序(application，app)后，x86的app会触发对虚拟运行环境中dll文件的调用，产生x86指令，将x86指令转换为arm指令，通过基于arm的操作系统执行x86指令。其中，x86app为基于x86指令集开发的应用程序，x86的app能够封装为pe文件。步骤505、检测设备基于第一api序列被调用过程中pe文件的行为特征，判断pe文件是否为恶意文件。可选地，本实施例提供的恶意文件检测方法单独使用软件实现，例如全部以计算机程序产品的形式实现。该软件可以由软件提供商提供给用户。该软件提供商可以和检测设备的厂商不同，比如说，检测设备的硬件单独由网络设备的厂商提供，检测设备上运行的用于检测恶意文件的软件单独由互联网应用的服务商提供。软件提供商在基于容器技术设计用于实现虚拟运行环境的程序代码时，采用多种方式使得虚拟运行环境能够输出测试文件调用第一api序列过程中的行为特征。例如，软件提供商在设计用于支持虚拟运行环境的第一api集合时，在第一api集合中的部分或者全部api中嵌入一段用于输出信息的程序代码。该程序代码的功能是在被执行时输出所嵌入的api被调用的相关信息。api被调用的相关信息包括但不限于api的标识、传入的参数、被调用的时间等等。可选地，软件提供商在设计第一api集合时，只在部分感兴趣的、对于区分正常异常行为效果较好的api中嵌入上述用于输出信息的程序代码。可选地，上述用于输出信息的程序代码将所嵌入的api被调用的相关信息输出到指定存储空间中，例如输出到指定日志文件中，以便于检测设备读取指定存储空间中的数据后，获得pe文件调用第一api序列的行为特征。换句话说，第一api集合中的api的特点一方面是api的标识与windowsapi集合中的windowsapi的标识相同，另一方面是在被调用时能够输出被调用的相关信息。例如，第一api集合中用于写文件的api为writefile()，该writefile()与windows操作系统的写文件的api名称相同。第一api集合中用于写文件的api为writefile()被调用时，还向日志文件输出被调用的相关信息，相关信息包括writefile()被调用时传入的参数，这些参数例如文件名、文件存储位置、将被写入文件的字符串内容，写入数据相对于文件头的偏移量等等。检测设备通过以上方式获取pe文件的行为特征后，根据获取的行为特征确认pe文件是否为恶意文件。例如，检测设备将上述pe文件的行为特征与预定规则匹配，根据匹配结果确认是否为恶意文件；或者将上述pe文件的行为特征输入预先通过机器学习算法训练生成的分类模型，根据分类模型的输出确认是否为恶意文件；或者通过人工分析上述pe文件的行为特征，确认是否为恶意文件。例如，检测设备通过以上方式获取pe文件的行为特征为{regdeletevalue(参数a)，regsetvalue(参数b)，setwindowshook(参数c)}。上述行为特征表明pe文件先通过regdeletevalue删除杀毒软件启动项，再通过注册表设置函数regsetvalue将自身添加到开机自启动项中，实现系统驻留；再进一步通过setwindowshook函数设置全局钩子，截获用户输入数据，窃取敏感信息。检测设备根据这一系列的行为特征，判断作为测试文件的pe文件为恶意文件。应理解，图5实施例提供的流程为基于非x86平台的检测设备检测windows可执行文件的方案的示例性说明，并不是基于非x86平台的检测设备检测windows可执行文件的唯一必选实现方式。可选地，在另一些实施例中，图5实施例中检测设备的linux操作系统可被替换为基于arm指令集架构的其他操作系统。在图5实施例中的linux操作系统被替换为基于arm指令集架构的其他操作系统的情况下，检测设备需要将图5实施例中的so文件替换为该其他操作系统的动态链接库。而这些实现方式属于图4实施例的一种具体情况，也应涵盖在本申请实施例的保护范围之内。当前现有网络中基于非x86平台的计算机设备越来越多，而大量的测试文件仍然是基于windows操作系统运行的可执行文件。而现有非x86平台的检测设备检测windows操作系统下的测试文件时，现有技术会由于测试文件无法执行而存在着天然的障碍。通过本申请实施例提供的方法，基于非x86平台的检测设备通过基于容器技术生成的虚拟运行环境，模拟出类似于windows操作系统的运行环境，从而利用该虚拟运行环境，兼容windows的可执行文件的正常执行。如此，即使测试文件是兼容windows操作系统的可执行文件，例如pe文件，而检测设备的操作系统是linux操作系统，也能够利用通过本申请实施例提供的方法，在linux操作系统下动态检测pe文件，从而摆脱测试文件对windows操作系统的依赖，因此基于非x86平台的检测设备能够动态检测基于windows系统运行的测试文件，而不必要求检测设备必须是基于兼容windows操作系统的x86平台，因此克服了检测设备的使用局限性，扩展了恶意文件检测技术的使用场景。以下通过图6实施例，对本申请实施例附图4和附图5所描述的恶意文件的检测方法进行举例说明。在附图6所示的实施例中，检测设备为基于arm平台的计算机设备。测试文件为windowsexe文件。换句话说，附图6描述的方法流程关于基于arm平台的检测设备如何检测windowsexe文件是否为恶意文件。该方法包括以下步骤601至步骤607。步骤601、检测设备获取作为测试文件的windowsexe文件。步骤602、检测设备获取windowsexe文件在虚拟运行环境中调用的多个windowsapi。步骤603、检测设备根据步骤602中被调用的多个api，依次访问动态链接库gdi32.dll、user32.dll或kernel32.dll。动态链接库gdi32.dll、user32.dll或kernel32.dll中含有上述被调用的多个api对应的执行函数。步骤604、检测设备根据gdi32.dll、user32.dll或kernel32.dll中命中的函数(即上述步骤603中被调用的多个api对应的执行函数)，访问含有命中的函数对应的基本函数的内核级动态链接库ntdll.dll。步骤605、检测设备运行的系统模拟进程确定ntdll.dll中的上述步骤604中命中的函数对应的基本函数映射的linuxapi。步骤606、检测设备运行的访问linux库，得到上述linuxapi对应的函数。步骤607、检测设备运行的unix内核根据步骤606中linuxapi对应的函数，通过unix设备驱动控制unix设备执行操作。下面通过图7实施例，对本申请实施例附图6所描述的恶意文件的检测方法进行举例说明。在附图7所示的实施例中，测试文件为malware.exe。其中，malware这个单词来自于malicious(有恶意的)和software(软件)这两个单词的合成，是恶意软件的术语，代表能够对计算机有威胁的软件程序，如病毒、蠕虫、木马、间谍软件等。malware.exe是一个pe文件。在x86平台下，运行malware.exe的过程中，会根据不同的函数调用，调用不同的dll文件，所有的dll调用，最终会调用到ntdll.dll文件中，由此进入windows系统的内核，实现函数调用的功能。而在本实施例中，基于arm平台的检测设备执行以下步骤701至步骤705，来运行malware.exe，并检测malware.exe包含的恶意文件。步骤701、检测设备启动malware.exe。例如，docker实例包括系统模拟进程，例如，docker实例为父进程，系统模拟进程是子进程。系统模拟进程为docker实例中用于模拟检测设备的操作系统的进程。例如，系统模拟进程可以访问dll文件，得到dll文件中封装的api，进行api转换。docker实例可以通过系统模拟进程启动malware.exe。docker实例通过系统模拟进程，将malware.exe的二进制映像加载到检测设备的内存空间，并启动二进制映像。此外，系统模拟进程用于访问malware.exe所需的dll文件和so文件，保证malware.exe运行过程中的dll调用和函数正常执行。其中，该内存空间由docker实例预先向检测设备真实的操作系统申请。步骤702、检测设备调用dll文件中的函数。其中，dll文件中的函数可以用于组成第一api序列。malware.exe运行过程中，会产生对windows操作系统的注册表、文件、系统io的请求，这些请求是以函数调用的方式通知给windows操作系统的，被调用的函数可以位于dll文件中，一个或多个被调用的函数可以组成api。可选地，系统模拟进程可以利用linux操作系统的资源模拟windows操作系统的资源。比如说，将windows的文件系统对应到linux的某个目录下，从而通过linux的目录模拟windows的文件系统。可选地，windows的网络系统通过基于linux的协议栈模拟实现。步骤703、检测设备进行指令转换。malware.exe在docker实例内运行产生的指令还是x86指令，可选地，指令转换进程对x86指令转换成arm指令。步骤704、检测设备通过linux操作系统上执行arm指令，以实现arm指令所指示的操作。可选地，检测设备的linux操作系统通过基于arm架构的cpu执行arm指令。在执行arm指令的过程中，cpu可以控制其他计算机硬件(如外围的输入输出设备)执行arm指令对应的操作。计算机硬件可以将操作产生的执行结果返回给linux操作系统，linux操作系统将执行结果返回给指令转换进程。指令转换进程将执行结果从arm指令转换为x86指令，将x86指令反馈到docker实例进程中，保证malware.exe继续执行。步骤705、检测设备根据调用过程中的动态行为，进行威胁判定。例如，检测设备对模拟的windowsapi进行监控，根据被调用的函数和参数，抽象出malware.exe的行为特征，根据malware.exe的行为特征进行恶意行为判定，从而完成malware.exe的动态检测。通过上述流程，基于arm平台的检测设备通过操作系统模拟的方式和指令转换的方式，实现了x86平台的文件在arm平台上的动态检测。并且，能在进程级别实现恶意文件的运行，避免传统的虚拟机的创建、调度等操作，占用资源少，运行速度快，最终实现跨平台检测恶意文件的目的。以下通过图8实施例，对本申请实施例附图4所描述的恶意文件的检测方法进行举例说明。在附图8所示的实施例中，检测设备为基于x86平台的计算机设备。测试文件为elf文件。换句话说，附图5描述的方法流程关于基于x86平台的检测设备如何检测利用linux操作系统进行恶意操作的恶意文件。应理解，图8实施例与图4实施例同理的步骤还请参见图4实施例，在图8实施例中不做赘述。参见图8，图8是本申请实施例提供的一种恶意文件的检测方法的流程图，该方法包括以下步骤801至步骤805。步骤801、检测设备获取一个elf文件，该elf文件是本申请实施例中的测试文件。其中，检测设备是上述实施例中的检测设备的一种具体情况，可选地，检测设备的操作系统是windows操作系统。elf文件是上述实施例中的测试文件的一种具体情况。elf文件为基于linux操作系统运行的可执行文件。elf文件的格式为elf格式。步骤802、检测设备在虚拟运行环境中运行elf文件。其中，虚拟运行环境是基于容器技术生成的。第一api集合中包括多个api。第一api集合包括虚拟运行环境提供的软件运行所需的多个api。第一api集合中的api的标识与linuxapi集合中的linuxapi的标识相同。linuxapi集合包括了linux操作系统为测试文件提供的软件运行所需的多个api。linuxapi集合中包括多个linuxapi。步骤803、检测设备获得elf文件在运行过程中调用的第一api序列，第一api序列中包括至少一个api，第一api序列中的api为第一api集合中的api。步骤804、检测设备在windows操作系统中执行第二api序列，第二api序列中包括至少一个windowsapi，第二api序列中的第一windows与第一api序列中的第一api具有映射关系。本步骤中，通过执行windowsapi，达到模拟执行linuxapi的效果，从而模拟linux系统为测试文件提供的运行环境，实现操作系统模拟的目的。可选地，模拟执行linuxapi的流程包括以下步骤8041至步骤8043。步骤8041、检测设备根据第一api序列中的每个api，分别从so文件中获取对应的函数。so文件由虚拟运行环境提供。例如，虚拟运行环境的动态链接库包括so文件。在一种可能的实现中，软件提供商在打包容器的镜像的过程中，软件提供商在镜像中封装so文件，则检测设备基于镜像生成容器的实例后，容器的实例为其中运行的elf文件提供so文件，使得elf文件可以调用so文件中的第一函数序列。步骤8042、检测设备根据第一函数序列中的每个函数以及函数之间的映射关系，分别从dll文件中获取映射的函数。dll文件由虚拟运行环境提供。例如，虚拟运行环境的动态链接库包括dll文件。在一种可能的实现中，软件提供商在打包容器的镜像的过程中，软件提供商在镜像中封装dll文件，则检测设备基于镜像生成容器的实例后，容器的实例为其中运行的elf文件提供dll文件，使得第一函数序列被调用后，检测设备能够访问dll文件，得到第二函数序列。步骤8043、在windows操作系统的内核中，根据第二函数序列执行操作。示例性地，如果在linux操作系统下，当elf文件调用api：frwite()，会调用到so文件中的函数frwite，在linux系统的内核中执行写文件操作。而在本实施例中，windows操作系统下运行elf文件的过程中，当elf文件调用api：frwite()时，检测设备调用kernel32.dll中，然后进一步调用ntdll.dll中的函数ntwritefile()，最后在windows系统的内核中执行写文件操作。通过windows操作系统的dll文件，能够模拟出linux操作系统上so文件的调用过程，通过在windows内核中根据函数执行操作，能够模拟出在linux内核中根据函数执行操作的过程。在一些实施例中，可选地，通过进行指令转换，将测试文件触发的指令转换为windows操作系统可执行的指令。可选地，指令转换的过程包括以下步骤一至步骤二。步骤一、检测设备获取测试文件在运行过程中触发的第一指令序列，第一指令序列中的每个指令为arm指令，第一指令序列中的每个arm指令用于指示调用第一api序列中的一个linuxapi。步骤二、检测设备将第一指令序列中的每个arm指令转换为x86指令，根据转换得到的x86指令得到第二指令序列，第二指令序列包括至少一个x86指令。第二指令序列中的每个x86指令用于指示调用第二api序列中的一个windowsapi。第二指令序列中的每个指令属于x86指令集。之后，检测设备通过x86cpu执行第二指令序列中的每个x86指令，以实现第二api序列中每个windowsapi对应的操作，从而通过windowsapi模拟了linuxapi。在一些实施例中，可选地，检测设备在linux操作系统中执行第二api序列之后，检测设备获取到第三指令序列，第三指令序列表示执行第二api序列后得到的结果，第三指令序列中的指令为x86指令。检测设备将第三指令序列中的每个x86指令转换为arm指令，根据转换得到的arm指令得到第四指令序列，第四指令序列中的指令属于arm指令集中的arm指令。检测设备将第四指令序列输入至虚拟运行环境。例如，基于上述方法流程，当得到armapp后，armapp会触发对虚拟运行环境中so文件的调用，产生arm指令，将arm指令转换为x86指令，通过基于x86的操作系统执行x86指令。其中，armapp为基于arm指令集开发的应用程序，可选地，armapp封装为elf文件。步骤805、检测设备基于第一api序列被调用过程中elf文件的行为特征，判断elf文件是否为恶意文件。可选地，软件提供商在基于容器技术设计用于实现虚拟运行环境的程序代码时，采用多种方式使得虚拟运行环境能够输出测试文件调用第一api序列过程中的行为特征。例如，软件提供商在设计用于支持虚拟运行环境的第一api集合时，在第一api集合中的部分或者全部api中嵌入一段用于输出信息的程序代码。该程序代码的功能是在被执行时输出所嵌入的api被调用的相关信息。api被调用的相关信息包括但不限于api的标识、传入的参数、被调用的时间等等。可选地，软件提供商在设计第一api集合时，只在部分感兴趣的、对于区分正常异常行为效果较好的api中嵌入上述用于输出信息的程序代码。可选地，上述用于输出信息的程序代码将所嵌入的api被调用的相关信息输出到指定存储空间中，例如输出到指定日志文件中，以便于检测设备读取指定存储空间中的数据后，获得pe文件调用第一api序列的行为特征。换句话说，第一api集合中的api的特点一方面是api的标识与linuxapi集合中的linuxapi的标识相同，另一方面是在被调用时能够输出被调用的相关信息。例如，第一api集合中用于写文件的api为frwite()，该frwite()与linux操作系统的写文件的api名称相同。第一api集合中用于写文件的api为frwite()被调用时，还向日志文件输出被调用的相关信息，相关信息包括frwite()被调用时传入的参数，这些参数例如文件名、文件存储位置、将被写入文件的字符串内容，写入数据相对于文件头的偏移量等等。检测设备通过以上方式获取elf文件的行为特征后，根据获取的行为特征确认elf文件是否为恶意文件。例如，检测设备将上述elf文件的行为特征与预定规则匹配，根据匹配结果确认是否为恶意文件；或者将上述elf文件的行为特征输入预先通过机器学习算法训练生成的分类模型，根据分类模型的输出确认是否为恶意文件；或者通过人工分析上述elf文件的行为特征，确认是否为恶意文件。例如，检测设备通过以上方式获取elf文件的行为特征为{regdeletevalue(参数a)，regsetvalue(参数b)，setlinuxhook(参数c)}。上述行为特征表明elf文件先通过regdeletevalue删除杀毒软件启动项，再通过注册表设置函数regsetvalue将自身添加到开机自启动项中，实现系统驻留；再进一步通过setlinuxhook函数设置全局钩子，截获用户输入数据，窃取敏感信息。检测设备根据这一系列的行为特征，判断作为测试文件的elf文件为恶意文件。又例如，elf文件在运行过程中调用打开文件的api，向该系统文件的api传入了表示linux内核符号表的参数值，则行为特征包括fopen、proc/kallsyms和r。其中，fopen表示打开文件，proc/kallsyms和r表示linux内核符号表。由于恶意文件通常会通过打开linux内核符号表，获取root权限，因此，当发现行为特征包括fopen、proc/kallsyms和r时，判断elf文件为恶意文件。应理解，图8实施例提供的流程为基于x86平台的检测设备检测linux可执行文件的方案的示例性说明，并不是基于x86平台的检测设备检测linux可执行文件的唯一必选实现方式。在另一些实施例中，可选地，图8实施例中的windows操作系统被替换为基于x86指令集架构的其他操作系统。在图8实施例中的windows操作系统被替换为基于x86指令集架构的其他操作系统的情况下，检测设备需要将图8实施例中的dll文件替换为该其他操作系统的动态链接库。而这些实现方式属于图4实施例的一种具体情况，也应涵盖在本申请实施例的保护范围之内。当前现有网络中基于x86平台的计算机设备越来越多，而大量的测试文件仍然是基于linux操作系统运行的可执行文件。而现有x86平台的检测设备检测linux操作系统下的测试文件时，现有技术会由于测试文件无法执行而存在着天然的障碍。通过本申请实施例提供的方法，基于x86平台的检测设备能够通过基于容器技术生成的虚拟运行环境，模拟出类似于linux操作系统提供的运行环境，从而利用该虚拟运行环境，兼容linux的可执行文件的正常执行。如此，即使测试文件是兼容linux操作系统的可执行文件，例如elf文件，而检测设备的操作系统是windows操作系统，利用通过本申请实施例提供的方法，在windows操作系统下动态检测elf文件，从而摆脱检测测试文件对linux操作系统的依赖，因此基于x86平台的检测设备能够动态检测基于linux系统运行的测试文件，而不必要求检测设备必须是基于兼容linux操作系统的arm平台，因此克服了检测设备的使用局限性，从而扩展了恶意文件检测技术的使用场景。在一些可能的实施例中，可选地，上述恶意文件的检测方法的产品形态是一个容器应用，该容器应用能够提供检测恶意文件的功能。例如，上文中的软件提供商可以是云计算服务提供者，例如云计算服务提供者为企业网络提供容器应用，云服务器将容器应用部署在企业网络中，企业网络中的检测设备通过运行该容器应用，能够实现上述实施例提供的方法。此外，可选地，通过云容器引擎(cloudcontainerengine，简称cce)，在企业网络中部署容器集群，在云端对容器应用进行部署、管理、扩容、升级、卸载、扩展、服务发现及负载均衡等生命周期管理。企业网络的用户能够根据检测恶意文件的需求，利用cce便捷地管理企业网络中部署的容器应用。以下通过图9实施例，对本申请实施例附图4所描述的恶意文件的检测方法进行举例说明。在附图9所示的实施例中，容器的形态为容器应用，云计算服务提供者通过对容器服务管理实体进行操作来得到容器应用的镜像。参见图9，该方法包括以下步骤901至步骤907。步骤901、容器服务管理实体创建容器应用的镜像。在一些可能的实施例中，可选地，容器服务管理实体是容器即服务(containerasaservice，caas)管理器。caas是一种用于提供容器服务的平台即服务(platformasaservice，paas)。caas位于paas层的底部，集成了paas层和iaas层的服务能力，例如，可选地，caas包括paas层的容器应用和iaas层的容器资源。caas管理器为caas中用于管理容器服务的实体，容器服务管理实体用于对caas进行管理和编排。当然，caas管理器这个名称仅是举例，也可以采用其他称呼来指代caas中用于管理容器服务的实体。在一些实施例中，可选地，容器服务管理实体基于docker技术，对虚拟运行环境的资源进行封装，得到docker镜像。例如，对各种注册表、dll调用、服务等进行打包，得到docker镜像。步骤902、容器服务管理实体向检测设备发送容器应用的镜像。可选地，检测设备接收镜像，根据镜像创建容器应用，运行该容器实例。在一些可能的实施例中，可选地，利用docker技术中的docker镜像库(也称dockerregistry)，将镜像发送给检测设备。例如，容器服务管理实体向docker镜像库发送docker镜像，检测设备从docker镜像库下载docker镜像，从而得到容器服务管理实体发送的镜像。例如，容器服务管理实体通过镜像发送指令(例如是dockerpush)指令，向docker镜像库发送该docker镜像，检测设备向docker镜像库发送镜像下载指令(例如是dockerpull指令)，docker镜像库响应于镜像下载指令，向检测设备发送docker镜像，从而将docker镜像部署在检测设备上。docker镜像库为集群中用于存储及分发docker镜像的节点设备。docker镜像库存储了大量的docker镜像。可选地，docker镜像库基于dockerregistry协议或dockerhub等协议实现。docker镜像库用于存储及分发docker镜像。可选地，docker镜像采用多个镜像层和一个镜像描述信息的形式存储在docker镜像站。步骤903、检测设备获取测试文件。步骤904、检测设备在虚拟运行环境中运行测试文件。步骤905、检测设备获得测试文件在运行过程中调用的第一api序列。步骤906、检测设备在第二操作系统中执行第二api序列。步骤907、检测设备基于第一api序列被调用过程中测试文件的行为特征，判断测试文件是否为恶意文件。参见图3，图9实施例描述的实现操作系统模拟的流程以及行为监控的流程在容器应用中执行。在一些实施例中，可选地，在每个容器应用中启动一个可执行文件，通过每个容器应用分别检测一个可执行文件。例如，如图3所示，创建3个容器的实例，分别是容器docker_1、容器docker_2和容器docker_n。通过容器docker_1启动app1，在容器docker_1中对app1进行检测。通过容器docker_2启动app2，在容器docker_2中对app2进行检测。通过容器docker_n启动appn，在容器docker_n中对appn进行检测，从而通过不同的容器，并行检测不同测试文件。以下通过图10实施例，对本申请实施例附图4所描述的恶意文件的检测方法进行举例说明。在附图10所示的实施例中，恶意文件的检测方法应用在网络安全领域。检测设备具体是以防火墙、路由器、安全网关、入侵检测设备为例的网络安全设备。网络安全设备通过检测网络中传播的恶意文件，保证网络的安全性。应理解，图10实施例与图4实施例同理的步骤还请参见图4实施例，在图10实施例中不做赘述。参见图10，图10是本申请实施例提供的一种网络安全的保护方法的流程图，该方法包括以下步骤1001至步骤1007。步骤1001、网络安全设备获取网络中传输的数据流。在本领域中，数据流(或称报文流)是指从一个源主机到目的方的一系列报文，其中目的方可以是另一个主机、包含多个主机的多播组、或者广播域。可选地，网络安全设备为ids类设备，网络安全设备通过旁路的方式获取数据流。即，网络设备不阻断报文在网络中的传输，而是通过端口镜像(portmirroring)的手段，复制从镜像端口流经的报文，得到镜像报文，对镜像报文进行解析，得到测试文件。可选地，网络安全设备为ips类设备，网络安全设备通过串联模式(in-linemode)，实时检查每一个通过的报文，以便在报文中的测试文件为恶意文件时，阻断报文在网络中的传输。步骤1002、网络安全设备从数据流中获取测试文件。可选地，网络安全设备获取数据流中每个报文的载荷数据后，按照报文的序列号对数据流中所有报文的载荷数据进行重组，从而获取测试文件。步骤1003、网络安全设备在虚拟运行环境中运行测试文件。步骤1004、网络安全设备获得测试文件在运行过程中调用的第一api序列。步骤1005、网络安全设备在第二操作系统中执行第二api序列。步骤1006、网络安全设备基于第一api序列被调用过程中测试文件的行为特征，判断测试文件是否为恶意文件。步骤1007、网络安全设备根据检测结果，对网络进行入侵防御。例如，网络安全设备为ids类设备，如果网络安全设备判断测试文件为恶意文件，网络安全设备发送告警消息。又如，网络安全设备为ips类设备，如果网络安全设备判断测试文件为恶意文件，网络安全设备丢弃报文，从而阻断报文的传输，并发送告警消息。通过本申请实施例提供的方法，网络安全设备通过实施跨平台动态检测恶意文件的方案，对报文中携带的测试文件进行检测，依据检测结果进行入侵防御，能够及时检测到网络中传输的恶意报文，提高网络的安全性。尤其是，网络安全设备通过操作系统模拟的手段，摆脱了检测过程对操作系统的依赖。网络中传输的报文携带了利用windows操作系统进行恶意操作的恶意文件时，使用虚拟运行环境模拟windows操作系统，在虚拟运行环境中运行恶意文件，从而侦测出这种恶意报文。网络中传输的报文携带了利用linux操作系统进行恶意操作的恶意文件时，使用虚拟运行环境模拟linux操作系统，在虚拟运行环境中运行恶意文件，从而侦测出这种恶意报文。因此网络安全设备能够动态检测基于windows系统运行的测试文件以及基于linux系统运行的测试文件，而不必要求网络安全设备必须是基于兼容windows系统的x86平台或兼容linux系统的arm平台，因此克服了网络安全设备的使用局限性，进而极大地扩展的网络入侵防御方法的适用场景，提高网络系统的安全性。可选地，图10实施例提供的网络安全设备应用在企业网络中，部署在企业网络的网关设备及云平台入口，该网络安全设备通过执行通过本申请实施例提供的方法，能够动态检测恶意文件，从而为企业网络的网络安全提供解决方案。附图11描述了网络安全设备几种可能部署场景的示例。示例性地，参见图11，企业网络包括总部局域网和分支机构的若干局域网。总部局域网中包括数据中心1102，核心办公区、办公区a和办公区b各自的局域网。数据中心1102、核心办公区、办公区a和办公区b各自的局域网通过交换机与防火墙1105连接。防火墙1105进一步通过路由器1101、nat设备(图中未示出)、网关设备(图中未示出)等等与广域网或者因特网连接。防火墙1105用于将总部局域网与广域网或因特网进行隔离，对总部局域网与广域网或者因特网之间交互的数据进行安全防护。可选地，总部局域网通过vpn与各分支机构的局域网1104连接，分支机构如图11所示的分支机构a、分支机构b和分支机构c。可选地，图10提供的网络安全设备部署在图11所示的企业网络中。例如，例如参见图11，网络安全设备为第一网络安全设备、第二网络安全设备、第三网络安全设备或第四网络安全设备。第一网络安全设备部署在总部局域网的网络出口，即防火墙1105与路由器1101之间，例如第一网络安全设备集成在出口防火墙、出口路由器或者旁挂防火墙中。第一网络安全设备用于防范来自互联网的恶意测试文件以及恶意的web流量。第二网络安全设备部署在总部局域网的数据中心1102的边界，例如是以直路方式设置在数据中心1102和防火墙1105之间的独立设备，用于保护服务器核心资产，发现内网潜伏的攻击、恶意扫描，渗透等。第三网络安全设备部署在总部局域网的核心部门1103的边界，例如是以直路方式设置在核心办公区的交换机和防火墙1105之间的独立设备，用于防范内网可疑测试文件传播，横向感染核心部门。第四网络安全设备部署在分支机构局域网1104的边界，例如是以直路方式设置在分支机构局域网和广域网路由设备之间的独立设备，用于避免恶意测试文件、未知威胁在分支机构局域网和总部局域网之间任意扩散。以下通过图12实施例，对本申请实施例附图10所描述的恶意文件的检测方法进行举例说明。在附图12所示的实施例中，网络安全设备为图11中的第一网络安全设备。测试文件为总部局域网的网络出口进入或流出的报文中携带的文件。换句话说，附图12描述的方法流程关于部署在总部局域网的网络出口的网络安全设备如何保护总部局域网的网络安全。应理解，图12实施例与图10实施例同理的步骤还请参见图10实施例，在图12实施例中不做赘述。参见图12，图12是本申请实施例提供的一种网络安全的保护方法的流程图，如图12所示，该方法可以包括以下步骤1201至步骤1206。步骤1201、第一网络安全设备采集从总部局域网的网络出口进入或流出的报文，得到该报文携带的测试文件，该测试文件为第一操作系统的可执行文件。步骤1202、第一网络安全设备在虚拟运行环境中运行测试文件。步骤1203、第一网络安全设备获得测试文件在运行过程中调用的第一api序列。步骤1204、第一网络安全设备在第二操作系统中执行第二api序列。步骤1205、第一网络安全设备基于第一api序列被调用过程中测试文件的行为特征，判断测试文件是否为恶意文件。图12实施例中的步骤1202的具体细节请参考图4实施例中的步骤403，图12实施例中的步骤1203的具体细节请参考图4实施例中的步骤404，图12实施例中的步骤1204的具体细节请参考图4实施例中的步骤405，图12实施例中的步骤1205的具体细节请参考图4实施例中的步骤406，为了简洁，在此不再赘述。步骤1206、若测试文件为恶意文件，第一网络安全设备上报在总部局域网的网络出口检测到恶意流量。通过本申请实施例提供的方法，通过在总部局域网的网络出口部署网络安全设备，由网络安全设备采集网络出口中出入的报文，实施跨平台动态检测恶意文件的方案，以对报文中携带的测试文件进行检测，依据检测结果进行入侵防御。通过该方法，若互联网向总部局域网传输的报文携带了利用windows操作系统进行恶意操作的恶意文件，网络安全设备使用虚拟运行环境模拟windows操作系统，在虚拟运行环境中运行恶意文件，从而侦测出这种恶意报文。若互联网向总部局域网传输的报文携带了利用linux操作系统进行恶意操作的恶意文件，网络安全设备使用虚拟运行环境模拟linux操作系统，在虚拟运行环境中运行恶意文件，从而侦测出这种恶意报文。由此可见，该方法能够为总部局域网有效防范来自互联网的恶意流量，提高总部局域网的网络安全。以下通过图13实施例，对本申请实施例附图10所描述的恶意文件的检测方法进行举例说明。在附图13所示的实施例中，网络安全设备为图11中的第二网络安全设备。测试文件为数据中心的边界进入或流出的报文中携带的文件。换句话说，附图13描述的方法流程关于部署在数据中心的边界的网络安全设备如何保护数据中心的网络安全。应理解，图13实施例与图10实施例同理的步骤还请参见图10实施例，在图13实施例中不做赘述。参见图13，图13是本申请实施例提供的一种网络安全的保护方法的流程图，如图13所示，该方法可以包括以下步骤1301至步骤1306。步骤1301、第二网络安全设备采集从数据中心的边界进入或流出的报文，得到该报文携带的测试文件，该测试文件为第一操作系统的可执行文件。步骤1302、第二网络安全设备在虚拟运行环境中运行测试文件。步骤1303、第二网络安全设备获得测试文件在运行过程中调用的第一api序列。步骤1304、第二网络安全设备在第二操作系统中执行第二api序列。步骤1305、第二网络安全设备基于第一api序列被调用过程中测试文件的行为特征，判断测试文件是否为恶意文件。图13实施例中的步骤1302的具体细节请参考图4实施例中的步骤403，图13实施例中的步骤1303的具体细节请参考图4实施例中的步骤404，图13实施例中的步骤1304的具体细节请参考图4实施例中的步骤405，图13实施例中的步骤1305的具体细节请参考图4实施例中的步骤406，为了简洁，在此不再赘述。步骤1306、若测试文件为恶意文件，第二网络安全设备上报在该数据中心的边界检测到恶意流量。通过本申请实施例提供的方法，通过在数据中心的边界部署网络安全设备，由网络安全设备采集网络出口中出入的报文，实施跨平台动态检测恶意文件的方案，以对报文中携带的测试文件进行检测，依据检测结果进行入侵防御。通过该方法，若数据中心内部传输的报文携带了利用windows操作系统进行恶意操作的恶意文件，网络安全设备使用虚拟运行环境模拟windows操作系统，在虚拟运行环境中运行恶意文件，从而侦测出这种恶意报文。若互联网向数据中心传输的报文携带了利用linux操作系统进行恶意操作的恶意文件，网络安全设备使用虚拟运行环境模拟linux操作系统，在虚拟运行环境中运行恶意文件，从而侦测出这种恶意报文。由此可见，该方法有助于发现数据中心内网传播的恶意文件，有助于保护服务器核心资产，发现内网潜伏的攻击、恶意扫描，渗透等。以下通过图14实施例，对本申请实施例附图10所描述的恶意文件的检测方法进行举例说明。在附图14所示的实施例中，网络安全设备为图11中的第三网络安全设备。测试文件为核心部门内部传输的报文中携带的文件。换句话说，附图14描述的方法流程关于部署在核心部门边界的网络安全设备如何保护核心部门的网络安全。应理解，图14实施例与图10实施例同理的步骤还请参见图10实施例，在图14实施例中不做赘述。参见图14，图14是本申请实施例提供的一种网络安全的保护方法的流程图，如图14所示，该方法可以包括以下步骤1401至步骤1406。步骤1401、第三网络安全设备采集核心部门内部传输的报文，得到该报文携带的测试文件，该测试文件为第一操作系统的可执行文件。步骤1402、第三网络安全设备在虚拟运行环境中运行测试文件。步骤1403、第三网络安全设备获得测试文件在运行过程中调用的第一api序列。步骤1404、第三网络安全设备在第二操作系统中执行第二api序列。步骤1405、第三网络安全设备基于第一api序列被调用过程中测试文件的行为特征，判断测试文件是否为恶意文件。图14实施例中的步骤1402的具体细节请参考图4实施例中的步骤403，图14实施例中的步骤1403的具体细节请参考图4实施例中的步骤404，图14实施例中的步骤1404的具体细节请参考图4实施例中的步骤405，图14实施例中的步骤1405的具体细节请参考图4实施例中的步骤406，为了简洁，在此不再赘述。步骤1406、若测试文件为恶意文件，第三网络安全设备上报在核心部门内部检测到恶意流量。通过本申请实施例提供的方法，通过在核心部门的边界部署网络安全设备，由网络安全设备采集核心部门中出入的报文，实施跨平台动态检测恶意文件的方案，以对报文中携带的测试文件进行检测，依据检测结果进行入侵防御。通过该方法，若核心部门内部传输的报文携带了利用windows操作系统进行恶意操作的恶意文件，网络安全设备使用虚拟运行环境模拟windows操作系统，在虚拟运行环境中运行恶意文件，从而侦测出这种恶意报文。若互联网向核心部门传输的报文携带了利用linux操作系统进行恶意操作的恶意文件，网络安全设备使用虚拟运行环境模拟linux操作系统，在虚拟运行环境中运行恶意文件，从而侦测出这种恶意报文。由此可见，该方法有助于发现核心部门内网传播的恶意文件，有助于防范内网可疑测试文件传播，横向感染核心部门。以下通过图15实施例，对本申请实施例附图10所描述的恶意文件的检测方法进行举例说明。在附图15所示的实施例中，网络安全设备为图11中的第四网络安全设备。测试文件为分支机构局域网的边界进入或流出的报文中携带的文件。换句话说，附图15描述的方法流程关于部署在分支机构局域网的边界的网络安全设备如何保护分支机构局域网的网络安全。应理解，图15实施例与图10实施例同理的步骤还请参见图10实施例，在图15实施例中不做赘述。参见图15，图15是本申请实施例提供的一种网络安全的保护方法的流程图，如图15所示，该方法可以包括以下步骤1501至步骤1506。步骤1501、第四网络安全设备采集从分支机构局域网的边界进入或流出的报文，得到该报文携带的测试文件。例如，可选地，该报文包括分支机构局域网内部传输的报文、企业总部与分支机构局域网之间传输的报文、外网流入至分支机构局域网的报文或分支机构局域网流出至外网的报文中的至少一项。步骤1502、第四网络安全设备在虚拟运行环境中运行测试文件。步骤1503、第四网络安全设备获得测试文件在运行过程中调用的第一api序列。步骤1504、第四网络安全设备在第二操作系统中执行第二api序列。步骤1505、第四网络安全设备基于第一api序列被调用过程中测试文件的行为特征，判断测试文件是否为恶意文件。图15实施例中的步骤1502的具体细节请参考图4实施例中的步骤403，图15实施例中的步骤1503的具体细节请参考图4实施例中的步骤404，图15实施例中的步骤1504的具体细节请参考图4实施例中的步骤405，图15实施例中的步骤1505的具体细节请参考图4实施例中的步骤406，为了简洁，在此不再赘述。步骤1506、若测试文件为恶意文件，第四网络安全设备上报在分支机构局域网的边界检测到恶意流量。通过本申请实施例提供的方法，通过在分支机构局域网的边界部署网络安全设备，由网络安全设备采集边界中出入的报文，实施跨平台动态检测恶意文件的方案，以对报文中携带的测试文件进行检测，依据检测结果进行入侵防御。通过该方法，若总部局域网向分支机构局域网传输的报文携带了利用windows操作系统进行恶意操作的恶意文件，网络安全设备使用虚拟运行环境模拟windows操作系统，在虚拟运行环境中运行恶意文件，从而侦测出这种恶意报文。若总部局域网向分支机构局域网传输的报文携带了利用linux操作系统进行恶意操作的恶意文件，网络安全设备使用虚拟运行环境模拟linux操作系统，在虚拟运行环境中运行恶意文件，从而侦测出这种恶意报文。由此可见，该方法能够为分支机构局域网有效防范来自总部局域网的恶意流量，避免恶意测试文件、未知威胁在分支机构局域网和总部局域网之间任意扩散，提高分支机构局域网的网络安全。在一些可能的实施例中，可选地，上述方法实施例应用在虚拟化架构下，方法实施例的执行主体是虚拟化架构中网元对应的实体。例如，该虚拟化架构是nfv架构。参见图16，nfv架构包括nfvmano以及vnf，nfvmano有三个主要功能块，分别是nfv编排器、vnf管理器和虚拟基础设施管理器(virtualisedinfrastructuremaneger，vim)。简单来说，nfv编排器能够对服务和资源进行编排，能够控制新的网络服务并将vnf集成到虚拟架构中，nfv编排器还能够验证并授权nfv基础设施的资源请求。vnf管理器能够管理vnf的生命周期。vim能够控制并管理nfv基础设施，包括计算资源、存储资源以及网络资源等。为了是nfvmano行之有效，它必须与现有系统中的api集成，以便跨多个网络域使用多个厂商的技术，同样地，运营商的运营支撑系统(operationsupportsystem，oss)和商务支撑系统(businesssupportsystem，bss)也需要与nfvmano系统实现互操作。例如，可选地，图16中的每个组件的功能如下。网络功能虚拟化编排器(networkfunctionvirtualizationorchestrator，nfvo)，用于实现对网络服务描述符(networkservicedescriptor，nsd)、虚拟网络功能转发图(virtualnetworkfunctionforwardinggraph，vnffg)的管理及处理，对网络服务的生命周期的管理，以及和虚拟网络功能管理器(virtualnetworkfunctionmanager，vnfm)配合，实现对虚拟网络功能(virtualnetworkfunction，vnf)的生命周期的管理和虚拟资源的全局视图功能。vnfm用于实现对vnf的生命周期的管理，包括vnf描述符(vnfdescriptor，vnfd)的管理、vnf的实例化、vnf实例的弹性伸缩(例如，扩容scalingout/up，和/或缩容scalingin/down)、vnf实例的治愈(healing)以及vnf实例的终止。vnfm还支持接收nfvo下发的弹性伸缩(scaling)策略，实现自动化的vnf的弹性伸缩。虚拟基础设施管理器(virtualisedinfrastructuremanager，vim)主要负责基础设施层的硬件资源、虚拟化资源的管理(包括，预留和分配)，以及虚拟资源状态的监控和故障上报，面向上层应用提供虚拟化资源池。运营和商务支撑系统(operationsandbusinesssupportsystems，oss/bss)指运营商现有的运行维护系统。网元管理系统(elementmanager，em)针对vnf执行传统的故障、配置、用户、性能和安全的管理(faultmanagement，configurationmanagement，accountmanagement，performancemanagement，securitymanagement，fcaps)的功能。虚拟化网络功能(virtualizednetworkfunction，vnf)对应于传统非虚拟化网络中的物理网络功能(physicalnetworkfunction，pnf)，例如，虚拟化的演进分组核心网(evolvedpacketcore，epc)的移动性管理实体(mobilitymanagemententity，mme)、服务网关(servicegateway，sgw)、分组数据网关(packetdatanetworkgateway，pgw)等节点。网络功能的功能性行为和状态与虚拟化与否无关，nfv技术需求希望vnf和pnf拥有相同的功能性行为和外部接口。其中，可选地，vnf包括一个或多个更低功能级别的vnf组件(virtualnetworkfunctioncomponent，vnfc)。nfv基础设施(nfvinfrastructure，nfvi):包括硬件资源、虚拟资源和虚拟化层。从vnf的角度来说，虚拟化层和硬件资源看起来是一个能够提供所需的虚拟资源的完整实体。在一些实施例中，可选地，nfvi的硬件资源是异构系统，该异构系统包括使用了不同类型指令集和体系架构的硬件，该硬件包括计算硬件、存储硬件、网络硬件等。比如如图16所示，该异构系统包括x86cpu以及armcpu。nfvi的虚拟化层用于实现上述方法实施例描述的操作系统模拟的功能以及指令转换的功能。nfvi的虚拟资源包括容器，该容器用于提供上述方法实施例描述的虚拟运行环境，该容器提供为vnf。以下通过图17实施例，对本申请实施例附图4所描述的恶意文件的检测方法进行举例说明。在附图17所示的实施例中，恶意文件的检测方法应用在nfv架构中，检测设备为vnf。软件提供商通过nfvmano中的nfvo、vnfm或vim，向检测设备下发测试文件，检测设备对测试文件的检测结果可以返回给nfvmano。可选地，若恶意文件检测的方法通过容器实现，vnf通过运行容器，以进行恶意检测，该容器由nfvmano下发至vnf。可选地，在nfvmano中部署caas管理器，由该caas管理器向vnf下发容器。可选地，由nfvmano中的其他网元向vnf下发容器。如此，实现容器化的vnf，该容器化的vnf通过运行容器，对测试文件进行恶意文件检测。其中，容器化的vnf是指在容器上创建的vnf，容器化的vnf的实例包括一个或多个vnfc实例。可选地，一个vnfc映射为caas服务中的一个容器应用，或者，一个vnf映射为caas服务中的一个容器应用。以下结合图17，对基于nfv架构进行恶意文件检测的方法流程进行描述，该方法可以包括以下步骤1701至步骤1706。步骤1701、nfvmano向vnf发送测试文件，该测试文件为第一操作系统的可执行文件。步骤1702、vnf接收测试文件，在虚拟运行环境中运行测试文件。步骤1703、vnf获得测试文件在运行过程中调用的第一api序列。步骤1704、vnf在第二操作系统中执行第二api序列。步骤1705、vnf基于第一api序列被调用过程中测试文件的行为特征，判断测试文件是否为恶意文件。步骤1706、vnf向nfvmano发送检测结果。nfv架构中，各个网元的功能通常不再依赖于专用的硬件实现，而是将电信网络中的各个网元虚拟化为各个软件，将各个软件部署在通用的硬件上，以便实现了软件和硬件的解耦。通过本申请实施例提供的方法，由于令恶意文件的检测功能摆脱对特定硬件的依赖，不必采用专用的硬件实现恶意文件的检测流程，因此，刚好满足了nfv中软硬件解耦的根本目标，可以将检测恶意文件的功能虚拟化为vnf，应用在nfv这种虚拟化架构下，从而为nfv的应用扩展出恶意文件检测这种场景。以上介绍了本申请实施例的恶意文件的检测方法，以下介绍本申请实施例的恶意文件的检测装置，应理解，该应用于恶意文件的检测装置其具有上述方法实施例的执行主体的任意功能。图18是本申请实施例提供的一种恶意文件的检测装置的结构示意图，如图18所示，该恶意文件的检测装置包括获取模块1801、运行模块1802、执行模块1803和判断模块1804。获取模块1801，用于获取测试文件，例如可以用于执行上述方法实施例中的步骤402、步骤501、步骤801、步骤903、步骤1002、步骤1201、步骤1301、步骤1401、步骤1501或步骤1702；运行模块1802，用于执行运行测试文件，例如可以用于执行上述方法实施例中的步骤403、步骤502、步骤802、步骤904、步骤1003、步骤1202、步骤1302、步骤1402、步骤1502或步骤1703；获取模块1801，还用于获取第一api序列，例如可以用于执行上述方法实施例中的步骤404、步骤503、步骤803、步骤905、步骤1004、步骤1203、步骤1303、步骤1403、步骤1503或步骤1703；执行模块1803，用于执行第二api序列，例如可以用于执行上述方法实施例中的步骤405、步骤504、步骤804、步骤906、步骤1005、步骤1204、步骤1304、步骤1404、步骤1504或步骤1704；判断模块1804，用于判断测试文件是否为恶意文件，例如可以用于执行上述方法实施例中的步骤406、步骤505、步骤805、步骤907、步骤1006、步骤1205、步骤1305、步骤1405、步骤1505或步骤1705。可选地，执行模块1803，用于执行步骤405中的步骤一至步骤三。可选地，执行模块1803，用于执行步骤504中的步骤(1)至步骤(3)。可选地，执行模块1803，用于执行步骤8041至步骤8043。可选地，执行模块1803，用于执行步骤405中的步骤a至步骤b。应理解，图18实施例提供的恶意文件的检测装置对应于上述方法实施例中的恶意文件的检测设备，恶意文件的检测装置中的各模块和上述其他操作和/或功能分别为了实现方法实施例中的恶意文件的检测设备所实施的各种步骤和方法，具体细节可参见上述方法实施例，为了简洁，在此不再赘述。应理解，图18实施例提供的恶意文件的检测装置在检测恶意文件时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将恶意文件的检测装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的恶意文件的检测装置与上述恶意文件的检测方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在检测设备上运行时，使得检测设备执行上述方法实施例提供的恶意文件的检测方法。本申请实施例还提供了一种芯片，当该芯片在检测设备上运行时，使得检测设备执行上述方法实施例提供的恶意文件的检测方法。该芯片可以是通用处理器，该通用处理器包括处理电路和与该处理电路内部连接通信的输入接口以及输出接口，该处理电路用于通过输入接口执行上述各个方法实施例中获取测试文件的步骤，该处理电路用于执行上述各个方法实施例中运行测试文件、获取第一api序列、执行第二api序列、判断测试文件是否为恶意文件的步骤。可选地，该通用处理器还可以包括存储介质，该处理电路用于通过存储介质执行上述各个方法实施例中的存储步骤。存储介质可以存储处理电路执行的指令，该处理电路用于执行存储介质存储的指令以执行上述各个方法实施例。本领域普通技术人员可以意识到，结合本文中所公开的实施例中描述的各方法步骤和单元，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各实施例的步骤及组成。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域普通技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参见前述方法实施例中的对应过程，在此不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，该单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。该作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本申请实施例方案的目的。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。该集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例中方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。以上描述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本
技术领域：
：的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机程序指令。在计算机上加载和执行该计算机程序指令时，全部或部分地产生按照本申请实施例中的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机程序指令可以从一个网站站点、计算机、服务器或数据中心通过有线或无线方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如软盘、硬盘、磁带)、光介质(例如，数字视频光盘(digitalvideodisc，dvd)、或者半导体介质(例如固态硬盘)等。本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。以上描述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。当前第1页12当前第1页12