CN114090440A

CN114090440A - An integrated source-free debugging method based on Android operating system

Info

Publication number: CN114090440A
Application number: CN202111381511.9A
Authority: CN
Inventors: 钱科铭
Original assignee: Guangzhou Lianan Technology Co ltd
Current assignee: Guangzhou Lianan Technology Co ltd
Priority date: 2021-11-21
Filing date: 2021-11-21
Publication date: 2022-02-25
Anticipated expiration: 2041-11-21
Also published as: CN114090440B

Abstract

The invention discloses an integrated source code-free debugging method based on an android operating system, which comprises the following steps of: 1) intelligently installing and updating a program to be debugged; 2) activating a debugging mode; the debugging switch is turned on at the system level by directly modifying an environmental variable ro.debug in the system; 3) starting and configuring a program to be debugged; 4) identifying the type of a variable; 5) source code level debugging based on decompilation; the method provides a whole set of automatic debugging process, takes ADB as a medium, realizes the installation, the activation of debugging mode, the starting and the addition to the program to be debugged, the breakpoint setting, the breakpoint variable identification and the like of software in a full-automatic way under the condition that only a software package without a software source code exists, and has the functions of supporting the execution of the breakpoint code, rewriting the variable content and the like in the manual debugging process.

Description

Integrated source code-free debugging method based on android operating system

Technical Field

The invention relates to an integrated source code-free debugging method based on an android operating system.

Background

Since the appearance of Android in 2008, the market share of Android is steadily increasing, and mobile operating systems such as Symbian and Windows Phone are directly caused to exit from the historical stage. However, such a mainstream mobile operating system has not been a good debugging tool for Android programs for many years. At present, the Android field of source code-free debugging still is in a relatively primitive and crude state. From a mobile phone to a computer, debugging can be really started, and various complicated steps are arranged in the middle. From the connection of the ADB, the opening of the debug port, the starting of the debug mode, the installation of the program to be debugged, and the like, each step consumes the effort and time of the debugger. Even if debugging is started formally, in the case of passive code debugging, the lack of variable type information makes debugging difficult. The prior technical scheme not only needs a debugger to do various preparation works in advance, but also has no graphical interface in the debugging process, each debugging operation needs the debugger to directly input a corresponding debugging command at a terminal, the debugging output can only be displayed at the terminal, multi-window interaction cannot be realized, and the debugging efficiency is low due to various factors.

Therefore, it is necessary to find a debugging method that can automatically build the debugging environment required by researchers and provide various important auxiliary functions during the debugging process.

Disclosure of Invention

In view of this, the present invention aims to provide an automatic debugging method, which uses ADB as a medium, can fully automatically implement installation of software, activate a debugging mode, start and attach to a program to be debugged, breakpoint setting, breakpoint variable identification, etc. in the case of only a software package without software source code, and has functions of supporting breakpoint code execution, rewriting variable content, etc. in a manual debugging process.

In order to solve the technical problems, the technical scheme of the invention is as follows:

an integrated source code-free debugging method based on an android operating system comprises the following steps:

1) intelligently installing and updating a program to be debugged;

calculating a hash value of a program to be debugged, comparing the hash value with the hash value of the existing program in the system, and if and only if the two hash values are not equal, namely the content of the program to be debugged is changed, replacing the old program with a new program to be debugged and installing the new program to the target equipment;

2) activating a debugging mode;

the debugging switch is turned on at the system level by directly modifying the environmental variable ro.debug in the system, so that the processing can avoid any change to the software package, ensure the integrity of the software package and simultaneously successfully debug the program;

3) starting and configuring a program to be debugged;

after the debugger is successfully attached, waiting for hundreds of milliseconds again, and assuming that the configuration related to debugging is finished in the period of time, releasing the suspension of the program, and according to the setting made in the interface in advance by the user, performing operations such as breakpoint setting and the like on the transient window through JDWP to ensure that the opportunity is not delayed;

4) identifying the type of a variable;

