CN115712453A - Method, device and equipment for collecting patch files - Google Patents

Abstract

The embodiment of the application provides a method, a device and equipment for collecting patch files, wherein in the method, a file in a specified format, in which release information of a patch is recorded, in a bulletin page is obtained, so that a list library is generated, log libraries uploaded by various clients are filtered through preset data hit conditions, a list to be matched is generated based on screened suspected patch files, further, files in the list to be matched and a white list are matched based on the same preset attribute field as a matching condition, and the files successfully matched in the list to be matched are regarded as patch files and recorded in a target white list. Therefore, the automatic collection of the patch files can be realized, the labor cost is reduced, and moreover, as the data in the target white list is identified by cross comparison, the accuracy is higher, and simultaneously, it can cover operating system of a large amount of different editions, has better data collection effect.

Description

Method, device and equipment for collecting patch files

Technical Field

The application relates to the technical field of security protection, in particular to a patch file collecting method, a Microsoft patch file device and electronic equipment.

Background

Microsoft patch files are very important for the Windows operating system. For a terminal with antivirus software deployed, in order to prevent the patch file from being "mistakenly killed" by the antivirus software, the microsoft patch file is usually collected in the form of a white list.

Microsoft patch files are generally distributed in a special format compression package, a large number of upgrading files are compressed in the compression package, and the traditional mode for collecting microsoft patch files is to decompress the compression package, calculate the Hash value of the released upgrading files and collect the Hash value. Because the upgrade information in the compressed package is obtained by performing field calculation and combination by using the existing version file information of the local operating system, when microsoft patch files are collected, a large number of operating systems with different versions need to be deployed for environment preparation, otherwise, the upgrade files released based on the upgrade information decompression are easy to be lost. The related art generally adopts a manual processing mode, however, the process is labor-consuming and still difficult to fully cover.

Disclosure of Invention

An object of the embodiments of the present application is to provide a method, an apparatus, and a device for collecting patch files, which are used to solve the problems in the related art that much labor is required to be consumed when collecting patch files, and it is still difficult to fully cover the patch files.

In a first aspect, a method for collecting patch files provided in an embodiment of the present application includes:

acquiring a file with a specified format in a bulletin page, and generating a list library based on the file with the specified format; the release information of the patch is recorded in the file with the specified format;

filtering a log library uploaded by each client, and generating a list to be matched based on files meeting preset data hit conditions in the log library;

and matching the files in the list to be matched with the list library based on the same preset attribute field as a matching condition, and recording the successfully matched files in the list to be matched into a target white list.

In the implementation process, a file in a specified format, in which the release information of the patch is recorded, in the bulletin page is obtained, so that a list library is generated, the log library uploaded by each client is filtered through a preset data hit condition, a list to be matched is generated based on the screened suspected patch files, further, files in the list to be matched and a white list are matched based on the same preset attribute field as a matching condition, the files successfully matched in the list to be matched are regarded as patch files, and the patch files are recorded in a target white list. Therefore, automatic collection of patch files can be achieved, labor cost is reduced, and due to the fact that data in the target white list are identified through cross comparison, accuracy is high, meanwhile, the patch files can cover a large number of operating systems of different versions, and the patch files have a better data collection effect.

Further, in some embodiments, the obtaining a file in a specified format in the advertisement page includes:

and detecting a crawler protocol of the announcement page, and acquiring a file with a specified format from the announcement page through a crawler technology under the condition that the crawler protocol supports crawling.

In the implementation process, the patch release information is acquired through a crawler technology, so that the labor cost can be reduced.

Further, in some embodiments, the specified format file is a CSV file of a corresponding knowledge base article; the obtaining of the file with the specified format from the announcement page through the crawler technology includes:

capturing all CSV files in the bulletin page through a crawler technology;

and extracting the CSV files corresponding to the knowledge base articles from the captured CSV files.

In the implementation process, all the crawled CSV files are filtered, so that the file with the specified format, in which the patch release information is recorded, can be accurately acquired.

Further, in some embodiments, the capturing all CSV files in the bulletin page by crawler technology includes:

and traversing and crawling the CSV file in the bulletin page according to a preset crawling rule, wherein the crawling rule comprises a root page address, a crawling hierarchy and a page type analysis mode.

