Android application dynamic test method and system, electronic equipment and storage medium

Abstract

The invention provides an Android application dynamic test method and system, electronic equipment and a storage medium, according to the Android application dynamic test method provided by the invention, instrumentation logic runs at the same authority level as system service, and the limitation that a traditional test tool is limited by application layer authority is broken through. According to the method, key behaviors such as system calling, inter-process communication and underlying resource access can be deeply observed, so that the test coverage rate and the behavior restoration precision are greatly improved, and omnibearing dynamic behavior analysis of the target application is realized. According to the method and the device, deeper and more targeted counter operation can be implemented on the countermeasure detection behavior of the application. Due to the fact that the tested application is usually in a low-permission operation environment and has limited perception capacity on the system bottom layer state, the testing tool can effectively interfere with the detection logic of the tested application by means of hiding root permission characteristics, disguising equipment information characteristics and the like, the probability of identifying the testing environment is reduced, and the stability and the concealment of the testing system are fundamentally improved.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of network security, and in particular to an Android application dynamic testing method and system, an electronic device and a storage medium. BACKGROUND

[0002] With the rapid development of mobile Internet, the Android operating system has become one of the global mainstream mobile operating systems due to its open source and high customizability, and has built a huge and complex mobile application ecosystem. A large number of application developers and third-party service providers continuously develop functions and business innovations around the Android platform, which greatly promotes the diversification and intelligent development of mobile applications.

[0003] However, the openness of the Android platform also brings significant security risks. To prevent application programs from being reverse-engineered, illegally tampered with or copied without authorization, more and more developers introduce anti-analysis techniques in applications. Such anti-analysis techniques can be roughly divided into two categories: one is a protection mechanism for static analysis, common methods include code obfuscation, resource encryption, DEX shell, function renaming, and custom virtual machines or dynamic loading of encrypted logic, etc., to hide the core business logic; the other is a detection mechanism for dynamic analysis, the main goal of which is to identify whether the application is running in a controlled or monitorable environment, such as common simulators, debuggers, test sandboxes or instrumentation environments. Once an abnormal running state is detected, the application usually triggers countermeasures such as forced crashes, exit execution flow, return error data or switch to a disguised behavior to block the behavior analysis path.

[0004] These anti-analysis techniques indeed have a positive significance in improving application security and protecting developer intellectual property rights. However, they are also abused by more and more malicious application developers, becoming a tool for hiding malicious behavior and bypassing behavior detection and security audits. Such behavior significantly increases the difficulty of malicious behavior analysis, making traditional security detection methods ineffective or even completely ineffective when facing target applications with strong anti-analysis capabilities.

[0005] On the other hand, most existing Android dynamic testing tools usually run at the application layer and are limited by the system sandbox mechanism and permission model. These tools often only have access to public API interfaces and are difficult to achieve deep observation of system calls, underlying data flow and interaction with system services, resulting in insufficient coverage of application behavior analysis.

[0006] In summary, the current mobile application dynamic testing field still faces the following key problems that need to be solved:

[0007] (1) Existing dynamic testing tools generally focus on monitoring application behavior, lacking the ability to perceive and process whether the application has adopted anti-technology, whether the test environment has been detected, and whether the analysis behavior has been evaded.

[0008] (2) Anti-technology implementation means is increasingly diversified, and common dynamic testing tools are usually run in an application layer environment with limited permissions, making it difficult to effectively identify and comprehensively counter a variety of complex anti-technologies. SUMMARY

[0009] Therefore, the purpose of the present application is to provide an Android application dynamic testing method, system, electronic device and storage medium to solve the above technical problems.

[0010] To achieve the above purpose, the first aspect of the present application provides an Android application dynamic testing method, comprising:

[0011] Deploying a plug-in logic at different system levels of an Android system;

[0012] Continuously monitoring the state of a target application in the Android system;

[0013] When the target application is detected to be started, starting the plug-in logic and comprehensively monitoring the behavior of the target application at different system levels using the plug-in logic;

[0014] Reserving root permissions of the Android system and hiding root permission features during testing, while disguising device information features.

[0015] In one embodiment, the plug-in logic is deployed at different system levels of the Android system, comprising:

[0016] Deploying a plug-in logic in the Linux kernel of the Android system, the runtime environment of the Android system, and the Binder communication framework of the Android system; wherein the plug-in logic deployed in the Linux kernel of the Android system is used to intercept and record system call behavior triggered by the application, and collect system call names and key parameters; the plug-in logic deployed in the runtime environment of the Android system is used to monitor Java layer method call behavior executed by the application; and the plug-in logic deployed in the Binder communication framework of the Android system is used to capture system service call requests initiated by the application, record call interfaces, service names, request parameters, and return results.

[0017] In one embodiment, the root permission features are hidden, comprising:

[0018] In the Android system construction stage, using a release compilation configuration to remove developer debugging flags and executable files of typical root tools;

[0019] Modify the starting process of the ADB tool to ensure that the root permission channel of the ADB is still retained during the initialization process of the Android system.

[0020] In one embodiment, the device information features are disguised, including:

[0021] Collect the main device models used by real users and related identification information, and write them into a preset configuration file in the system source code directory as the source of the disguised target information.

[0022] During the system construction process, read the content of the configuration file and replace the system-related device identification items with the disguised target values.

[0023] In one embodiment, it further includes:

[0024] Record the behavior data generated during the test process.

[0025] In one embodiment, the behavior data generated during the test process includes:

[0026] In the kernel space, a dedicated log virtual file is created in the proc virtual file system of the Linux kernel, and the collected system calls and related parameter information are written into the dedicated log virtual file by the instrumentation logic.

[0027] In the user space, the captured application behavior information is output to the system log using the standard log interface provided by the Android system.

[0028] In one embodiment, after the root permission of the Android system is retained during testing and the root permission features are hidden, and the device information features are disguised, it further includes:

[0029] When it is detected that the test environment is identified, corresponding countermeasures are developed and deployed through behavior backtracking and implementation mechanism analysis.

[0030] Based on the same inventive concept, the second aspect of the present application provides an Android application dynamic testing system, which includes:

[0031] An instrumentation logic deployment module is used to deploy instrumentation logic at different system levels of the Android system.

[0032] An application state monitoring module is used to continuously monitor the state of a target application in the Android system.

[0033] An application behavior detection module is used to start the instrumentation logic when the target application is detected to be started, and to comprehensively monitor the behavior of the target application at different system levels using the instrumentation logic.

[0034] The countermeasure module is used for reserving root permission of the Android system and hiding the root permission feature during testing, and disguising the device information feature.

[0035] Based on the same inventive concept, a third aspect of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the Android application dynamic testing method of the first aspect.

[0036] Based on the same inventive concept, a fourth aspect of the present application provides a non-transitory computer readable storage medium, which stores computer instructions for causing a computer to execute the Android application dynamic testing method of the first aspect.

[0037] As can be seen from the above, the Android application dynamic testing method provided by the present application breaks through the limitation of traditional testing tools on application layer permission, because the plug-in logic runs at the same permission level as the system service. Compared with existing dynamic testing tools that can only monitor behavior data of public APIs, the present application can deeply observe key behaviors such as system calls, inter-process communication, and underlying resource access, thereby greatly improving testing coverage and behavior restoration accuracy, and realizing all-round dynamic behavior analysis of the target application.

[0038] The present application can implement more in-depth and targeted countermeasures on the application's countermeasure detection behavior. Since the application under test is usually in a low-permission running environment, its perception ability of the system underlying state is limited, therefore, the testing tool can effectively interfere with its detection logic by hiding the root permission feature and disguising the device information feature, thereby reducing the probability of identifying the test environment and fundamentally improving the stability and concealment of the test system. BRIEF DESCRIPTION OF DRAWINGS

[0039] In order to more clearly illustrate the technical solutions in the present application or the related art, the following will briefly introduce the drawings needed to be used in the embodiments or the related art descriptions. Obviously, the drawings in the following description only provide embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor based on these drawings.

[0040] Figure 1 A flowchart of the Android application dynamic testing method provided by an embodiment of the present application;

[0041] Figure 2 A flowchart of the Android application dynamic testing method provided by another embodiment of the present application;

[0042] Figure 3 A schematic diagram of the Android application dynamic testing system provided by another embodiment of the present application;

[0043] Figure 4 The architecture diagram of the Android application dynamic testing system provided for another embodiment of the present application is shown in the figure.

