Terminal security product detection method, device, equipment and storage medium

Abstract

Embodiments of the present disclosure provide a terminal security product detection method, device, equipment and storage medium. The method loads a system library by calling a system-level interface, obtains a memory address of a target function and verifies the validity after success; when the memory address is valid, instruction data at the memory address of the target function is read, it is judged whether the instruction data contains a jump instruction, if it contains, the target address is parsed and jumped to the target address, the instruction data is read again, it is judged again whether the instruction data contains a jump instruction, if it does not contain, the instruction data is taken as actual entry point code data; then the instruction data is converted into a matchable format, matched with security feature identifiers in a preset terminal security product feature library, and a detection result is output according to a matching result. Efficient identification of terminal security products is realized, detection risks caused by file or registry operations are avoided, detection accuracy and real-time performance are improved, low-trace operation characteristics are possessed, and anti-detection mechanisms of security products are effectively avoided.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of terminal security testing technology and related technical fields, specifically to a testing method, apparatus, device, and storage medium applicable to a terminal security product. Background Technology

[0002] With the rapid development of information technology, endpoint security technology is also constantly being upgraded. Today, more and more enterprises and organizations are adopting advanced antivirus (AV) software and endpoint detection and response (EDR) systems to protect their endpoint devices. These technologies can not only effectively identify and block known malware, but also detect unknown threats through behavioral analysis and machine learning algorithms. For red team penetration testers, this means their attacks are more easily detected and intercepted. Traditional attack methods, such as exploiting known vulnerabilities or simple social engineering attacks, are often ineffective because these behaviors are likely to be identified as anomalous activity by AV / EDR systems and trigger timely alerts. Red teams have to invest more time and effort in researching new attack methods to bypass these robust protection mechanisms.

[0003] However, in existing technologies, to circumvent AV / EDR systems on the terminal, a detailed inspection of the target terminal environment is required to identify the security protection system. However, common terminal awareness technologies (such as process service matching, registry matching, and hook detection) leave obvious operational traces that are easily detected by monitoring systems. For example, process service matching relies on system commands or API calls to enumerate processes, leaving records in system logs; registry matching generates clear access records by reading registry entries; and hook detection, by detecting API function hijacking, exposes traces in system logs or memory scans. Furthermore, methods of obtaining application information through system commands or API calls are also easily identified by security monitoring systems due to log records or call logs.

[0004] Therefore, there is an urgent need for a testing method for terminal security products to solve the above problems. Summary of the Invention

[0005] The embodiments described herein provide a detection method, apparatus, device, and storage medium for terminal security products, addressing the problems existing in the prior art.

[0006] According to a first aspect of this disclosure, a method for testing terminal security products is provided, comprising:

[0007] Load system libraries by calling system-level interfaces;

[0008] When the system library is successfully loaded, the memory address of the target function is obtained, and the validity of the memory address is verified.

[0009] When the memory address is valid, read the instruction data at the memory address and parse the instruction data to determine whether it contains a jump instruction;

[0010] If the instruction data contains the jump instruction, then the following sub-steps are performed: parse the target address of the jump instruction and jump to the target address; reread the instruction data at the memory address and determine again whether the jump instruction is contained; if the second determination result is that the jump instruction is not contained, then the instruction data is recorded as the actual entry point code data of the target function;

[0011] The actual entry point code data is converted into a matchable code data and matched with the security feature identifier in the preset terminal security product feature library to obtain the matching result;

[0012] Based on the matching results, the detection results of the terminal security products are output.

[0013] In some embodiments of this disclosure, the step of obtaining the instruction data at the memory address includes:

[0014] The target function is used to read memory data of a predetermined length at the memory address.

[0015] In some embodiments of this disclosure, after the step of determining again whether the jump instruction is included, the method further includes:

[0016] If the second determination result is that the jump instruction is included, then the target address of the jump instruction is parsed again, and the jump is performed to the target address.

[0017] In some embodiments of this disclosure, the jump instruction includes instructions for implementing code execution flow hijacking.

[0018] In some embodiments of this disclosure, the step of matching the security feature identifier with a pre-set terminal security product feature library to obtain a matching result includes:

[0019] A sliding window matching mechanism is used to compare the code data in the matchable format with the security feature identifiers in the terminal security product feature library bit by bit until a match is successful or the traversal is completed.

[0020] In some embodiments of this disclosure, the step of employing the sliding window matching mechanism specifically includes:

[0021] Step a: Starting from the first address of the code data in the matching format, read a predetermined length of continuous memory data as a comparison buffer;

[0022] Step b: Extract the N-byte data block of the current window from the comparison buffer and perform a binary comparison with the feature data in the preset terminal security product feature library;

[0023] Step c: When the N-byte data block completely matches the feature data, it is determined that the match is successful and the comparison process is terminated.

[0024] Step d: When no match is found, slide the comparison window backward by M bytes, and repeat steps b and c until the comparison buffer is exhausted or the maximum number of matches is reached.

[0025] Wherein, N and M are preset positive integers, and M≤N.

[0026] In some embodiments of this disclosure, the step of outputting the detection result of the terminal security product based on the matching result includes:

[0027] When a match is successful, the output detection result includes at least one of the following: the name of the detected security product, product version identification information, and the memory address of the Hook location.