In the implementation process, the required CSV file can be obtained by setting the crawling rules of the root page address, the crawling hierarchy and the page type analysis mode, and thus, if the subsequent bulletin page is changed, only the crawling rule needs to be modified.

Further, in some embodiments, the preset data hit condition is determined based on the same field between a patch file and a file in the log repository.

In the implementation process, a data hit condition for screening out suspected patch files is determined in a cross comparison mode.

Further, in some embodiments, the preset data hit condition includes at least one of:

the field indicating the company name is a preset company name, the field indicating the product name is a preset operating system name, and the field indicating the product version number is not null.

In the implementation process, the suspected patch files can be effectively screened out by reasonably setting the preset data hit conditions.

Further, in some embodiments, the log library uploaded from each client filters out files meeting preset data hit conditions, generating a list to be matched based on the file, including:

if any file in the log library meets a preset data hit condition, storing the file; the file takes the hash value of the file as a primary key and is stored with the field of the file;

and after traversing all the files in each log library, generating a list to be matched based on each stored file.

In the implementation process, the hash value of the file meeting the preset data hit condition is used as the primary key, and a specific field is attached to store the file, so that the generation of a target white list in subsequent steps can be facilitated.

Further, in some embodiments, the preset attribute field includes: a field indicating a file size, a field indicating a product version, and a field indicating a file name.

In the implementation process, the patch file can be correctly identified by reasonably setting the preset attribute field.

Further, in some embodiments, the preset attribute field further includes: a field indicating a file path.

In the implementation process, the supplementary path information is used as a reference, so that the accuracy of identifying the patch file is improved.

Further, in some embodiments, the method further comprises:

and sending the target white list to each client so that the client detects the file entering the terminal of the client based on the target white list.

In the implementation process, the target white list is issued to each client, so that the 'mistaken killing' of each client on the patch file can be effectively reduced.

Further, in some embodiments, the method further comprises:

and acquiring the KB number of the file with the specified format corresponding to the file successfully matched in the list to be matched from the list library, and marking the file according to the KB number.

In the implementation process, the identified patch files are marked through the KB numbers, so that operation query and management are facilitated, a manager at a server can know the source of the files through the KB numbers, and can make clear data targets when other calls such as system file replacement are carried out, and compatibility is guaranteed.

In a second aspect, an embodiment of the present application provides a patch file collecting apparatus, including:

the acquisition module is used for acquiring a file with a specified format in the bulletin page and generating a list library based on the file with the specified format; the release information of the Microsoft patch is recorded in the file with the specified format;

the screening module is used for filtering files meeting preset data hit conditions from the log library uploaded by each client and generating a list to be matched based on the files;

and the matching module is used for matching the files in the list to be matched with the list library based on the same preset attribute field as a matching condition, and recording the successfully matched files in the list to be matched into a target white list.

In a third aspect, an embodiment of the present application provides an electronic device, including: memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the steps of the method according to any of the first aspect when executing the computer program.

In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having instructions stored thereon, which, when executed on a computer, cause the computer to perform the method according to any one of the first aspect.

In a fifth aspect, embodiments of the present application provide a computer program product, which when run on a computer, causes the computer to perform the method according to any one of the first aspect.

Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the above-described techniques.

In order to make the aforementioned objects, features and advantages of the present application more comprehensible, preferred embodiments accompanied with figures are described in detail below.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments of the present application will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and that those skilled in the art can also obtain other related drawings based on the drawings without inventive efforts.

Fig. 1 is a flowchart of a patch file collection method according to an embodiment of the present disclosure;

fig. 2 is a schematic diagram of a network security protection system according to an embodiment of the present application;

fig. 3 is a schematic diagram of a workflow of collecting microsoft patch files by a server according to an embodiment of the present application;

fig. 4 is a block diagram of a patch file collecting apparatus according to an embodiment of the present application;

FIG. 5 shows the present application examples provide A block diagram of an electronic device.

Detailed Description

Reference will now be made to the drawings in the following description of embodiments of the present application, the technical solutions in the embodiments of the present application are described.

