chapter-1/chapter-1.ipynb

{
 "cells": [
  {
   "cell_type": "markdown",
   "id": "16ef4aae-e71b-4940-8c47-76d1426f3c7c",
   "metadata": {},
   "source": [
    "# Chapter 1: Crafting a Rust-Based Network Sniffer\n",
    "\n",
    "[**Network sniffers**](https://en.wikipedia.org/wiki/Packet_analyzer), essential tools in understanding and analyzing data flow across networks, can be crafted from scratch with Rust. Rust's unique blend of performance and safety makes it an ideal choice for low-level network programming. In this exploration, we'll leverage the capabilities of the [**socket2**](https://github.com/rust-lang/socket2) crate, a powerful Rust library that provides abstractions for working with [**raw sockets**](https://en.wikipedia.org/wiki/Network_socket).\n",
    "\n",
    "Building a network sniffer requires a solid understanding of the fundamentals of raw network packets in Rust. In Rust, handling raw packets involves close interaction with sockets and meticulous byte manipulation. The `socket2` crate simplifies this process, offering abstractions that facilitate efficient packet capture and processing.\n",
    "\n",
    "Before we dive into the complexities of network sniffing, let's establish a foundation by understanding how Rust manages raw network packets. This understanding is pivotal as we construct our custom network sniffer, allowing us to delve deep into the world of low-level networking."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "4ec4ed77-fddd-4358-85b8-401115926814",
   "metadata": {},
   "source": [
    "## Table of Contents\n",
    "\n",
    "* [**Crafting a Rust Based Host Discovery Tool**](#1.-Crafting-a-Rust-Based-UDP-Host-Discovery-Tool)\n",
    "   * [**Network Exploration**](#1.1-Network-Exploration:-Decoding-the-Essence-of-UDP)\n",
    "   * [**Decoding the IP Layer**](#1.2-Decoding-the-IP-Layer-and-Uncover-Packet-Secrets)\n",
    "   * [**The IP Header Struct**](#1.3-The-IP-Header-Struct)\n",
    "   * [**Putting It All Together**](#1.4-Putting-It-All-Together)\n",
    "   * [**ICMP Structure Decoding**](#1.5-ICMP-Structure-Decoding)\n",
    "   * [**Decoding-TCP-packets**](#1.6-Decoding-TCP-packets)\n",
    "   * [**Decoding-UDP-packets**](#1.7-Decoding-UDP-packets)\n",
    "   * [**Port Scanning with SYN-flood Protections**](#1.8-Port-Scanning-in-the-Presence-of-SYN-flood-Protections)"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "ad1f3a57-c181-4673-9310-a78f9434e8d9",
   "metadata": {},
   "source": [
    "## 1. Crafting a Rust-Based UDP Host Discovery Tool\n",
    "\n",
    "In our pursuit to develop a robust [**UDP**](https://en.wikipedia.org/wiki/User_Datagram_Protocol) host discovery tool using Rust, the primary objective is to identify hosts within a target network. This tool holds significance in scenarios where a comprehensive overview of potential targets is sought, facilitating the streamlining of [**reconnaissance**](https://en.wikipedia.org/wiki/Footprinting) and exploitation efforts. The methodology relies on leveraging a well-established behavior exhibited by most operating systems when confronted with UDP datagrams directed at closed ports. Typically, a responsive host generates an ICMP message indicating that the port is unreachable. This [**ICMP**](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol) response serves as a valuable indicator of an active host, forming the basis for our host discovery mechanism.\n",
    "\n",
    "The deliberate selection of the User Datagram Protocol (UDP) stems from its inherent advantages in efficiently broadcasting messages across a subnet with minimal overhead. The lightweight nature of this protocol positions it as an ideal candidate for our purposes, emphasizing the goal of maximizing coverage while minimizing potential disruptions. A pivotal aspect of our approach involves the careful selection of a UDP port that is unlikely to be in active use, enabling us to probe multiple ports for comprehensive host coverage.\n",
    "\n",
    "Understanding the role of UDP in our host discovery tool necessitates a closer examination of its characteristics. UDP, characterized by its connectionless and lightweight nature, aligns seamlessly with our objective of quick and efficient host identification. The absence of overhead associated with connection-oriented protocols renders UDP well-suited for our purpose, as we intend to seamlessly broadcast messages and await ICMP responses. This strategic choice is not arbitrary; rather, it is a deliberate selection based on the efficiency and simplicity afforded by UDP in the context of host discovery.\n",
    "\n",
    "Delving into the complexities of our approach, the emphasis extends beyond constructing a basic host discovery tool to meticulous decoding and analysis of various network protocol headers. The true potency of our tool lies not only in its ability to identify hosts but also in its capacity to decipher the complex layers of network communications. Decoding network protocol headers necessitates a nuanced understanding of underlying structures, and Rust, with its focus on performance and safety, emerges as a dependable companion in this journey.\n",
    "\n",
    "As we kick off the implementation of this UDP host discovery tool, the scope extends beyond a singular operating system. The objective is to create a tool transcending platform limitations, catering to both Windows and Linux environments. This versatility is not merely a convenience but a strategic decision to enhance the tool's applicability, particularly in enterprise environments characterized by diverse operating systems.\n",
    "\n",
    "The prospective evolution of our tool goes beyond basic host discovery. We envision the incorporation of additional logic that could trigger comprehensive [**Nmap**](https://en.wikipedia.org/wiki/Nmap) port scans on any discovered hosts. This strategic enhancement adds a layer of sophistication, allowing for a deeper exploration of the network attack surface associated with each identified host. The decision to leave this as an exercise for the user underscores our commitment to fostering creativity and innovation within the realm of network exploration."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "354bc467-f62e-45cd-b34b-36964edde10d",
   "metadata": {},
   "source": [
    "### 1.1 Network Exploration: Decoding the Essence of UDP\n",
    "\n",
    "Packet sniffing, a fundamental aspect of network analysis, extends on Windows and Linux platforms, each requiring a distinct approach. To ensure adaptability across operating systems, we adopt a strategy that involves creating a socket object and dynamically determining the underlying platform. This platform awareness becomes particularly crucial as the complexities of raw socket access vary between Windows and Linux environments.\n",
    "\n",
    "On Windows, the process entails additional steps due to the need for setting specific flags via a socket input/output control (IOCTL) mechanism. This mechanism serves as a means of communication between user-space programs and kernel-mode components, facilitating the configuration of network interfaces to operate in [**promiscuous mode**](https://en.wikipedia.org/wiki/Promiscuous_mode). Promiscuous mode, a powerful but privileged state, allows the network interface to capture all incoming packets, regardless of their destination, providing a comprehensive view of network activity. The initiation of promiscuous mode on Windows involves the strategic use of IOCTL to enable the reception of all packets.\n",
    "\n",
    "In contrast, the Linux counterpart focuses on the specificity of protocols, where the example utilizes the Internet Control Message Protocol (ICMP) for packet sniffing. Linux, by default, requires a more targeted approach, necessitating the selection of a specific protocol for packet capture. The Rust implementation adeptly accommodates these differences, showcasing its platform-aware design.\n",
    "\n",
    "```rust\n",
    "use socket2::{Domain, Protocol, Socket, Type};\n",
    "use std::io::Result;\n",
    "use std::mem::MaybeUninit;\n",
    "use std::net::SocketAddr;\n",
    "\n",
    "fn main() -> Result<()> {\n",
    "    // Define the host to listen on\n",
    "    let host: SocketAddr = \"0.0.0.0:12345\".parse().unwrap();\n",
    "\n",
    "    let socket_protocol = if cfg!(target_os = \"windows\") {\n",
    "        0\n",
    "    } else {\n",
    "        1\n",
    "    };\n",
    "\n",
    "    // Create a raw socket\n",
    "    let sniffer = Socket::new(\n",
    "        Domain::IPV4,\n",
    "        Type::RAW,\n",
    "        Some(Protocol::from(socket_protocol)),\n",
    "    )?;\n",
    "    // bind to the public interface\n",
    "    sniffer.bind(&host.into())?;\n",
    "\n",
    "    // Read one packet\n",
    "    let mut buffer: [MaybeUninit<u8>; 65535] = unsafe { MaybeUninit::uninit().assume_init() };\n",
    "    let _ = sniffer.recv_from(&mut buffer)?;\n",
    "    let raw_buffer: &[u8] =\n",
    "        unsafe { std::slice::from_raw_parts(buffer.as_ptr() as *const u8, buffer.len()) };\n",
    "\n",
    "    // Print the captured packet\n",
    "    println!(\"{:?}\", raw_buffer);\n",
    "\n",
    "    Ok(())\n",
    "}\n",
    "```\n",
    "\n",
    "The provided Rust code exemplifies the initiation of a raw socket sniffer, starting with the definition of the host IP address to listen on. The subsequent steps involve the creation of a socket object, taking into account the protocol variations between Windows and Linux. In this context, the `cfg!(windows)` macro plays a pivotal role in conditionally determining the platform and adjusting the socket protocol accordingly.\n",
    "\n",
    "The default configuration of the socket will include IP headers in the captured packets, enhancing the depth of information gathered during the sniffing process. Moreover, the script automatically handles the complexities of promiscuous mode, a critical feature for comprehensive packet capture.\n",
    "\n",
    "While the provided Rust code captures a single packet for simplicity, it serves as a foundational example for more extensive network analysis tasks. The flexibility of Rust, combined with its platform-aware features, positions it as a reliable choice for crafting network tools that seamlessly operate across diverse operating systems. This illustrative example demystifies the complexities of packet sniffing on Windows and Linux, laying the groundwork for more sophisticated network exploration and analysis endeavors."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 2,
   "id": "a2b511ac-0243-4b97-af81-340eb4a7b78b",
   "metadata": {},
   "outputs": [],
   "source": [
    ":dep socket2 = {version = \"0.5.5\", features = [\"all\"]}"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 2,
   "id": "ef5b56e6-af6e-4465-89cd-cf7ea8238bf9",
   "metadata": {},
   "outputs": [],
   "source": [
    "use std::process::{Command, Output, Stdio};\n",
    "\n",
    "// A helper function to execute a shell command from a Rust script\n",
    "fn execute_command(command: &str) -> Result<(), std::io::Error> {\n",
    "    let status = Command::new(\"bash\")\n",
    "        .arg(\"-c\")\n",
    "        .arg(command)\n",
    "        .stderr(Stdio::inherit())\n",
    "        .status()?;\n",
    "\n",
    "    if status.success() {\n",
    "        Ok(())\n",
    "    } else {\n",
    "        Err(std::io::Error::from_raw_os_error(status.code().unwrap_or(1)))\n",
    "    }\n",
    "}"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 6,
   "id": "c4c5e390-3536-418e-a82e-71a6c6a5bed8",
   "metadata": {
    "scrolled": true
   },
   "outputs": [
    {
     "name": "stderr",
     "output_type": "stream",
     "text": [
      "[sudo] password for mahmoud:    Compiling decoding-the-essence-of-udp v0.1.0 (/home/mahmoud/Desktop/Rust Book Dark/dark-web-rust/chapter-1/decoding-the-essence-of-udp)\n",
      "    Finished dev [unoptimized + debuginfo] target(s) in 0.28s\n"
     ]
    },
    {
     "name": "stdout",
     "output_type": "stream",
     "text": [
      "[69, 0, 0, 84, 0, 0, 0, 0, 113, 1, 211, 15, 142, 251, 37, 238, 192, 168, 1, 8, 0, 0, 249, 9, 0, 21, 0, 1, 95, 67, 81, 101, 0, 0, 0, 0, 138, 100, 13, 0, 0, 0, 0, 0, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]\n"
     ]
    },
    {
     "data": {
      "text/plain": [
       "()"
      ]
     },
     "execution_count": 6,
     "metadata": {},
     "output_type": "execute_result"
    }
   ],
   "source": [
    "// The following command will execute the sniffer.\n",
    "// Set your sudo password below by replacing 'your-passowrd' accordingly\n",
    "\n",
    "let command = \"cd decoding-the-essence-of-udp && cargo build && echo 'your-passowrd' | sudo -S setcap cap_net_raw+ep target/debug/decoding-the-essence-of-udp && target/debug/decoding-the-essence-of-udp\";\n",
    "\n",
    "if let Err(err) = execute_command(command) {\n",
    "    eprintln!(\"Error executing command: {}\", err);\n",
    "}\n",
    "\n",
    "// In another terminal or shell window, choose a host to ping, for example: ping google.com"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "39bae1c1-79da-4671-900f-fba5af7f5a36",
   "metadata": {},
   "source": [
    "The displayed output indicates the successful capture of the initial ICMP ping request destined for the specified host. Running this example on Linux would yield the response from the pinged host.\n",
    "\n",
    "Capturing a single packet is limited in utility, prompting us to enhance the functionality to process more packets and decode their contents. Let's proceed by incorporating additional features into our sniffer code."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "bc352194-ee88-44aa-b4c7-20074e6031f7",
   "metadata": {},
   "source": [
    "### 1.2 Decoding the IP Layer and Uncover Packet Secrets\n",
    "\n",
    "Within the current implementation of our sniffer, we capture a lot of data, including IP headers and higher-level protocols such as [**TCP**](https://en.wikipedia.org/wiki/Transmission_Control_Protocol), [**UDP**](https://en.wikipedia.org/wiki/User_Datagram_Protocol), or [**ICMP**](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol). However, this information currently exists in an encoded binary form, presenting a significant challenge for comprehension. Our immediate objective is to decode the IP segment of a packet, a pivotal step that enables us to extract valuable insights. This includes determining the protocol type (TCP, UDP, or ICMP) and identifying the source and destination IP addresses. This decoding process sets the stage for a more profound understanding, forming the ground for parsing additional protocols in subsequent stages of our exploration.\n",
    "\n",
    "When examining an actual packet traversing the network, it becomes evident that decoding incoming packets requires a clear comprehension of their structure. The following table provides insight into the composition of an [**IP header**](https://en.wikipedia.org/wiki/IP_header), delineating its various fields.\n",
    "\n",
    "| Bit Offset   | Field              | Size (in bits) |\n",
    "|--------------|--------------------|----------------|\n",
    "| 0–3          | Version            | 4              |\n",
    "| 4–7          | HDR length         | 4              |\n",
    "| 8–15         | Type of service    | 8              |\n",
    "| 16–31        | Total length       | 16             |\n",
    "| 32–39        | Identification     | 8              |\n",
    "| 40–47        | Flags              | 8              |\n",
    "| 48–63        | Fragment offset    | 16             |\n",
    "| 64–71        | Time to live       | 8              |\n",
    "| 72–79        | Protocol           | 8              |\n",
    "| 80–95        | Header checksum    | 16             |\n",
    "| 96–127       | Source IP address  | 32             |\n",
    "| 128–159      | Destination IP address | 32         |\n",
    "| 160 onward   | Options            | Variable       |\n",
    "\n",
    "Our goal is to make sense of the IP header, excluding the last `Options` field, and focus on pulling out important information like the type of protocol, where the data is coming from (source IP), and where it's going (destination IP). To do this, we need a smart approach to break down each part of the IP header. For this task, we are using Rust which is good at handling this kind of challenge.\n",
    "\n",
    "As you may know, Rust provides us with a special tool called \"struct\", which is like a blueprint that helps us understand and organize the data we're dealing with. This tool works well with binary data, the language that computers speak.\n",
    "\n",
    "Now, let's dive into how we can use this Rust [**struct**](https://doc.rust-lang.org/std/keyword.struct.html) tool to read an IP header. Think of it like having a map that shows us the layout of the information we're looking for. Rust's struct acts like a guide, helping us decode the binary data that represents an IP header. It's like a decoder ring that makes sense of the mysterious binary language.\n",
    "\n",
    "Understanding Rust's struct is like learning the rules of a game. The rules help us play efficiently and understand how the game works. Similarly, Rust's struct has its own set of rules that help us interpret the binary data and understand what each part of the IP header means.\n",
    "\n",
    "As we go through the steps of using Rust's struct to read an IP header, think of it as following a recipe. The recipe (Rust's struct) tells us what ingredients (binary data) we need and how to combine them to get the final dish (decoded IP header). Rust's struct acts as our recipe book, guiding us through the process of turning complex binary data into something we can easily understand.\n",
    "\n",
    "The flexibility of Rust's struct is like having a Swiss Army knife. It not only helps us decode the IP header but also opens up possibilities for doing more advanced tasks, like understanding different types of protocols and analyzing networks in more detail. This journey with Rust's struct is not just about reading data; it's about unlocking the secrets hidden in the binary language and using them to understand networks better.\n",
    "\n",
    "In a nutshell, our exploration of decoding the IP header in Rust is like embarking on an exciting adventure. Rust, our trusty companion, makes the journey smoother by providing us with the right tools to decipher the language of computers. As we navigate through Rust's struct, it's not just about decoding binary data; it's about gaining insights and understanding the fascinating world of networks."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "61c10083-d156-464c-92b9-7e7987b14f2a",
   "metadata": {},
   "source": [
    "### 1.3 The IP Header Struct\n",
    "\n",
    "In the following code snippet, we encounter the definition of a new Rust struct object named `IP`, meticulously crafted to read and parse packet headers into distinct fields. The `IP` struct is equiped with a set of fields, each meticulously aligned with the components of the IP header, as illustrated in the earlier-mentioned IP header table. Each field is assigned a specific name, such as `ver_ihl` or `offset`, along with its corresponding data type, like `u8` or `u16`. The ability to specify bit width adds a layer of flexibility, offering the liberty to dictate lengths beyond the byte level, an important feature that exceeds conventional constraints.\n",
    "\n",
    "```rust\n",
    "struct IP {\n",
    "    ver_ihl: u8,\n",
    "    tos: u8,\n",
    "    len: u16,\n",
    "    id: u16,\n",
    "    offset: u16,\n",
    "    ttl: u8,\n",
    "    protocol_num: u8,\n",
    "    sum: u16,\n",
    "    src: u32,\n",
    "    dst: u32,\n",
    "}\n",
    "```\n",
    "\n",
    "This struct, being the cornerstone of our packet parsing work, demands a well-defined structure before instantiation. The `new` method comes to the forefront, adept at filling the fields with appropriate values. As we traverse the complexities of the `new` method, it takes a buffer as its first argument and crafts an object of the `IP` struct. The utilization of format characters within the method becomes pivotal, outlining the structure of binary data with precision.\n",
    "\n",
    "```rust\n",
    "impl IP {\n",
    "    fn new(buff: &[u8]) -> Option<Self> {\n",
    "        if buff.len() >= 20 {\n",
    "            let header = IP {\n",
    "                ver_ihl: buff[0],\n",
    "                tos: buff[1],\n",
    "                len: u16::from_be_bytes([buff[2], buff[3]]),\n",
    "                id: u16::from_be_bytes([buff[4], buff[5]]),\n",
    "                offset: u16::from_be_bytes([buff[6], buff[7]]),\n",
    "                ttl: buff[8],\n",
    "                protocol_num: buff[9],\n",
    "                sum: u16::from_be_bytes([buff[10], buff[11]]),\n",
    "                src: u32::from_be_bytes([buff[12], buff[13], buff[14], buff[15]]),\n",
    "                dst: u32::from_be_bytes([buff[16], buff[17], buff[18], buff[19]]),\n",
    "            };\n",
    "\n",
    "            Some(header)\n",
    "        } else {\n",
    "            None\n",
    "        }\n",
    "    }\n",
    "}\n",
    "```\n",
    "\n",
    "The `new` method unfolds as a meticulous orchestra of data extraction, where each field of the `IP` struct is populated by interpreting the corresponding bytes from the input buffer. The method meticulously adheres to the complexities of the IP header, ensuring that each field, from version and type of service to source and destination IP addresses, is accurately represented. This methodical approach not only adheres to the Rust language's conventions but also aligns seamlessly with the binary nature of network data.\n",
    "\n",
    "```rust\n",
    "impl IP {\n",
    "    fn protocol(&self) -> String {\n",
    "        match self.protocol_num {\n",
    "            1 => String::from(\"ICMP\"),\n",
    "            4 => String::from(\"IPv4\"),\n",
    "            6 => String::from(\"TCP\"),\n",
    "            17 => String::from(\"UDP\"),\n",
    "            255 => String::from(\"Reserved\"),\n",
    "            _ => format!(\"{}\", self.protocol_num),\n",
    "        }\n",
    "    }\n",
    "\n",
    "    fn src_address(&self) -> String {\n",
    "        Ipv4Addr::from(self.src).to_string()\n",
    "    }\n",
    "\n",
    "    fn dst_address(&self) -> String {\n",
    "        Ipv4Addr::from(self.dst).to_string()\n",
    "    }\n",
    "\n",
    "    fn offset(&self) -> String {\n",
    "        self.offset.to_string()\n",
    "    }\n",
    "\n",
    "    fn ttl(&self) -> String {\n",
    "        self.ttl.to_string()\n",
    "    }\n",
    "\n",
    "    fn ver(&self) -> String {\n",
    "        self.ver_ihl.to_string()\n",
    "    }\n",
    "\n",
    "    fn len(&self) -> String {\n",
    "        self.len.to_string()\n",
    "    }\n",
    "}\n",
    "```\n",
    "\n",
    "Beyond the instantiation complexities, the `IP` struct extends its capabilities with additional methods designed to provide meaningful insights into the parsed IP header. The `protocol` method, for instance, translates the protocol number into human-readable format, offering clarity on whether it corresponds to ICMP, IPv4, TCP, UDP, or falls under the category of reserved protocols. This method encapsulates an important understanding of the IP header's composition, bridging the gap between raw data and comprehensible information.\n",
    "\n",
    "Further enriching the `IP` struct's functionality are methods such as `src_address`, `dst_address`, `offset`, `ttl`, `ver`, and `len`, each meticulously crafted to extract and present specific elements of the IP header. The `src_address` and `dst_address` methods, for instance, leverage Rust's ability to convert raw IP addresses into human-readable strings, providing insights into the source and destination addresses with clarity. Meanwhile, `offset`, `ttl`, `ver`, and `len` offer a glimpse into the fragment offset, time to live, version, and total length of the IP header, respectively.\n",
    "\n",
    "In essence, this Rust code snippet not only materializes the complexities of creating a robust `IP` struct for parsing IP headers but also unfolds as a complex symphony of methods that bridge the gap between raw binary data and comprehensible insights. The thoughtful design choices and meticulous data extraction techniques showcased here underscore Rust's prowess in low-level programming and its ability to handle network data with finesse."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "f1870347-466d-4afe-b1e8-c20f5c7c15d7",
   "metadata": {},
   "source": [
    "### 1.4 Putting It All Together\n",
    "\n",
    "To integrate the recently developed IP decoding struct into our network sniffer, we will incorporate the functionality within our script:\n",
    "\n",
    "```rust\n",
    "use socket2::{Domain, Protocol, Socket, Type};\n",
    "use std::io::Result;\n",
    "use std::mem::MaybeUninit;\n",
    "use std::net::SocketAddr;\n",
    "use std::net::Ipv4Addr;\n",
    "\n",
    "\n",
    "struct IP {\n",
    "    ver_ihl: u8,\n",
    "    tos: u8,\n",
    "    len: u16,\n",
    "    id: u16,\n",
    "    offset: u16,\n",
    "    ttl: u8,\n",
    "    protocol_num: u8,\n",
    "    sum: u16,\n",
    "    src: u32,\n",
    "    dst: u32,\n",
    "}\n",
    "\n",
    "impl IP {\n",
    "    fn new(buff: &[u8]) -> Option<Self> {\n",
    "        if buff.len() >= 20 {\n",
    "            let header = IP {\n",
    "                ver_ihl: buff[0],\n",
    "                tos: buff[1],\n",
    "                len: u16::from_be_bytes([buff[2], buff[3]]),\n",
    "                id: u16::from_be_bytes([buff[4], buff[5]]),\n",
    "                offset: u16::from_be_bytes([buff[6], buff[7]]),\n",
    "                ttl: buff[8],\n",
    "                protocol_num: buff[9],\n",
    "                sum: u16::from_be_bytes([buff[10], buff[11]]),\n",
    "                src: u32::from_be_bytes([buff[12], buff[13], buff[14], buff[15]]),\n",
    "                dst: u32::from_be_bytes([buff[16], buff[17], buff[18], buff[19]]),\n",
    "            };\n",
    "\n",
    "            Some(header)\n",
    "        } else {\n",
    "            None\n",
    "        }\n",
    "    }\n",
    "\n",
    "    fn protocol(&self) -> String {\n",
    "        // Refer to ---> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml\n",
    "        match self.protocol_num {\n",
    "            0 => String::from(\"HOPOPT\"),\n",
    "            1 => String::from(\"ICMP\"),\n",
    "            2 => String::from(\"IGMP\"),\n",
    "            3 => String::from(\"GGP\"),\n",
    "            4 => String::from(\"IPv4\"),\n",
    "            5 => String::from(\"ST\"),\n",
    "            6 => String::from(\"TCP\"),\n",
    "            7 => String::from(\"CBT\"),\n",
    "            8 => String::from(\"EGP\"),\n",
    "            9 => String::from(\"IGP\"),\n",
    "            10 => String::from(\"BBN-RCC-MON\"),\n",
    "            11 => String::from(\"NVP-II\"),\n",
    "            12 => String::from(\"PUP\"),\n",
    "            13 => String::from(\"ARGUS\"),\n",
    "            14 => String::from(\"EMCON\"),\n",
    "            15 => String::from(\"XNET\"),\n",
    "            16 => String::from(\"CHAOS\"),\n",
    "            17 => String::from(\"UDP\"),\n",
    "            18 => String::from(\"MUX\"),\n",
    "            19 => String::from(\"DCN-MEAS\"),\n",
    "            20 => String::from(\"HMP\"),\n",
    "            21 => String::from(\"PRM\"),\n",
    "            22 => String::from(\"XNS-IDP\"),\n",
    "            23 => String::from(\"TRUNK-1\"),\n",
    "            24 => String::from(\"TRUNK-2\"),\n",
    "            25 => String::from(\"LEAF-1\"),\n",
    "            26 => String::from(\"LEAF-2\"),\n",
    "            27 => String::from(\"RDP\"),\n",
    "            28 => String::from(\"IRTP\"),\n",
    "            29 => String::from(\"ISO-TP4\"),\n",
    "            30 => String::from(\"NETBLT\"),\n",
    "            31 => String::from(\"MFE-NSP\"),\n",
    "            32 => String::from(\"MERIT-INP\"),\n",
    "            33 => String::from(\"DCCP\"),\n",
    "            34 => String::from(\"3PC\"),\n",
    "            35 => String::from(\"IDPR\"),\n",
    "            36 => String::from(\"XTP\"),\n",
    "            37 => String::from(\"DDP\"),\n",
    "            38 => String::from(\"IDPR-CMTP\"),\n",
    "            39 => String::from(\"TP++\"),\n",
    "            40 => String::from(\"IL\"),\n",
    "            41 => String::from(\"IPv6\"),\n",
    "            42 => String::from(\"SDRP\"),\n",
    "            43 => String::from(\"IPv6-Route\"),\n",
    "            44 => String::from(\"IPv6-Frag\"),\n",
    "            45 => String::from(\"IDRP\"),\n",
    "            46 => String::from(\"RSVP\"),\n",
    "            47 => String::from(\"GRE\"),\n",
    "            48 => String::from(\"DSR\"),\n",
    "            49 => String::from(\"BNA\"),\n",
    "            50 => String::from(\"ESP\"),\n",
    "            51 => String::from(\"AH\"),\n",
    "            52 => String::from(\"I-NLSP\"),\n",
    "            53 => String::from(\"SWIPE (deprecated)\"),\n",
    "            54 => String::from(\"NARP\"),\n",
    "            55 => String::from(\"MOBILE\"),\n",
    "            56 => String::from(\"TLSP\"),\n",
    "            57 => String::from(\"SKIP\"),\n",
    "            58 => String::from(\"IPv6-ICMP\"),\n",
    "            59 => String::from(\"IPv6-NoNxt\"),\n",
    "            60 => String::from(\"IPv6-Opts\"),\n",
    "            61 => String::from(\"any host internal protocol\"),\n",
    "            62 => String::from(\"CFTP\"),\n",
    "            63 => String::from(\"any local network\"),\n",
    "            64 => String::from(\"SAT-EXPAK\"),\n",
    "            65 => String::from(\"KRYPTOLAN\"),\n",
    "            66 => String::from(\"RVD\"),\n",
    "            67 => String::from(\"IPPC\"),\n",
    "            68 => String::from(\"any distributed file system\"),\n",
    "            69 => String::from(\"SAT-MON\"),\n",
    "            70 => String::from(\"VISA\"),\n",
    "            71 => String::from(\"IPCV\"),\n",
    "            72 => String::from(\"CPNX\"),\n",
    "            73 => String::from(\"CPHB\"),\n",
    "            74 => String::from(\"WSN\"),\n",
    "            75 => String::from(\"PVP\"),\n",
    "            76 => String::from(\"BR-SAT-MON\"),\n",
    "            77 => String::from(\"SUN-ND\"),\n",
    "            78 => String::from(\"WB-MON\"),\n",
    "            79 => String::from(\"WB-EXPAK\"),\n",
    "            80 => String::from(\"ISO-IP\"),\n",
    "            81 => String::from(\"VMTP\"),\n",
    "            82 => String::from(\"SECURE-VMTP\"),\n",
    "            83 => String::from(\"VINES\"),\n",
    "            84 => String::from(\"IPTM\"),\n",
    "            85 => String::from(\"NSFNET-IGP\"),\n",
    "            86 => String::from(\"DGP\"),\n",
    "            87 => String::from(\"TCF\"),\n",
    "            88 => String::from(\"EIGRP\"),\n",
    "            89 => String::from(\"OSPFIGP\"),\n",
    "            90 => String::from(\"Sprite-RPC\"),\n",
    "            91 => String::from(\"LARP\"),\n",
    "            92 => String::from(\"MTP\"),\n",
    "            93 => String::from(\"AX.25\"),\n",
    "            94 => String::from(\"IPIP\"),\n",
    "            95 => String::from(\"MICP (deprecated)\"),\n",
    "            96 => String::from(\"SCC-SP\"),\n",
    "            97 => String::from(\"ETHERIP\"),\n",
    "            98 => String::from(\"ENCAP\"),\n",
    "            100 => String::from(\"GMTP\"),\n",
    "            101 => String::from(\"IFMP\"),\n",
    "            102 => String::from(\"PNNI\"),\n",
    "            103 => String::from(\"PIM\"),\n",
    "            104 => String::from(\"ARIS\"),\n",
    "            105 => String::from(\"SCPS\"),\n",
    "            106 => String::from(\"QNX\"),\n",
    "            107 => String::from(\"A/N\"),\n",
    "            108 => String::from(\"IPComp\"),\n",
    "            109 => String::from(\"SNP\"),\n",
    "            110 => String::from(\"Compaq-Peer\"),\n",
    "            111 => String::from(\"IPX-in-IP\"),\n",
    "            112 => String::from(\"VRRP\"),\n",
    "            113 => String::from(\"PGM\"),\n",
    "            114 => String::from(\"any 0-hop protocol\"),\n",
    "            115 => String::from(\"L2TP\"),\n",
    "            116 => String::from(\"DDX\"),\n",
    "            117 => String::from(\"IATP\"),\n",
    "            118 => String::from(\"STP\"),\n",
    "            119 => String::from(\"SRP\"),\n",
    "            120 => String::from(\"UTI\"),\n",
    "            121 => String::from(\"SMP\"),\n",
    "            122 => String::from(\"SM (deprecated)\"),\n",
    "            123 => String::from(\"PTP\"),\n",
    "            124 => String::from(\"ISIS over IPv4\"),\n",
    "            125 => String::from(\"FIRE\"),\n",
    "            126 => String::from(\"CRTP\"),\n",
    "            127 => String::from(\"CRUDP\"),\n",
    "            128 => String::from(\"SSCOPMCE\"),\n",
    "            129 => String::from(\"IPLT\"),\n",
    "            130 => String::from(\"SPS\"),\n",
    "            131 => String::from(\"PIPE\"),\n",
    "            132 => String::from(\"SCTP\"),\n",
    "            133 => String::from(\"FC\"),\n",
    "            134 => String::from(\"RSVP-E2E-IGNORE\"),\n",
    "            135 => String::from(\"Mobility Header\"),\n",
    "            136 => String::from(\"UDPLite\"),\n",
    "            137 => String::from(\"MPLS-in-IP\"),\n",
    "            138 => String::from(\"manet\"),\n",
    "            139 => String::from(\"HIP\"),\n",
    "            140 => String::from(\"Shim6\"),\n",
    "            141 => String::from(\"WESP\"),\n",
    "            142 => String::from(\"ROHC\"),\n",
    "            143 => String::from(\"Ethernet\"),\n",
    "            144 => String::from(\"AGGFRAG\"),\n",
    "            145 => String::from(\"NSH\"),\n",
    "            146..=252 => String::from(\"Unassigned\"),\n",
    "            253 => String::from(\"Use for experimentation and testing\"),\n",
    "            254 => String::from(\"Use for experimentation and testing\"),\n",
    "            255 => String::from(\"Reserved\"),\n",
    "            _ => format!(\"{}\", self.protocol_num),\n",
    "        }\n",
    "    }\n",
    "\n",
    "    fn src_address(&self) -> String {\n",
    "        Ipv4Addr::from(self.src).to_string()\n",
    "    }\n",
    "\n",
    "    fn dst_address(&self) -> String {\n",
    "        Ipv4Addr::from(self.dst).to_string()\n",
    "    }\n",
    "\n",
    "    fn offset(&self) -> String {\n",
    "        self.offset.to_string()\n",
    "    }\n",
    "\n",
    "    fn ttl(&self) -> String {\n",
    "        self.ttl.to_string()\n",
    "    }\n",
    "\n",
    "    fn ver(&self) -> String {\n",
    "        self.ver_ihl.to_string()\n",
    "    }\n",
    "\n",
    "    fn len(&self) -> String {\n",
    "        self.len.to_string()\n",
    "    }\n",
    "}\n",
    "\n",
    "fn main() -> Result<()> {\n",
    "    // Define the host to listen on\n",
    "    let host: SocketAddr = \"0.0.0.0:12345\".parse().unwrap();\n",
    "\n",
    "    let socket_protocol = if cfg!(target_os = \"windows\") {\n",
    "        0\n",
    "    } else {\n",
    "        1\n",
    "    };\n",
    "\n",
    "    // Create a raw socket\n",
    "    let sniffer = Socket::new(\n",
    "        Domain::IPV4,\n",
    "        Type::RAW,\n",
    "        Some(Protocol::from(socket_protocol)),\n",
    "    )?;\n",
    "    // bind to the public interface\n",
    "    sniffer.bind(&host.into())?;\n",
    "\n",
    "    // Read one packet\n",
    "    let mut buffer: [MaybeUninit<u8>; 65535] = unsafe { MaybeUninit::uninit().assume_init() };\n",
    "    let _ = sniffer.recv_from(&mut buffer)?;\n",
    "    let raw_buffer: &[u8] =\n",
    "        unsafe { std::slice::from_raw_parts(buffer.as_ptr() as *const u8, buffer.len()) };\n",
    "\n",
    "    if raw_buffer.len() < 20 {\n",
    "        eprintln!(\"Invalid packet: too short\");\n",
    "        return Ok(());\n",
    "    }\n",
    "\n",
    "    // Create an IP header from the first 20 bytes\n",
    "    let ip_header = match IP::new(&raw_buffer[..20]) {\n",
    "        Some(header) => header,\n",
    "        None => return Ok(())\n",
    "    };\n",
    "\n",
    "    println!(\n",
    "        \"Protocol: {} {} -> {}\",\n",
    "        \"ICMP\",\n",
    "        ip_header.src_address(),\n",
    "        ip_header.dst_address()\n",
    "    );\n",
    "\n",
    "    println!(\"Version: {}\", ip_header.ver());\n",
    "    \n",
    "    println!(\n",
    "        \"Header Length: {} TTL: {}\",\n",
    "        ip_header.len(),\n",
    "        ip_header.ttl()\n",
    "    );\n",
    "\n",
    "    Ok(())\n",
    "}\n",
    "```"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "6ce67650-126c-4c31-90cd-52b74c875b8d",
   "metadata": {},
   "source": [
    "Let's put our previously developed code to the test to gain insights into the information extracted from the raw packets traversing the network. We highly recommend conducting this test from a Windows machine to leverage the diverse protocols such as UDP, and TCP, enabling fascinating testing scenarios like opening a web browser. For those confined to Linux, an alternative is to execute the previous ping test to witness the code in action."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "f3afc3c9-ca3c-4440-b217-e5c0fe038daa",
   "metadata": {},
   "outputs": [
    {
     "name": "stderr",
     "output_type": "stream",
     "text": [
      "   Compiling decoding-the-ip-header v0.1.0 (/home/mahmoud/Desktop/Rust Book Dark/dark-web-rust/chapter-1/decoding-the-ip-header)\n",
      "    Finished dev [unoptimized + debuginfo] target(s) in 0.25s\n"
     ]
    },
    {
     "name": "stdout",
     "output_type": "stream",
     "text": [
      "Protocol: ICMP 142.251.37.238 -> 192.168.1.8\n",
      "Version: 69\n",
      "Header Length: 84 TTL: 113\n",
      "Protocol: ICMP 142.251.37.238 -> 192.168.1.8\n",
      "Version: 69\n",
      "Header Length: 84 TTL: 113\n",
      "Protocol: ICMP 142.251.37.238 -> 192.168.1.8\n",
      "Version: 69\n",
      "Header Length: 84 TTL: 113\n",
      "Protocol: ICMP 142.251.37.238 -> 192.168.1.8\n",
      "Version: 69\n",
      "Header Length: 84 TTL: 113\n",
      "Protocol: ICMP 142.251.37.238 -> 192.168.1.8\n",
      "Version: 69\n",
      "Header Length: 84 TTL: 113\n"
     ]
    }
   ],
   "source": [
    "// The following command will execute the sniffer.\n",
    "// Set your sudo password below by replacing 'your-passowrd' accordingly\n",
    "\n",
    "let command = \"cd decoding-the-ip-header && cargo build && echo 'your-passowrd' | sudo -S setcap cap_net_raw+ep target/debug/decoding-the-ip-header && target/debug/decoding-the-ip-header\";\n",
    "\n",
    "if let Err(err) = execute_command(command) {\n",
    "    eprintln!(\"Error executing command: {}\", err);\n",
    "}\n",
    "\n",
    "// In another terminal or shell window, choose a host to ping, for example: ping google.com"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "2a2cf16e-2cec-410d-9e58-20d6afb3249d",
   "metadata": {},
   "source": [
    "It's evident that we encounter a limitation here, observing only a response for the ICMP protocol. Yet, for our intended purpose of crafting a host discovery scanner, this limitation is entirely acceptable. Our next course of action involves applying the same decoding techniques previously employed for the IP header to decode the ICMP messages, thereby expanding the capabilities of our network exploration tool."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "ec6bf70b-5d5e-4b15-b8b9-9b2b31336c2a",
   "metadata": {},
   "source": [
    "### 1.5 ICMP Structure Decoding\n",
    "\n",
    "In the world of network security and [**penetration testing**](https://en.wikipedia.org/wiki/Penetration_test), understanding the complexities of packet decoding is crucial. Having previously explored the decoding of the IP layer in our packet-sniffing efforts, our next attempt involves deciphering ICMP packets produced by our scanner's transmission of UDP datagrams to closed ports. [**ICMP**](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol), or Internet Control Message Protocol, messages possess varying contents, yet maintain three consistent elements: the type, code, and checksum fields. These fields play a pivotal role in conveying the nature of the ICMP message to the receiving host, thereby guiding its proper decoding.\n",
    "\n",
    "#### ICMP Structure\n",
    "\n",
    "Within the universe of ICMP messages, our focus narrows down to those with a type value of 3 and a corresponding code value of 3. This specific combination signifies the Destination Unreachable class of ICMP messages, specifically pinpointing the occurrence of a Port Unreachable error. The structural blueprint of a Destination Unreachable ICMP message is illustrated in the following excerpt that is shamelessly taken from [**RFC 792 Page 4**](https://datatracker.ietf.org/doc/html/rfc792), outlining the composition of its type, code, header, checksum, and additional components:\n",
    "\n",
    "\n",
    "> Destination Unreachable Message\n",
    "> \n",
    "     0                   1                   2                   3\n",
    "     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\n",
    "    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n",
    "    |     Type      |     Code      |          Checksum             |\n",
    "    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n",
    "    |                             unused                            |\n",
    "    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n",
    "    |      Internet Header + 64 bits of Original Data Datagram      |\n",
    "    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n",
    "\n",
    "> \n",
    ">    IP Fields:\n",
    "> \n",
    ">    Destination Address\n",
    "> \n",
    ">       The source network and address from the original datagram's data.\n",
    "> \n",
    ">    ICMP Fields:\n",
    "> \n",
    ">    Type\n",
    "> \n",
    ">       3\n",
    "> \n",
    ">    Code\n",
    "> \n",
    ">       0 = net unreachable;\n",
    "> \n",
    ">       1 = host unreachable;\n",
    "> \n",
    ">       2 = protocol unreachable;\n",
    "> \n",
    ">       3 = port unreachable;\n",
    "> \n",
    ">       4 = fragmentation needed and DF set;\n",
    "> \n",
    ">       5 = source route failed.\n",
    "> \n",
    ">    Checksum\n",
    "> \n",
    ">       The checksum is the 16-bit ones's complement of the one's\n",
    ">       complement sum of the ICMP message starting with the ICMP Type.\n",
    ">       For computing the checksum , the checksum field should be zero.\n",
    ">       This checksum may be replaced in the future.\n",
    "> \n",
    ">    Internet Header + 64 bits of Data Datagram\n",
    "> \n",
    ">       The internet header plus the first 64 bits of the original\n",
    "> \n",
    "> \n",
    "> [Page 4]\n",
    "\n",
    "Examining this structure, we discern that the first 8 bits represent the type, followed by the subsequent 8 bits housing the ICMP code. Notably, the originating IP header of the message that triggered the response is encapsulated within the ICMP message, presenting an opportunity for validation.\n",
    "\n",
    "#### Integration of ICMP Decoding\n",
    "\n",
    "Now, let's seamlessly integrate the decoding of ICMP packets into our existing packet-sniffing framework. The augmentation of our sniffer encompasses the implementation of an ICMP structure beneath the established IP structure. The following code snippet imports necessary modules and initializes the ICMP structure to facilitate the decoding process when ICMP packets are detected.\n",
    "\n",
    "```rust\n",
    "use std::env;\n",
    "use std::mem::MaybeUninit;\n",
    "use std::net::SocketAddr;\n",
    "use std::net::{IpAddr, Ipv4Addr};\n",
    "\n",
    "\n",
    "const ICMP_TYPE_CODE_MAP: &[((u8, u8), &str)] = &[\n",
    "    // taken from ---> https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml\n",
    "    ((0, 0), \"Echo Reply\"),\n",
    "    ((3, 0), \"Destination Unreachable - Net is unreachable\"),\n",
    "    ((3, 1), \"Destination Unreachable - Host is unreachable\"),\n",
    "    ((3, 2), \"Destination Unreachable - Protocol is unreachable\"),\n",
    "    ((3, 3), \"Destination Unreachable - Port is unreachable\"),\n",
    "    ((3, 4), \"Destination Unreachable - Fragmentation is needed and Don't Fragment was set\"),\n",
    "    ((3, 5), \"Destination Unreachable - Source route failed\"),\n",
    "    ((3, 6), \"Destination Unreachable - Destination network is unknown\"),\n",
    "    ((3, 7), \"Destination Unreachable - Destination host is unknown\"),\n",
    "    ((3, 8), \"Destination Unreachable - Source host is isolated\"),\n",
    "    ((3, 9), \"Destination Unreachable - Communication with destination network is administratively prohibited\"),\n",
    "    ((3, 10), \"Destination Unreachable - Communication with destination host is administratively prohibited\"),\n",
    "    ((3, 11), \"Destination Unreachable - Destination network is unreachable for type of service\"),\n",
    "    ((3, 12), \"Destination Unreachable - Destination host is unreachable for type of service\"),\n",
    "    ((3, 13), \"Destination Unreachable - Communication is administratively prohibited\"),\n",
    "    ((3, 14), \"Destination Unreachable - Host precedence violation\"),\n",
    "    ((3, 15), \"Destination Unreachable - Precedence cutoff is in effect\"),\n",
    "    ((4, 0), \"Source Quench\"),\n",
    "    ((5, 0), \"Redirect\"),\n",
    "    ((8, 0), \"Echo\"),\n",
    "    ((9, 0), \"Router Advertisement\"),\n",
    "    ((10, 0), \"Router Selection\"),\n",
    "    ((11, 0), \"Time Exceeded\"),\n",
    "    ((12, 0), \"Parameter Problem\"),\n",
    "    ((13, 0), \"Timestamp\"),\n",
    "    ((14, 0), \"Timestamp Reply\"),\n",
    "    ((15, 0), \"Information Request\"),\n",
    "    ((16, 0), \"Information Reply\"),\n",
    "    ((17, 0), \"Address Mask Request\"),\n",
    "    ((18, 0), \"Address Mask Reply\"),\n",
    "    ((30, 0), \"Traceroute\"),\n",
    "    ((40, 0), \"Photuris\"),\n",
    "    ((41, 0), \"ICMP for IPv6\"),\n",
    "    ((42, 0), \"No Next Header for IPv6\"),\n",
    "    ((43, 0), \"Destination Unreachable for IPv6\"),\n",
    "    ((44, 0), \"Packet Too Big for IPv6\"),\n",
    "    ((45, 0), \"Time Exceeded for IPv6\"),\n",
    "    ((46, 0), \"Parameter Problem for IPv6\"),\n",
    "    ((47, 0), \"Echo Request for IPv6\"),\n",
    "    ((48, 0), \"Echo Reply for IPv6\"),\n",
    "    ((49, 0), \"Multicast Listener Query for IPv6\"),\n",
    "    ((50, 0), \"Multicast Listener Report for IPv6\"),\n",
    "    ((51, 0), \"Multicast Listener Done for IPv6\"),\n",
    "    ((58, 0), \"Router Solicitation for IPv6\"),\n",
    "    ((59, 0), \"Router Advertisement for IPv6\"),\n",
    "    ((60, 0), \"Neighbor Solicitation for IPv6\"),\n",
    "    ((61, 0), \"Neighbor Advertisement for IPv6\"),\n",
    "    ((62, 0), \"Redirect Message for IPv6\"),\n",
    "];\n",
    "\n",
    "struct ICMP {\n",
    "    type_: u8,\n",
    "    code: u8,\n",
    "    sum: u16,\n",
    "    id: u16,\n",
    "    seq: u16,\n",
    "}\n",
    "\n",
    "impl ICMP {\n",
    "    fn new(buff: &[u8]) -> Self {\n",
    "        let header = (\n",
    "            buff[0],\n",
    "            buff[1],\n",
    "            u16::from_be_bytes([buff[2], buff[3]]),\n",
    "            u16::from_be_bytes([buff[4], buff[5]]),\n",
    "            u16::from_be_bytes([buff[6], buff[7]]),\n",
    "        );\n",
    "        ICMP {\n",
    "            type_: header.0,\n",
    "            code: header.1,\n",
    "            sum: header.2,\n",
    "            id: header.3,\n",
    "            seq: header.4,\n",
    "        }\n",
    "    }\n",
    "}\n",
    "\n",
    "struct IP {\n",
    "    // The previous IP implementation details goes here\n",
    "}\n",
    "\n",
    "impl IP {\n",
    "    // Constructor and methods already implemented for IP decoding\n",
    "}\n",
    "    \n",
    "fn icmp_type_name(type_: u8, code: u8) -> String {\n",
    "    for &((t, c), name) in ICMP_TYPE_CODE_MAP {\n",
    "        if t == type_ && (c == code || c == 255) {\n",
    "            return name.to_string();\n",
    "        }\n",
    "    }\n",
    "    format!(\"Type: {}, Code: {}\", type_, code)\n",
    "}\n",
    "\n",
    "fn sniff(host: IpAddr) {\n",
    "    // ..\n",
    "    loop {\n",
    "        // ..\n",
    "\n",
    "        // If it's ICMP, we want it\n",
    "        if ip_header.protocol() == \"ICMP\" {\n",
    "            println!(\n",
    "                \"Protocol: {} {} -> {}\",\n",
    "                \"ICMP\",\n",
    "                ip_header.src_address(),\n",
    "                ip_header.dst_address()\n",
    "            );\n",
    "            println!(\"Version: {}\", ip_header.ver());\n",
    "            println!(\n",
    "                \"Header Length: {} TTL: {}\",\n",
    "                ip_header.len(),\n",
    "                ip_header.ttl()\n",
    "            );\n",
    "\n",
    "            // Calculate where our ICMP packet starts\n",
    "            let offset = ip_header.offset().parse().unwrap_or_else(|_| {\n",
    "                eprintln!(\"Failed to parse offset\");\n",
    "                0\n",
    "            });\n",
    "            if offset + 8 <= raw_buffer.len() {\n",
    "                let buf = &raw_buffer[offset..offset + 8];\n",
    "                // Create our ICMP structure\n",
    "                let icmp_header = ICMP::new(buf);\n",
    "                println!(\n",
    "                    \"ICMP -> {}\",\n",
    "                    icmp_type_name(icmp_header.type_, icmp_header.code)\n",
    "                );\n",
    "                println!(\n",
    "                    \"ICMP -> {:?}\",\n",
    "                    icmp_header.clone()\n",
    "                );\n",
    "            } else {\n",
    "                eprintln!(\"Invalid ICMP packet: too short\");\n",
    "            }\n",
    "        }\n",
    "    }\n",
    "}\n",
    "```\n",
    "\n",
    "The ICMP decoding mechanism implemented in the above Rust code is a sophisticated and detailed process aimed at examining and comprehending the headers of ICMP packets within the context of a network sniffer. Each component of the logic contributes to a comprehensive understanding of the ICMP packet structure and its contents, making it an integral part of network protocol analysis. This Rust implementation adheres to Rust's syntax and semantics.\n",
    "\n",
    "The `ICMP_TYPE_CODE_MAP` constant serves as a meticulously crafted reference, encapsulating a comprehensive mapping between ICMP types and their corresponding codes. This constant is designed to enhance the interpretability of ICMP messages by associating each type and code combination with a human-readable description. Each entry in the constant is a tuple consisting of a pair of 8-bit unsigned integers representing the ICMP type and code, respectively, and a descriptive string explaining the nature of the ICMP message. This mapping not only aids us in understanding the meaning of various ICMP messages but also serves as a critical resource for implementing robust network applications and security tools.\n",
    "\n",
    "The constant begins by encompassing the essential ICMP types and codes commonly encountered in networking scenarios. Echo Reply, Echo Request, Destination Unreachable, Redirect, and Time Exceeded are just a few examples meticulously documented within the constant. It meticulously includes details about various Destination Unreachable codes, such as Net is unreachable, Host is unreachable, Protocol is unreachable, and Port is unreachable, explaining the reasons for such unreachable scenarios. Additionally, it extends its coverage to incorporate ICMP messages specifically tailored for IPv6, addressing the evolving landscape of internet protocols. The constant is structured to be easily extensible, allowing us to add more ICMP types and codes as needed, ensuring adaptability to evolving networking standards.\n",
    "\n",
    "The introduction of the `ICMP` struct further refines the decoding process. This struct encapsulates essential fields extracted from the ICMP packet header, including the type, code, checksum, identifier, and sequence number. The `new` method of the `ICMP` struct acts as a constructor, facilitating the creation of instances of this struct from a byte buffer, thereby enabling the extraction and organization of relevant information from ICMP packet headers.\n",
    "\n",
    "The utility function `icmp_type_name` plays a crucial role in translating numeric representations of ICMP types and codes into human-readable and descriptive strings. By using the `ICMP_TYPE_CODE_MAP` constant, this function iterates through the mappings, searching for a match based on the provided type and code parameters. If a match is found, it returns the corresponding descriptive name; otherwise, it constructs a default string incorporating the type and code values.\n",
    "\n",
    "The core of the ICMP decoding mechanism lies in the `sniff` function. Operating within a loop, this function continuously captures and processes packets. Upon identifying an ICMP packet, it extracts and prints relevant information, including the protocol type, source and destination addresses, version, header length, and Time to Live (TTL). The function meticulously calculates the offset to pinpoint the beginning of the ICMP packet within the raw buffer, ensuring its validity by checking its length. If the packet is valid, it constructs an instance of the `ICMP` struct and prints detailed information about the ICMP type using the `icmp_type_name` function.\n",
    "\n",
    "The ICMP decoding mechanism in this Rust code exemplifies a well-architected and modular approach to network protocol analysis. It leverages constants, structs, and utility functions to decode ICMP packets comprehensively, providing informative and human-readable insights into the nature of network communication. The attention to detail in handling various ICMP types and codes, coupled with a modular design, makes this implementation robust and adaptable to different network analysis scenarios."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "9927d182-5199-4447-82e5-fc8965937a1b",
   "metadata": {},
   "source": [
    "Let's put our developed code to the test to gain insights into the information extracted from the raw ICMP packets traversing the network."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "ac1917d6-be81-4023-a338-bb204d9ee8fa",
   "metadata": {},
   "outputs": [
    {
     "name": "stderr",
     "output_type": "stream",
     "text": [
      "    Finished dev [unoptimized + debuginfo] target(s) in 0.01s\n"
     ]
    },
    {
     "name": "stdout",
     "output_type": "stream",
     "text": [
      "Protocol: ICMP 127.0.0.1 -> 127.0.0.1\n",
      "Version: 69\n",
      "Header Length: 84 TTL: 64\n",
      "ICMP -> Echo Reply\n",
      "Protocol: ICMP 127.0.0.1 -> 127.0.0.1\n",
      "Version: 69\n",
      "Header Length: 84 TTL: 64\n",
      "ICMP -> Type: 69, Code: 0\n",
      "Protocol: ICMP 127.0.0.1 -> 127.0.0.1\n",
      "Version: 69\n",
      "Header Length: 84 TTL: 64\n",
      "ICMP -> Echo Reply\n",
      "Protocol: ICMP 127.0.0.1 -> 127.0.0.1\n",
      "Version: 69\n",
      "Header Length: 84 TTL: 64\n",
      "ICMP -> Type: 69, Code: 0\n",
      "Protocol: ICMP 127.0.0.1 -> 127.0.0.1\n",
      "Version: 69\n",
      "Header Length: 84 TTL: 64\n",
      "ICMP -> Echo Reply\n",
      "Protocol: ICMP 127.0.0.1 -> 127.0.0.1\n",
      "Version: 69\n",
      "Header Length: 84 TTL: 64\n",
      "ICMP -> Type: 69, Code: 0\n",
      "Protocol: ICMP 127.0.0.1 -> 127.0.0.53\n",
      "Version: 69\n",
      "Header Length: 101 TTL: 64\n",
      "ICMP -> Type: 69, Code: 192\n"
     ]
    }
   ],
   "source": [
    "// The following command will execute the sniffer.\n",
    "// Set your sudo password below by replacing 'your-passowrd' accordingly\n",
    "\n",
    "let command = \"cd decoding-icmp-packets && cargo build && echo 'your-passowrd' | sudo -S sudo setcap cap_net_raw+ep target/debug/decoding-icmp-packets && target/debug/decoding-icmp-packets\";\n",
    "\n",
    "if let Err(err) = execute_command(command) {\n",
    "    eprintln!(\"Error executing command: {}\", err);\n",
    "}\n",
    "\n",
    "// In another terminal or shell window, choose a host to ping, for example: ping google.com"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "84db9979-1829-4fe3-9918-bf0ad9b21f26",
   "metadata": {},
   "source": [
    "The provided output captures the complexities of ICMP packet traffic on the local loopback address (127.0.0.1), shedding light on the communication dynamics within the confines of the machine itself. The repeated occurrences of ICMP Echo Reply messages suggest a pattern of responsiveness, indicating that the local machine is actively responding to ping requests. This behavior aligns with the fundamental purpose of ICMP Echo Reply packets, commonly associated with the well-known ping utility, which verifies network connectivity and round-trip time.\n",
    "\n",
    "A closer examination of the output reveals some intriguing details that warrant further consideration. The presence of an unusually high version number and type (69), and header length (84) in the IP header hints at potential deviations from standard IPv4 conventions. While the typical IPv4 header has a version field set to 4 and a header length specified in 32-bit words, the values observed in this output indicate a departure from the norm. This departure may signify custom or non-standardized packet structures, emphasizing the importance of context and a nuanced understanding of the specific network environment or tool generating the captured output.\n",
    "\n",
    "The consistency of the Time to Live (TTL) value at 64 is noteworthy, as it is a common TTL setting for packets within a local network. The TTL represents the maximum number of hops a packet can traverse before being discarded, and a value of 64 is often employed for traffic confined within a local network segment. In the context of loopback communication, the repeated presence of this TTL value further supports the interpretation that the ICMP Echo Reply packets are circulating within the local machine, reinforcing the notion of a self-contained network communication process."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "ab7f540c-7735-4558-bf54-2d79117f1d6c",
   "metadata": {},
   "source": [
    "Having successfully decoded ICMP packets, the logical progression in our network analysis journey involves extending our capabilities to decipher more complex protocols such as TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). ICMP, while essential for basic network diagnostics, represents just one facet of the diverse communication protocols governing the internet. TCP and UDP, being core components of the transport layer, play pivotal roles in facilitating reliable and connection-oriented, as well as lightweight and connectionless, communication, respectively.\n",
    "\n",
    "Decoding TCP packets introduces a new layer of complexity, given TCP's emphasis on establishing and maintaining reliable connections. Unlike ICMP, TCP incorporates features like sequencing, acknowledgment, and flow control. Understanding the structure of TCP headers becomes important, as it involves dissecting fields such as source and destination ports, sequence and acknowledgment numbers, and flags indicating the nature of the packet. Unraveling the complexities of TCP communication provides insights into applications such as web browsing, file transfers, and email, where reliable and ordered data delivery is crucial.\n",
    "\n",
    "Similarly, delving into UDP packet decoding reveals the world of lightweight and fast communication. UDP, in contrast to TCP, prioritizes simplicity and speed over reliability. It lacks the connection establishment and acknowledgment mechanisms present in TCP, making it suitable for scenarios where rapid data transmission takes precedence. Deciphering UDP headers involves understanding fields like source and destination ports and length, offering a glimpse into real-time applications such as online gaming, streaming, and VoIP, where timely data delivery often outweighs the need for reliability.\n",
    "\n",
    "In conclusion, broadening our decoding capabilities beyond ICMP to encompass TCP and UDP marks a pivotal step in comprehending the diverse landscape of network protocols. Each protocol brings its own set of challenges and nuances, and by expanding our analysis toolkit, we empower ourselves to gain a holistic understanding of the complex communication patterns shaping the digital world."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "7972e4b1-813d-45bd-bd9a-f741db2d9482",
   "metadata": {},
   "source": [
    "### 1.6 Decoding TCP packets\n",
    "\n",
    "Decoding TCP packets involves understanding the complexities of the [**Transmission Control Protocol (TCP)**](https://en.wikipedia.org/wiki/Transmission_Control_Protocol), a fundamental protocol in the transport layer of the [**Internet Protocol Suite**](https://en.wikipedia.org/wiki/Internet_protocol_suite). Unlike [**ICMP**](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol), which is connectionless, TCP provides a reliable, connection-oriented communication channel. Understanding the structure of TCP packets entails parsing the various fields within the TCP header, each conveying essential information about the communication session.\n",
    "\n",
    "The TCP header includes crucial components such as the source and destination port numbers, which identify the endpoints of the communication. The sequence and acknowledgment numbers play a pivotal role in ensuring the ordered and reliable delivery of data. Flags within the TCP header signify the nature of the packet, indicating whether it is a data segment, a connection request (SYN), an acknowledgment (ACK), or other control messages. By decoding these flags, we gain insights into the state of the TCP connection and the ongoing communication process.\n",
    "\n",
    "> 3.1.  Header Format\n",
    "> \n",
    ">   TCP segments are sent as internet datagrams.  The Internet Protocol\n",
    ">   header carries several information fields, including the source and\n",
    ">   destination host addresses [2].  A TCP header follows the internet\n",
    ">   header, supplying information specific to the TCP protocol.  This\n",
    ">   division allows for the existence of host level protocols other than\n",
    ">   TCP.\n",
    "> \n",
    ">   TCP Header Format\n",
    "                           \n",
    "     0                   1                   2                   3   \n",
    "     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 \n",
    "    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n",
    "    |          Source Port          |       Destination Port        |\n",
    "    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n",
    "    |                        Sequence Number                        |\n",
    "    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n",
    "    |                    Acknowledgment Number                      |\n",
    "    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n",
    "    |  Data |           |U|A|P|R|S|F|                               |\n",
    "    | Offset| Reserved  |R|C|S|S|Y|I|            Window             |\n",
    "    |       |           |G|K|H|T|N|N|                               |\n",
    "    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n",
    "    |           Checksum            |         Urgent Pointer        |\n",
    "    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n",
    "    |                    Options                    |    Padding    |\n",
    "    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n",
    "    |                             data                              |\n",
    "    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n",
    "\n",
    ">                            TCP Header Format\n",
    ">\n",
    ">          Note that one tick mark represents one bit position.\n",
    ">\n",
    ">                               Figure 3.\n",
    ">\n",
    ">  Source Port:  16 bits\n",
    ">\n",
    ">    The source port number.\n",
    ">\n",
    ">  Destination Port:  16 bits\n",
    ">\n",
    ">    The destination port number.\n",
    ">\n",
    ">\n",
    ">\n",
    ">\n",
    ">                                                               [Page 15]\n",
    "\n",
    "[**Excerpt from rfc793 Page 15**](https://www.ietf.org/rfc/rfc793.txt)\n",
    "\n",
    "Furthermore, the decoding process extends to examining optional fields within the TCP header, such as the Window Size and Urgent Pointer. The Window Size reflects the amount of data a sender can transmit before expecting an acknowledgment, contributing to flow control. The Urgent Pointer, when utilized, points to urgent data within the packet, enabling timely processing by the receiver. Understanding these optional fields enhances the comprehension of the nuanced behaviors and optimizations implemented within the TCP protocol.\n",
    "\n",
    "Deciphering TCP packets provides valuable insights into various applications that heavily rely on TCP, including web browsing, file transfers (via protocols like FTP), and email (via protocols like SMTP). By analyzing the content of TCP packets, one can uncover patterns in data transmission, detect anomalies, and troubleshoot network-related issues. This in-depth analysis of TCP communication contributes to a holistic understanding of the diverse and interconnected aspects of networking protocols.\n",
    "\n",
    "Now, let's decode TCP packets using the **`socket2`** crate in Rust which involves establishing a raw socket connection, capturing packets, and dissecting the TCP headers. As we have previously learned, the `socket2` crate provides low-level access to socket functionality, allowing for fine-grained control over network communication. Below is a simplified example illustrating the basic steps for decoding TCP packets using `socket2`:\n",
    "\n",
    "```rust\n",
    "use std::mem::MaybeUninit;\n",
    "use std::net::SocketAddr;\n",
    "use std::net::{IpAddr, Ipv4Addr};\n",
    "\n",
    "// Constants for TCP and IP headers size\n",
    "const TCP_HEADER_SIZE: usize = 20;\n",
    "const IPV4_HEADER_SIZE: usize = 20;\n",
    "\n",
    "struct TCP {\n",
    "    source_port: u16,\n",
    "    destination_port: u16,\n",
    "    sequence_number: u32,\n",
    "    acknowledgment_number: u32,\n",
    "    data_offset: u8,\n",
    "    reserved: u8,\n",
    "    flags: u16,\n",
    "    window_size: u16,\n",
    "    checksum: u16,\n",
    "    urgent_pointer: u16,\n",
    "}\n",
    "\n",
    "impl TCP {\n",
    "    fn new(buffer: &[u8]) -> Self {\n",
    "        // Parse the TCP header fields from the buffer\n",
    "        let source_port = u16::from_be_bytes([buffer[0], buffer[1]]);\n",
    "        let destination_port = u16::from_be_bytes([buffer[2], buffer[3]]);\n",
    "        let sequence_number = u32::from_be_bytes([buffer[4], buffer[5], buffer[6], buffer[7]]);\n",
    "        let acknowledgment_number =\n",
    "            u32::from_be_bytes([buffer[8], buffer[9], buffer[10], buffer[11]]);\n",
    "        let data_offset = (buffer[12] >> 4) * 4; // The top 4 bits represent the data offset\n",
    "        let reserved = buffer[12] & 0b00001111;\n",
    "        let flags = u16::from_be_bytes([buffer[13], buffer[14]]);\n",
    "        let window_size = u16::from_be_bytes([buffer[15], buffer[16]]);\n",
    "        let checksum = u16::from_be_bytes([buffer[17], buffer[18]]);\n",
    "        let urgent_pointer = u16::from_be_bytes([buffer[19], buffer[20]]);\n",
    "\n",
    "        TCP {\n",
    "            source_port,\n",
    "            destination_port,\n",
    "            sequence_number,\n",
    "            acknowledgment_number,\n",
    "            data_offset,\n",
    "            reserved,\n",
    "            flags,\n",
    "            window_size,\n",
    "            checksum,\n",
    "            urgent_pointer,\n",
    "        }\n",
    "    }\n",
    "}\n",
    "\n",
    "fn sniff(address: SocketAddr) {\n",
    "    let socket_protocol = if cfg!(target_os = \"windows\") {\n",
    "        0\n",
    "    } else {\n",
    "        6 // TCP\n",
    "    };\n",
    "\n",
    "    let sniffer = socket2::Socket::new(\n",
    "        socket2::Domain::IPV4,\n",
    "        socket2::Type::RAW,\n",
    "        Some(socket2::Protocol::from(socket_protocol)),\n",
    "    )\n",
    "    .unwrap();\n",
    "\n",
    "    sniffer.bind(&address.into()).unwrap();\n",
    "\n",
    "    let mut buffer: [MaybeUninit<u8>; 65535] = unsafe { MaybeUninit::uninit().assume_init() };\n",
    "    loop {\n",
    "        // Receive a TCP packet\n",
    "        let _length = sniffer.recv_from(&mut buffer).unwrap();\n",
    "        let raw_buffer: &[u8] =\n",
    "            unsafe { std::slice::from_raw_parts(buffer.as_ptr() as *const u8, buffer.len()) };\n",
    "\n",
    "        // Process the TCP packet\n",
    "        if size >= IPV4_HEADER_SIZE + TCP_HEADER_SIZE {\n",
    "            let tcp_header =\n",
    "                TCP::new(&raw_buffer[IPV4_HEADER_SIZE..IPV4_HEADER_SIZE + TCP_HEADER_SIZE + 1]);\n",
    "            // Print or process TCP header information\n",
    "            println!(\"Source Port: {}\", tcp_header.source_port);\n",
    "            println!(\"Destination Port: {}\", tcp_header.destination_port);\n",
    "            println!(\"Sequence Number: {}\", tcp_header.sequence_number);\n",
    "            println!(\n",
    "                \"Acknowledgment Number: {}\",\n",
    "                tcp_header.acknowledgment_number\n",
    "            );\n",
    "            println!(\"Data Offset: {}\", tcp_header.data_offset);\n",
    "            println!(\"Reserved: {}\", tcp_header.reserved);\n",
    "            println!(\"Flags: {}\", tcp_header.flags);\n",
    "            println!(\"Window Size: {}\", tcp_header.window_size);\n",
    "            println!(\"Checksum: {}\", tcp_header.checksum);\n",
    "            println!(\"Urgent Pointer: {}\", tcp_header.urgent_pointer);\n",
    "        }\n",
    "    }\n",
    "}\n",
    "\n",
    "fn main() {\n",
    "    let socket = SocketAddr::new(IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)), 12345);\n",
    "\n",
    "    sniff(socket);\n",
    "}\n",
    "```\n",
    "\n",
    "This example sets up a raw socket, binds it to a local address (in this case, the loopback address), and enters a loop to continuously capture and process TCP packets. The `TCP` struct encapsulates the relevant fields from the TCP header, and the `sniff_tcp_packets` function initializes the socket and processes incoming TCP packets. Keep in mind that decoding TCP packets often involves additional considerations, such as handling variable-length options within the TCP header."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 3,
   "id": "027eeef8-a33b-42e7-a388-9987b99aab7e",
   "metadata": {},
   "outputs": [
    {
     "name": "stderr",
     "output_type": "stream",
     "text": [
      "   Compiling decoding-tcp-packets v0.1.0 (/home/mahmoud/Desktop/Rust Book Dark/dark-web-rust/chapter-1/decoding-tcp-packets)\n",
      "    Finished dev [unoptimized + debuginfo] target(s) in 0.26s\n"
     ]
    },
    {
     "name": "stdout",
     "output_type": "stream",
     "text": [
      "\n",
      "Protocol: TCP 52.200.215.80 -> 192.168.1.8\n",
      "Version: 69\n",
      "Header Length: 52 TTL: 60\n",
      "Source Port: 443\n",
      "Destination Port: 42436\n",
      "Sequence Number: 3205079071\n",
      "Acknowledgment Number: 1443482503\n",
      "Data Offset: 32\n",
      "Reserved: 0\n",
      "Flags: 4097\n",
      "Window Size: 63162\n",
      "Checksum: 24832\n",
      "Urgent Pointer: 1\n"
     ]
    },
    {
     "data": {
      "text/plain": [
       "()"
      ]
     },
     "execution_count": 3,
     "metadata": {},
     "output_type": "execute_result"
    }
   ],
   "source": [
    "// The following command will execute the sniffer.\n",
    "// Set your sudo password below by replacing 'your-passowrd' accordingly\n",
    "\n",
    "let command = \"cd decoding-tcp-packets && cargo build && echo 'your-passowrd' | sudo -S sudo setcap cap_net_raw+ep target/debug/decoding-tcp-packets && target/debug/decoding-tcp-packets\";\n",
    "\n",
    "if let Err(err) = execute_command(command) {\n",
    "    eprintln!(\"Error executing command: {}\", err);\n",
    "}\n",
    "\n",
    "// Just open your web browser and surf the internet"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "9e338373-00d9-4c60-9c29-e4ac6d60fdac",
   "metadata": {},
   "source": [
    "The decoded information from the captured TCP packet reveals a communication exchange involving the IP address **52.200.215.80**, which is attributed to Amazon Web Services (AWS) Elastic Compute Cloud (EC2). [**AWS EC2**](https://en.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud) is a scalable cloud computing service that provides virtual servers in the cloud, allowing users to run applications and host various types of workloads. The presence of a TCP packet suggests a data transfer or communication event between the AWS EC2 instance, acting as the source (**52.200.215.80**), and our local machine with the destination IP address **192.168.1.8**.\n",
    "\n",
    "The identification of the TCP protocol in the \"**Protocol: TCP**\" field signifies that the communication adheres to the principles of Transmission Control Protocol, a foundational aspect of reliable data transmission over networks. The source port **443** and destination port **42436** provide insight into the specific application layer protocols in use. Port 443 is commonly associated with HTTPS, the secure variant of the HTTP protocol used for secure communication over the internet. The arbitrary destination port 42436 suggests that the communication may involve a dynamically assigned port for the client-side of the connection, our local machine.\n",
    "\n",
    "Examining the TCP flags, the value **4097** (binary 1000000000001) indicates that this is an **ACK** (Acknowledgment) packet. ACK packets are crucial for ensuring reliable data transfer and confirming the receipt of previously sent packets. The sequence and acknowledgment numbers, 3205079071 and 1443482503, respectively, reveal the progression of the data exchange. The data offset of 32, when multiplied by 4, yields a header length of 128 bytes, providing an extensive structure for encapsulating the TCP information. The window size of 63162 signifies the amount of data (in bytes) that can be sent before an acknowledgment is expected, contributing to the flow control mechanisms in TCP.\n",
    "\n",
    "Now that we have successfully decoded both ICMP and TCP packets, the subsequent phase in our network analysis efforts involves the complex process of decoding UDP (User Datagram Protocol) packets. [**UDP**](https://en.wikipedia.org/wiki/User_Datagram_Protocol), unlike TCP, operates as a connectionless and stateless protocol, prioritizing speed and simplicity over the robust reliability mechanisms inherent in TCP. As we delve into UDP packet decoding, we encounter a different set of challenges and nuances. UDP packets lack the elaborate handshaking and acknowledgment mechanisms found in TCP, making their decoding a more direct and, in some ways, more challenging task.\n",
    "\n",
    "The UDP decoding process necessitates a sharp understanding of the UDP header structure, including crucial fields such as source and destination ports, length, and checksum. The source and destination ports denote the application processes communicating over UDP, providing insight into the specific services involved in the data exchange. The length field specifies the total length of the UDP packet, aiding in proper segmentation and reassembly. The checksum field serves as a verification mechanism to ensure the integrity of the UDP packet during transmission.\n",
    "\n",
    "In our decoding journey, we must meticulously extract and interpret these UDP header fields, considering the contextual relevance of each piece of information within the broader network communication. The absence of a formal connection setup and teardown process in UDP introduces unique challenges, as deciphering the intent and context of UDP packets relies heavily on the payload data and its interpretation within the specific application layer protocol.\n",
    "\n",
    "As we extend our decoding capabilities to encompass UDP packets, we aim to uncover the underlying dynamics of real-time and efficient data communication. UDP is frequently employed in scenarios where low latency and rapid data transmission are paramount, such as in multimedia streaming, online gaming, and other time-sensitive applications. Therefore, our UDP decoding endeavors not only contribute to a comprehensive understanding of network traffic but also enable us to distinguish the diverse applications and services thriving within the network ecosystem. In navigating the complexities of UDP packet decoding, we embark on a journey to unravel the rich tapestry of communication protocols that form the backbone of modern networking, further enhancing our ability to comprehend and analyze the multifaceted landscape of data transmission in diverse network environments."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "6d918f51-bfda-4890-948e-72c1c5468b2d",
   "metadata": {},
   "source": [
    "### 1.7 Decoding UDP packets\n",
    "\n",
    "Decoding User Datagram Protocol (UDP) packets involves understanding the characteristics of the [**User Datagram Protocol (UDP)**](https://en.wikipedia.org/wiki/User_Datagram_Protocol), which is another transport layer protocol in the [**Internet Protocol Suite**](https://en.wikipedia.org/wiki/Internet_protocol_suite). Unlike TCP, UDP is connectionless and does not guarantee reliable communication. UDP is often favored for applications where low latency and simplicity are more critical than ensuring every packet arrives intact.\n",
    "\n",
    "Similar to decoding TCP packets, understanding UDP packets requires parsing the UDP header, which contains essential information about the communication session. The UDP header is relatively simple compared to TCP, consisting of source and destination port numbers, a length field, and a checksum. Deciphering these fields provides insights into the source and destination of the communication, the length of the UDP packet, and a basic form of error checking through the checksum.\n",
    "\n",
    ">                          User Datagram Protocol\n",
    ">                          ----------------------\n",
    "> \n",
    "> Introduction\n",
    "> ------------\n",
    "> \n",
    "> This User Datagram  Protocol  (UDP)  is  defined  to  make  available  a\n",
    "> datagram   mode  of  packet-switched   computer   communication  in  the\n",
    "> environment  of  an  interconnected  set  of  computer  networks.   This\n",
    "> protocol  assumes  that the Internet  Protocol  (IP)  [1] is used as the\n",
    "> underlying protocol.\n",
    "> \n",
    "> This protocol  provides  a procedure  for application  programs  to send\n",
    "> messages  to other programs  with a minimum  of protocol mechanism.  The\n",
    "> protocol  is transaction oriented, and delivery and duplicate protection\n",
    "> are not guaranteed.  Applications requiring ordered reliable delivery of\n",
    "> streams of data should use the Transmission Control Protocol (TCP) [2].\n",
    "> \n",
    "> Format\n",
    "> ------\n",
    "\n",
    "                                    \n",
    "                  0      7 8     15 16    23 24    31  \n",
    "                 +--------+--------+--------+--------+ \n",
    "                 |     Source      |   Destination   | \n",
    "                 |      Port       |      Port       | \n",
    "                 +--------+--------+--------+--------+ \n",
    "                 |                 |                 | \n",
    "                 |     Length      |    Checksum     | \n",
    "                 +--------+--------+--------+--------+ \n",
    "                 |                                     \n",
    "                 |          data octets ...            \n",
    "                 +---------------- ...                 \n",
    "\n",
    ">                       User Datagram Header Format\n",
    "> \n",
    "> Fields\n",
    "> ------\n",
    "> \n",
    "> Source Port is an optional field, when meaningful, it indicates the port\n",
    "> of the sending  process,  and may be assumed  to be the port  to which a\n",
    "> reply should  be addressed  in the absence of any other information.  If\n",
    "> not used, a value of zero is inserted.\n",
    "> \n",
    "> \n",
    "> \n",
    "> \n",
    "> \n",
    "> Postel                                                          [page 1]\n",
    "\n",
    "[**Excerpt from rfc768 Page 1**](https://www.ietf.org/rfc/rfc768.txt)\n",
    "\n",
    "Decoding UDP packets involves extracting and interpreting these fields, similar to the TCP decoding process. The source and destination port numbers identify the applications or services involved in the communication, while the length field informs about the size of the UDP packet. The checksum is used for basic error detection, although UDP itself does not provide mechanisms for retransmission or acknowledgment.\n",
    "\n",
    "Now, let's explore an example of decoding UDP packets using the same `socket2` crate in Rust:\n",
    "\n",
    "```rust\n",
    "use std::mem::MaybeUninit;\n",
    "use std::net::SocketAddr;\n",
    "use std::net::{IpAddr, Ipv4Addr};\n",
    "\n",
    "// Constants for UDP header size\n",
    "const UDP_HEADER_SIZE: usize = 8;\n",
    "\n",
    "struct UDP {\n",
    "    source_port: u16,\n",
    "    destination_port: u16,\n",
    "    length: u16,\n",
    "    checksum: u16,\n",
    "}\n",
    "\n",
    "impl UDP {\n",
    "    fn new(buffer: &[u8]) -> Self {\n",
    "        // Parse the UDP header fields from the buffer\n",
    "        let source_port = u16::from_be_bytes([buffer[0], buffer[1]]);\n",
    "        let destination_port = u16::from_be_bytes([buffer[2], buffer[3]]);\n",
    "        let length = u16::from_be_bytes([buffer[4], buffer[5]]);\n",
    "        let checksum = u16::from_be_bytes([buffer[6], buffer[7]]);\n",
    "\n",
    "        UDP {\n",
    "            source_port,\n",
    "            destination_port,\n",
    "            length,\n",
    "            checksum,\n",
    "        }\n",
    "    }\n",
    "}\n",
    "\n",
    "fn sniff(address: SocketAddr) {\n",
    "    let socket_protocol = if cfg!(target_os = \"windows\") {\n",
    "        0\n",
    "    } else {\n",
    "        17 // UDP\n",
    "    };\n",
    "\n",
    "    let sniffer = socket2::Socket::new(\n",
    "        socket2::Domain::IPV4,\n",
    "        socket2::Type::RAW,\n",
    "        Some(socket2::Protocol::from(socket_protocol)),\n",
    "    )\n",
    "    .unwrap();\n",
    "\n",
    "    sniffer.bind(&address.into()).unwrap();\n",
    "\n",
    "    let mut buffer: [MaybeUninit<u8>; 65535] = unsafe { MaybeUninit::uninit().assume_init() };\n",
    "    loop {\n",
    "        // Receive a UDP packet\n",
    "        let _length = sniffer.recv_from(&mut buffer).unwrap();\n",
    "        let raw_buffer: &[u8] =\n",
    "            unsafe { std::slice::from_raw_parts(buffer.as_ptr() as *const u8, buffer.len()) };\n",
    "\n",
    "        // Process the UDP packet\n",
    "        if size >= UDP_HEADER_SIZE {\n",
    "            let udp_header = UDP::new(&raw_buffer[..UDP_HEADER_SIZE]);\n",
    "            // Print or process UDP header information\n",
    "            println!(\"Source Port: {}\", udp_header.source_port);\n",
    "            println!(\"Destination Port: {}\", udp_header.destination_port);\n",
    "            println!(\"Length: {}\", udp_header.length);\n",
    "            println!(\"Checksum: {}\", udp_header.checksum);\n",
    "        }\n",
    "    }\n",
    "}\n",
    "\n",
    "fn main() {\n",
    "    let socket = SocketAddr::new(IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)), 12345);\n",
    "\n",
    "    sniff(socket);\n",
    "}\n",
    "```\n",
    "\n",
    "This example sets up a raw socket, binds it to a local address (loopback address), and enters a loop to continuously capture and process UDP packets. The `UDP` struct encapsulates the relevant fields from the UDP header, and the `sniff` function initializes the socket and processes incoming UDP packets. Keep in mind that decoding UDP packets often involves simpler parsing compared to TCP, as UDP lacks the complexity of connection-oriented communication."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 9,
   "id": "77b62110-a6f9-4522-8065-317b1e2e5f9e",
   "metadata": {},
   "outputs": [
    {
     "name": "stderr",
     "output_type": "stream",
     "text": [
      "[sudo] password for mahmoud:     Finished dev [unoptimized + debuginfo] target(s) in 0.01s\n"
     ]
    },
    {
     "name": "stdout",
     "output_type": "stream",
     "text": [
      "\n",
      "Protocol: UDP 192.168.1.3 -> 224.0.0.251\n",
      "Version: 69\n",
      "Header Length: 89 TTL: 255\n",
      "Source Port: 5353\n",
      "Destination Port: 5353\n",
      "Length: 69\n",
      "Checksum: 12990\n"
     ]
    },
    {
     "data": {
      "text/plain": [
       "()"
      ]
     },
     "execution_count": 9,
     "metadata": {},
     "output_type": "execute_result"
    }
   ],
   "source": [
    "// The following command will execute the sniffer.\n",
    "// Set your sudo password below by replacing 'your-passowrd' accordingly\n",
    "\n",
    "let command = \"cd decoding-udp-packets && cargo build && echo 'your-passowrd' | sudo -S sudo setcap cap_net_raw+ep target/debug/decoding-udp-packets && target/debug/decoding-udp-packets\";\n",
    "\n",
    "if let Err(err) = execute_command(command) {\n",
    "    eprintln!(\"Error executing command: {}\", err);\n",
    "}\n",
    "\n",
    "// Just open your web browser and watch a video on YouTube, for example."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "e7f6cca6-50b7-4354-ab87-fde2fbef6dab",
   "metadata": {},
   "source": [
    "The above output represents a UDP packet captured from a network communication. The protocol field indicates that the packet operates under the User Datagram Protocol (UDP). In this specific instance, the communication originates from the IP address 192.168.1.3 and is destined for the multicast address 224.0.0.251. Multicast addresses like 224.0.0.251 are often used for service discovery in local networks, and UDP is a suitable choice for such scenarios due to its lightweight and connectionless nature.\n",
    "\n",
    "Examining the details of the UDP packet, the version field appears anomalous as it is labeled as 69. Typically, the version field in UDP packets is set to 0, and the presence of 69 could indicate a non-standard or proprietary use of the protocol. The header length is reported as 89, and the Time-to-Live (TTL) is set to the maximum value of 255. These values suggest a relatively large and possibly complex UDP packet with an extended header. The Source and Destination Ports are both identified as 5353, indicating a consistent port for both the sender and receiver. The Length field specifies the size of the UDP packet as 69 bytes, and the Checksum is reported as 12990, which is a value computed for error-checking purposes. In-depth analysis of these fields aids in understanding the characteristics and potential purposes of this UDP communication.\n",
    "\n",
    "The context of this UDP packet, being associated with multicast communication, suggests a scenario where devices on the network are exchanging service-related information. The choice of UDP aligns with service discovery mechanisms, which often prioritize efficiency and real-time updates over the reliability ensured by TCP. The unusual version field and the seemingly extended header length warrant further investigation, as they may indicate a specialized application or protocol extension. In conclusion, decoding and comprehending the complexities of this UDP packet provide valuable insights into the dynamics of local network communication and the specific protocols employed for service discovery or similar purposes."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "7c1b572f-8d4b-43dc-a694-449aeb4fe71a",
   "metadata": {},
   "source": [
    "### 1.8 Port Scanning in the Presence of SYN-flood Protections\n",
    "\n",
    "Building a Port Scanning tool in the presence of [**SYN-flood**](https://en.wikipedia.org/wiki/SYN_flood) Protections involves understanding how to find open ports, especially when facing challenges like SYN-flood protections. In the following sections, we are going to create a program to scan for open ports on a remote host. However, sometimes it can be wrong. This happens when a system uses SYN-flood protections, a kind of security that can confuse our program by making all ports look the same. Even if they are open, closed, or filtered, they all seem open due to a special security measure called [**SYN cookies**](https://en.wikipedia.org/wiki/SYN_cookies). These cookies help prevent certain types of cyber attacks, but they can also make our program think a port is open when it's not.\n",
    "\n",
    "In scenarios where SYN cookies are deployed, distinguishing between a genuinely active service and a falsely indicated open port becomes a meticulous task. Both cases involve the completion of the TCP three-way [**handshake**](https://en.wikipedia.org/wiki/Handshake_(computing)), a sequence crucial for determining port status in traditional port scanning tools like [**Nmap**](https://en.wikipedia.org/wiki/Nmap). However, SYN-flood protections introduce complexity, limiting the reliability of these conventional tools. To address this challenge, an alternative approach is proposed, focusing on post-connection activities. SYN-flood protections typically refrain from packet exchanges beyond the initial handshake unless a service is actively listening. Consequently, the detection of additional packets post-handshake could signify the existence of a service.\n",
    "\n",
    "A crucial aspect of adapting port-scanning capabilities to account for SYN cookies lies in examining TCP flags. The TCP specification designates a single byte at position 14 in the packet's header to store flags, with each bit representing a specific flag value. To create an effective filter, the relevant flag positions are identified, including ACK and FIN, ACK, and ACK and PSH. Leveraging the `socket2` library, we can connect to a remote service, capture and filter packets, and selectively display services indicating legitimate communications with specific TCP headers. This approach assumes that services not conforming to these criteria are falsely labeled as \"open\" due to SYN cookies.\n",
    "\n",
    "The implementation of a [Berkeley Packet Filter (BPF)](https://en.wikipedia.org/wiki/Berkeley_Packet_Filter) filter is essential for inspecting specific flag values indicative of packet transfers. The filter, focusing on the 14th byte (offset 13 for a 0-based index) of the TCP header, targets packets with flags set to ack and fin, or ack, or ack && psh. The resulting BPF filter serves as a critical tool for determining legitimate service responses in the presence of SYN-flood protections.\n",
    "\n",
    "Subsequently, we will introduce a port-scanning program that utilizes the BPF filter to establish full TCP connections and analyze packets beyond the three-way handshake. The program, while not optimized for efficiency, provides a functional demonstration. Key variables, such as the filter, device availability, and a results map tracking port confidence levels, are defined. The `sniff` function, executed in a separate thread, captures and processes packets concurrently. The `main` function parses target ports, initiates TCP connection attempts, and processes results based on confidence levels.\n",
    "\n",
    "```rust\n",
    "fn sniff(\n",
    "    socket: SocketAddr,\n",
    "    _iface: &str,\n",
    "    target: &str,\n",
    "    results: Arc<Mutex<HashMap<String, usize>>>,\n",
    ") -> io::Result<()> {\n",
    "    let socket_protocol = if cfg!(target_os = \"windows\") {\n",
    "        0\n",
    "    } else {\n",
    "        6 // TCP\n",
    "    };\n",
    "    let sniffer = Socket::new(\n",
    "        Domain::IPV4,\n",
    "        Type::RAW,\n",
    "        Some(Protocol::from(socket_protocol)),\n",
    "    )?;\n",
    "    sniffer.bind(&socket.into())?;\n",
    "\n",
    "    // TODO: set interface\n",
    "    // Available only on MacOS: https://docs.rs/socket2/latest/socket2/struct.Socket.html#method.device_index_v4\n",
    "    // let iface_index = sniffer.device_index_v4(&iface)?;\n",
    "    // socket.bind_device_by_index_v4(Some(&iface_index))?;\n",
    "\n",
    "    let mut buffer: [MaybeUninit<u8>; 65535] = unsafe { MaybeUninit::uninit().assume_init() };\n",
    "\n",
    "    println!(\"Capturing packets\");\n",
    "    loop {\n",
    "        // Receive a TCP packet\n",
    "        let _length = sniffer.recv_from(&mut buffer).unwrap();\n",
    "        let raw_buffer: &[u8] =\n",
    "            unsafe { std::slice::from_raw_parts(buffer.as_ptr() as *const u8, buffer.len()) };\n",
    "\n",
    "        // Create an IP header from the first 20 bytes\n",
    "        let ip_header = match IP::new(&raw_buffer[..20]) {\n",
    "            Some(header) => header,\n",
    "            None => return Ok(()),\n",
    "        };\n",
    "\n",
    "        if ip_header.dst_address() != target {\n",
    "            continue;\n",
    "        }\n",
    "\n",
    "        if raw_buffer.len() < IPV4_HEADER_SIZE + TCP_HEADER_SIZE {\n",
    "            eprintln!(\"Invalid packet: too short\");\n",
    "            continue;\n",
    "        }\n",
    "\n",
    "        let tcp_header =\n",
    "            TCP::new(&raw_buffer[IPV4_HEADER_SIZE..IPV4_HEADER_SIZE + TCP_HEADER_SIZE + 1]);\n",
    "\n",
    "        // Check if the flags match the specified combinations for Berkeley Packet Filter\n",
    "        let ack = (tcp_header.flags & ACK) != 0;\n",
    "        let fin = (tcp_header.flags & FIN) != 0;\n",
    "        let psh = (tcp_header.flags & PSH) != 0;\n",
    "\n",
    "        if !(ack && fin || ack || ack && psh) {\n",
    "            continue;\n",
    "        }\n",
    "\n",
    "        // Add the source port\n",
    "        let mut results = results.lock().unwrap();\n",
    "        results\n",
    "            .entry(tcp_header.destination_port.to_string())\n",
    "            .and_modify(|e| *e += 1)\n",
    "            .or_insert(1);\n",
    "    }\n",
    "}\n",
    "\n",
    "fn main() -> io::Result<()> {\n",
    "    let args: Vec<String> = std::env::args().collect();\n",
    "    if args.len() != 3 {\n",
    "        eprintln!(\"Usage: {} <target_ip> <ports>\", args[0]);\n",
    "        std::process::exit(1);\n",
    "    }\n",
    "\n",
    "    let target = match args.get(1) {\n",
    "        Some(target) => target,\n",
    "        None => \"eth0\",\n",
    "    };\n",
    "\n",
    "    let ports: Vec<&str> = match args.get(2) {\n",
    "        Some(ports) => ports.split(',').collect(),\n",
    "        None => vec![\"eth0\"],\n",
    "    };\n",
    "\n",
    "    let iface = match args.get(3) {\n",
    "        Some(iface) => iface,\n",
    "        None => \"eth0\",\n",
    "    };\n",
    "\n",
    "    let results = Arc::new(Mutex::new(HashMap::new()));\n",
    "\n",
    "    let socket = SocketAddr::new(IpAddr::V4(Ipv4Addr::new(0, 0, 0, 0)), 12345);\n",
    "\n",
    "    let sniff_thread = thread::spawn({\n",
    "        let iface = iface.to_string();\n",
    "        let target = target.to_string();\n",
    "        let results = results.clone();\n",
    "        move || {\n",
    "            if let Err(err) = sniff(socket, &iface, &target, results) {\n",
    "                eprintln!(\"Error capturing packets: {}\", err);\n",
    "            }\n",
    "        }\n",
    "    });\n",
    "\n",
    "    thread::sleep(Duration::from_secs(1));\n",
    "\n",
    "    for port in ports {\n",
    "        let target_addr = format!(\"{}:{}\", target, port);\n",
    "        println!(\"Trying {}\", target_addr);\n",
    "        // Opens a TCP connection to a remote host with a timeout.\n",
    "        if let Ok(stream) =\n",
    "            TcpStream::connect_timeout(&target_addr.parse::<SocketAddr>().unwrap(), TIMEOUT)\n",
    "        {\n",
    "            println!(\"Couldn't connect to the remote host...\");\n",
    "            drop(stream);\n",
    "        }\n",
    "    }\n",
    "\n",
    "    thread::sleep(Duration::from_secs(2));\n",
    "\n",
    "    let results = results.lock().unwrap();\n",
    "    for (port, confidence) in results.iter() {\n",
    "        if *confidence >= 1 {\n",
    "            println!(\"Port {} open (confidence: {})\", port, confidence);\n",
    "        }\n",
    "    }\n",
    "\n",
    "    if results.len() == 0 {\n",
    "        println!(\"All scanned ports on {} are closed\", target);\n",
    "    }\n",
    "    sniff_thread.join().unwrap();\n",
    "    Ok(())\n",
    "}\n",
    "```\n",
    "\n",
    "This code contains two primary functions, namely `sniff` and `main`, aimed at facilitating port scanning with due consideration for SYN-flood protection mechanisms. A comprehensive understanding of the code's complexities necessitates a detailed exploration of each segment.\n",
    "\n",
    "#### The `sniff` Function:\n",
    "\n",
    "Within the code, the `sniff` function plays a pivotal role in capturing network packets and meticulously monitoring them to determine the status of open ports. This function exhibits a nuanced design, reflecting an intelligent approach to packet analysis. The function's signature discloses its parameters, notably the `socket` representing the local socket address for binding during packet capture, the `_iface` parameter intended for specifying the network interface (though currently unused), the `target` denoting the destination IP address for port scanning, and finally, the `results` parameter encapsulating the outcomes within an `Arc<Mutex<HashMap<String, usize>>>` structure, ensuring thread-safe storage.\n",
    "\n",
    "The internal workings of the `sniff` function reveal a strategic use of conditional checks and packet analysis techniques. The function begins by determining the protocol of the local socket, accounting for variations across operating systems. Following this, a `Socket` instance is instantiated to engage in raw socket operations. Despite a placeholder for setting the network interface (`_iface`), the current implementation remains devoid of this functionality. The function utilizes an iterative loop for continuous packet reception, forming the core of the packet-sniffing process.\n",
    "\n",
    "Incoming packets experience a multistage assessment, starting with the creation of an IP header based on the initial 20 bytes. Subsequently, the destination address of the IP header experiences a check, and if it aligns with the designated target, the analysis proceeds. A safeguard against insufficient packet length is implemented to handle potential anomalies, flagging invalid packets that fall below a defined size threshold. The function then extracts the TCP header from the packet, and crucially, evaluates the TCP flags against predefined combinations indicative of particular states.\n",
    "\n",
    "Flag combinations such as `ACK and FIN`, `ACK`, and `ACK and PSH` are analyzed, with packets not conforming to these patterns being disregarded: the Berkeley Packet Filter. Upon a successful match, the source port information is extracted, and the results are updated within the thread-safe data structure. The utilization of a mutex ensures the integrity of concurrent data modifications. This complex technique of packet analysis within the `sniff` function forms the foundation of the overall port-scanning effort.\n",
    "\n",
    "#### The `main` Function:\n",
    "\n",
    "The `main` function orchestrates the overarching flow of the program, serving as the entry point for execution. Its primary responsibilities include parsing command-line arguments, initializing key variables, spawning a thread for packet sniffing, conducting TCP connection attempts on specified ports, and finally, presenting packed results.\n",
    "\n",
    "Starting with argument parsing, the function dynamically adapts to user inputs, accommodating variations in the provided parameters. The instantiation of an `Arc<Mutex<HashMap<String, usize>>>` structure named `results` signifies the shared container for collating and safeguarding the outcome of port scans.\n",
    "\n",
    "The creation of a socket address (`socket`) and subsequent thread instantiation for packet sniffing encapsulates the concurrent nature of the operation. A strategic pause via `thread::sleep` ensures synchronization, allowing the packet-sniffing thread to initialize before the subsequent port connection attempts begin.\n",
    "\n",
    "Iterating through the specified ports, the code initiates TCP connection attempts on the target IP, assessing the state of each port. A subsequent delay provides time for the packet-sniffing thread to capture relevant data. Post-delay, the results are extracted and analyzed, with open ports and associated confidence levels being displayed.\n",
    "\n",
    "Noteworthy is the final assessment, where the absence of open ports prompts a notification regarding the closure of all scanned ports on the target. The tidy conclusion of the `main` function involves awaiting the termination of the packet-sniffing thread, ensuring a graceful exit from the program.\n",
    "\n",
    "In summary, the combination of the `sniff` and `main` functions orchestrates a sophisticated yet rational approach to SYN-flood-protected port scanning. Each function contributes distinctively to the overarching objective, emphasizing the complexities involved in scanning network packets, interpreting TCP flags, and consolidating results within a concurrent and thread-safe framework."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 4,
   "id": "39b794ee-b94f-4a75-b048-40a8140a5376",
   "metadata": {},
   "outputs": [
    {
     "name": "stderr",
     "output_type": "stream",
     "text": [
      "    Finished dev [unoptimized + debuginfo] target(s) in 0.01s\n",
      "[sudo] password for mahmoud: Usage: target/debug/syn-flood-port-scanning <target_ip>\n",
      "Error executing command: Operation not permitted (os error 1)\n"
     ]
    },
    {
     "data": {
      "text/plain": [
       "()"
      ]
     },
     "execution_count": 4,
     "metadata": {},
     "output_type": "execute_result"
    }
   ],
   "source": [
    "// The following command will execute the sniffer.\n",
    "// Set your sudo password below by replacing 'your-passowrd' accordingly\n",
    "\n",
    "let command = \"cd syn-flood-port-scanning && cargo build && echo 'your-passowrd' | sudo -S setcap cap_net_raw+ep target/debug/syn-flood-port-scanning && target/debug/syn-flood-port-scanning\";\n",
    "\n",
    "if let Err(err) = execute_command(command) {\n",
    "    eprintln!(\"Error executing command: {}\", err);\n",
    "}"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "id": "279697b0-e7d3-4330-881d-29bb7c2e7126",
   "metadata": {},
   "outputs": [
    {
     "name": "stderr",
     "output_type": "stream",
     "text": [
      "    Finished dev [unoptimized + debuginfo] target(s) in 0.01s\n"
     ]
    },
    {
     "name": "stdout",
     "output_type": "stream",
     "text": [
      "Capturing packets\n",
      "Trying 127.0.0.1:80\n",
      "Trying 127.0.0.1:443\n",
      "Port 443 open (confidence: 1)\n",
      "Port 35642 open (confidence: 1)\n",
      "Port 35628 open (confidence: 3)\n",
      "Port 34006 open (confidence: 1)\n",
      "Port 80 open (confidence: 1)\n"
     ]
    }
   ],
   "source": [
    "// The following command will execute the sniffer.\n",
    "// Set your sudo password below by replacing 'your-passowrd' accordingly\n",
    "// Set <target_ip> and <port_numbers> at the very end of the command, like: 127.0.0.1 80,443,5555\n",
    "\n",
    "let command = \"cd syn-flood-port-scanning && cargo build && echo 'your-passowrd' | sudo -S setcap cap_net_raw+ep target/debug/syn-flood-port-scanning && target/debug/syn-flood-port-scanning 127.0.0.1 80,443\";\n",
    "\n",
    "if let Err(err) = execute_command(command) {\n",
    "    eprintln!(\"Error executing command: {}\", err);\n",
    "}"
   ]
  },
  {
   "cell_type": "markdown",
   "id": "cc461a75-6f0f-4c5f-9751-e49b4c419cbb",
   "metadata": {},
   "source": [
    "The output reveal the outcomes of the connection attempts, portraying a detailed account of the open ports and their associated confidence levels. Port 443 emerges as open with a confidence rating of 1, signifying that a packet with the specified TCP flags indicative of an open port was successfully intercepted during the packet-capturing phase. Similarly, ports 35642, 35628, and 34006 exhibit varying degrees of openness, each accompanied by a confidence level reflecting the frequency of corresponding packet captures. The confidence metric provides a nuanced perspective, offering insight into the reliability of the open port determination. In essence, a higher confidence level indicates a more robust affirmation of the port's accessibility."
   ]
  },
  {
   "cell_type": "markdown",
   "id": "7c2122da-745c-41f7-844f-33de862a03a6",
   "metadata": {},
   "source": [
    "In conclusion, the exploration of SYN-flood protections in port scanning underscores the dynamic nature of cybersecurity challenges. This section emphasizes adaptive strategies, leveraging post-connection packet analysis and BPF filters, to enhance the accuracy of port-scanning results in the presence of SYN cookies."
   ]
  }
 ],
 "metadata": {
  "kernelspec": {
   "display_name": "Rust",
   "language": "rust",
   "name": "rust"
  },
  "language_info": {
   "codemirror_mode": "rust",
   "file_extension": ".rs",
   "mimetype": "text/rust",
   "name": "Rust",
   "pygment_lexer": "rust",
   "version": ""
  }
 },
 "nbformat": 4,
 "nbformat_minor": 5
}