# How dcg Handles Windows-Specific Destructive Commands: Architecture and Implementation

> Learn how dcg handles destructive Windows commands using regex, Aho-Corasick matching, and contextual suggestions to block dangerous cmd.exe and PowerShell operations before execution.

- Repository: [Jeff Emanuel/destructive_command_guard](https://github.com/Dicklesworthstone/destructive_command_guard)
- Tags: architecture
- Published: 2026-07-16

---

**dcg (Destructive Command Guard) intercepts catastrophic Windows operations through a dedicated Windows pack that combines case-insensitive regex patterns, Aho-Corasick keyword matching, and contextual remediation suggestions to block destructive cmd.exe and PowerShell commands before execution.**

The open-source Destructive Command Guard repository provides cross-platform protection against dangerous shell operations. For Windows environments, dcg implements a specialized security layer that targets native Windows shells, applying platform-specific detection logic while maintaining the high-performance characteristics required for interactive command-line usage.

## Windows Pack Architecture and Platform Detection

The Windows-specific protection logic resides in [`src/packs/windows/mod.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/mod.rs), which orchestrates four specialized sub-packs: **filesystem**, **system**, **powershell**, and **misc**. According to the Dicklesworthstone/destructive_command_guard source code, these modules are always compiled into the binary but activate by default only on Windows targets using the `cfg(windows)` attribute at lines 31-35.

This architecture enables Unix systems to avoid Windows-specific matching overhead during normal operation while allowing CI/CD pipelines running on Linux to scan Windows script files (`.ps1`, `.cmd`) for destructive patterns. The platform-aware registration ensures zero-cost abstraction for non-Windows hosts without sacrificing cross-platform analysis capabilities.

### Case-Insensitive Matching Strategy

Windows command interpreters treat input as case-insensitive, requiring dcg to apply the `(?i)` inline regex flag to all Windows patterns as an authoritative gate. However, the **quick-reject keyword matcher** uses case-sensitive Aho-Corasick matching for performance optimization.

To bridge this semantic gap, the `windows_keyword_casings` helper function (lines 9-23 of [`src/packs/windows/mod.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/mod.rs)) generates realistic casing variations for each command:
- **cmd.exe verbs**: lowercase and UPPERCASE variants (e.g., `del`, `DEL`, `format`, `FORMAT`)
- **PowerShell cmdlets**: PascalCase and lowercase variants (e.g., `Remove-Item`, `remove-item`)

This dual-strategy approach ensures that `DEL /S`, `Del /s`, and `del /S` all trigger the filesystem pack's deep inspection while preserving the zero-allocation hot path for safe commands that contain no matching keywords.

## The Two-Stage Evaluation Pipeline

The evaluation process follows a high-performance pipeline defined in [`src/evaluator.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/evaluator.rs) that minimizes latency for approved commands while maximizing detection accuracy for destructive Windows operations.

### Stage 1: Keyword Quick-Reject with Aho-Corasick

Before evaluating expensive regex patterns, dcg scans the command string using an **Aho-Corasick automaton** against pack-specific keywords. If the quick-reject scanner finds no keyword matches, the engine skips all regex patterns for that pack entirely, preserving zero-allocation performance for safe commands.

Each Windows sub-pack defines its keyword set in dedicated source files. For example, [`src/packs/windows/filesystem.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/filesystem.rs) registers keywords such as `del`, `erase`, `rd`, `Remove-Item`, and `format` to trigger deeper inspection only when potentially relevant commands appear.

### Stage 2: Pattern Classification and Remediation

When keywords match, dcg evaluates the command string against two pattern categories defined via declarative macros:

**Safe patterns** (`safe_pattern!` macro): Whitelist entries that indicate preview-only or safe execution. For example, PowerShell commands containing the `-WhatIf` flag classify as safe regardless of destructive keywords present.

**Destructive patterns** (`destructive_pattern!` macro): Dangerous operations that trigger denial responses. Each pattern includes:
- A stable **rule ID** (e.g., `windows.filesystem:del-recursive`)
- **Severity level** (Critical, High, Medium)
- Human-readable description
- **Remediation suggestions** via `PatternSuggestion` structs