It should be noted that to: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures. Meanwhile, in the description of the present application, the terms "first", "second", and the like are used only for distinguishing the description, and are not to be construed as indicating or implying relative importance.

As described in the background art, the related art scheme for collecting patch files has the problems of high labor consumption and difficulty in overall coverage. Based on this, the embodiment of the present application provides a patch file collection method to solve this problem.

Embodiments of the present application are described below:

as shown in fig. 1, fig. 1 is a flowchart of a patch file collection method provided in an embodiment of the present application, where the method may be applied to a server of a network security protection system, where the network security protection system is a set of anti-virus security solutions designed for an enterprise-level network environment, and generally includes the server and a client, where the server is generally installed on a server or a terminal of a developer of the network security protection system; the client is generally installed on a terminal of a demand side of the network security protection system, and may be presented as security protection software (also called active defense software, and is more commonly antivirus software). In this embodiment, the server may manage the plurality of clients, including analyzing the killing logs uploaded by the plurality of clients and updating the white lists of the plurality of clients, so as to provide security protection for the terminals where the plurality of clients are located.

The method comprises the following steps:

in step 101, a file with a specified format in a bulletin page is obtained, and a business form library is generated based on the file with the specified format; the release information of the patch is recorded in the file with the specified format;

the patch referred to in this embodiment may be an official release patch to solve problems (typically found by hackers or virus designers) exposed by the operating system during use. Alternatively, the patch may be a microsoft patch and accordingly the microsoft announcement page referred to in this step may be a microsoft patch update advertising page, which is actually a microsoft official website. When microsoft official releases a new patch, a specified format file is provided in the microsoft announcement page, and the release information of the patch is explained. Of course, in other embodiments, the patch may also be a patch program issued for the problem that other operating systems, such as Linux system, macOS system, etc., are exposed during use, which is not limited in this application.

In some embodiments, the obtaining of the specified format file in the advertisement page mentioned in this step may include: and detecting a crawler protocol of the announcement page, and acquiring a file with a specified format from the announcement page through a crawler technology under the condition that the crawler protocol supports crawling. That is, the specified format file may be acquired by the web crawler. Web crawlers, also known as web spiders, web robots, and the like, are programs or scripts that automatically capture web information according to certain rules. Specifically, in this embodiment, the web crawler detects a crawler protocol of the advertisement page, i.e., a robot. And then, the web crawler can perform traversal crawling on the files with the specified format in the bulletin page according to preset rules, such as a root page address, a crawling hierarchy, a page type analysis mode and the like. Taking the patch as an example of a microsoft patch, in all published pages of microsoft, a crawler protocol supports crawling; moreover, the website data in the microsoft bulletin page is also public, so that the embodiment is compliant to acquire the file with the specified format through the crawler technology. Through the crawler technology, the automatic acquisition of the file with the specified format can be efficiently realized, and the labor cost is reduced.

Further, the microsoft bulletin page usually publishes the KB number corresponding to the new patch to explain the publishing information of the new patch. KB (Knowledge Base) is the name of Microsoft for a patch, and refers to which article in Microsoft Knowledge Base a certain patch corresponds, for example, KB888111, which corresponds to article 888111 in Microsoft Knowledge Base. Each KB number corresponds to at least one KB × CSV file. CSV (Comma-Separated Values) is a common, relatively simple file format that stores tabular data (numeric and text) in plain text form. CSV files are composed of any number of records, and the records are separated by a certain linefeed character; each record is made up of fields, and separators between fields are other characters or strings, most commonly commas or tabs. The CSV file may be a CSV file with a KB number in a file name, and a field of the file indicates release information such as a patch name, a size, a path, and the like. Then, when the file with the specified format is obtained through the crawler technology, all CSV files in the bulletin page may be captured through the crawler technology, and the crawled files are filtered at the same time, that is, CSV files corresponding to the knowledge base articles are extracted from the captured CSV files. Thus, the file in the specified format for recording the patch release information can be accurately acquired.