[0044] Figure 5 The schematic diagram of the electronic device for another embodiment of the present application is shown in the figure. DETAILED DESCRIPTION

[0045] In order to make the objectives, technical solutions and advantages of the present application clearer, the present application is further described in detail below with reference to the embodiments and the accompanying drawings.

[0046] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present application should be understood as the common meanings understood by those with ordinary skills in the art to which the present application belongs. The terms "first", "second" and similar terms used in the embodiments of the present application do not represent any order, number or importance, but are only used to distinguish different components. The terms "include", "contain" and similar terms mean that the components or objects before the terms cover the components or objects listed after the terms and their equivalents, and do not exclude other components or objects. The terms "connect" or "connected" and similar terms are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. The terms "upper", "lower", "left", "right" and the like are only used to represent relative positional relationships, and when the absolute positions of the described objects change, the relative positional relationships may also change accordingly.

[0047] Referring to Figure 1 and 2 It is shown that an embodiment of the present application provides an Android application dynamic testing method, which comprises the following steps:

[0048] Step S10, respectively deploying a plug-in logic at different system levels of an Android system;

[0049] Step S20, continuously monitoring the state of a target application in the Android system;

[0050] Step S30, when the target application is monitored to be started, starting the plug-in logic, and comprehensively monitoring the behaviors of the target application at different system levels by using the plug-in logic;

[0051] Step S40, reserving the root permission of the Android system and hiding the root permission feature during testing, and at the same time, disguising the device information feature. In the testing environment, the root permission is reserved to support high permission operations, but at the same time, the existence of the permission is hidden externally to prevent the application from identifying the testing environment as a high-risk or abnormal operation state through environment detection.

[0052] The Android application dynamic testing method provided in the application has the plug-in logic running at the same permission level as the system service, breaking through the limitation of the traditional testing tool being limited to the application layer permission. Compared with the existing dynamic testing tool which can only monitor the behavior data of the public API, the application can deeply observe the system call, inter-process communication, underlying resource access and other key behaviors, thereby greatly improving the test coverage and behavior restoration accuracy, and realizing the all-round dynamic behavior analysis of the target application.

[0053] The application can implement more in-depth and targeted countermeasures on the application's counter-detection behavior. Since the application under test is usually in a low-permission running environment, its perception ability of the system underlying state is limited, therefore the testing tool can effectively interfere with its detection logic by hiding the root permission feature, disguising the device information feature and other means, thereby reducing the probability of identifying the test environment and fundamentally improving the stability and concealment of the test system.

[0054] During the dynamic testing process, in addition to the application under test, there are usually multiple other applications running in the Android system. If the behaviors of all running applications are recorded without distinction, not only will the amount of log data increase, but also the subject of behavior will be difficult to distinguish, increasing the analysis difficulty. At the same time, it will also cause the increase of system performance overhead and many other problems. Therefore, during the testing process, the target test application needs to be marked to ensure that only the behavior of the application is captured, thereby realizing accurate and efficient data collection and avoiding irrelevant behavior interference with the analysis results.

[0055] The startup process of the Android application involves multiple key steps, including process creation, application loading, Activity startup, etc. The whole process relies on the cooperative work between multiple system components (such as Launcher, AMS, Zygote, WMS, etc.) and communicates through Binder to complete the startup.

[0056] In order to mark the application under test, the application is plugged in Zygote and ActivityThread which participate in the application startup process, judges whether the current startup application is the target application, and is responsible for notifying other plug-in points in the system to mark the current process and start the plug-in logic. Specifically, the application is plugged in the com_android_internal_os_Zygote_nativeForkAndSpecialize method in Zygote and the handleBindApplication method in ActivityThread, the former is responsible for creating a process for the application through the fork method, and the latter is used to respond to the bindApplication request of AMS to perform application-level initialization.

[0057] In one embodiment, the step S10 of deploying the instrumentation logic at different system levels of the Android system includes: deploying the instrumentation logic in the Linux kernel of the Android system, in the environment (ART / Dalvik) in which the Android system runs, and in the Binder communication framework of the Android system, respectively.

[0058] The instrumentation logic deployed in the Linux kernel of the Android system is used to intercept and record the system call behavior triggered by the application, including file access, process creation, memory allocation, and other underlying operations, and collect the system call name and its key parameters, such as file path, process ID, and memory address.

