Android system fine-grained traceability data acquisition method and device based on eBPF

Abstract

The invention provides an eBPF-based Android system fine-grained traceability data acquisition method and device. The method comprises the following steps: mounting eBPF hooks on different abstraction layers of an Android system to obtain information of the different abstraction layers; obtaining an association relationship between different abstraction layers based on the information of the different abstraction layers; and constructing a cross-layer traceability graph by taking the different abstraction layers as nodes and taking the incidence relation between the different abstraction layers as edges. According to the scheme, hooks are mounted in different entities of the Android system based on the eBPF to collect multiple types of information, and the cross-layer information association module is constructed to obtain the relationship between the entities so as to construct the cross-layer traceability graph, so that non-intrusive high-performance data collection, accurate traceability and behavior analysis are realized.

Description

Technical Field

[0001] The present application relates to the field of information security, and in particular to a method and device for collecting fine-grained traceability data for an Android system based on eBPF. Background Art

[0002] In recent years, with the rapid development of smartphones and mobile Internet, the Android operating system has become one of the most widely used mobile operating systems in the world. At the same time, cyber attacks and malware targeting Android devices are emerging in an endless stream. Attackers use various methods such as system vulnerabilities, social engineering, and malicious applications to infiltrate devices, and even launch advanced persistent threat (APT) attacks. These attacks usually use multi-layered and highly covert means to bypass traditional security protection mechanisms, posing a serious threat to user privacy and data security.

[0003] Currently, mainstream malware detection methods are mainly divided into two categories: static analysis and dynamic analysis. Static analysis usually determines whether an APK file has malicious behavior by extracting features such as permissions, API calls, and code structure. However, the detection effect of static analysis is greatly limited by evasion techniques such as code obfuscation, dynamic loading, and encryption protection. Dynamic analysis detects potential threats by running applications and observing their behavior. However, existing dynamic detection solutions usually rely on traditional hook technologies such as inline hooks and ptrace. These methods often require modifying the system operating environment, which may introduce additional performance overhead or be detected and evaded by malware. Dynamic sandbox detection runs in a simulated environment and is easily identified and evaded by malware through environmental fingerprint detection (such as IMEI and hardware information). In addition, it is difficult for them to comprehensively and accurately monitor the interactions between the four major components of the Android system: Activity, Service, Broadcast Receiver, and Content Provider, so there are limitations in their understanding of malicious behavior. The Android system consists of multiple layers, including the application layer, framework layer, kernel layer, etc. Components at each layer work together to complete system functions. Traditional dynamic detection methods often have problems with cross-layer and cross-component data inconsistency or loss during data collection and processing, resulting in misjudgment or omission of malicious behavior analysis. Traditional dynamic analysis methods also often only focus on a single dimension and lack a global understanding of system behavior. When facing advanced threats (such as APT attacks), it is difficult to accurately identify complex attack chains based on isolated behavior records alone, and it is impossible to provide effective traceability information. Summary of the Invention

[0004] The embodiments of the present application provide a fine-grained traceability data collection method and device for the Android system based on eBPF. Based on eBPF, hooks are mounted on different entities in the Android system to collect multiple types of information, and a cross-layer information association module is constructed to obtain the relationship between entities to construct a cross-layer traceability graph, thereby realizing non-invasive high-performance data collection, precise traceability and behavior analysis.

[0005] In a first aspect, an embodiment of the present application provides a method for collecting fine-grained traceability data for an Android system based on eBPF, the method comprising: Mount eBPF hooks on the process entity, file entity, network connection entity, Android component entity, framework API entity, and system call entity in the Android system to obtain the corresponding process call information, file access information, network connection information, IPC interaction information, API call information, and system call information; Construct a cross-layer information association module, which obtains the association relationship between process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities based on process call information, file access information, network connection information, IPC interaction information, API call information and system call information; A cross-layer traceability graph is constructed with process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities as nodes and the association relationships between process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities as edges.

[0006] In a second aspect, an embodiment of the present application provides an Android system fine-grained traceability data collection device based on eBPF, including: The hook mounting module is used to mount eBPF hooks on the process entity, file entity, network connection entity, Android component entity, framework API entity, and system call entity in the Android system to obtain the corresponding process call information, file access information, network connection information, IPC interaction information, API call information, and system call information; Build a cross-layer information association module to obtain the association relationship between process entities, file entities, network connection entities, Android component entities, framework API entities, and system call entities based on process call information, file access information, network connection information, IPC interaction information, API call information, and system call information; The traceability module uses process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities as nodes, and the association relationships between process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities as edges to build a cross-layer traceability graph.