the method comprises the steps that a function is divided into blocks, so that once a program is executed to a block under the condition that every block code removes a throwing exception, codes of the whole block are executed without omission, and after function blocks are divided, the blocks are connected according to the transfer direction of an execution flow to construct the relation between the blocks; after the blocking is finished, the static single assignment processing is carried out, the SSA generally uses a subscript mode to represent a new variable, whenever a variable on a Dalvik layer is assigned, a subscript counter of the register is increased by one, the current counter value is used for the subscript of the new SSA variable, the control flow in the form of Dalvik byte codes has unequal variables in the register and the function, and a dynamic mapping relation is formed between the variables and the register; in the process of constructing the SSA form of the function, the SSA introduces a function named Phi, which has the functions of showing that the function is selected from the two different registers and introducing a new SSA variable, when the Phi function is sufficient and reasonably added into an SSA chart, the construction of the SSA is completed, a function offset and a register are given, the variable type corresponding to the value of the register at the moment can be found out, in the debugging process, a breakpoint can be randomly set, the variable type of each register is analyzed in real time after the breakpoint is triggered, and the effective value of each register is read in real time by matching with a debugging protocol;

5) source code level debugging based on decompilation;

the source code level debugging based on the decompilation result can be realized by matching with a decompilation module, the source code level debugging can be realized as long as the mapping relation between the Dalvik control flow and the decompilation source code exists, and the seamless switching between the source code level debugging and the Dalvik instruction level debugging can be realized.

The technical effects of the invention are mainly reflected in the following aspects: the invention provides a whole set of automatic debugging process, which takes ADB as a medium, can fully automatically realize the installation of software, activate debugging modes, start and attach to a program to be debugged, set breakpoints, recognize breakpoint variables and the like under the condition that only a software package is available without software source codes, and also has the functions of supporting the execution of breakpoint codes, rewriting variable contents and the like in the manual debugging process. The debugger designed according to the scheme has the performance superior to various products on the market, can automatically build a debugging environment required by researchers, and provides various important auxiliary functions in the debugging process.

Drawings

Fig. 1 is a flowchart of an integrated source code-free debugging method based on an android operating system.

Detailed Description

The following detailed description of the present invention is provided in conjunction with the accompanying fig. 1 to make the technical solution of the present invention easier to understand and grasp.

Examples

Android (Android) is one of the mainstream mobile phone operating systems nowadays, Android Debug Bridge (ADB) is the most common debugging suite in the Android operating system, and provides various practical functions such as software installation and uninstallation, shell operation, port forwarding and the like, and a bytecode named Dalvik supported by the Android refers to a bytecode of a Java Virtual Machine (JVM) and changes a stack machine structure into a set of instruction set based on a register, so that the Dalvik and the JVM have a common place in many places, a debugging Protocol Java Debug Wire Protocol (JDWP) used by the Java virtual machine is also adopted by the Android, even along with the development of the Android, the Dalvik virtual machine is replaced by an Android Runtime (ART), and the dalv still supports each Android program as a set of instruction set, and never exits from the JDWP.

1) intelligent installation and update of program to be debugged

The content of the program to be debugged is not fixed. In some cases, a debugger may patch the debuggee program. In this case, the patched program needs to be reinstalled on the Android device. However, the procedure may also be constant at all times. If reinstallation is required once before each debug, many minutes of installation time will significantly reduce debug efficiency. The scheme calculates the hash value of the program to be debugged, and compares the hash value with the hash value of the existing program in the system. If and only if the two hash values are not equal, that is, the content of the program to be debugged is changed, the new program to be debugged will replace the old program and be installed on the target device. Therefore, time expenditure caused by unnecessary installation is saved, and debugging personnel can be ensured to debug the latest version.

2) Activating a debug mode

