CN116226871B - 基于静态和动态结合的漏洞验证方法、设备和介质 - Google Patents

Abstract

本发明涉及数据处理技术领域，公开了一种基于静态和动态结合的漏洞验证方法、设备和介质，该方法通过对车机零部件的固件包进行扫描，得到各第一预测漏洞数据，进而判断固件包中是否存在漏洞函数，若是，则生成漏洞函数记录表，实现了对固件包的静态漏洞验证，进而通过在记录的各漏洞函数的代码末尾位置添加程序断点，运行各漏洞测试脚本，得到在各程序断点处的第一运行结果以及脚本的第二运行结果，进而确定漏洞测试关联表，实现了对固件包的动态漏洞验证，最后针对其它零部件的漏洞验证请求，可以根据漏洞测试关联表判断是否存在漏洞，提高了验证效率，解决了现有技术中漏洞测试不准确、成本高、周期长以及无法准确定位漏洞点的问题。

Description

基于静态和动态结合的漏洞验证方法、设备和介质

技术领域

本发明涉及数据处理技术领域，尤其涉及一种基于静态和动态结合的漏洞验证方法、设备和介质。

背景技术

随着汽车系统越来越智能化，车机智能系统的安全性成为了目前面临的重要问题。如何保障车机智能系统、车机零部件智能系统的安全性，需要针对车机智能系统进行测试。

然而，在目前的测试方法中，比如，采用代码分析的方法，虽然能够定位到可能的漏洞点，但该方法费时费力，并且该漏洞点在不经过执行验证时无法确定其是否一定为漏洞，导致存在漏洞测试不准确的问题；又比如，采用构建车机模拟系统进行动态测试，虽然准确率较高，直接能够判断该车机智能化系统是否存在漏洞，但采用该方法成本高，周期长，并且不容易定位到具体的代码中的漏洞点，对于漏洞的查找不够精准。

有鉴于此，特提出本发明。

发明内容

为了解决上述技术问题，本发明提供了一种基于静态和动态结合的漏洞验证方法、设备和介质，以解决现有技术中漏洞测试不准确、成本高、周期长以及无法准确定位漏洞点的问题。

本发明实施例提供了一种基于静态和动态结合的漏洞验证方法，该方法包括：

S1.获取车机零部件中的固件包，对所述固件包进行扫描，得到所述固件包中的各第一预测漏洞数据；

S2. 根据各所述第一预测漏洞数据对应的补丁文件、对应的组件全部代码以及对应的代码片段，判断所述固件包中是否存在漏洞函数，若是，则生成漏洞函数记录表；

S3. 在所述固件包中查找所述漏洞函数记录表中记录的各漏洞函数，得到各代码末尾位置，在各所述代码末尾位置处添加程序断点；

S4. 运行针对所述车机零部件的各漏洞测试脚本，得到每一个所述漏洞测试脚本在各所述程序断点处的第一运行结果，以及各所述漏洞测试脚本的第二运行结果；

S5. 基于各所述漏洞测试脚本在各所述程序断点处的第一运行结果和各所述漏洞测试脚本的第二运行结果，确定漏洞测试关联表；

S6. 响应于其它零部件的漏洞验证请求，在确定出所述其它零部件的待测固件包中存在当前漏洞函数时，判断所述漏洞测试关联表中是否存在所述当前漏洞函数对应的漏洞测试脚本，若是，则确定所述当前漏洞函数存在漏洞。

本发明实施例提供了一种电子设备，所述电子设备包括：

处理器和存储器；

所述处理器通过调用所述存储器存储的程序或指令，用于执行任一实施例所述的基于静态和动态结合的漏洞验证方法的步骤。

本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行任一实施例所述的基于静态和动态结合的漏洞验证方法的步骤。

本发明实施例具有以下技术效果：

