CN104978532B - A kind of bug-fixing client logic testing method and bug-fixing client logic testing system - Google Patents

Abstract

The present application provides a method and system for testing logic of a vulnerability repairing client to solve the problem that the testing of the logic of the vulnerability repairing client is time-consuming and affects efficiency. The method includes: the vulnerability repairing client scans the system according to a pattern to find simulated vulnerabilities; if the simulated vulnerabilities are found, then download corresponding simulated vulnerability patches from the vulnerability library of the server, and the simulated The vulnerability patch is used to generate a simulated vulnerability repair logo on the basis of retaining the original system files of the system; install the simulated vulnerability patch and generate a corresponding simulated vulnerability repair logo; the vulnerability repair client traverses all modes to complete the entire testing process; if If all the above processes are executed normally, the test of the vulnerability repair client logic is passed. This application downloads and installs patches very quickly, which shortens the test time for repairing client logic and improves test efficiency.

Description

A testing method and system for vulnerability repair client logic

technical field

The present application relates to the technical field of testing, in particular to a testing method and system for loophole repair client logic.

Background technique

The vulnerability repair client scans the system for vulnerabilities that need to be repaired through the configuration conditions in the vulnerability library (libleak), such as detection of file existence, detection of file version number, detection of registry entries, etc. Users can select the vulnerabilities they want to fix and fix them. When repairing, first download the corresponding patch from the external network server, and then the vulnerability repair client calls the patch to repair the vulnerability.

The execution of the vulnerability repair client involves various logics, including startup pop-up window repair, background repair, main interface repair, patch package signature verification, download domain name verification, competing product logic, pop-up window logic, etc. Every time the vulnerability repair client is modified, the above logic needs to be tested one by one to test whether there will be problems in the implementation of the above logical steps on the vulnerability repair client. In the specific implementation, a logic of the vulnerability repair client is used as A mode of the test, so there will be hundreds or even thousands of modes corresponding to the test. But not all patches are suitable for testing, and when testing the patches suitable for testing in the corresponding mode, you need to download the corresponding patches and perform repair operations. A situation arises in which all suitable patches for testing have been patched. So typical patches are usually picked to test all modes of bugfix clients.

In this process, after the system scans the vulnerability and confirms that it can be patched, the vulnerability patch client needs to download the patch. A real patch often needs to perform a lot of operations when patching the vulnerability, so the patch is relatively large, which will result in a relatively large patch download. time consuming. When installing the patch after downloading, the patch needs to perform operations such as releasing and updating system files, so a restart is required to make the patch take effect, and the patch process is also time-consuming.

To sum up, when using patches to execute test cases to test the logic of the vulnerability repair client, both downloading and installing patches are very time-consuming and affect the efficiency of testing.

Contents of the invention

The present application provides a method and system for testing logic of a vulnerability repair client to solve the problem that the test of the logic of the vulnerability repair client is time-consuming and affects efficiency.

In order to solve the above problems, this application discloses a testing method for vulnerability repair client logic, including:

The vulnerability repair client scans the system according to a pattern to find simulated vulnerabilities;

If the simulated loophole is found, download the corresponding simulated loophole patch from the loophole database of the server, and the simulated loophole patch is used to generate the simulated loophole repair mark on the basis of retaining the original system files of the system;

Installing the simulated vulnerability patch and generating a corresponding simulated vulnerability repair identification, the simulated vulnerability repair identification is used to identify the completion of the simulated vulnerability repair;

The vulnerability repair client traverses all modes to complete the entire testing process;

If all the above processes are performed normally, the test of the vulnerability repair client logic is passed.

Preferably, after installing the simulated vulnerability patch and generating a corresponding simulated vulnerability repair identification, before executing the test in the next mode, it also includes:

Delete the generated simulated bugfix ID.

Preferably, the simulated vulnerability is that there is no simulated vulnerability repair file under the system-specific storage directory,

The vulnerability repair client scans the system according to a pattern to find simulated vulnerabilities, including:

The vulnerability repair client scans the specific storage directory of the system according to a pattern to see if there is a simulated vulnerability repair file. If it does not exist, it finds the simulated vulnerability, otherwise it does not find the simulated vulnerability.

Preferably, the simulated vulnerability is that there is no simulated vulnerability repair data in the system-specific registry key,

The vulnerability repair client scans the system according to a pattern to find simulated vulnerabilities, including:

The vulnerability repair client scans the system-specific registry entries for simulated vulnerability repair data according to a pattern. If it does not exist, it finds the simulated vulnerability, otherwise it does not find the simulated vulnerability.