[0059] Specifically, the Linux kernel is a core component at the bottom layer of the Android system, responsible for key system functions such as file operations, process management, and memory management. System calls are the main channel for Android applications to interact with the Linux kernel. Application programs run in the user space, while these key system functions are executed in the kernel space by the Linux kernel. In order to use the system functions provided by the kernel, the application needs to complete the conversion between the user state and the kernel state through system calls, and receive the return result after the operation is completed.

[0060] Specifically, the present application uses the debugging interface of the ptrace mechanism to monitor system calls. In the Linux kernel, each thread of an application maintains a set of attributes (flag bits) to record the running state of the thread. Among them, the _TIF_SYSCALL_WORK attribute is used to identify whether the current thread is in a debugging state. When this attribute is set to true, the Linux kernel saves the register state of the current thread in the pt_regs structure, and passes it to the methods syscall_trace_enter and syscall_trace_exit at the entry and exit of the system call execution, respectively. The present application starts ptrace debugging by customizing the flag, and instruments at the methods syscall_trace_enter and syscall_trace_exit to accurately capture the execution process of all system calls, including the system call number and its parameter information, thereby achieving comprehensive monitoring of application behavior.

[0061] The instrumentation logic deployed in the runtime environment of the Android system is used to monitor the Java layer method call behavior of the application execution, including the interpreted execution path and the native compiled code path. The recording content includes method name, call stack, and parameter information, facilitating subsequent behavior backtracking and pattern analysis.

[0062] Specifically, the runtime is a core component in the Android system responsible for executing application code, mainly for the execution of Java code and the interaction between Java code and Native code (C / C++) through JNI. Therefore, all Java code in the Android application is executed through the Android runtime, which makes the Android runtime an ideal instrumentation point for collecting application Java code behavior.

[0063] In the Android runtime, the execution of Java code mainly includes two modes: interpreted execution and native machine code execution. The two key methods related to Java code execution are interpreter::DoCall and ArtMethod::Invoke. The interpreter::DoCall method is responsible for interpreted execution, which directly runs the DEX bytecode generated after Java code compilation. The methods provided by the Android SDK also usually use the interpreted execution method. The ArtMethod::Invoke method is responsible for native machine code execution, which is used to execute JNI calls and reflection calls. The present application realizes comprehensive monitoring of Java method calls in the application by analyzing the corresponding content in the two methods.

[0064] Among them, the instrumentation logic deployed in the Binder communication framework of the Android system is used to capture the application initiated system service call request, record the call interface, service name, request parameter and return result, and reflect the interaction behavior between the application and the system component.

[0065] Specifically, Binder is the most core IPC mechanism in the Android system, which provides an efficient and secure implementation for data interaction between different processes. In the Android system, application programs must communicate with system service processes through Binder to access system service functions. System services not only provide various sensitive data, but also often judge whether the current running environment is abnormal according to the data provided by the system service. The present application realizes the monitoring of application IPC behavior by instrumenting in the Binder framework.

[0066] In order to accurately and comprehensively record the IPC interaction behavior of mobile applications through Binder, the present application chooses to instrument in the BpBinder object in the Native layer. Since Android applications can initiate Binder calls in the Java layer or the Native layer, if only instrumenting in the BinderProxy of the Java layer, IPC behaviors in the Native layer may be missed. In the core method transact of BpBinder, the key information is analyzed to complete the monitoring of IPC behavior.

[0067] In one embodiment, the root permission feature is hidden in step S40, including:

[0068] In step S41, during the Android system building stage, the release compilation configuration is used to remove the executable files of the developer debugging flag and typical root tools (such as the su command); and common root permission related traces are avoided to be exposed.

[0069] In step S42, the starting process of the ADB (Android Debug Bridge) tool is modified to ensure that the root permission channel of the ADB is still retained during the Android system initialization process. The high permission control of the device during the test process is realized, and the judgment of the system root state by the outside is not affected.

[0070] In one embodiment, the device information feature is disguised in step S40, including:

[0071] In step S43, the mainstream device models and related identification information (such as brand, device name, model, etc.) used by real users are collected and written into a preset configuration file in the system source code directory as a disguised target information source;