[0007] In a third aspect, an embodiment of the present application provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute an eBPF-based Android system fine-grained traceability data collection method.

[0008] In a fourth aspect, an embodiment of the present application provides a readable storage medium, in which a computer program is stored. The computer program includes a program code for controlling a process so that the process is executed by a processor. When the program code is executed by the processor, a fine-grained traceability data collection method for an Android system based on eBPF is implemented.

[0009] The main contributions and innovations of the present invention are as follows: In terms of data collection, the embodiment of the present application implements non-invasive, high-performance data collection by mounting eBPF hooks on the process entity, file entity, network connection entity, Android component entity, framework API entity, and system call entity of the Android system. This allows for the acquisition of rich runtime information with minimal system overhead, and the dynamic adjustment of the acquisition frequency of API call information and system call information, reducing noise and redundant data collection, and reducing the impact on system performance. In terms of information association and tracing, a cross-layer information association module is constructed to obtain the association relationship between various entities, and then a cross-layer traceability graph is constructed. The graph is a multi-level directed graph structure with millisecond-level timestamps on the edges. It can not only trace the attack evolution path along the timeline, but also achieve complete semantic connection from user intent to kernel behavior by setting upper-level semantic labels for nodes. It supports reverse tracing and behavior pattern reconstruction starting from any node, has good real-time and interpretability, and effectively solves the problems of traditional detection methods that are difficult to fully and accurately monitor component interactions, inconsistent or lost cross-layer and cross-component data, and lack of global understanding. It can accurately identify complex attack chains and provide strong support for malicious behavior analysis and tracing.

[0010] The details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more readily apparent. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings: Figure 1 This is a flowchart of a method for collecting fine-grained traceability data for an Android system based on eBPF according to an embodiment of the present application; Figure 2 This is a logic diagram of obtaining IPC interaction information and storing it in an IPC mapping table through a Binder IPC monitoring hook according to an embodiment of the present application; Figure 3 It is a logic diagram of obtaining API call information through an API call monitoring hook and storing it in an API mapping table according to an embodiment of the present application; Figure 4 It is a logic diagram of obtaining system call information through a system call hook and storing it in a system call mapping table according to an embodiment of the present application; Figure 5 This is a logic diagram for obtaining component information into a component mapping table by combining monitoring ActivityTaskManager logs and polling dumpsys activity activities information according to an embodiment of the present application; Figure 6 This is a structural block diagram of an eBPF-based fine-grained traceability data acquisition device for an Android system according to an embodiment of the present application; Figure 7 Schematic diagram of the hardware structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0012] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments are not intended to represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of one or more embodiments of this specification, as detailed in the appended claims.

[0013] It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than those described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments, and multiple steps described in this specification may be combined into a single step for description in other embodiments.

[0014] Example 1 The embodiment of the present application provides an Android system fine-grained traceability data collection method based on eBPF. Based on eBPF, different entities in the Android system are hooked to collect multiple types of information, and a cross-layer information association module is constructed to obtain the relationship between entities to build a cross-layer traceability graph, thereby achieving non-intrusive high-performance data collection, accurate traceability and behavior analysis. Specifically, reference Figure 1 , the method comprising: Mount eBPF hooks on the process entity, file entity, network connection entity, Android component entity, framework API entity, and system call entity in the Android system to obtain the corresponding process call information, file access information, network connection information, IPC interaction information, API call information, and system call information; Construct a cross-layer information association module, which obtains the association relationship between process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities based on process call information, file access information, network connection information, IPC interaction information, API call information and system call information; A cross-layer traceability graph is constructed with process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities as nodes and the association relationships between process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities as edges.

[0015] In some specific embodiments, the process entity is the process corresponding to each running software in the background when the software is running on the Android system. A process management hook is mounted on the process entity to obtain process call information. The process management eBPF hook is used to monitor the creation and execution of the process, and the parent-child relationship between processes to help identify the incubation chain of malware.

[0016] Furthermore, this solution stores process call information by defining a process mapping table, where the process call information includes a process ID, a user ID, and a parent-child relationship of processes.

[0017] Specifically, use the fork or execve function to implement the mounting of the process management hook.

