Security analysis test method for android application

Abstract

This invention provides a security analysis and testing method for Android applications. The method involves generating a target operation request from the target Android application and sending it to the kernel layer; then, based on the eBPF virtual machine, acquiring and analyzing the response information to obtain the security analysis and testing results of the target Android application. In this method, the eBPF program is registered and executed in the kernel, allowing for high-performance tracing of the target Android application and acquisition of response information at the kernel level. This enables the determination of the security analysis and testing results for the target Android application. Because the kernel layer and application layer are well isolated, kernel-level processing traces cannot be detected at the application layer, thus achieving high-performance and highly covert analysis and testing.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a security analysis and testing method for Android applications. Background Technology

[0002] In an era of rapid information and digital development, the rapid iteration of operating systems and their application ecosystems has become a core driving force for technological change. This is especially true for mobile terminal operating systems. Android, with its open-source nature, high customizability, and a vast application ecosystem built by global developers, has become one of the most influential operating systems in the mobile internet era. However, its security situation is far from optimistic. The Android platform, due to its openness, is more vulnerable to malware attacks. Traditional methods for analyzing and testing the security of Android applications are mainly divided into static and dynamic approaches. Firstly, regarding static analysis, developers can hide the actual program code through hardening and obfuscation techniques. Traditional static analysis methods struggle to penetrate obfuscation or hardening layers to capture the actual execution logic, severely hindering static analysis. Furthermore, since dynamic analysis and testing are generally built upon static analysis, hardening and obfuscation techniques also significantly impede dynamic analysis and testing of applications. In summary, traditional Android application security analysis and testing techniques have faced varying degrees of resistance, severely hindering the analysis and testing of Android applications. Summary of the Invention

[0003] The purpose of this invention is to provide a security analysis and testing method for Android applications, so as to achieve high-performance and highly covert analysis and testing.

[0004] This invention provides a security analysis and testing method for Android applications. The method is applied to an electronic device running an Android operating system. The Android operating system includes a kernel layer and an application layer that are isolated from each other. The kernel layer has an eBPF virtual machine, and an eBPF program is loaded in the eBPF virtual machine. The application layer includes multiple Android applications. The method includes: generating a target operation request through a target Android application; sending the target operation request to the kernel layer; obtaining response information associated with the target operation request based on the eBPF program in the eBPF virtual machine; and obtaining the security analysis and testing result of the target Android application by analyzing the response information.

[0005] Furthermore, the target operation request is either a file operation request or a privacy information acquisition request. The step of obtaining response information associated with the target operation request based on the eBPF program in the eBPF virtual machine, and analyzing the response information to obtain the security analysis test result of the target Android application, includes: determining the target system call corresponding to the target operation request; attaching a trace point to the target system call to obtain the system call parameters and system call return data corresponding to the target operation request through the eBPF program in the eBPF virtual machine; analyzing the system call parameters to obtain the operation analysis result corresponding to the system call return data; determining whether there is any abnormal behavior in the operation behavior related to the system call return data based on the operation analysis result, and obtaining a judgment result; and determining the security analysis test result of the target Android application based on the judgment result.

[0006] Furthermore, the step of obtaining the system call parameters and system call return data corresponding to the target operation request through the eBPF program in the eBPF virtual machine includes: before executing the target system call, calling a pre-registered first callback function through the eBPF program in the eBPF virtual machine to track the system call parameters corresponding to the target operation request according to the first callback function; calling the target system call to execute the processing logic corresponding to the target system call; and after completing the call to the target system call, calling a pre-registered second callback function through the eBPF program in the eBPF virtual machine to track the system call return data corresponding to the target operation request according to the second callback function.

[0007] Furthermore, before executing the target system call, the step of calling a pre-registered first callback function through the eBPF program in the eBPF virtual machine to track the system call parameters corresponding to the target operation request according to the first callback function includes: before executing the target system call, determining whether the target operation request meets preset filtering parameters; wherein, the preset filtering parameters include: system call number, user identifier filtering event; if the target operation request meets the preset filtering parameters, the pre-registered first callback function is called through the eBPF program in the eBPF virtual machine to track the system call parameters corresponding to the target operation request according to the first callback function.

[0008] Furthermore, the target operation request is a privacy information acquisition request. The steps of obtaining response information associated with the target operation request based on the eBPF program in the eBPF virtual machine, and analyzing the response information to obtain the security analysis test results of the target Android application include: calling a preset Framework API, sending the privacy information acquisition request to a designated service matching the privacy information acquisition request via the Framework API using the Binder mechanism, so as to obtain the response information associated with the privacy information acquisition request through the designated service; during the process of sending the privacy information acquisition request to the designated service via the Framework API using the Binder mechanism, calling a preset binder_transaction kernel function, collecting entry parameter information through a probe at the entry point of the binder_transaction kernel function; obtaining the entry parameter information and associated information by calling a preset static instrumentation function; saving the entry parameter information and the associated information to the eBPF Map; and analyzing the response information, the entry parameter information, and the associated information according to a preset privacy and security analysis method to obtain the security analysis test results of the target Android application.

[0009] Furthermore, the method also includes: using the eBPF program in the eBPF virtual machine to trace specified key functions used by the target Android application during its operation using probes, so as to capture specified pointers when the specified key functions are executed; extracting code association information of the executable code corresponding to the target Android application based on the specified pointers; wherein the code association information includes: address information and size information; sending the code association information to a user-space program, so that the user-space program can obtain the executable code based on the code association information and save it to a preset disk, thereby confirming that the target Android application has been unpacked.

[0010] Furthermore, the method also includes: setting a probe at a specified location in the dynamic link library of the target Android application based on the probe mechanism of the eBPF virtual machine; when the target Android application executes to the specified location, jumping to execute a pre-registered eBPF exception handler to obtain a processing result, so as to determine the dynamic instrumentation test result of the target Android application based on the processing result.

[0011] Furthermore, the method also includes: injecting a specified error into the target Android application through the eBPF virtual machine according to a preset error injection mechanism, so that when the target Android application makes a specified system call, it returns a specified return value corresponding to the specified error.

[0012] Furthermore, the method also includes: querying the user identification information, process name, and preset blocking policy corresponding to the target Android application through an eBPF Map; comparing the user identification information and the process name with the preset blocking policy respectively to obtain a comparison result; and returning a specified error code if the comparison result indicates that there is an illegal behavior.

[0013] Furthermore, the step of obtaining the security analysis test result of the target Android application by analyzing the response information includes: if both the target operation request and the response information are encrypted, obtaining the location information of a preset exported function, and setting a probe at a first location indicated by the location information; when the target Android application executes to the first location, obtaining the plaintext corresponding to the target operation request and the plaintext of the response information associated with the target operation request based on the eBPF program in the eBPF virtual machine; and obtaining the security analysis test result of the target Android application by analyzing the plaintext corresponding to the target operation request and the plaintext of the response information.

[0014] The security analysis and testing method for Android applications provided by this invention generates a target operation request from the target Android application and sends it to the kernel layer; it then obtains and analyzes the response information based on the eBPF virtual machine to obtain the security analysis and testing results of the target Android application. In this method, the eBPF program is registered and executed in the kernel, allowing for high-performance tracing of the target Android application and acquisition of response information at the kernel level, thereby determining the security analysis and testing results of the target Android application. Because the kernel layer and application layer are well isolated, kernel layer processing traces cannot be detected at the application layer, thus achieving high-performance and highly covert analysis and testing. Attached Figure Description

[0015] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram of a file structure in the prior art;

[0017] Figure 2 This is a schematic diagram of a Frida principle in the prior art;

[0018] Figure 3 This is a schematic diagram of an eBPF enable in the prior art;

[0019] Figure 4 A flowchart illustrating a security analysis and testing method for an Android application provided in an embodiment of the present invention;

[0020] Figure 5 A framework diagram of Android application security analysis and testing technology based on eBPF is provided for embodiments of the present invention;

[0021] Figure 6 A comparison chart of the capabilities of a mainstream static analysis framework, a dynamic analysis framework, and an eBPF-based analysis and testing framework provided for embodiments of the present invention;

[0022] Figure 7 A schematic diagram of the architecture of a data tracking scheme provided in an embodiment of the present invention;

[0023] Figure 8 A flowchart of an eBPF program tracing system call is provided as an embodiment of the present invention;

[0024] Figure 9 A flowchart for tracing function calls during system calls is provided as an embodiment of the present invention;

[0025] Figure 10 A system call tracing flowchart provided in an embodiment of the present invention;

[0026] Figure 11 A flowchart of Binder communication tracing provided in an embodiment of the present invention;

[0027] Figure 12 A mapping diagram provided for an embodiment of the present invention;

[0028] Figure 13 A schematic diagram of network communication for an Android application provided in an embodiment of the present invention;

[0029] Figure 14 This is another schematic diagram of network communication for an Android application provided in an embodiment of the present invention;

[0030] Figure 15This is a schematic diagram of a map reading and calling process provided in an embodiment of the present invention;

