面向云平台的多样化恶意软件检测架构

高超 郑小妹 贾晓启

摘要：近年来，恶意软件对物理机和云平台上虚拟机均构成巨大的安全威胁。在基础设施即服务（IaaS）云平台上部署传统的杀毒软件、防火墙等恶意软件检测工具存在以下问题：1）检测工具可能被破坏或者关闭；2）单一的检测工具效果不理想；3）检测工具可能被加壳等方式绕过；4）需要给每台客户机安装额外软件，难以部署实施。为此提出一种面向云平台的多样化恶意软件检测架构。该架构利用虚拟化技术截获客户机的特定行为，抓取客户机内软件释放的代码，通过多种杀毒软件多样化的扫描确定软件的恶意性。采用的动态内存提取的方式对客户机完全透明。最后在Xen上部署该架构并进行恶意软件检测测试，该架构对加壳恶意软件的检测率为85.7%，比杀毒软件静态扫描的检测率高14.3个百分点。实验结果表明，在云平台上采用多样化恶意软件检测框架能更好地保障客户机的安全。

关键词：

云平台；恶意软件检测；虚拟化；多样化；动态扫描

中图分类号： TP309.5 文献标志码：A

0引言

恶意软件[1]是指带有攻击意图所编写的一段程序，用于破坏计算机操作、收集敏感信息或访问专用计算机。现有的恶意软件检测主要方法有2种[2]：一种方法是基于特征匹配。通过提取软件二进制文件特征或者动态的行为特征与恶意代码库的特征进行比对来判断是否是恶意软件。另一种方法是基于异常检测。通过发现软件行为中与正常行为不符的方式来判定是恶意软件。现在，恶意软件的检测主要由操作系统上的杀毒软件完成。在基础设施即服务（Infrastructure as a Service， IaaS）云平台客户机中部署传统杀毒软件存在以下问题：1）杀毒软件存在被关闭和破坏风险。杀毒软件处于客户机内部，恶意软件通过技术手段检测杀毒软件的存在后进行关闭和破坏操作。2）杀毒软件的静态扫描方式容易被加壳等手段绕过。3）单一杀毒软件的检测效果不理想。市面上主流杀毒软件的检测效果表现出较大差异。同一样本在一部分杀毒软件中报告安全，在另一部分中报告存在安全威胁。多种杀毒软件同时进行恶意软件检测表现出更好的效果，但是在同一台客户机中安装多种杀毒软件，除了普遍存在的兼容性问题，还会大量消耗客户机资源，严重影响性能。4）IaaS云平台的服务提供商需要在每个客户机中预装杀毒软件，这种方式很难被接受并且不利于快速扩展。鉴于上述原因，在云平台上客户机外部统一部署恶意软件的检测模块，提供客户机多样化的动态内存扫描服务有重大意义，既很大程度上降低被关闭和破坏的风险，增加了绕过的难度，还利用云平台强大的计算能力、技术基础，又能减少在每个客户机中部署杀毒软件的资源消耗。

作为云平台的基础技术，虚拟化技术[3]是通过在物理层和操作系统层之间加入中间层，即Hypervisor层。Hypervisor通过内存管理、外设管理、中央处理器（Central Processing Unit， CPU）调度等模块的重新设计完成内存虚拟化、外设虚拟化和CPU虚拟化，在同一套硬件资源上虚拟出多套虚拟硬件资源。多个操作系统可以互不影响地在同一台物理机上同时运行，复用物理资源。由于Hypervisor可以直接控制CPU、内存等硬件，在云平台上通过Hypervisor实现系统监控、恶意软件的检测在学术界逐渐的发展。

针对恶意软件检测在云平台上面临的诸多问题，本文提出了一种面向云平台的多样化恶意软件检测架构。该架构采用修改影子页表实现这一新方法，在对客户机完全透明的情形下，利用虚拟化技术截获客户机的特定行为，抓取客户机内软件释放的代码，最后综合多种恶意软件检测工具的结果做出软件是否恶意的判断，实验表明该架构对加壳恶意软件的检测效果比杀毒软件静态扫描的检测效果更好。

1相关研究