Preferably, said installing the simulated vulnerability patch and generating a corresponding simulated vulnerability repair identification includes:

Install the simulated vulnerability patch, and generate a corresponding simulated vulnerability repair file in a system-specific storage directory.

Preferably, said installing the simulated vulnerability patch and generating a corresponding simulated vulnerability repair identification includes:

Install the simulated vulnerability patch, and add corresponding simulated vulnerability repair data on the system-specific registry key.

Preferably, for the vulnerability database storing simulated vulnerability patches, a server containing the vulnerability database is established in advance on the intranet.

Preferably, a vulnerability repair client is set up on the local test machine, and the patch download domain name of the local test machine is pointed to the intranet simulation server in advance.

Preferably, the simulated vulnerability patch is pre-written and named according to the naming method of the real patch.

Preferably, the simulated vulnerability patch is stored in the vulnerability library of the simulation server in advance, and the information of the simulated vulnerability patch and the patch number are added to the vulnerability library, wherein the name of the simulated vulnerability patch includes the patch number.

Preferably, simulated vulnerability information is added to the vulnerability repair client in advance, and the simulated vulnerability information is used to identify the simulated vulnerability and the corresponding simulated vulnerability patch.

Correspondingly, the present application also discloses a test system for vulnerability repair client logic, including:

The first mode test module specifically includes the following three sub-modules:

The vulnerability scanning sub-module is used for the vulnerability repair client to scan the system according to a pattern to find simulated vulnerabilities;

Download the patch sub-module, which is used to download the corresponding simulated vulnerability patch from the vulnerability database of the server if the simulated vulnerability is found, and the simulated vulnerability patch is used to generate the simulated vulnerability patch on the basis of retaining the original system file Simulate vulnerability repair logo;

Install the patch submodule, which is used to install the simulated vulnerability patch and generate a corresponding simulated vulnerability repair identifier, and the simulated vulnerability repair identifier is used to identify that the simulated vulnerability repair is completed;

Other mode testing modules, used for vulnerability repair client to traverse all modes to complete the whole testing process;

The result module is used to pass the test of the vulnerability repair client logic if all the above processes are executed normally.

Preferably, the first mode test module also includes:

Delete the patch submodule, which is used to delete the generated simulated vulnerability repair identifier.

Preferably, the simulated vulnerability is that there is no simulated vulnerability repair file under the system-specific storage directory, and the scanning vulnerability submodule includes:

The first vulnerability scanning unit is used for the vulnerability repair client to scan the specific storage directory of the system according to a pattern to see if there is a simulated vulnerability repair file. If there is no simulated vulnerability, the simulated vulnerability is found; otherwise, no simulated vulnerability is found.

Preferably, the simulated vulnerability is that there is no simulated vulnerability repair file under the system-specific storage directory, and the scanning vulnerability submodule includes:

The second scanning vulnerability unit is used for the vulnerability repair client to scan system-specific registry entries according to a pattern if there is no simulated vulnerability repair data. If there is no simulated vulnerability repair data, the simulated vulnerability is found, otherwise no simulated vulnerability is found.

Preferably, the patch submodule installation includes:

The first patch installation unit is configured to install the simulated vulnerability patch, and generate a corresponding simulated vulnerability repair file in a system-specific storage directory.

The second patch installation unit is configured to install the simulated vulnerability patch, and add corresponding simulated vulnerability repair data to a system-specific registry entry.

Preferably, the system also includes:

The server and vulnerability database module is established, which is used to establish a server containing the vulnerability database in advance on the intranet for the vulnerability database storing simulated vulnerability patches.

The preset download domain name module is used to set the vulnerability repair client on the local test machine, and point the patch download domain name of the local test machine to the intranet simulation server in advance.

Write and name the patch module, which is used to pre-write simulated vulnerability patches and name them according to the naming method of real patches

Preserving the patch module is used to store the simulated vulnerability patches in the vulnerability database of the simulation server in advance, and add information and patch numbers of the simulated vulnerability patches in the vulnerability database, wherein the simulated vulnerability patches include in the name of patch number.

The adding information module is used to pre-add simulated vulnerability information in the vulnerability repair client, and the simulated vulnerability information is used to identify the simulated vulnerability and the corresponding simulated vulnerability patch.

Compared with the prior art, the present application includes the following advantages:

First, this application uses simulated vulnerabilities to replace real vulnerabilities, and the simulated vulnerability patches are used to replace real vulnerability patches. Therefore, the vulnerability repair client scans the system according to a pattern to find simulated vulnerabilities. If a simulated vulnerability is found, it downloads the corresponding simulated vulnerability patch from the vulnerability library of the server. The simulated vulnerability patch is in On the basis of retaining the original system files of the system, it is used to generate a simulated vulnerability repair logo, so the simulated vulnerability patch is relatively small and the download speed is relatively fast. Then install the simulated vulnerability patch and generate a simulated vulnerability repair identifier, the simulated vulnerability repair identifier is used to identify the completion of the simulated vulnerability repair, and the vulnerability repair client traverses all modes to complete the entire testing process, if all of the above-mentioned processes are executed normally, Then the test of the vulnerability repair client logic is passed. This application does not need to update system files when installing patches, and the installation speed is very fast. It can be seen that the downloading and installation of the patch are very fast in this application, which shortens the test time for repairing the client logic and improves the test efficiency.

Secondly, after the test of a certain logic is completed, other logic needs to be tested with this patch, so the patch needs to be uninstalled. In the prior art, when uninstalling, the system needs to be restored to the state before it was not patched, that is, the updated system files will be deleted, and the modified registry will be restored. Therefore, the system needs to be restarted, which is also very time-consuming. The vulnerability repair client of this application only generates a simulated vulnerability repair logo when executing a test mode. Therefore, after the test in this mode is completed and before the test is performed in the next mode, it only needs to delete the simulated bug repair logo. It is necessary to delete the simulated vulnerability repair file, or delete the simulated vulnerability repair data, without restarting, which saves time and further improves the efficiency of testing.

Again, the present application uses simulated loopholes to replace real loopholes, so the setting of the simulated loopholes can be controlled according to the preset simulated loopholes. Therefore, when scanning, you only need to scan whether there is a simulated vulnerability repair file in the system-specific storage directory, or scan whether there is simulated vulnerability repair data in a system-specific registry item, and you can quickly find the vulnerability, which further improves the testing efficiency. efficiency.

Again, this application aims at storing the vulnerability database of the simulated vulnerability patch, and establishes a server containing the vulnerability database in advance on the intranet, which can control the download environment of the vulnerability patch, so that the download of the vulnerability patch will not be affected by the external network environment, and further Increased download speed for exploit patches.

Description of drawings

Fig. 1 is a flow chart of a test method for vulnerability repair client logic described in the embodiment of the present application;

FIG. 2 is a structural diagram of a test system for a vulnerability repair client logic according to an embodiment of the present application.

Detailed ways

In order to make the above objects, features and advantages of the present application more obvious and comprehensible, the present application will be further described in detail below in conjunction with the accompanying drawings and specific implementation methods.

In the existing technology, when testing the logic of the vulnerability repair client, after the system scans the vulnerability and confirms that it can be repaired, the vulnerability repair client needs to download the patch from the external network due to the limitation of the network environment, which will result in time-consuming downloading of the patch. When installing after downloading the patch, the patch needs to release and update system files, and also modify the registry, etc., and the patching process is also time-consuming.

This application provides a testing method for the client logic of vulnerability repair. When the vulnerability is repaired, downloading and installing the patch are very fast, which improves the efficiency of the test.

Referring to FIG. 1 , it shows a flow chart of a testing method for vulnerability repair client logic according to an embodiment of the present application.

Step 11, the vulnerability repair client scans the system according to a pattern to find simulated vulnerabilities;

The execution of the vulnerability repair client involves various logics, including startup pop-up window repair, background repair, main interface repair, patch package signature verification, download domain name verification, competing product logic, pop-up window logic, etc. Every time the vulnerability repair client is modified, the above logic needs to be tested one by one to test whether there will be problems in the implementation of the above logical steps on the vulnerability repair client. In the specific implementation, a logic of the vulnerability repair client is used as A pattern for testing.

When the vulnerability repair client is testing a certain logic, it will scan the system according to the corresponding pattern to find simulated vulnerabilities. Therefore, when testing a logic on the vulnerability repair client, the system will be scanned according to a pattern to find out whether there are simulated vulnerabilities in the system. Wherein, the one kind of logic is the first logic of the vulnerability repair client test.

Step 12, if the simulated vulnerability is found, download the corresponding simulated vulnerability patch from the vulnerability library of the server, and the simulated vulnerability patch is used to generate the simulated vulnerability repair identification on the basis of retaining the original system files of the system ;

In specific implementation, if a simulated vulnerability is found in the above scanning and it is confirmed to fix the vulnerability, then download the simulated vulnerability patch from the vulnerability library of the intranet simulation server.

