RamiBot v3.8.0 – Installer + Setup Experience

🚀 Installation Experience Update

🚀 RamiBot v3.8.0 introduces a full installation experience from a clean system.

From zero to a fully operational cybersecurity environment — guided, reproducible, and accessible.

✨ Highlights

• 🎥 Full installation demo (clean Windows environment)
• 🛠️ Inno Setup installer configuration added
• ⚙️ Setup scripts (Windows & Linux)
• 🎨 UI improvements
• 🐳 Updated Docker configuration

---

🎥 Full Installation Demo (Windows)

---

⚠️ Notes

• First run may take ~15–20 minutes (container creation)
• Next runs are significantly faster

---

🎯 Why this matters

Setting up a cybersecurity environment is often complex and time-consuming.

RamiBot reduces that friction by guiding the process and preparing a ready-to-use environment.

---

⭐ If you find RamiBot useful, consider starring the repository.

RamiBot v3.7.3 — OAuth Token Authentication for OpenAI Codex and Anthropic

What's new in v3.7.3

OpenAI OAuth Token (ChatGPT Plus/Pro subscription)

• RamiBot can now authenticate with OpenAI using the OAuth token from the Codex CLI (~/.codex/auth.json) instead of
  a platform API key
• Routes requests to chatgpt.com/backend-api/codex/responses — uses your ChatGPT subscription instead of pay-per-use
  billing
• Account ID extracted automatically from the JWT — no manual configuration
• Static model list: GPT-5.2 Codex, GPT-5.1 Codex Max, GPT-5.1 Codex, GPT-5.1 Codex Mini, GPT-5.2, GPT-5.1, GPT-5
• Full tool calling and streaming support via the Responses API SSE protocol
• Set the access_token from ~/.codex/auth.json in Settings → API Keys → OpenAI OAuth Token

Anthropic OAuth Token (reserved)

• OAuth token field added for Anthropic (sk-ant-oat01-* format validation)
• Currently non-functional — Anthropic blocked third-party OAuth access in February 2026
• Infrastructure is in place and will activate automatically when Anthropic re-enables it

Settings UX

• Saving settings now automatically refreshes the model list — no need to reload the page or re-select the provider
  after entering new credentials

v3.7.2 — Service-Bound CVE Correlation & NVD 2.0 API

What's new in v3.7.2

Service-Bound CVE Correlation

Each CVE returned by cve_lookup now includes a SERVICE BINDING line derived from
CPE data, naming the exact vendor/product the CVE applies to. A global rule
(EVIDENCE_RULES rule 9) enforces that every CVE in a report or analysis is attached
only to the matching detected service — never reassigned to an unrelated service on the
same host.

CVE Query Lock

A new global rule (EVIDENCE_RULES rule 10) prevents the LLM from drifting when building
cve_lookup queries after service discovery. Queries must be derived strictly from
the detected product name and version string present in tool output. Forbidden inputs:
host IP, semantic pivots to adjacent software (Apache ≠ Log4j), and famous CVEs
introduced from background knowledge without a confirmed product match. The rule is
reinforced at skill level in both recon and analysis.

Expanded cve_lookup — Full NVD 2.0 API support

The tool now exposes the complete NVD 2.0 API parameter set:

Parameter	Description
keyword + exact_match	Whole-word keyword matching
cpe_name	Filter by full CPE 2.3 string
virtual_match_string	CPE pattern/wildcard matching
cvss_severity	Filter by LOW / MEDIUM / HIGH / CRITICAL
pub_start_date / pub_end_date	Publication date range
last_mod_start_date / last_mod_end_date	Last-modified date range
no_rejected	Exclude REJECT-status CVEs

The knowledge file (rami-kali/knowledge/tools/cve_lookup.md) has been fully rewritten
with a parameter table, 8 invocation examples, and the CVE Query Lock decision
sequence.

Files changed

