An application running control method and device, equipment and medium

By modifying the function addresses and instructions in the dynamic library, and combining the advantages of inline hooks and GOT hooks, efficient and stable calls to system library functions are achieved, solving the stability and complexity problems in existing technologies and ensuring the operational stability of the application.

CN115185595BActive Publication Date: 2026-03-17DOUYIN VISION CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2021-04-01
Publication Date
2026-03-17

AI Technical Summary

Technical Problem

In existing technologies, inline hooks that hijack function calls in system libraries have poor stability, while GOT hook solutions are complex and inflexible, leading to unstable application operation.

Method used

By modifying the execution address of the hijacked function and the first line of instruction in the first dynamic library to the target instruction, the execution address of the hijacked function is obtained using the function call module of the first dynamic library, and the function call module of the second dynamic library is jumped based on the target instruction, thereby achieving efficient and stable calling of the hijacked function.

Benefits of technology

It enables efficient and stable calls to system library functions, avoids multi-threaded contention issues, and ensures the stability of the application.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115185595B_ABST
    Figure CN115185595B_ABST
Patent Text Reader

Abstract

Embodiments of the present disclosure relate to a method and apparatus for controlling running of an application, and a device and a medium, wherein the method comprises: receiving an invocation instruction of a hijacked function in a second dynamic library by a first dynamic library; wherein a running address of the hijacked function in the second dynamic library is modified as a running address of a hijacked function and a first instruction of the hijacked function is modified as a target instruction; obtaining the running address of the hijacked function according to a first function calling module in the first dynamic library, and executing the hijacked function based on the running address of the hijacked function, and jumping to a second function calling module of the second dynamic library based on the target instruction in the process of executing the hijacked function; obtaining the running address of the hijacked function in the second dynamic library based on the second function calling module, and invoking the hijacked function based on the running address of the hijacked function. Embodiments of the present disclosure avoid the problem of multi-thread competition, and realize efficient and stable system function invocation.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a method, apparatus, device, and medium for controlling the operation of an application program. Background Technology

[0002] System libraries are provided by the operating system. Applications do not support modifying the code of system libraries. When the behavior of system libraries does not meet expectations, their behavior can only be changed by hijacking function calls. Among these methods, hijacking system calls is the most common.

[0003] Currently, there are two ways to hijack functions in the system library: inline hooks that modify function instructions and GOT hooks that modify the Global Offset Table (GOT). However, the stability of inline hooks is poor, while GOT hooks are complex and inflexible. Summary of the Invention

[0004] In order to solve the above-mentioned technical problems, or at least partially solve the above-mentioned technical problems, this disclosure provides a method, apparatus, device and medium for controlling the operation of an application.

[0005] This disclosure provides a method for controlling the execution of an application, the method comprising:

[0006] Receive a call instruction from a first dynamic library to a hijacked function in a second dynamic library; wherein the execution address of the hijacked function in the second dynamic library is modified to the execution address of the hijacked function and the first line of instruction of the hijacked function is modified to the target instruction;

[0007] The execution address of the hijacked function is obtained according to the first function call module in the first dynamic library, and the hijacked function is executed based on the execution address of the hijacked function. During the execution of the hijacked function, the execution jump is made to the second function call module of the second dynamic library based on the target instruction.

[0008] The second function call module obtains the running address of the hijacking function in the second dynamic library and calls the hijacking function based on the running address of the hijacking function.

[0009] This disclosure also provides an application running control device, the device comprising:

[0010] The instruction receiving module is used to receive the call instruction from the first dynamic library to the hijacked function in the second dynamic library; wherein the execution address of the hijacked function in the second dynamic library is modified to the execution address of the hijacked function and the first line instruction of the hijacked function is modified to the target instruction;

[0011] The jump module is used to obtain the execution address of the hijacked function according to the first function call module in the first dynamic library, and execute the hijacked function based on the execution address of the hijacked function. During the execution of the hijacked function, the jump module is used to jump to the second function call module of the second dynamic library based on the target instruction.

[0012] The calling module is used to obtain the running address of the hijacking function in the second dynamic library based on the second function calling module, and to call the hijacking function based on the running address of the hijacking function.

[0013] This disclosure also provides an electronic device, the electronic device comprising: a processor; a memory for storing executable instructions of the processor; the processor being configured to read the executable instructions from the memory and execute the instructions to implement the application operation control method provided in this disclosure.

[0014] This disclosure also provides a computer-readable storage medium storing a computer program for executing an application program execution control method as provided in this disclosure.

