An Android hotspot traffic detection method and system based on end-side cooperation and traffic marking

Abstract

This invention discloses a method and system for dynamic mapping and attribution of backend devices in Android hotspots, belonging to the field of mobile communication and network traffic identification technology. The method includes: establishing a TUN virtual network channel based on VPNService on an Android mobile terminal with hotspot sharing enabled; and using hotspot traffic provided by the system via a VPN forwarding switch to forward target hotspot traffic generated by backend devices accessing the hotspot and forwarded by the Android mobile terminal to the TUN virtual network interface created by VPNService, thereby entering the user-mode processing path. This invention highlights the continuous processing link of forwarding backend device traffic from Android hotspots to the VPNService TUN interface, reverse recovery of TUN addresses, connection tracking read assurance, and dynamic mapping with dual buffers for connection tracking, making it suitable for backend device traffic attribution recovery in Android hotspot scenarios.

Description

Technical Field

[0001] This invention relates to the field of mobile communication and network traffic identification technology, and in particular to a method and system for dynamic mapping and attribution of backend devices for Android hotspot sharing scenarios. Background Technology

[0002] After enabling hotspot sharing on a mobile terminal, backend devices typically access the cellular network through the frontend Android mobile terminal. Before reaching the network side, the traffic generated by the backend devices usually undergoes network address translation, session forwarding, and address rewriting processing via the frontend Android mobile terminal. After these processes, data packets from different backend devices often exhibit the same or similar external address characteristics on the network side. The network side typically only sees the access information corresponding to the frontend Android mobile terminal and finds it difficult to directly reconstruct the correspondence between each forwarded data packet and the actual backend device.

[0003] Existing solutions for handling hotspot-shared traffic mostly start from the network side, indirectly judging sharing behavior by utilizing hotspot on / off status, abnormal traffic characteristics, single packet characteristics, or statistical features. While these solutions can detect hotspot-shared phenomena to some extent, their focus is usually on identifying sharing behavior, sharing terminals, or sharing traffic control, rather than directly restoring the definitive correspondence between backend devices and specific forwarded data packets at the endpoint. Therefore, these solutions are unlikely to provide directly usable backend device attribution results to subsequent network processing.

[0004] On the other hand, there is also the idea of ​​reading some underlying state information from the terminal side to assist in analyzing hotspot traffic. However, in the actual Android operating environment, simply reading the underlying connection state cannot naturally form a stable and usable attribution recovery capability. On the one hand, after hotspot forwarding traffic enters the user-space processing path, it often manifests as packets related to the TUN virtual address. If there is no reverse recovery mechanism for the relationship between the TUN virtual address, port information, and connection tracking records, it is difficult to re-associate with the real backend device. On the other hand, if the terminal side only uses the results of a single state read momentarily, without organizing the relationship between connection characteristics and backend devices into a continuously updated dynamic mapping structure, the existing state information cannot be continuously applied to the attribution recovery process of subsequent data packets.

[0005] Furthermore, Android systems typically face limitations in accessing underlying network status due to permission constraints, interface constraints, and differences in implementation paths. For obtaining connection tracking information, relying on high-privilege interfaces or complex system-level access methods is often difficult to deploy directly in real-world Android hotspot environments. Especially in Android systems with SELinux enforced access control, even if the application process is running in an environment with high-level system access permissions, it may still be unable to reliably read connection tracking files due to security policies not granting access permissions to the corresponding file nodes. Even if the underlying status can be obtained, without combining it with feasible read paths, access control safeguards, mapping refresh mechanisms, miss-filling mechanisms, and failure cleanup mechanisms specific to Android hotspot scenarios, it is difficult to form a long-term, stable backend device ownership recovery solution.

[0006] Furthermore, in situations with high shared traffic and numerous concurrent connections, real-time access to the underlying state information for attribution determination of each data packet would result in significant processing latency and resource overhead. If the client-side were further required to write the attribution identifier of each data packet with restored attribution to the backend device, additional marking and forwarding burdens could arise in high-traffic scenarios. Therefore, developing a technical solution for Android hotspot scenarios that can stably restore backend device attribution while adapting to practical implementation constraints and high-traffic processing requirements remains a pressing issue in current technology. Summary of the Invention

[0007] In view of this, embodiments of the present invention provide an Android hotspot backend device dynamic mapping attribution method and system to solve the problems in the prior art where hotspot forwarding traffic is difficult to enter a unified user-space processing path, data packets after entering the TUN path are difficult to reverse recover the real backend device address, Android security enhancement mechanisms restrict stable reading of connection tracking status, existing underlying state information is difficult to continuously apply to the subsequent attribution process, and processing overhead is high in high-traffic scenarios.

[0008] In a first aspect, embodiments of the present invention provide a method for dynamic mapping and attribution of backend devices in an Android hotspot, comprising the following steps: On an Android mobile terminal with hotspot sharing enabled, a TUN virtual network channel is established based on the VpnService interface provided by the Android system, and a hotspot sharing interface, routing rules, or forwarding rules are configured so that target hotspot traffic generated by backend devices accessing the hotspot and forwarded by the Android mobile terminal is forwarded to the TUN virtual network interface created by the VpnService, so as to import the corresponding data packets into the user-space processing path; the data packets received through the TUN virtual network interface are parsed to read connection feature information including at least protocol type, source address, destination address, source port, and destination port; the backend device information and connection tracking information accessing the hotspot subnet of the Android mobile terminal are read, and when the security enhancement mechanism of the Android system restricts the reading of the connection tracking file, a security policy rule file for allowing preset state reading components to access the connection tracking file is loaded or configured; the bidirectional address port, connection status, etc. in the connection tracking information are parsed. The system uses connection state and timestamps, and establishes a dynamic mapping relationship supported by the connection state cache and fast retrieval cache based on the backend device information, connection tracking information, and connection feature information. The dynamic mapping relationship includes a mapping matching confidence value. Based on the dynamic mapping relationship, the system performs backend device attribution recovery on the data packets. When the source address or destination address of the data packet is the TUN address corresponding to the TUN virtual network interface, the system reversely recovers the corresponding backend device address based on port information, protocol type, and the bidirectional address-port correspondence in the connection tracking information. The system prioritizes searching for the corresponding backend device in the fast retrieval cache based on the connection feature information. When the search is successful and the mapping matching confidence value reaches a preset output threshold, the system determines the backend device corresponding to the data packet. After the attribution recovery is completed, the system writes the backend device attribution identifier determined by the dynamic mapping relationship onto the data packet. The system uses the user-space network protocol stack to reassemble and forward the data packet after writing the backend device attribution identifier. The network-side device parses the backend device attribution identifier and recovers the backend device attribution relationship of the corresponding connection traffic, session traffic, or time window traffic based on the backend device attribution identifier.

[0009] In some embodiments, the TUN traffic import step is used to provide a clear packet input path for dynamic mapping recovery. The Android mobile terminal can establish a TUN virtual network interface based on the system-provided VPNService interface, and by configuring the hotspot sharing interface, address information, routing information, and target forwarding rules, the target forwarding traffic generated by the backend device in the hotspot sharing scenario is forwarded to the TUN virtual network interface, thereby entering a unified user-space processing path. In this way, the terminal can obtain the packet-by-packet connection characteristics required for subsequent dynamic mapping recovery without changing the core network processing logic.

[0010] In some embodiments, the method for directing target hotspot traffic to the TUN virtual network interface can be determined based on the Android system version and device implementation conditions. For Android versions that already provide a VPN forwarding switch for hotspot traffic, the switch can be enabled, allowing target forwarding traffic on the hotspot sharing interface to enter the TUN virtual network interface corresponding to the VPNService according to the system network stack configuration. For Android devices that do not provide the switch or whose default configuration cannot meet the requirements for importing target traffic, policy routing, forwarding rules, address translation rules, or equivalent system network rules can be configured through an auxiliary configuration program with advanced system access permissions, so that target forwarding traffic on the hotspot sharing interface is imported into the TUN virtual network interface. The auxiliary configuration program is used to complete the system network rule configuration and does not independently perform backend device attribution restoration.

[0011] In some embodiments, the step of obtaining backend device information includes: reading NAT forwarding table information or connection tracking information when system permissions permit, to obtain backend device addresses, port mapping relationships, and connection status information, and constructing a backend device list accordingly; when the NAT forwarding table information or connection tracking information is inaccessible, incomplete, or cannot form a valid match, using an active probing method to complete the backend device list. The active probing method may include at least one of ARP scanning, ICMP probing, and TCP / UDP port probing. Therefore, active probing in this invention serves as a completion path when the underlying state is unavailable, rather than an independent main solution parallel to reading the underlying state.