[0028] When a match fails, a message indicating that no terminal security product was detected is output.

[0029] According to a second aspect of this disclosure, a detection device for terminal security products is provided, comprising:

[0030] The loading module is used to load system libraries by calling system-level interfaces;

[0031] The acquisition and verification module is used to acquire the memory address of the target function and verify the validity of the memory address when the system library is successfully loaded.

[0032] The parsing and detection module is used to read the instruction data at the memory address when the memory address is valid, and parse the instruction data to determine whether it contains a jump instruction;

[0033] The processing module is configured to, if the instruction data contains the jump instruction, execute the following sub-steps: parse the target address of the jump instruction and jump to the target address; reread the instruction data at the memory address and determine again whether it contains the jump instruction; if the second determination result is that it does not contain the jump instruction, record the instruction data as the actual entry point code data of the target function;

[0034] The feature matching module is used to convert the actual entry point code data into code data in a matchable format, and match it with the security feature identifier in the preset terminal security product feature library to obtain the matching result;

[0035] The result output module is used to output the detection results of the terminal security product based on the matching results.

[0036] In some embodiments of this disclosure, the instruction parsing and detection module is further configured to use the target function to read memory data of a predetermined length at the memory address.

[0037] In some embodiments of this disclosure, the instruction parsing and detection module is further configured to, if the second determination result is that the jump instruction is included, parse the target address of the jump instruction again and jump to the target address.

[0038] In some embodiments of this disclosure, the jump instruction includes instructions for implementing code execution flow hijacking.

[0039] In some embodiments of this disclosure, the feature matching module is further configured to use a sliding window matching mechanism to compare the code data of the matchable format with the security feature identifier in the terminal security product feature library bit by bit until a match is successful or the traversal is completed.

[0040] In some embodiments of this disclosure, the feature matching module is specifically used to read a predetermined length of continuous memory data as a comparison buffer, starting from the first address of the code data in the matchable format; extract an N-byte data block of the current window from the comparison buffer and perform a binary comparison with the feature data in the terminal security product feature library; when the N-byte data block completely matches the feature data, it is determined that the match is successful and the comparison process is terminated; when the match is unsuccessful, the comparison window is slid backward by M bytes, and the above steps of extracting the N-byte data block of the current window from the comparison buffer and performing a binary comparison with the feature data in the preset terminal security product feature library are repeated until the N-byte data block completely matches the feature data and the comparison process is terminated, until the comparison buffer is traversed or the maximum number of matches is reached; wherein, N and M are preset positive integers, and M≤N.

[0041] In some embodiments of this disclosure, the result output module is specifically used to output the detection result when the match is successful, including at least one of the following: the name of the detected security product, the product version identification information, and the memory address of the Hook location; when the match fails, it outputs a prompt message indicating that no terminal security product was detected.

[0042] According to a third aspect of this disclosure, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method as described in any of the above embodiments.

[0043] According to a fourth aspect of this disclosure, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the method as described in any of the above embodiments.

[0044] The present disclosure provides a method, apparatus, device, and storage medium for detecting terminal security products. The method loads a system library by calling a system-level interface. Upon successful loading, it obtains the memory address of the target function and verifies its validity. If valid, it reads the instruction data at the memory address, parses it to determine if it contains a jump instruction. If the instruction data contains the jump instruction, it executes the following sub-steps: parses the target address of the jump instruction and jumps to the target address; rereads the instruction data at the memory address of the target function and again determines if it contains the jump instruction; if the second determination result is that it does not contain instruction data, it uses the instruction data as the actual entry point code data of the target function; subsequently, it converts the code data into a matchable format and matches it with security feature identifiers in a preset terminal security product feature library, outputting the detection result based on the matching result. This memory feature detection mechanism achieves efficient and accurate identification of terminal security products, avoiding detection risks associated with file or registry operations, significantly improving detection accuracy and real-time performance, while also possessing low-trace operation characteristics, effectively circumventing anti-detection mechanisms. Employing binary feature matching technology, this solution precisely locates instruction-level modifications at function entry points (such as hooked jump instructions). Even in the face of obfuscated and encrypted memory tampering (such as interference instruction insertion or address spoofing), it can still achieve accurate identification at the instruction set level through byte-level comparison using a rule base. Based on a progressive verification process of "Hook behavior detection + binary feature matching," it first quickly screens for memory tampering through instruction sequence features (such as E9 jump instructions), and then confirms the security product type by comparing with a rule base, avoiding false positives caused by system code optimization or version differences, thus reducing the false positive rate by more than 70%. Furthermore, it employs an iterative memory reading mechanism to dynamically track jump instructions to reconstruct the actual execution path, accurately identifying hidden hook behaviors, with jump address resolution accuracy reaching the memory byte level. This solution relies only on a basic memory reading interface, without file, registry, or network operations, reducing system interaction logs by more than 90%, compressing the program size to a lightweight level (<100KB), and supporting covert transmission to evade conventional detection. Meanwhile, through a unified memory feature detection logic, it adapts to API Hook technology on platforms such as Windows (e.g., NtAllocateVirtualMemory) and Linux (e.g., mmap), covering more than 90% of commercial security protection tools, and achieving efficient cross-platform identification.