[0015] The technical solution provided in this disclosure has the following advantages compared with the prior art: The application execution control scheme provided in this disclosure receives a call instruction from a first dynamic library to a hijacked function in a second dynamic library; wherein, the execution address of the hijacked function in the second dynamic library is modified to the execution address of the hijacking function and the first line instruction of the hijacked function is modified to the target instruction; the execution address of the hijacked function is obtained according to the first function call module in the first dynamic library, and the hijacked function is executed based on the execution address of the hijacked function; during the execution of the hijacked function, the execution jump is made to the second function call module of the second dynamic library based on the target instruction; the execution address of the hijacking function in the second dynamic library is obtained based on the second function call module, and the hijacking function is called based on the execution address of the hijacking function. By adopting the above technical solution, by modifying the execution address of the hijacked function in the second dynamic library to the execution address of the hijacked function and modifying the first line of instructions of the hijacked function, the first dynamic library can call the hijacked function in the second dynamic library. Since the modification of the hijacked function in the second dynamic library can guarantee atomicity, the problem of multi-threaded competition is avoided, and efficient and stable system function calls are achieved, thereby ensuring the running stability of the application. Attached Figure Description

[0016] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0017] Figure 1 A schematic diagram illustrating an instruction modification provided in an embodiment of this disclosure;

[0018] Figure 2 A schematic diagram illustrating another instruction modification provided in an embodiment of this disclosure;

[0019] Figure 3 A schematic diagram illustrating an instruction error provided in an embodiment of this disclosure;

[0020] Figure 4 A flowchart illustrating an application operation control method provided in this embodiment of the present disclosure;

[0021] Figure 5 A schematic diagram illustrating a dynamic dependency invocation provided in an embodiment of this disclosure;

[0022] Figure 6 A flowchart illustrating another application operation control method provided in this embodiment of the disclosure;

[0023] Figure 7 A schematic diagram illustrating the operation control of an application provided in an embodiment of this disclosure;

[0024] Figure 8 A schematic diagram illustrating the operation control of another application provided in an embodiment of this disclosure;

[0025] Figure 9 A schematic diagram of the structure of an application operation control device provided in an embodiment of this disclosure;

[0026] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0027] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0028] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0029] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0030] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0031] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0032] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0033] System libraries are provided by the operating system. Applications do not support modifying the code of system libraries. When the behavior of system libraries does not meet expectations, their behavior can only be changed by hijacking function calls. Among these methods, hijacking system calls is the most common.

[0034] Currently, there are two main methods for hijacking functions in the system library: inline hooks that modify function instructions and GOT hooks that modify the global jump table. The principle behind inline hooks is to modify the instructions at the target function's entry point, causing it to jump to a user-defined function. The principle is as follows: Figure 1 As shown, Figure 1 This is a schematic diagram of an instruction modification provided in an embodiment of this disclosure. It uses a jump instruction and a target address data to replace the original instruction in the hijacked function. After the replacement, as shown... Figure 2 As shown, Figure 2This diagram illustrates another instruction modification provided in an embodiment of this disclosure, where original instructions 2 and 3 are replaced with a jump instruction and a target address. The jump instruction is generally as follows: "LDR PC, _target_address; .target_address_", where the first instruction fetches an address from the position of the next instruction and assigns it to the program register. Because the target address is random and can be any number within the address space, it generally occupies one address width (32 bits, or 4 bytes, on a 32-bit machine). The jump instruction itself also occupies one address width. Therefore, instruction modification requires at least two address widths. Because two address widths need to be modified, the hijacking process cannot guarantee atomicity. Under high concurrency, it is possible that another thread enters the hijacked function during the hijacking process, leading to runtime errors, such as... Figure 3 As shown, Figure 3 This diagram illustrates an instruction error provided by an embodiment of the present disclosure, where another thread enters before the target address has been modified, causing a hijacking error. Therefore, inline hooks are generally less stable and rarely used in online environments.

[0035] The principle of the aforementioned GOT hook is to replace the function address in the GOT table with a custom function, thereby hijacking the original function. This approach only requires modifying one address, ensuring atomicity and avoiding multi-threaded contention issues. However, its drawback is that for each dynamic library of the process to be hijacked, all dynamic libraries that depend on the current function must be modified. Furthermore, when a new dynamic library is loaded, a hijacking process must be triggered again, requiring the implementation of dynamic library loading behavior. Therefore, this approach is complex and lacks flexibility. To address these issues, this disclosure provides an application execution control method, which will be described below with reference to specific embodiments.

[0036] Figure 4 This is a flowchart illustrating an application execution control method provided in an embodiment of the present disclosure. This method can be executed by an application execution control device, which can be implemented in software and / or hardware, and is generally integrated into an electronic device. Figure 4 As shown, the method includes:

[0037] Step 101: Receive the call instruction from the first dynamic library to the hijacked function in the second dynamic library; wherein, the execution address of the hijacked function in the second dynamic library is modified to the execution address of the hijacked function and the first line of instruction of the hijacked function is modified to the target instruction.