Furthermore, when capturing all CSV files in the bulletin page by the crawler technology, traversing and crawling the CSV files in the bulletin page may be performed according to a preset crawling rule, where the crawling rule includes a root page address, a crawling hierarchy, and a page type parsing manner. That is to say, in implementation, the crawling rules of the root page address, the crawling hierarchy and the page type analysis mode can be set, so that when the web crawler operates, the data in the bulletin page can be analyzed and filtered according to the crawling rules, and finally the needed CSV file can be crawled. Moreover, if the follow-up bulletin page is changed, only the crawling rule needs to be modified, and convenience is achieved.

After the file with the specified format is obtained, the file with the specified format can be stored in a specified directory of the server and is subjected to data merging, so that a business form library is generated.

In step 102, filtering out files meeting preset data hit conditions from a log library uploaded by each client, and generating a list to be matched based on the files;

the log library mentioned in this step may be a library formed by the client recording the relevant information of all files that have gone through the checking and killing functions. By filtering the log library uploaded by each client, files meeting preset data hit rules can be screened out, the files can be regarded as suspected patch files, namely the files recorded in the list to be matched can be suspected patch files on the terminal where each client is located, and the terminals where different clients are located may have operating systems of different versions, so that the suspected microsoft patch files in the list to be matched cover multiple operating system versions. In practical application, because of the large number of clients, the suspected patch files in the list to be matched can basically cover all operating system versions.

In some embodiments, the predetermined data hit condition may be determined based on the same fields between the patch file and the file in the log repository. That is to say, specific fields in independent data of the patch file and files in the log library are correlated, and the preset data hit condition can effectively screen out suspected patch files by combining official patch release information and the searching and killing log. Further, in some embodiments, the predetermined data hit condition may include at least one of: the field indicating the company name is a preset company name, the field indicating the product name is a preset operating system name, and the field indicating the product version number is not null. Taking the example of the patch being a microsoft patch, generally speaking, for the journal library, if a field indicating a company name in a file is microsoft, it indicates that the file is issued by microsoft, but not from other developers, and the file may be considered to be a suspected microsoft patch file; if the field indicating the product name in one file is the Microsoft Windows operating system, the file is a file which is issued by Microsoft officials and aims at the Windows operating system, and the file can be considered as a suspected Microsoft patch file at this moment; the field indicating the product version number in the file released by non-microsoft official is generally empty, so if the field indicating the product version number in a file is not empty, the file can be considered as a suspected microsoft patch file. Through reasonably setting the preset data hit conditions, suspected patch files can be effectively screened out, and a good foundation is laid for subsequent identification. Of course, the preferable scheme is that the preset data hit condition includes the above three items at the same time; in addition, in other embodiments, the preset data hit condition may also set other contents according to the requirements of a specific scenario.

When the data matching is achieved, the server side can match each file in the log library one by one through a preset data hit condition, and then stores the files meeting the preset data hit condition one by one to generate a list to be matched.

Considering that the hash value of the microsoft patch file is usually recorded in the target white list to be generated subsequently, the step of generating the list to be matched may include: if any file in the log library meets a preset data hit condition, storing the file; the file takes the hash value of the file as a primary key and is stored with the field of the file; and after traversing all the files in each log library, generating a list to be matched based on each stored file. The hash value of the file is a digital fingerprint of the file, which may be a value calculated by using a hash function, and the hash function may compress a message or data into a digest, so that the amount of data becomes small, and the format of the data is fixed. The Hash function used may be SHA-1 (Secure Hash Algorithm 1), MD5 (Message Digest Algorithm 5), and the like, which is not limited in this application. The list to be matched can be regarded as a database, and the value of the primary key of the database can uniquely represent each row in the table, so that the hash value of the file meeting the preset data hit condition can be used as the primary key for storage, and the generation of the target white list in the subsequent steps is facilitated. And when generating the list to be matched, in addition to using the hash value as the primary key, specific fields of the file meeting the preset data hit condition may be attached for storage, and these specific fields may include fields that previously meet the data hit rule, such as a field indicating a company name, a field indicating a product version number, and the like, and may also include fields that are subsequently used for matching, such as a field indicating a file name, a field indicating a file size, and the like, and may also include other types of fields.

In step 103, matching the files in the list to be matched with the list library based on the same preset attribute field as a matching condition, and recording the successfully matched files in the list to be matched into a target white list.