[0031] Figure 16 A schematic diagram of an error injection test based on eBPF provided in an embodiment of the present invention;

[0032] Figure 17 A schematic diagram of SSL communication tracing based on eBPF provided in an embodiment of the present invention;

[0033] Figure 18 A schematic diagram of the structure of a security analysis and testing device for an Android application provided in an embodiment of the present invention;

[0034] Figure 19 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0035] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0036] Android, with its open-source nature, high customizability, and vast application ecosystem built by global developers, has become one of the most influential operating systems in the mobile internet era. However, its security situation is far from optimistic. The Android platform, due to its openness, is more vulnerable to malware attacks. Research shows that the number of malware on Android devices is increasing year by year, and applications downloaded from third-party app stores are more likely to be malware or have other security issues such as privacy breaches.

[0037] Traditional methods for security analysis and testing of Android applications are mainly divided into two types: static and dynamic. Firstly, regarding static analysis, developers can hide the actual program code through hardening and obfuscation techniques. Traditional static analysis methods struggle to penetrate obfuscation or hardening layers to capture the actual execution logic, severely hindering static analysis. Secondly, since dynamic analysis and testing are generally built upon static analysis, hardening and obfuscation techniques also significantly impede dynamic analysis and testing of Android applications. For dynamic analysis and testing, traditional techniques (such as Frida and Xposed based on dynamic instrumentation) rely on user-space injection, leaving numerous traces during both the injection and instrumentation processes. Their concealment is significantly flawed, making them easily detected and evaded by anti-debugging and anti-injection mechanisms (such as ptrace detection, memory verification, and environmentally sensitive behavior recognition), leading to dynamic interference or deliberate termination of the analysis process.

[0038] In Android application development, application protection technologies are widely used to improve application security. These technologies primarily prevent reverse engineering of applications, such as hardening, obfuscation, anti-debugging, and sandboxing. While Android application protection technologies play a crucial role in enhancing application security, they also present significant challenges to researchers' testing and analysis work.

[0039] A study analyzing over 20,000 apps with more than 10,000 downloads found that approximately one-quarter used hardening or obfuscation techniques to protect themselves from reverse engineering and further attacks. Malicious programs often use these protection techniques to conceal their behavior and evade reverse engineering and analysis. Further analysis of Android apps in my country's app market reveals that the use of hardening and obfuscation techniques is even more prevalent. Existing security testing tools and frameworks are unable to address the new challenges brought about by the development of application protection technologies, resulting in relatively weak testing and analysis of Android apps using these techniques (especially malicious programs). Therefore, researching testing and analysis techniques capable of countering various protection methods is extremely important for Android security research.

[0040] To facilitate understanding, the relevant concepts are explained below:

[0041] 1. Static analysis techniques

[0042] Static analysis is a technique that analyzes program logic by examining source code and bytecode without executing the program. Unlike dynamic analysis, static analysis does not rely on the program's runtime state; instead, it performs in-depth analysis of the code itself to analyze program behavior, discover vulnerabilities, or identify runtime bottlenecks. Static analysis typically uses automated tools to analyze the code's syntax, structure, control flow, and data flow to uncover potential security vulnerabilities and logical errors. In Android application development, Java or Kotlin are generally used. The source code is first compiled into Java bytecode files, which are then further converted into Dalvik bytecode format files (DEX files). The compiled DEX files can be directly loaded and executed by the Android virtual machine. Figure 1 The diagram illustrates a file structure where an Android application installation package can be divided into three parts: Dex files, dynamic link library files, and other files. The Dex file contains the application's bytecode (the product of compiling Java / Kotlin code) and is the core target of static analysis. Decompilers (such as Jadx and dex2jar) are typically used to restore the Dex bytecode to Java / Kotlin pseudocode, allowing direct examination of the code structure, control flow, and data flow. Dynamic link library files (NativeLibraries, .so files) are native code written in C / C++, typically used for high-performance computing or low-level system interactions. Tools like IDA Pro and Ghidra are generally used to disassemble the C / C++ code and analyze its logic.

[0043] 2. Dynamic analysis technology

[0044] Dynamic analytics is a technique that analyzes applications or detects vulnerabilities, malicious behavior, or performance issues by actually running the program and monitoring its runtime behavior (such as memory state, system calls, network communications, etc.). Its core lies in observing the dynamic interactions of a program in a real or simulated environment to address the challenges posed by static analysis obfuscation and hardening techniques. Dynamic analytics excels at verifying the exploitability of potential vulnerabilities, tracing runtime data flows, and analyzing the real-time behavior of malicious code. In the Android platform, dynamic analytics helps developers or security researchers gain a deeper understanding of the application's actual runtime logic by running the application and monitoring its behavior in the system environment in real time. For example, by injecting debugging tools (such as Frida, Xposed) or using a sandbox environment (such as the Android emulator), it is possible to trace application calls to sensitive APIs (such as obtaining location or accessing contacts), detect malicious code hijacking network communications, or expose data leakage risks caused by privilege abuse. Dynamic analysis can also capture the details of an application's interaction with system services (such as broadcast receivers and background services) during runtime, identify hidden vulnerabilities (such as component exposure and logic defects) or malicious behaviors (such as covert privilege escalation and privacy theft), and is especially suitable for analyzing hardened or obfuscated applications, providing direct evidence for the security assessment and performance optimization of mobile applications.

[0045] The following explains the static analysis techniques and their challenges:

[0046] Currently, solutions for static analysis of applications focus on automated static analysis frameworks. The mainstream static analysis framework, MobSF (Mobile Security Framework), is an open-source mobile security framework (see related technologies for details). Its static analysis technology can be applied to Android and iOS applications. Specifically, it works by decompiling the application and then performing static analysis based on static analysis rules. This includes the MobSFscan plugin, which performs security analysis by scanning the mobile application's source code. There are also some dedicated static analysis tools. QARK (Quick Android Review Kit), a static code analysis tool, focuses on detecting network and encryption-related vulnerabilities and finding network and encryption security issues in Android applications. In addition, there are tools that analyze program control flow and data flow. For example, FlowDroid is an open-source static data flow analysis tool based on the Soot framework. This tool can detect and analyze data flow to discover various privacy leaks, but it cannot find existing security vulnerabilities.

[0047] Android static analysis faces multiple challenges. The most common approach is to use code obfuscation and hardening techniques to combat static analysis. Developers employ name obfuscation, control flow flattening, or dynamic loading techniques to increase the difficulty of analysis. These techniques make the decompiled code either not the real code or difficult to understand, requiring a combination of unpacking and deobfuscation techniques for analysis. Regardless of the static analysis tool used, it cannot properly analyze Android applications that employ hardening and obfuscation protection techniques. Solutions for cracking or bypassing commercial hardening schemes and code obfuscation techniques (such as Ollyvm and ProGuard) lack universality and cannot be updated in sync with hardening and obfuscation techniques.

[0048] The following explains the dynamic analysis techniques and challenges:

[0049] Currently, solutions for dynamic analysis and testing of Android applications focus on code instrumentation techniques. For example, Frida is a powerful dynamic analysis and reverse engineering tool widely used in security research and debugging. It uses code instrumentation to insert custom logic before and after code execution, allowing researchers to modify and monitor application behavior at runtime. Figure 2 The diagram illustrates the Frida principle. Frida typically attaches to the target application via the ptrace system call, then injects a dynamic link library and unattaches it. Subsequent code hooking is based on the injected dynamic link library. Xposed is a hooking framework running on the Android operating system. By replacing critical files in the Android system, it can intercept calls to almost all Java functions and allows custom code in Xposed modules to modify the behavior when these functions are called. Its implementation principle is also code instrumentation. The above techniques instrument the application at the application layer using third-party tools. At the kernel layer, related technologies propose an Android application analysis method that hooks system calls into a system kernel module to analyze the Android application, achieving transparent tracing and analysis through a lower-level hooking approach. This method is more covert than application-level instrumentation, but it requires compatibility with different kernels, has poor robustness, and cannot be applied to actual analysis and testing processes.

[0050] Dynamic testing is generally built upon static analysis; therefore, the difficulty in identifying program code logic due to hardening and obfuscation makes dynamic testing extremely challenging. Furthermore, application protection technologies safeguard applications from debugging and tampering during runtime, severely hindering dynamic testing. Related technologies, when hardening applications for security, not only harden and obfuscate Android applications but also incorporate various anti-debugging techniques. These include detecting whether the current process is being debugged by other processes, detecting the presence of dynamic link libraries injected by dynamic analysis tools, and checking for code hooking. Most Android application dynamic testing tools are based on the Frida or Xposed frameworks. Firstly, these two dynamic testing frameworks contain numerous static features or runtime traces. Frida requires calling ptrace to inject dynamic link libraries into the target program, while Xposed replaces the application's class loader, allowing it to inject custom code or modify existing code when loading classes. These features are extremely easy for applications to detect, thus hindering analysis and testing. Therefore, common dynamic analysis tool features are easily detected, causing application crashes and making dynamic analysis and testing impossible. Therefore, many existing security testing tools fail to function properly or exhibit extremely low accuracy when faced with hardened and obfuscated applications. This results in researchers being unable to obtain reliable results when conducting static and dynamic analyses, thus impacting the overall security assessment.

