操作系统异常数据的处理方法、装置及设备与流程

本申请涉及网络安全技术领域，尤其是涉及到一种操作系统异常数据的处理方法、装置及设备。

背景技术：

文件系统存储着操作系统中的关键数据，其中在操作系统中文件系统包括磁盘文件系统和注册表，注册表与文件目录结构相似，同时内存也是操作系统一个重要的组成部分，一旦这些区域的数据被篡改，可能导致操作系统行为发生异常。

目前，现有的操作系统异常检测只是针对文件系统进行检测是否存在异常，而没有或是很少关注操作系统其他的关键项，因而如果由于操作系统其他关键项导致出现异常时，现有技术将无法及时检测到以及做相应的安全处理，不但会影响用户使用，而且还可能会造成一定的安全隐患。

技术实现要素：

有鉴于此，本申请提供了一种操作系统异常数据的处理方法、装置及设备，主要目的在于解决现有技术中操作系统异常项检测不全面，不但会影响用户使用，而且还可能会造成一定安全隐患的技术问题。

根据本申请的一个方面，提供了一种操作系统异常数据的处理方法，该方法包括：

监测操作系统对应的多个关键项的安全性，所述多个关键项至少包括安装软件、注册表、wmi、计划任务、系统引导区代码中的一个或多个；

若所述多个关键项中存在异常项，则根据与所述异常项对应预设的目标修复规则，对所述异常项进行修复，其中，不同的异常项都有各自对应预设的修复规则。

可选的，所述操作系统对应的安装软件的安全检测，具体包括：

获取所述操作系统中运行的目标软件的文件列表；

对所述文件列表进行路径和/或文件哈希值的安全检测；

若根据所述路径和/或文件哈希值判定存在异常，则确定所述安装软件对应的关键项为异常项。

可选的，所述操作系统对应的注册表的安全检测，具体包括：

对操作系统注册表项、和/或具备自启动性质项、和/或com组件项进行路径和对应值的安全检测；

若判定所述操作系统注册表项、和/或具备自启动性质项、和/或com组件项存在异常，则确定所述注册表对应的关键项为异常项。

可选的，所述操作系统对应的wmi的安全检测，具体包括：

获取wmi消费者及触发器并进行解析；

对解析内容进行恶意关键字项匹配；

若恶意关键字项匹配成功，则确定所述wmi对应的关键项为异常项。

可选的，所述操作系统对应的计划任务的安全检测，具体包括：

解析计划任务的名称以及所述计划任务的目标文件路径；

对所述计划任务的名称进行异常名称匹配；

若异常名称匹配成功，则获取所述目标文件路径中目标文件进行异常特征匹配；

若异常特征匹配成功，则确定所述计划任务对应的关键项为异常项。

可选的，所述操作系统对应的系统引导区代码的安全检测，具体包括：

将主引导记录mbr数据与所述操作系统干净的mbr数据进行对比；

若存在异常的跳转指令，则确定所述系统引导区代码对应的关键项为异常项。

可选的，若根据所述异常项确定安装包管理软件存在异常，则所述根据与所述异常项对应预设的目标修复规则，对所述异常项进行修复，具体包括：

通过注册表获取所述安装包管理软件的安装目录；

获取所述安装目录中所述安装包管理软件所在的文件夹位置；

若所述文件夹位置存在预定目标文件，则获取所述预定目标文件的文件信息并与异常规则字段描述进行匹配；

若异常规则字段描述匹配成功，则在所述文件夹位置中删除所述预定目标文件。

可选的，在所述根据与所述异常项对应预设的目标修复规则，对所述异常项进行修复之前，所述方法还包括：

根据所述目标修复规则，判断所述操作系统当前的文件系统和/或注册表是否需要后续修复操作；

若所述文件系统和/或注册表需要后续修复操作，则备份修复前所述文件系统和注册表原始位置的数据；

所述根据与所述异常项对应预设的目标修复规则，对所述异常项进行修复，具体包括：

若修复失败导致损坏所述操作系统的当前环境，则利用备份数据修复损坏的所述操作系统的当前环境。

可选的，所述方法还包括：

在对所述异常项进行修复的过程中，对所述目标修复规则进行动态更新。

可选的，所述对所述目标修复规则进行动态更新，具体包括：

获取所述目标修复规则中待更新的原字节码信息，以及与所述原字节码信息对应的标签信息；

