WO2015074526A1

WO2015074526A1 - Method and apparatus for injecting java by tecode into target process

Info

Publication number: WO2015074526A1
Application number: PCT/CN2014/091287
Authority: WO
Inventors: Jiahui LIANG
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2013-11-21
Filing date: 2014-11-17
Publication date: 2015-05-28
Anticipated expiration: 2016-05-21
Also published as: CN104657258B; CN104657258A

Abstract

Method and System for injecting Java bytecode into a target process of an application program are disclosed. The method includes: at a device having one or more processors and memory: during execution of the target process of the application program, detecting a call to load a predetermined code injection function; in response to the detected call to load the predetermined code injection function, loading Java bytecode referenced by the code injection function into a virtual machine; in accordance with a pre-stored Java native interface corresponding to the loaded Java bytecode, calling an entrypoint function in the Java bytecode, wherein the entrypoint function is configured to perform one or more extended tasks for the application program; and executing the entrypoint function in the virtual machine to accomplish the one or more extended tasks of the application program.

Description

METHOD AND APPARATUS FOR INJECTING JAVA BYTECODE INTO A TARGET PROCESS

PRIORITY CLAIM AND RELATED APPLICATION

This application claims priority to Chinese Patent Application No. 201310591379.3, entitled “Method and Apparatus for Injecting Java Bytecode into a Target Process” filed on November 21, 2013, which is incorporated by reference in its entirety.

FIELD OF THE TECHNOLOGY

The present disclosure relates to computer process injection technologies, and in particular, to a method for injecting Java bytecode into a target process.

BACKGROUND

An injection technology in computer programming refers to an injection of a binary file, for example, a . so file in Linux and a . dll file in Windows, into a target process, to implement function extension of the target process. On the other hand, with development of computer technologies, a virtual machine technology is extensively applied. However, it is difficult to inject bytecode that needs to be run by a virtual machine into a target process with the forgoing injection method.

SUMMARY

In some embodiments, a method of injecting Java bytecode to a target process is performed at a device (e.g., device 800, FIG. 8) with one or more processors and memory. The method includes: .

In some embodiments, a computing device (e.g., device 800 (FIG. 8) or a component thereof (e.g., injection module 828, FIG. 8) ) includes one or more processors and memory storing one or more programs for execution by the one or more processors, the one or more programs include instructions for performing, or controlling performance of, the operations of any of the methods described herein. In some embodiments, a non-transitory computer readable storage medium storing one or more programs, the one or more programs comprising instructions, which, when executed by a computing device (e.g., device 800 (FIG. 8) or a component thereof (e.g., injection module 828, FIG. 8) ) with one or more processors, cause the computing device to perform, or control performance of, the operations of any of the methods described herein. In some embodiments, a computing device (e.g., device 800 (FIG. 8) or a component thereof (e.g., injection module 828, FIG. 8) ) includes means for performing, or controlling performance of, the operations of any of the methods described herein.

Various advantages of the present application are apparent in light of the descriptions below.

BRIEF DESCRIPTION OF THE DRAWINGS

The aforementioned features and advantages of the invention as well as additional features and advantages thereof will be more clearly understood hereinafter as a result of a detailed description of preferred embodiments when taken in conjunction with the drawings.

FIG. 1 is a structural block diagram of a computer on which a virtual machine runs in accordance with some embodiments.

FIG. 2 is a flowchart of a method for injecting Java bytecode into a target process in accordance with some embodiments.

FIG. 3 is a structural block diagram of an Android device in accordance with some embodiments.

FIG. 4 is a flowchart of a method for injecting Java bytecode into a target process in accordance with some embodiments.

FIG. 5 is a flow chart of a method for injecting Java bytecode into a target process in accordance with some embodiments.

FIG. 6 is a structural block diagram of an apparatus for injecting Java bytecode into a target process in accordance with some embodiments.

FIG. 7 is a structural block diagram of an apparatus for injecting Java bytecode into a target process in accordance with some embodiments.

FIG. 8 is a block diagram of a device for injecting Java bytecode into a target process in accordance with some embodiments.

Like reference numerals refer to corresponding parts throughout the several views of the drawings.

DESCRIPTION OF EMBODIMENTS

Reference will now be made in detail to embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the subject matter presented herein. But it will be apparent to one skilled in the art that the subject matter may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

