Verification method and device and electronic equipment

Abstract

The invention provides a verification method which is applied to first electronic equipment and comprises the steps that a target list is obtained, the target list records at least one piece of component information of at least one component, the component information at least comprises a first identifier corresponding to the component, the first identifiers corresponding to different components are different, and the target list is generated by second electronic equipment; the second electronic equipment is different from the first electronic equipment; generating a second identifier corresponding to each component based on a generation mode of generating the first identifier by the second electronic equipment; and in response to the difference between the first identifier and the second identifier, alarm information is generated, and the alarm information represents that a target list generated by the second electronic equipment is abnormal.

Description

Technical Field

[0001] This disclosure relates to the field of information security, and more specifically, to a verification method, apparatus, and electronic device. Background Technology

[0002] As electronic devices become increasingly complex, their internal software systems, such as firmware or operating systems, are typically composed of numerous different software components. In the modern software supply chain, these components may originate from different vendors. To manage these components and ensure traceability of their origin and version, software vendors typically provide a software inventory (e.g., a Software Bill of Materials, SBOM) that details the name, version, and a unique identifier (e.g., a hash value) of each component included in the delivered software package. Device manufacturers or other downstream users then integrate or deploy the software based on this inventory upon receiving it.

[0003] However, in current practice, the software manifest is separate from the actual delivered software package (containing entity files for each component). This means the manifest itself is merely a declaration, and its accuracy depends on the vendor's procedural compliance and the security of the transmission process. The recipient lacks an effective automated mechanism to verify that each received component entity fully matches its declaration in the manifest. Summary of the Invention

[0004] In view of this, the present disclosure provides a verification method, apparatus and electronic device.

[0005] One aspect of this disclosure provides a verification method applied to a first electronic device, comprising: obtaining a target list, the target list recording at least one component information of at least one component, the component information including at least a first identifier corresponding to the component, the first identifiers corresponding to different components being different, the target list being generated by a second electronic device, the second electronic device being different from the first electronic device; generating a second identifier corresponding to each component based on the generation method of the first identifier generated by the second electronic device; and generating an alarm message in response to the difference between the first identifier and the second identifier, the alarm message indicating that there is an anomaly in the target list generated by the second electronic device.

[0006] According to embodiments of this disclosure, generating a second identifier corresponding to each component includes: generating a second identifier based on the binary information of the component using a feature extraction algorithm, wherein the feature extraction algorithm is used to confirm the uniqueness of the binary information, and the second identifiers corresponding to different components are different.

[0007] According to embodiments of this disclosure, generating a second identifier using a feature extraction algorithm includes: generating a second identifier based on a feature extraction algorithm that calculates a deterministic summary result; or generating a second identifier based on a feature extraction algorithm that calculates the distribution of data features.

[0008] According to embodiments of this disclosure, the verification method further includes: in response to the difference between the second identifier and the third identifier, determining the target component, wherein the third identifier is generated according to the historical version of the component; obtaining an update list, wherein the update list is generated by the second electronic device in response to the update of the component; and in response to the absence of the target component in the update list, generating alarm information, wherein the alarm information indicates that there is an anomaly in the component information corresponding to the target component in the target list.

[0009] According to embodiments of this disclosure, the component information further includes first functional information corresponding to the component, and the verification method further includes: obtaining a first log file corresponding to the component, the first log file being used to record at least one of the compilation environment, toolchain, dependencies, or file paths of the component, the first log file being generated by a second electronic device; determining second functional information corresponding to the component based on at least one of the compilation environment, toolchain, dependencies, or file paths; and generating alarm information in response to a difference between the first functional information and the second functional information, the alarm information indicating that the first functional information of the component recorded in the target list is abnormal.

[0010] According to embodiments of this disclosure, the verification method further includes: reverse compiling the component to generate reverse information, the reverse information including at least one of character information, code snippets, address information, or dependencies associated with the component; determining at least some attribute information of the component based on at least one of the character information, code snippets, address information, or dependencies and a preset information database, the attribute information including at least some of the compilation environment, toolchain, dependencies, or file paths corresponding to the component; and generating alarm information in response to a difference between the attribute information and a first log file exceeding a first difference threshold, the alarm information indicating a conflict between the first log file and the target list.

[0011] According to embodiments of this disclosure, the verification method further includes: obtaining component code corresponding to the component; generating a target list based on the component code; compiling the component code to generate a second log file corresponding to the component code; and generating an alarm message in response to a difference between the first log file and the second log file exceeding a second difference threshold, wherein the alarm message indicates a conflict between the component code and the target list.

[0012] According to embodiments of this disclosure, the verification method further includes: updating the target list in response to alarm information generation to indicate the location and content of the anomaly in the target list.

[0013] Another aspect of this disclosure provides a verification device, comprising: a first acquisition module for acquiring a target list, the target list recording information of at least one component constituting at least one component, the component information including at least a first identifier corresponding to the component, the first identifiers corresponding to different components being different, the target list being generated by a second electronic device, the second electronic device being different from the first electronic device; a first generation module for generating a second identifier corresponding to each component based on the generation method of the first identifier generated by the second electronic device; and a first alarm module for generating alarm information in response to the difference between the first identifier and the second identifier, the alarm information indicating that there is an anomaly in the target list generated by the second electronic device.

[0014] Another aspect of this disclosure provides a first electronic device, including: at least one processor; and a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform at least one of the following operations: acquiring a target list, the target list recording at least one component information of at least one component, the component information including at least a first identifier corresponding to the component, the first identifiers corresponding to different components being different, the target list being generated by a second electronic device, the second electronic device being different from the first electronic device; generating a second identifier corresponding to each component based on the generation method of the first identifier generated by the second electronic device; and generating an alarm message in response to the difference between the first identifier and the second identifier, the alarm message indicating that there is an anomaly in the target list generated by the second electronic device.

[0015] Another aspect of this disclosure provides a computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform a verification method according to any of the foregoing embodiments.

[0016] Another aspect of this disclosure provides a computer program product, including a computer program / instructions, characterized in that the computer program / instructions, when executed by a processor, implement the operation of the verification method of any of the foregoing embodiments. Attached Figure Description

