CN113268280B - Method and device for dynamically loading plug-in and electronic equipment - Google Patents
Method and device for dynamically loading plug-in and electronic equipment Download PDFInfo
- Publication number
- CN113268280B CN113268280B CN202110548163.3A CN202110548163A CN113268280B CN 113268280 B CN113268280 B CN 113268280B CN 202110548163 A CN202110548163 A CN 202110548163A CN 113268280 B CN113268280 B CN 113268280B
- Authority
- CN
- China
- Prior art keywords
- plug
- data
- dexfile
- empty
- memory address
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
- G06F9/44526—Plug-ins; Add-ons
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The invention provides a method and a device for dynamically loading a plug-in and an electronic device, wherein the method comprises the following steps: in response to the running event of the target application, loading plug-in data at the specified position into a first memory address, and recording the first memory address in a cookie of the empty DexFile object in a manner of loading the empty DexFile object; and storing the empty DexFile object recorded with the first memory address into an element array of the class loader so as to call plug-in data when the class loader is started. The method and the device can solve the problem that the dynamic loading of the plug-ins can reduce the application running efficiency when the Android application runs, improve the efficiency of storing the plug-in data into the class loader, and can quickly load the plug-ins without influencing the application running.
Description
Technical Field
The present invention relates to the field of plug-in loading technologies, and in particular, to a method and an apparatus for dynamically loading a plug-in, and an electronic device.
Background
After the Android 5.0, a new Android running environment ART (Android Run Time) is used to replace the previous Dalvik running environment, the ART mechanism is different from the Dalvik mechanism, in the Dalvik virtual machine, the system source code file is libdvm.so, a Just-In-Time (JIT) scheme is adopted, namely byte codes are converted into machine codes through a Just-In-Time compiler when the application runs, and the compiling scheme can affect the running efficiency of the application; in the ART virtual machine, a system source code file is libart, and a scheme Of pre-compiling (AOT) is adopted, namely, when an application is installed for the first Time, a bytecode is compiled into a machine code in advance, and the compiling scheme can improve the running efficiency Of the application. Sometimes, in order to realize some specific functions, the application needs to dynamically call an external plug-in through an API (application programming interface), namely, a dynamic loading plug-in.
However, when an external plug-in is called through an API interface to perform dynamic loading, AOT compilation optimization of the system is also triggered, so that the loading is too slow, memory consumption is severe when the application runs, the running efficiency and smoothness of the whole application are affected, even the phenomena of application deadlock and the like occur, and the method is particularly obvious in low-version models with poor performance.
Disclosure of Invention
In view of this, an object of the present invention is to provide a method, an apparatus, and an electronic device for dynamically loading a plug-in, so as to alleviate a problem that the running efficiency of an application is reduced when the plug-in is dynamically loaded during an Android application running, improve the efficiency of storing plug-in data into a class loader, and enable the plug-in to be quickly loaded without affecting the running of the application.
In a first aspect, an embodiment of the present invention provides a method for dynamically loading a plug-in, where the method is applied to an electronic device equipped with an android system, the electronic device prestores an empty DexFile object and is equipped with a target application, a specified position corresponding to the target application stores plug-in data of the target application, and the empty DexFile object includes a data structure of a DexFile; the method comprises the following steps: responding to the running event of the target application, loading the plug-in data of the specified position into a first memory address, and recording the first memory address in a cookie of the empty DexFile object in a manner of loading the empty DexFile object; and storing the empty DexFile object recorded with the first memory address into an element array of a class loader so as to call the plug-in data when the class loader is started.
With reference to the first aspect, this embodiment provides a first possible implementation manner of the first aspect, where the step of loading the plug-in data at the specified location into a first memory address and recording the first memory address in a cookie of the empty DexFile object in a manner of loading the empty DexFile object includes: loading the plug-in data at the designated position into a first memory address through a first sub thread corresponding to the main thread of the target application; loading the empty DexFile object in a second memory address through a second sub-thread corresponding to the main thread; when the first sub thread and the second sub thread are finished, obtaining the cookie of the plug-in data through the main thread, and replacing the cookie in the empty DexFile object with the cookie of the plug-in data; the first memory address is recorded in the cookie of the plug-in data.
With reference to the first possible implementation manner of the first aspect, this embodiment provides a second possible implementation manner of the first aspect, where a system libart.
With reference to the first aspect, this embodiment provides a third possible implementation manner of the first aspect, where a system libart.so in the android system prohibits the target application from accessing through a dlopen function, and a hook breakpoint is preset in a specified function of the system libart.so; loading the plug-in data of the specified position into a first memory address, and recording the first memory address in a cookie of the empty DexFile object in a manner of loading the empty DexFile object, wherein the step comprises the following steps: loading the plug-in data at the specified position into a first memory address through the main thread of the target application; and calling a loader of the DexFile through the main thread to load the empty DexFile object, acquiring the first memory address through a hook breakpoint in a specified function of libart.
With reference to the third possible implementation manner of the first aspect, this embodiment provides a fourth possible implementation manner of the first aspect, where the specified function includes an open function and a mmap function; in the process of loading the empty DexFile object, the step of acquiring the first memory address through a hook breakpoint in a specified function of libart. And acquiring path information of the empty DexFile object through an open function, detecting whether the path information is a storage path of the empty DexFile object, calling a mmap function to apply for a memory space for the empty DexFile object if the path information is the storage path of the empty DexFile object, and returning the first memory address to the mmap function.
With reference to the fourth possible implementation manner of the first aspect, this embodiment provides a fifth possible implementation manner of the first aspect, where the specifying function further includes: a fork function; the method further comprises the following steps: the AOT optimization process is interrupted by the fork function.
With reference to the first aspect, this embodiment provides a sixth possible implementation manner of the first aspect, where the method further includes: converting data corresponding to the plug-in data source codes into pixel data of the picture according to a preset conversion rule to obtain a plug-in data picture; and storing the plug-in data picture as encrypted plug-in data to a specified position of the electronic equipment.
With reference to the sixth possible implementation manner of the first aspect, this embodiment provides a seventh possible implementation manner of the first aspect, where before the step of loading the plug-in data in the specified location into the memory, the method further includes: and carrying out the reverse conversion operation of the preset conversion rule on the plug-in data picture to obtain the decrypted plug-in data.
With reference to the first aspect, this embodiment provides an eighth possible implementation manner of the first aspect, where the specified location is a tail location of a specified file of the target application or a specified directory of the target application.
In a second aspect, an embodiment of the present invention further provides a device for dynamically loading a plug-in, where the device is applied to an electronic device equipped with an android system, the electronic device prestores an empty DexFile object and is equipped with a target application, a specified position corresponding to the target application stores plug-in data of the target application, and the empty DexFile object includes a data structure of a DexFile; the device comprises: the processing module is used for responding to the running event of the target application, loading the plug-in data of the specified position into a first memory address, and recording the first memory address in the cookie of the empty DexFile object in a mode of loading the empty DexFile object; the storage module is used for storing the empty DexFile object recorded with the first memory address into an element array of a class loader so as to call the plug-in data when the class loader is started.
In a third aspect, an embodiment of the present invention further provides an electronic device, including a processor and a memory, where the memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the method for dynamically loading a plug-in according to any one of the foregoing embodiments.
In a fourth aspect, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions that, when invoked and executed by a processor, cause the processor to implement a method for dynamically loading a plug-in as in any one of the preceding embodiments.
The embodiment of the invention has the following beneficial effects:
according to the method, the device and the electronic equipment for dynamically loading the plug-ins, provided by the embodiment of the invention, the plug-in data at the designated position is loaded into the first memory address in response to the running event of the target application, and the first memory address is recorded in the cookie of the empty DexFile object in a manner of loading the empty DexFile object; and storing the empty DexFile object recorded with the first memory address into an element array of the class loader so as to call plug-in data when the class loader is started. By adopting the technology, when the application runs, the memory address of the plug-in data is recorded in the empty DexFile object of the data structure containing the DexFile, the memory address of the plug-in data can be directly obtained by reading the empty DexFile object, and the empty DexFile object has the characteristic of small memory occupation, so that the acquisition efficiency of the plug-in data is improved, and the overall efficiency of the dynamic plug-in loading process is further improved; the empty DexFile object recorded with the memory address of the plug-in data is stored in a local class loader, the plug-in data can be directly called when the class loader is started, the plug-in data can be acquired without depending on a network environment, the safety of the plug-in data can be improved, and the stability of the loading efficiency can be ensured.
Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.
In order to make the aforementioned and other objects, features and advantages of the present invention comprehensible, preferred embodiments accompanied with figures are described in detail below.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and other drawings can be obtained by those skilled in the art without creative efforts.
Fig. 1 is a schematic flowchart of a method for dynamically loading a plug-in according to an embodiment of the present invention;
fig. 2 is a schematic flowchart of another method for dynamically loading a plug-in according to an embodiment of the present invention;
fig. 3 is a schematic flowchart of another method for dynamically loading a plug-in according to an embodiment of the present invention;
FIG. 4 is a schematic diagram of two storage manners of plug-in data according to an embodiment of the present invention;
fig. 5 is a schematic diagram of the method for dynamically loading a plug-in, provided by the embodiment of the present invention, applied to different android systems;
fig. 6 is a schematic structural diagram of an apparatus for dynamically loading a plug-in according to an embodiment of the present invention;
fig. 7 is a schematic structural diagram of another apparatus for dynamically loading a plug-in according to an embodiment of the present invention;
fig. 8 is a schematic structural diagram of an electronic device according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the embodiments, and it is obvious that the described embodiments are some, but not all embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
Considering that when a plug-in is loaded, if AOT compiling optimization of a system is triggered, the loading is too slow, memory consumption is serious when the plug-in is operated, and the operation efficiency and the smoothness of the whole application are affected, the method, the device and the electronic equipment for dynamically loading the plug-in are implemented to optimize the process of dynamically loading the plug-in and improve the loading efficiency of the plug-in and the operation performance of the equipment.
To facilitate understanding of the embodiment, first, a method for dynamically loading a plug-in disclosed in the embodiment of the present invention is described in detail, referring to a flowchart of the method for dynamically loading a plug-in shown in fig. 1, where the method may be applied to an electronic device installed with an android system, and the electronic device may be a device such as an intelligent terminal, a computer, a mobile phone, and the like. The electronic equipment prestores an empty DexFile object and is provided with a target application, and the specified position corresponding to the target application stores plug-in data of the target application; the method may comprise the steps of:
step S102, responding to the running event of the target application, loading the plug-in data of the specified position into the first memory address, and recording the first memory address in the cookie of the empty DexFile object in a manner of loading the empty DexFile object.
Specifically, when a user needs to use some specific functions of an application, the application needs to dynamically call a plug-in (i.e., a dynamic loading plug-in) stored at a designated location corresponding to the application through an API interface to implement the specific functions, define the application as a target application, and define data of the plug-in as plug-in data of the target application. The empty DexFile object is defined as an empty dex file created at the upper layer, the empty dex file only has a file structure (namely, a data structure of DexFile) and no file data, and the file size of the empty DexFile object is less than 1kb. When the target application starts running, in response to a running event of the target application, firstly, directly loading plug-in data stored in a specified position corresponding to the target application into a local memory by calling a bottom-layer source code, and defining the address of the plug-in data in the local memory as a first memory address. By this operation, the plug-in data of the specified location is loaded into the first memory address. When the empty DexFile object is loaded to the specified memory address of the local memory by calling an API (application program interface), the first memory address is written into the cookie of the empty DexFile object, and then the first memory address is associated in the empty DexFile object, so that the first memory address is recorded in the cookie of the empty DexFile object. The recording manner of the first memory address in the cookie of the empty DexFile object is not limited herein.
Step S104, the empty DexFile object recorded with the first memory address is saved in an element array of the class loader, so that the plug-in data is called when the class loader is started.
Specifically, the empty DexFile object is stored in Elements (i.e., an element array) of a ClassLoader (i.e., a class loader), so that when the class loader is started, the memory address of the plug-in data can be directly obtained by reading the empty DexFile object, and the plug-in data is called.
In the method for dynamically loading the plug-in, the plug-in data at the specified position is loaded into a first memory address in response to the running event of the target application, and the first memory address is recorded in the cookie of the empty DexFile object in a manner of loading the empty DexFile object; and storing the empty DexFile object recorded with the first memory address into an element array of the class loader so as to call plug-in data when the class loader is started. By adopting the technology, when the application runs, the memory address of the plug-in data is recorded in the empty DexFile object of the data structure containing the DexFile, the memory address of the plug-in data can be directly obtained by reading the empty DexFile object, and the empty DexFile object has the characteristic of small memory occupation, so that the acquisition efficiency of the plug-in data is improved, and the overall efficiency of the dynamic plug-in loading process is further improved; the empty DexFile object recorded with the memory address of the plug-in data is stored in a local class loader, the plug-in data can be directly called when the class loader is started, the plug-in data can be acquired without depending on a network environment, the safety of the plug-in data can be improved, and the stability of the loading efficiency can be ensured.
On the basis of the method for dynamically loading the plug-in, referring to fig. 2, taking an Android system as a first type of Android system (for example, the Android system is a model of Android 5.0-7.0), an embodiment of the present invention further provides another method for dynamically loading the plug-in, where the method may include the following steps:
step S202, in response to the running event of the target application, loading the plug-in data at the designated location to the first memory address through the first sub-thread corresponding to the main thread of the target application.
Specifically, when the target application starts running, a process is created, and a main thread exists in the process, and the main thread is used for realizing basic functions (such as page display, various animations and the like) of the target application. In the main thread, a plurality of sub-threads can be started to respectively execute different task flows, and the start-stop time of each sub-thread runs through the whole main thread, namely: the child thread will return to the main thread after the child thread is finished. In response to a running event of the target application, a sub-thread (i.e., a first sub-thread) is first started in a main thread of the target application, and plug-in data of a specified location is loaded into a specified address (i.e., a first memory address) in the local memory through the first sub-thread.
Step S204, loading the empty DexFile object in the second memory address through the second sub-thread corresponding to the main thread.
Specifically, in the main thread of the target application, when the first sub-thread is started, another sub-thread (i.e., a second sub-thread) is also started, and the second sub-thread can load the empty DexFile object into a specified address (i.e., a second memory address) in the local memory.
Step S206, when the first sub thread and the second sub thread are finished, obtaining the cookie of the plug-in data through the main thread, and replacing the cookie in the empty DexFile object with the cookie of the plug-in data; the cookie of the plug-in data records a first memory address.
Step S208, the empty DexFile object recorded with the first memory address is saved in the element array of the class loader, so as to call the plug-in data when the class loader is started.
The following operation modes may be specifically adopted in the steps S202 to S208:
(1) Creating an empty DexFile object in advance;
(2) When a target application starts to run, responding to a running event of the target application, firstly starting a sub-thread (namely a first sub-thread) in a main thread of the target application, calling a dlopen function to open a system source code libart.so, returning a handle, then calling a dlsym function to acquire an address of an openMemory function derived symbol through the handle, constructing parameters required by the openMemory function, calling the openMemory function to load plug-in data to a specified memory address (namely a first memory address) in a local memory, and generating a cookie of the plug-in data after the loading is finished; wherein, the cookie records a first memory address.
(3) While the first sub-thread is carried out, another sub-thread (namely a second sub-thread) is started in a main thread of the target application, the empty DexFile object is loaded to a specified memory address (namely a second memory address) of a local memory by calling an API (application programming interface), and a cookie of the empty DexFile object is generated after the empty DexFile object is loaded; wherein, the cookie records a second memory address.
(4) And returning to the main thread after the first sub-thread and the second sub-thread are finished, reflecting and calling the cookie of the plug-in data through JNI, replacing the cookie of the empty DexFile object with the cookie of the plug-in data, and associating the empty DexFile object with the cookie of the plug-in data, namely establishing the association relationship between the empty DexFile object and the first memory address loaded with the plug-in data.
(5) And then, storing the empty DexFile object associated with the cookie of the plug-in data in Elements (element arrays) of a ClassLoader (class loader), so that the memory address of the plug-in data can be directly obtained by reading the empty DexFile object when the class loader is started, and the plug-in data is called.
And the system source code file libart in the first type of android system allows the target application to access through a dlopen function.
In the method for dynamically loading the plug-in, when the application runs, the data of the plug-in is loaded through a first sub-thread corresponding to a main thread, an empty DexFile object is loaded through a second sub-thread corresponding to the main thread, then the main thread is returned to obtain the cookie of the plug-in data, and the cookie of the empty DexFile object is replaced by the cookie of the plug-in data, so that the association relationship between the empty DexFile object and the memory address of the plug-in data is established, multithreading is carried out simultaneously, and the overall efficiency of the process of dynamically loading the plug-in can be improved compared with the mode of dynamically loading the plug-in by adopting a single thread; the memory address of the plug-in data can be directly obtained by reading the empty DexFile object, and the empty DexFile object has the characteristic of small memory occupation, so that the acquisition efficiency of the plug-in data is improved, and the overall efficiency of the dynamic plug-in loading process is further improved; the empty DexFile object recorded with the memory address of the plug-in data is stored in a local class loader, the plug-in data can be directly called when the class loader is started, the plug-in data can be acquired without depending on a network environment, the safety of the plug-in data can be improved, and the stability of the loading efficiency can be ensured.
On the basis of the method for dynamically loading the plug-in, as shown in fig. 3, taking an Android system as a second type of Android system (for example, the Android system is a model of Android 7.0-8.0), an embodiment of the present invention further provides another method for dynamically loading the plug-in, where a system source code file libart.so in the second type of Android system prohibits a target application from accessing through a dlopen function, and a hook breakpoint is preset in a specified function of libart.so; the method may comprise the steps of:
step S302, in response to the running event of the target application, loading the plug-in data at the specified location into the first memory address through the main thread of the target application.
Step S304, calling a loader of the DexFile through the main thread to load an empty DexFile object, acquiring a first memory address through a hook breakpoint in a designated function of libart.
For example, the above-mentioned specified functions may include an open function and a mmap function; the path information of the empty DexFile object can be obtained through an open function, whether the path information is the storage path of the empty DexFile object or not is detected, if yes, a mmap function is called to apply for a memory space for the empty DexFile object, and a first memory address is returned to the mmap function. In an actual operation process, in order to return the first memory address to the mmap function, a return value of the mmap function can be modified into the first memory address through a hook breakpoint in the mmap function.
Step S306, the empty DexFile object recorded with the first memory address is saved in the element array of the class loader, so as to call the plug-in data when the class loader is started.
A method for dynamically loading a plug-in shown in fig. 3 is described in a specific application scenario, where a specified function of libart.so includes an open function, a read function, a write function, a mmap function, a munmap function, a fstat function, and a fork function, and hook breakpoints are preset for these functions, and the method specifically adopts the following operation modes:
(1) After a hook breakpoint is preset for the designated function, an empty DexFile object is pre-created on the upper layer, when the target application starts to run, in response to a running event of the target application, an open function is called through a main thread of the target application to open a local file, an incoming parameter is path information for opening the file, and whether the path information is a storage path of the empty DexFile object is detected; if so, judging that the file is an empty DexFile object, recording the local opening operation, and determining the operation after the local opening operation as the memory operation performed on the empty DexFile object.
(2) Calling a read function to read data (such as file header information and the like) of the empty DexFile object which is opened, wherein incoming parameters of the read function comprise descriptors of the empty DexFile object; the path information of the empty DexFile object can be further obtained by calling a readlink function.
(3) Calling a mmap function to apply for a memory space for a file stored locally, wherein incoming parameters of the mmap function comprise a descriptor of the file; judging whether the file is the empty DexFile object or not according to the data (such as file header information and the like) of the empty DexFile object and the incoming parameters of the mmap function, if so, preventing the mmap function from applying for a memory space through a hook breakpoint in the mmap function, and directly returning the memory address of the plug-in data to the mmap function, wherein the process can generate a cookie of the empty DexFile object, and the memory address of the plug-in data can be recorded in the cookie of the empty DexFile object. In addition, since the size of the file is required to be obtained when the mmap function is called to apply for the memory, so as to ensure that the applied memory space is not smaller than the size of the file, the fstat function can be called to obtain the size of the file while the mmap function is called, wherein the incoming parameter of the fstat function comprises the file descriptor; judging whether the size of the applied memory is correspondingly consistent with the size of the empty DexFile object or not according to the data (such as file header information and the like) of the empty DexFile object and the transmitted parameters of the fstat function; if so, the size of the file is prevented from being known by the fstat function through a hook breakpoint in the fstat function, the memory size of the plug-in data is directly returned to the fstat function, and the memory size of the plug-in data is also recorded in a cookie of the empty DexFile object. At this time, the process may be regarded as replacing the cookie (empty cookie) of the empty DexFile object with the cookie (cookie in which the memory address and the memory size of the plug-in data are recorded) of the plug-in data, so that the association relationship between the empty DexFile object and the memory address of the plug-in data is established.
(4) Considering that AOT optimization usually requires calling a fork function to start a new process for execution, this embodiment may also prevent the process of AOT optimization from being executed through a hook breakpoint corresponding to the fork function.
(5) Calling a Munmap function to release the memory, wherein incoming parameters of the Munmap function carry the initial file address and the file size of the plug-in data, and whether the address of the Munmap function release memory corresponds to the memory address of the plug-in data or not can be judged according to the initial file address and the file size of the plug-in data; if so, the release of the memory operation is prevented by a hook breakpoint in the munmap function. The operation mode can ensure that the incidence relation between the empty DexFile object and the memory address of the plug-in data cannot be damaged in the memory releasing stage, and further ensures the reliability of the incidence relation.
(6) And calling a MakeDexElements function, and loading the empty DexFile object to a class loader ClassLoader to realize the whole loading process.
In the method for dynamically loading the plug-in, when the application runs, the breakpoint under the file memory operation function of the system source code is intercepted through a hook interception technology, and when the incidence relation between the empty DexFile object and the memory address of the plug-in data is established, the plug-in data only needs to be loaded into the local memory without loading the empty DexFile object into the memory, so that the accuracy of the plug-in loading result is ensured, and the overall efficiency of the process of dynamically loading the plug-in is improved; the memory address of the plug-in data can be directly obtained by reading the empty DexFile object, and the empty DexFile object has the characteristic of small memory occupation, so that the acquisition efficiency of the plug-in data is improved, and the overall efficiency of the dynamic plug-in loading process is further improved; the empty DexFile object recorded with the memory address of the plug-in data is stored in a local class loader, the plug-in data can be directly called only once when the class loader is started, the plug-in data can be obtained without depending on a network environment, the safety of the plug-in data can be improved, and the stability of the loading efficiency can be ensured.
On the basis of the method for dynamically loading the plug-in, in order to improve the safety of plug-in loading, the plug-in to be loaded is encrypted, and the operation mode of encryption processing can adopt the following steps:
step 1, converting data corresponding to the plug-in data source code into pixel data of a picture according to a preset conversion rule to obtain a plug-in data picture.
Specifically, the data of the plug-in to be loaded is encapsulated according to a custom file structure (the custom file structure includes file header information, each data area, and an offset address of each data area relative to the file header information), and the step 1 is executed after the encapsulation is completed. For example, binary data corresponding to the plug-in data source code may be encrypted and converted into pixel data of the png picture according to a preset conversion rule, and the pixel data together constitute the plug-in data picture.
And 2, storing the plug-in data picture as the encrypted plug-in data to the appointed position of the electronic equipment.
For the encrypted plug-in data, the following two storage methods can be adopted:
in the first storage mode, the encrypted plug-in data is stored to the tail position of the specified file of the target application. For example, writing the data of the encrypted plug-in to the end of a specified file (such as a dex file of an apk file) of a target application in the form of binary data, and recording offset information (namely the initial writing position of the binary data and the number of bits occupied by the binary data); by the operation mode, the application can acquire the data stream of the encrypted plug-in according to the offset information of the encrypted plug-in data during running, and further decrypt the plug-in and execute the subsequent operation process of plug-in loading.
If the encrypted plug-in data is stored by adopting the first storage mode, when an application runs, firstly, an absolute path of an apk file corresponding to a target application in a current system is determined by scanning a memory mapping file maps of an android system, then, the apk file is decompressed to obtain a dex file, the structure of the dex file is analyzed, the head signature information of the dex file is verified, and the data structure of the dex file is prevented from being artificially modified and damaged.
And the second storage mode is to store the encrypted plug-in data into the specified directory of the target application. For example, the data of the encrypted plug-in can be stored under the assets directory in the android system; through the operation mode, when the target application runs, the AssetManager function can be called through the API interface to directly read the data stream of the encrypted plug-in, and then the plug-in is decrypted and the operation process of subsequent plug-in loading is executed.
Referring to fig. 4, the foregoing steps 1 to 2 are described in a specific application scenario.
In fig. 4, firstly, data of a plug-in to be loaded is encapsulated according to a custom file structure according to actual needs, where the custom file structure includes file header information, a data area 1, a data area 2, and offset addresses (referred to as offset addresses for short) of the data areas relative to the file header information, and after encapsulation is completed, the data of the plug-in is encrypted by using a symmetric encryption algorithm, where the symmetric encryption algorithm may use the operation mode of step 1 above, or may use other encryption algorithms in the prior art, and is not limited herein; for the encrypted plug-in data, the two different storage modes can be adopted for storage according to actual needs, and if the first storage mode is adopted, the encrypted plug-in data can be added in an application source code class.dex in a binary form for hiding; if the second storage mode is adopted, the encrypted data of the plug-in can be stored in the assets directory in the android system.
Based on the above steps 1 to 2, before the step of loading the plug-in data at the designated position into the memory, the plug-in data picture needs to be decrypted, and an operation mode of the decryption corresponds to an encryption mode, which may specifically be: and performing reverse conversion operation of the preset conversion rule on the plug-in data picture to obtain decrypted plug-in data.
On the basis of the method for dynamically loading the plug-in, the operation process of dynamically loading the plug-in is described for a model with an Android system below Android 5.0, and the specific operation process is as follows:
an empty DexFile object is created in advance on the upper layer of an application, when the target application starts running, in response to a running event of the target application, a sub-thread (namely a first sub-thread) is started in a main thread of the target application, a dlopen function is called to open a system source code libdvm.so, a handle is returned, then a dlsym function is called to obtain that the parameter of the openDexFile function is the address of a derived symbol of a byte array through the handle, the parameter required by the openDexFile function is constructed, then the openDexFile function is called to load plug-in data to a specified memory address (namely a first memory address) in a local memory, and a cookie of the plug-in data is generated after the plug-in data is loaded; wherein, the cookie records a first memory address. While the first sub-thread is carried out, another sub-thread (namely a second sub-thread) is started in the main thread of the target application, the empty DexFile object is loaded to a specified memory address (namely a second memory address) of a local memory by calling an API (application programming interface), and a cookie of the empty DexFile object is generated after the loading is finished; wherein, the cookie records a second memory address. And returning to the main thread after the first sub-thread and the second sub-thread are finished, reflecting and calling the cookie of the plug-in data through JNI, replacing the cookie of the empty DexFile object with the cookie of the plug-in data, and associating the empty DexFile object with the cookie of the plug-in data, namely establishing the association relationship between the empty DexFile object and the first memory address loaded with the plug-in data. And then, storing the empty DexFile object associated with the cookie of the plug-in data in Elements (element arrays) of a ClassLoader (class loader), so that the memory address of the plug-in data can be directly obtained by reading the empty DexFile object when the class loader is started, and the plug-in data is called.
In addition, for the Android system which is a model above Android 8.0, a class loader InMemoryDexClassLoader is introduced into the Android system, and the working process of the class loader InMemoryDexClassLoader is similar to that of the class loader ClassLoader, which is not described herein again. Because a makeinmemorydexellents function exists in the source code of the android system, the function can be called through JNI reflection, plug-in source codes can be directly loaded in the memory, and the source codes are placed in the classLoader of the system. Therefore, the Android system is a model with Android being more than 8.0, and the operation process of replacing the cookie of the empty DexFile object with the cookie of the plug-in data does not exist when the plug-in is dynamically loaded.
For convenience of description, the above methods for dynamically loading plug-ins applied to different android systems are compared here, and as shown in fig. 5, for a plug-in that has been encrypted by a symmetric encryption algorithm, when a target application runs, the plug-in is first decrypted by using the symmetric algorithm and data of the plug-in is obtained, and then different android systems execute different plug-in dynamic loading processes:
(1) For a model with an Android system below Android 5.0, an openDexFile function needs to be called to load plug-in data to a specified memory address in a local memory, a cookie replacing process is performed (namely cookies for calling the plug-in data are reflected through JNI, cookies for an empty DexFile object are replaced by cookies for the plug-in data), and then the empty DexFile object is stored in a class loader so as to call the plug-in data when the class loader is started.
(2) For a model with an Android system of 5.0-7.0, an openMemory function is required to be called to load plug-in data to a specified memory address in a local memory, a cookie replacing process is carried out (namely cookies for calling the plug-in data are reflected through JNI, cookies for an empty DexFile object are replaced by cookies for the plug-in data), and then the empty DexFile object is stored in a class loader so as to call the plug-in data when the class loader is started.
(3) For a model with an Android system of Android 7.0-8.0, a hook breakpoint needs to be set for a specified function of a system source code file by using a hook interception technology, then the specified function with the hook breakpoint is called to replace a cookie process (a null DexFile object does not need to be loaded into a memory), and then the null DexFile object (the memory address and the memory size of plug-in data are recorded in the cookie of the null DexFile object) is stored in a class loader so as to call the plug-in data when the class loader is started.
(4) And for the Android system of a model with the Android system more than 8.0, calling a makeInMemoryDexElements function through JNI reflection to directly load the plug-in data to a specified memory address in a local memory, and storing the plug-in data in a class loader so as to call the plug-in data when the class loader is started.
Through the comparative analysis, the following results can be found: due to the fact that different Android systems have different source code designs, the Android system is a cookie replacing process when plug-in dynamic loading is carried out on the machine types below Android 8.0, and the Android system is a cookie replacing process when plug-in dynamic loading is carried out on the machine types above Android 8.0. Therefore, the method for dynamically loading the plug-in provided by the embodiment can be correspondingly adjusted according to different android systems, and has better universality for different android systems.
Based on the above method embodiment, an embodiment of the present invention further provides a device for dynamically loading a plug-in, as shown in fig. 6, where the device includes the following modules:
a processing module 62, configured to respond to an operation event of the target application, load the plug-in data at the specified location into a first memory address, and record the first memory address in a cookie of the empty DexFile object in a manner of loading the empty DexFile object;
a saving module 64, configured to save the empty DexFile object recorded with the first memory address into an element array of a class loader, so as to call the plug-in data when the class loader is started.
In the device for dynamically loading the plug-ins, in response to an operation event of a target application, plug-in data at a specified position is loaded into a first memory address, and the first memory address is recorded in a cookie of the empty DexFile object in a manner of loading the empty DexFile object; and storing the empty DexFile object recorded with the first memory address into an element array of the class loader so as to call plug-in data when the class loader is started. By adopting the technology, when the application runs, the memory address of the plug-in data is recorded in the empty DexFile object of the data structure containing the DexFile, the memory address of the plug-in data can be directly obtained by reading the empty DexFile object, and the empty DexFile object has the characteristic of small memory occupation, so that the acquisition efficiency of the plug-in data is improved, and the overall efficiency of the dynamic plug-in loading process is further improved; the empty DexFile object recorded with the memory address of the plug-in data is stored in a local class loader, the plug-in data can be directly called when the class loader is started, the plug-in data can be acquired without depending on a network environment, the safety of the plug-in data can be improved, and the stability of the loading efficiency can be ensured.
So if the system libart in the android system allows the target application to access through a dlopen function, the processing module 62 is further configured to: loading the plug-in data at the designated position into a first memory address through a first sub thread corresponding to the main thread of the target application; loading the empty DexFile object in a second memory address through a second sub-thread corresponding to the main thread; when the first sub thread and the second sub thread are finished, obtaining a cookie file of the plug-in data through the main thread, and replacing the cookie in the empty DexFile object with the cookie of the plug-in data; the first memory address is recorded in the cookie of the plug-in data.
If the system libart.so in the android system prohibits the target application from accessing through a dlopen function, and a hook breakpoint is preset in a specified function of the system libart.so, the processing module 62 is further configured to: loading the plug-in data of the specified position into a first memory address through the main thread of the target application; and calling a loader of the DexFile through the main thread to load the empty DexFile object, acquiring the first memory address through a hook breakpoint in a specified function of libart.
The specified functions comprise an open function and a mmap function; the processing module 62 is further configured to: and acquiring path information of the empty DexFile object through an open function, detecting whether the path information is a storage path of the empty DexFile object, calling a mmap function to apply for a memory space for the empty DexFile object if the path information is the storage path of the empty DexFile object, and returning the first memory address to the mmap function. Based on this, the above-mentioned specified function further includes: a fork function; the processing module 62 is further configured to: the AOT optimization process is interrupted by the fork function.
Referring to fig. 7, on the basis of the apparatus shown in fig. 6, an embodiment of the present invention further provides another apparatus for dynamically loading a plug-in, where the apparatus further includes: the encryption module 66 is configured to convert data corresponding to the plug-in data source code into pixel data of a picture according to a preset conversion rule, so as to obtain a plug-in data picture; and the storage module 68 is configured to store the plug-in data picture as encrypted plug-in data to a specified location of the electronic device. Based on this, the apparatus further comprises: and the decryption module 70 is configured to perform an inverse transformation operation of the preset transformation rule on the plug-in data picture to obtain decrypted plug-in data.
The device provided by the embodiment of the present invention has the same implementation principle and technical effect as the method embodiments, and for the sake of brief description, reference may be made to the corresponding contents in the method embodiments without reference to the device embodiments.
The embodiment of the invention provides electronic equipment, which particularly comprises a processor and a storage device; the storage means has stored thereon a computer program which, when executed by the processor, performs the method of dynamically loading a plug-in as described in any of the above embodiments.
Fig. 8 is a schematic structural diagram of an electronic device 100 according to an embodiment of the present invention, where the electronic device 100 includes: the device comprises a processor 80, a memory 81, a bus 82 and a communication interface 83, wherein the processor 80, the communication interface 83 and the memory 81 are connected through the bus 82; the processor 80 is arranged to execute executable modules, such as computer programs, stored in the memory 81.
The Memory 81 may include a high-speed Random Access Memory (RAM) and may also include a non-volatile Memory (non-volatile Memory), such as at least one disk Memory. The communication connection between the network element of the system and at least one other network element is realized through at least one communication interface 83 (which may be wired or wireless), and the internet, a wide area network, a local network, a metropolitan area network, etc. may be used.
Bus 82 may be an ISA bus, PCI bus, EISA bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one double-headed arrow is shown in FIG. 8, but that does not indicate only one bus or one type of bus.
The memory 81 is used for storing a program, the processor 80 executes the program after receiving an execution instruction, and the method executed by the apparatus defined by the flow process disclosed in any of the foregoing embodiments of the present invention may be applied to the processor 80, or implemented by the processor 80.
The processor 80 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware or instructions in the form of software in the processor 80. The Processor 80 may be a general-purpose Processor, and includes a Central Processing Unit (CPU), a Network Processor (NP), and the like; the device can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components. The various methods, steps and logic blocks disclosed in the embodiments of the present invention may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method for dynamically loading the plug-in disclosed by the embodiment of the invention can be directly embodied as the execution of a hardware decoding processor, or the combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in the memory 81, and the processor 80 reads the information in the memory 81 and completes the steps of the above-mentioned method for dynamically loading the plug-in combination with the hardware thereof.
The computer program product of the readable storage medium provided in the embodiment of the present invention includes a computer readable storage medium storing a program code, where instructions included in the program code may be used to execute the method for dynamically loading a plug-in the foregoing method embodiment, and specific implementation may refer to the foregoing method embodiment, and is not described herein again.
The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention or a part thereof which substantially contributes to the prior art may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
Finally, it should be noted that: the above-mentioned embodiments are only specific embodiments of the present invention, which are used for illustrating the technical solutions of the present invention and not for limiting the same, and the protection scope of the present invention is not limited thereto, although the present invention is described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: any person skilled in the art can modify or easily conceive the technical solutions described in the foregoing embodiments or equivalent substitutes for some technical features within the technical scope of the present disclosure; such modifications, changes or substitutions do not depart from the spirit and scope of the embodiments of the present invention, and they should be construed as being included therein. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.
Claims (10)
1. A method for dynamically loading plug-ins is characterized by being applied to electronic equipment provided with an android system, wherein an empty DexFile object is prestored in the electronic equipment and is provided with a target application, plug-in data of the target application is stored in a specified position corresponding to the target application, and the empty DexFile object comprises a data structure of a DexFile; the method comprises the following steps:
responding to the running event of the target application, loading the plug-in data of the specified position into a first memory address, and recording the first memory address in a cookie of the empty DexFile object in a manner of loading the empty DexFile object;
storing the empty DexFile object recorded with the first memory address into an element array of a class loader so as to call the plug-in data when the class loader is started;
if the system libart in the android system allows the target application to access through a dlopen function, loading the plug-in data of the specified position into a first memory address, and recording the first memory address in a cookie of the empty DexFile object in a manner of loading the empty DexFile object, wherein the step comprises the following steps:
loading the plug-in data at the designated position into a first memory address through a first sub thread corresponding to the main thread of the target application; loading the empty DexFile object in a second memory address through a second sub-thread corresponding to the main thread; when the first sub thread and the second sub thread are finished, obtaining the cookie of the plug-in data through the main thread, and replacing the cookie in the empty DexFile object with the cookie of the plug-in data; the first memory address is recorded in the cookie of the plug-in data.
2. The method according to claim 1, wherein a system libart. So in the android system prohibits the target application from being accessed through a dlopen function, and a hook breakpoint is preset in a specified function of the system libart. So;
loading the plug-in data of the specified position into a first memory address, and recording the first memory address in a cookie of the empty DexFile object in a manner of loading the empty DexFile object, wherein the step comprises the following steps:
loading the plug-in data of the specified position into a first memory address through the main thread of the target application;
and calling a loader of the DexFile through the main thread to load the empty DexFile object, acquiring the first memory address through a hook breakpoint in a specified function of libart.
3. The method of claim 2, wherein the specified functions include an open function and a mmap function;
in the process of loading the empty DexFile object, the step of obtaining the first memory address through a hook breakpoint in a specified function of libart.
And acquiring path information of the empty DexFile object through an open function, detecting whether the path information is a storage path of the empty DexFile object, calling a mmap function to apply for a memory space for the empty DexFile object if the path information is the storage path of the empty DexFile object, and returning the first memory address to the mmap function.
4. The method of claim 3, wherein the specifying a function further comprises: a fork function; the method further comprises the following steps: the AOT optimization process is interrupted by the fork function.
5. The method of claim 1, further comprising:
converting data corresponding to the plug-in data source codes into pixel data of the picture according to a preset conversion rule to obtain a plug-in data picture;
and storing the plug-in data picture as encrypted plug-in data to a specified position of the electronic equipment.
6. The method of claim 5, wherein prior to the step of loading the plug-in data at the specified location into the first memory address, the method further comprises:
and carrying out the reverse conversion operation of the preset conversion rule on the plug-in data picture to obtain the decrypted plug-in data.
7. The method of claim 1, wherein the designated location is a tail location of a designated file of the target application or a designated directory of the target application.
8. The device for dynamically loading the plug-ins is characterized in that the device is applied to electronic equipment provided with an android system, an empty DexFile object is prestored in the electronic equipment and provided with a target application, plug-in data of the target application is stored in a specified position corresponding to the target application, and the empty DexFile object comprises a data structure of the DexFile; the device comprises:
the processing module is used for responding to the running event of the target application, loading the plug-in data of the specified position into a first memory address, and recording the first memory address in a cookie of the empty DexFile object in a manner of loading the empty DexFile object;
the storage module is used for storing the empty DexFile object recorded with the first memory address into an element array of a class loader so as to call the plug-in data when the class loader is started;
so if the system libart in the android system allows the target application to access through a dlopen function, the processing module is further configured to: loading the plug-in data at the designated position into a first memory address through a first sub thread corresponding to the main thread of the target application; loading the empty DexFile object in a second memory address through a second sub-thread corresponding to the main thread; when the first sub thread and the second sub thread are finished, obtaining the cookie of the plug-in data through the main thread, and replacing the cookie in the empty DexFile object with the cookie of the plug-in data; the first memory address is recorded in the cookie of the plug-in data.
9. An electronic device comprising a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the method of dynamically loading plug-ins of any of claims 1 to 7.
10. A computer-readable storage medium having stored thereon computer-executable instructions that, when invoked and executed by a processor, cause the processor to implement the method of dynamically loading plugins of any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110548163.3A CN113268280B (en) | 2021-05-19 | 2021-05-19 | Method and device for dynamically loading plug-in and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110548163.3A CN113268280B (en) | 2021-05-19 | 2021-05-19 | Method and device for dynamically loading plug-in and electronic equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113268280A CN113268280A (en) | 2021-08-17 |
| CN113268280B true CN113268280B (en) | 2022-11-01 |
Family
ID=77231883
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110548163.3A Active CN113268280B (en) | 2021-05-19 | 2021-05-19 | Method and device for dynamically loading plug-in and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113268280B (en) |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106648755B (en) * | 2016-11-29 | 2020-02-25 | 北京奇虎科技有限公司 | Method and device for dynamically loading dex in android art environment |
| TWI649694B (en) * | 2017-10-30 | 2019-02-01 | 國立臺灣大學 | Android dynamic framework and method thereof |
-
2021
- 2021-05-19 CN CN202110548163.3A patent/CN113268280B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN113268280A (en) | 2021-08-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102332209B1 (en) | System and method for execution of application code compiled according to two instruction set architectures | |
| CN109960597B (en) | Dynamic registration method and related device of application layer interface | |
| CN107808096B (en) | method for detecting malicious codes injected during APK running, terminal equipment and storage medium | |
| CN108229148B (en) | Sandbox unshelling method and sandbox unshelling system based on Android virtual machine | |
| US20060136134A1 (en) | Information processing apparatus and method for obtaining software processing log | |
| US9111096B2 (en) | System and method for preserving and subsequently restoring emulator state | |
| CN109062582A (en) | A kind of encryption method and device of application installation package | |
| US11099889B2 (en) | Method-call-chain tracking method, electronic device, and computer readable storage medium | |
| US10311233B2 (en) | Generic unpacking of program binaries | |
| CN112882694A (en) | Program compiling method and device, electronic equipment and readable storage medium | |
| WO2023016481A1 (en) | Data processing method and related apparatus | |
| CN108985096B (en) | Security enhancement and security operation method and device for Android SQLite database | |
| CN110806913A (en) | Webpage screenshot method, device and equipment | |
| CN113268280B (en) | Method and device for dynamically loading plug-in and electronic equipment | |
| WO2023143545A1 (en) | Resource processing method and apparatus, electronic device, and computer-readable storage medium | |
| KR100818919B1 (en) | Method for invoking method and java virtual machine using the same | |
| CN110516445B (en) | Identification method and device for anti-detection malicious code and storage medium | |
| CN109684846A (en) | A kind of file extraction method and device | |
| EP3507689B1 (en) | Java card application package used as a library package | |
| US20060265687A1 (en) | Method for Finding a Function Call Stack in Run Time for a Computer System | |
| US11893113B2 (en) | Return-oriented programming protection | |
| CN110569644B (en) | Method, device and equipment for processing call request and calling function | |
| WO2019157891A1 (en) | Application installation method and application installer generating method | |
| CN112632534A (en) | Malicious behavior detection method and device | |
| US20120042100A1 (en) | Systems and methods for managing memory using multi-state buffer representations |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |