Methods, devices, storage media, and products for monitoring application privacy data streams
By monitoring the interaction calls from the managed code layer to the native code layer in the application, sensitive data and memory addresses are obtained, data identifiers are created and associated, solving the problem that the native code layer cannot be monitored in the existing technology, realizing accurate tracking and monitoring of sensitive data, and generating a privacy data flow graph.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- VIPSHOP (GUANGZHOU) SOFTWARE CO LTD
- Filing Date
- 2026-02-10
- Publication Date
- 2026-05-26
Smart Images

Figure CN122086705A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of network security technology, and in particular to a method, device, storage medium and product for monitoring application privacy data streams. Background Technology
[0002] In the mobile network era, smart mobile terminals have increasingly become the primary terminal form for users to conduct various online activities due to their portability and low cost. With the rapid development of applications, people often have a large number of applications installed on their mobile phones. Through these applications, people can perform various business operations, and in doing so, they also input a large amount of personal privacy information. This personal privacy information is at risk of being misused, seriously endangering people's personal network security. Therefore, it is necessary for applications to monitor their personal information collection and data processing activities.
[0003] Current monitoring of application-level personal information collection and data processing primarily focuses on the high-level language layer of applications, such as the Java layer for Android applications or the Objective-C layer for iOS applications. Data collection behavior is analyzed by monitoring the API calls provided at these layers. However, with the increasing sophistication of applications and the strengthening of detection efforts, sensitive operations such as personal information collection and data processing are shifting to the lower-level native code layer. Because existing monitoring technologies only target the high-level language layer and cannot effectively penetrate cross-layer call boundaries such as Java native interfaces, existing high-level language-based detection solutions face significant monitoring blind spots. They cannot monitor sensitive behaviors at the native code layer, allowing a large number of evasive collection and processing behaviors to remain hidden, undetectable, and untraceable.
[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention
[0005] The main purpose of this application is to provide a method, device, storage medium and product for monitoring application privacy data streams, aiming to solve the technical problem that traditional privacy compliance detection solutions cannot detect the native code layer and have monitoring blind spots.
[0006] To achieve the above objectives, this application proposes a method for monitoring application privacy data streams, the method comprising: Monitor the interaction calls from the managed code layer to the native code layer in the application to obtain sensitive data and memory addresses, create data identifiers for the sensitive data, and associate the data identifiers with the memory addresses; Based on the data identifier, the sensitive data is monitored for behavior and data flow in the native code layer to obtain monitoring events; Based on the data identifier, the sensitive data, the memory address, and the monitoring event are associated to generate a privacy data flow graph.
[0007] In one embodiment, the steps of interactive calls from the managed code layer to the native code layer in the monitoring application include: Hook the data conversion interface function of the managed code layer; When the data conversion interface function is called, the sensitive data and the memory address are obtained.
[0008] In one embodiment, the step of associating the data identifier with the memory address includes: Construct a mapping relationship between the sensitive data and the memory address; The data identifier and the memory address are associated through the mapping relationship.
[0009] In one embodiment, the monitoring events include behavioral monitoring events and data monitoring events. The step of performing behavioral monitoring and data flow monitoring on the sensitive data in the native code layer based on the data identifier to obtain the monitoring events includes: By hooking preset key functions through a dynamic binary instrumentation mechanism, the operation results of function operations performed on the memory address associated with the data identifier are recorded to obtain the behavior monitoring event; By scanning memory and listening to functions that perform memory operations on the sensitive data, the propagation path of the sensitive data carrying the data identifier in memory is traced to obtain the data monitoring event.
[0010] In one embodiment, the step of hooking a preset key function through a dynamic binary instrumentation mechanism, recording the operation results of function operations performed on the memory address associated with the data identifier, and obtaining the behavior monitoring event includes: The detection code is injected into the application, and the memory address of the preset key function is located; Insert the detection code at the preset detection point of the preset key function; The detection code records the behavior monitoring events of the preset key functions, wherein the behavior monitoring events include the call stack, parameters, and return values.
[0011] In one embodiment, the step of tracing the propagation path of the sensitive data carrying the data identifier in memory by scanning memory and listening to functions that perform memory operations on the sensitive data, and obtaining the data monitoring event, includes: Create a watchpoint for the memory address associated with the data identifier; Listen for function calls that operate on the sensitive data. If the function call is a memory operation function and the source address of the memory operation function matches the address of any monitoring point, record the propagation path of the sensitive data and update the address of the monitoring point to obtain the data monitoring event.
[0012] In one embodiment, the step of associating the sensitive data, the memory address, and the monitoring event based on the data identifier to generate a privacy data flow graph includes: Based on the data identifier, identify the behavioral monitoring events and data monitoring events that match the sensitive data from the monitoring events; By identifying the matching relationships between behavioral monitoring events and data monitoring events, the sensitive data, the memory address, and the monitoring events are associated to generate the privacy data flow graph. The types of matching relationships include time sequence relationships, call stack relationships, and memory address passing relationships.
[0013] In addition, to achieve the above objectives, this application also proposes an electronic device, the device comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the application privacy data stream monitoring method as described above.
[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the application privacy data stream monitoring method described above.
[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the application privacy data stream monitoring method described above.
[0016] One or more technical solutions proposed in this application have at least the following technical effects: The system monitors interactive calls from the managed code layer to the native code layer in an application to obtain sensitive data and memory addresses. Data identifiers are created for the sensitive data, and these identifiers are associated with the memory addresses. Based on these data identifiers, behavioral and data flow monitoring is performed on the sensitive data in the native code layer to obtain monitoring events. Finally, the sensitive data, memory addresses, and monitoring events are associated based on the data identifiers to generate a privacy data flow graph. In this embodiment, by monitoring interactive calls, the system captures the transmitted sensitive data and its memory address in the native code layer, and establishes a mapping relationship to associate the data identifier with the memory address. The data identifier enables accurate tracking of sensitive data, achieving the capture and association of privacy data sources across runtime environments. Based on the data identifier, behavioral and data flow monitoring of sensitive data in the native code layer precisely identifies and monitors key functions that perform operations on sensitive data. Combined with memory scanning, it can track the flow and transformation of sensitive data carrying data identifiers in memory in real time, achieving instruction-level deep monitoring of unsigned, hardened native code. Based on data identification, discrete sensitive data, memory addresses, and monitoring events are associated to construct a complete privacy data flow graph from the data source at the high-level language layer to the internal processing at the native layer and then to the outgoing network, enabling accurate monitoring of sensitive operations at the native code layer. Attached Figure Description
[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0019] Figure 1 This is a flowchart illustrating an embodiment of the method for monitoring application privacy data streams in this application. Figure 2 A simplified flowchart illustrating the method for monitoring application privacy data streams provided in Embodiment 1 of this application; Figure 3 This is a flowchart illustrating a second embodiment of the method for monitoring application privacy data streams in this application. Figure 4 This is a schematic diagram of the structure of a monitoring system for application privacy data streams according to an embodiment of this application; Figure 5This is a schematic diagram of the device structure of the hardware operating environment involved in the monitoring method of application privacy data stream in the embodiments of this application.
[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation
[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.
[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.
[0023] The main solution of this application embodiment is: to monitor the interaction calls from the managed code layer to the native code layer in the application to obtain sensitive data and memory addresses, to create data identifiers for the sensitive data, and to associate the data identifiers with the memory addresses; to perform behavior monitoring and data flow monitoring on the sensitive data in the native code layer based on the data identifiers to obtain monitoring events; and to associate the sensitive data, the memory addresses, and the monitoring events based on the data identifiers to generate a privacy data flow graph.
[0024] In the mobile network era, smart mobile terminals have increasingly become the primary terminal form for users to conduct various online activities due to their portability and low cost. With the rapid development of applications, people often have a large number of applications installed on their mobile phones. Through these applications, people can perform various business operations, and in doing so, they also input a large amount of personal privacy information. This personal privacy information is at risk of being misused, seriously endangering people's personal network security. Therefore, it is necessary for applications to monitor their personal information collection and data processing activities.
[0025] Current monitoring of application-level personal information collection and data processing primarily focuses on the high-level language layer of applications, such as the Java layer for Android applications or the Objective-C layer for iOS applications. Data collection behavior is analyzed by monitoring the API calls provided at these layers. However, with the increasing sophistication of applications and the strengthening of detection efforts, sensitive operations such as personal information collection and data processing are shifting to the lower-level native code layer. Because existing monitoring technologies only target the high-level language layer and cannot effectively penetrate cross-layer call boundaries such as Java native interfaces, existing high-level language-based detection solutions face significant monitoring blind spots. They cannot monitor sensitive behaviors at the native code layer, allowing a large number of evasive collection and processing behaviors to remain hidden, undetectable, and untraceable.
[0026] This application provides a solution for monitoring interactive calls from the managed code layer to the native code layer in an application to obtain sensitive data and memory addresses. A data identifier is created for the sensitive data, and the data identifier is associated with the memory address. Based on the data identifier, behavioral and data flow monitoring is performed on the sensitive data in the native code layer to obtain monitoring events. The sensitive data, memory address, and monitoring events are then associated based on the data identifier to generate a privacy data flow graph. Specifically, in this embodiment, by monitoring interactive calls, the transmitted sensitive data and its memory address in the native code layer are captured, and a mapping relationship is established to associate the data identifier and memory address. The data identifier enables accurate tracking of sensitive data, achieving the capture and association of privacy data sources across runtime environments. Based on the data identifier, behavioral and data flow monitoring of sensitive data in the native code layer precisely hooks and monitors key functions that perform operations on sensitive data. Combined with memory scanning, the flow and transformation process of sensitive data carrying the data identifier in memory can be tracked in real time, achieving instruction-level deep monitoring of unsigned, hardened native code. Based on data identification, discrete sensitive data, memory addresses, and monitoring events are associated to construct a complete privacy data flow graph from the data source at the high-level language layer to the internal processing at the native layer and then to the outgoing network, enabling accurate monitoring of sensitive operations at the native code layer.
[0027] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device capable of realizing the above functions.
[0028] Based on this, embodiments of this application provide a method for monitoring application privacy data streams, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the method for monitoring application privacy data streams according to this application.
[0029] In this embodiment, the method for monitoring application privacy data streams includes steps S10 to S30: Step S10: Monitor the interaction calls from the managed code layer to the native code layer in the application to obtain sensitive data and memory addresses, create data identifiers for the sensitive data, and associate the data identifiers with the memory addresses; It's important to note that the managed code layer refers to the code layer managed and executed by a virtual machine or runtime environment, typically written in high-level languages such as Java, Kotlin, and Objective-C. The native code layer refers to the code layer directly compiled into machine code and executed directly on the operating system, typically written in languages such as C and C++. Interactive calls refer to applications actively initiating calls from the managed code layer to functions or procedures in the native code layer during execution. In the Android system, the core of this mechanism is the Java native interface; a complete interactive call includes a jump from a Java method to a native code layer function, parameter and data conversion. Sensitive data refers to data objects involving user privacy that are actually passed from the managed code layer to the native code layer during interactive calls. Examples include a string representing a unique device identifier or a byte array containing location information. Memory addresses refer to the addresses used to store sensitive data in the native code layer during interactive calls. Data identifiers are unique tracking tags generated for successfully capturing sensitive data and memory address records. These are typically globally unique symbols or hash values.
[0030] Specifically, the system monitors the interfaces for data exchange between the managed code layer and the native code layer. When an interface is called and data is transferred through it, the call is intercepted. The system then parses and extracts the specific content of the sensitive data being transferred, and determines the memory address where this sensitive data is stored after arriving at the native code layer. A globally unique data identifier is created for this sensitive data, and a mapping relationship is established between the sensitive data and the memory address. This mapping relationship is used to associate the data identifier with the memory address, thus establishing monitoring for data transfer between the managed code layer and the native code layer.
[0031] Understandably, existing privacy compliance monitoring solutions are all based on monitoring managed code layer APIs. When sensitive operations are transferred to the native code layer through interactive calls, the original monitoring settings for the managed code layer become completely ineffective, creating a monitoring blind spot and compromising user privacy. This application establishes a monitoring starting point covering the entire code layer by monitoring interactive calls from the managed code layer to the native code layer in the application. At critical moments when sensitive data crosses the runtime boundary, the sensitive data content and its memory address in the native code layer are captured synchronously, and a data identifier is created for the sensitive data. The data identifier and memory address are associated, providing a physical anchor for subsequent continuous tracking of sensitive data throughout the entire native code layer.
[0032] In one feasible implementation, the steps of the interactive calls from the managed code layer to the native code layer in the monitoring application include steps S101-S102: Step S101: Hook the data conversion interface function of the managed code layer; Step S102: When the data conversion interface function is called, the sensitive data and the memory address are obtained.
[0033] It's important to note that data conversion interface functions are a set of standard interface functions defined for interactions between the managed code layer and the native code layer. For example, in Android's JNI (Java Native Interface) mechanism, data conversion interface functions include functions for converting strings, obtaining array element pointers, or calling methods. These functions perform format conversion and address mapping on data in parameters and return values during cross-layer calls, serving as the necessary path for data to cross runtime boundaries. Hooking refers to dynamically instrumenting calls to data conversion interface functions during application runtime, causing the execution flow to first enter the monitoring code, thus achieving non-intrusive monitoring. When an interactive call triggers the hooked data conversion interface function, the monitoring code gains execution rights, accesses all data parameters involved in the interactive call, obtains the content of sensitive data, and determines the memory address of that sensitive data in the native code layer.
[0034] Understandably, existing privacy data monitoring solutions cannot intervene in cross-layer data exchange, creating monitoring blind spots. By hooking into data transformation interface functions, this solution correlates and monitors data as it leaves the managed code layer and enters the native code layer, enabling the capture and tracking of cross-layer data flows. Sensitive data and memory addresses are captured when the data transformation interface function is called, associating the application's cross-layer behavior with sensitive data and recording the memory address of that sensitive data in the native code layer. This provides a precise index for subsequent continuous tracking of that sensitive data in the native code layer.
[0035] In one feasible implementation, the step of associating the data identifier with the memory address includes steps S103-S104: Step S103: Construct a mapping relationship between the sensitive data and the memory address; Step S104: Associate the data identifier and the memory address through the mapping relationship.
[0036] It should be noted that by establishing a mapping relationship between sensitive data and memory addresses, the current memory address of the sensitive data in the native code layer can be directly obtained. The established sensitive data-memory address mapping relationship is used as the value, and the data identifier as the key, stored in a tracking and management data structure to achieve the association.
[0037] Understandably, by constructing a mapping relationship between sensitive data and memory addresses, and then associating data identifiers with memory addresses based on this mapping, a global lookup table is built. Through the data identifier, its corresponding memory address in the native code layer can be retrieved; conversely, through the monitored memory address, its associated data identifier can also be traced. By constructing this mapping relationship, not only can the corresponding memory address be traced through the data identifier, but more importantly, when any function operation targeting that memory address is monitored subsequently, it is possible to reverse-lookup and associate it with the sensitive data content. Ultimately, this achieves the key transformation of elevating memory operations to understandable privacy-preserving data behavior events.
[0038] Specifically, an Android application obtains the device identification code by calling a system API, and then calls a bridging method to the native code layer to pass the device identification code to the native code layer for processing. By pre-hooking the data conversion interface function, the monitoring logic is triggered when the JNI bridging code is a parameter of this bridging method. By monitoring this cross-layer interaction call, the sensitive data content passed here, namely the string "123456012344", is obtained, and the memory address of this string in the native code layer, 0x7fde345678, is recorded. A unique data identifier, DEV_IMEI_001, is generated for this sensitive data, and a mapping relationship is established: DEV_IMEI_001 - ("123456012344", 0x7fde345678).
[0039] Step S20: Based on the data identifier, perform behavior monitoring and data flow monitoring on the sensitive data in the native code layer to obtain monitoring events; It should be noted that behavior monitoring refers to monitoring and recording, at the native code level, the specific function operations or processing procedures performed on sensitive data associated with data identifiers. Specific function operations include function calls that calculate or pass the memory address carrying the sensitive data. Data flow monitoring refers to tracing and recording, at the native code level, the flow and propagation path of sensitive data carrying data identifiers within memory addresses.
[0040] Specifically, sensitive data behavior monitoring is achieved by monitoring key execution points related to data processing in the native code layer. Data flow monitoring of sensitive data is achieved by continuously tracking the flow of sensitive data in memory addresses. When sensitive data is detected to be copied, moved, or converted to a new storage format, its initial memory address, target storage location, and transformation method are recorded, thereby generating data flow monitoring that reflects the spatial propagation trajectory of sensitive data.
[0041] Understandably, by monitoring the behavior of sensitive data in the native code layer, it's possible to identify which functions or logic processed the sensitive data. Data flow monitoring, on the other hand, can track the propagation path of sensitive data in memory. This enables real-time monitoring of the sensitive data processing process. Based on the monitoring events obtained after monitoring the behavior and data flow of sensitive data, snapshots of each key node in the entire data lifecycle of sensitive data in the native code layer are provided for the subsequent construction of a privacy data flow graph.
[0042] For example, based on the data identifier DEV_ID_001 created for the user communication device identifier, behavior monitoring is performed based on this data identifier. It is recorded that sensitive data with the data identifier DEV_ID_001 is processed by a data transformation function at time T1. Based on the data identifier, data flow monitoring is performed. It is recorded that sensitive data with the data identifier DEV_ID_001 is copied from memory area A to memory area B at time T2.
[0043] In one feasible implementation, refer to Figure 2 , Figure 2 This is a simplified flowchart of the application privacy data flow monitoring method provided in Embodiment 1 of this application. The monitoring events include behavior monitoring events and data monitoring events. The step of performing behavior monitoring and data flow monitoring on the sensitive data in the native code layer based on the data identifier to obtain the monitoring events includes steps S21-S22: Step S21: Hook the preset key function through the dynamic binary instrumentation mechanism, record the operation result of the function operation on the memory address associated with the data identifier, and obtain the behavior monitoring event; Step S22: By scanning memory and listening to functions that perform memory operations on the sensitive data, the propagation path of the sensitive data carrying the data identifier in memory is traced to obtain the data monitoring event.
[0044] It should be noted that dynamic binary instrumentation is a mechanism that dynamically inserts detection code into the binary instruction flow of the target process during program execution. Preset key functions refer to target functions in the native code layer that operate on sensitive data, such as functions related to memory operations, data computation, encryption, and network communication. Hooking operations involve inserting jump instructions into the execution path of the target function, causing the program execution flow to first jump to the monitoring code and then return to the original function to continue execution. Memory scanning refers to actively traversing the address space of the target process and discovering sensitive data based on preset sensitive data characteristics, including strings and data structures. Passive monitoring involves listening to functions that perform memory operations on sensitive data to passively monitor the calls of underlying functions performing memory copying and moving operations. Data monitoring events are obtained by recording changes in the memory addresses of sensitive data.
[0045] Understandably, dynamic binary instrumentation allows for direct monitoring of the binary code at the native code layer without relying on source code or symbol information. When a pre-defined key function is called and its operand matches the memory address associated with the data identifier, the detection code inserted through dynamic binary instrumentation records the result of this function call, generating a behavior monitoring event. This event includes the function identifier, call time, input parameters, return value, and call stack information. Sensitive data is copied and passed between different functions and buffers during native code layer processing. Simply monitoring the execution of pre-defined key functions cannot fully capture the flow path of sensitive data. Therefore, memory scanning and listening to functions that perform memory operations on sensitive data are used to proactively discover new instances or locations of sensitive data. When the source address of a memory operation function matches the memory address associated with the data identifier, the source and target addresses and operation type of this propagation are recorded, and the internal tracking state is updated, thus forming a complete data monitoring event. This ensures that even if sensitive data is moved multiple times within memory, its propagation path can be continuously and completely recorded. By monitoring the behavior and flow of sensitive data, deep monitoring of sensitive data is achieved within the native code layer. This not only identifies which functions call sensitive data within the native code layer, but also determines how sensitive data moves and propagates within memory. This provides comprehensive and detailed underlying data events for subsequently constructing a complete and accurate privacy data flow graph.
[0046] For example, a custom encryption function named `custom_encrypt` in the native code layer is hooked through a dynamic binary instrumentation mechanism. When this custom encryption function is called, and the memory address of its input parameter matches the memory address associated with the data identifier `DEV_ID_001`, a behavior monitoring event is generated. The function `custom_encrypt` processes sensitive data with the data identifier `DEV_ID_001`. At this point, the data identifier is associated with memory address 0x7faa1000. When the `memcpy` function is called, with its source address at 0x7faa1000 and its destination address at 0x7faa2000, a data monitoring event is generated, recording that the sensitive data with the data identifier `DEV_ID_001` is copied from address 0x7faa1000 to 0x7faa2000. The associated memory address of `DEV_ID_001` is then updated to 0x7faa2000. Meanwhile, by scanning the memory, sensitive data matching the device identifier characteristics was found at a new address 0x7faa3000. A new data identifier was created for the sensitive data, or the sensitive data was associated with an existing identifier, and the corresponding data monitoring event was recorded.
[0047] In one feasible implementation, the step of hooking a preset key function through a dynamic binary instrumentation mechanism, recording the operation results of function operations on the memory address associated with the data identifier, and obtaining the behavior monitoring event includes steps S211~S223: Step S211: Inject the detection code into the application and locate the address of the preset key function in memory; Step S212: Insert the detection code at the preset detection point of the preset key function; Step S213: Record the behavior monitoring events of the preset key function through the detection code, wherein the behavior monitoring events include the call stack, parameters and return values.
[0048] It should be noted that the detection code is a sequence of instructions that implements the monitoring logic. Through debugging and process attachment, the detection code becomes part of the application process and gains execution privileges, thus injecting the detection code into the application. This is achieved by locating the start position or specific offset of the instructions of a preset key function within the application's virtual address space. Locating the memory address of the preset key function can be achieved by parsing the binary file format and matching characteristic instruction sequences. A preset detection point refers to a pre-selected location in the control flow of a preset key function for inserting the monitoring logic. By dynamically modifying the original instructions at the target address, the execution flow is redirected to the detection code. After the detection code completes execution, the original instructions are executed again to insert the detection code into the preset detection point of the preset key function. Preset detection points include the entry and exit points of the preset key function. The call stack refers to the sequence of return addresses stored on the thread stack when the preset key function is called. Parameters refer to the actual input values or memory addresses passed to the currently monitored preset key function. The return value refers to the result returned to the caller after the preset key function completes execution.
[0049] Understandably, in scenarios with unsigned or obfuscated code, binary-level analysis is used to determine the entry points of pre-defined critical functions. This frees monitoring capabilities from the limitations of developer naming conventions or security hardening methods, significantly improving the robustness of the detection scheme. By inserting detection code at pre-defined detection points, control is gained at specific moments during the execution of the pre-defined critical functions. The execution result of the function is monitored without altering its core logic. Detection code is inserted at the entry point to record function parameters and the call stack, and at the exit point to record the function's return value. The recorded call stack allows each function operation to be placed within its specific call context, facilitating understanding of the business logic path triggered by the function operation. The recorded parameters reveal the specific content or address of the sensitive data that can be manipulated. The recorded return value confirms the result status of the function operation or the destination of the output data.
[0050] For example, for a native library stripped of its symbol table, the code segment of the native library is scanned to find signatures that match standard library functions, thereby determining the actual load address of the function in memory. After locating the entry address of the network sending function, a dynamic binary rewrite mechanism replaces the first few instructions at that entry address with a jump instruction, jumping to a detection code. This detection code first saves the current register state to record parameters, then executes the original replaced first few instructions, and finally jumps back to the rest of the network sending function to continue execution. When the hooked encryption function is called, the detection code at its entry point is triggered. The detection code records the call stack, parameters, and return value. Based on the recorded call stack, parameters, and return value, a semantically clear behavior monitoring event is generated. For example, in the 'call stack context', the function 'encryption function' performs encryption operation on sensitive data identified as DEV_IMEI_001, resulting in a 'status code'.
[0051] In one feasible implementation, the step of tracking the propagation path of the sensitive data carrying the data identifier in memory and obtaining the data monitoring event by scanning memory and listening to functions that perform memory operations on the sensitive data includes steps S221~S223: Step S221: Create a watchpoint for the memory address associated with the data identifier; Step S222: Listen for function calls that operate on the sensitive data. If the function call is a memory operation function and the source address of the memory operation function matches any monitoring point address, record the propagation path of the sensitive data and update the address of the monitoring point to obtain the data monitoring event.
[0052] It's important to note that watchpoints are used to mark and track specific memory addresses. By creating watchpoints for memory addresses associated with data identifiers, memory operations performed within those memory addresses can be monitored. Listening for function calls involves monitoring the execution of functions in the native code layer. When a memory operation function is called, its source and destination memory addresses are checked to see if they match the addresses of the created watchpoints.
[0053] Understandably, when sensitive data is processed at the native code layer, it often means that the sensitive data has been copied or moved to a new memory region. Starting with the memory address obtained from monitoring the managed code layer and the native code layer, a tracking marker is established for that memory address. This tracking marker is used to distinguish between ordinary memory operations and operations performed on sensitive data, thus associating changes in the physical location of sensitive data with the data identifier. By listening to function calls that operate on sensitive data, events of sensitive data moving from one memory region to another are captured in real time. When the source address of a captured memory copy operation matches the monitoring point address, it indicates that the tracked sensitive data has propagated. This propagation event is recorded, forming a data flow record, resulting in a data monitoring event. The data monitoring event includes the data identifier, source address, destination address, operation type, and timestamp. Simultaneously, to track subsequent function calls to sensitive data in the new memory region, the associated address of the monitoring point is updated. This ensures the continuity of the sensitive data flow path, accurately recording its propagation path and obtaining data monitoring events even if sensitive data is transferred multiple times in memory.
[0054] For example, a watchpoint is created for the memory address 0x7faa1000 associated with the data identifier DEV_IMEI_001. This watchpoint records information including the monitored address 0x7faa1000, the associated data identifier DEV_IMEI_001, the creation time, and the current status. A list of all watchpoints is also created and maintained. For a function being monitored, when the function is called, the watchpoint list is queried. It is found that the source address of the function is a watchpoint associated with the data identifier DEV_IMEI_001. A data monitoring event 'Sensitive data associated with data identifier DEV_IMEI_001 has been propagated from address 0x7faa1000 to address 0x7faa2346 through a function operation' is generated. The address of this watchpoint is then updated from 0x7faa1000 to 0x7faa2346.
[0055] Step S30: Based on the data identifier, associate the sensitive data, the memory address, and the monitoring event to generate a privacy data flow graph.
[0056] It should be noted that the privacy data flow graph is a structured form of data representation. Using data identifiers as the sole clue, it integrates and connects originally discrete information fragments such as sensitive data, memory addresses, behavioral monitoring events, and data monitoring events according to their inherent relationships.
[0057] Understandably, sensitive data and memory addresses are obtained by monitoring the interaction calls between the managed code layer and the native code layer. Further monitoring of the behavior and data flow of this sensitive data within the native code layer yields monitoring events. These events are isolated; by using data identifiers, they are chained together to construct a data representation describing the complete data path. This provides a highly confident basis for determining whether sensitive data exhibits privacy violations within the native code layer.
[0058] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating a second embodiment of the application privacy data stream monitoring method of this application. The step of associating the sensitive data, the memory address, and the monitoring event based on the data identifier to generate a privacy data stream graph includes steps S31-S32: Step S31: Based on the data identifier, identify the behavior monitoring events and data monitoring events that match the sensitive data from the monitoring events; Step S32: By identifying the matching relationship between the behavior monitoring events and the data monitoring events, the sensitive data, the memory address, and the monitoring events are associated to generate the privacy data flow graph. The types of the matching relationship include time sequence relationship, call stack relationship, and memory address passing relationship.
[0059] It should be noted that the monitoring events are traversed using the data identifier as the query key. For behavior monitoring events, it is checked whether the recorded operation object matches the memory address associated with the data identifier. For data monitoring events, it is checked whether the recorded source address or destination address matches the memory address associated with the data identifier. Monitoring events that pass the check are identified as monitoring events matching sensitive data. The timing relationship is determined by the timestamps of the monitoring events to determine their order of occurrence. The call stack relationship is determined by comparing the call stack information recorded in the behavior monitoring events. The memory address passing relationship is determined by using the mapping between the source address and the destination address recorded in the data monitoring events.
[0060] Understandably, by using data identifiers as indexes, records related to sensitive data can be quickly and accurately filtered from a complex and numerous set of function calls and memory operations. Introducing multi-dimensional matching relationships elevates the data from an event set to an event flow graph. By combining temporal relationships, call stack relationships, and memory address propagation relationships, the generated privacy data flow graph is not merely a timeline, but a complete lifecycle path of sensitive data within the native code layer. This significantly enhances the credibility of the privacy data flow graph and its effectiveness as evidence for compliance assessments.
[0061] For example, for the data identifier DEV_IMEI_001, its associated addresses include addresses 0x7fde34567890 and 0x7faa99887766. Behavior monitoring event A is selected from the event pool: the function `custom_encrypt` operates on address 0x7faa99887766. Data monitoring event B: Sensitive data is copied from 0x7fde34567890 to 0x7faa99887766. Behavior monitoring event C: The function `SSL_write` sends sensitive data from address 0x7faa99887766. These events are all identified as matching DEV_IMEI_001. Association of events A, B, and C reveals that the target address of event B (0x7faa99887766) matches the operation address of event A (0x7faa99887766), and also matches the data source address of event C (0x7faa99887766). This indicates that the data flow followed a path of "copy -> encryption -> send". The order of these three events is confirmed to be: B->A->C. Analyzing the call stacks of events A and C reveals that they share some high-level call paths and originate from the same JNI call context, thus anchoring all events to the same cross-layer data processing operation. A privacy data flow graph for DEV_IMEI_001 is generated, clearly showing: "Sensitive data (IMEI) is passed from the managed code layer to the native code layer -> copied to a new buffer -> encrypted in this buffer -> the encrypted data is sent over the network from the same buffer". This graph uses data identifiers as the main structure and matching relationships as the connection logic, intuitively presenting a complete chain of evidence of violations.
[0062] This embodiment provides a method for monitoring application privacy data flow. It monitors interactive calls from the managed code layer to the native code layer in the application to obtain sensitive data and memory addresses. A data identifier is created for the sensitive data, and the data identifier is associated with the memory address. Based on the data identifier, behavioral and data flow monitoring is performed on the sensitive data in the native code layer to obtain monitoring events. The sensitive data, memory address, and monitoring events are associated based on the data identifier to generate a privacy data flow graph. In other words, this embodiment captures the transmitted sensitive data and its memory address in the native code layer by monitoring interactive calls, and establishes a mapping relationship to associate the data identifier and memory address. The data identifier enables accurate tracking of sensitive data, achieving the capture and association of privacy data sources across runtime environments. Behavioral and data flow monitoring of sensitive data is performed in the native code layer based on the data identifier. A dynamic binary instrumentation mechanism is used to accurately hook and monitor key functions that perform operations on sensitive data, achieving instruction-level deep insight into the processing logic. Simultaneously, combined with active memory scanning and passive listening, the flow, copying, and transformation process of sensitive data carrying data identifiers in memory is tracked in real time. This approach provides a comprehensive view of the "black box" operations within the native layer, revealing not only "how data is processed" but also "how data flows in memory." Based on data identification, it automatically associates and integrates discrete sensitive data entities, memory addresses, and all monitoring events, constructing a complete and visualized privacy data flow graph from the high-level language layer data collection source, through the complex processing chain within the native layer, to the network outgoing nodes. This forms an end-to-end compliance evidence chain, providing a decisive basis for automatically and reliably determining the privacy compliance behavior of applications at the native layer.
[0063] For example, to help understand the implementation flow of the application privacy data stream monitoring method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 4 , Figure 4 This is a schematic diagram of the structure of a monitoring system for application privacy data streams according to an embodiment of this application. Figure 4As shown, the application privacy data flow monitoring system includes a target process space, a native code layer detection engine, and a compliance analysis and report generation center. The target process space includes the managed code layer, the native code layer, and runtime data stored in the native code layer. The native code layer detection engine includes a JNI bridge monitor, a dynamic binary instrumentation controller, and a memory data scanner. The JNI bridge monitor is responsible for monitoring the interaction calls between the managed layer and the native layer. Its specific functions include intercepting JNI calls, establishing cross-layer data mappings (i.e., associating sensitive data with memory addresses in the native code layer), and recording parameters called back from the native layer to the managed layer, thereby capturing the bidirectional flow of cross-layer data. The dynamic binary instrumentation controller is responsible for implementing deep behavioral monitoring within the native code layer. It monitors key functions through function-level hooking and basic block-level tracing. Even if the target function is obfuscated and hardened, and symbolic information is stripped away (i.e., in an unsigned state), it can still be located and instrumented using signature-based methods. The memory data scanner is responsible for tracking the flow of sensitive data in the native layer memory. It employs a combination of passive listening and monitoring of memory operation functions such as memcpy, and active scanning, using memory matching based on sensitive data fingerprints, to discover and track the propagation path of sensitive data in real time. The Compliance Analysis and Report Generation Center is responsible for the final evidence integration and output. It receives and correlates raw events reported by various modules of the detection engine layer, performs automated compliance analysis based on a complete and visualized privacy data flow graph, and generates a detection report containing a complete chain of evidence.
[0064] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the monitoring method of application privacy data flow in this application. Any simple modifications based on this technical concept are within the protection scope of this application.
[0065] This application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the application privacy data stream monitoring method in Embodiment 1 above.
[0066] The following is for reference. Figure 5The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of this application. The electronic devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.
[0067] like Figure 5 As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. While electronic devices with various systems are shown in the figures, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.
[0068] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.
[0069] The electronic device provided in this application, employing the application privacy data stream monitoring method described in the above embodiments, can solve the technical problem that traditional privacy compliance detection schemes cannot detect the native code layer, resulting in monitoring blind spots. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the application privacy data stream monitoring method described in the above embodiments, and other technical features of this electronic device are the same as those disclosed in the previous embodiment method, and will not be repeated here.
[0070] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.
[0071] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
[0072] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the application privacy data stream monitoring method described in the above embodiments.
[0073] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.
[0074] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.
[0075] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by an electronic device, the electronic device: monitors interactive calls between the managed code layer and the native code layer in the application to obtain sensitive data and memory addresses; creates data identifiers for the sensitive data and associates the data identifiers with the memory addresses; performs behavioral monitoring and data flow monitoring of the sensitive data in the native code layer based on the data identifiers to obtain monitoring events; and associates the sensitive data, the memory addresses, and the monitoring events based on the data identifiers to generate a privacy data flow graph.
[0076] Computer program code for performing the operations of this application can be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, and C++, and conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0077] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0078] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.
[0079] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described monitoring method for application privacy data streams. This solves the technical problem that traditional privacy compliance detection schemes cannot detect the native code layer, resulting in monitoring blind spots. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the application privacy data stream monitoring method provided in the above embodiments, and will not be elaborated upon here.
[0080] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the application privacy data stream monitoring method described above.
[0081] The computer program product provided in this application can solve the technical problem that traditional privacy compliance detection schemes cannot detect the native code layer, resulting in monitoring blind spots. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the application privacy data stream monitoring method provided in the above embodiments, and will not be repeated here.
[0082] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.
Claims
1. A method for monitoring application privacy data streams, characterized in that, The method for monitoring application privacy data streams includes: Monitor the interaction calls from the managed code layer to the native code layer in the application to obtain sensitive data and memory addresses, create data identifiers for the sensitive data, and associate the data identifiers with the memory addresses; Based on the data identifier, the sensitive data is monitored for behavior and data flow in the native code layer to obtain monitoring events; Based on the data identifier, the sensitive data, the memory address, and the monitoring event are associated to generate a privacy data flow graph.
2. The method for monitoring application privacy data streams as described in claim 1, characterized in that, The steps of the interactive calls from the managed code layer to the native code layer in the monitoring application include: Hook the data conversion interface function of the managed code layer; When the data conversion interface function is called, the sensitive data and the memory address are obtained.
3. The method for monitoring application privacy data streams as described in claim 1, characterized in that, The step of associating the data identifier with the memory address includes: Construct a mapping relationship between the sensitive data and the memory address; The data identifier and the memory address are associated through the mapping relationship.
4. The method for monitoring application privacy data streams as described in claim 1, characterized in that, The monitoring events include behavioral monitoring events and data monitoring events. The steps of performing behavioral monitoring and data flow monitoring of the sensitive data in the native code layer based on the data identifier to obtain monitoring events include: By hooking preset key functions through a dynamic binary instrumentation mechanism, the operation results of function operations performed on the memory address associated with the data identifier are recorded to obtain the behavior monitoring event; By scanning memory and listening to functions that perform memory operations on the sensitive data, the propagation path of the sensitive data carrying the data identifier in memory is traced to obtain the data monitoring event.
5. The method for monitoring application privacy data streams as described in claim 4, characterized in that, The steps of hooking preset key functions through a dynamic binary instrumentation mechanism, recording the operation results of function operations on the memory address associated with the data identifier, and obtaining the behavior monitoring event include: The detection code is injected into the application, and the memory address of the preset key function is located; Insert the detection code at the preset detection point of the preset key function; The detection code records the behavior monitoring events of the preset key functions, wherein the behavior monitoring events include the call stack, parameters, and return values.
6. The method for monitoring application privacy data streams as described in claim 4, characterized in that, The steps of tracking the propagation path of sensitive data carrying the data identifier in memory and obtaining the data monitoring event by scanning memory and listening to functions that perform memory operations on the sensitive data include: Create a watchpoint for the memory address associated with the data identifier; Listen for function calls that operate on the sensitive data. If the function call is a memory operation function and the source address of the memory operation function matches the address of any monitoring point, record the propagation path of the sensitive data and update the address of the monitoring point to obtain the data monitoring event.
7. The method for monitoring application privacy data streams as described in claim 1, characterized in that, The step of associating the sensitive data, the memory address, and the monitoring event based on the data identifier to generate a privacy data flow graph includes: Based on the data identifier, identify the behavioral monitoring events and data monitoring events that match the sensitive data from the monitoring events; By identifying the matching relationships between behavioral monitoring events and data monitoring events, the sensitive data, the memory address, and the monitoring events are associated to generate the privacy data flow graph. The types of matching relationships include time sequence relationships, call stack relationships, and memory address passing relationships.
8. An electronic device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the method for monitoring application privacy data streams as claimed in any one of claims 1 to 7.
9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the monitoring method for application privacy data streams as described in any one of claims 1 to 7.
10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the monitoring method for application privacy data streams as described in any one of claims 1 to 7.