[0012] In some embodiments, an Android terminal can obtain connection tracking information from at least one connection tracking status source. These sources may include the ` / proc / net / nf_conntrack` file, the ` / proc / net / ip_conntrack` file, connection tracking command output, the Netlink connection tracking interface, and equivalent connection tracking status interfaces provided by the vendor. Compared to limiting connection tracking reading to a single file path, this multi-source compatibility approach can adapt to different Android versions, kernel configurations, and vendor implementation differences. By combining the connection tracking information with connection characteristic information from data packets received via the TUN virtual network interface, a feasible status input source for Android hotspot scenarios can be formed.

[0013] In some embodiments, when the Android system's security enhancement mechanism restricts application processes from accessing connection tracking files, a security policy rule file can be loaded, written, or configured to allow a preset state reading component to access the connection tracking file. The security enhancement mechanism may include SELinux mandatory access control. The preset state reading component can be an application process, a local daemon, a command-line state reader, or a local library component called by the application process. Through the security policy rule file, the preset state reading component can be granted permission to read ` / proc / net / nf_conntrack` or an equivalent connection tracking state file to meet the connection state input conditions required for establishing and refreshing dynamic mapping relationships. The security policy configuration is not an independent backend device identification mechanism, but rather an implementation method to ensure that the connection tracking reading protection module can stably obtain connection state input.

[0014] In some embodiments, when reading the connection tracking information, at least a portion of the following information can be further parsed: protocol type, connection state, first-direction source address, first-direction destination address, first-direction source port, first-direction destination port, second-direction source address, second-direction destination address, second-direction source port, and second-direction destination port. By comparing the protocol type and port information of the current data packet with the bidirectional address-port combination in the connection tracking information, the correspondence between the backend device address and the TUN address can be restored, thereby improving the consistency recovery capability of hotspot forwarding traffic before and after address translation.

[0015] In some embodiments, the dynamic mapping relationship includes at least connection characteristic information, backend device address, backend device ownership identifier, mapping establishment time, mapping update time, mapping lifetime, and mapping matching confidence value. The terminal side can be configured to periodically read the latest NAT forwarding table information or connection tracking information and update the dynamic mapping relationship; simultaneously, outdated mapping entries are cleaned up according to a preset lifetime, connection state changes, or time window. In this way, the dynamic mapping relationship not only carries the ownership recovery result at a certain moment but can also continue to play a role in ownership recovery when subsequent data packets arrive.

[0016] In some embodiments, the mapping matching confidence value is used to represent the degree of matching of the current dynamic mapping item as the basis for backend device attribution recovery. The mapping matching confidence value can be determined based on at least one of the following parameters: integrity of connection tracking fields, time difference between connection status timestamp and current data packet arrival time, number of consecutive hits of the same connection feature within a preset time window, connection tracking status source type, backend device information source, and consistency of TUN address reverse recovery results. For example, the mapping matching confidence value can be increased when the bidirectional address port field in the connection tracking record is complete, the status timestamp is close to the current data packet arrival time, the same connection feature consecutively hits the same backend device, and the TUN address reverse recovery result is consistent with the backend device list; the mapping matching confidence value can be decreased when the backend device information is only completed by active probes, the connection status field is incomplete, the time difference exceeds a preset threshold, the reliability of the connection tracking status source is low, or the TUN address reverse recovery result is inconsistent.

[0017] In one specific implementation, the mapping matching confidence value can be set as a discrete level or a normalized value. The discrete level method can include three levels: high, medium, and low. A high level indicates complete and consecutive hits; a medium level indicates basically complete fields but a time difference close to a threshold; and a low level indicates missing fields, sources of supplementary information, or conflicts. The normalized value method can accumulate field completeness scores, time validity scores, consecutive hit scores, source reliability scores, and reverse recovery consistency scores according to preset weights, and limit the accumulated result to a preset value range. When the mapping matching confidence value reaches a preset output threshold, the backend device attribution identifier is output; when it does not reach the preset output threshold, the corresponding connection feature is added to the pending confirmation queue, and the mapping matching confidence value is recalculated after subsequent connection tracking updates, connection status cache hits, or consecutive data packet matches.

[0018] In some embodiments, the dynamic mapping relationship is supported by a connection state cache and a fast retrieval cache. The connection state cache stores timestamped connection tracking history information to support backtracking and retrieving connection states within a preset time window; the fast retrieval cache directly retrieves the backend device address or backend device ownership identifier based on connection feature information, thereby reducing the processing overhead of repeatedly accessing underlying state information in high-traffic scenarios. In other words, the dynamic mapping relationship is not a simple instantaneous query result, but is maintained by connection state information in the time dimension and a fast index structure oriented towards packet-by-packet processing.

[0019] In some embodiments, when performing backend device attribution recovery on a data packet, the corresponding backend device is first searched in the dynamic mapping relationship based on the connection feature information. When the search is successful and the mapping matching confidence value reaches a preset output threshold, the current data packet is restored to the corresponding backend device, and the corresponding backend device attribution identifier is output. When the search fails, the matching is re-executed based on the latest obtained NAT forwarding table information, connection tracking information, or the completed backend device list, and the dynamic mapping relationship is backfilled after a successful match. Thus, the dynamic mapping relationship constitutes both the core bearer structure of attribution recovery and the continuous mechanism for attribution recovery.

[0020] In some embodiments, when the current data packet does not match the fast retrieval cache, the most recently saved connection state cache within a preset time window can be retrieved first. If no matching result is found, the latest connection tracking information is refreshed, and matching is re-executed based on the refresh result. For data packets that still cannot recover their attribution after refreshing, or data packets that form a mapping item but whose mapping matching confidence value does not reach the preset output threshold, the corresponding connection features can be added to the pending confirmation queue, statistics queue, or subsequent completion process. The mapping matching confidence value is updated after subsequent connection tracking information refresh, connection state cache hit, or consecutive data packet matching success. This processing method can avoid low-match mapping results directly affecting the backend device attribution recovery result.

[0021] In some embodiments, when the source or destination address of a data packet is the address corresponding to a TUN virtual network interface, the real backend device address can be recovered based on the port information, protocol type, and corresponding mapping relationship in the connection tracking information of the data packet. This method enables the re-association of TUN-related data packets entering the user-space processing path with the real backend device, thereby solving the problem of difficulty in recovering the real backend device address in TUN virtual address scenarios.

[0022] In some embodiments, after the backend device attribution is restored, the backend device attribution identifier determined by the dynamic mapping relationship is written into the IP header field, extension field, or tunnel encapsulation metadata. This backend device attribution identifier writing is used to output the backend device attribution restoration result completed on the terminal side to the network side, so that the network side can perform subsequent processing on connection traffic, session traffic, or time window traffic based on this result. In this invention, backend device attribution identifier writing is a method of outputting the dynamic mapping restoration result, rather than an identification mechanism independent of attribution restoration.

[0023] In some embodiments, when the hotspot forwarding traffic rate is high, the number of data packets to be processed is large, or the end-side processing load reaches a preset condition, it is not required to write the backend device ownership identifier to each and every data packet that has completed backend device ownership recovery. Instead, according to a preset probability rule or a preset selection rule, only a portion of the data packets are written with the backend device ownership identifier. The preset selection rule may include: prioritizing writing the backend device ownership identifier to the first or several packets of the same connection; extracting data packets according to a preset time window and then writing the backend device ownership identifier; or sampling and writing the backend device ownership identifier to data packets that have completed backend device ownership recovery according to a preset ratio. In this way, the end-side overhead caused by full packet-by-packet marking can be reduced while maintaining connection-level, session-level, or time-window-level ownership recovery capabilities.

[0024] In some embodiments, the network-side device accumulates the received data packets with backend device attribution identifiers written on them according to connection information, session information, or time window information. When the accumulated data packets are sufficient to characterize the source of the corresponding backend device, the network-side device attribution relationship of the corresponding connection traffic, session traffic, or time window traffic is restored. The role of the network-side device in this invention is mainly to utilize the attribution restoration result output by the end side, rather than to independently re-determine the attribution of the backend devices.

[0025] In some embodiments, the user-space network protocol stack is used to perform session management, packet reassembly, and forwarding control on at least one of TCP and UDP packets in user space, thereby ensuring that the dynamic mapping recovery result is stably output in a unified user-space processing link. Thus, TUN traffic import, connection tracking read guarantee, TUN address reverse recovery, dynamic mapping recovery, backend device home identifier writing, and subsequent forwarding can form a complete and continuous terminal-side processing closed loop.

