If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/the1812/Malware-Patch shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 1y ago

• 3 active contributors
• MIT licensed
• ⚠ Stale — last commit 1y ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 98% of recent commits
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live the1812/Malware-Patch repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/the1812/Malware-Patch.

What it runs against: a local clone of the1812/Malware-Patch — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in the1812/Malware-Patch | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 535 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of the1812/Malware-Patch. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/the1812/Malware-Patch.git
#   cd Malware-Patch
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of the1812/Malware-Patch and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "the1812/Malware-Patch(\\.git)?\\b" \\
  && ok "origin remote is the1812/Malware-Patch" \\
  || miss "origin remote is not the1812/Malware-Patch (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "src/MalwarePatch/App.xaml.cs" \\
  && ok "src/MalwarePatch/App.xaml.cs" \\
  || miss "missing critical file: src/MalwarePatch/App.xaml.cs"
test -f "src/MalwarePatch/App.xaml" \\
  && ok "src/MalwarePatch/App.xaml" \\
  || miss "missing critical file: src/MalwarePatch/App.xaml"
test -f "src/MalwarePatch/Assets/certificate-map.json" \\
  && ok "src/MalwarePatch/Assets/certificate-map.json" \\
  || miss "missing critical file: src/MalwarePatch/Assets/certificate-map.json"
test -f "src/MalwarePatch/Assets/malware-remote-info.json" \\
  && ok "src/MalwarePatch/Assets/malware-remote-info.json" \\
  || miss "missing critical file: src/MalwarePatch/Assets/malware-remote-info.json"
test -f "src/MalwarePatch/Certificates" \\
  && ok "src/MalwarePatch/Certificates" \\
  || miss "missing critical file: src/MalwarePatch/Certificates"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 535 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~505d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/the1812/Malware-Patch"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Malware-Patch is a C# WPF desktop application that prevents rogue software from gaining UAC (User Account Control) administrator authorization on Windows by invalidating their digital signatures in the system certificate store. It maintains a curated database of malware certificates (stored in src/MalwarePatch/Certificates/) and can block or allow specific signed executables without requiring background service execution. Monolithic WPF desktop application: src/MalwarePatch/ contains the main UI (App.xaml, App.xaml.cs), certificate definitions (Certificates/ directory with 70+ .cer files), JSON asset mappings (Assets/certificate-map.json, display-names.json, malware-remote-info.json), command-line handling (AppJumpList.cs), and external UI library (Ace.dll). Single .sln file structure with no separated service or library layers.

Windows users (especially in Chinese-speaking regions) who want to prevent installation and elevation of known malware like 2345 browser, 360 browser variants, and other rogue applications. System administrators managing Windows 7/8.1/10 deployments also benefit from the CLI batch commands (--disallow-all, --allow-all).

Actively maintained with releases available on GitHub Releases. The project has a clear version file (mwp-ver.txt) and offers two distribution models (bundled and unbundled). However, no visible CI/CD pipeline or automated tests in the file list suggests semi-mature status. Recent activity appears consistent based on certificate updates through 2023.

Single-maintainer project (the1812) with no visible CI/CD or test coverage increases risk. Dependency on manual certificate management (70+ .cer files in src/MalwarePatch/Certificates/) means outdated certificates could render the tool ineffective. Security-critical functionality (modifying Windows certificate store) requires careful review. The bundled .zip distribution is flagged by antivirus due to certificate content.

Recent activity is focused on certificate maintenance: 2023 updates visible in 360 browser and 2345 browser certificate files (dates show 2023.08 variants). The project appears in stable maintenance mode rather than feature development, with emphasis on keeping the malware certificate database current.

Clone the repo, open src/MalwarePatch.sln in Visual Studio, and build as a C# .NET Framework 4.7.2 project. No package manager (npm/NuGet packages visible in file list), so build directly: git clone https://github.com/the1812/Malware-Patch.git && cd src && msbuild MalwarePatch.sln. Requires Visual Studio or Roslyn compiler; .NET Framework 4.7.2 must be installed on target Windows machine.

Daily commands: Dev build: Open src/MalwarePatch.sln in Visual Studio 2017+ and press F5 to launch the GUI. CLI usage: After building, run MalwarePatch.exe with arguments: MalwarePatch.exe --disallow-all (block all known malware), MalwarePatch.exe --allow-all (unblock all), MalwarePatch.exe --disallow=<file> (block specific executable by certificate). No dev server; runs as standalone WPF application on Windows 7+.