[0045] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0046] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings of the embodiments will be briefly described below. It should be understood that the drawings described below only relate to some embodiments of this disclosure and are not intended to limit this disclosure, wherein:

[0047] Figure 1 This is a schematic flowchart of a detection method for a terminal security product provided in an embodiment of this disclosure;

[0048] Figure 2 This is a flowchart illustrating an example of a detection method for a terminal security product provided in this disclosure.

[0049] Figure 3 This is a schematic diagram of the structure of a detection device for a terminal security product provided in an embodiment of this disclosure;

[0050] Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this disclosure.

[0051] In the accompanying diagram, markers with the same last two digits correspond to the same elements. It should be noted that the elements in the diagram are schematic and not drawn to scale. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the described embodiments of this disclosure without creative effort are also within the scope of protection of this disclosure.

[0053] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of the phrase "embodiment" in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0054] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists, A and B exist simultaneously, or B exists. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0055] Furthermore, in all embodiments of this disclosure, terms such as “first” and “second” are used only to distinguish one component (or part of a component) from another component (or another part of a component).

[0056] In the description of this application, unless otherwise stated, "multiple" means two or more (including two), and similarly, "multiple groups" means two or more (including two groups).

[0057] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0058] Based on the problems existing in the current technology Figure 1 This is a flowchart illustrating a detection method for a terminal security product provided in an embodiment of this disclosure, as shown below. Figure 1 As shown, the specific process of the testing method for terminal security products includes:

[0059] S110. Load system libraries by calling system-level interfaces.

[0060] Optionally, the system-level interfaces include, but are not limited to, the Windows API interface and the Linux C library (glibc) interface.

[0061] Optionally, the system library is a dynamic link library in the operating system, such as the Ntdll.dll library in Windows. Its main functions include: providing system call interfaces (such as Native APIs), enabling interaction between applications and the kernel layer, including low-level functions such as process management, memory management, and thread scheduling (such as NtCreateProcess and NtAllocateVirtualMemory), serving as a bridge between user mode and kernel mode, and many system-level operations (such as process injection and API Hook detection) involve calling this library.

[0062] Optionally, the target function is a low-level function related to memory management, process control, or system calls.

[0063] In the actual implementation process, system libraries are loaded by calling the system-level interfaces in the operating system application programming interface.

[0064] If loading fails, the detection process will be terminated.

[0065] Optionally, before step S110, the method further includes:

[0066] S100, Startup process;

[0067] In practice, the target program can be run directly via the command prompt (cmd), or a new process can be created programmatically using APIs such as CreateProcess. This not only launches the target application but also establishes the process environment for subsequent memory operations and function detection. The choice of launch method depends on actual needs: running directly via cmd facilitates debugging and logging, while creating a process via API makes the entire detection logic easier to integrate into automation tools.

[0068] S120. When the system library is successfully loaded, the memory address of the target function is obtained, and the validity of the memory address of the target function is verified.

[0069] In the specific implementation process, if the verification result is valid, that is, the returned function address is a non-null handle, then the next step is executed. If the verification result is invalid, that is, the returned function address is a null address or a specified error code, then it means that the address acquisition failed and the detection process is terminated.

[0070] In one specific embodiment, if the system is Windows, the Ntdll.dll library is loaded through the LoadLibrary("ntdll.dll") function, and the Ntdll.dll library is loaded into the address space of the detection tool process to obtain the library handle hNtdll.

[0071] Validity verification: If hNtdll == NULL, loading is considered to have failed. Common reasons include:

[0072] Insufficient user access permissions (e.g., not running as an administrator);

[0073] The library file is corrupted or the version is incompatible (such as system files being tampered with).

[0074] If loading fails, output an error message (e.g., obtain the specific error code using GetLastError()) and terminate the program; if loading succeeds, proceed to the next step.

[0075] Call GetProcAddress(hNtdll, "NtAllocateVirtualMemory") to obtain the actual memory address of the function, lpNtAllocateVirtualMemory.

[0076] Validity verification: If lpNtAllocateVirtualMemory == NULL, the retrieval fails. Possible reasons include:

[0077] The function name is misspelled (e.g., "NtAllocateVirtualMemory" is misspelled).

[0078] System version differences (e.g., the objective function has been renamed or removed in the current Windows version).

[0079] Successful processing: The valid address is recorded in the memory variable func_addr, which will serve as the base address for subsequent memory checks.

[0080] In another specific embodiment, if the target system is Linux, the C standard library is loaded through the dlopen("libc.so.6", RTLD_NOW) function to obtain the library handle.

[0081] Validity verification: If handle == NULL, loading is considered to have failed. Common reasons include:

[0082] The library file path is incorrect (e.g., libc.so.6 is not installed on the system).

[0083] Insufficient permissions (e.g., lack of file read permissions).

[0084] If loading fails, retrieve the error message using dlerror() and terminate the program; if loading succeeds, proceed to the next step.

[0085] Call dlsym(handle, "mmap") to get the memory address lpMmap of the mmap function.

[0086] Validity verification: If lpMmap == NULL, the retrieval failed. Possible reasons include:

[0087] Incorrect symbol name (e.g., "mmap" is misspelled);

[0088] Library version incompatibility (e.g., the target function does not exist in the current libc version).

