A method of verifying integrity of a plug-in and a computing device

Abstract

A method for checking integrity of a plug-in and a computing device, involving an aspect program, the aspect program is started in response to the start of a target program, the aspect program runs in the same process as the target program, and the calling instruction of the target program for the plug-in loading function is acquired; according to the calling instruction, the target plug-in to be loaded is determined; the current integrity characteristic value of the target plug-in is determined; it is verified whether the real integrity characteristic value of the target plug-in pre-stored is consistent with the current integrity characteristic value; in response to the verification that the real integrity characteristic value is consistent with the current integrity characteristic value, the target plug-in is loaded, and the plug-in calling process of the target program which does not depend on the file opening event can be detected without changing the target program and without the target program being aware, and the plug-in tampering risk that may exist is accurately identified.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of information security technology, and in particular relate to a method and computing device for verifying the integrity of a plug-in. Background Technology

[0002] Plugins, as functional extension modules that can be loaded and executed within host software, are widely used in integrated development environments (IDEs), intelligent editors, AI agents, and other software. Represented by IDEs like VSCode and Cursor, and AI agent tools like Claude Code, host software generally provides plugin or skill extension systems, allowing third-party developers to publish plugins. After users download and install them from the official marketplace, the host process loads the plugin code into its address space at runtime, thereby extending the functionality of the host software. Plugin loading within the host process is typically accomplished by a module loader maintained internally by the host through dynamic module loading interfaces, such as the `require()` function in Node.js runtime, the dynamic `import()` function in the ESModule specification, or a custom skill loading entry point defined by the host software.

[0003] File Integrity Monitoring (FIM) is a security technology used to detect whether files have been modified without authorization. Its basic principle is to calculate the hash value of the protected file and establish a baseline record. Subsequently, the file system is periodically scanned, the file hash value is recalculated, and compared with the baseline. If an inconsistency is found, the file is determined to have been tampered with, and an alarm is triggered. FIM technology has been maturely applied in scenarios such as protecting critical operating system files and preventing configuration file tampering.

[0004] With the rapid development of the plugin ecosystem, security incidents involving malicious tampering of plugins after installation are gradually increasing, creating a demand for runtime integrity verification of plugins. However, existing integrity detection methods often fall short of expectations when applied to plugin scenarios. On one hand, the plugin loading process is directly driven by the module loader within the host process, and the technical characteristics of the loading path differ from those of regular file access scenarios. Therefore, existing file-level integrity detection methods still have room for improvement in terms of the timing and method of intervention during the plugin loading process.

[0005] On the other hand, even if plugin tampering can be detected, existing methods are still insufficient to meet the actual needs of plugin security protection in terms of the timeliness of detection and the ability to take proactive measures at the plugin loading point.

[0006] This specification provides a solution for verifying the integrity of plugins, which at least partially solves the above-mentioned problems. Summary of the Invention

[0007] This specification provides an embodiment of a method and computing device for verifying the integrity of a plug-in, including:

[0008] This specification provides a method for verifying the integrity of a plugin, the method relating to an aspect program that starts in response to the startup of a target program, the aspect program and the target program running in the same process, the method comprising:

[0009] Obtain the call instructions from the target program for the plugin loading function;

[0010] Based on the invocation instruction, the target plugin to be loaded is determined;

[0011] Determine the current integrity feature value of the target plugin;

[0012] Verify whether the pre-stored true integrity feature value of the target plugin is consistent with the current integrity feature value;

[0013] In response to the verification that the true integrity feature value matches the current integrity feature value, the target plugin is loaded.

[0014] A second aspect of this specification provides a computer-readable storage medium having a computer program stored thereon that, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0015] A third aspect of this specification provides a computing device including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method described in the first aspect.

[0016] The present embodiment provides a scheme for verifying the integrity of plugins. Without modifying the target program or requiring the target program's awareness, it can detect the plugin call process of the target program that does not depend on file open events, and accurately identify potential plugin tampering risks. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the architecture of a plug-in integrity verification system in one embodiment of this specification;

[0019] Figure 2 This is the main flowchart of a plug-in integrity verification method in one embodiment of this specification;