[0018] In some specific embodiments, the file entity is file data stored in the Android system, and a file access hook is mounted on the file entity to detect the process's access to the file entity to obtain file access information, thereby helping the system to identify malware's access to sensitive files and analyze malicious traffic patterns.

[0019] Furthermore, this solution stores file access information by defining a file mapping table, where the file access information includes the operation history of each process on the file entity, the access path of the file entity, access rights, and whether the file entity is a sensitive file.

[0020] Specifically, VFS, openat, and read / write functions are used to implement the mounting of file access hooks.

[0021] In some specific embodiments, the network connection entity is a network channel established when the Android system interacts with other devices through the network. A network behavior hook is mounted in the network connection entity to detect the communication behavior of the Android system, thereby helping to analyze malicious traffic patterns and suspicious communications.

[0022] Furthermore, this solution stores network connection information by defining a network mapping table, where the network connection information includes IP addresses, ports, and DNS queries.

[0023] Specifically, use the socket, connect, and sendmsg functions to implement the mounting of network behavior hooks.

[0024] In some specific embodiments, the Android component entity is a basic building block of an Android application, including Activity, Service, Broadcast Receiver and Content Provider. A Binder IPC monitoring hook is mounted in the Android component entity to monitor the interaction relationship between different basic building blocks of the Android application to obtain IPC interaction information.

[0025] Furthermore, this solution stores IPC interaction information by defining an IPC mapping table, where the IPC interaction information includes the process IDs of the caller and the callee, the component name, the target handle of the called service, and the transaction code.

[0026] Specifically, the logic diagram of obtaining IPC interaction information and storing it in the IPC mapping table through the Binder IPC monitoring hook is as follows: Figure 2 As shown, this solution uses the Binder function to implement the mounting of the Binder IPC monitoring hook. Figure 2The process first captures the binder_transaction event via eBPF as input data. Based on the target handle in the raw data, it then retrieves information about the target process with which the source process or component interacts via Binder. Next, the transaction code is used to parse the specific service interface called in the target process. Ultimately, this information is represented as a structured IPC mapping table containing fields such as "calling process ID, component name, called service process ID, and specific service," accurately restoring the semantics of Binder IPC events.

[0027] In some specific embodiments, the framework API entity is a business interface and method of the Android system, and an API call monitoring hook is mounted in the framework API entity to monitor the call information of the Android framework API.

[0028] Furthermore, this solution stores API call information by defining an API mapping table, where the API call information includes an API name, an API address, and an offset.

[0029] Specifically, this solution obtains API call information through API call monitoring hook and stores it in the logic diagram of API mapping table as shown below: Figure 3 As shown, through / proc / <pid> / maps gets the Zygote memory map, combines it with oatdump to parse the ota file, locates the address of the API in the memory to implement the mounting of the API call monitoring hook, Figure 3 First, based on the Zygote process memory map and OAT file parsing, the actual address of the target API in memory (base address + offset) is located; then, the eBPF uprobe hook is mounted to the API entry point to capture the calling process and the called Java layer API in real time; finally, this information is represented as a structured API mapping table containing fields such as "calling process, target API", realizing semantic association from the kernel layer to the Java API layer.

[0030] In some specific embodiments, the system call entity is a system call made by a user to request a service from the Android system, and a system call hook is mounted in the system call entity to monitor the system call information of the bottom layer of the Android system.

[0031] Furthermore, this solution stores system call information by defining a system call mapping table, where the system call information includes a system call ID, a system call name, and system call parameters.

[0032] Specifically, the logic diagram of obtaining system call information through the system call hook and storing it in the system call mapping table is as follows: Figure 4 As shown, the sys_enter and sys_exit functions are used to implement the mounting of the system call hook. Figure 4 First, eBPF captures system call events as input data. Based on the system call ID in the raw data, the corresponding specific system call name is obtained. The system call parameters are then supplemented. Ultimately, this information is represented as a structured system call mapping table containing segments such as the calling process ID and the called system call name, accurately restoring the semantics of Binder IPC events.

[0033] In some specific embodiments, this solution implements dynamic monitoring by mounting eBPF hooks at different abstraction layers of the Android system to perform non-invasive, high-performance data collection, thereby collecting process call information, file access information, network connection information, IPC interaction information, API call information, and system call information during Android runtime with minimal system overhead.

[0034] In some specific embodiments, the collection frequency of API call information and system call information is dynamically adjusted.

