# Secure access to network data for mobile network traffic analysis applications

Djob Barbe Thystere Mvondo Djob, Yérom-David Bromberg

► To cite this version:

Djob Barbe Thystere Mvondo Djob, Yérom-David Bromberg. Secure access to network data for mobile network traffic analysis applications. 55th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN 2025), IEEE/IFIP, Jun 2025, Naples, Italy. 10.1109/dsn64029.2025.00063.1. hal-05088761

HAL Id: hal-05088761

https://hal.science/hal-05088761v1

Submitted on 28 May 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Secure access to network data for mobile network traffic analysis applications

Djob Mvondo

Univ Rennes, CNRS, INRIA, IRISA

barbe-thystere.mvondo-djob@irisa.fr

Yerom-David Bromberg

Univ Rennes, CNRS, INRIA, IRISA

david.bromberg@irisa.fr

**Abstract**—Mainstream mobile operating systems (mOSes), such as Android or IOS, do not allow applications to perform network traffic analysis (NTA) by design for security reasons. Indeed, users' network traffic data contain sensitive information, such as browsing history, that can be maliciously exploited, e.g., sold to entities or for blackmailing.

In this paper, we explore the problem of providing a secure and efficient way to grant full network data access to a mobile application willing to perform NTA while preventing misuse of the latter data. We consider the network data to be misused if the latter is sent or leaked out of control of the mobile device. e.g., to an external server. To this aim, we design SANEM, an on-device kernel-level solution. It takes the form of permission that provides a means for an application to perform NTA without being able to misuse the user's network data.

We implement a corresponding prototype atop Android 14. Our evaluation on a rooted Samsung S20 shows that SANEM incurs a small overhead on NTA applications that load it and the overall system resources. Furthermore, compared to other workaround mechanisms, such as on-device local/fake VPNs, the overhead with SANEM is considerably lower.

## I. INTRODUCTION

Android is now the most widely used operating system with 71.62% market shares in September 2022 [109]. Its application ecosystem grows every day; the related application store (i.e., Google Play Store) holds more than 3.3 million applications with a rate of more than 90,000 submissions per month [110]. In 2022, estimates indicate that more than 111.3 billion applications were downloaded on the platform [111]. Unfortunately, this success does not come without a counterpart, as it comes in pair with malware proliferation [105, 118].

To protect users' data, most mainstream mobile operating systems (named thereafter mOSes), such as Android or IOS, use a specific set of access policies to limit applications' manipulation scope of users' information. A direct consequence of these policies is that applications cannot have full access to the device network traffic, i.e., to analyze/monitor all incoming and outgoing network messages. Indeed, network traffic contains sensitive information about the device's owner (downloaded applications, browsing history habits, etc.), and its analysis could be used for malicious purposes, e.g., selling this data or blackmail.

Despite the security benefits of prohibiting network analysis of applications, we argue that it also prohibits several features that could benefit users. Concretely, Network Traffic Analysis (NTA) enables to trace mobile applications to detect unusual

activity and attacks from a network perspective, thereby improving on-device security. Indeed, NTA is one of the cornerstone features of user protection against malware, as it is usually observed on desktop computers. For example, a tracker detection system [63, 64] will monitor network traffic to detect malware according to network footprints, such as stalkerwares [15, 43, 61, 86, 95]. As shown in Figure 1, malware targeting mobile devices generally spoof sensitive user data (e.g., SMS records or geographic position) and transmit them to an online server where they can be used for malicious purposes [9, 22, 37, 38, 92]. These make them harmful and difficult, if not almost impossible, to detect without NTA, as has been demonstrated by the proliferation of stalkerware, or pegasus-type malware [56, 57].

<figure><img src="image_2.png" /><figcaption>Fig. 1: Representation of mobile malware sending sensitive data to an external server for malicious purposes.</figcaption></figure>

To date, applications must leverage the virtual private network (VPN) permission provided by mOSes to perform NTA. With the VPN permission, an application can create a fake VPN (also named local VPN) at the user level to have the privilege to collect the network traffic on-device [44–46, 48, 54, 67, 91, 93, 100, 107, 120, 125].

However, such approaches have at least three main shortcomings. First, as shown in previous works, due to the user-level-based VPN, these approaches incur severe CPU and network overhead, impacting all running applications [46, 67, 107] (Section VI). Second, an application that uses VPN permission to access network traffic data has no restriction regarding its use, opening up a security breach. Once the VPN permission is acquired, applications can freely misuse network traffic data. We consider the network data to be misused if it is sent or leaked out of control of the mobile device, e.g., to an external server. For instance, a user's confidential network data
can be sent to an external server, which can be exploited for malicious purposes, exposing the device owner's privacy and security. Third, there can be only one VPN instance at a time on mOSes, such as Android [8]. Consequently, the existence of a fake VPN for network traffic monitoring purposes excludes using any other VPN. This exclusion is counterproductive; some applications may need to analyze network traffic, while others may need a VPN for other use cases.

Another approach to avoid any data leakage is to combine the use of the VPN permission with sandboxing techniques [31, 65, 79, 98, 115] to isolate applications that perform NTA. However, sandboxing is a heavyweight approach with scalability issues and also has a substantial impact on performance [12, 50].

**Our work.** To the best of our knowledge, no existing solution overcomes the aforementioned shortcomings at once. In this work, we present SANEM<fnref n="1" />, which allows the implementation of NTA while addressing the aforementioned issues. SANEM allows capturing network traffic data from a mobile device to an application, e.g., an antivirus, while preventing the misuse of the latter data. SANEM is an on-device and kernel-level solution in the form of a permission that provides a seamless way for an application willing to do NTA to access network data without leakage. SANEM is: (i) **efficient**, it introduces negligible overheads; (ii) **secure**, it prevents entirely trusting applications compared to the approach with VPN permissions; and (iii) **not exclusive**, as it allows a true VPN to be used in parallel.

Concretely, SANEM provides a new permission that enables an application to capture network traffic *via* a specific interface that abstracts a shared memory buffer filled by the kernel. To prevent misuse of the captured network traffic, SANEM imposes a set of restrictions on NTA applications that use it. First, it adequately filters outgoing network traffic: it blocks the application's sending of network traffic data over the network while allowing its update operations. Second, it prohibits the use of Inter Component Communication (ICC) to prevent the leakage of the captured network traffic to another application, which prevents any potential data exchanges with unrestricted applications. Third, it forbids the creation or update of public files to avoid unauthorized access.

Furthermore, when a SANEM based NTA application is uninstalled, all related files are deleted to guarantee that any previously saved information remains unreachable. Given these restrictions, it appears that ill-intentioned developers should think twice before using SANEM to design their malware. Inherently, they cannot consider our solution as an easy way to leak data.

**Contributions.** We propose an approach to collect network traffic on-device securely. Our approach, SANEM, is better than any other fake/local VPN solutions for performing NTA;

unlike them, SANEM guarantees end-users that NTA cannot be misused. We make the following contributions:

* To the best of our knowledge, SANEM is the first efficient solution that enables applications to capture network traffic while ensuring that collected user data are not misused or leaked. SANEM is a kernel-level solution that provides secure NTA, i.e., respectful of user privacy. NTA is provided to developers as a new permission that end-users trust.

* We have developed a prototype of SANEM on top of Android 14 (android14-6.1 kernel) and thoroughly evaluated it on a rooted Samsung Galaxy S20 by using it in two mobile applications that aim to perform NTA: TrackerControl [63, 64], and PCAPDroid [34]. It appears that SANEM incurs a negligible overhead on applications regarding CPU usage and network throughput. We also compare SANEM against a fake VPN alternative PrivacyGuard [107]; we observe that SANEM overhead is 1,5× better than PrivacyGuard.

## II. BACKGROUND

We present an overview of mOSes permissions and applications' different ways of exchanging data with other applications on the mobile device or external to the device.

**Permission principles.** mOSes restrict applications' access to some of their features by using permissions. Permissions regulate applications' access to APIs on mobile devices. Each permission gives access to a specific set of actions (e.g., issuing a phone call, recording a video, etc.) and data (e.g., user contacts). Each application must declare the permissions it will need, usually *via* an input manifest file [7, 49]. Depending on the mOS, permissions may have several categories [11]. Android, for example, classifies permissions into *install-time*, *runtime*, and *special* permissions [7]. *Install-time* permissions are granted directly by the mOS during installation. These permissions are listed on stores (e.g., Google Play Store) application pages for users to consider. *Runtime* permissions are requested by applications during execution, and the device owner may approve or reject the request. However, these restrictions can be revoked by the user at any time. Finally, special permissions correspond to specific application operations, such as drawing over another application [7], and are only defined by the platform or OEMs. Despite the elaborated permission model, once a permission is granted to an application, there is no control over how the features and data are used.

Once the proper permission is granted, applications can send sensitive data over the network or share it with other applications without the user's consent.

**Data exchange among applications.** In mOSes, applications are isolated from each other. However, there exist at least three major ways to exchange and or leak data from one application to another: (i) through Inter-Process Communication (IPC)

<footnote n="1">¹Secure Access to Network data for Mobile</footnote>
mechanisms, (ii) through the filesystem, and (iii) through the network [80, 94].

IPC in mOSes typically involves sending events coupled with a payload in a specific format to a specific target or a group of target applications. Parameters can be associated with events as in iOS, or the payload can contain a URI that defines the location of the data associated with the event as in Android [13, 59]. Each application configures handlers for each event so that it can trigger the corresponding handler when it receives an event from another application. For example, in Android, there is the concept of intents, which corresponds to events, and to each intent, you can attach a payload with the URI of the data you want to share [59].

File systems are another way for an application to share data. Applications in mOSes can create files in a specific shared storage where every other application can access them. In general, the content in the shared storage space remains even after the uninstallation of the application that created the content [4]. In addition, applications can create files and grant access to some applications to read them [6]. Thus, applications can also exchange sensitive information using the filesystem path.

Finally, the network path can also traditionally be used to exchange data. However, in mOSes, applications cannot use RAW sockets (e.g., RAW UNIX sockets) to exchange data directly [104], unless the mobile device is jailbroken. Only the use of TCP/UDP-based sockets is permitted. This is one of the reasons why mOSes usually advise using IPC to share data among applications [5].

### III. MOTIVATIONS

Applications on mOSes are not able to capture network traffic for security reasons. However, network traffic data can be leveraged by third-party applications for several use cases to enhance on-device security auditing tools, such as antivirus software that detects malware with network footprints.

#### A. Issues with current solutions.

To date, the only way for applications on mOSes to capture network traffic is to leverage VPN permissions to create a local VPN<fnref n="2" />. Once the VPN permission is granted, an application can configure a local VPN and have the device's network traffic routed through the latter. In this way, it can perform NTA. However, doing so raises three critical issues. The first concerns performance, as such NTA based solution can cause up to 45% overhead for network performance (throughput and latency) for applications [107]. The second concerns data control since there is no control over how the VPN based solution effectively uses the data. The device owner has no choice but to trust the goodness of the application developers: at the system level, nothing prevents the application from sending the captured network traffic data to an external server. The last concerns VPN conflicts since for security concerns and to avoid any conflicts among VPNs, only one VPN can be instantiated at a time on mOSes like Android [8]. Accordingly, if the unique VPN interface is hijacked to capture network traffic, it is no longer possible for the end-user to protect himself via an additional real VPN. Thus, relying on a VPN to provide access to network data is a major limitation.

