Dynamic library hijacking method, electronic equipment and computer program product

Abstract

The invention provides a dynamic library hijacking method, electronic equipment and a computer program product, which realize real-time replacement and function extension of a dynamic library through dynamic library renaming, memory residence and loading sequence control without modifying an APK or restarting an application. According to the embodiment, no file remains in the hijacking process, only code segments ( / proc / sef / map is displayed as liba.so) are reserved in a memory, and detection based on file hash or path is avoided. And moreover, the JNIOnLoad of the original library and all the JNI methods are normally executed, so that the collapse problems of UnsfidLink Error and the like are avoided.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to a dynamic library hijacking method, electronic device, and computer program product. Background Art

[0002] In Android application development, native dynamic libraries (.so) are widely used to implement core functions such as high-performance computing and hardware interaction. Traditional technologies statically package dynamic libraries into APKs, leading to problems such as bloated application size and a lack of hot update capabilities. While existing dynamic loading solutions can achieve on-demand loading through System.loadLibrary, they still face three major technical bottlenecks: First, conventional hooking technologies (such as the Xposed framework or GOT Hook) rely on system-level modifications or fixed symbol interception, resulting in poor Android version compatibility and an inability to capture inline function calls. Second, dynamically loaded external libraries must be explicitly stored in the file system, making their path information and memory mapping traces susceptible to detection by security tools (such as Anti-VM and behavioral sandboxes). Third, if the JNI method registration logic is not fully taken over during dynamic replacement, it can easily lead to crash risks such as UnsatisfiedLinkError. Therefore, existing technologies cannot achieve covert hijacking and seamless replacement of dynamic libraries without modifying the APK, nor can they guarantee the integrity of the JNI call chain and the ability to resist security detection. Summary of the Invention

[0003] The purpose of the embodiments of the present application is to provide a dynamic library hijacking method, electronic device and computer program product, which are used to achieve hidden hijacking and seamless replacement of dynamic libraries without modifying the APK, while ensuring the integrity of the JNI call chain and the ability to resist security detection.

[0004] The embodiment of the present application provides a dynamic library hijacking method, comprising:

[0005] Locate the original library in the private directory of the target application and rename the original library's first name to a temporary name;

[0006] Rename the second name of the hijacked library to the first name;

[0007] Load the hijacking library named first;

[0008] After loading the hijacked library into memory, delete the hijacked library file, rename the temporary name of the original library to the first name, and use dlopen to load the original library with the first name;

[0009] Continue to execute the method in the original library.

[0010] In the above technical solution, the original library and the hijacked library are dynamic libraries. By renaming the dynamic library, controlling memory residency and loading order, real-time replacement and function expansion of the dynamic library are achieved without modifying the APK or restarting the application. The hijacking process of this embodiment leaves no file residue, and only the code segment is retained in the memory ( / proc / self / maps shows liba.so(deleted)), avoiding detection based on file hash or path. In addition, the JNI_OnLoad and all JNI methods of the original library are executed normally, avoiding crashes such as UnsatisfiedLinkError.

[0011] Specifically, locate the target application private directory (such as / data / app / <package> / lib / arm64). Rename the original library liba.so to a temporary name (such as libcc.so). Android app private directories have read and write permissions isolated. Hijacking requires modifying files after the app is installed by escalating privileges or injecting code. In this step, renaming the original library avoids subsequent loading conflicts and preserves its complete functional logic.

[0012] Rename the hijacked library libb.so to liba.so, replacing the original library location. Android dynamic library loading priority: application private directory > system directory. The hijacked library is disguised as the original library name, ensuring that System.loadLibrary("a") prioritizes loading the hijacked library. The hijacked library must export the same global symbols as the original library (using the --export-dynamic compilation option) to prevent symbol resolution failures.

[0013] The application calls System.loadLibrary("a") to load the hijacked library (the disguised liba.so). The underlying dlopen process: parses the ELF file header, maps the code (.text) and data (.data) segments into memory; executes the initialization function in the init_array segment; and calls JNI_OnLoad (if present). A background thread is started in the hijacked library's init_array to perform cleanup operations.