Wherein, the simulated vulnerability patch is used to generate a simulated vulnerability repair identifier on the basis of retaining the original system files of the system. The simulated vulnerability repair identifier is used to identify that the vulnerability has been fixed.

Step 13, installing the simulated vulnerability patch and generating a corresponding simulated vulnerability repair identifier;

It can be known from the above that the simulated vulnerability patch is used to generate a simulated vulnerability repair file on the basis of retaining the original system files of the system. Therefore, after downloading the simulated vulnerability patch, it is necessary to install the simulated vulnerability patch to repair the corresponding vulnerability. When installing the simulated vulnerability patch, the system files in the original system are not modified, and only the corresponding simulated vulnerability patch is generated to complete the vulnerability. repair.

Wherein, the simulated vulnerability repair identifier is used to identify the completion of simulated vulnerability repair.

After step 13 is executed, one mode of the vulnerability repair client is executed. If the one mode is executed normally, then step 14 is executed; otherwise, the one mode is debugged until the test execution is normal.

Step 14, the vulnerability repair client traverses all modes to complete the entire testing process;

Next, the vulnerability repair client traverses all modes, and executes the process from step 11 to step 13 above for each mode, until all modes of the vulnerability repair client are executed, and the entire testing process is completed.

Step 15, if all the above processes are performed normally, the test of the vulnerability repair client logic is passed.

Otherwise, the test of the vulnerability repair client logic fails, and you can debug the place where the execution error occurs.

To sum up, this application uses simulated vulnerabilities to replace real vulnerabilities, and uses simulated vulnerability patches to replace real vulnerability patches. Therefore, the vulnerability repair client scans the system according to a pattern to find simulated vulnerabilities. If a simulated vulnerability is found, it downloads the corresponding simulated vulnerability patch from the vulnerability library of the server. The simulated vulnerability patch is in On the basis of retaining the original system files of the system, it is used to generate a simulated vulnerability repair logo, so the simulated vulnerability patch is relatively small and the download speed is relatively fast. Then install the simulated vulnerability patch and generate a simulated vulnerability repair identifier, the simulated vulnerability repair identifier is used to identify the completion of the simulated vulnerability repair, and the vulnerability repair client traverses all modes to complete the entire testing process, if all of the above-mentioned processes are executed normally, Then the test of the vulnerability repair client logic is passed. This application does not need to update system files or modify the registry when installing the patch, and the installation speed is very fast. It can be seen that the downloading and installation of the patch are very fast in this application, which shortens the test time for repairing the client logic and improves the test efficiency.

Preferably, after installing the simulated vulnerability patch and generating a corresponding simulated vulnerability repair identification, before executing the test in the next mode, it also includes:

Delete the generated simulated bugfix ID.

In the specific implementation, you can write a corresponding deletion program to delete the simulated vulnerability repair logo, and you can also add a delete statement to delete the simulated vulnerability repair logo after the corresponding mode test of the vulnerability repair client is completed. This application does not limit this time.

Because the execution of the vulnerability repair client involves various logics, a logic of the vulnerability repair client will be used as a test mode during testing, but not all patches are suitable for testing, so typical patches are usually selected to test vulnerabilities Fix all modes of the client. After a certain mode is executed, the patch needs to be used to perform tests in other modes, so the patch needs to be uninstalled.

In the prior art, when uninstalling, the system needs to be restored to the state before it was not patched, that is, the updated system files will be deleted, and the modified registry will be restored. Therefore, the system needs to be restarted, which is also very time-consuming.

The vulnerability repair client of this application only generates a simulated vulnerability repair logo when executing a test mode. Therefore, after the test in this mode is completed and before the test is executed in the next mode, it is only necessary to delete the simulated bug repair logo. Restarting saves a lot of time and further improves the efficiency of testing.

Preferably, the simulated vulnerability is that there is no simulated vulnerability repair file under the system-specific storage directory, and the vulnerability repair client scans the system according to a mode to find the simulated vulnerability, including:

The vulnerability repair client scans the specific storage directory of the system according to a pattern to see if there is a simulated vulnerability repair file. If it does not exist, it finds the simulated vulnerability, otherwise it does not find the simulated vulnerability.

The simulated vulnerability scanned by the system can be pre-set to be a simulated vulnerability repair file that does not exist in the system-specific storage directory. For example, if the zz. If c:\zz.dat is found in the scan, that is, the zz.dat file exists in the C drive of the system, then the system does not have a vulnerability.

Therefore, when the vulnerability repair client scans the system according to a certain pattern, it can scan whether there is a simulated vulnerability repair file in the specific storage directory of the system. If it does not exist, it will find the simulated vulnerability, otherwise it will not find the simulated vulnerability.