#### B. Objective and Challenges

Due to the aforementioned reasons, our solution should overcome the following four challenges.

**Challenge 1: Safe and simple delivery of network traffic data.** The first challenge concerns the safe delivery of the collected network traffic to an application that needs it. In mOses, applications run in sandboxes that are isolated from each other. The mOS kernel controls access to the resource level of each sandbox. Thus, applications cannot natively view all incoming and outgoing network traffic of the underlying mobile device.

Our solution must be simple and generic enough so that an application can capture the network traffic without requiring special modifications to its code base.

**Challenge 2: Network restrictions without hampering existing features.** The second challenge concerns finding adequate restrictions to apply to applications to avoid misuse of network data while keeping most applications' network-related features unaffected. It is not enough to ban outgoing traffic and isolate applications from the network. For example, with the standard TCP/IP, when establishing a network connection between two entities, messages are exchanged (sent and received — SYN-ACK) [14, 16]; therefore, we cannot allow incoming network messages for an application while banning all outgoing messages. Additionally, for most protocols, such as HTTP/HTTPS, when receiving a message, a confirmation reply should be sent, for example, an HTTP 200 OK reply message.

Our solution must adequately filter the network data traffic. It must carefully maintain a list of allowed network messages to authorize outgoing traffic judiciously.

**Challenge 3: Preventing covert channel attacks.** Even if data leakage through the network is no longer possible (by solving Challenge 2), it is still possible to leak *via* data exchange among applications *via* covert channel attacks. Our solution must prevent such attacks relevant to our objective [93], particularly covert channel attacks from the system perspective, such as IPC mechanisms or file systems. Note that we are not covering dedicated covert attacks that use unorthodox mediums such as ultrasonic audio beacons, infrared, light, vibrations, etc. [18, 26, 39, 41, 76, 77, 93, 117]. This is outside the scope of our work (Section IV).

**Challenge 4: Preventing side-channel attacks.** The fourth challenge concerns side channel attacks [93]. We must find the right usage policy for our solution to avoid unintentional data leaks. For example, an application should not be able to

<footnote n="2">²Note that even with Android Native Development Kit (NDK), only root processes can access raw sockets [73, 102].</footnote>
load our solution to get network traffic data and unload it to
remove *à postériori* the security restrictions to take advantage
of previously collected network traffic data.

IV. THREAT MODEL AND ASSUMPTIONS

Our threat model considers the mutual distrust between a
mOS kernel and an application that wants to access to network
traffic data. Thus, the threat model consists of the following
two perspectives.

A. *The kernel.*

The mOS kernel is trusted. It can have all the necessary access to the mobile device. It does not trust third-party applications and needs to protect network traffic data. From the kernel perspective, network traffic data is misused if the data is sent to an external server through a network interface, which can be maliciously leveraged. Thus, if an application gets access to all network traffic data and manages to send them to an external server through a network interface, it breaches our security model.

B. *Malicious applications and attacks.*

Third-party applications are not trusted. A third-party ap-
plication wants to implement NTA to protect the device user
from data leakage. However, we cannot fully trust third-party
applications, as some may have malicious intent. We assume
that applications with granted access to network traffic data
can perform the intended NTA without requiring connections
to an external server. However, such an application can still
need to update itself, update an internal component (e.g., an
internal viral database), or receive push notifications from an
external server.

We consider an application malicious if it wants to access
network traffic data and manages to leak this data to an exter-
nal server through a network interface. A malicious application
behaves as a normal application. It can request several per-
missions, including those for creating and manipulating files,
communicating with other applications, and sending/receiving
packets over the network.

Upon access to network traffic data, we consider that a
malicious application can launch different attacks to leak
the captured network data. We are covering the known
covert and channel attacks that are the most relevant to our
context, taken from previous studies that have been carried
out [75, 94, 108]. Our work focuses on vulnerabilities that
are exploited *via* the mOSes API or services by malicious
applications running in the user space. For each attack, we
assume that the malicious application obtains access to the
network traffic data access through a specific solution in the
form of permission, but some restrictions can be applied to
the application as a counterpart. The five attacks are derived
from the different existing permissions and communication
mechanisms provided by mOSes to applications, as shown in
Section II.

**Attack 1: Using the network.** A malicious application can try establishing a TCP connection with a remote server and start transmitting the retrieved network traffic data. This attack does not require any special permission since data transmission *via* the network device requires a normal permission that can be obtained by any application.

**Attack 2: Using IPC.** To bypass any network restriction applied to it due to the network traffic data access, a malicious application can transmit network traffic data in several chunks to another application using IPC mechanisms, also referred to as ICC in Android jargon. Thus, even if the malicious application has restricted network rights, it can bypass it *via* another unrestricted application, which can then transmit the captured data over the network.

**Attack 3: Using the file system.** A malicious application can create a file in shared storage to write the captured network traffic data. Thus, another unrestricted application can *a posteriori* read the content to send it to an external server over the network finally. Apart from shared storage, it can only create and share the file with a specific application instead of making it accessible to everyone else.

**Attack 4: Loading-unloading.** A malicious application can gain the necessary network access by loading the permission and tricking the mobile device holder into unloading it (e.g., with regular notifications). Once the permission is unloaded, the application can send the network traffic data over the network.

**Attack 5: Leftover files.** A restricted malicious application can also create a public file to record the captured network traffic data. Then, it can wait for the mobile device owner to uninstall and then reinstall the application, but without its previously granted permission to monitor the network traffic data. Therefore, the new version of the application can access the public file that persisted before its previous uninstallation and then send it to an external server (where there are no more restrictions).

C. *Out of scope*

The main goal of our work is to provide access and ensure
the proper use of network traffic data by applications, i.e.,
network traffic data not sent to an external server. We focus
on techniques to mitigate the misuse of network traffic data.
Since we consider the kernel to be trusted, we do not consider
privilege escalation attacks, in which an application will try
to get root access to have network traffic access. Additionally,
we do not consider covert channel attacks that use mediums
such as ultrasonic audio beacons, infrared, light, vibrations,
etc. [18, 26, 39, 41, 76, 77, 117, 122] or covert timing
channels [20, 40, 69, 72, 103] to extract data from mobile
devices or to communicate between applications without using
mOSes services. Such attacks involve two physical devices
communicating with each other, which is outside the scope of
our work. We rely on previous works to protect against such
attacks.

V. A NEW SECURITY PERMISSION — SANEM

SANEM is a new security class that takes the form of a
permission that can be granted to applications that require
to analyze the network traffic. As mentioned in Section IV,
access to the network traffic interface is not possible without
a trade-off and is subject to restrictions to prevent data leakage.
SANEM stems from the idea that restricting the application
network flow should not be a major burden. Accordingly, as
illustrated in Figure 2, SANEM is a twofold approach. Firstly,
SANEM provides a secure way to access the network traffic
data through a simple interface. Secondly, SANEM imposes
several restrictions on the application to avoid data leakage.

<figure><img src="image_3.png" /><figcaption>Fig. 2: SANEM actions on an application APP X.</figcaption></figure>

A. *Simple API to enable secure analysis of the network traffic*

By default, the network traffic from mobile devices is not
exposed to any application. Therefore, following the *challenge 1*, SANEM needs to find an easy mechanism to provide an
easy and secure way to access network traffic data.

To this end, SANEM introduces: (i) a shared memory
buffer in the kernel, denoted *shNetData* for shared network
data, and (ii) a component named *NET DATA RENDERER* to
synchronize the shared memory buffer with the underlying
network interface (see Figure 2). *shNetData* has a config-
urable size (16MB by default as most kernel ring buffer sizes
such as the *dmesg* ring buffer [85]). Applications that get
the SANEM permission will be able to map *shNetData* to
their address space with only READ rights (See Figure 3).
For each incoming and outgoing network packet, the kernel
through the *NET DATA RENDERER* updates *shNetData*. The
shared counters of the ring buffers between the kernel and the
SANEM application enable the tracking of produced (kernel)
and consumed (application) data on the ring.

Once SHNETDATA is mapped to userspace, the applications
can then periodically read the data pushed by the kernel
and leverage the data for their own purpose. To simplify the

SANEM secure network data access

<figure><img src="image_4.png" /><figcaption>Fig. 3: SANEM secure network traffic data access for an
application APP X</figcaption></figure>

integration process, we expose to applications a simple Java
API, which is a JNIf wrapper for two C functions:

*   `setShNetData(@addr)`: This function takes a block of
    memory in the application's address space at the `@addr`
    address and asks the kernel to map the `SHNETDATA`, so
    that the application can read its content.

*   `pollShNetData(@addr, period, callback, raw)`: This function takes the address of the mapped `shNetData`, periodically reads its content (using `period` as an interval), and calls the `callback` function with the read data as input. The `raw` parameter SANEM should push raw network packets or not to the shared buffer. This way, the application can easily leverage and process the network traffic data.

Our SHNETDATA+NET DATA RENDERER design is similar
to kernel libraries that expose packet buffers to user space
in desktop and server OSes [25, 70]. Similarly to tools
like tcpdump, SANEM exposes the network's incoming
and outgoing traffic without correlating the observed packets
to running applications. However, SANEM applications can
easily perform fingerprinting from packet headers to correlate
applications with network traces [2, 114, 119].

B. SANEM network restrictions

Granting the SANEM permission goes hand in hand
with restrictions regarding incoming and outgoing network
communications. These restrictions act as a barrier to prevent
applications requesting the SANEM permission from leaking
data to an external server. Following the *challenge 2*, the
perfect restriction would have been to ban all incoming and
outgoing messages to/from applications, resulting in total
isolation. Such isolation is undesirable as applications usually
need to update themselves (e.g., an internal component)
and/or receive push notifications from an external server.

**Analysis of applications' network needs.** We analyze the network messages exchanged to authorize applications' updates and push messages. For a push notification with TCP (with the

<footnote n="3">³Java Native Interface</footnote>
latest standard, RFC9293), once the SYN-ACK handshake is established, the external server can send a message to the application. For applications' updates, a download operation is involved, either the download of a new version of the application or an updated version of an internal component, e.g., a database. As shown in Figure 4, when a client downloads a file from a server with TCP:

1) The client and the server establish a connection by exchanging an empty packet (data length is 0) with SYN (client), ACK (server), and SYN-ACK (client) flags. This step is the same, followed by the application and the external server for push notifications. When sending the ACK, the packet header sequence number should be the sequence number received from the SYN packet +1. The header also contains information about a window size and maximum data segment sizes used by the TCP protocol during data transmission.

2) The server can then start sending the data (following the emission of an empty packet with the PSH flag). The client may send reset packets to resume an aborted transfer or the service (corresponding to an empty packet with the RST flag).

3) Then, the server sends an empty packet with the FIN flag to signal the end of the transmission.

Thus, the only outgoing messages for applications' updates are empty packets with the flags ACK, SYN-ACK, or RST.

<figure><img src="image_5.png" /><figcaption>Fig. 4: Overview of network messages exchanged between clients downloading files from a server.</figcaption></figure>

Overall, the key observation is that, for an application update and push notifications, applications mainly require incoming network access and outgoing access for empty packets with ACK, SYN-ACK, and RST flags.

1) SANEM *network filter*: Based on the aforementioned observations, when an application loads the SANEM permission, it is subject to several network restrictions, as shown in Figure 5. Firstly, it can receive network packets from the exterior. Secondly, during the TCP handshake phase, it can only send empty packets with the flags ACK, SYN-ACK, or RST. Note that even if we trust the kernel, which is

