Verification method and electronic equipment

Abstract

The invention discloses a verification method and electronic equipment, and relates to the technical field of information security and artificial intelligence application, and the method comprises the steps: responding to a target trigger event, and determining a target to-be-verified file; under the condition that the target to-be-verified file meets a target condition, performing security verification on the target to-be-verified file in parallel by utilizing a plurality of threads; wherein the to-be-verified file is at least part of a target file, and the target file is a file which can respond to the target trigger event and has a read-write state change.

Description

Technical Field

[0001] The present application relates to the field of information security and artificial intelligence application technology, and in particular to a verification method and electronic equipment. Background Art

[0002] There are many local PC (Personal Computer) applications (applications) containing large models on the market. These applications contain large model files, large installation packages and a large number of files. When users use these application package files and other types of files with similar characteristics (such as data files), they usually face a key problem: how to perform efficient and comprehensive file verification to ensure the security of the files used.

[0003] Known technologies often only verify key files and ignore verification of some files, so that it is impossible to effectively identify whether the ignored files have been tampered with, damaged or missing, resulting in users encountering unforeseen problems when using the files. Summary of the invention

[0004] To this end, this application discloses the following technical solutions:

[0005] A verification method, comprising:

[0006] In response to a target triggering event, determining a target file to be verified;

[0007] When the target file to be verified meets the target condition, a security check is performed on the target file to be verified in parallel using multiple threads;

[0008] The target file to be verified is at least a part of the target file, and the target file is a file that can change its read / write state in response to the target trigger event.

[0009] Optionally, in response to a target triggering event, determining a target file to be verified includes at least one of the following:

[0010] In response to a target triggering event, obtaining first file information of a target file, and determining the target file to be verified based on the first file information;

[0011] Obtaining source information of the target triggering event, and determining the target file to be verified from the target file based on the source information;

[0012] Obtaining configuration information of the electronic device, and determining the target file to be verified from the target file based on the configuration information;

[0013] Obtaining target reference information, and determining a subfile in the target file that matches the target reference information as the target file to be verified, wherein the target reference information is obtained based on big data related to the target file;

[0014] The attribute information of the target file is obtained, and the target file to be verified is determined from the target file based on the attribute information.

[0015] Optionally, determining the target file to be verified based on the first file information includes one of the following:

[0016] Obtaining configuration variable update information of the target file, and determining a subfile in the target file that matches the configuration variable update information as the target file to be verified;

[0017] Obtaining structural information of the target file and file hash values ​​of each structural level, and determining the target file to be verified from the target file based on the structural information and the file hash values;

[0018] Verification configuration information of the target file is obtained, and a subfile or a structural level in the target file corresponding to the verification configuration information is determined as the target file to be verified.

[0019] Optionally, determining a subfile in the target file that matches the configuration variable update information as the target file to be verified includes at least one of the following:

[0020] In a case where the configuration variable information is a modification timestamp of the target file, determining a target subfile having a target timestamp in the target file as the target file to be verified, the target subfile being unique or non-unique;

[0021] In a case where the configuration variable information is an update log of the target file, determining a target subfile in the target file corresponding to the abnormal update log as the target file to be verified;

[0022] In a case where the configuration variable information is an update mark of the target file, determining a target subfile in the target file corresponding to the update mark as the target file to be verified;

[0023] The association relationship between the configuration variable information and the hierarchical structure of the target file is obtained, and based on the association relationship, a target subfile is located from the target file as the target file to be verified.

[0024] Optionally, when the target file to be verified meets the target condition, a security check is performed on the target file to be verified in parallel using multiple threads, including:

[0025] Obtaining second file information of the target file to be verified, wherein the second file information includes at least one of data volume information, quantity information, type information, and position information of the target file to be verified in the target file;

[0026] In the case where the second file information meets the corresponding verification condition, the target file to be verified is verified in parallel using multiple threads running on multiple cores of at least one processor.

[0027] Optionally, using multiple threads to perform security verification on the target file to be verified in parallel includes at least one of the following:

[0028] When the data amount of the target file to be verified is greater than a first threshold, the target file to be verified is divided into blocks to obtain a plurality of file blocks, so as to perform integrity verification and / or accuracy verification on the plurality of file blocks in parallel by using a plurality of threads running on a plurality of cores of at least one processor;

[0029] In the case where there are multiple target files to be verified, multiple threads running on multiple cores of at least one processor are used to perform integrity verification and / or accuracy verification on the multiple target files to be verified in parallel;

[0030] When the types of the target files to be verified are different and / or the structural levels of the target files are the same or different, the integrity and / or accuracy of the multiple target files to be verified are checked in parallel using multiple threads running on multiple cores of at least one processor.

[0031] Optionally, the target file to be verified is divided into blocks to obtain multiple file blocks, including at least one of the following:

[0032] In the case where the target file to be verified is an independent file in the target file, splitting the target file to be verified into a plurality of file blocks based on the data volume and / or specific character content of the target file to be verified;

[0033] In the case where the target file to be verified includes a file structure hierarchy, splitting the target file to be verified into a plurality of file blocks based on the file structure hierarchy relationship of the target file to be verified;

[0034] Obtaining a data type in the target file to be verified, and splitting the target file to be verified into multiple file blocks based on the data type;

[0035] The function service information corresponding to the target file to be verified and / or the attack probability of each part of the target file to be verified is obtained, and the target file to be verified is split into multiple file blocks based on the function service information and / or the attack probability.

[0036] Optionally, when there are multiple target files to be verified, performing integrity verification and / or accuracy verification on the multiple target files to be verified in parallel using multiple threads running on multiple cores of at least one processor includes at least one of the following:

[0037] In the case where there are multiple target files to be verified and the data amounts of all the files are not greater than the first threshold, calling multiple threads running on multiple cores of at least one processor to perform integrity verification and / or accuracy verification on the multiple target files to be verified in parallel based on the type and / or structural level of each target file to be verified;

[0038] When there are multiple target files to be checked and the data amount of the first file to be checked is greater than a first threshold, the first file to be checked is processed in blocks, and integrity and / or accuracy checks are performed in parallel on each file block of the first file to be checked and other target files to be checked using multiple threads running on multiple cores of at least one processor.

[0039] Optionally, using multiple threads to perform security verification on the target file to be verified in parallel includes:

[0040] Using multiple threads running on multiple cores of at least one processor to perform hash processing on multiple target files to be verified or multiple file blocks in parallel, obtaining a current hash value of each target file to be verified or file block, and comparing the current hash value with a target reference hash value to obtain a verification result of the target file to be verified;

[0041] and / or,

[0042] The target trigger event is generated by at least one of the following:

[0043] In response to an operation of changing a running state of a target application of the electronic device, the target application is an application including a large model file or capable of calling a large model file;

[0044] In response to an operation of changing the read-write state of the target large model file in the electronic device;

[0045] In response to detecting an event that the electronic device is attacked.

[0046] An electronic device includes a processor and at least one large model file capable of running on the processor, when the large model file is called by a target application, the read / write state of the large model file changes, and the processor is capable of performing at least one of the following:

[0047] Determine a target file to be verified, where the target file to be verified belongs to at least a part of the large model file or the target application;