For example, when the vulnerability repair client scans the system according to a mode, it can scan the specific storage directory of the system, that is, the C drive, for the existence of the simulated vulnerability repair file, namely zz.dat. If the zz.dat file does not exist in the C drive of the system, the simulated vulnerability is found; if the zz.dat file exists in the C drive of the system, the simulated vulnerability is not found.

Corresponding to this simulated vulnerability, the simulated vulnerability repair is identified as a simulated vulnerability repair file, so when the simulated vulnerability patch is installed, a corresponding simulated vulnerability repair file will be generated in a specific storage directory of the system.

After the corresponding mode test is executed, before the next mode executes the test, it is only necessary to delete the simulated vulnerability repair file.

Preferably, the simulated vulnerability is that there is no simulated vulnerability repair data in a system-specific registry item, and the vulnerability repair client scans the system according to a pattern to find the simulated vulnerability, including:

The vulnerability repair client scans the system-specific registry entries for simulated vulnerability repair data according to a pattern. If it does not exist, it finds the simulated vulnerability, otherwise it does not find the simulated vulnerability.

The vulnerability repair client scans the system according to a mode, and the simulated vulnerability scanned by the system can be pre-set whether there is simulated vulnerability repair data in a system-specific registry item, for example, setting the value of a certain item in a certain registry of the system The data is x, if the return value is 0 after scanning, then the registry entry does not have simulated vulnerability repair data, and the system has a vulnerability; otherwise, if the return value is x after scanning, then the system does not have a vulnerability.

Corresponding to this simulated vulnerability, the simulated vulnerability repair is identified as a simulated vulnerability repair file, so when the simulated vulnerability patch is installed, corresponding simulated vulnerability repair data will be generated in a system-specific registry entry.

After the test of this mode is completed, before the test of the next mode is executed, it is only necessary to delete the simulated vulnerability repair data.

When the system scans according to the corresponding mode, it can scan according to the preset simulated vulnerabilities. If the simulated vulnerabilities are scanned, the corresponding repair operation will be performed. Otherwise, continue to scan in other modes until the end of the test.

This application uses simulated vulnerabilities to replace real vulnerabilities, so the settings of simulated vulnerabilities can be controlled according to the preset simulated vulnerabilities. Therefore, when scanning, you only need to scan whether there is a simulated vulnerability repair file in the system-specific storage directory, or scan whether there is simulated vulnerability repair data in a system-specific registry item, and you can quickly find the vulnerability, which further improves the testing efficiency. efficiency.

Preferably, for the vulnerability database storing simulated vulnerability patches, a server containing the vulnerability database is established in advance on the intranet.

The simulated vulnerability patch needs to be stored in the vulnerability database, and the simulated vulnerability patch corresponding to the above can be downloaded in the vulnerability database when the simulated vulnerability is scanned. Therefore, a server can be established in advance, and the server is established for the above-mentioned vulnerability database. And the server can be established in the intranet, which is the local test and the connected internal network for performing the test, so the network environment can be controlled, so that the download speed of the patch will not be affected by the network environment.

Preferably, a vulnerability repair client is set up on the local test machine, and the patch download domain name of the local test machine is pre-pointed to the server.

This application will set the vulnerability repair client on the local test machine. The vulnerability repair client needs to download the simulated vulnerability patch from the server's vulnerability database. Therefore, the host file of the local test machine can be modified in advance, and the patch download domain name of the local test machine Point to the server, such as pointing to the above-mentioned intranet server.

Preferably, the simulated vulnerability patch is pre-written and named according to the naming method of the real patch.

This application will pre-write the simulated vulnerability patch and name the simulated vulnerability patch according to the naming method of the real patch. The naming method of the real patch usually includes the system targeted by the patch, the variable unique identifier, the corresponding platform and the system of a certain language.

For example, if an exe program is written in advance, and the exe program is used as a simulated vulnerability patch, then the exe program can be set to only generate a zz.dat file in the c:\ directory, and the corresponding simulated vulnerability repair file is zz. dat. Name the exe program WindowsXP-kb444441-x86-chs.exe, then the simulated vulnerability patch name is WindowsXP-kb444441-x86-chs, which is named according to the naming method of the real patch, which means that under the WindowsXP system, The unique identifier of the patch is the patch number kb444441, x86 platform, chs is the Chinese system.

Preferably, the simulated vulnerability patch is stored in the vulnerability database of the server in advance, and the information of the simulated vulnerability patch and the patch number are added to the vulnerability database, wherein the name of the simulated vulnerability patch includes the patch number.

