A vulnerability detection method and device, a storage medium and an electronic device

Abstract

Embodiments of the present specification disclose a vulnerability detection method and device, a storage medium and an electronic device, wherein the method comprises: configuring a vulnerability detection kernel function and a target exception handling function in a kernel space of a vehicle operating system, starting a preset hardware access protection mechanism based on the vulnerability detection kernel function, the preset hardware access protection mechanism is used to trigger an access exception state when requesting access to a user space memory through an operating system interface in the kernel space, jumping to the vulnerability detection kernel function when monitoring the access exception state through the target exception handling function each time, recording memory access information corresponding to the access exception state through the vulnerability detection kernel function and restoring the kernel access execution process, performing double acquisition vulnerability detection processing on the operating system interface based on each memory access information, and obtaining a double acquisition vulnerability detection result.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a vulnerability detection method, apparatus, storage medium, and electronic device. Background Technology

[0002] The operating system of intelligent connected vehicles, as a highly complex microkernel real-time operating system integrating real-time, security, and reliability requirements, must effectively support the deployment and operation of various intelligent applications. It must also handle task and resource scheduling among the vehicle's complex hardware resources (including high-performance chips) and diverse upper-layer intelligent application software, providing the basic environment and operational guarantees for realizing various vehicle functions. Typically, vulnerabilities in the operating system of intelligent connected vehicles can be used to implement remote code execution (RCE), local privilege escalation (LPE), or trigger system crashes (DoS), directly leading to abnormalities in critical vehicle functions or even complete system failure. In extreme cases, it may even cause the vehicle control system to crash, resulting in the vehicle becoming unresponsive or uncontrollable, seriously endangering driving safety. Furthermore, if system privileges in an intelligent connected vehicle are gained through vulnerabilities, backdoor programs can be implanted, thereby stealing sensitive information such as vehicle location, owner identity, and operation logs, as well as engaging in malicious activities such as unauthorized vehicle control, identity theft, data extortion, and behavioral tracking, creating long-term security risks.

[0003] Vulnerability discovery in intelligent connected vehicles is an effective means of finding potential systemic defects, which can prevent "small problems from causing big failures". Integrating vulnerability discovery capabilities into the R&D process can realize a systematic transformation of "design is security" and ensure security from the source. Summary of the Invention

[0004] This specification provides a vulnerability detection method, apparatus, storage medium, and electronic device, the technical solutions of which are as follows:

[0005] Firstly, embodiments of this specification provide a vulnerability detection method, the method comprising:

[0006] Configure vulnerability detection kernel functions and target exception handling functions in the kernel space of the vehicle operating system;

[0007] Based on the vulnerability detection kernel function, a preset hardware access protection mechanism is enabled. The preset hardware access protection mechanism is used to trigger an access exception state when the kernel space requests access to user space memory through the operating system interface.

[0008] When the access exception state is detected each time by the target exception handling function, the kernel access execution flow is jumped to the vulnerability detection kernel function. The vulnerability detection kernel function records the memory access information corresponding to the access exception state and resumes the execution of the kernel access execution flow.

[0009] Based on the memory access information provided, the operating system interface is subjected to dual acquisition vulnerability detection processing to obtain dual acquisition vulnerability detection results.

[0010] In one feasible implementation, enabling a preset hardware access protection mechanism based on the vulnerability detection kernel function includes:

[0011] The vulnerability detection kernel function performs access protection mechanism configuration on the target control register of the device processor to enable the preset hardware access protection mechanism to prohibit kernel mode access to user space memory.

[0012] The resumption of the kernel access execution process includes:

[0013] The vulnerability detection kernel function temporarily disables access protection for the target control register of the device processor to disable the preset hardware access protection mechanism, allowing kernel-mode access to user space memory to resume the kernel access execution process.

[0014] After the kernel access execution process is completed, the step of enabling the preset hardware access protection mechanism based on the vulnerability detection kernel function is executed.

[0015] In one feasible implementation, the step of configuring the access protection mechanism for the target control register of the device processor through the vulnerability detection kernel function includes:

[0016] In the kernel space of the vehicle operating system, the target control register associated with the access protection control function of the device processor is set to the access protection enabled state;

[0017] The process of disabling access protection for the target control register of the device processor through the vulnerability detection kernel function includes:

[0018] In the kernel space of the vehicle operating system, the target control register associated with the access protection control function of the device processor is set to the access protection off state.

[0019] In one feasible implementation, configuring the vulnerability detection kernel function and the target exception handling function in the kernel space of the vehicle operating system includes:

[0020] Vulnerability detection logic is configured in the kernel call function within the kernel space of the vehicle operating system, resulting in the configured vulnerability detection kernel function.

[0021] Obtain the original exception handling function of the vehicle operating system, configure the original exception handling function with jump vulnerability detection code, and obtain the configured target exception handling function. The vulnerability detection code is used to jump the kernel access execution flow to the vulnerability detection kernel function when an abnormal access state is detected.

[0022] In one feasible implementation, the step of configuring vulnerability detection logic for kernel call functions in the kernel space of the vehicle operating system to obtain the configured vulnerability detection kernel function includes:

[0023] In the kernel space of the vehicle operating system, it is detected whether the vehicle operating system supports the function of calling custom kernel functions;

[0024] If the vehicle operating system supports the custom kernel call function function, then the original kernel call function to be configured is determined, and the vulnerability detection logic is configured on the original kernel call function to obtain the configured vulnerability detection kernel function.

[0025] If the vehicle operating system does not support the custom kernel call function function, then the silent kernel call function in the kernel call function table is queried, and the vulnerability detection logic is configured for the silent kernel call function to obtain the configured vulnerability detection kernel function. The silent kernel call function is a kernel call function whose kernel call frequency is less than a frequency threshold.

[0026] In one feasible implementation, configuring the jump vulnerability detection code on the original exception handling function to obtain the configured target exception handling function includes:

[0027] In the kernel space of the vehicle operating system, it is detected whether the vehicle operating system supports custom exception handling functions;

[0028] If the vehicle operating system supports custom exception handling functions, then the original exception handling function to be configured is determined, and jump vulnerability detection code is configured for the original exception handling function to obtain the configured target exception handling function.

[0029] If the vehicle operating system does not support custom exception handling functions, then the original binary file corresponding to the original exception handling function is determined, the jump vulnerability detection code is configured in the original binary file to obtain the target binary file, and the target exception handling function is generated based on the target binary file.

[0030] In one feasible implementation, the step of performing dual-access vulnerability detection processing on the operating system interface based on each of the memory access information to obtain dual-access vulnerability detection results includes:

[0031] Extract the interface call records of the operating system interface from each of the memory access information;

[0032] Based on the interface call record, it is detected whether the memory access information includes a preset vulnerability detection feature, which is the feature of at least two accesses to the same user space memory address by the same kernel call function;

[0033] If the memory access information includes preset vulnerability detection features, then it is determined that the operating system interface has a dual acquisition vulnerability, and a dual acquisition vulnerability detection result for the operating system interface is generated.

[0034] In one feasible implementation, if the memory access information includes preset vulnerability detection features, then determining that the operating system interface has a double-access vulnerability and generating a double-access vulnerability detection result for the operating system interface includes:

[0035] If the memory access information includes preset vulnerability detection features, then it is determined that the operating system interface has a dual acquisition vulnerability, and the abnormal kernel call function, abnormal system call interface and abnormal user space memory address corresponding to the dual acquisition vulnerability are determined.

[0036] Based on the abnormal kernel call function, the abnormal system call interface, and the abnormal user space memory address, a dual acquisition vulnerability detection result is generated for the operating system interface.

[0037] Secondly, embodiments of this specification provide a vulnerability detection device, the device comprising:

[0038] The function configuration module is used to configure vulnerability detection kernel functions and target exception handling functions in the kernel space of the vehicle operating system;

[0039] The mechanism activation module is used to activate a preset hardware access protection mechanism based on the vulnerability detection kernel function. The preset hardware access protection mechanism is used to trigger an access exception state when the kernel space requests access to user space memory through the operating system interface.

[0040] An anomaly detection module is used to jump the kernel access execution flow to the vulnerability detection kernel function each time the access anomaly state is detected by the target anomaly handling function, and to record the memory access information corresponding to the access anomaly state and resume the execution of the kernel access execution flow through the vulnerability detection kernel function.

[0041] The vulnerability detection module is used to perform dual acquisition vulnerability detection processing on the operating system interface based on the memory access information, and obtain the dual acquisition vulnerability detection result.

[0042] In one feasible implementation, enabling a preset hardware access protection mechanism based on the vulnerability detection kernel function includes:

[0043] The vulnerability detection kernel function performs access protection mechanism configuration on the target control register of the device processor to enable the preset hardware access protection mechanism to prohibit kernel mode access to user space memory.

[0044] The resumption of the kernel access execution process includes:

[0045] The vulnerability detection kernel function temporarily disables access protection for the target control register of the device processor to disable the preset hardware access protection mechanism, allowing kernel-mode access to user space memory to resume the kernel access execution process.

[0046] After the kernel access execution process is completed, the step of enabling the preset hardware access protection mechanism based on the vulnerability detection kernel function is executed.

[0047] In one feasible implementation, the step of configuring the access protection mechanism for the target control register of the device processor through the vulnerability detection kernel function includes:

[0048] In the kernel space of the vehicle operating system, the target control register associated with the access protection control function of the device processor is set to the access protection enabled state;

[0049] The process of disabling access protection for the target control register of the device processor through the vulnerability detection kernel function includes:

[0050] In the kernel space of the vehicle operating system, the target control register associated with the access protection control function of the device processor is set to the access protection off state.

[0051] In one feasible implementation, configuring the vulnerability detection kernel function and the target exception handling function in the kernel space of the vehicle operating system includes:

[0052] Vulnerability detection logic is configured in the kernel call function within the kernel space of the vehicle operating system, resulting in the configured vulnerability detection kernel function.

[0053] Obtain the original exception handling function of the vehicle operating system, configure the original exception handling function with jump vulnerability detection code, and obtain the configured target exception handling function. The vulnerability detection code is used to jump the kernel access execution flow to the vulnerability detection kernel function when an abnormal access state is detected.

[0054] In one feasible implementation, the step of configuring vulnerability detection logic for kernel call functions in the kernel space of the vehicle operating system to obtain the configured vulnerability detection kernel function includes:

[0055] In the kernel space of the vehicle operating system, it is detected whether the vehicle operating system supports the function of calling custom kernel functions;

[0056] If the vehicle operating system supports the custom kernel call function function, then the original kernel call function to be configured is determined, and the vulnerability detection logic is configured on the original kernel call function to obtain the configured vulnerability detection kernel function.

[0057] If the vehicle operating system does not support the custom kernel call function function, then the silent kernel call function in the kernel call function table is queried, and the vulnerability detection logic is configured for the silent kernel call function to obtain the configured vulnerability detection kernel function. The silent kernel call function is a kernel call function whose kernel call frequency is less than a frequency threshold.

[0058] In one feasible implementation, configuring the jump vulnerability detection code on the original exception handling function to obtain the configured target exception handling function includes:

[0059] In the kernel space of the vehicle operating system, it is detected whether the vehicle operating system supports custom exception handling functions;

[0060] If the vehicle operating system supports custom exception handling functions, then the original exception handling function to be configured is determined, and jump vulnerability detection code is configured for the original exception handling function to obtain the configured target exception handling function.

[0061] If the vehicle operating system does not support custom exception handling functions, then the original binary file corresponding to the original exception handling function is determined, the jump vulnerability detection code is configured in the original binary file to obtain the target binary file, and the target exception handling function is generated based on the target binary file.

[0062] In one feasible implementation, the step of performing dual-access vulnerability detection processing on the operating system interface based on each of the memory access information to obtain dual-access vulnerability detection results includes:

[0063] Extract the interface call records of the operating system interface from each of the memory access information;

[0064] Based on the interface call record, it is detected whether the memory access information includes a preset vulnerability detection feature, which is the feature of at least two accesses to the same user space memory address by the same kernel call function;

[0065] If the memory access information includes preset vulnerability detection features, then it is determined that the operating system interface has a dual acquisition vulnerability, and a dual acquisition vulnerability detection result for the operating system interface is generated.

[0066] In one feasible implementation, if the memory access information includes preset vulnerability detection features, then determining that the operating system interface has a double-access vulnerability and generating a double-access vulnerability detection result for the operating system interface includes:

[0067] If the memory access information includes preset vulnerability detection features, then it is determined that the operating system interface has a dual acquisition vulnerability, and the abnormal kernel call function, abnormal system call interface and abnormal user space memory address corresponding to the dual acquisition vulnerability are determined.

[0068] Based on the abnormal kernel call function, the abnormal system call interface, and the abnormal user space memory address, a dual acquisition vulnerability detection result is generated for the operating system interface.

[0069] Thirdly, embodiments of this specification provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the above-described method steps.

[0070] Fourthly, embodiments of this specification provide an electronic device that may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the above-described method steps.

[0071] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following:

[0072] In one or more embodiments of this specification, the electronic device configures a vulnerability detection kernel function and a target exception handling function in the kernel space of the vehicle operating system. Based on the vulnerability detection kernel function, a preset hardware access protection mechanism is enabled. This preset hardware access protection mechanism triggers an access exception state when the kernel space requests access to user space memory through the operating system interface. Each time the access exception state is detected by the target exception handling function, the kernel access execution flow jumps to the vulnerability detection kernel function. The vulnerability detection kernel function records the memory access information corresponding to the access exception state and resumes the execution of the kernel access execution flow. Based on each memory access information... By performing dual-access vulnerability detection processing on the operating system interface, the detection results for dual-access vulnerabilities can be obtained. Through sophisticated configuration of the operating system kernel and utilization of hardware access protection mechanisms, a highly efficient detection mode that deeply integrates software and hardware is realized. It utilizes the characteristics of preset hardware access protection mechanisms for access capture, which is more efficient and has less impact on system stability compared to traditional dynamic analysis tools. Moreover, its accuracy is significantly improved because it is not affected by system task scheduling. Finally, through automated and deterministic analysis of the recorded information, it can accurately and reliably locate highly concealed dual-access vulnerabilities, providing strong technical support for ensuring the software security of complex systems such as intelligent connected vehicles from the source. Attached Figure Description

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

[0074] Figure 1 This is a schematic diagram illustrating a scenario of a double-acquisition vulnerability provided in this manual;

[0075] Figure 2 This is a flowchart illustrating a vulnerability detection method provided in an embodiment of this specification;

[0076] Figure 3 This is a schematic diagram of the execution flow of a kernel function related to vulnerability detection, provided in an embodiment of this specification.

[0077] Figure 4 This is a flowchart illustrating another embodiment of a vulnerability detection method provided in the embodiments of this specification;

[0078] Figure 5 This is a flowchart illustrating a function configuration provided in an embodiment of this specification;

[0079] Figure 6 This is a flowchart illustrating a vulnerability detection logic configuration provided in an embodiment of this specification;

[0080] Figure 7 This is a flowchart illustrating a jump vulnerability detection configuration provided in the embodiments of this specification;

[0081] Figure 8 This is a schematic diagram of the structure of a vulnerability detection device provided in the embodiments of this specification;

[0082] Figure 9 This is a schematic diagram of the structure of an electronic device provided in the embodiments of this specification. Detailed Implementation

[0083] 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 are within the scope of protection of this specification.

[0084] In the description of this specification, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. In the description of this specification, it should be noted that, unless otherwise expressly specified and limited, "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. Those skilled in the art can understand the specific meaning of the above terms in this specification based on the specific circumstances. Furthermore, in the description of this specification, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0085] In related technologies, traditional operating system vulnerability mining relies on diverse input sources, such as command lines, browsers, network services, and USB peripherals. However, intelligent vehicle operating systems typically run in the vehicle controller and can generally only receive input through specific communication channels such as the CAN bus, UDS diagnostic protocol, and OTA interface. This makes vulnerability mining no longer just a matter of accumulating technology, but also involves a comprehensive understanding of the overall vehicle architecture and electronic and electrical systems.

[0086] In intelligent connected vehicle operating systems, the double fetch vulnerability has become a significant vulnerability for implementing data contention and privilege escalation due to its strong concealment and complex triggering conditions.

[0087] Typically, intelligent connected vehicle operating systems divide virtual memory addresses into kernel space and user space. Kernel space is responsible for running kernel code, driver module code, etc., and has higher privileges; user space runs user code and enters the kernel through system calls to complete related functions. Normally, when user space passes data to the kernel, the kernel first copies the user data to kernel space using copy functions such as `copy_from_user()` for verification and related processing. However, when the input data is complex, the kernel may only reference its pointer and temporarily retain the data in user space for later processing. If other malicious threads tamper with this data, it can cause inconsistencies between the kernel's verification data and the actual data used, leading to abnormal code execution.

[0088] The Double Fetch vulnerability is essentially a race condition vulnerability, manifesting as a data access competition between kernel mode and user mode. Its principle is as follows: Figure 1 As shown, Figure 1 This is a schematic diagram illustrating a dual-access vulnerability scenario provided in this manual. Figure 1 In this scenario, a user-mode thread prepares data and enters the kernel via a system call. This data is retrieved twice within the kernel. The first retrieval performs security checks (such as buffer size and pointer availability). Once the checks are passed, the data is retrieved a second time for actual processing. Between these two retrievals, another user-mode thread can create a race condition: tampering with the already checked user-mode data can lead to out-of-bounds access or buffer overflows during actual use, ultimately causing a crash or privilege escalation.

[0089] Currently, the discovery of double-access vulnerabilities still relies on static code auditing or detection tools based on vehicle operating systems such as Windows and Linux, which are difficult to adapt to the operating systems of intelligent connected vehicles. Therefore, there is an urgent need for a new technical solution that can effectively discover and locate double-access vulnerabilities for intelligent connected vehicle scenarios.

[0090] The present specification will now be described in detail with reference to specific embodiments.

[0091] In one embodiment, such as Figure 2 As shown, a vulnerability detection method is proposed. This method relies on a computer program and can run on a vulnerability detection device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application. The vulnerability detection device can be an electronic device, including but not limited to: personal computers, tablets, handheld devices, vehicle-mounted devices, servers, computing devices, or other processing devices connected to a wireless modem. In different networks, terminal devices can be called by different names, such as: user equipment, access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent or user equipment, cellular phone, cordless phone, device in 5G network or future evolved network, etc.

[0092] Specifically, the vulnerability detection method includes:

[0093] S102: Configure vulnerability detection kernel functions and target exception handling functions in the kernel space of the vehicle operating system;

[0094] Step S102 is the preparation stage before testing, which involves implanting or modifying two key functional modules in the vehicle operating system kernel.

[0095] First, the vulnerability detection kernel function is a core functional entity introduced in this invention. It is not part of the regular business logic of the operating system, but a kernel-level function specifically designed to implement this vulnerability detection.

[0096] In some embodiments, the vulnerability detection kernel function can serve as a control interface to receive instructions from user-mode programs to enable or disable hardware protection; the vulnerability detection kernel function can also serve as an exception response unit to perform tasks such as information logging and process recovery when a specific exception is captured.