将所述原字节码信息和所述标签信息发送给云端服务器，以使得所述云端服务器根据所述标签信息确定是否对所述原字节码信息进行更新；

接收所述云端服务器返回的更新后的新字节码信息；

在所述目标修复规则中更新替换所述原字节码信息为所述新字节码信息。

根据本申请的另一方面，提供了一种操作系统异常数据的处理装置，该装置包括：

监测模块，用于监测操作系统对应的多个关键项的安全性，所述多个关键项至少包括安装软件、注册表、wmi、计划任务、系统引导区代码中的一个或多个；

修复模块，用于若所述多个关键项中存在异常项，则根据与所述异常项对应预设的目标修复规则，对所述异常项进行修复，其中，不同的异常项都有各自对应预设的修复规则。

可选的，所述监测模块，具体用于获取所述操作系统中运行的目标软件的文件列表；

对所述文件列表进行路径和/或文件哈希值的安全检测；

若根据所述路径和/或文件哈希值判定存在异常，则确定所述安装软件对应的关键项为异常项。

可选的，所述监测模块，具体用于对操作系统注册表项、和/或具备自启动性质项、和/或com组件项进行路径和对应值的安全检测；

若判定所述操作系统注册表项、和/或具备自启动性质项、和/或com组件项存在异常，则确定所述注册表对应的关键项为异常项。

可选的，所述监测模块，具体用于获取wmi消费者及触发器并进行解析；

对解析内容进行恶意关键字项匹配；

若恶意关键字项匹配成功，则确定所述wmi对应的关键项为异常项。

可选的，所述监测模块，具体用于解析计划任务的名称以及所述计划任务的目标文件路径；

对所述计划任务的名称进行异常名称匹配；

若异常名称匹配成功，则获取所述目标文件路径中目标文件进行异常特征匹配；

若异常特征匹配成功，则确定所述计划任务对应的关键项为异常项。

可选的，所述监测模块，具体用于将主引导记录mbr数据与所述操作系统干净的mbr数据进行对比；

若存在异常的跳转指令，则确定所述系统引导区代码对应的关键项为异常项。

可选的，所述修复模块，具体用于若根据所述异常项确定安装包管理软件存在异常，则通过注册表获取所述安装包管理软件的安装目录；

获取所述安装目录中所述安装包管理软件所在的文件夹位置；

若所述文件夹位置存在预定目标文件，则获取所述预定目标文件的文件信息并与异常规则字段描述进行匹配；

若异常规则字段描述匹配成功，则在所述文件夹位置中删除所述预定目标文件。

可选的，所述装置还包括：判断模块和备份模块；

所述判断模块，用于根据所述目标修复规则，判断所述操作系统当前的文件系统和/或注册表是否需要后续修复操作；

所述备份模块，用于若所述文件系统和/或注册表需要后续修复操作，则备份修复前所述文件系统和注册表原始位置的数据；

所述修复模块，具体用于若修复失败导致损坏所述操作系统的当前环境，则利用备份数据修复损坏的所述操作系统的当前环境。

可选的，所述装置还包括：

更新模块，用于在对所述异常项进行修复的过程中，对所述目标修复规则进行动态更新。

可选的，所述更新模块，具体用于获取所述目标修复规则中待更新的原字节码信息，以及与所述原字节码信息对应的版本标签信息；

将所述原字节码信息和所述版本标签信息发送给云端服务器，以使得所述云端服务器根据所述版本标签信息确定是否对所述原字节码信息进行更新；

接收所述云端服务器返回的更新后的新字节码信息；

在所述目标修复规则中更新替换所述原字节码信息为所述新字节码信息。

依据本申请又一个方面，提供了一种存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述操作系统异常数据的处理方法。

依据本申请再一个方面，提供了一种操作系统异常数据处理的实体设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述操作系统异常数据的处理方法。

借由上述技术方案，本申请提供的一种操作系统异常数据的处理方法、装置及设备。与目前现有的操作系统异常检测只是针对文件系统进行检测相比，本申请可同时监测操作系统对应的安装软件、注册表、wmi、计划任务、系统引导区代码等多个关键项的安全性，并且对于这些关键项可实现具有针对性的异常项修复。进而可实现对操作系统异常项的全面检测与修复，扩大了操作系统异常项的修复范围，提高了操作系统异常项检测的精确性，在发现操作系统存在异常项时可做到及时响应和快速修复，减少对用户使用的影响，提高了一定的安全性。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

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

图1示出了本申请实施例提供的一种操作系统异常数据的处理方法的流程示意图；