通过对获取的车机零部件的固件包进行扫描，得到各第一预测漏洞数据，进而根据对应的补丁文件、组件全部代码以及代码片段，判断固件包中是否存在漏洞函数，若是，则生成漏洞函数记录表，实现了对固件包的静态漏洞验证，以初步精准定位漏洞位置，进而通过在记录的各漏洞函数的代码末尾位置添加程序断点，运行针对车机零部件的各漏洞测试脚本，得到在各程序断点处的第一运行结果以及脚本的第二运行结果，通过各第一运行结果和第二运行结果确定漏洞测试关联表，实现了对固件包的动态漏洞验证，以对静态验证的结果进行确认，进一步提高了漏洞验证的准确性，最后针对其它零部件的漏洞验证请求，在待测固件包中存在当前漏洞函数时，可以根据漏洞测试关联表判断当前漏洞函数是否存在漏洞，以在后续的每次漏洞验证中，无需进行完整测试，提高了验证效率，解决了现有技术中漏洞测试不准确、成本高、周期长以及无法准确定位漏洞点的问题。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的一种基于静态和动态结合的漏洞验证方法的流程图；

图2是本发明实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将对本发明的技术方案进行清楚、完整的描述。显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所得到的所有其它实施例，都属于本发明所保护的范围。

本发明实施例提供的基于静态和动态结合的漏洞验证方法，主要适用于验证车机零部件的固件包是否存在漏洞的情况，可以由平台、服务器、终端或云端等电子设备执行，例如，可以将该方法集成在漏洞检测系统中，通过漏洞检测系统执行。

图1是本发明实施例提供的一种基于静态和动态结合的漏洞验证方法的流程图。参见图1，该基于静态和动态结合的漏洞验证方法具体包括：

S1.获取车机零部件中的固件包，对固件包进行扫描，得到固件包中的各第一预测漏洞数据。

其中，漏洞检测系统可以调用漏洞扫描平台，通过漏洞扫描平台与车机零部件建立接口，从车机零部件中读取固件包。或者，漏洞检测系统可以获取用户上传的车机零部件的固件包，将其发送至漏洞扫描平台。

进一步的，漏洞检测系统可以通过调用漏洞扫描平台，对固件包进行扫描，得到该固件包中的各第一预测漏洞数据。其中，第一预测漏洞数据可以用于描述固件包中可能涉及的漏洞点；第一预测漏洞数据可以包括漏洞标识、漏洞文件路径、车机零部件名称以及固件包名称。漏洞标识可以是CVE（Common Vulnerabilities and Exposures，通用漏洞披露）ID，即可能涉及的漏洞点所对应的标识字段，该标识字段为行业漏洞的统一标识字段。

S2. 根据各第一预测漏洞数据对应的补丁文件、对应的组件全部代码以及对应的代码片段，判断固件包中是否存在漏洞函数，若是，则生成漏洞函数记录表。

其中，针对每一个第一预测漏洞数据，可以根据第一预测漏洞数据中的漏洞标识，从漏洞数据库中获取与该漏洞标识对应的补丁文件、版本信息、组件名称以及漏洞描述信息，进一步的，可以获取补丁文件的版本信息，并获取与该版本信息对应的组件的组件全部代码，以及，补丁文件对应的补丁代码段。

具体的，针对每一个第一预测漏洞数据，可以根据组件全部代码、补丁代码段以及第一预测漏洞数据对应的代码片段，判断是否存在漏洞函数，基于存在的漏洞函数生成漏洞函数记录表，以对固件包中存在的漏洞函数进行记录。

在一种具体的实施方式中，步骤S2包括如下步骤：

步骤S21. 针对每一个第一预测漏洞数据，根据第一预测漏洞数据中的漏洞标识，获取第一预测漏洞数据对应的补丁文件、版本信息、组件名称以及漏洞描述信息；

步骤S22. 基于补丁文件的版本信息获取组件全部代码，并获取补丁文件对应的补丁代码段；

步骤S23. 在组件全部代码中查找与补丁代码段相对应的参考代码段；

