Inside Non-Root Android Ad Blockers: TUN Interfaces, Packet Sinks, and Memory-Safe Filtering

The Android Sandbox Constraint: Why Root Was Once Mandatory

Under the Android security architecture, every installed package is assigned a distinct Linux User ID (e.g., u0_a184). The Linux kernel enforces strict discretionary access controls (DAC) and SELinux policies:

• Process A cannot read Process B's memory space.
• Process A cannot bind to or inspect Process B's network sockets.
• Non-root processes cannot modify the kernel routing table or inject iptables / nftables rules.

In the early days of Android, stopping app ads required gaining root privilege to alter the read-only system partition (specifically overwriting /system/etc/hosts with millions of blacklisted domains). But modifying system partitions breaks Google Play Integrity API attestations, trips Samsung Knox warranty bits, and exposes the OS to rootkit risks.

The Non-Root Gateway: android.net.VpnService as a Local Loopback

Android 4.0 introduced the VpnService API, originally designed for corporate enterprise VPN tunnels. Crucially, Google built this API to operate at the OS network adapter level (Layer 3) rather than as an application proxy.

When an application instantiates a VpnService.Builder and calls establish(), the Android OS kernel creates a virtual network interface (typically tun0) and hands the app a standard Unix file descriptor wrapped in Java: a ParcelFileDescriptor.

ASCII Packet Pipeline: The Journey of an Android Network Request

Here is the exact lifecycle of an outbound socket request when an on-device local firewall is running:

[ Installed App / Game ] (UID: 10245)
          |
     (getaddrinfo / Socket Connect)
          |
    [ Linux Kernel IP Stack ]
          |
    (Default Route points to TUN0)
          |
          v
   +-------------------------------------------------------+
   |   Local TUN File Descriptor (ParcelFileDescriptor)   |
   +-------------------------------------------------------+
                              |
                              v
             +---------------------------------+
             |   NULLOG In-Memory Engine (RAM) |
             |   - Packet Dissector (IPv4/IPv6)|
             |   - DNS Port 53/DoT Interceptor |
             +---------------------------------+
                              |
            [ Match Hostname Against Radix-Trie ]
                             / \
                            /   \
          (Blacklisted Domain)   (Legitimate Traffic)
                   |                       |
                   v                       v
      +------------------------+   +-------------------------------+
      | Drop Packet or Synthesize|   | Pass Unmodified Packet to     |
      | NXDOMAIN / 0.0.0.0     |   | Real Hardware NIC (wlan0/rmnet)|
      +------------------------+   +-------------------------------+
                   |                               |
                   v                               v
         [ Ad Fails to Load ]             [ Remote Web Server ]

High-Throughput Rule Matching: Why Radix-Tries Beat Hash Maps

A production ad blocker must evaluate between 80,000 and 150,000 domain rules for every network query. If this evaluation is handled poorly, CPU spikes will throttle the phone and drain the battery within hours.

Standard approaches fail at scale on mobile hardware:

• Linear Regular Expressions: Testing hundreds of regex patterns against incoming domain strings results in \(O(N \cdot M)\) complexity, causing severe CPU thermal throttling.
• Standard Hash Tables: While exact lookups are \(O(1)\), wildcard subdomains (e.g., *.adservice.google.com) force repeated string slicing and hash calculations for every dot-separated label.

NULLOG implements a Radix-Trie (Compressed Prefix Tree) stored entirely in unswappable heap memory. In a Radix-Trie, domain names are indexed in reverse (TLD first):

(Root)
  └── "com"
        └── "google"
              ├── "adservice"  [FLAG: BLOCK]
              ├── "pagead2"    [FLAG: BLOCK]
              └── "play"       [FLAG: PASS]

Lookup complexity is bounded strictly by the length of the domain string \(O(k)\), independent of how many tens of thousands of rules exist. The lookup completes in under 0.38 milliseconds with an in-memory footprint below 14 megabytes.

Defeating Stealth Ad Bypasses: Hardcoded DoH & Direct IPs

As standard DNS sinkholing became widespread, aggressive ad networks began modifying their Android SDKs to bypass local resolvers using two stealth techniques:

1. Hardcoded DNS-over-HTTPS (DoH): Some ad SDKs ignore system DNS settings entirely. Instead, they open an encrypted TLS connection directly to Cloudflare (1.1.1.1:443) or Google (8.8.8.8:443) via HTTPS REST APIs, resolving ad hosts silently past simple DNS filters.
2. Direct IP Connections: Certain interstitial networks periodically distribute raw IPv4 addresses hardcoded in their configuration blobs, bypassing DNS host resolution altogether.

Because NULLOG sits at the IP packet layer (Layer 3 via TUN), it is not limited to passive DNS monitoring. NULLOG intercepts outbound TCP/UDP traffic destined for known public resolver endpoints, enforces protocol inspection, and neutralizes encrypted DNS leaks before they escape the device.

How to Verify Zero-Leakage Yourself (Audit Commands)

Trust in security software must be backed by empirical verification. You can audit NULLOG's network behavior yourself using Android Debug Bridge (adb):

To verify that NULLOG is not sending your data to any remote command-and-control server, connect your phone to a workstation with USB debugging enabled and run:

# Check active socket endpoints for NULLOG package
adb shell dumpsys netstats detail | grep -E "nullog|com.privyxe.nullog"

# Inspect open network file descriptors
adb shell lsof | grep -E "tun0|NULLOG"

You will observe that NULLOG maintains zero open TCP connections to external IP addresses. All filtering occurs locally in memory, making it mathematically impossible for browsing telemetry to be exported.