मैंने मौजूदा kali-mcp को Go में फिर से इम्प्लीमेंट करके देखा है

नमस्ते। मैं सूचना सुरक्षा विभाग में पढ़ाई कर रहा एक विश्वविद्यालय छात्र हूँ।

मैं mock hacking / traffic testing / CTF automation कार्यों में kali-mcp का अक्सर उपयोग करता रहा हूँ, लेकिन कई agents को एक साथ जोड़ने वाले वातावरण में bottleneck का सामना करना पड़ा, इसलिए मैंने इसे सीधे Go में फिर से इम्प्लीमेंट करके देखा।

GitHub: https://github.com/found-cake/kali-mcp-go

---

मौजूदा kali-mcp की संरचना और सीमाएँ

मूल संस्करण Flask + Python में इम्प्लीमेंट किया गया है, और CommandExecutor class हर request पर subprocess.Popen बनाती है, फिर stdout/stderr को अलग-अलग पढ़ने के लिए 2 daemon threads अतिरिक्त रूप से चलाती है।

एकल agent में यह पर्याप्त है, लेकिन multi-agent वातावरण में जब concurrent requests बढ़ जाती हैं, तो नीचे जैसी समस्याएँ आती हैं।

• Flask का डिफ़ॉल्ट single worker — agents एक-दूसरे को block करते हैं
• हर request पर process + thread creation overhead
• agent response delay को timeout समझकर उसी काम को फिर से retry करते हैं

---

मुख्य बदलाव

सर्वर

• पहले: Flask (डिफ़ॉल्ट single worker)
• बदलाव: Fiber v3 / fasthttp — पूरी concurrency

आउटपुट कलेक्शन

• पहले: 2 daemon threads के साथ readline loop
• बदलाव: 2 goroutines + WaitGroup के साथ synchronization, stdout/stderr कलेक्ट करने के समय को स्पष्ट रूप से मिलाकर बिना output loss के प्रोसेस किया

timeout/cancel

• पहले: process.wait(timeout=...) + force kill
• बदलाव: context-आधारित — pipe तक को सटीक रूप से बंद किया जाता है

Metasploit अस्थायी फ़ाइल

• पहले: /tmp/mks_msf_resource.rc hardcoding — concurrent requests में race condition की संभावना
• बदलाव: os.CreateTemp — हर request के लिए unique filename के साथ सुरक्षित प्रोसेसिंग

tshark समर्थन

• पहले: नहीं
• बदलाव: dedicated endpoint जोड़ा गया

---

आर्किटेक्चर

पहले जैसी ही 2-tier संरचना बनाए रखते हुए अंदरूनी हिस्से को बदला गया है।

[AI Client]  →(MCP stdio)→  [mcp-client]  →(HTTP + Bearer token)→  [kali-server]  →(exec)→  [nmap, tshark, ...]