To further describe technical means adopted by the present technology to achieve a predetermined objective and effects, the following describes in detail specific implementation manners, structures, characteristics, and effects of the present invention with reference to accompanying drawings and exemplary embodiments.

FIG. 1 is a structural block diagram of a computer on which a virtual machine runs. It may be understood that, the computer herein includes various computing devices with architecture comprising a memory and at least one processor, such as a personal computer, a server, a smart phone, and a tablet. As shown in FIG. 1, a computer 100 includes: a memory 102, one or more processors 104, and other hardware 106. It may be understood that, a structure shown in FIG. 1 is only schematic, and does not limit a structure of the computer 100. For example, the computer 100 may further include components more than or fewer than those shown in FIG. 1, or has a configuration different from that shown in FIG. 1.

The memory 102 may be configured to store one or more software programs and modules, and the processor (s) 104 execute various functional applications and data processing by running the software programs and modules that are stored in the memory 102. The memory 102 may include a high-speed random memory, and may also include a nonvolatile memory, for example, one or more magnetic storage devices, flash memories, or other nonvolatile solid-state memories. In some instances, the memory 102 may further include memories that are remotely located relative to the processors 104, and these remote memories may be connected to a vulnerability detection server through a network. An instance of the foregoing network includes but is not limited to the Internet, an enterprise intranet, a local area network, a mobile communications network, and a combination thereof.

The other hardware 106, for example, may include a display, a keyboard, a network card, and an audio circuit, which are generally configured to provide an input/output function or a function of exchanging data with other devices.

The foregoing software programs and modules stored in the memory 102, for example, may include: an operating system kernel 122, a Java virtual machine (JVM) 124, a Java class library 126, and one or more Java application programs 128. The operating system kernel 122 directly controls various pieces of hardware, and specifically may be Windows operating system or a Linux kernel. The JVM 124 runs on the system kernel 122, is essentially a virtual computer, and is implemented by simulating various computer functions on the operating system kernel 122. The JVM 124 generally includes a bytecode instruction set, a group of registers, a stack, a garbage collection heap, and a storage method domain. The JVM 124 shields information relevant to a specific operating system platform, so that a Java program can run, by only generating a target code (bytecode) that runs on a JVM, on various platforms without being modified. When executing the bytecode, in fact, the JVM 124 eventually interprets the bytecode as a machine instruction on a specific platform and then executes the instruction. The Java class library 126 is a public class library provided to facilitate programming. Various interfaces may be provided in the Java class library 126 to provide various functions, and these interfaces may be used by an application program layer. The Java application program 128 is an application program which is implemented based on various interfaces of the Java class library and has various functions.

Further, the foregoing software programs and modules stored in the memory 102 may further include: a local binary shared library 130 and a Java native interface (JNI) 132. The local binary shared library 130, for example, may be a . dll file in the Windows system and a . so file in the Linux system. The JNI 132 is configured to provide a standard interface during implementation of different JVMs, so that a Java application may use the local binary shared library 130, thereby extending the functions of the original JVM 124.

In some embodiments, a method for injecting Java bytecode into a target process includes the following steps, as shown in FIG. 2:

Step S101: Modify a register of the target process by using a system call provided by a host operating system, to load a binary shared library.

In a computer system, program code runs in two modes. One is a user mode, and the other is a kernel mode. An application program on an application layer runs in the user mode, and a device driver and a file system run in the kernel mode. A program that runs in the user mode is strictly managed, so that it does not damage a system-level application. However, a program that runs in the kernel mode may have full access to the computer. The system call is a way that program code running in the kernel mode provides a service for program code running in the user mode.

Using the Linux system as an example, its system call is implemented by using int 80h, and entrypoint functions are differentiated by using the system call. A basic process in which an operating system implements the system call is that: the application program calls a library function (API) ； the API stores the system call number of the system call into an EAX, and then makes the system enter a kernel state by using an interruption call； an interruption processing function in the kernel calls a corresponding kernel function (the system call) according to the system call number of the system call； the system call completes a corresponding function, stores a return value into the EAX, and returns the EAX to the interruption processing function； the interruption processing function returns to the API； and the API returns the EAX to the application program.

A process in which the application program calls the system call includes: the system call number is stored into the EAX； a function parameter is stored into another general register； and the interruption for the call No. 0x80 (int 0x80) is triggered.

Specifically, in the Linux system, a register of the target process may be modified by using a ptrace function, to call a dlopen function. However, the dlopen function is used to load the binary shared library. In other operating systems, the specific command possibly varies, but its principle and process are similar.