[0048] When the target file to be verified meets the target condition, a security check is performed on the target file to be verified in parallel using multiple threads.

[0049] A storage medium carries one or more computer instruction sets, which, when executed by an electronic device, can enable the electronic device to implement any of the verification methods described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0051] Figure 1 It is a flow chart of the verification method provided by this application;

[0052] Figure 2 is an example of a hash tree corresponding to the file hierarchy structure provided in this application;

[0053] Figure 3 This is a flow chart of security verification of the target file to be verified provided by the present application;

[0054] Figure 4 This is a schematic diagram of the block processing and HASH verification of the target file to be verified provided by the present application;

[0055] Figure 5 It is a structural diagram of the electronic device provided in this application. DETAILED DESCRIPTION

[0056] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0057] The embodiments of the present application provide a verification method and an electronic device, which are mainly used to implement efficient and comprehensive file verification of target files such as application packages or data files that are large in size, contain a large number of files and / or have a large amount of file data, so as to avoid unforeseen problems during the use of the files (such as during the operation of the application package).

[0058] The verification method provided in the embodiment of the present application can be applied to electronic devices in many general or special computing device environments or configurations, such as personal computers, server computers, handheld devices or portable devices, tablet devices, multi-processor devices, etc.

[0059] See also Figure 1 As shown in the method flow chart, the verification method provided in the embodiment of the present application may include the following steps 101 to 102, and these steps are described in detail below.

[0060] Step 101: In response to a target triggering event, determine a target file to be verified.

[0061] The target file to be verified is at least a part of the target file, and the target file is a file that can change its read / write state in response to the target trigger event.

[0062] The target file may be, but is not limited to, an application package, a model file, a large model file, or a data file, etc. The embodiment of the present application does not limit the type of the target file, and may be, but is not limited to, various types of files such as application files, document files, image files, audio and video files, database files, web pages, or address files.

[0063] The target trigger event is an event generated based on an operation on a target file.

[0064] Taking the target file as an application package as an example, the target trigger event may include but is not limited to events generated based on operations such as downloading, saving, opening, installing, starting, sharing, etc. of the application package. Taking the target file as a data file as an example, the target trigger event may include but is not limited to events generated based on operations such as downloading, saving, sharing, opening, etc. of the data file.

[0065] The target trigger event can trigger the target file to be read and written, for example, triggering the target file to be written from the cloud to the local to realize file download, reading from the local to the cloud or other devices to realize file sharing, reading from the SSD (Solid State Drive) to the memory or cache to realize file opening, editing, and start loading, or triggering the target file to be written from the memory to the SSD to realize file saving, etc., so that the target file can respond to the target trigger event and undergo a change in the read and write state.

[0066] The target file to be verified includes at least the file in the target file that has verification requirements and needs to be verified. The target file to be verified can be the entire file of the target file or a part of the target file, and can specifically include but is not limited to abnormal files in the target file, files that have been modified and edited, and / or files marked as untrusted, etc.

[0067] In actual application scenarios, when the target trigger event is generated based on the operation of the target file, for example, when the user downloads an application package from the cloud based on actual needs or loads the file in the application package installed on the local device into the memory to start the application, a target trigger event will be generated. In response to the target trigger event, the target file to be verified can be first determined from the target file, such as abnormal files in the target file, modified and edited files, and / or files marked as untrusted, etc., so as to perform file verification on them.

[0068] Step 102: When the target file to be verified meets the target condition, a security check is performed on the target file to be verified in parallel using multiple threads.

[0069] The security verification may include, but is not limited to, any one or more of integrity verification, signature or identity verification, data accuracy verification, etc.

[0070] The target condition may be, but is not limited to, set to include at least one of the following:

[0071] Condition 1: The data volume of the target file to be verified reaches the data volume threshold;

[0072] Condition 2: There are multiple target files to be verified (such as reaching the number threshold), and each target file to be verified is in the same or different levels of the directory structure;

[0073] Condition 3: There are multiple target files to be verified (e.g., reaching a quantity threshold), and the types of the target files to be verified are different and / or the corresponding verification methods are different. For example, the target files to be verified are different types such as data files, multimedia files, or database files, and these different types of files need to be verified based on different verification methods such as integrity verification, signature or identity verification, data accuracy verification, etc.

[0074] After determining the target file to be verified from the target file, this step can further determine whether the target file to be verified meets the target condition, and in response to the target file to be verified meeting the target condition, use multiple threads in parallel to perform security verification on the target file to be verified.

[0075] Exemplarily, in the case where the data volume of the target file to be verified reaches the data volume threshold, the target file to be verified can be processed into blocks to obtain multiple file blocks, and multiple threads can be used to perform security verification on each file block of the target file to be verified in parallel. In the case where the number of target files to be verified is multiple, and each target file to be verified is in the same or different levels of directory structure, multiple threads can be used to perform security verification on each target file to be verified in parallel according to the directory structure level where each target file to be verified is located. In the case where the number of target files to be verified is multiple (such as reaching the quantity threshold), and the types of each target file to be verified are different and / or the corresponding verification methods are different, multiple threads can be used to perform security verification on each target file to be verified in parallel according to the type of each target file to be verified and / or the corresponding verification method (such as integrity verification, signature or identity verification, data accuracy verification, etc.). This part will be described in detail in the following embodiments.

[0076] On the contrary, if the target file to be verified does not meet the target condition, for example, the number of target files to be verified is 1 and the data volume does not reach the data volume threshold, a single thread can be used to perform the required security verification on the target file to be verified, such as integrity verification, signature or identity verification, data accuracy verification, etc.

[0077] In summary, the verification method provided by this embodiment includes: in response to a target trigger event, determining a target file to be verified; and when the target file to be verified meets the target condition, using multiple threads to perform security verification on the target file to be verified in parallel; wherein the target file to be verified is at least part of the target file, and the target file is a file that can respond to the target trigger event and undergo a read-write state change. Based on the method provided by the embodiment of the present application, on the one hand, the efficiency of file verification can be improved by multi-threaded parallel verification, and on the other hand, at least the target file to be verified with verification requirements (such as abnormal files in the target file, files that have been modified and edited, and / or files that are marked as untrusted, etc.) can be determined from the target file targeted by the target trigger event, and only the determined target file to be verified (rather than the entire file of the target file) can be verified in a targeted manner, further reducing the amount of data for file verification and improving the verification efficiency, while ensuring the coverage of files with verification requirements in the target file, avoiding missing verification of files with verification requirements, so that the embodiment of the present application effectively ensures the security of all files in the target file (such as an application package) while improving the efficiency of file verification and achieving efficient and comprehensive file verification.

[0078] In an optional embodiment, step 101 in the method provided in the present application, i.e., determining the target file to be verified in response to a target trigger event, can be implemented as at least one of the following implementations "1-1" to "1-5", including but not limited to.

[0079] 1-1. In response to a target triggering event, first file information of a target file is obtained, and the target file to be verified is determined based on the first file information.

[0080] The first file information of the target file may include, but is not limited to, configuration information of the target file, directory structure of the target file, file hash values ​​(HASH values) corresponding to each level of directory structure, timestamp information of file modification, etc.

