PCAPdroid
An Android app that captures and inspects the network traffic of the phone it runs on, described in its own repository as a “No-root network monitor, firewall and PCAP dumper for Android”. GPL-3.0, Java, written by emanuele-faranda. 4,387★, 519 forks on 2026-08-06; created 2020-01-06, last pushed 2026-08-05, so it is eight years of maintained work rather than a weekend release. Distributed on F-Droid and Google Play.
How it gets the packets is the design decision everything else follows from. Capturing traffic on Android normally needs root. PCAPdroid instead registers itself as a VPN service and lets the operating system hand it every packet the device sends, then routes them onward itself using zdtun, a minimal userspace TCP/IP stack. Nothing leaves the phone to a remote endpoint — the VPN is a local capture point, not a tunnel. It buys the tool its whole audience and costs it one thing: Android allows one active VPN app at a time, so on an unrooted device PCAPdroid and a real VPN cannot both run.
What it shows
- Per-app connection logs for user and system apps, with the fields that identify a destination without decrypting anything: SNI, DNS queries, HTTP URLs, remote IPs, plus offline geolocation of the remote server.
- Protocol identification via nDPI, ntop’s deep-packet-inspection library, which is what turns a socket to an IP address into “this app is talking to this service.”
- Payload inspection — HTTP requests and responses through built-in decoders, and raw hexdump or text for anything else.
- TLS decryption through a bundled mitmproxy addon, plus
SSLKEYLOGFILEexport for decrypting a capture afterwards in an external tool. - PCAP export, or a live stream to Wireshark on a desktop.
Firewall rules (block an app, a domain, an IP), malware detection against third-party blocklists, and PCAPng export are behind a paid tier. So the code is GPL-3.0 and some of the shipped capability is not free — the licence and the pricing are answering different questions.
Why a capture tool is a defensive one
This spoke’s founding sources all watch traffic that a defender already owns the vantage point on: a hardened server, a SOC’s alert pipeline, an enterprise proxy. PCAPdroid is the first source here on the case where the defender is the device owner and the thing being observed is the software they installed. The unit of investigation is an app, not a host, and the question it answers is where that app connects and what it sends — the same question a SOC asks of an endpoint, asked by a person about their own phone.
It is also the first tool in the corpus that does its work by breaking TLS on purpose. Every other
source treats encryption in transit as a control to be strengthened (mutual-tls,
certificate-lifecycle-management). Here it is the obstacle: to see what an app sends, you install
a CA certificate you control and let a local proxy sit in the middle. That is exactly the position an
attacker wants, reached legitimately because the person doing it owns both ends. The dual-use line
this spoke and ../osint-wiki draw is unusually literal in this tool.
What it does not evidence
The repository documents mechanism and features. It publishes no detection figures for the malware blocklists, no false-positive rate, no comparison against the alternatives, and no independent review of the mitm addon or the certificate handling it requires the user to trust. That is this spoke’s standing pattern again, now at its fourth artifact: shuffle ships an entire SOAR platform with no efficacy data, vaultls ships a CA with no security review, and PCAPdroid ships a TLS interceptor with neither. Inspectable code keeps arriving; measured behaviour does not.
Star counts, feature tiers and store availability are a 2026-08-06 snapshot.
Why this page is in this spoke
Routed by the hub on dominant substance: monitoring what software on your device talks to, and
blocking it, is defensive practice — visibility and control at the endpoint. Runner-up was
../osint-wiki, which owns reconnaissance and traffic analysis in service of intelligence
gathering; the seam is real, and a source about using captured traffic to profile a target would go
there. ../embedded-iot-wiki was considered and declined — Android is the host here, not the subject.
Related
network-traffic-analysis · emanuele-faranda · wireshark · defensive-security · security-operations-center · system-hardening · synthesis