Method and apparatus for detecting code injection behavior

Abstract

The embodiment of the present specification provides a detection method and device for code injection behavior. In the method, for an application program (APP) to be detected, the code of a first function associated with the APP is read from the memory of a process running the APP to obtain first code corresponding to the first function; for the APP to be detected, the code of the first function associated with the APP is read from a hard disk to obtain second code corresponding to the first function; and the first code and the second code are compared to determine whether the first code and the second code are the same. If the first code and the second code are the same, it is determined that no external code injection behavior occurs to the APP to be detected. If the first code and the second code are not the same, it is determined that the external code injection behavior occurs to the APP to be detected. The embodiment of the present specification can more effectively detect whether the external code injection behavior occurs to the APP.

Description

Technical Field

[0001] This specification relates to electronic information technology in one or more embodiments, and more particularly to methods and apparatus for detecting code injection behavior. Background Technology

[0002] With the continuous development of network technology, various applications (APPs) have emerged that can realize various business functions. For example, there are APPs that can realize facial recognition, APPs that can make online shopping, and online banking APPs. Users can realize specific business functions by using specific APPs.

[0003] Currently, various code injection techniques targeting apps have emerged. One method involves injecting aspects into the app through secure aspects. This is typically a normal server monitoring of the app's operation. However, attacks exploiting code injection have also appeared, leading to malicious consequences such as adding friends in bulk, bypassing facial recognition authentication, and cracking online banking passwords. Another type of app attack involves attackers injecting code into the targeted app, modifying its operational flow to achieve their attack goals.

[0004] Therefore, when an app is running, it is necessary to first detect whether external code injection has occurred, so as to detect attacks against the app more timely and effectively. Summary of the Invention

[0005] This specification describes one or more embodiments of a method and apparatus for detecting code injection behavior, which can more effectively detect whether external code injection behavior has occurred in an APP.

[0006] According to the first aspect, a method for detecting code injection behavior is provided, which includes:

[0007] For the application APP to be tested, the code of the first function associated with the APP is read from the memory of the process running the APP, so as to obtain the first code corresponding to the first function;

[0008] For the APP to be tested, the code of the first function associated with the APP is read from the hard drive in order to obtain the second code corresponding to the first function;

[0009] Compare the first code with the second code. If they are the same, it is determined that no external code injection has occurred for the APP to be tested. If they are different, it is determined that external code injection has occurred for the APP to be tested.

[0010] The step of reading the code of the first function associated with the APP includes: reading the code of the function preamble of the first function associated with the APP;

[0011] And / or,

[0012] The code is binary code;

[0013] And / or,

[0014] The external code injection behavior includes: injecting external code into the process running the APP using Frida-based inline hooks.

[0015] The first function includes any one or more functions included in the APP to be detected.

[0016] The first function includes: specified system library functions.

[0017] The specified system library functions include: the specified libc functions.

[0018] The specified libc functions include at least one of the following: the exit function, the _exit function, and the abort function.

[0019] The process, after determining that external code injection has occurred against the app to be detected, further includes:

[0020] This directly confirms that the external code injection behavior is an attack targeting the app being tested.

[0021] or,

[0022] The system acquires the internal runtime environment information of the terminal device formed when the APP to be detected is executed on the terminal device, so as to use the runtime environment information to detect whether the external code injection behavior is an attack behavior; wherein, the runtime environment information is: information that the terminal device does not need to use when executing the APP to be detected, but is the runtime information of the terminal device affected by the execution of the APP to be detected.

[0023] The method further includes: pre-defining a custom read function;

[0024] The step of reading the code of the first function associated with the APP from the memory of the process running the APP includes: reading the code of the first function from the memory of the process running the APP through a custom function;

[0025] The step of reading the code of the first function associated with the APP from the hard drive includes: reading the code of the first function from the hard drive through a custom function.

[0026] According to the second aspect, a device for detecting code injection behavior is provided, wherein the device includes:

[0027] The first reading module is configured to read the code of a first function associated with the application (APP) to be detected from the memory of the process running the APP, so as to obtain the first code corresponding to the first function;

[0028] The second reading module is configured to read the code of a first function associated with the APP from the hard disk for the APP to be detected, so as to obtain the second code corresponding to the first function;

[0029] The injection behavior detection module is configured to compare whether the first code and the second code are the same. If they are the same, it is determined that no external code injection behavior has occurred for the APP to be detected. If they are different, it is determined that external code injection behavior has occurred for the APP to be detected.

[0030] According to a third aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method described in any embodiment of this specification.

[0031] The combination of one or more embodiments of this specification has at least the following beneficial effects:

[0032] 1. When an app is executed, the first function associated with that app is read from the hard drive into the memory of the running app's process. If external code injection occurs, the code of the first function mapped into memory will change relative to the code of the first function on the hard drive. This specification's embodiments utilize this characteristic for detection, thereby enabling more accurate and effective detection of whether external code injection has occurred against an app under test.

[0033] 2. In the embodiments of this specification, the software feature-based detection method commonly used in the prior art is not adopted. Instead, at least one of the system library functions, such as the exit function, the _exit function, and the abort function, is used as the aforementioned first function, and detection is implemented by detecting whether the code of at least one of the exit function, the _exit function, and the abort function is changed. Since the exit function, the _exit function, and the abort function are all system library functions with universality, no matter what type or function the APP to be detected is, these system library functions can be used for detection, and the implementation method has universality. Moreover, since it is only necessary to detect whether the code of at least one of the exit function, the _exit function, and the abort function is changed, without detecting a large amount of other code such as the code of millions of functions, the implementation manner is greatly simplified.

[0034] 3. In the embodiments of this specification, a custom read function may be used to read the code of the first function, instead of the existing read function of the system library in the terminal device, thereby further preventing an attacker from perceiving the process of detecting external code injection behavior, and improving the detection security. Brief Description of the Drawings

[0035] To more clearly describe the technical solutions in the embodiments of this specification or the prior art, the drawings required in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below show some embodiments of this specification, and those of ordinary skill in the art can obtain other drawings based on these drawings without any creative effort.

[0036] Figure 1 is a flowchart of a method for detecting code injection behavior in an embodiment of this specification.

[0037] Figure 2 is a schematic structural diagram of a device for detecting code injection behavior in an embodiment of this specification.

[0038] Figure 3 is a schematic structural diagram of a device for detecting code injection behavior in another embodiment of this specification. Detailed Description of the Embodiments

[0039] First, some special terms involved in the embodiments of this specification are explained.

[0040] hook: translated as "hook", refers to the behavior of inserting code into the normal execution flow of a program.

[0041] inline hook: A type of hook implementation that mainly involves inserting jump code into the function body of the target function. When the jump code is executed, it jumps to the external code injected by the attacker and executes it. After execution, it jumps back to the original function.

[0042] Frida: A popular hook framework, it's a binary dynamic instrumentation framework. For example, with Frida, attackers can add external code they write to the normal execution flow of an app.

[0043] The solution provided in this specification will now be described with reference to the accompanying drawings.

[0044] Figure 1 This is a flowchart of a method for detecting code injection behavior in one embodiment of this specification. The execution entity of this method is a code injection behavior detection device. This device can be located in the terminal device running the app to be detected. It is understood that this method can also be executed by any device, equipment, platform, or device cluster with computing and processing capabilities. See also... Figure 1 The method includes:

[0045] Step 101: For the APP to be tested, read the code of the first function associated with the APP from the memory of the process running the APP, so as to obtain the first code corresponding to the first function.

[0046] Step 103: For the APP to be tested, read the code of the first function associated with the APP from the hard drive in order to obtain the second code corresponding to the first function.

[0047] Step 105: Compare the first code with the second code. If they are the same, proceed to step 107. If they are not the same, proceed to step 109.

[0048] Step 107: Determine that no external code injection has occurred in the APP to be tested.