[0035] In some specific embodiments, in order to balance data integrity and system performance, this solution introduces a "sensitivity grading and dynamic sampling control" mechanism to control the collection frequency of API call information and system call information, so as to reduce system resource overhead, avoid redundant data, and ensure the criticality and accuracy of behavior tracking.

[0036] In this solution, "high-frequency" calls refer to the number of system calls or API calls exceeding a preset threshold within a unit of time (e.g., one second). For example, system calls like read, write, and open triggered more than 300 times within one second, or network connection attempts (such as the connect system call) exceeding 30 times within one second, are considered high-frequency behavior. For these high-frequency operations, the system automatically adjusts the sampling frequency, using event-interval sampling and aggregated statistics to reduce memory and CPU overhead. For example, for consecutive system calls, the sampling ratio can be adjusted to 1:N, retaining only typical call information. For repeated HTTP Keep-Alive network connection behavior, the system automatically filters out duplicates.

[0037] Specifically, this solution classifies API call information and system call information based on their sensitivity, and dynamically adjusts the sampling frequency of high-frequency system call information and API call information to reduce noise. The benefit of this is to ensure the non-intrusiveness of the tracking process, reduce the collection of redundant data, reduce the impact on system performance, and reduce the system computing overhead when generating cross-layer traceability graphs.

[0038] Sensitivity levels are divided based on the potential risks of the operation type, including but not limited to the following three aspects: (1) Data access risk classification: Operations that access user sensitive data are classified as high sensitivity, such as APIs that access contacts, SMS logs, location information (GPS), media resources (audio, image, video), such as ContentResolver.query(), TelephonyManager.getLine1Number(), etc.; operations that access external storage directories, application installation packages, etc. are classified as medium sensitivity; operations that access cache or temporary files are classified as low sensitivity.

[0039] (2) Permission and control capability classification: Component scheduling APIs with control capabilities are classified as high sensitivity, such as sendTextMessage(), startService(), bindService(), etc.; APIs that access system configurations are classified as medium sensitivity, such as Settings.Secure.getXXX(); APIs related to ordinary UI operations are classified as low sensitivity.

[0040] (3) System call behavior classification: System calls with significant execution capabilities are classified as high sensitivity, such as execve, ptrace, and mmap (with execution permissions); system calls with moderate control capabilities are classified as medium sensitivity, such as openat, unlink, and chmod; system calls that are frequently used in daily life but have lower risks (such as gettimeofday and futex) are classified as low sensitivity.

[0041] Based on the above classification system, a corresponding relationship is established between the sampling strategy and the sensitivity of the calling behavior: for API and system calls with high sensitivity levels, the system maintains complete sampling even if the calling frequency is high to ensure the traceability of the behavior; for calls with low sensitivity levels and excessively high triggering frequency, the system can dynamically reduce the sampling ratio according to the frequency threshold, thereby reducing the collection overhead.

[0042] In some embodiments, the association relationships among process entities, file entities, network connection entities, Android component entities, framework API entities, and system call entities include association relationships between entities of different types and association relationships between entities of the same type.

[0043] In some specific embodiments, when a user calls a component through an Android application, the relevant process and component information will be recorded in a process mapping table and a component mapping table, and the mapping table is associated through the user ID and the process ID.

[0044] For example, when a chat software interface is opened in an Activity component on the Android system, the system will store the process call information of the chat software in the process mapping table and the IPC interaction information of the Activity component in the IPC mapping table. The logic diagram of obtaining component information and mapping it to the component mapping table by monitoring the ActivityTaskManager log and polling the dumpsys activity activities information is as follows: Figure 5 As shown, in Figure 5 To enhance the mapping capability between the underlying behavior obtained from the kernel perspective and the semantics of application-layer components, the system-provided logcat and dumpsys interfaces are used in user mode to obtain structured information of currently running components (such as Activities). Combined with the process behavior, Binder interaction, system calls, network access and other data collected by eBPF, semantic fusion is performed through process ID and timestamp to construct a component mapping table and achieve behavioral observability of component entities. In other words, this solution associates component information with process information in the component mapping table by monitoring ActivityTaskManager logs and polling dumpsys activity activities, and associates the process call information of the chat software with the IPC interaction information of the Activity component through user ID and process ID.

[0045] In some specific embodiments, when a user calls a component through an Android application, causing communication between different processes, the IPC interaction information between different processes will be recorded in the IPC mapping table, and the association relationship between different processes will be obtained through the target handle and transaction code.