[0038] In this context, "dynamic library" refers to a Dynamic Link Library (DLL). Dynamic linking is a technique for resolving dynamic dependencies between code libraries. Dynamic dependencies are runtime dependencies, i.e., non-compile-time dependencies. The first dynamic library and the second dynamic library refer to two different code libraries. The hijacked function is a function in the system library. The hijacked function can be a function whose runtime behavior does not meet requirements and needs to be hijacked. The hijacked function is the actual function that needs to be called, and it can be a user-defined function. The hijacked function can be any function in the system library; for example, it could be a function with vulnerabilities or a function requiring monitoring, etc., with no specific limitations.

[0039] Invocation instructions are instructions used to call functions in system libraries. Calls to functions in system libraries can be implemented through system interfaces. The system call interface is a collection of all system call interfaces provided by the operating system; it is also known as the application programming interface (API). These interfaces serve as the interface between applications and the operating system. System call interfaces are generally encapsulated in system base libraries, such as libc.so in Android. Other user-space system libraries and application dynamic libraries typically do not directly call system libraries, but instead call interfaces encapsulated in libc.so, such as open, read, and mmap.

[0040] In this embodiment of the disclosure, when the first dynamic library calls the hijacked function in the second dynamic library, the application's execution control device can receive the call instruction from the first dynamic library to the hijacked function in the second dynamic library. Furthermore, before the call is executed, the hijacked function has been modified by the hijacking call; that is, the execution address of the hijacked function in the second dynamic library has been modified to the execution address of the hijacking function, and the first line of instruction of the hijacked function has been modified to a target instruction. The target instruction is used to indicate a jump from the first dynamic library to the second dynamic library, preparing for subsequent calls.

[0041] The modification to the hijacked function described above, since the target instruction is used to implement intra-file jumps, can be completed with a single instruction, ensuring its atomicity. Atomicity means an indivisible operation that is not interrupted by any other task or event after execution. In this solution, since interruption occurs between instructions, atomicity refers to an operation that can be completed in a single instruction. In this solution, because the execution address of the hijacked function is stored in the global jump table in the second dynamic library, only a single jump instruction that can jump to the global jump table is needed to hijack the function. Furthermore, only one modification is needed to hijack all calls to the hijacked function, thus ensuring atomicity. Under high concurrency, this prevents runtime errors caused by another thread entering the hijacked function, improving stability and ensuring that multi-threaded contention issues are avoided.

[0042] Step 102: Obtain the execution address of the hijacked function based on the first function call module in the first dynamic library, and execute the hijacked function based on the execution address of the hijacked function. During the execution of the hijacked function, jump to the second function call module of the second dynamic library based on the target instruction.

[0043] The function call module refers to the functional module in a dynamic library used for calling different functions. The function call module can include a procedure linking table and a global jump table. The global jump table stores the execution addresses of multiple functions, while the procedure linking table stores the value-fetching jump instructions corresponding to each function in the global jump table. Each entry in the Global Offset Table (GOT) corresponds to one or more external functions that the current dynamic library depends on, storing the execution addresses of these external functions. The Procedure Linking Table (PLT) is a block table, and each entry also corresponds to one or more external functions that the current dynamic library depends on, storing the value-fetching jump instructions for each function. These instructions are used to retrieve the execution address of the dependent external function from the corresponding entry in the global jump table and then complete the jump.

[0044] Both the first dynamic library and the second dynamic library include function call modules, that is, both include global jump tables and procedure link tables. They are distinguished by being first and second. The first dynamic library includes a first function call module, and the second dynamic library includes a second function call module. The first function call module includes a second procedure link table and a second global jump table, and the second function call module includes a first procedure link table and a first global jump table.

[0045] In this embodiment of the disclosure, obtaining the execution address of the hijacked function from the first function call module in the first dynamic library and executing the hijacked function based on the execution address of the hijacked function may include: determining the second value jump instruction corresponding to the hijacked function in the second process link table of the first function call module; obtaining the execution address of the hijacked function from the second global jump table of the first function call module based on the second value jump instruction, and jumping to the execution address of the hijacked function to execute the hijacked function.

[0046] When the application's execution control device implements the first dynamic library call to the hijacked function, it can first determine the second value jump instruction corresponding to the hijacked function in the second process link table of the local first function call module. By executing the second value jump instruction, it can obtain the execution address of the hijacked function from the local second global jump table and execute the hijacked function based on the execution address.