研究人员对利用虚拟化技术进行监控和恶意软件检测进行了大量的研究，取得了一些这方面的成果。基于虚拟化技术的监控技术按照监控软件的部署位置分为外部监控和内部监控。内部监控软件，与传统的监控软件有些相似，与被监控虚拟机位于同一个操作系统内。外部监控软件位于被监控系统外，借助Hypervisor获得被监控虚拟机的二进制信息，通过技术手段恢复成操作系统的系统调用或者进程创建等消息。这方面的监控软件很多，比如Panorama是Yin等[4]设计的基于QEMU（Quick Emulator）[5]的系统级别监视系统，用于分析恶意软件的执行流程和感染路径。VAMPiRE[6]、Cobra[7]是已经提出细粒度的监控软件框架：其中VAMPiRE是通过操作内存的读写运行权限实现在系统的任何地方下断点；Cobra采用将待监控代码分块运行于低权限的环境中，通过修改内存属性等，完成对待监控代码的行为分析。外部监控系统调用在VMwatcher（Virtual Machine watcher）[8]和TTAnalyze[9]中实现。VMwatcher支持多种虚拟化工具比如Xen[10]、KVM（Kernel Virtual Machine）[11]、VMware，它根据磁盘、内存信息等重构客户机语义，进而分析是否存在恶意软件。TTAnalyze在QEMU模拟的环境中执行恶意程序，并记录恶意程序的系统调用和Windows应用程序编程接口（Application Programming Interface， API）。这些安全软件利用虚拟化技术的隔离性质，通过直接访问被监控虚拟机的内存，重构其内核数据结构，确定虚拟机的状态并采取相应的措施。这些都属于被动监控的范畴，被动的监控框架不适合于入侵防御系统（Intrusion Prevention System， IPS）等需要主动进行安全防御的软件。Lares[12]、SIM（Secure InVM）[13]属于主动监控框架，它们通过在内核的适当位置放置钩子函数进行监控，Lares导致了大量的hypervisorguest切换开销，不适合于细粒度的监控，SIM通过Intel硬件虚拟化一些特殊技术，消除了hypervisorguest切换开销。HVSM（Hybrid Virtualization Security Monitor）[14]和RTKDSM（RealTime Kernel Data Structure Monitoring）[15]是最近提出的面向云平台的虚拟机监控框架。HVSM对虚拟机中所有进程进行hash校验，通过比对hash校验值判断进程是否被恶意软件感染。RTKDSM基于启发式的内存分析工具实现对虚拟机内存的分析，完成了支付数据流跟踪、应用程序白名单、进程完整性校验等一系列功能。

上述的各种框架，主要存在三方面的不足导致不能应用于云平台的恶意软件检测：1）以TTAnalyze为代表的架构是基于QEMU虚拟机，不能直接应用于当前使用的KVM或Xen虚拟机的云平台；2）以SIM为代表的内部监控框架，需要在客户机内安装特定的功能模块甚至修改客户机内核，本文认为这种框架很难快速地部署在云平台上，不具有通用性；3）HVSM和RTKDSM主要功能是保障虚拟机中进程和数据的完整性，不能用于检测虚拟机中恶意软件。本文针对恶意软件加壳等反检测技术，提出一种面向云平台的多样化恶意软件检测架构，在保持对客户机透明的情况下，检测客户机中恶意软件，并基于Xen虚拟化平台实现原型系统。

2架构设计

2.1威胁模型

近年来，恶意软件的设计越来越复杂，隐藏水平愈加高级。IaaS云服务商提供客户机恶意软件扫描服务存在以下问题：1）杀毒软件和恶意软件运行环境缺少有效的隔离，存在被关闭和破坏的风险。2）单一杀毒软件的检测效果与多种杀毒软件联合查杀效果相比存在较大差距。3）加壳恶意软件可能绕过杀毒软件检测。这种恶意软件，利用特殊的算法对代码段、数据段等进行加密压缩，并添加入解密头。其载入内存时，解密头动态的解密出恶意代码，并将控制权交给恶意软件。4）在客户机内安装模块，不便于迅速扩展也可能引入新的安全漏洞。客户机内安装模块可能不被云服务的消费者接受，安装的模块可能成为出现信息泄露等安全事件后被怀疑的对象。针对恶意软件带来的安全威胁和云平台部署需求，本文提出一种面向云平台的多样化恶意软件检测架构。该架构部署在操作系统外部。在对客户机透明的情况下，动态截获客户机中恶意软件释放恶意载荷过程，通过多种杀毒软件的联合查杀完成对云平台上加壳恶意软件检测的目的。

