NETWORK SCANNING PACKET ANALYSIS MASTERY
Network Scanning & Packet Analysis Mastery
Goal: Master the art of seeing, understanding, and manipulating network traffic at the byte level—developing the deep expertise that separates security professionals from script kiddies, and understanding why every packet on your network tells a story if you know how to read it.
Project Overview Table
| # | Project | Core Topics Covered | Difficulty |
|---|---|---|---|
| 1 | Raw Socket Packet Sniffer | Raw Sockets, Promiscuous Mode, Ethernet/IP/TCP Parsing, Layer 2-4 Headers | Advanced |
| 2 | TCP Port Scanner (Mini-Nmap) | TCP Three-Way Handshake, SYN/Connect Scans, Raw Packet Crafting, ICMP Handling | Advanced |
| 3 | ARP Network Discovery Tool | ARP Protocol, Layer 2 Addressing, MAC-IP Mapping, Subnet Enumeration | Intermediate |
| 4 | Protocol Dissector / Packet Decoder | Protocol Parsing, DNS/HTTP/SMTP Decoding, Binary vs Text Protocols, Plugin Architecture | Advanced |
| 5 | TCP Stream Reassembler | TCP Sequence Numbers, Out-of-Order Packets, Flow State Machine, Connection Tracking | Expert |
| 6 | DNS Traffic Analyzer | DNS Message Format, Query/Response Parsing, Name Compression, DNS Tunneling Detection | Intermediate |
| 7 | HTTP Traffic Inspector | HTTP Protocol, TCP Reassembly, Cookie/Session Extraction, Chunked Encoding | Advanced |
| 8 | Network Traffic Visualizer | Real-time Aggregation, Flow Statistics, Bandwidth Calculation, ncurses/Web UI | Intermediate |
| 9 | Intrusion Detection System (IDS) | Pattern Matching (Aho-Corasick), Snort-like Rules, Deep Packet Inspection, Alert Management | Expert |
| 10 | Packet Injection / Crafting Tool | Raw Packet Construction, IP/TCP Checksum Calculation, Source Spoofing, Pseudo-Header | Expert |
| 11 | ARP Spoofer and Detector | ARP Cache Poisoning, MITM Positioning, Gratuitous ARP, Attack Detection | Advanced |
| 12 | PCAP File Analyzer | PCAP Format Parsing, Forensic Analysis, File Carving, BPF Filter Compilation | Intermediate |
| 13 | TLS Handshake Analyzer | TLS Record Layer, ClientHello/ServerHello, SNI Extraction, JA3 Fingerprinting, X.509 Parsing | Advanced |
| 14 | Network Bandwidth Monitor | Flow Accounting, Rate Calculation, Socket-to-PID Mapping, Real-time Display | Intermediate |
| 15 | WiFi Probe Request Monitor | 802.11 Frames, Monitor Mode, Radiotap Headers, MAC Randomization Detection | Advanced |
Why Network Scanning & Packet Analysis Matters
In 1988, Robert Morris released the first major internet worm. It exploited, among other things, a lack of network visibility—administrators couldn’t see what was happening on their networks. Today, network traffic analysis remains the foundation of:
- Security Operations: SOC analysts spend 80%+ of their time analyzing network traffic and logs
- Incident Response: “What did the attacker access?” is answered by packet captures
- Penetration Testing: Reconnaissance through scanning is the first phase of any engagement
- Debugging: “Why is the app slow?” often has a network answer hidden in packet timing
The Hidden World Under Every Click:
When you visit "https://google.com":
Your Browser The Network Google's Server
│ │ │
│──[DNS Query: google.com?]────────>│ │
│<─[DNS Reply: 142.250.80.46]───────│ │
│ │ │
│──[TCP SYN]────────────────────────│────────────────────────────────────>│
│<─[TCP SYN-ACK]────────────────────│<────────────────────────────────────│
│──[TCP ACK]────────────────────────│────────────────────────────────────>│
│ │ │
│──[TLS ClientHello: SNI=google]───>│────────────────────────────────────>│
│<─[TLS ServerHello + Certificate]──│<────────────────────────────────────│
│──[Key Exchange, Encrypted Data]──>│────────────────────────────────────>│
│ │ │
│ ALL OF THIS happens in <100ms │ │
│ and YOU can see EVERY packet │ │
This guide teaches you to SEE this invisible world.
The Power You’re About to Gain:
- See Everything: Every device on your network, every connection, every byte transferred
- Understand Protocols: Not just “HTTP” but the actual bytes that make up a request
- Build Security Tools: Your own Nmap, Wireshark, Snort—from scratch
- Think Like an Attacker: Understand reconnaissance, MITM, and how attacks work
- Debug the Impossible: Network-level debugging reveals what application logs hide
Concept Summary Table
| Concept Cluster | What You Need to Internalize |
|---|---|
| Packets as bytes | Every network communication is just numbered bytes with headers. There’s no magic—just binary data with well-defined formats you can read and write. |
| The OSI/TCP-IP layers | Data flows DOWN through layers (encapsulation) when sending, UP through layers (decapsulation) when receiving. Each layer adds/removes headers. |
| Raw sockets | Normal sockets hide headers from you. Raw sockets let you see (or craft) the entire packet including all headers. Requires root privileges. |
| Promiscuous mode | Normally NICs ignore packets not addressed to them. Promiscuous mode captures EVERYTHING on the wire—the foundation of packet sniffing. |
| The TCP handshake | SYN → SYN-ACK → ACK establishes connections. Understanding this reveals how port scanners work and why SYN scans are “stealthy.” |
| ARP and Layer 2 | IP addresses need to be resolved to MAC addresses. ARP has NO authentication—this is why MITM attacks work on local networks. |
| Protocol parsing | Each protocol has a defined header structure. Parsing means casting byte buffers to structs and extracting fields. Endianness matters! |
| Checksum calculation | TCP/IP uses checksums to detect corruption. If you craft packets manually, you MUST calculate valid checksums or they’ll be dropped. |
| Flow tracking | A “flow” is a bidirectional conversation (5-tuple: src IP, src port, dst IP, dst port, protocol). Tracking flows is essential for stateful analysis. |
| BPF (Berkeley Packet Filter) | Filter packets in the kernel for efficiency. tcpdump filters like “tcp port 80” compile to BPF bytecode. |
Deep Dive Reading by Concept
This section maps each core concept to specific book chapters. Read these before or alongside the projects to build strong mental models.
Packet Structure & Network Fundamentals
| Concept | Book | Chapter |
|---|---|---|
| How packets are structured | “TCP/IP Illustrated, Volume 1” by W. Richard Stevens | Ch. 1-3: Link Layer, IP, ARP |
| The TCP/IP model in practice | “Computer Networks” by Tanenbaum | Ch. 5: Network Layer, Ch. 6: Transport Layer |
| What happens when you type a URL | “Computer Systems: A Programmer’s Perspective” by Bryant & O’Hallaron | Ch. 11: Network Programming |
| Physical layer to application | “TCP/IP Guide” by Charles Kozierok | Part IV: TCP/IP Protocols |
Raw Sockets & Packet Capture
| Concept | Book | Chapter |
|---|---|---|
| Raw socket programming | “The Linux Programming Interface” by Michael Kerrisk | Ch. 58: Sockets: Internet Domains |
| The socket API in depth | “Unix Network Programming, Vol. 1” by W. Richard Stevens | Ch. 28: Raw Sockets |
| libpcap programming | “Network Security Tools” by Nitesh Dhanjani | Ch. 2: Packet Sniffing |
| BPF and packet filtering | “The BSD Packet Filter” by McCanne & Jacobson | Original paper |
TCP/IP Deep Dive
| Concept | Book | Chapter |
|---|---|---|
| TCP three-way handshake | “TCP/IP Illustrated, Volume 1” by Stevens | Ch. 18: TCP Connection Establishment |
| TCP state machine | “TCP/IP Illustrated, Volume 1” by Stevens | Ch. 18-19: TCP Connection Management |
| Sequence numbers & reliability | “TCP/IP Illustrated, Volume 1” by Stevens | Ch. 17: TCP: Transmission Control Protocol |
| UDP and ICMP | “TCP/IP Illustrated, Volume 1” by Stevens | Ch. 6: ICMP, Ch. 11: UDP |
Port Scanning & Network Reconnaissance
| Concept | Book | Chapter |
|---|---|---|
| Port scanning techniques | “Nmap Network Scanning” by Gordon Lyon | Ch. 5: Port Scanning Techniques |
| SYN scans, FIN scans, etc. | “Nmap Network Scanning” by Gordon Lyon | Ch. 5.2-5.7: Scan Types |
| Host discovery | “Nmap Network Scanning” by Gordon Lyon | Ch. 3: Host Discovery |
| Service detection | “Nmap Network Scanning” by Gordon Lyon | Ch. 7: Service and Version Detection |
ARP & Layer 2
| Concept | Book | Chapter |
|---|---|---|
| ARP protocol in detail | “TCP/IP Illustrated, Volume 1” by Stevens | Ch. 4: ARP: Address Resolution Protocol |
| Ethernet framing | “Computer Networks” by Tanenbaum | Ch. 4: The Medium Access Control Sublayer |
| ARP spoofing attacks | “Hacking: The Art of Exploitation” by Jon Erickson | Ch. 4: Networking |
| Layer 2 security | “The Practice of Network Security Monitoring” by Bejtlich | Ch. 3: The Architecture of NSM |
Application Layer Protocols
| Concept | Book | Chapter |
|---|---|---|
| DNS protocol structure | “DNS and BIND” by Cricket Liu | Ch. 2: How Does DNS Work? |
| DNS message format | “TCP/IP Illustrated, Volume 1” by Stevens | Ch. 11: DNS |
| HTTP protocol | “HTTP: The Definitive Guide” by Gourley & Totty | Ch. 1-4: HTTP Fundamentals |
| TLS/SSL handshake | “Bulletproof TLS and PKI” by Ivan Ristić | Ch. 2: Protocol, Ch. 3: PKI |
Network Security & IDS
| Concept | Book | Chapter |
|---|---|---|
| Network security monitoring | “The Practice of Network Security Monitoring” by Bejtlich | All—this is THE book |
| Intrusion detection concepts | “The Practice of Network Security Monitoring” by Bejtlich | Ch. 7: Using Zeek |
| Attack signatures | “Practical Packet Analysis” by Chris Sanders | Ch. 10: Basic Network Forensics |
| Snort rule writing | Snort documentation | Rules section |
Packet Crafting & Exploitation
| Concept | Book | Chapter |
|---|---|---|
| Crafting packets | “Hacking: The Art of Exploitation” by Erickson | Ch. 4: Networking |
| Checksum calculation | “TCP/IP Illustrated, Volume 1” by Stevens | Ch. 3: IP, Ch. 17: TCP |
| Man-in-the-middle attacks | “Penetration Testing” by Georgia Weidman | Ch. 8: Network Attacks |
| Spoofing & injection | “The Linux Programming Interface” by Kerrisk | Ch. 58: Raw Sockets |
Wireless Security
| Concept | Book | Chapter |
|---|---|---|
| 802.11 protocol | “802.11 Wireless Networks: The Definitive Guide” by Gast | Ch. 4-5: Frame Format |
| Monitor mode | “Linux Basics for Hackers” by OccupyTheWeb | Ch. 15: Wireless Hacking |
| WiFi security analysis | “Practical Packet Analysis” by Sanders | Ch. 13: Wireless Packet Analysis |
Essential Reading Order for Maximum Comprehension
Foundation (Before starting any project):
- TCP/IP Illustrated, Vol. 1 — Ch. 1-4 (Ethernet, IP, ARP basics)
- The Linux Programming Interface — Ch. 56-58 (Sockets overview)
- Practical Packet Analysis — Ch. 1-3 (Wireshark basics to see what you’ll build)
Protocol Depth (Alongside Projects 1-4):
- TCP/IP Illustrated, Vol. 1 — Ch. 17-19 (TCP deep dive)
- Nmap Network Scanning — Ch. 5 (Port scanning theory)
- TCP/IP Illustrated, Vol. 1 — Ch. 11 (DNS)
Security Focus (Alongside Projects 5-11):
- Hacking: The Art of Exploitation — Ch. 4 (Network attacks)
- The Practice of Network Security Monitoring — Ch. 1-7 (NSM architecture)
- Bulletproof TLS and PKI — Ch. 1-4 (TLS protocol)
Mastery (Before Capstone):
- The Practice of Network Security Monitoring — Complete
- Nmap Network Scanning — Complete
- Original RFCs for protocols you’re implementing
Understanding the Fundamentals
To truly understand network scanning and packet analysis, you need to understand what’s happening at the wire level—the actual bytes flowing between machines. This knowledge reveals that networks have no secrets from anyone who can observe the wire.
The Core Question: How Can You See What Others Are Doing?
The answer lies in understanding three things:
- How packets are structured (they’re just bytes with headers)
- How network interfaces work (promiscuous mode sees everything)
- How to decode protocols (once you have bytes, you interpret them)
How Network Traffic Actually Works
The TCP/IP Stack (What You’re Intercepting)
┌─────────────────────────────────────────────────────────────────┐
│ APPLICATION LAYER │
│ HTTP, DNS, SMTP, FTP, SSH, etc. │
├─────────────────────────────────────────────────────────────────┤
│ TRANSPORT LAYER │
│ TCP / UDP │
│ (Ports, Sequences, Acknowledgments) │
├─────────────────────────────────────────────────────────────────┤
│ NETWORK LAYER │
│ IP │
│ (Source/Dest IP addresses) │
├─────────────────────────────────────────────────────────────────┤
│ DATA LINK LAYER │
│ Ethernet / WiFi │
│ (MAC addresses, Frames) │
├─────────────────────────────────────────────────────────────────┤
│ PHYSICAL LAYER │
│ (Actual electrical signals) │
└─────────────────────────────────────────────────────────────────┘
When you capture packets, you’re grabbing Ethernet frames that contain IP packets that contain TCP/UDP segments that contain application data.
What a Packet Actually Looks Like
Ethernet Frame (14 bytes header):
┌──────────────────┬──────────────────┬──────────┬─────────────────┐
│ Dest MAC (6) │ Src MAC (6) │ Type (2) │ Payload... │
└──────────────────┴──────────────────┴──────────┴─────────────────┘
IP Packet (20+ bytes header):
┌────┬────┬────────┬───────┬────┬──────┬────┬──────────┬──────────┐
│Ver │IHL │TOS │Length │ID │Flags │TTL │Protocol │Checksum │
├────┴────┴────────┴───────┴────┴──────┴────┴──────────┴──────────┤
│ Source IP Address (4 bytes) │
├──────────────────────────────────────────────────────────────────┤
│ Destination IP Address (4 bytes) │
└──────────────────────────────────────────────────────────────────┘
TCP Segment (20+ bytes header):
┌─────────────┬─────────────┬──────────────────────────────────────┐
│ Src Port(2) │ Dst Port(2) │ Sequence Number (4 bytes) │
├─────────────┴─────────────┼──────────────────────────────────────┤
│ │ Acknowledgment Number (4 bytes) │
├───────┬────────┬──────────┼──────────────────────────────────────┤
│Offset │Reserved│ Flags │ Window Size (2 bytes) │
│ │ │SYN ACK...│ │
├───────┴────────┴──────────┴──────────────────────────────────────┤
│ Checksum + Urgent Pointer + Options │
└──────────────────────────────────────────────────────────────────┘
Key Insight: Every packet is just a sequence of bytes with well-defined header formats. If you can capture the bytes, you can decode everything.
How Packet Sniffing Works
1. Raw Sockets
Normal sockets only see data destined for your application. Raw sockets let you see the full packet including headers:
// Linux: Create raw socket that sees ALL IP packets
int sock = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
2. Promiscuous Mode
Normally, your network card ignores packets not addressed to your MAC. Promiscuous mode tells it to capture everything:
// Enable promiscuous mode on interface
struct ifreq ifr;
ioctl(sock, SIOCGIFFLAGS, &ifr);
ifr.ifr_flags |= IFF_PROMISC;
ioctl(sock, SIOCSIFFLAGS, &ifr);
3. BPF (Berkeley Packet Filter)
For efficiency, you can filter packets in the kernel before they reach your program:
# Only capture TCP packets to port 80
tcpdump -i eth0 'tcp port 80'
How Network Scanning Works
Port Scanning Techniques
| Scan Type | How It Works | Stealth Level | Speed |
|---|---|---|---|
| TCP Connect | Full 3-way handshake | Low (logged) | Slow |
| TCP SYN | Send SYN, wait for SYN-ACK | Medium | Fast |
| UDP Scan | Send UDP, wait for ICMP unreachable | Medium | Very slow |
| FIN/NULL/XMAS | Exploit RFC compliance gaps | High | Medium |
| ACK Scan | Detect firewall rules | N/A | Fast |
TCP SYN Scan (The “Stealth” Scan)
Scanner Target
│ │
│────── SYN ────────────────────>│
│ │
│<───── SYN-ACK ─────────────────│ (Port OPEN)
│ │
│────── RST ────────────────────>│ (Don't complete handshake!)
│ │
OR:
│────── SYN ────────────────────>│
│ │
│<───── RST ─────────────────────│ (Port CLOSED)
Why it’s “stealth”: The connection is never completed, so it may not be logged by the target application (though modern systems still detect it).
Host Discovery Techniques
| Method | Protocol | How It Works |
|---|---|---|
| ARP Scan | Layer 2 | “Who has IP X?” — can’t be blocked on local network |
| ICMP Echo | ICMP | Classic ping — often blocked by firewalls |
| TCP SYN Ping | TCP | SYN to common port (80, 443) — more reliable |
| UDP Ping | UDP | Closed port triggers ICMP unreachable |
Project 1: Raw Socket Packet Sniffer
- File: NETWORK_SCANNING_PACKET_ANALYSIS_MASTERY.md
- Main Programming Language: C
- Alternative Programming Languages: Rust, Python, Go
- Coolness Level: Level 4: Hardcore Tech Flex
- Business Potential: 1. The “Resume Gold”
- Difficulty: Level 3: Advanced
- Knowledge Area: Network Programming / Raw Sockets
- Software or Tool: Raw Sockets, libpcap
- Main Book: “The Linux Programming Interface” by Michael Kerrisk
What you’ll build: A packet sniffer from scratch using raw sockets that captures all traffic on your network interface and displays packet headers in real-time.
Why it teaches Network Analysis: This is the foundation of everything. By building a sniffer, you’ll understand exactly how packets are structured, how promiscuous mode works, and why root privileges are required.
Core challenges you’ll face:
- Creating raw sockets → Maps to kernel-level network access
- Enabling promiscuous mode → Maps to NIC configuration
- Parsing Ethernet frames → Maps to Layer 2 understanding
- Decoding IP headers → Maps to Layer 3 understanding
- Handling TCP/UDP → Maps to Layer 4 understanding
Key Concepts:
- Raw Sockets: “The Linux Programming Interface” Chapter 58 — Michael Kerrisk
- Ethernet Framing: “TCP/IP Illustrated, Volume 1” Chapter 2 — W. Richard Stevens
- IP Header Format: “TCP/IP Illustrated, Volume 1” Chapter 3 — W. Richard Stevens
- Socket Programming: “The Sockets Networking API” Chapter 28 — W. Richard Stevens
Difficulty: Advanced Time estimate: 1-2 weeks Prerequisites: C programming, basic networking concepts
Real world outcome:
$ sudo ./packet_sniffer eth0
[2024-12-20 14:32:01] Captured 1,247 bytes
Ethernet: 00:1a:2b:3c:4d:5e -> ff:ff:ff:ff:ff:ff (ARP)
ARP: Who has 192.168.1.100? Tell 192.168.1.1
[2024-12-20 14:32:01] Captured 74 bytes
Ethernet: 00:1a:2b:3c:4d:5e -> 00:11:22:33:44:55 (IPv4)
IP: 192.168.1.50 -> 142.250.80.46 (TCP)
TCP: 52341 -> 443 [SYN] Seq=0 Win=65535
[2024-12-20 14:32:01] Captured 66 bytes
IP: 142.250.80.46 -> 192.168.1.50 (TCP)
TCP: 443 -> 52341 [SYN, ACK] Seq=0 Ack=1 Win=65535
# You're seeing EXACTLY what Wireshark sees!
Implementation Hints: Core structure in C:
// 1. Create raw socket
int sock = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
// 2. Bind to interface
struct sockaddr_ll sll;
sll.sll_family = AF_PACKET;
sll.sll_ifindex = if_nametoindex("eth0");
bind(sock, (struct sockaddr*)&sll, sizeof(sll));
// 3. Set promiscuous mode
struct packet_mreq mreq;
mreq.mr_ifindex = if_nametoindex("eth0");
mreq.mr_type = PACKET_MR_PROMISC;
setsockopt(sock, SOL_PACKET, PACKET_ADD_MEMBERSHIP, &mreq, sizeof(mreq));
// 4. Capture loop
while (1) {
int len = recvfrom(sock, buffer, sizeof(buffer), 0, NULL, NULL);
parse_ethernet_frame(buffer, len);
}
Parse headers by casting buffer to structs:
struct ethhdr *eth = (struct ethhdr *)buffer;
struct iphdr *ip = (struct iphdr *)(buffer + sizeof(struct ethhdr));
struct tcphdr *tcp = (struct tcphdr *)(buffer + sizeof(struct ethhdr) + ip->ihl*4);
Learning milestones:
- You see ARP packets → You understand Layer 2
- You decode IP addresses → You understand Layer 3
- You see TCP flags → You understand the transport layer
- You capture your own web traffic → You can analyze real protocols
The Core Question You’re Answering
“What IS a packet? Can I actually see the raw bytes flowing through my network card, and can I decode them myself?”
Before you write any code, sit with this question. Most developers think of network communication as high-level abstractions—HTTP requests, JSON responses, socket connections. But underneath, it’s ALL just bytes flowing through a wire. Your packet sniffer tears away the abstraction and shows you the truth: every DNS lookup, every TLS handshake, every ping—it’s all just numbered bytes with well-defined header structures.
When you complete this project, you’ll never look at network traffic the same way. You’ll understand why Wireshark exists, why tcpdump is powerful, and why network engineers speak in terms of “frames,” “packets,” and “segments.”
Concepts You Must Understand First
Stop and research these before coding:
- The OSI/TCP-IP Layer Model
- What’s the difference between a “frame” (Layer 2), “packet” (Layer 3), and “segment” (Layer 4)?
- When you capture traffic, which layer are you capturing at?
- Why does each layer need its own header?
- Book Reference: “TCP/IP Illustrated, Volume 1” Ch. 1 — Stevens
- How a Network Interface Card (NIC) Works
- What does the NIC do when a packet arrives that’s NOT addressed to its MAC?
- What is “promiscuous mode” and why does enabling it require root?
- How does the kernel deliver packets to your program?
- Book Reference: “The Linux Programming Interface” Ch. 58 — Kerrisk
- Socket Types: SOCK_STREAM vs SOCK_DGRAM vs SOCK_RAW
- What does each socket type give you access to?
- Why can’t you see packet headers with a regular TCP socket?
- What is
AF_PACKETand how is it different fromAF_INET? - Book Reference: “Unix Network Programming, Vol. 1” Ch. 28 — Stevens
- Ethernet Frame Format
- What are the first 14 bytes of every Ethernet frame?
- What does the “EtherType” field tell you?
- How do you know if the payload is IP, ARP, or something else?
- Book Reference: “TCP/IP Illustrated, Volume 1” Ch. 2 — Stevens
- IP Header Format
- What does the IHL (Internet Header Length) field mean?
- Where are the source and destination IP addresses in the header?
- What does the “Protocol” field tell you about the payload?
- Book Reference: “TCP/IP Illustrated, Volume 1” Ch. 3 — Stevens
- Endianness (Byte Order)
- What is “network byte order” and why does it exist?
- What do
htons(),ntohs(),htonl(),ntohl()do? - What happens if you forget to convert and your machine is little-endian?
- Book Reference: “Computer Systems: A Programmer’s Perspective” Ch. 2 — Bryant & O’Hallaron
Questions to Guide Your Design
Before implementing, think through these:
- Choosing Your Capture Method
- Should you use raw sockets (
AF_PACKET) or libpcap? - What are the tradeoffs? (Raw sockets = more control, libpcap = more portable)
- Will your approach work on macOS/BSD, or only Linux?
- Should you use raw sockets (
- Handling Different Protocols
- How will you distinguish between IPv4 and IPv6 packets?
- What will you do with ARP packets vs IP packets?
- How will you handle unknown EtherTypes gracefully?
- Parsing Strategy
- Will you cast the buffer directly to header structs, or copy field by field?
- What’s the risk of casting (alignment, undefined behavior)?
- How will you handle variable-length headers (IP options)?
- Output Format
- What information is most useful to display?
- Should you show hex dumps of raw bytes?
- How will you make the output readable without being overwhelming?
- Error Handling
- What happens if
socket()fails (hint: needs root)? - What if the interface name is wrong?
- How will you handle malformed packets gracefully?
- What happens if
Thinking Exercise
Before coding, trace this scenario by hand:
You're capturing on your laptop (192.168.1.50, MAC: aa:bb:cc:dd:ee:ff)
Your router is 192.168.1.1 (MAC: 00:11:22:33:44:55)
You visit http://example.com which resolves to 93.184.216.34
Trace the FIRST packet your sniffer will capture when you type the URL:
Questions while tracing:
- What type of packet is sent first? (Hint: DNS or ARP?)
- Draw the Ethernet header: what’s the destination MAC? Source MAC?
- If it’s an IP packet, what protocol number is in the IP header?
- If it’s UDP (for DNS), what are the source and destination ports?
- Where does the DNS query data start in the buffer?
Draw the packet layout:
Offset 0: [Ethernet Header - 14 bytes]
Dest MAC (6) | Src MAC (6) | EtherType (2)
Offset 14: [IP Header - 20 bytes minimum]
Version/IHL | TOS | Length | ID | Flags/Offset | TTL | Protocol | Checksum
Source IP (4 bytes) | Destination IP (4 bytes)
Offset 34: [UDP Header - 8 bytes]
Src Port (2) | Dst Port (2) | Length (2) | Checksum (2)
Offset 42: [DNS Query Data]
Transaction ID | Flags | Questions | ...
Now verify your understanding:
- If the captured packet is 78 bytes total, how many bytes are DNS data?
- What byte offset would you look at to find the destination port?
- How would you detect if this packet contains DNS vs HTTP?
The Interview Questions They’ll Ask
Prepare to answer these confidently:
- “Explain how packet sniffing works at the operating system level.”
- Talk about raw sockets, AF_PACKET, promiscuous mode, the kernel’s role
- “What’s the difference between capturing at Layer 2 vs Layer 3?”
- Layer 2 includes Ethernet headers and sees ARP; Layer 3 only sees IP
- “Why does Wireshark need root/admin privileges?”
- Promiscuous mode and raw socket access are privileged operations
- “How would you capture only HTTP traffic?”
- BPF filter: “tcp port 80”, or manually check IP protocol and TCP ports
- “What’s the maximum size of an Ethernet frame, and why does it matter?”
- 1518 bytes (with VLAN: 1522). MTU affects fragmentation.
- “How do you handle packets that arrive out of order or fragmented?”
- IP fragmentation: check fragment offset/MF flag. TCP: use sequence numbers.
- “What would you see differently sniffing on a hub vs a switch?”
- Hub: all traffic. Switch: only broadcast/multicast and traffic to/from you (unless port mirroring)
- “How could an attacker evade a packet sniffer?”
- Encryption (TLS), tunneling (VPN), fragmentation, timing attacks
Hints in Layers
(Only read these if you’re stuck!)
Hint 1: Getting the Socket to Work
If socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)) returns -1:
- Are you running as root? (
sudo) - Check
errnowithperror("socket") - On macOS, use BPF devices (
/dev/bpf*) instead of AF_PACKET
Hint 2: Binding to an Interface
struct sockaddr_ll sll = {0};
sll.sll_family = AF_PACKET;
sll.sll_ifindex = if_nametoindex("eth0"); // or "en0" on macOS
sll.sll_protocol = htons(ETH_P_ALL);
if (bind(sock, (struct sockaddr*)&sll, sizeof(sll)) < 0) {
perror("bind");
}
If if_nametoindex returns 0, the interface name is wrong. Use ip link or ifconfig to find it.
Hint 3: Parsing the Ethernet Header
#include <net/ethernet.h> // for struct ether_header
struct ether_header *eth = (struct ether_header *)buffer;
printf("Src MAC: %02x:%02x:%02x:%02x:%02x:%02x\n",
eth->ether_shost[0], eth->ether_shost[1], eth->ether_shost[2],
eth->ether_shost[3], eth->ether_shost[4], eth->ether_shost[5]);
uint16_t ethertype = ntohs(eth->ether_type);
if (ethertype == ETHERTYPE_IP) {
// Parse IP header at buffer + 14
} else if (ethertype == ETHERTYPE_ARP) {
// Parse ARP header
}
Hint 4: Parsing the IP Header
#include <netinet/ip.h> // for struct iphdr (Linux) or struct ip (BSD)
struct iphdr *ip = (struct iphdr *)(buffer + sizeof(struct ether_header));
// IP header length is in 32-bit words
int ip_header_len = ip->ihl * 4;
// Source and destination IPs
struct in_addr src, dst;
src.s_addr = ip->saddr;
dst.s_addr = ip->daddr;
printf("IP: %s -> %s\n", inet_ntoa(src), inet_ntoa(dst));
// What's the payload?
if (ip->protocol == IPPROTO_TCP) {
// TCP at buffer + 14 + ip_header_len
} else if (ip->protocol == IPPROTO_UDP) {
// UDP at buffer + 14 + ip_header_len
}
Hint 5: Enabling Promiscuous Mode
struct packet_mreq mreq = {0};
mreq.mr_ifindex = if_nametoindex("eth0");
mreq.mr_type = PACKET_MR_PROMISC;
if (setsockopt(sock, SOL_PACKET, PACKET_ADD_MEMBERSHIP,
&mreq, sizeof(mreq)) < 0) {
perror("setsockopt PACKET_ADD_MEMBERSHIP");
}
Without promiscuous mode, you only see packets addressed to YOUR MAC or broadcast.
Hint 6: Using lldb to Debug
Compile with -g and run in lldb:
$ sudo lldb ./packet_sniffer
(lldb) breakpoint set --name parse_ethernet_frame
(lldb) run eth0
(lldb) p/x buffer[0] # First byte of Ethernet dest MAC
(lldb) memory read buffer buffer+14 # Hex dump of Ethernet header
Books That Will Help
| Topic | Book | Chapter |
|---|---|---|
| Raw socket fundamentals | “The Linux Programming Interface” by Michael Kerrisk | Ch. 58: Sockets (Raw Sockets section) |
| Ethernet frame format | “TCP/IP Illustrated, Volume 1” by W. Richard Stevens | Ch. 2: Link Layer |
| IP header format | “TCP/IP Illustrated, Volume 1” by W. Richard Stevens | Ch. 3: IP: Internet Protocol |
| TCP/UDP headers | “TCP/IP Illustrated, Volume 1” by W. Richard Stevens | Ch. 11: UDP, Ch. 17: TCP |
| Packet capture with libpcap | “Practical Packet Analysis” by Chris Sanders | Ch. 4: Working with Captured Packets |
| Network programming in C | “Unix Network Programming, Vol. 1” by W. Richard Stevens | Ch. 28: Raw Sockets |
| BPF filters | “The BSD Packet Filter” paper by McCanne & Jacobson | Original paper (available online) |
Project 2: TCP Port Scanner (Mini-Nmap)
- File: NETWORK_SCANNING_PACKET_ANALYSIS_MASTERY.md
- Main Programming Language: C
- Alternative Programming Languages: Rust, Python, Go
- Coolness Level: Level 4: Hardcore Tech Flex
- Business Potential: 1. The “Resume Gold”
- Difficulty: Level 3: Advanced
- Knowledge Area: Network Security / Port Scanning
- Software or Tool: Raw Sockets, TCP/IP
- Main Book: “Nmap Network Scanning” by Gordon Lyon (Fyodor)
What you’ll build: A port scanner that implements TCP Connect, SYN, and UDP scanning from scratch—understanding exactly how Nmap works internally.
Why it teaches Network Scanning: Port scanning is the foundation of network reconnaissance. Building one teaches you the TCP handshake, raw packet crafting, and how services respond to probes.
Core challenges you’ll face:
- TCP Connect scan → Maps to socket connect() behavior
- SYN scan (half-open) → Maps to raw packet crafting
- UDP scanning → Maps to ICMP unreachable handling
- Service detection → Maps to banner grabbing
- Timeout handling → Maps to async/concurrent programming
Key Concepts:
- TCP Three-Way Handshake: “TCP/IP Illustrated, Volume 1” Chapter 18 — W. Richard Stevens
- Port Scanning Theory: “Nmap Network Scanning” Chapter 5 — Gordon Lyon
- Raw Packet Crafting: “The Linux Programming Interface” Chapter 58 — Michael Kerrisk
- Concurrent Scanning: “TCP/IP Sockets in C” Chapter 6 — Donahoo & Calvert
Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Project 1, TCP/IP fundamentals
Real world outcome:
$ sudo ./port_scanner -sS 192.168.1.1 -p 1-1000
Scanning 192.168.1.1 (1000 ports)...
Scan type: TCP SYN (half-open)
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open http
443/tcp open https
8080/tcp filtered http-proxy
Scan completed in 2.34 seconds
997 closed ports not shown
$ sudo ./port_scanner -sU 192.168.1.1 -p 53,67,123,161
PORT STATE SERVICE
53/udp open domain
67/udp open|filtered dhcp
123/udp open ntp
161/udp closed snmp
Implementation Hints:
TCP Connect Scan (easiest, but not stealthy):
int scan_connect(char *ip, int port) {
int sock = socket(AF_INET, SOCK_STREAM, 0);
struct sockaddr_in addr = {
.sin_family = AF_INET,
.sin_port = htons(port),
.sin_addr.s_addr = inet_addr(ip)
};
// Set non-blocking for timeout
fcntl(sock, F_SETFL, O_NONBLOCK);
int result = connect(sock, (struct sockaddr*)&addr, sizeof(addr));
// Use select() to wait with timeout
// If connect succeeds -> port open
// If connection refused -> port closed
// If timeout -> port filtered
}
SYN Scan (requires crafting raw packets):
- Build IP header + TCP header with SYN flag
- Calculate checksums manually
- Send via raw socket
- Capture response with another raw socket
- SYN-ACK = open, RST = closed, nothing = filtered
UDP Scan:
- Send UDP packet to port
- If ICMP “port unreachable” → closed
- If any UDP response → open
-
If timeout → open filtered (ambiguous)
Learning milestones:
- Connect scan works → You understand TCP connections
- SYN scan works → You can craft raw packets
- You detect firewall filtering → You understand ICMP behavior
- Scan speed is comparable to Nmap → You understand concurrency
The Core Question You’re Answering
“How does Nmap know which ports are open? What’s actually happening at the packet level when I scan a host?”
Port scanning seems like magic until you build one yourself. Then you realize it’s just clever manipulation of TCP’s three-way handshake. A SYN scan works because TCP must respond to SYN packets—the protocol demands it. By crafting packets and interpreting responses, you can map any network’s attack surface.
When you complete this project, you’ll understand every Nmap scan type from first principles. You’ll know why SYN scans are “stealthy,” why UDP scans are slow, and why firewalls make scanning complex.
Concepts You Must Understand First
Stop and research these before coding:
- The TCP Three-Way Handshake
- What are the SYN, SYN-ACK, and ACK packets?
- What sequence numbers are exchanged, and why?
- What does it mean when a port sends RST instead of SYN-ACK?
- Book Reference: “TCP/IP Illustrated, Volume 1” Ch. 18 — Stevens
- Port States: Open, Closed, Filtered
- What response indicates “open”? (SYN-ACK)
- What response indicates “closed”? (RST)
- What does no response mean? (Filtered by firewall, or packet dropped)
- Book Reference: “Nmap Network Scanning” Ch. 5 — Lyon
- Raw Packet Crafting
- How do you construct an IP header from scratch?
- How do you set TCP flags (SYN, ACK, RST, FIN)?
- Why must you calculate IP and TCP checksums manually?
- Book Reference: “Hacking: The Art of Exploitation” Ch. 4 — Erickson
- The TCP Pseudo-Header
- What is the pseudo-header used for in checksum calculation?
- Why does the TCP checksum include parts of the IP header?
- How do you calculate the checksum correctly?
- Book Reference: “TCP/IP Illustrated, Volume 1” Ch. 17 — Stevens
- ICMP Error Messages
- What ICMP message indicates “port unreachable”?
- What ICMP message indicates “host unreachable” or “admin prohibited”?
- How do you capture ICMP responses related to your probes?
- Book Reference: “TCP/IP Illustrated, Volume 1” Ch. 6 — Stevens
- Concurrency and Timeouts
- How do you scan thousands of ports efficiently?
- What timeout indicates a port is “filtered”?
- How do you use
select()orepoll()for non-blocking I/O? - Book Reference: “Unix Network Programming, Vol. 1” Ch. 6 — Stevens
Questions to Guide Your Design
Before implementing, think through these:
- Choosing Scan Types
- Which scan type will you implement first? (Connect is easiest)
- For SYN scan, how will you send AND receive raw packets simultaneously?
- How will you handle UDP’s inherent ambiguity?
- Performance Considerations
- If scanning 65535 ports, how many concurrent connections do you allow?
- What’s your timeout per port vs overall scan?
- How will you handle rate limiting to avoid triggering IDS?
- Response Handling
- How will you correlate responses to specific probes?
- For SYN scan, how do you match incoming SYN-ACK to the port you probed?
- How do you handle receiving RST from a different host (spoofed)?
- Stealth Considerations
- Why is SYN scan called “half-open”?
- What log entries does Connect scan leave vs SYN scan?
- How could you implement FIN/NULL/XMAS scans?
- Service Detection
- After finding open ports, how do you identify services?
- What is “banner grabbing” and how does it work?
- How does Nmap’s
-sVversion detection work?
Thinking Exercise
Before coding, trace these scenarios by hand:
Scenario 1: TCP Connect Scan to Port 22 (SSH Open)
Your scanner (192.168.1.50) Target (192.168.1.1)
│ │
│──[SYN] port 22 ──────────────────>│
│ │
│<─[SYN-ACK] ───────────────────────│ (Port OPEN!)
│ │
│──[ACK] ──────────────────────────>│ (Connection established)
│ │
│──[RST] ──────────────────────────>│ (Close immediately)
Questions:
- What would the target’s SSH server log show?
- Why do you send ACK and then RST?
Scenario 2: TCP SYN Scan to Port 23 (Telnet Closed)
Your scanner Target
│ │
│──[SYN] port 23 ──────────────────>│
│ │
│<─[RST] ───────────────────────────│ (Port CLOSED)
Questions:
- Why does the target send RST instead of SYN-ACK?
- What does the target’s kernel do when it receives SYN for a closed port?
Scenario 3: TCP SYN Scan to Port 80 (Filtered by Firewall)
Your scanner Firewall Target
│ │ │
│──[SYN] port 80 ────────────────>│ │
│ │ (dropped) │
│ ... wait ... │ │
│ ... timeout ... │ │
│ (Port FILTERED) │ │
Questions:
- How long should you wait before declaring “filtered”?
- Some firewalls send ICMP “admin prohibited”—what would you see?
The Interview Questions They’ll Ask
Prepare to answer these confidently:
- “Explain the difference between a SYN scan and a Connect scan.”
- Connect completes handshake (logged). SYN sends only SYN, never ACKs (less logged).
- “Why is UDP scanning unreliable and slow?”
- No handshake. Closed ports send ICMP unreachable (rate-limited). Open ports may not respond.
- “How would you detect if a port is being filtered by a firewall?”
- No response (timeout) or ICMP admin-prohibited. Distinguished from closed by no RST.
-
**“What’s the difference between open filtered and filtered?”** -
open filtered: Could be either (e.g., UDP no response). filtered: Firewall definitely blocking.
-
- “How does Nmap detect operating systems?”
- TCP/IP stack fingerprinting: window sizes, TTL values, flag responses to unusual probes.
- “How could you evade an IDS during port scanning?”
- Slow scanning, fragmented packets, decoy IPs, timing variations.
- “What happens if you SYN scan from a spoofed source IP?”
- Responses go to spoofed IP. You can’t see them unless you control that host or sniff.
- “Explain what an XMAS scan is and why it works.”
- Sets FIN+PSH+URG flags. Per RFC, closed ports RST; open ports ignore. Works on RFC-compliant stacks.
Hints in Layers
(Only read these if you’re stuck!)
Hint 1: Start with TCP Connect Scan It’s the simplest and requires no raw sockets:
int sock = socket(AF_INET, SOCK_STREAM, 0);
fcntl(sock, F_SETFL, O_NONBLOCK); // Non-blocking
struct sockaddr_in addr;
addr.sin_family = AF_INET;
addr.sin_port = htons(port);
addr.sin_addr.s_addr = inet_addr(target_ip);
connect(sock, (struct sockaddr*)&addr, sizeof(addr));
// Use select() with timeout to check if connection succeeded
fd_set fds;
FD_ZERO(&fds);
FD_SET(sock, &fds);
struct timeval tv = {1, 0}; // 1 second timeout
int result = select(sock + 1, NULL, &fds, NULL, &tv);
if (result > 0) {
// Check if connection succeeded or failed
int error;
socklen_t len = sizeof(error);
getsockopt(sock, SOL_SOCKET, SO_ERROR, &error, &len);
if (error == 0) printf("Port %d: OPEN\n", port);
else printf("Port %d: CLOSED\n", port);
} else {
printf("Port %d: FILTERED\n", port);
}
close(sock);
Hint 2: Building a SYN Packet
struct iphdr ip;
struct tcphdr tcp;
// IP header
ip.version = 4;
ip.ihl = 5;
ip.tot_len = htons(sizeof(ip) + sizeof(tcp));
ip.ttl = 64;
ip.protocol = IPPROTO_TCP;
ip.saddr = inet_addr("192.168.1.50"); // Your IP
ip.daddr = inet_addr(target_ip);
// TCP header
tcp.source = htons(random_port()); // Random source port
tcp.dest = htons(target_port);
tcp.seq = htonl(random());
tcp.ack_seq = 0;
tcp.doff = 5; // 20 bytes, no options
tcp.syn = 1; // SYN flag!
tcp.window = htons(65535);
// Calculate checksums (see next hint)
Hint 3: TCP Checksum Calculation
struct pseudo_header {
uint32_t src_addr;
uint32_t dst_addr;
uint8_t placeholder;
uint8_t protocol;
uint16_t tcp_length;
};
uint16_t calculate_tcp_checksum(struct iphdr *ip, struct tcphdr *tcp) {
struct pseudo_header psh;
psh.src_addr = ip->saddr;
psh.dst_addr = ip->daddr;
psh.placeholder = 0;
psh.protocol = IPPROTO_TCP;
psh.tcp_length = htons(sizeof(struct tcphdr));
char buffer[sizeof(psh) + sizeof(struct tcphdr)];
memcpy(buffer, &psh, sizeof(psh));
memcpy(buffer + sizeof(psh), tcp, sizeof(struct tcphdr));
return checksum((uint16_t*)buffer, sizeof(buffer));
}
Hint 4: Sending Raw Packets
int sock = socket(AF_INET, SOCK_RAW, IPPROTO_TCP);
int one = 1;
setsockopt(sock, IPPROTO_IP, IP_HDRINCL, &one, sizeof(one));
char packet[sizeof(struct iphdr) + sizeof(struct tcphdr)];
// Build IP and TCP headers in packet buffer...
struct sockaddr_in dest;
dest.sin_family = AF_INET;
dest.sin_addr.s_addr = inet_addr(target_ip);
sendto(sock, packet, sizeof(packet), 0,
(struct sockaddr*)&dest, sizeof(dest));
Hint 5: Receiving SYN-ACK or RST Responses You need a second raw socket to capture responses:
int recv_sock = socket(AF_INET, SOCK_RAW, IPPROTO_TCP);
char buffer[65535];
while (1) {
int len = recvfrom(recv_sock, buffer, sizeof(buffer), 0, NULL, NULL);
struct iphdr *ip = (struct iphdr*)buffer;
struct tcphdr *tcp = (struct tcphdr*)(buffer + ip->ihl * 4);
// Check if this is a response to our scan
if (ntohs(tcp->dest) == our_source_port) {
if (tcp->syn && tcp->ack) {
printf("Port %d: OPEN\n", ntohs(tcp->source));
} else if (tcp->rst) {
printf("Port %d: CLOSED\n", ntohs(tcp->source));
}
}
}
Hint 6: Concurrent Scanning with epoll
#include <sys/epoll.h>
int epfd = epoll_create1(0);
struct epoll_event events[MAX_CONCURRENT];
// Add all sockets to epoll
for (int i = 0; i < num_sockets; i++) {
struct epoll_event ev;
ev.events = EPOLLOUT; // Wait for write-ready (connect complete)
ev.data.fd = sockets[i];
epoll_ctl(epfd, EPOLL_CTL_ADD, sockets[i], &ev);
}
// Wait for multiple connections simultaneously
int ready = epoll_wait(epfd, events, MAX_CONCURRENT, timeout_ms);
for (int i = 0; i < ready; i++) {
// Check if connection succeeded
}
Books That Will Help
| Topic | Book | Chapter |
|---|---|---|
| TCP three-way handshake | “TCP/IP Illustrated, Volume 1” by W. Richard Stevens | Ch. 18: TCP Connection Establishment |
| Port scanning techniques | “Nmap Network Scanning” by Gordon Lyon | Ch. 5: Port Scanning Techniques |
| Raw packet crafting | “Hacking: The Art of Exploitation” by Jon Erickson | Ch. 4: Networking |
| TCP checksum calculation | “TCP/IP Illustrated, Volume 1” by W. Richard Stevens | Ch. 17: TCP |
| ICMP error handling | “TCP/IP Illustrated, Volume 1” by W. Richard Stevens | Ch. 6: ICMP |
| Non-blocking I/O | “Unix Network Programming, Vol. 1” by W. Richard Stevens | Ch. 6: I/O Multiplexing |
| Firewall evasion | “Nmap Network Scanning” by Gordon Lyon | Ch. 10: Firewall and IDS Evasion |
Project 3: ARP Network Discovery Tool
- File: NETWORK_SCANNING_PACKET_ANALYSIS_MASTERY.md
- Main Programming Language: C
- Alternative Programming Languages: Rust, Python, Go
- Coolness Level: Level 3: Genuinely Clever
- Business Potential: 2. The “Micro-SaaS / Pro Tool”
- Difficulty: Level 2: Intermediate
- Knowledge Area: Network Discovery / ARP Protocol
- Software or Tool: Raw Sockets, ARP
- Main Book: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens
What you’ll build: A tool that discovers all hosts on your local network by sending ARP requests and analyzing responses—like arp-scan or Nmap’s -sn on a local network.
Why it teaches Network Analysis: ARP operates at Layer 2 and cannot be blocked by IP firewalls. Understanding ARP reveals how IP addresses map to physical hardware and exposes the inherent vulnerabilities of local networks.
Core challenges you’ll face:
- ARP packet structure → Maps to Layer 2 addressing
- Broadcast addresses → Maps to network topology
- MAC address parsing → Maps to hardware addressing
- Subnet iteration → Maps to IP addressing and CIDR
- Response timing → Maps to network latency
Key Concepts:
- ARP Protocol: “TCP/IP Illustrated, Volume 1” Chapter 4 — W. Richard Stevens
- Ethernet Broadcasting: “Computer Networks” Chapter 5 — Tanenbaum
- Subnet Calculation: “TCP/IP Guide” Section 5 — Charles Kozierok
- Layer 2 Attacks: “The Practice of Network Security Monitoring” Chapter 3 — Bejtlich
Difficulty: Intermediate Time estimate: 1 week Prerequisites: Basic C, understanding of IP/MAC addresses
Real world outcome:
$ sudo ./arp_scanner 192.168.1.0/24
Scanning 254 hosts on 192.168.1.0/24...
IP Address MAC Address Vendor
─────────────────────────────────────────────────
192.168.1.1 00:1a:2b:3c:4d:5e Cisco Systems
192.168.1.50 dc:a6:32:12:34:56 Raspberry Pi
192.168.1.100 f0:18:98:ab:cd:ef Apple, Inc.
192.168.1.105 00:11:22:33:44:55 Intel Corporate
192.168.1.150 b8:27:eb:11:22:33 Raspberry Pi
5 hosts discovered in 1.2 seconds
# You now know EVERY device on your network!
Implementation Hints: ARP packet structure:
struct arp_packet {
// Ethernet header
uint8_t eth_dest[6]; // ff:ff:ff:ff:ff:ff (broadcast)
uint8_t eth_src[6]; // Your MAC
uint16_t eth_type; // 0x0806 (ARP)
// ARP header
uint16_t hw_type; // 1 (Ethernet)
uint16_t proto_type; // 0x0800 (IPv4)
uint8_t hw_size; // 6 (MAC length)
uint8_t proto_size; // 4 (IP length)
uint16_t opcode; // 1 (request) or 2 (reply)
uint8_t sender_mac[6];
uint8_t sender_ip[4];
uint8_t target_mac[6]; // 00:00:00:00:00:00 for request
uint8_t target_ip[4];
};
Algorithm:
- Get your own IP and MAC address
- Calculate subnet range from CIDR
- For each IP in range: send ARP request
- Listen for ARP replies (different hosts respond)
- Build table of IP → MAC mappings
- Optional: Look up MAC vendor from OUI database
Learning milestones:
- You see your router respond → You understand ARP basics
- You discover unknown devices → You see the power of Layer 2
- You identify vendors by MAC → You understand OUI prefixes
- You understand why ARP spoofing works → You see the vulnerability
Project 4: Protocol Dissector / Packet Decoder
- File: NETWORK_SCANNING_PACKET_ANALYSIS_MASTERY.md
- Main Programming Language: C
- Alternative Programming Languages: Rust, Python
- Coolness Level: Level 3: Genuinely Clever
- Business Potential: 2. The “Micro-SaaS / Pro Tool”
- Difficulty: Level 3: Advanced
- Knowledge Area: Protocol Analysis / Parsing
- Software or Tool: libpcap
- Main Book: “Practical Packet Analysis” by Chris Sanders
What you’ll build: A protocol dissector that reads captured packets (or live traffic) and decodes application-layer protocols like HTTP, DNS, SMTP, and FTP into human-readable format.
Why it teaches Packet Analysis: Wireshark’s power comes from its protocol dissectors. Building your own teaches you how protocols are structured and how to extract meaningful data from raw bytes.
Core challenges you’ll face:
- Protocol identification → Maps to port numbers and heuristics
- DNS message parsing → Maps to binary protocol decoding
- HTTP request/response parsing → Maps to text protocol decoding
- Handling fragmentation → Maps to TCP stream reassembly
- Extensible architecture → Maps to plugin systems
Key Concepts:
- DNS Protocol: “TCP/IP Illustrated, Volume 1” Chapter 11 — W. Richard Stevens
- HTTP Protocol: “HTTP: The Definitive Guide” Chapters 1-4 — Gourley & Totty
- Protocol Parsing: “Practical Packet Analysis” Chapters 6-8 — Chris Sanders
- SMTP Protocol: RFC 5321
Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Projects 1-3, familiarity with common protocols
Real world outcome:
$ sudo ./packet_decoder eth0
─── DNS Query ───────────────────────────────────────────────
Time: 14:32:01.234 Src: 192.168.1.50 -> 8.8.8.8
Transaction ID: 0x1234
Flags: Standard query
Questions: 1
- www.google.com (A record)
─── DNS Response ────────────────────────────────────────────
Time: 14:32:01.267 Src: 8.8.8.8 -> 192.168.1.50
Transaction ID: 0x1234
Answers: 2
- www.google.com -> 142.250.80.46 (A, TTL=300)
- www.google.com -> 142.250.80.47 (A, TTL=300)
─── HTTP Request ────────────────────────────────────────────
Time: 14:32:01.290 Src: 192.168.1.50:52341 -> 142.250.80.46:80
GET /search?q=hello HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64)
Accept: text/html,application/xhtml+xml
─── HTTP Response ───────────────────────────────────────────
Time: 14:32:01.456 Src: 142.250.80.46:80 -> 192.168.1.50:52341
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 15234
[Body truncated: 15234 bytes]
Implementation Hints: Protocol dispatch table:
typedef void (*dissector_fn)(uint8_t *data, int len);
struct protocol_entry {
int port;
char *name;
dissector_fn dissector;
};
struct protocol_entry protocols[] = {
{53, "DNS", dissect_dns},
{80, "HTTP", dissect_http},
{443, "HTTPS", dissect_tls_hello},
{25, "SMTP", dissect_smtp},
{21, "FTP", dissect_ftp},
{0, NULL, NULL}
};
DNS parsing (binary protocol):
void dissect_dns(uint8_t *data, int len) {
struct dns_header *hdr = (struct dns_header *)data;
printf("Transaction ID: 0x%04x\n", ntohs(hdr->id));
printf("Questions: %d\n", ntohs(hdr->qdcount));
// Parse questions (tricky: compressed names!)
uint8_t *ptr = data + sizeof(struct dns_header);
char name[256];
ptr = parse_dns_name(data, ptr, name); // Handle compression
printf(" - %s\n", name);
}
HTTP parsing (text protocol):
void dissect_http(uint8_t *data, int len) {
// HTTP is text-based, split by \r\n
char *line = strtok((char*)data, "\r\n");
printf("%s\n", line); // Request/Status line
while ((line = strtok(NULL, "\r\n")) && strlen(line) > 0) {
printf("%s\n", line); // Headers
}
}
Learning milestones:
- DNS queries decode correctly → You understand binary protocols
- HTTP requests are readable → You understand text protocols
- You add a new protocol dissector → You understand the architecture
- You see passwords in FTP/Telnet → You understand why encryption matters
Project 5: TCP Stream Reassembler
- File: NETWORK_SCANNING_PACKET_ANALYSIS_MASTERY.md
- Main Programming Language: C
- Alternative Programming Languages: Rust, Go
- Coolness Level: Level 4: Hardcore Tech Flex
- Business Potential: 1. The “Resume Gold”
- Difficulty: Level 4: Expert
- Knowledge Area: TCP/IP / Stream Processing
- Software or Tool: libpcap
- Main Book: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens
What you’ll build: A tool that reassembles fragmented TCP streams from packet captures, reconstructing complete HTTP sessions, file transfers, or any TCP-based conversation.
Why it teaches TCP: TCP is complex—packets arrive out of order, get retransmitted, and must be reassembled. This project forces you to understand sequence numbers, acknowledgments, and flow control deeply.
Core challenges you’ll face:
- Sequence number tracking → Maps to TCP reliability
- Out-of-order handling → Maps to packet reordering
- Retransmission detection → Maps to duplicate handling
- Connection tracking → Maps to state machine per flow
- Memory management → Maps to buffer management
Key Concepts:
- TCP State Machine: “TCP/IP Illustrated, Volume 1” Chapter 18 — W. Richard Stevens
- Sequence Numbers: “TCP/IP Illustrated, Volume 1” Chapter 17 — W. Richard Stevens
- Stream Reassembly: libnids documentation and source code
- Flow Tracking: “The Practice of Network Security Monitoring” Chapter 5 — Bejtlich
Difficulty: Expert Time estimate: 3-4 weeks Prerequisites: Projects 1-4, deep TCP understanding
Real world outcome:
$ sudo ./tcp_reassembler capture.pcap
Found 47 TCP streams:
Stream 1: 192.168.1.50:52341 <-> 93.184.216.34:80
Duration: 0.234s
Client sent: 523 bytes
Server sent: 45,231 bytes
[Exported to stream_1_client.bin, stream_1_server.bin]
Stream 2: 192.168.1.50:52342 <-> 93.184.216.34:443 (TLS)
Duration: 1.234s
Client sent: 2,341 bytes
Server sent: 156,789 bytes
[Encrypted - TLS detected]
# View reconstructed HTTP session:
$ cat stream_1_client.bin
GET /index.html HTTP/1.1
Host: example.com
$ cat stream_1_server.bin | head -20
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 45000
<!DOCTYPE html>...
Implementation Hints: Flow tracking structure:
struct tcp_flow {
uint32_t src_ip, dst_ip;
uint16_t src_port, dst_port;
uint32_t client_isn; // Initial sequence number
uint32_t server_isn;
struct segment *client_segments; // Linked list
struct segment *server_segments;
uint8_t *client_stream; // Reassembled data
uint8_t *server_stream;
int client_len, server_len;
};
struct segment {
uint32_t seq;
uint16_t len;
uint8_t *data;
struct segment *next;
};
Reassembly algorithm:
- For each TCP packet, find or create flow state
- Insert segment into sorted list (by sequence number)
- Check for overlaps/retransmissions
- When contiguous segments exist, copy to stream buffer
- Handle FIN/RST to close stream
The tricky parts:
- Sequence number wraparound (use 32-bit comparison correctly)
- Overlapping segments (retransmissions with different data)
- Half-open connections (only see one side)
Learning milestones:
- Simple streams reassemble → You understand sequence numbers
- Out-of-order packets work → You understand reordering
- You export HTTP payloads → You can analyze application data
- You handle edge cases → You truly understand TCP
Project 6: DNS Traffic Analyzer
- File: NETWORK_SCANNING_PACKET_ANALYSIS_MASTERY.md
- Main Programming Language: C
- Alternative Programming Languages: Python, Go, Rust
- Coolness Level: Level 3: Genuinely Clever
- Business Potential: 3. The “Service & Support” Model
- Difficulty: Level 2: Intermediate
- Knowledge Area: DNS / Network Monitoring
- Software or Tool: libpcap, DNS
- Main Book: “DNS and BIND” by Cricket Liu
What you’ll build: A DNS monitoring tool that captures all DNS queries on your network, showing what domains every device is looking up—revealing browsing patterns, malware callbacks, and data exfiltration.
Why it teaches DNS: DNS is the “phonebook” of the internet. By analyzing DNS traffic, you can see what every device is trying to access, even before the actual connections happen.
Core challenges you’ll face:
- DNS message parsing → Maps to binary protocol decoding
- Name compression → Maps to DNS pointer handling
- Query types (A, AAAA, MX, TXT) → Maps to DNS record types
- Response code analysis → Maps to error detection
- Caching behavior → Maps to TTL handling
Key Concepts:
- DNS Protocol: “DNS and BIND” Chapter 2 — Cricket Liu
- DNS Message Format: RFC 1035
- DNS Security: “The Practice of Network Security Monitoring” Chapter 8 — Bejtlich
- Name Compression: “TCP/IP Illustrated, Volume 1” Chapter 11 — Stevens
Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Project 1, basic DNS understanding
Real world outcome:
$ sudo ./dns_monitor eth0
DNS Traffic Monitor - Listening on eth0
═══════════════════════════════════════════════════════════════
[14:32:01] 192.168.1.50 -> 8.8.8.8
Query: www.google.com (A)
Answer: 142.250.80.46 (TTL: 300)
[14:32:02] 192.168.1.105 -> 192.168.1.1
Query: suspicious-domain.ru (A)
Answer: NXDOMAIN ⚠️ (Domain not found)
[14:32:03] 192.168.1.100 -> 8.8.8.8
Query: api.openai.com (A)
Answer: 104.18.6.192 (TTL: 60)
[14:32:04] 192.168.1.50 -> 8.8.8.8
Query: asdkjh2k3h4.evil.com (TXT) ⚠️
# Possible DNS tunneling/exfiltration!
─── Statistics ───────────────────────────────────────────────
Total queries: 1,234
Unique domains: 89
Top queriers:
192.168.1.50: 456 queries
192.168.1.100: 321 queries
Top domains:
google.com: 123 queries
facebook.com: 87 queries
Implementation Hints: DNS header structure:
struct dns_header {
uint16_t id; // Transaction ID
uint16_t flags; // QR, Opcode, AA, TC, RD, RA, Z, RCODE
uint16_t qdcount; // Questions
uint16_t ancount; // Answers
uint16_t nscount; // Authority
uint16_t arcount; // Additional
};
Parsing DNS names (handle compression!):
// DNS names use compression: 0xC0 0xXX means "pointer to offset XX"
int parse_dns_name(uint8_t *packet, uint8_t *ptr, char *name) {
int len = 0;
while (*ptr != 0) {
if ((*ptr & 0xC0) == 0xC0) { // Compression pointer
int offset = ((*ptr & 0x3F) << 8) | *(ptr+1);
parse_dns_name(packet, packet + offset, name + len);
return (ptr - packet) + 2;
}
int label_len = *ptr++;
memcpy(name + len, ptr, label_len);
len += label_len;
name[len++] = '.';
ptr += label_len;
}
name[len-1] = '\0'; // Remove trailing dot
return (ptr - packet) + 1;
}
Learning milestones:
- You see DNS queries from your machine → You understand DNS basics
- You decode answers correctly → You understand response format
- You detect suspicious patterns → You understand DNS security
- You see what your smart devices query → You understand IoT privacy
Project 7: HTTP Traffic Inspector
- File: NETWORK_SCANNING_PACKET_ANALYSIS_MASTERY.md
- Main Programming Language: C
- Alternative Programming Languages: Python, Go, Rust
- Coolness Level: Level 3: Genuinely Clever
- Business Potential: 2. The “Micro-SaaS / Pro Tool”
- Difficulty: Level 3: Advanced
- Knowledge Area: HTTP / Web Traffic Analysis
- Software or Tool: libpcap, HTTP parsing
- Main Book: “HTTP: The Definitive Guide” by Gourley & Totty
What you’ll build: An HTTP traffic analyzer that captures and decodes HTTP requests/responses, showing URLs, headers, cookies, and response bodies in real-time.
Why it teaches Web Protocols: HTTP is the backbone of the web. Understanding how to capture and analyze it reveals cookies, authentication tokens, API calls, and why HTTPS matters.
Core challenges you’ll face:
- TCP stream reassembly → Maps to HTTP over TCP
- Request/response parsing → Maps to HTTP message format
- Chunked encoding → Maps to transfer encodings
- Cookie extraction → Maps to session tracking
- Content decoding → Maps to gzip/deflate
Key Concepts:
- HTTP Message Format: “HTTP: The Definitive Guide” Chapter 3 — Gourley & Totty
- HTTP Headers: “HTTP: The Definitive Guide” Chapter 4 — Gourley & Totty
- Cookies: “HTTP: The Definitive Guide” Chapter 11 — Gourley & Totty
- Stream Reassembly: Project 5 learnings
Difficulty: Advanced Time estimate: 2 weeks Prerequisites: Project 5 (TCP reassembly)
Real world outcome:
$ sudo ./http_inspector eth0 --show-headers --show-cookies
HTTP Traffic Inspector - Port 80
═══════════════════════════════════════════════════════════════
▶ REQUEST 192.168.1.50 -> 93.184.216.34
GET /api/user/profile HTTP/1.1
Host: example.com
Cookie: session=abc123def456; user_id=42 ← Session Token!
Authorization: Bearer eyJhbGciOiJIUzI1... ← JWT Token!
◀ RESPONSE 93.184.216.34 -> 192.168.1.50
HTTP/1.1 200 OK
Content-Type: application/json
Set-Cookie: tracking=xyz789; Expires=...
{"user": "john", "email": "john@example.com"}
⚠️ WARNING: Sensitive data transmitted in cleartext!
- Session cookie: abc123def456
- JWT token detected
- Email address: john@example.com
─── Summary ───────────────────────────────────────────────────
Requests: 234
Sessions detected: 12
Credentials captured: 3 ⚠️
Images: 45 (exportable with --extract-images)
Implementation Hints: Combine TCP reassembly with HTTP parsing:
void on_tcp_stream_complete(struct tcp_flow *flow) {
if (flow->dst_port == 80 || flow->src_port == 80) {
parse_http_stream(flow);
}
}
void parse_http_stream(struct tcp_flow *flow) {
// Client stream contains requests
char *request = (char *)flow->client_stream;
parse_http_request(request);
// Server stream contains responses
char *response = (char *)flow->server_stream;
parse_http_response(response);
}
void parse_http_request(char *data) {
// First line: METHOD PATH VERSION
char method[16], path[1024], version[16];
sscanf(data, "%s %s %s", method, path, version);
// Headers until empty line
char *line = strtok(data, "\r\n");
while ((line = strtok(NULL, "\r\n")) && strlen(line) > 0) {
if (strncmp(line, "Cookie:", 7) == 0) {
extract_cookies(line + 8);
}
}
}
Learning milestones:
- You see HTTP requests → You understand HTTP basics
- You extract cookies → You understand session tracking
- You decode chunked responses → You understand transfer encoding
- You realize why HTTPS matters → You’ve seen credentials in cleartext
Project 8: Network Traffic Visualizer
- File: NETWORK_SCANNING_PACKET_ANALYSIS_MASTERY.md
- Main Programming Language: Python
- Alternative Programming Languages: Go, JavaScript/Electron, Rust
- Coolness Level: Level 3: Genuinely Clever
- Business Potential: 2. The “Micro-SaaS / Pro Tool”
- Difficulty: Level 2: Intermediate
- Knowledge Area: Data Visualization / Network Monitoring
- Software or Tool: libpcap, ncurses/Web UI
- Main Book: “Practical Packet Analysis” by Chris Sanders
What you’ll build: A real-time visualization of network traffic showing connections between hosts, bandwidth usage, and protocol distribution—like a mini-Glasswire or ntopng.
Why it teaches Network Analysis: Visualization reveals patterns invisible in raw logs. You’ll see which hosts are chatty, who’s using the most bandwidth, and anomalous connection patterns.
Core challenges you’ll face:
- Real-time data aggregation → Maps to streaming analytics
- Connection tracking → Maps to flow state management
- Bandwidth calculation → Maps to byte counting per flow
- Graph layout → Maps to network topology visualization
- UI responsiveness → Maps to async architecture
Key Concepts:
- Traffic Analysis: “The Practice of Network Security Monitoring” Chapter 4 — Bejtlich
- Network Visualization: “Network Flow Analysis” — Michael Lucas
- ncurses Programming: “NCURSES Programming HOWTO” — Pradeep Padala
- Real-time Dashboards: “Designing Data-Intensive Applications” Chapter 11 — Kleppmann
Difficulty: Intermediate Time estimate: 2 weeks Prerequisites: Project 1, basic UI programming
Real world outcome:
┌─────────────────────────────────────────────────────────────────┐
│ Network Traffic Visualizer Packets: 45,231 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ [Router] │
│ 192.168.1.1 │
│ │ │
│ ├───[████████████]─── Laptop (192.168.1.50) │
│ │ 45.2 Mbps ↓ HTTP: 67%, HTTPS: 30%, DNS: 3% │
│ │ │
│ ├───[████]─────────── Phone (192.168.1.100) │
│ │ 12.1 Mbps ↓ HTTPS: 95%, DNS: 5% │
│ │ │
│ └───[██]───────────── IoT Cam (192.168.1.150) │
│ 3.2 Mbps ↑ UDP: 100% ⚠️ Uploading! │
│ │
├─────────────────────────────────────────────────────────────────┤
│ Top Destinations: Protocol Distribution: │
│ 1. google.com 23.4 MB [████████░░] TCP 82% │
│ 2. facebook.com 12.1 MB [██░░░░░░░░] UDP 15% │
│ 3. amazonaws.com 8.7 MB [░░░░░░░░░░] ICMP 3% │
└─────────────────────────────────────────────────────────────────┘
Implementation Hints: Data structures for aggregation:
from collections import defaultdict
from dataclasses import dataclass
@dataclass
class FlowStats:
bytes_sent: int = 0
bytes_recv: int = 0
packets: int = 0
protocols: dict = None # port -> bytes
flows = defaultdict(FlowStats) # (src_ip, dst_ip) -> stats
def update_stats(packet):
src = packet.ip.src
dst = packet.ip.dst
size = len(packet)
flows[(src, dst)].bytes_sent += size
flows[(src, dst)].packets += 1
if hasattr(packet, 'tcp'):
port = packet.tcp.dport
flows[(src, dst)].protocols[port] += size
For visualization, use:
- ncurses for terminal UI
- Plotly/Dash for web dashboard
- Dear ImGui for desktop app
Learning milestones:
- You see packet counts updating → Basic capture works
- You identify top talkers → You understand traffic patterns
- You spot anomalies → You can detect suspicious behavior
- You build a usable UI → You’ve created a real tool
Project 9: Intrusion Detection System (IDS)
- File: NETWORK_SCANNING_PACKET_ANALYSIS_MASTERY.md
- Main Programming Language: C
- Alternative Programming Languages: Rust, Go
- Coolness Level: Level 4: Hardcore Tech Flex
- Business Potential: 3. The “Service & Support” Model
- Difficulty: Level 4: Expert
- Knowledge Area: Network Security / Pattern Matching
- Software or Tool: libpcap, regex/pattern matching
- Main Book: “The Practice of Network Security Monitoring” by Richard Bejtlich
What you’ll build: A mini-Snort/Suricata that detects suspicious network patterns using rules—port scans, known malware signatures, SQL injection attempts, and more.
Why it teaches Network Security: IDS forces you to understand what “malicious” looks like at the packet level. You’ll learn attack signatures, evasion techniques, and the limits of signature-based detection.
Core challenges you’ll face:
- Rule parsing → Maps to Snort/Suricata rule format
- Pattern matching → Maps to deep packet inspection
- State tracking → Maps to flow-based detection
- Alert management → Maps to logging and notification
- Performance → Maps to high-speed packet processing
Key Concepts:
- IDS Concepts: “The Practice of Network Security Monitoring” Chapter 7 — Bejtlich
- Snort Rules: Snort documentation and rule writing guides
- Pattern Matching: Aho-Corasick algorithm for multi-pattern matching
- Attack Signatures: “Practical Packet Analysis” Chapter 10 — Sanders
Difficulty: Expert Time estimate: 1 month Prerequisites: Projects 1-7, security mindset
Real world outcome:
$ sudo ./mini_ids -i eth0 -r rules/default.rules
Mini-IDS v1.0 - Loading 1,234 rules...
Listening on eth0 in promiscuous mode...
[ALERT] [1:1000001:1] SCAN nmap SYN scan detected
Src: 192.168.1.200:54321 -> 192.168.1.1:22
Pattern: SYN to multiple ports from same source
[ALERT] [1:1000015:1] WEB-ATTACKS SQL injection attempt
Src: 10.0.0.50:48123 -> 192.168.1.100:80
Pattern: "' OR '1'='1" in HTTP request
Payload: GET /login?user=admin'%20OR%20'1'='1
[ALERT] [1:1000042:1] MALWARE known C2 callback
Src: 192.168.1.150:39182 -> 185.234.219.45:443
Pattern: TLS SNI matches known malware domain
Domain: evil-c2-server.ru
─── Statistics ───────────────────────────────────────────────
Packets analyzed: 1,234,567
Alerts triggered: 47
- Scan detection: 12
- Web attacks: 23
- Malware: 8
- Policy violations: 4
Implementation Hints: Rule format (Snort-like):
alert tcp any any -> $HOME_NET 80 (
msg:"SQL Injection attempt";
content:"' OR '"; nocase;
sid:1000015; rev:1;
)
alert tcp any any -> any any (
msg:"Nmap SYN scan";
flags:S;
detection_filter:track by_src, count 20, seconds 5;
sid:1000001; rev:1;
)
Rule matching engine:
struct rule {
char *msg;
int protocol; // TCP, UDP, ICMP
uint32_t src_ip, dst_ip;
uint16_t src_port, dst_port;
char *content; // String to match
int nocase; // Case-insensitive
uint8_t flags; // TCP flags
// Detection filter state
int count;
int seconds;
};
int match_rule(struct rule *r, uint8_t *packet, int len) {
// Check protocol
// Check IP addresses
// Check ports
// Check TCP flags
// Search for content in payload
if (r->content && !find_pattern(packet, r->content, r->nocase)) {
return 0;
}
return 1; // Match!
}
For performance, use Aho-Corasick for multi-pattern matching.
Learning milestones:
- You detect port scans → You understand scan signatures
- You detect SQL injection → You understand web attack patterns
- You add custom rules → You understand rule syntax
- You handle high traffic → You understand performance challenges
Project 10: Packet Injection / Crafting Tool
- File: NETWORK_SCANNING_PACKET_ANALYSIS_MASTERY.md
- Main Programming Language: C
- Alternative Programming Languages: Rust, Python (Scapy-like)
- Coolness Level: Level 4: Hardcore Tech Flex
- Business Potential: 1. The “Resume Gold”
- Difficulty: Level 4: Expert
- Knowledge Area: Network Security / Packet Crafting
- Software or Tool: Raw Sockets
- Main Book: “Hacking: The Art of Exploitation” by Jon Erickson
What you’ll build: A tool that crafts and injects custom packets with arbitrary headers—allowing you to test firewalls, spoof addresses, or create custom protocol traffic.
Why it teaches Low-Level Networking: Creating packets from scratch forces complete understanding of every header field, checksum calculation, and protocol interaction. This is the deepest level of network knowledge.
Core challenges you’ll face:
- IP header construction → Maps to IP protocol details
- TCP header with valid checksum → Maps to pseudo-header calculation
- Spoofing source addresses → Maps to raw socket permissions
- Receiving responses → Maps to promiscuous capture
- Avoiding detection → Maps to protocol compliance
Key Concepts:
- Raw Socket Sending: “The Linux Programming Interface” Chapter 58 — Kerrisk
- Checksum Calculation: “TCP/IP Illustrated, Volume 1” Chapter 3 — Stevens
- Packet Crafting: “Hacking: The Art of Exploitation” Chapter 4 — Erickson
- Protocol Compliance: RFC 791 (IP), RFC 793 (TCP)
Difficulty: Expert Time estimate: 2-3 weeks Prerequisites: Projects 1-2, deep protocol understanding
Real world outcome:
# Craft a custom SYN packet with spoofed source
$ sudo ./packet_craft --syn \
--src-ip 10.0.0.1 --src-port 12345 \
--dst-ip 192.168.1.1 --dst-port 80
Crafted packet (54 bytes):
Ethernet: 00:11:22:33:44:55 -> ff:ff:ff:ff:ff:ff
IP: 10.0.0.1 -> 192.168.1.1 (proto: TCP)
TCP: 12345 -> 80 [SYN] Seq=1234567890
Checksum: 0x3a7f (valid)
Packet sent!
# Test firewall rules with crafted packets
$ sudo ./packet_craft --icmp-echo \
--src-ip 8.8.8.8 \
--dst-ip 192.168.1.100
# Craft a custom DNS query
$ sudo ./packet_craft --udp \
--dst-ip 8.8.8.8 --dst-port 53 \
--payload-hex "0001010000010000000000000377777706676f6f676c6503636f6d0000010001"
Implementation Hints: TCP checksum requires a “pseudo-header”:
struct pseudo_header {
uint32_t src_addr;
uint32_t dst_addr;
uint8_t placeholder;
uint8_t protocol;
uint16_t tcp_length;
};
uint16_t tcp_checksum(struct iphdr *ip, struct tcphdr *tcp, int tcp_len) {
struct pseudo_header psh;
psh.src_addr = ip->saddr;
psh.dst_addr = ip->daddr;
psh.placeholder = 0;
psh.protocol = IPPROTO_TCP;
psh.tcp_length = htons(tcp_len);
// Checksum over pseudo-header + TCP header + data
char buf[65535];
memcpy(buf, &psh, sizeof(psh));
memcpy(buf + sizeof(psh), tcp, tcp_len);
return checksum((uint16_t *)buf, sizeof(psh) + tcp_len);
}
uint16_t checksum(uint16_t *ptr, int nbytes) {
uint32_t sum = 0;
while (nbytes > 1) {
sum += *ptr++;
nbytes -= 2;
}
if (nbytes == 1) {
sum += *(uint8_t *)ptr;
}
sum = (sum >> 16) + (sum & 0xffff);
sum += (sum >> 16);
return (uint16_t)(~sum);
}
Send via raw socket:
int sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW);
int one = 1;
setsockopt(sock, IPPROTO_IP, IP_HDRINCL, &one, sizeof(one));
sendto(sock, packet, packet_len, 0,
(struct sockaddr *)&dest_addr, sizeof(dest_addr));
Learning milestones:
- ICMP ping works → You can craft basic packets
- TCP SYN with valid checksum → You understand checksums
- Spoofed packets reach target → You understand raw sockets
- You test firewall rules → You can use this for security testing
Project 11: ARP Spoofer and Detector
- File: NETWORK_SCANNING_PACKET_ANALYSIS_MASTERY.md
- Main Programming Language: C
- Alternative Programming Languages: Python, Rust
- Coolness Level: Level 4: Hardcore Tech Flex
- Business Potential: 3. The “Service & Support” Model
- Difficulty: Level 3: Advanced
- Knowledge Area: Network Security / MITM Attacks
- Software or Tool: Raw Sockets, ARP
- Main Book: “Hacking: The Art of Exploitation” by Jon Erickson
What you’ll build: Both sides of ARP attacks—a spoofer that can position you as man-in-the-middle, and a detector that alerts when ARP spoofing is occurring on your network.
Why it teaches Network Security: ARP spoofing is a fundamental attack vector on local networks. Understanding it reveals why Layer 2 is inherently insecure and how MITM attacks work.
Core challenges you’ll face:
- Gratuitous ARP → Maps to ARP cache poisoning
- Continuous spoofing → Maps to maintaining MITM position
- Traffic forwarding → Maps to IP forwarding
- Detection via inconsistencies → Maps to anomaly detection
- Ethical considerations → Maps to authorized testing only
Key Concepts:
- ARP Spoofing: “Hacking: The Art of Exploitation” Chapter 4 — Erickson
- MITM Attacks: “Penetration Testing” Chapter 8 — Georgia Weidman
- ARP Cache: “TCP/IP Illustrated, Volume 1” Chapter 4 — Stevens
- Detection Methods: “The Practice of Network Security Monitoring” Chapter 6 — Bejtlich
Difficulty: Advanced Time estimate: 1-2 weeks Prerequisites: Project 3 (ARP), Project 10 (packet crafting)
Real world outcome:
# ARP Spoofer (use only on networks you own!)
$ sudo ./arp_spoof --target 192.168.1.100 --gateway 192.168.1.1
[*] Getting MAC addresses...
Target: 192.168.1.100 -> f0:18:98:ab:cd:ef
Gateway: 192.168.1.1 -> 00:1a:2b:3c:4d:5e
[*] Starting ARP spoofing...
Telling 192.168.1.100 that 192.168.1.1 is at OUR MAC
Telling 192.168.1.1 that 192.168.1.100 is at OUR MAC
[*] Enabling IP forwarding...
[*] MITM position established! Traffic now flows through us.
Captured 1,234 packets, 456 KB
Press Ctrl+C to stop and restore ARP tables...
─────────────────────────────────────────────────────────────
# ARP Spoof Detector (run on any machine)
$ sudo ./arp_detect eth0
ARP Spoof Detector - Monitoring eth0
═══════════════════════════════════════════════════════════════
[14:32:01] ARP table: 192.168.1.1 -> 00:1a:2b:3c:4d:5e (Gateway)
[14:32:01] ARP table: 192.168.1.50 -> dc:a6:32:12:34:56 (Laptop)
[14:35:22] ⚠️ WARNING: ARP conflict detected!
192.168.1.1 was 00:1a:2b:3c:4d:5e
192.168.1.1 now claims to be 00:11:22:33:44:55
POSSIBLE ARP SPOOFING ATTACK!
[14:35:22] ⚠️ Gratuitous ARP detected from 00:11:22:33:44:55
Multiple IPs claimed: 192.168.1.1, 192.168.1.100
MITM ATTACK LIKELY IN PROGRESS!
Implementation Hints: ARP spoofing loop:
void arp_spoof(char *target_ip, char *gateway_ip, uint8_t *target_mac, uint8_t *gateway_mac) {
// Tell target that WE are the gateway
send_arp_reply(target_ip, target_mac, gateway_ip, our_mac);
// Tell gateway that WE are the target
send_arp_reply(gateway_ip, gateway_mac, target_ip, our_mac);
}
// Must run continuously (ARP caches expire)
while (running) {
arp_spoof(target, gateway, target_mac, gateway_mac);
sleep(2);
}
Detection via ARP table monitoring:
struct arp_entry {
uint32_t ip;
uint8_t mac[6];
time_t first_seen;
};
void on_arp_packet(struct arp_packet *arp) {
struct arp_entry *existing = find_entry(arp->sender_ip);
if (existing && memcmp(existing->mac, arp->sender_mac, 6) != 0) {
// MAC changed for same IP!
alert("ARP spoofing detected! IP %s changed MAC",
ip_to_str(arp->sender_ip));
}
// Also detect: multiple IPs claiming same MAC (MITM indicator)
}
Learning milestones:
- You redirect traffic through yourself → You understand MITM
- You see victim’s traffic → You understand the attack impact
- Detector catches your spoofer → You understand detection
- You understand mitigations → Static ARP, 802.1X, VLANs
Project 12: PCAP File Analyzer
- File: NETWORK_SCANNING_PACKET_ANALYSIS_MASTERY.md
- Main Programming Language: C
- Alternative Programming Languages: Rust, Python, Go
- Coolness Level: Level 2: Practical but Forgettable
- Business Potential: 2. The “Micro-SaaS / Pro Tool”
- Difficulty: Level 2: Intermediate
- Knowledge Area: File Formats / Forensics
- Software or Tool: libpcap/PCAP format
- Main Book: “Practical Packet Analysis” by Chris Sanders
What you’ll build: A tool that reads PCAP files (Wireshark captures), analyzes the traffic, and generates statistics, extracts files, or searches for patterns.
Why it teaches Forensics: Real-world packet analysis often happens on saved captures, not live traffic. Understanding the PCAP format and building analysis tools is essential for incident response.
Core challenges you’ll face:
- PCAP file format → Maps to file format parsing
- Timestamp handling → Maps to time-based analysis
- Large file processing → Maps to streaming analysis
- File extraction (carving) → Maps to protocol-level extraction
- Search/filter → Maps to BPF compilation
Key Concepts:
- PCAP Format: libpcap documentation, Wireshark Developer’s Guide
- File Carving: “Practical Packet Analysis” Chapter 9 — Sanders
- Forensic Analysis: “Network Forensics” by Sherri Davidoff
- BPF Filters: tcpdump documentation
Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Project 1, file I/O experience
Real world outcome:
$ ./pcap_analyzer capture.pcap
PCAP Analysis Report
═══════════════════════════════════════════════════════════════
File: capture.pcap
Size: 45.2 MB
Duration: 00:15:23 (2024-12-20 14:00:00 - 14:15:23)
Packets: 123,456
─── Traffic Summary ───────────────────────────────────────────
Total bytes: 892.3 MB
Protocols:
TCP: 89,234 packets (72.3%)
UDP: 31,456 packets (25.5%)
ICMP: 2,766 packets (2.2%)
─── Top Conversations ─────────────────────────────────────────
1. 192.168.1.50 <-> 142.250.80.46:443 234.5 MB (HTTPS)
2. 192.168.1.50 <-> 104.18.6.192:443 89.2 MB (HTTPS)
3. 192.168.1.50 <-> 93.184.216.34:80 45.1 MB (HTTP)
─── Extracted Files ───────────────────────────────────────────
1. image_001.jpg (234 KB) from 93.184.216.34
2. document.pdf (1.2 MB) from 93.184.216.34
3. script.js (45 KB) from 142.250.80.46
$ ./pcap_analyzer capture.pcap --filter "tcp port 80" --extract-http
Extracted 47 HTTP objects to ./extracted/
Implementation Hints: PCAP file structure:
// Global header (24 bytes)
struct pcap_file_header {
uint32_t magic; // 0xa1b2c3d4 or 0xd4c3b2a1 (endianness)
uint16_t version_major;
uint16_t version_minor;
int32_t thiszone; // GMT offset
uint32_t sigfigs;
uint32_t snaplen; // Max bytes per packet
uint32_t network; // Link-layer type (1 = Ethernet)
};
// Packet header (16 bytes each)
struct pcap_pkthdr {
uint32_t ts_sec; // Timestamp seconds
uint32_t ts_usec; // Timestamp microseconds
uint32_t caplen; // Captured length
uint32_t len; // Original length
};
Using libpcap for reading:
pcap_t *handle = pcap_open_offline("capture.pcap", errbuf);
struct pcap_pkthdr *header;
const u_char *packet;
while (pcap_next_ex(handle, &header, &packet) >= 0) {
analyze_packet(packet, header->caplen);
}
Learning milestones:
- You read PCAP files → You understand the format
- You generate statistics → You can analyze captures
- You extract files → You understand file carving
- You filter by BPF → You understand packet filtering
Project 13: TLS Handshake Analyzer
- File: NETWORK_SCANNING_PACKET_ANALYSIS_MASTERY.md
- Main Programming Language: C
- Alternative Programming Languages: Rust, Go
- Coolness Level: Level 3: Genuinely Clever
- Business Potential: 3. The “Service & Support” Model
- Difficulty: Level 3: Advanced
- Knowledge Area: Cryptography / TLS Protocol
- Software or Tool: libpcap
- Main Book: “Bulletproof TLS and PKI” by Ivan Ristić
What you’ll build: A tool that captures TLS handshakes and extracts metadata—server names (SNI), certificate chains, cipher suites, and protocol versions—without decrypting the traffic.
Why it teaches Encrypted Traffic: Even encrypted traffic leaks metadata. TLS handshakes reveal who you’re talking to, what ciphers are used, and certificate details—all in cleartext before encryption begins.
Core challenges you’ll face:
- TLS record layer → Maps to record protocol parsing
- Handshake messages → Maps to ClientHello/ServerHello
- SNI extraction → Maps to extension parsing
- Certificate parsing → Maps to X.509/ASN.1
- JA3 fingerprinting → Maps to client identification
Key Concepts:
- TLS Protocol: “Bulletproof TLS and PKI” Chapters 1-4 — Ristić
- TLS Handshake: “Serious Cryptography” Chapter 16 — Aumasson
- JA3 Fingerprinting: Salesforce JA3 documentation
- X.509 Certificates: “Bulletproof TLS and PKI” Chapter 6 — Ristić
Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Projects 1-4, basic crypto understanding
Real world outcome:
$ sudo ./tls_analyzer eth0
TLS Handshake Analyzer - Monitoring port 443
═══════════════════════════════════════════════════════════════
[14:32:01] TLS Handshake: 192.168.1.50:52341 -> 142.250.80.46:443
ClientHello:
Version: TLS 1.2 (supported: TLS 1.3)
SNI: www.google.com
Cipher Suites (17):
- TLS_AES_128_GCM_SHA256
- TLS_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
...
JA3 Hash: 769,47-53-5-10-49161-49162,0-23-65281,29-23-24,0
JA3 Fingerprint: a0e9f5d64349fb13191bc781f81f42e1
ServerHello:
Version: TLS 1.3
Selected Cipher: TLS_AES_128_GCM_SHA256
Certificate:
Subject: CN=www.google.com
Issuer: CN=GTS CA 1C3, O=Google Trust Services LLC
Valid: 2024-11-20 to 2025-02-12
SANs: www.google.com, *.google.com, google.com
─── Summary ───────────────────────────────────────────────────
Handshakes captured: 234
TLS 1.3: 89% TLS 1.2: 11%
Unique SNIs: 45
Unique JA3 fingerprints: 12 (possible client profiling)
Implementation Hints: TLS record structure:
struct tls_record {
uint8_t content_type; // 22 = Handshake
uint16_t version; // 0x0301 = TLS 1.0 (misleading)
uint16_t length;
uint8_t data[];
};
struct tls_handshake {
uint8_t msg_type; // 1 = ClientHello, 2 = ServerHello
uint24_t length; // 3 bytes!
uint8_t data[];
};
Parsing ClientHello for SNI:
void parse_client_hello(uint8_t *data, int len) {
uint8_t *ptr = data;
uint16_t version = ntohs(*(uint16_t*)ptr); ptr += 2;
ptr += 32; // Skip random
uint8_t session_len = *ptr++; ptr += session_len;
uint16_t cipher_len = ntohs(*(uint16_t*)ptr); ptr += 2 + cipher_len;
uint8_t comp_len = *ptr++; ptr += comp_len;
// Extensions
uint16_t ext_len = ntohs(*(uint16_t*)ptr); ptr += 2;
while (ptr < data + len) {
uint16_t ext_type = ntohs(*(uint16_t*)ptr); ptr += 2;
uint16_t ext_len = ntohs(*(uint16_t*)ptr); ptr += 2;
if (ext_type == 0) { // SNI extension
// Parse SNI list
ptr += 2; // List length
uint8_t name_type = *ptr++;
uint16_t name_len = ntohs(*(uint16_t*)ptr); ptr += 2;
printf("SNI: %.*s\n", name_len, ptr);
}
ptr += ext_len;
}
}
Learning milestones:
- You extract SNI → You understand TLS metadata
- You parse certificates → You understand PKI
- You generate JA3 hashes → You understand fingerprinting
- You identify weak configurations → You understand TLS security
Project 14: Network Bandwidth Monitor
- File: NETWORK_SCANNING_PACKET_ANALYSIS_MASTERY.md
- Main Programming Language: C
- Alternative Programming Languages: Go, Rust, Python
- Coolness Level: Level 2: Practical but Forgettable
- Business Potential: 2. The “Micro-SaaS / Pro Tool”
- Difficulty: Level 2: Intermediate
- Knowledge Area: Network Monitoring / Statistics
- Software or Tool: libpcap, ncurses
- Main Book: “Network Flow Analysis” by Michael Lucas
What you’ll build: A real-time bandwidth monitor showing per-host and per-application traffic usage, like iftop or nethogs.
Why it teaches Traffic Analysis: Understanding who’s using bandwidth requires tracking flows over time. This project teaches flow accounting, rate calculation, and real-time display.
Core challenges you’ll face:
- Per-flow byte counting → Maps to flow tracking
- Rate calculation → Maps to time-series data
- Process identification → Maps to socket-to-PID mapping
- Real-time display → Maps to ncurses/UI
- Historical data → Maps to circular buffers
Key Concepts:
- Flow Accounting: “Network Flow Analysis” Chapter 3 — Lucas
- Rate Calculation: sliding window algorithms
- Socket-PID Mapping: /proc/net/tcp parsing on Linux
- ncurses: “NCURSES Programming HOWTO”
Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Project 1, basic statistics
Real world outcome:
┌─────────────────────────────────────────────────────────────────┐
│ Bandwidth Monitor - eth0 [q]uit │
├─────────────────────────────────────────────────────────────────┤
│ Total: ▼ 45.2 Mbps ▲ 12.3 Mbps │
│ │
│ Source Destination ▼ Down ▲ Up PID │
│ ───────────────────────────────────────────────────────────── │
│ 192.168.1.50 youtube.com:443 32.1 MB/s 1.2 MB/s 1234│
│ 192.168.1.50 spotify.com:443 8.2 MB/s 0.1 MB/s 5678│
│ 192.168.1.50 github.com:443 2.1 MB/s 0.5 MB/s 9012│
│ 192.168.1.50 192.168.1.1:53 0.1 MB/s 0.1 MB/s (dns)│
│ │
│ ──────────────────────────────────────────────────────────────│
│ Process Breakdown: │
│ chrome (PID 1234) 32.5 MB/s │
│ spotify (PID 5678) 8.3 MB/s │
│ git (PID 9012) 2.6 MB/s │
└─────────────────────────────────────────────────────────────────┘
Implementation Hints: Flow tracking with rate calculation:
struct flow {
uint32_t src_ip, dst_ip;
uint16_t src_port, dst_port;
uint64_t bytes_down;
uint64_t bytes_up;
// For rate calculation
uint64_t last_bytes_down;
uint64_t last_bytes_up;
time_t last_update;
double rate_down; // bytes/sec
double rate_up;
};
void update_rate(struct flow *f) {
time_t now = time(NULL);
double elapsed = difftime(now, f->last_update);
if (elapsed > 0) {
f->rate_down = (f->bytes_down - f->last_bytes_down) / elapsed;
f->rate_up = (f->bytes_up - f->last_bytes_up) / elapsed;
f->last_bytes_down = f->bytes_down;
f->last_bytes_up = f->bytes_up;
f->last_update = now;
}
}
Socket-to-PID mapping on Linux:
// Parse /proc/net/tcp to find which PID owns a socket
// Format: local_address:port remote_address:port ... inode
// Then search /proc/*/fd/* for socket:[inode]
Learning milestones:
- You see byte counts → Basic flow tracking works
- Rates calculate correctly → Time-series analysis works
- You identify processes → You understand socket ownership
- Real-time display works → You built a usable tool
Project 15: WiFi Probe Request Monitor
- File: NETWORK_SCANNING_PACKET_ANALYSIS_MASTERY.md
- Main Programming Language: C
- Alternative Programming Languages: Python, Rust
- Coolness Level: Level 3: Genuinely Clever
- Business Potential: 1. The “Resume Gold”
- Difficulty: Level 3: Advanced
- Knowledge Area: Wireless Security / 802.11
- Software or Tool: libpcap, Monitor Mode
- Main Book: “802.11 Wireless Networks: The Definitive Guide” by Matthew Gast
What you’ll build: A WiFi monitor that captures probe requests from nearby devices, revealing their MAC addresses, device types, and networks they’re looking for.
Why it teaches Wireless Security: Phones constantly broadcast probe requests looking for known networks. This reveals movement patterns, device inventory, and preferred networks—major privacy implications.
Core challenges you’ll face:
- Monitor mode → Maps to WiFi promiscuous capture
- 802.11 frame parsing → Maps to wireless protocol structure
- Radiotap header → Maps to PHY-layer metadata
- SSID extraction → Maps to probe request analysis
- MAC randomization detection → Maps to privacy countermeasures
Key Concepts:
- 802.11 Protocol: “802.11 Wireless Networks” Chapters 4-5 — Gast
- Monitor Mode: “Linux Basics for Hackers” Chapter 15 — OccupyTheWeb
- Radiotap Header: radiotap.org specification
- WiFi Privacy: Research on MAC randomization effectiveness
Difficulty: Advanced Time estimate: 2 weeks Prerequisites: Project 1, WiFi adapter supporting monitor mode
Real world outcome:
$ sudo ./wifi_probe_monitor wlan0mon
WiFi Probe Request Monitor
═══════════════════════════════════════════════════════════════
[14:32:01] MAC: f0:18:98:ab:cd:ef (Apple, Inc.)
Signal: -45 dBm
Probing for: "HomeNetwork", "Starbucks WiFi", "ATT-WiFi"
[14:32:02] MAC: dc:a6:32:12:34:56 (Raspberry Pi)
Signal: -60 dBm
Probing for: "IoT-Network"
[14:32:03] MAC: 4a:3b:2c:1d:0e:ff (Randomized) ⚠️
Signal: -52 dBm
Probing for: <broadcast> (no specific SSID)
Note: MAC randomization detected
─── Statistics ───────────────────────────────────────────────
Unique devices: 47
Unique SSIDs probed: 89
Randomized MACs: 23 (49%)
Top SSIDs:
"ATT-WiFi-xxxx": 12 devices
"xfinitywifi": 8 devices
"Starbucks": 6 devices
# This reveals: what networks are popular, device inventory,
# and that ~half of devices use MAC randomization
Implementation Hints: Enable monitor mode:
# Set interface to monitor mode
sudo ip link set wlan0 down
sudo iw wlan0 set monitor none
sudo ip link set wlan0 up
# Or use airmon-ng start wlan0
Parse 802.11 frames:
// Radiotap header varies in length
struct radiotap_header {
uint8_t version;
uint8_t pad;
uint16_t len; // Total radiotap length
uint32_t present; // Bitmap of present fields
};
// 802.11 frame control
struct ieee80211_hdr {
uint16_t frame_control; // Type, subtype, flags
uint16_t duration;
uint8_t addr1[6]; // Destination/receiver
uint8_t addr2[6]; // Source/transmitter
uint8_t addr3[6]; // BSSID
uint16_t seq_ctrl;
};
// Probe request: subtype 0x0040
// Extract SSID from tagged parameters after header
Detect MAC randomization:
int is_randomized_mac(uint8_t *mac) {
// Locally administered bit is set (second-least significant bit of first byte)
return (mac[0] & 0x02) != 0;
}
Learning milestones:
- You see probe requests → You understand 802.11 basics
- You extract SSIDs → You understand frame structure
- You detect randomization → You understand privacy measures
- You realize the privacy implications → You see why this matters
Project Comparison Table
| Project | Difficulty | Time | Depth of Understanding | Fun Factor |
|---|---|---|---|---|
| 1. Raw Socket Sniffer | Advanced | 1-2 weeks | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| 2. Port Scanner | Advanced | 2-3 weeks | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 3. ARP Scanner | Intermediate | 1 week | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| 4. Protocol Dissector | Advanced | 2-3 weeks | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 5. TCP Reassembler | Expert | 3-4 weeks | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| 6. DNS Analyzer | Intermediate | 1-2 weeks | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| 7. HTTP Inspector | Advanced | 2 weeks | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 8. Traffic Visualizer | Intermediate | 2 weeks | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 9. IDS | Expert | 1 month | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 10. Packet Crafter | Expert | 2-3 weeks | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 11. ARP Spoofer/Detector | Advanced | 1-2 weeks | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 12. PCAP Analyzer | Intermediate | 1-2 weeks | ⭐⭐⭐ | ⭐⭐⭐ |
| 13. TLS Analyzer | Advanced | 2-3 weeks | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 14. Bandwidth Monitor | Intermediate | 1-2 weeks | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| 15. WiFi Probe Monitor | Advanced | 2 weeks | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
Recommended Learning Paths
If you’re new to networking:
- Project 1: Raw Socket Sniffer — See packets for the first time
- Project 3: ARP Scanner — Understand Layer 2
- Project 6: DNS Analyzer — Understand a real protocol
- Project 2: Port Scanner — Understand TCP deeply
If you want to understand security:
- Project 2: Port Scanner — How attackers find targets
- Project 11: ARP Spoofer — How MITM works
- Project 9: IDS — How to detect attacks
- Project 10: Packet Crafter — How to test defenses
If you want to build monitoring tools:
- Project 1: Raw Socket Sniffer — Foundation
- Project 4: Protocol Dissector — Decode protocols
- Project 8: Traffic Visualizer — Present data
- Project 14: Bandwidth Monitor — Track usage
If you want forensics skills:
- Project 12: PCAP Analyzer — Read captures
- Project 5: TCP Reassembler — Reconstruct sessions
- Project 7: HTTP Inspector — Extract web traffic
- Project 13: TLS Analyzer — Analyze encrypted connections
Capstone Project: Full Network Security Monitor
- File: NETWORK_SCANNING_PACKET_ANALYSIS_MASTERY.md
- Main Programming Language: C
- Alternative Programming Languages: Rust, Go
- Coolness Level: Level 5: Pure Magic (Super Cool)
- Business Potential: 4. The “Open Core” Infrastructure
- Difficulty: Level 5: Master
- Knowledge Area: Network Security / Complete System
- Software or Tool: libpcap, ncurses, SQLite
- Main Book: “The Practice of Network Security Monitoring” by Richard Bejtlich
What you’ll build: A complete network security monitoring system combining packet capture, protocol analysis, traffic visualization, anomaly detection, and alerting—a mini Security Onion.
Why it’s the ultimate project: This integrates every previous project into a production-grade tool. You’ll understand why tools like Zeek, Snort, and Wireshark are architected the way they are.
Core challenges you’ll face:
- All previous challenges combined
- Data persistence → Maps to database design for network data
- Dashboard design → Maps to security operations UX
- Alert correlation → Maps to event analysis
- Performance at scale → Maps to high-speed packet processing
Key Concepts:
- All previous resources, plus:
- NSM Architecture: “The Practice of Network Security Monitoring” — Bejtlich
- Zeek Design: Zeek documentation
- Time-series Databases: InfluxDB/Prometheus documentation
Difficulty: Master Time estimate: 3-6 months Prerequisites: All previous projects
Real world outcome:
┌─────────────────────────────────────────────────────────────────┐
│ Network Security Monitor v1.0 [LIVE] │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─ Alerts ──────────────┐ ┌─ Traffic Overview ──────────────┐│
│ │ ⚠️ Port scan detected │ │ ▼45.2 Mbps ▲12.3 Mbps ││
│ │ ⚠️ DNS tunneling │ │ [█████████░] 892.3 MB today ││
│ │ ⚠️ New host on network│ │ Protocols: TCP 82% UDP 15% ││
│ └───────────────────────┘ └─────────────────────────────────┘│
│ │
│ ┌─ Connection Log ────────────────────────────────────────────┐│
│ │ 14:32:01 192.168.1.50 -> google.com:443 (TLS 1.3) ││
│ │ 14:32:01 192.168.1.50 -> 8.8.8.8:53 (DNS: google.com) ││
│ │ 14:32:02 192.168.1.100 -> suspicious.ru:80 (HTTP) ⚠️ ││
│ └─────────────────────────────────────────────────────────────┘│
│ │
│ ┌─ Hosts ─────────────────┐ ┌─ DNS Queries ─────────────────┐│
│ │ 192.168.1.1 (Router) │ │ google.com 123 queries ││
│ │ 192.168.1.50 (Laptop) │ │ facebook.com 89 queries ││
│ │ 192.168.1.100 (Phone) │ │ suspicious.ru 1 query ⚠️ ││
│ │ 192.168.1.150 (IoT) │ │ evil-c2.net 3 queries ⚠️││
│ └─────────────────────────┘ └─────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────┘
$ ./nsm --query "last 24h alerts severity:high"
3 high-severity alerts:
[2024-12-20 10:23] Port scan from 192.168.1.200 (100+ ports)
[2024-12-20 14:32] DNS tunneling detected to evil-c2.net
[2024-12-20 15:01] Known malware C2 callback from 192.168.1.150
Implementation Hints: Architecture:
- Capture Engine (C): High-performance packet capture
- Protocol Parsers: Modular dissectors for each protocol
- Flow Tracker: Connection state management
- Detection Engine: IDS rules + anomaly detection
- Storage Layer: SQLite/LevelDB for logs, time-series for metrics
- Dashboard: ncurses or web-based UI
- Alert Manager: Event correlation and notification
Design for extensibility:
- Plugin architecture for new protocols
- Lua scripting for custom detection (like Zeek)
- REST API for external integration
Learning milestones:
- Packet capture works at high speed → Core architecture solid
- Multiple protocols decode → Parser framework works
- Alerts fire correctly → Detection engine works
- Dashboard shows real-time data → Full integration
- You catch a real attack → You built a production tool
Summary
| # | Project Name | Main Language |
|---|---|---|
| 1 | Raw Socket Packet Sniffer | C |
| 2 | TCP Port Scanner (Mini-Nmap) | C |
| 3 | ARP Network Discovery Tool | C |
| 4 | Protocol Dissector / Packet Decoder | C |
| 5 | TCP Stream Reassembler | C |
| 6 | DNS Traffic Analyzer | C |
| 7 | HTTP Traffic Inspector | C |
| 8 | Network Traffic Visualizer | Python |
| 9 | Intrusion Detection System (IDS) | C |
| 10 | Packet Injection / Crafting Tool | C |
| 11 | ARP Spoofer and Detector | C |
| 12 | PCAP File Analyzer | C |
| 13 | TLS Handshake Analyzer | C |
| 14 | Network Bandwidth Monitor | C |
| 15 | WiFi Probe Request Monitor | C |
| Capstone | Full Network Security Monitor | C |
Important Ethical Notes
⚠️ Authorization Required: Many of these projects involve capturing network traffic or sending packets that could affect other systems. Only use these tools on:
- Networks you own
- Networks where you have explicit written authorization
- Isolated lab environments
Unauthorized network scanning or packet capture may violate:
- Computer Fraud and Abuse Act (US)
- Computer Misuse Act (UK)
- Similar laws in other jurisdictions
Always get permission first.
Sources
Web Resources Consulted:
- Nmap Port Scanning Techniques
- TCP SYN Scan - Nmap
- UDP Scan - Nmap
- How to Code Packet Sniffer in C - BinaryTides
- Linux Socket Filter - Linux Journal
- Packet Sniffing - Paessler IT Explained
- SYN Scanning - TechTarget
- Practical Packet Analysis - No Starch Press
Books Referenced:
- “TCP/IP Illustrated, Volume 1: The Protocols” by W. Richard Stevens
- “The Linux Programming Interface” by Michael Kerrisk
- “Nmap Network Scanning” by Gordon Lyon (Fyodor)
- “Practical Packet Analysis” by Chris Sanders
- “The Practice of Network Security Monitoring” by Richard Bejtlich
- “Hacking: The Art of Exploitation” by Jon Erickson
- “Computer Networks” by Andrew S. Tanenbaum
- “DNS and BIND” by Cricket Liu
- “Bulletproof TLS and PKI” by Ivan Ristić
- “HTTP: The Definitive Guide” by Gourley & Totty
- “802.11 Wireless Networks: The Definitive Guide” by Matthew Gast
- “The Sockets Networking API” by W. Richard Stevens