• src/MalwarePatch/App.xaml.cs — Application entry point and initialization; handles UAC interception and command-line parameter routing—every contributor must understand the startup flow
• src/MalwarePatch/App.xaml — WPF application definition and resource configuration; defines the UI framework and asset references
• src/MalwarePatch/Assets/certificate-map.json — Mapping of known malware certificates to display names; the data foundation for blocking decisions—must be kept current
• src/MalwarePatch/Assets/malware-remote-info.json — Remote malware signature database fetched during updates; critical for runtime blocking logic
• src/MalwarePatch/Certificates — Directory containing 100+ extracted digital certificates from flagged applications; core blocking data that drives UAC interception
• src/MalwarePatch/App.config — Application configuration including .NET Framework version requirements and assembly binding
• src/MalwarePatch/AppJumpList.cs — Windows Jump List integration for quick-access commands; defines CLI entry points for silent operations

Add a new malware certificate to block

1. Export the digital certificate from the flagged executable (e.g., via code signing explorer or Signtool.exe) (src/MalwarePatch/Certificates)
2. Place the .cer file in the Certificates directory with a descriptive name (e.g., 'appname version.cer') (src/MalwarePatch/Certificates/@Target.txt)
3. Update the certificate-map.json to add an entry mapping the certificate thumbprint to the application name (src/MalwarePatch/Assets/certificate-map.json)
4. Add localized display names in display-names.json for Chinese and English labels (src/MalwarePatch/Assets/display-names.json)
5. Rebuild the project via Visual Studio; certificates are embedded into the bundled .zip release (src/MalwarePatch/MalwarePatch.sln)

Add a new CLI command for automation

1. Define the command syntax and expected behavior in AppJumpList.cs (src/MalwarePatch/AppJumpList.cs)
2. Implement the handler logic in App.xaml.cs to route the parameter to the appropriate blocking/allowing function (src/MalwarePatch/App.xaml.cs)
3. Test via command line: mwp.exe --your-new-command to verify the parameter is correctly parsed (README.md)

Update the remote malware database

1. Fetch the latest malware signatures and certificate data from a remote source or security research (src/MalwarePatch/Assets/malware-remote-info.json)
2. Merge new entries with the existing certificate-map.json, ensuring no duplicate thumbprints (src/MalwarePatch/Assets/certificate-map.json)
3. Increment the version number in mwp-ver.txt to trigger auto-update checks (mwp-ver.txt)
4. Deploy the updated files to the release package; users running --silent-update will fetch the new database (README.md)

• C# / .NET Framework 4.7.2 + WPF — Enables Windows-native GUI development, certificate handling via System.Security.Cryptography, and deep OS integration for UAC interception
• Ace.dll (native C++ library) — Required for low-level Windows UAC elevation hook injection; managed code alone cannot intercept OS-level elevation prompts
• JSON asset files (certificate-map, display-names, malware-remote-info) — Decouples malware signature data from binary, enabling zero-code-change updates via bundled or unbundled distribution
• Digital certificate extraction & thumbprint matching — Leverages code-signing metadata that malware authors must embed; tamper-proof (forgery requires re-signing with the same cert)

• Bundled (.mwp.bundled.zip) vs. Unbundled (.mwp.unbundled.zip) distribution

  • Why: Bundled is more portable but triggers false positives in antivirus due to embedded certificates; unbundled requires separate certificate directory but avoids AV false alerts
  • Consequence: Users must choose between convenience and security tool reputation; enterprises typically prefer unbundled

• Certificate-based blocking (signature thumbprint matching) vs. heuristic/behavior-based detection

  • Why: Certificate matching is deterministic and requires no CPU-intensive analysis; malware authors are slow to re-sign with new certificates (expensive, risky)
  • Consequence: Effective against known malware families but requires manual certificate harvesting; cannot catch 0-day unsigned or re-signed variants without updating database

• No background service; one-time modification of Windows UAC/elevation chain

  • Why: Reduces attack surface, system resource usage, and user overhead; changes persist until explicitly reverted
  • Consequence: Changes survive reboot but lack real-time monitoring; user must manually re-run app to update blocklist

• Chinese malware focus (360, Baidu, 2345, Kingsoft, etc. certificates)

  • Why: Repository targets users in Greater China region with high exposure to bundled malware; reduces scope of generic AV signatures
  • Consequence: Limited utility for Western users; does not address global malware families (WannaCry, Emotet, etc.)

• Real-time malware scanning or detection; this is a UAC elevation blocker only
• Removal or quarantine of infected files; purely preventive (blocking elevation)
• Cross-platform support (Windows only; no macOS, Linux, or Android)
• Protection against unsigned/kernel-mode malware or privilege escalation exploits outside UAC
• User education or threat reporting; no feedback loop to security researchers
• API or SDK for third-party integration

