CN112214266A

CN112214266A - Android shelling method and device for deception call chain, storage medium and computer equipment

Info

Publication number: CN112214266A
Application number: CN202011087559.4A
Authority: CN
Inventors: 田志宏; 金成杰; 鲁辉; 何陆潇涵; 孙彦斌; 苏申
Original assignee: Guangzhou University
Current assignee: Guangzhou University
Priority date: 2020-10-12
Filing date: 2020-10-12
Publication date: 2021-01-12

Abstract

The embodiment of the invention provides a deception calling chain android shelling method and device, a storage medium and computer equipment. The method comprises the steps of selecting a function arrival path, selecting a shelling point, constructing a virtual calling chain to call all functions in an App, completing decryption of a Dex file by the App, finding a plurality of universal and deep shelling points in a complex and changeable source code environment, constructing a deception calling chain according to needs to call a java method on a Native layer, and reducing modification cost.

Description

Android shelling method and device for deception call chain, storage medium and computer equipment

[ technical field ] A method for producing a semiconductor device

The invention relates to the field of android reinforcement reverse analysis, in particular to an android shelling method and device for a deception calling chain, a storage medium and computer equipment.

[ background of the invention ]

The location and fileName used in the DexHunter shelling process are obtained by the technicians through manual analysis, and by analyzing and researching the reinforcement mode of each reinforcement service in detail, a fixed characteristic character string is selected as the mark for shelling starting. There is a significant limitation to using such an approach: if the consolidation vendor has different characterization consolidation methods for different apps, then the DexHunter can no longer accurately locate the shelling start.

The experimental model of DexAuto is still the old android4.4 version and is not open source, only the time consumed by shelling can be paid attention to from the experimental result, the function integrity of Dex after shelling is not disclosed, and whether the function extraction type reinforcement can be repaired or not is still to be testified.

The PackerGrind achieves a certain effect, but if the packed application program loads different codes into the same memory and executes the codes under different conditions, the PackerGrind cannot judge which codes are real because of lack of semantic information; since the DROIDUNPACK is built on the whole system simulation, the detection of implementing the anti-simulation technique will inevitably destroy the subsequent analysis.

However, these tools cannot separate their own components to solve the problem of finer granularity, for example, the situation of dynamically loading Dex cannot be solved due to the life cycle limitation of the class loader of the simulation operation of DexAuto; if a consolidator uses invalid classes or garbage classes to detect if it is abnormally loaded and directly exits the killing process, then DexAuto cannot deal with this situation.

It can be seen that these tools either require special scenarios to function or do not take into account the function extraction. In fact, the reinforcing condition is complex and variable, and the upgrading iteration is performed all the time. Through intensive research, the method can not repair deeper function extraction type protection, such as completing a reinforcement scene of a function backfill function body after a function call is decrypted.

[ summary of the invention ]

In view of this, the embodiment of the present invention provides an android shelling method, an android shelling device, a storage medium, and a computer device for a deception call chain, which are used to obtain a plurality of shelling points, construct a deception call chain as needed to perform java method invocation at a Native layer, and reduce modification cost.

In one aspect, an embodiment of the present invention provides a spoofing android shelling method, including:

selecting a function arrival path;

selecting a shelling point;

constructing a virtual call chain to call all functions in App;

app completes the decryption of Dex file.

Optionally, the selecting a function arrival path specifically includes:

the Quick code mode or Interpreter mode is selected and finally the ExecuteWitchImpl function is entered.

Optionally, the selecting a shelling point specifically includes: an Execute function, dexfile object, or Execute switch impl is selected as the shelling point.

Optionally, the constructing a virtual call chain to call all functions in the App specifically includes:

setting a calling chain entrance;

entering an Invoke function, constructing parameters in the Invoke function, and returning to an entry of a calling chain after the active calling chain completes calling;