The binary shared library, for example, may be the binary shared library 130 shown in FIG. 1, and includes an automatic start function. In an instance, the automatic start function is implemented by using global variables. For example, in c/c++ language, when a certain binary shared library (adynamic link library) is loaded by dlopen, the global variables need to be automatically initialized. At this time, any function call during initialization may be used as the entrypoint function, and this entrypoint function can complete all needed events.

Step S102: Load into a virtual machine a file including the Java bytecode having a specified path in the binary shared library, and call the entrypoint function in the Java bytecode.

As described above, after the binary shared library is loaded, the automatic start function inside the library is enabled. After the automatic start function is enabled, step S102 is performed, to load the file including the Java bytecode having the specified path into the virtual machine, and the entrypoint function included in the loaded Java bytecode may be called by using a Java native interface (e.g., JNI 132) .

Step S103: Instructions in the Java bytecode are executed by the virtual machine, and these instructions in the Java bytecode may use various interfaces in the Java class library, so as to implement various functions that are based on the Java class library, that is, perform step S103.

According to the method described herein, Java bytecode of a class library, which relies on a virtual machine and runs on the virtual machine, can be injected into a target process, thereby extending functions of the target process.

In some embodiments, another method for injecting Java bytecode into a target process, which is similar to the method described with FIG. 1 is provided. A difference lies in that the method in this embodiment is applied to a device that runs the Android operating system.

FIG. 3 is a schematic architectural diagram of an Android device 200. As shown in FIG. 3, an Android device 200 includes: a memory 102, a processor 104, and other hardware 106. This Android device can be implemented by the device 100 shown in FIG. 1, and reference may be made to the foregoing description.

A software program and module in the memory 102 in FIG. 3, for example, may include: a Linux kernel 222, a Delvik virtual machine (DVM) 224, an Android framework 226, and an Android application program 228. The Linux kernel 222 directly controls various pieces of hardware. The DVM 224 runs on the system kernel 222. A JVM 124 is a stack machine, while the DVM 224 is a register machine.

The Android framework 226 is a public class library provided to facilitate programming. Various interfaces, for example, a communication management interface, a location interface, and an installation package management interface, may be provided in the Android framework 226 to provide various functions, and these interfaces may be used by an application program layer. The Android application program 228 is an application program which is implemented based on various interfaces of an Android class library and has various functions.

Further, the foregoing software programs and modules stored in memory 102 may further include: a local binary shared library 130 and a JNI 132. The local binary shared library 130, for example, may be a . so file in the Linux system. The JNI 132 is configured to provide a standard interface during implementation of different JVMs, so that a Java application may use the local binary shared library 130, thereby extending the functions of the original DVM 224.

Referring to FIG. 4, the method in this embodiment includes the following steps:

Step S201: Modify a register of the target process by using a system call provided by the Linux system, to load a binary shared library.

For example, a register of the target process is modified by using a ptrace function, to call a dlopen function, and the binary shared library is loaded by using the dlopen function.

The loaded binary shared library may include an automatic start function. In an instance, the automatic start function is implemented by using global variables. For example, in c/c++ language, when a certain binary shared library (a dynamic link library) is loaded by dlopen, the global variables need to be automatically initialized. At this time, any function call during initialization may be used as an entrypoint function, and the entrypoint function can complete all needed events, for example, perform step S202.

Step S202: The binary shared library loads a file including the Java bytecode in a specified path into the DVM 224, and calls the entrypoint function in the Java bytecode by using the JNI 132.

As described above, after the binary shared library is loaded, the automatic start function inside it is enabled. After the automatic start function is enabled, step S202 is performed, to load a . dex file in the specified path into the DVM 224, and the entrypoint function in the loaded . dex file may be called by using the JNI 132.

Step S203: Instructions in the . dex file are executed by the DVM 224, and these instructions in the . dex file may use various interfaces provided by the Android framework 226, so as to implement various functions that are based on the Android framework 226. The foregoing . dex file is a compression format that is specially designed for the DVM, and is applicable to a system whose memory and processor are limited in speed.

According to the method provided by this embodiment, a code that is executed by relying on an Android framework interface can be injected into a target process. In this way, various functions in the Android system can be implemented in the target process, thereby greatly extending functions of the target process.