[0049] Step 109: Determine that external code injection has occurred in the APP to be detected.

[0050] In existing technologies, detecting external code injection typically involves detecting common software characteristics such as port information, characteristic files, and characteristic strings. In other words, current technologies usually detect whether a specific port is being used, or whether a specific characteristic file or string is present. Because these characteristic-based detection methods are quite common, attackers can easily bypass detection by not using the specific ports and modifying the specific characteristic files or strings. Therefore, their reliability and timeliness are relatively poor.

[0051] From the above Figure 1 As can be seen from the illustrated process, the method in the embodiments of this specification adopts a completely different approach from the prior art. Analysis of the internal logic of external code injection reveals that when external code injection occurs, such as injecting external code into an app through the Frida framework's inline hook method, the code of some functions associated with that app (referred to as the first function for ease of description) will change. In other words, after the first function is read from the hard drive into the process running the app, the code in the process's memory will change relative to the code on the hard drive. The above... Figure 1 The method shown utilizes this characteristic for detection, thereby enabling more accurate and effective detection of whether external code injection has occurred in an app under test.

[0052] The following is about Figure 1 Each step shown is explained separately.

[0053] First, for step 101: For the APP to be tested, read the code of the first function associated with the APP from the memory of the process running the APP, so as to obtain the first code corresponding to the first function.

[0054] In the methods described in the embodiments of this specification, the code refers to binary code.

[0055] Typically, when external code is injected into an app under test, it affects the app by modifying the function prologue of the first function associated with the app. The function prologue is a series of instructions that run when a function starts. To influence the normal operation of the app by injecting external code, the function prologue of the first function is usually modified.

[0056] Therefore, in step 101, all the code of the first function can be read from the memory of the process running the APP. However, preferably, in step 101, only the function prologue code of the first function can be read from the memory of the process running the APP, thereby reducing the amount of code read and the workload of subsequent code comparison, and reducing the occupation of terminal device processing resources.

[0057] A common external code injection behavior includes injecting external code into the process running the app being tested using Frida-based inline hooks.

[0058] Taking the aforementioned external code injection behavior based on Frida's inline hook as an example, we can illustrate the rationality of the detection method based on function prefaces. Frida's source code can be divided into different modules: frida-node, frida-python, frida-qml, and frida-swift are responsible for implementing different language bindings of Frida. Frida's core module is implemented through frida-core, which defines various types of monitors to monitor Frida behavior, such as ExitMonitor. These monitors are implemented using the application programming interface (API) "Interceptor.attach". "Interceptor.attach" is responsible for the specific implementation of the inline hook. It inserts a trampoline (jump code) into the function preface of the first function associated with the app being tested, thus causing a change in the function preface. Therefore, we can determine whether external code injection behavior based on Frida's inline hook exists based on whether the function preface changes.

[0059] After external code injection, such as injection via Frida's inline hook, typically two types of functions will have their code modified. In this embodiment, the function whose code is modified when the app under test is run is designated as the first function associated with the app. Therefore, the first function includes the following two types:

[0060] Type 1: Functions included in the app to be tested. This means that when external code injection occurs, the code of the functions in the app to be tested will change after being read from the hard drive into the process's memory. Accordingly, in step 101, the first function involved can be any one or more functions included in the app to be tested. That is, in step 101, the code of any one or more functions included in the app to be tested (such as the code of function prologues) is read.

[0061] Type Two: System Library Functions. This means that when external code injection occurs, regardless of which app is being tested, the code of some system library functions will change after being read from the hard drive into the process's memory. Accordingly, in step 101, the first function involved can be a specified system library function. That is, in step 101, the code of the specified system library function (such as the function prologue code) is read.

[0062] In one embodiment of this specification, the specified system library functions include libc functions. libc is short for Standard Clibrary, a function library conforming to the ANSI C standard. The libc library provides macros, type definitions, string manipulation functions, mathematical calculation functions, and input / output functions used in the C language.