responsible for establishing handshakes, we are forced to impose restrictions since SANEM applications can try to mimic TCP handshake exchange messages to leak data. Lastly, once the TCP handshake is established, it cannot send outgoing packets (except for *hello* messages with a pre-shared key for TLS as described in Section V-B2). To prevent data leakage through storage covert channels [23, 30, 74, 126], we impose a constant window size and maximum segment size field in the headers of the allowed outgoing packets. Additionally, when receiving a *SYN*, the sequence number is saved and compared when the *ACK* sender sends the sequence number. The packet is dropped if the sequence number of the *ACK* packet is not the direct increment of the previously saved sequence number. The same logic follows with the acknowledgment number. Furthermore, the sequence number for the *SYN-ACK* is overwritten with a random value to prevent data leakage. However, we do not check the fields regarding source port, destination port, checksum, and urgent pointer; if these fields are altered to hide encoded sensitive data, it will hinder the transmission of the network packets. Packet headers filled with additional header data will be dropped. To prevent timing covert channels with external servers, SANEM imposes a random delay between 500ms and 1s between successive *SYN* or *SYN-ACK* messages. Concretely, when a *SYN* is transmitted, the next *SYN* request will see its processing time affected by a random delay. We chose the latter interval, but any other interval value can work depending on the target latency requirements. The delay only impacts the application's update operations but not its execution.

Concretely, when an application loads the SANEM permission, each call to the transmit handler of the network interface verifies if the content complies with the SANEM network policy. If the network operation parameters (header flags, payload size) do not comply with the SANEM policy, an exception is raised, and the operation is aborted. Thus, all applications operations can continue working without compromising the network traffic data exposed with SANEM. Note that, even with TLS/SSL (Section V-B2), from the network interface handler, we are still able to identify the TCP headers since they are not encrypted (compared to application protocol headers

<figure><img src="image_6.png" /><figcaption>Fig. 5: Overview of SANEM network outgoing check mechanism. Each outgoing network request goes through a compliant checker that allows or aborts the network request depending on its content and if it is in the process of a TCP handshake.</figcaption></figure>
— for example, HTTP headers) [84, 96].

Consequently, applications that require SANEM should
move from a *pull* to a *push* model to limit the impact of
restrictions on their network usage. For instance, instead of
pulling updates to a remote hub, applications should now
follow a push model. The remote hub will notify applications
that an update is available. Then, applications will trigger the
download of the update (since all incoming network messages
are allowed). Note that these restrictions are applied similarly
on both control and data channels of the protocols used.

2) *Special cases: UDP and TLS:* In this section, we discuss special cases regarding UDP and TLS consideration for SANEM.

**Handling UDP.** Since our restrictions rely on observations over TCP connection establishment, applications using UDP for updates and push notifications should move to *UDP over TCP* to comply with SANEM. This way, the changes to the application remain minimal since they concern the network transport layer. Otherwise, our network restrictions will block their updates/push notifications.

**Handling TLS.** An application could need to perform updates through a secure TLS connection. To allow such operations without providing a way to leak data, we rely on the 0-round trip resumption (0-RTT) handshake of TLS 1.3. Concretely, before an SANEM application could access network traffic (Section V-A), it must provide a list of pre-shared keys (PSK) established when performing TLS handshake with servers before asking for the SANEM permission. These PSKs are stored in a PSK store only accessible by the mOS kernel. Providing a list of PSKs forces application developers to get access to the PSKs to provide them for SANEM. However, it does not change the TLS handshake nor the application core workflow, making these changes light for application developers.

Thus, after a TCP handshake, as shown in Figure 6,
SANEM can allow *hello* messages with a valid PSK
(present in the PSK store) in the header used for 0-RTT
handshake. However, similar to the network restrictions in
Section V-B1, the *hello* messages should not contain any
additional data; otherwise, they will be dropped. With this
mechanism, SANEM can perform updates over TLS if the
application previously established a TLS connection with the
target server (before applying SANEM). Similarly to Section
V-B1, we impose a random delay between 500ms and 1s be-
tween successive allowed *hello* messages to prevent timing
covert channels that can leak data. This random delay will
also significantly lengthen attacks relying on the transmission
of "hello" to two or more servers to serve as 0 and 1 signals.
However, timing covert channels are complex to completely
mitigate and are out of the scope of SANEM (Section IV-C)
and we aim to rely on existing works. 0-RTT resumption is
only available with TLS 1.3, however, TLS 1.3 was supported
by up to 48% servers in 2020 [68] and to 63% in 2021 [123] of
web servers. Thus, relying on TLS 1.3 feature does not restrict
SANEM to a small set of web servers. Note that, since keys

renegotiation is impossible with TLS 1.3 [29], SANEM does
not handle such scenarios.

<figure><img src="image_7.png" /><figcaption>Fig. 6: Overview of SANEM network outgoing check mechanism to allow TLS 0-RTT resumption without risk of data leaking.</figcaption></figure>

SANEM network restrictions prohibit *Attack 1* (Section IV-B), as the network packets containing network traffic data do not match the allowed outgoing network packets pattern (empty packets with the flags *ACK*, *SYN* − *ACK*, or *RST*).

C. SANEM *ICC* restrictions.

An additional security layer of SANEM is the Inter Com-
ponent Communication (ICC) control. ICC allows applications
to exchange messages through interprocess communication
(IPC) [3, 24, 101]. An application loading the SANEM
can send messages regarding network traffic data to another
application that does not have the SANEM restrictions. To
avoid this scenario, we introduce an ICC control that checks
for SANEM applications if the recipient of an ICC message
loads the SANEM permission. If the recipient does not load
the SANEM permission, then ICC is impossible.With this
constraint, even if an application exchanges network traffic
data with another (with the SANEM permission), the network
traffic information cannot be sent to an external server since
both are subject to the same network restrictions. Therefore,
the network traffic data exposed to the application with
SANEM remains secure concerning our threat model.

SANEM does not prevent ICC of applications to con-
tent providers as SMS/contacts providers as they require the
user's collaboration since the application does not control the
corresponding activated activity. Thus, transmitting data to
an unprotected destination (e.g., SMS/contact) without users'
consent is impossible. Similarly, SANEM does not block ICC
to system services.

SANEM ICC restrictions prohibit *Attack 2* since ICC for SANEM applications is only possible with SANEM applications with network restrictions.

D. SANEM *public file policy*.

A restricted application can write sensitive data to a shared
storage the network traffic data obtained via SANEM, al-
lowing another unrestricted application to read the content
and leak data to an external server. To avoid this bypass of
restrictions, when loading the SANEM permission, all calls to
the file API for shared storage are prohibited. For example, in
Android, this corresponds to prohibiting the use of external and
shared storage by banning `MANAGED_EXTERNAL_STORAGE` permission. A direct consequence of this policy is that an application cannot leave files on the device after uninstallation since, by default, `mOSes` delete all applications' files except those created on shared storage. This policy does not reduce the application's data storage capacity since it can still use its private storage.

SANEM public file policy prohibits Attack 3 as a SANEM application cannot create public files and shared storage with another application. Additionally, in September 2019, the release of Android API level 29 (Android 10) deprecated the possibility of sharing an application identifier, which could allow an application to get access to other applications' private files [27]. Thus, if the SANEM public file policy is applied, there is no way to use the filesystem to share network traffic data with another application. Furthermore, SANEM public file policy prohibits Attack 4 since no files can be left on the device at uninstallation.

Overall, SANEM ICC restrictions and public file policy address *challenge 3* related to network traffic data leakage to another unrestricted application.

## E. SANEM usage

Coupled with the network restrictions and access to network traffic data, SANEM comes with a specific usage that enforces the security of network traffic data concerning our threat model. The usage specification is the *unability to unload the SANEM* on an application when it has already been loaded. This prevents the mobile device holder from (un)intentionally removing the SANEM permission on an application that could already have stored network traffic data. Removing the permission would lift the application's various restrictions and allow the transmission of network traffic data over the network. Thus, imposing this specific usage restriction is strictly necessary to solve the *challenge 4* and prohibits Attack 5 to avoid unloading the restrictions after getting network traffic data.

## F. SANEM security proof.

To prove that SANEM does not leak the exposed network traffic data with respect to our threat model, we represent SANEM capabilities using propositional logic and model the different potential attacks a malicious application can perform (described in Section IV). To fully express our security model, let us consider the following logic propositions (related to SANEM security restrictions) about an application APP:

(P): App has SANEM

(Q): App accepts incoming network packets

(R): App allows outgoing network packets

(S): The outgoing packet is an empty packet

(T): The outgoing packet has the RST header flag

(U): The outgoing packet has the SYN header flag

(V): The outgoing packet has the SYN-ACK header flag

(W): SANEM App has access to network traffic data

(X): The target application for ICC has the SANEM

(Y): SANEM App can perform ICC

(Z): App can send and receive incoming network traffic

(ZA): App can save network traffic to files

(ZB): All App related files are deleted after uninstallation

(ZC): App possess no files with sensitive network traffic data

(ZD): App can create a public file

(ZE): SANEM App can share a file with another application

(ZF): SANEM can be unloaded on App

With the previous propositions, we can define the correlation with respect to SANEM properties :

(1) $P \wedge X \to Y$ (ICC allowed between SANEM apps)

(2) $P \wedge \neg X \to \neg Y$ (ICC not allowed between SANEM and non SANEM apps)

(3) $P \wedge \neg S \to \neg R$ (Outgoing network message of non-empty packets banned for SANEM apps)

(4) $P \to Q$

(5) $P \wedge S \wedge (T \vee U \vee V) \to R$ (SANEM apps allow outgoing network message for empty packets with RST or SYN/SYN-ACK headers)

(6) $P \to W$

(7) $P \to ZA$

(8) $P \to ZB$

(9) $ZB \to ZC$

(10) $ZC \to \neg W$

(11) $P \to \neg ZD$

(12) $\neg ZD \to \neg ZE$

(13) $P \to \neg ZF$

With the different correlations, we prove that SANEM mitigates every possible malicious application attack.

**Attack 1 mitigation proof:** It consists in showing that $\neg R$ is true. From the statement, we see that the application has SANEM, and thus $P$ is true. Additionally, applications want to send network traffic data. Thus, the network packets are not empty, meaning $\neg S$. Using the rule (4): $P \wedge \neg S \to \neg R$, we can conclude $\neg R$. Thus, if an application has the SANEM it cannot send network traffic data to the exterior.

**Attack 2 mitigation proof:** It consists of showing that $\neg Y$ is true, knowing $P$ is true. From the statement, the application has SANEM ($P$ is true) and wants to perform an ICC on a non-SANEM application ($\neg X$). From the rule (2): $P \wedge \neg X \to \neg Y$, we can conclude that $\neg Y$ is true. Thus, with SANEM ICC restrictions, an application cannot send the network traffic data to another unrestricted application that will send the data to an external server.

**Attack 3 mitigation proof:** It consists of showing that $\neg ZE$ is true, knowing $P$ is true. From rule (11) $P \to \neg ZD$, $\neg ZD$ is true. Then, applying rule (12) $\neg ZD \to \neg ZE$, we can conclude that $\neg ZE$ is true. Thus, an application with SANEM cannot use public files to share network traffic data with an unrestricted application.