[0026] In some embodiments, the method of this invention further includes: collecting and de-identifying data packets that have completed attribution recovery or have had their attribution identifiers written into them, according to the backend device attribution recovery results and at least one strategy among IP address, session identifier, application protocol, and time window, to generate an offline dataset for verifying dynamic mapping recovery results or constructing hotspot traffic identification and analysis samples. Further, the collection and de-identification storage may include at least one of the following methods: saving different data files according to the backend device attribution results, saving the collected data locally, uploading the collected data to a server via a network, and having the server perform timestamp calibration on the received data to form an offline dataset. The timestamp calibration can be used to improve the consistency of data analysis across devices and processing links.

[0027] In some embodiments, the data collection and desensitization storage process includes: first, writing the traffic samples to be saved corresponding to the backend device attribution recovery results into a buffer; then, writing the data in the buffer into a PCAP file in segments according to at least one of the following conditions: a preset time window, a file size threshold, or a backend device dimension. The PCAP file can be named according to the start connection time, the start time of the time window, or the backend device address, and stored according to the classification of frontend device traffic and traffic from different backend devices. By adopting a buffer plus segmented disk writing method, the I / O overhead caused by high-frequency disk writing can be reduced, and the continuity of the sample construction process can be improved.

[0028] In a second aspect, embodiments of the present invention also provide an Android hotspot backend device dynamic mapping attribution system, including a TUN traffic import module, a connection feature parsing module, a connection tracking and reading guarantee module, a dual-buffer dynamic mapping module, a TUN address reverse recovery and marking module, a user-space protocol stack forwarding module, and a network-side cumulative utilization module. The TUN traffic import module forwards target hotspot traffic on the hotspot sharing interface to the TUN virtual network interface created by the VPNService; the connection feature parsing module extracts connection feature information of data packets received via the TUN virtual network interface; the connection tracking read guarantee module obtains backend device information and connection tracking information, and configures security policy rule files when SELinux access is restricted; the dual-buffer dynamic mapping module parses the bidirectional address port, connection status, and timestamp in the connection tracking information, and maintains dynamic mapping relationships and mapping matching confidence values ​​based on connection status caching and fast retrieval caching; the TUN address reverse recovery and marking module reversely recovers the real backend device address based on the TUN address, port information, protocol type, and connection tracking records, and outputs the attribution recovery result in the form of a backend device attribution identifier; the user-space protocol stack forwarding module ensures that labeled data packets are forwarded along a unified user-space path; and the network-side cumulative utilization module uses the backend device attribution identifier to recover connection-level, session-level, or time-window-level traffic attribution.

[0029] Compared with the prior art, the embodiments of the present invention have at least the following beneficial effects:

[0030] First, this invention can restore the correspondence between forwarded traffic and actual backend devices in Android hotspot sharing scenarios, enabling the network or management side to not only see the mixed traffic uniformly forwarded by the front-end Android mobile terminals, but also to further distinguish the service traffic generated by different backend devices. This provides a clearer basis for attribution in device-level traffic statistics, device-level policy execution, abnormal device location, and subsequent network processing.

[0031] Secondly, this invention can utilize the VPNService and TUN virtual network channels provided by the Android system to form a unified user-space input path for target hotspot traffic, enabling the continuous reception, parsing, and processing of traffic from backend devices in the hotspot. This approach facilitates the integration of the backend device ownership recovery process into a unified processing chain without altering the basic hotspot sharing functionality, thereby improving the feasibility of the solution in real Android device environments.

[0032] Third, this invention improves the availability and stability of connection state information by leveraging connection tracking read guarantees and security policy rule file configuration, even under conditions of permission constraints, interface differences, and SELinux security enhancement mechanisms in the Android system. Therefore, it can still provide a relatively stable source of state for backend device attribution recovery across different Android versions, kernel configurations, or vendor implementations.

[0033] Fourth, this invention can re-associate data packets entering the TUN path with the real backend device, avoiding the loss of backend device origin due to TUN virtual addresses, address translation, or port mapping. Therefore, after hotspot forwarding traffic enters the user-space processing path, the correspondence with the real backend device can still be maintained, improving the accuracy of hotspot shared traffic attribution recovery.

[0034] Fifth, this invention can continuously maintain the dynamic mapping relationship between connection features and backend devices through connection state caching and fast retrieval caching, enabling the backend device attribution results to be updated as the connection state changes, rather than relying on a single query or manual analysis. Therefore, in scenarios with multiple device access, frequent connection changes, and continuous hotspot sharing from business sessions, it can improve the continuity and stability of attribution recovery.

[0035] Sixth, this invention can perform reliability control on the attribution recovery results by mapping and matching confidence values ​​and pending confirmation queues, avoiding the direct output of unstable results when connection status is missing, mapping information is expired, TUN address reverse recovery results are inconsistent, or matching basis is insufficient. This mechanism helps reduce misattribution and improves the reliability of device-level traffic management, network auditing, and policy control results.

[0036] Seventh, this invention can reduce the number of times the underlying connection state is accessed per packet by fast retrieval cache in high-traffic, high-concurrency connection scenarios, and reduce the mutual influence between state refresh and per-packet query through a lightweight dual-caching structure. Therefore, it can reduce end-side processing latency and resource overhead, and improve the operating efficiency of the solution when hot traffic is high.

[0037] Eighth, this invention combines a selective marking mechanism with a network-side cumulative utilization mechanism, enabling the network side to recover the backend device attribution relationship of corresponding traffic based on five-tuples, sessions, time windows, user accounts, or base station-side connections without writing backend device attribution identifiers to every single data packet. This reduces the end-side marking and forwarding burden while maintaining the network side's ability to utilize the attribution results.

[0038] Ninth, this invention can provide network-side devices, auxiliary devices, or management platforms with directly usable backend device attribution identifiers, enabling subsequent processing to be further refined from the overall Android mobile terminal to specific backend devices. Therefore, this invention can support application scenarios such as hotspot sharing traffic metering, abnormal terminal identification, access control, quality of service management, differentiated policy enforcement, and network operation and maintenance troubleshooting.

[0039] Tenth, this invention can combine local storage, remote uploading, server-side timestamp calibration, and PCAP segmented storage to transform online attribution recovery results into verifiable, analyzable, and trainable offline sample data. Therefore, this invention can not only serve online network processing but also be used for offline analysis, sample dataset construction, model training, state verification, and hotspot sharing behavior research, thus expanding the invention's application value. Attached Figure Description

[0040] Figure 1 This is a schematic diagram of the overall process of dynamic mapping and attribution of Android hotspot backend devices based on VpnService TUN traffic import and connection tracking dual buffering according to the present invention.

[0041] Figure 2 This is a block diagram of the module composition of the hotspot backend device dynamic mapping attribution system of the present invention.

[0042] Figure 3 This is a flowchart illustrating the dynamic mapping and attribution process of the present invention based on connection tracking dual buffering and TUN address reverse recovery.

[0043] Figure 4 This is a collaborative swimlane diagram between the Android mobile terminal, backend device, user-mode link, connection tracking state, and network-side device of this invention.

[0044] Figure 5 This is a flowchart of the sample collection and PCAP segmented storage process based on the backend device attribution results of this invention.

[0045] in, Figure 1 In this context, 101 indicates establishing a TUN virtual network channel and forwarding target hotspot traffic to the TUN virtual network interface; 102 indicates parsing IP packets and extracting five-tuple connection features; 103 indicates reading backend device information and connection tracking status under the protection of security policy rules; 104 indicates establishing and refreshing the dynamic mapping relationship between connection features and backend devices based on connection state cache and fast retrieval cache; 105 indicates recovering the backend device affiliation of data packets based on TUN address reverse recovery results, dynamic mapping relationship, and mapping matching confidence value, and writing the backend device affiliation identifier; and 106 indicates user-space forwarding and the network side accumulating and utilizing the backend device affiliation identifier.

[0046] Figure 2 In the diagram, 201 represents the TUN traffic import module, 202 represents the connection feature parsing module, 203 represents the connection tracking and reading guarantee module, 204 represents the dual-buffer dynamic mapping module, 205 represents the TUN address reverse recovery and marking module, 206 represents the user-space protocol stack forwarding module, 207 represents the network-side cumulative utilization module, and 208 represents the acquisition and processing module.