[0047] For example, Figure 5 This is a schematic diagram of a dynamic dependency call provided in an embodiment of the present disclosure, such as... Figure 5 As shown, assuming A is the first dynamic library and B is the second dynamic library, A depends on function F of B. The specific calling process can include: 1. The code of A calling function F will be compiled into a jump code, which jumps to the code block of the value-fetching jump instruction corresponding to function F in the PLT table of A; 2. This code block will obtain the running address of function F from the GOT table in A; 3. Then the jump is completed.

[0048] The execution address of function F is obtained by the linker when A is loaded into the process at runtime, by searching for the dynamic library of B. Then, the execution address of function F is filled into the corresponding entry for F in A's GOT table. Thus, even if the address of F cannot be determined at compile time, A can still call function F through runtime linking behavior.

[0049] The aforementioned target instruction is used to instruct a first value-fetching jump instruction from the first dynamic library to the second function call module in the second dynamic library, wherein the first value-fetching jump instruction includes the value-fetching jump instruction corresponding to the hijacked function in the first process link table of the second function call module.

[0050] In this embodiment of the disclosure, when the hijacked function is executed, since the first line of instructions in the hijacked function is modified to the target instruction, the execution of the hijacked function can jump to the first value retrieval jump instruction of the second function call module of the second dynamic library. The first value retrieval jump instruction is the value retrieval jump instruction corresponding to the hijacked function.

[0051] Step 103: Obtain the running address of the hijacking function in the second dynamic library based on the second function call module, and call the hijacking function based on the running address of the hijacking function.

[0052] In this embodiment of the disclosure, obtaining the running address of the hijacking function in the second dynamic library based on the second function call module, and calling the hijacking function based on the running address of the hijacking function, may include: obtaining the running address of the hijacking function from the first global jump table in the second function call module based on the first value jump instruction, and jumping to the running address of the hijacking function to execute the hijacking function.

[0053] After the execution of the hijacked function jumps to the first value-fetching jump instruction of the second dynamic library, the execution address of the hijacked function can be obtained from the first global jump table by executing the first value-fetching jump instruction, and the hijacked function can be executed based on the execution address of the hijacked function to realize the call of the hijacked function.

[0054] In conventional inline hook hijacking schemes, two lines of instructions are needed for modification because a direct jump to the execution address of the hijacked function is required. The execution address of the hijacked function requires a full address width, hence at least two address widths. However, in this scheme, since the execution address of the hijacked function is stored in the first global jump table, only one jump instruction is needed to jump to the first global jump table to complete the hijacking of the function. Furthermore, only one modification is needed to hijack all calls to the hijacked function, ensuring atomicity and preventing multi-threaded contention issues.

[0055] The application execution control scheme provided in this disclosure receives a call instruction from a first dynamic library to a hijacked function in a second dynamic library. The execution address of the hijacked function in the second dynamic library is modified to the execution address of the hijacking function, and the first line instruction of the hijacked function is modified to the target instruction. The execution address of the hijacked function is obtained from the first function call module in the first dynamic library, and the hijacked function is executed based on this address. During the execution of the hijacked function, the system jumps to the second function call module of the second dynamic library based on the target instruction. The execution address of the hijacking function in the second dynamic library is obtained from the second function call module, and the hijacking function is called based on this address. By modifying the execution address of the hijacked function in the second dynamic library to the execution address of the hijacking function and modifying the first line instruction of the hijacked function, the first dynamic library can call the hijacking function in the second dynamic library. Since the modification of the hijacked function in the second dynamic library ensures atomicity, it avoids multi-threaded contention, achieves efficient and stable system function calls, and thus ensures the operational stability of the application.

[0056] In some embodiments, the application execution control method may further include: receiving a call instruction from a second dynamic library to a local hijacked function, jumping to a second function call module, and calling the hijacked function based on the second function call module.

[0057] When the second dynamic library calls the hijacked functions it includes, the application's execution control device can, based on the third value jump instruction in the call instruction that jumps to the hijacked function in the first process link table of the second dynamic library, execute the third value jump instruction to obtain the execution address of the hijacked function from the first global jump table. Since the execution address of the hijacked function has been modified to the execution address of the hijacking function, what is actually obtained is the execution address of the hijacking function, and the hijacking function is executed based on the execution address of the hijacking function.

[0058] In the above scheme, in addition to enabling external dynamic libraries to call hijacked functions in the current dynamic library, the current dynamic library can also call local hijacked functions. Based on the above atomic modifications, the stability of system calls can be guaranteed, thereby ensuring the stability of application operation control.

[0059] Figure 6 This is a flowchart illustrating another application operation control method provided in this embodiment of the present disclosure. Based on the above embodiments, this embodiment further details the application operation control method. Figure 6 As shown, the method includes:

[0060] Step 201: Modify the execution address of the hijacked function in the second dynamic library to the execution address of the hijacked function, and modify the first line instruction of the hijacked function to the target instruction.