[0020] Figure 3 This is a flowchart illustrating the cross-section weaving mechanism in one embodiment of this specification;

[0021] Figure 4 This is a flowchart illustrating the baseline establishment process in one embodiment of this specification;

[0022] Figure 5 This is a schematic diagram of the state transition of the baseline lifecycle in one embodiment of this specification;

[0023] Figure 6 This is a logical diagram illustrating the configuration and handling strategy in one embodiment of this specification. Detailed Implementation

[0024] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0025] Figure 1 A schematic diagram of the architecture of a plug-in integrity verification system in one embodiment of this specification is shown. Figure 1 As shown, the system is deployed on a terminal device running the target program 100. The target program 100 can be software with plug-in extension capabilities, such as an integrated development environment (e.g., VSCode, Cursor), an AI agent tool (e.g., Claude Code), or other applications that support plug-in or skill extension systems. During runtime, the target program 100 loads plug-in code into the process address space for execution via a dynamic module loading interface through its internally maintained module loader, thereby achieving functional extension.

[0026] The core architecture of the system comprises five modules: aspect base module 110, aspect function module 120, multi-source baseline verification module 130, Trusted Execution Environment (TEE) storage and comparison module 140, and processing module 150. The multi-source baseline verification module 130 and the TEE storage and comparison module 140 are optional modules.

[0027] It should be noted that in this embodiment, the aspect base module 110 and the target program 100 run in the same process, which is a key design feature that distinguishes this embodiment from traditional plug-in security detection schemes. Since the aspect base module 110 and the target program 100 share the same process address space, the aspect base module 110 can directly perceive the calling behavior of the plug-in loading function within the target program 100, without relying on the file system event callback mechanism at the operating system level, and also avoids the latency and permission isolation issues caused by cross-process communication.

[0028] Before going into the specific functions of each module, we will first explain several core technical concepts involved in this embodiment.

[0029] Aspect-Oriented Programming (AOP) is a programming paradigm that achieves unified maintenance of program functionality through pre-compilation or runtime dynamic proxies. Its core idea is to extract cross-cutting concerns (such as logging, permission verification, and transaction management) that are scattered across multiple business modules, have no direct connection to the core business logic, but still need to be executed. These concerns are then encapsulated as independent aspects, and their processing logic is automatically woven into specific nodes of program execution (called pointcuts). Taking the application scenario of this embodiment as an example, the plugin loading process of the target program 100 can be regarded as an execution chain. The role of AOP is equivalent to setting an interception point at the entry point of the plugin loading function in this chain. When the plugin loading function is called, the interception point automatically triggers the pre-set detection logic in the aspect function module 120. After the detection is completed, it is decided whether to return control to the original plugin loading function. Throughout the entire process, the business code of the target program 100 and the plugin itself does not need to be modified. This weaving method has different implementations across different technology stacks: in the Java ecosystem, bytecode enhancement can be achieved using ByteBuddy or ASM; in the Node.js environment, ES6 Proxy objects can be used to proxy and wrap module loading functions; in the Python environment, function interception can be achieved through decorators or runtime Monkey Patch. This embodiment does not limit the specific weaving implementation method.

[0030] Dynamic loading of plugins is another key concept for understanding the technical background of this embodiment. Taking the Node.js runtime as an example, when the target program 100 needs to load a plugin, the module loader calls the require() function or the Module._load method to resolve the disk path of the plugin file according to the plugin identifier, read the plugin code into the process memory, and execute it. Under the ESModule specification, the dynamic import() function performs a similar role. For AI agent tools, the loading of plugins (usually called skills) is driven by the host's custom skill loading entry point. These loading paths share a common technical feature: the reading and loading of plugin code is directly completed by the module resolution mechanism inside the host process, without going through the standard file open and read system call paths provided by the operating system. From the perspective of the operating system kernel, no regular file I / O events are generated during the plugin loading process. This characteristic directly causes the traditional file integrity monitoring (FIM) technology based on file system event callbacks to lose its intervention opportunity in this scenario—the detection hooks such as inotify, fsnotify, or Filter Manager minifilter that FIM relies on will not be triggered on the dynamic loading path of the plugin.

