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/trickster0/OffensiveRust 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.

AVOID — Stale and unlicensed — last commit 2y ago

• 12 active contributors
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 62% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows 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 trickster0/OffensiveRust repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/trickster0/OffensiveRust.

What it runs against: a local clone of trickster0/OffensiveRust — 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 trickster0/OffensiveRust | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 773 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of trickster0/OffensiveRust. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/trickster0/OffensiveRust.git
#   cd OffensiveRust
#
# 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 trickster0/OffensiveRust and re-run."
  exit 2
fi

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

# 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 "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "Allocate_With_Syscalls/src/main.rs" \\
  && ok "Allocate_With_Syscalls/src/main.rs" \\
  || miss "missing critical file: Allocate_With_Syscalls/src/main.rs"
test -f "Process_Injection_CreateRemoteThread/src/main.rs" \\
  && ok "Process_Injection_CreateRemoteThread/src/main.rs" \\
  || miss "missing critical file: Process_Injection_CreateRemoteThread/src/main.rs"
test -f "amsi_bypass/src/main.rs" \\
  && ok "amsi_bypass/src/main.rs" \\
  || miss "missing critical file: amsi_bypass/src/main.rs"
test -f "Unhooking/src/main.rs" \\
  && ok "Unhooking/src/main.rs" \\
  || miss "missing critical file: Unhooking/src/main.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 773 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~743d)"
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/trickster0/OffensiveRust"
  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).

OffensiveRust is a collection of weaponized Rust code samples for red team implant development and post-exploitation operations on Windows systems. It demonstrates techniques like process injection via CreateRemoteThread, syscall-based memory allocation, AES/RC4 payload encryption, PEB walking, kernel driver exploitation, and named pipe communication — all compiled to small, LLVM-based binaries designed to evade static AV signatures. Flat monorepo: each subdirectory (Allocate_With_Syscalls/, Create_DLL/, Process_Injection_CreateRemoteThread/, etc.) is a standalone Cargo project with its own src/main.rs or src/lib.rs, Cargo.toml, and optional lock file. Shared patterns: ntapi bindings for low-level syscalls, winapi crate for high-level Win32 APIs, and payload encryption via aes or rc4 crates. Litcrypt_String_Encryption/ includes a dedicated example for compile-time string obfuscation.

Red team operators and penetration testers who need production-grade offensive tooling written in Rust; security researchers experimenting with evasion techniques and implant architecture; and defensive security engineers studying red team methodologies to improve detection.

Experimental / actively developed. The repo contains 11MB+ of Rust code across 20+ standalone projects, but shows no CI/CD pipelines, no unit tests, and no versioning strategy visible. It appears to be a personal research project documenting working exploits rather than a hardened, battle-tested framework. Last commit data unavailable, but the breadth of examples (PEB_Walk, Kernel_Driver_Exploit, Injection_AES_Loader) suggests ongoing exploration.

High risk for production use. Dependencies like ntapi and device-io are thin wrappers around Windows internals with minimal maintenance; the codebase has zero visible test coverage for critical injection/syscall code; no security audit trail or code review process evident. Heavy reliance on unsafe Rust blocks for interop with Win32 APIs means memory safety guarantees are forfeit — a logic error in Allocate_With_Syscalls or Process_Injection_CreateRemoteThread could crash the host or expose the implant. Single-maintainer (@trickster0) with no organizational backing.

No recent activity data visible in the file list. The presence of both Injection_AES_Loader and Injection_Rc4_Loader suggests iterative refinement of encryption schemes; Kernel_Driver_Exploit and DeviceIoControl indicate exploration of privileged execution paths. The .gitmodules file hints at external dependencies, but no PR or issue tracking data is provided.

git clone https://github.com/trickster0/OffensiveRust.git
cd OffensiveRust
cd Allocate_With_Syscalls  # or any subdirectory
cargo build --release
./target/release/Allocate_With_Syscalls.exe

Daily commands: Each project is independent. From any subdirectory: cargo build --release produces a standalone .exe in target/release/. For DLL output (Create_DLL), cargo build --release --lib produces a .dll. No central build system or Makefile.