rami-kali/mcp_server.py · backend/skills/composer.py ·
backend/skills/definitions/recon.json · backend/skills/definitions/analysis.json ·
backend/skills/definitions/reporting.json · rami-kali/knowledge/tools/cve_lookup.md
· README.md · rami-kali/README.md

RamiBot v3.7.1 — CVE Intelligence via NVD API

What's new in v3.7.1

cve_lookup — CVE Intelligence Tool

New MCP tool that queries the NIST National Vulnerability Database (NVD)
in real time from inside the rami-kali container.

Capabilities:

• Look up any CVE by ID (e.g. CVE-2021-44228) — returns CVSS score,
  severity, description, affected CPEs and references
• Keyword search by product/version (e.g. apache log4j 2.14) with
  configurable result limit (1–20)
• No binary required — uses Python stdlib urllib, always available

Evidence integration:

• Full Evidence Gate support: has_findings: true with verified CVE ID,
  CVSS score and status as confirmed facts
• Dedicated knowledge base at knowledge/tools/cve_lookup.md with NVD
  query strategy, CVSS bands, evidence rules and chaining workflows
• Chains naturally with searchsploit_query and nuclei_scan:
  nmap discovers version → cve_lookup enriches → searchsploit finds exploit

Total active MCP tools: 45

RamiBot v3.7 — zsh shell, proxychains4, and expanded toolset

What's new in v3.7

                                                                                                                                                                                                                                           ### rami-kali

• zsh by default — syntax highlighting (green/red feedback) and autosuggestions (arrow-up / →) in the Docker terminal - proxychains4 with two ready-made profiles: Burp (/etc/proxychains4.conf) and Tor (/etc/proxychains4-tor.conf)
• New pentest tools: masscan, ffuf, nuclei, theHarvester
• gobuster_dir now accepts a proxy parameter for direct Burp/Tor routing
• QoL packages: nano, vim-tiny, tmux, jq, socat, net-tools, lsof, procps, and more

Backend

• terminal.py shell detection now prefers zsh → bash → sh

RamiBot v3.6 -- Burp Suite skill, language selector, and Hermes tool chaining

Release 3.6

New

• burp_expert skill — new skill for web application assessment via Burp Suite MCP:
  staged workflow (traffic generation → proxy history → request crafting → fuzzing),
  evidence discipline rules, and anti-XML tool execution enforcement

• Response language selector — choose LLM response language (Auto / ES / EN / FR / DE / PT / IT)
  from Settings → Interface; removed from Sidebar

Improved

• Hermes tool chaining — backend now detects and executes <tool_call> XML emitted as plain
  text by Hermes/Llama fine-tuned models; up to 8-hop tool loop with full tool schema per hop

• Tool name resolution — normalized lookup (full name + tool-part after __) so model-output
  names like get_proxy_http_history correctly resolve to rami-kali__get_proxy_http_history

Fixed

• Tor DNS startup race condition — Rami-Kali now waits for both TransPort (9040) and
  DNSPort (5353) before applying transparent proxy iptables rules, preventing DNS resolution
  failures (Could not resolve host) during Tor initialization

Maintenance

• Repository line-ending normalization — enforced LF endings via .gitattributes for
  cross-platform consistency (Docker / Linux environments)

RamiBot v3.5 — Deterministic Security Reporting

🚀 RamiBot v3.5.0
Deterministic Security Reporting

This release introduces strict evidence-based reporting across all modes.

Improvements

Evidence-locked analysis (tool output only)

No inferred vulnerabilities or severity inflation

Severity derived exclusively from confirmed scanner findings

Conditional risk language enforced

Internal reasoning fully isolated from reports and PDFs

Structured RAW → PARSED → INTERPRETATION separation

Outcome

RamiBot now produces deterministic, reproducible, and tool-grounded security reports.

Tag: v3.5.0
Commit: 57d5aa9

RamiBot v3.4 — Tool Approval Gate - PDF

What's new in v3.4