FIG. 5 is a flowchart of a process 500 for injecting Java bytecode to a target process. In some embodiments, the process is performed by a computing device (e.g., device 800 in FIG. 8) having one or more processors and memory.

In some embodiments, the device, during execution of the target process of the application program, detects (502) a call to load a predetermined code injection function. The predetermined code injection function is a function that is included in the program code of the application program which can be utilized to call the Java bytecode located at a particular location. Since the Java bytecode may be configured to accomplish any tasks, the functions of the application program can be extended by writing the desired tasks into the Java bytecode at any time after the development of the application program. In some embodiments, the predetermined code injection function specifies (504) a path for a file containing the Java bytecode in a local binary shared library. In some embodiments, the predetermined code injection function specifies (506) a path for downloading a file containing the Java bytecode from a remote server. In some embodiments, the path for the file can be dependent on one or more variable values at the time the code injection function is called during the target process, such that different Java bytecode files may be loaded for different execution conditions currently present for the target process.

In some embodiments, in response to the detected call to load the predetermined code injection function, the device loads (508) Java bytecode referenced by the code injection function into a virtual machine. In some embodiments, loading the Java bytecode referenced by the code injection function into the virtual machine further includes (510) : storing a system call number of the code injection function into a register of the target process； generating a system interrupt to enter a kernel mode； and loading the Java bytecode into the virtual machine while in the kernel mode. After the execution of the Java bytecode, the process returns to the interruption point, and the target process is resumed based on the system call number stored in the register.

In some embodiments, in accordance with a pre-stored Java native interface corresponding to the loaded Java bytecode, the device calls (512) an entrypoint function in the Java bytecode, wherein the entrypoint function is configured to perform one or more extended tasks for the application program. In some embodiments, in accordance with the pre-stored Java native interface corresponding to the loaded Java bytecode, calling the entrypoint function in the Java bytecode further includes (514) : identifying at least one global variable in the loaded Java bytecode in accordance with the pre-stored Java native interface； and initializing the at least one global variable, including calling the entrypoint function to initialize the at least one global variable.

In some embodiments, after the entrypoint function is called, the device executes (516) the entrypoint function in the virtual machine to accomplish the one or more extended tasks of the application program. In some embodiments, executing the entrypoint function further initializes the at least one global variable.

Other aspects of the method are described with respect to FIGS. 1-5.

In some embodiments, an apparatus for injecting Java bytecode into a target process in shown in FIG. 6. The apparatus includes: a local injection module 31 and Java bytecode loading module 32.

The local injection module 31 is configured to modify a register of the target process by using a system call provided by a host operating system, to load a binary shared library.

The Java bytecode loading module 32 is stored in the binary shared library, and is automatically executed as the binary shared library is loaded. The Java bytecode loading module 32 is configured to load a file including the Java bytecode in a specified path into a virtual machine, and calls an entrypoint function in the file including the Java bytecode. The Java bytecode includes a specific logic code, to implement a specific function.

For other details about the apparatus in this embodiment, reference may be further made to other parts of the present disclosure.

In some embodiments, an apparatus for injecting Java bytecode into a target process is shown in FIG. 7. The apparatus includes: a local injection module 41 and a . dex file loading module 42.

The local injection module 41 is configured to modify a register of the target process by using a system call provided by the Linux system, to load a binary shared library. For example, a register of the target process is modified by using a ptrace function, to call a dlopen function, and the binary shared library is loaded by using the dlopen function.

The . dex file loading module 42 is stored in the binary shared library, and is automatically executed as the binary shared library is loaded. A . dex file in a specified path is loaded into a DVM 224, and an entrypoint function in the loaded . dex file may be called by using a JNI 132. Thereby, instructions in the . dex file are executed, and these instructions in the . dex file may use various interfaces provided by an Android framework 226, so as to implement various functions that are based on the Android framework 226.

In accordance with some embodiments, a Java virtual machine is executed on a device 800, and the Java virtual machine facilitates the execution of Java bytecode on the device 800. Examples of device 800 include, but are not limited to, a handheld computer, a wearable computing device, a personal digital assistant (PDA) , a tablet computer, a laptop computer, a desktop computer, a cellular telephone, a smart phone, an enhanced general packet radio service (EGPRS) mobile phone, a media player, a navigation device, a game console, a television, a remote control, or a combination of any two or more of these data processing devices or other data processing devices. The device also includes an injection module 828, the injection module 828 injects Java bytecode to a target process executed in the Java virtual machine.

