Memory damage detection method and device, electronic equipment and readable storage medium

Abstract

The invention discloses a memory damage detection method and device, electronic equipment and a readable storage medium, and belongs to the technical field of memories. The method comprises the steps that under the condition that access operation for any target memory object is obtained, multiple real-time feature values of the target memory object are collected and based on the target memory object, and a real-time verification code to be verified is generated; obtaining a reference verification code of the target memory object from the target space; the reference verification code is generated based on a plurality of characteristic values of the collected target memory object at a historical moment; verifying the verification code to be verified based on the reference verification code, and continuing to execute the access operation under the condition that the verification code to be verified passes the verification; or, under the condition that the verification code to be verified does not pass verification, it is determined that the memory is damaged. The damage of the memory can be found in time, the process is realized through pure software, special hardware is not needed, only a small amount of extra memory is occupied, the performance overhead is small, and the real-time performance is high.

Description

Methods, devices, electronic equipment, and readable storage media for detecting memory corruption. Technical Field

[0001] This application belongs to the field of memory technology, and in particular relates to a method, apparatus, electronic device and readable storage medium for detecting memory damage. Background Technology

[0002] Random Access Memory (RAM) is a valuable resource in embedded systems. Function pointers, global variables, and function return addresses are critical memory objects. Damage to these three types of objects seriously threatens system security and stability. Therefore, timely detection of damage to memory objects is crucial for maintaining memory security and operating system security.

[0003] The hardware-level detection provided by related technologies relies on hardware modules such as MPU (Memory Protection Unit) and MMU (Memory Management Unit), which are not suitable for low-cost MCUs; the software-level protection and static analysis tools provided by related technologies can only detect single memory problems (such as stack protection only preventing stack overflow), and their real-time performance is poor. Summary of the Invention

[0004] This application aims to address at least one of the technical problems existing in the related art. To this end, this application proposes a method, apparatus, electronic device, and readable storage medium for detecting memory corruption, which can detect memory corruption in a timely manner. This process is implemented purely in software, requires no special hardware, occupies only a small amount of additional memory, has low performance overhead, and high real-time performance.

[0005] Firstly, this application provides a method for detecting memory corruption. The method includes: upon receiving an access operation targeting any target memory object, collecting and generating a real-time verification code based on multiple real-time feature values ​​of the target memory object; the target memory object is any one of a function pointer, a global variable, and a function return address; obtaining a reference verification code for the target memory object from the target space; the reference verification code is generated based on multiple feature values ​​of the target memory object collected at a historical time; the historical time is the operating system startup time, the time when a user with privileges modifies the feature values, or the time corresponding to the function entry point; verifying the verification code based on the reference verification code; if the verification code passes verification, continuing the access operation; or, if the verification code fails verification, determining that memory corruption exists.

[0006] The memory corruption detection method provided in this application embodiment can achieve integrated protection of multiple key objects such as function pointers, global variables, and function return addresses through multi-dimensional features. Since the verification code is generated by multiple feature values, any tampering with any feature value can cause the verification code to fail. This can effectively prevent attackers from forging legitimate verification codes and can detect memory corruption in a timely manner. This process is implemented in pure software, without the need for special hardware, and only occupies a small amount of additional memory. It has low performance overhead (it can be adapted to 8 / 16 / 32-bit MCUs, and is especially suitable for resource-constrained embedded devices), and has high real-time performance.

[0007] According to one embodiment of this application, the target space is a kernel secure area or a stack; obtaining the reference verification code of the target memory object from the target space includes: if the target memory object is a function pointer or a global variable, obtaining the reference verification code of the target memory object from the kernel secure area; or, if the target memory object is a function return address, obtaining the reference verification code of the target memory object from the stack of memory.

[0008] According to one embodiment of this application, before obtaining the reference verification code of the target memory object from the kernel secure area, the method further includes: at the startup time of the operating system, performing the following operations by the compiler: inserting a verification code initialization function into the program startup code by the compiler, executing the verification code initialization function to collect multiple feature values ​​corresponding to function pointers and global variables respectively; generating a reference verification code for the function pointer based on the multiple feature values ​​of the function pointer, and generating a reference verification code for the global variable based on the multiple feature values ​​of the global variable; storing the reference verification code for the function pointer and the reference verification code for the global variable in the kernel secure area, wherein there is physical isolation between the kernel secure area and the storage areas of the function pointer and the global variable in memory; and the user-level code does not have read and write permissions to the kernel secure area.

[0009] According to one embodiment of this application, before obtaining the reference verification code of the target memory object from the stack of memory, the method further includes: performing the following operations by the compiler: inserting verification code generation logic at the entry point of the protected function; executing the verification code generation logic to collect multiple feature values ​​of the function return address; generating a reference verification code for the function return address based on the multiple feature values ​​of the function return address; and storing the verification code of the function return address into the stack of memory.

[0010] According to one embodiment of this application, obtaining an access operation for any target memory object includes: obtaining a user's access operation for any object; if a target attribute is found among multiple attributes of the object, the target attribute is used to indicate that the object belongs to the target memory object; inserting verification code verification logic of the target memory object through a compiler; and executing the verification code verification logic of the target memory object to collect and generate a real-time verification code to be verified based on multiple feature values ​​of the target memory object.

[0011] According to one embodiment of this application, the verification logic for inserting a target memory object by the compiler includes: when the target memory object is a global variable, replacing the read instruction of the global variable with the verification logic for the global variable by the compiler; when the target memory object is a function pointer, replacing the function address of the function pointer with the verification logic for the function pointer by the compiler; and when the target memory object is a function return address, inserting the verification logic for the function return address at the exit of the protected function by the compiler.

[0012] According to one embodiment of this application, multiple feature values ​​include parameter values, storage location, and context information of a target memory object; based on the multiple feature values ​​of the target memory object, generating a verification code to be verified or a reference verification code includes: obtaining a system dynamic identifier; performing an addition operation on the parameter values, storage location, context information, and system dynamic identifier of the target memory object to obtain a first intermediate result; performing an XOR operation on the storage location and system dynamic identifier of the target memory object to obtain a second intermediate result; and performing an XOR operation on the first intermediate result and the second intermediate result to obtain the verification code to be verified or a reference verification code.