2.2架构设计

本文架构中，将云平台分为2部分：一部分是服务消费者控制的客户机；另一部分是服务提供商控制的安全服务域和Hypervisor。如图1，通过在Hypervisor中增加监控模块、安全模块、数据中心，在安全服务域中增加服务线程，云服务商提供客户机内恶意软件检测服务。没有更改客户机的操作系统、模块、应用软件，对客户机保持透明。每个部分的工作如下。

监控模块通过在Hypervisor的客户机捕获处理过程中插入hook函数，hook影子页表修改事件s，过滤不关心的客户机进程，并从内存和寄存器及相关结构体数据结构中重构操作系统语义env，将这些数据传给安全模块。

安全模块接收监控模块发送的事件信息（s，env），按设定的格式存储到数据中心。然后选择并通知某个安全服务域。同时，安全模块还会响应安全服务域的Hypercall请求。

数据中心负责存储相关的事件信息（s，env）。

服务线程服务线程被唤醒后，通过Hypercall的方式请求Hypervisor中安全模块的服务，负责和Hypervisor进行数据交换。

需要指出的是，与在客户机内部安装传统的杀毒软件、防火墙等恶意软件检测工具的方式相比，本文提出的架构具有4个特点：1）Hypervisor和客户机、安全服务域和客户机之间资源被很好地隔离，导致本文架构不易被关闭和破坏。2）安装不同恶意软件检测工具的多个安全域的综合结果检测率更高。3）该架构通过截获不同的事件，完成动态提取恶意软件释放的代码。相比静态扫描的方式，理论上更难被绕过。4）添加的所有模块（监控模块、安全模块、数据中心等）部署于服务提供商控制的安全服务域和Hypervisor中，所以不需要在客户机中安装额外软件。

2.3恶意软件检测思路

从恶意软件执行过程分析，恶意代码可以直接被操作系统载入内存，也可以以加密数据的形式载入内存，等到特定的条件触发后被解密释放到内存中。通过在本架构中抓取软件的载入内存行为或者释放代码行为，取出其载入的代码或者释放的代码，用这些代码块的恶意性来判断软件的恶意性。为了保持对客户机的透明性，不能采用在Hypervisor中利用客户机操作系统的函数hook的方式或者和客户机内模块交互的方式来获取这些行为。希望在本框架下，监控模块选取特定的事件S，等价的截获代码载入内存或者解密释放的过程，利用寄存器、内存值和相关数据结构用语义重构的方式恢复操作系统状态env，并将事件（S，env）发送给安全模块，安全模块通过地址转换函数确定正在操作的内存块，将内存块的起始地址、大小以及（S，env）存储到数据中心的日志中，并通知某个安全服务域，安全服务域中的服务线程通过Hypercall的方式请求拷贝内存块，并将内存块保存到文件中，借助于主流杀毒软件的文件扫描功能来判断软件的恶意性。

2.4事件的选取

在事件选取过程中，利用了影子页表[16]和Intel禁止运行（NoeXecute， NX）技术。在内存虚拟化的实现中，存在两种不同的页表：一种是客户机维护的客户机页表；另一种是Hypervisor维护的影子页表。客户机页表将客户机虚拟地址映射为客户机物理地址。影子页表将客户机地址映射为物理地址。客户机物理地址是物理地址的抽象层，它们之间存在映射关系。客户机在读写或者运行某个地址时发生页错误，Hypervisor会同步该地址的影子页表和客户机页表。比如软件第一次载入内存或者通过VirtualProtect更改内存属性会更改相应的客户机页表项。当实际用到这一地址的时候，通过影子页表页错误处理函数将客户机页表和影子页表同步。在Intel CPU中，执行禁止位（eXecute Disable， XD）用于区分内存中的指令存储区域和数据存储区域。对支持数据执行保护（Data Executing Prevention， DEP）的操作系统会对程序数据段设置XD位，防止由于缓冲区溢出等漏洞导致执行数据段的shellcode。称XD未设置内存区域为可执行。

希望通过选取特定事件S来获取客户机中软件的可执行代码。由于页面分配可以同时设置可写和可执行属性，后续对页面的写操作能够产生新的可执行代码。这样可执行代码来源于两种情形，如图 2所示。