[0097] In this specification, the configuration of the vulnerability detection kernel function is flexible and can be chosen according to the characteristics of the vehicle operating system. In one embodiment, if the vehicle operating system itself supports adding custom kernel calls (e.g., through a Board Support Package (BSP), a new kernel call function can be directly written and registered as the "detection function". In another embodiment, if the operating system does not support direct addition, existing kernel functions can be modified. Specifically, a kernel call function that is not currently used or is not important in the kernel call table can be found and modified. The modification method depends on whether the operating system is open source: if it is an open source system (such as a specific version of Linux), its source code can be directly modified and the kernel recompiled; if it is a closed source system (such as QNX), reverse engineering is required to locate the binary code of the target function and patch it.

[0098] Secondly, the target exception handling function is a standard function configured by jumping from a pre-existing exception handling function in the vehicle operating system kernel that is bound to the CPU hardware exception mechanism. In this invention, the target exception handling function refers to a function used to handle memory access exceptions, such as, in the x86 architecture, a function configured based on the exception handling function for handling page faults.

[0099] In some embodiments, the target exception handling function is configured by modifying its binary code in the logic code of its original exception handling function and inserting a jump instruction, so that when the target exception handling function is triggered by the CPU, the program execution flow can be jumped to the vulnerability detection kernel function configured above as soon as possible.

[0100] S104: Enable a preset hardware access protection mechanism based on the vulnerability detection kernel function. The preset hardware access protection mechanism is used to trigger an access exception state when the kernel space requests access to user space memory through the operating system interface.

[0101] Step S104 marks the start and "arming" phase of the detection task. After preparation S102 is completed, the "detection program" running on the vehicle's operating system will initiate the entire detection task by executing S104-S108. This "detection program" will first actively call the "vulnerability detection kernel function" configured in S102 via a system call, passing a parameter for "enabling protection".

[0102] Upon receiving this instruction, the vulnerability detection kernel function will perform its "control interface" duties, namely, to operate the corresponding hardware registers of the CPU to enable the "preset hardware access protection mechanism".

[0103] This default hardware access protection mechanism is a security feature provided by the CPU itself, not a software simulation. For example, for x86 architecture processors, it can be implemented by modifying a specific bit (e.g., bit 21) of its CR4 control register. When this bit is set, the CPU's Memory Management Unit (MMU) automatically prevents code running at the highest privilege level (Ring 0, i.e., kernel mode) from accessing user space (e.g., Ring 3) memory.

[0104] Optionally, in this specification, enabling or disabling the default hardware access protection mechanism involves modifying a specific bit of a default register (which may be called the access protection register). The register is operated by a custom vulnerability detection kernel function to enable or disable the CPU access protection mechanism, and then the vulnerability detection is achieved by capturing records in exception handling.

[0105] Therefore, when subsequent kernel code (e.g., when executing an operating system interface) attempts to read data in user space, this access behavior will be judged as a violation by the CPU hardware, thereby immediately triggering a hardware-level, non-ignorable "access exception state", such as a "page fault exception", thus realizing the triggering of an access exception state when the kernel space requests access to user space memory through the operating system interface.

[0106] S106: When the access exception state is detected each time by the target exception handling function, the kernel access execution flow is jumped to the vulnerability detection kernel function, the vulnerability detection kernel function records the memory access information corresponding to the access exception state and resumes the execution of the kernel access execution flow;

[0107] Step S106 is the core execution and information capture phase of vulnerability detection, and it is repeatedly triggered during the detection process.

[0108] When the vulnerability detection mechanism deployed in S104 is triggered—that is, when a thread in the vehicle operating system requests kernel access to user memory through a system interface and generates an "access exception state"—the program execution flow is as follows:

[0109] The vehicle operating system automatically directs the program execution flow to the modified "target exception handling function" in S102. After the "target exception handling function" captures the access exception state, it immediately executes the jump instruction at its entry point, and redirects the subsequent execution flow back to the "vulnerability detection kernel function".

[0110] At this point, the control "vulnerability detection kernel function" begins to perform its duties as an "exception response unit." Its internal process is rigorous and precise, and can be referenced as follows:

[0111] 1) Save the current values ​​of all general-purpose registers of the CPU;

[0112] Optionally, the current values ​​of all CPU general-purpose registers can be pushed onto the stack (a process known as a stack push operation). This can be understood as copying the value from each CPU general-purpose register one by one in a predetermined order and storing each copy of the data safely on the memory stack. This ensures that the program's running state can be fully restored after processing, guaranteeing system stability.

[0113] In layman's terms, if the current values ​​of all the CPU's general-purpose registers are not saved first, the important data left in the registers by the original function may be completely overwritten and destroyed by the subsequent operations of the "vulnerability detection kernel function". After the "vulnerability detection kernel function" finishes executing, the original state cannot be recovered, and the entire system may crash.

[0114] Therefore, by pushing data onto the stack, the original execution state is completely backed up onto the stack. After the vulnerability detection kernel function finishes execution, a reverse "pop" operation is performed, putting the backed-up data back into the registers intact. In this way, the original function can seamlessly continue execution from where it was interrupted.

[0115] 2) Temporarily disable the default hardware access protection mechanism;

[0116] Optionally, hardware access protection can be temporarily disabled immediately by manipulating control registers (such as CR4). This step is crucial because if protection is not disabled, the program will attempt to execute the same failed instruction again upon resumption of execution, triggering the same exception again and causing the system to crash into an infinite loop.

[0117] 3) While temporarily disabling the preset hardware access protection mechanism, record the memory access information corresponding to the abnormal access status;

[0118] Optionally, this could involve operating a specific address register of the CPU, such as the CR2 register in the x86 architecture. This register is automatically filled by the CPU when a page fault is triggered, and its content is the specific memory address that caused the exception. This step reads the value of this register and outputs it along with context information such as the current function call stack to the log file, forming a precise memory access record.

[0119] 4) Restore the context and continue: Restore the register values ​​saved in step 1) from the stack, and then jump back to the original exception instruction that caused the "access exception state," allowing it to be re-executed from that point. Because the protection has been temporarily disabled at this time, the instruction can be executed successfully, the kernel can successfully obtain the data, and the entire kernel access execution process can continue.

[0120] In an optional embodiment, the system will automatically re-enable hardware access protection immediately after the exception instruction that causes the "access exception state" is successfully executed, in order to prepare to capture the next (possibly the second) access.

[0121] For example, such as Figure 3 As shown, Figure 3 This is a schematic diagram of the execution flow of a kernel function involved in vulnerability detection. First, the current values ​​of all general-purpose registers of the CPU are pushed onto the stack, saving the current values ​​of all general-purpose registers; then... Figure 3 This illustrates a two-branch conditional judgment process based on "Is it a jump to the (target) exception handling function?";

[0122] Branch 1: "Yes" path ( Figure 2 (Left-hand flow, exception handling mode) When a hardware access exception occurs, i.e., the access exception state is detected, the operating system will execute this path when jumping to the vulnerability detection kernel function via the (target) exception handling function. Its function is to record the exception event and restore system operation. Specifically:

[0123] 1) Read the value of the access protection register: First, obtain the current hardware protection status.

[0124] 2) To temporarily disable the default hardware access protection mechanism, it is necessary to "calculate the value to disable access protection".

[0125] 3) Modify the access protection register: Perform the modification to immediately and temporarily disable hardware protection. This is to prevent the same exception from being triggered again in subsequent processing, thus avoiding system crashes.

[0126] 4) Read the page fault address register: This step involves retrieving the memory address that triggered the exception from a specific CPU register. This is a crucial step in obtaining evidence of the vulnerability; it involves acquiring the memory access information corresponding to the page fault state.

[0127] 5) Output Records: Record the memory access information, such as the memory address, obtained in the previous step into the log.

[0128] 6) Pop the values ​​of other registers from the stack and restore them, that is, restore the saved register values ​​from the stack.

[0129] 7) Jump to page error address: Then jump back to the original exception instruction that caused the "access exception state", and redirect the program execution flow to the address of the instruction that caused the error.

[0130] 8) Resume program execution: Re-execute the program from the point of the error. Since the protection has been temporarily disabled, the instruction can be executed successfully, the kernel can successfully obtain the data, and the entire kernel access and execution process can continue.

[0131] Branch 2: "No" path ( Figure 2 (Right-side flow, a control mode)

[0132] This path is executed when an external program (such as a detection tool) directly calls a non-exception handling function to actively control or when an abnormal protection state has not been triggered. Its function is to manually enable or disable hardware protection; specifically:

[0133] 1) Read the value of the access protection register: Similarly, first obtain the current hardware protection status.

[0134] 2) Is the access protection register enabled?: This is a judgment based on the function call parameters. The caller will pass in an instruction indicating whether it wants to "enable" or "disable".

[0135] 3) Calculate the value to enable / disable access protection: If the command is "Enable", calculate a new value to enable protection. If the command is "Disable", calculate a new value to disable protection.

[0136] 4) Modify the access protection register: Write the new value calculated in the previous step into the hardware register, thereby enabling or disabling hardware protection.

[0137] 5) Pop the values ​​of other registers from the stack and restore them: restore the CPU working state.

[0138] 6) End: Execution completed.

[0139] S108: Perform dual acquisition vulnerability detection processing on the operating system interface based on the memory access information, and obtain the dual acquisition vulnerability detection result.

[0140] S108 is the final analysis and judgment stage.

[0141] As an illustration, after testing one or more operating system interfaces, the log file generated in S106, containing a series of memory access information, will be used for analysis. "Double-pass vulnerability detection processing" refers to an automated log analysis process whose core judgment logic is to filter and compare all memory access records to check whether there is "during a complete operating system interface call, the same kernel function performed two or more accesses to the same user space memory address."

