v0.1.0

Support the Developer

DirNutek - A High-Speed, Professional Web Fuzzer

DirNutek is a blazing-fast, concurrent directory and file scanner for web servers, designed to be a professional-grade tool for web reconnaissance. It started as a fun "chillout" project to master asynchronous Rust and has evolved into a powerful fuzzer capable of discovering hidden content and potential vulnerabilities.

---

Development Roadmap

This roadmap outlines the development plan for DirNutek, transforming it from a powerful scanner into a full-featured, professional web fuzzing tool.

Phase 1: Core Engine (Completed)

This phase established the fundamental building blocks of the fuzzer.

• ✅ CLI Argument Parsing: A robust command-line interface using clap.
• ✅ Concurrent HTTP Requests: A high-performance, asynchronous scanning engine using tokio and reqwest.
• ✅ Response Handling & Filtering: Basic and advanced filtering by status code, and content length (words, characters, lines).
• ✅ Concurrency Control: A Semaphore to manage the number of concurrent requests.
• ✅ Recursive Scanning: The ability to recursively scan discovered directories, with depth control.
• ✅ Multiple HTTP Methods: Support for a wide range of HTTP methods.

---

Phase 2: Advanced Fuzzing & Flexibility (In Progress)

This phase focuses on expanding the fuzzer's capabilities to handle more complex and realistic fuzzing scenarios.

• ✅ Multiple Fuzzing Modes:

  • Goal: Allow fuzzing of different parts of a URL, not just the path.
  • Implementation:
    • Introduce a FUZZ keyword that can be placed anywhere in the URL.
    • Parameter Fuzzing:
      • Use Case: Discovering vulnerabilities like SQL injection or Cross-Site Scripting (XSS) by fuzzing URL parameters.
      • Example: dirnutek -u "http://example.com/page?id=FUZZ" -w sqli.txt
    • Subdomain Fuzzing:
      • Use Case: Discovering hidden or forgotten subdomains.
      • Example: dirnutek -u "http://FUZZ.example.com" -w subdomains.txt
  • CLI: The -u flag will be enhanced to detect the FUZZ keyword and adapt the fuzzing strategy accordingly.

• ✅ Custom Headers & Authentication:

  • Goal: Enable scanning of authenticated endpoints and fuzzing of header values.
  • Implementation:
    • Add a -H, --header flag that can be specified multiple times.
    • Use Cases:
      • Authentication: -H "Authorization: Bearer <TOKEN>"
      • Custom User-Agent: -H "User-Agent: MyCustomScanner"
      • Header Fuzzing: -H "X-Forwarded-For: FUZZ"
  • CLI: -H, --header <HEADER>. The application will need to parse these headers and add them to every request. If FUZZ is present in a header value, the fuzzer will iterate through the wordlist for that header.

• ✅ POST Data Fuzzing:

  • Goal: Fuzz the body of POST requests.
  • Implementation:
    • Add a -d, --data flag to specify the request body.
    • If the FUZZ keyword is present in the data, the fuzzer will replace it with words from the wordlist.
  • Use Case: Finding vulnerabilities in forms and API endpoints that accept POST requests.
  • Example: dirnutek -u http://example.com/login -d '{"username":"admin","password":"FUZZ"}' -w passwords.txt -X POST

---

Phase 3: Professional Tooling & Output (To Do)

This phase focuses on features that make DirNutek a professional-grade tool that can be integrated into larger security workflows.

• ✅ Advanced Reporting:

  • Goal: Provide machine-readable output formats for easy parsing and integration with other tools.
  • Implementation:
    • Add a -o, --output <FILE> flag to save results to a file.
    • Add a --format flag to specify the output format.
    • Use the serde crate to serialize results into different formats.
  • Formats:
    • json: For easy parsing by scripts and other tools.
    • csv: For easy import into spreadsheets.
    • txt: Plain text (default).

• ✅ Session Management:

  • Goal: Allow users to pause and resume long-running scans.
  • Implementation:
    • Periodically save the state of the scan (e.g., the current queue, visited URLs) to a state file.
    • Add a --resume <STATE_FILE> flag to load the state and continue the scan.
  • Use Case: Recovering from interruptions without losing progress on large scans.

---

Phase 4: The "Show-Off" Features (Future)

This phase includes features that will make DirNutek a truly top-tier tool.