[0081] Optionally, the configuration information may include verification configuration information of the target file, which is used to instruct to verify specific sub-files or directory structure levels in the target file. For example, when releasing an application or model, the developer may mark specific sub-files or directory structure levels in the target file such as the application package or model file. These marks can be regarded as verification configuration information of the target file, and the marked sub-files or directory structure levels need to be pre-verified when the terminal reads and writes.

[0082] This implementation 1-1 is based on the first file information of the target file, and determines from the target file at least the abnormal files, modified and edited files, and / or files marked as untrusted files that have verification requirements, as the target files to be verified.

[0083] Exemplarily, for example, based on the timestamp information of file modification, files in the target file that have been modified and edited since the most recent historical verification are determined as target files to be verified that require verification; based on the marking information contained in the verification configuration information of the target file, specific sub-files or files corresponding to the marked directory structure levels marked by the developer when releasing the target file such as the application or model are determined, and these files are determined as target files to be verified that require verification; and / or, files corresponding to the directory structure levels in which the file hash values ​​corresponding to each level of the directory structure in the target file have changed compared with the reference hash value (such as the benchmark hash value given when the file was released) are determined as target files to be verified that require verification, and so on.

[0084] 1-2. Obtain source information of a target triggering event, and determine the target file to be verified from the target file based on the source information.

[0085] Optionally, the source information of the target trigger event is mainly used to characterize the operation on which the target trigger event is triggered, for example, whether it is triggered based on a trigger action such as file download (such as downloading from an official website or from an off-site website), save, open, install, start, or share.

[0086] In this implementation 1-2, based on the source information of the target triggering event, at least a target file to be verified that has a verification requirement is determined from the target file.

[0087] Specifically, the part of the target file to be verified can be determined based on the trigger action based on the target trigger event represented by the source information of the target trigger event, so as to at least obtain the file in the target file that has verification requirements as the target file to be verified.

[0088] For example, if the source information represents that the target file such as a large model file or an application package is downloaded from the official website, only the signature of the file can be verified. If it is downloaded unofficially, the entire file content needs to be verified; if the source information represents starting or opening a target file such as an application / large model file, only the variable part of the target file needs to be verified; if the source information represents sharing the target file, only the shared part of the target file needs to be verified; if the source information represents saving the target file, the entire target file can be verified or only the updated part of the target file can be verified.

[0089] 1-3. Obtain configuration information of the electronic device, and determine the target file to be verified from the target file based on the configuration information.

[0090] Optionally, the configuration information of the electronic device may include, but is not limited to, a security configuration policy or hardware configuration of the electronic device.

[0091] The security configuration strategy of electronic devices may include but is not limited to:

[0092] a. A strategy for instructing to perform security verification on the entire target file;

[0093] b. A strategy for instructing to perform security verification on the modified variable portion of the target file;

[0094] c. A strategy for indicating that only the signature authentication of the target file is to be verified or specific parts of different files are to be verified.

[0095] The hardware configuration of the electronic device may include but is not limited to the number, model, size, capacity (such as disk capacity), current remaining available resources (such as remaining disk capacity, number of idle processors), etc. of different functions / types of hardware such as the electronic device's processor, storage, memory, cache, graphics card, etc., to indicate whether there are sufficient hardware resources to support the full verification of the target file.

[0096] In the present implementation 1-3, based on the configuration information of the electronic device, at least one file that has a verification requirement is determined from the target file as the target file to be verified.

[0097] Wherein, in the case where the configuration information of the electronic device includes the security configuration policy, the file matching the security configuration policy can be directly determined from the target file as the target file to be verified. For example, for the above-mentioned strategy a, the entire file of the target file is determined as the target file to be verified; for the above-mentioned strategy b, the file where the modified variable part of the target file is located is determined as the target file to be verified; for the above-mentioned strategy c, the signature authentication file of the target file or the specific part of the indicated different files is determined as the target file to be verified.

[0098] In the case where the configuration information of the electronic device includes the hardware configuration of the electronic device, the target file to be verified can be determined based on whether the hardware configuration represents sufficient hardware resources to support the full verification of the target file. If the hardware configuration of the electronic device represents that the electronic device has sufficient hardware resources to support the full verification of the target file, the entire file of the target file can be directly determined as the target file to be verified; conversely, if the hardware configuration of the electronic device represents that the electronic device does not have sufficient hardware resources to support the full verification of the target file, partial files such as abnormal files, modified and edited files, and / or files marked as untrusted can be further determined from the target file as the target file to be verified.

[0099] 1-4. Obtain target reference information, and determine the subfile in the target file that matches the target reference information as the target file to be verified.

[0100] The target reference information is obtained based on big data related to the target file.

[0101] The target reference information may specifically include, but is not limited to, evaluation information on applications, models, databases, etc. on forums, application stores, official websites, model stores, etc., and / or descriptions or prompts of security vulnerability information, etc. The evaluation information may include, but is not limited to, evaluation information on different security dimensions such as file integrity, accuracy, potential security risks / vulnerabilities, and directions that may be tampered with or attacked.

[0102] This implementation 1-4 uses the target reference information as a basis to determine the sub-file in the target file that matches the target reference information as the target file to be verified. Including but not limited to: based on the evaluation information of different security dimensions such as completeness, accuracy, potential security risks / vulnerabilities, and directions that may be tampered with or attacked in big data from various sources, the files that may be missing, have potential security risks, and / or may be tampered with or attacked in the target file are determined as the target file to be verified; or, based on the description / prompt of the security vulnerability information of the target file (such as an application package or a large model file) in the application store, official website, model store, etc., the sub-file indicated by the description / prompt of the security vulnerability information in the target file is determined as the target file to be verified.

[0103] 1-5. Obtain attribute information of a target file, and determine the target file to be verified from the target file based on the attribute information.

[0104] The properties of the target file include but are not limited to the type of the target file. The type of the target file is used to indicate which type of file the target file belongs to, such as a large model file, an application package, a data file, a multimedia file, or a database file.

[0105] Different types of files may have different parts that need to be verified. For example, a large model file may need to verify the model weight file, an application package may need to verify the signature authentication file, and multimedia files or data files may need to perform an integrity check on the entire file, etc.

[0106] Based on this, the present implementation 1-5 takes the attribute of the type of the target file as a basis, and determines from the target file a file that needs to be verified and matches the type of the target file, as the target file to be verified.

[0107] However, it is not limited to this. In practical applications, the target file to be verified can also be determined in combination with the data volume and other attributes of the target file. For example, when the data volume of the target file is small, such as less than the data volume threshold, the entire file of the target file (such as the entire lightweight application package) can be directly determined as the target file to be verified.

[0108] This embodiment determines the target file to be verified from the target file in response to the target trigger event, such as determining abnormal files, modified and edited files and / or files marked as untrusted files from the target file, so that it is convenient to subsequently verify only the determined target file to be verified (rather than indiscriminately verifying the entire target file), further reducing the amount of data for file verification and improving verification efficiency.

[0109] At the same time, by determining the target file to be verified based on the first file information of the target file, the source information of the target trigger event, the configuration information of the electronic device, the target reference information obtained from the big data related to the target file and / or the attribute information of the target file, the target file to be verified can be accurately and effectively mined out as the target file to be verified, thereby reducing the amount of file verification data while ensuring the coverage of the files in the target file that have verification requirements, avoiding missing the verification of files that have verification requirements.