[0017] The above and other objects, features and advantages of this disclosure will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0018] Figure 1 A flowchart illustrating a verification method according to an embodiment of the present disclosure is shown schematically.

[0019] Figure 2 Another flowchart of a verification method according to an embodiment of the present disclosure is illustrated schematically;

[0020] Figure 3Another flowchart of a verification method according to an embodiment of the present disclosure is illustrated schematically;

[0021] Figure 4 Another flowchart of a verification method according to an embodiment of the present disclosure is illustrated schematically;

[0022] Figure 5 Another flowchart of a verification method according to an embodiment of the present disclosure is illustrated schematically;

[0023] Figure 6 Another flowchart of a verification method according to an embodiment of the present disclosure is illustrated schematically;

[0024] Figure 7 Another flowchart of a verification method according to an embodiment of the present disclosure is illustrated schematically;

[0025] Figure 8 Another flowchart of a verification method according to an embodiment of the present disclosure is illustrated schematically;

[0026] Figure 9 A block diagram of a verification apparatus according to an embodiment of the present disclosure is schematically shown; and

[0027] Figure 10 A block diagram of an electronic device suitable for implementing the methods described above, according to embodiments of the present disclosure, is illustrated schematically. Detailed Implementation

[0028] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0029] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0030] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0031] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0032] In the embodiments disclosed herein, the collection, updating, analysis, processing, use, transmission, provision, disclosure, and storage of data (e.g., including but not limited to user personal information) comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. In particular, necessary measures have been taken to prevent unauthorized access to user personal information data and to safeguard user personal information security, network security, and national security.

[0033] The embodiments of this disclosure provide a verification method applied to a first electronic device, comprising: obtaining a target list, the target list recording at least one component information of at least one component, the component information including at least a first identifier corresponding to the component, the first identifiers corresponding to different components being different, the target list being generated by a second electronic device, the second electronic device being different from the first electronic device; generating a second identifier corresponding to each component based on the generation method of the first identifier generated by the second electronic device; and generating alarm information in response to the difference between the first identifier and the second identifier, the alarm information indicating that there is an anomaly in the target list generated by the second electronic device.

[0034] Figure 1 A flowchart illustrating a verification method according to an embodiment of the present disclosure is shown schematically.

[0035] like Figure 1 As shown, the verification method may include at least operations S110 to S130.

[0036] In operation S110, a target list is obtained. The target list records at least one component information of at least one component. The component information includes at least the first identifier corresponding to the component. Different components have different first identifiers. The target list is generated by a second electronic device, which is different from the first electronic device.

[0037] The first electronic device can be a verification server used to execute the verification process; the second electronic device can be a development device, such as a code compilation or management server used by the original design manufacturer. The target inventory is a structured data file, such as a software bill of materials, that records all components and their attributes constituting a specific version of the software product in a machine-readable format. A component can be any unit that constitutes the basic input / output system code, such as a source file, a firmware module, a static library, or a driver. The first identifier is a unique representation value strictly associated with the component's content. It is generated based on a deterministic generation rule according to the complete data content of the component, ensuring that any change to its content results in a different first identifier.

[0038] Specifically, the process of obtaining the target list may include: downloading the target list file from a second electronic device or an intermediate storage server via a pre-defined network interface, such as a secure file transfer protocol interface. This target list file is associated with a batch of components to be verified (e.g., a specific version of the underlying input / output system source code package).

[0039] For example, after completing the development of the basic input / output system code for version 1.1, the original design manufacturer (ODM) generates a software bill of materials (BOM) file representing that version on its development device (second electronic device) for all source code files. This file records multiple component entries such as "main.c" and "pch_init.c," each containing a unique string generated by the second electronic device based on the corresponding file content as a primary identifier. Subsequently, the ODM uploads this BOM file along with the complete version 1.1 basic input / output system source code package to the first electronic device (verification server), or the operator of the first electronic device controls it to download the BOM from an intermediate storage server to the source code package.

[0040] In operation S120, based on the generation method of the first identifier generated by the second electronic device, the second identifier corresponding to each component is generated.

[0041] The generation method refers to a pre-agreed, deterministic data processing algorithm or rule disclosed to the first and second electronic devices. This rule can accept a component as input and output a unique identifier of fixed length or format. Specifically, the first electronic device reads the actual data content of each component obtained along with the target list and applies the exact same generation method used by the second electronic device to each component, thereby independently calculating the second identifier corresponding to the current content of each component.

[0042] For example, the verification server (the first electronic device) reads the binary content of the file "main.c" from the uploaded version 1.1 Basic Input / Output System source code package. Applying pre-defined deterministic data processing rules—the same as those used by the original design manufacturer's development equipment—it processes the binary content to generate a new, unique string, which becomes the second identifier for the "main.c" file. This process is repeated for all other files in the source code package, generating a second identifier for each file.

[0043] In operation S130, in response to the difference between the first identifier and the second identifier, an alarm message is generated. The alarm message indicates that there is an anomaly in the target list generated by the second electronic device. In this embodiment, the alarm message can be, but is not limited to, one or more of the following: a log record, an email notification sent to a designated administrator, or a warning label displayed on the system monitoring dashboard. Specifically, for each component recorded in the target list, its associated first identifier is compared one by one with the second identifier generated by the first electronic device for the same component in operation S120. If it is found that the first identifier and the second identifier of any component do not completely match, the generation of alarm message is triggered.

[0044] For example, the verification server compares the first identifier (e.g., "A1B2C3D4...") corresponding to "main.c" recorded in the software bill of materials file with the newly generated second identifier (e.g., "X9Y8Z7W6...") locally. If the two are inconsistent, the system determines an anomaly and immediately generates an alarm message, which may read: "Alarm: Component 'main.c' verification failed. The target manifest identifier does not match the actual generated identifier, potentially indicating code tampering or version error."

[0045] According to embodiments of this disclosure, by acquiring a target list generated by a second electronic device on a first electronic device, and independently generating second identifiers for each component based on the same generation method for comparison, an automated trust verification mechanism can be established. This mechanism can objectively and efficiently determine whether the component entities provided by the manufacturer are consistent with their declared states in the target list without human intervention. This solves the problem of difficulty in ensuring consistency between the provided code and the declared information due to information opacity, and effectively prevents the risk of code inconsistency caused by unintentional or intentional actions (e.g., unauthorized modification of code after generating the list).