Tool Approval Gate (human-in-the-loop MCP)

RamiBot now supports an optional approval gate that pauses execution before every MCP tool call and waits for explicit
operator confirmation.

How it works:

1. Enable MCP in the sidebar → the Approval Mode toggle appears
2. Activate it — every tool call triggers an inline banner
3. The banner shows: tool name, key arguments (target, host, port…), a risk badge colored by level, and a
   120 s countdown
4. Click APPROVE → tool runs normally; DENY → LLM receives [TOOL EXECUTION DENIED BY USER] and responds
   accordingly
5. No response in 120 s → auto-denied

Risk levels sourced from rami-kali/config.yaml → risk_levels:

Level	Color	Examples
low	🟢 green	default
medium	🟡 amber	default for unlisted tools
high	🟠 orange	sqlmap, hydra, msf_console, mimikatz…
critical	🔴 red	configurable

Edge cases covered: multiple tool calls per turn (sequential banners), Stop during approval, 120 s timeout
auto-deny, MCP-disabled hides the toggle.

Also included

• reportPdf.js — browser-native PDF export for security reports
• UI polish and findings improvements carried over from v3.3

Files changed

• backend/main.py
• frontend/src/components/ToolApprovalBanner.jsx (new)
• frontend/src/components/ChatPanel.jsx
• frontend/src/components/Sidebar.jsx
• frontend/src/store.js
• frontend/src/reportPdf.js (new)
• README.md

v3.3.0 — Multi-Provider Tool Execution Stabilization

RamiBot v3.3.0

Release Date: 2026-02-27

---

🚀 Overview

Version 3.3.0 introduces major architectural improvements to multi-provider tool execution, enhanced timeout handling, and stronger error control mechanisms.

This release significantly improves stability, reliability, and provider abstraction consistency across the platform.

---

✨ Architecture Improvements

🔄 Multi-Provider Tool Format Normalization

Different LLM providers expect different tool execution formats.
v3.3.0 standardizes internal history handling while adapting per provider.

OpenAI / OpenRouter / LM Studio / Ollama

Follow-up history uses OpenAI-style format:

• role: "assistant" with tool_calls array
• role: "tool" with tool_call_id

This format is used internally as the canonical representation.

Anthropic

The method _convert_messages() in:

backend/adapters/anthropic_adapter.py

translates OpenAI-style tool messages into Anthropic-compatible format:

• tool_use blocks
• tool_result blocks

Any new provider extending BaseAdapter must implement equivalent translation logic if its API does not accept OpenAI-style tool messages.

---

⏱ Timeout Adaptation

Improved handling of long-running tool executions:

• Better synchronization between backend execution time and LLM expectations
• Reduced premature timeouts
• More consistent follow-up behavior after delayed tool responses

---

🛠 Command Corrections

• Fixed inconsistencies in tool invocation flow
• Improved argument parsing
• Cleaner execution pipeline between main.py and adapters

---

🚨 Robust Error Handling

If a tool fails due to:

• Exception
• Timeout
• Execution error

The function:

_format_tool_content() (main.py)

injects an explicit failure notice:

[TOOL EXECUTION FAILED]

This ensures:

• The LLM reports real execution errors
• Fabricated tool outputs are prevented
• Output remains auditable and deterministic

---

🧠 Impact

• Improved multi-provider compatibility
• Reduced hallucinated tool responses
• Cleaner adapter abstraction layer
• Stronger foundation for future provider integrations

---

🔜 Forward Compatibility

The adapter architecture is now structured to support:

• Additional LLM providers
• Custom provider-specific message translation layers
• More advanced execution control in future major versions

---

End of v3.3.0

RamiBot v3.2.0 – Public Release

🚀 RamiBot v3.2.0
✨ New Features

Scope selection directly from UI

Persistent scope configuration

Docker container start/stop from frontend

⚙ Improvements

MCP stability improvements

UI enhancements

🐛 Fixes

Minor frontend fixes