[0142] If the conditions for the dual-acquisition vulnerability detection process described above are met, the "Dual-acquisition vulnerability detection result" will be "Vulnerability exists," and the specific operating system interface and kernel function name where the vulnerability resides can be further output. If no record meeting this condition is found in the log after the test is completed, the detection result will be "No vulnerability found." In this way, the vulnerability detection method described in this specification can efficiently and accurately automate the discovery of dual-acquisition vulnerabilities.

[0143] In one feasible implementation, the dual-acquisition vulnerability detection process based on the memory access information of the operating system interface is performed to obtain the dual-acquisition vulnerability detection result. This can be achieved by referring to the following method:

[0144] Step A2: Extract the interface call records of the operating system interface from each of the memory access information;

[0145] The "vulnerability detection kernel function" described in S106 above generates a log file containing a large amount of raw memory access information during execution. This information is a chronological log record, which may contain test data from multiple different operating system interfaces.

[0146] Therefore, in order to perform effective analysis, it is necessary to first parse and extract this raw memory access information. Specifically, an analysis module can be set up that reads all log records and, based on the context information in the records (e.g., timestamp, process ID, thread ID, current system interface call identifier, etc.), categorizes and aggregates all memory access records belonging to the same system interface call lifecycle.

[0147] For example, the detection program calls interface A at time T1, ends at time T2, and calls interface B at time T3. The purpose of this step is to organize all memory access logs generated between T1 and T2 into a complete "interface A call record," and organize the logs generated after T3 into a "interface B call record." Each processed "interface call record" contains all the details of the kernel's access to user space memory during that interface call.

[0148] Step A4: Based on the interface call record, detect whether the memory access information includes a preset vulnerability detection feature, wherein the preset vulnerability detection feature is the feature of at least two accesses to the same user space memory address by the same kernel call function;

[0149] This step is the core feature matching and detection stage. After obtaining the structured "interface call records" from step A2, the analysis module will traverse and detect each record to find whether a "preset vulnerability detection feature" exists.

[0150] The "preset vulnerability detection feature" is a clear technical representation of a double-acquisition vulnerability. In this invention, it is precisely defined as: "In the same interface call record, there is an instance where the same kernel call function accesses the same user space memory address two or more times."

[0151] Optionally, the detection process can be as follows: For each "interface call record," construct a counter with "kernel function name + user space memory address" as the key. Traverse all memory access entries in the interface call record, counting the corresponding key for each entry encountered. After the traversal is complete, check if there is a key with a count value greater than or equal to 2.

[0152] Step A6: If the memory access information includes preset vulnerability detection features, then it is determined that the operating system interface has a dual acquisition vulnerability, and a dual acquisition vulnerability detection result for the operating system interface is generated.

[0153] This step is the final judgment and result generation stage. During the detection process in step A4, once an "interface call record" is found to contain the aforementioned "preset vulnerability detection feature" (i.e., a key with a count value greater than or equal to 2), the analysis module can make a judgment.

[0154] The determination is as follows: determine which operating system interface corresponds to the "interface call record" has a double-access vulnerability, and then the system will generate a "double-access vulnerability detection result".

[0155] In one embodiment, the detection result may be a detailed report, which may include: the name of the vulnerable operating system interface; the name of the specific kernel function call that triggered the vulnerability; the user space memory address that was accessed multiple times; the timestamp of each access or other relevant contextual information.

[0156] This "Double Acquisition Vulnerability Detection Result" provides developers with direct and effective evidence to locate, reproduce, and fix the vulnerability. If none of the described characteristics are found in all "API call records" after detection, the result is that no double acquisition vulnerability was found.

[0157] In this specification, the structured interface call records are first extracted from the raw and mixed memory access information (step A2), providing a clear and organized data foundation for subsequent analysis. Then, objective and clear preset vulnerability features are used for automated matching (step A4), completely replacing the inefficiency and uncertainty of manual analysis and greatly improving the accuracy and reliability of detection. Finally, through automated judgment and result generation (step A6), intuitive and operable vulnerability reports can be generated, thus realizing a highly efficient and automated processing system from massive amounts of raw data to accurate security conclusions, providing strong technical support for the rapid location and remediation of vulnerabilities.

[0158] In one feasible implementation, if the memory access information includes preset vulnerability detection features, then it is determined that the operating system interface has a double-access vulnerability, and a double-access vulnerability detection result for the operating system interface is generated. This can be achieved by referring to the following method:

[0159] Step B2: If the memory access information includes preset vulnerability detection features, then it is determined that the operating system interface has a dual acquisition vulnerability, and the abnormal kernel call function, abnormal system call interface and abnormal user space memory address corresponding to the dual acquisition vulnerability are determined.

[0160] This step is the vulnerability confirmation and key information extraction stage. During the detection process of the previous step A4, once the analysis module matches a "preset vulnerability detection feature" (i.e., at least two accesses of the same kernel function to the same user address) in a certain "interface call record", the program flow will enter this step.

[0161] First, "determining that the operating system interface has a double-access vulnerability" is a logical decision. The operating system interface is then marked as having a "double-access vulnerability".

[0162] Secondly, "determining the abnormal kernel call function, abnormal system call interface, and abnormal user space memory address corresponding to the dual-acquisition vulnerability" is an information extraction action. This information has already been captured and correlated in the recording phase of S106 and the data preparation phase of A2. This step will precisely extract the following three core elements from the "interface call record" containing the vulnerability characteristics:

[0163] Exceptional kernel function call: The specific name or identifier of the kernel function that caused multiple accesses.

[0164] Exception system call interface: The name of the operating system interface to which this kernel function is exposed.

[0165] Abnormal user space memory address: The specific memory address of the user space that was accessed multiple times.

[0166] This step not only confirmed the qualitative conclusion that there is a "double-access vulnerability," but also gathered all the technical details describing the vulnerability.

[0167] Step B4: Generate a dual acquisition vulnerability detection result for the operating system interface based on the abnormal kernel call function, the abnormal system call interface, and the abnormal user space memory address.

[0168] Using the three core elements extracted in step B2, format and structure them to generate a user-friendly and information-complete "dual acquisition vulnerability detection result".

[0169] In a specific embodiment, the detection result may be a detailed electronic report document, the contents of which may include, but are not limited to: vulnerability summary: clearly indicating that a double-access vulnerability has been detected; vulnerability location information: interface name, kernel function, memory address; original evidence: attached with the original log entries related to the vulnerability recorded in S106, including the timestamp of each access, context, etc., as technical evidence.

[0170] Through this step, the system transforms its internal detection and judgment into a deliverable, traceable final product that can guide repair work, thus completing the closed loop of the entire detection process.

[0171] In this embodiment of the specification, the electronic device is configured with a vulnerability detection kernel function and a target exception handling function in the kernel space of the vehicle operating system. A preset hardware access protection mechanism is enabled based on the vulnerability detection kernel function. This preset hardware access protection mechanism is used to trigger an access exception state when the kernel space requests access to user space memory through the operating system interface. Each time the access exception state is detected by the target exception handling function, the kernel access execution flow is jumped to the vulnerability detection kernel function. The vulnerability detection kernel function records the memory access information corresponding to the access exception state and resumes the execution of the kernel access execution flow. Based on the memory access information, the electronic device... By performing dual-access vulnerability detection processing on the system interface, the detection results can be obtained. Through sophisticated configuration of the operating system kernel and utilization of hardware access protection mechanisms, a highly efficient detection mode with deep integration of software and hardware is realized. It uses the characteristics of preset hardware access protection mechanisms for access capture. Compared with traditional dynamic analysis tools, it has higher detection efficiency, less impact on system stability, and significantly improved accuracy because it is not affected by system task scheduling. Finally, through automated and deterministic analysis of the recorded information, it can accurately and reliably locate highly concealed dual-access vulnerabilities, providing strong technical support for ensuring the software security of complex systems such as intelligent connected vehicles from the source.

[0172] Optional, please see Figure 4 , Figure 4 This is a flowchart illustrating another embodiment of a vulnerability detection method proposed in this specification. Specifically:

[0173] S202: Configure vulnerability detection kernel functions and target exception handling functions in the kernel space of the vehicle operating system;

[0174] For details, please refer to the method steps in other embodiments of this specification, which will not be repeated here.

[0175] S204: The vulnerability detection kernel function performs access protection mechanism configuration on the target control register of the device processor to enable the preset hardware access protection mechanism to prohibit kernel mode access to user space memory;

[0176] This step is the "deployment" or "alert activation" phase of the entire vulnerability detection process. Its core is to activate the hardware security features built into the processor (CPU) to establish the preconditions for subsequent access capture.

[0177] First, this step can be initiated by a "detection program" running in user space via a system call (syscall). This "detection program" calls the "vulnerability detection kernel function" configured in S202, passing a parameter indicating "enable protection".

[0178] Secondly, upon receiving the instruction, the "vulnerability detection kernel function" begins executing the "access protection mechanism enabling configuration process." In a preferred embodiment, this process is a standardized "read-modify-write" operation sequence to ensure the security and accuracy of the operation.

[0179] Reading: The vulnerability detection kernel function first reads the current full value of the "Target Control Register of the Device Processor". The "Target Control Register" refers to a special hardware register in the CPU used to control its advanced operating features and security policies.

[0180] Calculation: The vulnerability detection kernel function calculates a new target value based on the current value read and the "enable protection" instruction, using bitwise operations (e.g., an OR operation with a preset mask). This calculation ensures that only the specific location used for access protection is "enabled," without affecting the bits in the register that control other functions.

[0181] Write: The vulnerability detection kernel function writes the calculated new target value back to the "target control register".

[0182] In a specific example, when the device processor is an x86 architecture, the "target control register" can be the CR4 register. In this case, "enabling configuration processing" means setting bit 21 of the CR4 register to 1.