entering an EnterInterpreterFromInvake function, constructing the EnterInterpreterFromInvake function, saving the value of a result register after executing Excute, and returning to the Invake function;

entering an Excute function for construction, returning to a register after the calling is completed, and returning to an EnterterInterpreteFromInvake function;

entering an ExcutSwitchImpl function for construction, and returning to an Execute function after the calling is finished;

and calling a decryption method, and returning to the ExcuteSwitchImpl function after decryption is completed.

Optionally, the setting the call chain entry includes: and constructing necessary parameters and active call chain identifications.

In another aspect, an embodiment of the present invention provides a spoofed call chain android shelling device, including:

the first selection module is used for selecting a function arrival path;

the second selection module is used for selecting a shelling point;

the construction module is used for constructing a virtual call chain to call all functions in the App;

and the decryption module is used for the App to finish calling and decrypt the Dex file.

Optionally, the first selecting module is specifically configured to:

Optionally, the second selecting module is specifically configured to:

an Execute function, dexfile object, or Execute switch impl is selected as the shelling point.

In another aspect, an embodiment of the present invention provides a storage medium, where the storage medium includes a stored program, where when the program runs, a device in which the storage medium is located is controlled to execute the foregoing spoofed call chain android shelling method.

In another aspect, an embodiment of the present invention provides a computer device, including a memory and a processor, where the memory is used to store information including program specification, and the processor is used to control execution of program instructions, where the program instructions are loaded by the processor and executed to implement the steps of the foregoing spoofed call chain android shelling method.

According to the technical scheme of the android shelling method, the android shelling device, the storage medium and the computer equipment of the call chain, the function arrival path is selected, the shelling point is selected, the virtual call chain is constructed to call all functions in the App, the App completes the decryption of the Dex file by calling, the purpose of finding a plurality of universal and deeper shelling points in a complex and changeable source code environment is achieved, the call chain is deceived as required to call a java method in a Native layer, and the cost of modification is reduced.

[ description of the drawings ]

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive labor.

Fig. 1 is a flowchart of an android shelling method for a spoofed call chain according to an embodiment of the present invention;

FIG. 2 is a flow chart of selecting a shelling point according to one embodiment of the present invention;

fig. 3 is a flowchart for constructing a virtual call chain to call all functions in App according to an embodiment of the present invention;

fig. 4 is a structural diagram of an android shelling apparatus for a spoofed call chain according to an embodiment of the present invention;

fig. 5 is a schematic diagram of a computer device according to an embodiment of the present invention.

[ detailed description ] embodiments

For better understanding of the technical solutions of the present invention, the following detailed descriptions of the embodiments of the present invention are provided with reference to the accompanying drawings.

It should be understood that the described embodiments are only some embodiments of the invention, and not all embodiments. 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.

The terminology used in the embodiments of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in the examples of the present invention and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

It should be understood that the term "and/or" as used herein is merely one type of associative relationship that describes an associated object, meaning that three types of relationships may exist, e.g., A and/or B, may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" herein generally indicates that the former and latter related objects are in an "or" relationship.

Fig. 1 is a flowchart of a method for spoofing call chain android shelling according to an embodiment of the present invention, as shown in fig. 1, the method includes:

and 101, selecting a function arrival path.

Step 102, selecting a shelling point.

And 103, constructing a virtual calling chain to call all functions in the App.

And step 104, the App completes the decryption of the Dex file by calling.

According to the android shelling method for the deception call chain, provided by the embodiment of the invention, the function arrival path is selected, the shelling point is selected, the virtual call chain is constructed to call all functions in the App, the App completes the call to decrypt the Dex file, so that a plurality of universal and deeper shelling points are found in a complex and changeable source code environment, the deception call chain is constructed as required to carry out java method calling at a Native layer, and the modification cost is reduced.

Fig. 2 is a flowchart of selecting a shelling point according to an embodiment of the present invention, and as shown in fig. 2, the method includes:

201. a function arrival path is selected.

