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

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, 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) 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 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 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 demonstrates this structure, defining safe patterns at lines 101-123 and destructive patterns at lines 124-198.

// 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

{
  "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 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. 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.

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 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.

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, while the powershell sub-pack in src/packs/windows/powershell.rs handles cmdlets like Remove-Item, Clear-Content, and Stop-Process.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}