[0046] Figure 2 Another flowchart of a verification method according to an embodiment of the present disclosure is illustrated schematically.

[0047] like Figure 2 As shown, based on the aforementioned embodiments, operation S120 may include operation S210.

[0048] In operation S210, based on the binary information of the component, a second identifier is generated through a feature extraction algorithm. This algorithm is used to uniquely verify the binary information; different components correspond to different second identifiers. The binary information of a component refers to the complete byte sequence data that constitutes that component. This applies regardless of whether the component is a readable source code file or a compiled, packaged binary module (such as firmware, drivers, or library files). Using binary information as the processing object allows this method to effectively verify closed-source components for which the source code is unavailable. The feature extraction algorithm is a deterministic computation process that takes the complete binary information of a component as input and generates an output value (i.e., the second identifier) ​​that uniquely represents the state of that binary information. This process ensures that any modification to the component's content will be reflected in the identifier. Specifically, the first electronic device reads each acquired component as a whole data block, regardless of its internal structure or file type. This complete data block is then input into a preset feature extraction algorithm to calculate the unique second identifier for the component's current state.

[0049] For example, the first electronic device obtains a component named "example.rom" from a software package provided by the manufacturer. This component is a pre-compiled graphics card driver firmware, the source code of which is not visible. The "example.rom" file is read completely from the first byte to the last byte, forming a binary information stream. This information stream is used as input to call a pre-built feature extraction algorithm for processing. After processing, the algorithm outputs a fixed-length digest value, which is used as the second identifier of the "example.rom" component. In this way, even without being able to examine its internal code, a precise digital fingerprint of its current version state can be generated.

[0050] According to embodiments of this disclosure, by explicitly defining the identifier generation basis as the component's binary information and employing a feature extraction algorithm, the integrity verification of the vendor-provided, pre-packaged binary firmware or module is directly achieved without relying on access to the component's source code. This avoids the difficulty in discovering problems due to the inability to perform code-level reviews, ensures that the received binary entity is completely consistent with the entity declared by the vendor in the target list, and effectively prevents the risk of compiled modules being replaced or tampered with during delivery.

[0051] Figure 3 Another flowchart of a verification method according to an embodiment of the present disclosure is illustrated schematically.

[0052] like Figure 3As shown, based on the foregoing embodiments, operation S210 may include operation S310 or S320.

[0053] In operation S310, a second identifier is generated based on the feature extraction algorithm that computes the deterministic summary result.

[0054] In operation S320, a second identifier is generated based on a feature extraction algorithm that calculates the feature distribution of the data.

[0055] Feature extraction algorithms for calculating deterministic summaries refer to a class of algorithms that can generate a fixed-length, unique summary value from input data of arbitrary length through a one-way function operation. These algorithms suffer from the avalanche effect, meaning that small changes in the input data can lead to large and unpredictable differences in the output summary value. Feature extraction algorithms that calculate the distribution of data features, on the other hand, refer to another class of algorithms that analyze the internal structure and content distribution of the input data to generate an identifier that represents its similarity features.

[0056] Specifically, the first electronic device can select one of the feature extraction algorithms to generate the second identifier according to a preset verification strategy. When a strict, complete consistency verification of the component is required, operation S310 can be used; when it is necessary to generate an identifier that reflects the internal structural characteristics of the data, operation S320 can be used. The two operations provide different identifier generation mechanisms, but both are used for the goal of uniquely confirming the component.

[0057] For example, when performing operation S310, a secure hash algorithm (such as the SHA-256 algorithm) can be used. For a component named "examp.bin", its complete binary information is input into the SHA-256 algorithm module, and a 256-bit digest value is generated after the operation. This digest value is the second identifier.

[0058] For example, when performing operation S320, a block fingerprinting algorithm (such as the ssdeep algorithm) can be used. For the same "examp.bin" component, the algorithm will divide its content into blocks, calculate the characteristics of each block, and finally combine these characteristics into a variable-length string that reflects the segmentation characteristics of the content. This string is the second identifier.

[0059] According to embodiments of this disclosure, for critical security modules requiring absolute consistency, a deterministic digest algorithm can be used for zero-tolerance verification; while for other scenarios, algorithms that reflect the inherent characteristics of the data can be selected. This flexibility enhances the robustness and applicability of the verification framework, enabling it to cope with more complex verification scenarios.

[0060] Figure 4Another flowchart of a verification method according to an embodiment of the present disclosure is illustrated schematically.

[0061] like Figure 4 As shown, based on the aforementioned embodiments, the verification method may further include operations S410 to S430.

[0062] In operation S410, in response to the difference between the second identifier and the third identifier, the target component is determined. The third identifier is generated based on the historical version component corresponding to the component according to the generation method. The historical version component refers to the component entity released before the current version, or the previous version or specified baseline version corresponding to the current component. The third identifier is a unique identifier for the historical version component. The target component is the identified component whose content has changed between the two versions.

[0063] Specifically, the first electronic device can acquire the third identifier in two ways: First, it can directly query and read the pre-calculated third identifier from the archived historical target list or version management database; second, in scenarios where direct acquisition is not possible or secondary verification is required, it can acquire the entity data of historical version components from storage locations such as code repositories, and generate the third identifier in real time using the same generation method as the second identifier. The second identifier of the current version component is compared with the acquired or generated third identifier. If the two are inconsistent, the component is identified as the target component.

[0064] For example, the first electronic device is verifying the source code package of version 1.1 and has calculated the second identifier of component "examp.c" as "X9Y8Z7W6...". To obtain its third identifier for version 1.0, it first attempts to search for the identifier corresponding to "examp.c" in the archived version 1.0 target list. If found, the pre-stored identifier "K5L6M7N8..." is used directly as the third identifier. Alternatively, if the pre-stored identifier is not found, the version control system is accessed, the version 1.0 "examp.c" file is checked out, and the same feature extraction algorithm is applied to it to calculate its third identifier "K5L6M7N8..." on the spot. Since the second identifier "X9Y8Z7W6..." is different from the third identifier "K5L6M7N8...", "examp.c" is identified as a target component.