Xml files of a software package that is released do not generally identify itself as debug (debuggable). If an Android program is not marked as debug, the program cannot be debugged. There are generally two solutions to this situation. One is repackaging. The advantage of this approach is that compatibility is good, and debug mode can be activated by patching xml for any software package. However, this method has a practical limitation. Android requires that all packages need to be signed, and the signature is hooked to the integrity of the package, so patching means that the entire package needs to be re-signed. Many software on the market can check the signature of the own software package in the running process to ensure that the own software package is not tampered, and the repackaging mode can trigger the detection. The solution adopts another way to turn on the debug switch at the system level by directly modifying the environment variable ro. The processing can avoid any change to the software package, ensure the integrity of the software package and successfully debug the program.

3) Starting and configuring program to be debugged

Apparently, to start a program, the target program can be started simply by sending a command through the ADB. However, from the viewpoint of debugging, there are many cumbersome steps in the middle of the program to be debugged from the start up to the state where the user can debug. Generally, a debugger will want to break down a program as early as possible to prevent the code fragments to be debugged from running out at the instant the program is running. In this case, the program to be debugged needs to be started in a halt mode by the ADB. A program started in this mode is in a suspended state and waits for the attachment of a debugger. However, it is not sufficient to wait for an attach, and even if the attach is done, the program runs directly without any break points. In addition, limited by the debugging protocol, the Android device side does not have any means to know that the debugging personnel has already done all preparations for debugging. Therefore, on the device side, when the debugger is found to be successfully attached, it will wait for only a few hundred milliseconds again, and it is assumed that the configuration related to debugging has been completed in this period of time, and the program is released from being suspended. According to the scheme, according to the setting made in the interface by the user in advance, the operations such as breakpoint setting and the like are carried out in the short window through JDWP, and the opportunity is ensured not to be delayed.

4) Variable type identification

The difficulty in debugging the Dalvik program is determining the variable type. When debugging a program based on Dalvik byte codes, if the content of a register is to be acquired by a debugging protocol, the variable type of the variable needs to be provided by the debugger. The program with debugging information compiled in the conventional development attaches the information, so that various variables can be displayed smoothly in the debugging process. However, for various reasons, the debugger does not necessarily have this debugging information. In this case, if one register is to be fetched, only two schemes remain.

Scheme one directly specifies the variable type as the original data type (native type) regardless of the program context. This way, although the value in this register can be retrieved, the information retrieved is likely to be meaningless. For example, the register actually stores an object (object), but the debugger reads the object through the original type int, and the obtained register value is a pointer to the object. This is of no interest to the researcher, since what the researcher wants is necessarily the item it points to, not the pointer itself.

The other scheme is that the context of the program is firstly analyzed and understood, the variable type of the register at the moment is known, and then the content of the register is obtained according to the variable type through a debugging protocol. This approach can correctly return what the researcher wishes to obtain. However, this practice is labor intensive. Although the variable type of a single-position single register in a certain function can be solved by means of manpower analysis, debugging is dynamic, the position where a program is executed changes at any time, and the variable type also changes. Even if the high-intensity manual analysis can be endured, the manual error cannot occur in the analysis process.

If the variable type is directly specified as an object, the server side of the debug protocol will use the value of this register as an object pointer to read the object contents when the register is encountered that actually stores the original type. Since the value of this register itself is not a legal pointer, in most cases it will cause illegal memory operation and cause the debuggee program to crash directly. Even with a very low probability, the value of this register happens to be a valid pointer in fact, and the contents of the read object are erroneous. Therefore, this scheme does not hold.

The first step of the analysis is to block the function so that, in the case of removing the throw exception, once the program executes to the block, the code of the whole block will be executed without omission. There are three main cases in Dalvik where the program execution flow can be changed. One is conditional jumps, such as if-eqz instructions, to the target address if the source register value is zero. The second case is a switch instruction. The packed-switch and the spare-switch in Dalvik can determine the target address of the jump by looking up the jump table according to the value of the source register. The third case is capture of an anomaly. If a trap of an exception is registered somewhere inside the function (i.e., the try block) and such an exception is thrown there, then the execution of the function will be carried over directly from where the exception was thrown to the corresponding exception handling code. In the above cases, the address reached when the function execution flow changes is an entry of a code block. And when this code block executes an entry to the next code block, this means here the end of this code block. After the function blocks are divided, the blocks are connected according to the transfer direction of the execution flow to construct the relationship between the blocks.