**Attack 4 mitigation proof:** It consists of showing that $\neg ZF$ is true, knowing $P$ is true. From rule (13) $P \to \neg ZF$, concluding that $\neg ZF$ is true. Thus, since SANEM prohibits unloading it
once it is applied, an application cannot unload it to lift its restrictions and transmit retrieved network traffic data over the network.

**Attack 5 mitigation proof:** Similarly to the previous two proofs, *P* is true, and we want to show that $¬W$ is true. Since *P* is true, by rule (8): $P → ZB$, $ZB$ is true. If we apply rules (9) and (10): we get $ZB → ZC → ¬W$, showing that $¬W$ is true. Thus, SANEM prevents an application from exploiting leftover files over uninstallation since, due to the public file policy, no application-related file remains on the device after uninstallation.

Overall, we show that SANEM complies with our threat model and prevents several attack scenarios that want to expose the sensitive network traffic data.

## VI. EVALUATIONS

**Goal and methodology.** Our evaluation has several goals. The first is to break down SANEM internals cost. The second is to assess the overhead introduced by SANEM on a real mobile device and compare it against a local VPN approach, PrivacyGuard [107]. PrivacyGuard is an open-source on-device VPN-based platform for intercepting the network traffic of applications to detect the leakage of multiple types of sensitive data, such as a phone's IMEI number or location data. It leverages the VPNService class provided by the Android SDK. Concretely, we compare the overhead that SANEM and PrivacyGuard impose on an NTA application's performance and evaluate each approach's scalability. We chose PrivacyGuard as the local VPN approach since the code is publicly available, we managed to successfully port it to work with the Android version we used for our SANEM prototype. For fairness, we use PrivacyGuard in their no-filter mode, i.e., just capturing network packets without any additional processing.

We modify two NTA applications, TrackerControl [62] and PCAPdroid [34]. TrackerControl aims to identify and report applications that send personal data over the Internet and alert users to potentially dangerous websites. TrackerControl uses the Android VPN by default to capture incoming and outgoing network traffic details. In its free version, PCAPdroid is similar to TrackerControl, as it aims to track and analyze connections established by applications on mobile devices. Both applications leverage the local VPN approach to capture network traffic. We modify them to use the PrivacyGuard mechanism on the one hand and SANEM on the other hand to get network traffic details. Both NTA applications are entirely functional with SANEM. All the reported results are the average of 10 runs of the experiment. We perform 10 runs as they are enough to provide us 95% confidence intervals $≤ 2\%$ for our experiments.

**Testbed.** Our testbed is a rooted Samsung Galaxy S20 with 8GB of memory and 128 GB of disk storage. Our S20 mobile device has an Exynos 990 chipset with a Cortex-A76 CPU and 4x2.0 GHz Cortex-A55, and a ARM Mali-G77 MP11 GPU.

**Prototype details.** Our prototype of SANEM consists of two parts. The first part concerns kernel changes to introduce SANEM restrictions and system calls for initiating

the shared memory. SANEM ICC restrictions are performed by modifying the Android kernel's Binder to block ICC between a SANEM app and a non-SANEM app. SANEM network filter implementations are performed in the network transmission pipeline of the Android kernel before the call to the network card driver. The second part is a user-level API that supports applications willing to initialize the shared memory and poll over the content. We introduce SANEM in Android 14 (android14-6.1 kernel) with 1409 LOCs, and the user-level API has 621 LOCs<fnref n="4" />.

We introduce 42 LOCs to TrackerControl to use SANEM and 38 LOCs for PrivacyGuard, and 58 LOCs to PCAPdroid to use SANEM and 47 LOCs for PrivacyGuard. The difference in the LOCs for both applications for PrivacyGuard is due to a different number of code sections where the network data is required from the PrivacyGuard wrapper.

### A. Breakdown of SANEM overhead

To evaluate SANEM overhead, we consider a scenario where a NTA application updates its viral URLs database from a server on the same wireless network. The sizes of the downloaded database are fixed for each experiment and vary from 25MB to 100MB. We measure the throughput and mean latency of the NTA application download operations when the NTA application loads SANEM and when it does not (no restrictions). Since SANEM performs several checks regarding an application network activity, we focus on measuring the overhead of SANEM on the network performance. We also measure the CPU time required by the kernel to set up the SANEM restrictions and initialize the shared memory. We repeat the experiment with varying sizes of the shared memory from 4MB to 256MB used by the SANEM mechanism. We consider the two NTA applications: TrackerControl and PCAPdroid.

<table><caption>TABLE I: SANEM restrictions average initialization times breakdown (ICC, network, and shared memory set up).</caption><thead><tr><th>Shared mem to set up</th><th>Network (µs)</th><th>ICC (µs)</th><th>Shared (µs)</th><th>Total (µs)</th></tr></thead><tbody><tr><td>4 MB</td><td>49</td><td>51</td><td>256</td><td>356</td></tr><tr><td>16 MB</td><td>49</td><td>51</td><td>259</td><td>359</td></tr><tr><td>64 MB</td><td>49</td><td>51</td><td>293</td><td>393</td></tr><tr><td>256 MB</td><td>49</td><td>51</td><td>359</td><td>459</td></tr></tbody></table>

**Cost of initializing the restrictions.** Table I shows the breakdown of the time required to initialize SANEM restrictions into the time to initialize network restrictions, ICC, and the shared memory. We only report the results for TrackerControl as the results with PCAPdroid are similar. Setting up the ICC restrictions is straightforward since it corresponds to adding the application's UID to a global array, which is scanned before launching an ICC operation to check whether it should be performed. Thus, it takes a relatively short time, on average, 49µs compared to the other operations and independently of the shared memory size. The same mechanisms (global array

<footnote n="4">⁴We use sloccount [124] to compute the LOCs</footnote>
<table><caption>TABLE II: Download time and throughput for TrackerControl when it loads SANEM compared to when it does not per file sizes.</caption><thead><tr><th>File size</th><th>25MB</th><th>50MB</th><th>75MB</th><th>100MB</th></tr></thead><tbody><tr><th colspan="5">Download time (ms) - lower is better</th></tr><tr><td>SANEM (ours)</td><td>181</td><td>193</td><td>215</td><td>232</td></tr><tr><td>no-SANEM</td><td>173</td><td>183</td><td>204</td><td>221</td></tr><tr><th colspan="5">Throughput (MB/s) - higher is better</th></tr><tr><td>SANEM (ours)</td><td>81.1</td><td>81.7</td><td>81.4</td><td>81.2</td></tr><tr><td>no-SANEM</td><td>83.6</td><td>84.3</td><td>83.9</td><td>83.7</td></tr></tbody></table>

<table><caption>TABLE III: Download time and throughput for PCAPdroid when it loads SANEM compared to when it does.</caption><thead><tr><th>File size</th><th>25MB</th><th>50MB</th><th>75MB</th><th>100MB</th></tr></thead><tbody><tr><th colspan="5">Download time (ms) - lower is better</th></tr><tr><td>SANEM (ours)</td><td>179</td><td>190</td><td>214</td><td>233</td></tr><tr><td>no-SANEM</td><td>170</td><td>181</td><td>201</td><td>218</td></tr><tr><th colspan="5">Throughput (MB/s) - higher is better</th></tr><tr><td>SANEM (ours)</td><td>79.1</td><td>80.1</td><td>80.2</td><td>80.3</td></tr><tr><td>no-SANEM</td><td>82.7</td><td>83.8</td><td>82.3</td><td>82.1</td></tr></tbody></table>

with applications identifiers) apply to the network filters at the mOS network transmit and receive handlers. Adding an entry to this global array also takes 51µs, on average. The longest operation is setting up the shared memory needs to be initialized by the kernel, and the reference sent in userspace and mapped. Its completion time ranges from 256µs to 359µs, thus taking 72% to 78% in our experiments' total restriction initialization time. The shared memory initialization time is relatively constant since it consists of passing references regarding the start and the end of the shared virtual address space for mapping to the user space.

**Network impact on the application loading SANEM.** Table II and III report the download time and throughput with and without SANEM for TrackerControl and PCAPdroid, respectively. For TrackerControl, the overhead incurred by SANEM reaches 5.6% regarding the download time and 4.2% regarding network throughput. For PCAPdroid, the overhead incurred by SANEM reaches 5.2% regarding download time and 3.8% regarding network throughput. The main overhead source comes from the checks performed for each outgoing packet. However, SANEM overhead on network operations is less than 6%.

## B. SANEM vs. local VPN approach

We consider the scenario where one application wants to perform NTA to protect the device and uses either SANEM or either a local VPN approach. The local VPN approach runs on the vanilla Android kernel. We consider only one application using SANEM to perform NTA as users usually have one security product, and it is not recommended to have more than one [10, 55, 83]. We assess the overhead of both solutions on system resources and other applications as we increase the device's network activity. We consider the two NTA applications, TrackerControl and PCAPdroid.

<table><caption>TABLE IV: Memory and CPU overhead ratio of SANEM and PrivacyGuard on TrackerControl with respect to the baseline (neither SANEM nor PrivacyGuard) for different numbers of network background applications running.</caption><thead><tr><th>Colocated apps</th><th>10</th><th>20</th><th>30</th><th>40</th></tr></thead><tbody><tr><th colspan="5">Memory overhead ratio - lower is better</th></tr><tr><td>SANEM (ours)</td><td>1.12</td><td>1.13</td><td>1.13</td><td>1.13</td></tr><tr><td>PRIVACYGUARD</td><td>1.4</td><td>1.54</td><td>1.63</td><td>1.83</td></tr><tr><th colspan="5">CPU overhead ratio - lower is better</th></tr><tr><td>SANEM (ours)</td><td>1.1</td><td>1.14</td><td>1.22</td><td>1.3</td></tr><tr><td>PRIVACYGUARD</td><td>1.34</td><td>1.42</td><td>1.5</td><td>1.57</td></tr></tbody></table>

<table><caption>TABLE V: Memory and CPU overhead ratio of SANEM and PrivacyGuard on PCAPdroid with respect to the baseline (neither SANEM nor PrivacyGuard) for different numbers of network background applications running.</caption><thead><tr><th>Colocated apps</th><th>10</th><th>20</th><th>30</th><th>40</th></tr></thead><tbody><tr><th colspan="5">Memory overhead ratio - lower is better</th></tr><tr><td>SANEM (ours)</td><td>1.13</td><td>1.14</td><td>1.14</td><td>1.14</td></tr><tr><td>PRIVACYGUARD</td><td>1.52</td><td>1.5</td><td>1.6</td><td>1.79</td></tr><tr><th colspan="5">CPU overhead ratio - lower is better</th></tr><tr><td>SANEM (ours)</td><td>1.1</td><td>1.13</td><td>1.2</td><td>1.27</td></tr><tr><td>PRIVACYGUARD</td><td>1.36</td><td>1.44</td><td>1.49</td><td>1.6</td></tr></tbody></table>