[0089] Successful processing: Record the valid address func_addr for subsequent memory instruction reads.

[0090] S130. When the memory address of the target function is valid, read the instruction data at the memory address of the target function and parse the instruction data to determine whether it contains a jump instruction.

[0091] Optionally, the target function can be used to read memory data of a predetermined length at the memory address of the target function.

[0092] Specifically, the jump instructions include, but are not limited to, instructions used to hijack the code execution flow, and their machine code values ​​are specific values.

[0093] In the specific implementation process, `ReadProcessMemory` is called to read the memory instruction data at the function entry point. A jump instruction search is performed on this memory instruction data to check for the presence of jump instructions. The `ReadProcessMemory` function is used to read and record the memory instruction data at the target address. Specifically, starting from the address obtained in the previous step, `ReadProcessMemory` reads a certain range of memory data, which typically contains the first few instructions of the target function. By reading this binary data and representing it in hexadecimal form, it is easy to compare it with the standard function code later to determine if there are any abnormal modifications. Recording this raw instruction data is the foundation of the entire detection process, ensuring that subsequent matching and verification have a clear basis.

[0094] The process of determining whether the memory instruction data at the target address contains jump instructions involves the following steps: If an abnormal jump instruction (e.g., starting with hexadecimal E9) is found in the read memory data, it usually means that the function entry point has been hooked. In this case, the program needs to further parse the jump instruction and calculate the destination address. This destination address is then used as a new checkpoint, and the code is read again to obtain the actual code data executed after the jump. If no jump instruction is detected, it means that the code region remains intact, and the detection process terminates.

[0095] The process reads and records memory instruction data at the target address. Specifically, upon detecting a jump instruction, the program re-reads the memory instruction data at the target address using ReadProcessMemory. Recording this data allows us to obtain the code segment actually loaded and executed after being hooked. This data collection ensures that the detection process covers code areas that may have been modified by malicious or legitimate security products, providing a more accurate analytical basis for subsequent feature matching.

[0096] In some specific implementations, ReadProcessMemory(process_handle, func_addr, buffer, size, &read_bytes) is called to read a preset number of bytes (such as the first 16 bytes) starting from func_addr into buffer;

[0097] Parse the instructions in the buffer: If a jump instruction (hexadecimal E9) is detected, calculate the jump target address: target_addr = func_addr + offset;

[0098] Jump to target_addr, repeatedly execute ReadProcessMemory and jump detection until there are no more jump instructions (hexadecimal E9) in the instruction set, and record the final buffer as the actual executed code data.

[0099] Optionally, the machine code value of the jump instruction is a specific hexadecimal value.

[0100] S140. If the instruction data contains the jump instruction, then the following sub-steps are performed:

[0101] S1401. Parse the target address of the jump instruction;

[0102] S1402, Jump to the target address;

[0103] S1403. Reread the instruction data at the memory address of the target function, and determine again whether the instruction data contains the jump instruction;

[0104] S1404. If the second judgment result is that the jump instruction is not present, then the instruction data is recorded as the actual entry point code data of the target function;

[0105] In some embodiments, after S1403, the method further includes:

[0106] S1405. If the instruction data at the current memory address still contains the jump instruction, then the target address of the jump instruction is parsed again, and the jump is performed to the target address.

[0107] Optionally, the instruction data at the memory address of the target function is read twice and the jump instruction is checked twice in order to successfully find the actual entry point of the target function.

[0108] S150. Convert the actual entry point code data into code data in a matchable format according to a predetermined rule, and match it with the security feature identifier in the preset terminal security product feature library to obtain the matching result.

[0109] Optionally, the predetermined rules include converting the actual entry point code into hexadecimal format. For example, converting the binary instruction E801000000 into the string "E801000000" to form a standardized, matchable data sequence.

[0110] Optionally, the feature library data is obtained through non-public reverse engineering. This involves manually performing dynamic debugging and static disassembly on the target security program to extract the underlying feature data of its Hook operations. For example, the feature data is specified as a 16-byte hexadecimal sequence (e.g., "4883EC2848896C24304889742438"), covering the modification range of typical Hook instructions.

[0111] Optionally, a sliding window matching mechanism is adopted to compare the actual executed code data with the security feature identifier bit by bit or block by block until a match is successful or the traversal is completed.

[0112] Optionally, starting from the first byte of the code data, a sub-data block of the same length as the feature data (16 bytes) is extracted. The memcmp function is used to precisely compare the sub-data block with the hexadecimal features in the feature library: if there is a complete match, the recognition is considered successful and the matching is terminated; if there is no match, the sliding window moves forward by 1 byte, and the extraction and comparison operation is repeated until all data (such as a 256-byte memory segment) is traversed.

[0113] Optionally, the step of employing a sliding window matching mechanism to compare the matchable code data with security feature identifiers in the feature library bit by bit until a match is successful or the traversal is complete specifically includes:

[0114] Step a: Starting from the first address of the code data in the matching format, read a predetermined length of continuous memory data as a comparison buffer;

[0115] Step b: Extract the N-byte data block of the current window from the comparison buffer and perform a binary comparison with the feature data in the preset terminal security product feature library;

[0116] Step c: When the N-byte data block completely matches the feature data, it is determined that the match is successful and the comparison process is terminated.