[0061] The hijacked function is a function in the system library.

[0062] After step 201, steps 202-204 and / or step 205 can be performed.

[0063] Step 202: Receive the call instruction from the first dynamic library to the hijacked function in the second dynamic library.

[0064] Step 203: Obtain the execution address of the hijacked function according to the first function call module in the first dynamic library, and execute the hijacked function based on the execution address of the hijacked function. During the execution of the hijacked function, jump to the second function call module of the second dynamic library based on the target instruction.

[0065] The function call module includes a procedure linking table and a global jump table. The global jump table stores the execution addresses of multiple functions, and the procedure linking table stores the value-fetching jump instructions corresponding to each function in the global jump table. Optionally, the target instruction is used to indicate the first value-fetching jump instruction from the first dynamic library to the second function call module in the second dynamic library. The first value-fetching jump instruction includes the value-fetching jump instruction corresponding to the hijacked function in the first procedure linking table of the second function call module.

[0066] In this embodiment of the disclosure, obtaining the execution address of the hijacked function from the first function call module in the first dynamic library and executing the hijacked function based on the execution address of the hijacked function may include: determining the second value jump instruction corresponding to the hijacked function in the second process link table of the first function call module; obtaining the execution address of the hijacked function from the second global jump table of the first function call module based on the second value jump instruction, and jumping to the execution address of the hijacked function to execute the hijacked function.

[0067] Step 204: Obtain the running address of the hijacking function in the second dynamic library based on the second function call module, and call the hijacking function based on the running address of the hijacking function.

[0068] In this embodiment of the disclosure, obtaining the running address of the hijacking function in the second dynamic library based on the second function call module, and calling the hijacking function based on the running address of the hijacking function, includes: obtaining the running address of the hijacking function from the first global jump table in the second function call module based on the first value jump instruction, and jumping to the running address of the hijacking function to execute the hijacking function.

[0069] Step 205: Receive the call instruction from the second dynamic library to the hijacked function on the local machine, jump to the second function call module, and call the hijacked function based on the second function call module.

[0070] The following specific example will further illustrate the application operation control method provided in this disclosure. Figure 7 This is a schematic diagram illustrating the operation control of an application provided in an embodiment of the present disclosure. Figure 7 This demonstrates the operational controls of the application before any improvements were made. Figure 7 The dashed arrows indicate jumps, solid straight arrows indicate reads, and curved arrows indicate flow pointers. Taking the `open` function in the Android system as an example, its implementation is in the current dynamic library `libc.so`. When the external dynamic library `libbinder.so` calls the `open` function, it needs to complete the jump through its own PLT and GOT tables. `libc.so` also calls the `open` function, which also completes the function call through the PLT and GOT tables corresponding to the `open` function in `libc.so`. See [link to documentation] for specific calling methods. Figure 5 This will not be elaborated upon here.

[0071] Figure 8 This is a schematic diagram illustrating the operation control of another application provided in an embodiment of this disclosure. Figure 8 This demonstrates the improved application execution control in this solution. Figure 8In this diagram, dashed arrows indicate jumps, solid straight arrows indicate reads, and curved arrows indicate the flow path. In this solution, the GOT table corresponding to the `open` function in `libc.so` can be modified first, changing the previously stored execution address of the `open` function to the execution address of the custom function `my_open`, such as... Figure 8 As shown, calls to the `open` function in `libc.so` will all jump to the `my_open` function. Then, the first line of the `open` function is modified to jump to the PLT table corresponding to the `open` function. Because this is a relative jump within the file, it can be accomplished with a single instruction, ensuring its atomicity. For example... Figure 8 As shown, the call to the open function in libbinder.so can jump to the PLT table corresponding to open in libc.so, and then jump to the my_open function.

[0072] This solution requires only a single modification to the runtime address and instructions to hijack all calls to the hijacked function. The modification is atomic, ensuring no multi-threaded contention issues arise. This solution combines the advantages of inline hooks and GOT hooks, achieving efficient and stable call hijacking.

[0073] The application execution control scheme provided in this embodiment modifies the execution address of the hijacked function in the second dynamic library to the execution address of the hijacking function, and modifies the first line instruction of the hijacked function to the target instruction; receives the call instruction from the first dynamic library to the hijacked function in the second dynamic library, obtains the execution address of the hijacked function according to the first function call module in the first dynamic library, and executes the hijacked function based on the execution address of the hijacked function. During the execution of the hijacked function, it jumps to the second function call module of the second dynamic library based on the target instruction, obtains the execution address of the hijacking function in the second dynamic library based on the second function call module, and calls the hijacking function based on the execution address of the hijacking function; receives the call instruction from the second dynamic library to the local hijacked function, jumps to the second function call module, and calls the hijacking function based on the second function call module. By adopting the above technical solution, by modifying the execution address of the hijacked function in the second dynamic library to the execution address of the hijacked function and modifying the first line of instructions of the hijacked function, the first dynamic library and the second dynamic library can realize the call of the hijacked function in the second dynamic library. Since the modification of the hijacked function in the second dynamic library can guarantee atomicity, the problem of multi-threaded competition is avoided, and efficient and stable system function calls are realized, thereby ensuring the running stability of the application.