**CPU overhead.** We perform the following experiment to assess the CPU overhead introduced by SANEM. We consider the two modes of TrackerControl and PCAPdroid (SANEM and PrivacyGuard). In both modes, the detection precision of TrackerControl remains the same. We run several simple network background applications on the device to generate a network load. Each background application generates network traffic with a throughput 25MB/s to a server on the network. The number of background applications ranges from 10 (250MB/s network load) to 40 (1GB/s network load). We measure the overall CPU usage incurred by our NTA applications with SANEM and PrivacyGuard. Our baseline is the CPU usage when our network traffic monitoring application does not run. Table IV and V present the CPU usage concerning our baseline as we increase the number of colocated applications that generate a network load for TrackerControl and PCAPdroid, respectively. For both NTA applications, we observe that SANEM incurs 1.1× (28% CPU usage) to 1.3× (59% CPU usage) overhead compared to baseline. In contrast, PrivacyGuard incurs up to 1.6× (75% CPU usage) (the CPU usage is the average usage across cores). This is because SANEM is a kernel-level solution; it incurs fewer kernel-user context switches to retrieve network traffic data than an entire user-level approach (PrivacyGuard). Additionally, SANEM uses shared memory that does not require memory copy from the kernel space to the userspace, while PrivacyGuard requires memory copy, which adds the burden on the CPU. Overall, SANEM exerts less stress on CPU resources than PrivacyGuard.
<table><caption>TABLE VI: Download time and throughput overhead for an application when TrackerControl runs with SANEM or PrivacyGuard with respect to the baseline (neither SANEM nor PrivacyGuard).</caption><thead><tr><th>File size</th><th>25MB</th><th>50MB</th><th>75MB</th><th>100MB</th></tr></thead><tbody><tr><th colspan="5">Download overhead (%) - lower is better</th></tr><tr><td>SANEM (ours)</td><td>1.3</td><td>1.4</td><td>1.22</td><td>1.18</td></tr><tr><td>PRIVACYGUARD</td><td>5.1</td><td>5.3</td><td>5.2</td><td>5.1</td></tr><tr><th colspan="5">Throughput overhead (%) - lower is better</th></tr><tr><td>SANEM (ours)</td><td>2.2</td><td>2.19</td><td>2</td><td>2.1</td></tr><tr><td>PRIVACYGUARD</td><td>10.4</td><td>10.8</td><td>10.5</td><td>10.6</td></tr></tbody></table>

**Memory overhead.** We perform the following experiment to understand the memory stress introduced by SANEM. We repeat the scenario of 10 and measure the memory usage instead of the CPU usage. Table IV and V also report the memory with respect to the baseline (no SANEM and no PrivacyGuard) for TrackerControl and PCAPdroid, respectively. For both NTA applications, memory overhead with SANEM is 1.1× (92MB additional memory) to 1.13× (up to 118MB additional memory for 40 colocated apps) compared to baseline and up to 1.83× (up to 168MB additional memory for 40 colocated apps) with PrivacyGuard.

**Network impact on other applications.** We performed the following experiment to evaluate the impact of SANEM on other network applications. We repeat the same experiment as 10 with one running network application, which is our experiment target. The network application downloads files of different sizes. We record the download speed and throughput overhead incurred on our target application when TrackerControl runs with SANEM and PrivacyGuard with respect to the baseline (neither SANEM nor PrivacyGuard). Due to space constraints, we only show the results for TrackerControl and discuss PCAPdroid in the text. Table VI report download speed and throughput for TrackerControl. For both NTA applications, the overhead incurred with SANEM is up to 1.4% compared to 5.3% with PrivacyGuard for the download time and up to 2.2% with SANEM compared to 10.8% with PrivacyGuard. SANEM incurs less overhead due to the shared memory mechanism and fewer copies between different memory address spaces in PrivacyGuard.

## VII. ADOPTION DISCUSSION AND FUTURE WORK

**Adoption discussion.** An application should follow a modularization logic to leverage the network data with SANEM to perform NTA. Concretely, an application may want to perform several other operations apart from NTA, which could be prohibited by SANEM restrictions, e.g., enabling user payments. In this case, the target application should be split into two separate applications. The first performs NTA with SANEM, and the second does not load SANEM and is restriction-free. This enables applications to implement NTA with SANEM without sacrificing other functionalities that could be hindered by SANEM restrictions. Applications such

as viruses already apply this modularization logic since they separate some of their features into independent products. For example, the *Parental Control* of viruses usually comes as a separate distinct application. Consequently, SANEM adoption does not break the development logic of our target applications, such as viruses. Applications that perform NTA by relying on external databases and computation, such as cloud-based antivirus that relies on a viral database, can also adopt SANEM. Concretely, they can switch to on-device processing with an internal database and regularly update the latter through push notifications, which are allowed by SANEM (Section V-B). For example, NTA applications such as IDS/IPS typically rely on specialized rulesets maintained by third parties such as Suricata [113] with Proofpoint ET [89] and Talos [106]. Thus, they can easily adopt SANEM to perform NTA since they can update the rulesets whenever necessary. Regarding portability, SANEM, being a system level approach, can be easily ported to iOS since we only rely on ring buffers, IPC tracking, and file management, which are not specific to Android. Furthermore, Android and iOS have the same permission model, and they are Unix-based, which will further facilitate SANEM implementation in iOS. Finally, even though SANEM requires changes to legacy mOSes. However, we believe such research work can be introduced to legacy mOSes code, such as fine-grained permissions [19, 21, 51, 52, 130] that are now implemented in legacy mOSes.

**Future work.** The key challenge behind using SANEM is the restriction on the application loading it. For example, an NTA application loading SANEM cannot communicate its findings to the exterior, which hinders collaborative protection models [66, 78]. We intend to improve its design to make it less restrictive without comprising security with respect to our threat model, to ease its adoption by mainstream applications. We also envision exploring the use of mechanisms such as eBPF, that alleviate the need for modifying legacy kernels. In our current prototype, we do not use eBPF for the implementation of SANEM since its support in Android is still in progress [32]. However, as eBPF support grows, it can become a viable alternative for SANEM implementation.

## VIII. RELATED WORK

We separate the related work into four parts: ICC flaws, permission auditing techniques, malware dynamic analysis, and information flow control.

**ICC flaws.** Several works [1, 3, 101] highlight several ICC flaws due to the lack of consistent mechanisms to document message types, very limited checking that a message conforms to its specifications, the inability to declare dependencies on other modules explicitly, and the lack of checks for backward compatibility as message types evolve over time. To cope with ICC flaws, some research tools such as DINA [24], IccTA [31], or COVERT [17] propose lightweight formal analysis to identify malicious IAC behaviors hidden within dynamically loaded code through reflective/DCL calls. SANEM is not affected by known ICC flaws since it prohibits ICC between a
SANEM application and a non-SANEM application to avoid network data leakage.

**Permission auditing.** SANEM relies on establishing a specific permission that will apply restrictions on applications. Permissions, however, can be sources of flaws when used in a specific way. To this end, several works audit permissions in mOSes [35, 71, 87, 97, 99, 119] to build comprehensive models around permission and highlight design flaws. The SANEM permission does not rely on other permissions and, therefore, cannot be affected by a flaw originating from a faulty permission.

**Dynamic analysis for malware detection.** Static analysis is no longer sufficient to detect malware on mobile devices. Malwares can obfuscate their code and run malicious programs at run-time bypassing static analyzers. For example, several works show how programs exploit updates to load malware behaviors [47, 53, 71, 112, 116, 127, 132] and leverage android modules to load malware programs [28]. As a result, several approaches have emerged to propose dynamic malware analysis that relies on KNN classifiers [131], random forest [58], keyword correlation in API calls [33], or execution traces [88, 90, 133]. However, dynamic analysis techniques require root access on devices which is not always possible for users. SANEM does not require root access to provide access to application network traces that can be analyzed to detect stalkerwares, for example.

**Information flow control (IFC).** SANEM goal is to provide network traffic data to untrusted applications while preventing its misuse. The model is similar to that of IFC systems. IFC is an approach to security that allows application writers to control how data flows between pieces of an application and the outside world [81, 82]. In general, with IFC systems, applications are viewed as two parts a trusted and an untrusted part that runs in a sandbox [31, 65, 79, 98, 115] or use cryptography techniques to secure data from the untrusted as DStar [129]. IFC systems such as FlowFence [36] also require applications to declare their data usage flow beforehand to block unregistered patterns and usually come with specific runtimes to express the data flows [128].

SANEM does not use sandboxing since we do not want to intercept and monitor every action carried out by the application. There is only a filter on the network path of the application. Other sets of functionalities are blocked, and there is no need for prior knowledge of applications' data flows. A direct consequence is that SANEM is transparent to applications and does not need to require codebase changes to applications, as for other sandboxing solutions [12]. Additionally, compared to IFC sandboxing approaches, we do not incur overhead on the target application.

**DNS filtering offered by commercial VPNs.** Some commercial VPNs propose to filter out a list of malicious servers to secure the browsing experience of users. Mobile device manufacturers sometimes propose their commercial VPN with equivalent features, such as Google One introduced with the Google Pixel 7 lineup [42]. However, some studies showed that commercial VPNs should not be fully trusted regarding user

privacy [60]. Additionally, more than just filtering malicious servers is required, as applications can still communicate sensitive user details with servers that are not filtered out. SANEM does not need to maintain a list of trusted servers as its restrictions protect users' network information from being sent to an external server.

# IX. CONCLUSION

In this work, we present SANEM, an mOS permission that allows NTA applications to have access to the network traffic data. To ensure that the network traffic data is not misused (sent to an external server), SANEM comes with additional restrictions regarding network, IPC/ICC, and public file usage. Further, we demonstrated that compared to non-secure VPN approaches, SANEM incurs less overhead, lower memory footprint, and better scalability. In addition, SANEM allows for secure analysis of network traffic data, giving the user confidence in the use of the captured network traces. Our approach enforces security at the system level. It no longer relies on the will of the developer, who can no longer leak captured data. NTA becomes more secure with our approach than with traditional fake VPN techniques.

# X. ACKNOWLEDGMENTS

We thank the anonymous reviewers for their insightful comments. This work was supported by Rennes Métropole (Program "Allocation d'installation scientifique", AIS, Rennes, France), along with the French ANR project sGOV (ANR-23-CE25-0007-01).

# REFERENCES

[1] W. Ahmad, C. Kästner, J. Sunshine, and J. Aldrich, "Inter-app communication in android: Developer challenges," in *2016 IEEE/ACM 13th Working Conference on Mining Software Repositories (MSR)*, 2016, pp. 177–188.

[2] H. F. Alan and J. Kaur, "Can android applications be identified using only tcp/ip headers of their launch time traffic?" in *Proceedings of the 9th ACM Conference on Security & Privacy in Wireless and Mobile Networks*, ser. WiSec '16. New York, NY, USA: Association for Computing Machinery, 2016, p. 61–66. [Online]. Available: https://doi.org/10.1145/2939918.2939929

[3] M. Alhanahnah, Q. Yan, H. Bagheri, H. Zhou, Y. Tsutano, W. Srisa-An, and X. Luo, "Dina: Detecting hidden android inter-app communication in dynamic loaded code," *IEEE Transactions on Information Forensics and Security*, vol. 15, pp. 2782–2797, 2020.

[4] Android, "Overview of shared storage," 2020, https://developer.android.com/training/data-storage/shared.

[5] Android, "Use interprocess communication," 2020, http s://developer.android.com/training/articles/security-tips. html#IPC.

[6] Android, "Access app-specific files," 2022, https://developer.android.com/training/data-storage/app-specific.
[7] Android, “Permissions on android,” 2022, https://device.loper.android.com/guide/topics/permissions/overview.

[8] Android, “Vpn service documentation,” 2022, https://developer.android.com/reference/android/net/VpnService.html.