[0063] Analysis of external code injection behaviors such as Frida-based injection reveals that this type of injection hooks the `exit`, `_exit`, and `abort` functions and registers a monitor, "ExitMonitor," to monitor the state when these three functions are called. When these three functions are detected to be executing, Frida-based external code injection loads a piece of code into the running app's process. In other words, generally speaking, regardless of which app is subjected to external code injection, such as Frida-based inline hooking, the code of the function prologues of specified libc functions, such as the `exit`, `_exit`, and `abort` functions, will be modified. Therefore, in one embodiment of this specification, the aforementioned libc functions include at least one of the following: the `exit` function, the `_exit` function, and the `abort` function. That is, in step 101, the code (e.g., the code of the function prologue) of at least one of the `exit`, `_exit`, and `abort` functions is read.

[0064] The `abort` function is used to: immediately terminate the current process, or generate an exception to terminate the program; no objects are destroyed when the process terminates. Both the `exit` and `_exit` functions can be used to terminate a process; however, `_exit` immediately enters the kernel after being called, while `exit` performs some cleanup before entering the kernel, such as calling various termination handlers and closing all I / O streams.

[0065] Next, for step 103: For the APP to be tested, read the code of the first function associated with the APP from the hard drive in order to obtain the second code corresponding to the first function.

[0066] There is no necessary order of execution between steps 101 and 103.

[0067] The function code stored on the terminal device's hard drive is the function's original code. In step 103, the original code of the first function is read, that is, the code that has not been modified due to external code injection.

[0068] If step 101 involves reading all the code of the first function from the memory of the running app's process, then step 103 will also involve reading all the code of the first function from the hard drive. If step 101 involves reading only the function prologue code of the first function from the memory of the running app's process, then step 103 will also involve reading the function prologue code of the first function from the hard drive.

[0069] The first function in step 103 is the same as the first function in step 101. That is, either both read the code of one or more functions included in the APP to be tested, or both read the code of at least one of the specified libc functions, such as the `exit` function, the `_exit` function, and the `abort` function. The difference between step 103 and step 101 is that the source of the function code is different. In step 103, it is the original code of the first function on the hard drive, while in step 101, it is the code after the original code of the first function has been mapped to memory.

[0070] If the external code injection is an attack launched by an attacker, the attacker will typically monitor the reading of various functions through external code monitoring functions. Therefore, in steps 101 and 103, if existing system library reading functions in the terminal device are used, such as the open, read, dlopen, and dlsym functions in libc.so, once an attacker hooks these reading functions, they are likely to discover that the terminal device is reading the code of the first function, thus realizing that their external code injection, i.e., the attack, is being detected. To further prevent attackers from noticing the detection process of external code injection, in one embodiment of this specification, a custom reading function can be pre-defined, that is, the existing system library reading functions in the terminal device are not used; then, in step 101, the code of the first function is read from the memory of the process running the APP using the custom function instead of the system library reading function; in step 103, the code of the first function associated with the APP is read from the hard disk using the custom function.

[0071] Next, for steps 105, 107, and 109: compare whether the first code and the second code are the same. If they are the same, it is determined that no external code injection has occurred for the APP to be tested. If they are not the same, it is determined that external code injection has occurred for the APP to be tested.

[0072] As mentioned earlier, step 103 involves the original code of the first function on the hard drive, while step 101 involves the code after the original code of the first function is mapped into memory. Even if external code injection occurs, the code of the function on the hard drive cannot be modified; only the code mapped into memory can be modified. Therefore, if the first code (i.e., the code of the first function read from memory) is the same as the second code (i.e., the code of the first function read from the hard drive), it indicates that no external code injection has occurred. For example, no attacker has injected external code into the app under test using the inline hook method based on the Frida framework.

[0073] If at least one of the `exit`, `_exit`, and `abort` functions is used as the first function mentioned above, that is, the above is executed based on at least one of these three functions. Figure 1 The process involves various steps to achieve detection. After step 109 is completed, confirming that external code injection has occurred against the app to be detected, the following two processing methods can be included:

[0074] Solution 1: Directly determine that the external code injection behavior is an attack targeting the app under test.

[0075] Typically, modifications to the `exit`, `_exit`, and `abort` functions are attacks made by attackers against the app. Therefore, after step 109 is completed, process 1 can be executed.

[0076] Process 2: Obtain the internal runtime environment information of the terminal device formed when the APP to be tested is executed on the terminal device, so as to use the runtime environment information to detect whether the external code injection behavior is an attack behavior; wherein, the runtime environment information is: information that the terminal device does not need to use when executing the APP to be tested, but is the runtime information of the terminal device affected by the execution of the APP to be tested.

[0077] The implementation process of this process 2 includes:

[0078] The runtime environment information may include memory usage. In process 2, it is determined whether the memory usage is greater than a first predetermined value. Alternatively, when multiple memory usage values ​​are received, the increase in memory usage is calculated based on these multiple values, and it is determined whether the increase in memory usage is greater than a second predetermined value. If so, it is determined that the external code injection behavior is an attack behavior.

[0079] The runtime environment information can include the dynamic link libraries loaded by the process running the APP to be tested. In process 2, it is determined whether a dynamic link library of a specified type, such as the ffmpeg library, exists in the dynamic link libraries loaded by the process. If so, it is determined that the external code injection behavior is an attack behavior.

[0080] The runtime environment information may include the amount of data read cumulatively from the disk of the terminal device by the process running the APP to be tested. In this process 2, it is determined whether the received amount of data is greater than a third predetermined value, or, when multiple amounts of data are received, the growth rate of the data is calculated based on the multiple amounts of data, and it is determined whether the growth rate of the data is greater than a fourth predetermined value; if so, it is determined that the external code injection behavior is an attack behavior.

[0081] The runtime environment information may include the number of interrupts generated during video decoding. In this process 2, it is determined whether the number of received interrupts is greater than a fifth predetermined value, or, when multiple interrupts are received, the increase in the number of interrupts is calculated based on the multiple interrupts, and it is determined whether the increase in the number of interrupts is greater than a sixth predetermined value; if so, it is determined that the external code injection behavior is an attack behavior.

[0082] Figure 1 The detection process shown can be performed during the process of running the APP to be detected.

[0083] In one embodiment of this specification, a device for detecting code injection behavior is provided. See also Figure 2 The device includes:

[0084] The first reading module 201 is configured to read the code of a first function associated with the application APP from the memory of the process running the APP, so as to obtain the first code corresponding to the first function;

[0085] The second reading module 202 is configured to read the code of a first function associated with the APP from the hard disk for the APP to be detected, so as to obtain the second code corresponding to the first function;

[0086] The injection behavior detection module 203 is configured to compare whether the first code and the second code are the same. If they are the same, it is determined that no external code injection behavior has occurred for the APP to be detected. If they are different, it is determined that external code injection behavior has occurred for the APP to be detected.

[0087] exist Figure 2 In one embodiment of the device shown in this specification, the first reading module 201 is configured to read the code of the function preamble of the first function; the second reading module 202 is configured to read the code of the function preamble of the first function.

[0088] exist Figure 2 In one embodiment of the device shown in this specification, the code is binary code; and / or, the external code injection behavior includes: injecting the external code into the process running the APP using a Frida-based inline hook.

[0089] exist Figure 2 In one embodiment of the device shown in this specification, the first function includes: any one or more functions included in the APP to be detected.

[0090] exist Figure 2 In one embodiment of the apparatus shown in this specification, the first function includes: a specified system library function. Figure 2 In one embodiment of the device shown in this specification, the system library functions include libc functions. Figure 2 In one embodiment of the apparatus shown in this specification, the libc function includes at least one of the following: the exit function, the _exit function, and the abort function.

[0091] In one embodiment of the device described in this specification, see [link to embodiment]. Figure 3 It further includes an attack behavior detection module 301;