S1：分配一块属性为可写的内存，写入数据，更改页表属性为可执行。

S2：分配一块可写可运行的内存，写入代码。

对于S1，客户机更改页表属性，会导致页中内容被用到时，发生影子页表的页错误，Hypervisor可以获得该事件。对于S2，如果设置影子页表为可写可运行属性，后续对页面的写操作将不能截获。通过更改影子页表的实现，对客户机内存可写可执行页面采用特殊的处理方式：对于需要将影子页表更改为可写可运行的属性的情况，根据当前页错误类型去掉写或运行属性。也就是，页错误类型为写错误，Hypervisor同步影子页表的时候只给写权限；页错误类型为取指错误，给予运行权限并去掉写权限。采取这种处理方式，能够获得对可写可执行页面的后续操作同时不影响软件的正常工作。

3恶意软件检测架构原型系统实现

在Xen4.4.0上实现了上述架构的原型。机器硬件配置是4核64位Intel Core i34150（支持VME、NX）CPU，内存为4GB，采用Ubuntu14.04 LTS 内核版本3.13.052作为宿主操作系统，客户机采用32位Windows 7操作系统。

操作系统中除了恶意软件还有很多其他正常软件。对所有的进程都进行事件的截获会带来很大的性能消耗。为减轻这种性能消耗，一般有两种策略：一种是忽略系统和可信任进程（即白名单策略）；另一种是只处理疑似样本进行。在本文的实现中，只对疑似样本进行事件截获。

3.1初始化阶段

安全服务域dom0首先创建服务线程thread，thread申请足够大的空间512个页的空间作为Hypervisor和dom0进行数据交换的缓冲区。然后，dom0注册中断处理函数scan_interrupt并绑定事件通道，这一步通过bind_virq_to_irqhandler完成。最后，dom0通过VMCALL指令通知Hypervisor对指定的domU设置疑似样本的名字规则（比如virus前缀）并开启事件截获。

3.2函数hook和语义重构

本文的hook函数放置在Xen影子页表页错误的处理函数sh_page_fault中。该函数首先判断页错误是否由影子页表和客户机页表不同步导致：如果是则将客户机页表相应的页面“传送”给影子页表；如果不是，则将错误直接传给客户机。本文在sh_page_fault读取完客户机页表相应项，并计算出需要对影子页表修改的值后，在实施修改之前（即在sh_page_fault中shadow_set_l1e语句前）加入hook函数scan_shadow_page_fault。该hook函数只有开启了事件截获才会执行。

截获指定事件后，从当前VMCS结构中读取客户机gdt表。gdt表中第6项、第7项分别包含处理器控制区域struct _KPCR结构和当前线程环境块struct _TEB结构的首地址。本文从struct _KPCR+0x124处得到线程控制结构ethread，从struct _TEB中恢复整个进程相关的信息，比如进程标识符PID、进程名字、进程的二进制文件路径。

3.3限制到指定进程

对获取到的事件都进行语义重构会引入较大的性能消耗，本文采取了特别的方式减少语义重构的次数。客户机进程切换会对cr3赋值，该步骤需要hypervisor辅助完成。采用在cr3切换到疑似进程时设置标志位表示需要进行语义重构，在cr3切换出去时清除标志位的方式，避免在可信任进程上进行语义重构的操作。

3.4事件处理

当事件发生时，根据当前寄存器值，内存和Windows 7 相关数据结构恢复出进程相关的信息。根据页错误的虚拟地址、客户机页表和影子页表的对应项，对S1和S2分别进行处理（如程序1）。对于S1事件，过滤发生在内核空间中的页表属性变化，对用户空间的页表属性变化，则记录其物理页mfn。对于S2事件，如果页错误是因为没有写权限引起的，则去掉运行权限，给予写权限；如果是因为没有运行权限引起的，则去掉写权限，给予运行权限。

程序1事件处理函数。

程序前

Function handle_s1（va，Gl1e，Sl1e）

If （va>0x80000000）//不处理内核地址

Return；

If （（！（Sl1e & PAGE_X）） && （Gl1e & PAGE_X））

Log_this_page（Sl1e）；//记录这一页，拷贝

Function handle_s2（Gl1e，regs）

If （Gl1e & PAGE_X） && （Gl1e & PAGE_W）//页面可写可执行

If （regs->error_code & PEFC_insn_fetch）//当前错误是运行错误，去掉写权限