[0074] Figure 9 This is a schematic diagram of the structure of an application operation control device provided in an embodiment of the present disclosure. This device can be implemented by software and / or hardware, and is generally integrated into an electronic device. Figure 9As shown, the device includes:

[0075] The instruction receiving module 301 is used to receive the call instruction from the first dynamic library to the hijacked function in the second dynamic library; wherein the execution address of the hijacked function in the second dynamic library is modified to the execution address of the hijacked function and the first line instruction of the hijacked function is modified to the target instruction;

[0076] The jump module 302 is used to obtain the execution address of the hijacked function according to the first function call module in the first dynamic library, and execute the hijacked function based on the execution address of the hijacked function. During the execution of the hijacked function, the jump module 302 is used to jump to the second function call module of the second dynamic library based on the target instruction.

[0077] The calling module 303 is used to obtain the running address of the hijacking function in the second dynamic library based on the second function calling module, and to call the hijacking function based on the running address of the hijacking function.

[0078] Optionally, the function call module includes a process link table and a global jump table. The global jump table is used to store the execution addresses of multiple functions, and the process link table is used to store the value retrieval jump instructions corresponding to each function in the global jump table.

[0079] Optionally, the target instruction is used to indicate a first value-fetching jump instruction from the first dynamic library to the second function call module in the second dynamic library, wherein the first value-fetching jump instruction includes the value-fetching jump instruction corresponding to the hijacked function in the first process link table of the second function call module.

[0080] Optionally, the calling module 303 is specifically used for:

[0081] Based on the first value jump instruction, the execution address of the hijacking function is obtained from the first global jump table in the second function call module, and the execution address of the hijacking function is jumped to the execution address of the hijacking function to execute the hijacking function.

[0082] Optionally, the jump module 302 is specifically used for:

[0083] Determine the second value jump instruction corresponding to the hijacked function in the second process link table of the first function call module;

[0084] Based on the second value jump instruction, the execution address of the hijacked function is obtained from the second global jump table of the first function call module, and the execution address of the hijacked function is jumped to the execution address of the hijacked function to execute the hijacked function.

[0085] Optionally, the device further includes a local invocation module for:

[0086] The system receives the instruction from the second dynamic library to call the hijacked function locally, jumps to the second function call module, and calls the hijacked function based on the second function call module.

[0087] Optionally, the hijacked function is a function in the system library.

[0088] The application running control device provided in this disclosure can execute the application running control method provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects of the execution method.

[0089] This disclosure also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the application program execution control method provided in any embodiment of this disclosure.

[0090] Figure 10 This is a schematic diagram of an electronic device provided in an embodiment of the present disclosure. See below for details. Figure 10 The diagram illustrates a structural schematic suitable for implementing the electronic device 400 in the embodiments of this disclosure. The electronic device 400 in the embodiments of this disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 10 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0091] like Figure 10 As shown, electronic device 400 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 401, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 402 or a program loaded from storage device 408 into random access memory (RAM) 403. RAM 403 also stores various programs and data required for the operation of electronic device 400. Processing device 401, ROM 402, and RAM 403 are interconnected via bus 404. Input / output (I / O) interface 405 is also connected to bus 404.

[0092] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 408 including, for example, magnetic tapes, hard disks, etc.; and communication devices 409. Communication device 409 allows electronic device 400 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 10 An electronic device 400 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0093] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 409, or installed from storage device 408, or installed from ROM 402. When the computer program is executed by processing device 401, it performs the functions defined in the application operation control method of embodiments of this disclosure.

[0094] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0095] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0096] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0097] The aforementioned computer-readable medium carries one or more programs. When the electronic device executes the aforementioned one or more programs, the electronic device causes the following: it receives a call instruction from a first dynamic library to a hijacked function in a second dynamic library; wherein the execution address of the hijacked function in the second dynamic library is modified to the execution address of the hijacking function and the first line instruction of the hijacked function is modified to a target instruction; it obtains the execution address of the hijacked function according to a first function call module in the first dynamic library, and executes the hijacked function based on the execution address of the hijacked function; during the execution of the hijacked function, it jumps to a second function call module of the second dynamic library based on the target instruction; it obtains the execution address of the hijacking function in the second dynamic library based on the second function call module, and calls the hijacking function based on the execution address of the hijacking function.

