KR102683445B1 - Method for android malicious app record and replay, recording medium and device for performing the method - Google Patents

Abstract

The present invention relates to a method for recording and re-executing an Android malicious app, and a recording medium and device for performing the same.
A method of recording and re-executing an Android malicious app according to the present invention includes the steps of receiving a command from a user to record or re-execute; Changing the process state to a record or re-execution state in response to the input command; When the target app to be analyzed is executed by the user, determining the currently set state; If the determined currently set state is a recording state, recording the content of the app being executed by the user, and if it is a re-execution state, opening the recorded file and re-executing the app according to the contents of the file; and terminating execution of the target app after the recording and re-execution are completed.

Description

Method for recording and rerunning Android malicious apps, recording medium and device for performing the same {METHOD FOR ANDROID MALICIOUS APP RECORD AND REPLAY, RECORDING MEDIUM AND DEVICE FOR PERFORMING THE METHOD}

The present invention relates to a method of recording and re-executing Android malicious apps, a recording medium and device for performing the same. More specifically, it relates to a method for recording and re-executing malicious apps by recording and re-executing the API used to detect the execution environment of Android. It relates to methods for recording and re-running Android malicious apps, and recording media and devices for doing so.

Record & Replay tools for smartphone apps are very important in app development, from bug replay to systematic stability testing. However, existing Android platform-based app recording and rerunning tools cannot record and rerun Android APIs, making it difficult to rerun apps that perform different operations depending on the execution environment.

The Android malicious app dynamic analysis tool is a tool that analyzes Android malicious code by executing suspected malicious code in a safe environment called a sandbox consisting of an emulator. It is mainly used in a rooted environment because it requires elevated privileges to analyze internal operations. Perform malicious app analysis. However, recent Android malicious apps have disabled many existing analysis tools by applying detection evasion and anti-analysis techniques to hide their malicious behavior from analysis tools.

In order to efficiently analyze malicious apps with analysis evasion techniques applied, it is necessary to reproduce the malicious behavior of the malicious app in a rooting or emulation environment where existing dynamic analysis tools operate. However, existing Android-based record and replay tools cannot record and replay some APIs that malicious apps use to detect Android's execution environment.

Therefore, it is necessary to develop an Android malicious app recording and re-execution tool that can record and re-execute malicious apps by also recording and re-executing the API (Application Programming Interface) used to detect Android's execution environment.

The technology behind the present invention is disclosed in Republic of Korea Patent Publication No. 10-2271269 (announced on June 29, 2021).

The technical problem to be achieved by the present invention is to record and re-execute the API used to detect Android's execution environment to record and re-execute malicious apps, thereby modifying the Android platform code of the Android Open Source Project (AOSP) to The purpose is to provide a method for recording and rerunning Android malicious apps that can record target apps running without rooting or hooking, as well as recording media and devices for doing so.

In addition, it is intended to provide a method for recording and rerunning an Android malicious app that receives a user command to distinguish the target app process from other processes and sets the recording and re-execution status of the target app process, and a recording medium and device for performing the method.

In addition, a method for recording and re-running Android malicious apps that records and re-executes malicious apps with analysis evasion techniques applied by recording and re-executing interactions between the target app and the user, and interactions between the target app and other apps, a recording medium for performing this, and This is to provide a device.

A method of recording and re-executing an Android malicious app according to an embodiment of the present invention to achieve this technical problem includes receiving a command from a user to record or re-execute; Changing the process state to a record or re-execution state in response to the input command; When the target app to be analyzed is executed by the user, determining the currently set state; If the determined currently set state is a recording state, recording the content of the app being executed by the user, and if it is a re-execution state, opening the recorded file and re-executing the app according to the contents of the file; and terminating execution of the target app after the recording and re-execution are completed.

At this time, the step of changing the process state to a record or rerun state involves modifying the Android Activity Manager to process the input command, and calling a method to change the record and rerun state by modifying the zygote process. The process state can be changed to record or re-execution state.