Gl1e &=～PAGE_W

If （regs->error_code & PEFC_write_access）//当前错误是写错误，去掉运行权限

Gl1e&=～PAGE_X

程序后

3.5异步读写

事件相关信息（物理页、进程名字、虚拟地址）记录完毕。Hypervisor用send_guest_vcpu_virq函数给dom0发送中断后，立即将控制权交还给客户机操作系统。中断处理函数scan_interrupt唤醒服务线程thread。thread通过VMCALL指令请求将相应的页面拷贝到指定内存中。采用这种异步的方式，能够使客户机等待的时间特别短，对客户机性能影响小。

服务线程最终将相应的内存块分别写入文件。由于现在没有各种杀毒软件的开放应用程序编程接口（Application Programming Interface， API）API，不能利用API对内存进行扫描。暂时采取写入文件，将多种杀毒软件的扫描结果作为是否是恶意软件的判断依据。

4实验结果

文献[2]中提到，恶意软件检测主要有基于特征匹配的方式和基于异常检测两种。现有的杀毒软件一般采用了基于特征匹配的静态扫描方式，首先对疑似的二进制文件进行特征提取和计算hash校验值，并将这些值和恶意软件特征库进行比对。下面，本文通过加壳恶意软件检测实验，说明本文架构对加壳恶意软件的检测效果比杀毒软件静态扫描的检测效果更好。

实验中，在原型系统的一个客户机中运行收集到疑似恶意软件样本，原型系统会自动提取出程序动态释放的内存块。本文的云平台采用多样化的扫描方式，采用Avast（11.1.2241）、Avira（15.0.13.210）、Kaspersky（15.0.0）、Dr.Web（10.0）、McAfee（14.0.1127）五款杀毒软件对提取出的全部内存块进行扫描。如果任何一个杀毒软件检测报告恶意软件，则认为该软件恶意。如果都没有报告恶意软件，则认为该软件是正常软件。作为对比，同时用Avast（11.1.2241）、Avira（15.0.13.210）、Kaspersky（15.0.0）、Dr.Web（10.0）、McAfee（14.0.1127）五款杀毒软件直接对疑似样本的二进制文件进行扫描，判断是否恶意方式与原型系统中一致。

实验过程中，对收集的107个疑似样本（标号为样本1到样本107）进行加壳处理。加壳工具采用了ASPacker、ACProtect、NSpack、Upack等工具。其中由于61个疑似样本在Windows 7 32位环境不能运行，采用其他46个进行测试，得到相应的实验结果。图3是原型系统的恶意软件检测数目和杀毒软件检测数目对比。本文提出的多样化恶意软件检测框架的检测率为85.7%，比传统静态扫描的71.4%检测率高14.3个百分点。

10个样本（如表1）在原型系统中报告存在恶意软件，但是杀毒软件静态扫描不能检测出恶意软件。导致这种差异的原因是，静态扫描加壳恶意软件时，对疑似的二进制文件进行特征提取和计算hash校验值的方式受到壳的干扰和原始二进制加密等方面的影响，导致特征码或hash值的改变，从而绕过检测。而在本文实现的原型系统中，通过截获恶意软件释放恶意代码的过程，对释放过程完成后的代码进行特征提取，此时外壳已经执行完成，加密的二进制也完成了解密，所以能够提取出原始软件的特征，因此原型系统通过提取恶意软件未加壳时的特征发现恶意软件。

5个样本（如表2）在原型系统中检测不出，但是杀毒软件能够报告威胁。通过分析，导致这种情形的原因可能如下：1）恶意软件未能触发恶意载荷载入内存的行为；2）恶意软件通过面向返回的编程（ReturnOriented Programming， ROP）[17]或者returnintolibc[18]等方式利用系统动态链接库文件（Dynamic Link Library， DLL）相关的代码。接下来，为了解决上述问题，将完善恶意软件自动触发机制，并结合文献[19]中的相关工作，完善对利用ROP和returnintolibc技术的恶意软件的检测。

5结语

本文提出了一种面向云平台的多样化恶意软件检测架构，利用虚拟化技术截获客户机的特定行为，抓取客户机内软件释放的代码，通过多种杀毒软件多样化的扫描确定软件的恶意性。已经在Xen上实现了整个架构的原型。在测试工作中，实现的原型系统对加壳恶意软件的检测效果比杀毒软件静态扫描的检测效果更好。