[0072] In step S44, during the system building process, the configuration file content is read, and the system related device identification items (such as ro.product.model, ro.build.product, etc.) are replaced with the disguised target values. After the building is completed, the device information exposed to the outside of the system will be presented as the target brand model, thereby improving the concealment of the test environment and avoiding being identified as a test device commonly used for security analysis by the application.

[0073] Exemplarily, the test device (such as the Google Pixel series) is disguised as a common brand model widely used in China to avoid the identification of the test device itself and the resulting countermeasures.

[0074] In one embodiment, the Android application dynamic test method in the present application further includes the following steps:

[0075] In step S50, the behavior data generated during the test process is recorded. The recording content covers application behavior data, suspected countermeasure behavior and other information, which provides a basis for subsequent manual analysis, behavior backtracking and strategy updating.

[0076] Since the plug-in logic is respectively deployed in the kernel space and the user space, different log recording methods are used in the two types of running environments in this embodiment to ensure the integrity of the behavior data and the accessibility of the subsequent analysis. Specifically, in step S50, the behavior data generated during the test process is recorded, including the following steps:

[0077] Step S51, in the kernel space, by creating a dedicated log virtual file in the proc virtual file system of the Linux kernel, the inserted logic writes the collected system calls and related parameter information into the dedicated log virtual file; the subsequent analysis module can read the log file content to restore and analyze the underlying behavior.

[0078] Step S52, in the user space, the standard log interface provided by the Android system (including the Log class in the Java layer and the __android_log_print interface in the Native layer) is used to output the captured application behavior information to the system log. The analysis process can extract the behavior records related to the target application by reading the log buffer content, which can be used for subsequent behavior analysis and visual display.

[0079] In one embodiment, after reserving the root permission of the Android system and hiding the root permission feature during testing, and disguising the device information feature, step S40 further includes the following steps:

[0080] Step S60, in the case where the test environment is identified, by behavior backtracking and implementation mechanism analysis, the corresponding countermeasures are formulated and deployed. The stealthiness and effectiveness of the test system are continuously optimized to maintain the stable testing capability of mobile applications in complex confrontation scenarios.

[0081] The high-coverage behavior detection mechanism constructed in the present application can not only be used for behavior analysis, but also has the ability to identify unknown or variant confrontation behaviors. During testing, the system will continuously record abnormal interaction behaviors and potential countermeasure failure behaviors to assist analysts in discovering uncovered confrontation logic. This mechanism helps the tool maintain its updating ability when facing continuously evolving confrontation technologies, ensuring the long-term adaptability of the test system.

[0082] Since the present application uses system insertion technology to monitor mobile application behavior, the overall test mechanism does not rely on traditional dynamic analysis tools, and therefore has very few test environment features in the default running state, significantly reducing the risk of being identified as a test environment by the application. To further enhance the countermeasure capability of the confrontation behavior, the present application also hides and disguises some key environmental features, including root permissions and device identification information, to effectively deal with the application's perception behavior of such information, and improve the stealthiness and stability of the testing process.

[0083] Since the application needs to use root permission when performing part of the test process, and root permission is the most common test environment feature, most normal user devices do not have root permission by default. Therefore, many applications will detect whether the device has been rooted to determine whether the current is in a test environment. The common root permission related countermeasures currently include: detecting whether the system is a test version (user-debug); detecting the presence of root tools and detecting the su command and related files.

[0084] The application adopts a system source code level instrumentation mechanism, allowing detection logic or countermeasures to be inserted in any module of the Android system. Compared with the static function structure of traditional tools, this method has higher customization freedom, and can dynamically expand behavior collection points, adjust instrumentation strategies, or optimize existing countermeasures according to actual test needs, thereby continuously enhancing system test capabilities and countermeasure adaptation capabilities.

[0085] It should be noted that the method of the embodiments of the application can be executed by a single device, such as a computer or a server. The method of the embodiments can also be applied to a distributed scenario, and completed by multiple devices cooperating with each other. In this distributed scenario, one of the multiple devices can only execute one or more steps in the method of the embodiments of the application, and the multiple devices can interact with each other to complete the method.

[0086] It should be noted that some embodiments of the application have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in a different order than the order described above and still achieve the desired result. In addition, the processes depicted in the figures do not necessarily require the particular order shown or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing can be advantageous or possible.

