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/atom0s/Steamless 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 2y ago

• 2 active contributors
• Other licensed
• ⚠ Stale — last commit 2y ago
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 99% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ 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 atom0s/Steamless repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/atom0s/Steamless.

What it runs against: a local clone of atom0s/Steamless — 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 atom0s/Steamless | Confirms the artifact applies here, not a fork | | 2 | License is still Other | 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 ≤ 801 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other 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 "Steamless.API/Model/SteamlessPlugin.cs" \\
  && ok "Steamless.API/Model/SteamlessPlugin.cs" \\
  || miss "missing critical file: Steamless.API/Model/SteamlessPlugin.cs"
test -f "Steamless.API/PE32/Pe32File.cs" \\
  && ok "Steamless.API/PE32/Pe32File.cs" \\
  || miss "missing critical file: Steamless.API/PE32/Pe32File.cs"
test -f "Steamless.API/PE64/Pe64File.cs" \\
  && ok "Steamless.API/PE64/Pe64File.cs" \\
  || miss "missing critical file: Steamless.API/PE64/Pe64File.cs"
test -f "Steamless.CLI/Program.cs" \\
  && ok "Steamless.CLI/Program.cs" \\
  || miss "missing critical file: Steamless.CLI/Program.cs"
test -f "Steamless.Unpacker.Variant30.x86/Main.cs" \\
  && ok "Steamless.Unpacker.Variant30.x86/Main.cs" \\
  || miss "missing critical file: Steamless.Unpacker.Variant30.x86/Main.cs"

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

Steamless is a C# DRM remover that unpacks SteamStub DRM protection from Steam-protected executables. It strips only the SteamStub wrapper layer (various versions from v1 to v20+) from PE32/PE64 binaries while preserving Steamworks API calls and game integrity, enabling legitimate owners to analyze or run their purchases without the DRM runtime check. Modular plugin architecture: Steamless.API/ defines core contracts (SteamlessPlugin base class, Pe32File/Pe64File wrappers for PE binary handling, LoggingService). Variant-specific unpackers in Steamless.Unpacker.Variant*.x86/ implement unpacking logic per SteamStub version. Steamless.CLI/ provides command-line interface; GUI likely in separate unpublished project. ExamplePlugin/ demonstrates plugin interface for custom variants.

Reverse engineers, security researchers, and game preservation enthusiasts who own Steam games and need to remove SteamStub DRM protection for legitimate analysis, archival, or offline play. Plugin developers extending Steamless can add support for new SteamStub variants via the Steamless.API contract.

Active ongoing project with modular plugin architecture supporting 10+ SteamStub variants. Single primary maintainer (atom0s) with community contributions. Contains working CLI and GUI variants. Lacks public test suite or CI/CD pipeline visible in repo structure, suggesting reliance on manual testing. Production-ready for its intended scope (DRM removal only) but without automated regression tests.

Single-maintainer risk with slow-to-moderate update cadence as new SteamStub variants emerge post-release. No visible automated testing framework despite handling binary PE format manipulation (a high-risk operation). Dependency on accurate SteamStub header structure definitions in variant unpacker classes (e.g., Steamless.Unpacker.Variant20.x86/Classes/SteamStubHeader.cs) — incorrect struct offsets silently corrupt output. Legal status constrained by CCA-NCND v4 license limiting commercial use.

Repository structure shows support for SteamStub variants up to at least Variant20, with separate x86 unpackers for different versions. No active commit history visible in provided data, but presence of multiple variant-specific projects suggests ongoing maintenance as new Steam DRM versions are deployed. Current focus appears to be breadth (supporting more variants) rather than depth (features).

git clone https://github.com/atom0s/Steamless.git
cd Steamless
dotnet build Steamless.sln
# Or in Visual Studio 2019+: open Steamless.sln and Build Solution

Daily commands: CLI mode: dotnet run --project Steamless.CLI -- --input game.exe --output game_unpacked.exe. Plugin development: Create new project inheriting SteamlessPlugin in Steamless.API, implement UnpackFile() and GetAuthor() methods, output DLL to plugin folder that Steamless discovers at runtime.

• Steamless.API/Model/SteamlessPlugin.cs — Abstract base class for all unpacker plugins; defines the plugin contract that every variant implementation must follow.
• Steamless.API/PE32/Pe32File.cs — Core PE32 file parsing and manipulation logic; essential for understanding how executable headers and sections are read and modified.
• Steamless.API/PE64/Pe64File.cs — Core PE64 file parsing and manipulation logic; parallels Pe32File for 64-bit executable support.
• Steamless.CLI/Program.cs — Command-line entry point; demonstrates how to instantiate the plugin system and trigger unpacking workflows.
• Steamless.Unpacker.Variant30.x86/Main.cs — Reference implementation of a variant unpacker showing the complete pattern for DRM removal and decryption logic.
• Steamless.API/Services/LoggingService.cs — Centralized logging and event notification system used across all plugins and the main application.
• Steamless.API/Crypto/AesHelper.cs — Cryptographic utility for AES decryption of Steam DRM sections; core to the unpacking process.