After the blocking is completed, a Static Single Assignment (SSA) process is performed. In the SSA concept, one variable will and will only be assigned once and each variable must be assigned before use. SSA generally represents a new variable using a subscript. Whenever a variable (i.e., register) at the Dalvik level is assigned, the index counter of this register is incremented by one and the current counter value is used for the index of the new SSA variable. For example, "x ═ 10; x is 20; "will become" x1 ═ 10; x2 ═ 20 ".

Control flow in the form of Dalvik bytecode with unequal variables in registers and functions. From a compilation point of view, developers can theoretically define an infinite number of variables, but in fact the number of valid registers is limited. That is, there is a dynamic mapping between variables and registers. For example, when the Dalvik compiler finds that a variable in the function is no longer used after it is executed somewhere, even if the life cycle of the variable in the source code is not yet over, the compiler's optimization flow will recognize this virtually shorter life cycle and mark the corresponding register as free where the actual life of the variable is over. The actual life cycle of the variable at this stage, i.e. from the last assignment of the variable until the end of its life, can be mapped to the register in which it is stored. Thereafter, if new variables need to be defined, the program will still occupy this register even if the old variables remain alive from the source point of view.

In constructing the SSA form of the function, there is a very central concept, namely the Phi function. If there are no jumps in a function, the construction of the SSA form is simple. Whenever a variable is reassigned, the life cycle of the variable ends in the SSA, and a new variable is generated. However, if there are branches in the function that jump, there is a place in the function to join. If a register is assigned separately in two branches, and then the two branches are merged and used, there is no way to determine from which branch the value of the register came at the point of this merge. In this case, SSA introduces a function named Phi. Its role is to indicate that a selection is made from these two different registers and to introduce a new SSA variable.

For a simple control flow graph, where the Phi function needs to be added is obvious. However, when the control flow has a certain complexity, it becomes difficult to find a place where the Phi function needs to be inserted. To solve this problem, the Dominance Front (DF) in graph theory is required. DF is a collection of nodes. Given a node, its DF indicates that if the program is to run to the direct 12 (IDOM) node of a DF node, the program must first pass through the given node. This property of DF exactly matches the Phi function mentioned above. If node N defines a variable V, then node N's DF is queried. And if the DF corresponding to the node N is not empty, inserting Phi functions into the nodes in each DF. DF can be calculated by referring to "effective computing static simple assignment form and the control dependency graph" (Cytron et al, 1991).

When the Phi function is sufficient and reasonably added to the SSA graph, the construction of the SSA is complete. The goal of the present stage is to find where the contents of this register are defined at this moment, given a function offset and a register. Since the register is used at this location, the variable index of the register used here in the SSA can be directly known, and the definition is looked up from the SSA by this index.

When the definition and the use of the variable can find out the reference relation through SSA, the next step is formally started to process related to the variable type. After the definition is found by the SSA, in the assignment statement, there are two cases, type determinable or type indeterminable, for the content on the right side of the equal sign. For the former, such as the variable definition is derived from the Dalvik instruction const, then the type of this variable is the native integer type. If the source is an instruction such as move-result-object or new-instance, the type of the variable is an object and not a native variable type. For the case where the type is indeterminate, the right side of the assignment statement is a Phi function. In this case, it is necessary to recursively process the parameters in the Phi function, and perform the definition query again for each variable appearing in the parameters. In this case, the final search may have a plurality of definitions. For example, a switch is used in the source code, and an assignment is performed to the same variable in each case block, and this variable is used after the entire switch is ended. In the SSA, there is a Phi function in the common successor node of each case node corresponding to the switch, and each variable included in the parameter of the Phi function is derived from the assignment statement in these case nodes respectively. If the same variable type is used for the definitions of these variables, then it is possible to determine the variable returned by Phi, which type is also consistent with the type of its respective parameter. Theoretically, when the variable types of the Phi function parameters are not uniform, the types of the variables returned by Phi cannot be determined. However, the compiler itself also needs to determine the type of a variable, otherwise the program may crash. Thus, under normal circumstances, the various definitions resulting from such recursive lookup should be of the same type.