[0031] Integrity feature values ​​are used to characterize the integrity of plugin code. The basic idea is to calculate or extract a feature value that reflects the state of the code content by analyzing or extracting the plugin's runtime code according to preset rules. When the plugin code is modified, this feature value changes accordingly, allowing determination of whether the code has been tampered with. There are various ways to generate integrity feature values, such as using hash algorithms (e.g., SHA-256, MD5) to calculate the code digest, or using digital signatures, Cyclic Redundancy Check (CRC), etc. This embodiment does not impose a unique limitation on the generation method of integrity feature values, as long as the feature value has sufficient distinguishability against changes in the code content.

[0032] TEE (Trusted Execution Environment) is a hardware-based security technology designed to create a physically isolated secure region within the processor, separate from the main operating system (Rich Execution Environment, REE), to protect the confidentiality and integrity of sensitive code and data. In terminal devices, the REE typically hosts the execution of conventional code such as the operating system, applications, host software, and plugins; the TEE, as a secure region isolated from the ordinary execution environment, possesses relatively independent computing and storage capabilities. In one embodiment of this specification, security-sensitive information such as true integrity feature values, baseline status, plugin identifiers, and version numbers can be stored in the TEE. Furthermore, the comparison process between the current integrity feature value and the true integrity feature value can also be completed within the TEE, and the aspect-oriented program in the REE can receive the verification results returned by the TEE. This setup helps prevent baseline data from being tampered with by malicious code in the REE and also helps improve the credibility of the verification results. It should be noted that in this embodiment, the TEE is an optional security enhancement component; in scenarios where the TEE is not deployed, true integrity feature values ​​can also be stored using cloud storage, local secure storage, protected configuration files, or operating system security sandboxes.

[0033] Back Figure 1 The system architecture is shown. The aspect base module 110 acts as a trigger layer, starting synchronously when the target program 100 starts, and weaving pointcuts into the plugin dynamic loading interfaces (including but not limited to require(), import(), skill loader entry points) and plugin installation, update, enable, and disable interfaces. When any of the above interfaces is called, the aspect base module 110 captures the call event and forwards the call instruction to the aspect function module 120.

[0034] The aspect function module 120, as the processing layer, receives the call instruction and executes the core logic of integrity detection, including determining the target plugin, calculating the current integrity feature value, completing the verification based on the integrity feature value (optionally calling the TEE storage and comparison module 140), and deciding whether to allow or trigger the action based on the verification result.

[0035] The multi-source baseline verification module 130 intervenes when the plugin first establishes a baseline or when a legitimate update occurs, verifying the baseline from at least two external trusted sources (such as...). Figure 1As shown, the two external trusted sources are the official signature of the plugin platform and the cloud-based trusted whitelist. The baseline value is pulled and cross-compared with the local hash calculation result to prevent supply chain contamination. In this embodiment, the baseline refers to the integrity reference record established by the plugin in a trusted state. Its core content is the plugin's true integrity feature value, and it may also include related information such as plugin identifier, version number, baseline establishment time, and baseline status. In other words, the true integrity feature value is the core data item in the baseline used for integrity comparison, and the baseline is the complete record that carries this data item and manages its lifecycle. The baseline status mentioned in subsequent paragraphs indicates whether the true integrity feature value carried by the baseline can be used for runtime comparison at the current moment.

[0036] The TEE storage and comparison module 140 is deployed within the TEE of the terminal device. The TEE is a secure area isolated from the Rich Execution Environment (REE), possessing independent computing and storage capabilities to ensure the confidentiality and integrity of data storage and computation processes. In some implementations, the actual integrity characteristic value of the plugin is stored within the TEE, and the comparison operation is also executed within the TEE in a closed loop; programs in the REE cannot read or modify the baseline data in the TEE.

[0037] Based on the judgment result of the aspect function module 120, the handling module 150 performs preset operations such as logging, alarm notification, or loading of interception plugins. Specific strategies can be configured differently according to plugin type and risk level.

[0038] Figure 2 The main flowchart of a plug-in integrity verification method in one embodiment of this specification is shown. Figure 2 As shown, the overall execution of this method can be divided into three stages: the software startup stage, the baseline establishment stage, and the runtime load detection stage. The software startup stage completes the weaving of aspects and the establishment of detection points; the baseline establishment stage establishes a reliable integrity baseline after the plugin is installed; and the runtime load detection stage performs real-time verification every time a plugin is loaded. The following explanation focuses on the main steps of the runtime load detection stage.