[0047] Figure 3 In the code, 301 indicates reading connection tracking records from / proc / net / nf_conntrack under the protection of SELinux security policy rules; 302 indicates parsing the protocol, bidirectional address port, connection state, and timestamp; 303 indicates forming a connection state cache and retaining it for a preset time window; 304 indicates performing reverse recovery of the backend device address and querying the cache quickly when the current packet involves a TUN address, combining port information and protocol type; 305 indicates determining whether a backend device is matched and the mapping match confidence value reaches a preset output threshold; 306 indicates outputting the backend device address or backend device ownership identifier when the preset output threshold is reached; 307 indicates backtracking the connection state cache and triggering the latest state refresh when there is no match; and 308 indicates backfilling the dynamic mapping relationship and mapping match confidence value after a successful match, and entering the pending confirmation queue if it still fails.

[0048] Figure 4 In the diagram, 401 indicates that the backend device generates a hotspot service IP packet; 402 indicates that the Android terminal receives and forwards the packet via the hotspot interface; 403 indicates that the target hotspot traffic is forwarded to the TUN virtual network interface; 404 indicates the connection characteristics of the user-space link resolution packet; 405 indicates reading and refreshing the connection tracking status; 406 indicates restoring the backend device affiliation based on the TUN address reverse recovery and mapping matching confidence value; 407 indicates writing the backend device affiliation identifier to the selected packet and forwarding it; and 408 indicates that the network side uses the backend device affiliation identifier cumulatively by connection, session, or time window.

[0049] Figure 5 In the code, 501 indicates receiving a data packet whose ownership has been restored or whose backend device ownership identifier has been written; 502 indicates determining the sample classification based on the backend device, connection information, or time window; 503 indicates writing the traffic sample to be saved to the memory buffer; 504 indicates determining whether the time window, file size threshold, or backend device dimension meets the disk writing conditions; 505 indicates generating a PCAP file; and 506 indicates local saving, remote uploading, and server timestamp calibration. Detailed Implementation

[0050] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the following embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present invention. Where there is no conflict, the technical features of the various embodiments of the present invention can be combined with each other.

[0051] like Figure 1 As shown, the core idea of ​​this invention is not simply to indirectly identify hotspot sharing behavior, but rather, in the Android hotspot scenario, first, step 101 is executed to forward the target hotspot traffic to the TUN virtual network interface created by the VPNService. Then, step 102 is executed to obtain connection feature information that can be parsed packet by packet. Next, steps 103 and 104 are executed to establish a connection state cache and a fast retrieval cache based on connection tracking read assurance. Then, step 105 is executed to perform backend device attribution recovery on the data packets to be processed, combining the TUN address reverse recovery result, dynamic mapping relationship, and mapping matching confidence value, and write the backend device attribution identifier. Finally, step 106 is executed to forward the data packets via the user-space link, and the network side performs cumulative utilization on the backend device attribution identifier. Thus, dynamic mapping attribution based on connection tracking dual cache becomes the core mechanism for end-side backend device attribution recovery. TUN traffic import, connection tracking read assurance, TUN address reverse recovery, backend device attribution identifier writing, and network-side cumulative utilization respectively constitute the input assurance, state assurance, recovery assurance, output assurance, and result utilization stages of this core mechanism.

[0052] like Figure 2As shown, in one embodiment, the mobile terminal-side system may include a TUN traffic import module 201, a connection feature parsing module 202, a connection tracking and reading guarantee module 203, a dual-buffer dynamic mapping module 204, a TUN address reverse recovery and marking module 205, a user-space protocol stack forwarding module 206, a network-side cumulative utilization module 207, and a collection and processing module 208. The TUN traffic import module 201 forwards target hotspot traffic on the hotspot sharing interface to the TUN virtual network interface and into user space; the connection feature parsing module 202 extracts connection feature information such as source address, destination address, protocol type, source port, and destination port; the connection tracking read guarantee module 203 obtains backend device information and underlying connection status information in the hotspot subnet, and guarantees connection tracking status reading through security policy rule files when SELinux access is restricted; the dual-buffer dynamic mapping module 204 establishes, maintains, and refreshes the dynamic mapping relationship and mapping matching confidence value between connection feature information and backend devices; the TUN address reverse recovery and marking module 205 recovers the real backend device address based on the TUN address, port information, protocol type, and connection tracking record, and writes the backend device ownership identifier to the data packet when needed; the user space protocol stack forwarding module 206 performs session management, reassembly, and forwarding of the marked data packet; the network side cumulative utilization module 207 accumulates the utilization of the backend device ownership identifier; and the collection and processing module 208 performs local storage, remote upload, or subsequent dataset construction on the data packet based on the ownership result.

[0053] In one implementation, the dual-buffered dynamic mapping module 204 and the TUN address reverse recovery and marking module 205 can execute a dynamic home recovery algorithm based on connection tracking dual-buffering and confidence control. The algorithm takes as input the connection characteristics of data packets received via the TUN virtual network interface, a list of backend devices, connection tracking records, TUN address information, and a preset output threshold, and outputs the backend device address, the backend device home identifier, and the mapping matching confidence value. The algorithm includes the following steps.

[0054] First, initialize the activity cache, build cache, fast retrieval cache, and pending confirmation queue, and set the connection status time window, mapping lifetime, confidence output threshold, and selective labeling parameters. The activity cache is used for querying the current data packet, the build cache is used to receive the latest connection tracking status, the fast retrieval cache is used to directly obtain the backend device attribution result based on connection characteristics, and the pending confirmation queue is used to store connection characteristics that have not yet met the output conditions.

[0055] Second, the connection tracking status source is read periodically or based on trigger conditions, and the reading results are parsed into status candidates. Each status candidate includes at least the protocol type, bidirectional address port, connection status, status timestamp, and status source type. For status candidates involving TUN addresses, a reverse recovery key is generated based on the protocol type, port information, and bidirectional address port relationship; for status candidates that can directly correspond to the backend device address of a hotspot subnet, a five-tuple search key and backend device candidate attribution results are generated.

[0056] Third, candidate mapping items are generated in the construction cache based on the state candidates, and the mapping matching confidence value of each candidate mapping item is calculated. The mapping matching confidence value can be determined based on field completeness, connection state time validity, state source reliability, number of consecutive hits of the same connection feature, consistency of TUN address reverse recovery results, and backend device list matching results; when there are missing fields, expired states, low source reliability, or conflicting reverse recovery results, the mapping matching confidence value is reduced.

[0057] Fourth, after the candidate mapping items are generated in the cache construction process, the cache construction is switched to the new active cache through version number switching, reference switching, or equivalent atomic switching, and the candidate mapping items that meet the preset conditions are synchronized to the fast retrieval cache. Thus, the connection tracking state refresh process and the packet-by-packet query process are isolated from each other, avoiding the impact on packet-by-packet attribution recovery efficiency due to frequent updates to the connection state under high concurrency traffic.

[0058] Fifth, for current data packets arriving via the TUN virtual network interface, extract their connection characteristic information and determine whether the source or destination address corresponds to the TUN virtual network interface address. When a TUN address exists, prioritize searching for the real backend device address in the active cache based on the protocol type, port information, and reverse recovery key; when no TUN address exists or reverse recovery has been completed, search for the corresponding backend device attribution result in the fast retrieval cache based on the five-tuple retrieval key.

[0059] Sixth, when the fast retrieval cache is hit and the mapping matching confidence value reaches the preset output threshold, the corresponding backend device address or backend device ownership identifier is output; when the fast retrieval cache is not hit or the mapping matching confidence value does not reach the preset output threshold, the preset time window state in the active cache is traced back, and a connection tracking status refresh is triggered if necessary, and the mapping matching confidence value is recalculated. If the rematch is successful, the dynamic mapping relationship and fast retrieval cache are populated back; if the output conditions are still not met, the corresponding connection feature is added to the pending confirmation queue.

[0060] Seventh, when it is necessary to write the backend device ownership identifier, the decision on whether to mark the current data packet is made based on the current traffic rate, end-side processing load, the number of times the same connection has been marked, and preset selection rules. The preset selection rules may include connection first packet marking, marking of the first few packets, time window sampling marking, or proportional sampling marking. Data packets not selected for writing the identifier can still complete end-side ownership recovery based on dynamic mapping relationships, but it is not necessary to carry the backend device ownership identifier in every packet.