Set up a simulation server in the intranet in advance, and set up a vulnerability library in the simulation server. The vulnerability library in the simulation server simulates the environment of the vulnerability library in the real server. The simulated vulnerability patch can be stored in the vulnerability library of the simulation server in advance, and the information of the simulated vulnerability patch and the patch number are added to the vulnerability library, wherein the name of the simulated vulnerability patch contains the patch number, such as in the above example The name of the simulated vulnerability patch is WindowsXP-kb444441-x86-chs, where kb444441 is the patch number. Each of the patch numbers is the unique identifier of the patch, so they are all unique.

Preferably, simulated vulnerability information is added to the vulnerability repair client in advance, and the simulated vulnerability information is used to identify the simulated vulnerability and the corresponding simulated vulnerability patch.

In the logic test of the vulnerability repair client, it is necessary to scan the simulated vulnerability and download the corresponding simulated vulnerability patch. Therefore, the simulated vulnerability information can be added to the vulnerability repair client in advance, and the vulnerability identification in the simulated vulnerability information The simulated vulnerability is scanned to find, and after the vulnerability is found, the corresponding simulated vulnerability patch can also be found according to the patch identifier in the simulated vulnerability information.

In the specific implementation, the vulnerability identification can be set according to the above two simulated vulnerabilities, corresponding to the settings of the simulated vulnerability patches in the vulnerability database of the server, and the same settings can be configured for the patch identification, so that after finding the simulated vulnerabilities, according to the When the patch identifier finds the corresponding simulated vulnerability patch, you can find the simulated vulnerability patch corresponding to the simulated vulnerability in the vulnerability database of the intranet simulation server and execute the download.

This application counts the time spent using real vulnerability patches and simulated vulnerability patches by the vulnerability repair client in the specific implementation. The following uses this as an example to discuss the specific data as shown in Table 1:

Table 1

From the data in Table 1, it can be seen that when the vulnerability repair client uses the real vulnerability patch to test, the test time of each mode is roughly 483-1343s. When the vulnerability repair client uses the simulated vulnerability patch for testing, the test time for each mode is roughly 14-24s.

When testing with a real vulnerability patch, it takes no less than 100 seconds to download the patch, install the patch, restart to make the patch take effect, uninstall the patch, and restart after uninstalling, which is very time-consuming. In addition, when installing the real patch in the win7 system, there is still an internal system repair mechanism that the xp system does not have, so the installation time will be longer

When using the simulated vulnerability patch for testing, the longest time to download the patch is only 10s. The test time using the simulated vulnerability patch is very fast, which greatly improves the test efficiency and does not require any restart during the test The steps can be executed quickly by using the automated program, which further improves the test efficiency.

Referring to FIG. 2 , it shows a structural diagram of a testing system for a vulnerability repair client logic in the embodiment of the present application.

Correspondingly, the present application also provides a vulnerability repair client logic testing system, including a first mode testing module 15, other mode testing modules 16 and a result module 17, wherein,

The first mode test module 15 specifically includes the following 3 submodules:

The vulnerability scanning sub-module 151 is used for the vulnerability repair client to scan the system according to a mode to find simulated vulnerabilities;

Download patch sub-module 152, if find the simulated loophole, then download the loophole patch corresponding to the simulation from the loophole storehouse of server, the loophole patch of described simulation is used on the basis of retaining the original system file of the system Generate a simulated vulnerability repair logo;

Install the patch sub-module 153, which is used to install the simulated vulnerability patch and generate a corresponding simulated vulnerability repair identifier, and the simulated vulnerability repair identifier is used to identify that the simulated vulnerability repair is completed;

Other pattern testing module 16, is used for loophole repair client traversing all patterns to complete the whole testing process;

The result module 17 is configured to pass the test of the vulnerability repair client logic if all the above processes are performed normally.

Preferably, the system also includes:

The delete patch submodule 154 is used to delete the generated simulated vulnerability repair identifier.

The simulated vulnerability is that there is no simulated vulnerability repair file under the system-specific storage directory, and the scanning vulnerability submodule 151 includes:

The first vulnerability scanning unit 1511 is used for the vulnerability repair client to scan the specific storage directory of the system according to a pattern to see if there is a simulated vulnerability repair file. If there is no simulated vulnerability, the simulated vulnerability is found; otherwise, no simulated vulnerability is found.

The simulated vulnerability is that there is no simulated vulnerability repair file under the system-specific storage directory, and the scanning vulnerability submodule 151 includes:

The second scanning vulnerability unit 1512 is used for the vulnerability repairing client to scan system-specific registry entries according to a pattern if there is no simulated vulnerability repair data. If there is no simulated vulnerability, the simulated vulnerability is found; otherwise, no simulated vulnerability is found.

Install patch submodule 153, including:

The first patch installation unit 1531 is configured to install the simulated vulnerability patch, and generate a corresponding simulated vulnerability repair file in a system-specific storage directory.

The second patch installation unit 1532 is configured to install the simulated vulnerability patch, and add corresponding simulated vulnerability repair data to a system-specific registry entry.

Establishing the server and vulnerability database module 10 is used for establishing a server containing the vulnerability database on the intranet in advance for the vulnerability database storing simulated vulnerability patches.

The preset download domain name module 11 is used to set the vulnerability repair client on the local test machine, and point the patch download domain name of the local test machine to the intranet simulation server in advance.

Write and name patch module 12, which is used to pre-write simulated vulnerability patches and name them according to the naming method of real patches

Preserve patch module 13, be used for preserving the vulnerability patch of described simulation in the vulnerability storehouse of simulation server, and add the information and the patch number of the vulnerability patch of simulation in the vulnerability storehouse, wherein in the name of the vulnerability patch of described simulation Contains the patch number.

In the test of the vulnerability repair client logic, each mode will be tested separately. The test module corresponding to a certain mode of the mode is the same as the scanning vulnerability sub-module 141, and both include corresponding sub-modules, such as the scanning vulnerability sub-module and the download patch sub-module. module, install patch submodule, and remove patch submodule.

The information adding module 14 is configured to pre-add simulated vulnerability information in the vulnerability repair client, and the simulated vulnerability information is used to identify the simulated vulnerability and the corresponding simulated vulnerability patch.

As for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for the related parts, please refer to the part of the description of the method embodiment.

Each embodiment in this specification is described in a progressive manner, each embodiment focuses on the difference from other embodiments, and the same and similar parts of each embodiment can be referred to each other.

This application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

Finally, it should also be noted that in this text, relational terms such as one and second etc. are only used to distinguish one entity or operation from another, and do not necessarily require or imply that these entities or operations, any such actual relationship or order exists. Furthermore, the term "comprises", "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus comprising a set of elements includes not only those elements, but also includes elements not expressly listed. other elements of, or also include elements inherent in, such a process, method, commodity, or apparatus. Without further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising said element.

The above is a detailed introduction to the testing method and system of a vulnerability repair client logic provided by this application. In this paper, specific examples are used to illustrate the principle and implementation of this application. The description of the above embodiment is only for To help understand the method and its core idea of this application; at the same time, for those of ordinary skill in the art, according to the idea of this application, there will be changes in the specific implementation and application scope. In summary, the content of this specification It should not be construed as a limitation of the application.

Claims (18)