[0014] Call unlink(" / path / to / liba.so") in the hijacked library's init_array or in a separate thread to delete the hijacked library's own file. After the file is deleted, the hijacked library is marked as "deleted" in / proc / self / maps, but the code segment remains in memory, allowing the hijacked library code to continue executing. Rename the original library from libcc.so to liba.so.

[0015] The hijacked library calls dlopen(" / path / to / liba.so",RTLD_LAZY|RTLD_GLOBAL) to load the original library with the restored name. The hijacked library (liba.so(deleted) in memory) and the original library (the newly loaded liba.so) coexist in the process address space.

[0016] Continue to execute the original library method, including: the hijacking library intercepts the original library function through the Inline Hook and forwards the call to the original library logic.

[0017] In some optional implementations, locating the original library in the private directory of the target application includes:

[0018] Unpack the installation package file of the target application and locate the original library named first in its private directory;

[0019] Reverse engineer the original library and track the methods and relative addresses called by RegisterNatives in the original library.

[0020] In the above technical solution, use a tool (such as apktool or jadx) to decompress the APK file and extract its internal resources and code. The APK file is essentially a compressed package. After decompression, you can view the package name (package attribute) in the AndroidManifest.xml file and the native library file (such as liba.so) in the lib directory. Locate the native library in the private directory. For example, if the target application package name is com.example.app, the native library path is: data / app / com.example.app / lib / arm64-v8a / liba.so.

[0021] For reverse analysis, choose a static analysis tool (such as IDA Pro, Ghidra, or Radare2) or a dynamic debugging tool (such as Frida or GDB). Reverse analysis involves opening liba.so in the reverse tool and searching for the exported function JNI_OnLoad; analyzing its code logic, locating the RegisterNatives call site, and tracing the RegisterNatives call to extract the method and its relative address.

[0022] In some optional implementations, unpacking the installation package file of the target application includes: using an apktool tool to unpack the installation package file of the target application.

[0023] In some optional implementations, reverse engineering the original library includes analyzing the export functions of the original library using IDA Pro or Ghidra.

[0024] In some optional implementations, renaming the second name of the hijacking library to be before the first name further includes: compiling the hijacking library;

[0025] Write a hijacking library, including:

[0026] In the JNI_OnLoad of the hijacked library, the original library with a temporary name is dynamically loaded through dlopen, and the JNI_OnLoad function pointer of the original library is obtained through dlsym, which automatically triggers the initialization logic of the original library, so that the JNI method of the original library is registered normally, avoiding application crashes;

[0027] According to the original library method and relative address, the Inline Hook technology is used to intercept the temporary original library method and declare the same proxy function to ensure that parameters can be passed normally and results can be returned when called.

[0028] In the above technical solution, writing the hijacking library (libb.so) is the key step to realize dynamic library hijacking. Its core goal is to take over the JNI method calls of the original library and transparently forward the logic, while ensuring the normal initialization and compatibility of the original library.

[0029] Hijack the library's JNI_OnLoad implementation:

[0030] By dynamically loading the original library and triggering its initialization, it ensures that the JNI methods are correctly registered.

[0031] Specifically, in the hijacked library's JNI_OnLoad, use dlopen to load the renamed original library (libcc.so). Obtain and actively call the original library's JNI_OnLoad to ensure that its RegisterNatives is executed correctly.

[0032] Inline Hook intercepts the original library:

[0033] Hijack the target function in the original library (such as encryption algorithm, network communication) to achieve parameter monitoring or logic tampering.

[0034] Specifically, reverse engineering is used to obtain the relative address of the target function in the original library (e.g., 0x1234) and calculate its absolute address. A hook framework (e.g., Dobby) is used to hijack the target function. The same proxy function is declared to ensure that parameters are passed and results are returned normally when called.

[0035] In some optional implementations, the method of the temporary original library is intercepted by using the Inline Hook technology, including:

[0036] Use the Dobby or Substrate tool of the Hook framework to hijack the target function entry.