步骤S24. 于预设系统界面展示参考代码段，并获取用户于预设系统界面录入的漏洞函数以及最新版本标识；

步骤S25. 获取第一预测漏洞数据对应的代码片段，在代码片段的版本标识与最新版本标识不一致的情况下，判断代码片段中是否存在漏洞函数，若是，则将漏洞函数记录至漏洞函数记录表。

其中，针对步骤S23，可以通过模糊查询的方法，在组件全部代码中查找与补丁代码段相对应的参考代码段，即，与补丁代码段匹配率最高的代码段。

进一步的，通过步骤S24，将组件全部代码中与补丁代码段匹配率最高的代码段反馈至预设系统界面进行展示，以使用户根据展示内容查找漏洞函数，将漏洞函数在预设系统界面中录入，并且，根据步骤S21中获取的漏洞描述信息，将最新版本标识输入至预设系统界面中。其中，漏洞描述信息可以是对漏洞的文字描述，文字描述中包括存在漏洞的版本数据，以及最新版本标识，最新版本标识用于描述组件对应的最新版本号。

进一步的，在上述步骤S25中，可以根据第一预测漏洞数据对应的漏洞文件路径，获取第一预测漏洞数据对应的代码片段。在代码片段中查找版本标识（如version）字段，若该版本标识与步骤S24中获取到的最新版本标识一致，则表示代码片段的版本为最新版本，即已将漏洞消除的版本，无需再在代码片段中查询是否存在漏洞函数。

若该版本标识与最新版本标识不一致，则可以进一步判断代码片段中查找是否存在步骤S24中用户录入的漏洞函数，若存在，则可以通过预设系统界面展示查找到的漏洞函数所对应的代码数据，并通过查找到的漏洞函数生成漏洞记录数据，将漏洞记录数据写入至漏洞函数记录表。其中，漏洞记录数据包括漏洞函数的名称、漏洞函数对应的组件名称以及漏洞函数的位置。

具体的，可以通过重复执行上述步骤，以对每一个第一预测漏洞数据进行处理，直至所有第一预测漏洞数据处理完成，得到最终的漏洞函数记录表。其中，漏洞函数记录表可以包括一条或多条漏洞记录数据。

通过上述步骤S21-S25，针对多个第一预测漏洞数据，采用静态验证的方法，判断固件包中是否存在漏洞函数并生成漏洞函数记录表，可以初步精准定位出代码漏洞位置，提高漏洞定位的精准性。

S3. 在固件包中查找漏洞函数记录表中记录的各漏洞函数，得到各代码末尾位置，在各代码末尾位置处添加程序断点。

其中，可以在定位各漏洞函数的代码末尾位置之前，先将固件包添加至车机模拟平台，以便于后续通过车机模拟平台运行漏洞测试脚本。

在一种具体的实施方式中，步骤S3包括如下步骤：

S31. 在车机模拟平台中查找是否存在车机零部件的当前固件包，若存在，则判断当前固件包是否与固件包一致，在不一致的情况下，将当前固件包替换为固件包；

S32. 针对漏洞函数记录表中记录的每一个漏洞函数，在固件包中查询漏洞函数对应的代码末尾位置，在代码末尾位置处添加程序断点。

即，若车机模拟平台中存在的当前固件包与车机零部件的固件包一致，则可以直接执行S32，否则，先采用固件包对当前固件包进行替换，进而执行S32。当然，若车机模拟平台中不存在当前固件包，则可以直接将车机零部件的固件包添加至车机模拟平台。

针对步骤S32，可以对漏洞函数记录表中记录的每一个漏洞函数，在固件包中定位出相应的代码末尾位置。示例性的，可以通过漏洞记录数据中的漏洞函数的位置，在固件包中进行初步定位，进而在初步定位的位置附近，查找漏洞函数记录表中记录的漏洞函数，以提高查找效率，同时，确保查找的准确性。

进一步的，在查找到记录的漏洞函数后，可以在对应的代码的末尾位置处添加程序断点。

