VoidGuard - v6.0.3

v6.0.3

Other changes

• Fix : Phase 6 Some ERRs (559b69b)
• Update : Phase 6 (Final) (04808cf)

Full changelog: v5.0.2...v6.0.3

VoidGuard - v5.0.2

v5.0.2

Other changes

• Fix : Some version ERRs (66792c9)

Full changelog: v5.0.0...v5.0.2

VoidGuard - 5.0.0

v5.0.0

Other changes

• Update : Phase 5 (7b7d894)

Full changelog: v3.0.0...v5.0.0

VoidGuard - v3.0.0

v3.0.0

Other changes

• Fix : Phase 4 Fixed (a602af5)
• Update : Phase 4 (21ffc25)
• Update : Phase 3 (afcb952)
• Docs : Update WIKI (0eea4c0)

Full changelog: v2.1.0...v3.0.0

VoidGuard - v4.0.0

v4.0.0

Other changes

• Update : Phase 4 (21ffc25)
• Update : Phase 3 (afcb952)
• Docs : Update WIKI (0eea4c0)

Full changelog: v2.1.0...v4.0.0

VoidGuard - v2.1.0

Changelog

All notable changes to this project are documented here.
Format loosely follows Keep a Changelog.

[Unreleased] — Phase 3 not started

Added (Phase 2 completion)

• Network Adapters tab: full adapter list (IPv4/IPv6/gateway/DNS/MAC/
  DHCP/link speed) via native GetAdaptersAddresses.
• Services Manager: list, start/stop/restart, and change startup type
  via native Service Control Manager APIs, with an extra-strength
  confirmation for a starter set of protected system services.
• Phase 2 marked complete in handoffs/02-phase-2-handoff.md, with a
  prioritized checklist for the first Windows compile/debug pass.

Phase 2 (process + ports)

Added

• Process Manager: live process table, search, sort, confirmed termination.
• Open Port Monitoring: TCP/UDP listening endpoints with owning process.
• Port Control: terminate a port's owning process; open/block a port
  via native Windows Firewall COM API (no shell execution).
• Project renamed from the internal working name "WinGuard" to VoidGuard.
• Per-phase handoff documents under handoffs/.
• GitHub project scaffolding: LICENSE, CONTRIBUTING, CODE_OF_CONDUCT,
  issue/PR templates, CI workflow.
• Project wiki source under wiki/.
• Informational GitHub Pages site under docs/.

Known caveats

• Native Windows code (GetExtendedTcpTable/GetExtendedUdpTable,
  firewall COM interfaces) has not been compiled or run on Windows
  yet — see handoffs/02-phase-2-handoff.md.

[0.1.0] — Phase 1

Added

• Tauri + React + TypeScript + Tailwind app shell.
• Sidebar navigation (13 sections), dark/light/system theme.
• Live dashboard: CPU, RAM, disk, process count, uptime.
• SQLite schema for every planned subsystem.
• Event log and append-only audit log backend + read APIs.
• Honest "not implemented yet" placeholder for every unbuilt page.

VoidGuard - v2.0.0

Phase 2 Handoff — Process, Ports, Network, Services

Status: In progress — Process Manager and Open Port Control shipped;
Network Adapters and Services Manager remaining.
Date: 2026-08-22

What shipped

Process Manager (complete)

• commands::process::list_processes — full process table via sysinfo
  (pid, parent pid, name, exe path, CPU%, memory, start time).
• commands::process::terminate_process — explicit, confirmed-only kill.
• src/pages/ProcessesPage.tsx — search, column sort, confirm-before-kill
  dialog, structured error display on failed termination.
• Windows-specific enrichment (Authenticode signature, publisher,
  integrity level, SHA-256, live network-connection count) is modeled
  as Option fields, currently always None. This is the next piece
  of Phase 2/3 work, not a Phase 1 gap.

Open Port Monitoring + Control (complete, Windows-only — see caveat below)

Pulled forward from the original Phase 4 firewall scope at the user's
request, since "see what's on a port / kill it / open or close the
port" was wanted now rather than later:

• commands::ports::list_listening_ports — enumerates TCP + UDP
  listening endpoints via GetExtendedTcpTable / GetExtendedUdpTable
  (native windows crate, no shelling out), resolving each PID's
  process name and full image path via QueryFullProcessImageNameW.
• commands::ports::terminate_port_owner — kills the process bound to
  a port; thin wrapper over process::terminate_process that audits
  and logs the action as a port action specifically.
• commands::ports::open_port / close_port — creates/removes a
  single named Windows Firewall rule scoped to exactly one
  port + protocol + direction, via the native INetFwPolicy2 /
  INetFwRule COM interfaces (the same API the Firewall control panel
  itself uses). No netsh, no shell invocation anywhere.