[0065] When operating S420, an update manifest is retrieved. This update manifest is generated by the second electronic device in response to component updates. It is a document provided by the second electronic device (e.g., the developers or system of the original design manufacturer) that records all expected changes from the previous version to the current version. This manifest typically exists in the form of a text file, a structured data file, or a version control system commit log, and its content usually records the names of the modified components and related modification descriptions.

[0066] For example, when the original design manufacturer uploaded the source code package for version 1.1, it also uploaded an update list named "changelist.txt". This file contains: "1. Fixed a power management unit issue, modified file: examA.c. 2. Added support for new display panels, modified file: examB.c." The first electronic device reads this file and extracts a list of declared updates: ["exampA.c", "exampB.c"].

[0067] In operation S430, in response to the absence of a target component in the update list, an alarm message is generated. The alarm message indicates that the component information corresponding to the target component in the target list is abnormal. The first electronic device compares the list of all target components determined in operation S410 with the declared update list extracted from the update list in operation S420. For any component that exists in the target component list but not in the declared update list, it is determined to be an undeclared modification, and an alarm is triggered. That is, the actual content of a component has changed, but this change was not declared in the update list provided by the developer.

[0068] For example, in operation S410, the target component list is determined to be ["exampA.c", "exampC.c"] through identifier comparison. In operation S420, the declaration update list extracted from the update manifest is ["exampA.c", "exampB.c"]. Comparison reveals that the target component "exampA.c" exists in the declaration update list, and the verification passes. However, the target component "exampC.c" does not exist in the declaration update list, and the target component "exampB.c" exists in the declaration update list but has not actually been updated. Therefore, an alarm message is generated, which could be: "Alarm: Component 'exampC.c' has undergone content changes but was not declared in the update manifest; there may be unrecorded modification behavior." or "Alarm: Component 'exampB.c' has not undergone content changes but is declared in the update manifest; the component content may not have been successfully updated."

[0069] According to embodiments of this disclosure, an automated cross-validation mechanism for change declarations is established by comparing the actual modified components determined by identifier differences with the update list provided by the developer. Instead of passively trusting the accuracy and completeness of the update list, this mechanism proactively discovers all code-level changes through technical means and verifies them against the declarations. This effectively solves the problem of incomplete or inaccurate update records due to human negligence or intentional concealment, and can accurately capture "deceptive" or "hidden" modifications.

[0070] Figure 5 Another flowchart of a verification method according to an embodiment of the present disclosure is illustrated schematically.

[0071] like Figure 5 As shown, based on the aforementioned embodiments, the component information also includes the first functional information corresponding to the component. The verification method may further include operations S510 to S530.

[0072] During operation of S510, the first log file corresponding to the component is obtained. This first log file records at least one of the following: the compilation environment, toolchain, dependencies, or file paths used to generate the component. The first log file is generated by the second electronic device. First functional information is a declaration of a specific technical feature supported by the component, recorded in the target manifest (e.g., software bill of materials). The first log file typically refers to the build log file, a process record generated by the second electronic device during the compilation of the source code to generate the component. It contains detailed information such as the specific compilation instructions used to build the component, the list of included source files, and macro definitions. Simultaneously with receiving a new version of the component, the first electronic device also downloads the build log file corresponding to that version of the component from the second electronic device or a designated storage location.

[0073] For example, the target list records a storage control component named "exampleD", whose first functional information is "supports disk array mode". At the same time, the first electronic device obtains the build log file "exampleD_build.log" corresponding to the version of this component from the original design manufacturer's server.

[0074] When operating the S520, based on at least one of the following: compilation environment, toolchain, dependencies, or file paths, the second functional information corresponding to the component is determined. The second functional information can be the actual technical characteristics of the component that are fixed during actual compilation and parsed and derived from the first log file. Specifically, the first electronic device parses the first log file according to a preset rule base, retrieving key information related to a specific function from the log file. For example, it checks whether source code files implementing a specific function have been compiled, or whether compilation macros that enable a specific function have been defined. Based on the retrieved information, the actual state of the function in the actual compilation output can be determined; this is the second functional information.

[0075] For example, the first electronic device parses and obtains the "exampleD_build.log" file. According to preset rules, it is known that the implementation of "disk array mode" depends on the compilation of the "exampleE.c" file. Searching the log file for compilation records, it is found that the log only contains "...compiling exampleF.c...", but no compilation records for "exampleE.c" are found. However, exampleF.c has dependencies related to the Advanced Host Controller Interface (AHCI) mode. Based on this, the second functional information of this component is determined to be "may only support Advanced Host Controller Interface (AHCI) mode".

[0076] During operation of S530, in response to a difference between the first functional information and the second functional information, an alarm message is generated. The alarm message indicates that there is an anomaly in the first functional information of the component recorded in the target manifest. The first electronic device compares the first functional information of a certain component recorded in the target manifest with the second functional information of that component parsed from the compilation log. If the functional characteristics declared in the target manifest are inconsistent with the functional characteristics actually fixed during compilation, such as functional degradation or functional mismatch, it indicates that there is a discrepancy between the declaration and the fact, and an alarm will be generated.

[0077] For example, the first functional information of the "exampleD" component, "Supports RAID mode," is compared with the parsed second functional information, "May only support Advanced Host Controller Interface (AHCI) mode." Since the two do not match, an anomaly is determined, and an alarm message is generated. The message could be: "Alarm: Component 'exampleD' functional mismatch. Declared function: Supports RAID mode; Actual compiled function: May only support Advanced Host Controller Interface (AHCI) mode."

[0078] According to the embodiments of this disclosure, by comparing the functional information declared in the target list with the actual functional information parsed from the compilation log, the problem that it is impossible to confirm whether the declared function actually exists or whether the functional level is consistent based solely on the target list can be solved. It can effectively detect "deceptive" behavior where the functional declaration does not match the actual situation due to configuration errors, negligence, or intentional concealment. For example, the supplier declares support for a certain advanced function, but the actual compilation only includes the basic function.

[0079] Figure 6 Another flowchart of a verification method according to an embodiment of the present disclosure is illustrated schematically.

[0080] like Figure 6 As shown, based on the aforementioned embodiments, the verification method may further include operations S610 to S630.