[0061] Eighth, the network-side cumulative utilization module 207 accumulates marked data packets according to the dimensions of five-tuple, session, time window, user account, or base station-side connection. When the cumulative result meets the preset judgment conditions, the backend device attribution of the corresponding connection traffic, session traffic, or time window traffic is restored. Through the above algorithm, the end-side reduces the processing overhead caused by accessing the underlying state and writing the identifier packet by packet while maintaining the accuracy of attribution restoration.

[0062] Furthermore, in one implementation, the current data packet can be represented as a connection feature vector. ,in Indicates the protocol type. and These represent the source address and the destination address, respectively. and These represent the source port and the destination port, respectively. Indicates direction information. Indicates the packet arrival time. Represent the j-th candidate mapping item in the active cache or build cache as... The set of candidate mapping terms is represented as For each candidate mapping item Calculate the mapping matching confidence value :

[0063] .

[0064] in, This indicates the integrity score of the connection tracking field. This indicates the time validity score of the state. This indicates consecutive hits on the same connectivity feature. This indicates the reliability score of the connection tracking status source. This represents the consistency score of the TUN address reverse recovery result, where E_j represents the penalty item corresponding to multiple candidate conflicts or inconsistent backend device lists. to To preset weights, This means limiting the calculation results to a range of 0 to 1 or other preset values. For example, the state-time validity score. According to Confirmed, among which The state time corresponding to the candidate mapping item. Set a preset time window; consecutive hits score points. According to Confirmed, among which H represents the number of consecutive hits, and H is the preset hit count threshold.

[0065] In the candidate mapping set M, select those that satisfy... The candidate mappings are used as target candidates. If Not less than the preset output threshold ,and The difference between the confidence value of the second-highest candidate mapping item and the confidence value of the second-highest candidate mapping item shall not be less than a preset difference threshold. Then output The corresponding backend device address or backend device ownership identifier; if the above conditions are not met, the connection tracking status is refreshed, the connection status cache within the preset time window is traced back, or the current connection feature is added to the pending confirmation queue. By setting both the output threshold and the difference threshold, the probability of misattribution when the scores of multiple candidate mapping items are close can be reduced.

[0066] In selective labeling scenarios, the selective labeling probability can be further determined based on the mapping matching confidence value of the target candidate, the current processing load on the end side, and the number of times the same connection has been labeled. For example, it can make Follow It increases with the current processing load on the network side or the number of times the same connection has been marked. Network-side devices can target the affiliation of objects. and backend devices Calculate cumulative value ,in It can represent a 5-tuple, session, time window, user account, or base station-side connection. Reaching the preset quantity threshold, or In the same belonging object When the proportion below reaches a preset threshold, the belonging object is determined. The corresponding backend device is Therefore, the endpoint does not need to mark each data packet individually, and the network side can still recover the backend device attribution of the corresponding traffic based on the cumulative results.

[0067] The embodiments of the present invention will be described in detail below with reference to the method steps.

[0068] In step S101, on an Android mobile terminal with the hotspot sharing function enabled, a TUN virtual network channel is established based on the VpnService interface provided by the Android system, and the hotspot sharing interface, routing rules or forwarding rules are configured so that the hotspot traffic generated by the backend device accessing the hotspot and forwarded by the Android mobile terminal is forwarded to the TUN virtual network interface created by the VpnService, so as to import the corresponding data packets into the user space processing path.

[0069] like Figure 4 As shown in sections 401 to 403, in one specific implementation, after the backend device generates a hotspot service IP packet, the Android mobile terminal receives and forwards the packet via the hotspot interface. The mobile terminal calls the VPNService interface provided by the Android system to establish a TUN virtual network interface and configures the corresponding address information, routing rules, and hotspot forwarding rules, so that the target data packet on the hotspot sharing interface is forwarded to the TUN virtual network interface and enters the user-space processing path. In this way, without changing the basic hotspot sharing function, data packets that need to perform home restoration can be uniformly imported into the terminal-side processing link.

[0070] Furthermore, in some implementations, the TUN virtual network interface can be configured to import only traffic related to hotspot forwarding, while local traffic from the front-end terminal that does not require home restoration can be excluded from this processing link, or quickly identified after entering. This reduces unnecessary data processing burden and improves the targeting of traffic processing for hotspot back-end devices.

[0071] In some embodiments, after data packets enter user space via the TUN virtual network interface, they can be sent to the local processing module via JNI bridging, and then passed to the subsequent home recovery and acquisition processing links via a queue structure. The purpose of this processing method is to ensure that data packets imported via TUN traffic can enter the subsequent parsing, mapping recovery, and forwarding processes in a unified order, thereby avoiding inconsistencies in home recovery results under different processing paths.

[0072] In step S102, the data packet is parsed to read connection feature information including at least protocol type, source address, destination address, source port, and destination port.

[0073] In one implementation, the connection feature parsing module first performs network layer and transport layer parsing on the IP packets received via the TUN virtual network interface, extracting information such as protocol type, source IP address, destination IP address, source port, and destination port, and then organizes this information into connection features that can be used to retrieve dynamic mapping relationships. For TCP and UDP packets that can form a complete 5-tuple, the 5-tuple can be directly used as connection feature information; for scenarios where transport layer port information cannot be completely extracted, auxiliary retrieval conditions can be formed by combining the available network layer identifier and time information.

[0074] It should be noted that the connection feature information is not only used for instantaneous data packet parsing, but is integrated into multiple stages such as dynamic mapping relationship establishment, fast cache hit retrieval, miss backfilling, and cumulative utilization at the network-side connection level or session level. Therefore, in this embodiment of the invention, the connection feature information is one of the fundamental inputs for dynamic mapping recovery to operate.

[0075] In step S103, the backend device information and connection tracking information of the Android mobile terminal hotspot subnet are read, and when the Android system's security enhancement mechanism restricts the reading of connection tracking files, a security policy rule file for allowing preset state reading components to access the connection tracking files is loaded or configured.

[0076] like Figure 3 301 to 303 and Figure 4 As shown in Figure 405, in one embodiment, the connection tracking read assurance module prioritizes reading NAT forwarding table information or connection tracking information to obtain backend device addresses, port mapping relationships, and connection status information, and constructs a backend device list based on the information. Since Android hotspot traffic typically undergoes address translation and port mapping during actual operation, simply relying on the packet addresses appearing in the TUN interface cannot reliably reconstruct the actual backend devices. Therefore, it is necessary to introduce the underlying connection status as the basic state source for attribution recovery.

[0077] Furthermore, in a real-world Android environment, connection tracking information can be obtained by reading the ` / proc / net / nf_conntrack` file. This implementation provides a more direct path for reading connection status in Android hotspot scenarios, avoiding excessive reliance on lower-level interfaces with higher privileges, thereby improving the feasibility of the solution in real-world terminal environments. The connection tracking and reading guarantee module can periodically read the contents of this file, parse the connection status, source address, destination address, protocol type, and mapped port information, and organize it into the status records required for subsequent dynamic mapping establishment.

[0078] In a more specific implementation, when the Android system enables the SELinux mandatory access control mechanism, even in a runtime environment with advanced system access permissions, the default application process or local state reading component may fail to read the connection tracking state due to a mismatch between the process security context and the access control rules of the connection tracking state source. To address this, the security domain, executable file label, connection tracking state source label, and access permissions corresponding to the default state reading component can be defined in the device policy file, following the configuration method of the SELinux policy file on the Android device side. The security policy rule file can be used to allow the default state reading component to perform at least one access operation on the connection tracking state source, including reading, opening, obtaining attributes, or directory searching. The connection tracking state source may include / proc / net / nf_conntrack, or it may include a file node, command output interface, or kernel interface in the system equivalent to the connection tracking state output. Therefore, the connection tracking read assurance module can stably read the connection tracking state after the access control conditions are met, thereby providing continuous state input for dynamic mapping relationship establishment, periodic refreshing, and miss backfilling.

[0079] It should be noted that the purpose of configuring the security policy rule file is not to bypass system security mechanisms or create an independent identification path, but rather to establish explicit access control permissions for connection tracking state reading in an Android implementation environment with the corresponding system access conditions. In actual configuration, priority can be given to limiting the security domain of the preset state reading component itself and the type of connection tracking state source, avoiding extending access permissions to unrelated processes or file nodes. In other words, the security policy rule file is a connection tracking state reading protection mechanism, and its technical effect is to reduce the probability of state reading failures due to SELinux policy restrictions and to provide a more stable state source for subsequent dynamic mapping recovery processes.