图2示出了本申请实施例提供的另一种操作系统异常数据的处理方法的流程示意图；

图3示出了本申请实施例提供的一种操作系统异常项修复策略动态更新方法的系统架构示意图；

图4示出了本申请实施例提供的一种操作系统异常数据的处理装置的结构示意图；

具体实施方式

下文中将参考附图并结合实施例来详细说明本申请。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

目前现有的操作系统异常检测只是针对文件系统进行检测是否存在异常，而没有或是很少关注操作系统其他的关键项，鉴于此，本实施例提供了一种操作系统异常数据的处理方法，可实现更加全面的操作系统异常项检测，如图1所示，该方法包括：

101、监测操作系统对应的多个关键项的安全性。

其中，多个关键项至少包括安装软件、注册表、wmi(windowsmanagementinstrumentation，windows管理规范)、计划任务、系统引导区代码中的一个或多个。相当于除了监控原有文件系统以外，本实施例还可同时监控这些其他关键项的安全性。

对于本实施例的执行主体可为操作系统异常数据的处理装置或设备，可配置在客户端侧，或者根据实际需求配置在服务器侧。具体可用于操作系统异常项检测与修复处理。

102、若监测到多个关键项中存在异常项，则根据与异常项对应预设的目标修复规则，对异常项进行修复。

其中，不同的异常项都有各自对应预设的修复规则。修复规则中可包括删除、和/或更新、和/或禁用、和/或启用、和/或替换、和/或复制、和/或锁定等操作。并且可选的，这些操作在执行时可以选择是否告知用户。以便考虑实际情况，减少对用户使用的影响。

在本实施例中，可预先针对不同的异常项，编辑各自对应的修复规则脚本，在利用修复规则对异常项修复时，可获取相应的修复规则脚本进行解析，然后执行相应的修复策略指令，进而实现对异常项的有效修复。

本实施例提供的一种操作系统异常数据的处理方法，与目前现有的操作系统异常检测只是针对文件系统进行检测相比，本实施例可同时监测操作系统对应的安装软件、注册表、wmi、计划任务、系统引导代码等多个关键项的安全性，并且对于这些关键项可实现具有针对性的异常项修复。进而可实现对操作系统异常项的全面检测与修复，扩大了操作系统异常项的修复范围，提高了操作系统异常项检测的精确性，在发现操作系统存在异常项时可做到及时响应和快速修复，减少对用户使用的影响，提高了一定的安全性。

进一步的，作为上述实施例具体实施方式的细化和扩展，为了完整说明本实施例的实施过程，提供了另一种操作系统异常数据的处理方法，如图2所示，该方法包括：

201、监测操作系统对应的多个关键项的安全性。

为了说明每个关键项安全性检测的过程，下面给出多个可选实例(a至e)：

a、操作系统对应的安装软件的安全检测，具体可包括：首先获取操作系统中运行的目标软件的文件列表；然后对该文件列表进行路径和/或文件哈希值的安全检测；若根据路径和/或文件哈希值判定存在异常，则确定安装软件对应的关键项为异常项。

例如，针对所运行操作系统上的软件检测，通过获取软件所有文件的列表，对该列表进行路径、文件hash规则判定，若命中异常规则，则认为是异常项。通过这种可选方式可准确判别操作系统关于安装软件方面的异常项。

b、操作系统对应的注册表的安全检测，具体包括：对操作系统注册表项、和/或具备自启动性质项、和/或com组件(comcomponent)项进行路径和对应值的安全检测；若判定操作系统注册表项、和/或具备自启动性质项、和/或com组件项存在异常，则确定注册表对应的关键项为异常项。

例如，针对系统服务注册表项、具备自启动性质项，以及本机存在的com组件等项进行路径及值进行规则匹配，若名字异常规则，则认为是异常项。通过这种可选方式可准确判别操作系统关于注册表方面的异常项。

c、操作系统对应的wmi的安全检测，具体包括：首先获取wmi消费者及触发器并进行解析；然后对解析内容进行恶意关键字项匹配；若恶意关键字项匹配成功，则确定wmi对应的关键项为异常项。

例如，针对wmi的检测，通过取得本机存在的wmi消费者及触发器，解析其中内容，对内容进行恶意关键字项的匹配，匹配成功认为是异常项。通过这种可选方式可准确判别操作系统关于wmi方面的异常项。