The entire analysis process flow is now complete. Given a function offset and a register, the variable type corresponding to the value of the register at this time can be found through the above process. In the debugging process, breakpoints can be set at will, the variable types of the registers are analyzed in real time after the breakpoints are triggered, the effective numerical values of the registers are read in real time by matching with a debugging protocol, and the debugging efficiency is effectively improved.

5) Source code level debugging based on decompilation

By matching with another matched decompilation module, the scheme can realize source code level debugging based on a decompilation result. As long as the mapping relation between the Dalvik control flow and the decompiling source code exists, the scheme can realize source code level debugging and can realize seamless switching between the source code level debugging and the Dalvik instruction level debugging.

It will be evident to those skilled in the art that the invention is not limited to the details of the foregoing illustrative embodiments, and that the present invention may be embodied in other specific forms without departing from the spirit or essential attributes thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.

Furthermore, it should be understood that although the present description refers to embodiments, not every embodiment may contain only a single embodiment, and such description is for clarity only, and those skilled in the art should integrate the description, and the embodiments may be combined as appropriate to form other embodiments understood by those skilled in the art.

Claims

1. an integrated source-free debugging method based on Android operating system, is characterized in that, comprises the following steps:

1) Intelligent installation and update of the program to be debugged;

Calculate the hash value of the program to be debugged, and compare it with the hash value of the existing program in the system, if and only if the two hash values are not equal, that is, the content of the program to be debugged changes, and the new program to be debugged changes. It will replace the old program and install it on the target device;

2) Activate debug mode;

By directly modifying the environment variable ro.debuggable in the system and turning on the debug switch at the system level, this process can avoid any changes to the software package, ensure the integrity of the software package, and at the same time successfully debug the program;

3) The startup and configuration of the program to be debugged;

When it is found that the debugger is successfully attached, wait for hundreds of milliseconds, and assume that the configuration related to debugging has been completed during this time, and release the suspension of the program. According to the settings made by the user in the interface in advance, in this short period of time The window of the window is set by JDWP for breakpoints and other operations to ensure that the timing will not be delayed;

4) Variable type identification;

The function should be divided into blocks, so that each block of code will be executed without omission once the program executes to the block, except that the exception is thrown. After dividing the function block, it is necessary to Connect these blocks according to the transfer direction of the execution process to build the relationship between blocks; after the block is completed, static single assignment processing is required. SSA generally uses subscripts to represent new variables. Whenever the Dalvik level When the variable above is assigned, the subscript counter of this register will be incremented by one, and the current counter value will be used for the subscript of the new SSA variable. The control flow in the form of Dalvik bytecode, the register and the variable in the function are not equal, There is a dynamic mapping relationship between variables and registers; in the process of constructing the function SSA form, SSA introduces a function named Phi, its role is to choose from these two different registers, and introduce a new When the Phi function is sufficiently and reasonably added to the SSA chart, the construction of SSA is completed. Given a function offset and a register, the variable type corresponding to the value of this register can be found at this time. During debugging, breakpoints can be set at will, and after the breakpoint is triggered, the variable type of each register can be analyzed in real time, and the effective value of each register can be read in real time with the debugging protocol;

5) Source-level debugging based on decompilation;

With the decompilation module, source-level debugging based on decompilation results can be realized. As long as there is a mapping relationship between Dalvik control flow and decompiled source code, source-level debugging can be realized, and source-level debugging and Dalvik instruction-level debugging can be realized. Switch seamlessly.