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

• 12 active contributors
• MIT licensed
• ⚠ Stale — last commit 2y ago
• ⚠ Single-maintainer risk — top contributor 82% 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 Jessecar96/SteamDesktopAuthenticator repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Jessecar96/SteamDesktopAuthenticator.

What it runs against: a local clone of Jessecar96/SteamDesktopAuthenticator — 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 Jessecar96/SteamDesktopAuthenticator | 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 ≤ 596 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Jessecar96/SteamDesktopAuthenticator(\\.git)?\\b" \\
  && ok "origin remote is Jessecar96/SteamDesktopAuthenticator" \\
  || miss "origin remote is not Jessecar96/SteamDesktopAuthenticator (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 "Steam Desktop Authenticator/Program.cs" \\
  && ok "Steam Desktop Authenticator/Program.cs" \\
  || miss "missing critical file: Steam Desktop Authenticator/Program.cs"
test -f "Steam Desktop Authenticator/MainForm.cs" \\
  && ok "Steam Desktop Authenticator/MainForm.cs" \\
  || miss "missing critical file: Steam Desktop Authenticator/MainForm.cs"
test -f "Steam Desktop Authenticator/UserFormAuthenticator.cs" \\
  && ok "Steam Desktop Authenticator/UserFormAuthenticator.cs" \\
  || miss "missing critical file: Steam Desktop Authenticator/UserFormAuthenticator.cs"
test -f "Steam Desktop Authenticator/FileEncryptor.cs" \\
  && ok "Steam Desktop Authenticator/FileEncryptor.cs" \\
  || miss "missing critical file: Steam Desktop Authenticator/FileEncryptor.cs"
test -f "Steam Desktop Authenticator/Manifest.cs" \\
  && ok "Steam Desktop Authenticator/Manifest.cs" \\
  || miss "missing critical file: Steam Desktop Authenticator/Manifest.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 596 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~566d)"
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/Jessecar96/SteamDesktopAuthenticator"
  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).

Steam Desktop Authenticator is a Windows desktop application that replicates Steam's mobile two-factor authenticator, allowing users to generate time-based authentication codes and approve trade/login confirmations without a smartphone. Written in C# using WinForms, it reads encrypted maFiles (Steam account credential files) and provides a GUI to manage multiple Steam accounts' authentication tokens locally. Single monolithic WinForms desktop application. Main entry point: Program.cs → MainForm.cs (primary UI window). Supporting UI forms include LoginForm.cs, ConfirmationFormWeb.cs, SettingsForm.cs, ImportAccountForm.cs. Core logic: UserFormAuthenticator.cs manages account data, FileEncryptor.cs handles encrypted maFile persistence, Manifest.cs parses Steam's manifest format. All forms have paired .Designer.cs and .resx files.

PC gamers and Steam power users who need two-factor authentication on desktop instead of mobile, or developers debugging Steam's authentication system. Specifically targets Windows 10+ users who have Steam accounts with mobile authenticator enabled and want offline desktop access.

Abandoned/legacy project. The README explicitly states: 'Steam Desktop Authenticator is no longer supported and will not receive any more updates.' The project was community-maintained but is now unmaintained. This is a stable codebase with 112K lines of C#, but no active development, ongoing security maintenance, or version updates—use at your own risk.

High risk for production use. The project is explicitly unsupported and unmaintained; the README warns users to use Steam's official app instead because SDA 'completely defeats the purpose of two-factor authentication' (defeating the security model). Additional risk: if you lose the encryption key or delete maFiles without saving the revocation code, account recovery is nearly impossible. Fake malicious versions have been circulating, so download only from this specific GitHub repo.

No active development. The repository is in read-only/archived state. No recent commits, PRs, or issue triage are happening. This is a frozen snapshot of the last stable release before the project was abandoned.

Check README for instructions.

Daily commands:

1. Install .NET 8 from https://dotnet.microsoft.com/en-us/download/dotnet/8.0. 2. Open Visual Studio → Build → Build Solution (or dotnet build from CLI). 3. Press F5 or click 'Start' to launch the WinForms application. The app reads/writes to the maFiles/ directory in its working folder for encrypted account data.

• Steam Desktop Authenticator/Program.cs — Application entry point and initialization; understand how the desktop app bootstraps and manages the main window lifecycle.
• Steam Desktop Authenticator/MainForm.cs — Primary UI controller managing authenticator accounts, token generation, and user interactions; the core business logic hub.
• Steam Desktop Authenticator/UserFormAuthenticator.cs — Core authenticator logic for TOTP token generation and Steam-specific authentication algorithms.
• Steam Desktop Authenticator/FileEncryptor.cs — Encryption/decryption of stored account credentials; critical for secure persistence of sensitive Steam data.
• Steam Desktop Authenticator/Manifest.cs — Manifest file parsing and account registry management; defines how accounts are persisted and loaded.
• Steam Desktop Authenticator/LoginForm.cs — Steam login flow and session management; implements the authentication interaction with Steam's servers.
• Steam Desktop Authenticator/ConfirmationFormWeb.cs — Web-based confirmation UI for trade and market confirmations; bridges desktop app with Steam's web interface.

Add a new authenticator account type

1. Create a new subclass of authenticator logic in UserFormAuthenticator.cs, implementing the token generation algorithm (Steam Desktop Authenticator/UserFormAuthenticator.cs)
2. Update Manifest.cs to support serialization of the new account type in the manifest JSON structure (Steam Desktop Authenticator/Manifest.cs)
3. Modify MainForm.cs to display and refresh tokens for the new account type in the main UI grid (Steam Desktop Authenticator/MainForm.cs)
4. If import is needed, add import logic to ImportAccountForm.cs (Steam Desktop Authenticator/ImportAccountForm.cs)

Add a new UI dialog or form

1. Create a new .cs file with a class inheriting from Form, and its corresponding .Designer.cs and .resx files (e.g., NewFeatureForm.cs, NewFeatureForm.Designer.cs, NewFeatureForm.resx) (Steam Desktop Authenticator/)
2. Define UI controls in the Designer file and implement event handlers in the main .cs file (Steam Desktop Authenticator/[NewFeatureForm].cs)
3. Invoke the new form from MainForm.cs or another existing form using ShowDialog() or Show() (Steam Desktop Authenticator/MainForm.cs)
4. If the form needs to persist settings, integrate with SettingsForm.cs or Manifest.cs (Steam Desktop Authenticator/SettingsForm.cs)

Add a new account data field or encrypted credential

1. Define the new field in the Manifest.cs account structure and update JSON serialization/deserialization (Steam Desktop Authenticator/Manifest.cs)
2. Encrypt/decrypt the new field using FileEncryptor.cs methods in the manifest load/save pipeline (Steam Desktop Authenticator/FileEncryptor.cs)
3. Update ImportAccountForm.cs to parse and import the new field from external account exports (Steam Desktop Authenticator/ImportAccountForm.cs)
4. Add UI input controls in WelcomeForm.cs or a dedicated setup form to capture the new field from users (Steam Desktop Authenticator/WelcomeForm.cs)

Add Steam API interaction or trade confirmation logic

1. Implement new Steam API method calls or web request logic in a handler file (e.g., extend ConfirmationFormWeb.cs or create a new Steam API helper) (Steam Desktop Authenticator/ConfirmationFormWeb.cs)
2. Integrate the API call into MainForm.cs to trigger on user action or background refresh (Steam Desktop Authenticator/MainForm.cs)
3. Update TradePopupForm.cs if the new logic requires user notifications or quick-access buttons (Steam Desktop Authenticator/TradePopupForm.cs)
4. Test with account credentials stored in Manifest.cs to ensure API auth headers are properly attached (Steam Desktop Authenticator/Manifest.cs)