[0051] In summary, traditional Android application security analysis and testing techniques have faced varying degrees of resistance, severely hindering the analysis and testing of Android applications. Therefore, this invention provides a method for security analysis and testing of Android applications, which can be applied to scenarios requiring security analysis and testing of Android applications.

[0052] To facilitate understanding of this embodiment, a security analysis and testing method for Android applications disclosed in this invention will first be introduced. The method is applied to electronic devices, such as computers, tablets, and mobile phones. The electronic device runs an Android operating system. The Android operating system includes a kernel layer and an application layer that are isolated from each other. The kernel layer contains an eBPF virtual machine, which loads eBPF programs. The application layer includes multiple Android applications. The eBPF virtual machine is a lightweight, sandboxed virtual machine within the kernel layer, allowing users to run custom programs in kernel space to achieve real-time monitoring and analysis of system events. The developer-defined eBPF programs will be executed by the kernel layer virtual machine and will operate throughout the entire Android operating system. eBPF (Extended Berkeley Packet Filter) is a kernel technology that allows developers to run specific functions without modifying the kernel code. The concept of eBPF originates from Berkeley Packet Filter (BPF), a network filter developed by Bell Labs that can capture and filter network packets. eBPF is essentially a small, controlled virtual machine environment implemented within the Linux kernel, allowing developers to dynamically load custom programs into the kernel. For example... Figure 3 The diagram illustrates an eBPF enabling mechanism. The Android operating system is divided into the application layer, Java API framework layer, native code and runtime layer, hardware abstraction layer, and the bottom Linux kernel layer from top to bottom. The eBPF virtual machine resides in the kernel layer. Therefore, developer-defined eBPF programs will be executed by the eBPF virtual machine in the kernel layer and will operate on the entire Android operating system, including the top application layer, thereby enabling efficient event monitoring, network packet filtering, security detection, and other functions.

[0053] It should be noted that in this plan, user information was obtained with the user's consent and complies with relevant laws and policies. For example... Figure 4 As shown, the method includes the following steps:

[0054] Step S102: Generate a target operation request through the target Android application;

[0055] The target Android application mentioned above can be any application among multiple Android applications in the application layer; the target operation request mentioned above may be a file operation request, a request to obtain privacy information, etc. In actual implementation, the target operation request can be generated by the target Android application in the application layer.

[0056] Step S104: Send the target operation request to the kernel layer;

[0057] Step S106: Based on the eBPF program in the eBPF virtual machine, obtain the response information associated with the target operation request, and analyze the response information to obtain the security analysis test results of the target Android application.

[0058] In practice, the generated target operation request can be sent to the kernel layer. Then, by running the eBPF program in the eBPF virtual machine, the response information associated with the target operation request can be obtained. Usually, the response information associated with different target operation requests is also different. For example, if the target operation request is a file operation request, the corresponding response information may include the application file name, file operation path, file operation flag (read / write / create), etc. The obtained response information can be analyzed to obtain the security analysis and test results of the target Android application. For example, based on the response information corresponding to the above file operation request, the entire lifecycle operation of the application file can be analyzed, thereby achieving in-depth insight, accurate modeling, and proactive defense of the target Android application's related operation behavior on application files.

[0059] The aforementioned security analysis and testing method for Android applications generates a target operation request from the target Android application and sends it to the kernel layer. It then uses the eBPF virtual machine to obtain and analyze the response information to arrive at the security analysis and testing results for the target Android application. In this method, the eBPF program is registered and executed in the kernel. This allows for high-performance tracing of the target Android application at the kernel level and the acquisition of response information, thereby determining the security analysis and testing results. Because the kernel layer and application layer are well isolated, kernel-level processing traces cannot be detected at the application layer, thus achieving high-performance and highly covert analysis and testing.

[0060] like Figure 5 The diagram illustrates a framework for Android application security analysis and testing based on eBPF. This technology is divided into two parts: application security analysis and testing. In terms of technical implementation, it consists of three modules: kernel instrumentation based on eBPF, application-layer instrumentation, and kernel tracing implemented with other security mechanisms; user-layer tracing; and application testing. These three modules enable system-level monitoring, in-depth tracking of application behavior, comprehensive testing and behavior supervision of applications, thus constructing a full-link security analysis and testing system.

[0061] The kernel instrumentation module inserts hooks at the kernel level using eBPF's kprobe and tracepoint mechanisms. This allows for the monitoring and interception of system calls, Binder communication, and other critical kernel functions, capturing interactions between applications and the operating system to obtain low-level behavioral data. This module enables functions such as file read / write tracing, privacy and security analysis, privilege escalation detection, and dynamic code loading detection.

[0062] Leveraging eBPF's uprobes (user-space probes), this module collects real-time runtime function calls, dynamic linking behavior, and the execution trajectory of business logic for Android applications' SSL (Secure Sockets Layer) calls, Framework APIs, and dynamic link libraries (including system and user-defined libraries). This module enables HTTP / S (HTTP: HyperText Transfer Protocol; HTTPS: HyperText Transfer Protocol Secure) communication content tracing, runtime code unpacking, and dynamic testing.

[0063] The application testing module utilizes other eBPF mechanisms to set hardware breakpoints, perform error injection tests, send program signals, and use the LSM mechanism for security defense. This module enables dynamic testing of Android applications and blocking of malicious behavior.

[0064] The eBPF-based Android application security analysis and testing framework has two significant advantages over other frameworks: 1. It can trace kernel functions; 2. It offers superior concealment in analysis and testing. For example... Figure 6 The chart shows a comparison of the capabilities of mainstream static analysis frameworks, dynamic analysis frameworks, and eBPF-based analysis and testing frameworks. In terms of system call and kernel-level function call tracing, DroidTrace uses ptrace for system call tracing, but it cannot trace other kernel functions, and ptrace is easily detected by applications. InviSeal uses kernel modules to trace system calls and kernel-level functions, at the cost of requiring kernel modifications. The eBPF-based framework, however, can trace system calls and kernel-level function calls without kernel modification and is not detected by applications. Furthermore, other dynamic analysis and testing frameworks modify the Android system or application to inject dynamic instrumentation libraries when tracing application-level function calls, but the eBPF-based framework can directly instrument and debug the application process, significantly outperforming other frameworks.

[0065] The basic concepts and three main modules of this technical solution are described in detail below:

[0066] I. Basic Concepts:

[0067] 1. Data Tracking Solution

[0068] like Figure 7 The diagram shows the architecture of a data tracing solution. The architecture of a data tracing solution is generally divided into three parts: data source, collection, and front end.

[0069] Data Source: Based on the source of the trace data, define the fundamental source of the monitored events, i.e., which points in the kernel or application can be observed. Common sources include Tracepoints, Kprobes, and Uprobes. Tracepoints are static, built-in tracepoints. Kprobes are dynamic tracepoints for kernel functions, capable of tracing any kernel function except those on a blacklist. Uprobes are dynamic tracepoints for user-space functions.

[0070] Data Acquisition: Based on the raw event callback interfaces provided by the kernel to user space, the acquisition section defines which interfaces the kernel provides to allow user-space tools (front-end) to configure which data sources to monitor and to receive the data streams (event logs) generated by these events. Common examples include ftrace, perf_events, debugfs, and bpf (bpf also refers to eBPF or ebpf, which will not be discussed further below). eBPF can be attached to almost all data sources, including Tracepoints, kprobes / uprobes, perf_events, and network events.

[0071] Frontend: The command-line tools or libraries actually used by the user. They utilize the underlying data collection mechanism to configure the data source, receive event data streams, and perform parsing, filtering, aggregation, statistics, visualization, or storage. Examples include ftrace, bcc, and bpftrace.

[0072] 2. Basic Architecture of eBPF Analysis and Testing Program

[0073] like Figure 8The diagram illustrates an eBPF program tracing system call flowchart. Developers write the C source code of the eBPF program in the development environment and compile it into bytecode that can be loaded by system calls. Then, functions encapsulated by a third-party Go library load the bytecode and other parameters into the kernel. Specifically, this involves passing the bytecode and other parameters to the BPF syscall and performing BPF bytecode loading verification and JIT compilation. The eBPF program shares data between the Linux Kernel Layer and the eBPF Program Layer through a Map mechanism. The eBPF Program Layer contains the basic components of an eBPF analysis and testing program: eBPF C source code and bytecode, Go third-party libraries, and other handlers. When performing file reading and writing operations through an Android application in the Application Layer, interaction with the Linux Kernel Layer is required via system calls.

[0074] II. Three main modules:

[0075] 1. Kernel-level tracing module

[0076] The design of two tracing schemes, system call tracing and Binder communication tracing, will be described in detail below for this module.

[0077] A. System call tracing