[0039] Step S200: Obtain the call instructions from the target program for the plugin loading function.

[0040] As mentioned earlier, the faceted base module 110 starts synchronously when the target program 100 starts, and completes the weaving of the faceted points at the plug-in dynamic loading interface.

[0041] Figure 3 A schematic flowchart of the cross-section weaving mechanism in one embodiment of this specification is shown. Figure 3As shown, the aspect-based support module 110 establishes interception points on the call path of the plugin loading function through AOP weaving. Weaving can be implemented in various ways, including runtime dynamic proxies, compile-time or packaging-time static bytecode enhancement, and function pointer replacement. Taking runtime dynamic proxies as an example, the aspect-based support module 110 saves a reference to the original plugin loading function during weaving and replaces the original function's position in the call chain with a proxy function. When the business logic of the target program 100 triggers plugin loading, the call request reaches the interception point set by the proxy function, instead of directly reaching the original plugin loading function. With bytecode enhancement, the aspect-based support module 110 can insert detection call instructions at the entry point of the plugin loading method during the compilation or loading phase of the plugin loading class of the target program 100 using bytecode manipulation tools (such as ASM or ByteBuddy), so that the plugin loading method automatically triggers the detection logic of the aspect function module 120 when it is executed.

[0042] Regarding the choice of advice type, this embodiment can employ AOP advice forms such as Around Advice and Before Advice. With Around Advice, after capturing the call instruction, the proxy function first executes integrity check logic, and then decides whether to return control to the original plugin loading function based on the check result; that is, the check logic is "wrapped" around the original loading call. With Before Advice, the proxy function triggers the check logic before the original plugin loading function executes. If the check fails, an exception is thrown or an error code is returned to block the subsequent loading process. Both advice forms can complete integrity verification before the plugin code is actually executed; the difference lies in the organization of the control flow. This embodiment does not impose a unique limitation on the advice type.

[0043] In a specific use case, assuming the target program 100 is VSCode, after a user launches VSCode and opens a Python project, the VSCode Extension Host process needs to activate the installed Python language support plugin. At this time, the Extension Host process calls the ExtensionHostManager.activateById method. This call is intercepted by the pointcut woven into the activationById entry point by the Aspect Base module 110. The Aspect Base module 110 then obtains the corresponding call instruction and forwards it to the Aspect Function module 120.

[0044] Step S202: Determine the target plugin to be loaded according to the calling instruction.

[0045] After receiving the call instruction, the aspect function module 120 parses the plugin identifier information from the instruction to determine the target plugin to be loaded. The plugin identifier can be the plugin's unique name (such as "ms-python.python"), the disk path of the plugin package, or the plugin's index number in the host program's registry. The aspect function module 120 uses this identifier to locate the target plugin's runtime code file, preparing for subsequent calculation of integrity feature values.

[0046] If the plugin identifier carried in the calling instruction cannot be matched with a corresponding record in the local list of installed plugins, the aspect function module 120 can handle it according to a preset exception handling strategy, such as recording an exception log and allowing loading, or refusing loading and triggering an alarm. Specific exception handling strategies are not limited in this embodiment.

[0047] Step S204: Determine the current integrity feature value of the target plugin.

[0048] After identifying the target plugin, the aspect function module 120 calculates the current integrity feature value for the target plugin's running code. This current integrity feature value reflects the actual code state of the target plugin at the time of loading. The calculation scope can cover all running code files of the target plugin, or it can cover only the core code files according to the preset configuration. The specific implementation of the calculation method will be explained in subsequent paragraphs.

[0049] Step S206: Verify whether the real integrity feature value of the pre-stored target plugin is consistent with the current integrity feature value.