[0110] In an optional embodiment, determining the target file to be verified based on the first file information can be further implemented as including but not limited to at least one of the following implementation modes "2-1" to "2-3".

[0111] 2-1. Obtain configuration variable update information of the target file, and determine a subfile in the target file that matches the configuration variable update information as the target file to be verified.

[0112] The configuration variable update information of the target file may include, but is not limited to, a modification timestamp, an update log, and / or an update position mark of the target file.

[0113] The sub-file in the target file that matches the configuration variable update information may be a file, or it may be a file corresponding to a file directory / sub-directory in the overall file directory structure of the target file. Different configuration variable update information can locate the variable file in the target file with different accuracy, which is also related to the hierarchical structure of the file in the file directory structure of the target file and the mechanism for recording update information, and the specific accuracy may depend on the actual situation.

[0114] This embodiment 2-1 can be further implemented as including but not limited to at least one of the following embodiments "3-1" to "3-4".

[0115] 3-1. When the configuration variable information is a modification timestamp of a target file, a target subfile with a target timestamp in the target file is determined as the target file to be verified, and the target subfile may be unique or non-unique.

[0116] The target timestamp may be, but is not limited to, the latest timestamp of the file, or a normal or illegal modification timestamp of the modified file determined based on version release / update / upgrade time or content modification / tampering, attack time.

[0117] In the case where the configuration variable information is the modification timestamp of the target file, this embodiment specifically determines the target subfile in the target file with the latest timestamp (for example, with a timestamp later than the latest historical verification time as a benchmark) and / or the target subfile with a normal or illegal modification timestamp as the target file to be verified. The target subfile in the target file with such a target timestamp may have file information adjustment (normal adjustment or illegal adjustment) due to various reasons such as version release / update / upgrade or modification / tampering of the file content during use, attack, etc., and therefore needs to be verified to ensure the security of the file during use.

[0118] 3-2. When the configuration variable information is an update log of the target file, a target subfile corresponding to the abnormal update log in the target file is determined as the target file to be verified.

[0119] The update log of the target file includes update records of each file in the target file, such as the update timeline of each file, the file content update position corresponding to each update time node on the update timeline, and the like.

[0120] This embodiment specifically determines the abnormal update log of the target file by matching the update log of the target file with the official update record of the target file, and then determines the target subfile corresponding to the abnormal update log in the target file as the target file to be verified.

[0121] The target sub-file corresponding to the abnormal update log in the target file is a file that has a high probability of being tampered with (illegally modified), attacked, or damaged / missing, so there is a need for verification. This implementation effectively verifies the security of such files by determining the target sub-file corresponding to the abnormal update log in the target file as the target file to be verified, so as to avoid unforeseen problems encountered by users during the use of the files due to tampering, attack, or damage / missing of such files.

[0122] 3-3. When the configuration variable information is an update mark of a target file, a target subfile corresponding to the update mark in the target file is determined as the target file to be verified.

[0123] The update mark of the target file may include, but is not limited to, any one or more of the target file's update location (address, path, etc.) mark, update name mark, update function / service mark, etc. For example, it may specifically include address / path mark information of the corresponding sub-file that is updated in the target file, name mark information of the corresponding sub-file that is updated, or mark information of the function / service provided by the corresponding sub-file that is updated, etc.

[0124] In the case where the configuration variable information is an update mark of the target file, this embodiment locates the target sub-file that has been updated in the target file through the update mark, for example, based on the address / path mark information, the name mark information and / or the mark information of the function or service, the target sub-file that has been updated in the target file is located, and the located target sub-file is determined as the target file to be verified.

[0125] 3-4. Obtain an association relationship between the configuration variable information and the hierarchical structure of the target file, and locate a target subfile from the target file as the target file to be verified based on the association relationship.

[0126] The hierarchical structure of the target file refers to the directory hierarchical structure represented by the file directory of the target file (essentially, the file hierarchical structure of the target file), such as the directory hierarchical structure represented by the file directory of an application package or a large model file.

[0127] The association relationship between the configuration variable information and the hierarchical structure of the target file mainly refers to the level in the hierarchical structure of the target file at which the configuration variable update information is recorded, so as to locate the target sub-file from the target file as the target file to be verified based on the recorded level.

[0128] Optionally, if the configuration variable update information is recorded in the bottom level of the hierarchical structure of the target file, the sub-file corresponding to the recorded bottom level can be directly determined as the target file to be verified; if the configuration variable update information is recorded in the middle level of the hierarchical structure of the target file, the files corresponding to the middle level and each level below it can be determined as the target file to be verified, that is, it is necessary to traverse and verify the files of the middle level and each level below it, and the files of the middle level and each level below it are all target files to be verified that need to be verified.

[0129] In practical applications, it is also possible to determine at which level in the hierarchical structure of the target file the configuration variable update information is recorded and at which node in the level to which it belongs, and based on the recorded level and node, locate the target subfile from the target file as the target file to be verified. The accuracy of the position of the variable file that can be located in the target file by different configuration variable update information is different, which is also related to the hierarchical structure of the file in the file directory structure of the target file and the mechanism for recording update information, which can be determined according to the actual situation.

[0130] Exemplarily, if the configuration variable update information is recorded in a node at the bottom level of the hierarchical structure of the target file, the sub-file corresponding to the node at the bottom level recorded therein can be directly determined as the target file to be verified; if the configuration variable update information is recorded in a node at an intermediate level of the hierarchical structure of the target file, the file corresponding to the sub-directory (i.e., the sub-tree contained therein) corresponding to the node at the intermediate level can be determined as the target file to be verified.

[0131] 2-2. Obtain structural information of the target file and file hash values ​​of each structural level, and determine the target file to be verified from the target file based on the structural information and the file hash values.

[0132] The structural information of the target file refers to the directory hierarchy structure represented by the file directory of the target file, which is essentially the file hierarchy structure of the target file.

[0133] In this embodiment, a hash tree consistent with the directory hierarchy structure is pre-built for the file directory of the target file. Each node in the hash tree at least includes the file hash value of the directory node corresponding to the node in the file directory structure of the target file.

[0134] Among them, the hash value stored in each leaf node in the hash tree is the hash value of each individual file in the target file or the file block obtained by block processing of an individual file. It is easy to understand that, corresponding to the directory hierarchy structure of the target file, the hash value in the leaf node refers to the hash value of the bottom-level file in the directory hierarchy structure of the target file or the hash value of the file block obtained after block processing of the bottom-level file.

[0135] The hash value stored in the non-leaf node in the hash tree is the hash value obtained by performing a hash operation on the hash values ​​stored in each child node of the non-leaf node. Corresponding to the directory hierarchy structure of the target file, the hash value in the non-leaf node can be understood as the overall hash value corresponding to each file / file block under the corresponding intermediate-level directory node corresponding to the non-leaf node in the directory hierarchy structure of the target file.