202. The shelling point was selected.

In the embodiment of the present invention, selecting a shelling point specifically includes: an Execute function, dexfile object, or Execute switch impl is selected as the shelling point.

In the embodiment of the invention, two methods for Android to execute Java under ART in the Android 8.1.0 version are provided, one is a Quick code mode, and the other is an Interpreter mode. The two modes are chosen by using _ Interpreter _ entrypoint parameter in PerformmCall function, and if the value is true, the Interpreter mode is entered. Entering the immediate mode in the Quick code mode requires passing through the art _ Quick _ to _ immediate _ bridge function. The execution method used for compiling only influences the running speed of the application and does not influence whether an interpreter is finally used when the program is executed. Both methods eventually enter the Execute function, but we eventually choose an Execute switchimpl function that enters slightly later than it, where the shelling can theoretically be deeper than the Execute function execution path-degree.

Google gradually discards the Goto jump table starting from Andriod 7.0 in the default way to implement the interpreter implementation until its shadow is not visible after version 8.0, starting to have the default way to use the assembly interpreter all the time. Java methods are closely related to Native layers, and the important thing is the ArtMethod object. For a function with an Artmethod object, there is an API (Application Programming Interface, abbreviated API; also called Application Programming Interface) in the source code: getDexFile, the DexFile object to which it belongs can be obtained. The DexFile object is internally provided with a Begin () method and a Size () method which are used for acquiring the start address and the file Size of the corresponding Dex file in the memory respectively. If a Java method needs to be executed, it must be interpreted by an interpreter, and the only way in this process is to enter the Execute function in the source code of the interpreter.

If the reinforcement vendor does not disable dex2oat when loading the shell with DexClassLoader, then only the initialization function will run in interpreted mode. If dex2oat is disabled, then the initialization function and other functions are both running in interpretation mode. Since such an initialization function is irrelevant to the presence or absence of the disabled dex2oat by the reinforcement manufacturer, it will always run in the interpretation mode, which will inevitably enter the ART interpreter. As can be seen from the above, the initialization function of the class also enters the Execute function.

The selection of the shelling points also has good and bad points, the good shelling points can allow all the App added with shells to enter the shelling process, and the bad shelling points can only meet the requirements of partial reinforcement manufacturers. Since the flow, such as dex2oat, also has a dexfile object, these shells of vendors that disable the dex2oat flow cannot be removed if this is taken as a generic shelling point. Since Execute is an inline function, it is difficult to modify the logic of Execute in hook form, so this is the most fundamental condition that can cope with all vendors' consolidation schemes.

Before entering the Execute, an Enternterpreterfrom invoke function completes the calling of the Execute function, and the function creates a stack frame of a Native part of the Java method on a Native stack; then, the function calls the alloca method to additionally allocate a space on the Native stack frame to store the ShadowFrame stack frame. The Java method and stack frame are then associated: when a Java method is executed by an interpreter, the interpreter stack frame ShadowFrame of the Java method is contained in a Native stack frame of the Java method. The ShadowFrame stack frame is a common pointer variable in android source codes, so that the stack frame can be traced back to an original Java method. In the Dex objects after the android8.0 version, we can obtain some very critical information, such as: how to obtain the Dex object, finding the position of the dexfile object in the source code can be regarded as a 'shelling point', and as an alternative, the Dex object can be obtained by a zero-step direct method: occurring in the parameter, occurring in the return value, occurring in the execution process. As an alternative, it is possible to use a one-step indirect method: and acquiring the dexfile object through the existing ArtMethod object. As an alternative, it is possible to use a two-step indirect method: and acquiring ArtMethod through the existing showframe, and then acquiring the dexfile object.

In the embodiment of the invention, the shelling point of the Execute Switch impl function is a main processing logic function in the Switch mode after the Execute function, and the point is the main shelling point selected by us. Since the function is actually executed when it enters this place, which means that the interpreter starts working, the path of execution is deeper than the Execute function for this shelling opportunity.