In addition, when the determined currently set state is the recording state, the event contents occurring outside the target app executed by the user are recorded in the API (Application Programming Interface) call information file, and the touch generated by the user's touch is recorded in the API (Application Programming Interface) call information file. Events are recorded in real time to record interactions between the target app and the user, and the intent received by the target app and the time the intent is received are recorded to receive broadcasts sent through the intent object. By recording events, you can record interactions between the target app and other apps.

In addition, when the determined currently set state is a recording state, the routine environment is detected by searching the number (su) file of the target app executed by the user, and the API call information called by the malicious app is recorded each time it is detected, The API that checks the existence of a file, the API that checks the specified package information, the API that retrieves the value of the specified attribute, and the buffer read API used to check the execution result of the cell command can each be recorded.

In addition, if the determined currently set state is a re-execution state, the target app is re-executed as recorded, but the event that occurs outside the target app executed by the user is reproduced and re-executed, or the API called by the target app is performed. The operation flow can be modified and re-executed.

Additionally, a computer program for performing the method of recording and re-executing the Android malicious app may be recorded on a computer-readable recording medium according to another embodiment of the present invention.

In addition, an Android malicious app recording and re-executing device according to another embodiment of the present invention includes a command input unit that receives either a recording or re-executing command from the user; a state change unit that changes the process state to a record or re-execution state in response to the input command; A state determination unit that determines the currently set state when the target app to be analyzed is executed by the user; And if the determined currently set state is in the recording state, the content of the app being executed by the user is recorded, and if it is in the re-execution state, the recorded file is opened and the app is re-executed according to the contents of the file, and after the recording and re-execution are completed, the app is executed. Includes an execution unit that terminates execution of the target app.

At this time, the state change unit processes the input command by modifying the Android activity manager, and modifies the zygote process to change the process state to the record or re-execution state by calling a method to change the recording and re-execution state. You can.

In addition, when the determined currently set state is the recording state, the executing unit records event contents occurring outside the target app executed by the user in an API (Application Programming Interface) call information file, and Touch events that occur are recorded in real time to record the interaction between the target app and the user, and the intent received by the target app and the time at which the intent is received are recorded, and the intent sent through the intent object is recorded. By recording broadcast reception events, interactions between the target app and other apps can be recorded.

In addition, if the determined currently set state is the record state, the execution unit detects the routine environment by searching the number (su) file of the target app executed by the user, and provides API call information called by the malicious app whenever detected. You can record the API that checks the existence of a file, the API that checks the specified package information, the API that gets the value of the specified attribute, and the buffer read API that is used to check the execution result of the cell command.

In addition, if the determined currently set state is a re-execution state, the executing unit re-executes the target app according to the recorded contents, but reproduces and re-executes an event that occurs outside the target app executed by the user or re-executes the target app. The operation flow of the calling API can be modified and re-executed.

In this way, according to the present invention, the API used to detect Android's execution environment is recorded and re-executed to record and re-execute the malicious app, thereby modifying the Android platform code of the Android open source project to execute it without rooting or hooking the device. This has the effect of recording the target app and then using the recorded execution flow to re-execute the malicious app in an execution environment different from the recording stage, thereby preventing the malicious app from hiding its malicious behavior in the analysis environment.

Additionally, according to the present invention, in order to distinguish the target app process from other processes, a user command can be received and the recording and re-execution status of the target app process can be set.

Additionally, according to the present invention, it is possible to record and re-execute malicious apps to which analysis evasion techniques have been applied by recording and re-executing interactions between the target app and the user, and interactions between the target app and other apps.