[0013] According to one embodiment of this application, the method further includes: verifying the user's permissions when a user modifies the parameter values ​​of function pointers and / or global variables through a target update interface; updating the parameter values ​​of function pointers and / or global variables in memory if the user's permissions are verified; and updating the reference verification code of function pointers and / or global variables in the kernel security zone based on the updated parameter values ​​of function pointers and / or global variables.

[0014] According to one embodiment of this application, the system dynamic identifier is used to identify the current startup of the operating system; the system dynamic identifier is generated based on the following methods: combining the task identifier of the operating system and the system startup timestamp to obtain the system dynamic identifier; or, if the operating system supports a true random number generator, generating a random number based on the true random number generator and using the random number as the system dynamic identifier.

[0015] According to one embodiment of this application, after the verification code fails to pass verification, the method further includes: performing at least one of the following operations: terminating the current task of the operating system; disabling related peripherals; recording log information related to the target memory object; the log information includes at least a portion of the object type, storage location, error value, verification code verification result, corruption occurrence timestamp, and current task identifier; inputting an alarm to an external system; the alarm is used to indicate that the memory is corrupted.

[0016] Secondly, this application provides a memory corruption detection device, comprising: a first processing module, configured to, upon receiving an access operation for any target memory object, collect and generate a real-time verification code based on multiple real-time feature values ​​of the target memory object; the target memory object is any one of a function pointer, a global variable, and a function return address; a second processing module, configured to obtain a reference verification code for the target memory object from the target space; the reference verification code is generated based on multiple feature values ​​of the target memory object collected at a historical time; the historical time is the operating system startup time, the time when a user with privileges modifies the feature values, or the time corresponding to the function entry point; a third processing module, configured to verify the verification code based on the reference verification code, and if the verification code passes verification, continue executing the access operation; or, if the verification code fails verification, determine that memory corruption exists.

[0017] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the memory corruption detection method provided in the first aspect above.

[0018] Fourthly, this application provides a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the memory corruption detection method provided in the first aspect above.

[0019] Fifthly, this application provides a chip including a processor and a communication interface coupled to the processor, the processor being used to run programs or instructions to implement the memory corruption detection method provided in the first aspect.

[0020] In a sixth aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the memory corruption detection method provided in the first aspect above.

[0021] The above-described one or more technical solutions in this application embodiment have at least one of the following technical effects: When an access operation targeting any target memory object is obtained, a real-time verification code to be verified is generated based on multiple real-time feature values ​​of the target memory object; a reference verification code for the target memory object is obtained from the target space; the reference verification code is generated based on multiple feature values ​​of the target memory object collected at a historical time; the historical time is the operating system startup time, the time when a user with privileges modifies the feature values, or the time corresponding to the function entry point; the verification code to be verified is verified based on the reference verification code; if the verification code to be verified passes the verification, then... Continue performing access operations; or, if the verification code fails to pass verification, it is determined that there is memory corruption. It can achieve integrated protection of multiple key objects such as function pointers, global variables, and function return addresses through multi-dimensional features. Since the verification code is generated by multiple feature values, any feature value being tampered with can cause the verification code to fail to pass verification, preventing attackers from forging legitimate verification codes. It can detect memory corruption in a timely manner. This process is implemented in pure software, without special hardware, occupies only a small amount of additional memory, has low performance overhead (it can be adapted to 8 / 16 / 32-bit MCUs, especially suitable for resource-constrained embedded devices), and has high real-time performance.

[0022] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0023] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments in conjunction with the following drawings, in which: FIG1 is a schematic flowchart of one of the memory corruption detection methods provided in the embodiments of this application; FIG2 is a system architecture diagram of the memory corruption detection method provided in the embodiments of this application; FIG3 is a schematic structural diagram of the memory corruption detection device provided in the embodiments of this application; FIG4 is a schematic structural diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0025] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0026] Memory is a valuable resource in embedded systems. For example, MCU memory is typically in the KB to MB range and has relatively low computing power. Within memory, function pointers, global variables, and function return addresses are three critical memory objects for normal program execution, and their integrity directly determines the system's stability and security. Currently, memory corruption targeting these three types of objects (such as buffer overflows modifying function pointers, stack overflows overwriting return addresses, and out-of-bounds access modifying global variables) has become a major method of network attacks. Currently, there are several methods for detecting memory corruption: a. Hardware-level protection: This relies on hardware modules such as the MPU (Memory Protection Unit) and MMU (Memory Management Unit). Memory can be divided into different regions with different access permissions (e.g., read-only / read-write / execute regions). However, this method is too coarse-grained and cannot detect out-of-bounds access within the same region (e.g., array index overflow modifying adjacent function pointers). Furthermore, low-cost MCUs typically do not integrate this type of hardware. In addition, most memory protection technologies require significant hardware resources (such as additional RAM / ROM) or computing power, making them unsuitable for resource-constrained embedded devices.

[0027] b. Software-level protection: Stack protection (such as the -fstack-protector compilation option of the GCC compiler) can only detect stack frame corruption and cannot cover multiple types of critical data such as global variables, function pointers, system objects, and memory pools; software-simulated memory marking (such as HWASAN) has a performance overhead of 2-5 times, which does not meet the real-time requirements of embedded systems; debugging tools (such as Valgrind) require a lot of memory and computing power, and are only suitable for the development stage and cannot be deployed on mass-produced devices.

[0028] c. Static analysis tools: can only detect potential risks at the static code level (such as uninitialized pointers), and cannot deal with memory corruption triggered dynamically at runtime (such as buffer overflows caused by network packet injection). The performance overhead of software simulation technology is too high, which makes embedded systems unable to meet the real-time task requirements of milliseconds or even microseconds.

[0029] To address the aforementioned technical problems, embodiments of this application provide a method, apparatus, electronic device, and readable storage medium for detecting memory corruption.