[0117] Step d: When no match is found, slide the comparison window backward by M bytes, and repeat steps b and c until the comparison buffer is exhausted or the maximum number of matches is reached.

[0118] Wherein, N and M are preset positive integers, and M≤N.

[0119] For example: Read memory data: 0x256 bytes → convert to hexadecimal string → Window 1: compare the first 16 bytes with the feature library → no match → Window 2: compare bytes 2-17 → and so on → when a match is successful, record the offset and feature identifier.

[0120] A YARA-like rule matching system is adopted, including:

[0121] Matching modes: The following feature matching methods are supported:

[0122] Exact match: Strictly compare the hexadecimal byte sequence (e.g., "E900000000" must be exactly the same);

[0123] Fuzzy matching: uses wildcards (such as "??" representing any byte) to be compatible with code obfuscation scenarios (such as "4883EC??48896C2430");

[0124] Relative offset matching: Specifies the relative position of the feature in the code segment (e.g., $hook_pattern at 0 requires the feature to be located at the beginning of the data).

[0125] By combining regular expressions with offset positioning, it is possible to adapt to the hook features of security products (such as inserting irrelevant instructions or address offset adjustments).

[0126] The program performs hexadecimal matching between memory instruction data and known endpoint security product characteristic data. Specifically, after obtaining the hexadecimal representation of the target code, the program compares it with a pre-built feature library. This feature library stores specific binary signatures of various endpoint security products or other security tools. Through rigorous hexadecimal matching, it can quickly detect whether the memory code contains characteristic information consistent with known products. This process accurately identifies modified or clearly marked security product modules, providing a basis for subsequent judgments.

[0127] The program determines whether a specific endpoint security product is matched. If so, it outputs the detection result; otherwise, no endpoint security product was detected. Specifically, after hexadecimal matching, the program determines whether the current memory area contains the predetermined endpoint security product characteristics based on the matching result. If a match is detected, it indicates that a specific security product exists in the system, and the result will be recorded and output with relevant information, such as the product name, version number, and the specific location of the Hook. If no match is found, it means that this code segment does not display any known characteristics, and the program will output the message "No endpoint security product detected."

[0128] One possible implementation supports updating the security product feature library via cloud synchronization or local import to adapt to variant features of new security products.

[0129] S160. Based on the matching result, output the detection result of the terminal security product;

[0130] In the specific implementation process, when a match is successfully made with any of the terminal security product features in the terminal security product feature library, it indicates that a terminal security product has been detected. The output detection result includes at least one of the following: the name of the detected security product, product version identification information, and the memory address of the Hook location. When the match fails, it indicates that no terminal security product has been detected, and a prompt message indicating that no terminal security product has been detected is output.

[0131] In some optional embodiments, the results are output as follows:

[0132] If the match is successful, the output will include the security product name (e.g., "XX Security Guard"), Hook location (func_addr or target_addr), and other information.

[0133] If the match fails, the output will be "No target security product detected".

[0134] Optionally, after step S150, the method further includes:

[0135] S160. After completing all detection and matching processes, the program performs cleanup: releasing all allocated memory, closing open handles, and archiving or reporting detection logs and results to ensure the integrity and traceability of the detection process. Finally, the program exits normally.

[0136] The Hook behavior detection in step S120 and the feature matching in step S140 constitute a dual verification mechanism: first, code tampering behavior is detected through jump instructions (Hook existence verification), and then the type of security product is confirmed through feature library matching (qualitative verification), significantly reducing the false positive rate. Detecting Hook behavior first and then verifying feature consistency greatly reduces the false positive rate.

[0137] The terminal security product detection method provided in this disclosure loads a system library by calling a system-level interface. Upon successful loading, the memory address of the target function is obtained and its validity verified. When the memory address is valid, the instruction data at that address is read, parsed, and its inclusion of a jump instruction is determined. If a jump instruction is included, the target address is parsed and the user jumps to that address. The instruction data is then read again, and the jump instruction is checked again. If no jump instruction is included, the instruction data is used as the actual entry point code data. This data is then converted to a matchable format and matched against security feature identifiers in a pre-set terminal security product feature library. The detection result is output based on the matching result. This method achieves efficient identification of terminal security products, avoids detection risks caused by file or registry operations, improves detection accuracy and real-time performance, and features low-trace operation characteristics, effectively circumventing anti-detection mechanisms of security products.

[0138] The following two examples illustrate this point:

[0139] Example 1:

[0140] like Figure 2 The diagram shown is a flowchart of this embodiment 1.

[0141] 1. Application starts;

[0142] The target program can be run directly via the command prompt, or a new process can be created programmatically by calling API interfaces such as CreateProcess. This operation establishes the process runtime environment, providing a foundation for subsequent memory operations and function detection. Command-line startup facilitates debugging and logging, while API interface startup is beneficial for integration into automated detection tools. The specific startup method can be chosen according to actual needs.

[0143] 2. Loading the Ntdll library;

[0144] After the process starts, the Ntdll.dll library is loaded into the current process's address space by calling the Windows API function LoadLibrary. Ntdll.dll contains the implementation of low-level system functions (such as memory management and system calls), and loading this library is a necessary prerequisite for obtaining the addresses of subsequent functions.