Figure 1 is a block diagram showing a device for recording and re-executing Android malicious apps according to an embodiment of the present invention.
Figure 2 is a diagram illustrating the command processing flow in the Android malicious app recording and re-executing device according to an embodiment of the present invention.
Figure 3 is a diagram illustrating a process in which a command input from a device for recording and re-executing an Android malicious app according to an embodiment of the present invention is transmitted to Zygot.
Figure 4 is a diagram illustrating prevention of duplicate intent reception in a device for recording and re-executing Android malicious apps according to an embodiment of the present invention.
Figure 5 is a flowchart showing the operational flow of a method for recording and rerunning an Android malicious app according to an embodiment of the present invention.
Figure 6 is an example diagram showing the results of a WaTFBank app experiment according to a method for recording and rerunning Android malicious apps according to an embodiment of the present invention.
Figure 7 is an example diagram showing the results of a RootBeer app experiment according to a method for recording and rerunning Android malicious apps according to an embodiment of the present invention.

Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the attached drawings. In this process, the thickness of lines or sizes of components shown in the drawings may be exaggerated for clarity and convenience of explanation.

Additionally, the terms described below are terms defined in consideration of functions in the present invention, and may vary depending on the intention or custom of the user or operator. Therefore, definitions of these terms should be made based on the content throughout this specification.

Hereinafter, preferred embodiments of the present invention will be described in more detail with reference to the drawings.

First, a device for recording and re-executing Android malicious apps according to an embodiment of the present invention will be described through FIGS. 1 to 4.

Figure 1 is a block diagram showing a device for recording and re-executing Android malicious apps according to an embodiment of the present invention.

As shown in Figure 1, the Android malicious app recording and re-execution device 100 according to an embodiment of the present invention includes a command input unit 110, a state change unit 120, a state determination unit 130, and an execution unit 140. Includes.

First, the command input unit 110 receives a command, either record or re-execute, from the user.

And the state change unit 120 changes the process state to a record or re-execution state in response to the command input through the command input unit 110.

In detail, the Android activity manager is modified to process commands input through the command input unit 110, and the zygote process is modified to call a method to change the recording and re-execution status to record or re-execute the process status. Change to

Figure 2 is a diagram illustrating the command processing flow in the Android malicious app recording and re-executing device according to an embodiment of the present invention.

As shown in FIG. 2, the state change unit 120 processes commands input from the user by modifying the Activity Manager, which has the function of executing apps as a system service that manages Android activities. . At this time, the processing flow of the activity manager command (am command) entered by the user is shown in Figure 2.

Figure 3 is a diagram illustrating a process in which a command input from a device for recording and re-executing an Android malicious app according to an embodiment of the present invention is transmitted to Zygot.

As shown in FIG. 3, the state change unit 120 is installed in the Java Layer of the Activity Manager Service subclass where the actual operation of the activity manager is implemented to set the recording and re-execution states and set state check commands. Add member variables that store the recording and re-execution status, and implement methods to change and check the values of the added member variables. The command to run the app in the configured state is implemented by calling a method that changes the recording and re-execution status of the Zygote process and calling the command to run the app in the Agility Manager.

At this time, the Zygot process creates a process for the app to be executed when the app is executed on the Android platform. If you run the app after changing the recording and re-execution status of the Zygot process, the target app process is forked by Zygot and has the same state as the Zygot process. At this time, the flow of the activity manager command (am command) sent to Zygot through the activity is shown in Figure 3.

And when the target app to be analyzed by the user is executed, the state determination unit 130 determines the currently set state.

Finally, if the currently set state determined by the determination unit 130 is a recording state, the execution unit 140 records the content of the app being executed by the user, and if it is a re-execution state, the execution unit 140 opens the recorded file and executes the app according to the contents of the file. Re-executes and terminates execution of the target app after recording and re-execution are completed.

In detail, if the currently set state determined by the determination unit 130 is a record state, the execution unit 140 records the event contents that occur outside the target app executed by the user in an API (Application Programming Interface) call information file. It records the interaction between the target app and the user by recording touch events generated by the user's touch in real time.

In other words, a touch event refers to a touch that occurs when a user runs an app, and it is desirable to record the interaction between the target app and the user by recording the user's touch in real time.