[0078] System call tracing primarily utilizes the tracepoint interface provided by the kernel to trigger an eBPF program at the entry or exit point of a system call. By attaching the eBPF program to the raw_tracepoint, critical parameters and status information can be obtained immediately when a system call occurs. Because the raw_tracepoint provides lower-level, more raw event data, this method typically incurs less overhead and allows for finer-grained control over data acquisition and processing, thereby enabling real-time monitoring and analysis of system call behavior without interfering with normal system operation. Figure 8 As shown, after the BPF program passes verification and JIT compilation, the functions in the eBPF program are registered in the syscall tracing function callback table. This allows for callbacks to the registered BPF functions before or after a system call, thus enabling system call tracing. Figure 9 The diagram illustrates a system call tracing function call flowchart. When an application makes a system call, the el0 svc exception is triggered. If it's determined to be a system call, the execution flow is divided into three steps: syscall_trace_enter, invoke_syscall, and syscall_trace_exit. These steps respectively involve calling a pre-registered callback function before the system call to trace the system call parameters, executing the system call, and calling a pre-registered callback function after the system call to trace the system call return value. Within these two trace functions, the bpf function (i.e., the callback function) registered in the callback function table mentioned earlier is called, thus passing data to the tracing program.

[0079] like Figure 10 The diagram illustrates a system call tracing flowchart. The eBPF analysis and testing program is responsible for setting filter parameters and processing tracing data, while the BPF program is loaded and executed by the eBPF virtual machine, performing corresponding logic before and after the system call. Before the system call, filter parameters (system call number and UID filtering events) are set. After confirming that the operation request matches the filter parameters, a callback function is called to trace and save the context and call parameters corresponding to the operation request. After the system call, the saved context and call parameters are retrieved, and the event tracing data is submitted along with the return value. The eBPF analysis and testing program can then retrieve and process data from the saved data Map.

[0080] For example, in one embodiment, by tracking the file operation-related system calls of an application with a specified UID, it is possible to obtain the process PID, thread TID, system call name, specific parameters of the system call, and return value. In particular, extra processing is performed on string type parameters, parsing and outputting the content pointed to by their address.

[0081] B. Binder Communication Tracking

[0082] Binder is the core inter-process communication (IPC) mechanism in the Android operating system. It allows application components (such as Activities, Services, and ContentProviders) running in different processes to communicate securely and efficiently and invoke methods. Binder efficiently and securely connects isolated processes within the system. All inter-application messages (including requests to access private data) pass through Binder IPC. For example, starting an Activity, Service, or querying a content provider actually sends a Binder transaction. The Binder IPC carries the caller's UID (User Identifier), which the server can use to determine the caller's permissions. Applications typically accessing sensitive data through Binder to call corresponding services or ContentProviders. For example, actions such as obtaining location, contacts, and device IDs are all transmitted via Binder. Research shows that analyzing Binder messages can directly extract sensitive data. For instance, tools like BinderFilter capture Binder communication data by hooking kernel functions through kernel modules and can successfully intercept any requests for GPS location, with the returned data containing specific latitude and longitude coordinates. Therefore, Binder monitoring can reveal when an application accesses and what private information it transmits. Several methods exist for Binder tracing. Adding a kernel module at the kernel level allows for filtering and logging, but this has poor compatibility and requires kernel modification. Another method, Binder-trace, uses Frida to hook the IPCThreadState::transact() function and parses the Binder communication content. This method is inefficient, relies on the dynamic instrumentation tool Frida, and has poor stealth capabilities.

[0083] This solution utilizes kernel-level kprobe and tracepoint for data collection, and then uses eBPF to dynamically capture Binder transaction information. This not only provides excellent stealth but also does not rely on any third-party dynamic instrumentation tools or kernel modules. Furthermore, direct instrumentation at the kernel level allows filtering operations to be performed in kernel space, avoiding the overhead of passing data to user space for filtering, thus significantly improving performance. Figure 11The diagram illustrates a Binder communication tracing process. To ensure that the performance overhead of the application during tracing does not affect its operation, a "lightweight entry point + deep processing of raw_tracepoint" design approach is adopted. At the entry point of the `binder_transaction` kernel function, `kprobe` is used to collect entry parameter information containing Binder communication content. Then, the entry parameter information captured at the entry point is obtained in the subsequent static instrumentation function `trace_binder_transaction`. Other necessary information (such as context information) is then collected and submitted to the Maps. Figure 8 The eBPF Program Layer can retrieve the tracking data from the Maps to enable Binder communication tracking.

[0084] In addition, to better track the content of Binder communication, this solution designs a direct memory read technique for processes. Instead of transmitting complete Binder communication data through eBPF, it uses the Linux kernel system call process_vm_readv. After obtaining the collected address information, the tracing program relies on this system call and address to directly read the memory of the traced program and extract the Binder communication data. This can greatly improve the efficiency of the tracing system and prevent packet loss during collection.

[0085] 2. Application Layer Tracing Module

[0086] For this module, the following sections will detail two tracing schemes: Framework API tracing and SSL communication tracing.

[0087] A. Framework API Tracing

[0088] Starting with Android 5.0, the Android system fully adopted ART (Android Runtime) instead of Dalvik, and used the dex2oat tool to pre-compile dex bytecode into OAT (Optimized Android Executable, an application compilation format) and ODEX (Optimized Dalvik Executable, an application optimization format) files on the device. OAT files are essentially ELF-compliant binaries, and the executable segment (.text) contains AArch64 machine instructions for Java methods. Figure 12The diagram illustrates a mapping process where, during system startup, Zygote or System Server maps system service-related OAT / ELF files to processes using mmap. Similarly, during application incubation, the corresponding pages are copied, allowing direct execution of native instructions to achieve the startup and runtime efficiency advantages of Ahead-of-Time (AOT) compilation. If a method in a system class is compiled and optimized into native code, the corresponding method's code address can be found in the OAT file. In one embodiment, the application is also optimized by the system using AOT to generate a base.odex file, reducing application startup time and improving application runtime efficiency.

[0089] This solution proposes a dynamic tracing method for Android OAT code based on eBPF uprobes. The specific process is as follows: First, a symbol extraction tool is used to determine the relative offset (fileoffset) of the target tracing method within the OAT file. Figure 12 As shown, boot-framework.oat is mapped into the application's virtual memory, and its executable segment corresponds to the executable section of the binary file. Only the relative offset (fileoffset) of the target tracing method in the file needs to be found to calculate the actual address (base address + fileoffset) of the method using the base address. Subsequently, a user-mode probe is registered with the kernel via the eBPF system call interface, specifying that the loaded eBPF program will be triggered when the process executes to the actual address. When the program executes to the location corresponding to the actual address, the eBPF program is triggered. The triggered eBPF program obtains the register context and, optionally, a user stack or memory snapshot in kernel mode, and returns key runtime parameters to user space via the ring buffer. When the OAT file changes due to system OTA upgrades or dex2oat recompilation, only the new file needs to be re-parsed and the probe offset updated to maintain tracing effectiveness. This method achieves real-time, low-overhead, and process-transparent dynamic behavior observation of Android framework layer AOT-generated code without modifying the system image and application bytecode, exhibiting good versatility and maintainability.

[0090] B. SSL Communication Tracking

[0091] like Figure 13 The diagram shown illustrates network communication in an Android application. Figure 14The diagram illustrates another type of network communication in Android applications. Android applications can perform network communication in two ways: communication without TLS (Transport Layer Security) encryption (also known as SSL encryption) and communication with TLS encryption. Without encryption, after establishing a connection with the target via `connect`, plaintext information is transmitted directly using the `send` system call, and plaintext responses are received using the `recv` system call. In this case, all communication data is transmitted in plaintext, which is highly insecure. Therefore, TLS encryption is introduced to encrypt the data, such as... Figure 14 As shown, specifically, data is encrypted when passing through the encryption component. At this point, all data transmitted in system calls is ciphertext, ensuring that the data is not eavesdropped on by third parties during transmission. In Linux, SSL / TLS encryption is primarily implemented through the OpenSSL library. On the Android platform, Android can communicate through different TLS-related dynamic link libraries, such as libssl.so, libboringssl.so, or the application's own dynamic link library.

[0092] The SSL communication tracing scheme in this solution will be described in detail later and will not be repeated here.

[0093] 3. Application Testing Module

[0094] For this module, the following sections will focus on two technical solutions: error injection testing based on eBPF and integration testing of eBPF with the dynamic instrumentation tool Frida.

[0095] A. Error Injection Testing Based on eBPF

[0096] Error injection testing based on eBPF is a software testing method that uses eBPF technology to simulate various faults at the operating system kernel level. It involves writing and loading eBPF programs into the kernel to dynamically intercept specific system calls, network events, or other kernel functions, and modify their behavior to simulate faults, such as forcing error codes, increasing latency, or dropping network packets. The specific process of error injection testing will be described in detail later and will not be repeated here.

[0097] B. eBPF and Frida Integration Testing Technology