[0080] In other embodiments, when NAT forwarding table information or connection tracking information is inaccessible, incomplete, or cannot form a valid match, the connection tracking read guarantee module can use an active probing method to complete the backend device list. This active probing method may include performing ARP scans on hotspot subnets to discover active addresses, using ICMP probing to confirm the connectivity status of the corresponding addresses, and using TCP / UDP port probing to identify active terminal characteristics. It should be understood that this active probing method in this invention is a completion mechanism set up to ensure that dynamic mapping recovery can continue to establish and maintain the required backend device information, and does not change the core technical line of this invention, which is connection tracking dual-buffered dynamic mapping.

[0081] In step S104, a dynamic mapping relationship supported by a connection state cache and a fast retrieval cache is established based on the backend device information, connection tracking information, and connection feature information. Specifically, the dual-caching dynamic mapping module can associate and store connection feature information with the backend device address, backend device ownership identifier, mapping establishment time, mapping update time, mapping lifetime, and mapping matching confidence value. In this way, on the one hand, the ownership of the backend device corresponding to the current connection feature can be saved, and on the other hand, the time dimension and mapping matching confidence value can be used to determine whether the mapping relationship needs to be refreshed, continued, output, or cleaned up.

[0082] In a more specific implementation, the dynamic mapping relationship is supported by a connection state cache and a fast retrieval cache. The connection state cache stores timestamped connection tracking history information. Since the same connection may experience state changes at different points in time, or the arrival time of user-space data packets may not be completely synchronized with the connection state reading time, retaining the connection state history within a certain time window helps to perform time association and state backtracking during subsequent recovery. The fast retrieval cache uses connection feature information as an index to directly associate the backend device address, backend device ownership identifier, and mapping matching confidence value, so as to prioritize fast hits when data packets arrive, reducing the processing overhead of querying the underlying connection state information packet by packet.

[0083] In some embodiments, the connection state cache may employ a lightweight double-buffered structure. Specifically, the connection state cache includes an active cache and a build cache; the active cache queries the current data packet and maintains a read-only or low-write-frequency state; the build cache receives the latest read connection tracking information, parses the protocol type, bidirectional address port, connection state, and timestamp, and generates candidate mapping entries. After the build cache completes field parsing, conflict checking, and candidate mapping entry generation, the system switches the build cache to the new active cache through reference switching, version number switching, or equivalent atomic switching. The original active cache can then be reused as the build cache for the next round. In this way, the connection tracking refresh process and the packet-by-packet query process can be isolated from each other, reducing the processing overhead caused by lock contention and high-frequency updates.

[0084] To ensure the dynamic mapping relationship remains valid, the terminal can be configured to periodically read the latest NAT forwarding table information or connection tracking information and update the dynamic mapping relationship. Alternatively, an immediate refresh can be triggered when a fast retrieval cache miss occurs, the mapping match confidence value is insufficient, or the backlog in the confirmation queue reaches a preset condition. Mapping entries that have not been matched within a preset time window, whose connection status has expired, or whose lifespan has exceeded a threshold can be deleted or marked as invalid by a cleanup mechanism. Therefore, the dynamic mapping relationship used in this embodiment of the invention is not a static mapping table, but a continuously functioning structure that can be dynamically maintained as the connection status changes.

[0085] In step S105, backend device attribution recovery is performed on the data packet based on the dynamic mapping relationship and mapping matching confidence value. After determining the backend device corresponding to the data packet, the backend device attribution identifier determined by the dynamic mapping relationship is written to the data packet.

[0086] like Figure 3 304 to 308 and Figure 4 As shown in Figures 406 and 407, in one embodiment, when a new data packet arrives, the TUN address reverse recovery and marking module first searches the fast retrieval cache for the corresponding backend device address, backend device attribution identifier, and mapping match confidence value based on the connection feature information of the current data packet. If the search is successful and the mapping match confidence value reaches a preset output threshold, it indicates that the connection feature has established a stable correspondence with a certain backend device, and the attribution of the current data packet can be restored to that backend device.

[0087] If the fast retrieval cache misses, or the mapping matching confidence value of the hit result does not reach the preset output threshold, the TUN address reverse recovery and marking module can further access the connection state cache and re-execute the matching based on the latest acquired connection tracking information, port mapping relationships, and backend device list. If the re-match is successful, the matching result and the updated mapping matching confidence value are written back to the fast retrieval cache for direct use by subsequent data packets with the same or related connection characteristics. By prioritizing fast hits, backfilling the underlying state, backfilling the cache after success, and allowing low-confidence packets to enter the confirmation queue, the accuracy of attribution recovery can be maintained while also ensuring processing efficiency in high-traffic scenarios.

[0088] In one important implementation, when the source or destination address of a data packet corresponds to the address of a TUN virtual network interface, the system does not directly determine the backend device based on the TUN address. Instead, it performs reverse recovery by combining the port information, protocol type, and corresponding records in the connection tracking information of the data packet. Specifically, it first searches for the corresponding mapping entry in the connection state cache or connection tracking record based on the port information and protocol type, and then recovers the real backend device address based on the mapping entry. In this way, TUN-related data packets entering the user-space processing path can be re-associated with the real backend device, thus forming a complete closed loop between TUN traffic import and homepage recovery.

[0089] After determining the backend device corresponding to the current data packet, the TUN address reverse recovery and marking module generates a backend device attribution identifier based on the backend device address, port mapping relationship, or its conversion result in the dynamic mapping relationship, and writes the backend device attribution identifier into the corresponding field of the current data packet. The backend device attribution identifier can be written into an IP header field, an extended field, or tunnel encapsulation metadata. It should be emphasized that writing the backend device attribution identifier is not the core identification behavior of this invention, but rather a result-bearing method for outputting the backend device attribution result recovered on the terminal side to the network side.

[0090] In some embodiments, to avoid the high processing overhead of writing backend device ownership identifiers to all data packets whose ownership has been restored in high-traffic scenarios, a selective marking mechanism can be adopted. Specifically, the decision to enter selective marking mode can be based on the hotspot forwarding traffic rate, the number of data packets to be processed, or the processing load on the endpoint. In selective marking mode, the backend device ownership identifier can be written preferentially to the first or several packets of the same connection, or data packets can be sampled and written according to a preset time window, or data packets whose ownership has been restored can be sampled and written according to a preset ratio. In this way, although not all data packets carry the backend device ownership identifier, as long as the network side receives a sufficient number of marked data packets, it can still restore the backend device ownership relationship of the corresponding connection, session, or time window traffic.

[0091] In step S106, the data packets containing the backend device home identifier are reassembled and forwarded using the user-space network protocol stack, and the backend device home identifier is parsed by the network-side device.

[0092] In one implementation, the user-space protocol stack forwarding module utilizes the user-space network protocol stack to perform session management, packet reassembly, and forwarding control within user space. For data packets belonging to the same connection or session, necessary reassembly and forwarding can be performed according to protocol processing requirements to ensure that data packets carrying the backend device's ownership identifier can be stably output along a unified processing path. By introducing the user-space network protocol stack, the additional burden caused by frequent switching between kernel mode and user mode at different processing stages can be reduced, and the continuity of the backend device's ownership identifier in the terminal-side processing link can be enhanced.

[0093] It should be noted that the traffic forwarding step described in this invention is not a normal forwarding process independent of dynamic mapping recovery, but rather a guarantee step for outputting the attribution recovery result. Without a unified user-space forwarding path, the processing results formed by TUN traffic import, dynamic mapping recovery, and backend device attribution identifier writing will be difficult to reliably transmit to subsequent network processing stages.

[0094] Furthermore, the network-side device restores the backend device affiliation relationship of the corresponding connection traffic, session traffic, or time window traffic based on the backend device affiliation identifier.

[0095] like Figure 4 As shown in Figure 408, in one embodiment, after the network-side device receives a data packet with a backend device attribution identifier from an Android terminal, it does not independently re-determine the attribution of the hotspot backend device. Instead, it directly uses the backend device attribution identifier output by the terminal to accumulate the marked data packets according to at least one dimension selected from the five-tuple, session information, time window, user account, or base station-side connection. Once enough marked data packets have been accumulated to characterize the source of the corresponding backend device, the corresponding connection traffic, session traffic, or time window traffic can be restored to be attributed to the corresponding backend device.