In addition, when the currently set state determined by the determination unit 130 is the recording state, the execution unit 140 records the intent received by the target app and the time at which the intent was received, and creates an intent object. It records interactions between the target app and other apps by recording broadcast reception events sent through .

In other words, a broadcast reception event means receiving a notification delivered by another app, such as receiving SNS. Since this notification is sent through an intent object, the intent received by the target app and the intent received It is desirable to implement this by recording time.

Additionally, the execution unit 140 records interactions between the target app and the user, interactions between the target app and other apps, and APIs used to detect Android's execution environment.

At this time, device files are used to record interactions between the target app and the user. The app can interact with input devices by calling standard input/output system calls, and read device files to record input events from input devices such as keyboard and mouse. You can also record it. You can also record interactions between the target app and the user by using the getevent tool supported by the Android SDK to obtain information about the input device and a real-time dump of kernel input events.

Additionally, the execution unit 140 uses a broadcast message received by the target app to record interactions between the target app and other apps. By registering a broadcast receiver to receive specific broadcasts, Android apps can receive and use information such as SMS reception and system time changes from system services. Since the broadcast message is wrapped in an intent object, the intent received by the target app and the uptime at the time the intent is received are recorded.

In addition, when the currently set state determined by the determination unit 130 is a record state, the execution unit 140 searches the su file of the target app executed by the user to detect a routine environment, and detects a malicious environment whenever detected. Record the API call information called by the app, including the API that checks the existence of a file, the API that checks the specified package information, the API that gets the value of the specified property, and the buffer read API used to check the execution result of the cell command. Record each.

In addition, if the determined currently set state is a re-execution state, the execution unit 140 re-executes the target app according to the recorded contents, but reproduces and re-executes events that occur outside of the target app executed by the user or re-executes the target app. The operation flow of the calling API can be modified and re-executed.

In detail, re-execution of the execution flow of a malicious app can be divided into two types: reproduction of events that occur outside the target app and reproduction of the Android API called by the target app.

First, an event reproduction tool is implemented to reproduce events that occur outside the target app. At this time, the target app re-executes the interaction between the app and the user and the interaction between the target app and other apps by receiving external events reproduced by the event reproduction tool.

Additionally, the event reproduction tool reads the interactions between the app and the user and between the target app and other apps from the file, calculates the time interval in which each interaction was recorded, and delivers the reproduced external events to the target app.

At this time, if the interaction to be reproduced is an interaction between the app and the user, the interaction between the reproduced app and the user is recorded in the device file. If the interaction to be reproduced is an interaction between the target app and another app, the interaction recorded through the activity manager is recorded. Restore the tent and broadcast it to the target app. At this time, if the recorded intent is delivered to the target app as is, the target app can receive the intent reproduced by the event reproduction tool and the intent broadcast by the system.

Figure 4 is a diagram illustrating prevention of duplicate intent reception in a device for recording and re-executing Android malicious apps according to an embodiment of the present invention.

As shown in Figure 4, in order to prevent duplicate reception of intents, when the target app registers a broadcast receiver in the re-execution state, it registers the operation of the intent it wants to receive with a specific prefix. In addition, the same prefix is attached to the action of the intent broadcasted by the event reproduction tool to distinguish it from the intent broadcasted by the system.

At this time, when the target app receives the intent broadcasted by the event reproduction tool, the prefix is removed from the operation of the received intent to prevent the operation of the intent changed during the intent transmission and reception process from affecting the operation of the target app. do.

In addition, the execution unit 140 modifies the API used to determine whether a malicious app is rooted and detects an emulator, and when the target app calls the corresponding API, the execution unit 140 reads the recorded API information without performing the operation of the existing API. Changes the execution results of the called API and the values that affect the API execution.

Hereinafter, a method of recording and re-executing an Android malicious app according to an embodiment of the present invention will be described with reference to FIGS. 5 to 7.