• Windows Forms (WinForms) — Lightweight desktop UI framework for Windows; allows rapid form-based UI development without external dependencies; matches the .NET Framework ecosystem.
• AES encryption (via FileEncryptor.cs) — Industry-standard symmetric encryption for protecting stored account secrets and TOTP seeds at rest on disk.
• TOTP (Time-based One-Time Password) — Standard RFC 6238 algorithm for generating 6-digit codes synchronized with server time; compatible with Steam's mobile authenticator.
• JSON serialization (Manifest.cs) — Human-readable and portable format for persisting account registry; easy to version-control and diff.
• .NET Framework / C# — Windows-native language with built-in cryptography libraries; enables direct OS integration and quick deployment as a standalone exe.

• Desktop-only (Windows 10+) vs. cross-platform

  • Why: Windows Forms and certain Steam API integrations are Windows-specific; easier to implement and secure for this use case.
  • Consequence: Mac and Linux users cannot use this tool; must rely on Steam's official mobile app.

• Store encrypted secrets in local manifest.json vs. cloud

  • Why: Keeps secrets offline and under user control; avoids third-party server compromise risks.
  • Consequence: No account recovery if manifest file is lost; users must maintain encrypted backups manually.

• WebBrowser control for confirmations (ConfirmationFormWeb.cs) vs. direct API calls

  • Why: Reuses Steam's existing web UI; avoids reverse-engineering confirmation endpoints and HTML parsing.
  • Consequence: Tied to Steam's web UI changes; breaking changes can silently fail without clear error messages.

• Single-threaded main form event loop vs. async/await throughout

  • Why: Simpler logic for a small desktop app; reduces threading complexity and UI deadlock risks.
  • Consequence: Long-running operations (login, API calls) can freeze the UI; requires manual background threading where needed.

• Cross-platform support (macOS, Linux)
• Mobile/native

1. Submodule dependency: The repo uses git submodules (see .gitmodules); cloning without --recursive will leave the lib/ folder empty and the build will fail. 2. maFiles directory structure: The app expects an unencrypted maFiles/ folder at runtime with individual <accountname>.maFile JSON files; missing this causes silent failures. 3. Encryption key storage: Each account's encryption key is stored in manifest.json; if this file is lost or corrupted, all maFiles become unrecoverable (no key derivation fallback). 4. .NET 8 requirement: Older guide mentions .NET Framework; current README specifies .NET 8, so check your installed version. 5. Steam API rate limits: The app makes unthrottled requests to Steam's API for confirmations; aggressive polling may trigger temporary IP blocks. 6. Web confirmation parsing: ConfirmationFormWeb.cs relies on parsing Steam's HTML/JavaScript; any UI changes on Steam's side break confirmation detection.

• Time-based One-Time Password (TOTP) — SDA generates 5-digit Steam authentication codes using TOTP (HMAC-SHA1 + time-based counter); understanding the algorithm is essential to debug or modify token generation in UserFormAuthenticator.cs.
• Base32 Encoding — Steam account secrets in maFiles are stored as base32-encoded strings; the authenticator must decode these before HMAC computation.
• AES-256 Encryption (CBC mode with PKCS7 padding) — The entire maFiles credential storage relies on AES-256-CBC symmetric encryption; FileEncryptor.cs implements this, and any changes here affect account security.
• HMAC (Hash-based Message Authentication Code) — TOTP generation uses HMAC-SHA1 to create authenticator codes; this is the cryptographic foundation of Steam's 2FA scheme.
• Manifest Pattern (Account Registry/Metadata Store) — SDA uses a manifest.json file to track all linked Steam accounts, encryption keys, and metadata; Manifest.cs deserializes this, making it the central account registry.
• WinForms Event-Driven UI Architecture — The entire UI (MainForm, LoginForm, ConfirmationFormWeb) is built on WinForms event callbacks and form lifecycle; understanding Form.Load, button Click handlers, and timers is essential for UI modification.
• Confirmation Polling (Continuous HTTP Polling Pattern) — SDA polls Steam's confirmation API in a loop to detect pending trades/logins; ConfirmationFormWeb.cs implements this; high polling frequency can trigger rate limits.