[0136] See also Figure 2, shows an example of a hash tree, in which L1, L2, L3, and L4 represent the files or file blocks at the bottom of the directory hierarchy of the target file. The hash values ​​in each leaf node, such as hash0-0, hash0-1, hash1-0, and hash1-1, are specifically the hash values ​​obtained by performing a hash operation on the corresponding files or file blocks. Taking the leaf node hash0-0 as an example, the hash value in this node is specifically the hash value hash(L1) obtained by performing a hash operation on the corresponding file or file block L1, and the same is true for other leaf nodes. The hash value in a non-leaf node is the hash value obtained by performing a hash operation on the hash values ​​of its child nodes. For example, the hash value in a non-leaf node hash0 is the result of performing a hash operation on the hash values ​​hash(L1) and hash(L2) of its two child nodes hash0-0 and hash0-1, and then further performing a hash operation on the sum value, specifically expressed as hash(hash0-0+hash0-1), and the same is true for other non-leaf nodes.

[0137] In actual applications, when the target file is generated, modified (such as generated or modified by the developer), released or version upgraded, the hash values ​​corresponding to each file in the target file or the changed file and its parent directory can be calculated in real time to generate a hash tree corresponding to the latest target file, and store it in the cache file as a reference hash tree, which is released or updated synchronously with the release, version upgrade, etc. of the target file such as the application package or large model file.

[0138] On this basis, in response to a target trigger event, such as downloading an application package or a large model file, the hash value of each file in the directory hierarchy structure of the target file can be calculated based on the directory hierarchy structure of the target file to obtain a current hash tree generated in real time, and the hash value of the file at each structural level in the generated current hash tree is compared node by node with the hash value of the file at each level in the reference hash tree saved in the cache file of the target file. The hash value comparison process is used to determine which level and which node in the current hash tree has a hash value different from the reference hash value of the corresponding node, and then the files corresponding to the corresponding nodes with different hash values ​​in the hash tree or the files contained in the corresponding directory nodes are determined as abnormal files that need to be verified, that is, determined as the target files to be verified.

[0139] Optionally, when performing the hash value comparison process, the current hash tree and the reference hash tree can be checked starting from the root directory / root node and proceeding to the next level in the directory structure hierarchy / hash tree hierarchy. If the hash values ​​of the corresponding intermediate nodes are consistent, the comparison of the subtree of the intermediate node can be skipped to achieve rapid detection and location of files with tampering / missing problems.

[0140] 2-3. Obtain verification configuration information of the target file, and determine the sub-file or structure level in the target file corresponding to the verification configuration information as the target file to be verified.

[0141] The verification configuration information of the target file is used to instruct to verify specific sub-files or directory structure levels in the target file. For example, when releasing an application or model, the developer can mark specific sub-files or directory structure levels in the target file such as the application package or model file. These marks can be regarded as the verification configuration information of the target file. The marked sub-files or directory structure levels need to be pre-verified when the terminal reads and writes.

[0142] This implementation method uses the verification configuration information of the target file as a basis, and determines the subfiles in the target file corresponding to the verification configuration information or the subfiles contained in the structure level corresponding to the verification configuration information as the target file to be verified. For example, based on the marking information contained in the verification configuration information of the target file, the specific subfiles or the files corresponding to the marked directory structure level marked by the developer when publishing the target file of the application or model are determined, and these files are determined as the target files to be verified that have verification requirements.

[0143] This embodiment determines the target file to be verified from the target file based on the first file information of the target file in response to the target trigger event, which can facilitate subsequent targeted verification of only the determined target file to be verified (rather than indiscriminately verifying the entire target file), further reducing the amount of data for file verification and improving verification efficiency.