Figure 5 is a flowchart showing the operational flow of a method for recording and re-running an Android malicious app according to an embodiment of the present invention. With reference to this, the specific operation of the present invention will be described.

According to an embodiment of the present invention, the command input unit 110 first receives a command, either record or re-execute, from the user (S10).

Next, the state change unit 120 changes the process state to a record or re-execution state in response to the command input in step S10 (S20).

In detail, the Android Activity Manager is modified to process the command entered in step S10, and the zygote process is modified to change the process state to record or rerun state by calling a method to change the record and rerun state.

During the recording and re-executing process, recording and re-executing the operations of all processes without distinguishing between the processes of the target app not only has a large overhead, but is also impossible. Therefore, in an embodiment of the present invention, the state of the executing target app process is set to one of three states, such as a record state, a re-execution state, and a basic state, to distinguish the target app process from other processes, and to perform a recording operation according to the state of the target app process. You can distinguish between executing or re-executing tasks.

In order to set the recording and re-execution status, the embodiment of the present invention uses the Android debug bridge to receive commands input by the user from an external device as an example, but is not limited to this. Commands used to set the record and rerun status include commands to set the record and rerun status, check the set status, and run the app with the set status.

Next, the status determination unit 130 determines whether the target app to be analyzed by the user is executed (S30).

As a result of the determination in step S30, if the target app has been executed, the state determination unit 130 determines the currently set state (S40).

At this time, if the currently set state determined in step S40 is a recording state, the execution unit 140 records the content of the app being executed by the user (S50).

In detail, the contents of events that occur outside of the target app run by the user are recorded in an API (Application Programming Interface) call information file, and touch events generated by the user's touch are recorded in real time to connect the target app and the user. Record interactions.

In addition, the intent received by the target app and the time it receives the intent are recorded, and a broadcast reception event sent through the intent object is recorded to record interactions between the target app and other apps.

According to an embodiment of the present invention, the execution unit 140 records the execution flow of the target app that is executed without rooting or hooking the device by modifying the Android platform code of the Android Open Source Project (AOSP). can do.

In other words, since the Android platform does not require permission to use the app's internal storage, files for re-execution used during the recording process are stored in the app's internal storage.

In addition, the routine environment is detected by searching the number (su) file of the target app executed by the user, and upon detection, the API call information called by the malicious app is recorded, and the API that checks the presence or absence of the file, specified package information You can also record the API that checks, the API that gets the value of the specified property, and the buffer read API that is used to check the execution result of the cell command.

In other words, the malicious app determines whether the device is rooted by checking the system properties changed due to rooting, the presence or absence of a binary number file related to rooting, and whether apps related to rooting are installed, and determines whether the device is rooted or not by checking the unique properties of the emulator or the emulator on the host PC. To execute, the emulator is detected using the added module information.

Therefore, in an embodiment of the present invention, the execution unit 140 modifies the API used to determine whether a malicious app is rooted and detects an emulator, and records the call information along with the operation of the existing API when the target app calls the corresponding API. do. The information recorded includes the execution results of the called API and the values that affect the API execution.

And, if the currently set state determined in step S40 is a re-execution state, the execution unit 140 opens the recorded file and re-executes the app according to the contents of the file (S60).

In detail, the target app is re-executed as recorded, but events occurring outside the target app executed by the user are reproduced and re-executed, or the operation flow of the API called by the target app is modified and re-executed.

When recording and re-execution are completed in steps S50 and S60, the execution unit 140 ends execution of the target app (S70).

In an embodiment of the present invention, in order to check whether the API used to detect Android's execution environment can be recorded and re-executed, two apps (WaTFBank app and RootBeer app) that determine the Android's execution environment by calling a specific API are targeted. The experiment was conducted.