[0183] Finally, once the write operation is complete, the "pre-defined hardware access protection mechanism" is successfully enabled. This means that the CPU's Memory Management Unit (MMU) will then strictly enforce a new access rule: prohibiting any code running in kernel mode (Ring 0) from directly accessing memory space belonging to user mode (Ring 3). If any kernel code violates this rule, the CPU will not execute the access instruction, but will immediately trigger an "access exception state" (e.g., page fault exception) at the hardware level, thereby handing control over to step S206 for processing.

[0184] S206: When the access exception state is detected each time by the target exception handling function, the kernel access execution flow is jumped to the vulnerability detection kernel function. The vulnerability detection kernel function records the memory access information corresponding to the access exception state. The vulnerability detection kernel function performs temporary access protection shutdown on the target control register of the device processor to disable the preset hardware access protection mechanism to allow kernel mode to access user space memory and resume the execution of the kernel access execution flow.

[0185] This step is the key execution stage in the entire detection loop, responsible for "capturing," "recording," and "allowing." The internal logic of this step is activated when the hardware access protection mechanism deployed in S204 is triggered by kernel access to user space.

[0186] First, the phrase "whenever the access exception state is detected by the target exception handling function" describes the triggering condition for this step. Specifically, when kernel code executed by a thread through the system interface attempts to access a protected user-space memory address, the device processor hardware immediately generates an "access exception state." This exception is caught by the "target exception handling function," which is preset by the operating system and modified in S202.

[0187] Secondly, "jumping the kernel access execution flow to the vulnerability detection kernel function" describes the first response action after an anomaly occurs. After detecting an anomaly, one of the tasks of the "target anomaly handling function" is to execute a jump instruction to immediately transfer CPU control and execution flow to the preset "vulnerability detection kernel function".

[0188] Furthermore, the phrase "recording memory access information corresponding to the abnormal access state through the vulnerability detection kernel function" describes the core operation of information capture. After entering the "vulnerability detection kernel function," the program executes a series of actions to accurately record the event:

[0189] Context saving: In order to ensure that the system can recover seamlessly after handling the exception, the function will first push the current values ​​of all general-purpose registers onto the stack for saving.

[0190] Information extraction: The function reads a specific register that is automatically filled by the processor when an exception is triggered, namely the "page fault address register" (CR2 register in x86 architecture), and obtains the precise user space memory address that caused the exception. This address is the critical "memory access information".

[0191] Log output: The function will extract the memory address, along with other possible context information (such as timestamps, current kernel function identifiers, etc.), and output it to the log file, thus completing the recording of an access event.

[0192] Finally, the description of "temporarily disabling access protection on the target control register of the device processor through the vulnerability detection kernel function to disable... and resume the execution of the kernel access execution flow" describes the key operation to ensure the continued operation of the system. After recording the information, the function performs "temporary access protection disabling," which means performing the reverse operation on the same "target control register" mentioned in S204 (such as the CR4 register in the x86 architecture), clearing the control bits corresponding to the access protection, thereby temporarily disabling the hardware protection mechanism. The purpose of this is to avoid an infinite loop caused by triggering the same exception again when the program returns to the original instruction. After disabling the protection and restoring the register context, the previously interrupted kernel access instruction is successfully executed, and the entire kernel access execution flow is resumed from the point of interruption and continues.

[0193] S208: After the kernel access execution process is completed, S204 is executed.

[0194] S210: Perform dual acquisition vulnerability detection processing on the operating system interface based on the memory access information, and obtain the dual acquisition vulnerability detection result.

[0195] For details, please refer to the method steps in other embodiments of this specification.

[0196] In the embodiments described in this specification, the protection is explicitly enabled and temporarily disabled using CPU hardware registers through steps S204 and S206. This not only inherits the high efficiency and stability brought by the combination of hardware and software, but also introduces a crucial "automatic rearming" mechanism through step S208. This mechanism ensures that after a single access is allowed, the detection system can immediately and deterministically return to the alert state, thereby reliably capturing every subsequent memory access. This explicit "capture-allow-rearm" loop greatly enhances the rigor and reliability of the entire detection logic, ensuring that the data used for analysis in S210 fully reflects the dual acquisition behavior, thus making the vulnerability detection results more accurate.

[0197] Optionally, the configuration process for enabling access protection mechanisms for the target control registers of the device processor through the vulnerability detection kernel function can be performed in the following manner:

[0198] In the kernel space of the vehicle operating system, the target control register associated with the access protection control function of the device processor is set to the access protection enabled state;

[0199] This implementation provides more specific and low-level technical details on how to enable hardware access protection.

[0200] First, the phrase "in the kernel space of the vehicle operating system" clarifies the execution environment of this operation. This means that the operation is executed by kernel code with the highest privilege level, specifically by the "vulnerability detection kernel function" defined above when it is called.

[0201] Secondly, "the target control register associated with the access protection control function of the device processor" is a precise description of the object of operation. It refers to the hardware register in the CPU that directly and uniquely controls the "access protection" function required by this invention. In a specific example, such as on an x86 architecture processor, this target control register is the CR4 register.

[0202] Finally, "setting to the access protection enabled state" describes the core technical action and the final state achieved. The "setting" (Set a bit) is a low-level bit operation. Specifically, the "vulnerability detection kernel function" executes one or more instructions to perform a bitwise operation on the target control register (e.g., an OR operation with a specific mask), thereby changing the value of the specific bit in that register corresponding to the access protection function from 0 to 1. For example, in the CR4 register of the x86 architecture, this specific bit can be bit 21.

[0203] Once this feature is successfully set to 1, the CPU hardware enters an "access protection enabled state." At this time, its Memory Management Unit (MMU) strictly prohibits kernel-mode access to user-space memory. This completes the entire "defense" process, laying the foundation for subsequent anomaly detection.

[0204] Optionally, the process of disabling access protection for the target control register of the device processor through the vulnerability detection kernel function can be performed in the following manner:

[0205] In the kernel space of the vehicle operating system, the target control register associated with the access protection control function of the device processor is set to the access protection off state.

[0206] This implementation provides more specific and low-level technical details on how to enable hardware access protection.

[0207] First, the phrase "in the kernel space of the vehicle operating system" clarifies the execution environment of this operation. This means that the operation is executed by kernel code with the highest privilege level, specifically by the "vulnerability detection kernel function" defined above when it is called.

[0208] Secondly, "the target control register associated with the access protection control function of the device processor" is a precise description of the object of operation. It refers to the hardware register in the CPU that directly and uniquely controls the "access protection" function required by this invention. In a specific example, such as on an x86 architecture processor, this target control register is the CR4 register.

[0209] Finally, "setting to the access protection enabled state" describes the core technical action and the final state achieved. The "setting" (Set a bit) is a low-level bit operation. Specifically, the "vulnerability detection kernel function" executes one or more instructions to perform a bitwise operation on the target control register (e.g., an OR operation with a specific mask), thereby changing the value of the specific bit in that register corresponding to the access protection function from 0 to 1. In the x86 architecture's CR4 register, this specific bit can be bit 21.

[0210] Once this feature is successfully set to 1, the CPU hardware enters an "access protection enabled state." At this time, its Memory Management Unit (MMU) strictly prohibits kernel-mode access to user-space memory. This completes the entire "defense" process, laying the foundation for subsequent anomaly detection.

[0211] Optional, please see Figure 5 , Figure 5This is a flowchart illustrating a function configuration method proposed in this specification. Specifically, the configuration of the vulnerability detection kernel function and the target exception handling function in the vehicle operating system's kernel space can be performed as follows:

[0212] S302: Configure vulnerability detection logic for kernel call functions in the kernel space of the vehicle operating system to obtain the configured vulnerability detection kernel function;

[0213] This step details the process of generating the "vulnerability detection kernel function." Its core idea is not to create a new kernel function from scratch, but rather to reuse and refactor an existing kernel function within the existing kernel framework.

[0214] First, a kernel call function needs to be selected from the vehicle operating system's syscall table as the target for modification. In a preferred embodiment, a kernel call function that is not used or is not critical during normal system operation can be selected to minimize the impact on the original system functionality.

[0215] Secondly, the "vulnerability detection logic configuration" is executed. This configuration process refers to replacing or overriding the original logic of the selected kernel call function with the entirely new logic required by this invention. The entirely new logic is the logic described in other embodiments of this specification, which has the dual responsibilities of "manual control" and "exception logging" (refer to the flowchart shown in the accompanying drawings). The specific implementation of this configuration process depends on the characteristics of the target operating system:

[0216] For example, for open-source operating systems, configuration can be accomplished by directly modifying the source code of the kernel call functions and then recompiling the kernel.

[0217] For example, for closed-source operating systems (such as QNX), it is necessary to use binary analysis techniques such as reverse engineering to locate the machine code of the function in the kernel file, and then replace the original instructions with new instructions that implement the function described in this invention through binary patching.

[0218] After the above logic replacement is completed, the modified kernel call function becomes a "configured vulnerability detection kernel function" with specific detection capabilities.

[0219] S304: Obtain the original exception handling function of the vehicle operating system, configure the jump vulnerability detection code for the original exception handling function, and obtain the configured target exception handling function. The vulnerability detection code is used to jump the kernel access execution flow to the vulnerability detection kernel function when an access abnormal state is detected.

[0220] This step describes the generation process of the "target exception handling function". Its core idea is to redirect the flow through code configuration in the normal exception handling process.

[0221] First, it is necessary to "obtain the original exception handling function of the vehicle operating system," which can be located in the standard function of the operating system kernel responsible for handling memory access exceptions (such as page faults). This standard function is the pre-defined interface between the operating system and the CPU hardware exception mechanism.