Although the files in the list to be matched cover a plurality of operating system versions, the files are not necessarily patch files, so that the files in the list to be matched are matched with the list library on the basis of the same preset attribute field serving as a matching condition, the official patch release information is combined with the check log returned by the terminal with the client terminal, and cross comparison is performed through field matching, so that the patch files are identified, and the missing files in the traditional unpacking mode are recovered.

Specifically, the preset attribute field may be an attribute field in which the patch file objectively exists. In some embodiments, the preset attribute field may include: a field indicating a file size, a field indicating a product version, and a field indicating a file name. That is to say, after the list to be matched is generated, the file is compared with the list library one by one, the three attribute fields of the file Size, the Product Version and the name are matched, and when the comparison is completely consistent, the file details of the file are matched with the official patch release information, so that the file can be determined as a patch file, and the hash value of the file can be recorded into a target white list. Further, the preset attribute field may further include: a field indicating a file path. In practical application, if the path information of a file is not matched with the path information of a patch file, the file is often not the patch file, so that the field indicating the file path can be used as reference information, and the accuracy rate of identifying the patch file is improved.

In addition, after the server generates the target white list, the server can send the target white list to each client, so that each client can detect the file entering the terminal where the corresponding client is located based on the target white list. That is to say, the server may issue the target white list, and each client updates the original white list based on the target white list to perform the checking and killing function, so that the hash values of the patch files corresponding to a large number of operating systems of different versions are collected by the target white list, and thus, the 'mistaken killing' of the patch files by each client can be effectively reduced.

Also, in some embodiments, the method may further comprise: and acquiring the KB number of the file with the specified format corresponding to the file successfully matched in the list to be matched from the white name list library, and marking the file according to the KB number. That is to say, when a file in the list to be matched is determined as a microsoft patch file by comparison, the file can be marked according to the KB number of the file in the specified format having the same preset attribute field as the file, and the file is regarded as being issued by the KB number, so that archiving is completed. Therefore, operation inquiry and management are facilitated, and a manager of the server can know the source of the file through the KB number; meanwhile, when other calls such as system file replacement are carried out, a data target can be defined through the KB number, and compatibility is guaranteed.

According to the method and the device for generating the patch file, the file with the specified format, in which the release information of the patch is recorded, in the announcement page is obtained, the list library is generated, the log library uploaded by each client is filtered through the preset data hit conditions, the list to be matched is generated based on the screened suspected patch files, then the files in the list to be matched and the white list are matched based on the same preset attribute fields serving as the matching conditions, the files in the list to be matched are regarded as the patch files, and the files which are successfully matched in the list to be matched are recorded in the target white list. Therefore, automatic collection of patch files can be achieved, labor cost is reduced, and due to the fact that data in the target white list are identified through cross comparison, accuracy is high, meanwhile, the patch files can cover a large number of operating systems of different versions, and a better data collection effect is achieved.

To illustrate the solution of the present application in more detail, a specific embodiment is described below:

as shown in fig. 2, fig. 2 is a schematic diagram of a network security protection system provided in this embodiment, where the network security protection system includes a server 21 and multiple clients 22. In this embodiment, after the plurality of clients 22 record the relevant information of all local files that have gone through the checking and killing function, a log library is generated and uploaded to the server 21; the server 21 collects microsoft patch files by using the log library uploaded by the clients 22 and combining microsoft official patch release information, and issues a target white list obtained based on a data collection result to the clients 22.

Specifically, the workflow of the server 21 for collecting microsoft patch files is shown in fig. 3, and includes:

s301, traversing and crawling specified CSV files in the Microsoft patch updating advertisement page through a crawler technology;

the specified CSV file is a KB × CSV file, for example, windows11 update, each KB _ number is issued in a Microsoft patch update advertisement page to explain the patch release information, and an update file table is attached at the end of the update file page, and the table contains information such as file names, file sizes and paths;

the crawler technology can detect a robot.txt protocol in a Microsoft patch update advertisement page, determine the access range according to the protocol, further crawl according to a crawling rule, crawl all CSV files, and filter all the crawled CSV files to obtain a specified CSV file; the crawling rule comprises a root page address, a crawling hierarchy, a page type analysis mode and the like;