[0144] At the same time, by using the first file information of the target file (such as the configuration variable update information of the target file, the structure information of the target file and the file hash values ​​of each structure level 、 The target files to be verified are determined based on the verification configuration information of the target file, which can accurately and effectively mine the target files to be verified that truly meet the verification requirements in the target file, thereby reducing the amount of file verification data while ensuring the coverage of the files in the target file that meet the verification requirements, and avoiding missing the verification of files that meet the verification requirements.

[0145] In an alternative embodiment, see Figure 3 As shown in the safety verification flow chart, step 102 in the method provided by the present application can be implemented as follows:

[0146] Step 301: Obtain second file information of the target file to be verified.

[0147] The second file information of the target file to be verified may include, but is not limited to, at least one of data volume information, quantity information, type information, and position information of the target file to be verified in the target file.

[0148] The location information is used to represent the level or subdirectory of the target file to be verified in the directory structure of the target file.

[0149] Step 302: When the second file information satisfies a corresponding verification condition, use multiple threads running on multiple cores of at least one processor to perform integrity verification and / or accuracy verification on the target file to be verified in parallel.

[0150] The verification condition is a judgment condition for whether a multi-threaded parallel verification is required, which is also the target condition described above.

[0151] Exemplarily, the verification condition may be, but is not limited to, set to at least one of the following:

[0152] a. The data volume of the target file to be verified reaches the data volume threshold;

[0153] b. There are multiple target files to be verified (such as reaching the number threshold), and each target file to be verified is in the same or different levels of directory structure;

[0154] c. There are multiple target files to be verified (eg, reaching a quantity threshold), and the types of the target files to be verified are different and / or the corresponding verification methods are different.

[0155] In this embodiment, when the second file information meets the corresponding verification conditions, multiple threads running on multiple cores of at least one processor are used to perform integrity verification and / or accuracy verification on the target file to be verified in parallel, so as to improve the verification efficiency of the target file to be verified based on a multi-threaded parallel approach.

[0156] The multiple cores may specifically be multiple cores of a multi-core processor, or multiple cores of multiple single-core processors, or multiple cores of a single-core and multi-core processor, or multiple cores of a multi-core and multi-core processor. There is no limitation to this and it can be determined according to the actual application situation.

[0157] The integrity check performed on the target file to be checked may be, but is not limited to, a HASH check based on a file hash value, and / or a vector similarity check based on vector similarity calculation of the file, and the like.

[0158] Specifically, the HASH verification of the target file to be verified can be achieved by comparing the current hash value of the target file to be verified calculated in real time with the reference hash value of the target file to be verified. The reference hash value can be the hash value corresponding to the target file to be verified in the reference hash tree saved in the cache file.

[0159] Similarly, the vector similarity check of the target file to be checked can be realized by performing vector similarity calculation on the current document vector of the target file to be checked calculated in real time and the reference document vector of the target file to be checked. The reference document vector can be the document vector of the target file to be checked that is synchronously provided when the official releases or upgrades the target file such as the application package or the large model file. The reference document vector can also be saved in the cache file.

[0160] The accuracy verification of the target file to be verified may include, but is not limited to, the accuracy verification of the signature data, file data, identity data and / or permission data of the target file to be verified, which may be determined according to actual application requirements.

[0161] This embodiment obtains the second file information of the target file to be verified, and when the second file information meets the verification conditions, uses multiple threads running on multiple cores of at least one processor to perform integrity verification and / or accuracy verification on the target file to be verified in parallel, thereby effectively improving the file verification efficiency and achieving efficient and rapid completion of the verification of the target file.

[0162] In an optional embodiment, in step 102 of the method provided in the present application, the target file to be verified is security verified in parallel using multiple threads, which can be implemented as at least one of the following implementation modes "4-1" to "4-3".

[0163] 4-1. When the data amount of the target file to be verified is greater than a first threshold, the target file to be verified is divided into blocks to obtain multiple file blocks, so as to perform integrity verification and / or accuracy verification on the multiple file blocks in parallel using multiple threads running on multiple cores of at least one processor.

[0164] Specifically, in this implementation, when the data volume of the target file to be verified is relatively large, that is, larger than the first threshold, the target file to be verified is processed into blocks.

[0165] Optionally, if the target file to be verified is an independent file or the lowest file in the directory hierarchy structure of the target file, the target file to be verified can be split into multiple file blocks based on, but not limited to, block strategies such as random splitting, splitting according to storage location order, or splitting according to specific strings / separators.

[0166] If the target file to be verified is a non-independent multi-level structure file including sub-directories, the target file to be verified can be split based on the hierarchical structure relationship of the target file to be verified, or the target file to be verified can be split according to the data type (such as text, table, image, voice, code, etc.) in the target file to be verified, or the target file to be verified can be split according to the importance / functional priority of the data in the target file to be verified or the possibility of being attacked, etc., so as to obtain multiple file blocks of the target file to be verified.

[0167] After obtaining multiple file blocks of the target file to be verified, multiple threads running on multiple cores of at least one processor may be further used to perform integrity verification and / or accuracy verification on the multiple file blocks in parallel.

[0168] For example, using multiple threads running on multiple cores of at least one processor, integrity checks such as HASH checks or vector similarity checks are performed on the multiple file blocks in parallel, and / or accuracy checks are performed on signature data, file data, identity data and / or permission data of the multiple file blocks in parallel.

[0169] 4-2. When there are multiple target files to be verified, use multiple threads running on multiple cores of at least one processor to perform integrity verification and / or accuracy verification on the multiple files to be verified in parallel.

[0170] Among them, when there are multiple target files to be verified, the multiple target files to be verified can be in the same directory level in the directory hierarchy structure of the target file, or can be in different directory levels, and the data amount of each target file to be verified can be greater than the first threshold or less than the first threshold, depending on the actual situation.

[0171] Specifically, when there are multiple target files to be verified and the data volume is no more than a first threshold, multiple threads running on multiple cores of at least one processor can be called to perform integrity checks and / or accuracy checks on the multiple files to be verified in parallel based on the type of each target file to be verified and / or the structural level at which they are located.

[0172] When there are multiple target files to be checked and the data amount of the first file to be checked is greater than a first threshold, the first file to be checked can be processed in blocks, and integrity and / or accuracy checks can be performed in parallel on each file block of the first file to be checked and other files to be checked using multiple threads running on multiple cores of at least one processor.

[0173] 4-3. When the types of the target files to be verified are different and / or the structural levels of the target files are the same or different, the integrity and / or accuracy of the multiple target files to be verified are checked in parallel using multiple threads running on multiple cores of at least one processor.

[0174] This embodiment is still aimed at the case where there are multiple target files to be verified. If the types of the multiple target files to be verified are different, different threads can be used to perform verification respectively. For example, different types of files such as video files, document files, database files, web pages or address files can be processed respectively using different threads. Therefore, for the case where the types of the multiple target files to be verified are different, multiple threads running on multiple cores of at least one processor can be used to perform integrity verification and / or accuracy verification on the multiple target files to be verified in parallel. Among them, each thread corresponds to the file verification for the same file type.

[0175] The directory levels at which multiple target files to be verified are the same or different means that the multiple target files to be verified are respectively located at the same directory level in the directory hierarchy structure of the target file, or are respectively located at different directory levels in the directory hierarchy structure of the target file (for example, all are at the third level, or some target files to be verified are at the third level, some target files to be verified are at the fourth level, some target files to be verified are at the fifth level, etc.).

[0176] Among them, if multiple target files to be verified are at the same directory level in the directory hierarchy structure of the target files, multiple threads running on multiple cores of at least one processor can be used to perform integrity checks and / or accuracy checks in parallel on the file blocks of multiple target files to be verified or target files to be verified whose data volume is greater than a first threshold.

[0177] If multiple target files to be verified are not in the same directory level in the directory hierarchy of the target files, the target files to be verified can be divided based on the hierarchical structure relationship of each target file to be verified, and multiple threads running on multiple cores of at least one processor can be used to perform integrity checks and / or accuracy checks on each sub-file or file block finally obtained by dividing the multiple target files to be verified in parallel.

[0178] This embodiment performs integrity verification and / or accuracy verification on the target file to be verified in parallel based on the data volume, number, type or structural level of the target file to be verified, using multiple threads running on multiple cores of at least one processor. This can realize parallel verification processing on the target file to be verified that matches its data volume, number, type or structural level of the target file, accelerates the verification process of the target file to be verified in different situations, effectively improves the file verification efficiency, and can quickly and efficiently complete the verification of the target file.

[0179] In an optional implementation, the target file to be verified is divided into blocks to obtain multiple file blocks, which can be implemented as at least one of the following "5-1" to "5-4".

[0180] 5-1. When the target file to be verified is an independent file in the target file, split the target file to be verified into multiple file blocks based on the data volume and / or specific character content of the target file to be verified.

[0181] The target file to be verified is an independent file in the target file, which may mean that the target file to be verified is a file located at the bottom of the directory hierarchy structure of the target file, or the target file to be verified is a file in the target file without a subdirectory hierarchy.

[0182] In the case where the target file to be verified is an independent file in the target file, in an optional implementation, the target file to be verified may be split based on the data volume of the target file to be verified, thereby obtaining multiple file blocks of the target file to be verified. Optionally, based on a predetermined data block size, the target file to be verified may be equally divided into multiple file blocks of the data block size (the data volume of the last file block is less than or equal to the predetermined data block size, depending on the actual situation).

[0183] However, it is not limited thereto. In other implementations, the target file to be verified may be divided into blocks based on separators, specific characters or sequence marks in the target file to be verified, so as to split the target file to be verified into multiple file blocks.

[0184] 5-2. When the target file to be verified includes a file structure hierarchy, the target file to be verified is split into a plurality of file blocks based on the file structure hierarchy relationship of the target file to be verified.

[0185] In the case where the target file to be verified includes a file structure hierarchy, the target file to be verified may be split based on the file structure hierarchy relationship of the target file to be verified, such as the tree hierarchy relationship corresponding to the target file to be verified in the directory hierarchy structure.

[0186] Exemplarily, the target file to be verified may be split into a corresponding number of multiple file blocks according to the number of forks contained in the directory node where the target file to be verified is located, represented by the tree-like hierarchical relationship corresponding to the target file to be verified in the directory hierarchy structure of the target file.

[0187] 5-3. Obtain the data type in the target file to be verified, and split the target file to be verified into multiple file blocks based on the data type.

[0188] The data types in the target file to be verified may include but are not limited to text, tables, images, voice, code, etc. When the target file to be verified includes different types of data such as text, tables, images, voice, code, etc., the target file to be verified may be split based on the data type to obtain multiple file blocks of the target file to be verified, and different file blocks correspond to different data types.

[0189] Optionally, when the target file to be verified is a single independent file in the target file, the target file to be verified can be directly split into multiple file blocks based on different data types of the data in the target file to be verified. When the target file to be verified includes a file structure hierarchy in the target file, the target file to be verified can be first split based on the file structure hierarchy relationship of the target file to be verified, and on this basis, for the target sub-files / target file blocks that include different types of data such as text, video, etc. in each of the split sub-files / file blocks, the target sub-files / target file blocks can be further split based on the data type.

[0190] 5-4. Obtain functional service information corresponding to the target file to be verified and / or the attack probability of each part of the target file to be verified, and split the target file to be verified into multiple file blocks based on the functional service information and / or the attack probability.

[0191] In this embodiment, the target file to be verified can be split into multiple file blocks by specifically splitting the target file to be verified based on the functional priority levels of different functional service information corresponding to the target file to be verified, and / or the probability of each part of the target file to be verified being attacked.

[0192] The function priority levels / attack probabilities corresponding to the data in the same file block are the same or meet a first proximity condition. The first proximity condition may be that the difference between the function priority levels of different functions is less than a threshold, or the difference between the attack probabilities of different data is less than a threshold.

[0193] In addition, optionally, the target file to be verified may be split into multiple file blocks according to different importance levels of different data in the target file to be verified.

[0194] The importance levels of the data in the same file block are the same or meet a second proximity condition, and the second proximity condition may be that the difference between the importance levels of different data is less than a threshold.

[0195] This embodiment splits the target file to be verified into multiple file blocks based on the corresponding splitting strategy, which can facilitate the subsequent multi-threaded parallel verification processing on the target file to be verified, thereby providing a basis for accelerating the file verification process and improving the file verification probability based on multi-threaded parallel verification processing.

[0196] In an optional embodiment, multiple threads are used in parallel to perform security verification on the target file to be verified, which can be specifically implemented as follows:

[0197] Multiple threads running on multiple cores of at least one processor are used to perform hash processing on multiple target files to be verified or multiple file blocks in parallel to obtain current hash values ​​of each file to be verified or file block, and the current hash values ​​are compared with target reference hash values ​​to obtain verification results of the target files to be verified.

[0198] Wherein, when the data volume of each target file to be verified is not greater than the first threshold, it is not necessary to process each file to be verified in blocks. In this case, multiple threads running on multiple cores of at least one processor can be used to perform hash processing on multiple files to be verified in parallel to obtain the current hash value of each file to be verified.

[0199] In the case that there is a first file to be verified whose data volume is greater than the first threshold value among the target files to be verified, the first file to be verified may be split into multiple file blocks based on any one of the data volume of the first file to be verified, the data type contained, the corresponding functional service information, the probability of each part being attacked, etc. And multiple threads running on multiple cores of at least one processor are used to perform hash processing on the multiple file blocks and other unsplit target files to be verified in parallel to obtain the current hash values ​​corresponding to the multiple file blocks and other unsplit target files to be verified.

[0200] If the data volume of each target file to be verified is greater than the first threshold, each target file to be verified may be processed in blocks, and multiple threads running on multiple cores of at least one processor may be used to perform hash processing on the file blocks of each target file to be verified in parallel to obtain the current hash values ​​corresponding to the file blocks of each target file to be verified.

[0201] The target reference hash value may be a corresponding hash value in a reference hash tree stored in a cache file corresponding to the target file.

[0202] After obtaining the current hash value of the target file or file block to be verified, the node corresponding to the target file or file block to be verified in the reference hash tree can be determined, and the node value can be read from the corresponding node as the target reference hash value, and then the verification result of the target file or file block to be verified can be obtained by comparing the current hash value with the target reference hash value. Among them, if the current hash value of the target file / file block to be verified is the same as the corresponding target reference hash value, it indicates that the target file / file block to be verified has passed the verification, that is, it indicates that the target file / file block to be verified is safe; on the contrary, if the current hash value of the target file / file block to be verified is different from the corresponding target reference hash value, it indicates that the target file / file block to be verified has not passed the verification, that is, it indicates that the target file / file block to be verified is not safe, and there may be problems such as tampering or data missing.

[0203] See also Figure 4 , a schematic diagram is provided for processing a target file to be verified by dividing it into blocks, and performing parallel HASH verification on each file block obtained by dividing it into blocks based on multiple threads, wherein Chunk1...Chunk4 represents each file block obtained after dividing the target file to be verified File into blocks (Split), Thread1...Thread4 represents multiple threads running on multiple cores of at least one processor, Hash1-Hash4 represents current hash values ​​obtained by performing hash operations on file blocks Chunk1...Chunk4 respectively, and Check represents performing HASH verification on the file block based on the calculated current block hash value and the corresponding target reference hash value.

[0204] Optionally, during the hash value comparison process, if the hash values ​​of the corresponding intermediate nodes are consistent, the comparison of the subtree of the intermediate node can be skipped to achieve rapid detection and location of files that have been tampered with / missing, etc.

[0205] Optionally, the target trigger event may also be generated from at least one of the following: in response to an operation that changes the running state of a target application of an electronic device, wherein the target application is an application that includes a large model file or can call a large model file; in response to an operation that changes the read / write state of a target large model file in an electronic device; in response to an event that detects that the electronic device has been attacked.

[0206] The operation of changing the running state of the target application of the electronic device may include, but is not limited to, operations such as installing, loading, starting, pausing, activating, and suspending the target application.

[0207] The operation of changing the read-write status of the target large model file in the electronic device may include, but is not limited to, downloading, saving, opening, installing, starting, sharing, and the like operations of the target large model file.

[0208] Incidents of electronic device attacks may include, but are not limited to, password intrusion, Trojan horse intrusion, phishing attacks, node attacks, network monitoring, security vulnerability exploitation, port scanning, etc.

[0209] This embodiment uses multiple threads to perform hash-based security verification on the target file to be verified in parallel, which can accelerate the file verification process and improve the file verification efficiency based on multi-threaded parallel processing, while quickly and efficiently determining the files in the target file that have been tampered with or have data missing problems based on the hash verification method.

[0210] In addition, this embodiment designs the target trigger event accordingly to support the target trigger event generated in response to an operation of changing the running state of the target application of the electronic device, in response to an operation of changing the read / write state of the target large model file in the electronic device, or in response to detecting an event that the electronic device is attacked. In the event of an operation of changing the running state of the target application of the electronic device, in response to an operation of changing the read / write state of the target large model file in the electronic device, or an event that the electronic device is attacked, the verification method provided by the present application can be executed to effectively perform security verification on target files such as target applications or target large model files, so as to quickly locate abnormal files or attacked files in target files such as target applications or target large model files, thereby avoiding unforeseen problems encountered by users during the use of files.

[0211] The present application also provides an electronic device, see Figure 5 As shown in the composition structure diagram, the electronic device includes a processor 10 and at least one large model file that can run on the processor. The large model file can be stored in the memory 20 of the electronic device. When the large model file is called by the target application, the read-write state of the large model file changes, and the processor can execute the verification method provided in any embodiment of the text.

[0212] The changes in the read-write status of the large model file may include, but are not limited to, changes in the read-write status of the large model file caused by operations such as saving, opening, installing, starting, and sharing the large model file.

[0213] Among them, the processor can be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a neural network processor (NPU), a deep learning processor (DPU) or other programmable logic devices, etc.

[0214] Optionally, the electronic device may also include storage resources such as memory and cache.

[0215] Optionally, the electronic device may further include a camera assembly, and / or be connected to an external camera assembly.

[0216] In addition, the electronic device may also include components such as a communication interface and a communication bus. The memory, processor, and communication interface communicate with each other through the communication bus.

[0217] The communication interface is used for communication between electronic devices and other devices. The communication bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc.

[0218] An embodiment of the present application further discloses a storage medium, which carries one or more computer instruction sets. When the one or more computer instruction sets are executed by an electronic device, the electronic device can implement the verification method as described in any one of the above items.

[0219] It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0220] For the convenience of description, the above system or device is described by dividing it into various modules or units according to its functions. Of course, when implementing the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0221] It can be known from the description of the above implementation methods that those skilled in the art can clearly understand that the present application can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solution of the present application can be essentially or the part that makes a creative contribution can be embodied in the form of a software product, which can be stored in a storage medium such as ROM / RAM, a disk, an optical disk, etc., including several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present application or some parts of the embodiments.