[0081] In operation S610, the component is reverse-compiled to generate reverse information. This reverse information contains at least one of the following: character information, code snippets, address information, or dependencies associated with the component. Reverse compilation is a process of static analysis of a compiled binary component to extract its internal structural and content characteristics without accessing the source code. Reverse information is the data extracted in this process that reflects the component's inherent characteristics; for example, unencrypted strings embedded in the binary file (character information), function header or footer instruction sequences with distinct characteristics generated by a specific compiler (code snippets), or reference records to functions of other modules (dependencies). Specifically, for a compiled component entity (e.g., a firmware binary file) provided by a second electronic device, the binary file is processed using a reverse compilation tool, and a series of identifiable feature data are extracted as reverse information.

[0082] For example, consider reverse engineering a binary component named "exampleG.bin". The analysis tool found the string "ABCDEFG..." in the file, which is character information; it also identified that the instruction sequences at multiple function entry points conformed to a specific assembly format, which is code snippets; furthermore, it discovered that the component calls functions from the external library "exampleH.lib", which is a dependency. These extracted pieces of information together constitute the reverse engineering information for this component.

[0083] In operation S620, based on at least one of character information, code snippets, address information, or dependencies, and a preset information database, at least a portion of the component's attribute information is determined. The attribute information includes at least a portion of the component's corresponding compilation environment, toolchain, dependencies, or file paths. The preset information database is a knowledge base that stores the mapping relationships between various reverse information features and specific attribute information. Attribute information refers to the actual environment parameters used to generate the component, inferred through reverse analysis. Specifically, the reverse information extracted in operation S610 is matched with the preset information database. By searching for features in the reverse information, the most likely attribute information for generating these features is derived from the database, such as which compiler, which version of the toolchain, or which library files are linked.

[0084] For example, the reverse engineering information of "exampleG.bin" is compared with an information database. Database records show that the aforementioned specific function entry instruction sequence (code snippet) is unique to the "Compiler A1.1" version of the compiler. Simultaneously, the database records show that the string "ABCDEFG..." is typically associated with "Driver Source Package v2.1". Combining these matching results, the component's attribute information is determined to be: "Compiler Toolchain: Compiler A1.1; Dependency: exampleH.lib; Source Code Association: Driver Source Package v2.1".

[0085] In operation S630, in response to the difference between the attribute information and the first log file exceeding a first difference threshold, an alarm message is generated. The alarm message indicates a conflict between the first log file and the target list. The first difference threshold is a preset tolerance parameter used to define the acceptable degree of deviation between the inferred attribute information and the log file records. For example, the attribute information determined in operation S620 is compared item by item with the corresponding information recorded in the first log file (i.e., the compilation log) obtained in operation S510, the number of mismatches or severity scores are calculated, and compared with the first difference threshold. If the difference exceeds the threshold, the first log file is considered unreliable.

[0086] For example, the first log file (exampleD_build.log) records the compilation toolchain for "exampleG.bin" as "Compiler B1.0". However, the attribute information inferred by operation S620 is "Compiler A1.1". There is a clear conflict between the two. Assuming the first difference threshold is set to not allow any differences in the compilation toolchain, the current difference exceeds the threshold. Therefore, an alarm message is generated, which could be: "Alarm: The authenticity of the first log file is questionable. The inferred compilation toolchain (Compiler A1.1) for component 'exampleG.bin' does not match the log record (Compiler B1.0)."

[0087] According to embodiments of this disclosure, by performing reverse analysis on binary components to infer their true attributes and comparing them with a first log file provided by the supplier, the prerequisite problem of relying on the authenticity of the first log file in the aforementioned embodiments is solved. This effectively identifies "deceptive" behavior by suppliers who provide false or inaccurate compilation logs to hide the true compilation environment or evade review, ensuring that all log file-based analyses (such as functional information verification) are based on reliable data, and avoiding verification vulnerabilities introduced by log file forgery.

[0088] Figure 7 Another flowchart of a verification method according to an embodiment of the present disclosure is illustrated schematically.

[0089] like Figure 7 As shown, based on the aforementioned embodiments, the verification method may further include operations S710 to S730.

[0090] The S710 operator retrieves the component code corresponding to the component, and the second electronic device generates a target list based on the component code. The component code refers to the human-readable source code files used to generate the binary component, such as source files and header files. The S710 operator is used to verify the authenticity of deliverables provided by the supplier (such as binary components and build logs) when there are doubts.

[0091] For example, after an alarm is generated in the S630 regarding the authenticity of the "exampleG.bin" component log, the first electronic device initiates a deep verification process. The system accesses the version control server and retrieves all source code files of the source code file "exampleG" corresponding to "exampleG.bin".

[0092] When operating the S720, the component code is compiled, generating a second log file corresponding to the component code. This second log file is a completely new log record generated by the first electronic device in a trusted, controlled compilation environment by actually compiling the component code. This log file is considered the true compilation record of the current component code. Specifically, the first electronic device uses a toolchain that matches the compilation environment (or a standardized verification environment) declared in the first log file to perform a complete compilation operation on the acquired component code. During this process, all compilation instructions, output information, and dependencies are captured, forming the second log file.

[0093] For example, the first electronic device executes compilation commands on the source code file "exampleG" in an isolated environment configured with compiler B1.0. All screen output during the compilation process, including the compilation commands for each file, the compilation parameters used, the linked libraries, and other information, is redirected and saved to a file named "Real_exampleG.log", which is the second log file.

[0094] When operating the S730, in response to a difference between the first log file and the second log file exceeding a second difference threshold, an alarm message is generated. This alarm message indicates a conflict between the component code and the target list. The first electronic device uses an automated comparison tool to perform a structured or textual comparison of the first log file provided by the supplier and the locally generated second log file. The comparison may include the list of compiled modules, the compilation parameters used by each module, the order and version of linked libraries, etc. If the number or severity of differences exceeds the second difference threshold, a conflict is determined, indicating an inconsistency between the component code provided by the supplier, the compilation logs, and the final binary component.

[0095] For example, the comparison tool found that the first log file (exampleD_build.log) provided by the vendor contained compilation records for the "exampleI.c" file, while the locally generated second log file (Real_exampleG.log) did not, because the file does not exist in the source code package. This difference was judged as a serious discrepancy, exceeding the second discrepancy threshold. Therefore, an alert message was generated, which could read: "Alert: There is a serious conflict between the component code and the target manifest. The provided source code cannot reproduce its declared compilation logs, and incorrect source code or forged logs may have been delivered."