[0087] Based on the same inventive concept, corresponding to any of the above-mentioned embodiment methods, the application also provides an Android application dynamic test system, as shown in Figure 3 and 4 The system includes the following modules:

[0088] An instrumentation logic deployment module is configured to deploy instrumentation logic at different system levels of the Android system respectively;

[0089] An application state monitoring module is configured to continuously monitor the state of a target application in the Android system;

[0090] The application behavior detection module is configured to start the plug-in logic when the target application is detected to be started, and to comprehensively monitor the behavior of the target application at different system levels by using the plug-in logic.

[0091] The countermeasure behavior module is configured to retain the root permission of the Android system and hide the root permission feature during testing, and to disguise the device information feature.

[0092] In order to counter the above root permission detection method, the application selects a release version as the test environment during system compilation. The release version is the official system version and does not have root permission, so there is no su command in the system, effectively avoiding the test of the application on the root-related files and system version. In order to still be able to use the root permission to perform necessary operations during testing, the application modifies the initialization process of the ADB tool. In the initialization process, the ADB tool will first perform the regular initialization work, such as external communication initialization, permission authentication, etc. Then, in the original logic, the ADB tool reduces itself from the root level permission to the normal permission through the drop_privileges method to ensure security. In order to be able to use the root permission through the ADB tool during testing, the application modifies the implementation of the drop_privileges method to skip the downgrade operation, thereby maintaining the root permission of the ADB process. Since this method modification occurs at the system level, the countermeasure behavior cannot detect it, and thus cannot identify whether the device has root permission, thereby achieving countermeasures.

[0093] In addition, since the system plug-in tool of the application is implemented by customizing the AOSP source code, the AOSP system only supports running in a few devices, and the application selects the Google Pixel phone as the test platform because it is the most convenient to use. However, the number of users using Pixel devices in China is extremely small. At the same time, Pixel devices have become the first choice for security researchers because they support device unlocking and can flash AOSP custom systems. Therefore, some applications will identify whether the device is produced by Google or is a commonly used model for security analysis by obtaining device information when detecting the running environment, and will determine whether the current running environment has potential risks accordingly. In the Android system, mobile applications obtain device information mainly through the fields in the android.os.Build class or by accessing specific system properties. In fact, the fields in the android.os.Build class are also obtained by accessing system properties. Applications can determine the device brand, model, manufacturer, and even identify whether the device is running on an AOSP system by using the information stored in these system properties, and then decide whether to take corresponding protection measures.

[0094] In order to counter the device information-based running environment detection method, the application modifies the configuration file information in the system source code before AOSP system compilation, replacing all device information-related content with the corresponding content of a popular domestic brand device. The application specifically selects OnePlus ACE 3V as the camouflage target, and camouflages the key system attributes of the test device as the real values of this model. By modifying the system compilation configuration, all applications that call the android.os.Build class or read system attributes to obtain device information will identify the test device as a common OnePlus device, thereby bypassing device model detection and avoiding application crashes or function limitations due to abnormal running environment. If necessary, the application also provides a flexible configuration mechanism to camouflage the device deploying the tool as a device of other brands or models, further enhancing the evasion ability of the countermeasures.

[0095] Further, the Android application dynamic testing system of the application also includes a log module for recording behavior data generated during testing.

[0096] Specifically, in the kernel space, a dedicated log virtual file is created in the proc virtual file system of the Linux kernel, and the inserted logic writes the collected system calls and related parameter information into the dedicated log virtual file; the subsequent analysis module can read the log file content to restore and analyze the underlying behavior. In the user space, the captured application behavior information is output to the system log using the standard log interface provided by the Android system (including the Log class in the Java layer and the __android_log_print interface in the Native layer). The analysis process can extract the behavior records related to the target application by reading the log buffer content, which can be used for subsequent behavior analysis and visualization.

[0097] Further, the Android application dynamic testing system of the application also includes a user interaction module to simplify the interaction process between the user and the testing tool, providing a unified operation interface and control interface to improve the usability and configuration flexibility of the tool. It supports multiple core functions, including test task configuration, test target application installation and management, test process control, test result display, and metadata information query, making it easy for users to centrally manage the testing process and analyze the results. Specifically, the following aspects are included:

[0098] Test target setting: The tool provides a test target selection interface, allowing users to import the application to be tested (such as an APK file) through a graphical interface and automatically complete the relevant initialization settings, preparing for the testing phase.