[0098] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0099] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0100] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0101] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0102] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0103] According to one or more embodiments of this disclosure, this disclosure provides a method for controlling the execution of an application, including:

[0104] Receive a call instruction from a first dynamic library to a hijacked function in a second dynamic library; wherein the execution address of the hijacked function in the second dynamic library is modified to the execution address of the hijacked function and the first line of instruction of the hijacked function is modified to the target instruction;

[0105] The execution address of the hijacked function is obtained according to the first function call module in the first dynamic library, and the hijacked function is executed based on the execution address of the hijacked function. During the execution of the hijacked function, the execution jump is made to the second function call module of the second dynamic library based on the target instruction.

[0106] The second function call module obtains the running address of the hijacking function in the second dynamic library and calls the hijacking function based on the running address of the hijacking function.

[0107] According to one or more embodiments of this disclosure, in the application execution control method provided by this disclosure, the function call module includes a process link table and a global jump table. The global jump table is used to store the execution addresses of multiple functions, and the process link table is used to store the value retrieval jump instructions corresponding to each function in the global jump table.

[0108] According to one or more embodiments of this disclosure, in the application execution control method provided by this disclosure, the target instruction is used to indicate a first value retrieval jump instruction from the first dynamic library to the second function call module in the second dynamic library, wherein the first value retrieval jump instruction includes the value retrieval jump instruction corresponding to the hijacking function in the first process link table of the second function call module.

[0109] According to one or more embodiments of this disclosure, in the application execution control method provided by this disclosure, obtaining the execution address of the hijacking function in the second dynamic library based on the second function call module, and calling the hijacking function based on the execution address of the hijacking function, includes:

[0110] Based on the first value jump instruction, the execution address of the hijacking function is obtained from the first global jump table in the second function call module, and the execution address of the hijacking function is jumped to the execution address of the hijacking function to execute the hijacking function.

[0111] According to one or more embodiments of this disclosure, the application execution control method provided by this disclosure includes obtaining the execution address of the hijacked function based on the first function call module in the first dynamic library, and executing the hijacked function based on the execution address of the hijacked function, comprising:

[0112] Determine the second value jump instruction corresponding to the hijacked function in the second process link table of the first function call module;

[0113] Based on the second value jump instruction, the execution address of the hijacked function is obtained from the second global jump table of the first function call module, and the execution address of the hijacked function is jumped to the execution address of the hijacked function to execute the hijacked function.

[0114] According to one or more embodiments of this disclosure, the application execution control method provided in this disclosure further includes:

[0115] The system receives the instruction from the second dynamic library to call the hijacked function locally, jumps to the second function call module, and calls the hijacked function based on the second function call module.

[0116] According to one or more embodiments of this disclosure, in the application execution control method provided by this disclosure, the hijacked function is a function in the system library.

[0117] According to one or more embodiments of this disclosure, this disclosure provides an application operation control device, including:

[0118] The instruction receiving module is used to receive the call instruction from the first dynamic library to the hijacked function in the second dynamic library; wherein the execution address of the hijacked function in the second dynamic library is modified to the execution address of the hijacked function and the first line instruction of the hijacked function is modified to the target instruction;

[0119] The jump module is used to obtain the execution address of the hijacked function according to the first function call module in the first dynamic library, and execute the hijacked function based on the execution address of the hijacked function. During the execution of the hijacked function, the jump module is used to jump to the second function call module of the second dynamic library based on the target instruction.

[0120] The calling module is used to obtain the running address of the hijacking function in the second dynamic library based on the second function calling module, and to call the hijacking function based on the running address of the hijacking function.

[0121] According to one or more embodiments of this disclosure, in the application execution control device provided by this disclosure, the function call module includes a process link table and a global jump table. The global jump table is used to store the execution addresses of multiple functions, and the process link table is used to store the value retrieval jump instructions corresponding to each function in the global jump table.

[0122] According to one or more embodiments of this disclosure, in the application execution control device provided by this disclosure, the target instruction is used to indicate a first value retrieval jump instruction from the first dynamic library to the second function call module in the second dynamic library, wherein the first value retrieval jump instruction includes the value retrieval jump instruction corresponding to the hijacking function in the first process link table of the second function call module.

[0123] According to one or more embodiments of this disclosure, in the application execution control device provided by this disclosure, the calling module is specifically used for:

[0124] Based on the first value jump instruction, the execution address of the hijacking function is obtained from the first global jump table in the second function call module, and the execution address of the hijacking function is jumped to the execution address of the hijacking function to execute the hijacking function.