[0096] In conjunction with the foregoing embodiments, operation S710 may include: in response to the difference between the attribute information and the first log file being greater than a first difference threshold, obtaining the component code corresponding to the component. That is, only when a low-cost reverse analysis method (such as operations S610~S630) discovers significant discrepancies in the log file provided by the supplier will a high-cost local compilation verification process requiring a complete compilation environment be triggered for final, decisive confirmation, thereby executing subsequent operations S720 to S730.

[0097] According to embodiments of this disclosure, by recompiling the component code provided by the supplier in a trusted environment and comparing the generated second log file with the first log file provided by the supplier, it no longer relies on any procedural files (such as compilation logs) provided unilaterally by the supplier. Instead, it directly verifies the integrity and consistency of the "source code-log-binary" chain by reproducing the compilation process. This can reveal the deepest level of "deception" behavior, such as providing a seemingly clean set of source code, but the actual delivered binary component is compiled from another set of source code containing malicious code, supplemented by forged compilation logs.

[0098] Figure 8 Another flowchart of a verification method according to an embodiment of the present disclosure is illustrated schematically.

[0099] like Figure 8 As shown, based on the aforementioned embodiments, the verification method may further include operation S810.

[0100] In operation S810, in response to the generation of the alarm information, the target list is updated to indicate the location and content of the anomaly. Updating the target list does not mean overwriting or deleting the original information, but rather supplementing or annotating the original target list. By adding new data fields or metadata, the anomaly information discovered during the verification process is associated and bound to its corresponding component entry. The location of the anomaly refers to the specific component name or identifier where the problem occurred, while the anomaly content describes in detail the type of alarm and the specific inconsistencies.

[0101] Specifically, when any of the aforementioned operations (such as S130, S430, S530, etc.) generates alarm information, the system will automatically locate the component entry related to the alarm in the target list, add a structured field under that entry, such as "verification annotation", and write the alarm details, such as alarm type, verification time, and specific differences found (e.g., expected identifier and actual identifier), as the value of the field.

[0102] According to embodiments of this disclosure, by writing back and updating the target list with the alarm information found during the verification process, when a security vulnerability occurs in the future, this target list with anomaly annotations can help the team quickly determine whether the problem is related to anomalies such as previously known, undeclared modifications or functional inconsistencies, thereby significantly shortening the vulnerability response and remediation time.

[0103] Combining the aforementioned embodiments, firstly, by comparing the first identifier in the target list with the second identifier actually generated based on the component's binary information, it can be ensured that the delivered component entity is consistent with the declaration. Furthermore, by comparing the identifier differences between old and new versions with the update list, it can be verified whether there are any undeclared modifications during version iterations. Alternatively, by comparing the functional declarations in the target list with the actual compilation information in the compilation log, it can be verified whether there are any discrepancies between the declared and actual component functions. To ensure the reliability of the verification basis itself, reverse engineering of the binary component can be performed to infer its true compilation attributes, and this can be compared with the compilation log provided by the supplier to verify the authenticity of the log. On the other hand, with the source code available, local compilation can be performed in a trusted environment. By comparing the locally generated logs with the logs provided by the supplier, the completeness and consistency of the "source code-logs-packaged firmware" delivery chain can be finally determined.

[0104] According to the embodiments of this disclosure, not only can consistency errors caused by negligence be detected, but also various deceptive behaviors that suppliers may engage in during the delivery process can be effectively identified and prevented, such as hiding code modifications, falsely reporting functional configurations, and forging compilation process evidence. By writing the verification results back to the target list, a static supplier statement is transformed into a dynamically updated, trusted record that has undergone rigorous third-party auditing. This greatly improves the transparency, traceability, and security of software materials, fundamentally solving the problem of trust deficiency caused by information asymmetry in the software supply chain.

[0105] Figure 9 A block diagram of a verification apparatus according to an embodiment of the present disclosure is shown schematically.

[0106] like Figure 9 As shown, the verification device 900 may include a first acquisition module 910, a first generation module 920, and a first alarm module 930.

[0107] The first acquisition module 910 is used to acquire a target list. The target list records at least one component information of at least one component. The component information includes at least a first identifier corresponding to the component. Different components have different first identifiers. The target list is generated by a second electronic device, which is different from the first electronic device. In some embodiments, the first acquisition module 910 can be used to perform operation S110 in the above verification method, which will not be described in detail here.

[0108] The first generation module 920 is used to generate a first identifier based on the second electronic device, and to generate a second identifier corresponding to each component. In some embodiments, the first generation module 920 can be used to perform operation S120 in the above verification method, which will not be described in detail here.

[0109] The first alarm module 930 is used to generate alarm information in response to the difference between the first identifier and the second identifier. The alarm information indicates that there is an anomaly in the target list generated by the second electronic device. In some embodiments, the first alarm module 930 can be used to perform operation S130 in the above verification method, which will not be described in detail here.

[0110] According to embodiments of this disclosure, the first generation module may include a second generation module.

[0111] The second generation module generates a second identifier based on the binary information of the component using a feature extraction algorithm. The feature extraction algorithm is used to verify the uniqueness of the binary information, and different components correspond to different second identifiers. In some embodiments, the second generation module can be used to perform operation S210 in the above verification method, which will not be elaborated here.

[0112] According to embodiments of this disclosure, the second generation module may include a third generation module or a fourth generation module.

[0113] The third generation module is used to generate a second identifier based on a feature extraction algorithm that calculates the deterministic summary result. In some embodiments, the third generation module can be used to perform operation S310 in the above verification method, which will not be elaborated here.

[0114] The fourth generation module is used to generate a second identifier based on a feature extraction algorithm that calculates the feature distribution of the data. In some embodiments, the fourth generation module can be used to perform operation S320 in the above verification method, which will not be elaborated here.

[0115] According to embodiments of this disclosure, the verification device may include a first determining module, a second acquiring module, and a second alarm module.

[0116] The first determining module is used to determine the target component in response to the difference between the second identifier and the third identifier. The third identifier is generated according to the generation method of the historical version component corresponding to the component. In some embodiments, the first determining module can be used to perform operation S410 in the above verification method, which will not be elaborated here.