Figure 6 is an example diagram showing the results of the WaTFBank app experiment according to the method for recording and rerunning Android malicious apps according to an embodiment of the present invention, and Figure 7 is a diagram showing the RootBeer app according to the method for recording and rerunning Android malicious apps according to an embodiment of the present invention. This is an example drawing showing the results of the experiment.

In an embodiment of the present invention, the API for checking the existence of a file, the API for checking the specified package information, the API for getting the value of the specified attribute, and the buffer read API used for checking the execution result of the shell command were modified, and each experiment confirmed that the target app had a different execution flow by recording and re-executing the modified API.

First, for the two apps (WaTFBank app and RootBeer app) that call the modified API as shown in Figures 6 and 7, the general execution result (a) and the method for recording and re-executing Android malicious apps according to an embodiment of the present invention are shown. By checking that the output of (b) is different when used, you can confirm that the modified API is properly re-executed.

To explain this in detail, first, the WaTFBank app shown in Figure 6 checks whether it is rooted by calling the "API that checks the existence of a file" to check the presence or absence of a su file, and performs different executions depending on whether it is rooted. This is an app that displays a screen. If it is not in a rooted environment, a screen waiting for user input is displayed. If it is in a rooted environment (when an su file is found), it prints a message saying that it was run in a rooted environment.

At this time, in the general execution result (a), it was confirmed that the user's input was waiting, and in the re-execution result (b) according to an embodiment of the present invention, it was confirmed that the phrase that it was executed in a rooted environment was output.

In addition, the RootBeer app shown in Figure 7 is an app that checks rooting through various methods, and in the Root Management App inspection, it called "API to check specified package information" to check whether apps related to rooting were installed. In the 2nd SU Binary check, the "buffer Read API used to check the execution results of shell commands" is called, the execution results of the binary file (su) related to routing are received, and the existence of the number file is checked. As a result, the general execution result (a ), the result was output that there was no problem in the Root Management App, 2nd SU Binary check, and in the re-execution result (b) according to the embodiment of the present invention, it was confirmed that the result was output that there was a problem in the Root Management App, 2nd SU Binary check. You can.

Through this, it can be confirmed that the method for recording and rerunning Android malicious apps according to an embodiment of the present invention prevents malicious apps from hiding their malicious behavior in the analysis environment.

This method of recording and re-executing Android malicious apps can be implemented as an application or in the form of program instructions that can be executed through various computer components and recorded on a computer-readable recording medium. The computer-readable recording medium may include program instructions, data files, data structures, etc., singly or in combination.

The program instructions recorded on the computer-readable recording medium may be specially designed and configured for the present invention, or may be known and usable by those skilled in the computer software field.

Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks and magnetic tapes, optical recording media such as CD-ROMs and DVDs, and magneto-optical media such as floptical disks. media), and hardware devices specifically configured to store and perform program instructions, such as ROM, RAM, flash memory, etc.

Examples of program instructions include not only machine language code such as that created by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like. The hardware device may be configured to operate as one or more software modules to perform processing according to the invention.

As described above, the method for recording and re-executing Android malicious apps according to an embodiment of the present invention records and re-executes the malicious app by recording and re-executing the API used to detect the execution environment of Android, thereby recording and re-executing the Android platform code of the Android open source project. Modify to record target apps running without rooting or hooking the device, and then use the recorded execution flow to re-run the malicious app in a different execution environment than the recording phase, so that the malicious app does not hide its malicious behavior in the analysis environment. You can prevent it.

Additionally, according to an embodiment of the present invention, in order to distinguish the target app process from other processes, a user command can be received and the recording and re-execution status of the target app process can be set.

Additionally, according to an embodiment of the present invention, it is possible to record and re-execute malicious apps to which analysis evasion techniques have been applied by recording and re-executing interactions between the target app and the user, and interactions between the target app and other apps.

The present invention has been described with reference to the embodiments shown in the drawings, but these are merely illustrative, and those skilled in the art will understand that various modifications and other equivalent embodiments are possible therefrom. will be. Therefore, the true technical protection scope of the present invention should be determined by the technical spirit of the patent claims below.