通过上述步骤S31-S32，实现了在车机模拟平台中添加固件包，以及对程序断点的添加，进而便于后续通过车机模拟平台运行漏洞测试脚本，得到各程序断点处的运行结果和整个脚本的运行结果。

S4. 运行针对车机零部件的各漏洞测试脚本，得到每一个漏洞测试脚本在各程序断点处的第一运行结果，以及各漏洞测试脚本的第二运行结果。

其中，漏洞测试脚本可以是用户设置的代码文件，即用于测试车机零部件中的固件包是否存在漏洞的测试文件。一个车机零部件对应的漏洞测试脚本的数量可以是一个或多个，即针对一个车机零部件的固件包，可以有不同角度的漏洞测试。

具体的，针对车机零部件的每一个漏洞测试脚本，可以通过车机模拟平台运行漏洞测试脚本，得到该漏洞测试脚本在各程序断点处的第一运行结果，以及该漏洞测试脚本的第二运行结果。

可选的，第一运行结果为漏洞函数未运行或漏洞函数运行，第二运行结果为运行异常或运行正常。其中，漏洞函数未运行表示程序断点处对应的漏洞函数没有被运行，漏洞函数运行表示程序断点处对应的漏洞函数被运行；运行异常表示漏洞测试脚本在车机模拟平台上的运行结果出现异常，运行正常表示漏洞测试脚本在车机模拟平台上的运行结果未出现异常。

S5. 基于各漏洞测试脚本在各程序断点处的第一运行结果和各漏洞测试脚本的第二运行结果，确定漏洞测试关联表。

其中，对于漏洞函数未运行的第一运行结果，表示该漏洞函数没有被运行到，进而表明该漏洞函数无法让该固件包产生漏洞。对于漏洞函数运行的第一运行结果，表示该漏洞函数被运行到，如果第二运行结果为运行异常，则可以表明该漏洞函数可能使固件包产生漏洞。

因此，在本发明实施例中，可以忽视漏洞函数未运行的第一运行结果，在第二运行结果为运行异常的情况下，针对漏洞函数运行的第一运行结果，对其对应的漏洞函数继续进行验证，以验证是否为该漏洞函数引起的运行异常，即漏洞函数是否确实使固件包产生漏洞。

在一种具体的实施方式中，步骤S5包括如下步骤：

S51. 对于每一个漏洞测试脚本，将第一运行结果为漏洞函数运行的各漏洞函数记录至脚本函数关联表中；

S52. 针对每一个漏洞测试脚本，在漏洞测试脚本的第二运行结果为运行正常的情况下，将漏洞测试脚本、脚本函数关联表中漏洞测试脚本对应的各漏洞函数、固件包以及第二运行结果记录至漏洞测试关联表中，并将记录的各漏洞函数的名称设置为无；

S53. 在漏洞测试脚本的第二运行结果为运行异常的情况下，获取脚本函数关联表中漏洞测试脚本对应的各漏洞函数的补丁文件集合，根据补丁文件集合对固件包进行升级处理；

S54. 基于漏洞测试脚本对升级后的固件包进行测试，得到第三运行结果；

S55. 若第三运行结果与第二运行结果一致，则将漏洞测试脚本、补丁文件集合对应的各漏洞函数、固件包以及第二运行结果记录至漏洞测试关联表中，并将记录的各漏洞函数的名称设置为无。

在上述步骤S51中，脚本函数关联表可以包括每一个漏洞测试脚本对应的初始记录数据，其中，所述初始记录数据包括漏洞测试脚本的名称、以及漏洞测试脚本的各第一运行结果中为漏洞函数运行的漏洞函数的名称，一条初始记录数据中可以包括一个或多个漏洞函数的名称。

在得到脚本函数关联表之后，在上述步骤S52中，对于每一个漏洞测试脚本，可以判断第二运行结果是否为运行正常，若是，则表示该固件包不存在漏洞，此时可以将脚本函数关联表中针对该漏洞测试脚本所记录的各漏洞函数的名称、固件包的名称、漏洞测试脚本的名称、车机零部件的名称、以及第二运行结果，写入至漏洞测试关联表，并将各漏洞函数的名称设置为无。