[0125] According to one or more embodiments of this disclosure, in the application execution control device provided by this disclosure, the jump module is specifically used for:

[0126] Determine the second value jump instruction corresponding to the hijacked function in the second process link table of the first function call module;

[0127] Based on the second value jump instruction, the execution address of the hijacked function is obtained from the second global jump table of the first function call module, and the execution address of the hijacked function is jumped to the execution address of the hijacked function to execute the hijacked function.

[0128] According to one or more embodiments of this disclosure, in the application execution control device provided by this disclosure, the device further includes a local invocation module, used for:

[0129] The system receives the instruction from the second dynamic library to call the hijacked function locally, jumps to the second function call module, and calls the hijacked function based on the second function call module.

[0130] According to one or more embodiments of this disclosure, in the application execution control device provided by this disclosure, the hijacked function is a function in the system library.

[0131] According to one or more embodiments of this disclosure, this disclosure provides an electronic device, including:

[0132] processor;

[0133] Memory used to store the processor's executable instructions;

[0134] The processor is configured to read the executable instructions from the memory and execute the instructions to implement the operation control method of the application as provided in any of the present disclosure.

[0135] According to one or more embodiments of the present disclosure, the present disclosure provides a computer-readable storage medium storing a computer program for executing an application program as described in any of the present disclosure.

[0136] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0137] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0138] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A method of controlling execution of an application program, characterized by, The method comprises the following steps: receiving a calling instruction of a hijacked function in a second dynamic library by a first dynamic library, wherein a running address of the hijacked function in the second dynamic library is modified as a running address of a hijacked function, and a first instruction of the hijacked function is modified as a target instruction, and the hijacked function is a function in a system library; obtaining the running address of the hijacked function according to a first function calling module in the first dynamic library, and executing the hijacked function based on the running address of the hijacked function, and jumping to a second function calling module of the second dynamic library based on the target instruction during the execution of the hijacked function; obtaining the running address of the hijacked function in the second dynamic library based on the second function calling module, and calling the hijacked function based on the running address of the hijacked function.

2. The method of claim 1, wherein, The function calling module comprises a procedure link table and a global jump table, and the global jump table is used for storing running addresses of multiple functions, and the procedure link table is used for storing value jump instructions corresponding to each function in the global jump table.

3. The method of claim 2, wherein the target instruction is a first value jump instruction for indicating a jump from the first dynamic library to the second function calling module in the second dynamic library, and the first value jump instruction comprises a value jump instruction corresponding to the hijacked function in a first procedure link table of the second function calling module. The method of obtaining the running address of the hijacked function in the second dynamic library based on the second function calling module, and calling the hijacked function based on the running address of the hijacked function comprises:

4. The method of claim 3, wherein, obtaining the running address of the hijacked function from a first global jump table in the second function calling module based on the first value jump instruction, and jumping to the running address of the hijacked function to execute the hijacked function. The method of obtaining the running address of the hijacked function according to the first function calling module in the first dynamic library, and executing the hijacked function based on the running address of the hijacked function comprises:

5. The method of claim 1, wherein, determining a second value jump instruction corresponding to the hijacked function in a second procedure link table of the first function calling module; obtaining the running address of the hijacked function from a second global jump table of the first function calling module based on the second value jump instruction, and jumping to the running address of the hijacked function to execute the hijacked function. The method further comprises the following steps:

6. The method of claim 1, wherein, receiving a calling instruction of the hijacked function in the second dynamic library by the second dynamic library, jumping to the second function calling module, and calling the hijacked function based on the second function calling module. The method comprises the following steps:

7. An application program execution control device characterized by comprising: an instruction receiving module is configured to receive a calling instruction of a hijacked function in a second dynamic library by a first dynamic library, wherein a running address of the hijacked function in the second dynamic library is modified as a running address of a hijacked function, and a first instruction of the hijacked function is modified as a target instruction, and the hijacked function is a function in a system library; ​ The jump module is configured to obtain a running address of the hijacked function according to a first function call module in a first dynamic library, and execute the hijacked function based on the running address of the hijacked function, and jump to a second function call module of the second dynamic library based on the target instruction during the execution of the hijacked function; The call module is configured to obtain a running address of the hijacked function in the second dynamic library based on the second function call module, and call the hijacked function based on the running address of the hijacked function.

8. An electronic device, comprising: The electronic device comprises: a processor; a memory for storing executable instructions of the processor; the processor is configured to read the executable instructions from the memory and execute the instructions to implement the method for controlling the running of the application program according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, and the computer program is configured to execute the method for controlling the running of the application program according to any one of claims 1-6.

Citation Information

Patent Citations

  • Application running method and file reinforcing method and device

    CN106295371A

  • Method and device for running second system application in first system, equipment and medium

    CN111984263A