s302, storing the crawled appointed CSV files into an appointed directory of an appointed server, and performing data merging on all the stored appointed CSV files to generate a Microsoft update information list library;

s303, creating a data hit rule aiming at suspected Microsoft patch files, filtering the log library uploaded by each client, and screening out the suspected Microsoft patch files in each log library;

wherein the data hit rule is: company Name = Microsoft corporation | | Product

Operating System | | Product version number! = null. The data hit ruleIn the above description, "i" is a parallel symbol, "=" the content on the left side is a field, and the content on the right side is detailed information of the field, that is, when a file in the log library satisfies the data hit rule, the file is a suspected microsoft patch file;

s304, aiming at the suspected Microsoft patch files which are screened out, taking a hash value as a main key and attaching specific fields to carry out storage one by one so as to generate a list to be matched;

s305, comparing suspected Microsoft patch files in the list to be matched with a Microsoft update information name list library one by one, matching three attribute fields of Size, product Version and name of the files, and when the comparison is completely consistent, regarding the suspected Microsoft patch files as Microsoft patch files, and recording the hash values of the Microsoft patch files into a target white list;

s306, aiming at the Microsoft patch files recorded in the target white list, the KB _ number where the piece of data in the Microsoft update information name list library is located is obtained, the Microsoft patch files are regarded as being issued by the KB _ number, and archiving is completed.

As can be seen from the above, in the embodiment of the present application, the crawler technology is used as a support, existing independent data such as microsoft official announcement information and a log library of a client are fully utilized, microsoft patch files are identified by a cross-comparison method, and the microsoft patch files are restored to specific directory numbers. Therefore, the traditional method that the files are collected and unpacked by manpower in the industry can be replaced, the early-stage operation is not needed, the source can be ignored, a better data collection effect can be achieved, and the method is higher in accuracy, more comprehensive in coverage and the like.

Corresponding to the foregoing method embodiments, the present application further provides embodiments of a microsoft patch file collecting apparatus and a terminal applied thereto:

as shown in fig. 4, fig. 4 is a block diagram of a patch file collecting apparatus provided in an embodiment of the present application, where the apparatus includes:

an obtaining module 41, configured to obtain a file in a specified format in an advertisement page, and generate a business form library based on the file in the specified format; the release information of the patch is recorded in the file with the specified format;

the screening module 42 is configured to filter out files meeting preset data hit conditions from the log library uploaded by each client, and generate a list to be matched based on the files;

and the matching module 43 is configured to match the files in the list to be matched with the list library based on the same preset attribute field as a matching condition, and record the successfully matched files in the list to be matched into a target white list.

The implementation process of the functions and actions of each module in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.

Please refer to fig. 5, where fig. 5 is a block diagram of an electronic device according to an embodiment of the present disclosure. The electronic device may include a processor 510, a communication interface 520, a memory 530, and at least one communication bus 540. Wherein the communication bus 540 is used for realizing direct connection communication of these components. In this embodiment, the communication interface 520 of the electronic device is used for performing signaling or data communication with other node devices. Processor 510 may be an integrated circuit chip having signal processing capabilities.

The Processor 510 may be a general-purpose Processor including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components. The various methods, steps, and logic blocks disclosed in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor 510 may be any conventional processor or the like.

The Memory 530 may be, but is not limited to, a Random Access Memory (RAM), a Read Only Memory (ROM), a Programmable Read Only Memory (PROM), an Erasable Read Only Memory (EPROM), an electrically Erasable Read Only Memory (EEPROM), and the like. The memory 530 stores computer readable instructions that, when executed by the processor 510, enable the electronic device to perform the steps associated with the method embodiment of fig. 1 described above.

Optionally, the electronic device may further include a memory controller, an input output unit.

The memory 530, the memory controller, the processor 510, the peripheral interface, and the input/output unit are electrically connected to each other directly or indirectly, so as to implement data transmission or interaction. For example, these elements may be electrically coupled to each other via one or more communication buses 540. The processor 510 is used to execute executable modules stored in the memory 530, such as software functional modules or computer programs included in the electronic device.

The input and output unit is used for providing a task for a user and starting an optional time interval or preset execution time for the task creation so as to realize the interaction between the user and the server. The input/output unit may be, but is not limited to, a mouse, a keyboard, and the like.