[0222] Secondly, the "configure jump vulnerability detection code for the original exception handling function" is executed. This configuration process typically involves inserting a small piece of code, "jump vulnerability detection code," at the entry point of the original exception handling function, i.e., at the very beginning of function execution. The core of the "jump vulnerability detection code" is an unconditional jump instruction (e.g., the JMP instruction under the x86 architecture). The target address of this jump instruction is precisely set to the entry address of the "vulnerability detection kernel function" obtained in S302.

[0223] Through the above configuration, the "configured target exception handling function" is obtained. Its function becomes: when an "access exception state" occurs, and the CPU transfers control to this modified exception handling function, it immediately executes the jump instruction at the entry point. This allows the kernel's access execution flow to be immediately and forcibly redirected to the "vulnerability detection kernel function" for processing, instead of continuing to execute the original, conventional exception handling logic. This constitutes the key hub in the entire detection scheme, from "exception capture" to "analysis and logging."

[0224] This specification presents a highly flexible and practically applicable technical implementation path. By reusing and modifying existing kernel call functions in S302, and redirecting the jump to the original exception handling function entry point in S304, this invention cleverly integrates vulnerability detection logic seamlessly into the target operating system. This approach not only possesses strong adaptability, being equally applicable to open-source systems and difficult-to-modify closed-source commercial systems (such as QNX), but its "surgical" precise modification, compared to large-scale refactoring, is less invasive to the original system framework and more convenient to implement, thereby ensuring the deployability and reliability of the entire advanced detection solution on diverse, especially resource-constrained, intelligent connected vehicle operating systems.

[0225] In one possible implementation, please refer to Figure 6 , Figure 6 This is a flowchart illustrating a vulnerability detection logic configuration proposed in this specification. The configuration of the vulnerability detection logic in the kernel call function within the vehicle operating system's kernel space yields the configured vulnerability detection kernel function. The following method can be used as a reference:

[0226] S402: In the kernel space of the vehicle operating system, detect whether the vehicle operating system supports the custom kernel call function function;

[0227] Specifically, this involves understanding the specific characteristics of the target vehicle's operating system in order to determine the most efficient and appropriate configuration strategy to be adopted subsequently.

[0228] The "custom kernel call function functionality" refers to whether the operating system provides an official, reserved interface to kernel developers or system integrators for adding or implementing user-defined kernel-level functions. In one embodiment, this can be determined by consulting the operating system's official documentation (such as the Board Support Package (BSP), API manual, or relevant configuration files). For example, some real-time operating systems (RTOS) provide such customized interfaces to facilitate driver development and system adaptation by hardware manufacturers.

[0229] S404: If the vehicle operating system supports the custom kernel call function function, then determine the original kernel call function to be configured, configure the vulnerability detection logic on the original kernel call function, and obtain the configured vulnerability detection kernel function;

[0230] First, "determining the original kernel call function to be configured" means directly using the kernel call function provided by the operating system that is specifically designed for customization as our modification target. For example, in one embodiment of the QNX operating system, this function could be ker_sys_custom.

[0231] Secondly, "configuring vulnerability detection logic for the original kernel call function" refers to filling or writing the logic code required by this invention, which has the dual responsibilities of "manual control" and "exception logging," into this reserved original kernel call function. Because this function itself is designed for user customization, this configuration process is usually quite straightforward; for example, it can be done by writing functional code that conforms to its interface specification in assembly language or C language.

[0232] This step allows you to conveniently and stably generate the required "configured vulnerability detection kernel function" using methods provided by the operating system.

[0233] S406: If the vehicle operating system does not support the custom kernel call function function, then query the silent kernel call function in the kernel call function table, configure the vulnerability detection logic for the silent kernel call function, and obtain the configured vulnerability detection kernel function. The silent kernel call function is a kernel call function whose kernel call frequency is less than the frequency threshold.

[0234] This step describes a workaround configuration strategy for situations where the target operating system does not support custom kernel call function functionality, demonstrating the broad adaptability of this invention.

[0235] First, "querying silent kernel call functions in the kernel call function table" is a discovery process to find suitable targets for modification. The "kernel call function table" is a mapping table maintained in the operating system kernel that associates user-mode system call numbers with the addresses of specific kernel-mode processing functions. The "silent kernel call function" is a special type of kernel function defined in this invention, characterized by "kernel call frequency less than a frequency threshold." In one embodiment, this frequency threshold can be set to a very small value (e.g., 0), that is, finding a function that has theoretically or practically never been called in all scenarios of normal system operation. Such functions can be identified through static analysis of kernel code, or through dynamic instrumentation, performance analysis, and other methods.

[0236] Secondly, "configuring vulnerability detection logic for the silent kernel call function" refers to a process of "function hijacking" or "reuse". Once a "silent kernel call function" is identified, this step completely replaces its original, almost unused logic with the vulnerability detection logic required by this invention. This replacement process is the same as described in S302, that is, depending on whether the operating system is open source, it is implemented by modifying the source code or by binary patching.

[0237] Through this step, even on a completely closed operating system that does not provide custom interfaces, this invention can still successfully configure a "vulnerability detection kernel function" with the required functions by "borrowing a shell", thereby ensuring the feasibility of the entire detection scheme.

[0238] This specification presents an adaptive and highly compatible deployment strategy. By first detecting whether the operating system supports the custom function in S402, this invention can intelligently select the optimal implementation path: when the system supports it (S404), it uses the official and stable configuration method; while when the system does not support it (S406), it innovatively provides an effective solution in closed or restricted environments by querying and modifying the "silent kernel call function." This dual-path adaptive strategy ensures that the core detection logic of this invention can overcome the limitations of different operating systems (whether open source, closed source, or with or without reserved interfaces), greatly expanding the applicability and practical value of the technology, and guaranteeing the feasibility of the solution in the complex and diverse intelligent connected vehicle software ecosystem.

[0239] In one possible implementation, please refer to Figure 7 , Figure 7This is a flowchart illustrating a jump vulnerability detection configuration proposed in this specification. Specifically, by executing the jump vulnerability detection code configured on the original exception handling function, the configured target exception handling function can be obtained. The following method can be used as a reference:

[0240] S502: In the kernel space of the vehicle operating system, detect whether the vehicle operating system supports a custom exception handling function;

[0241] This step is a preliminary, adaptive detection step, the purpose of which is to determine whether the target vehicle's operating system provides open customization capabilities in its anomaly handling mechanism.

[0242] The "custom exception handling function" feature refers to whether the operating system provides an official, standard interface (e.g., a registerable callback function pointer or hook) that allows developers to take over or extend the system's default exception handling process with custom logic.

[0243] In one embodiment, this detection can be performed by consulting the operating system's kernel development documentation or security manual.

[0244] S504: If the vehicle operating system supports custom exception handling functions, then determine the original exception handling function to be configured, configure the jump vulnerability detection code on the original exception handling function, and obtain the configured target exception handling function.

[0245] This step describes the configuration process when the target operating system provides an open interface.

[0246] First, "determining the original exception handling function to be configured" means directly using the exception handling interface or hook function provided by the operating system that is dedicated to customization as the configuration object.

[0247] Secondly, "configuring jump vulnerability detection code for the original exception handling function" refers to registering or mounting a function pointer pointing to the entry address of the "vulnerability detection kernel function" of this invention onto the aforementioned customized interface. In this way, when a related memory access exception occurs, the operating system will follow its standard procedure and call this "custom" exception handling function, thus naturally directing the execution flow to our "vulnerability detection kernel function" without modifying the system's core files.

[0248] S506: If the vehicle operating system does not support custom exception handling functions, then determine the original binary file corresponding to the original exception handling function, configure the jump vulnerability detection code in the original binary file to obtain the target binary file, and generate the target exception handling function based on the target binary file.

[0249] This step describes the configuration strategy when the target operating system is a closed system that does not provide open custom interfaces.

[0250] First, "determining the original binary file corresponding to the original exception handling function" is a location process. This requires using reverse engineering and static analysis to precisely locate the file offset of the machine code of the standard function responsible for handling memory access exceptions within the core files of the operating system (such as the kernel image file).

[0251] Secondly, "configuring the jump vulnerability detection code in the original binary file to obtain the target binary file" is a direct binary patching process. Specifically, it involves directly modifying the "original binary file" by replacing several original machine instructions at the entry point of the exception handling function with an unconditional jump (JMP) instruction. The target address of this jump instruction points to the entry address of the "vulnerability detection kernel function." After this modification, the original file becomes the "target binary file."

[0252] Finally, "generating the target exception handling function based on the target binary file" refers to deploying this modified "target binary file" to the vehicle controller. When the operating system loads and runs, the exception handling function loaded into memory is actually a modified version containing jump logic. Therefore, at runtime, this function becomes the required "target exception handling function" capable of implementing process redirection.

[0253] This specification provides a highly adaptable deployment strategy for redirecting abnormal processes. By pre-detecting whether the operating system provides an open custom interface in S502, this invention can intelligently select the configuration path: when the system supports it (S504), the jump logic is mounted in an official and stable manner; while when the system is a closed environment that does not support it (S506), a powerful underlying solution is provided by directly patching the kernel binary file. This dual-path adaptive design ensures that the key link between "hardware anomalies" and "detection functions" can be successfully established on both open and closed operating systems, thereby guaranteeing the universal applicability of the entire vulnerability detection scheme and its engineering feasibility in real and complex automotive environments.

[0254] The following will combine Figure 8 This specification provides a detailed description of the vulnerability detection device provided in the embodiments. It should be noted that... Figure 8 The vulnerability detection device shown is used to execute this specification. Figures 1 to 7 The methods shown in the embodiments are illustrated for ease of explanation, showing only the parts related to the embodiments of this specification. For specific technical details not disclosed, please refer to this specification. Figures 1 to 7 The example shown.