[0030] The memory corruption detection method, apparatus, electronic device, and readable storage medium provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0031] The memory corruption detection method provided in this application embodiment can be executed by an operating system, specifically a security monitoring program in the operating system.

[0032] As shown in Figure 1, the method for detecting memory corruption includes steps 110, 120, 130, 140, and 150.

[0033] Step 110: When an access operation for any target memory object is obtained, collect and generate a real-time verification code based on multiple feature values ​​of the target memory object in real time.

[0034] The operating system in this application refers to an embedded operating system.

[0035] The target memory object refers to a critical memory object protected by a protection mechanism. The target memory object can be any one of the following: a function pointer, a global variable, or a function return address. It can also be other memory objects, such as a memory pool.

[0036] When the operating system or an application accesses or uses the protected target memory object, the operating system will automatically trigger the CAPTCHA verification process.

[0037] Specifically, it collects multiple feature values ​​of the target memory object in real time, thereby generating a real-time verification code for the target memory object.

[0038] These multiple feature values ​​include at least the parameter value (V), storage location (Area), and context information (C) of the target memory object.

[0039] The parameter value of the target memory object, also known as its own value, refers to the value of the parameter.

[0040] The storage location of the target memory object refers to its storage address in memory.

[0041] The context information of a target memory object typically refers to the environment, state, and other information associated with that object and with which it interacts.

[0042] The system dynamic identifier can be obtained, which is used to identify the current startup of the operating system. Then, the parameter values, storage location, context information and system dynamic identifier of the target memory object are processed (including addition operation processing, XOR processing, etc.) to obtain a verification code to be verified.

[0043] Specifically, the parameter values, storage location, context information, and system dynamic identifier of the target memory object can be added to obtain the first intermediate result; then the storage location and system dynamic identifier of the target memory object can be XORed to obtain the second intermediate result; then the first and second intermediate results can be XORed to obtain the verification code to be verified or the reference verification code.

[0044] Function pointers, global variables, and function return addresses can all be used to generate real-time verification codes based on the above method.

[0045] Step 120: Obtain the reference verification code of the target memory object from the target space; the reference verification code is generated based on multiple feature values ​​of the target memory object collected at historical moments; the historical moments are the operating system startup moment, the moment when the authorized user modifies the feature values, or the moment corresponding to the function entry point.

[0046] In this embodiment of the application, after generating the verification code to be verified, it needs to be compared and verified with the reference verification code stored in the target space, which refers to the kernel security area and stack in memory.

[0047] The reference verification code is generated at a historical moment. For function pointers or global variables, this historical moment can be the operating system startup moment or the moment when a user with operating privileges modifies the feature value (usually the parameter value). For function return addresses, this historical moment is generally the moment corresponding to the function entry point.

[0048] The reference verification code is generated based on multiple feature values ​​of the target object at historical moments and the system dynamic identifier. The generation method of the reference verification code is the same as that of the verification code to be verified, that is, by processing the parameter values, storage location, context information and system dynamic identifier of the target memory object at historical moments (including addition operation processing, XOR processing, etc.) to obtain the reference verification code.

[0049] The reference verification code for function pointers or global variables is stored in the kernel security zone. This kernel security zone is physically isolated from the storage area of ​​function pointers or global variables in memory. Hardware access control mechanisms (such as MPU and ARM TrustZone) can be used to restrict read and write permissions to only privileged code (such as the RTOS kernel). In other words, user-level code does not have permission to access the kernel security zone. This prevents out-of-bounds access from simultaneously tampering with the target object and the verification code.

[0050] It is worth noting that, in order to reduce the latency of function calls, the reference verification code of the function return address is stored on the kernel stack.

[0051] Therefore, if the target memory object is a function pointer or a global variable, the reference verification code of the target memory object is obtained from the kernel security area; or if the target memory object is a function return address, the reference verification code of the target memory object is obtained from the stack of memory.

[0052] Furthermore, the steps of obtaining the reference verification code and generating the verification code to be verified can be performed in parallel.

[0053] Step 130: Verify the verification code to be verified based on the reference verification code, and determine whether the verification passes. If yes, proceed to step 130; otherwise, proceed to step 150. Step 140: If the verification code to be verified passes, continue to perform the access operation. Step 150: If the verification code to be verified fails, determine that there is memory corruption.

[0054] After generating the real-time verification code to be verified and the reference verification code, the verification code to be verified can be verified based on the reference verification code. That is, the reference verification code is compared with the verification code to be verified. If the two are the same or identical, it can be determined that the verification code to be verified has passed. In this case, the access operation can continue. If the two are different or inconsistent, it can be determined that the verification code to be verified has failed, indicating that the relevant feature value has been tampered with, indicating that there is memory corruption. In this case, the access operation can be refused and protective measures can be taken to effectively protect the operating system and avoid further damage to the system.

[0055] The security protection method provided in this application embodiment collects and generates a real-time verification code based on multiple feature values ​​of the target memory object when an access operation is obtained for any target memory object. A reference verification code for the target memory object is obtained from the target space. The reference verification code is generated based on multiple feature values ​​of the target memory object collected at a historical time. Historical times include the operating system startup time, the time when a user with privileges modifies the feature values, or the time corresponding to a function entry point. The verification code to be verified is then verified based on the reference verification code. If the verification code passes verification, the access operation continues; or, if the verification code fails verification, memory corruption is determined. This method achieves integrated protection for multiple key objects such as function pointers, global variables, and function return addresses through multi-dimensional features. Since the verification code is generated from multiple feature values, any tampering with any feature value can cause the verification code to fail verification, preventing attackers from forging legitimate verification codes and enabling timely detection of memory corruption. This process is implemented purely in software, requiring no special hardware, consuming only a small amount of additional memory, and has low performance overhead (adaptable to 8 / 16 / 32-bit MCUs, especially suitable for resource-constrained embedded devices), and has high real-time performance.

[0056] In some embodiments, the target space is the kernel secure area or the stack; obtaining the reference verification code of the target memory object from the target space includes: if the target memory object is a function pointer or a global variable, obtaining the reference verification code of the target memory object from the kernel secure area; or, if the target memory object is a function return address, obtaining the reference verification code of the target memory object from the stack of memory.