[0046] For example, a chat software has a main process and a sub-process responsible for pushing messages. The IPC mapping table will record that the main process is the caller and the sub-process that pushes messages is the callee. At the same time, the target handle and transaction code will make it clear that this communication is to obtain new message reminders, so that the details of inter-process communication can be clearly presented.

[0047] In some specific embodiments, when a user operates in an application, the application often calls the framework API provided by the Android system to implement specific functions. The system will capture and parse these API calls and record the relationship between the caller (usually a process or component) and the service called through the API.

[0048] For example, when a user clicks the share function in an application, the application calls the system's share API. The system will record which application process calls the share API and the corresponding sharing service behind the API, making it easier to understand how the application uses the system function.

[0049] In some specific embodiments, the Android framework API will eventually call the underlying system calls. The system will capture these system calls and parse the specific call content and related parameters to obtain the most fine-grained behavior information.

[0050] For example, an application calls an API to read a file. This API will eventually trigger the underlying file reading system call. After the system captures and parses this system call, it can know the specific file being read, the starting position and length of the read, and other detailed information, thereby gaining a deeper understanding of the underlying system operations.

[0051] In some specific embodiments, data related to file operations are associated with file names through a file mapping table. The file mapping table records relevant information about file operations, and these operations can be matched with specific files through the file names.

[0052] For example, if an application performs a read operation on a file named "user_info.txt", the file mapping table will record detailed information about the operation. The file name "user_info.txt" can be used to associate the operation with the file, making it easier to track file usage.

[0053] In some embodiments, the cross-layer provenance graph is a multi-level directed graph structure, and each edge of the cross-layer provenance graph carries a millisecond timestamp.

[0054] Specifically, the millisecond-level timestamp on each edge of the cross-layer traceability graph can be used to trace the attack evolution path along the timeline.

[0055] Specifically, the cross-layer traceability graph in this solution will be dynamically updated based on data such as process call information, file access information, network connection information, IPC interaction information, API call information, and system call information.

[0056] In some specific embodiments, an upper-layer semantic label is set for each node in the cross-layer traceability graph, and the upper-layer semantic label is the behavior logic of the user calling the node.

[0057] Specifically, the user's operation intention of calling the corresponding node is obtained based on the process call information and IPC interaction information, and the operation purpose of the operation intention is obtained based on the API call information. Based on the operation intention and operation purpose, an upper-level semantic label is set for each node in the cross-layer traceability graph.

[0058] Specifically, the startup behavior of the component is monitored through the process call information, and the specific target components and services that the application interacts with are identified through the transaction code and target handle information in the IPC interaction information during the interaction process, thereby obtaining the operation intention initiated by the user or application layer.

[0059] For example, the user's operation intention includes interface jump, service request, background task startup, broadcast registration and reception, etc., combined with API call information, such as accessing phone status (TelephonyManager.getDeviceId), sending text messages (SmsManager.sendTextMessage), obtaining geographic location information (such as LocationManager.getLastKnownLocation), accessing contacts (such as ContentResolver.query(ContactsContract.Contacts.CONTENT_URI)), reading media files (such as MediaStore.Images.Media.EXTERNAL_CONTENT_URI), etc., the purpose and context of the specific operation can be further inferred.

[0060] Specifically, user intent analysis needs to be combined with underlying system behavior verification to eliminate misjudgments. Through fine-grained collection and semantic verification of low-level behaviors such as system calls, file operations, and network communications, accurate identification of complex attack behaviors and detection of dynamic code behaviors can be achieved.

[0061] Specifically, this solution uses a cross-layer traceability graph to achieve cross-layer mapping, achieving a complete semantic connection from user intent to kernel behavior. By using node information at higher levels, such as components and APIs, this solution addresses the semantic gaps often seen in traditional system call logs. Furthermore, by using low-level node information at the system call layer, this solution addresses the lack of granular semantics in API detection and the avoidance of dynamically loaded code in traditional Android detection systems, thus resolving the detection blind spots caused by dynamic code loading in traditional solutions.

[0062] Specifically, by embedding the hierarchical information of the cross-layer traceability graph and the timestamps in the edges of the cross-layer traceability graph, it supports reverse tracing and behavior pattern reconstruction starting from any node, with good real-time performance and explainability.