It will be appreciated that the configuration shown in fig. 5 is merely illustrative and that the electronic device may include more or fewer components than shown in fig. 5 or may have a different configuration than shown in fig. 5. The components shown in fig. 5 may be implemented in hardware, software, or a combination thereof.

The embodiment of the present application further provides a storage medium, where the storage medium stores instructions, and when the instructions are run on a computer, when the computer program is executed by a processor, the method in the method embodiment is implemented, and in order to avoid repetition, details are not repeated here.

The present application also provides a computer program product which, when run on a computer, causes the computer to perform the method of the method embodiments.

In the several embodiments provided in this application, it should be understood that, the disclosed apparatus and method may be implemented in other ways. The apparatus embodiments described above are merely illustrative, and for example, the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In addition, functional modules in the embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

The above description is only an example of the present application and is not intended to limit the scope of the present application, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application shall be included in the protection scope of the present application. It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising a … …" does not exclude the presence of another identical element in a process, method, article, or apparatus that comprises the element.

Claims (13)

1. A patch file collection method is characterized by comprising the following steps:

acquiring a file with a specified format in a bulletin page, and generating a list library based on the file with the specified format; in the file with the specified format recording release information of the patch;

filtering files meeting preset data hit conditions from a log library uploaded by each client, and generating a list to be matched based on the files;

and matching the files in the list to be matched with the list library based on the same preset attribute field as a matching condition, and recording the successfully matched files in the list to be matched into a target white list.

2. The method of claim 1, wherein obtaining the file in the specified format in the advertisement page comprises:

and detecting a crawler protocol of the announcement page, and acquiring a file with a specified format from the announcement page through a crawler technology under the condition that the crawler protocol supports crawling.

3. The method of claim 2, wherein the specified format file is a CSV file of a corresponding knowledge base article; the obtaining of the file with the specified format from the announcement page through the crawler technology includes:

capturing all CSV files in the bulletin page through a crawler technology;

and extracting the CSV files corresponding to the knowledge base articles from the captured CSV files.

4. The method of claim 3, wherein capturing all CSV files in the bulletin page by crawler technology comprises:

and traversing and crawling the CSV file in the bulletin page according to a preset crawling rule, wherein the crawling rule comprises a root page address, a crawling hierarchy and a page type analysis mode.

5. The method of claim 1, wherein the preset data hit condition is determined based on a field that is the same between a patch file and a file in the log repository.

6. The method of claim 5, wherein the predetermined data hit condition comprises at least one of:

the field indicating the company name is a preset company name, the field indicating the product name is a preset operating system name, and the field indicating the product version number is not null.

7. The method according to claim 1, wherein the filtering out files meeting preset data hit conditions from the log library uploaded by each client, and generating a list to be matched based on the files comprises:

if any file in the log library meets a preset data hit condition, storing the file; the file takes the hash value of the file as a primary key and is stored with the field of the file;

and after traversing all the files in each log library, generating a list to be matched based on each stored file.

8. The method of claim 1, wherein the preset attribute field comprises: a field indicating a file size, a field indicating a product version, and a field indicating a file name.

9. The method of claim 8, wherein the preset-attribute field further comprises: a field indicating a file path.

10. The method of claim 1, further comprising:

and sending the target white list to each client so that the client detects the file entering the terminal of the client based on the target white list.

11. The method of claim 1, further comprising:

and acquiring the KB number of the file with the specified format corresponding to the file successfully matched in the list to be matched from the list library, and marking the file according to the KB number.

12. A patch file collection apparatus, comprising:

the acquisition module is used for acquiring a file with a specified format in the bulletin page and generating a list library based on the file with the specified format; the release information of the patch is recorded in the file with the specified format;

the screening module is used for filtering files meeting preset data hit conditions from the log library uploaded by each client and generating a list to be matched based on the files;

and the matching module is used for matching the files in the list to be matched with the list library based on the same preset attribute field as a matching condition, and recording the successfully matched files in the list to be matched into a target white list.

13. An electronic device, comprising: memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the method according to any one of claims 1 to 11 when executing the computer program.

Images