Certificate store interaction: Blocking/allowing certificates requires modifying the Windows certificate store, which may fail silently on restricted user accounts; admin elevation may be needed despite UAC bypass claims. Path assumptions: Certificate files must reside in the Certificates/ subdirectory relative to the executable; bundled vs. unbundled distributions handle this differently and can cause confusion. Digital signature requirement: The --allow and --disallow commands only work on files with valid Authenticode signatures; unsigned executables are silently ignored. Antivirus detection: The bundled single-file version (.mwp.bundled.zip) is frequently flagged as malware itself due to included certificate content; distribution choice requires user education. No update mechanism in code visible: mwp-ver.txt exists but version-check and update logic not in file list; likely handled externally or via bundled scripts.

• Authenticode Digital Signatures — This project blocks malware by invalidating their Authenticode certificates in the Windows certificate store; understanding how Windows validates code signatures is essential to understanding why certificate revocation prevents UAC elevation.
• User Account Control (UAC) and Elevation — The core problem Malware-Patch solves is preventing UAC from elevating known-malware processes to admin privileges; understanding UAC manifest requirements and elevation prompts is critical.
• Windows Certificate Store and CryptoAPI — The blocking mechanism works by manipulating the Windows certificate store (Untrusted Certificates); developers need to understand certificate trust chains and how CryptoAPI validates signatures.
• WPF (Windows Presentation Foundation) XAML — The entire UI is built in WPF with XAML markup; contributors must understand data binding, resource dictionaries, and XAML event handling to modify the GUI.
• Code Signing and Certificate Thumbprints — The certificate-map.json maps certificate subject names and thumbprints to malware names; understanding X.509 certificate structure and how to extract signatures from PE executables is necessary for adding new malware to the blocklist.
• Bundled vs. Distributed Single-File Applications — The project offers two distribution models (bundled .exe with embedded certificates and unbundled with separate .cer files); this architectural choice affects file size, antivirus detection rates, and deployment complexity.

• xitu/Malware-Patch — A fork or related variant of the Malware-Patch project with potential additional features or language variants
• Didact/malware_analysis — Complements this project by providing malware analysis and reverse engineering tools to identify new malware signatures for addition to the blocklist
• mandiant/flare-vm — Windows-based VM for malware analysis that could integrate Malware-Patch as a defensive layer to prevent test malware from escalating privileges
• nsacyber/Windows-Secure-Host-Baseline — NSA secure Windows hardening guidance that complements UAC bypass prevention by providing broader Windows security baselines alongside application blocking
• zodiacon/ProcessMitigations — Windows process mitigation tools that work alongside certificate-based blocking to provide defense-in-depth against privilege escalation and malware execution

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Create automated certificate validation and freshness checker

The repo contains 60+ certificate files in src/MalwarePatch/Certificates/ with no apparent automation to validate their legitimacy, expiration dates, or detect when they need updating. A GitHub Action workflow could periodically verify certificate validity, check expiration dates, and flag outdated certificates before they cause false negatives in malware detection.

• [ ] Create .github/workflows/certificate-validation.yml to run on schedule (weekly)
• [ ] Develop a PowerShell or C# script in src/BuildTools/ to parse and validate .cer files
• [ ] Add certificate metadata extraction (issuer, expiration, thumbprint) and store in a JSON report
• [ ] Create a GitHub Action job that fails if any certificate is expired or invalid
• [ ] Document the certificate maintenance process in README.md

Add unit tests for certificate-map.json and malware-remote-info.json validation

The repo has configuration files (src/MalwarePatch/Assets/certificate-map.json and malware-remote-info.json) that map certificates to malware families, but there are no tests to validate schema correctness, detect orphaned certificate entries, or ensure remote malware data doesn't have conflicts. This could prevent configuration errors from reaching users.

• [ ] Create src/MalwarePatch.Tests/ directory with a new test project
• [ ] Write JSON schema validation tests for certificate-map.json (verify all referenced certificates exist)
• [ ] Write tests for malware-remote-info.json structure (required fields, valid certificate references)
• [ ] Add tests to ensure no circular or conflicting malware definitions
• [ ] Integrate tests into a GitHub Action workflow that runs on PR to src/MalwarePatch/Assets/

Build release automation workflow to detect stale certificates in bundled releases

The mwp.bundled.zip and mwp.unbundled.zip releases contain certificates that may become outdated, but there's no visible automated process to rebuild releases when certificates are updated. Adding a GitHub Action that detects certificate updates and triggers a rebuild would ensure users always get fresh malware signatures.