FIG. 8 is a block diagram illustrating a representative device 800 in accordance with some embodiments. Device 800, typically, includes one or more processing units (CPUs) 802, one or more network interfaces 804, memory 806, and one or more communication buses 808 for interconnecting these components (sometimes called a chipset) . Device 800 also includes a user interface 810. User interface 810 includes one or more output devices 812 that enable presentation of media content, including one or more speakers and/or one or more visual displays. User interface 810 also includes one or more input devices 814, including user interface components that facilitate user input such as a keyboard, a mouse, a voice-command input unit or microphone, a touch screen display, a touch-sensitive input pad, a gesture capturing camera, or other input buttons or controls. Furthermore, some devices 800 use a microphone and voice recognition or a camera and gesture recognition to supplement or replace the keyboard. Memory 806 includes high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid state memory devices； and, optionally, includes non-volatile memory, such as one or more magnetic disk storage devices, one or more optical disk storage devices, one or more flash memory devices, or one or more other non-volatile solid state storage devices. Memory 806, optionally, includes one or more storage devices remotely located from one or more processing units 802. Memory 806, or alternatively the non-volatile memory within memory 806, includes a non-transitory computer readable storage medium.

In some implementations, memory 806, or the non-transitory computer readable storage medium of memory 806, stores the following programs, modules, and data structures, or a subset or superset thereof:

o operating system 816 including procedures for handling various basic system services and for performing hardware dependent tasks；

o network communication module 818 for connecting device 800 to other computing devices (e.g., a server) connected to one or more networks 110 via one or more network interfaces 804 (wired or wireless) ；

o presentation module 820 for enabling presentation of information (e.g., a user interface for application (s) 826, widgets, websites and webpages thereof, and/or games, audio and/or video content, text, etc. ) at device 800 via one or more output devices 812 (e.g., displays, speakers, etc. ) associated with user interface 810；

o input processing module 822 for detecting one or more user inputs or interactions from one of the one or more input devices 814 and interpreting the detected input or interaction；

o Java virtual machine 824 for loading Java bytecode, converts the loaded Java bytecode to machine instructions, and executes the machine instructions；

o one or more applications 826 for execution by device 800 (e.g., games, application marketplaces, payment platforms, and/or other web or non-web based applications) ；

o injection module 828, which provides data processing and functionalities for the injecting Java bytecode to a target process of an application program； and

o library data 860, including one or more of, but not limited to:

· local binary shared library 862 storing bytecode files for implementing various extended functions；

· Java native interface library 864 storing Java native interfaces for injecting Javabyte code for various functions into a target process； and

· Java class library 866 storing Java class library files for various basic functions.

Each of the above identified elements may be stored in one or more of the previously mentioned memory devices, and corresponds to a set of instructions for performing a function described above. The above identified modules or programs (i.e., sets of instructions) need not be implemented as separate software programs, procedures, modules or data structures, and thus various subsets of these modules may be combined or otherwise re-arranged in various implementations. In some implementations, memory 806, optionally, stores a subset of the modules and data structures identified above. Furthermore, memory 806, optionally, stores additional modules and data structures not described above.

While particular embodiments are described above, it will be understood it is not intended to limit the invention to these particular embodiments. On the contrary, the invention includes alternatives, modifications and equivalents that are within the spirit and scope of the appended claims. Numerous specific details are set forth in order to provide a thorough understanding of the subject matter presented herein. But it will be apparent to one of ordinary skill in the art that the subject matter may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

Although some of the various drawings illustrate a number of logical stages in a particular order, stages that are not order dependent may be reordered and other stages may be combined or broken out. While some reordering or other groupings are specifically mentioned, others will be obvious to those of ordinary skill in the art and so do not present an exhaustive list of alternatives. Moreover, it should be recognized that the stages could be implemented in hardware, firmware, software or any combination thereof.

The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated.

Claims

A method of injecting Java bytecode into a target process of an application program, the method comprising:

at a device having one or more processors and memory:

during execution of the target process of the application program, detecting a call to load a predetermined code injection function；

in response to the detected call to load the predetermined code injection function, loading Java bytecode referenced by the code injection function into a virtual machine；

in accordance with a pre-stored Java native interface corresponding to the loaded Java bytecode, calling an entrypoint function in the Java bytecode, wherein the entrypoint function is configured to perform one or more extended tasks for the application program； and