According to the technical scheme for selecting the shelling points, the function arrival path and the shelling points are selected, so that a plurality of universal and deep shelling points are found in a complex and changeable source code environment, and the shelling points are found more efficiently.

Fig. 3 is a flowchart of constructing a virtual call chain to call all functions in App according to an embodiment of the present invention, and as shown in fig. 3, the method includes:

301. the call chain entry is set.

In the embodiment of the present invention, the setting of the access to the call chain includes: and constructing necessary parameters and active call chain identifications.

In the embodiment of the invention, this step is to construct a virtual call chain to "trick" the shell, App to let App decrypt the operation of the Dex file before calling it naturally in order to call its function normally. JNI provides a series of interfaces for interaction of Java layer functions and Native layer functions. When a function located in the Java layer needs to be called in a c/c + + function in the Native layer, a method _ id of the function needs to be obtained first, and then the call to the function in the Java layer needs to be completed through a CallObjectMethod function such as that provided in JNI. We focus on a detail that this method _ id parameter will be converted to the ArtMethod object pointer during the call. And calling the function in the Java layer by calling the Invoke function in the ArtMethod class through the ArtMethod object layer by layer. Therefore, we can see that the Invoke method plays a role of an important pivot in JNI, and can also be said to be an entry method for spoofing calls. The method of constructing customized Invoke function logic in source code has become clear: first, a decision is made in the function, and when it is found that it is our own calling method through the passed parameters, the dump of ArtMethod is made and returned directly. Secondly, setting relevant parameters in an Invoke method of the user, and calling the artethod- > Invoke to make the invocation logic which loads all classes and wants by identifying the parameters.

Here we need to construct the necessary parameters, such as self and shorty, which represent the trace labels of the current thread and the current called method respectively, because it is needed to keep two of them valid in the subsequent execution flow, and at the same time, we set up the active call chain identifier additionally, to provide the necessary recognition condition for the subsequent judgment of the function entering the call chain, and the first step before the function construction is to judge the spoofed call chain identifier. Finally Invoke the Invoke method of ArtMethod to begin a "spoof" call

Step 302, entering an Invoke function, constructing parameters in the Invoke function, and returning to the call chain entry after the active call chain completes the call.

In the embodiment Of the invention, the running mode Of the RT belongs to the precompiled AOT (AOT for short), when the Apk is installed, each Java method is compiled into an object code by Dex2OAT, but not a bytecode executed by a virtual machine, but a Dex bytecode still exists in an OAT process, so that the code execution Of the ART supports both a QuickCompiledCode mode and an interpreter mode as well as a JIT execution mode. Invoke may enter OAT optimization, Interpreter mode execution methods. If the current is Interpreter mode, call art:: Interpreter: EnterterInterpreterFromInvoke; if the OAT mode is selected, call art _ quick _ invoke _ stub (stub for short). The EnterInterpretertFromInvote function determines whether a Native or an interpreter executes, and the interpreter is divided into an interpretation mode and a quick mode.

From the LinkCode part of the Android source code, it can be known that whether a class method is executed by an interpreter or directly by a local machine instruction, its Entry point is obtained by the member function getentrypoingfromcompildcode of the ArtMethod class, and the Entry point is not NULL. However, Invoke does not set an address value directly at this point, but rather calls indirectly through stub. This is because ART requires setting some special registers.

Since the interpreter can be set in advance to run in the Swtich mode, the function needing to be recovered is necessarily executed in the interpretation mode, so we only focus on this part of the area. The deepening of the active call chain must firstly grasp an important principle of 'unreal execution', some parameters can be set to be null, but key parameters are still constructed, for example, the position of a receiver parameter is null, and other positions need to be meaningful, so that construction is required according to the execution degree, for example, the self parameter is currentThread, the position of an ArtMethod parameter is this, and the positions of the number of parameters are args static function and args + 1. And at the same time of construction, a mark for identifying the arrival of the active call chain is added at the forefront of the function.