[0255] Please see Figure 8 This diagram illustrates the structure of a vulnerability detection device according to an embodiment of this specification. The vulnerability detection device 1 can be implemented as all or part of a device through software, hardware, or a combination of both. According to some embodiments, the vulnerability detection device 1 includes a function configuration module 11, a mechanism activation module 12, an anomaly detection module 13, and a vulnerability detection module 14, specifically used for:

[0256] Function configuration module 11 is used to configure vulnerability detection kernel functions and target exception handling functions in the kernel space of the vehicle operating system;

[0257] The mechanism activation module 12 is used to activate a preset hardware access protection mechanism based on the vulnerability detection kernel function. The preset hardware access protection mechanism is used to trigger an access exception state when the kernel space requests access to user space memory through the operating system interface.

[0258] The anomaly detection module 13 is used to jump the kernel access execution flow to the vulnerability detection kernel function each time the access anomaly state is detected by the target anomaly handling function, and to record the memory access information corresponding to the access anomaly state and resume the execution of the kernel access execution flow through the vulnerability detection kernel function.

[0259] The vulnerability detection module 14 is used to perform dual acquisition vulnerability detection processing on the operating system interface based on the memory access information, and obtain the dual acquisition vulnerability detection result.

[0260] In one feasible implementation, enabling a preset hardware access protection mechanism based on the vulnerability detection kernel function includes:

[0261] The vulnerability detection kernel function performs access protection mechanism configuration on the target control register of the device processor to enable the preset hardware access protection mechanism to prohibit kernel mode access to user space memory.

[0262] The process of resuming execution of the kernel access execution includes:

[0263] The vulnerability detection kernel function temporarily disables access protection for the target control register of the device processor to disable the preset hardware access protection mechanism, allowing kernel-mode access to user space memory to resume the kernel access execution process.

[0264] After the kernel access execution process is completed, the step of enabling the preset hardware access protection mechanism based on the vulnerability detection kernel function is executed.

[0265] In one feasible implementation, the step of configuring the access protection mechanism for the target control register of the device processor through the vulnerability detection kernel function includes:

[0266] In the kernel space of the vehicle operating system, the target control register associated with the access protection control function of the device processor is set to the access protection enabled state;

[0267] The process of disabling access protection for the target control register of the device processor through the vulnerability detection kernel function includes:

[0268] In the kernel space of the vehicle operating system, the target control register associated with the access protection control function of the device processor is set to the access protection off state.

[0269] In one feasible implementation, configuring the vulnerability detection kernel function and the target exception handling function in the kernel space of the vehicle operating system includes:

[0270] Vulnerability detection logic is configured in the kernel call function within the kernel space of the vehicle operating system, resulting in the configured vulnerability detection kernel function.

[0271] Obtain the original exception handling function of the vehicle operating system, configure the original exception handling function with jump vulnerability detection code, and obtain the configured target exception handling function. The vulnerability detection code is used to jump the kernel access execution flow to the vulnerability detection kernel function when an abnormal access state is detected.

[0272] In one feasible implementation, the step of configuring vulnerability detection logic for kernel call functions in the kernel space of the vehicle operating system to obtain the configured vulnerability detection kernel function includes:

[0273] In the kernel space of the vehicle operating system, it is detected whether the vehicle operating system supports the function of calling custom kernel functions;

[0274] If the vehicle operating system supports the custom kernel call function function, then the original kernel call function to be configured is determined, and the vulnerability detection logic is configured on the original kernel call function to obtain the configured vulnerability detection kernel function.

[0275] If the vehicle operating system does not support the custom kernel call function function, then the silent kernel call function in the kernel call function table is queried, and the vulnerability detection logic is configured for the silent kernel call function to obtain the configured vulnerability detection kernel function. The silent kernel call function is a kernel call function whose kernel call frequency is less than a frequency threshold.

[0276] In one feasible implementation, configuring the jump vulnerability detection code on the original exception handling function to obtain the configured target exception handling function includes:

[0277] In the kernel space of the vehicle operating system, it is detected whether the vehicle operating system supports custom exception handling functions;

[0278] If the vehicle operating system supports custom exception handling functions, then the original exception handling function to be configured is determined, and jump vulnerability detection code is configured for the original exception handling function to obtain the configured target exception handling function.

[0279] If the vehicle operating system does not support custom exception handling functions, then the original binary file corresponding to the original exception handling function is determined, the jump vulnerability detection code is configured in the original binary file to obtain the target binary file, and the target exception handling function is generated based on the target binary file.

[0280] In one feasible implementation, the step of performing dual-access vulnerability detection processing on the operating system interface based on each of the memory access information to obtain dual-access vulnerability detection results includes:

[0281] Extract the interface call records of the operating system interface from each of the memory access information;

[0282] Based on the interface call record, it is detected whether the memory access information includes a preset vulnerability detection feature, which is the feature of at least two accesses to the same user space memory address by the same kernel call function;

[0283] If the memory access information includes preset vulnerability detection features, then it is determined that the operating system interface has a dual acquisition vulnerability, and a dual acquisition vulnerability detection result for the operating system interface is generated.

[0284] In one feasible implementation, if the memory access information includes preset vulnerability detection features, then determining that the operating system interface has a double-access vulnerability and generating a double-access vulnerability detection result for the operating system interface includes:

[0285] If the memory access information includes preset vulnerability detection features, then it is determined that the operating system interface has a dual acquisition vulnerability, and the abnormal kernel call function, abnormal system call interface and abnormal user space memory address corresponding to the dual acquisition vulnerability are determined.

[0286] Based on the abnormal kernel call function, the abnormal system call interface, and the abnormal user space memory address, a dual acquisition vulnerability detection result is generated for the operating system interface.

[0287] It should be noted that the vulnerability detection device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the vulnerability detection method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the vulnerability detection device and the vulnerability detection method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0288] The example numbers in this specification are for descriptive purposes only and do not represent the superiority or inferiority of the examples.

[0289] In this embodiment of the specification, the electronic device is configured with a vulnerability detection kernel function and a target exception handling function in the kernel space of the vehicle operating system. A preset hardware access protection mechanism is enabled based on the vulnerability detection kernel function. This preset hardware access protection mechanism is used to trigger an access exception state when the kernel space requests access to user space memory through the operating system interface. Each time the access exception state is detected by the target exception handling function, the kernel access execution flow is jumped to the vulnerability detection kernel function. The vulnerability detection kernel function records the memory access information corresponding to the access exception state and resumes the execution of the kernel access execution flow. Based on the memory access information, the electronic device... By performing dual-access vulnerability detection processing on the system interface, the detection results can be obtained. Through sophisticated configuration of the operating system kernel and utilization of hardware access protection mechanisms, a highly efficient detection mode with deep integration of software and hardware is realized. It uses the characteristics of preset hardware access protection mechanisms for access capture. Compared with traditional dynamic analysis tools, it has higher detection efficiency, less impact on system stability, and significantly improved accuracy because it is not affected by system task scheduling. Finally, through automated and deterministic analysis of the recorded information, it can accurately and reliably locate highly concealed dual-access vulnerabilities, providing strong technical support for ensuring the software security of complex systems such as intelligent connected vehicles from the source.

[0290] This specification also provides a computer storage medium that can store multiple instructions adapted to be loaded and executed by a processor as described above. Figures 1 to 7 The vulnerability detection method described in the illustrated embodiment can be found in the following documentation for its specific execution process. Figures 1 to 7 The specific details of the illustrated embodiments will not be elaborated here.

[0291] This specification also provides a computer program product that stores at least one instruction, said at least one instruction being loaded and executed by the processor as described above. Figures 1 to 7The vulnerability detection method described in the illustrated embodiment can be found in the following documentation for its specific execution process. Figures 1 to 7 The specific details of the illustrated embodiments will not be elaborated here.

[0292] Please refer to Figure 9 This is a structural block diagram of an electronic device provided in an embodiment of this specification. The electronic device in this specification may include one or more of the following components: a processor 1010, a memory 1020, an input device 1030, an output device 1040, and a bus 1050. The processor 1010, memory 1020, input device 1030, and output device 1040 may be connected to each other via the bus 1050.

[0293] Processor 1010 may include one or more processing cores. Processor 1010 connects to various parts of the electronic device using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 1020, and by calling data stored in memory 1020. Optionally, processor 1010 may be implemented using at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). Processor 1010 may integrate one or more of a central processing unit (CPU), graphics processing unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into processor 1010 and may be implemented separately through a communication chip.

[0294] The memory 1020 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 1020 may include non-transitory computer-readable storage medium. The memory 1020 may be used to store instructions, programs, code, code sets, or instruction sets.

[0295] The input device 1030 is used to receive input instructions or data, and includes, but is not limited to, a keyboard, mouse, camera, microphone, or touch device. The output device 1040 is used to output instructions or data, and includes, but is not limited to, a display device and a speaker. In this embodiment, the input device 1030 can be a temperature sensor for acquiring the operating temperature of the electronic device. The output device 1040 can be a speaker for outputting audio signals.

[0296] In addition, those skilled in the art will understand that the structure of the electronic device shown in the above figures does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the electronic device may also include radio frequency circuits, input units, sensors, audio circuits, wireless fidelity (WIFI) modules, power supplies, Bluetooth modules, etc., which will not be described in detail here.

[0297] In the embodiments of this specification, the executing entity for each step can be the electronic device described above. Optionally, the executing entity for each step can be the operating system of the electronic device. The operating system can be Android, iOS, or other operating systems; this specification does not limit this.

[0298] exist Figure 9 In the electronic device, the processor 1010 can be used to call a program stored in the memory 1020 and execute it to implement the vulnerability detection method as described in the various method embodiments of this specification.