如果第二运行结果为运行异常，则可以针对漏洞函数运行的第一运行结果，判断运行异常是否由其对应的漏洞函数引起。具体的，通过上述步骤S53，可以根据脚本函数关联表中记录的漏洞函数的名称，获取用于修复各漏洞函数的补丁文件集合，采用补丁文件集合对固件包进行补丁升级。

进一步的，采用漏洞测试脚本再次对升级后的固件包进行测试，得到第三运行结果。如果第三运行结果与第二运行结果一致，则可以表示补丁升级之前与升级之后的运行结果相同，表明不是升级的各漏洞函数导致的运行异常，此时可以按照漏洞测试关联表的格式，将信息写入，即写入脚本函数关联表中针对该漏洞测试脚本所记录的各漏洞函数的名称、固件包的名称、漏洞测试脚本的名称、车机零部件的名称、以及第二运行结果，并将漏洞函数名称设置为无。

通过上述步骤S51-S55，可以实现对静态验证后记录的各漏洞函数的动态验证，以确定记录的各漏洞函数是否产生漏洞，进一步保证了漏洞检测的准确性。

对于第三运行结果与第二运行结果不一致的情况，可选的，在步骤S54之后，还包括：

S56. 若第三运行结果与第二运行结果不一致，则将补丁文件集合划分为各当前集合；

S57. 针对每一个所述当前集合，将当前集合作为新的补丁文件集合，根据新的补丁文件集合对固件包进行升级处理，并重复执行步骤S54-S57，直至新的补丁文件集合由单个补丁文件构成，若基于单个补丁文件升级后的第三运行结果与第二运行结果不一致，则将漏洞测试脚本、补丁文件集合对应的漏洞函数、固件包以及第二运行结果记录至漏洞测试关联表中。

具体的，如果第三运行结果与第二运行结果不一致，则表示第二运行结果的运行异常，是由补丁升级的各漏洞函数引起的。由于补丁升级文件由多个漏洞函数的补丁文件构成，因此，为了进一步确定其中引起漏洞的漏洞函数，还可以对补丁文件集合进行拆分，以重复上述验证过程。在步骤S56中，对补丁文件集合进行拆分，可以是将补丁文件集合拆分成多个大小相同的当前集合。

在一种示例中，将补丁文件集合划分为各当前集合，包括：若补丁文件集合中的补丁文件的数量为偶数，则将补丁文件集合拆分为补丁文件数量相同的两个当前集合；若补丁文件集合中的补丁文件的数量为奇数，则将补丁文件集合拆分为两个当前集合，其中，两个当前集合中补丁文件的数量差为1。

通过该方式，可以将补丁文件集合拆分为两个当前集合，且两个当前集合中补丁文件的数量差距最小，可以实现对补丁文件集合的均分，与随机拆分多个集合的方式相比，均分可以进一步提高漏洞验证的效率。

进一步的，对于每一个当前集合，可以将其作为新的补丁文件集合，对固件包进行升级处理，进而继续返回执行步骤S54-S57，直至新的补丁文件集合中补丁文件的数量为1。此时，可以对固件包进行升级处理，若升级后的第三运行结果与第二运行结果不一致，则将漏洞测试脚本、补丁文件集合对应的漏洞函数、固件包以及第二运行结果记录至漏洞测试关联表中，若第三运行结果与第二运行结果一致，则记录上述信息，并将记录的漏洞函数的名称设置为无。

通过上述步骤，可以实现对补丁文件集合的拆分，进而便于对各漏洞函数逐步验证，有效减少了车机模拟平台运行漏洞测试脚本的次数，无需对每一个漏洞函数依次进行补丁升级验证，提高了漏洞验证的整体效率。