• README.md — Defines the project vision, rationale for Rust in red team operations, and navigation guide for all 40+ offensive techniques covered.
• Allocate_With_Syscalls/src/main.rs — Demonstrates low-level memory allocation via syscalls—foundational technique for avoiding user-land API hooks in AV/EDR evasion.
• Process_Injection_CreateRemoteThread/src/main.rs — Core process injection pattern used across multiple variants; critical for understanding the project's primary offensive primitive.
• amsi_bypass/src/main.rs — AMSI patching technique; essential reference for Windows Defender evasion, a common defensive bypass requirement.
• Unhooking/src/main.rs — EDR unhooking logic; shows how to detect and restore hooked APIs, enabling execution past endpoint protection.
• PEB_Walk/src/main.rs — Process Environment Block traversal for module enumeration without calling public APIs; demonstrates anti-analysis techniques.
• UUID_Shellcode_Execution/src/main.rs — Unconventional shellcode execution via UUIDs; illustrates creative obfuscation and execution channels.

Add a New Shellcode Injection Technique

1. Create a new directory under the project root (e.g., Process_Injection_MyTechnique/) (Process_Injection_MyTechnique/Cargo.toml)
2. Define a Cargo.toml following the pattern in Process_Injection_CreateRemoteThread/Cargo.toml with appropriate Windows API dependencies (winapi, ntapi) (Process_Injection_MyTechnique/Cargo.toml)
3. Implement the injection primitive in src/main.rs, referencing Process_Injection_CreateRemoteThread/src/main.rs for API call patterns (Process_Injection_MyTechnique/src/main.rs)
4. Add an entry to the README.md table of contents with a brief description of the evasion technique (README.md)

Add a New Defense Evasion Module

1. Create a new directory (e.g., etw_bypass/) following the naming convention of amsi_bypass/ or Unhooking/ (etw_bypass/Cargo.toml)
2. Import and configure ntapi or winapi in Cargo.toml as demonstrated in amsi_bypass/Cargo.toml (etw_bypass/Cargo.toml)
3. Implement the bypass logic in src/main.rs, studying amsi_bypass/src/main.rs and Unhooking/src/main.rs for hooking/patching patterns (etw_bypass/src/main.rs)
4. Document the technique in README.md under the defense evasion section (README.md)

Add a New Encrypted Shellcode Loader

1. Create a new directory (e.g., Injection_ChaCha20_Loader/) mirroring Injection_AES_Loader/ or Injection_Rc4_Loader/ (Injection_ChaCha20_Loader/Cargo.toml)
2. Add cryptographic dependencies (e.g., chacha20, generic-array) to Cargo.toml (Injection_ChaCha20_Loader/Cargo.toml)
3. Implement cipher setup and shellcode decryption in src/main.rs, following the allocation and process injection pattern from Injection_AES_Loader/src/main.rs (Injection_ChaCha20_Loader/src/main.rs)
4. Integrate the new loader example into the README.md examples section (README.md)

Add a New C2 Communication Channel

1. Create a new directory (e.g., dns_exfiltration/) for the new channel type (dns_exfiltration/Cargo.toml)
2. Add protocol-specific dependencies to Cargo.toml (e.g., trust-dns-resolver for DNS queries) (dns_exfiltration/Cargo.toml)
3. Implement the channel logic in src/main.rs, following the server/client pattern from Named_Pipe_Server/src/main.rs and Named_Pipe_Client/src/main.rs (dns_exfiltration/src/main.rs)
4. Document the channel characteristics in README.md under the communication/persistence section (README.md)

• Rust — Memory safety, performance, low-level access via FFI, and strong type system reduce exploit chain bugs while maintaining fine-grained Windows API control.
• Windows ntapi / winapi crates — Enable direct access to undocumented NT kernel APIs and raw syscalls without relying on Microsoft's documented kernel32.dll interfaces, allowing evasion of API hooking.
• Inline assembly (asm!) — Permits direct syscall invocation and assembly-level manipulation to bypass userland hook detection engines.
• Cryptographic crates (AES, RC4) — Encrypt shellcode payloads to evade signature-based detection by AV/EDR and obfuscate indicators of compromise.
• Cargo — undefined

Rust edition 2018 is older; future upgrades to 2021 may require dependency bumps. ntapi version 0.3.6 is pinned—never versions may have breaking changes. Create_DLL generates non-standard Rust DLLs with no explicit entry point, risking loader compatibility issues. Syscall stubs in Allocate_With_Syscalls are hand-crafted and may break between Windows versions (10/11/Server 2022). No environment variables or external services required, but mingw-w64 toolchain required for cross-compilation from *nix. OPSEC: all compiled binaries retain debug symbols by default—use strip post-build or enable LTO in Cargo.toml [profile.release].