[0117] The second acquisition module is used to acquire an update list, which is generated by the second electronic device in response to component updates. In some embodiments, the second acquisition module can be used to perform operation S420 in the above verification method, which will not be elaborated here.

[0118] The second alarm module generates an alarm message in response to the absence of a target component in the updated list. The alarm message indicates that there is an anomaly in the component information corresponding to the target component in the target list. In some embodiments, the second alarm module can be used to perform operation S430 in the above verification method, which will not be elaborated here.

[0119] According to embodiments of this disclosure, the verification device may include a third acquisition module, a second determination module, and a third alarm module.

[0120] The third acquisition module is used to acquire the first log file corresponding to the component. The first log file records at least one of the compilation environment, toolchain, dependencies, or file paths of the generated component. The first log file is generated by the second electronic device. In some embodiments, the third acquisition module can be used to perform operation S510 in the above verification method, which will not be elaborated here.

[0121] The second determining module is used to determine the second functional information corresponding to the component based on at least one of the compilation environment, toolchain, dependencies, or file path. In some embodiments, the second determining module can be used to perform operation S520 in the above verification method, which will not be elaborated here.

[0122] The third alarm module is used to generate alarm information in response to a difference between the first functional information and the second functional information. The alarm information indicates that there is an anomaly in the first functional information of the component recorded in the target list. In some embodiments, the third alarm module can be used to perform operation S530 in the above verification method, which will not be described in detail here.

[0123] According to embodiments of this disclosure, the verification device may include a reverse engineering module, a third determination module, and a fourth alarm module.

[0124] The reverse compilation module is used to reverse compile the component and generate reverse information. The reverse information includes at least one of the following: character information, code snippets, address information, or dependencies associated with the component. In some embodiments, the reverse compilation module can be used to perform operation S610 in the above verification method, which will not be elaborated here.

[0125] The third determining module is used to determine at least part of the attribute information of a component based on at least one of character information, code snippets, address information, or dependencies, and a preset information database. The attribute information includes at least part of the compilation environment, toolchain, dependencies, or file paths corresponding to the component. In some embodiments, the third determining module can be used to perform operation S620 in the above verification method, which will not be elaborated here.

[0126] The fourth alarm module is used to generate alarm information in response to a difference between the attribute information and the first log file exceeding a first difference threshold. The alarm information indicates a conflict between the first log file and the target list. In some embodiments, the fourth alarm module can be used to perform operation S630 in the above verification method, which will not be elaborated here.

[0127] According to embodiments of this disclosure, the verification device may include a fourth acquisition module, a compilation module, and a fifth alarm module.

[0128] The fourth acquisition module is used to acquire the component code corresponding to the component, and the second electronic device generates a target list based on the component code. In some embodiments, the fourth acquisition module can be used to perform operation S710 in the above verification method, which will not be elaborated here.

[0129] The compilation module is used to compile the component code and generate a second log file corresponding to the component code. In some embodiments, the compilation module can be used to perform operation S720 in the above verification method, which will not be elaborated here.

[0130] The fifth alarm module generates an alarm message in response to a difference between the first log file and the second log file exceeding a second difference threshold. The alarm message indicates a conflict between the component code and the target list. In some embodiments, the fifth alarm module can be used to perform operation S730 in the above verification method, which will not be elaborated here.

[0131] According to embodiments of this disclosure, the verification device may include a manifest update module.

[0132] The inventory update module is used to update the target inventory in response to alarm information generation, so as to indicate the location and content of the anomaly in the target inventory. In some embodiments, the inventory update module can be used to perform operation S810 in the above verification method, which will not be described in detail here.

[0133] Any one or more of the modules, submodules, units, and subunits according to embodiments of the present disclosure, or at least part of the functions of any one or more of them, can be implemented in one module. Any one or more of the modules, submodules, units, and subunits according to embodiments of the present disclosure can be implemented by dividing them into multiple modules. Any one or more of the modules, submodules, units, and subunits according to embodiments of the present disclosure can be at least partially implemented as hardware circuitry, such as a Field-Programmable Gate Array (FPGA), a Programmable Logic Array (PLA), a System-on-Chip, a System-on-a-Substrate, a System-on-Package, an Application-Specific Integrated Circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, one or more of the modules, submodules, units, and subunits according to embodiments of the present disclosure can be at least partially implemented as computer program modules, which, when run, can perform corresponding functions.

[0134] For example, any plurality of the first acquisition module 910, the first generation module 920, and the first alarm module 930 can be combined into one module / unit / subunit, or any one of these modules / units / subunits can be split into multiple modules / units / subunits. Alternatively, at least part of the functionality of one or more of these modules / units / subunits can be combined with at least part of the functionality of other modules / units / subunits and implemented in one module / unit / subunit. According to embodiments of this disclosure, at least one of the first acquisition module 910, the first generation module 920, and the first alarm module 930 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the first acquisition module 910, the first generation module 920, and the first alarm module 930 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0135] It should be noted that the data processing system part in the embodiments of this disclosure corresponds to the data processing method part in the embodiments of this disclosure. The specific description of the data processing system part is referred to in the data processing method part, and will not be repeated here.

[0136] Figure 10 A block diagram of an electronic device suitable for implementing the methods described above, according to embodiments of the present disclosure, is illustrated schematically. Figure 10 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0137] like Figure 10 As shown, a first electronic device 1000 according to an embodiment of the present disclosure includes a processor 1001, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage portion 1008 into a random access memory (RAM) 1003. The processor 1001 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 1001 may also include onboard memory for caching purposes. The processor 1001 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0138] RAM 1003 stores various programs and data required for the operation of the first electronic device 1000. Processor 1001, ROM 1002, and RAM 1003 are interconnected via bus 1004. Processor 1001 performs various operations of the method flow according to embodiments of the present disclosure by executing programs in ROM 1002 and / or RAM 1003. It should be noted that the programs may also be stored in one or more memories other than ROM 1002 and RAM 1003. Processor 1001 may also perform various operations of the method flow according to embodiments of the present disclosure by executing programs stored in said one or more memories.