在本发明实施例中，生成的漏洞测试关联表，可以用于对下一次漏洞验证进行控制，以使在后续漏洞验证的过程中，无需每次均执行上述完整流程，提高了漏洞验证效率。

S6. 响应于其它零部件的漏洞验证请求，在确定出其它零部件的待测固件包中存在当前漏洞函数时，判断漏洞测试关联表中是否存在当前漏洞函数对应的漏洞测试脚本，若是，则确定当前漏洞函数存在漏洞。

具体的，在针对其它零部件进行漏洞验证时，可以先判断其它零部件的待测固件包中是否存在漏洞函数，如果存在，则进一步在漏洞测试关联表查找待测固件包中存在的漏洞函数，如果查找到对应的漏洞测试脚本，则可以确定其存在漏洞。

在一种具体的实施方式中，步骤S6包括如下步骤：

S61. 接收其它零部件的漏洞验证请求，响应于漏洞验证请求，对其它零部件的待测固件包进行扫描，并判断待测固件包中是否存在当前漏洞函数；

S62. 若存在当前漏洞函数，则判断漏洞测试关联表中是否存在当前漏洞函数对应的漏洞测试脚本，若否，则确定当前漏洞函数不存在漏洞，若是，则确定当前漏洞函数存在漏洞，并于预设系统界面展示对应的漏洞测试脚本和当前漏洞函数的名称。

在上述步骤S61中，可以参考步骤S1-S2，通过漏洞扫描平台，对待测固件包进行扫描，得到待测固件包中的各第二预测漏洞数据，进而根据各第二预测漏洞数据对应的补丁文件、对应的组件全部代码以及对应的代码片段，判断待测固件包中是否存在当前漏洞函数。

进一步的，如果存在，则在漏洞测试关联表中查找是否存在当前漏洞函数对应的漏洞测试脚本，若存在，则表示该当前漏洞函数经过脚本测试确认过能够引起漏洞，进而可以确定待测固件包中的当前漏洞函数存在漏洞。

进一步的，可以将对应的漏洞测试脚本和当前漏洞函数的名称，反馈至预设系统界面进行展示。

通过上述步骤S61-S62，实现了通过漏洞测试关联表，在后续漏洞验证过程中的漏洞验证控制，无需每次均进行车机模拟平台的测试，提高了系统整体的运行效率。

本发明具有以下技术效果：通过对获取的车机零部件的固件包进行扫描，得到各第一预测漏洞数据，进而根据对应的补丁文件、组件全部代码以及代码片段，判断固件包中是否存在漏洞函数，若是，则生成漏洞函数记录表，实现了对固件包的静态漏洞验证，以初步精准定位漏洞位置，进而通过在记录的各漏洞函数的代码末尾位置添加程序断点，运行针对车机零部件的各漏洞测试脚本，得到在各程序断点处的第一运行结果以及脚本的第二运行结果，通过各第一运行结果和第二运行结果确定漏洞测试关联表，实现了对固件包的动态漏洞验证，以对静态验证的结果进行确认，进一步提高了漏洞验证的准确性，最后针对其它零部件的漏洞验证请求，在待测固件包中存在当前漏洞函数时，可以根据漏洞测试关联表判断当前漏洞函数是否存在漏洞，以在后续的每次漏洞验证中，无需进行完整测试，提高了验证效率，解决了现有技术中漏洞测试不准确、成本高、周期长以及无法准确定位漏洞点的问题。

图2是本发明实施例提供的一种电子设备的结构示意图。如图2所示，电子设备400包括一个或多个处理器401和存储器402。

处理器401可以是中央处理单元（CPU）或者具有数据处理能力和/或指令执行能力的其他形式的处理单元，并且可以控制电子设备400中的其他组件以执行期望的功能。