[0145] 3. Verify the validity of library loading;

[0146] After calling LoadLibrary, the returned pointer must be checked for nullability. If the pointer is valid, it indicates that Ntdll.dll has been successfully loaded, and subsequent steps can continue; if the pointer is null, it is determined that loading has failed (possibly due to insufficient permissions, file corruption, or version incompatibility, etc.), and the program will exit immediately to avoid abnormal operations.

[0147] 4. Obtain the address of the target function;

[0148] After the library loads successfully, the GetProcAddress function is used to query the actual memory address of the NtAllocateVirtualMemory function in Ntdll.dll. This function is the low-level interface for Windows system memory allocation, and its address is a crucial reference for subsequent memory data reading.

[0149] 5. Function address validity verification;

[0150] The validity of the obtained NtAllocateVirtualMemory function address is verified: if the address is empty, the acquisition is deemed to have failed (possibly due to a misspelled function name, system version differences, or the function being tampered with), and the program exits safely; if the address is valid, it is recorded to a memory variable or log to provide a benchmark for subsequent testing.

[0151] 6. Memory instruction data reading;

[0152] The `ReadProcessMemory` function is used to read a range of memory data (usually containing the first few instructions) from the starting address of the target function, and then converts the binary data into hexadecimal format for recording. This raw instruction data is the basis for subsequent comparison with standard function code. The size of the read binary data is 256 bytes.

[0153] 7. Jump instruction detection;

[0154] The read memory data is parsed. If a jump instruction starting with hexadecimal E9 is found (a typical feature of a function entry point being hooked), the jump destination address is calculated and used as a new detection point. The process then returns to step 6 to reread the memory data. If no jump instruction is detected, it indicates that the code area has not been modified, and the process proceeds directly to the feature matching step.

[0155] 8. Data reading after hooking;

[0156] When a jump instruction is detected, the memory instruction data at the jump destination address is read through the ReadProcessMemory function, and the data is recorded to obtain the actual code segment executed, ensuring that the detection covers areas that may be modified by security tools.

[0157] 9. Hexadecimal feature matching;

[0158] The read memory instruction data is compared in hexadecimal with a pre-built endpoint security product signature database. The signature database stores binary signatures of various security tools, and precise matching can identify whether the memory code contains signature information of known security products.

[0159] 10. Determination of test results;

[0160] The system determines whether an endpoint security product exists based on the matching results: if a signature in the feature library is matched, the detection result is output (including product name, version number, and Hook location, etc.); if no feature is matched, the conclusion "No endpoint security product detected" is output.

[0161] 11. Program termination;

[0162] After the detection process is completed, resource cleanup operations are performed (releasing memory, closing handles, etc.), and the detection logs and results are archived or reported to ensure the traceability of the detection process. Finally, the program exits normally.

[0163] Example 2: Testing of Windows-based terminal security products

[0164] This embodiment uses the Windows operating system as an example to detail the complete process of a memory feature detection-based terminal security product. The specific steps are as follows:

[0165] 1. Target process startup and system library loading

[0166] Process initialization: Start the target process (such as notepad.exe) through the CreateProcess API, obtain the process handle hProcess, and build the process environment for memory operations.

[0167] Ntdll library loading and verification: In the detection tool process, call LoadLibrary("ntdll.dll") to obtain the library handle hNtdll. If hNtdll == NULL (due to insufficient permissions, corrupted library file, etc.), output "Library loading failed" and terminate the program.

[0168] Target function address acquisition and verification: Obtain the function address lpNtAllocateVirtualMemory using GetProcAddress(hNtdll, "NtAllocateVirtualMemory"). If the address is NULL (due to incorrect function name or system version incompatibility), output "Function address acquisition failed" and terminate the program.

[0169] 2. Iterative Hook Behavior Detection

[0170] First memory data read: Call ReadProcessMemory(hProcess,lpNtAllocateVirtualMemory,&buffer[0], 16,&bytesRead) to read the first 16 bytes of instructions at the entry point of the target function and store them in the buffer buffer.

[0171] Jump instruction parsing and iteration: Parse the first 5 bytes of the buffer (typical hook modification range). If the hexadecimal value E9 is found (corresponding to the jmp instruction):

[0172] Calculate the jump offset: offset = *(DWORD*)(buffer + 1) (the last 4 bytes of the E9 instruction are the relative offset);

[0173] Calculate the target address: targetAddr = (LPVOID)((DWORD)lpNtAllocateVirtualMemory +5 + offset);

[0174] Starting from targetAddr, repeatedly call the ReadProcessMemory instruction until there are no more E9 instructions in the buffer.

[0175] Record the final code data: Assume that the instructions read after two iterations are 4883EC28 48896C24304889742438 (hexadecimal), which will be used as the actual code segment executed.

[0176] 3. Steps for hexadecimal feature matching and result determination

[0177] Example of a feature library rule: The preset YARA rule is used to match the Hook feature of a security product. It matches code that starts with the instruction sequence such as sub rsp,28h, mov [rsp+30h], rbx, etc., and requires the feature to be located at the beginning of the code.

[0178] Matching and Output: Compare the hexadecimal code string with the signature database. If it matches the above rules, it is determined that "XXX Security Guard" exists, and the following output is given:

[0179] Endpoint security product detected: XXX Security Guard

[0180] Hooked function: NtAllocateVirtualMemory

[0181] Hook initial address: 0x7FFE00001234

[0182] Actual execution address: 0x7FFE00005678

[0183] This embodiment employs a dual verification mechanism, which uses E9 commands to detect hooking behavior (behavior verification) and feature library matching to confirm product type (feature verification), thereby reducing the false alarm rate.

[0184] Based on the above embodiments, this disclosure also provides a detection device for terminal security products, such as... Figure 3 As shown, the detection device for terminal security products includes:

[0185] Loading module 310 is used to load system libraries by calling system-level interfaces;

[0186] The dynamic acquisition and verification module 320 is used to acquire the memory address of the target function and verify the validity of the memory address of the target function when the system library is successfully loaded.

[0187] The instruction parsing and detection module 330 is used to read the instruction data at the memory address of the target function when the memory address is valid, and parse the instruction data to determine whether it contains a jump instruction;

[0188] The processing module 340 is configured to, if the instruction data contains the jump instruction, perform the following sub-steps: parse the target address of the jump instruction and jump to the target address; reread the instruction data at the memory address and determine again whether it contains the jump instruction; if the second determination result is that the instruction data does not contain the jump instruction, then record the instruction data as the actual entry point code data of the target function;

[0189] The feature matching module 350 is used to convert the actual entry point code data into code data in a matchable format, and match it with the security feature identifier in the preset terminal security product feature library to obtain the matching result;

[0190] The result output module 360 ​​is used to output the detection results of the terminal security product based on the matching results.

[0191] In a specific implementation, the instruction parsing and detection module 330 is also used to read memory data of a predetermined length at the memory address of the target function using the target function.

[0192] In a specific implementation, the instruction parsing and detection module 330 is further configured to, if the second judgment result is that the jump instruction is included, parse the target address of the jump instruction again and jump to the target address.

[0193] In specific implementations, the jump instruction includes, but is not limited to, instructions used to hijack the code execution flow.

[0194] In a specific implementation, the feature matching module 350 is further configured to use a sliding window matching mechanism to compare the code data of the matchable format with the security feature identifiers in the terminal security product feature library bit by bit until a match is successful or the traversal is completed.

[0195] In a specific implementation, the feature matching module 350 is specifically used to read a predetermined length of continuous memory data as a comparison buffer, starting from the first address of the code data of the matchable format; extract an N-byte data block of the current window from the comparison buffer and perform a binary comparison with the feature data in the terminal security product feature library; when the N-byte data block completely matches the feature data, it is determined that the match is successful and the comparison process is terminated; when the match is unsuccessful, the comparison window is slid backward by M bytes, and the above steps of extracting the N-byte data block of the current window from the comparison buffer and performing a binary comparison with the feature data in the preset terminal security product feature library are repeated until the N-byte data block completely matches the feature data and the comparison process is terminated, until the comparison buffer is traversed or the maximum number of matches is reached; wherein, N and M are preset positive integers, and M≤N.

[0196] In a specific implementation, the result output module 360 ​​is specifically used to output the detection result when the match is successful, including at least one of the following: the name of the detected security product, the product version identification information, and the memory address of the Hook location; when the match fails, it outputs a prompt message indicating that no terminal security product was detected.

[0197] This disclosure provides a detection device for terminal security products. It combines a static feature library with real-time memory data to form a dual verification mechanism. By organically integrating a multi-step Hook detection method with a precise feature matching algorithm, it achieves efficient identification of specific security products within the terminal. Dynamic memory reading and address verification, iterative Hook jump parsing, and hexadecimal feature matching significantly improve the accuracy and real-time performance of the detection.

[0198] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the present invention according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0199] This application also provides a computer device. Please refer to the following for details. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0200] The computer device includes a memory 410 and a processor 420 that are interconnected via a system bus. It should be noted that only a computer device with components 410-420 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components may be implemented alternatively. Those skilled in the art will understand that the computer device described herein is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0201] Computer devices can include desktop computers, laptops, handheld computers, and cloud servers. These devices allow for human-computer interaction with users through keyboards, mice, remote controls, touchpads, or voice-activated devices.

[0202] The memory 410 includes at least one type of readable storage medium, including non-volatile memory or volatile memory, such as flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. RAM may include static RAM or dynamic RAM. In some embodiments, the memory 410 may be an internal storage unit of a computer device, such as the hard disk or RAM of the computer device. In other embodiments, memory 410 may also be an external storage device of the computer device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or FlashCard. Of course, memory 410 may include both internal and external storage units of the computer device. In this embodiment, memory 310 is typically used to store the operating system and various application software installed on the computer device, such as the program code of the methods described above. Furthermore, memory 410 may also be used to temporarily store various types of data that have been output or will be output.

[0203] Processor 420 is typically used to perform overall operations of a computer device. In this embodiment, memory 410 is used to store program code or instructions, including computer operation instructions, and processor 420 is used to execute the program code or instructions stored in memory 410 or process data, such as program code that runs the methods described above.

[0204] In this article, the bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus system can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0205] Another embodiment of this application also provides a computer-readable medium, which may be a computer-readable signal medium or a computer-readable medium. A processor in a computer reads computer-readable program code stored in the computer-readable medium, enabling the processor to execute the functional actions specified in each step or combination of steps in the above method; and to generate means for implementing the functional actions specified in each block or combination of blocks in the block diagram.