d、操作系统对应的计划任务的安全检测，具体包括：首先解析计划任务的名称以及计划任务的目标文件路径；然后对计划任务的名称进行异常名称匹配；若异常名称匹配成功，则获取目标文件路径中目标文件进行异常特征匹配；若异常特征匹配成功，则确定计划任务对应的关键项为异常项。

例如，针对计划任务，解析计划任务名称，及计划任务的目标文件路径，对计划任务名称进行异常名称规则匹配，成功再认为是可疑项，同时再对目标文件进行特征匹配，若命中特征，则确定为异常计划任务项。通过这种可选方式可准确判别操作系统关于计划任务方面的异常项。

e、操作系统对应的系统引导区代码的安全检测，具体包括：将主引导记录(masterbootrecord，mbr)数据与操作系统干净的mbr数据进行对比；若存在异常的跳转指令，则确定系统引导区代码对应的关键项为异常项。

例如，针对系统引导代码，取得本机mbr数据，与该系统下干净的mbr数据进行对比，若发现存在异常的跳转指令，则认为是异常的引导项。通过这种可选方式可准确判别操作系统关于计划任务方面的异常项。通过这种可选方式可准确判别操作系统关于系统引导区代码方面的异常项。

202、若监测出多个关键项中存在异常项，则根据与异常项对应预设的目标修复规则，判断操作系统当前的文件系统和/或注册表是否需要后续修复操作。

例如，具体可对目标修复规则进行解析，根据解析内容判断后续对异常项修复时，是否也涉及到修复操作系统当前的文件系统和/或注册表。

203、若判定文件系统和/或注册表需要后续修复操作，则备份修复前文件系统和注册表原始位置的数据。

在本实施例中，由于文件系统和注册表的文件也是很大的，如果备份全部数据可能会影响整体的异常项修复效率，所以可针对文件系统和注册表中需要修复的数据进行提前备份，这样备份的数据量级大大减小，备份速度加快，进而可提高操作系统异常项的修复效率。

204、根据目标修复规则，对异常项进行修复，若修复失败导致损坏操作系统的当前环境，则利用备份数据修复损坏的操作系统的当前环境。

对于本实施例，通过上述首先数据备份然后再进行修复的方式，能够有效避免修复失败损坏操作系统当前环境，减少对用户使用的影响。

为了说明具体利用修复规则进行修复的过程，示例性可选的，若根据异常项确定安装包管理软件存在异常，则根据目标修复规则，对异常项进行修复具体可包括：首先通过注册表获取安装包管理软件的安装目录；再获取该安装目录中安装包管理软件所在的文件夹位置；若文件夹位置存在预定目标文件，则获取预定目标文件的文件信息并与异常规则字段描述进行匹配；若异常规则字段描述匹配成功，则在文件夹位置中删除该预定目标文件。通过这种可选方式，可有效对安装包管理软件中的漏洞进行修复，减少操作系统由于安装软件方面的异常项对用户使用的影响，使得用户可安全在操作系统中使用该安装包管理软件。

例如，以修复winrar漏洞为例，首先通过注册表获取本机winrar的安装目录；再取出安装目录中winrar所在文件夹位置；然后判断文件夹位置是否存在unacev2.dll，如果存在，则获取该unacev2.dll目标文件版本、大小等信息，与异常规则字段描述进行匹配；如果匹配成功，可在执行修复逻辑时将该unacev2.dll目标文件删除。

上述步骤201至204所示的过程，具体可利用操作系统异常项修复策略脚本来实现。该异常项修复策略脚本适用于通过“扫描”(对指定位置、对象进行安全性扫描)以及“修复”(对扫描结果进行处理)两个操作，用以检测与修复当前操作系统的异常、问题、缺陷、风险项等。在目前传统的方案中，都是事先编写脚本然后下发到客户端本地执行，相当于本实施例中的异常项修复策略脚本与具体实现相分离。然而，考虑到本实施例方法的应用场景，如果后续需要对异常项修复策略进行更新时，通过传统这种脚本与实现分离的方式，会使得更新的时效性受限，不能应对突发情况；并且异常项修复策略可能会存在缺陷、问题，而无法及时进行有效规避。如果中途暂停运行异常项修复策略脚本来替换运行更新后的异常项修复策略脚本，在暂停时间段内无法对操作系统异常项进行有效检测与修复。