The filesystem pack implementation at lines 56-198 of [`src/packs/windows/filesystem.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/filesystem.rs) demonstrates this structure, defining safe patterns at lines 101-123 and destructive patterns at lines 124-198.

```rust
// Conceptual representation of pattern definitions in filesystem.rs
destructive_pattern!(
    id: "windows.filesystem:del-recursive",
    regex: r"(?i)\b(?:del|erase)(?:\.exe)?\s+(?:[^|&\r\n]*\s+)?/s\b",
    severity: Critical,
    description: "Recursive deletion without confirmation",
    remediation: [
        "Add /p to confirm each file deletion",
        "Use specific file paths instead of wildcards",
        "Test with echo first to verify file selection"
    ]
);

```

## Windows Filesystem Protection in Practice

When processing a destructive Windows command such as `del /s /q C:\temp\*`, dcg executes the following detection sequence according to the source code:

1. The **Aho-Corasick matcher** identifies the `del` keyword in the command string
2. The case-insensitive regex `(?i)\b(?:del|erase)(?:\.exe)?\s+(?:[^|&\r\n]*\s+)?/s\b` matches the recursive deletion flag `/s`
3. The classifier assigns severity `Critical` and rule ID `windows.filesystem:del-recursive`
4. The system emits a JSON denial containing remediation suggestions

```json
{
  "denied": true,
  "ruleId": "windows.filesystem:del-recursive",
  "severity": "Critical",
  "description": "Recursive deletion without confirmation",
  "remediation": {
    "safeAlternative": [
      "Add /p to confirm each file",
      "Scope the path precisely before deleting",
      "Use 'del /?' to review safe usage options"
    ]
  }
}

```

PowerShell commands receive equivalent protection. The pattern `(?i)Remove-Item\s+.*-Recurse.*-Force` catches recursive forced deletions while the safe pattern matcher allows `-WhatIf` variants to execute without blocking.

## Integration with Core Components

The [`src/config.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/config.rs) module loads Windows pack configurations and determines enablement based on the host OS. Enabled packs feed into the evaluator pipeline that processes all incoming commands through the quick-reject and regex matching stages.

Users inspect Windows-specific detection logic through the CLI interface defined in [`src/cli.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/cli.rs). The `dcg explain "<command>"` subcommand displays exactly why a Windows command triggered a block and presents available remediation alternatives, parsing the `PatternSuggestion` structures into human-readable guidance.

## Summary

- **Platform-aware compilation**: Windows packs use `cfg(windows)` for default enablement while remaining compiled for all targets to support cross-platform script scanning
- **Case-insensitive detection**: Regex patterns employ `(?i)` flags while the keyword matcher uses multi-casing strategies via `windows_keyword_casings` to handle Windows shell semantics
- **Two-stage performance**: Aho-Corasick quick-reject followed by detailed regex classification ensures sub-millisecond evaluation for safe commands
- **Comprehensive coverage**: Four specialized sub-packs (filesystem, powershell, system, misc) protect against `del /s`, `format X:`, `Stop-Process -Force`, and registry modifications
- **Actionable remediation**: Every destructive match includes specific `PatternSuggestion` alternatives such as adding `/p` confirmation flags or using `-WhatIf` previews

## Frequently Asked Questions

### Does dcg work on Linux for scanning Windows scripts?

Yes. While Windows packs enable by default only on Windows via `cfg(windows)`, the code remains compiled for all targets. This allows Linux CI pipelines to scan `.ps1` and `.cmd` files for destructive patterns without executing them on Windows hosts, as implemented in [`src/config.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/config.rs).

### How does dcg handle the case-insensitivity of Windows commands?

dcg applies the `(?i)` inline regex flag to all Windows patterns for authoritative case-insensitive matching. The quick-reject keyword matcher uses case-sensitive Aho-Corasick matching for speed, compensated by generating realistic casing variations through the `windows_keyword_casings` helper function in [`src/packs/windows/mod.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/mod.rs) lines 9-23.

### What remediation suggestions does dcg provide for blocked Windows commands?

Each destructive pattern includes a `PatternSuggestion` list offering safer alternatives. For `del /s`, dcg suggests adding `/p` to confirm each file. For PowerShell's `Remove-Item`, it recommends using `-WhatIf` first. These suggestions appear in the JSON denial output under the `remediation.safeAlternative` field according to the schema in [`src/packs/windows/filesystem.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/filesystem.rs).

### Which Windows shells does dcg protect?

The Windows pack protects both `cmd.exe` and PowerShell environments. The filesystem pack covers `cmd.exe` verbs like `del`, `erase`, `rd`, and `format` defined in [`src/packs/windows/filesystem.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/filesystem.rs), while the powershell sub-pack in [`src/packs/windows/powershell.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/windows/powershell.rs) handles cmdlets like `Remove-Item`, `Clear-Content`, and `Stop-Process`.