Skip to content

Developer Notes

Jump to bottom
Johnny Watts (aka., "Kaotick Jay") edited this page Jun 20, 2025 · 1 revision

🧑‍💻 Developer Notes

This page provides guidance for developers contributing to NetSentinel, including code style, logging standards, dependency practices, and a forward-looking roadmap.

🧱 Code Style & Logging Standards

Python Style Guide

NetSentinel follows a strict and uniform Python coding standard for consistency and maintainability:

Area Style Guide
Indentation 4 spaces (no tabs)
Line length 100 characters max
Function names snake_case
Class names PascalCase
Constant names ALL_CAPS
Comments Use full sentences, capitalize & punctuate
Docstrings Use """Triple-quoted""" for public methods & classes
Imports Grouped: stdlib, third-party, internal

⚠️ No magic numbers. Constants should be declared or loaded from config modules.

Logging Standards

All output must go through the Logger class in utils/logger.py.

logger = Logger()
logger.info("This is informational.")
logger.warn("This is a warning.")
logger.error("Something went wrong.")
logger.success("Operation completed successfully.")
logger.debug("Detailed technical info.")

Logging format:

[2025-06-20 14:23:01] [INFO] Starting SMB enumeration

Colorized output is reserved for CLI; future support for non-TTY output is under consideration.

📦 Dependency Management

NetSentinel uses a minimalist dependency set to keep the tool portable and easily auditable.

Required Libraries

scapy
colorama
impacket

All dependencies are pinned in requirements.txt to specific versions where necessary.

Managing Dependencies

  • Install using:

    pip install -r requirements.txt

  • Use [venv] for isolation:

    python3 -m venv .venv
source .venv/bin/activate

  • When adding a new module, document external imports at the top and update requirements.txt if new packages are introduced.

  • Avoid bloated frameworks or transitive dependencies unless explicitly required.

🚀 Roadmap & TODOs

This is a working list of planned improvements and in-progress development goals.

✅ Short-Term Roadmap (v1.1.x)

  • Modular recon architecture (core/)
  • JSON-based export
  • Environment-based config override
  • GitHub release and README polish
  • Documentation and wiki launch

🧪 Mid-Term Enhancements (v1.2+)

  • Add --snmp-enum module
  • Add NetBIOS name resolution module
  • Introduce configurable thread pool for faster scanning
  • Support authenticated SMB enumeration
  • Optional port range flag (override ports.py)
  • JSON schema validation for output file
  • Add verbosity flag for debug output (--debug)

🔒 Long-Term Features (v1.5+)

  • Plugin system for loading external modules
  • TLS service banner extraction
  • Host OS fingerprinting based on TTL and banners
  • File-based logging support (--log-file)
  • Optional SQLite export mode
  • Add detection signature research (simulate beaconing tools)

⚠️ Potential Refactors

  • Refactor recon.py for better testability and decoupled scan logic
  • Abstract main.py CLI parsing into reusable function (cli.py)
  • Modularize credentials handling and encryption support

💡 Contribution Tips

  • Always branch from dev (or your feature branch) — not main
  • Name branches clearly: feature/snmp-enum, fix/kerberos-timeout
  • Write clear, actionable commit messages
  • Maintain testability: write isolated functions/methods with no global state

🛡 Security Practices

  • Do not commit credentials or .json config files
  • Add test coverage to sensitive modules (kerberos_enum, etc.)
  • Validate all input and fail gracefully with informative logging

📞 Questions or Feature Ideas?

  • Use GitHub Issues to track bugs or feature requests
  • PRs are welcome and should follow the guidelines above
  • Tag with enhancement, bug, or security when relevant

This project showcases real-world red team tool engineering with an emphasis on stealth, maintainability, and extensibility.

Clone this wiki locally