[0063] Example 2 Based on the same concept, refer to Figure 6 , this application also proposes an Android system fine-grained traceability data collection device based on eBPF, including: The hook mounting module is used to mount eBPF hooks on the process entity, file entity, network connection entity, Android component entity, framework API entity, and system call entity in the Android system to obtain the corresponding process call information, file access information, network connection information, IPC interaction information, API call information, and system call information; Build a cross-layer information association module to obtain the association relationship between process entities, file entities, network connection entities, Android component entities, framework API entities, and system call entities based on process call information, file access information, network connection information, IPC interaction information, API call information, and system call information; The traceability module uses process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities as nodes, and the association relationships between process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities as edges to build a cross-layer traceability graph.

[0064] Example 3 This embodiment also provides an electronic device, referring to Figure 7 , includes a memory 404 and a processor 402, wherein the memory 404 stores a computer program, and the processor 402 is configured to run the computer program to perform the steps in any of the above method embodiments.

[0065] Specifically, the processor 402 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0066] Memory 404 may include a large-capacity memory 404 for data or instructions. By way of example, and not limitation, memory 404 may include a hard disk drive (HDD), a floppy disk drive, a solid-state drive (SSD), flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 404 may include removable or non-removable (or fixed) media. Where appropriate, memory 404 may be internal or external to the data processing device. In certain embodiments, memory 404 is non-volatile memory. In certain embodiments, memory 404 includes read-only memory (ROM) and random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically alterable ROM (EAROM) or a flash memory (FLASH), or a combination of two or more of these. In appropriate circumstances, the RAM may be a static random access memory (SRAM) or a dynamic random access memory (DRAM), wherein the DRAM may be a fast page mode dynamic random access memory 404 (FPMDRAM), an extended data output dynamic random access memory (EDODRAM), a synchronous dynamic random access memory (SDRAM), etc.

[0067] The memory 404 may be used to store or cache various data files required for processing and / or communication, as well as possible computer program instructions executed by the processor 402 .

[0068] The processor 402 reads and executes computer program instructions stored in the memory 404 to implement any one of the eBPF-based fine-grained traceability data collection methods for the Android system in the above embodiments.

[0069] Optionally, the electronic device may further include a transmission device 406 and an input / output device 408 , wherein the transmission device 406 is connected to the processor 402 , and the input / output device 408 is connected to the processor 402 .

[0070] Transmission device 406 can be used to receive or transmit data via a network. Specific examples of such networks may include wired or wireless networks provided by the electronic device's communications provider. In one embodiment, the transmission device includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, transmission device 406 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0071] The input and output devices 408 are used to input or output information. In this embodiment, the input information may be process call information, file access information, network connection information, IPC interaction information, API call information, and system call information, and the output information may be a cross-layer traceability graph.

[0072] Optionally, in this embodiment, the processor 402 may be configured to execute the following steps through a computer program: Mount eBPF hooks on the process entity, file entity, network connection entity, Android component entity, framework API entity, and system call entity in the Android system to obtain the corresponding process call information, file access information, network connection information, IPC interaction information, API call information, and system call information; Construct a cross-layer information association module, which obtains the association relationship between process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities based on process call information, file access information, network connection information, IPC interaction information, API call information and system call information; A cross-layer traceability graph is constructed with process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities as nodes and the association relationships between process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities as edges.

[0073] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be repeated here.

[0074] In general, various embodiments may be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects of the invention may be implemented in hardware, while other aspects may be implemented in firmware or software executed by a controller, microprocessor, or other computing device, but the invention is not limited thereto. Although various aspects of the invention may be shown and described as block diagrams, flow charts, or using some other graphical representation, it should be understood that, as non-limiting examples, the blocks, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or a controller or other computing device, or some combination thereof.

[0075] The embodiments of the present invention may be implemented by computer software that is executable by a data processor of a mobile device, such as in a processor entity, or by hardware, or by a combination of software and hardware. Computer software or programs (also referred to as program products) including software routines, applets and / or macros may be stored in any device-readable data storage medium, and they include program instructions for performing specific tasks. A computer program product may include one or more computer executable components that are configured to perform an embodiment when the program is run. One or more computer executable components may be at least one software code or a portion thereof. In addition, it should be noted at this point that, for example, Figure 7 Any block of the logic flow in the program may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on physical media such as memory chips or memory blocks implemented within the processor, magnetic media such as hard disks or floppy disks, and optical media such as, for example, DVDs and their data variants, CDs, etc. Physical media are non-transitory media.