[0098] Frida, as an open-source dynamic instrumentation testing tool, has many publicly detectable features, many of which can be removed by modifying the source code and recompiling. For example, each process in the Android operating system has a maps file to describe the process's virtual memory layout. The traces of Frida injecting dynamic link libraries in the maps are difficult to eliminate because the data in the maps is generated from the kernel layer and is constantly changing, and the kernel does not provide any interface to hide any traces of dynamic link libraries.

[0099] The core of using eBPF to hide Frida traces is to intercept and tamper with the read operations of specific files at the kernel level, thereby providing user space with a modified, false view that does not contain Frida characteristics. This primarily utilizes eBPF's kprobe (kernel function probe) and kretprobe (kernel function return probe) functions to precisely hook into several key functions in the kernel that handle the reading process of the / proc / [pid] / maps file. For example... Figure 15The diagram illustrates a maps read call flow. When any process attempts to read the ` / proc / [pid] / maps` file of a target application, it begins with a `read` system call, which then triggers a call to the kernel function `seq_read`. The `kprobe` (`kprobe_seq_read`) mounted at the `seq_read` entry point is activated first. It obtains the current process's PID (Process Identifier) ​​and UID, comparing them with the target set in user space to ensure that read operations only apply to specific processes. The probe analyzes the first parameter of `seq_read`, `struct file *file`, to confirm whether the file being read is a map. After confirming the target, it stores key context information for this read operation, such as the address of the user-space receive buffer (`user_buf`), the pointer to the `seq_file` structure, and the current state of the internal buffer of `seq_file`, into a BPF map named `seq_read_info_m`. Simultaneously, it initializes a record structure in another map, `seq_buf_records_m`, for storing the location of data to be tampered with later. During the kernel's generation of the maps file content, the `seq_path` function is called to format the pathname of each memory mapping record. The `kretprobe(kretprobe_seq_path)` function, mounted at the return point of `seq_path`, is triggered after each `seq_path` execution. It checks the contents just written to the internal buffer of `seq_file`. It reads this newly generated content using `bpf_probe_read` and performs string matching against Frida's characteristic paths (such as ` / memfd:frida`). Once a match is successful, the probe calculates the starting address of the complete maps line containing Frida characteristics in the `seq_file` kernel buffer and records this address in the BPF mapping `seq_buf_records_m`. This mapping uses the process ID and the `seq_file` pointer as a composite key, allowing for precise recording of multiple lines to be modified for each independent read operation. When the `seq_read` function completes copying data from the `seq_file` kernel buffer to the user space buffer and is about to return, its return probe `kretprobe_seq_read` is triggered. The `kretprobe_seq_read` function is the core of the tampering process. It first retrieves all previously saved context information from `seq_read_info_m` and `seq_buf_records_m`, including the user buffer address, the size of the data being read, and the kernel address of all marked Frida lines.Then, the `bpf_probe_write_user` function directly writes the predefined replacement content (`[anon:bionic_alloc_small]...`) into the user-space memory buffer (`user_buf`). It precisely calculates the exact location of each Frida record in the user buffer based on the previously recorded address and the actual amount of data copied in this `seq_read`, and then overwrites it. This function also handles the complex case of multiple reads by `seq_read` (i.e., the kernel buffer of `seq_file` is filled and copied multiple times). By maintaining state (such as `work_idx`, `buf_left`) in `seq_buf_records_m`, it ensures that even if a Frida record is split across two read calls, it can still be completely and correctly replaced. After all the tampering operations are complete, the relevant BPF mapping entries (such as records in `seq_read_info_m` and `seq_buf_records_m`) are deleted, releasing resources and preparing for the next map file read.

[0100] The following is about Figure 5 This section explains the key functions in the security analysis and testing modules within the capability set. These include file read / write analysis, privacy and security analysis, and runtime code unpacking in the security analysis module, as well as malicious behavior blocking and application-layer dynamic testing in the testing module. The specific implementation process of each function will be further explained below.

[0101] This invention also provides another method for security analysis and testing of Android applications, which is implemented based on the method described in the above embodiments. In this method, the target operation request is either a file operation request or a privacy information acquisition request. The method includes the following steps:

[0102] Step 1: Generate a target operation request through the target Android application;

[0103] Step two: Send the target operation request to the kernel layer;

[0104] Step 3: Based on the target operation request, determine the target system call corresponding to the target operation request;

[0105] Step 4: Attach a trace point to the target system call so that the eBPF program in the eBPF virtual machine can obtain the system call parameters and system call return data corresponding to the target operation request.

[0106] In practical implementation, when the target operation request is a file operation request or a request to obtain private information, the target system call corresponding to the target operation request can be determined first. Then, a trace point can be attached to this target system call. When the target Android application runs to this trace point, the system call parameters and system call return data corresponding to the target operation request can be obtained through an eBPF program. For example, taking a file operation request as an example, this file operation request can specifically be file read / write analysis. File read / write analysis is a core function for monitoring and auditing all file operation behaviors of applications on the device. Its purpose is to identify and prevent sensitive data leakage, illegal data tampering, and unauthorized access to critical system files. The Android platform kernel uses the Linux kernel, and all file operations are implemented through system calls provided by the kernel. For example, opening a file calls the `openat` system call, reading a file uses system calls such as `read` and `pread64`, writing a file calls the `write` system call, and closing a file calls the `close` system call. Therefore, kprobe (kernel function probe) or tracepoint can be used to attach to system calls related to file operation requests to obtain system call parameters corresponding to file operation requests, such as file name, path, operation flags (read / write / create), and obtain the corresponding system call return data.

[0107] The steps described above, which involve obtaining the system call parameters and system call return data corresponding to the target operation request through the eBPF program in the eBPF virtual machine, can be achieved through steps 40 to 42:

[0108] Step 40: Before executing the call to the target system call, the eBPF program in the eBPF virtual machine calls the pre-registered first callback function to track the system call parameters corresponding to the target operation request according to the first callback function.

[0109] This step 40 can be achieved through the following steps 401 to 402:

[0110] Step 401: Before executing the call to the target system, determine whether the target operation request meets the preset filtering parameters; wherein, the preset filtering parameters include: system call number, user identifier filtering event;

[0111] Step 402: If the target operation request matches the preset filtering parameters, the eBPF program in the eBPF virtual machine calls the pre-registered first callback function to track the system call parameters corresponding to the target operation request according to the first callback function.

[0112] The aforementioned system call number can be understood as the system call number corresponding to the target system call; the aforementioned user identifier filtering event can be understood as a pre-set filtering condition; in actual implementation, before executing the call to the target system call, it can be determined whether the target operation request meets the preset filtering parameters. Only after meeting the preset filtering parameters will the first callback function be called to track the system call parameters.

[0113] Step 41: Invoke the target system call to execute the processing logic corresponding to the target system call;

[0114] Step 42: After the target system call is completed, the eBPF program in the eBPF virtual machine calls the pre-registered second callback function to track the system call return data corresponding to the target operation request according to the second callback function.

[0115] Step 5: Analyze the system call parameters to obtain the operation analysis results corresponding to the system call return data;

[0116] Continuing with the example of a file operation request, by analyzing the system call parameters mentioned above, we can analyze the entire lifecycle of file operations, thereby achieving deep insight, accurate modeling, and proactive defense of application file behavior. Through correlation analysis, the complete flow path of data can be clearly depicted. For example, we can precisely trace how an application first reads the address book database via the `read` system call, then processes it in memory, and finally writes the data to a local file or sends it to the network via system calls such as `write`. This provides the most direct and fundamental chain of evidence for identifying "sensitive data leaks," rather than relying solely on upper-level guesses based on API calls.

[0117] Step 6: Based on the operation analysis results, determine whether there are any abnormal behaviors in the operation behavior of the system call returned data, and obtain the judgment result;

[0118] Step 7: Determine the security analysis test results of the target Android application based on the judgment results.

[0119] Based on the above operational analysis results, it can be determined whether there are any abnormal behaviors in the operations on the data returned by system calls. Based on the judgment results, the security analysis and testing results of the target Android application can be determined. For example, for file operation requests, specific malicious behaviors usually manifest as a series of regular file operations. For example, ransomware behavior can be identified as a typical pattern of "traversing directories -> repeatedly opening files -> reading file content -> writing encrypted content back to the original file or a new file -> unlinking to delete the original file." Once a large number of files exhibit this operation sequence within a short period, it can be identified as ransomware behavior, and an alert or block can be issued immediately. There is also malicious code release (Dropper) behavior: It can be monitored that the application writes files such as .so and .dex to a private directory or executable directory via the write system call, and then loads the file with executable permissions via the mmap system call. This clearly reveals the process of dynamically loading malicious code.

[0120] This invention also provides another method for security analysis and testing of Android applications, which is implemented based on the method in the above embodiments. In this method, the target operation request is a privacy information acquisition request; the method includes the following steps:

[0121] Step 10: Generate a target operation request through the target Android application;

[0122] Step 11: Send the target operation request to the kernel layer;

[0123] Step 12: Invoke the preset Framework API and use the Binder mechanism to send the privacy information acquisition request to the specified service that matches the privacy information acquisition request, so as to obtain the response information associated with the privacy information acquisition request through the specified service;