1. A test method for vulnerability repair client logic, characterized in that, comprising: Adding simulated vulnerability information in the vulnerability repair client in advance, the simulated vulnerability information is used to identify the simulated vulnerability and the corresponding simulated vulnerability patch; The vulnerability repair client scans the system according to a pattern to find simulated vulnerabilities; if a simulated vulnerability is found, it downloads the corresponding simulated vulnerability patch from the vulnerability library of the server, and the simulated vulnerability patch On the basis of retaining the original system files of the system, it is used to generate a simulated vulnerability repair logo; Installing the simulated vulnerability patch and generating a corresponding simulated vulnerability repair identification, the simulated vulnerability repair identification is used to identify the completion of the simulated vulnerability repair; The vulnerability repair client traverses all modes to complete the entire testing process; If all the above processes are performed normally, the test of the vulnerability repair client logic is passed; Wherein, after installing the simulated vulnerability patch and generating the corresponding simulated vulnerability repair identification, before performing the test in the next mode, it also includes: The generated simulated vulnerability patch identification is deleted, so as to realize the uninstallation of the simulated vulnerability patch. 2. The method according to claim 1, characterized in that, the simulated loophole is that there is no simulated loophole repair file under the specific storage directory of the system, The vulnerability repair client scans the system according to a pattern to find simulated vulnerabilities, including: The vulnerability repair client scans the specific storage directory of the system according to a pattern to see if there is a simulated vulnerability repair file. If it does not exist, it finds the simulated vulnerability, otherwise it does not find the simulated vulnerability. 3. The method according to claim 1, characterized in that, the simulated loophole is that there is no simulated loophole repair data in the system-specific registry entry, The vulnerability repair client scans the system according to a pattern to find simulated vulnerabilities, including: The vulnerability repair client scans the system-specific registry entries for simulated vulnerability repair data according to a pattern. If it does not exist, it finds the simulated vulnerability, otherwise it does not find the simulated vulnerability. 4. The method according to claim 2, wherein said installing the simulated vulnerability patch and generating a corresponding simulated vulnerability repair identification comprises: Install the simulated vulnerability patch, and generate a corresponding simulated vulnerability repair file in a system-specific storage directory. 5. The method according to claim 3, wherein said installing the simulated vulnerability patch and generating a corresponding simulated vulnerability repair identification comprises: Install the simulated vulnerability patch, and add corresponding simulated vulnerability repair data on the system-specific registry key. 6. The method according to claim 1, further comprising: For the vulnerability library storing simulated vulnerability patches, a server containing the vulnerability library is established in advance on the intranet. 7. The method of claim 1, further comprising: Set up the vulnerability repair client on the local test machine, and point the patch download domain name of the local test machine to the server in advance. 8. The method of claim 1, further comprising: Pre-write simulated vulnerability patches and name them according to the naming method of real patches. 9. The method according to claim 8, further comprising: The simulated vulnerability patch is stored in the vulnerability database of the server in advance, and the information of the simulated vulnerability patch and the patch number are added to the vulnerability database, wherein the name of the simulated vulnerability patch includes the patch number. 10. A test system for vulnerability repair client logic, characterized in that, comprising: Adding an information module is used to add simulated vulnerability information in the vulnerability repair client in advance, and the simulated vulnerability information is used to identify the simulated vulnerability and the corresponding simulated vulnerability patch; The first mode test module specifically includes the following three sub-modules: The vulnerability scanning sub-module is used for the vulnerability repair client to scan the system according to a pattern to find simulated vulnerabilities; Download the patch sub-module, which is used to download the corresponding simulated vulnerability patch from the vulnerability database of the server if the simulated vulnerability is found, and the simulated vulnerability patch is used to generate the simulated vulnerability patch on the basis of retaining the original system file Simulate vulnerability repair logo; Install the patch submodule, which is used to install the simulated vulnerability patch and generate a corresponding simulated vulnerability repair identifier, and the simulated vulnerability repair identifier is used to identify that the simulated vulnerability repair is completed; Other mode testing modules, used for vulnerability repair client to traverse all modes to complete the whole testing process; The result module is used to pass the test of the vulnerability repair client logic if all the above processes are executed normally; The delete patch sub-module is used to delete the generated simulated vulnerability patch identification, so as to realize the uninstallation of the simulated vulnerability patch. 11. The system according to claim 10, wherein the simulated vulnerability is that there is no simulated vulnerability repair file under the system-specific storage directory, and the scanning vulnerability submodule includes: The first vulnerability scanning unit is used for the vulnerability repair client to scan the specific storage directory of the system according to a pattern to see if there is a simulated vulnerability repair file. If there is no simulated vulnerability, the simulated vulnerability is found; otherwise, no simulated vulnerability is found. 12. The system according to claim 10, wherein the simulated vulnerability is that there is no simulated vulnerability repair file under the system-specific storage directory, and the scanning vulnerability submodule includes: The second scanning vulnerability unit is used for the vulnerability repair client to scan system-specific registry entries according to a pattern if there is no simulated vulnerability repair data. If there is no simulated vulnerability repair data, the simulated vulnerability is found, otherwise no simulated vulnerability is found. 13. The system according to claim 11, wherein installing the patch submodule comprises: The first patch installation unit is configured to install the simulated vulnerability patch, and generate a corresponding simulated vulnerability repair file in a system-specific storage directory. 14. The system according to claim 12, wherein installing the patch submodule comprises: The second patch installation unit is configured to install the simulated vulnerability patch, and add corresponding simulated vulnerability repair data to a system-specific registry entry. 15. The system of claim 10, further comprising: The server and vulnerability database module is established, which is used to establish a server containing the vulnerability database in advance on the intranet for the vulnerability database storing simulated vulnerability patches. 16. The system of claim 10, further comprising: The preset download domain name module is used to set the vulnerability repair client on the local test machine, and point the patch download domain name of the local test machine to the intranet simulation server in advance. 17. The system of claim 10, further comprising: Write and name the patch module, which is used to pre-write simulated vulnerability patches and name them according to the naming method of real patches. 18. The system of claim 17, further comprising: Preserving the patch module is used to store the simulated vulnerability patches in the vulnerability database of the simulation server in advance, and add information and patch numbers of the simulated vulnerability patches in the vulnerability database, wherein the simulated vulnerability patches include in the name of patch number.