[0050] The aspect function module 120 sends the current integrity feature value to the TEE storage and comparison module 140, which then compares the current integrity feature value with the pre-stored true integrity feature value of the target plugin within the TEE. The true integrity feature value is written to the TEE after the plugin is installed through the baseline establishment process and represents the code characteristics of the plugin in a trusted state. The comparison operation is performed within the TEE, and programs in ordinary execution environments cannot interfere with the comparison process or read intermediate comparison data. After completing the comparison, the TEE storage and comparison module 140 returns the verification result to the aspect function module 120.

[0051] Step S208: In response to the verification that the true integrity feature value matches the current integrity feature value, load the target plugin.

[0052] If the verification results show that the two are consistent, it indicates that the target plugin's code has not been modified since the baseline was established. The aspect function module 120 returns control to the original plugin loading function, and the target program 100 continues to complete the plugin loading and activation process. If the verification results show that the two are inconsistent, it indicates that the target plugin's code may have been tampered with. The aspect function module 120 does not return control to the original loading function but instead triggers a disposal process. The specific execution method of the disposal process will be explained in subsequent paragraphs.

[0053] Figure 2 The plugin integrity verification method shown can detect the plugin call process of the target program without modifying the target program or requiring the target program to be aware of it, and accurately identify potential plugin tampering risks.

[0054] In one embodiment of this specification, when determining the current integrity feature value of the target plugin, a preset hash algorithm is used to perform hash calculation on the running code of the target plugin to obtain the current integrity feature value. The preset hash algorithm can be a message digest algorithm such as SHA-256, SHA-512, or MD5. Taking SHA-256 as an example, this algorithm maps input data of arbitrary length to a fixed-length digest value of 256 bits (32 bytes). Assuming that the running code of the target plugin consists of three files: the entry file extension.js (approximately 12KB), the core logic file core.js (approximately 85KB), and the configuration file package.json (approximately 2KB), the aspect function module 120 combines the above files into a continuous data segment according to a preset concatenation rule (such as concatenating byte by byte after lexicographical order of filenames), performs SHA-256 operation on the continuous data segment, and obtains a hash value in the form of a 64-bit hexadecimal string, such as a3f2b8c91d4e..., which is the current integrity feature value.

[0055] In other implementations, the hash value of each file can be calculated separately, and then the hash values ​​of the files can be concatenated in a fixed order and a secondary hash calculated to obtain the current integrity feature value. Alternatively, digital signatures, CRC checks, or other methods can be used to generate the integrity feature value. This embodiment does not impose a unique limitation on the specific algorithm for generating the integrity feature value, as long as the algorithm has sufficient distinguishability for changes in the code content.

[0056] Figure 4 A flowchart illustrating the baseline establishment process in one embodiment of this specification is shown. Figure 4As shown, the true integrity feature value is determined according to the following steps: after the target plugin is installed, the initial integrity feature value of the target plugin is calculated using the same preset hash algorithm as the runtime detection; based on the initial integrity feature value, the true integrity feature value of the target plugin is determined.

[0057] The timing of baseline establishment is determined by the aspect base module 110. When the aspect base module 110 captures the plugin installation completion event of the target program 100 (e.g., the VSCode extensionInstalled event), it triggers the aspect function module 120 to execute the baseline establishment process. The aspect function module 120 uses the same hash algorithm and concatenation rules as in step S204 to calculate the initial integrity feature value for all runtime code files of the newly installed plugin. The same algorithm and rules as runtime detection are used here to ensure the comparability of the feature values ​​calculated in the baseline establishment phase and the runtime detection phase—if the two phases use different algorithms or different file concatenation orders, even if the plugin code has not been modified, the feature values ​​calculated in the two phases will be inconsistent, leading to misjudgment.

[0058] In one embodiment of this specification, the true integrity feature value is stored in the Trusted Execution Environment (TEE). When verifying whether the pre-stored true integrity feature value of the target plugin is consistent with the current integrity feature value, the aspect function module 120 initiates a comparison request to the TEE storage and comparison module 140 through a standard interface provided by the terminal TEE (such as the GlobalPlatform TEE Client API) based on the current integrity feature value and the identification information of the target plugin. The TEE storage and comparison module 140 retrieves the corresponding true integrity feature value within the TEE based on the plugin identifier, performs the comparison operation, and returns the comparison result to the aspect function module 120. Based on the returned result, the aspect function module 120 determines whether the true integrity feature value is consistent with the current integrity feature value.