[0124] The aforementioned privacy information request can be used to request user personal information, such as name, address, phone number, and ID number. This embodiment can obtain associated response information through the privacy information request to perform privacy and security analysis based on the response information. This analysis focuses on detecting whether the application adheres to the principles of "legality, legitimacy, and necessity" when collecting, using, storing, and transmitting user personal information, ensuring that its behavior complies with relevant laws and regulations. Applications seeking device or user privacy information will inevitably do so through system calls or API calls within the system framework layer. The former can be tracked using the system call tracing mentioned earlier, while the latter will always use Binder communication. Binder is the core inter-process communication (IPC) mechanism of the Android system. When an application calls a Framework API (such as LocationManager), this API is actually a proxy within the application process, sending the request to the real service running in the system service process (such as LocationManagerService) via Binder. Tracing Binder communication is equivalent to monitoring the most basic information exchange bus of the system. Therefore, using the eBPF-based Binder communication tracing technology mentioned above, it is possible to monitor Binder communication between all applications and system services, and even between applications themselves.

[0125] Step 13: During the process of sending a request to obtain privacy information to a specified service via the Binder mechanism through the Framework API, the preset binder_transaction kernel function is called. At the entry point of the binder_transaction kernel function, the entry parameter information is collected by a probe.

[0126] Step fourteen: Obtain the input parameter information and the associated information by calling the preset static instrumentation function;

[0127] Step 15: Save the input parameter information and related information to the eBPF Map;

[0128] Step 16: Analyze the response information, entry parameter information, and associated information according to the preset privacy and security analysis method to obtain the security analysis test results of the target Android application.

[0129] Privacy data security analysis methods are mainly divided into privacy policy consistency analysis, data collection beyond permitted scope analysis, and privacy data leakage analysis. Privacy policy consistency refers to comparing the application's actual data collection behavior with the content of its privacy policy statement. This detects non-compliant behaviors such as "failure to disclose collection and usage rules," "failure to clearly state the purpose of collection and usage," and "default selection of agreement to the privacy policy." Data collection beyond permitted scope analysis checks whether the application attempts to call relevant APIs to obtain geographical location without obtaining "location information" permission, or whether there is "collection beyond permitted scope," i.e., requesting permission for permissions that are not necessary for its business function. Privacy data leakage analysis analyzes whether the application sends sensitive user information (such as device ID, location information, SMS content, etc.) in plaintext to a remote server or to a third-party SDK not declared in the privacy policy. Based on the above Binder communication tracing, a comprehensive analysis of the app's privacy security can be performed.

[0130] This invention also provides another method for security analysis and testing of Android applications, which is implemented based on the method in the above embodiments and further includes the following steps:

[0131] Step 20: Using the eBPF program in the eBPF virtual machine, probes are used to trace the specified key functions used by the target Android application during its operation, so as to capture the specified pointer when the specified key function is executed.

[0132] To prevent reverse engineering, many applications (including malicious and legitimate ones) use "packing" techniques to encrypt or compress their main executable code (such as the classes.dex file). Runtime code unpacking / deobfuscation is a technique that extracts the decrypted, real code from memory during application runtime, and is a prerequisite for deep security analysis. However, traditional Android application unpacking techniques mainly rely on manual debugging, memory dumping, and hooking techniques targeting Dalvik / ART. These methods require modifying the Android system source code or injecting dynamic link libraries. Most applications have strict runtime environment checks, making methods that modify system source code or inject dynamic link libraries to unpack the application easily detectable, causing the unpacking process to exit prematurely and failing to obtain a complete unpacking result. This embodiment proposes an Android application unpacking solution based on eBPF. The core of this solution lies in using eBPF's Uprobe mechanism to accurately trace specified key functions in libart.so. These specified key functions include ExecuteNterpImpl, Execute, and VerifyClass. These three functions are essential steps in the execution of Android application code. When the specified key functions are executed, a specified pointer can be captured. Specifically, the specified pointer can be an ArtMethod pointer.

[0133] Step 21: Extract the code association information of the executable code corresponding to the target Android application based on the specified pointer; the code association information includes: address information and size information;

[0134] Based on the specified pointer captured above, the address and size information of the executable code corresponding to the target Android application can be extracted. For example, the address and size information of DexFile can be extracted based on the captured ArtMethod pointer.

[0135] Step 22: Send the code association information to the user-mode program so that the user-mode program can obtain the executable code based on the code association information and save it to the preset disk, thus confirming that the target Android application has been unpacked.

[0136] In practical implementation, the aforementioned code association information can be sent to the user-space program. The user-space program can then parse the memory address and size of the executable code based on the code association information, achieving accurate location of the executable code. Based on the parsed memory address and size, the executable code can be retrieved and saved to a preset disk, thus completing the unpacking of the target Android application. The entire architecture consists of a kernel-level eBPF program responsible for event capture and a user-space Go program responsible for reading remote process memory and dumping the DEX file via the `process_vm_readv` system call. This design avoids the problems of traditional tools like FRIDA-DEXDump requiring PTRACE attachment or dynamic library injection, greatly improving stealth. Although this solution only supports runtime unpacking scenarios, its innovative combination of eBPF technology features and ART virtual machine internal mechanisms provides a novel and practical technical path for Android security research and malware analysis, particularly suitable for security analysis scenarios requiring high stealth.

[0137] This invention also provides another method for security analysis and testing of Android applications, which is implemented based on the method in the above embodiments and further includes the following steps:

[0138] Step 30: Based on the eBPF virtual machine's probe mechanism, set a probe at a specified location in the target Android application's dynamic link library.

[0139] Step 31: When the target Android application reaches the specified location, jump to execute the pre-registered eBPF exception handler, obtain the processing result, and determine the dynamic instrumentation test result of the target Android application based on the processing result.

[0140] Dynamic testing refers to testing activities conducted in the actual running state of software or systems. By executing code, driver interfaces, or simulating real input, the program under test is loaded and run in memory, and its response, output, and internal state are observed to evaluate its functional correctness, performance, security features, and stability. This embodiment proposes a dynamic instrumentation testing method based on the eBPF Uprobe mechanism. Uprobe can instrument code at any location in the application's dynamic link library. When the application executes to a specified location, a breakpoint exception is triggered, entering the exception handler, which further jumps to a pre-registered eBPF program to execute preset logic, thus achieving dynamic instrumentation testing of general applications.

[0141] This embodiment can also implement dynamic instrumentation testing based on the eBPF error injection mechanism. Error injection can force the application to return a specified value when executing system calls, allowing testing of more execution paths under different system call results. In addition, this embodiment utilizes semaphore sending reporters and the Perf mechanism to implement dynamic hardware breakpoint registration. Hardware breakpoints can be set at specified locations in the application to monitor register group information when the application reaches a specific location, providing more possibilities for dynamic testing of the application.

[0142] In addition, this embodiment innovatively combines eBPF with Frida, leveraging eBPF's ability to trace system calls and read and write user memory to dynamically remove Frida runtime features during application execution, providing better concealment for application testing.

[0143] This invention also provides another method for security analysis and testing of Android applications, which is implemented based on the method in the above embodiments and further includes the following steps:

[0144] By using the eBPF virtual machine and following a preset error injection mechanism, a specified error is injected into the target Android application so that when the target Android application makes a specified system call, a specified return value corresponding to the specified error is returned.

[0145] Error injection testing based on eBPF is a software testing method that uses eBPF technology to simulate various failures at the operating system kernel level. The key advantage of this method is that it can achieve accurate, efficient, and non-intrusive testing of the system's behavior under real failure conditions without modifying the application or kernel source code, thereby verifying the system's fault tolerance and robustness. Developers write corresponding handling code for possible errors (such as memory allocation failures). However, these errors rarely occur in normally functioning systems. For example, kmalloc() is a kernel function used to allocate memory. Theoretically, it may fail, so the code calling it must check the return value and perform remedial measures in case of failure. But in practice, kmalloc() almost never fails. This results in error-handling paths specifically handling such failures being almost never executed, which may hide defects (bugs). The kernel has had a fault-injection framework since 2006, which can force function calls like kmalloc() to fail. However, this old framework either caused all kmalloc() calls to fail (leading to a system crash and making it impossible to test the target code) or its failure condition parameters were cumbersome and inflexible to configure. The recently emerging BPF technology offers significant flexibility in solving this problem. Using kprobe, developers can mount BPF programs onto arbitrary kernel functions for information gathering. Previously, these BPF programs could not alter the execution of the mounted function. This problem was solved with the introduction of the new patch bpf_override_return(). Developers write a BPF program. They use kprobe to mount this BPF program onto a kernel function they want to test (e.g., the openat system call). Then, they call bpf_override_return() within this BPF program. When the kernel executes the corresponding function, it is "hijacked" by this BPF program. The original function body is not executed, but instead the BPF program's specified return value is returned directly (for example, -2, i.e. -ENOENT, simulating a file not found error).