[0299] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0300] The above-disclosed embodiments are merely preferred embodiments of this specification and should not be construed as limiting the scope of this specification. Therefore, any equivalent variations made in accordance with the claims of this specification shall still fall within the scope of this specification.

Claims

1. A vulnerability detection method, characterized in that, The method includes: Vulnerability detection logic is configured for kernel call functions in the kernel space of the vehicle operating system to obtain the configured vulnerability detection kernel function. The original exception handling function of the vehicle operating system is obtained, and jump vulnerability detection code is configured for the original exception handling function to obtain the configured target exception handling function. The vulnerability detection code is used to jump the kernel access execution flow to the vulnerability detection kernel function when an access anomaly is detected. Based on the vulnerability detection kernel function, a preset hardware access protection mechanism is enabled. The preset hardware access protection mechanism is used to trigger an access exception state when the kernel space requests access to user space memory through the operating system interface. When the access exception state is detected each time by the target exception handling function, the kernel access execution flow is jumped to the vulnerability detection kernel function. The vulnerability detection kernel function records the memory access information corresponding to the access exception state and resumes the execution of the kernel access execution flow. Extract the interface call records of the operating system interface from each of the memory access information; Based on the interface call record, it is detected whether the memory access information includes a preset vulnerability detection feature, which is the feature of at least two accesses to the same user space memory address by the same kernel call function; If the memory access information includes preset vulnerability detection features, then it is determined that the operating system interface has a dual acquisition vulnerability, and a dual acquisition vulnerability detection result for the operating system interface is generated.

2. The method according to claim 1, characterized in that, The step of enabling the preset hardware access protection mechanism based on the vulnerability detection kernel function includes: The vulnerability detection kernel function performs access protection mechanism configuration on the target control register of the device processor to enable the preset hardware access protection mechanism to prohibit kernel mode access to user space memory. The resumption of the kernel access execution process includes: The vulnerability detection kernel function temporarily disables access protection for the target control register of the device processor to disable the preset hardware access protection mechanism, allowing kernel-mode access to user space memory to resume the kernel access execution process. After the kernel access execution process is completed, the step of enabling the preset hardware access protection mechanism based on the vulnerability detection kernel function is executed.

3. The method according to claim 2, characterized in that, The process of enabling access protection mechanism for the target control register of the device processor through the vulnerability detection kernel function includes: In the kernel space of the vehicle operating system, the target control register associated with the access protection control function of the device processor is set to the access protection enabled state; The process of disabling access protection for the target control register of the device processor through the vulnerability detection kernel function includes: In the kernel space of the vehicle operating system, the target control register associated with the access protection control function of the device processor is set to the access protection off state.

4. The method according to claim 1, characterized in that, The step of configuring vulnerability detection logic for kernel call functions in the kernel space of the vehicle operating system to obtain the configured vulnerability detection kernel function includes: In the kernel space of the vehicle operating system, it is detected whether the vehicle operating system supports the function of calling custom kernel functions; If the vehicle operating system supports the custom kernel call function function, then the original kernel call function to be configured is determined, and the vulnerability detection logic is configured on the original kernel call function to obtain the configured vulnerability detection kernel function. If the vehicle operating system does not support the custom kernel call function function, then the silent kernel call function in the kernel call function table is queried, and the vulnerability detection logic is configured for the silent kernel call function to obtain the configured vulnerability detection kernel function. The silent kernel call function is a kernel call function whose kernel call frequency is less than a frequency threshold.

5. The method according to claim 1, characterized in that, The step of configuring jump vulnerability detection code on the original exception handling function to obtain the configured target exception handling function includes: In the kernel space of the vehicle operating system, it is detected whether the vehicle operating system supports custom exception handling functions; If the vehicle operating system supports custom exception handling functions, then the original exception handling function to be configured is determined, and jump vulnerability detection code is configured for the original exception handling function to obtain the configured target exception handling function. If the vehicle operating system does not support custom exception handling functions, then the original binary file corresponding to the original exception handling function is determined, the jump vulnerability detection code is configured in the original binary file to obtain the target binary file, and the target exception handling function is generated based on the target binary file.

6. The method according to claim 1, characterized in that, If the memory access information includes preset vulnerability detection features, then it is determined that the operating system interface has a double-access vulnerability, and a double-access vulnerability detection result for the operating system interface is generated, including: If the memory access information includes preset vulnerability detection features, then it is determined that the operating system interface has a dual acquisition vulnerability, and the abnormal kernel call function, abnormal system call interface and abnormal user space memory address corresponding to the dual acquisition vulnerability are determined. Based on the abnormal kernel call function, the abnormal system call interface, and the abnormal user space memory address, a dual acquisition vulnerability detection result is generated for the operating system interface.

7. A vulnerability detection device, characterized in that, The device includes: The function configuration module is used to configure vulnerability detection logic for kernel call functions in the kernel space of the vehicle operating system, obtain the configured vulnerability detection kernel function, obtain the original exception handling function of the vehicle operating system, configure the jump vulnerability detection code for the original exception handling function, and obtain the configured target exception handling function. The vulnerability detection code is used to jump the kernel access execution flow to the vulnerability detection kernel function when an access anomaly is detected. The mechanism activation module is used to activate a preset hardware access protection mechanism based on the vulnerability detection kernel function. The preset hardware access protection mechanism is used to trigger an access exception state when the kernel space requests access to user space memory through the operating system interface. An anomaly detection module is used to jump the kernel access execution flow to the vulnerability detection kernel function each time the access anomaly state is detected by the target anomaly handling function, and to record the memory access information corresponding to the access anomaly state and resume the execution of the kernel access execution flow through the vulnerability detection kernel function. The vulnerability detection module is used to extract the interface call record of the operating system interface from each of the memory access information. Based on the interface call record, it detects whether the memory access information includes a preset vulnerability detection feature. The preset vulnerability detection feature is the feature that the same kernel function accesses the same user space memory address at least twice. If the memory access information includes the preset vulnerability detection feature, it is determined that the operating system interface has a double acquisition vulnerability, and a double acquisition vulnerability detection result for the operating system interface is generated.

8. The apparatus according to claim 7, characterized in that, The step of enabling the preset hardware access protection mechanism based on the vulnerability detection kernel function includes: The vulnerability detection kernel function performs access protection mechanism configuration on the target control register of the device processor to enable the preset hardware access protection mechanism to prohibit kernel mode access to user space memory. The resumption of the kernel access execution process includes: The vulnerability detection kernel function temporarily disables access protection for the target control register of the device processor to disable the preset hardware access protection mechanism, allowing kernel-mode access to user space memory to resume the kernel access execution process. After the kernel access execution process is completed, the step of enabling the preset hardware access protection mechanism based on the vulnerability detection kernel function is executed.

9. The apparatus according to claim 8, characterized in that, The process of enabling access protection mechanism for the target control register of the device processor through the vulnerability detection kernel function includes: In the kernel space of the vehicle operating system, the target control register associated with the access protection control function of the device processor is set to the access protection enabled state; The process of disabling access protection for the target control register of the device processor through the vulnerability detection kernel function includes: In the kernel space of the vehicle operating system, the target control register associated with the access protection control function of the device processor is set to the access protection off state.

10. The apparatus according to claim 7, characterized in that, The step of configuring vulnerability detection logic for kernel call functions in the kernel space of the vehicle operating system to obtain the configured vulnerability detection kernel function includes: In the kernel space of the vehicle operating system, it is detected whether the vehicle operating system supports the function of calling custom kernel functions; If the vehicle operating system supports the custom kernel call function function, then the original kernel call function to be configured is determined, and the vulnerability detection logic is configured on the original kernel call function to obtain the configured vulnerability detection kernel function. If the vehicle operating system does not support the custom kernel call function function, then the silent kernel call function in the kernel call function table is queried, and the vulnerability detection logic is configured for the silent kernel call function to obtain the configured vulnerability detection kernel function. The silent kernel call function is a kernel call function whose kernel call frequency is less than a frequency threshold.

11. The apparatus according to claim 7, characterized in that, The step of configuring jump vulnerability detection code on the original exception handling function to obtain the configured target exception handling function includes: In the kernel space of the vehicle operating system, it is detected whether the vehicle operating system supports custom exception handling functions; If the vehicle operating system supports custom exception handling functions, then the original exception handling function to be configured is determined, and jump vulnerability detection code is configured for the original exception handling function to obtain the configured target exception handling function. If the vehicle operating system does not support custom exception handling functions, then the original binary file corresponding to the original exception handling function is determined, the jump vulnerability detection code is configured in the original binary file to obtain the target binary file, and the target exception handling function is generated based on the target binary file.

12. The apparatus according to claim 7, characterized in that, If the memory access information includes preset vulnerability detection features, then it is determined that the operating system interface has a double-access vulnerability, and a double-access vulnerability detection result for the operating system interface is generated, including: If the memory access information includes preset vulnerability detection features, then it is determined that the operating system interface has a dual acquisition vulnerability, and the abnormal kernel call function, abnormal system call interface and abnormal user space memory address corresponding to the dual acquisition vulnerability are determined. Based on the abnormal kernel call function, the abnormal system call interface, and the abnormal user space memory address, a dual acquisition vulnerability detection result is generated for the operating system interface.

13. A computer storage medium, characterized in that, The computer storage medium stores a plurality of instructions, which are adapted to be loaded by a processor and executed as method steps as claimed in any one of claims 1 to 7.

14. A computer program product, characterized in that, The computer program product stores at least one instruction, which is loaded by a processor and executed as a method step as claimed in any one of claims 1 to 7.

15. An electronic device, characterized in that, include: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed the method steps as claimed in any one of claims 1 to 7.

Images