100: Device for recording and rerunning Android malicious apps
110: Command input unit
120: Status change unit
130: Status judgment unit
140: execution department

Claims (11)

In a method of recording and rerunning an Android malicious app performed by a device for recording and rerunning an Android malicious app,
Receiving either a record or re-execute command from the user;
Changing the process state to a record or re-execution state in response to the input command;
When the target app to be analyzed is executed by the user, determining the currently set state;
If the determined currently set state is a recording state, recording the content of the app being executed by the user, and if it is a re-execution state, opening the recorded file and re-executing the app according to the contents of the file; and
Comprising: terminating execution of the target app after the recording and re-execution are completed,
The step of changing the process state to record or rerun state is,
Android malicious app records and changes the process state to the record or rerun state by modifying the Android activity manager to process the input command and modifying the zygote process to call a method to change the record and rerun state. How to redo. delete According to paragraph 1,
If the currently set state determined above is a recording state,
Events that occur outside of the target app executed by the user are recorded in an API (Application Programming Interface) call information file,
Touch events generated by the user's touch are recorded in real time to record the interaction between the target app and the user,
An Android malware that records interactions between the target app and other apps by recording the intent received by the target app and the time the intent was received, and recording broadcast reception events sent through the intent object. How to record and rerun apps. According to paragraph 1,
If the currently set state determined above is a recording state,
Detect the routine environment by searching the su file of the target app executed by the user, and record the API call information called by the malicious app each time it is detected.
A method of recording and re-executing Android malicious apps that records the API that checks the existence of a file, the API that checks the specified package information, the API that gets the value of the specified property, and the buffer read API that is used to check the execution result of the cell command. According to paragraph 1,
If the currently set state determined above is a rerun state,
Re-executes the target app as recorded, but records and re-executes Android malicious apps that reproduce and re-execute events that occur outside of the target app executed by the user, or modify the operation flow of the API called by the target app and re-execute it. method. A computer-readable recording medium on which a computer program is recorded, for performing the method of recording and re-executing an Android malicious app according to any one of claims 1 and 3 to 5. a command input unit that receives either a record or re-execute command from the user;
a state change unit that changes the process state to a record or re-execution state in response to the input command;
a state determination unit that determines the currently set state when the target app to be analyzed is executed by the user; and
If the determined currently set state is in the recording state, the content of the app being executed by the user is recorded. If it is in the re-execution state, the recorded file is opened and the app is re-executed according to the contents of the file, and after the recording and re-execution are completed, the target Includes an execution part that terminates execution of the app,
The state change unit,
Android malicious app records and changes the process state to the record or rerun state by modifying the Android activity manager to process the input command and modifying the zygote process to call a method to change the record and rerun state. Redo device. delete In clause 7,
The executive department,
If the determined currently set state is a recording state, the event contents occurring outside the target app executed by the user are recorded in an API (Application Programming Interface) call information file,
Touch events generated by the user's touch are recorded in real time to record the interaction between the target app and the user,
An Android malware that records interactions between the target app and other apps by recording the intent received by the target app and the time the intent was received, and recording broadcast reception events sent through the intent object. App recording and relaunch device. In clause 7,
The executive department,
If the determined currently set state is a recording state, the routine environment is detected by searching the number (su) file of the target app executed by the user, and the API call information called by the malicious app is recorded whenever detected,
An Android malicious app recording and re-execution device that records the API that checks the existence of a file, the API that checks the specified package information, the API that gets the value of the specified property, and the buffer read API that is used to check the execution result of the cell command. In clause 7,
The executive department,
If the currently set state determined above is the re-execution state, re-execute the target app according to the recorded contents,
An Android malicious app recording and re-execution device that reproduces and re-executes events that occur outside of the target app executed by the user, or modifies and re-executes the operation flow of the API called by the target app.