[0146] like Figure 16The diagram illustrates an eBPF-based error injection test. A normal system call passes through three functions: `syscall_trace_enter`, `invoke_syscall`, and `syscall_trace_exit`, while the actual system call logic resides in `invoke_syscall`. By registering an eBPF program in `syscall_trace_enter`, when the application executes a specified system call, the registered eBPF program is triggered, calling `bpf_override_return` to directly inject a preset return value. This performs an error injection test, hijacking the normal execution of the system call, skipping `invoke_syscall` and subsequent steps, and returning the preset return value.

[0147] This invention also provides another method for security analysis and testing of Android applications, which is implemented based on the method in the above embodiments and further includes the following steps:

[0148] Step 40: Query the user identification information, process name, and preset blocking policy corresponding to the target Android application through eBPF Map;

[0149] The eBPF Map mentioned above is a data structure shared between the kernel and user space; the user identification information mentioned above can be a user ID (Identity Document); the preset blocking policy mentioned above can be represented in the form of a blacklist path, a list of sensitive files, etc.; in actual implementation, the user identification information, process name, and preset blocking policy corresponding to the target Android application can be queried through the eBPF Map.

[0150] Step 41: Compare the user identification information and process name with the preset blocking policy respectively to obtain the comparison results;

[0151] Step 42: If the comparison result indicates illegal behavior, return the specified error code.

[0152] In actual implementation, the aforementioned user identification information and process name can be compared with the preset blocking policy to determine whether there is any illegal behavior. For example, if the user identification information exists in the blacklist, the user can be considered an illegal user. If illegal access to protected files (such as the address book database / data / data / ... / contacts2.db) or writing of an executable file to the SD card is detected, the eBPF program can use the error injection mechanism to directly return the specified error code (such as -EPERM, operation not allowed), thereby directly blocking the operation at the kernel level, making it fail transparently to the application layer, and achieving undetectable blocking of malicious behavior.

[0153] This invention also provides another method for security analysis and testing of Android applications, which is implemented based on the method described in the above embodiments. This method includes the following steps:

[0154] Step 51: Generate a target operation request through the target Android application;

[0155] Step 52: Send the target operation request to the kernel layer;

[0156] Step 53: Based on the eBPF program in the eBPF virtual machine, obtain the response information associated with the target operation request.

[0157] Step 54: If both the target operation request and response information are encrypted, obtain the location information of the preset exported function and set a probe at the first location indicated by the location information;

[0158] Step 55: When the target Android application executes to the first position, based on the eBPF program in the eBPF virtual machine, obtain the plaintext corresponding to the target operation request and the plaintext of the response information associated with the target operation request.

[0159] Step 56: By analyzing the plaintext of the target operation request and the plaintext of the response information, the security analysis test results of the target Android application are obtained.

[0160] In practice, eBPF cannot decrypt already encrypted SSL / TLS traffic. However, as... Figure 14 Since the data processed by the `send()` and `recv()` system calls at the network socket level is already encrypted, the only way to capture it is before it is encrypted (for sending traffic) or after it is decrypted (for receiving traffic). This point in time exists within user-space SSL / TLS library functions. Therefore, the target of the tracing is not the kernel system calls, but rather the functions in user-space `libssl.so` or its lower-level libraries, such as the standard `SSL_write` and `SSL_read` functions (corresponding to the aforementioned default exported functions). Here, unencrypted plaintext can be read—that is, the plaintext corresponding to the target operation request, and the plaintext of the response information associated with the target operation request.

[0161] This embodiment proposes a real-time tracing method for SSL plaintext calls based on eBPF uprobes. First, the ELF files libssl.so / libboringssl.so (or other vendor-customized TLS libraries) in the Android system are parsed offline to locate the relative offsets of core exported symbols such as SSL_write, SSL_read, and SSL_do_handshake within the text segment. Then, eBPF system calls are used to register a user-mode probe with the kernel, specifying the eBPF program triggered when the application executes to the target function. For example... Figure 17 The diagram illustrates an eBPF-based SSL communication tracing method. When any process maps and executes the aforementioned TLS function, it triggers an eBPF program. This program reads registers in kernel mode (ARM64 x0–x5, containing pointers to SSL and plaintext buffers), calls `bpf_probe_read_user()` to extract user-layer plaintext data, including timestamps, PID / UIDs, and thread identifiers, and efficiently sends this data back to the user-space analyzer via a ring buffer. This process does not require disabling SELinux, modifying the TLS library or application code, and is transparent to multiple processes. It enables continuous, low-overhead, and accurate dynamic observation of the SSL plaintext lifecycle (handshake, pre-encryption writing, post-decryption reading), providing a reliable foundation for traffic auditing, intrusion detection, and encryption protocol performance profiling.

[0162] The aforementioned security analysis and testing method for Android applications consists of two parts: application security analysis and application testing. First, to counter application security protection measures, eBPF is used for high-performance tracing of Android applications at the kernel level, and behavioral analysis is performed based on the tracing results. Second, eBPF-based Android application testing techniques are researched, including mechanisms such as eBPF semaphore sending and error injection for application testing. Furthermore, user-level instrumentation techniques based on eBPF are investigated, and attempts are made to combine eBPF with existing advanced Android application dynamic instrumentation testing tools for covert testing of Android applications.

[0163] This approach provides an eBPF-based security analysis and testing technology for Android applications, enabling high-performance, highly stealthy security analysis and testing of Android applications to fill the gaps and deficiencies in existing Android application testing technologies. eBPF offers powerful tracing and analysis capabilities. By adding probes to kernel system call functions, tracepoints, and user-space functions, it can perform comprehensive tracing of applications with minimal performance overhead. Because the Android system's application layer and kernel layer are well isolated, kernel-level instrumentation traces cannot be detected at the application layer. This means the application cannot capture changes at the kernel layer or perceive whether it is being tracked, thus preventing the triggering of corresponding risk control strategies and achieving high-performance, highly stealthy analysis and testing.

[0164] In summary, this solution has the following advantages:

[0165] 1. Compared to existing technologies and frameworks, it can work without modifying the Android system and kernel, and has better compatibility.

[0166] 2. Most existing technologies and frameworks cannot achieve the tracing and testing of kernel-level functions, while this solution can achieve comprehensive tracing and testing at both the kernel and user levels.

[0167] 3. Because eBPF programs are registered and executed in the kernel, they have a stealth that other analysis and testing frameworks do not possess, making them undetectable by the target application and exhibiting good robustness.

[0168] 4. Compared to other technologies and frameworks, the eBPF program in this solution is registered and executed in the kernel, resulting in lower performance overhead during tracing, analysis, and testing.

[0169] 5. Compared to other technologies and frameworks, the tracking, testing and analysis part of this solution is very comprehensive, covering the main paths involved in the operation of Android applications.

[0170] This invention provides a security analysis and testing device for Android applications. The device is applied to an electronic device running an Android operating system. The Android operating system includes a kernel layer and an application layer that are isolated from each other. The kernel layer contains an eBPF virtual machine, which loads an eBPF program. The application layer includes multiple Android applications, such as... Figure 18As shown, the device includes: a generation module 180, used to generate a target operation request through a target Android application; a sending module 181, used to send the target operation request to the kernel layer; and an acquisition module 182, used to acquire response information associated with the target operation request based on an eBPF program in the eBPF virtual machine, and to obtain the security analysis test results of the target Android application by analyzing the response information.

[0171] The aforementioned security analysis and testing device for Android applications uses an eBPF program registered and executed within the kernel. This eBPF program can perform high-performance tracing of the target Android application at the kernel level and obtain response information, thereby determining the security analysis and testing results of the target Android application. Because the kernel layer and the application layer are well isolated, the processing traces of the kernel layer cannot be detected at the application layer, thus enabling high-performance and highly covert analysis and testing.

[0172] Furthermore, the target operation request is either a file operation request or a privacy information acquisition request; the acquisition module 182 is also used to: determine the target system call corresponding to the target operation request based on the target operation request; attach a trace point to the target system call to obtain the system call parameters and system call return data corresponding to the target operation request through the eBPF program in the eBPF virtual machine; analyze the system call parameters to obtain the operation analysis result corresponding to the system call return data; determine whether there is any abnormal behavior in the operation behavior on the system call return data based on the operation analysis result, and obtain the judgment result; and determine the security analysis test result of the target Android application based on the judgment result.

[0173] Furthermore, the acquisition module 182 is also used to: before executing the call to the target system call, call a pre-registered first callback function through the eBPF program in the eBPF virtual machine to track the system call parameters corresponding to the target operation request according to the first callback function; call the target system call to execute the processing logic corresponding to the target system call; and after the call to the target system call is completed, call a pre-registered second callback function through the eBPF program in the eBPF virtual machine to track the system call return data corresponding to the target operation request according to the second callback function.

[0174] Furthermore, the acquisition module 182 is also used to: determine whether the target operation request meets the preset filtering parameters before executing the call to the target system call; wherein, the preset filtering parameters include: system call number, user identifier filtering event; if the target operation request meets the preset filtering parameters, the eBPF program in the eBPF virtual machine calls the pre-registered first callback function to track the system call parameters corresponding to the target operation request according to the first callback function.