[0099] Test application installation: After the user confirms the test target, the tool automatically installs the application in the test environment and completes the necessary system configuration to ensure that the inserted logic can correctly bind the application under test.

[0100] Test management: The tool provides a unified test control interface, supporting user operations such as starting, pausing, and terminating test tasks, and setting key parameters such as whether to enable automated testing, test duration, and whether to retain test applications.

[0101] Test result display: After the test is completed, the tool automatically organizes and analyzes the collected behavior data and presents the test results through a graphical interface, helping users quickly identify abnormal behavior or potential risks.

[0102] Metadata query: To facilitate in-depth analysis of test results by users, the tool provides a detailed data query interface, supporting users to access complete behavior data recorded during the test, including behavior timestamps, call types, parameter contents, and other metadata information.

[0103] The Android application dynamic testing system in this embodiment has the beneficial effects of the method embodiments described above, and will not be repeated here.

[0104] Based on the same inventive concept, the present application also provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor executes the program to implement the Android application dynamic testing method of any one of the embodiments.

[0105] Figure 5 A more specific hardware structure of an electronic device is shown, which can include a processor 1101, a memory 1102, an input / output interface 1103, a communication interface 1104, and a bus 1105. The processor 1101, the memory 1102, the input / output interface 1103, and the communication interface 1104 are connected to each other through the bus 1105 for communication within the device.

[0106] The processor 1101 can be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, etc., for executing related programs to implement the technical solutions provided by the embodiments of the present specification.

[0107] The memory 1102 can be implemented in the form of a ROM (Read Only Memory), a RAM (Random Access Memory), a static storage device, a dynamic storage device, etc. The memory 1102 can store an operating system and other application programs, and when the technical solutions provided in the embodiments of the present specification are implemented by software or firmware, the related program codes are stored in the memory 1102 and are called and executed by the processor 1101.

[0108] The input / output interface 1103 is configured to connect an input / output module to realize information input and output. The input / output module can be configured as a component in the device (not shown in the figure) or can be externally connected to the device to provide corresponding functions. The input device can include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device can include a display, a speaker, a vibrator, an indicator light, etc.

[0109] The communication interface 1104 is configured to connect a communication module (not shown in the figure) to realize the communication interaction between the device and other devices. The communication module can realize communication through a wired manner (such as USB, network cable, etc.) or through a wireless manner (such as mobile network, WIFI, Bluetooth, etc.).

[0110] The bus 1105 includes a channel for transmitting information between various components (such as the processor 1101, the memory 1102, the input / output interface 1103, and the communication interface 1104) of the device.

[0111] It should be noted that although the above device only shows the processor 1101, the memory 1102, the input / output interface 1103, the communication interface 1104, and the bus 1105, in the specific implementation process, the device can also include other components necessary for normal operation. In addition, those skilled in the art can understand that the above device can also only contain the components necessary to implement the embodiments of the present specification, and does not have to contain all the components shown in the figure.

[0112] The electronic device of the above embodiments is used to implement the corresponding Android application dynamic testing method in any of the preceding embodiments, and has the beneficial effects of the corresponding method embodiments, which are not described here.

[0113] Based on the same inventive concept, corresponding to any of the above method embodiments, the present application also provides a non-transitory computer readable storage medium storing computer instructions for causing the computer to execute the Android application dynamic testing method according to any of the above embodiments.

[0114] The computer readable media of the embodiments can include permanent and non-permanent, removable and non-removable media, which can be implemented by any method or technology to store information. The information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device, or any other non-transmission medium that can be used to store information accessible by a computing device.

[0115] The storage medium of the above embodiments stores computer instructions for causing the computer to execute the Android application dynamic testing method as described in any of the above embodiments, and has the beneficial effects of the corresponding method embodiments, which are not described here.

[0116] Those skilled in the art should understand that the discussion of any of the above embodiments is only exemplary and is not intended to imply that the scope of the present application (including claims) is limited to these examples; the above embodiments or technical features between different embodiments can also be combined, the steps can be implemented in any order, and there are many other changes of the different aspects of the embodiments of the present application as described above. In order to be brief, they are not provided in detail.