[0206] Computer-readable media include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared memory or semiconductor systems, devices or apparatuses, or any suitable combination thereof, wherein the memory is used to store program code or instructions, the program code including computer operation instructions, and the processor is used to execute the program code or instructions of the above-described methods stored in the memory.

[0207] The definitions of memory and processor can be found in the description of the foregoing computer device embodiments, and will not be repeated here.

[0208] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0209] In the various embodiments of this application, the functional units or modules can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0210] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0211] Unless otherwise expressly indicated by the context, the singular form of words used herein and in the appended claims includes the plural form, and vice versa. Thus, when referring to the singular, the plural form of the corresponding term is generally included. Similarly, the terms “comprising” and “including” shall be interpreted as including rather than exclusively. Likewise, the terms “including” and “or” shall be interpreted as including unless such interpretation is expressly prohibited herein. Where the term “example” is used herein, particularly when it follows a set of terms, the “example” is merely exemplary and illustrative and should not be considered exclusive or extensive.

[0212] Further aspects and scope of adaptation become apparent from the description provided herein. It should be understood that various aspects of this application may be implemented individually or in combination with one or more other aspects. It should also be understood that the descriptions and specific embodiments herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0213] Several embodiments of this disclosure have been described in detail above. However, it is obvious that those skilled in the art can make various modifications and variations to the embodiments of this disclosure without departing from the spirit and scope of this disclosure. The scope of protection of this disclosure is defined by the appended claims.

Claims

1. A method for testing terminal security products, characterized in that, include: Load system libraries by calling system-level interfaces; When the system library is successfully loaded, the memory address of the target function is obtained, and the validity of the memory address is verified. When the memory address is valid, read the instruction data at the memory address and parse the instruction data to determine whether it contains a jump instruction. The jump instruction includes instructions used to hijack the code execution flow. If the instruction data contains the jump instruction, then the following sub-steps are performed: parse the target address of the jump instruction and jump to the target address; reread the instruction data at the memory address and determine again whether the jump instruction is contained; if the second determination result is that the jump instruction is not contained, then the instruction data is recorded as the actual entry point code data of the target function; The actual entry point code data is converted into code data in a matching format and matched with the security feature identifier in the preset terminal security product feature library to obtain the matching result. The terminal security product feature library stores the binary signatures of various terminal security products or other security tools. Based on the matching results, the detection results of the terminal security products are output.

2. The method according to claim 1, characterized in that, The step of obtaining the instruction data at the memory address includes: The target function is used to read memory data of a predetermined length at the memory address.

3. The method according to claim 1, characterized in that, After the step of determining again whether the jump instruction is included, the method further includes: If the second determination result is that the jump instruction is included, then the target address of the jump instruction is parsed again, and the jump is performed to the target address.

4. The method as described in claim 1, characterized in that, The step of matching the security feature identifiers with those in a pre-set terminal security product feature database to obtain the matching result includes: A sliding window matching mechanism is used to compare the code data in the matchable format with the security feature identifiers in the terminal security product feature library bit by bit until a match is successful or the traversal is completed.

5. The method as described in claim 4, characterized in that, The steps involving the sliding window matching mechanism specifically include: Step a: Starting from the first address of the code data in the matching format, read a predetermined length of continuous memory data as a comparison buffer; Step b: Extract the N-byte data block of the current window from the comparison buffer and perform a binary comparison with the feature data in the preset terminal security product feature library; Step c: When the N-byte data block completely matches the feature data, it is determined that the match is successful and the comparison process is terminated. Step d: When no match is found, slide the comparison window backward by M bytes, and repeat steps b and c until the comparison buffer is exhausted or the maximum number of matches is reached. Wherein, N and M are preset positive integers, and M≤N.

6. The method according to claim 1, characterized in that, The step of outputting the detection result of the terminal security product based on the matching result includes: When a match is successful, the output detection result includes at least one of the following: the name of the detected security product, the product version identification information, and the memory address of the Hook location; When a match fails, a message indicating that no terminal security product was detected is output.

7. A detection device for terminal security products, characterized in that, include: The loading module is used to load system libraries by calling system-level interfaces; The acquisition and verification module is used to acquire the memory address of the target function and verify the validity of the memory address when the system library is successfully loaded. The parsing and detection module is used to read the instruction data at the memory address of the target function when the memory address is valid, and parse the instruction data to determine whether it contains a jump instruction. The jump instruction includes instructions used to implement code execution flow hijacking. The processing module is configured to, if the instruction data contains the jump instruction, execute the following sub-steps: parse the target address of the jump instruction and jump to the target address; reread the instruction data at the memory address and determine again whether it contains the jump instruction; if the second determination result is that it does not contain the jump instruction, record the instruction data as the actual entry point code data of the target function; The feature matching module is used to convert the actual entry point code data into code data in a matchable format, and match it with the security feature identifier in the preset terminal security product feature library to obtain the matching result. The terminal security product feature library stores the binary signatures of various terminal security products or other security tools. The result output module is used to output the detection results of the terminal security product based on the matching results.

8. A computer device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 6.

Images