为了解决上述问题，本实施例方法进一步可选的，提出一种操作系统异常项修复策略的动态更新方案，即在对操作系统异常项进行修复的过程中，可对目标修复规则进行动态更新。通过本可选方式，可以极大的提升异常项修复策略以及数据的控制能力，同时提升了异常项修复策略更新的时效性。

可选的，上述对目标修复规则进行动态更新，具体可包括：首先获取目标修复规则中待更新的原字节码信息，以及与原字节码信息对应的标签信息；然后将原字节码信息和标签信息发送给云端服务器，以使得云端服务器根据该标签信息确定是否对原字节码信息进行更新；接收云端服务器返回的更新后的新字节码信息；然后在目标修复规则中更新替换原字节码信息为该新字节码信息。通过这种可选方式可有效实现操作系统异常项修复策略的动态更新，即可在运行该异常项修复策略脚本的过程中，对修复策略中的字节码信息进行动态更新，进而可及时修复该策略脚本中的缺陷与问题，不会中途暂停运行异常项修复策略脚本，可保证实时对操作系统异常项进行有效检测与修复。

下面说明本动态更新过程的具体实现方式，需要说明的是，本实现方式只是示例性给出，并不对本实施例方法做任何限定：

(1)首先配置异常项修复策略，给出控制信息的获取位置，如配置云端服务器(cloud)获取所用的网址，以及本地(local)获取所用的本地磁盘目录。

(2)通过步骤(1)给出的位置，可获取到控制信息，其中会列出功能脚本的列表信息。

例如，<scriptid＝"0"guid＝"2690b77e-276c-4bff-99f6-5fff2607ea19"/>

<scriptid＝"1"guid＝"38e62270-cd24-4aa2-9483-b27060158c9c"/>

其中guid部分用以区分不同的功能脚本。

(3)通过步骤(2)获取到功能脚本列表，调用getscript接口函数，传入需要载入的guid列表，该接口会优先在cloud端获取，若获取失败，则表示该脚本无更新，此时从本地获取即可，反之则从cloud端直接获取到最新的脚本。

(4)功能脚本提供“扫描”、“修复”功能，其中针对规则数据的定义，