[0037] In some optional implementations, loading the hijacking library named first includes:

[0038] The target application calls System.loadLibrary to load the hijacked library named first.

[0039] In some optional implementations, before using dlopen to load the first named original library, the method further includes:

[0040] In / proc / self / maps it shows that the hijack library named first has been deleted.

[0041] In some optional implementations, deleting the hijacked library file, renaming the temporary name of the original library to the first name, and using dlopen to load the original library with the first name include:

[0042] After the execution of init_array of the hijacked library is completed, the thread is started to delete the hijacked library file; in JNI_OnLoad of the hijacked library, the temporary name of the original library is renamed to the first name, and then dlopen is used to load the original library with the first name.

[0043] In the above technical solution, in the init_array section of the hijacking library, an independent thread is started to perform the file deletion operation. The hijacking library file is deleted in the init_array stage, and only liba.so (deleted) is displayed in / proc / self / maps, avoiding static detection based on file hash. In the JNI_OnLoad of the hijacking library, the renaming operation of the original library is performed, and the original library with the restored name is loaded through dlopen, and its initialization logic is triggered. After the original library is loaded through the second dlopen, there are two libraries with the same name in the memory (the hijacking library is marked as deleted, and the original library is mapped normally), which interferes with the judgment of the reverse analysis tool. The hijacking library loads the original library through dlopen and retains its symbol table to ensure that the JNI method is registered normally when the application calls RegisterNatives, avoiding the UnsatisfiedLinkError crash.

[0044] An electronic device provided in an embodiment of the present application includes: a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and when the machine-readable instructions are executed by the processor, any of the above methods is performed.

[0045] An embodiment of the present application provides a computer-readable storage medium, wherein when the computer-readable instructions in the computer-readable storage medium are executed by a processor, any of the above methods is executed.

[0046] A computer program product provided in an embodiment of the present application includes a computer program / instruction, which implements the steps of any of the above methods when executed by a processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without creative work.

[0048] Figure 1 A flowchart of the steps of a dynamic library hijacking method provided in an embodiment of the present application;

[0049] Figure 2 A schematic diagram of a possible structure of an electronic device provided in an embodiment of the present application.

[0050] Icons: 110 - communication unit, 120 - memory, 130 - input unit, 131 - touch-sensitive surface, 132 - other input devices, 140 - display unit, 141 - display panel, 150 - sensor, 160 - audio circuit, 170 - wireless communication unit, 180 - processor, 190 - power supply. DETAILED DESCRIPTION

[0051] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0052] The dynamic library hijacking method provided by one or more embodiments of the present application can be used to: by hijacking the dynamic library, new functional modules can be added or existing functions can be modified without modifying the original application code, such as implementing logging, parameter modification, behavior monitoring, etc., thereby improving the flexibility and efficiency of development. Figure 1 , Figure 1 A flowchart of a dynamic library hijacking method provided in an embodiment of the present application includes:

[0053] Step 100: Locate the original library in the private directory of the target application and rename the first name of the original library to a temporary name;

[0054] Step 200: rename the second name of the hijacked library to the first name;

[0055] Step 300: Load the hijacking library named first;

[0056] Step 400: After loading the hijacked library into the memory, delete the hijacked library file, rename the temporary name of the original library to the first name, and use dlopen to load the original library with the first name;

[0057] Step 500: Continue executing the method in the original library.

[0058] In the embodiment of the present application, the original library and the hijacked library are dynamic libraries. By renaming the dynamic library, residing in memory and controlling the loading order, there is no need to modify the APK or restart the application to achieve real-time replacement and function expansion of the dynamic library. An independent thread is started in the init_array stage of the hijacked library, and unlink is called to delete its own file (liba.so). At this time, the code segment of the hijacked library has been loaded into the memory, but the file system no longer retains the hijacked library file. The hijacking process of this embodiment has no file residues, and only the code segment is retained in the memory ( / proc / self / maps is displayed as liba.so (deleted)). After the hijacked library is deleted, the original library is renamed from a temporary name (libcc.so) to liba.so. Its file content is not modified, and the hash value is consistent with the original version, avoiding detection based on file hash. After the hijacked library (libb.so) is renamed to liba.so, it is stored in the application's private directory (e.g., / data / app / ... / lib / arm64), exactly as the normal library path. Furthermore, after the hijacked library file is deleted, only the original library file (liba.so) with the restored name remains in the same directory, which is exactly the same as the original installation path, thus avoiding path detection. Furthermore, JNI_OnLoad and all JNI methods in the original library execute normally, avoiding crashes such as UnsatisfiedLinkError.