[0057] As explained in the foregoing embodiments, the reference verification code of function pointers or global variables is stored in the kernel secure area to prevent external tampering; while the function return address is stored in the stack because the stack itself is an efficient data structure for handling function calls and returns, in order to reduce the latency of function calls, which will not be elaborated further here.

[0058] In some embodiments, before obtaining the reference verification code of the target memory object from the kernel secure area, the method further includes: at the operating system startup time, performing the following operations by the compiler: inserting a verification code initialization function into the program startup code by the compiler, executing the verification code initialization function to collect multiple feature values ​​corresponding to function pointers and global variables respectively; generating a reference verification code for the function pointer based on the multiple feature values ​​of the function pointer, and generating a reference verification code for the global variable based on the multiple feature values ​​of the global variable; storing the reference verification code for the function pointer and the reference verification code for the global variable in the kernel secure area, wherein there is physical isolation between the kernel secure area and the storage areas of the function pointer and the global variable in memory; and user-level code does not have read and write permissions to the kernel secure area.

[0059] The compiler automatically inserts the verification code initialization function pdv_global_init() into the program startup code (such as startup.s, C library initialization function __libc_init_array). This verification code initialization function is used to indicate the reference verification codes corresponding to the generated function pointers and global variables.

[0060] When the verification code initialization function is executed, multiple feature values ​​corresponding to function pointers and global variables are collected. Based on the multiple feature values ​​of the function pointer, a reference verification code for the function pointer is generated, and based on the multiple feature values ​​of the global variable, a reference verification code for the global variable is generated. The reference verification codes of the function pointer and the global variable are stored in the kernel secure area. That is, the feature collection, verification code generation, and secure area storage of global variables and function pointer objects are completed before the execution of the main function, without the need for manual invocation by the developer.

[0061] The kernel security area refers to a separate memory segment created during the code linking phase by the linker script, used to store reference verification codes. Taking an ARM Cortex-M embedded system as an example, the linker script is defined as follows: MEMORY { / / Code and read-only data area FLASH (rx): ORIGIN = 0x08000000, LENGTH = 512K / / Ordinary data and stack area (including global variables and function pointers) RAM (rwx): ORIGIN = 0x20000000, LENGTH = 128K / / Kernel security area (stores verification codes) PDV_SECURE (rwx): ORIGIN = 0x20020000, LENGTH = 8K} SECTIONS {.pdv_secure : {. = ALIGN(4);PROVIDE(pdv_secure_start = .);*(.pdv_ptr_codes) / / Function pointer verification code storage segment*(.pdv_var_codes) / / The global variable verification code storage segment PROVIDE(pdv_secure_end = .);}>PDV_SECURE / / Mapped to an independent secure memory region} In some embodiments, before retrieving the reference verification code of the target memory object from the memory stack, the method further includes: performing the following operations by the compiler: inserting verification code generation logic at the entry point of the protected function; executing the verification code generation logic to collect multiple feature values ​​of the function return address; generating a reference verification code for the function return address based on the multiple feature values ​​of the function return address; and storing the verification code of the function return address to the memory stack.

[0062] Protecting a function's entry point refers to a series of security checks or preparatory operations performed before a function is called and begins execution. Protecting a function's exit point refers to protective operations performed after the function has finished executing and before it returns, ensuring that the function's return value is correct, the integrity of the stack is restored, and the execution of the return instruction has not been tampered with.

[0063] Therefore, when the target memory object is the return address of a function, its corresponding reference verification code is usually generated at the entry point of the protection function and verified at the exit point of the protection function.

[0064] Specifically, for the function return instruction (ret), the verification code generation logic pdv_verify_gen is inserted at the entry point of the protected function, and the verification code pdv_verify_ret verification logic is inserted at the exit point of the protected function.

[0065] In some embodiments, obtaining an access operation for any target memory object includes: obtaining a user's access operation for any object; if a target attribute is found among multiple attributes of the object, the target attribute is used to indicate that the object belongs to the target memory object; inserting the verification code verification logic of the target memory object through the compiler; and executing the verification code verification logic of the target memory object to collect and generate a real-time verification code to be verified based on multiple feature values ​​of the target memory object.

[0066] Developers can mark objects that need to be protected by using the compiler-defined attribute __attribute__((pdv_protect)), as shown in the following example: / / Mark global variables (basic types) that need to be protected int g_sensor_config __attribute__((pdv_protect)) = 0x0001; / / Mark global variables (array types) that need to be protected char g_device_id

[16] __attribute__((pdv_protect)) = "DEV-Sensor"; / / Mark function pointers that need to be protected __attribute__((pdv_protect)) void (*func_ptr)(void) =&normal_func; / / Mark functions that need to be protected (protect function return address) __attribute__((pdv_protect)) int sensor_init(void){ ...} For any memory object that is accessed, if it is determined that it has the custom target attribute __attribute__((pdv_protect)), then the memory object can be determined as the target memory object.

[0067] As described in the foregoing embodiments, for the function return address, verification code generation logic is inserted at the entry point of the protected function, and verification code verification logic is inserted at the exit point of the protected function.

[0068] For global variables or function pointers, the reference verification code is generated when the operating system starts up or when a user with privileges modifies the parameter value, while the corresponding verification code to be verified is generated when the user accesses the target memory object.

[0069] Specifically, after the compiler front-end (such as Clang) recognizes the pdv_protect attribute, it passes the marking information to the intermediate code generation stage (LLVM IR); the compiler back-end automatically inserts CAPTCHA verification logic through a custom Pass (such as LLVM Pass), and then executes the CAPTCHA verification logic to collect and generate a real-time CAPTCHA to be verified based on multiple feature values ​​of the target memory object.