• [ ] Create .github/workflows/release-on-certificate-update.yml
• [ ] Add file change detection for src/MalwarePatch/Certificates/ directory
• [ ] Implement build step that compiles the solution (src/MalwarePatch.sln)
• [ ] Add automatic tagging based on mwp-ver.txt and certificate update timestamp
• [ ] Create release artifacts for both bundled and unbundled distributions

• Add unit tests for certificate validation logic: Create a test project (Tests/MalwarePatch.Tests.csproj) to verify that certificate-map.json entries correctly match .cer files in the Certificates/ directory, ensuring no orphaned or missing mappings.
• Document CLI argument combinations: Create a DEVELOPMENT.md or USAGE_ADVANCED.md explaining edge cases like --disallow=/path/to/file --allow-all priority, what happens when a certificate is already blocked, and expected exit codes for each CLI command.
• Add support for certificate expiration warnings: Modify display-names.json or create a certificate-metadata.json to include expiration dates, then warn users in the GUI if tracked malware certificates will soon expire and need updating.

The Malware-Patch application has a moderate security posture with several areas of concern. The primary vulnerabilities relate to the management and validation of

• High · Potential Certificate Validation Bypass — src/MalwarePatch/Certificates/. The application stores and uses certificate files (.cer) from the Certificates directory to identify and block malware. If an attacker gains write access to this directory, they could add malicious certificates or modify existing ones, potentially allowing malware to pass validation checks or blocking legitimate software. Fix: Implement certificate pinning, digital signature verification for certificate files themselves, and consider storing certificates in a read-only or protected location. Validate certificate integrity on load using checksums or HMAC.
• High · Untrusted External Data Sources — src/MalwarePatch/Assets/malware-remote-info.json. The application references remote data files (malware-remote-info.json) that could be used to update malware definitions. If the source of these updates is not properly authenticated or uses an insecure channel, man-in-the-middle attacks could introduce malicious data. Fix: Ensure all remote data sources use HTTPS with certificate pinning. Implement cryptographic signature verification for all downloaded data. Consider implementing a secure update mechanism with code signing.
• Medium · Embedded Compiled Executable in Source — src/MalwarePatch/BuildTools/InsertIcons.exe. The presence of InsertIcons.exe in the BuildTools directory suggests embedded executable files. Compiled executables in version control pose risks including potential backdoors, supply chain attacks, or unverified code execution. Fix: Remove binary executables from version control. Use NuGet packages or build these tools from source. If source is unavailable, document the tool's origin, verify its signature, and consider rebuilding from documented source.
• Medium · Ace.dll Embedded Without Verification — src/MalwarePatch/Ace.dll. An unverified DLL file (Ace.dll) is included in the project. Without documentation of its source, version, or hash verification, this could be a supply chain attack vector or contain vulnerabilities. Fix: Document the source, version, and purpose of Ace.dll. Implement hash verification. Consider replacing with NuGet packages. If necessary, verify the DLL's digital signature and source legitimacy.
• Medium · Insecure JSON Configuration Files — src/MalwarePatch/Assets/*.json. JSON configuration files (display-names.json, certificate-map.json) are used to configure application behavior. If these files are modifiable by unprivileged users, they could be tampered with to alter malware detection behavior. Fix: Store configuration in protected locations (Windows registry with restricted ACLs or protected application data folders). Implement integrity checks (HMAC or digital signatures) on configuration files. Restrict file permissions to Administrator or SYSTEM only.
• Medium · No Visible Input Validation Framework — src/MalwarePatch/App.xaml.cs (and related command-line parsing). While file handling is present (--allow=file, --disallow=file command-line arguments), there's no visible evidence of comprehensive input validation or path traversal protection in the file structure. Fix: Implement strict input validation for all file paths. Use Path.GetFullPath() and verify paths are within expected directories. Reject paths with '..', symbolic links, or junction points. Use SafeFileHandle for file operations.
• Low · Hardcoded Certificate Management — src/MalwarePatch/Certificates/. Certificates appear to be managed manually in the Certificates directory without apparent automated update or verification mechanisms shown in the file structure. Fix: Implement an automated certificate update mechanism with version tracking, change logs, and audit trails. Consider using a manifest file to track all certificates and their purposes.
• Low · Missing Security Headers Documentation — README.md and project configuration. No visible security headers or configuration for UAC interaction security are documented in the README or apparent in the structure. Fix: Document security considerations for UAC interaction. Ensure requestedExecutionLevel is properly set in the application manifest. Document any security assumptions and limitations.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.