[0096] In scenarios employing selective labeling mechanisms, network-side devices can perform attribution recovery based on 5-tuples, sessions, time windows, user accounts, or base station-side connection objects, without requiring each data packet to carry a separate backend device attribution identifier. For example, for the same 5-tuple or the same session, the network-side device can determine the backend device attribution of the connection based on the previous number of labeled data packets; for scenarios accumulating data within a time window, the network-side device can determine the attribution of the corresponding traffic within that window after accumulating a sufficient number of labeled samples within a preset time window; for processing scenarios associated with user accounts or base station-side connections, the network-side device can associate the backend device attribution identifier with the account dimension or access connection dimension. Therefore, this embodiment of the invention can reduce the performance overhead of full packet-by-packet labeling on the terminal side without sacrificing subsequent attribution utilization capabilities.

[0097] like Figure 5 As shown, in some embodiments, the method of the present invention may further include a data acquisition and dataset construction process. Specifically, step 501 is executed first to receive data packets whose attribution has been restored or whose backend device attribution identifier has been written; then step 502 is executed to determine the sample classification according to the backend device, connection information, or time window; subsequently, step 503 is executed to write the traffic samples to be saved into a memory buffer; and step 504 determines whether the disk writing conditions are met. When the disk writing conditions are met, step 505 is executed to generate a PCAP file, and step 506 can be further executed to perform local storage, remote upload, and server timestamp calibration. The acquired data can be stored locally in PCAP or a similar format, or it can be uploaded to a remote server via a network. After receiving the data, the server can perform timestamp calibration to improve the consistency of multi-source data, and then form an offline dataset for verifying the dynamic mapping recovery results or constructing hotspot traffic identification and analysis samples.

[0098] Combination Figures 1 to 5As can be seen from the above implementation methods, the embodiments of the present invention form a continuous closed loop around the core mechanism of dynamic mapping attribution based on connection tracking dual buffers: First, the data packet input required for attribution recovery is obtained through VpnServiceTUN traffic import; then, the real backend device state basis is obtained through connection tracking read guarantee and TUN address reverse recovery; next, the connection state cache, fast retrieval cache, and mapping matching confidence value provide a continuous working structure and output judgment basis for packet-by-packet attribution recovery; subsequently, the backend device attribution result determined by the end side is output to the network side through backend device attribution identifier writing; finally, through network side cumulative utilization and optional collection links, the attribution recovery result can serve online processing and offline analysis. Therefore, the present invention can provide a backend device traffic attribution scheme that balances feasibility, continuity, and processing efficiency under the actual implementation constraints of Android hotspots.

[0099] In scenarios involving home broadband replacement or temporary travel sharing, Android mobile terminals often serve as temporary access gateways for multiple devices, such as simultaneously providing network services to tablets, laptops, in-vehicle devices, and smart wearable devices. By adopting this invention, operational or enterprise networks can differentiate and identify the traffic corresponding to different backend devices without changing the access methods of the backend devices. This supports differentiated protection strategies for different services such as video conferencing, online education, map navigation, and background synchronization, improving network experience and resource utilization efficiency in hotspot sharing scenarios.

[0100] In scenarios such as enterprise mobile office, on-site operation and maintenance support, emergency communication, and temporary networking for exhibitions, front-end Android mobile terminals often undertake centralized networking tasks for multiple back-end devices. In these situations, this invention can be used to mark the traffic of different service terminals on the terminal side, and the core network side or enterprise private network side can then perform access control, bandwidth scheduling, service priority allocation, and audit retention based on this data. Furthermore, in scenarios such as operator network optimization or hotspot service analysis, the anonymized traffic data generated by this invention can also be used for hotspot service profiling, network load assessment, and offline identification model training, thereby enhancing the engineering application value of the solution.

[0101] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for dynamically mapping and attributing backend devices in an Android hotspot, characterized in that, Includes the following steps: S101. On an Android mobile terminal with hotspot sharing enabled, a TUN virtual network channel is established based on the VpnService interface provided by the Android system, and hotspot sharing interface, routing rules or forwarding rules are configured so that the target hotspot traffic generated by the backend device accessing the hotspot and forwarded by the Android mobile terminal is forwarded to the TUN virtual network interface created by the VpnService so as to import the corresponding data packets into the user space processing path. S102. Parse the data packets received via the TUN virtual network interface and read connection characteristic information including at least the protocol type, source address, destination address, source port, and destination port. S103. Read the backend device information and connection tracking information of the Android mobile terminal hotspot subnet, and when the Android system's security enhancement mechanism restricts the reading of the connection tracking file, load or configure a security policy rule file for allowing the preset state reading component to access the connection tracking file, wherein the connection tracking information is at least used to characterize the bidirectional address port correspondence of the hotspot forwarding traffic before and after address translation. S104. Parse the bidirectional address port, connection status and timestamp in the connection tracking information, and establish a dynamic mapping relationship supported by the connection status cache and the fast retrieval cache based on the backend device information, connection tracking information and connection feature information. The dynamic mapping relationship includes the mapping matching confidence value. S105. Perform backend device attribution recovery on data packets based on dynamic mapping relationships. Specifically, when the source or destination address of a data packet is a TUN address corresponding to a TUN virtual network interface, the corresponding backend device address is recovered in reverse based on the port information, protocol type, and bidirectional address-port correspondence in the connection tracking information. The corresponding backend device is searched in the fast retrieval cache based on connection feature information. When the search is successful and the mapping matching confidence value reaches a preset output threshold, the backend device corresponding to the data packet is determined and the backend device attribution identifier determined by the dynamic mapping relationship is written. When the search fails or the mapping matching confidence value does not reach the preset output threshold, matching is re-executed based on the connection status cache, the latest acquired connection tracking information, or the completed backend device information. Upon successful matching, the dynamic mapping relationship and the mapping matching confidence value are updated. S106. The user-space network protocol stack is used to reassemble and forward the data packets after writing the backend device affiliation identifier, and the network-side device parses the backend device affiliation identifier to restore the backend device affiliation relationship of the corresponding connection traffic, session traffic or time window traffic based on the backend device affiliation identifier.

2. The method according to claim 1, characterized in that, Step S101 includes: after creating the TUN virtual network interface, configuring address information and routing rules, and configuring policy routing, forwarding rules or equivalent rules through the hotspot traffic provided by the Android system via the VPN forwarding switch, or through an auxiliary configuration program with advanced system access permissions, so that the target forwarding traffic on the hotspot sharing interface enters the TUN virtual network interface; and sending the data packets received through the TUN virtual network interface to the local processing module through JNI bridging or queue structure.

3. The method according to claim 1, characterized in that, Step S103 includes: reading NAT forwarding table information or connection tracking information when system permissions permit, to obtain backend device addresses, port mapping relationships and connection status information, and constructing a backend device list accordingly; When the NAT forwarding table information or connection tracking information is inaccessible, incomplete, or cannot form a valid match, the backend device list is completed by active probing. The active probing method includes at least one of ARP scanning, ICMP probing, and TCP / UDP port probing. On the Android device, the connection tracking information is obtained through at least one connection tracking status source, including the / proc / net / nf_conntrack file, the / proc / net / ip_conntrack file, connection tracking command output, the Netlink connection tracking interface, or an equivalent connection tracking status interface provided by the vendor. The dynamic mapping relationship includes at least: connection feature information, backend device address, backend device ownership identifier, mapping establishment time, mapping update time, mapping lifetime, and mapping matching confidence value; The refresh thread is configured to periodically read the latest NAT forwarding table information or connection tracking information, update the dynamic mapping relationship, and clean up invalid mapping items according to preset lifespan, connection status changes, or time windows. The dynamic mapping relationship is supported by a connection state cache and a fast retrieval cache. The connection state cache is used to store connection tracking history information with timestamps, and the fast retrieval cache is used to quickly retrieve the backend device address or backend device ownership identifier based on connection feature information. The connection state cache includes an active cache and a build cache. The build cache is used to receive the latest read connection tracking information and generate candidate mapping items. The active cache is used for querying the current data packet. After the build cache is updated, it is replaced by reference switching, version number switching, or equivalent atomic switching.

4. The method according to claim 1, characterized in that, In step S105, when the source address or destination address of the data packet is the TUN address corresponding to the TUN virtual network interface, the backend device is not directly determined based on the TUN address, but the corresponding backend device address is restored based on the port information, protocol type, and bidirectional address-port correspondence in the connection tracking information of the data packet. The method of writing the backend device ownership identifier in step S105 includes: writing the backend device ownership identifier into the IP header field, extension field, or tunnel encapsulation metadata; wherein, the backend device ownership identifier is obtained by converting the backend device address or port mapping relationship in the dynamic mapping relationship. After determining the backend device corresponding to the data packet, when the hotspot forwarding traffic rate, the number of data packets to be processed, or the end-side processing load reaches the preset conditions, according to the preset probability rule or preset selection rule, only the backend device affiliation identifier is written to some of the data packets that have completed the backend device affiliation recovery. The preset selection rules include at least one of the following: preferentially writing the backend device ownership identifier into the first message or the first few messages of the same connection; extracting data packets according to a preset time window and then writing them into the backend device ownership identifier; or sampling data packets that have completed the backend device ownership recovery and writing them into the backend device ownership identifier according to a preset ratio.