存储器402可以包括一个或多个计算机程序产品，所述计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。所述易失性存储器例如可以包括随机存取存储器（RAM）和/或高速缓冲存储器（cache）等。所述非易失性存储器例如可以包括只读存储器（ROM）、硬盘、闪存等。在所述计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器401可以运行所述程序指令，以实现上文所说明的本发明任意实施例的基于静态和动态结合的漏洞验证方法以及/或者其他期望的功能。在所述计算机可读存储介质中还可以存储诸如初始外参、阈值等各种内容。

在一个示例中，电子设备400还可以包括：输入装置403和输出装置404，这些组件通过总线系统和/或其他形式的连接机构（未示出）互连。该输入装置403可以包括例如键盘、鼠标等等。该输出装置404可以向外部输出各种信息，包括预警提示信息、制动力度等。该输出装置404可以包括例如显示器、扬声器、打印机、以及通信网络及其所连接的远程输出设备等等。

当然，为了简化，图2中仅示出了该电子设备400中与本发明有关的组件中的一些，省略了诸如总线、输入/输出接口等等的组件。除此之外，根据具体应用情况，电子设备400还可以包括任何其他适当的组件。

除了上述方法和设备以外，本发明的实施例还可以是计算机程序产品，其包括计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本发明任意实施例所提供的基于静态和动态结合的漏洞验证方法的步骤。

所述计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本发明实施例操作的程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。

此外，本发明的实施例还可以是计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本发明任意实施例所提供的基于静态和动态结合的漏洞验证方法的步骤。

所述计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子（非穷举的列表）包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦式可编程只读存储器（EPROM或闪存）、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

需要说明的是，本发明所用术语仅为了描述特定实施例，而非限制本申请范围。如本发明说明书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法或者设备中还存在另外的相同要素。

还需说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。除非另有明确的规定和限定，术语“安装”、“相连”、“连接”等应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案。

Claims (8)

1.一种基于静态和动态结合的漏洞验证方法，其特征在于，包括如下步骤：

S1.获取车机零部件中的固件包，对所述固件包进行扫描，得到所述固件包中的各第一预测漏洞数据；

S2.根据各所述第一预测漏洞数据对应的补丁文件、对应的组件全部代码以及对应的代码片段，判断所述固件包中是否存在漏洞函数，若是，则生成漏洞函数记录表；

S3. 在所述固件包中查找所述漏洞函数记录表中记录的各漏洞函数，得到各代码末尾位置，在各所述代码末尾位置处添加程序断点；

S4. 运行针对所述车机零部件的各漏洞测试脚本，得到每一个所述漏洞测试脚本在各所述程序断点处的第一运行结果，以及各所述漏洞测试脚本的第二运行结果；

S5. 基于各所述漏洞测试脚本在各所述程序断点处的第一运行结果和各所述漏洞测试脚本的第二运行结果，确定漏洞测试关联表；

S6. 响应于其它零部件的漏洞验证请求，在确定出所述其它零部件的待测固件包中存在当前漏洞函数时，判断所述漏洞测试关联表中是否存在所述当前漏洞函数对应的漏洞测试脚本，若是，则确定所述当前漏洞函数存在漏洞；

步骤S5包括如下步骤：

S51. 对于每一个所述漏洞测试脚本，将第一运行结果为漏洞函数运行的各漏洞函数记录至脚本函数关联表中；

S52. 针对每一个所述漏洞测试脚本，在所述漏洞测试脚本的第二运行结果为运行正常的情况下，将所述漏洞测试脚本、所述脚本函数关联表中所述漏洞测试脚本对应的各漏洞函数、所述固件包以及所述第二运行结果记录至所述漏洞测试关联表中，并将记录的各漏洞函数的名称设置为无；

S53. 在所述漏洞测试脚本的第二运行结果为运行异常的情况下，获取所述脚本函数关联表中所述漏洞测试脚本对应的各漏洞函数的补丁文件集合，根据所述补丁文件集合对所述固件包进行升级处理；

S54. 基于所述漏洞测试脚本对升级后的固件包进行测试，得到第三运行结果；