Since we will continue into the enterterpreterfrom invoke function in interpreted mode in order to deepen the active call chain, and we return directly into the original entry of the call chain after the active call chain completes the call, not letting it continue with real execution. If the file is not to be deepened, the Dex file is directly traced back and dumped in the Invoke function according to the API of the ArtMethod, namely the GetDexFile function.

In the embodiment of the invention, Dex2oat is the advanced compiling operation of the Dex file in ART, and as a result, a locally executable ELF file is generated and can be directly executed by a local processor.

Step 303, entering an enterterfrommonvake function, constructing the enterterfrommonvake function, saving the value of the result register after the execution of the Excute, and returning to the Invoke function.

In the embodiment of the invention, the front part of the function of the EnterInterpreterfrom invoke is subjected to parameter push operation, and the last lines really enter the theme: if not, calling Execute, which is the interpreter entry function of ART, and the byte code of Dex is obtained by ArtMethod:: GetCodeItem function, and executed by Execute one by one. ② Native function calls InterpreterJni. InterpreterJni obtains Entry point of native function through GetEntryPointFromJni, jumps and executes.

When constructing the internal logic of the function, namely the EnterterInterpreterFromInvake, some parameters which are firstly transferred by the custom are NULL or are constructed randomly because the real content of the parameters cannot be actually obtained. Since the parameters cannot be truly dereferenced, i.e., the setvregceference method therein cannot be performed, we choose to use SetVReg instead. The principle is that the source code uses SetVReg and SetVRegLong for the passing of parameters in both non-dereferencing cases, without dereferencing the parameters we constructed. It is also stated above that the function that arrives here by entering the active call chain is not a Native function and will eventually enter Execute, so we all need to preserve the execution logic before Execute and ensure that it is completely executed. And after executing the Execute, saving the value of the result register, then throwing out the stack frame print Log and smoothly returning to Invoke of the spoofed call chain.

And step 304, entering an Excute function for construction, returning to a register after the calling is completed, and returning to an EnterterInterpreterfrom invoke function.

In the embodiment of the present invention, if there is Just-In-Time (JIT), JIT In ART is used In combination with AOT, and JIT compiles a quick code corresponding to method, then artinterpreter to computer codec bridge is selected to Execute the corresponding quick code. If these conditions are not met, then an Mterp or Switch type interpreter implementation is selected to interpret execution of the corresponding Dalvik bytecode according to kInterpreterImplKind. ART is implemented using Mterp type interpreters by default, so the executemeterpimpl () function is called to interpret the execution of the Dalvik bytecode in most cases. The Mterp bottom layer is written in assembly language, and although the execution efficiency is high, the change is extremely complicated. The type of interpreter is therefore chosen at the time of construction in the switch approach, because its bottom layer is implemented by C + + code, readability is high and operational space is large.

During construction, GetDexPC () is used for obtaining the execution step number at the initial time, and we choose to jump to ExecuteWitchImpl for execution when the stack frame just starts to execute an instruction. ExecuteWitchImpl is an interpreter function implemented by Switch, and the nature of the C + + implementation makes it very convenient to alter it. When the call is completed, return to the register identified by the spoofed call chain and return to the corresponding location of the enterinterpretrfominvoke.

And step 305, entering an ExcutSwitchImpl function for construction, and returning to an Execute function after the calling is completed.

In embodiments of the present invention, Interpreter works to interpret incoming Java methods in a machine-understandable language to perform operations. Switch implementation is to execute instructions one by one through a pedometer. Firstly, acquiring the number of execution steps in the initial time through GetDexPC () in the ExecuteSwitchImpl; at (ins + dex _ pc) obtains an Instruction statement to be executed; then selecting a case condition to be executed according to the instruction; after the corresponding operation is performed, pass Next _? xx functions jump to the next instruction to be executed, which takes several bytes, are executed this time? Is just a table; after each cycle is executed, the pedometer is reset.