[0222] Finally, it should be noted that, in this article, relational terms such as first, second, third and fourth are used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the statement "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0223] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A verification method, comprising: In response to a target triggering event, determining a target file to be verified; When the target file to be verified meets the target condition, a security check is performed on the target file to be verified in parallel using multiple threads; The target file to be verified is at least a part of the target file, and the target file is a file that can change its read / write state in response to the target trigger event.

2. The method according to claim 1, wherein determining the target file to be verified in response to the target triggering event comprises at least one of the following: In response to a target triggering event, obtaining first file information of a target file, and determining the target file to be verified based on the first file information; Obtaining source information of the target triggering event, and determining the target file to be verified from the target file based on the source information; Obtaining configuration information of the electronic device, and determining the target file to be verified from the target file based on the configuration information; Obtaining target reference information, and determining a subfile in the target file that matches the target reference information as the target file to be verified, wherein the target reference information is obtained based on big data related to the target file; The attribute information of the target file is obtained, and the target file to be verified is determined from the target file based on the attribute information.

3. The method according to claim 2, wherein: Determining the target file to be verified based on the first file information includes one of the following: Obtaining configuration variable update information of the target file, and determining a subfile in the target file that matches the configuration variable update information as the target file to be verified; Obtaining structural information of the target file and file hash values ​​of each structural level, and determining the target file to be verified from the target file based on the structural information and the file hash values; Verification configuration information of the target file is obtained, and a subfile or a structural level in the target file corresponding to the verification configuration information is determined as the target file to be verified.