• Jessecar96/steamguard-python — Same author's Python port of Steam authenticator logic; useful reference for understanding TOTP generation and maFile format parsing in another language.
• DoctorMcKay/node-steam-user — Node.js library for Steam account interaction including authenticator support; complements SDA by providing programmatic auth APIs for integration.
• DoctorMcKay/node-steamcommunity — Node.js bindings for Steam Community API (trade confirmations, marketplace, etc.); SDA uses similar endpoints that are documented here.
• ValvePython/steam — Python library for Steam client & Community interaction, including authenticator code generation; provides alternative implementation of SDA's core logic.
• Frogger/Steam-Desktop-Authenticator-fork — Community fork attempting to continue maintenance after the original project was abandoned; may have ongoing patches and security fixes.

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.

Extract and consolidate Form UI logic into a base UserControl class

The repo contains 10+ Form files (LoginForm, ConfirmationFormWeb, TradePopupForm, etc.) that likely share common UI patterns, event handling, and validation logic. Creating a reusable base UserControl would reduce code duplication, improve maintainability, and make future form changes easier. This is a concrete refactoring opportunity visible from the file structure.

• [ ] Analyze LoginForm.cs, ConfirmationFormWeb.cs, TradePopupForm.cs, and SettingsForm.cs for common patterns (initialization, event handlers, validation)
• [ ] Create a new BaseAuthenticatorForm.cs class inheriting from Form with shared lifecycle methods
• [ ] Extract common UI initialization and event binding logic into the base class
• [ ] Refactor 3-4 existing Form classes to inherit from BaseAuthenticatorForm
• [ ] Add unit tests for the base form (InputValidation, EventHandling) in a new Tests folder

Add comprehensive unit tests for FileEncryptor.cs and MaFileEncryptedException.cs

Encryption is security-critical in an authenticator app. FileEncryptor.cs has no visible test coverage, yet it handles sensitive credential encryption/decryption. Adding tests for edge cases (corrupted files, wrong passwords, missing files) would catch regressions early and document expected behavior for future contributors.

• [ ] Create Steam Desktop Authenticator/Tests/FileEncryptorTests.cs with xUnit or MSTest
• [ ] Add test cases for: valid encryption/decryption round-trip, wrong password rejection, corrupted file handling, empty file handling, large file handling
• [ ] Add tests for MaFileEncryptedException custom exception behavior and message formatting
• [ ] Update Steam Desktop Authenticator.csproj to include test project references
• [ ] Document test coverage expectations in a new TESTING.md file

Create a GitHub Actions CI workflow for .NET build and test verification

The repo has no visible CI/CD pipeline. Given the security-sensitive nature of an authenticator and the README warning about fake versions, automated build verification on each PR would prevent regressions and ensure code quality. A .NET-specific GitHub Actions workflow is concrete and immediately valuable.

• [ ] Create .github/workflows/build-and-test.yml with .NET build matrix (net48, net5.0, net6.0)
• [ ] Add step to restore NuGet dependencies from lib/ and packages
• [ ] Add step to build Steam Desktop Authenticator.csproj with /p:TreatWarningsAsErrors=true
• [ ] Add step to run FileEncryptorTests.cs and any existing unit tests
• [ ] Add step to verify .exe generation and sign check (if applicable)
• [ ] Document build requirements in CONTRIBUTING.md (Visual Studio version, .NET SDK requirements)

• Add comprehensive unit tests for FileEncryptor.cs: currently no test coverage for AES encryption/decryption edge cases, key derivation, or corrupted file handling. Create FileEncryptorTests.cs with xUnit.
• Document the maFile format in a MAFILE_FORMAT.md file: newcomers don't understand the JSON structure, encryption scheme, or account metadata fields. Reverse-engineer and document from Manifest.cs and UserFormAuthenticator.cs parsing logic.
• Extract TOTP generation logic into a standalone, well-tested utility class: currently embedded in UserFormAuthenticator.cs with no clear API. Create SteamTotpGenerator.cs with isolated HMAC-SHA1 + base32 decode, then add 10+ test cases for time-sync edge cases.