[0059] Specifically, by decompiling the APK file of the target application, locating the target application private directory (such as / data / app / <package>Rename the original library liba.so under / lib / arm64 to a temporary name (such as libcc.so). Android app private directories have read and write permissions isolated. Hijacking requires modifying files after the app is installed by escalating privileges or injecting code. In this step, renaming the original library avoids subsequent loading conflicts and preserves its complete functional logic.

[0060] Rename the hijacked library libb.so to liba.so, replacing the original library location. Android dynamic library loading priority: application private directory > system directory. The hijacked library is disguised as the original library name, ensuring that System.loadLibrary("a") prioritizes loading the hijacked library. The hijacked library must export the same global symbols as the original library (using the --export-dynamic compilation option) to prevent symbol resolution failures.

[0061] The application calls System.loadLibrary("a") to load the hijacked library (the disguised liba.so). The underlying dlopen process: parses the ELF file header, maps the code (.text) and data (.data) segments into memory; executes the initialization function in the init_array segment; and calls JNI_OnLoad (if present). A background thread is started in the hijacked library's init_array to perform cleanup operations.

[0062] Call unlink(" / path / to / liba.so") in the hijacked library's init_array or in a separate thread to delete the hijacked library's own file. After the file is deleted, the hijacked library is marked as "deleted" in / proc / self / maps, but the code segment remains in memory, allowing the hijacked library code to continue executing. Rename the original library from libcc.so to liba.so.

[0063] The hijacked library calls dlopen(" / path / to / liba.so",RTLD_LAZY|RTLD_GLOBAL) to load the original library with the restored name. The hijacked library (liba.so(deleted) in memory) and the original library (the newly loaded liba.so) coexist in the process address space.

[0064] Continue to execute the original library method, including: the hijacking library intercepts the original library function through the Inline Hook and forwards the call to the original library logic.

[0065] APK (Android Package Kit) is the installation package file format of Android applications, which contains application code, resources, certificates and native libraries (.so files). After the user installs the APK, the system will decompress it to / data / app / <package_name> The lib / subdirectory stores dynamic libraries for different ABIs (such as armeabi-v7a and arm64-v8a).

[0066] JNI (Java Native Interface) is a Java native interface that allows Java code to interact with native code such as C / C++. JNI methods are methods implemented in native code (C / C++) and called by the Java layer.

[0067] System.loadLibrary is the Java layer method for loading local dynamic libraries, which is used to load the library named lib <name>.so library, triggering the loading of dynamic libraries and executing init_array and JNI_OnLoad.

[0068] JNI_OnLoad is an initialization function that is automatically called when a dynamic library is loaded. It is used to register JNI methods or perform other initialization operations.

[0069] RegisterNatives is a function provided by JNI that is used to manually bind local methods to native methods in Java classes, avoiding automatic method name lookup (improving performance) and supporting dynamic registration.

[0070] init_array is a segment in ELF (Executable and Linkable Format) files that stores an array of initialization function pointers. When a dynamic library is loaded, all functions in init_array are automatically executed before JNI_OnLoad.

[0071] Dlopen is a function for dynamically loading a shared library. Dlsym is used to obtain the address of a symbol (function or variable) from a loaded library.

[0072] Inline Hook: A technique that redirects the execution flow to custom code by modifying the machine instructions of the target function (such as inserting a jump instruction). It is used to intercept function calls and implement logging, parameter tampering, behavior monitoring, etc. The core steps of Inline Hook include: backing up the original function entry code; inserting a jump instruction (such as B<hook_func> ); Jump back to the original function after executing the logic in the proxy function.

[0073] / proc / self / maps is a virtual file in Linux that displays the memory map of the current process (loaded libraries, stack, memory areas, etc.). / proc / self / maps is used to debug memory leaks and view the loading status of dynamic libraries (for example, the (deleted) flag indicates that the file has been deleted but remains in memory).

[0074] Dynamic library loading process: System.loadLibrary → load .so → execute init_array → call JNI_OnLoad → register JNI method.

[0075] In some optional implementations, locating the original library in the private directory of the target application includes:

[0076] Unpack the installation package file of the target application and locate the original library named first in its private directory;

[0077] Reverse engineer the original library and track the methods and relative addresses called by RegisterNatives in the original library.

[0078] In this embodiment of the application, a tool (such as apktool or jadx) is used to decompress the APK file and extract its internal resources and code. The APK file is essentially a compressed package. After decompression, the package name (package attribute) in AndroidManifest.xml and the native library file (such as liba.so) in the lib directory can be viewed. Locate the native library in the private directory. For example, if the target application package name is com.example.app, the native library path is: data / app / com.example.app / lib / arm64-v8a / liba.so.

[0079] For reverse analysis, choose a static analysis tool (such as IDA Pro, Ghidra, or Radare2) or a dynamic debugging tool (such as Frida or GDB). Reverse analysis involves opening liba.so in the reverse tool and searching for the exported function JNI_OnLoad; analyzing its code logic, locating the RegisterNatives call site, and tracing the RegisterNatives call to extract the method and its relative address.

[0080] In some optional implementations, unpacking the installation package file of the target application includes: using an apktool tool to unpack the installation package file of the target application.

[0081] In some optional implementations, reverse engineering the original library includes analyzing the export functions of the original library using IDA Pro or Ghidra.

[0082] In some optional implementations, renaming the second name of the hijacking library to be before the first name further includes: compiling the hijacking library;

[0083] Write a hijacking library, including:

[0084] In the JNI_OnLoad of the hijacked library, the original library with a temporary name is dynamically loaded through dlopen, and the JNI_OnLoad function pointer of the original library is obtained through dlsym, which automatically triggers the initialization logic of the original library, so that the JNI method of the original library is registered normally, avoiding application crashes;

[0085] According to the original library method and relative address, the Inline Hook technology is used to intercept the temporary original library method and declare the same proxy function to ensure that parameters can be passed normally and results can be returned when called.

[0086] In the embodiment of the present application, writing a hijacking library (libb.so) is a key step in realizing dynamic library hijacking. Its core goal is to take over the JNI method calls of the original library and transparently forward the logic, while ensuring the normal initialization and compatibility of the original library.

[0087] Hijack the library's JNI_OnLoad implementation:

[0088] By dynamically loading the original library and triggering its initialization, it ensures that the JNI methods are correctly registered.

[0089] Specifically, in the hijacked library's JNI_OnLoad, use dlopen to load the renamed original library (libcc.so). Obtain and actively call the original library's JNI_OnLoad to ensure that its RegisterNatives is executed correctly.

[0090] Inline Hook intercepts the original library:

[0091] Hijack the target function in the original library (such as encryption algorithm, network communication) to achieve parameter monitoring or logic tampering.

[0092] Specifically, reverse engineering is used to obtain the relative address of the target function in the original library (e.g., 0x1234) and calculate its absolute address. A hooking framework (e.g., Dobby) is used to hijack the target function. The same proxy function is declared to ensure that parameters are passed and results are returned correctly when called, thus ensuring proper initialization and compatibility with the original library.

[0093] In some optional implementations, the method of the temporary original library is intercepted by using the Inline Hook technology, including:

[0094] Use the Dobby or Substrate tool of the Hook framework to hijack the target function entry.

[0095] In some optional implementations, loading the hijacking library named first includes:

[0096] The target application calls System.loadLibrary to load the hijacked library named first.

[0097] In some optional implementations, before using dlopen to load the first named original library, the method further includes:

[0098] In / proc / self / maps it shows that the hijack library named first has been deleted.

[0099] In some optional implementations, deleting the hijacked library file, renaming the temporary name of the original library to the first name, and using dlopen to load the original library with the first name include:

[0100] After the execution of init_array of the hijacked library is completed, the thread is started to delete the hijacked library file; in JNI_OnLoad of the hijacked library, the temporary name of the original library is renamed to the first name, and then dlopen is used to load the original library with the first name.

[0101] In the embodiment of the present application, in the init_array segment code of the hijacking library, an independent thread is started to perform file deletion operation, and the hijacking library file is deleted in the init_array stage, and only liba.so (deleted) is displayed in / proc / self / maps, to avoid static detection based on file hash. In the JNI_OnLoad of the hijacking library, the rename operation of the original library is performed, and the original library of the restored name is loaded by dlopen, and its initialization logic is triggered. After the original library is loaded by secondary dlopen, there are two libraries of the same name in the memory (the hijacking library is marked as deleted, and the original library is normally mapped), which interferes with the judgment of the reverse analysis tool. The hijacking library loads the original library by dlopen and retains its symbol table, ensures that the application normally registers JNI methods when calling RegisterNatives, avoids the collapse of UnsatisfiedLinkError.

[0102] All the above optional technical solutions of this embodiment can be combined in any way to form the optional technical solutions of the present invention, and will not be given examples one by one here.

[0103] The dynamic library hijacking method of this embodiment can be implemented on the browser client side and used as an engine device of the browser. It can also be implemented in an electronic device, which performs its functions independently.

[0104] Figure 2 This is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. Figure 2 , the electronic device can be used to implement the dynamic library hijacking method provided in the above embodiment. Specifically:

[0105] The electronic device may include a communication unit 110, a memory 120 including one or more computer-readable storage media, an input unit 130, a display unit 140, a sensor 150, an audio circuit 160, a WiFi (wireless fidelity) module 170, a processor 180 including one or more processing cores, and a power supply 190. Those skilled in the art will understand that Figure 2 The electronic device structure shown in the figure does not constitute a limitation of the electronic device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange components differently.

[0106] The communication unit 110 can be used to send and receive information or receive and send signals during calls. The communication unit 110 can be a network communication device such as an RF (Radio Frequency) circuit, a router, or a modem. In particular, when the communication unit 110 is an RF circuit, after receiving the downlink information from the base station, it is handed over to one or more processors 180 for processing; in addition, uplink data is sent to the base station. Generally, the RF circuit used as a communication unit includes but is not limited to an antenna, at least one amplifier, a tuner, one or more oscillators, a subscriber identity module (SIM) card, a transceiver, a coupler, an LNA (Low Noise Amplifier), a duplexer, etc. In addition, the communication unit 110 can also communicate with the network and other devices through wireless communication. The wireless communication may use any communication standard or protocol, including but not limited to GSM (Global System of Mobile communication), GPRS (General Packet Radio Service), CDMA (Code Division Multiple Access), WCDMA (Wideband Code Division Multiple Access), LTE (Long Term Evolution), email, SMS (Short Messaging Service), etc. The memory 120 may be used to store software programs and modules, and the processor 180 executes various functional applications and data processing by running the software programs and modules stored in the memory 120. The memory 120 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application program required for at least one function (such as a sound playback function, an image playback function, etc.); and the data storage area may store data created according to the use of the electronic device (such as audio data, a phone book, etc.). In addition, the memory 120 may include a high-speed random access memory and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage device. Accordingly, the memory 120 may further include a memory controller to provide the processor 180 and the input unit 130 with access to the memory 120 .

[0107] The input unit 130 can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical, or trackball signal input related to user settings and function control. Specifically, the input unit 130 may include a touch-sensitive surface 131 and other input devices 132. The touch-sensitive surface 131, also known as a touch display or touchpad, can detect user touch operations on or near it (for example, operations performed by a user using a finger, stylus, or any other suitable object or accessory on or near the touch-sensitive surface 131) and drive corresponding connected devices according to a pre-set program. Optionally, the touch-sensitive surface 131 may include a touch detection device and a touch controller. The touch detection device detects the user's touch position and detects signals generated by the touch operation, transmitting the signals to the touch controller. The touch controller receives the touch information from the touch detection device, converts it into touch point coordinates, and then sends it to the processor 180. It can also receive and execute commands from the processor 180. In addition, the touch-sensitive surface 131 can be implemented using various types, including resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch-sensitive surface 131, the input unit 130 may further include other input devices 132. Specifically, the other input devices 132 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, and a joystick.

[0108] The display unit 140 can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the electronic device, which can be composed of graphics, text, icons, videos and any combination thereof. The display unit 140 may include a display panel 141. Optionally, the display panel 141 may be configured in the form of an LCD (Liquid Crystal Display), an OLED (Organic Light-Emitting Diode), or the like. Furthermore, the touch-sensitive surface 131 may cover the display panel 141. When the touch-sensitive surface 131 detects a touch operation on or near it, it is transmitted to the processor 180 to determine the type of touch event. The processor 180 then provides corresponding visual output on the display panel 141 according to the type of touch event. Although in Figure 2 In the embodiment, the touch-sensitive surface 131 and the display panel 141 are implemented as two independent components to implement input and output functions, but in some embodiments, the touch-sensitive surface 131 and the display panel 141 can be integrated to implement input and output functions.

[0109] The electronic device may also include at least one sensor 150, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display panel 141 according to the brightness of the ambient light, and the proximity sensor may turn off the display panel 141 and / or the backlight when the electronic device is moved to the ear. As a type of motion sensor, the gravity acceleration sensor can detect the magnitude of acceleration in all directions (generally three axes), and can detect the magnitude and direction of gravity when stationary. It can be used for applications that identify the posture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.; as for other sensors that the electronic device can also be configured with, such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., they will not be described here.

[0110] The audio circuit 160, speaker, and microphone provide an audio interface between the user and the electronic device. The audio circuit 160 converts received audio data into electrical signals and transmits them to the speaker, which then converts them into sound signals for output. The microphone, on the other hand, converts collected sound signals into electrical signals, which are then received by the audio circuit 160 and converted into audio data. The audio data is then processed by the processor 180 and then transmitted to, for example, another electronic device via the RF circuit 110. Alternatively, the audio data can be output to the memory 120 for further processing. The audio circuit 160 may also include an earphone jack to allow communication between external headphones and the electronic device.

[0111] In order to achieve wireless communication, the electronic device may be equipped with a wireless communication unit 170, which may be a WiFi module. WiFi is a short-range wireless transmission technology. The electronic device can help users send and receive emails, browse web pages, and access streaming media through the wireless communication unit 170, providing users with wireless broadband Internet access. Figure 2 A wireless communication unit 170 is shown, but it is understandable that it is not an essential component of the electronic device and can be omitted as needed without changing the essence of the invention.

[0112] Processor 180 is the control center of the electronic device, connecting all components of the phone using various interfaces and circuits. By running or executing software programs and / or modules stored in memory 120 and accessing data stored in memory 120, it performs various functions of the electronic device and processes data, thereby providing overall monitoring of the phone. Optionally, processor 180 may include one or more processing cores; preferably, processor 180 may integrate an application processor and a modem processor, with the application processor primarily handling the operating system, user interface, and application programs, while the modem processor primarily handles wireless communications. It is understood that the modem processor may not be integrated into processor 180.

[0113] The electronic device also includes a power supply 190 (e.g., a battery) for supplying power to various components. Preferably, the power supply can be logically connected to the processor 180 via a power management system, thereby enabling the power management system to manage charging, discharging, and power consumption. The power supply 190 can also include one or more DC or AC power supplies, a recharging system, a power failure detection circuit, a power converter or inverter, a power status indicator, and other arbitrary components.

[0114] Although not shown, the electronic device may further include a camera, a Bluetooth module, etc., which will not be described in detail here. Specifically in this embodiment, the display unit of the electronic device is a touch screen display, and the electronic device further includes a memory, and one or more programs, wherein the one or more programs are stored in the memory, and are configured to be executed by one or more processors to include instructions for performing the following operations: locating the original library under the private directory of the target application, renaming the first name of the original library to a temporary name; renaming the second name of the hijacked library to the first name; loading the hijacked library named the first name; after loading the hijacked library into the memory, deleting the hijacked library file, renaming the temporary name of the original library to the first name, and using dlopen to load the original library with the first name; continuing to execute the method in the original library.

[0115] Optionally, the memory is further configured to store the following instructions: unpacking the installation package file of the target application, and locating the original library named as the first name in the private directory thereof;

[0116] Reverse engineer the original library and track the methods and relative addresses called by RegisterNatives in the original library.

[0117] Optionally, the memory is also used to store the following instructions: after executing init_array of the hijacked library, start a thread to delete the hijacked library file; in JNI_OnLoad of the hijacked library, rename the temporary name of the original library to the first name, and then use dlopen to load the original library with the first name.

[0118] A computer program product provided in an embodiment of the present application includes a computer program / instruction, which implements the steps of any of the above methods when executed by a processor.

[0119] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interface, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0120] In addition, the units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0121] Furthermore, the functional modules in each embodiment of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0122] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any actual relationship or order between these entities or operations.