[0070] In some embodiments, the compiler inserts verification code validation logic for the target memory object, including: when the target memory object is a global variable, the compiler replaces the read instruction of the global variable with the verification code validation logic for the global variable; when the target memory object is a function pointer, the compiler replaces the function address of the function pointer with the verification code validation logic for the function pointer; when the target memory object is a function return address, the compiler inserts the verification code validation logic for the function return address at the exit of the protected function.

[0071] When the system or user performs a read operation on the marked global variable, the load instruction is replaced by a pdv_verify_data function call, which is the verification logic for the global variable's verification code.

[0072] When a function pointer is called, pdv_verify_ptr verification logic is inserted. This pdv_verify_ptr verification logic is the verification code logic for the function pointer.

[0073] For the function return instruction (ret), the verification code generation logic pdv_verify_gen is inserted at the entry point of the protected function, and the verification logic pdv_verify_ret is inserted at the exit point. This pdv_verify_ret verification logic is the verification code verification logic of the function return address.

[0074] In some embodiments, the multiple feature values ​​include the parameter values, storage location, and context information of the target memory object; generating a verification code to be verified or a reference verification code based on the multiple feature values ​​of the target memory object includes: obtaining a system dynamic identifier; performing an addition operation on the parameter values, storage location, context information, and system dynamic identifier of the target memory object to obtain a first intermediate result; performing an XOR operation on the storage location and system dynamic identifier of the target memory object to obtain a second intermediate result; and performing an XOR operation on the first intermediate result and the second intermediate result to obtain the verification code to be verified or the reference verification code.

[0075] In some embodiments, the system dynamic identifier is used to identify the current startup of the operating system; the system dynamic identifier is generated based on the following methods: combining the operating system's task identifier and the system startup timestamp to obtain the system dynamic identifier; or, if the operating system supports a true random number generator, generating a random number based on the true random number generator and using the random number as the system dynamic identifier.

[0076] Specifically, when the embedded system starts up, a unique system dynamic identifier (represented by S) is generated, supporting two generation methods: Basic mode: generated based on the system's task ID and system startup timestamp, for example, TaskID=0x4456444E, BootTime=0x12345678, then S = TaskID + BootTime = 0x568A9AC6; Enhanced mode: if the hardware supports TRNG (True Random Number Generator), a random number can be generated by calling TRNG, and the random number is used as the system dynamic identifier to ensure that the dynamic identifier is different each time it starts up.

[0077] For three types of objects—function pointers, global variables, and function return addresses—the system automatically collects feature values ​​from three dimensions during their creation or initialization phases (such as global variable initialization, function pointer assignment, and function return address push onto the stack) to generate corresponding reference verification codes.

[0078] The feature values ​​of different objects are dynamically adapted according to their attributes to ensure the uniqueness of the features and their association with the scene. Please refer to Table 1 below for details.

[0079] Referring to Table 1 below, this application embodiment provides specific information corresponding to the parameter values, storage location, and context information of the target memory object:

[0080] Table 1 shows that the operating system generates a reference verification code (InitCode) based on the system dynamic identifier S and three feature values ​​V, A, and C using a preset lightweight hybrid algorithm. The preset default algorithm is: InitCode = (V + A + C + S) ^ (A ^ S), where "+" is 32-bit unsigned addition and "^" is XOR operation. This algorithm ensures that even a small change in any feature value (such as modifying the global variable value by 1 bit) will result in a significantly different verification code. The algorithm can also be customized through the system interface.

[0081] The first intermediate result is "V + A + C + S", and the second intermediate result is "A ^ S".

[0082] Specifically, based on the data in Table 1, the reference verification code or the verification code to be verified for the function pointer can be generated based on the following expression: InitCode1 = (Ptr_Value + Ptr_Addr + Caller_ID + S) ^ (Ptr_Addr ^ S), where InitCode1 represents the reference verification code or the verification code to be verified for the function pointer, Ptr_Value represents the parameter value of the function pointer (i.e., the address of the target function pointed to by the function pointer in memory), Ptr_Addr represents the storage location of the function pointer, and Caller_ID represents the context information of the function pointer (i.e., the calling function ID).

[0083] For global variables, the reference verification code or the verification code to be verified can be generated based on the following expression: InitCode 2 = (Var_Value + Var_Addr + Var_Attr + S) ^ (Var_Addr ^ S), where InitCode2 represents the reference verification code or the verification code to be verified for the global variable, Var_Value represents the parameter value of the global variable (i.e., basic type variables directly take their value; complex types such as structures take the XOR value of all member characteristic values), Var_Addr represents the storage location of the global variable, and Var_Attr represents the context information of the global variable (i.e., variable attributes, whether read-only or read-write, identified by a bitmask).

[0084] The reference verification code or verification code to be verified for the function return address can be generated based on the following expression: InitCode 3 = (Ret_Addr + Stack_Pos + Stack_Base + S) ^ (Stack_Pos ^S), where InitCode3 represents the reference verification code or verification code to be verified for the function return address, Ret_Addr represents the parameter value of the function return address (i.e., the return instruction address pushed onto the stack frame when the function is called), Stack_Pos represents the storage location of the function return address, and Stack_Base represents the context information of the function return address (i.e., the stack frame base address).

[0085] This application's embodiments ensure that the verification code cannot be statically forged through multi-dimensional feature binding (V+A+C+S), isolate storage to prevent the reference verification code and the target memory object from being tampered with simultaneously, and the system's dynamic identifier Secret is generated based on dynamic information or TRNG, making it difficult for attackers to forge. In addition, the verification code adopts lightweight generation logic, requiring only 5 algorithm operations (three additions and two XORs) and only a few instructions, with minimal performance overhead.

[0086] In addition, since it supports custom CAPTCHA algorithms and error handling strategies, the enhanced mode (such as TRNG and TrustZone collaboration) can be turned on / off according to the needs of the scenario, and the protection strength can be flexibly adjusted.

[0087] In some embodiments, the method further includes: verifying the user's permissions when a user modifies the parameter values ​​of function pointers and / or global variables through a target update interface; updating the parameter values ​​of function pointers and / or global variables in memory if the user's permissions are verified; and updating the reference verification code of function pointers and / or global variables in the kernel security zone based on the updated parameter values ​​of function pointers and / or global variables.