• Critical · Project No Longer Supported - Unmaintained Code — README.md, entire codebase. The README explicitly states 'Steam Desktop Authenticator is no longer supported and will not receive any more updates.' This means security vulnerabilities will never be patched, and the codebase may contain known exploits that won't be addressed. Fix: Users should migrate to Steam's official mobile authenticator app immediately. Consider archiving the repository or adding prominent deprecation notices.
• Critical · Sensitive Credential Storage Risk — FileEncryptor.cs, Manifest.cs, and related authentication handling. The application handles Steam authentication credentials and stores encrypted manifest files (mafiles). Without access to the actual implementation, there's inherent risk in desktop-based credential management. The presence of FileEncryptor.cs and MaFileEncryptedException suggests local encryption, but desktop-based storage is vulnerable to local privilege escalation attacks. Fix: Never store Steam credentials locally. Use system credential stores (Windows Credential Manager). Implement additional security measures like requiring PIN entry for sensitive operations. Consider using hardware tokens if available.
• High · No Visible Input Validation in Forms — LoginForm.cs, PhoneInputForm.cs, ImportAccountForm.cs, InputForm.cs, ListInputForm.cs, CaptchaForm.cs. Multiple form classes exist (LoginForm.cs, PhoneInputForm.cs, ImportAccountForm.cs, etc.) but without code inspection, proper input validation and sanitization cannot be verified. Forms accepting user input are potential vectors for injection attacks. Fix: Implement strict input validation on all user input fields. Use allowlists for expected input patterns. Sanitize all data before use in API calls or storage.
• High · Deprecated Desktop Authentication Method — Entire application design. The README explicitly warns about fake versions and phishing risk. A desktop authenticator is inherently less secure than mobile apps as it's on the same device as the browser, increasing likelihood of malware compromise. Fix: Users should use official Steam mobile app. Developers should consider whether this tool should continue to exist at all given the security risks.
• High · Web-Based Confirmation Form Potential XSS — ConfirmationFormWeb.cs, ConfirmationFormWeb.Designer.cs. The presence of ConfirmationFormWeb.cs suggests the application displays web content. Without code inspection, it's unclear if proper security measures are in place to prevent XSS attacks from malicious Steam responses. Fix: Ensure all content from Steam API is properly validated and escaped before rendering. Use WebBrowser control security settings properly. Consider using a more modern HTML rendering library with better security controls.
• High · No Visible HTTPS/Certificate Pinning — Network communication components (not directly visible in file list). As an application communicating with Steam API, there's no visible evidence of certificate pinning or HTTPS validation hardening in the file structure. Fix: Implement certificate pinning for Steam API endpoints. Use only HTTPS for all communications. Validate SSL certificates properly to prevent MITM attacks.
• Medium · Windows Forms Security Concerns — All .Designer.cs and .cs files in Steam Desktop Authenticator folder. The application uses Windows Forms UI with multiple forms and popup dialogs. Windows Forms can be vulnerable to UI redressing and lacks modern security features of WPF or web-based UIs. Fix: Consider migrating to WPF with proper security controls. Implement window validation to prevent UI spoofing attacks. Use proper input validation and output encoding.
• Medium · Manifest File Storage Security — Manifest.cs, FileEncryptor.cs. The presence of Manifest.cs and mafile handling suggests account data is stored in files. Encryption strength and key derivation methods are not visible, potentially using weak encryption. Fix: Use strong encryption (AES-256-GCM) with proper key derivation (PBKDF2 or Argon2). Store encryption keys in secure system storage, not derived from passwords alone. Implement secure deletion of sensitive data in memory.
• Medium · Potential Command Injection via CommandLineOptions — undefined. CommandLineOptions.cs processes command-line arguments. If these are not properly validated and sanitized, 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.