BPF Ninja: Making Sense of Tcpdump, Wireshark, and the PCAP World
- 2 days ago
- 9 min read

Hey folks!
Today we’re diving into a topic every network forensic analyst must get familiar with: tcpdump and the power-packed world around it—Wireshark, pcap, pcapng, and all the little details that actually matter when you're dealing with real-life packet analysis.
If you’re like me and enjoy understanding why a tool works the way it does (and not just copy-pasting commands from Stack Overflow), this blog’s for you
So, What’s tcpdump and Why Should You Care?
Imagine this:
You're investigating suspicious traffic, and all you’ve got is command line access. You need something light, fast, reliable—and boom—tcpdump comes to your rescue.
It’s a CLI-based packet capture tool that lets you sniff traffic in real time, apply filters, and save packet data for analysis. Originally born in the *NIX universe, it now works on Windows too. Pretty cool, right?
Under the hood, tcpdump uses the legendary libpcap library, which is like the oxygen tcpdump breathes. Here's what makes it so useful:
💡 Key Superpowers of tcpdump (Thanks to libpcap):
🔍 1. BPF (Berkeley Packet Filter)
This is a simple filtering language that lets you capture only the traffic you want. For example:
tcpdump port 443 and host 192.168.1.9
Boom—you’re only grabbing HTTPS packets to/from that host.
💾 2. Capture or Save Packets
You can choose to display packet headers on-screen, or save them into .pcap files to analyze later. These files are gold for forensic investigations. Imagine capturing something today and analyzing it 3 years later—yep, pcap has your back.
🔁 3. Live or Offline
tcpdump can sniff a live interface or read from a saved .pcap file as if it’s a live stream. That’s super helpful when you’re analyzing a case retrospectively.
📏 4. Snaplen Control
Don't want to capture entire packets because of size or legal constraints? Use -s to define the snap length (i.e., number of bytes to capture per packet).
Capturing just the headers? No problem.
tcpdump -s 96 -i eth0 -w output.pcap
🧠 Heads-Up: tcpdump Is for Capturing, Not Deep Diving
tcpdump is great for capturing data, but it doesn’t do fancy analysis. When you want to dissect those packets like a digital autopsy, you bring in the big gun: Wireshark.
🐟 Enter Wireshark: Your Friendly GUI Packet Analyzer
Wireshark is a graphical application that reads .pcap and .pcapng files, and honestly, it's a lifesaver when you're trying to figure out what went down on the wire. It decodes hundreds of protocols out of the box and lays everything out for you in a beautiful 3-pane display.
What makes Wireshark insanely useful:
Auto-dissectors for common protocols
Follow TCP Stream feature for full conversation analysis
Color-coded filtering
Click-and-zoom details for every packet field
Pro tip: You can capture packets directly in Wireshark, but for high-volume environments or remote machines, stick with tcpdump.
📟 Want CLI Power with Wireshark's Brain? Use tshark
Wireshark also comes with tshark, its CLI twin. So you can build your filters in Wireshark’s GUI and then export them to tshark scripts—perfect for large-scale or automated analysis.
tshark -r test.pcap -Y "http.request.method == GET"
📂 What’s Really Inside a .pcap File?
Okay, this is where things get forensically juicy. A .pcap file is not just a bunch of packets thrown together. It includes metadata that matters:
File Header Includes:
Magic Bytes: Helps identify it as a pcap file. Most common = 0xd4c3b2a1 (little-endian).
Version: For libpcap compatibility.
Timestamp Offset: Usually zero (all timestamps are in UTC—thank god).
Snaplen: Max bytes per packet saved.
Link Type: Like Ethernet, Wi-Fi, etc.
Each Packet Entry Has:
Timestamp (seconds + microseconds since epoch)
Captured Length
Original Packet Length (in case it was truncated)
These tiny details help determine whether you lost data during capture or were just intentionally limiting it.
📦 pcapng: The Next-Gen Format (but Be Careful)
Then comes pcapng—aka pcap Next Generation. It’s more flexible and stores:
Multiple interfaces in one file
Rich metadata (like capture comments)
Higher-res timestamps
Interface stats and DNS logs
Sounds awesome, right?
But here’s the catch: Not all tools support it properly. Even some versions of tcpdump can’t read pcapng without throwing vague errors.
So what do we do?
Convert it to regular pcap using editcap (comes with Wireshark):
editcap -F pcap captured_file.pcapng capture_file.pcap
Double-check with:
file capture_file.pcap
And voilà—you’re back in business.
🛠️ Thoughts: tcpdump and Wireshark = A Power Combo
Here’s how I look at it:
Use tcpdump for quick, controlled, stealthy captures (especially remotely or over SSH).
Use Wireshark for visual, detailed, protocol-level analysis.
Use tshark when you need scripting and automation.
Stick to pcap unless you absolutely need pcapng features.
Always verify your captures. A truncated packet can break your case.
--------------------------------------------------------------------------------------------------
Lets talk about BPF Filters
We’re diving into something that might sound dry but is actually one of the most powerful tools in your network forensics and incident response toolkit: BPF (Berkeley Packet Filter) syntax.
Now, if you’ve worked with tcpdump, Wireshark, or even snort or bro/zeek, you’ve already touched BPF. Think of it like your VIP bouncer at a nightclub—BPF decides what packets are "interesting" enough to get through the door and what gets kicked to the curb. 🧹
So why should you care?
Because it’s super-efficient, running close to the kernel, and helps you cut down on noise, saving time and resources during investigations or live captures.
🧠 What Even Is BPF?
At its core, BPF is a way to tell your system, “Only give me the packets I care about.” It’s a language that lets you define filters for capturing or processing packets.
Since tools like tcpdump and Wireshark use libpcap under the hood, BPF filters work across most major packet capture tools. That’s why learning it once pays off everywhere.
🧱 BPF Primitives: The Basics
Let’s say you're filtering water through a sieve. The holes in that sieve are your BPF filters. The smaller and more specific the holes, the more precise the capture.
Here are the building blocks (called primitives):
ip, ip6, tcp, udp, icmp: Protocol matchers.
ip is IPv4 traffic.
ip6 is IPv6.
If you want both: ip or ip6.
host: Filters packets by IP address (Layer 3).
Example: host 192.168.1.1
ether host: Filters by MAC address (Layer 2).
Example: ether host 00:11:BA:8c:98:d3
net: Filters by network range (CIDR).
Example: net 172.168.1.1/8
port: Filters by TCP/UDP port (Layer 4).
Example: port 443 (catches both TCP and UDP unless specified)
portrange: A range of ports.
Example: portrange 20-25
💡 Tip: BPF is stateless. It evaluates each packet independently, so if you're tracking a flow or multi-step exchange, that's handled in higher layers (e.g., Zeek, Suricata).
🔄 Directional Filters: src, dst, both?
Sometimes, you don’t want all traffic to/from an IP—maybe just the ones sent by it.
Here’s how direction works:
src host 192.168.1.1 → only source.
dst port 443 → only destination.
ether src 00:11:BA:8c:98:d3 → source MAC.
src net 172.168.1.1/8 → source from entire subnet.
⚠️ Note: When you say just host, port, or net, it’s bidirectional. Be specific if needed!
🧮 Combining Filters: AND, OR, NOT
This is where it gets fun (and powerful). You can combine primitives logically:
tcp and (port 80 or port 443) and not host 192.168.1.1
⬆️ That says:“Give me all TCP traffic on ports 80 or 443, but exclude anything involving 192.168.1.1.”
📌 Wrap complex filters in quotes, especially in shell commands. Shells interpret parentheses and spaces—don’t let that ruin your day.
🧪 Advanced Primitives (Forensics-Friendly)
You’ll probably need these in more forensic-heavy cases:
vlan 100 → Capture traffic on VLAN 100.
gateway → Detect packets with mismatched Layer 2/3 addressing (good for catching rogue devices).
Byte offsets & bitmasks → Ultra-specific matching based on packet byte positions. (More niche, but very powerful!)
🧰 Tcpdump Tips for Real-World Use
Let’s be honest—tcpdump can do a LOT more than just watch packets fly by your screen. Here are some gold-nugget options:
Flag | What it does |
-i any | Capture from all interfaces. |
-n | Disable DNS resolution (important for stealth & speed). |
-r file.pcap | Read from a PCAP instead of live traffic. |
-w out.pcap | Write captured packets to a file. |
-C 5 | Rotate output every 5MB. |
-G 30 | Rotate output every 30 seconds. Use with -w and time-formatted filenames like: -w dump_%F_%T.pcap. |
-W 10 | Keep only the last 10 files (used with -C or -G). |
-F filter.txt | Load a complex BPF filter from a file instead of typing it inline. Super helpful in team environments. |
🎯 Real-Life Example: Reducing a PCAP for Wireshark
Imagine you’ve got a 500MB pcap file but Wireshark can barely open it. You want to reduce it to something smaller—say, only traffic on HTTP/S or exclude noisy DNS and multicast.
Here’s how:
tcpdump -n -r full_capture.pcap -w reduced_capture.pcap
'tcp and (port 80 or port 443) and not port 53 and not net 192.168.1.1/4'
💡 This can cut the file size by almost 40–50% if the excluded traffic is significant.
📚 TL;DR - Quick Reference
Use quotes! 'port 80 and not host 10.0.0.1'
Know your direction: src, dst, host, ether host
Reduce noise: Use -n to disable DNS, and filter early
Modularize filters: Use -F for long BPFs
Save time: Use -C, -G, -W for file rotation
--------------------------------------------------------------------------------------------------
Before ending todays article, I want to give few commands which might be helpful for you
First Let’s admit it — network forensics can sound scary at first. You open up Wireshark or run tcpdump and BAM! — thousands of packets flying across the screen like it's The Matrix.
Let’s jump into some cool and useful tcpdump commands with real-world examples and context.
Example 1: Live Sniffing on an Interface — But Keep It Light
sudo tcpdump -n -s 100 -A -i eth0 -c 1000
🧠 What it does:
Monitors the eth0 interface (you can replace it with yours etc.)
Captures only the first 100 bytes of each packet (-s 100) to avoid dumping the whole packet — helpful for big networks.
-A dumps the actual ASCII content, which is super helpful for catching things like HTTP requests, cleartext creds, etc.
Stops after 1000 packets (-c 1000) so you don’t go blind.
-n speeds things up by not resolving DNS or port numbers — we want raw IPs and ports.
Example 2: Filter a pcap file for traffic from one host
tcpdump -n -r captured.pcap -w filtered.pcap 'host 192.168.1.1'
📂 You already have a .pcap file but you’re only interested in what one machine (say, 192.168.1.1) was up to.
-r captured.pcap: Reads the original pcap.
-w filtered.pcap: Writes only the filtered traffic.
'host 192.168.1.1': Our BPF (Berkeley Packet Filter) here filters both source or destination.
🧪 Try changing 'host' to:
'src host 192.168.1.1': only source
'dst host 192.168.1.1': only destination
Example 3: Rotate Files Daily for 2 Weeks — DNS Focused
sudo tcpdump -n -i eth0 -w dns-%F.%T.pcap -G 86400 -W 14 '(tcp or udp) and port 53'
🧠 What’s going on here:
We’re capturing DNS traffic only (TCP or UDP on port 53).
-w dns-%F.%T.pcap: Writes files with timestamps (great for organizing).
-G 86400: Rotates every 86,400 seconds = 1 day.
-W 14: Keeps only 14 files, so after 2 weeks, it stops or starts overwriting depending on your logic.
Perfect for long-term DNS analysis (e.g., DNS tunneling detection, malware beaconing).
Example 4: Rotating 100MB Files of Suspected APT Host Traffic
sudo tcpdump -n -i eth0-w suspected.pcap -C 100 'host 192.168.1.1'
🔍 Use this when you want to capture unlimited traffic to/from a shady IP, but don’t want your disk to explode.
-C 100: Rolls over to a new file every 100MB.
Files will be named like: suspected.pcap, suspected1.pcap, suspected2.pcap, etc.
💡 Tip: Add -W to limit how many files you keep:
-W 10
Example 5: Filter HTTP Traffic (not encrypted) and show requests
sudo tcpdump -i eth0 -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
😅 I know, this one looks scary. But here's what it's doing:
Filters HTTP requests only (and not empty ACKs or TCP keepalives).
-A + -s 0 dumps full ASCII of each packet — you can literally see GET and POST requests.
Real use case: Someone accessed your internal web app over HTTP. You suspect credential theft or command injection. This gives you a live view of the payloads.
Example 6: Capture suspicious outbound connections to multiple ranges
sudo tcpdump -i eth0 'dst net 185.100.87.0/24 or dst net 91.219.236.0/24'
🎯 This captures outbound traffic to known shady subnets. Perfect when you're watching beaconing or C2 callbacks.
You can expand the filter like this:
'((dst net 185.100.87.0/24) or (dst net 91.219.236.0/24)) and not port 443'
👉 Exclude HTTPS to avoid noise!
Tips from Me
Always test your BPF filter on small captures using -c 100 to make sure it’s not too broad.
Wireshark’s filter syntax ≠ tcpdump syntax! In Wireshark, you use ip.addr == x.x.x.x, but in tcpdump you just say 'host x.x.x.x'.
Use tcpdump -D to list all interfaces.
When in doubt, log to file first, analyze later. Don't grep in real-time unless you know what you're doing.
Bonus: Convert pcap to readable text
Want to take a .pcap and turn it into readable logs?
tcpdump -nn -tttt -r suspicious.pcap > readable_logs.txt
You’ll get timestamps + decoded traffic — perfect for incident timelines or report writing.
Final Words
Tcpdump is one of those tools that feels a bit raw at first, but once you get the hang of BPF filters, it's like having X-ray vision for your network. It's lightweight, powerful, and deadly accurate when used right. Combine it with tools like Wireshark for analysis and you've got a forensic powerhouse in your hands.
------------------------------------------------Dean-------------------------------------------------
Commentaires