[0088] This application embodiment supports users to legally modify the parameter values ​​of protected function pointers and global variables. Here, parameter values ​​usually refer to parameter values ​​that need to be executed through a dedicated interface (such as os_pdv_update) to verify user permissions. For example, it determines whether the user is in RTOS kernel mode or whether the authorized task is executable. If so, it means that the user permission verification is successful; if not, it means that the user permission verification is unsuccessful, and the corresponding parameter value update is refused.

[0089] If user permission verification is successful, the parameter values ​​of function pointers and / or global variables in memory can be updated. Following the aforementioned algorithm for calculating InitCode, the updated parameter values ​​of function pointers and / or global variables are generated, and the reference verification code InitCode of function pointers and / or global variables in the kernel security area is updated to ensure that subsequent verifications are based on the latest data.

[0090] In some embodiments, the system dynamic identifier is used to identify the current startup of the operating system; the system dynamic identifier is generated based on the following methods: combining the operating system's task identifier and the system startup timestamp to obtain the system dynamic identifier; or, if the operating system supports a true random number generator, generating a random number based on the true random number generator and using the random number as the system dynamic identifier.

[0091] In some embodiments, after the verification code fails to be verified, the method further includes performing at least one of the following operations: terminating the current task of the operating system; disabling related peripherals; recording log information related to the target memory object; the log information includes at least a portion of the object type, storage location, error value, verification code verification result, timestamp of the corruption occurrence, and identifier of the current task; inputting alarm information to an external system; the alarm information is used to indicate that the memory is corrupted.

[0092] When memory corruption is detected, the system calls the central error handling function (which can be customized by the user through the system interface). Users can execute preset protective measures within the error handling function, supporting three types of response strategies: 1. Emergency Protection: For safety-critical scenarios (such as automotive electronics), terminate the current task to prevent the damage from spreading; disable related peripherals; trigger system reset, etc.; 2. Log Recording: Record corruption information to non-volatile storage (such as EEPROM, Flash), including: corrupted data type (such as "function pointer"), data address, current error value; verification code comparison result (InitCode, CurCode); timestamp of corruption occurrence, and current running task ID; 3. Alarm Notification: Notify external systems through hardware interfaces (such as LED lights) or software interfaces (such as sending alarms to the gateway) to facilitate fault location.

[0093] Referring to Figure 2, this application embodiment provides a system architecture diagram of a method for detecting memory corruption, including a detection protection object layer, a compiler extension layer, a runtime core layer, and a hardware adapter.