[0117] In addition, in order to simplify the description and discussion, and so as not to make the embodiments of the present application difficult to understand, the well-known power / ground connections of integrated circuit (IC) chips and other components can or can not be shown in the provided drawings. In addition, the devices can be shown in the form of block diagrams in order to avoid making the embodiments of the present application difficult to understand, and this also takes into account the fact that the details of the implementation of these block diagram devices are highly dependent on the platform to be implemented the embodiments of the present application (i.e. these details should be fully within the understanding of those skilled in the art). Where specific details (e.g. circuits) are set forth in order to describe the exemplary embodiments of the present application, it will be apparent to those skilled in the art that the embodiments of the present application can be implemented without these specific details or with variations of these specific details. Therefore, these descriptions should be considered illustrative rather than limiting.

[0118] While the present application has been described in connection with certain embodiments thereof, many modifications, substitutions, changes, and of forms will be apparent to those of ordinary skill in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) can use the embodiments discussed.

[0119] Embodiments of the present application are intended to cover all such alternatives, modifications, and variations as come within the scope of the appended claims. Accordingly, any and all such alterations, omissions, equivalents, improvements, and the like are intended to be encompassed by the present application.

Claims

1. A method for dynamic testing of Android applications, characterized in that, include: Deploy instrumentation logic at different system levels within the Android system; Continuously monitor the status of the target application in the Android system; When the target application is detected to be starting, the instrumentation logic is activated, and the instrumentation logic is used to comprehensively monitor the behavior of the target application at different system levels; During testing, root permissions of the Android system are preserved and root permission characteristics are hidden, while device information characteristics are disguised.

2. The Android application dynamic testing method according to claim 1, characterized in that, The deployment of instrumentation logic at different system levels in the Android system includes: Instrumentation logic is deployed in the Linux kernel of the Android system, the Android system runtime environment, and the Android system Binder communication framework, respectively. The instrumentation logic deployed in the Linux kernel of the Android system is used to intercept and record the system call behavior triggered by the application, and to collect the system call name and its key parameters. The instrumentation logic deployed in the Android system runtime environment is used to monitor the Java layer method call behavior executed by the application. The instrumentation logic deployed in the Binder communication framework of the Android system is used to capture the system service call requests initiated by the application, and to record the call interface, service name, request parameters, and return results.

3. The Android application dynamic testing method according to claim 1, characterized in that, The process of hiding root permission features includes: During the Android system build phase, a release build configuration is used to remove developer debugging flags and executable files for typical root tools; Modify the startup process of the ADB tool to ensure that the root permission channel of ADB is still preserved during the Android system initialization process.

4. The Android application dynamic testing method according to claim 1, characterized in that, The spoofing of device information features includes: Collect mainstream device models and related identification information used by real users, and write them into a preset configuration file in the system source code directory as a disguised target information source; During system construction, the contents of the configuration file are read, and the system-related device identification items are replaced with spoofed target values.

5. The Android application dynamic testing method according to claim 1, characterized in that, Also includes: Record behavioral data generated during the testing process.

6. The Android application dynamic testing method according to claim 5, characterized in that, The recorded behavioral data generated during the testing process includes: In the kernel space, a dedicated log virtual file is created in the Linux kernel's proc virtual file system, and the instrumentation logic writes the collected system call and related parameter information into the dedicated log virtual file. In user space, the captured application behavior information is output to the system log using the standard logging interface provided by the Android system.

7. The Android application dynamic testing method according to claim 1, characterized in that, The method of preserving Android system root privileges and hiding root privilege characteristics during testing, while also disguising device information characteristics, further includes: If the test environment is detected to be identified, corresponding countermeasures are formulated and deployed through behavior backtracking and implementation mechanism analysis.

8. An Android application dynamic testing system, characterized in that, include: The instrumentation logic deployment module is used to deploy instrumentation logic at different system levels of the Android system. The application status monitoring module is used to continuously monitor the status of target applications in the Android system; The application behavior detection module is used to activate the instrumentation logic when the target application is detected to start, and to use the instrumentation logic to comprehensively monitor the behavior of the target application at different system levels. The countermeasure module for adversarial behavior is used to preserve the root privileges of the Android system and hide the characteristics of the root privileges during testing, while also disguising the characteristics of device information.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the Android application dynamic testing method as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to execute the Android application dynamic testing method according to any one of claims 1 to 7.

Images