• Process Injection via CreateRemoteThread — Core technique for implant delivery into target processes; every red team implant relies on this; OffensiveRust demonstrates both the syscall and Win32 API variants
• Syscall Direct Invocation (Syscall Stubs) — Bypasses Win32 API hooks installed by security tools; OffensiveRust's Allocate_With_Syscalls avoids user-mode EDR interception by calling NTDLL directly
• Process Environment Block (PEB) Walking — Fileless enumeration of loaded DLLs and function exports without API calls; PEB_Walk implements this to locate NTDLL and KERNEL32 addresses at runtime
• Payload Encryption (AES-256, RC4) — Defeats static signature detection of embedded shellcode; Injection_AES_Loader and Injection_Rc4_Loader encrypt payloads in transit and decrypt in memory
• Named Pipes (IPC) — Inter-process communication between implant and C2 or between implant stages; OffensiveRust includes both client and server examples for bidirectional comms
• LLVM-Based Evasion — Rust's LLVM backend produces unique binary patterns vs. C/C++ compiled with MSVC, helping bypass signature-based AV detection
• Compile-Time String Obfuscation (litcrypt) — Hides hardcoded strings (API names, C2 addresses) from static analysis and yara rules; Litcrypt_String_Encryption demonstrates this technique

• Rust-Shellcode/Shellcode — Generates raw shellcode payloads in Rust for injection into remote processes, directly compatible with OffensiveRust loaders
• RustHunt/RustHunt — Adversary detection and hunt framework in Rust, useful for testing evasion techniques from Allocate_With_Syscalls and PEB_Walk
• byt3bl33d3r/SILENTTRINITY — Command & control framework; OffensiveRust payloads can be deployed as SILENTTRINITY agents
• GetRektBoy/CVE-2021-1732 — Rust implementation of Win32k elevation of privilege, complementary kernel exploitation to Kernel_Driver_Exploit
• Legitimate-Use/Invoke-WmiMethod — PowerShell-based WMI lateral movement; OffensiveRust can be used to drop payloads that Invoke-WmiMethod deploys

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 a unified build validation workflow with cross-compilation targets