[0092] The attack behavior detection module 301 is configured to directly determine whether the external code injection behavior is an attack behavior against the APP to be detected; or, to obtain the internal runtime environment information of the terminal device formed when the terminal device executes the APP to be detected, so as to use the runtime environment information to detect whether the external code injection behavior is an attack behavior; wherein, the runtime environment information is: information that the terminal device does not need to use when executing the APP to be detected, but is the runtime information of the terminal device affected by the execution of the APP to be detected.

[0093] exist Figure 2 In one embodiment of the device shown in this specification,

[0094] The first reading module 201 is configured to read the code of the first function from the memory of the process running the APP through a custom function;

[0095] The second reading module 202 is configured to read the code of the first function associated with the APP from the hard drive using a custom function.

[0096] This specification provides, in one embodiment, a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the methods of any embodiment in the specification.

[0097] This specification provides a computing device according to one embodiment, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to perform the method of any embodiment of the specification.

[0098] It is understood that the structures illustrated in the embodiments of this specification do not constitute a specific limitation on the apparatus of the embodiments of this specification. In other embodiments of the specification, the above-described apparatus may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0099] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0100] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this invention can be implemented using hardware, software, widgets, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0101] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. Methods for detecting code injection behavior, among which, include: For the application APP to be tested, the code of the first function associated with the APP is read from the memory of the process running the APP, so as to obtain the first code corresponding to the first function; For the APP to be tested, the code of the first function associated with the APP is read from the hard drive in order to obtain the second code corresponding to the first function; Compare the first code and the second code to see if they are the same. If they are the same, it is determined that no external code injection has occurred for the APP to be tested. If they are not the same, it is determined that external code injection has occurred for the APP to be tested. Determine if a dynamic link library of a specified type exists in the dynamic link libraries loaded in the process of the app being tested. If so, determine that the external code injection behavior is an attack behavior. The step of reading the code associated with the first function of the APP includes: reading the code of the function prologue of the first function associated with the APP; the function prologue is the instruction that the function runs when it starts. The first function includes a specified system library function; the system library function satisfies the following: regardless of the type and function of the APP to be detected, as long as external code injection occurs, the code of the system library function will change after being read from the hard disk into the process's memory.

2. The method according to claim 1, The code is binary code; And / or, The external code injection behavior includes: Frida-based inline hooks inject external code into the process running the app.

3. The method according to claim 1, wherein, The first function includes any one or more functions included in the APP to be detected.

4. The method according to claim 1, wherein, The specified system library functions include: the specified libc functions.

5. The method according to claim 4, wherein, The specified libc functions include at least one of the following: the exit function, the _exit function, and the abort function.

6. The method according to claim 1, wherein, The method further includes: pre-defining a custom read function; The step of reading the code of the first function associated with the APP from the memory of the process running the APP includes: reading the code of the first function from the memory of the process running the APP through a custom function; The step of reading the code of the first function associated with the APP from the hard drive includes: reading the code of the first function from the hard drive through a custom function.

7. A device for detecting code injection behavior, wherein, The device includes: The first reading module is configured to read the code of a first function associated with the application (APP) to be detected from the memory of the process running the APP, so as to obtain the first code corresponding to the first function; The second reading module is configured to read the code of a first function associated with the APP from the hard disk for the APP to be detected, so as to obtain the second code corresponding to the first function; The injection behavior detection module is configured to compare whether the first code and the second code are the same. If they are the same, it is determined that no external code injection behavior has occurred for the APP to be detected. If they are different, it is determined that external code injection behavior has occurred for the APP to be detected. Specifically, it determines whether a dynamic link library of a specified type exists in the dynamic link library loaded in the process of running the APP to be tested. If so, it determines that the external code injection behavior is an attack behavior. The first reading module is configured to read the code of the function prologue of the first function; the second reading module is configured to read the code of the function prologue of the first function; the function prologue is the instruction that the function runs when it starts. The first function includes a specified system library function; the system library function satisfies the following: regardless of the type and function of the APP to be detected, as long as external code injection occurs, the code of the system library function will change after being read from the hard disk into the process's memory.

8. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-6.

Images