[0094] The compiler extension layer identifies the target attributes (__attribute__((pdv_protect)) of the target memory object through the compiler front-end, and performs code instrumentation such as CAPTCHA verification logic through the compiler back-end.

[0095] The detection protection layer can detect accesses by the operating system or application to target memory objects such as function pointers, global variables, and function return addresses.

[0096] The runtime core layer can collect multiple feature values ​​of the target memory object and manage the verification code, that is, generate a real-time verification code to be verified, verify the verification code to be verified based on the reference verification code, and perform access control based on the verification result. That is, if the verification code to be verified passes the verification, the access operation continues to be executed; if the verification code to be verified fails the verification, protective measures are taken.

[0097] In addition, the runtime core layer can update the reference verification code of the target memory object based on the modification operations of the user on the target memory object.

[0098] The hardware adapter is an optional module and may include a TRNG module, a TrustZone module, and an alarm module. The TRNG module can generate a dynamic system identifier, the TrustZone module can select the mode for generating the dynamic system identifier (enable or disable basic mode, enhanced mode, etc.), and the alarm module can output an alarm when the verification code fails to be verified.

[0099] The detailed execution process of each layer is described in the aforementioned method implementation examples, and will not be repeated here.

[0100] Employing a unified protection framework of "multi-dimensional feature value binding, dynamic CAPTCHA verification, storage isolation, and compiler automatic instrumentation," a "reference CAPTCHA" is generated and stored during the initialization phase. Before data access or use, the CAPTCHA to be verified is recalculated and compared with the reference CAPTCHA. If they do not match, memory corruption is detected, and a response is triggered. The CAPTCHA is generated jointly by "data attributes, context information, and system dynamic identifiers," ensuring unpredictability and uniqueness, preventing attackers from forging legitimate CAPTCHAs. Furthermore, the CAPTCHA uses lightweight generation logic, requiring only 5 algorithmic operations (three additions and two XOR operations) and a few instructions, resulting in minimal performance overhead. It supports multiple types of protected objects, including function pointers, stack return addresses, and global data, overcoming the limitations of traditional technologies that only provide "single-scenario protection."

[0101] The memory corruption detection method provided in this application can be executed by a memory corruption detection device. This application uses the execution of the memory corruption detection method by a memory corruption detection device as an example to illustrate the memory corruption detection device provided in this application.

[0102] This application also provides a device for detecting memory corruption.

[0103] As shown in Figure 3, the memory corruption detection device includes: a first processing module 310, a second processing module 320, and a third processing module 330.

[0104] The first processing module 310 is used to collect and generate a real-time verification code based on multiple real-time feature values ​​of the target memory object when an access operation for any target memory object is obtained; the target memory object is any one of function pointer, global variable, and function return address; the second processing module 320 is used to obtain a reference verification code of the target memory object from the target space; the reference verification code is generated based on multiple feature values ​​of the target memory object collected at a historical time; the historical time is the operating system startup time, the time when the authorized user modifies the feature values, or the time corresponding to the function entry point; the third processing module 330 is used to verify the verification code to be verified based on the reference verification code, and if the verification code to be verified passes the verification, the access operation continues; or, if the verification code to be verified fails the verification, it is determined that there is memory corruption.

[0105] According to the memory corruption detection device provided in this application embodiment, when an access operation is obtained for any target memory object, a real-time verification code to be verified is generated based on multiple real-time feature values ​​of the target memory object. A reference verification code for the target memory object is obtained from the target space. The reference verification code is generated based on multiple feature values ​​of the target memory object collected at a historical time. The historical time is the operating system startup time, the time when a user with authorization modifies the feature values, or the time corresponding to the function entry. The verification code to be verified is verified based on the reference verification code. If the verification code to be verified passes the verification, the access operation continues. Or, if the verification code to be verified fails the verification, memory corruption is determined. This device can achieve integrated protection of multiple key objects such as function pointers, global variables, and function return addresses through multi-dimensional features. Since the verification code is generated by multiple feature values, any tampering with any feature value can cause the verification code to fail the verification, preventing attackers from forging legitimate verification codes and timely detection of memory corruption. This process is implemented purely in software, requiring no special hardware, occupying only a small amount of additional memory, with low performance overhead (adaptable to 8 / 16 / 32-bit MCUs, especially suitable for resource-constrained embedded devices), and has high real-time performance.

[0106] In some embodiments, the target space is the kernel secure area or the stack; the second processing module 320 is configured to: obtain the reference verification code of the target memory object from the kernel secure area when the target memory object is a function pointer or a global variable; or, obtain the reference verification code of the target memory object from the stack of memory when the target memory object is a function return address.

[0107] In some embodiments, the memory corruption detection device further includes: a fourth processing module, configured to: at the operating system startup time, perform the following operations by the compiler: insert a verification code initialization function into the program startup code by the compiler, execute the verification code initialization function to collect multiple feature values ​​corresponding to function pointers and global variables respectively; generate a reference verification code for the function pointer based on the multiple feature values ​​of the function pointer, and generate a reference verification code for the global variable based on the multiple feature values ​​of the global variable; store the reference verification code for the function pointer and the reference verification code for the global variable in the kernel secure area, wherein there is physical isolation between the kernel secure area and the storage area of ​​the function pointer and the global variable in memory; and user-level code does not have read and write permissions to the kernel secure area.

[0108] In some embodiments, the fourth processing module is further configured to: perform the following operations through the compiler: insert verification code generation logic into the entry point of the protected function; execute the verification code generation logic to collect multiple feature values ​​of the function return address; generate a reference verification code for the function return address based on the multiple feature values ​​of the function return address; and store the verification code of the function return address into the stack in memory.

[0109] In some embodiments, the first processing module 310 is specifically used to: obtain user access operations on any object; when it is determined that a target attribute exists among multiple attributes of the object, the target attribute is used to indicate that the object belongs to a target memory object; insert the verification code verification logic of the target memory object through the compiler; execute the verification code verification logic of the target memory object to collect and generate a real-time verification code to be verified based on multiple feature values ​​of the target memory object.

[0110] In some embodiments, the third processing module 330 is configured to: replace the read instruction of the global variable with the verification code verification logic of the global variable by the compiler when the target memory object is a global variable; replace the function address of the function pointer with the verification code verification logic of the function pointer by the compiler when the target memory object is a function pointer; and insert the verification code verification logic of the function return address at the exit of the protected function by the compiler when the target memory object is a function return address.

[0111] In some embodiments, the multiple feature values ​​include the parameter values, storage location, and context information of the target memory object; the memory corruption detection device further includes: a fifth processing module, used to generate a verification code to be verified or a reference verification code based on the multiple feature values ​​of the target memory object in the following manner: obtaining a system dynamic identifier; performing an addition operation on the parameter values, storage location, context information, and system dynamic identifier of the target memory object to obtain a first intermediate result; performing an XOR operation on the storage location and system dynamic identifier of the target memory object to obtain a second intermediate result; and performing an XOR operation on the first intermediate result and the second intermediate result to obtain the verification code to be verified or the reference verification code.

[0112] In some embodiments, the memory corruption detection device further includes: a sixth processing module, configured to: verify the user's permissions when a user modifies the parameter values ​​of function pointers and / or global variables through a target update interface; update the parameter values ​​of function pointers and / or global variables in memory if the user's permissions are verified; and update the reference verification code of function pointers and / or global variables in the kernel security area based on the updated parameter values ​​of function pointers and / or global variables.

[0113] In some embodiments, the system dynamic identifier is used to identify the current startup of the operating system; the system dynamic identifier is generated based on the following methods: combining the operating system's task identifier and the system startup timestamp to obtain the system dynamic identifier; or, if the operating system supports a true random number generator, generating a random number based on the true random number generator and using the random number as the system dynamic identifier.

[0114] In some embodiments, the memory corruption detection device further includes: a seventh processing module, configured to perform at least one of the following operations: terminating the current task of the operating system; disabling related peripherals; recording log information related to the target memory object; the log information includes at least a portion of the object type, storage location, error value, verification code result, corruption occurrence timestamp, and current task identifier; inputting an alarm to an external system; the alarm is used to indicate that the memory is corrupted.

[0115] The memory corruption detection device in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the device.

[0116] The memory corruption detection device in this application embodiment can be a device with an operating system. This operating system can be a Microsoft (Windows) operating system, an Android operating system, an iOS operating system, or other possible operating systems; this application embodiment does not specifically limit it.

[0117] The memory corruption detection device provided in this application embodiment can implement the various processes implemented in the method embodiment of FIG1. ​​To avoid repetition, it will not be described again here.

[0118] In some embodiments, as shown in FIG4, this application embodiment also provides an electronic device 400, including a processor 401, a memory 402, and a computer program stored on the memory 402 and executable on the processor 401. When the program is executed by the processor 401, it implements the various processes of the above-described memory corruption detection method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0119] Processor 401 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 401 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0120] The memory 402 may be a ROM (Read Only Memory) or other type of static storage device capable of storing static information and instructions, RAM (Random Access Memory) or other type of dynamic storage device capable of storing information and instructions, or it may be an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.

[0121] The memory 402 is used to store computer programs that execute the embodiments of this application, and the execution is controlled by the processor 401. The processor 401 is used to execute the computer programs stored in the memory 402 to implement the steps shown in the foregoing method embodiments.

[0122] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0123] This application also provides a non-transitory computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described memory corruption detection method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0124] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0125] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method for detecting memory corruption.