4. The method according to claim 3, wherein: Determining a subfile in the target file that matches the configuration variable update information as the target file to be verified includes at least one of the following: In a case where the configuration variable information is a modification timestamp of the target file, determining a target subfile having a target timestamp in the target file as the target file to be verified, the target subfile being unique or non-unique; In a case where the configuration variable information is an update log of the target file, determining a target subfile in the target file corresponding to the abnormal update log as the target file to be verified; In a case where the configuration variable information is an update mark of the target file, determining a target subfile in the target file corresponding to the update mark as the target file to be verified; The association relationship between the configuration variable information and the hierarchical structure of the target file is obtained, and based on the association relationship, a target subfile is located from the target file as the target file to be verified.

5. The method according to any one of claims 1 to 4, wherein: When the target file to be verified meets the target condition, a security check is performed on the target file to be verified in parallel using multiple threads, including: Obtaining second file information of the target file to be verified, wherein the second file information includes at least one of data volume information, quantity information, type information, and position information of the target file to be verified in the target file; In the case where the second file information meets the corresponding verification condition, the target file to be verified is verified in parallel using multiple threads running on multiple cores of at least one processor.

6. The method according to claim 5, wherein: Using multiple threads to perform security verification on the target file to be verified in parallel includes at least one of the following: When the data amount of the target file to be verified is greater than a first threshold, the target file to be verified is divided into blocks to obtain a plurality of file blocks, so as to perform integrity verification and / or accuracy verification on the plurality of file blocks in parallel by using a plurality of threads running on a plurality of cores of at least one processor; In the case where there are multiple target files to be verified, multiple threads running on multiple cores of at least one processor are used to perform integrity verification and / or accuracy verification on the multiple target files to be verified in parallel; When the types of the target files to be verified are different and / or the structural levels of the target files are the same or different, the integrity and / or accuracy of the multiple target files to be verified are checked in parallel using multiple threads running on multiple cores of at least one processor.

7. The method according to claim 6, wherein: The target file to be verified is divided into blocks to obtain multiple file blocks, including at least one of the following: In the case where the target file to be verified is an independent file in the target file, splitting the target file to be verified into a plurality of file blocks based on the data volume and / or specific character content of the target file to be verified; In the case where the target file to be verified includes a file structure hierarchy, splitting the target file to be verified into a plurality of file blocks based on the file structure hierarchy relationship of the target file to be verified; Obtaining a data type in the target file to be verified, and splitting the target file to be verified into multiple file blocks based on the data type; The function service information corresponding to the target file to be verified and / or the attack probability of each part of the target file to be verified is obtained, and the target file to be verified is split into multiple file blocks based on the function service information and / or the attack probability.

8. The method according to claim 6, wherein when there are multiple target files to be verified, performing integrity verification and / or accuracy verification on multiple target files to be verified in parallel using multiple threads running on multiple cores of at least one processor, comprises at least one of the following: In the case where there are multiple target files to be verified and the data amounts of all the files are not greater than the first threshold, calling multiple threads running on multiple cores of at least one processor to perform integrity verification and / or accuracy verification on the multiple target files to be verified in parallel based on the type and / or structural level of each target file to be verified; When there are multiple target files to be checked and the data amount of the first file to be checked is greater than a first threshold, the first file to be checked is processed in blocks, and integrity and / or accuracy checks are performed in parallel on each file block of the first file to be checked and other target files to be checked using multiple threads running on multiple cores of at least one processor.

9. The method according to claim 1, wherein: Using multiple threads to perform security verification on the target file to be verified in parallel, including: Using multiple threads running on multiple cores of at least one processor to perform hash processing on multiple target files to be verified or multiple file blocks in parallel, obtaining a current hash value of each target file to be verified or file block, and comparing the current hash value with a target reference hash value to obtain a verification result of the target file to be verified; and / or, The target trigger event is generated by at least one of the following: In response to an operation of changing a running state of a target application of the electronic device, the target application is an application including a large model file or capable of calling a large model file; In response to an operation of changing the read-write state of the target large model file in the electronic device; In response to detecting an event that the electronic device is attacked.

10. An electronic device, comprising a processor and at least one large model file capable of running on the processor, wherein when the large model file is called by a target application, the read / write state of the large model file changes, and the processor is capable of performing at least one of the following: Determine a target file to be verified, where the target file to be verified belongs to at least a part of the large model file or the target application; When the target file to be verified meets the target condition, a security check is performed on the target file to be verified in parallel using multiple threads.

Images