[9] E. Armageddon, “When technology takes hostages: The rise of ‘stalkerware’,” *Vice: Motherboard*, 2017.

[10] Asus, “The impact of installing multiple antivirus programs on the system,” https://www.asus.com/us/support/faq/1053660/.

[11] M. Backes, S. Bugiel, E. Derr, P. D. McDaniel, D. Octeau, and S. Weisgerber, “On demystifying the android application framework: Re-visiting android permission specification analysis,” in *25th USENIX Security Symposium, USENIX Security 16, Austin, TX, USA, August 10-12, 2016*, T. Holz and S. Savage, Eds. USENIX Association, 2016, pp. 1101–1118.

[12] M. Backes, S. Bugiel, C. Hammer, O. Schranz, and P. von Styp-Rekowsky, “Boxify: Full-fledged app sandboxing for stock android,” in *24th USENIX Security Symposium (USENIX Security 15)*. Washington, D.C.: USENIX Association, Aug. 2015, pp. 691–706. [Online]. Available: https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/backes

[13] H. Bagheri, J. Garcia, A. Sadeghi, S. Malek, and N. Medvidovic, “Software architectural principles in contemporary mobile software: from conception to practice,” *Journal of Systems and Software*, vol. 119, pp. 31–44, 2016. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0164121216300607

[14] H. Balakrishnan, S. Seshan, E. Amir, and R. H. Katz, “Improving tcp/ip performance over wireless networks,” in *Proceedings of the 1st annual international conference on Mobile computing and networking*, 1995, pp. 2–11.

[15] C. Baraniuk, “The rise of stalkerware,” *New Scientist*, vol. 244, no. 3257, pp. 20–21, 2019. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0262407919322079

[16] S. M. Bellovin, “Security problems in the tcp/ip protocol suite,” *ACM SIGCOMM Computer Communication Review*, vol. 19, no. 2, pp. 32–48, 1989.

[17] S. Bhandari, W. B. Jaballah, V. Jain, V. Laxmi, A. Zemmari, M. S. Gaur, M. Mosbah, and M. Conti, “Android inter-app communication threats and detection techniques,” *Computers and Security*, vol. 70, pp. 392–421, 2017. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0167404817301414

[18] K. Block, S. Narain, and G. Noubir, “An autonomic and permissionless android covert channel,” in *Proceedings of the 10th ACM Conference on Security and Privacy in Wireless and Mobile Networks*, ser. WiSec ’17. New York, NY, USA: Association for Computing Machinery, 2017, p. 184–194. [Online]. Available: https://doi.org/10.1145/3098243.3098250

[19] S. Bugiel, S. Heuser, and A.-R. Sadeghi, “Flexible

and fine-grained mandatory access control on android for diverse security and privacy policies,” in *22nd USENIX Security Symposium (USENIX Security 13)*. Washington, D.C.: USENIX Association, Aug. 2013, pp. 131–146. [Online]. Available: https://www.usenix.org/conference/usenixsecurity13/technical-sessions/presentation/bugiel

[20] S. Cabuk, C. E. Brodley, and C. Shields, “Ip covert timing channels: Design and detection,” in *Proceedings of the 11th ACM Conference on Computer and Communications Security*, ser. CCS ’04. New York, NY, USA: Association for Computing Machinery, 2004, p. 178–187. [Online]. Available: https://doi.org/10.1145/1030083.1030108

[21] M. Conti, B. Crispo, E. Fernandes, and Y. Zhauniarovich, “Crêpe: A system for enforcing fine-grained context-related policies on android,” *IEEE Transactions on Information Forensics and Security*, vol. 7, no. 5, pp. 1426–1438, 2012.

[22] J. Cox, “Meet flexispy, the company getting rich selling ‘stalkerware’ to jealous lovers,” 2017.

[23] D. M. Dakhane and P. R. Deshmukh, “Active warden for tcp sequence number base covert channel,” in *2015 International Conference on Pervasive Computing (ICPC)*. IEEE, 2015, pp. 1–5.

[24] B. F. Demissie, D. Ghio, M. Ceccato, and A. Avancini, “Identifying android inter app communication vulnerabilities using static and dynamic analysis,” in *Proceedings of the International Conference on Mobile Software Engineering and Systems*, ser. MOBILESoft ’16. New York, NY, USA: Association for Computing Machinery, 2016, p. 255–266. [Online]. Available: https://doi.org/10.1145/2897073.2897082

[25] L. Deri et al., “Improving passive packet capture: Beyond device polling,” in *Proceedings of SANE*, vol. 2004. Amsterdam, Netherlands, 2004, pp. 85–93.

[26] L. Deshotels, “Inaudible sound as a covert channel in mobile devices,” in *8th USENIX Workshop on Offensive Technologies (WOOT 14)*. San Diego, CA: USENIX Association, Aug. 2014. [Online]. Available: https://www.usenix.org/conference/woot14/workshop-program/presentation/deshotels

[27] G. Developers, “Documentation - <manifest>,” https://developer.android.com/guide/topics/manifest/manifest-element, 2022.

[28] M. Diamantaris, E. P. Papadopoulos, E. P. Markatos, S. Ioannidis, and J. Polakis, *REAPER: Real-Time App Analysis for Augmenting the Android Permission System*. New York, NY, USA: Association for Computing Machinery, 2019, p. 37–48. [Online]. Available: https://doi.org/10.1145/3292006.3300027

[29] M. E. Rescorla, “The transport layer security (tls) protocol version 1.3,” https://datatracker.ietf.org/doc/html/rfc8446.

[30] M. A. Elsadig and Y. A. Fadlalla, “Survey on covert storage channel in computer network protocols: detec-
tion and mitigation techniques,” *International Journal of Advances in Computer Networks and Its Security*, vol. 6, no. 3, pp. 11–17, 2016.

[31] W. Enck, P. Gilbert, S. Han, V. Tendulkar, B.-G. Chun, L. P. Cox, J. Jung, P. McDaniel, and A. N. Sheth, “Taintdroid: An information-flow tracking system for realtime privacy monitoring on smartphones,” *ACM Trans. Comput. Syst.*, vol. 32, no. 2, jun 2014. [Online]. Available: https://doi.org/10.1145/2619091

[32] Eunomia, “ebpf tutorial by example: Using ebpf programs on android,” https://eunomia.dev/en/tutorials/22-android/.

[33] L. Falsina, Y. Fratantonio, S. Zanero, C. Kruegel, G. Vigna, and F. Maggi, “Grab ’n run: Secure and practical dynamic code loading for android applications,” in *Proceedings of the 31st Annual Computer Security Applications Conference*, ser. ACSAC 2015. New York, NY, USA: Association for Computing Machinery, 2015, p. 201–210. [Online]. Available: https://doi.org/10.1145/2818000.2818042

[34] E. Faranda, “Pcapdroid,” https://github.com/emanuele-f/PCAPdroid.

[35] A. P. Felt, H. J. Wang, A. Moshchuk, S. Hanna, and E. Chin, “Permission Re-Delegation: Attacks and defenses,” in *20th USENIX Security Symposium (USENIX Security 11)*. San Francisco, CA: USENIX Association, Aug. 2011. [Online]. Available: https://www.usenix.org/conference/usenixsecurity11/permission-re-delegation-attacks-and-defenses

[36] E. Fernandes, J. Paupore, A. Rahmati, D. Simionato, M. Conti, and A. Prakash, “FlowFence: Practical data protection for emerging IoT application frameworks,” in *25th USENIX Security Symposium (USENIX Security 16)*. Austin, TX: USENIX Association, Aug. 2016, pp. 531–548. [Online]. Available: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/fernandes

[37] L. Franceschi-Bicchierai and J. Cox, “Inside the ‘stalker-ware’ surveillance market, where ordinary people tap each other’s phones,” *Vice: Motherboard*, 2017.

[38] E. Galperin, “The state of the stalkerware,” 2020.

[39] M. Gao, F. Lin, W. Xu, M. Nuermaimaiti, J. Han, W. Xu, and K. Ren, “Deaf-aid: Mobile iot communication exploiting stealthy speaker-to-gyroscope channel,” in *Proceedings of the 26th Annual International Conference on Mobile Computing and Networking*, ser. MobiCom ’20. New York, NY, USA: Association for Computing Machinery, 2020. [Online]. Available: https://doi.org/10.1145/3372224.3419210

[40] S. Gianvecchio, H. Wang, D. Wijesekera, and S. Jajodia, “Model-based covert timing channels: Automated modeling and evasion,” in *Recent Advances in Intrusion Detection*, R. Lippmann, E. Kirda, and A. Trachtenberg, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2008, pp. 211–230.

[41] I. Giechaskiel and K. Rasmussen, “Taxonomy and chal-

lenges of out-of-band signal injection attacks and defenses,” *IEEE Communications Surveys and Tutorials*, vol. 22, no. 1, pp. 645–670, 2020.

[42] Google, “Google one,” 2022, https://one.google.com/a bout.

[43] Y. Han, K. A. Roundy, and A. Tamersoy, “Towards stalkerware detection with precise warnings,” in *Annual Computer Security Applications Conference*, ser. ACSAC. New York, NY, USA: Association for Computing Machinery, 2021, p. 957–969. [Online]. Available: https://doi.org/10.1145/3485832.3485901

[44] M. Henze, D. Kerpen, J. Hiller, M. Eggert, D. Hellmanns, E. Mühmer, O. Renuli, H. Maier, C. Stüble, R. Häußling, and K. Wehrle, “Towards transparent information on individual cloud service usage,” in *2016 IEEE International Conference on Cloud Computing Technology and Science (CloudCom)*, 2016, pp. 366–370.

[45] M. Henze, J. Pennekamp, D. Hellmanns, E. Mühmer, J. H. Ziegeldorf, A. Drichel, and K. Wehrle, “Cloudanalyzer: Uncovering the cloud usage of mobile apps,” in *Proceedings of the 14th EAI International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services*, ser. MobiQuitous 2017. New York, NY, USA: Association for Computing Machinery, 2017, p. 262–271. [Online]. Available: https://doi.org/10.1145/3144457.3144471

[46] C.-C. Hu, T.-H. Jeng, and Y.-M. Chen, “Dynamic android malware analysis with de-identification of personal identifiable information,” in *2020 the 3rd International Conference on Computing and Big Data*, ser. ICCBD ’20. New York, NY, USA: Association for Computing Machinery, 2020, p. 30–36. [Online]. Available: https://doi.org/10.1145/3418688.3418694

[47] A. Hussein, M. Payer, A. Hosking, and C. A. Vick, “Impact of gc design on power and performance for android,” in *Proceedings of the 8th ACM International Systems and Storage Conference*, ser. SYSTOR ’15. New York, NY, USA: Association for Computing Machinery, 2015. [Online]. Available: https://doi.org/10.1145/2757667.2757674

[48] M. Ikram, N. Vallina-Rodriguez, S. Seneviratne, M. A. Kaafar, and V. Paxson, “An analysis of the privacy and security risks of android vpn permission-enabled apps,” in *Proceedings of the 2016 Internet Measurement Conference*, ser. IMC ’16. New York, NY, USA: Association for Computing Machinery, 2016, p. 349–364. [Online]. Available: https://doi.org/10.1145/2987443.2987471

[49] iOS, “Accessing private data,” 2022, https://developer.apple.com/design/human-interface-guidelines/patterns/accessing-private-data/.