[0126] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0127] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described memory corruption detection method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0128] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0129] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, 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, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0130] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the related technology, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0131] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

[0132] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. 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 may be combined in any suitable manner in one or more embodiments or examples.

[0133] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

Claims

1. A method for detecting memory corruption, characterized in that, include: Upon receiving an access operation for any target memory object, the system collects and generates a real-time verification code based on multiple real-time feature values ​​of the target memory object. The target memory object can be any one of a function pointer, a global variable, or a function return address. Obtain the reference verification code of the target memory object from the target space; The reference verification code is generated based on multiple feature values ​​of the target memory object collected at historical moments; the historical moments are the operating system startup moment, the moment when a user with privileges modifies the feature values, or the moment corresponding to the function entry point; The verification code to be verified is verified based on the reference verification code. If the verification code to be verified passes the verification, the access operation continues; or, if the verification code to be verified fails the verification, it is determined that there is memory corruption.

2. The method for detecting memory corruption according to claim 1, characterized in that, The target space is the kernel secure area or the stack; obtaining the reference verification code of the target memory object from the target space includes: obtaining the reference verification code of the target memory object from the kernel secure area when the target memory object is the function pointer or the global variable; or, obtaining the reference verification code of the target memory object from the stack of the memory when the target memory object is the function return address.

3. The method for detecting memory corruption according to claim 2, characterized in that, Before obtaining the reference verification code of the target memory object from the kernel secure area, the method further includes: at the startup time of the operating system, performing the following operations by the compiler: inserting a verification code initialization function into the program startup code by the compiler, executing the verification code initialization function to collect multiple feature values ​​corresponding to the function pointer and global variables respectively; generating a reference verification code for the function pointer based on the multiple feature values ​​of the function pointer, and generating a reference verification code for the global variables based on the multiple feature values ​​of the global variables; storing the reference verification code for the function pointer and the reference verification code for the global variables in the kernel secure area, wherein there is physical isolation between the kernel secure area and the storage area of ​​the function pointer and the global variables in memory; and user-level code does not have read and write permissions to the kernel secure area.

4. The method for detecting memory corruption according to claim 3, characterized in that, Before retrieving the reference verification code of the target memory object from the stack of the memory, the method further includes: performing the following operations by the compiler: inserting verification code generation logic at the entry point of the protected function; executing the verification code generation logic to collect multiple feature values ​​of the function return address; generating a reference verification code for the function return address based on the multiple feature values ​​of the function return address; and storing the verification code of the function return address into the stack of the memory.

5. The method for detecting memory corruption according to claim 1, characterized in that, The process of obtaining an access operation for any target memory object includes: obtaining a user's access operation for any object; if a target attribute is found among multiple attributes of the object, the target attribute is used to indicate that the object belongs to the target memory object; inserting the verification code verification logic of the target memory object through the compiler; and executing the verification code verification logic of the target memory object to collect and generate a real-time verification code based on multiple feature values ​​of the target memory object.

6. The method for detecting memory corruption according to claim 5, wherein the verification logic of inserting a verification code into the target memory object through the compiler includes: When the target memory object is the global variable, the compiler replaces the read instruction of the global variable with the verification code logic of the global variable; When the target memory object is a function pointer, the compiler replaces the function address of the function pointer with the verification code logic of the function pointer; when the target memory object is a function return address, the compiler inserts the verification code logic of the function return address at the exit of the protected function.

7. The method for detecting memory corruption according to any one of claims 2-4, characterized in that, The multiple feature values ​​include the parameter values, storage location, and context information of the target memory object; Generating a verification code or reference verification code based on multiple feature values ​​of a target memory object includes: obtaining a system dynamic identifier; performing an addition operation on the parameter value, storage location, context information, and system dynamic identifier of the target memory object to obtain a first intermediate result; performing an XOR operation on the storage location and system dynamic identifier of the target memory object to obtain a second intermediate result; and performing an XOR operation on the first intermediate result and the second intermediate result to obtain the verification code or reference verification code.

8. The method for detecting memory corruption according to claim 7, characterized in that, The method further includes: verifying the user's permissions when a user modifies the parameter values ​​of a function pointer and / or a global variable through a target update interface; updating the parameter values ​​of the function pointer and / or the global variable in memory if the user's permissions are verified; and updating the reference verification code of the function pointer and / or the global variable in the kernel security zone based on the updated parameter values ​​of the function pointer and / or the global variable.

9. The method for detecting memory corruption according to claim 7, characterized in that, The system dynamic identifier is used to identify the current startup of the operating system; the system dynamic identifier is generated based on the following methods: combining the task identifier of the operating system and the system startup timestamp to obtain the system dynamic identifier; or, if the operating system supports a true random number generator, generating a random number based on the true random number generator and using the random number as the system dynamic identifier.

10. The method for detecting memory corruption according to claim 1, characterized in that, After the verification code fails to pass verification, the method further includes: performing at least one of the following operations: terminating the current task of the operating system; disabling related peripherals; recording log information related to the target memory object; the log information includes at least a portion of object type, storage location, error value, verification code result, timestamp of corruption occurrence, and identifier of the current task; inputting an alarm to an external system; the alarm is used to indicate that the memory is corrupted.

11. A device for detecting memory corruption, characterized in that, The first processing module is used to collect and generate a real-time verification code based on multiple real-time feature values ​​of the target memory object when an access operation for any target memory object is obtained. The target memory object can be any one of a function pointer, a global variable, or a function return address. The second processing module is used to obtain the reference verification code of the target memory object from the target space; The reference verification code is generated based on multiple feature values ​​of the target memory object collected at historical moments; the historical moments are the operating system startup moment, the moment when a user with privileges modifies the feature values, or the moment corresponding to the function entry point; The third processing module is used to verify the verification code to be verified based on the reference verification code. If the verification code to be verified passes the verification, the access operation continues; or, if the verification code to be verified fails the verification, it is determined that there is memory corruption.

12. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the memory corruption detection method as described in any one of claims 1-10.

13. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the memory corruption detection method as described in any one of claims 1-10.

Images