5. The method according to claim 1, characterized in that, Step S106 includes: the network-side device accumulates the received data packets with the back-end device affiliation identifier written in them according to at least one dimension of five-tuple, session information, time window, user account or base station-side connection, and restores the back-end device affiliation relationship of the corresponding connection traffic, session traffic or time window traffic based on the accumulation result. It also includes: collecting and de-identifying data packets that have completed ownership recovery or have been written with backend device ownership identifiers according to the backend device ownership recovery results and at least one of the following strategies: IP address, session identifier, application protocol and time window, in order to generate an offline dataset for verifying dynamic mapping recovery results or constructing hotspot traffic identification and analysis samples. The data collection and desensitization storage includes at least one of the following methods: saving different data files according to the backend device affiliation results, saving the collected data locally, uploading the collected data to the server via the network, and having the server perform timestamp calibration on the received data to form an offline dataset; When reading the connection tracking information, at least a portion of the following information is parsed: protocol type, connection status, first direction source address, first direction destination address, first direction source port, first direction destination port, second direction source address, second direction destination address, second direction source port, and second direction destination port, in order to restore the correspondence between the backend device address and the TUN address.

6. The method according to claim 5, characterized in that, When the current data packet is not found in the fast retrieval cache, the most recently saved connection state cache within the preset time window is searched first; if no matching result is found, the latest connection tracking information is refreshed and the refresh result is written to the construction cache. After the construction cache completes field parsing, conflict checking and candidate mapping item generation, it is switched to the new active cache, and the matching is re-executed based on the switched active cache. The data collection and desensitization storage includes: first, writing the traffic samples to be saved corresponding to the backend device attribution recovery results into a buffer; then, writing the data in the buffer into a PCAP file in segments according to at least one of the following conditions: a preset time window, a file size threshold, or a backend device dimension.

7. The method according to claim 6, characterized in that, Before reading the connection tracking information, the method further includes: when the Android system's security enhancement mechanism restricts the application process from accessing the connection tracking state source, configuring a security policy rule file that describes the security domain of the preset state reading component, the executable file label, the connection tracking state source label, and access permissions according to the Android device-side SELinux policy file configuration method, so that the preset state reading component performs at least one access operation among reading, opening, obtaining attributes, or directory searching on the connection tracking state source; wherein, the security enhancement mechanism includes the SELinux mandatory access control mechanism, and the preset state reading component includes at least one of the following: an application process, a local daemon process, a command-line state reading program, or a local library component called by the application process; The mapping matching confidence value is determined based on at least one of the following parameters: completeness of connection tracking fields, time difference between connection status timestamp and current data packet arrival time, number of consecutive hits of the same connection feature within a preset time window, connection tracking status source type, backend device information source, and consistency of TUN address reverse recovery results. Specifically, the mapping matching confidence value is increased when the bidirectional address port field is complete, the time difference is less than a preset threshold, the same connection feature hits the same backend device consecutively, and the reverse recovery results are consistent. The mapping matching confidence value is decreased when the field is missing, the time difference exceeds the preset threshold, the source is supplementary information, or the reverse recovery results are inconsistent.

8. The method according to claim 7, characterized in that, When the mapping matching confidence value reaches the preset output threshold, the backend device ownership identifier is output; when the mapping matching confidence value does not reach the preset output threshold, the corresponding connection feature is added to the confirmation queue, and the mapping matching confidence value is updated after subsequent connection tracking information is refreshed, connection status cache is hit, or consecutive data packets are successfully matched. For candidate mapping items Calculate the confidence value of the mapping match ,in ; This indicates the integrity score of the connection tracking field. This indicates the time validity score of the state. Indicates consecutive successful shots. This indicates the reliability score of the connection tracking status source. This indicates the consistency score of the reverse recovery results from the TUN address. Indicates conflict penalty items, to To preset weights, This indicates that the calculation results will be limited to a preset range of values; From the candidate mapping set Select to satisfy Candidate mapping terms are used as target candidates; when Not less than the preset output threshold ,and The difference between the confidence value of the second-highest candidate mapping item and the confidence value of the second-highest candidate mapping item shall not be less than a preset difference threshold. When the target candidate is selected, the backend device ownership identifier corresponding to it is output. Otherwise, it will trigger a refresh of the connection tracking status, a rollback of the connection status cache, or the addition of the corresponding connection feature to the pending confirmation queue. The selective marking probability is determined based on the mapping matching confidence value of the current target candidates, the current processing load on the endpoint, and the number of times the same connection has been marked. ,in The confidence level increases with the mapping match value and decreases with the increase of the end-side processing load or the number of times the same connection has been marked; the network-side device processes marked data packets according to their belonging objects. and backend devices Calculate cumulative value ,when When the preset quantity threshold is reached or the proportion within the same belonging object reaches a preset percentage threshold, the belonging object is determined. The corresponding backend device is .

9. An Android hotspot backend device dynamic mapping and attribution system, characterized in that, include: The TUN traffic import module is used to establish a TUN virtual network channel based on VpnService on an Android mobile terminal with hotspot sharing enabled, and to configure hotspot sharing interface, routing rules or forwarding rules so that the target hotspot traffic generated by the backend device connected to the hotspot and forwarded by the Android mobile terminal is forwarded to the TUN virtual network interface created by VpnService. The connection feature parsing module is used to parse data packets received via the TUN virtual network interface and read connection feature information. The connection tracing and reading protection module is used to obtain backend device information and connection tracing information for accessing the hotspot subnet, and to load or configure security policy rule files when the SELinux mandatory access control mechanism of the Android system restricts the reading of connection tracing files; The dual-caching dynamic mapping module is used to parse the bidirectional address port, connection status and timestamp in the connection tracking information, and to establish and maintain the dynamic mapping relationship between the connection feature information and the backend device and the mapping matching confidence value based on the connection status cache and the fast retrieval cache. The TUN address reverse recovery and marking module is used to recover the backend device address based on the bidirectional address-port correspondence in the port information, protocol type and connection tracking information when the source address or destination address of the data packet is a TUN address, and to perform backend device attribution recovery on the data packet based on the dynamic mapping relationship and the mapping matching confidence value, and to write the backend device attribution identifier determined by the dynamic mapping relationship to the data packet that has completed attribution recovery when needed. The user-space protocol stack forwarding module is used to reassemble and forward data packets after writing the backend device's home identifier using the user-space network protocol stack. The network-side cumulative utilization module is used to parse the backend device affiliation identifier and restore the backend device affiliation relationship of the corresponding connection traffic, session traffic or time window traffic based on the backend device affiliation identifier.

10. The system according to claim 9, characterized in that, The connection tracking and reading protection module is configured to: read NAT forwarding table information or connection tracking information when system permissions permit; when the Android system's SELinux mandatory access control mechanism restricts the reading of connection tracking files, load or configure a security policy rule file to allow the preset state reading component to read the connection tracking file; and when the information is inaccessible, incomplete, or cannot form a valid match, perform active probing to complete the backend device list. The dual-cached dynamic mapping module is further configured to: use a timestamped connection state cache and a fast retrieval cache to support the establishment, updating, miss backfilling and invalidation cleanup of dynamic mapping relationships, and add the corresponding connection features to the confirmation queue when the mapping matching confidence value does not reach the preset output threshold. The TUN address reverse recovery and marking module is further configured to: when the source address or destination address of the data packet is a TUN address, recover the corresponding backend device address based on the port information, protocol type and bidirectional address port correspondence in the connection tracking information, and in high traffic or high load scenarios, only perform backend device ownership identification writing on some data packets that have completed the backend device ownership recovery. It also includes a data acquisition and processing module, which is configured to: classify and save data packets according to the backend device attribution recovery results, and perform timestamp calibration processing on the data acquired locally or uploaded to the server, or trigger the server to perform timestamp calibration processing, in order to verify the dynamic mapping recovery results or construct hotspot traffic identification and analysis samples.

Images