[0059] Imagine if the comparison logic ran within the REE (Real Equipment Environment). A malicious program with high system privileges could hijack the execution flow of the comparison function, tamper with the comparison results, or bypass the comparison process. In this embodiment, the comparison operation is executed within the TEE rather than in a normal execution environment. The hardware isolation mechanism of the TEE prevents programs in the REE from accessing the internal storage area and execution environment of the TEE. The input (current integrity feature value), reference data (true integrity feature value), and output (comparison result) of the comparison process all flow within the security boundary of the TEE, reducing the risk of external interference with the comparison process.

[0060] In some implementations, the TEE storage and comparison module 140 can also use a secure storage interface (such as the GP TEESecure Storage API) to encrypt and store the true integrity feature value. The key is derived from the key management service inside the TEE, and the REE cannot obtain the decryption key.

[0061] In one embodiment of this specification, when determining the true integrity feature value based on the initial integrity feature value, cross-validation from an external trusted source is also introduced. Specifically, the multi-source baseline verification module 130 obtains the baseline integrity feature value of the target plugin from an external trusted source, which includes any combination of official marketplace signatures (i.e., the plugin platform's official signature), cloud-based trusted whitelists, and plugin publisher public key signatures. The multi-source baseline verification module 130 verifies whether the baseline integrity feature value is consistent with the initial integrity feature value. In response to the consistency verification, the initial integrity feature value is written as the true integrity feature value into the TEE.

[0062] For example, consider this scenario: A developer releases a formatting tool plugin called `code-formatter`, version 2.1.0, on the VSCode marketplace. After the user installs the plugin, the aspect function module 120 calculates the initial integrity feature value as `e7d9a1...`. The multi-source baseline verification module 130 then retrieves the signature hash value of plugin version 2.1.0 from the official signing service of the VSCode marketplace, and simultaneously queries the registered hash value of the plugin from the cloud-based trusted whitelist service. If both external baseline values ​​match the locally calculated `e7d9a1...`, this value is written to the TEE as the true integrity feature value. If either external baseline value is inconsistent with the locally calculated result—for example, the signature hash returned by the marketplace is `e7d9a1...` while the value returned by the cloud-based whitelist is `f8c3b2...`—then baseline establishment is refused, an alarm log is recorded, and a warning is issued indicating potential supply chain contamination or tampering during distribution.

[0063] In some implementations, at least two external trusted sources can be required to participate in cross-verification, rather than relying on a single trusted source. This is because a single trusted source itself can be compromised (for example, if an attacker compromises the cloud whitelist service and tampers with the registration hash value of a plugin, relying solely on the whitelist's verification mechanism will misclassify the tampered plugin as legitimate). Introducing cross-verification from two or more independent trusted sources requires attackers to compromise multiple independent systems simultaneously to complete the contamination, significantly increasing the attack cost.

[0064] In some implementations, the multi-source baseline verification module 130 can also introduce the plugin publisher's public key signature as a third verification source. When publishing a plugin, the plugin publisher uses their private key to sign the plugin package. The multi-source baseline verification module 130 uses the corresponding public key to verify the signature and extracts the hash value carried in the signature, performing a three-way comparison with the local calculation result and the marketplace signature.

[0065] In one embodiment of this specification, the TEE storage and comparison module 140 stores not only the true integrity feature values ​​of each plugin, but also the baseline state corresponding to each plugin. The baseline state is used to indicate the availability of the true integrity feature value of the plugin at the current moment.

[0066] Figure 5 A schematic diagram of the state transition of the baseline lifecycle is shown in one embodiment of this specification. For example... Figure 5 As shown, the baseline status includes the following five types: NEW (new installation, no baseline created), TRUSTED (baseline created and trusted), UPDATING (legally updating), SUSPENDED (disabled but baseline retained), and REVOKED (baseline revoked).

[0067] The transition rules between states are as follows: After the plugin is installed, the initial baseline state is NEW. After the multi-source baseline verification module 130 performs cross-validation and writes the true integrity feature value into the TEE, the baseline state transitions to TRUSTED. At this time, the true integrity feature value of the plugin can be used for runtime comparison. When the aspect base module 110 captures an update event initiated by the official channel, the baseline state transitions from TRUSTED to UPDATING. During the UPDATING state, runtime comparison is skipped to avoid misjudging code changes caused by legitimate updates as tampering. After the update is completed, the multi-source baseline verification is re-executed. If the verification passes, the original baseline is overwritten with the integrity feature value of the new version, and the baseline state transitions back to TRUSTED. If the verification fails, the baseline is rolled back to the previous version and an alarm is triggered. When the user actively disables the plugin, the baseline state transitions from TRUSTED to SUSPENDED. The baseline data is retained, but the plugin loading request will be rejected. When an external trusted source issues a revocation command (e.g., the marketplace marks a plugin as malicious), the baseline state is forcibly transitioned from the current state to REVOKED. The baseline is invalidated, and all subsequent loading requests for the plugin are blocked.

[0068] During the verification process in step S206, the return result from the TEE storage and comparison module 140 includes not only the conclusion of whether the comparison is consistent, but also the current baseline state of the target plugin. If the return result indicates that the true integrity feature value is unavailable—for example, the baseline state is REVOKED or SUSPENDED—then regardless of the comparison result between the current integrity feature value and the true integrity feature value, the aspect function module 120 terminates the loading of the target plugin. This mechanism ensures that plugins that have been officially revoked or disabled by users cannot be loaded and executed in any way.

[0069] In one embodiment of this specification, in response to a change operation targeting the target plugin, the TEE storage and comparison module 140 is invoked to update the baseline state of the target plugin. The change operation includes at least one of a user disabling operation, a plugin uninstallation operation, and a plugin update operation.

[0070] Specifically, the aspect base module 110 also incorporates a pointcut at the plugin management interface of the target program 100, covering entry points for plugin disabling, uninstalling, and updating operations. When a user disables a plugin through the management interface of the target program 100, the aspect base module 110 captures the disabling event, and the aspect function module 120 calls the TEE storage and comparison module 140 to migrate the plugin's baseline state from TRUSTED to SUSPENDED. When a user uninstalls a plugin, the aspect function module 120 calls the TEE storage and comparison module 140 to delete the baseline record corresponding to the plugin, releasing TEE storage space. When a plugin is updated through official channels, the aspect function module 120 first migrates the baseline state to UPDATING, and after the update is completed and passes multi-source baseline verification, it overwrites the baseline with the new version's integrity feature value and migrates the state back to TRUSTED.

[0071] For scenarios where multiple versions coexist, such as when target program 100 allows different versions of the same plugin to be installed simultaneously, the TEE storage and comparison module 140 maintains multiple baseline records for the same plugin identifier by version number. During runtime detection, the aspect function module 120 accurately matches the baseline record of the corresponding version according to the actual version number of the target plugin determined in step S202, avoiding confusion between baselines of different versions.

[0072] In one embodiment of this specification, in response to a discrepancy between the true integrity feature value and the current integrity feature value verification, at least one of the following operations is performed: logging, alarming, or terminating the loading of the target plugin. Figure 6 A logical diagram illustrating the configuration of a handling strategy in one embodiment of this specification is shown. Figure 6As shown, the handling strategy of the handling module 150 is stored in the local security directory, supporting differentiated configuration according to plugin type and risk level. For example, for high-privilege plugins involving file system access and network communication, it can be configured to directly intercept loading and trigger an alarm when verification is inconsistent; for low-privilege plugins that only involve interface aesthetics, it can be configured to only log and allow loading when verification is inconsistent, allowing the user to decide whether to continue using the plugin.

[0073] When performing the interception operation, the handling module 150 returns a preset error code or exception object to the plugin loading function of the target program 100, causing the target program 100 to complete the subsequent process according to its own error handling logic (such as prompting the user that the plugin loading failed). The handling module 150 does not modify the error handling logic of the target program 100, but only blocks the transmission of control flow on the loading chain.

[0074] In one embodiment of this specification, in response to the target program 100 reaching a threshold idle time, the current integrity feature value of all installed plugins is verified to be consistent with the corresponding true integrity feature value. This batch verification mechanism, as a supplement to runtime successive detection, is used to discover plugins that have been tampered with between two loads but have not yet been reloaded.

[0075] Specifically, the aspect-based base module 110 detects the activity status of the target program 100. When it detects that the target program 100 has not generated any new plugin loading requests or user interaction operations within a preset time period (e.g., 30 minutes), it determines that the target program 100 has entered an idle state and triggers the batch verification process. During batch verification, the aspect function module 120 traverses the local list of installed plugins, calculates the current integrity characteristic value of each plugin, and sends it to the TEE storage and comparison module 140 for comparison. For plugins that do not match the comparison, the corresponding operation is performed according to the preset strategy of the handling module 150. The execution priority of batch verification is lower than that of real-time loading detection. If the target program 100 generates a new plugin loading request during the batch verification process, the batch verification is paused, and real-time loading detection is processed first.

[0076] In other implementations, batch verification can also be triggered manually by the user or by the faceted base module 110 at a preset fixed period (such as every hour). This embodiment does not limit the triggering method of batch verification.

[0077] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0078] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0079] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0080] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0081] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0082] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0083] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0084] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0085] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0086] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0087] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0088] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0089] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0090] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0091] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for verifying the integrity of a plugin, the method relating to an aspect that starts in response to the startup of a target program, the aspect and the target program running in the same process, the method comprising: Obtain the call instructions from the target program for the plugin loading function; Based on the invocation instruction, the target plugin to be loaded is determined; Determine the current integrity feature value of the target plugin; Verify whether the pre-stored true integrity feature value of the target plugin is consistent with the current integrity feature value; In response to the verification that the true integrity feature value matches the current integrity feature value, the target plugin is loaded.