[0123] The above description is merely an embodiment of the present application and is not intended to limit the scope of protection of the present application. For those skilled in the art, various modifications and variations of the present application are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.< / name> < / package> < / package>

Claims

1. A dynamic library hijacking method, characterized in that: include: Locate the original library in the private directory of the target application and rename the first name of the original library to a temporary name; Rename the second name of the hijacked library to the first name; Load the hijacking library named first; After loading the hijacked library into the memory, the hijacked library file is deleted, the temporary name of the original library is renamed to the first name, and the original library with the first name is loaded using dlopen; Continue to execute the method in the original library.

2. The method according to claim 1, wherein The original library located in the private directory of the target application includes: Unpack the installation package file of the target application and locate the original library named first in its private directory; Reverse-engineer the original library and trace the methods and relative addresses called by RegisterNatives in the original library.

3. The method according to claim 2, wherein The step of renaming the second name of the hijacking library to be before the first name further includes: compiling the hijacking library; The writing of the hijacking library includes: In the JNI_OnLoad of the hijacked library, the original library named temporarily is dynamically loaded through dlopen, and the JNI_OnLoad function pointer of the original library is obtained through dlsym, which actively triggers the initialization logic of the original library, so that the JNI method of the original library is normally registered; According to the method and relative address, the method of the original library named temporarily is intercepted through the Inline Hook technology, and the same proxy function is declared to ensure that parameters can be passed normally and results can be returned when called.

4. The method according to claim 3, wherein The Inline Hook technology is used to intercept the method of the temporary library, including: Use the Dobby or Substrate tool of the Hook framework to hijack the target function entry.

5. The method according to claim 1, wherein The loading of the hijacking library named as the first one includes: The target application calls System.loadLibrary to load the hijacking library named as the first name.

6. The method according to claim 1, wherein Before using dlopen to load the first named original library, the method further includes: In / proc / self / maps it shows that the hijacked library named first has been deleted.

7. The method according to claim 1, wherein The process of deleting the hijacked library file, renaming the temporary name of the original library to the first name, and using dlopen to load the original library with the first name includes: After the execution of init_array of the hijacking library is completed, a thread is started to delete the hijacking library file; in JNI_OnLoad of the hijacking library, the temporary name of the original library is renamed to the first name, and then dlopen is used to load the original library with the first name.

8. An electronic device, characterized in that: include: A processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and when the machine-readable instructions are executed by the processor, the method according to any one of claims 1 to 7 is performed.

9. A computer-readable storage medium, characterized in that When the computer-readable instructions in the computer-readable storage medium are executed by a processor, the method according to any one of claims 1 to 7 is performed.

10. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instruction is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images