packet capture from cloud phones with tcpdump and Wireshark
packet capture from cloud phones with tcpdump and Wireshark
if you need raw packet capture from a cloud Android phone (not just HTTPS bodies, the full layer-3 view), the workflow is tcpdump on the cloud phone, pull the pcap to your laptop, open in Wireshark. this matters when your debugging crosses transport-layer boundaries: TLS handshake failures, gRPC streams, QUIC, MTU issues, packet retransmissions, and DNS resolution paths. tools like Charles Proxy and Burp only see HTTP. tcpdump sees everything.
cloud phones in cloudf.one make this practical because the phone is reachable over ADB-over-network, and rooted variants are available for pulling pcaps that include real user-traffic headers. this guide covers the full pipeline: install tcpdump on the cloud phone, capture for a window of activity, pull the pcap, decrypt TLS in Wireshark with key logs, and tear down.
why packet capture beats HTTP-level inspection sometimes
three categories of bugs need raw packet visibility. TLS handshake failures (the app cannot complete the handshake; you need to see the cert chain offered by the server vs the trust store). transport-protocol issues (QUIC, HTTP/3, gRPC streams that misbehave at the framing layer). DNS resolution (slow, leaked, or hijacked DNS that no HTTP-level tool surfaces).
for HTTP-level work, Charles Proxy, mitmproxy, and Burp Suite are easier. for layer-3 work, tcpdump + Wireshark is the right tool.
prerequisites
on your laptop: Wireshark, Android platform-tools (for adb). on the cloud phone: tcpdump binary (often not installed by default on Samsung Android).
cloud phone must be rooted to capture from the WiFi interface in promiscuous mode. cloudf.one offers rooted variants for security and network research; specify when you provision.
# install Wireshark on macOS
brew install --cask wireshark
# verify
wireshark --version
step 1: connect to the cloud phone
adb connect adb-sg.cloudf.one:5555
adb devices
confirm with adb shell that the device is rooted:
adb -s adb-sg.cloudf.one:5555 shell "su -c 'id'"
# expected: uid=0(root) gid=0(root) ...
step 2: push the tcpdump binary
most Samsung Android builds do not ship tcpdump. download a static arm64 build (the Android-tools repo on GitHub maintains a current one) and push it.
# example, replace with the current static build URL
wget https://www.androidtcpdump.com/static-arm64/tcpdump
chmod +x tcpdump
adb -s adb-sg.cloudf.one:5555 push tcpdump /data/local/tmp/
adb -s adb-sg.cloudf.one:5555 shell chmod 755 /data/local/tmp/tcpdump
verify:
adb -s adb-sg.cloudf.one:5555 shell "su -c '/data/local/tmp/tcpdump --version'"
step 3: list interfaces
cloud phones expose multiple network interfaces: wlan0 (WiFi), rmnet_data* (cellular), lo (loopback). pick the one carrying your test traffic.
adb -s adb-sg.cloudf.one:5555 shell "su -c 'ip addr show'"
most cloud phone traffic rides wlan0 (when WiFi is on) or rmnet_data0 (when cellular). cloudf.one phones typically use a virtual WiFi by default, so wlan0 is the right capture target.
step 4: start a capture
capture all traffic on wlan0 to a pcap file:
adb -s adb-sg.cloudf.one:5555 shell \
"su -c '/data/local/tmp/tcpdump -i wlan0 -w /sdcard/capture.pcap -s 0'"
-s 0 captures the full packet (no truncation). -w /sdcard/capture.pcap writes the pcap to /sdcard/.
leave this running. trigger the app behavior you want to capture from another terminal (e.g. via Maestro, Appium, or manual interaction).
stop the capture with Ctrl+C.
step 5: filter to specific traffic
raw wlan0 capture pulls everything, including OS-level chatter. filter to the IP or port you care about:
# capture only traffic to/from a specific server
adb -s adb-sg.cloudf.one:5555 shell \
"su -c '/data/local/tmp/tcpdump -i wlan0 host api.example.com -w /sdcard/capture.pcap -s 0'"
# capture only HTTPS (port 443)
adb -s adb-sg.cloudf.one:5555 shell \
"su -c '/data/local/tmp/tcpdump -i wlan0 port 443 -w /sdcard/capture.pcap -s 0'"
# capture DNS only
adb -s adb-sg.cloudf.one:5555 shell \
"su -c '/data/local/tmp/tcpdump -i wlan0 port 53 -w /sdcard/capture.pcap -s 0'"
filtering on-device keeps the pcap small.
step 6: pull the pcap to your laptop
adb -s adb-sg.cloudf.one:5555 pull /sdcard/capture.pcap ./capture.pcap
open in Wireshark:
wireshark capture.pcap
Wireshark’s display filter syntax (http.request.method == "POST", tls.handshake.type == 1, dns.qry.name contains "example") lets you slice the capture however you need.
step 7: decrypt TLS in Wireshark
raw tcpdump captures HTTPS as encrypted bytes. to decrypt in Wireshark, you need the TLS session keys. there are two ways to get them on a cloud phone.
option A: SSLKEYLOGFILE in the app. if you control the app, build it with the SSLKEYLOGFILE environment variable pointing at a writable file. modern OkHttp and Java versions respect this when set (consult the OpenSSL key-log format docs). pull the key log file via adb pull after the capture, then tell Wireshark about it via Edit, Preferences, Protocols, TLS, Pre-Master-Secret log filename.
option B: Frida script that hooks the TLS write functions and dumps keys. our Frida hooking guide covers the pattern. extract keys, point Wireshark at the resulting key log.
once Wireshark has the keys, HTTPS appears decrypted in the dissector pane.
step 8: capture cellular vs WiFi
if you want to see traffic over the cloud phone’s cellular interface specifically (different from the virtual WiFi), capture on rmnet_data0:
adb -s adb-sg.cloudf.one:5555 shell \
"su -c '/data/local/tmp/tcpdump -i rmnet_data0 -w /sdcard/cellular.pcap -s 0'"
useful for verifying that a Singapore mobile IP is actually used (the Wireshark Statistics, Endpoints view shows the source IP, which should match a Singapore mobile carrier ASN).
step 9: tear down
# stop tcpdump if still running
adb -s adb-sg.cloudf.one:5555 shell "su -c 'pkill tcpdump'"
# clean up pcap on device
adb -s adb-sg.cloudf.one:5555 shell rm /sdcard/capture.pcap
common pitfalls
three issues catch teams new to packet capture on cloud phones.
first, no root, no capture. android-tcpdump on non-rooted devices can only see traffic for the app it runs as, not the system. cloudf.one rooted variants solve this.
second, large pcaps. unfiltered captures on busy interfaces grow fast. always filter at capture time or set a -W ring buffer.
third, TLS without keys. you’ll see the handshake but not the application data. unless you control the app or use Frida to extract keys, you can only verify TLS handshake-level info, not payload contents.
for context on when to use which network-debugging tool, our mitmproxy guide covers the HTTP-level work that does not need raw pcap.
try packet capture on a real Singapore cloud phone
register for a free trial and request a rooted Singapore phone. push tcpdump, capture for 30 seconds, pull to your laptop, open in Wireshark. for ongoing network research, scale to a paid plan with persistent rooted devices.
frequently asked questions
do I need root for tcpdump on Android?
for full packet capture on an interface, yes. without root you can only capture traffic for your own app via VpnService-based capture libraries. for forensic-level capture, root is required.
can I capture without ADB-over-network?
the capture itself runs on the cloud phone. ADB-over-network is only needed to pull the pcap. if your cloud phone provides a separate file-pull mechanism (cloudf.one’s dashboard does), you can skip ADB entirely.
what’s the maximum capture duration?
limited by /sdcard/ free space. a busy interface can produce 100 MB per minute. use -W ring buffers for long captures.
does Wireshark work on the cloud phone directly?
no, Wireshark is a desktop tool. capture on the phone with tcpdump, pull, analyze on your laptop. there is a remote-capture protocol called rpcap, but it is rarely used on Android.
can I capture WireGuard or other VPN traffic?
yes, but you’ll see the encrypted VPN packets, not the inner traffic. to see inside, capture on the VPN’s tunnel interface (e.g. tun0) instead of wlan0.