• [FUTURE] Interactive TUI Dashboard:

  • Goal: Provide a real-time view of the scan's progress.
  • Implementation:
    • Use a crate like ratatui to create a terminal user interface.
    • Display real-time statistics like:
      • Requests per second (RPS).
      • A live-updating list of found results.
      • Total progress (e.g., "Request 10,234 / 50,000").
      • Error rates.

• [FUTURE] Plugin/Scripting Engine:

  • Goal: Allow for ultimate flexibility by enabling users to write their own custom logic.
  • Implementation:
    • Embed a scripting language like Lua or Rhai.
    • Expose parts of the fuzzer's internal state to the scripting engine.
  • Use Cases:
    • Custom payload generation.
    • Complex response validation logic.
    • Chaining requests based on previous results.

---

Original Project Idea & Implementation Notes

The following sections detail the original project idea and implementation notes, which serve as the foundation for the current and future development of DirNutek.

Core Features (The "MVP")

1. CLI: Use the clap crate to take command-line arguments:
   • -u or --url: The base URL to scan (e.g., http://testsite.com).
   • -w or --wordlist: The path to the text file (e.g., ~/wordlists/common.txt).
2. Core Logic:
   • Read the wordlist file.
   • For each word in the file (e.g., "admin"), create a new URL (e.g., http://testsite.com/admin).
   • Create a tokio task to send an HTTP GET or HEAD request to that URL.
3. Concurrency: Don't do this one by one! Use tokio::spawn to launch hundreds (or thousands) of these requests concurrently.
4. Response Handling:
   • Check the HTTP status code of the response.
   • Print interesting results:
     • [200 OK] /index.html
     • [301 Moved] /old-page -> /new-page
     • [403 Forbidden] /admin (Finding a "Forbidden" directory is a win!)
   • Ignore boring results: By default, you'd ignore 404 Not Found.

"Show-Off" Bonus Features 🚀

• Recursive Scanning: If you find a directory (e.g., /api/), automatically start a new scan inside that directory (e.g., /api/users, /api/v1, etc.).
• Status Code Filtering: Add flags to let the user filter results.
  • --exclude-404 (Default)
  • --include-500 (To find server errors)
  • --only-200 (To only see valid pages)
• Concurrency Limiting: Use a tokio::sync::Semaphore to limit concurrent requests to a specific number (e.g., 50) so you don't crash your machine or the target.
• TUI Dashboard: Use ratatui to make a cool terminal dashboard showing:
  • Requests per second (RPS).
  • A live-updating list of "Found" results.
  • Total progress (e.g., "Request 10,234 / 50,000").

Implementation Plan: DirNutek

This plan outlines a structured approach to building DirNutek, starting with the Minimum Viable Product (MVP) and then progressively adding "Show-Off" bonus features.

Phase 1: Project Setup & MVP

1. ✅ Project Initialization:

   • ✅ Create a new Rust project: cargo new dirnutek --bin
   • ✅ Add dependencies to Cargo.toml:

     [dependencies]
     clap = { version = "4.0", features = ["derive"] } # For CLI argument parsing
     tokio = { version = "1", features = ["full"] } # For asynchronous runtime
     reqwest = { version = "0.11", features = ["json", "rustls-tls"] } # For HTTP requests
     anyhow = "1.0" # For simplified error handling
     # Consider `url` crate for robust URL manipulation if needed

   • ✅ Consideration: Start with a minimal set of features for tokio and reqwest and add more as needed to keep compile times down. rustls-tls is generally preferred for security over native-tls.

2. ✅ CLI Argument Parsing (clap):

   • ✅ Define a struct to hold command-line arguments (URL, wordlist path).
   • ✅ Use #[derive(Parser)] and #[clap(author, version, about)] for metadata.
   • ✅ Implement argument validation (e.g., URL format, wordlist file existence).
   • ✅ Consideration: Provide clear help messages for all arguments.

3. Wordlist Loading:

   • ✅ Create an async function to read the wordlist file.
   • ✅ Read the file line by line, storing words in a Vec<String>.
   • ✅ Handle file I/O errors gracefully (e.g., file not found).
   • Consideration: For very large wordlists, consider streaming words instead of loading all into memory to reduce memory footprint.

4. Asynchronous HTTP Requests (tokio, reqwest):

   • ✅ Create an async function, e.g., scan_url(client: &reqwest::Client, base_url: &str, word: &str) -> Result<(), anyhow::Error>.
   • ✅ Inside scan_url, construct the full URL (e.g., http://example.com/admin).
   • ✅ Use reqwest::Client to send GET or HEAD requests. HEAD requests are often f...