[0175] Furthermore, the target operation request is a privacy information acquisition request; the acquisition module 182 is also used to: call a preset Framework API, and send the privacy information acquisition request to a specified service matching the privacy information acquisition request through the Framework API using the Binder mechanism, so as to obtain the response information associated with the privacy information acquisition request through the specified service; during the process of sending the privacy information acquisition request to the specified service through the Framework API using the Binder mechanism, call a preset binder_transaction kernel function, and collect entry parameter information through a probe at the entry point of the binder_transaction kernel function; obtain the entry parameter information and the associated information by calling a preset static instrumentation function; save the entry parameter information and the associated information to the eBPF Map; and analyze the response information, entry parameter information and associated information according to a preset privacy and security analysis method to obtain the security analysis test results of the target Android application.

[0176] Furthermore, the device is also used to: use an eBPF program in the eBPF virtual machine to trace specified key functions used by the target Android application during its operation using probes, so as to capture specified pointers when the specified key functions are executed; extract code association information of the executable code corresponding to the target Android application based on the specified pointers; wherein, the code association information includes: address information and size information; send the code association information to a user-space program, so that the user-space program can obtain the executable code based on the code association information and save it to a preset disk, thus confirming that the target Android application has been unpacked.

[0177] Furthermore, the device is also used for: a probe mechanism based on the eBPF virtual machine, setting probes at specified locations in the dynamic link libraries of the target Android application; when the target Android application executes to the specified location, it jumps to execute a pre-registered eBPF exception handler, obtains the processing result, and determines the dynamic instrumentation test result of the target Android application based on the processing result.

[0178] Furthermore, the device is also used to: inject a specified error into the target Android application through the eBPF virtual machine according to a preset error injection mechanism, so that when the target Android application makes a specified system call, it returns a specified return value corresponding to the specified error.

[0179] Furthermore, the device is also used to: query the user identification information, process name, and preset blocking policy corresponding to the target Android application through the eBPF Map; compare the user identification information and process name with the preset blocking policy respectively to obtain the comparison result; and return a specified error code if the comparison result indicates that there is illegal behavior.

[0180] Furthermore, the device is also used to: if both the target operation request and response information are encrypted, obtain the location information of a preset derived function, and set a probe at the first location indicated by the location information; when the target Android application executes to the first location, obtain the plaintext corresponding to the target operation request and the plaintext of the response information associated with the target operation request based on the eBPF program in the eBPF virtual machine; and obtain the security analysis test results of the target Android application by analyzing the plaintext corresponding to the target operation request and the plaintext of the response information.

[0181] The Android application security analysis and testing device provided in this embodiment of the invention has the same implementation principle and technical effect as the aforementioned Android application security analysis and testing method embodiment. For the sake of brevity, any parts not mentioned in the Android application security analysis and testing device embodiment can be referred to the corresponding content in the aforementioned Android application security analysis and testing method embodiment.

[0182] This invention also provides an electronic device, see [link to relevant documentation]. Figure 19 As shown, the electronic device includes a processor 130 and a memory 131. The memory 131 stores machine-executable instructions that can be executed by the processor 130. The processor 130 executes the machine-executable instructions to implement the security analysis and testing method of the above-mentioned Android application.

[0183] Furthermore, Figure 19 The electronic device shown also includes a bus 132 and a communication interface 133, with the processor 130, the communication interface 133 and the memory 131 connected via the bus 132.

[0184] The memory 131 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 133 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 132 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 19 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0185] Processor 130 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 130 or by instructions in software form. Processor 130 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 131, and processor 130 reads the information in memory 131 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0186] This invention also provides a machine-readable storage medium storing machine-executable instructions. When these machine-executable instructions are called and executed by a processor, they cause the processor to implement the aforementioned security analysis and testing method for Android applications. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0187] The computer program product of the security analysis and testing method for Android applications provided in this embodiment of the invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0188] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0189] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A security analysis and testing method for Android applications, characterized in that, The method is applied to an electronic device running an Android operating system; the Android operating system includes: a kernel layer and an application layer that are isolated from each other; the kernel layer has an eBPF virtual machine, and the eBPF virtual machine loads an eBPF program; the application layer includes multiple Android applications, and the method includes: Generate a target operation request from the target Android application; The target operation request is sent to the kernel layer; Based on the eBPF program in the eBPF virtual machine, obtain response information associated with the target operation request, and analyze the response information to obtain the security analysis test results of the target Android application; The target operation request is either a file operation request or a privacy information acquisition request. The steps of obtaining response information associated with the target operation request based on the eBPF program in the eBPF virtual machine, and obtaining the security analysis test results of the target Android application by analyzing the response information, include: Based on the target operation request, determine the target system call corresponding to the target operation request; A trace point is attached to the target system call so that the system call parameters and system call return data corresponding to the target operation request can be obtained by the eBPF program in the eBPF virtual machine. The system call parameters are analyzed to obtain the operation analysis results corresponding to the system call return data; Based on the operation analysis results, it is determined whether there are any abnormal behaviors in the operation behavior of the system call returned data, and the determination result is obtained; The security analysis and test results of the target Android application are determined based on the judgment results; The steps of obtaining the system call parameters and system call return data corresponding to the target operation request through the eBPF program in the eBPF virtual machine include: Before executing the target system call, the eBPF program in the eBPF virtual machine calls a pre-registered first callback function to track the system call parameters corresponding to the target operation request according to the first callback function; Invoke the target system call to execute the processing logic corresponding to the target system call; After the target system call is completed, the eBPF program in the eBPF virtual machine calls the pre-registered second callback function to track the system call return data corresponding to the target operation request according to the second callback function.

2. The method according to claim 1, characterized in that, Before executing the target system call, the step of calling a pre-registered first callback function through the eBPF program in the eBPF virtual machine to trace the system call parameters corresponding to the target operation request according to the first callback function includes: Before executing the target system call, it is determined whether the target operation request meets preset filtering parameters; wherein, the preset filtering parameters include: system call number, user identifier filtering event; If the target operation request matches the preset filtering parameters, the eBPF program in the eBPF virtual machine calls the pre-registered first callback function to track the system call parameters corresponding to the target operation request according to the first callback function.

3. The method according to claim 1, characterized in that, The target operation request is: a privacy information acquisition request; The steps of obtaining response information associated with the target operation request based on the eBPF program in the eBPF virtual machine, and obtaining the security analysis test results of the target Android application by analyzing the response information, include: The system calls a preset Framework API and uses the Binder mechanism to send the privacy information acquisition request to a designated service that matches the privacy information acquisition request, so as to obtain the response information associated with the privacy information acquisition request through the designated service. During the process of sending the privacy information acquisition request to the designated service through the Framework API using the Binder mechanism, a preset binder_transaction kernel function is called, and at the entry point of the binder_transaction kernel function, entry parameter information is collected by a probe. By calling a preset static instrumentation function, the entry parameter information and the associated information related to the entry parameter information are obtained; The input parameter information and the associated information are saved to the eBPF Map; The response information, the entry parameter information, and the associated information are analyzed according to a preset privacy and security analysis method to obtain the security analysis test results of the target Android application.

4. The method according to claim 1, characterized in that, The method further includes: The eBPF program in the eBPF virtual machine uses probes to trace specified key functions used by the target Android application during its operation, so as to capture specified pointers when the specified key functions are executed. Extract code association information of the executable code corresponding to the target Android application based on the specified pointer; wherein, the code association information includes: address information and size information; The code association information is sent to a user-mode program so that the user-mode program can obtain the executable code based on the code association information and save it to a preset disk, thus confirming that the target Android application has been unpacked.

5. The method according to claim 1, characterized in that, The method further includes: Based on the probe mechanism of the eBPF virtual machine, a probe is set at a specified location in the dynamic link library of the target Android application. When the target Android application reaches the specified location, it jumps to execute the pre-registered eBPF exception handler to obtain the processing result, and determines the dynamic instrumentation test result of the target Android application based on the processing result.

6. The method according to claim 1, characterized in that, The method further includes: The eBPF virtual machine injects a specified error into the target Android application according to a preset error injection mechanism, so that when the target Android application makes a specified system call, it returns a specified return value corresponding to the specified error.

7. The method according to claim 1, characterized in that, The method further includes: The eBPF Map is used to query the user identification information, process name, and preset blocking policy corresponding to the target Android application. The user identification information and the process name are compared with the preset blocking policy to obtain the comparison results; If the comparison result indicates illegal behavior, return the specified error code.

8. The method according to claim 1, characterized in that, The step of obtaining the security analysis test results of the target Android application by analyzing the response information includes: If both the target operation request and the response information are encrypted, obtain the location information of the preset derived function, and set a probe at the first location indicated by the location information; When the target Android application executes to the first position, based on the eBPF program in the eBPF virtual machine, the plaintext corresponding to the target operation request and the plaintext of the response information associated with the target operation request are obtained; By analyzing the plaintext corresponding to the target operation request and the plaintext of the response information, the security analysis test results of the target Android application are obtained.

Images