executing the entrypoint function in the virtual machine to accomplish the one or more extended tasks of the application program.
The method of claim 1, wherein the predetermined code injection function specifies a path for a file containing the Java bytecode in a local binary shared library.
The method of claim 1, wherein the predetermined code injection function specifies a path for downloading a file containing the Java bytecode from a remote server.
The method of claim 1, wherein loading the Java bytecode referenced by the code injection function into the virtual machine further comprises:

storing a system call number of the code injection function into a register of the target process；

generating a system interrupt to enter a kernel mode； and

loading the Java byte code into the virtual machine while in the kernel mode.
The method of claim 1, wherein in accordance with the pre-stored Java native interface corresponding to the loaded Java bytecode, calling the entrypoint function in the Java bytecode further comprises:

identifying at least one global variable in the loaded Java bytecode in accordance with the pre-stored Java native interface； and

initializing the at least one global variable, including calling the entrypoint function to initialize the at least one global variable.
The method of claim 5, wherein executing the entrypoint function further initializes the at least one global variable.
The method of claim 1, wherein the virtual machine is a Velvik virtual machine and the device is an Android device.
A device, comprising:

one or more processors； and

memory having instructions stored thereon, the instructions, when executed by the one or more processors, cause the processors to perform operations comprising:

during execution of a target process of an application program, detecting a call to load a predetermined code injection function；

in response to the detected call to load the predetermined code injection function, loading Java bytecode referenced by the code injection function into a virtual machine；

in accordance with a pre-stored Java native interface corresponding to the loaded Java bytecode, calling an entrypoint function in the Java bytecode, wherein the entrypoint function is configured to perform one or more extended tasks for the application program； and

executing the entrypoint function in the virtual machine to accomplish the one or more extended tasks of the application program.
The device of claim 8, wherein the predetermined code injection function specifies a path for a file containing the Java bytecode in a local binary shared library.
The device of claim 8, wherein the predetermined code injection function specifies a path for downloading a file containing the Java bytecode from a remote server.
The device of claim 8, wherein loading the Java bytecode referenced by the code injection function into the virtual machine further comprises:

storing a system call number of the code injection function into a register of the target process；

generating a system interrupt to enter a kernel mode； and

loading the Java byte code into the virtual machine while in the kernel mode.
The device of claim 8, wherein in accordance with the pre-stored Java native interface corresponding to the loaded Java bytecode, calling the entrypoint function in the Java bytecode further comprises:

identifying at least one global variable in the loaded Java bytecode in accordance with the pre-stored Java native interface； and

initializing the at least one global variable, including calling the entrypoint function to initialize the at least one global variable.
The device of claim 12, wherein executing the entrypoint function further initializes the at least one global variable.
The device of claim 8, wherein the virtual machine is a Velvik virtual machine and the device is an Android device.
A non-transitory computer-readable medium having instructions stored thereon, the instructions, when executed by one or more processors, cause the processors to perform operations comprising:

during execution of a target process of an application program, detecting a call to load a predetermined code injection function；

in response to the detected call to load the predetermined code injection function, loading Java bytecode referenced by the code injection function into a virtual machine；

in accordance with a pre-stored Java native interface corresponding to the loaded Java bytecode, calling an entrypoint function in the Java bytecode, wherein the entrypoint function is configured to perform one or more extended tasks for the application program； and

executing the entrypoint function in the virtual machine to accomplish the one or more extended tasks of the application program.
The computer-readable medium of claim 15, wherein the predetermined code injection function specifies a path for a file containing the Java bytecode in a local binary shared library.
The computer-readable medium of claim 15, wherein the predetermined code injection function specifies a path for downloading a file containing the Java bytecode from a remote server.
The computer-readable medium of claim 15, wherein loading the Java bytecode referenced by the code injection function into the virtual machine further comprises:

storing a system call number of the code injection function into a register of the target process；

generating a system interrupt to enter a kernel mode； and

loading the Java byte code into the virtual machine while in the kernel mode.
The computer-readable medium of claim 15, wherein in accordance with the pre-stored Java native interface corresponding to the loaded Java bytecode, calling the entrypoint function in the Java bytecode further comprises:

identifying at least one global variable in the loaded Java bytecode in accordance with the pre-stored Java native interface； and

initializing the at least one global variable, including calling the entrypoint function to initialize the at least one global variable.
The computer-readable medium of claim 19, wherein executing the entrypoint function further initializes the at least one global variable.