When the method is constructed, a reinforcing idea of the App needs to be analyzed, for example, a goto instruction is executed firstly when a function under certain reinforcement enters shell code, and then parameters needed for decryption are prepared and a decryption method is called by using an invoke-static instruction. Since many vendors are concerned about efficiency, when a function is actually called, its CodeItem is definitely restored and will not be encrypted back. Therefore, if the ArtMethod object is traced back Dex and dumped after the invoke-static is executed, all the internal functions can be completely reserved. Meanwhile, it is also considered that if the first instruction is not a goto command after a certain Java method is converted into an assembly, it means that the method has no execution shell logic and can be directly dumped and returned to Execute.

And step 306, calling a decryption method, and returning to the ExcuteSwitchImpl function after decryption is completed.

In the embodiment of the present invention, each instruction processing after the Java method is converted into assembly language has a PREAMBLE macro, that is, a dexpcmevevent function of instrumentation is called to implement the logic related to the pedometer described above. When explaining the execution, we actually fetch an instruction, find the corresponding assembly implementation in the Switch option through opcode, and then run. Most opcodes contain operations that fetch the next instruction and then jump to execution, eventually forming a loop. However, there are opcodes with special call operations that will open a Java call. This Java call is done by the Doinvoke function, which then records the location where the dex instruction executes and updates into the shadow _ frame. Dolnvoke is a template function that can handle invoke-directinvoke/static/super

Virtual/interface, etc., which is actually a springboard calling a method B in the reinforcement shell from a method A in the original Dex.

Here, the foregoing App reinforcement concept is used to complete the final spoofed call chain, after a goto command is compiled from a function, we enter an invoke-static command, and here call the DoInvoke function to actually execute this Java method of the decryption operation, and annotate the operation that it originally took the next instruction: interrupting its execution flow after the decryption operation is completed, it will not continue to execute the following goto, nop or other commands. And immediately transferring the Java method which is only corresponding to the CodeItem of the ArtMethod after calling the decryption method and returning after the completion. At this time, the program flow interrupts Switch and returns to execute Switch impl, and finally returns to the position of the initial incoming call chain entry to wait for the next Java method to be delivered.

In the technical scheme for constructing the virtual call chain to call all functions in the App, a call chain entry is set, an Invoke function is entered, parameters in the Invoke function are constructed, the call chain entry is returned after the active call chain completes calling, an EnterterInterpreterfrom Invoke function is entered and constructed for the EnterterInterpreterfrom Invoke function, the value of a result register is saved and the Invoke function is returned after Excute is executed, the Excute function is entered and constructed, the register is returned and the EnterInterpreterfrom Invoke function is returned after calling is completed, the ExcutSwitchImpl function is entered and constructed, the Execute function is returned after calling is completed, the call method is decrypted, and the ExcutSwitchImPL function is returned after decryption is completed. The method realizes reinforcement under different scenes by using different reinforcement methods, and deepens the calling of the Java method on a Native layer.

An embodiment of the present invention provides a deception call chain android shelling device, where the device is applied to a computer device, fig. 4 is a schematic structural diagram of the deception call chain android shelling device provided in an embodiment of the present invention, and as shown in fig. 4, the device includes: the first selection module 11 is used for selecting a function arrival path, the second selection module 12 is used for selecting a shelling point, the construction module 13 is used for constructing a virtual call chain to call all functions in the App, and the decryption module 14 is used for the App to finish calling and decrypting the Dex file.

In the embodiment of the present invention, the first selection module 11 is specifically configured to select a Quick code mode or an inter mode and finally enter an execute switch impl function.

In the embodiment of the present invention, the second selection module 12 is specifically configured to select an Execute function, a dexfile object, or an Execute switch impl as a shelling point.