以异常统一资源定位符(uniformresourcelocator，url)信息为例，在更新前url列表中包含aa.com、bb.com、cc.com。如果需要新增一个dd.com，在现有的情况下需要重新脚本并发布。但可使用本实施例中的方法，通过提供形如“getscript”的思路，提供了getlistdata接口，该接口传入标签tag，用以区分当前规则列表版本信息等，后续的{“aa.com”,”bb.com”,”cc.com”}也被传入，如black_url_list＝getlistdata(tag,{"aa.com","bb.com","cc.com"}。

(5)getlistdata接口将tag及现有列表传入云端服务器，云端服务器区分tag后对列表数据进行修正操作(增、删)，如增加dd.com，最后返回被修正后的数据。通过上述逻辑完成对策略脚本、规则数据的动态更新功能，本实施例方法原型图如图3所示。

通过应用上述本实施例方案，可有效实现操作系统异常项修复策略的动态更新，即可在运行该异常项修复策略脚本的过程中，对修复策略中的字节码信息进行动态更新，进而可及时修复该策略脚本中的缺陷与问题，不会中途暂停运行异常项修复策略脚本，可保证实时对操作系统异常项进行有效检测与修复。

进一步的，作为图1、图2所示方法的具体实现，本实施例提供了一种操作系统异常数据的处理装置，如图4所示，该装置包括：监测模块31、修复模块32。

监测模块31，可用于监测操作系统对应的多个关键项的安全性，所述多个关键项至少包括安装软件、注册表、wmi、计划任务、系统引导区代码中的一个或多个；

修复模块32，可用于若所述多个关键项中存在异常项，则根据与所述异常项对应预设的目标修复规则，对所述异常项进行修复，其中，不同的异常项都有各自对应预设的修复规则。

在具体的应用场景中，所述监测模块31，具体可用于获取所述操作系统中运行的目标软件的文件列表；对所述文件列表进行路径和/或文件哈希值的安全检测；若根据所述路径和/或文件哈希值判定存在异常，则确定所述安装软件对应的关键项为异常项。

在具体的应用场景中，所述监测模块31，具体还可用于对操作系统注册表项、和/或具备自启动性质项、和/或com组件项进行路径和对应值的安全检测；若判定所述操作系统注册表项、和/或具备自启动性质项、和/或com组件项存在异常，则确定所述注册表对应的关键项为异常项。

在具体的应用场景中，所述监测模块31，具体还可用于获取wmi消费者及触发器并进行解析；对解析内容进行恶意关键字项匹配；若恶意关键字项匹配成功，则确定所述wmi对应的关键项为异常项。

在具体的应用场景中，所述监测模块31，具体还可用于解析计划任务的名称以及所述计划任务的目标文件路径；对所述计划任务的名称进行异常名称匹配；若异常名称匹配成功，则获取所述目标文件路径中目标文件进行异常特征匹配；若异常特征匹配成功，则确定所述计划任务对应的关键项为异常项。

在具体的应用场景中，所述监测模块31，具体还可用于将主引导记录mbr数据与所述操作系统干净的mbr数据进行对比；若存在异常的跳转指令，则确定所述系统引导区代码对应的关键项为异常项。

在具体的应用场景中，所述修复模块32，具体可用于若根据所述异常项确定安装包管理软件存在异常，则通过注册表获取所述安装包管理软件的安装目录；获取所述安装目录中所述安装包管理软件所在的文件夹位置；若所述文件夹位置存在预定目标文件，则获取所述预定目标文件的文件信息并与异常规则字段描述进行匹配；若异常规则字段描述匹配成功，则在所述文件夹位置中删除所述预定目标文件。

在具体的应用场景中，本装置还包括：判断模块和备份模块；

所述判断模块，用于根据所述目标修复规则，判断所述操作系统当前的文件系统和/或注册表是否需要后续修复操作；

所述备份模块，用于若所述文件系统和/或注册表需要后续修复操作，则备份修复前所述文件系统和注册表原始位置的数据；

所述修复模块32，具体还可用于若修复失败导致损坏所述操作系统的当前环境，则利用备份数据修复损坏的所述操作系统的当前环境。

在具体的应用场景中，本装置还包括：更新模块；

更新模块，可用于在对所述异常项进行修复的过程中，对所述目标修复规则进行动态更新。

在具体的应用场景中，所述更新模块，具体用于获取所述目标修复规则中待更新的原字节码信息，以及与所述原字节码信息对应的版本标签信息；将所述原字节码信息和所述版本标签信息发送给云端服务器，以使得所述云端服务器根据所述版本标签信息确定是否对所述原字节码信息进行更新；接收所述云端服务器返回的更新后的新字节码信息；在所述目标修复规则中更新替换所述原字节码信息为所述新字节码信息。

需要说明的是，本实施例提供的一种操作系统异常数据的处理装置所涉及各功能单元的其它相应描述，可以参考图1、图2中的对应描述，在此不再赘述。

基于上述如图1、图2所示方法，相应的，本实施例还提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述如图1、图2所示的操作系统异常数据的处理方法。

基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该待识别软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

基于上述如图1、图2所示的方法，以及图4所示的虚拟装置实施例，为了实现上述目的，本实施例还提供了一种操作系统异常数据处理的实体设备，具体可以为个人计算机、服务器、智能手机、平板电脑、或者其它网络设备等，该实体设备包括存储介质和处理器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现上述如图1、图2所示的方法。

可选的，该实体设备还可以包括用户接口、网络接口、摄像头、射频(radiofrequency，rf)电路，传感器、音频电路、wi-fi模块等等。用户接口可以包括显示屏(display)、输入单元比如键盘(keyboard)等，可选用户接口还可以包括usb接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如wi-fi接口)等。

本领域技术人员可以理解，本实施例提供的一种操作系统异常数据处理的实体设备结构并不构成对该实体设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件布置。

存储介质中还可以包括操作系统、网络通信模块。操作系统是管理上述实体设备硬件和待识别软件资源的程序，支持信息处理程序以及其它待识别软件和/或程序的运行。网络通信模块用于实现存储介质内部各组件之间的通信，以及与信息处理实体设备中其它硬件和软件之间通信。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以借助软件加必要的通用硬件平台的方式来实现，也可以通过硬件实现。通过应用实施例的技术方案，与目前现有的操作系统异常检测只是针对文件系统进行检测相比，本实施例可同时监测操作系统对应的安装软件、注册表、wmi、计划任务、系统引导代码等多个关键项的安全性，并且对于这些关键项可实现具有针对性的异常项修复。进而可实现对操作系统异常项的全面检测与修复，扩大了操作系统异常项的修复范围，提高了操作系统异常项检测的精确性，在发现操作系统存在异常项时可做到及时响应和快速修复，减少对用户使用的影响，提高了一定的安全性。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。