• src/pages/NetworkPage.tsx — table of listening ports with risk
  badges, and three confirm-gated actions per row: terminate owner,
  block port, allow port. Every action shows a distinct confirmation
  dialog explaining exactly what will happen before the backend is
  called.
• Every port action (terminate/open/close) writes an audit_logs row
  and, on success, an events row (PORT_CLOSED / FIREWALL_CHANGED).

⚠️ Compile/runtime caveat — read before merging

This module was written in a Linux sandbox with no Windows target
available to compile or run against. The windows crate API
surface used here (GetExtendedTcpTable, GetExtendedUdpTable,
INetFwPolicy2, INetFwRule, QueryFullProcessImageNameW, buffer
sizing via a null-then-real call pattern) is written to the best of
available knowledge of the real Win32/COM signatures, but:

• Struct layouts (MIB_TCPTABLE_OWNER_PID, MIB_UDPTABLE_OWNER_PID)
  use a variable-length trailing array (table: [ROW; ANYSIZE_ARRAY])
  — the raw-pointer slice construction in enumerate_tcp/enumerate_udp
  needs to be verified against whatever layout the installed
  windows crate version actually generates.
• COM interface method names/signatures for INetFwRule setters
  (SetLocalPorts, SetProfiles, etc.) should be diffed against the
  windows crate version pinned in Cargo.toml (0.54) — these APIs
  have shifted across crate versions before.
• First task for whoever picks this up on a real Windows box:
  cargo check in src-tauri/, fix whatever the compiler flags, add
  the integration test described in DEVELOPMENT.md under
  #[cfg(windows)].

None of this affects the frontend, the audit/event plumbing, or the
non-Windows build path (#[cfg(not(windows))] correctly returns
AppError::not_supported everywhere).

Remaining in Phase 2

• commands::network — adapter enumeration (Wi-Fi/Ethernet/VPN,
  IPv4/IPv6/gateway/DNS/DHCP/MAC/link speed). Section 9 of the
  original spec; not started.
• commands::services — SCM enumeration + start/stop/restart/startup
  type change, with protected-service confirmation. Not started.
• network_snapshots and services tables already exist in the DB
  schema (Phase 1) and are unused until this lands.

Handoff to whoever continues Phase 2

Follow the exact same shape as ports.rs: cross-platform command
function → #[cfg(windows)] mod windows_impl doing the real work →
#[cfg(not(windows))] fallback returning AppError::not_supported.
Reuse record_audit / record_event from commands::audit /
commands::events for every mutating action.

VoidGuard - v0.1.0

v0.1.0 — Foundation & Core Monitoring -- VoidGuard

This release introduces the initial foundation of the Windows security and system monitoring platform.

Version 0.1.0 focuses exclusively on Phase 1 of the project: establishing the application architecture, desktop interface, core system monitoring, local data storage, and event infrastructure.

Included in This Release

Application Foundation

• Initial Tauri desktop application
• React and TypeScript frontend
• Rust backend
• Modular project architecture
• Frontend-to-backend IPC foundation
• Initial application configuration system

Dashboard

• Initial security dashboard
• Real-time CPU monitoring
• RAM usage monitoring
• Disk usage monitoring
• Basic system health indicators
• Network connection status
• Initial security status components

Event Infrastructure

• Centralized event model
• Event categories and severity levels
• Event normalization layer
• Initial event storage
• Foundation for future real-time security monitoring

Local Database

• SQLite integration
• Initial database schema
• Database initialization
• Migration infrastructure
• Repository layer

User Interface

• Modern desktop UI
• Sidebar navigation
• Dashboard layout
• Dark and light theme foundation
• Responsive components
• Loading and empty states
• Initial settings structure

Current Scope

This release is intentionally limited to the Phase 1 foundation.

The following major features are not yet part of v0.1.0:

• Process management
• Open-port monitoring
• Firewall management
• DNS management
• Windows service management
• File integrity monitoring
• Startup/persistence monitoring
• Advanced security scanning
• Risk correlation engine
• Advanced security scoring
• Full audit system

These features are planned for subsequent releases.

Stability

v0.1.0 should be considered an early development release.

The architecture and APIs may change in future versions as additional monitoring and security modules are introduced.

Roadmap

Upcoming development will focus on:

• Process monitoring
• Network interface monitoring
• Open-port detection
• Windows service monitoring
• File system monitoring
• Startup and persistence monitoring
• Security event correlation
• Risk scoring
• Firewall and DNS management
• Advanced auditing and security analysis

Feedback

Bug reports, feature requests, architectural suggestions, and security-related feedback are welcome through the project's GitHub issue tracker.

---

This release establishes the foundation for the broader Windows security and system monitoring platform.