Add Support for a New SteamStub Variant

1. Create a new project folder (e.g., Steamless.Unpacker.Variant32.x86) and copy the ExamplePlugin structure. (ExamplePlugin/Main.cs)
2. Define the SteamStub header structure specific to your variant (check Steamless.Unpacker.Variant31.x86/Classes/SteamStubHeader.cs for reference). (Steamless.Unpacker.Variant31.x86/Classes/SteamStubHeader.cs)
3. Implement DRM flags and helper methods to parse the variant's encryption and protection scheme. (Steamless.Unpacker.Variant31.x86/Classes/SteamStubHelpers.cs)
4. Inherit from SteamlessPlugin and override CanUnpack() and Unpack() methods in your Main.cs. (Steamless.API/Model/SteamlessPlugin.cs)
5. Use Pe32File or Pe64File for section manipulation, AesHelper for decryption, and LoggingService for diagnostic output. (Steamless.API/Services/LoggingService.cs)
6. Register the new plugin by adding its DLL to the plugins folder where the CLI/GUI application looks for plugins at runtime. (Steamless.CLI/Program.cs)

Add a New Cryptographic Decryption Method

1. Extend AesHelper.cs with a new static method for your encryption algorithm (e.g., AesDecrypt with custom IV/key derivation). (Steamless.API/Crypto/AesHelper.cs)
2. Call the new decryption method from your variant's SteamStubHelpers class during the unpacking process. (Steamless.Unpacker.Variant31.x86/Classes/SteamStubHelpers.cs)
3. Log decryption progress using LoggingService.LogMessage() to provide user feedback. (Steamless.API/Services/LoggingService.cs)

Modify PE File Structure During Unpacking

1. Load the source executable using Pe32File.FromFile() or Pe64File.FromFile() in your variant's Unpack() method. (Steamless.API/PE32/Pe32File.cs)
2. Iterate over sections and use Pe32Helpers or Pe64Helpers to identify and extract the original code section. (Steamless.API/PE32/Pe32Helpers.cs)
3. Decrypt the extracted section using AesHelper and reinsert it into the PE sections list. (Steamless.API/Crypto/AesHelper.cs)
4. Call Pe32File.WriteFile() to save the unpacked executable with corrected section headers and entry points. (Steamless.API/PE32/Pe32File.cs)

• C# / .NET Framework — Low-level PE manipulation, cryptography, and cross-platform plugin system require strong typing and direct memory access. .NET provides managed access to unsafe code with GC overhead acceptable for batch unpacking.
• WPF (Windows Presentation Foundation) — Desktop GUI for interactive unpacking; common choice for Windows-native .NET applications with real-time logging display.
• Plugin Architecture (Dynamic Assembly Loading) — Variant-specific unpacking logic evolves independently; plugins allow new variants to be added without rebuilding the entire application.
• SharpDisasm (x86/x64 Disassembler) — Some variants require instruction-level analysis to locate encryption keys or DRM entry points during unpacking (bundled in Variant20/21 plugins).
• AES Cryptography (System.Security.Cryptography) — Steam DRM sections are encrypted with AES; native .NET crypto APIs avoid external dependencies and provide hardware acceleration.

• Plugin-based architecture instead of monolithic unpacker

  • Why: SteamStub variants differ significantly in DRM structure and encryption; maintaining separate plugins allows independent iteration and testing.
  • Consequence: Higher operational complexity (plugin discovery, versioning) but cleaner code isolation and easier community contributions for specific variants.

• Support both PE32 and PE64 via separate variant plugins

  • Why: 32-bit and 64-bit executables have different structure and unpacking strategies; code duplication is minimal but logical separation is clear.
  • Consequence: Twice as many unpacker plugins to maintain, but the variant discovery system automatically selects the correct one based on file architecture.

• Batch CLI mode with no real-time interaction during unp

  • Why: undefined
  • Consequence: undefined

1. Struct packing: SteamStubHeader structs in variant classes depend on exact byte alignment; missing [StructLayout(LayoutKind.Sequential, Pack = 1)] causes offset mismatches. 2. Plugin discovery: CLI/GUI expects unpackers in a specific plugin folder at runtime; DLL not in correct location silently skips variant support. 3. OEP recovery: Original Entry Point offset in packed executables varies per variant; hardcoded offsets in older variants fail on patched Steam builds. 4. PE section mapping: Pe32File.cs assumes standard .text/.data/.reloc layout; obfuscated or non-standard section names may fail silently. 5. License scope: CCA-NCND v4 forbids commercial distribution; hosting Steamless on commercial platforms risks legal action.