接下来，将完善恶意软件的自动触发机制，使恶意软件在条件未满足时释放恶意载荷，达到检测的目的；同时，将完善对采用ROP和returnintolibc方式的恶意软件的检测。

参考文献：

[1]

Wikimedia Foundation. Malware [EB/OL]. [20160304]. https：//en.wikipedia.org/wiki/Malware.

[2]

IDIKA N， MATHUR A P. A survey of malware detection techniques [D]. West Lafayette， IN： Purdue University， 2007： 1-48. http：//citeseerx.ist.psu.edu/viewdoc/download？doi=10.1.1.75.4594&rep=rep1&type=pdf.

[3]

UHLIG R， NEIGER G， RODGERS D， et al. Intel virtualization technology [J]. Computer， 2005， 38（5）： 48-56.

[4]

YIN H， SONG D， EGELE M， et al. Panorama： capturing systemwide information flow for malware detection and analysis [C]// Proceedings of the 14th ACM Conference on Computer and Communications Security. New York： ACM， 2007： 116-127.

[5]

QEMU main page [EB/OL]. [20160304]. http：//wiki.qemu.org/Main_Page.

[6]

VASUDEVAN A， YERRABALLI R. Stealth breakpoints [C]// Proceedings of the 21st Annual Computer Security Applications Conference. Piscataway， NJ： IEEE， 2005： 383-392.

[7]

VASUDEVAN A， YERRABALLI R. Cobra： finegrained malware analysis using stealth localizedexecutions [C]// Proceedings of the 2006 IEEE Symposium on Security and Privacy. Piscataway， NJ： IEEE， 2006： 265-279.

[8]

JIANG X， WANG X， XU D. Stealthy malware detection through VMMbased outofthebox semantic view reconstruction [C]// Proceedings of the 14th ACM Conference on Computer and Communications Security. New York： ACM， 2007： 128-138.

[9]

BAYER U， KRUEGEL C， KIRDA E. TTAnalyze： a tool for analyzing malware [EB/OL]. [20151220]. https：//www.cs.ucsb.edu/～chris/research/doc/eicar06_ttanalyze.pdf.

[10]

Linux Foundation. The Xen project [EB/OL]. [20160304]. http：//www.xenproject.org/.

[11]

LinuxKVM organization. Kernel virtual machine [EB/OL]. [20160304]. http：//www.linuxkvm.org/page/Main_Page.

[12]

PAYNE B D， CARBONE M， SHARIF M， et al. Lares： an architecture for secure active monitoring using virtualization [C]// SP 2008： Proceedings of the 2008 IEEE Symposium on Security and Privacy. Piscataway， NJ： IEEE， 2008： 233-247.

[13]

SHARIF M I， LEE W， CUI W， et al. Secure inVM monitoring using hardware virtualization [C]// Proceedings of the 16th ACM Conference on Computer and Communications Security. New York： ACM， 2009： 477-487.

[14]

MAO Y， CHEN X， LUO Y. HVSM： an inoutVM security monitoring architecture in IAAS cloud [C]// Proceedings of the 2014 IEEE Information and Network Security. Piscataway， NJ： IEEE， 2014： 185-192.

[15]

HIZVER J， CHIUEH T. Realtime deep virtual machine introspection and its applications [C]// VEE14： Proceedings of the 10th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments. New York： ACM， 2014： 3-14.

[16]

BARHAM P， DRAGOVIC B， FRASER K， et al. Xen and the art of virtualization [J]. ACM SIGOPS Operating Systems Review， 2003， 37（5）： 164-177.

[17]

BUCHANAN E， ROEMER R， SHACHAM H， et al. When good instructions go bad： Generalizing returnoriented programming to RISC [C]// Proceedings of the 15th ACM Conference on Computer and Communications Security. New York： ACM， 2008： 27-38.

[18]

SHACHAM H. The geometry of innocent flesh on the bone： returnintolibc without function calls （on the x86） [C]// Proceedings of the 14th ACM Conference on Computer and Communications Security. New York： ACM， 2007： 552-561.

[19]

JIA X， WANG R， JIANG J， et al. Defending returnoriented programming based on virtualization techniques [J]. Security and Communication Networks， 2013， 6（10）： 1236-1249.