S55. 若所述第三运行结果与所述第二运行结果一致，则将所述漏洞测试脚本、所述补丁文件集合对应的各漏洞函数、所述固件包以及所述第二运行结果记录至所述漏洞测试关联表中，并将记录的各漏洞函数的名称设置为无；

在步骤S54之后，还包括：

S56. 若所述第三运行结果与所述第二运行结果不一致，则将所述补丁文件集合划分为各当前集合；

S57. 针对每一个所述当前集合，将所述当前集合作为新的补丁文件集合，根据新的补丁文件集合对所述固件包进行升级处理，并重复执行步骤S54-S57，直至新的补丁文件集合由单个补丁文件构成，若基于单个补丁文件升级后的所述第三运行结果与所述第二运行结果不一致，则将所述漏洞测试脚本、所述补丁文件集合对应的漏洞函数、所述固件包以及所述第二运行结果记录至所述漏洞测试关联表中。

2.根据权利要求1所述的方法，其特征在于，步骤S2包括如下步骤：

步骤S21. 针对每一个所述第一预测漏洞数据，根据所述第一预测漏洞数据中的漏洞标识，获取所述第一预测漏洞数据对应的补丁文件、版本信息、组件名称以及漏洞描述信息；

步骤S22. 基于所述补丁文件的版本信息获取组件全部代码，并获取所述补丁文件对应的补丁代码段；

步骤S23. 在所述组件全部代码中查找与所述补丁代码段相对应的参考代码段；

步骤S24. 于预设系统界面展示所述参考代码段，并获取用户于所述预设系统界面录入的漏洞函数以及最新版本标识；

步骤S25. 获取所述第一预测漏洞数据对应的代码片段，在所述代码片段的版本标识与所述最新版本标识不一致的情况下，判断所述代码片段中是否存在所述漏洞函数，若是，则将所述漏洞函数记录至漏洞函数记录表。

3.根据权利要求1所述的方法，其特征在于，步骤S3包括如下步骤：

S31. 在车机模拟平台中查找是否存在所述车机零部件的当前固件包，若存在，则判断所述当前固件包是否与所述固件包一致，在不一致的情况下，将所述当前固件包替换为所述固件包；

S32. 针对所述漏洞函数记录表中记录的每一个漏洞函数，在所述固件包中查询所述漏洞函数对应的代码末尾位置，在所述代码末尾位置处添加程序断点。

4.根据权利要求1所述的方法，其特征在于，所述第一运行结果为漏洞函数未运行或漏洞函数运行，所述第二运行结果为运行异常或运行正常。

5.根据权利要求1所述的方法，其特征在于，将所述补丁文件集合划分为各当前集合，包括：

若所述补丁文件集合中的补丁文件的数量为偶数，则将所述补丁文件集合拆分为补丁文件数量相同的两个当前集合；

若所述补丁文件集合中的补丁文件的数量为奇数，则将所述补丁文件集合拆分为两个当前集合，其中，两个当前集合中补丁文件的数量差为1。

6.根据权利要求1所述的方法，其特征在于，步骤S6包括如下步骤：

S61. 接收其它零部件的漏洞验证请求，响应于所述漏洞验证请求，对所述其它零部件的待测固件包进行扫描，并判断所述待测固件包中是否存在当前漏洞函数；

S62. 若存在当前漏洞函数，则判断所述漏洞测试关联表中是否存在所述当前漏洞函数对应的漏洞测试脚本，若否，则确定所述当前漏洞函数不存在漏洞，若是，则确定所述当前漏洞函数存在漏洞，并于预设系统界面展示对应的漏洞测试脚本和所述当前漏洞函数的名称。

7.一种电子设备，其特征在于，所述电子设备包括：

处理器和存储器；

所述处理器通过调用所述存储器存储的程序或指令，用于执行如权利要求1至6任一项所述的基于静态和动态结合的漏洞验证方法的步骤。

8.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行如权利要求1至6任一项所述的基于静态和动态结合的漏洞验证方法的步骤。