[0139] According to embodiments of this disclosure, the first electronic device 1000 may further include an input / output (I / O) interface 1005, which is also connected to a bus 1004. The first electronic device 1000 may also include one or more of the following components connected to the input / output (I / O) interface 1005: an input section 1006 including a keyboard, mouse, etc.; an output section 1007 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a LAN card, modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to the input / output (I / O) interface 1005 as needed. A removable medium 1011, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1010 as needed so that computer programs read from it can be installed into the storage section 1008 as needed.

[0140] According to embodiments of this disclosure, the method flow according to embodiments of this disclosure can be implemented as a computer software program. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable storage medium, the computer program containing program code for performing the methods shown in the flowchart. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1009, and / or installed from removable medium 1011. When the computer program is executed by processor 1001, it performs the functions defined in the system of embodiments of this disclosure. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0141] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs that, when executed, implement the method according to the embodiments of this disclosure.

[0142] According to embodiments of this disclosure, the computer-readable storage medium can be a non-volatile computer-readable storage medium. Examples include, but are not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0143] For example, according to embodiments of this disclosure, a computer-readable storage medium may include the ROM 1002 and / or RAM 1003 described above and / or one or more memories other than ROM 1002 and RAM 1003.

[0144] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods provided in the embodiments of this disclosure. When the computer program product is run on an electronic device, the program code is used to enable the electronic device to implement the verification methods provided in the embodiments of this disclosure.

[0145] When the computer program is executed by the processor 1001, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0146] In one embodiment, the computer program may rely on tangible storage media such as optical storage devices or magnetic storage devices. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via communication section 1009, and / or installed from removable medium 1011. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof. According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code may be executed entirely on a user computing device, partially on a user device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing devices can be connected to user computing devices via any type of network, including local area networks (LANs) or wide area networks (WANs), or they can be connected to external computing devices (e.g., via the Internet using an Internet service provider).

[0147] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions. Those skilled in the art will understand that the features described in the various embodiments of the present disclosure can be combined and / or combined in various ways, even if such combinations are not explicitly described in the present disclosure. In particular, the features described in the various embodiments of this disclosure may be combined and / or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

[0148] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A verification method, applied to a first electronic device, comprising: Obtain a target list, the target list recording at least one component information of at least one component, the component information including at least a first identifier corresponding to the component, the first identifier corresponding to different components being different, the target list being generated by a second electronic device, the second electronic device being different from the first electronic device; Based on the generation method of the first identifier generated by the second electronic device, generate the second identifier corresponding to each of the components; In response to the difference between the first identifier and the second identifier, an alarm message is generated, which indicates that there is an anomaly in the target list generated by the second electronic device.

2. The method according to claim 1, wherein generating the second identifier corresponding to each of the components comprises: Based on the binary information of the component, the second identifier is generated by a feature extraction algorithm. The feature extraction algorithm is used to confirm the uniqueness of the binary information, and the second identifier is different for different components.

3. The method according to claim 2, wherein generating the second identifier through a feature extraction algorithm comprises: The second identifier is generated based on a feature extraction algorithm that computes a deterministic summary result; or, The second identifier is generated based on a feature extraction algorithm that calculates the feature distribution of the data.

4. The method according to claim 1, further comprising: In response to the difference between the second identifier and the third identifier, a target component is determined, wherein the third identifier is generated according to the generation method based on the historical version component corresponding to the component; Obtain an update list, which is generated by the second electronic device in response to an update of the component; In response to the absence of the target component in the updated list, an alarm message is generated, indicating that there is an anomaly in the component information corresponding to the target component in the target list.

5. The method according to claim 1, wherein the component information further includes first functional information corresponding to the component, and the method further includes: Obtain the first log file corresponding to the component. The first log file is used to record at least one of the compilation environment, toolchain, dependencies or file paths that generated the component. The first log file is generated by the second electronic device. Based on at least one of the compilation environment, the toolchain, the dependencies, or the file path, determine the second functional information corresponding to the component; In response to the difference between the first functional information and the second functional information, an alarm message is generated, the alarm message indicating that there is an anomaly in the first functional information of the component recorded in the target list.

6. The method according to claim 5, further comprising: The component is reverse-compiled to generate reverse information, which includes at least one of the following: character information, code snippets, address information, or dependencies associated with the component. According to at least one of the character information, the code fragment, the address information or the dependency and a preset information database, attribute information of the component is determined, the attribute information including at least part of a compilation environment, a tool chain, a dependency or a file path corresponding to the component; In response to a difference between the attribute information and the first log file being greater than a first difference threshold, alarm information is generated, the alarm information indicating that the first log file conflicts with the target manifest.

7. The method of claim 5, further comprising: obtaining component code corresponding to the component, the second electronic device generating a target manifest according to the component code; compiling the component code to generate a second log file corresponding to the component code; in response to a difference between the first log file and the second log file being greater than a second difference threshold, generating alarm information, the alarm information indicating that the component code conflicts with the target manifest.

8. The method of any one of claims 1 to 7, further comprising: in response to the alarm information being generated, updating the target manifest to indicate a location and an exception content of the exception in the target manifest.

9. A verification apparatus configured in a first electronic device, comprising: a first obtaining module configured to obtain a target manifest, the target manifest recording at least one component information of at least one component, the component information including at least a first identifier corresponding to the component, the first identifiers corresponding to different components being different, the target manifest being generated by a second electronic device, the second electronic device being different from the first electronic device; a first generating module configured to generate a second identifier corresponding to each of the components based on a generation manner of the first identifier generated by the second electronic device; and a first alarm module configured to generate alarm information in response to the first identifier and the second identifier being different, the alarm information indicating that the target manifest generated by the second electronic device is abnormal.

10. A first electronic device, comprising: at least one processor; and a memory connected with the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform at least one of the following operations: obtaining a target manifest, the target manifest recording at least one component information of at least one component, the component information including at least a first identifier corresponding to the component, the first identifiers corresponding to different components being different, the target manifest being generated by a second electronic device, the second electronic device being different from the first electronic device; generating a second identifier corresponding to each of the components based on a generation manner of the first identifier generated by the second electronic device; and generating alarm information in response to the first identifier and the second identifier being different, the alarm information indicating that the target manifest generated by the second electronic device is abnormal. ​ ​

Images