[50] K. Jamrozik, P. von Styp-Rekowsky, and A. Zeller, “Mining sandboxes,” in *Proceedings of the 38th International Conference on Software Engineering*, ser. ICSE ’16. New York, NY, USA: Association
for Computing Machinery, 2016, p. 37–48. [Online].
Available: https://doi.org/10.1145/2884781.2884782

[51] S. Jana, D. Molnar, A. Moshchuk, A. Dunn, B. Livshits, H. J. Wang, and E. Ofek, “Enabling Fine-Grained permissions for augmented reality applications with recognizers,” in *22nd USENIX Security Symposium (USENIX Security 13)*. Washington, D.C.: USENIX Association, Aug. 2013, pp. 415–430. [Online]. Available: https://www.usenix.org/conference/usenixse curity13/technical-sessions/presentation/jana

[52] J. Jeon, K. K. Micinski, J. A. Vaughan, A. Fogel, N. Reddy, J. S. Foster, and T. Millstein, “Dr. android and mr. hide: fine-grained permissions in android applications,” in *Proceedings of the Second ACM Workshop on Security and Privacy in Smartphones and Mobile Devices*, ser. SPSM ’12. New York, NY, USA: Association for Computing Machinery, 2012, p. 3–14. [Online]. Available: https://doi.org/10.1145/2381 934.2381938

[53] Y.-S. Jeong, Y.-U. Park, J.-C. Moon, S.-J. Cho, D. Kim, and M. Park, “An anti-piracy mechanism based on class separation and dynamic loading for android applications,” in *Proceedings of the 2012 ACM Research in Applied Computation Symposium*, ser. RACS ’12. New York, NY, USA: Association for Computing Machinery, 2012, p. 328–332. [Online]. Available: https://doi.org/10.1145/2401603.2401674

[54] H. Jin, M. Liu, K. Dodhia, Y. Li, G. Srivastava, M. Fredrikson, Y. Agarwal, and J. I. Hong, “Why are they collecting my data? inferring the purposes of network traffic in mobile apps,” *Proc. ACM Interact. Mob. Wearable Ubiquitous Technol.*, vol. 2, no. 4, dec 2018. [Online]. Available: https://doi.org/10.1145/3287 051

[55] Kaspersky, “Running more than one antivirus program,”
https://www.kaspersky.com/resource-center/preemptive
-safety/running-more-than-one-antivirus-program.

[56] Kaspersky, “Tinycheck,” 2020, https://github.com/Kas
perskyLab/TinyCheck.

[57] Kaspersky, “More privacy control for all with tinycheck tool,” 2021, https://www.kaspersky.com/about/press-releases/2021_more-privacy-control-for-all-with-tinycheck-tool.

[58] A. Kelec and Z. Djuric, “A proposal for addressing security issues related to dynamic code loading on android platform,” *Computer Systems Science and Engineering*, vol. 35, no. 4, pp. 271–282, 2020.

[59] A. Khan, S. Lee, and J. Wang, “Differences in inter-app communication between android and ios systems.”

[60] M. T. Khan, J. DeBlasio, G. M. Voelker, A. C. Snoeren, C. Kanich, and N. Vallina-Rodriguez, “An empirical analysis of the commercial vpn ecosystem,” in *Proceedings of the Internet Measurement Conference 2018*, ser. IMC ’18. New York, NY, USA: Association for Computing Machinery, 2018, p. 443–456. [Online]. Available: https://doi.org/10.1145/3278532.3278570

[61] C. Khoo, K. Robertson, and R. Deibert, “Installing fear: A Canadian legal and policy analysis of using, developing, and selling smartphone spyware and stalkerware applications,” 2019.

[62] K. Kollnig, “Tracker control for android,” https://tracke rcontrol.org/.

[63] K. Kollnig, P. Dewitte, M. V. Kleek, G. Wang, D. Omeiza, H. Webb, and N. Shadbolt, “A fait accompli? an empirical study into the absence of consent to third-party tracking in android apps,” in *Seventeenth Symposium on Usable Privacy and Security (SOUPS 2021)*. USENIX Association, Aug. 2021, pp. 181–196. [Online]. Available: https://www. usenix.org/conference/soups2021/presentation/kollnig

[64] K. Kollnig and N. Shadbolt, “Trackercontrol: Transparency and choice around app tracking,” *Journal of Open Source Software*, vol. 7, no. 75, p. 4270, 2022.

[65] M. Krohn, A. Yip, M. Brodsky, N. Cliffer, M. F. Kaashoek, E. Kohler, and R. Morris, “Information flow control for standard os abstractions,” *ACM SIGOPS Operating Systems Review*, vol. 41, no. 6, pp. 321–334, 2007.

[66] S. Laube and R. Böhme, “Strategic aspects of cyber risk information sharing,” *ACM Comput. Surv.*, vol. 50, no. 5, Nov. 2017. [Online]. Available: https://doi.org/10.1145/3124398

[67] A. Le, J. Varmarken, S. Langhoff, A. Shuba, M. Gjoka, and A. Markopoulou, “Antmonitor: A system for monitoring from mobile devices,” in *Proceedings of the 2015 ACM SIGCOMM Workshop on Crowdsourcing and Crowdsharing of Big (Internet) Data*, 2015, pp. 15–20.

[68] H. Lee, D. Kim, and Y. Kwon, “Tls 1.3 in practice: how tls 1.3 contributes to the internet,” in *Proceedings of the Web Conference 2021*, ser. WWW ’21. New York, NY, USA: Association for Computing Machinery, 2021, p. 70–79. [Online]. Available: https://doi.org/10.1145/3442381.3450057

[69] K. S. Lee, H. Wang, and H. Weatherspoon, “PHY covert channels: Can you see the idles?” in *11th USENIX Symposium on Networked Systems Design and Implementation (NSDI 14)*. Seattle, WA: USENIX Association, Apr. 2014, pp. 173–185. [Online]. Available: https://www.usenix.org/conference/nsdi 14/technical-sessions/presentation/lee

[70] Linux., “Packet mmap,” https://docs.kernel.org/networ king/packet_mmap.html.

[71] L. Luo, “Heap memory snapshot assisted program analysis for android permission specification,” in *2020 IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER)*, 2020, pp. 435–446.

[72] X. Luo, E. W. W. Chan, and R. K. C. Chang, “Tcp covert timing channels: Design and detection,” in *2008 IEEE International Conference on Dependable Systems and Networks With FTCS and DCC (DSN)*, 2008, pp.
420–429.

[73] Madhav, “Raw socket using ndk,” https://groups.google.com/g/android-ndk/c/7FZCKNwun2I.

[74] G. R. Malan, D. Watson, F. Jahanian, and P. Howell, “Transport and application protocol scrubbing,” in *Proceedings IEEE INFOCOM 2000. Conference on Computer Communications. Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies* (Cat. No. 00CH37064), vol. 3. IEEE, 2000, pp. 1381–1390.

[75] C. Marforio, H. Ritzdorf, A. Francillon, and S. Capkun, “Analysis of the communication between colluding applications on modern smartphones,” in *28th Annual Computer Security Applications Conference, ACSAC 2012, Orlando, FL, USA, 3-7 December 2012*, R. H. Zakon, Ed. ACM, 2012, pp. 51–60.

[76] N. Matyunin, J. Szefer, and S. Katzenbeisser, “Zero-permission acoustic cross-device tracking,” in *2018 IEEE International Symposium on Hardware Oriented Security and Trust (HOST)*, 2018, pp. 25–32.

[77] N. Matyunin, Y. Wang, and S. Katzenbeisser, “Vibrational covert channels using low-frequency acoustic signals,” in *Proceedings of the ACM Workshop on Information Hiding and Multimedia Security*, ser. IH MMSec’19. New York, NY, USA: Association for Computing Machinery, 2019, p. 31–36. [Online]. Available: https://doi.org/10.1145/3335203.3335712

[78] G. Meng, Y. Liu, J. Zhang, A. Pokluda, and R. Boutaba, “Collaborative security: A survey and taxonomy,” *ACM Comput. Surv.*, vol. 48, no. 1, Jul. 2015. [Online]. Available: https://doi.org/10.1145/2785733

[79] O. Mirzaei, G. Suarez-Tangil, J. Tapiador, and J. M. de Fuentes, “Triflow: Triaging android applications using speculative information flows,” in *Proceedings of the 2017 ACM on Asia Conference on Computer and Communications Security*, ser. ASIA CCS ’17. New York, NY, USA: Association for Computing Machinery, 2017, p. 640–651. [Online]. Available: https://doi.org/10.1145/3052973.3053001

[80] G. Modi, V. Laxmi, S. Naval, and M. S. Gaur, “Improving leakage path coverage in android apps,” in *2017 IEEE Trustcom/BigDataSE/ICESS*, 2017, pp. 355–362.

[81] A. C. Myers and B. Liskov, “A decentralized model for information flow control,” *SIGOPS Oper. Syst. Rev.*, vol. 31, no. 5, p. 129–142, oct 1997. [Online]. Available: https://doi.org/10.1145/269005.266669

[82] A. C. Myers and B. Liskov, “Protecting privacy using the decentralized label model,” *ACM Trans. Softw. Eng. Methodol.*, vol. 9, no. 4, p. 410–442, oct 2000. [Online]. Available: https://doi.org/10.1145/363516.363526

[83] Norton, “Problems running multiple security products,” https://support.norton.com/sp/en/gb/home/current/solut ions/kb20080520095244EN.

[84] M. F. Nowlan, N. Tiwari, J. Iyengar, S. O. Amin, and B. Ford, “Fitting square pegs through round pipes: Unordered delivery Wire-Compatible with TCP and TLS,” in *9th USENIX Symposium on Networked Systems Design and Implementation (NSDI 12)*. San Jose, CA: USENIX Association, Apr. 2012, pp. 383–398. [Online]. Available: https://www.usenix.org/confe rence/nsdi12/technical-sessions/presentation/nowlan

[85] L. M. Page, “dmesg,” https://man7.org/linux/man-pag es/man1/dmesg.1.html, 2010.

[86] C. Parsons, A. Molnar, J. Dalek, J. Knockel, M. Kenyon, B. Haselton, C. Khoo, and R. Deibert, “The predator in your pocket: A multidisciplinary assessment of the stalkerware application industry,” 2019.

[87] U. Pehlivan, N. Baltaci, C. Acartürk, and N. Baykal, “The analysis of feature selection methods and classification algorithms in permission based android malware detection,” in *2014 IEEE Symposium on Computational Intelligence in Cyber Security (CICS)*, 2014, pp. 1–8.

[88] S. Poeplau, Y. Fratantonio, A. Bianchi, C. Kruegel, and G. Vigna, “Execute this! analyzing unsafe and malicious dynamic code loading in android applications.” in *NDSS*, vol. 14, 2014, pp. 23–26.

[89] Proofpoint, “Et pro® ruleset,” https://www.proofpoint.c om/us/threat-insight/et-pro-ruleset.

[90] Z. Qu, S. Alam, Y. Chen, X. Zhou, W. Hong, and R. Riley, “Dydroid: Measuring dynamic code loading and its security implications in android applications,” in *2017 47th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN)*, 2017, pp. 415–426.

[91] A. Rao, A. M. Kakhki, A. Razaghpanah, A. Tang, S. Wang, J. Sherry, P. Gill, A. Krishnamurthy, A. Legout, A. Mislove et al., “Using the middle to meddle with mobile,” *CCIS, Northeastern University, Tech. Rep.*, December, 2013.