• PE (Portable Executable) Format — Steamless parses PE32/PE64 headers, sections, and exports; understanding PE structure (DOS header, NT header, section table, RVA-to-file-offset mapping) is essential to unpacking without corrupting binaries.
• SteamStub DRM — The specific DRM protection scheme Steamless removes; varies across 20+ versions with different encryption, packing, and OEP obfuscation techniques. Each variant requires custom unpacker logic.
• Original Entry Point (OEP) Recovery — SteamStub encrypts and relocates the real executable code; Steamless must identify and restore the OEP (original program start address) to make unpacked binaries executable.
• AES Encryption (Block Cipher) — SteamStub payload is encrypted with AES; Steamless.API/Crypto/AesHelper.cs handles decryption using variant-specific keys and initialization vectors.
• Relocation Table (.reloc Section) — When unpacking, image base and section addresses may change; the relocation table must be updated to fix absolute address references in the unpacked code.
• RVA (Relative Virtual Address) — PE files use RVA to reference code/data; Steamless must convert RVA ↔ file offset using the section header table during binary reconstruction.
• Plugin Architecture / Dependency Injection — Steamless uses abstract SteamlessPlugin base class and runtime plugin discovery to support multiple variants without recompiling core; enables community contributions for new SteamStub versions.

• OllyDbg/pydbg — Binary debugging and PE inspection tool; complements Steamless by allowing manual verification of unpacked executables and OEP validation.
• x64dbg/x64dbg — Modern debugger for PE binaries used to verify Steamless output and trace SteamStub behavior during unpacking development.
• radare2/radare2 — Reverse engineering framework for PE analysis; used by Steamless contributors to identify new SteamStub variants and validate unpacking correctness.
• dnSpy/dnSpy — .NET decompiler and debugger; useful for analyzing Steamless plugin code and Steamworks API integration in unpacked games.
• 0xd4d/dnlib — .NET metadata reader/writer used internally by Steamless variants for analyzing .NET assemblies wrapped by SteamStub.

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.

Add x64 unpacker variants for Variant10, Variant20, and Variant21

The repo currently has x86 implementations for Variant10, Variant20, and Variant21, but only Variant30 has an x64 version. Modern games increasingly use 64-bit executables, and supporting x64 for these variants would significantly expand compatibility. This is a high-value addition that directly aligns with the project's goal of supporting as many games as possible.

• [ ] Create Steamless.Unpacker.Variant10.x64/ directory mirroring the x86 structure with x64-specific PE64 handling
• [ ] Create Steamless.Unpacker.Variant20.x64/ with x64 adaptations of SteamStubHeader, SteamStubDrmFlags, and SteamStubHelpers from the x86 variant
• [ ] Create Steamless.Unpacker.Variant21.x64/ following the same pattern as Variant20.x64
• [ ] Update the plugin architecture in Steamless.API to allow registration and loading of these new x64 variants
• [ ] Add test cases or documentation demonstrating support for x64 variants of these stub versions

Add unit tests for PE32/PE64 file parsing (Steamless.API/PE32/PE64 modules)

The Pe32File.cs, Pe64File.cs, and their helper classes (Pe32Helpers, Pe64Helpers) are critical for parsing executable headers and sections, but there are no visible test files in the structure. Adding comprehensive unit tests would ensure robust handling of edge cases, malformed files, and prevent regressions when maintaining multiple variant unpackers.

• [ ] Create Steamless.Tests/ project with MSTest or xUnit framework
• [ ] Add Pe32FileTests.cs with tests for header parsing, section reading, and boundary conditions
• [ ] Add Pe64FileTests.cs with tests specific to 64-bit PE format handling and differences from 32-bit
• [ ] Add Pe32HelpersTests.cs and Pe64HelpersTests.cs for utility function validation
• [ ] Create sample test PE files or mock data to ensure tests can run without external dependencies

Add GitHub Actions CI workflow for multi-variant testing and automated builds

The repo has no visible CI configuration (.github/workflows/ is empty except FUNDING.yml). With multiple unpacker variants and both x86/x64 architectures, a CI pipeline would catch cross-platform build failures early, validate each variant independently, and ensure CLI and plugin loading work correctly across different configurations.