The repo contains 20+ Rust projects with no CI/CD. A GitHub Actions workflow should validate builds for x86_64-pc-windows-gnu, x86_64-pc-windows-msvc, and i686-pc-windows-msvc targets (mentioned in README's 'Cross Compiling' section). This prevents regressions when dependencies like ntapi are updated and ensures all weaponization tools remain compilable across target architectures.

• [ ] Create .github/workflows/build-validation.yml that iterates over each Cargo.toml in subdirectories
• [ ] Test against x86_64-pc-windows-msvc, x86_64-pc-windows-gnu, and i686-pc-windows-msvc targets
• [ ] Add validation for clippy warnings and cargo check across all projects
• [ ] Document build prerequisites in README (Windows SDK, MinGW versions, etc.)

Add size optimization benchmarks for compiled artifacts

The README explicitly mentions 'Optimizing executables for size' as a section, but the repo lacks any tooling to measure or validate size optimizations. Red team implants require minimal footprint. Create a comparative benchmarking system that measures and reports binary sizes across projects before/after optimization flags.

• [ ] Create scripts/size_report.sh that compiles each project with default and optimized Cargo.toml profiles
• [ ] Add a shared Cargo profile template in a build-config/ directory with LTO, strip, and opt-level settings documented
• [ ] Generate a size_report.md artifact showing binary sizes (baseline vs. optimized) for each of the 20+ projects
• [ ] Add this as a CI artifact in the build-validation workflow from PR #1

Document and consolidate Windows API usage patterns across injection modules

Multiple injection projects (Process_Injection_CreateRemoteThread, Process_Injection_CreateThread, Shellcode_Local_inject, Injection_AES_Loader, Injection_Rc4_Loader) use similar Windows APIs (VirtualAlloc, CreateRemoteThread, etc.) but lack a shared knowledge base. Create a reference guide mapping which APIs each project uses, with OPSEC considerations and detection risks.

• [ ] Create docs/INJECTION_PATTERNS.md documenting each injection variant (CreateRemoteThread vs. CreateThread vs. syscall-based)
• [ ] Add a table mapping each Injection_* project to: target process type, memory allocation method, shellcode execution vector, and known EDR detection vectors
• [ ] Create a shared src/injection_utils/ or update existing utility patterns to reduce code duplication between Process_Injection_* modules
• [ ] Reference specific lines in Process_Injection_CreateRemoteThread/src/main.rs and Shellcode_Local_inject/src/main.rs showing common patterns

• Add unit tests to Process_Injection_CreateRemoteThread/ verifying handle cleanup and payload integrity before injection; currently no test coverage for memory safety in unsafe blocks
• Document Windows version compatibility matrix (Windows 10 vs 11 vs Server 2022) for syscall offsets in Allocate_With_Syscalls/src/main.rs and PEB_Walk/src/types.rs; currently no version guards
• Create a build profile in Cargo.toml top-level [profile.release] enabling opt-level=z, lto=true, and strip=true across all projects to reduce binary size from ~500KB; README mentions optimization but provides no working defaults

• Critical · Intentional Malware/Offensive Tools Repository — Repository root - all modules. This repository is explicitly designed for creating weaponized malware and offensive security tools including process injection, shellcode execution, AMSI bypass, API hooking, and privilege escalation exploits. The codebase is purpose-built for red team operations and contains functional malicious payloads. Fix: This is legitimate security research only if used in authorized penetration testing engagements. Ensure strict access controls, legal authorization, and controlled distribution. Consider using only in isolated lab environments.
• High · Process Injection Capabilities — Process_Injection_* directories, Shellcode_Local_inject/. Multiple process injection modules exist (Process_Injection_CreateRemoteThread, Process_Injection_CreateThread, Process_Injection_Self_EnumSystemGeoID, Shellcode_Local_inject) that enable arbitrary code execution in target processes without legitimate consent, bypassing security boundaries. Fix: Restrict usage to authorized security testing only. Implement logging and monitoring. Consider code signing and integrity verification mechanisms.
• High · Memory Allocation via Syscalls Bypassing Security Monitoring — Allocate_With_Syscalls/src/main.rs. The Allocate_With_Syscalls module directly invokes system calls to allocate memory, potentially evading EDR (Endpoint Detection and Response) and security monitoring tools that hook high-level Windows APIs. Fix: Use only in controlled testing environments. Pair with robust logging mechanisms. Ensure EDR solutions are configured to detect direct syscall patterns.
• High · AMSI Bypass Implementation — amsi_bypass/src/main.rs. The amsi_bypass module contains code to disable or bypass Windows Antimalware Scan Interface (AMSI), a critical security boundary that allows antivirus products to scan scripts and memory. Fix: Use only in authorized penetration tests. Document usage thoroughly. Ensure target organizations are aware this technique may be tested.
• High · API Hooking Capabilities — apihooking/src/main.rs. The apihooking module implements API hooking to intercept and modify Windows API calls, potentially enabling credential theft, behavior manipulation, and security control evasion. Fix: Restrict to authorized security assessments. Implement audit logging. Consider digital signatures to prevent unauthorized modification.
• High · Privilege Escalation via Kernel Driver Exploitation — Kernel_Driver_Exploit/src/main.rs. The Kernel_Driver_Exploit module contains code to exploit vulnerable kernel drivers for privilege escalation from user mode to system level. Fix: Use only in authorized assessments of fully patched systems. Obtain explicit written authorization. Ensure all kernel exploits are properly isolated and tested in disposable environments.
• High · Debug Privilege Escalation — EnableDebugPrivileges/src/main.rs. EnableDebugPrivileges module enables debug privileges which can be used to attach to sensitive processes and manipulate them. Fix: Restrict capability usage. Monitor debug privilege grants. Only use in authorized contexts with proper logging.
• Medium · Encrypted Payload Loaders (AES and RC4) — Injection_AES_Loader/, Injection_Rc4_Loader/. The Injection_AES_Loader and Injection_Rc4_Loader modules contain encrypted shellcode loaders, enabling obfuscation of malicious payloads to evade static analysis and detection. Fix: Use only in controlled red team exercises. Implement decryption key management securely. Ensure payloads are only decrypted in authorized contexts.
• Medium · Direct System Call Assembly (asm_syscall) — asm_syscall/src/. Direct assembly-level syscall invocations bypass user-mode API monitoring and can evade detection mechanisms that rely on API hooking. Fix: Monitor for suspicious syscall patterns at kernel level. Use only in authorized testing with full awareness of evasion implications.
• Medium · PEB (Process Environment Block) Walking — undefined. undefined Fix: undefined

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.