[92] A. Razaghpanah, R. Nithyanand, N. Vallina-Rodriguez, S. Sundaresan, M. Allman, C. Kreibich, P. Gill et al., “Apps, trackers, privacy, and regulators: A global study of the mobile tracking ecosystem,” in *The 25th Annual Network and Distributed System Security Symposium (NDSS 2018)*, 2018.

[93] J. Reardon, Á. Feal, P. Wijesekera, A. E. B. On, N. Vallina-Rodriguez, and S. Egelman, “50 ways to leak your data: An exploration of apps’ circumvention of the android permissions system,” in *28th USENIX Security Symposium (USENIX Security 19)*. Santa Clara, CA: USENIX Association, Aug. 2019, pp. 603–620. [Online]. Available: https://www.usenix.org/c onference/usenixsecurity19/presentation/reardon

[94] J. Reardon, Á. Feal, P. Wijesekera, A. E. B. On, N. Vallina-Rodriguez, and S. Egelman, “50 ways to leak your data: An exploration of apps’ circumvention of the android permissions system,” in *28th USENIX Security Symposium (USENIX Security 19)*, 2019, pp. 603–620.

[95] I. Reyes, P. Wijesekera, J. Reardon, A. Elazari Bar On, A. Razaghpanah, N. Vallina-Rodriguez, S. Egelman et al., ““won’t somebody think of the children?” examining coppa compliance at scale,” in *The 18th Pri-
vacy Enhancing Technologies Symposium (PETS 2018), 2018.

[96] F. Rochet, E. Assogba, and O. Bonaventure, "Tcpls: Closely integrating tcp and tls," in Proceedings of the 19th ACM Workshop on Hot Topics in Networks, ser. HotNets '20. New York, NY, USA: Association for Computing Machinery, 2020, p. 45–52. [Online]. Available: https://doi.org/10.1145/3422604.3425947

[97] F. Roesner, T. Kohno, A. Moshchuk, B. Parno, H. J. Wang, and C. Cowan, "User-driven access control: Rethinking permission granting in modern operating systems," in 2012 IEEE Symposium on Security and Privacy, 2012, pp. 224–238.

[98] I. Roy, D. E. Porter, M. D. Bond, K. S. McKinley, and E. Witchel, "Laminar: Practical fine-grained decentralized information flow control," SIGPLAN Not., vol. 44, no. 6, p. 63–74, jun 2009. [Online]. Available: https://doi.org/10.1145/1543135.1542484

[99] N. R. Roy, A. K. Khanna, and L. Aneja, "Android phone forensic: Tools and techniques," in 2016 International Conference on Computing, Communication and Automation (ICCCA), 2016, pp. 605–610.

[100] A. Sadeghi, H. Bagheri, J. Garcia, and S. Malek, "A taxonomy and qualitative comparison of program analysis techniques for security assessment of android software," IEEE Transactions on Software Engineering, vol. 43, no. 6, pp. 492–530, 2017.

[101] A. Sadeghi, H. Bagheri, and S. Malek, "Analysis of android inter-app security vulnerabilities using covert," in 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, vol. 2, 2015, pp. 725–728.

[102] Samy, "Android ndk - raw socket creation problem," https://android-developers.narkive.com/BK5uGK4f/an droid-ndk-raw-socket-creation-problem.

[103] G. Shah and A. Molina, "Keyboards and covert channels," in 15th USENIX Security Symposium (USENIX Security 06). Vancouver, B.C. Canada: USENIX Association, Jul. 2006. [Online]. Available: https://www.usenix.org/conference/15th-usenix-securi ty-symposium/keyboards-and-covert-channels

[104] Y. Shao, J. Ott, Y. J. Jia, Z. Qian, and Z. M. Mao, "The misuse of android unix domain sockets and security implications," in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, 2016, pp. 80–91.

[105] T. Shishkova and A. Kivva, "Mobile malware evolution 2021," https://securelist.com/mobile-malware-evolutio n-2021/105876/, 2022.

[106] Snort, "Talos," https://snort.org/talos.

[107] Y. Song and U. Hengartner, "Privacyguard: A vpn-based platform to detect information leakage on android devices," in Proceedings of the 5th Annual ACM CCS Workshop on Security and Privacy in Smartphones and Mobile Devices, 2015, pp. 15–26.

[108] R. Spreitzer, V. Moonsamy, T. Korak, and S. Mangard, "Systematic classification of side-channel attacks: A

case study for mobile devices," IEEE Commun. Surv. Tutorials, vol. 20, no. 1, pp. 465–488, 2018.

[109] statcounter, "Mobile operating system market share worldwide," https://gs.statcounter.com/os-market-s hare/mobile/worldwide, 2022.

[110] statista, "Average number of new android app releases via google play per month from march 2019 to june 2022," https://www.statista.com/statistics/1020956/andr oid-app-releases-worldwide/, 2022.

[111] statistaX, "Annual number of app downloads from the google play store worldwide from 2016 to 2021," https: //www.statista.com/statistics/734332/google-play-app-i nstalls-per-year/, 2022.

[112] M. Sun, T. Wei, and J. C. Lui, "Taintart: A practical multi-level information-flow tracking system for android runtime," in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS '16. New York, NY, USA: Association for Computing Machinery, 2016, p. 331–342. [Online]. Available: https://doi.org/10.1145/ 2976749.2978343

[113] Suricata, "Suricata - features," https://suricata.io/featur es/.

[114] V. F. Taylor, R. Spolaor, M. Conti, and I. Martinovic, "Robust smartphone app identification via encrypted network traffic analysis," IEEE Transactions on Infor mation Forensics and Security, vol. 13, no. 1, pp. 63–78, 2018.

[115] E. Tromer and R. Schuster, "Droiddisintegrator: Intra-application information flow control in android apps," in Proceedings of the 11th ACM on Asia Conference on Computer and Communications Security, ser. ASIA CCS '16. New York, NY, USA: Association for Computing Machinery, 2016, p. 401–412. [Online]. Available: https://doi.org/10.1145/2897845.2897888

[116] K.-Y. Tsai, Y.-H. Chiu, and T.-C. Wu, "Android app copy protection mechanism based on dynamic loading," in The 18th IEEE International Symposium on Con sumer Electronics (ISCE 2014), 2014, pp. 1–3.

[117] Y. Tu, Z. Lin, I. Lee, and X. Hei, "Injected and delivered: Fabricating implicit control over actuation systems by spoofing inertial sensors," in 27th USENIX Security Symposium (USENIX Security 18). Baltimore, MD: USENIX Association, Aug. 2018, pp. 1545–1562. [Online]. Available: https://www.usenix.org/conferenc e/usenixsecurity18/presentation/tu

[118] S. Wall, "2023 sonicwall cyber threat report casts new light on shifting front lines, threat actor behavior," https: //www.sonicwall.com/news/2023-sonicwall-cyber-thre at-report-casts-new-light-on-shifting-front-lines-threat -actor-behavior/.

[119] H. Wang, Y. Guo, Z. Tang, G. Bai, and X. Chen, "Reevaluating android permission gaps with static and dynamic analysis," in 2015 IEEE Global Communica tions Conference (GLOBECOM). IEEE, 2015, pp. 1–6.

[120] X. Wang, A. Continella, Y. Yang, Y. He, and S. Zhu,
“Leakdoctor: Toward automatically diagnosing privacy
leaks in mobile applications,” *Proc. ACM Interact. Mob.
Wearable Ubiquitous Technol.*, vol. 3, no. 1, mar 2019.
[Online]. Available: https://doi.org/10.1145/3314415

[121] X. Wang, S. Chen, and J. Su, “Automatic mobile app
identification from encrypted traffic with hybrid neural
networks,” *IEEE Access*, vol. 8, pp. 182065–182077,
2020.

[122] X. Wang and D. S. Reeves, “Robust correlation of encrypted attack traffic through stepping stones by manipulation of interpacket delays,” in *Proceedings of the 10th ACM Conference on Computer and Communications Security*, ser. CCS ’03. New York, NY, USA: Association for Computing Machinery, 2003, p. 20–29. [Online]. Available: https://doi.org/10.1145/948109.948115

[123] D. Warburton and F. L. Sander Vinberg, “The 2021 tls telemetry report,” https://www.f5.com/labs/articles/thr eat-intelligence/the-2021-tls-telemetry-report.

[124] D. A. Wheeler, “Sloccount–a set of tools for counting physical source lines of code (sloc),” http://www.dwhe eler.com/sloccount, 2004.

[125] D. Wu, R. K. C. Chang, W. Li, E. K. T. Cheng, and D. Gao, “MopEye: Opportunistic monitoring of per-app mobile network performance,” in *2017 USENIX Annual Technical Conference (USENIX ATC 17)*. Santa Clara, CA: USENIX Association, Jul. 2017, pp. 445–457. [Online]. Available: https://www.usenix.org/conferenc e/atc17/technical-sessions/presentation/wu

[126] J. Xing, Q. Kang, and A. Chen, “Netwarden: Mitigating network covert channels while preserving performance,” in *USENIX Security*, 2020.

[127] Y. Yang, W. Luo, Y. Pei, M. Pan, and T. Zhang, “Execution enhanced static detection of android privacy leakage hidden by dynamic class loading,” in *2019 IEEE 43rd Annual Computer Software and Applications Conference (COMPSAC)*, vol. 1, 2019, pp. 149–158.

[128] A. Yip, X. Wang, N. Zeldovich, and M. F. Kaashoek, “Improving application security with data flow assertions,” in *Proceedings of the ACM SIGOPS 22nd Symposium on Operating Systems Principles*, ser. SOSP ’09. New York, NY, USA: Association for Computing Machinery, 2009, p. 291–304. [Online]. Available: https://doi.org/10.1145/1629575.1629604

[129] N. Zeldovich, S. Boyd-Wickizer, and D. Mazières, “Securing distributed systems with information flow control,” in *5th USENIX Symposium on Networked Systems Design and Implementation (NSDI 08)*. San Francisco, CA: USENIX Association, Apr. 2008. [Online]. Available: https://www.usenix.org/conferenc e/nsdi-08/securing-distributed-systems-information-flo w-control

[130] Y. Zhang, M. Yang, G. Gu, and H. Chen, “Rethinking permission enforcement mechanism on mobile systems,” *IEEE Transactions on Information Forensics and Security*, vol. 11, no. 10, pp. 2227–2240, 2016.

[131] C. Zhao, W. Zheng, L. Gong, M. Zhang, and C. Wang, “Quick and accurate android malware detection based on sensitive apis,” in *2018 IEEE International Conference on Smart Internet of Things (SmartIoT)*, 2018, pp. 143–148.

[132] Y. Zhauniarovich, M. Ahmad, O. Gadyatskaya, B. Crispo, and F. Massacci, “Stadyna: Addressing the problem of dynamic code updates in the security analysis of android applications,” in *Proceedings of the 5th ACM Conference on Data and Application Security and Privacy*, ser. CODASPY ’15. New York, NY, USA: Association for Computing Machinery, 2015, p. 37–48. [Online]. Available: https://doi.org/10.1145/2699026.2699105

[133] M. Zheng, M. Sun, and J. C. Lui, “Droidtrace: A ptrace based android dynamic analysis system with forward execution capability,” in *2014 International Wireless Communications and Mobile Computing Conference (IWCMC)*, 2014, pp. 128–133.