• [ ] Create .github/workflows/build.yml to build all projects (Steamless.API, Steamless.CLI, all variants) on Windows
• [ ] Add build matrix testing for Debug and Release configurations
• [ ] Include a step to verify all unpacker variant plugins can be discovered and loaded by the API
• [ ] Add artifact uploading for compiled CLI and plugin DLLs on successful builds
• [ ] Optionally add a workflow for automated testing (once Steamless.Tests project exists from suggestion #2)

• Add unit tests for Steamless.API/PE32/Pe32Helpers.cs and PE64/Pe64Helpers.cs helper methods (RVA conversion, section lookup) — currently no test files exist despite these being core to binary parsing correctness.
• Document SteamStub variant identification logic: create a guide in /docs/ explaining how the CLI determines which unpacker (Variant10, Variant20, etc.) to use for a given executable, with hex dumps of distinguishing SteamStub header markers.
• Implement PE64 x64 unpacker plugins (only Steamless.Unpacker.Variant20.x86 visible; Variant20.x64 is missing) — copy x86 variant, adjust register sizes and calling conventions, test against 64-bit Steam games.

Steamless presents a moderate-to-high security risk profile due to its core purpose of circumventing DRM protections (legal/compliance concern) combined with several technical security gaps. The primary risks include: (1) unverified binary dependencies with supply chain implications, (2) insufficient input validation for binary PE file parsing that could enable exploitation, (3) unvetted cryptographic implementations, and (4) an unsandboxed plugin system. The codebase lacks comprehensive security documentation and threat modeling. While the project has legitimate research and preservation use cases, users must understand legal implications. Developers should prioritize input validation hardening, dependency verification, and cryptographic code review.

• High · DRM Circumvention Tool - Legal and Security Concerns — Repository root - Project purpose. Steamless is explicitly designed to remove SteamStub DRM protection from applications. This functionality may violate the Digital Millennium Copyright Act (DMCA) and similar laws in other jurisdictions that prohibit circumvention of access controls, regardless of intent. Additionally, the tool could be misused for software piracy and distribution of unpacked copyrighted binaries. Fix: Ensure compliance with local laws and Steam's Terms of Service. Add prominent legal disclaimers. Consider implementing safeguards to prevent misuse such as watermarking or tracking.
• Medium · Unmanaged Binary Dependencies — Steamless.Unpacker.Variant20.x86/SharpDisasm.dll, Steamless.Unpacker.Variant21.x86/SharpDisasm.dll. The codebase includes unverified binary dependencies such as 'SharpDisasm.dll' in multiple variant unpacker folders (Variant20, Variant21). These binaries are not properly documented, and their integrity and origin cannot be verified from the provided file structure. This poses a supply chain risk. Fix: Replace unmanaged binaries with verified NuGet packages or source code. Implement integrity checks (hash verification) for any required binaries. Document the source and version of all dependencies.
• Medium · Lack of Input Validation Framework — Steamless.API/PE32/Pe32File.cs, Steamless.API/PE64/Pe64File.cs, Steamless.API/Extensions/FileStreamExtensions.cs. The codebase contains PE file parsing logic (Pe32File, Pe64File) that directly manipulates binary structures and streams. There is no visible input validation framework or security checks for malformed PE files, which could lead to buffer overflows, arbitrary code execution, or denial of service when processing crafted malicious PE files. Fix: Implement comprehensive input validation for all PE file parsing operations. Add bounds checking, magic number verification, and section validation. Implement fuzzing tests with malformed PE files.
• Medium · Missing Cryptographic Verification — Steamless.API/Crypto/AesHelper.cs. The AesHelper.cs utility exists for encryption/decryption operations, but without visible code review, it's unclear if the cryptographic implementation follows security best practices. Weak crypto implementations could lead to unpredictable behavior during DRM removal. Fix: Ensure AES implementation uses authenticated encryption (AES-GCM or AES-CBC with HMAC). Verify proper IV handling, key derivation, and padding schemes. Use established cryptographic libraries rather than custom implementations.
• Low · Missing Security Headers and Logging Controls — Steamless.API/Services/LoggingService.cs. While primarily a desktop application, the CLI and plugin infrastructure could benefit from enhanced logging security. The LoggingService lacks visible mechanisms for preventing sensitive information leakage in logs (e.g., file paths, intermediate decryption keys, memory addresses). Fix: Implement log filtering to prevent sensitive data exposure. Add configuration options for log levels. Never log cryptographic keys, full file paths, or memory addresses.
• Low · Plugin Architecture Without Sandboxing — Steamless.API/Model/SteamlessPlugin.cs, ExamplePlugin/. The plugin system (SteamlessPlugin.cs, ExamplePlugin) allows loading external code with full access to the application's capabilities. There is no visible sandboxing or capability restriction mechanism, allowing malicious plugins to access all PE file parsing and DRM removal functionality. Fix: Implement a plugin signature verification system. Restrict plugin capabilities through AppDomains or separate processes. Document plugin security requirements clearly. Consider publishing plugin guidelines.

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.