2. The method as described in claim 1, determining the current integrity feature value of the target plugin, specifically includes: The target plugin's running code is hashed using a preset hash algorithm to obtain the current integrity feature value.

3. The method as described in claim 2, wherein the true integrity feature value is determined according to the following steps: After the target plugin is installed, the initial integrity feature value of the target plugin is calculated using the preset hash algorithm; Based on the initial integrity feature value, the true integrity feature value of the target plugin is determined.

4. The method of claim 2, wherein, The true integrity feature value is stored in a trusted execution environment; Verifying whether the pre-stored true integrity feature value of the target plugin is consistent with the current integrity feature value specifically includes: Based on the current integrity feature value and the target plugin, the trusted execution environment is invoked to verify whether the current integrity feature value is consistent with the actual integrity feature value of the target plugin; Based on the return result from the trusted execution environment, determine whether the true integrity feature value is consistent with the current integrity feature value.

5. The method as described in claim 3, wherein determining the true integrity feature value of the target plugin based on the initial integrity feature value specifically includes: Obtain the baseline integrity feature value of the target plugin from an external trusted source, which includes at least two of the following: the plugin platform's official signature, a cloud-based trusted whitelist, and the plugin publisher's signature. Verify whether the baseline integrity feature value is consistent with the initial integrity feature value. In response to the verification that the baseline integrity feature value is consistent with the initial integrity feature value, use the initial integrity feature value as the true integrity feature value.

6. The method of claim 4, wherein, The trusted execution environment also stores the baseline state corresponding to the target plugin; The baseline status indicates the availability of the true integrity feature value; the returned result also includes the baseline status of the target plugin; The method further includes: If the returned result indicates that the true integrity feature value is unavailable, the loading of the target plugin will be terminated.

7. The method of claim 6, wherein, The method further includes: In response to a change operation for the target plugin, the trusted execution environment is invoked to update the baseline state of the target plugin, wherein the change operation includes at least one of a user disabling operation, a plugin uninstallation operation, and a plugin update operation.

8. The method of claim 1, further comprising: In response to a discrepancy between the true integrity feature value and the current integrity feature value, at least one of the following operations is performed: logging, alarm, or terminating the loading of the target plugin.

9. The method of claim 1, further comprising: In response to the target program's idle time reaching a threshold, verify whether the current integrity feature value of all installed plugins is consistent with the corresponding real integrity feature value.

10. A computing device comprising a memory and a processor, the memory storing executable code, wherein the processor, when executing the executable code, implements the method as claimed in any one of claims 1-9.

Images