[0076] Those skilled in the art should understand that the technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0077] The above embodiments merely illustrate several embodiments of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, all of which fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.< / pid>

Claims

1. A fine-grained traceability data collection method for Android system based on eBPF, characterized in that: The following steps are involved: Mount eBPF hooks on the process entity, file entity, network connection entity, Android component entity, framework API entity, and system call entity in the Android system to obtain the corresponding process call information, file access information, network connection information, IPC interaction information, API call information, and system call information; Construct a cross-layer information association module, which obtains the association relationship between process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities based on process call information, file access information, network connection information, IPC interaction information, API call information and system call information; A cross-layer traceability graph is constructed with process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities as nodes and the association relationships between process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities as edges.

2. The method for collecting fine-grained traceability data for an Android system based on eBPF according to claim 1 is characterized in that: Mounting a process management hook on the process entity to obtain process call information; A file access hook is mounted on the file entity to detect the process's access to the file entity to obtain file access information; a network behavior hook is mounted in the network connection entity to detect the communication behavior of the Android system; a Binder IPC monitoring hook is mounted in the Android component entity to monitor the interaction relationship between different basic building blocks of the Android application to obtain IPC interaction information; an API call monitoring hook is mounted in the framework API entity to monitor the call information of the Android framework API; and a system call hook is mounted in the system call entity to monitor the system call information of the underlying Android system.

3. The method for collecting fine-grained traceability data for an Android system based on eBPF according to claim 1 is characterized in that: A process mapping table is defined to store process call information, including process ID, user ID, and process parent-child relationship. A component mapping table is defined to store application component call information, including component name, package name, process name, and current running status. A file mapping table is defined to store file access information, including the operation history of each process on the file entity, the access path of the file entity, access rights, and whether the file is a sensitive file. By defining a network mapping table to store network connection information, the network connection information includes IP address, port and DNS query; by defining an IPC mapping table to store IPC interaction information, the IPC interaction information includes the process ID of the caller and the callee, the component name, the target handle of the called service and the transaction code; An API mapping table is defined to store API call information, which includes an API name, an API address, and an offset; a system call mapping table is defined to store system call information, which includes a system call ID, a system call name, and system call parameters.

4. The method for collecting fine-grained traceability data for an Android system based on eBPF according to claim 1, wherein: Dynamically adjust the collection frequency of API call information and system call information.

5. The method for collecting fine-grained traceability data for an Android system based on eBPF according to claim 1 is characterized in that: The association relationships among process entities, file entities, network connection entities, Android component entities, framework API entities, and system call entities include association relationships between entities of different types and association relationships between entities of the same type.

6. The method for collecting fine-grained traceability data for an Android system based on eBPF according to claim 1, wherein: The cross-layer provenance graph is a multi-level directed graph structure, and each edge of the cross-layer provenance graph carries a millisecond-level timestamp.

7. The method for collecting fine-grained traceability data for an Android system based on eBPF according to claim 1, wherein: An upper-layer semantic label is set for each node in the cross-layer traceability graph, where the upper-layer semantic label is the behavior logic of the user calling the node.

8. A fine-grained traceability data acquisition device for Android system based on eBPF, characterized in that: include: The hook mounting module is used to mount eBPF hooks on the process entity, file entity, network connection entity, Android component entity, framework API entity, and system call entity in the Android system to obtain the corresponding process call information, file access information, network connection information, IPC interaction information, API call information, and system call information; Build a cross-layer information association module to obtain the association relationship between process entities, file entities, network connection entities, Android component entities, framework API entities, and system call entities based on process call information, file access information, network connection information, IPC interaction information, API call information, and system call information; The traceability module uses process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities as nodes, and the association relationships between process entities, file entities, network connection entities, Android component entities, framework API entities and system call entities as edges to build a cross-layer traceability graph.

9. An electronic device comprising a memory and a processor, characterized in that: The memory stores a computer program, and the processor is configured to run the computer program to execute the eBPF-based Android system fine-grained traceability data collection method described in any one of claims 1-7.

10. A readable storage medium, characterized in that: The readable storage medium stores a computer program, which includes a program code for controlling a process so that the process is executed by a processor. When the program code is executed by the processor, an eBPF-based Android system fine-grained traceability data collection method according to any one of claims 1 to 7 is implemented.

Images