CN108229107B - Shelling method and container for Android platform application program - Google Patents

Shelling method and container for Android platform application program Download PDF

Info

Publication number
CN108229107B
CN108229107B CN201611189649.8A CN201611189649A CN108229107B CN 108229107 B CN108229107 B CN 108229107B CN 201611189649 A CN201611189649 A CN 201611189649A CN 108229107 B CN108229107 B CN 108229107B
Authority
CN
China
Prior art keywords
shelling
shelled
application program
activity
container
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
Application number
CN201611189649.8A
Other languages
Chinese (zh)
Other versions
CN108229107A (en
Inventor
李伏一
乔伟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wuhan Antiy Information Technology Co ltd
Original Assignee
Wuhan Antiy Information Technology Co ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Wuhan Antiy Information Technology Co ltd filed Critical Wuhan Antiy Information Technology Co ltd
Priority to CN201611189649.8A priority Critical patent/CN108229107B/en
Publication of CN108229107A publication Critical patent/CN108229107A/en
Application granted granted Critical
Publication of CN108229107B publication Critical patent/CN108229107B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12Protecting executable software
    • G06F21/121Restricting unauthorised execution of programs
    • G06F21/125Restricting unauthorised execution of programs by manipulating the program code, e.g. source code, compiled code, interpreted code, machine code
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12Protecting executable software
    • G06F21/14Protecting executable software against software analysis or reverse engineering, e.g. by obfuscation

Abstract

The invention discloses a shelling method of an Android platform application program, which is applied to a preset shelling container positioned in an application layer, and the application to be shelled is copied to a file directory of the shelling container by acquiring a path of an application program to be shelled input from the outside; analyzing a Manifest file of an application program to be shelled to obtain the active Activity and resource information of the application program, wherein the resource information at least comprises a resource path; loading the resource path and the code of the application program to be shelled into the process space of a shelling container according to the path of the application program to be shelled; acquiring a dex file structure of the application program to be shelled; and shelling the application program to be shelled according to the dex file structure. The invention also discloses a shelling container which comprises an analysis module, a dynamic loading module and a core shelling module. The invention does not need root authority, does not need to modify system source codes, is convenient to realize and has high shelling efficiency.

Description

Shelling method and container for Android platform application program
Technical Field
The invention relates to the technical field of information security, in particular to a shelling method and a container for an Android platform application program.
Background
The Android system has the open source characteristic, and the Android platform application program is rapidly developed along with the continuous improvement of the performance of the mobile terminal. However, malicious applications on the Android platform are increasing, and the privacy and asset security of users are seriously jeopardized. Nowadays, malicious applications on the Android platform mostly use reinforcement technology to hide logic of malicious codes of the applications so as to bypass searching and killing of a antivirus engine and cause serious harm to users. To solve the problem, the shelling technology of Android reinforcement application is carried forward.
The existing shelling schemes for Android applications are mainly divided into the following two types: the first method is realized by writing memory data into a file when an Android application runs through some dynamic debugging tools, the method needs manual participation and root permission, and the existing reinforcement technology adopts a plurality of protection means for the method, so that the efficiency and the success rate of the shelling method are low. The second way is to reconstitute the data into a new de-shelled file by modifying the system level virtual machine (e.g., Dalvik virtual machine or ART virtual machine) to obtain the data structure associated with the dex file. This method can realize an automatic huller, but needs to modify the system code, and needs to refresh every time of modification, and the use is very tedious to update, and is not suitable for the use scene of the ordinary user.
Disclosure of Invention
The invention aims to provide a shelling method and a container for an Android platform application program, which are suitable for the use scene of a common user, do not need root authority, are convenient to realize and have high shelling efficiency.
In order to achieve the purpose, the invention discloses a shelling method of an Android platform application program, which is applied to a preset shelling container located in an application layer, and the shelling method comprises the following steps:
acquiring a path of an externally input application program to be shelled, and copying the application to be shelled into a file directory of a shelling container;
analyzing a Manifest file of an application program to be shelled to obtain the active Activity and resource information of the application program, wherein the resource information at least comprises a resource path;
loading the resource path and the code of the application program to be shelled into the process space of a shelling container according to the path of the application program to be shelled; the code loading comprises the following steps: starting the acquired main Activity, and sending a starting parameter of a substitute Activity to a system layer, wherein the substitute Activity is the Activity of the Manifest file in the shelling container; the system layer acquires a starting parameter of the proxy Activity to carry out Activity management; the shelling container creates a new ClassLoader object for the main Activity, and binds the ClassLoader object to a loader of a system layer for loading the Activity class; calling a function of a loading class by using the ClassLoader object to complete code loading;
acquiring a dex file structure of the application program to be shelled;
and shelling the application program to be shelled according to the dex file structure.
Further, the management of Activity includes life cycle management, stack management or verification of authenticity.
Further, the method for binding the ClassLoader object comprises the following steps: constructing a LoadeAPK object of the application program to be shelled through a system function getPackageInfoNoCheck (); replacing the mClassLoader member variable of the application program to be shelled with the constructed ClassLoader object; the CurrentThread object is obtained through reflection, the member variable mpacties is obtained, and the created LoadeAPK object is added to the Map of the mpacties.
Further, the method for loading the resource path comprises the following steps: creating an AssetManager object, calling an addAssessPath function in the AssetManager in a reflection mode, and loading a resource path of an application program to be shelled into the AssetManager; creating a Resources object of the application to be shelled according to the AssetManager; the created Resources object is added to the resource cache table of the shelling container.
Further, the shelling the application program to be shelled according to the dex file structure of the application program to be shelled includes the following steps: opening up a new space for storing the repaired dex file according to the size of the corresponding gdvm. userdexfiles structural body of the dex file in the memory; acquiring a current DexFile structure through a gDvm. userDexFiles structure, analyzing the DexFile structure, and determining a structure needing to be repaired; repairing each structural body, and recombining all DexClassData structural bodies to form the repaired dex file in the memory; and (4) enabling the repaired dex file to be from the Dump in the memory to a corresponding output directory.
In order to achieve the above object, the present invention further discloses a shelling container, configured to shell an application in an Android platform application layer, where the shelling container includes an parsing module, a dynamic loading module, and a core shelling module, where:
the analysis module is used for acquiring a path of an externally input application program to be shelled, and copying the application to be shelled into a file directory of a shelling container; analyzing a Manifest file of an application program to be shelled to obtain the active Activity and resource information of the application program, wherein the resource information at least comprises a resource path;
the dynamic loading module is used for loading the resource path and the code of the application program to be shelled into the process space of the shelling container according to the path of the application program to be shelled; the code loading comprises the following steps: starting the acquired main Activity, and sending a starting parameter of a substitute Activity to a system layer, wherein the substitute Activity is the Activity of the Manifest file in the shelling container; the system layer acquires a starting parameter of the proxy Activity to carry out Activity management; the dynamic loading module creates a new ClassLoader object for the main Activity, and binds the ClassLoader object to a loader of a system layer for loading the Activity class; calling a function of a loading class by using the ClassLoader object to complete code loading;
the core shelling module is used for acquiring a dex file structure of the application program to be shelled; and shelling the application program to be shelled according to the dex file structure.
Further, the management of Activity includes life cycle management, stack management or verification of authenticity.
Further, the method for binding the ClassLoader object comprises the following steps: constructing a LoadeAPK object of the application program to be shelled through a system function getPackageInfoNoCheck (); replacing the mClassLoader member variable of the application program to be shelled with the constructed ClassLoader object; the CurrentThread object is obtained through reflection, the member variable mpacties is obtained, and the created LoadeAPK object is added to the Map of the mpacties.
Further, the method for loading the resource path by the dynamic loading module includes: creating an AssetManager object, calling an addAssessPath function in the AssetManager in a reflection mode, and loading the resource of the application program to be shelled into the AssetManager; creating a Resources object of the application to be shelled according to the AssetManager; the created Resources object is added to the resource cache table of the shelling container.
Further, the shelling the application program to be shelled according to the dex file structure includes the following steps: opening up a new space for storing the repaired dex file according to the size of the corresponding gdvm. userdexfiles structural body of the dex file in the memory; acquiring a current DexFile structure through a gDvm. userDexFiles structure, analyzing the DexFile structure, and determining a structure needing to be repaired; repairing each structural body, and recombining all DexClassData structural bodies to form the repaired dex file in the memory; and (4) enabling the repaired dex file to be from the Dump in the memory to a corresponding output directory.
Further, after the dynamic loading module finishes loading the resource path and the code, the shelling container calls an OnCreate function of the main Activity, and a core shelling module is called in the function.
Compared with the prior art, the invention has the beneficial effects that: the existing shelling mode needs to interfere in the process of the application program to be shelled, so that root authority of the application program to be shelled needs to be obtained. The invention uses the principle of dynamic loading to load the resource path and the code of the application program to be deshelled into a preset deshelling container to realize the deshelling of the application program in the application layer. The invention does not need root authority because of no cross-process operation, does not need to modify system source codes, can be suitable for the use scene of common users, and has convenient realization and high shelling efficiency.
Drawings
Fig. 1 is a flowchart of a shelling method for an Android platform application according to the present invention.
FIG. 2 is a flow chart of the code loading of the present invention.
FIG. 3 is a flowchart illustrating the shelling of the application to be shelled according to the present invention.
Fig. 4 is a schematic structural diagram of a hulling vessel according to the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention will be described in further detail with reference to the accompanying drawings.
Although the steps in the present invention are arranged by using reference numbers, the order of the steps is not limited, and the relative order of the steps can be adjusted unless the order of the steps is explicitly stated or other steps are required for the execution of a certain step.
The invention aims to realize the shelling of the reinforcement application, and the kernel of the shelling lies in the reconstruction of the dex file structure, and the related information of the dex file structure needs to be solved before the invention is understood.
Firstly, all application installation packages of the Android platform exist in the form of apk, the apk is a ZIP compression package, and after decompression, resource files, signature files, configuration files and an executable file class.
Figure 746221DEST_PATH_IMAGE001
TABLE 1
Logically, the dex file can be divided into 3 areas, i.e., a header, an index area, and a data area. The ids suffix of the index area is an abbreviation of identifiers, meaning an identification code of something. The data of the area is mostly a pointer to the data area.
The header in the dex file, in addition to describing the file information of the dex file, has indexes of other areas in the file, and the structure of the index is as follows:
struct DexHeader { ubyte magic[8]; /* includes version number */ uint checksum; /* adler32 checksum */ ubyte signature[kSHA1DigestLen]; /* SHA-1 hash */ uint fileSize; /* length of entire file */ uint headerSize; /* offset to start of next section */ uint endianTag; uint linkSize; uint linkOff; uint mapOff; uint stringIdsSize; uint stringIdsOff; uint typeIdsSize; uint typeIdsOff; uint protoIdsSize; uint protoIdsOff; uint fieldIdsSize; uint fieldIdsOff; uint methodIdsSize; uint methodIdsOff; uint classDefsSize; uint classDefsOff; uint dataSize; uint dataOff; };
the bold font field represents the information of the dex file, such as a magic field, and the field in the dex file is fixed as: dex.035; checksum is a check value of the entire dex file to ensure integrity and tamper resistance of the file. The other fields are present in pairs, representing the position and size of the corresponding index zone: if sting _ ids _ off represents the location of the string index area, string _ ids _ size represents the size of the index area, and so on.
In the Android system, a structure body of a DexFile is used for describing the structure of the whole dex file, a DexHeader is used for describing header information of the dex file, a ClassDef structure is used for describing information of each class, the ClassDef structure is a structure body mainly operated in the shelling process, class _ data _ off in the ClassDef structure points to the structure of DexClassData, and the DexClassData structure describes specific information in the class, and the method comprises the following steps: static member variables and example member variables, and static methods and example methods, wherein the methods are described by a structural body of DexMethod, and the structure of DexMethod comprises a structural body of DexCode for describing relevant information of specific instructions of the method. The main operation in the shelling process is three levels of data, namely DexClassData, DexMethod and DexCode.
Some specific embodiments of the present invention are given below.
Example 1
Referring to fig. 1, in some embodiments, the shelling method for Android platform applications disclosed in the present invention is applied to a preset shelling container located in an application layer, and it can be understood that the shelling container is also an application program and has its own Manifest file. The shelling method comprises the following steps:
and S01, acquiring the path of the application program to be shelled input from the outside, and copying the application to be shelled into the file directory of the shelling container.
And S02, analyzing the Manifest file of the application program to be shelled, and acquiring the main Activity and the resource information of the application program to be shelled.
The main Activity comprises an Activity character string used for describing the main page, and the resource information comprises: pictures, icons, XML files, and paths of resources.
S03, loading the code and resource path of the application program to be shelled into the process space of the shelling container according to the path of the application program to be shelled.
S031, add the resource path of the application to be shelled to the system resource management class of the shelling container. It can be understood that the system also completes the loading of the resources such as pictures, icons, XML files, and the like.
Specifically, an AssetManager object needs to be created first, and theoretically, the resource path of an apk file can be loaded into the Resources object by calling an addasspath method in the AssetManager. However, because the addassetPath is a method in which the hidden api cannot directly call the apk file, after the AssetManager object is created, the method must be called by reflection, and the path of the application to be shelled is transmitted to the addassetPath, so as to load the resource path into the AssetManager. Since applications typically use Resource objects to access Resources, a new Resource object needs to be created by the AssetManager and added to the Resource cache table of the shelling container.
S032, code loading. As shown in connection with fig. 2, the code loading includes the following steps:
s0321, the acquired primary Activity is started.
S0322, sending a start parameter of a substitute Activity to the system layer, where the substitute Activity is the Activity of the Manifest file in the shelling container, and hereinafter, the substitute Activity is denoted as stubbactivity.
S0323, the system layer acquires the starting parameter of the stub Activity to complete the Activity management.
The invention takes the stubbActivity as the substitute of the main Activity, and deceives the Activity management service class (AMS for short in the following) used for managing the Activity by the system layer, thereby realizing the work of life cycle management, stack management or authenticity check of the Activity.
S0324, the shelling container creates a new ClassLoader object for the main Activity, and binds the ClassLoader object to a loader of the system layer loading Activity class.
The source dex path of the ClassLoader is the path copied by S01. Theoretically, the Android platform can load the code by using the path of the application program loaded by the self ClassLoader object, but the components of the application program loaded in this way have no life cycle, that is, the main Activity cannot be started normally in this way. In order for the loaded component to have a lifecycle, it is therefore necessary to create a new ClassLoader object with the shelling container and bind this object to the loader at the system level for loading the Activity class.
For ease of understanding, we now introduce the hierarchical relationship of the ClassLoader objects: the ClassLoader object is in the LoadeApk object, the LoadeApk object is in the mPackages of the CurrentThread object, and the system layer uses the LoadeApk object in the mPackages.
The method for binding the ClassLoader object comprises the following steps: constructing a LoadeAPK object of the application program to be shelled through a system function getPackageInfoNoCheck (); replacing the mClassLoader member variable of the application program to be shelled with the constructed ClassLoader object; the CurrentThread object is obtained through reflection, the member variable mpacties is obtained, and the created LoadeAPK object is added to the Map of the mpacties.
It can be understood that the system layer uses the function LoadClass of the ClassLoader call loading class to complete code loading.
The existing shelling mode needs to interfere in the process of the application program to be shelled, so that root authority of the application program to be shelled needs to be obtained. The invention uses the principle of dynamic loading to load the resource path and the code of the application program to be deshelled into a preset deshelling container to realize the deshelling of the application program in the application layer. The invention does not need root authority because of no cross-process operation, does not need to modify system source codes, can be suitable for the use scene of common users, and has convenient realization and high shelling efficiency.
And S04, acquiring the dex file structure of the application program to be shelled.
And acquiring a gDvm. userDexFiles structure corresponding to the dex file of the application program to be shelled in the memory.
And S05, shelling the application program to be shelled according to the dex file structure. As shown in connection with fig. 3:
s051, opening up a new space according to gdvm. userdexfiles size for storing repaired Dex file.
S052, obtaining the current DexFile structure by gdvm. userdexffiles, then parsing the DexFile structure to obtain the data therein, traversing the whole DexFile according to the header data in the structure, and determining the structure to be repaired.
Determining a structural body needing to be repaired by traversing a specific hierarchy from DexClassData to DexMethod and then to a specific DexCode structure, and if class _ data _ off in DexClassData is judged to be a remote address, determining that the class _ data _ off needs to be repaired; if the code _ off in the DexMethod is judged to be a remote address, determining that the address needs to be repaired; and if the instruction of the insns in the DexCode structure is judged to be null, determining that the instruction needs to be repaired.
S053, repairing each structural body, and recombining all DexClassData structural bodies to form a new dex file in the memory.
Repairing each structure body, corresponding to S052, if class _ data _ off in DexClassData is a remote address, then copying the value pointed by the address to a newly opened space; if code _ off in DexMethod is a remote address, copying the structure body of the DexMethod pointed remotely to a corresponding position in the newly opened space; if the instructions of the insns in the DexCode structure are empty, the instructions are restored through the insns in the Method object.
And recombining all DexClassData structures, namely recalculating the offset through repairing the finished DexClassData structures, and filling the offset into the structure corresponding to the DexFile.
Recalculating data of a header in the DexFile, wherein some data are fixed and unchangeable, such as a magic field, a header size, string _ ids _ off and the like of the Dex file, and can be directly filled in, some data, such as type _ ids _ off, proto _ ids _ off and the like, need to be recalculated and then are filled in, and after the data of the header is repaired, a new Dex file is formed.
And S054, writing the recombined new Dex file from the memory Dump to a corresponding output directory in a file form, wherein the file is a file after being shelled.
Example 2
As shown in fig. 4, a shelling container is used for shelling an application in an Android platform application layer, and includes a parsing module 10, a dynamic loading module 20, and a core shelling module 30, where:
the parsing module 10 is configured to obtain a path of an application program to be shelled, which is input from the outside, and copy the application to be shelled into a file directory of a shelling container; and analyzing the Manifest file of the application program to be shelled to acquire the main Activity and the resource information of the application program to be shelled. The main Activity comprises an Activity character string used for describing the main page, and the resource information at least comprises a resource path.
The dynamic loading module 20 is configured to load the code and the resource path of the application program to be shelled into a shelling container according to the path of the application program to be shelled, so as to create a class of a main Activity. Specifically, the method comprises the following steps:
1. resource path loading: an AssetManager object is created, and theoretically, the resource path of an apk file can be loaded into the Resources object by calling an addAssessPath method in the AssetManager. However, because the addassetPath is a method in which the hidden api cannot directly call the apk file, after the AssetManager object is created, the method must be called by reflection, and the path of the application to be shelled is transmitted to the addassetPath, so as to load the resource path into the AssetManager. Since applications typically use Resource objects to access Resources, a new Resource object needs to be created by the AssetManager and added to the Resource cache table of the shelling container.
2. Code loading, including the following:
(1) the acquired primary Activity is launched.
(2) And sending a start parameter of the substitute Activity to the system layer, wherein the substitute Activity is the Activity of the Manifest file in the shelling container, and the substitute Activity is recorded as the stub Activity.
(3) And the system layer acquires the starting parameter of the stub Activity to complete the management of the Activity.
The invention takes the stubbActivity as the substitute of the main Activity, and deceives the Activity management service class (AMS for short in the following) used for managing the Activity by the system layer, thereby realizing the work of life cycle management, stack management or authenticity check of the Activity.
(4) The dynamic loading module 20 creates a new ClassLoader object for the main Activity, and binds the ClassLoader object to a loader of the system layer loading Activity class. The launching of Activity is realized by means of a dynamic proxy.
Specifically, the dynamic loading module 20 creates a new ClassLoader object for the main Activity, and then constructs a loadapk object of the application to be shelled through a system function getheadinfonocheck (); replacing the mClassLoader member variable of the application program to be shelled with the constructed ClassLoader object; the CurrentThread object is obtained through reflection, the member variable mpacties is obtained, and the created LoadeAPK object is added to the Map of the mpacties.
It can be understood that the system layer also completes code loading by using the function LoadClass of the ClassLoader call loading class.
The existing shelling mode needs to interfere in the process of the application program to be shelled, so that root authority of the application program to be shelled needs to be obtained. The invention uses the principle of dynamic loading to load the resource path and the code of the application program to be deshelled into a preset deshelling container to realize the deshelling of the application program in the application layer. The invention does not need root authority because of no cross-process operation, does not need to modify system source codes, can be suitable for the use scene of common users, and has convenient realization and high shelling efficiency.
When the dynamic loading module 20 finishes loading the resource path and the code, the shelling container calls an OnCreate function of the main Activity, and calls the core shelling module 30 in the function.
The core shelling module 30 comprises the following functions:
1. the method includes obtaining a dex file structure of the application program to be shelled, that is, obtaining a gdvm.
2. And shelling the application program to be shelled according to the dex file structure. Specifically, the method comprises the following steps:
(1) and opening up a new space according to the size of gDvm. userDexFiles, and storing the repaired Dex file.
(2) Obtaining a current DexFile structure through gDvm. userDexFile, analyzing the DexFile structure to obtain data in the DexFile structure, and traversing the whole DexFile file to determine a structure needing to be repaired according to head data in the structure.
(3) And restoring each structural body, and recombining all DexClassData structural bodies to form a new Dex file in the memory.
If class _ data _ off in DexClassData is a remote address, then the value pointed by the address is copied to the newly opened space; if code _ off in DexMethod is a remote address, copying the structure body of the DexMethod pointed remotely to a corresponding position in the newly opened space; if the instructions of the insns in the DexCode structure are empty, the instructions are restored through the insns in the Method object.
And recombining all DexClassData structures, namely recalculating the offset through repairing the finished DexClassData structures, and filling the offset into the structure corresponding to the DexFile.
Recalculating data of a header in the DexFile, wherein some data are fixed and unchangeable, such as a magic field, a header size, string _ ids _ off and the like of the Dex file, and can be directly filled in, some data, such as type _ ids _ off, proto _ ids _ off and the like, need to be recalculated and then filled in, and after the data of the header is repaired, a new Dex file is formed.
(4) And writing the recombined new Dex file from the memory Dump to a corresponding output directory in a file form, wherein the file is an uncoated file.
The foregoing description shows and describes several preferred embodiments of the invention, but as aforementioned, it is to be understood that the invention is not limited to the forms disclosed herein, but is not to be construed as excluding other embodiments and is capable of use in various other combinations, modifications, and environments and is capable of changes within the scope of the inventive concept as expressed herein, commensurate with the above teachings, or the skill or knowledge of the relevant art. And that modifications and variations may be effected by those skilled in the art without departing from the spirit and scope of the invention as defined by the appended claims.

Claims (8)

1. A shelling method of an Android platform application program is applied to a preset shelling container located in an application layer, and is characterized by comprising the following steps:
acquiring a path of an externally input application program to be shelled, and copying the application to be shelled into a file directory of a shelling container;
analyzing a Manifest file of an application program to be shelled to obtain the active Activity and resource information of the application program, wherein the resource information at least comprises a resource path;
loading the resource path and the code of the application program to be shelled into the process space of a shelling container according to the path of the application program to be shelled; the code loading comprises the following steps: starting the acquired main Activity, and sending a starting parameter of a substitute Activity to a system layer, wherein the substitute Activity is the Activity of the Manifest file in the shelling container; the system layer acquires a starting parameter of the proxy Activity to carry out Activity management; the shelling container creates a new ClassLoader object for the main Activity, and binds the ClassLoader object to a loader of a system layer for loading the Activity class; calling a function of a loading class by using the ClassLoader object to complete code loading;
acquiring a dex file structure of the application program to be shelled;
according to the dex file structure, shelling the application program to be shelled;
the shelling of the application program to be shelled according to the dex file structure of the application program to be shelled comprises the following steps: opening up a new space for storing the repaired dex file according to the size of the corresponding gdvm. userdexfiles structural body of the dex file in the memory; acquiring a current DexFile structure through a gDvm. userDexFiles structure, analyzing the DexFile structure, and determining a structure needing to be repaired; repairing each structural body, and recombining all DexClassData structural bodies to form the repaired dex file in the memory; and (4) enabling the repaired dex file to be from the Dump in the memory to a corresponding output directory.
2. A shelling method as claimed in claim 1, wherein the management of Activity comprises lifecycle management, stack management or verification of authenticity.
3. A shelling method as defined in claim 1, wherein the method of binding a ClassLoader object comprises the steps of: constructing a LoadeAPK object of the application program to be shelled through a system function getPackageInfoNoCheck (); replacing the mClassLoader member variable of the application program to be shelled with the constructed ClassLoader object; the CurrentThread object is obtained through reflection, the member variable mpacties is obtained, and the created LoadeAPK object is added to the Map of the mpacties.
4. A shelling method as defined in claim 1, wherein the method of loading a resource path comprises: creating an AssetManager object, calling an addAssessPath function in the AssetManager in a reflection mode, and loading a resource path of an application program to be shelled into the AssetManager; creating a Resources object of the application to be shelled according to the AssetManager; the created Resources object is added to the resource cache table of the shelling container.
5. A shelling container for Android platform applications, configured to shell an application in an Android platform application layer, where the shelling container includes a parsing module, a dynamic loading module, and a core shelling module, where:
the analysis module is used for acquiring a path of an externally input application program to be shelled, and copying the application to be shelled into a file directory of a shelling container; analyzing a Manifest file of an application program to be shelled to obtain the active Activity and resource information of the application program, wherein the resource information at least comprises a resource path;
the dynamic loading module is used for loading the resource path and the code of the application program to be shelled into the process space of the shelling container according to the path of the application program to be shelled; the code loading comprises the following steps: starting the acquired main Activity, and sending a starting parameter of a substitute Activity to a system layer, wherein the substitute Activity is the Activity of the Manifest file in the shelling container; the system layer acquires a starting parameter of the proxy Activity to carry out Activity management; the dynamic loading module creates a new ClassLoader object for the main Activity, and binds the ClassLoader object to a loader of a system layer for loading the Activity class; calling a function of a loading class by using the ClassLoader object to complete code loading;
the core shelling module is used for acquiring a dex file structure of the application program to be shelled; according to the dex file structure, shelling the application program to be shelled;
the kernel shelling module shelling the application program to be shelled according to the dex file structure comprises the following steps: opening up a new space for storing the repaired dex file according to the size of the corresponding gdvm. userdexfiles structural body of the dex file in the memory; acquiring a current DexFile structure through a gDvm. userDexFiles structure, analyzing the DexFile structure, and determining a structure needing to be repaired; repairing each structural body, and recombining all DexClassData structural bodies to form the repaired dex file in the memory; and (4) enabling the repaired dex file to be from the Dump in the memory to a corresponding output directory.
6. A shelling container as defined in claim 5, wherein said method of dynamically loading modules to bind ClassLoader objects comprises the steps of: constructing a LoadeAPK object of the application program to be shelled through a system function getPackageInfoNoCheck (); replacing the mClassLoader member variable of the application program to be shelled with the constructed ClassLoader object; the CurrentThread object is obtained through reflection, the member variable mpacties is obtained, and the created LoadeAPK object is added to the Map of the mpacties.
7. A shelling container as defined in claim 5, wherein said method of dynamically loading a resource path by a module comprises: creating an AssetManager object, calling an addAssessPath function in the AssetManager in a reflection mode, and loading the resource of the application program to be shelled into the AssetManager; creating a Resources object of the application to be shelled according to the AssetManager; the created Resources object is added to the resource cache table of the shelling container.
8. A shelling container as claimed in claim 5 wherein said dynamic load module, upon completion of loading the resource path and code, calls an OnCreate function of said primary Activity and said core shelling module is called within the OnCreate function.
CN201611189649.8A 2016-12-21 2016-12-21 Shelling method and container for Android platform application program Active CN108229107B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201611189649.8A CN108229107B (en) 2016-12-21 2016-12-21 Shelling method and container for Android platform application program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201611189649.8A CN108229107B (en) 2016-12-21 2016-12-21 Shelling method and container for Android platform application program

Publications (2)

Publication Number Publication Date
CN108229107A CN108229107A (en) 2018-06-29
CN108229107B true CN108229107B (en) 2021-06-25

Family

ID=62650994

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201611189649.8A Active CN108229107B (en) 2016-12-21 2016-12-21 Shelling method and container for Android platform application program

Country Status (1)

Country Link
CN (1) CN108229107B (en)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112214250A (en) * 2019-06-24 2021-01-12 北京京东尚科信息技术有限公司 Application program assembly loading method and device
CN111581639B (en) * 2020-03-27 2022-10-14 北京大学 Universal automatic shelling method and system for Android shelling application program
CN111625290B (en) * 2020-05-06 2023-03-24 小船出海教育科技(北京)有限公司 Layout file preloading method and device under Android platform and electronic equipment
CN112068932A (en) * 2020-09-01 2020-12-11 北京指掌易科技有限公司 Application program integration and monitoring method, device, system, equipment and medium
CN112230927A (en) * 2020-09-17 2021-01-15 贝壳技术有限公司 File redirection method, code loading control method and device
CN112214267A (en) * 2020-10-12 2021-01-12 广州大学 Android shelling acceleration method and device, storage medium and computer equipment
CN112883374B (en) * 2021-02-02 2022-07-01 电子科技大学 General Android platform application program shelling method and system based on ART environment
CN114385261A (en) * 2021-12-23 2022-04-22 湖南小算科技信息有限公司 Method for loading program in process
CN116662270A (en) * 2022-09-09 2023-08-29 荣耀终端有限公司 File analysis method and related device

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8892876B1 (en) * 2012-04-20 2014-11-18 Trend Micro Incorporated Secured application package files for mobile computing devices
CN105574411A (en) * 2015-12-25 2016-05-11 北京奇虎科技有限公司 Dynamic unshelling method, device and equipment
CN105930692A (en) * 2016-04-20 2016-09-07 北京鼎源科技有限公司 Dynamic shelling method for Android application
CN105989252A (en) * 2015-12-12 2016-10-05 武汉安天信息技术有限责任公司 Function level packing-oriented unpacking method and system
CN106203120A (en) * 2016-07-15 2016-12-07 北京邮电大学 A kind of multiple spot Hook reverse method for Android reinforcement application

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8892876B1 (en) * 2012-04-20 2014-11-18 Trend Micro Incorporated Secured application package files for mobile computing devices
CN105989252A (en) * 2015-12-12 2016-10-05 武汉安天信息技术有限责任公司 Function level packing-oriented unpacking method and system
CN105574411A (en) * 2015-12-25 2016-05-11 北京奇虎科技有限公司 Dynamic unshelling method, device and equipment
CN105930692A (en) * 2016-04-20 2016-09-07 北京鼎源科技有限公司 Dynamic shelling method for Android application
CN106203120A (en) * 2016-07-15 2016-12-07 北京邮电大学 A kind of multiple spot Hook reverse method for Android reinforcement application

Also Published As

Publication number Publication date
CN108229107A (en) 2018-06-29

Similar Documents

Publication Publication Date Title
CN108229107B (en) Shelling method and container for Android platform application program
AU2004218703B2 (en) Security-related programming interface
US9336018B2 (en) Mechanism for class data sharing using extension and application class-loaders
US7577848B2 (en) Systems and methods for validating executable file integrity using partial image hashes
US8271608B2 (en) System and method for a mobile cross-platform software system
Bojinov et al. Address space randomization for mobile devices
US20080148399A1 (en) Protection against stack buffer overrun exploitation
US7634806B2 (en) Peer assembly inspection
CN108229148B (en) Sandbox unshelling method and sandbox unshelling system based on Android virtual machine
CN109784039B (en) Construction method of safe operation space of mobile terminal, electronic equipment and storage medium
CN111400757A (en) Method for preventing native code in android third-party library from revealing user privacy
US20150039872A1 (en) Multiple Signed Filesystem Application Packages
CN113391874A (en) Virtual machine detection countermeasure method and device, electronic equipment and storage medium
US20240061933A1 (en) Systems and methods for causing nonpredictable environment states for exploit prevention and malicious code neutralization for javascript-enabled applications
CN111625296B (en) Method for protecting program by constructing code copy
CN116173511A (en) Game heat updating method, device, computer equipment and storage medium
US20190102279A1 (en) Generating an instrumented software package and executing an instance thereof
CN109408194B (en) System and method for simulating execution of file
US20170316211A1 (en) Application translocation
CN107315951B (en) Program installation package anti-interception method and device
US11720374B1 (en) Dynamically overriding a function based on a capability set
Kim et al. Self-controllable mobile app protection scheme based on binary code splitting
CN116679971A (en) Thermal repair method, device, electronic equipment and storage medium
WO2023154092A1 (en) Dynamically overriding a function based on a capability set during load time
CN117857118A (en) Asymmetric encryption-based cloud mobile phone system mirror image tamper-proof method

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
CB02 Change of applicant information

Address after: 430000 No.C20 Building of Wuhan Software New Town Industry Phase III, No.8 Huacheng Avenue, Donghu New Technology Development Zone, Wuhan City, Hubei Province

Applicant after: WUHAN ANTIY INFORMATION TECHNOLOGY Co.,Ltd.

Address before: Room 01, 12 / F, building B4, phase 4-1, software industry, No.1, Software Park East Road, Donghu New Technology Development Zone, Wuhan City, Hubei Province, 430000

Applicant before: WUHAN ANTIY INFORMATION TECHNOLOGY Co.,Ltd.

CB02 Change of applicant information
GR01 Patent grant
GR01 Patent grant