The spoofed call chain android shelling device provided by this embodiment may be used to implement the spoofed call chain android shelling method in fig. 1, fig. 2, and fig. 3, and for specific description, reference may be made to an embodiment of the spoofed call chain android shelling method described above, and a description is not repeated here.

According to the technical scheme provided by the embodiment of the invention, the function arrival path is selected, the shelling point is selected, the virtual calling chain is constructed to call all functions in the App, the App completes the decryption of the Dex file by calling, so that a plurality of universal and deeper shelling points are found in a complex and changeable source code environment, the deception calling chain is constructed as required to carry out java method calling on a Native layer, and the modification cost is reduced.

Fig. 5 is a schematic diagram of a computer device according to an embodiment of the present invention. As shown in fig. 5, the computer device 20 of this embodiment includes: the processor 21, the memory 22, and the computer program 23 stored in the memory 22 and capable of running on the processor 21, where the computer program 23 when executed by the processor 21 implements the method applied to spoof call chain android shelling, which is not described herein for avoiding repetition. Alternatively, the computer program is implemented by the processor 21 to implement the function applied to spoof calling of each model/unit in the chain android shelling device in the embodiment, which is not described herein again to avoid repetition.

The computer device 20 includes, but is not limited to, a processor 21, a memory 22. Those skilled in the art will appreciate that 5 is merely an example of a computing device 20 and is not intended to limit the computing device 20 and may include more or fewer components than those shown, or some of the components may be combined, or different components, e.g., the computing device may also include input output devices, network access devices, buses, etc.

The Processor 21 may be a Central Processing Unit (CPU), other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic device, discrete hardware component, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The storage 22 may be an internal storage unit of the computer device 20, such as a hard disk or a memory of the computer device 20. The memory 22 may also be an external storage device of the computer device 20, such as a plug-in hard disk provided on the computer device 20, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like. Further, the memory 22 may also include both internal storage units of the computer device 20 and external storage devices. The memory 22 is used for storing computer programs and other programs and data required by the computer device. The memory 22 may also be used to temporarily store data that has been output or is to be output.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the embodiments provided in the present invention, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, a division of a unit is merely a logical division, and an actual implementation may have another division, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

Units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.

The integrated unit implemented in the form of a software functional unit may be stored in a computer readable storage medium. The software functional unit 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) or a Processor (Processor) to execute some steps of the methods according to the embodiments of the present invention. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The present invention is not limited to the above preferred embodiments, and any modifications, equivalent substitutions, improvements, etc. within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims

1. A deception calling chain android shelling method is characterized by comprising the following steps:

selecting a function arrival path;

selecting a shelling point;

constructing a virtual call chain to call all functions in App;

app completes the decryption of Dex file.

2. The method of claim 1, wherein selecting a function arrival path specifically comprises:

3. The method according to claim 1, wherein the selecting a shelling point comprises: an Execute function, dexfile object, or Execute switch impl is selected as the shelling point.

4. The method according to claim 1, wherein the constructing of the virtual call chain to call all functions in App specifically comprises:

setting a calling chain entrance;

5. The method of claim 4, wherein the setting the call chain entry comprises: and constructing necessary parameters and active call chain identifications.

6. A deception call chain android shelling device, comprising:

the first selection module is used for selecting a function arrival path;

the second selection module is used for selecting a shelling point;

7. The apparatus of claim 6, wherein the first selection module is specifically configured to:

8. The apparatus of claim 6, wherein the second selection module is specifically configured to:

9. A storage medium comprising a stored program, wherein the program, when executed, controls a device on which the storage medium is located to execute the spoofed call chain android shelling method of any one of claims 1 to 5.

10. A computer device comprising a memory for storing information including program specifications and a processor for controlling the execution of program instructions, wherein the program instructions when loaded and executed by the processor implement the steps of a spoofed call chain android shelling method as claimed in any one of claims 1 to 5.