Onboarding: BeyondDimension/SteamTools

Generated by RepoPilot · 2026-05-05 · Source

Verdict

WAIT — Mixed signals — read the receipts

• Last commit 8w ago
• 5 active contributors
• GPL-3.0 licensed
• CI configured
• ⚠ Small team — 5 top contributors
• ⚠ Concentrated ownership — top contributor handles 50% of commits
• ⚠ GPL-3.0 is copyleft — check downstream compatibility
• ⚠ No test directory detected

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

TL;DR

Watt Toolkit (formerly Steam++) is an open-source, cross-platform multi-function toolbox for Steam users built on .NET 7 / C# 11 with Avalonia UI. It provides features like network acceleration via local reverse proxy (bypassing SNI-based blocking for Steam CDN/community), Steam account switcher, game save cloud sync, and ASF (ArchiSteamFarm) integration. It solves the problem of Steam being inaccessible or slow in regions with network restrictions, and bundles several Steam power-user utilities into one GUI app. This is a large C# monorepo (WattToolkit.slnx solution) with platform-specific build scripts under build/linux/ and build/macos/, packaging scripts under packaging/, and ref/ holding pre-built interop assemblies. The UI layer uses Avalonia (cross-platform), with build/settings_v4_app.json driving publish configuration and NuGet.Config managing private/custom feeds.

Who it's for

Chinese-market Steam users and PC gamers who need to bypass network-level Steam restrictions, and C# / .NET developers who want to contribute to a large-scale, cross-platform Avalonia desktop app with real-world network proxy, platform integration, and multi-target build complexity.

Maturity & risk

The project has substantial download volume (GitHub badge shows total downloads in the millions range), an active CI/CD pipeline in .github/workflows/dotnet.yml and publish.yml, and is distributed via Steam Store (App ID 2425030), Microsoft Store, and direct releases. It is actively developed and production-ready for its primary use case, with Crowdin-managed i18n and dependabot configured.

The project is heavily dependent on reverse-proxying Steam network infrastructure, meaning Valve could break compatibility at any time with CDN or auth changes. The SNK signing keys (WattToolkit.snk, avalonia.snk) in the repo root are a security consideration for forks. There is a single primary maintainer organization (BeyondDimension) and the CI workflows (CI.yml.bak is disabled/backed-up) suggest some pipeline instability. The .gitmodules file indicates submodule dependencies whose external health is not visible here.

Active areas of work

The primary CI workflow is dotnet.yml and publish.yml; CI.yml.bak is currently disabled, suggesting a recent pipeline migration. The Crowdin localization badge indicates ongoing translation work. Dependabot is configured (.github/dependabot.yml) for automated dependency updates. The presence of build/publish_apphost_linux_x64.sh and packaging/build.ps1 suggests active cross-platform release packaging work.

Get running

git clone --recurse-submodules https://github.com/BeyondDimension/SteamTools.git cd SteamTools

Ensure .NET 7 SDK is installed: https://dotnet.microsoft.com/download/dotnet/7.0

dotnet restore WattToolkit.slnx

To build for your current platform:

dotnet build WattToolkit.slnx

For Linux-specific setup:

bash build/linux/environment_check.sh

Daily commands:

Development run (after restore):

dotnet run --project <path-to-main-project>.csproj

Linux packaging:

bash build/publish_apphost_linux_x64.sh

Windows packaging:

powershell -File packaging/build.ps1

macOS packaging:

bash build/macos/build.sh

Map of the codebase

• WattToolkit.slnx — The solution file defining all projects, their relationships, and the overall build structure — must be read first to understand the project topology.
• build/settings_v4_app.json — Central application build/publish settings that control feature flags, platform targets, and versioning for the entire toolbox.
• .github/workflows/dotnet.yml — Primary CI workflow defining the build matrix, test steps, and artifact generation for all supported platforms.
• .github/workflows/publish.yml — Release publication pipeline — governs how builds are packaged, signed, and distributed across Windows, macOS, and Linux.
• NuGet.Config — Configures NuGet package sources including any private feeds, critical for restoring all dependencies correctly.
• packaging/build.ps1 — Cross-platform packaging script that orchestrates final artifact assembly, code signing, and installer creation.
• build/linux/Steam++.sh — Linux entry-point shell script that bootstraps the application environment, sets up paths, and launches the .NET runtime — essential for understanding Linux deployment.

How to make changes

Add a new Linux platform feature or script

1. Create the feature shell script following the existing pattern (env checks, error handling, exit codes) (build/linux/Steam++.sh)
2. Register any new desktop integration entries or file associations (build/linux/init_desktop.sh)
3. Add environment validation for any new runtime dependencies your feature requires (build/linux/environment_check.sh)
4. Update the Linux program file structure documentation to reflect new files (doc/program-file-structure/Linux.md)

Add a new platform build target

1. Add the new platform project reference and solution configuration to the solution file (WattToolkit.slnx)
2. Define build settings, RIDs (Runtime Identifiers), and feature flags for the new target (build/settings_v4_app.json)
3. Create or extend the packaging script to handle artifact assembly for the new platform (packaging/build.ps1)
4. Add a new CI job matrix entry targeting the new platform (.github/workflows/dotnet.yml)
5. Add the new platform artifact to the publish pipeline (.github/workflows/publish.yml)

Add a new native/interop dependency

1. Place the native DLL/SO/dylib in the ref/ directory following existing naming conventions (ref/WinDivert.dll)
2. Document the new dependency, its license, and its purpose (doc/open-source-library.md)
3. Update SHA256 generation script if the new binary needs checksum verification (packaging/SHA256.ps1)
4. Update build settings to include the new native asset in the output (build/settings_v4_app.json)

Add or update application branding/icons

1. Place SVG source artwork following the v2 naming convention (res/icons/app/v2/Logo.svg)
2. Export and place the Windows .ico file at all required resolutions (res/icons/app/v2/Icon.ico)
3. Export and place the macOS .icns bundle (res/icons/app/v2/Logo.icns)
4. Update Android mipmap resources for all density buckets (res/icons/app/v2/UnitTest.Droid/mipmap-hdpi/ic_launcher2.png)

Why these technologies

• .NET / C# — Provides cross-platform runtime (Windows, Linux, macOS) with a single codebase, strong ecosystem for system-level operations, and Avalonia UI support for native-feeling desktop apps.
• Avalonia UI — Enables truly cross-platform native desktop UI from a single C# codebase, avoiding Electron's memory overhead while still supporting all three major desktop OSes.
• WinDivert (native) — Required for low-level Windows network packet interception that enables the Steam network acceleration and proxy features — no managed alternative exists for this capability.
• GitHub Actions — Provides the multi-platform build matrix (Windows, Ubuntu, macOS runners) needed to simultaneously build and test all platform targets in CI.
• Shell scripts (Bash/PowerShell) — Platform-specific bootstrapping, environment validation, and packaging logic that must run before the .NET runtime is available or outside its scope.
• Zstandard (libzstd) — High-performance compression for application data and network traffic, reducing bandwidth and improving perceived performance for Chinese users behind slow connections.

Trade-offs already made

• Avalonia over Electron/web-based UI

  • Why: Reduces memory footprint and provides native OS integration (system tray, notifications, file dialogs) without shipping a full Chromium runtime.
  • Consequence: Smaller community and fewer ready-made UI components than Electron; custom controls require more effort.

• WinDivert kernel driver for network features

  • Why: Only mechanism to transparently intercept and redirect Steam network traffic at the packet level on Windows without requiring VPN-level OS privileges.
  • Consequence: Requires driver signing, Windows-only, adds AV false-positive risk

Traps & gotchas

1. The repo uses git submodules (.gitmodules) — you MUST clone with --recurse-submodules or run 'git submodule update --init --recursive' or the build will fail with missing references. 2) WattToolkit.snk and avalonia.snk are strong-name signing keys checked into the repo; forks must either replace these or disable strong-name signing to avoid assembly conflicts. 3) NuGet.Config may reference private/internal BeyondDimension feeds that external contributors cannot access, potentially causing restore failures for some packages. 4) The Linux build requires specific environment dependencies checked by build/linux/environment_check.sh — skipping this script on a fresh machine will cause cryptic runtime failures.

Architecture

Concepts to learn

• SNI-based network blocking bypass via local reverse proxy — The core acceleration feature works by intercepting HTTPS connections locally and re-routing them to bypass SNI inspection — understanding this is essential to working on the network proxy subsystem.
• Strong-name signing (.snk) in .NET — WattToolkit.snk and avalonia.snk are used to sign assemblies for tamper-proofing and GAC compatibility — forks must handle these keys carefully to avoid assembly identity conflicts.
• Avalonia MVVM pattern — All UI in this app is built with Avalonia's XAML and the MVVM (Model-View-ViewModel) pattern — contributors must understand data binding, commands, and ReactiveUI/CommunityToolkit.Mvvm conventions.
• .NET RID (Runtime Identifier) catalog — The cross-platform publish scripts use RIDs (e.g. linux-x64, win-x64, osx-arm64) to produce platform-specific self-contained binaries — misunderstanding RIDs causes wrong build artifacts.
• Git submodules — The .gitmodules file means parts of the codebase live in external repos — failing to initialize submodules is the #1 cause of fresh-clone build failures.
• Crowdin localization workflow — crowdin.yml defines automated sync between source code string files and Crowdin's translation platform — contributors adding new UI strings must follow this integration to avoid untranslated text in releases.
• AppHost (dotnet publish apphost) — build/publish_apphost_linux_x64.sh uses the .NET apphost mechanism to produce a native executable wrapper — this is how the app launches without requiring users to invoke 'dotnet' directly.

Related repos

• JustArchiNET/ArchiSteamFarm — Watt Toolkit integrates ASF directly for Steam card farming automation; understanding ASF's API is required for that feature area.
• nicehash/NiceHashQuickMiner — Close alternative in spirit — another C#/.NET desktop utility app targeting a gaming-adjacent platform, useful for architectural comparison.
• AvaloniaUI/Avalonia — The cross-platform UI framework powering Watt Toolkit's desktop interface — contributors must understand Avalonia XAML and MVVM patterns.
• BeyondDimension/SteamTools — This is the canonical repo; the Gitee mirror (rmbgame/SteamTools) is synced via .github/workflows/sync-gitee.yml for Chinese users.
• dotnet/runtime — Watt Toolkit targets .NET 7 and uses runtime-specific publish features (apphost, RID-specific builds) — relevant when debugging platform-specific runtime issues.

PR ideas

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 GitHub Actions CI workflow for Avalonia/Desktop builds (replace CI.yml.bak)

The repo has a .github/workflows/CI.yml.bak file which indicates the CI workflow was disabled or broken. Given the project targets multiple platforms (Windows, Linux, macOS) with Avalonia and there is an avalonia.snk key file plus WattToolkit.slnx solution file, restoring and fixing a proper CI workflow that builds and tests the Avalonia desktop app on all three platforms would catch regressions early. The existing dotnet.yml and xamarin.yml exist but the primary CI is disabled.

• [ ] Rename or review .github/workflows/CI.yml.bak to understand why it was disabled
• [ ] Create a new .github/workflows/CI.yml that triggers on push and pull_request to main branches
• [ ] Add matrix build steps for ubuntu-latest, windows-latest, and macos-latest using dotnet build WattToolkit.slnx
• [ ] Include a dotnet test step targeting any test projects found in the solution
• [ ] Verify the NuGet.Config private feed sources are handled with secrets so forks can still build public code
• [ ] Add a build status badge to README.md and README.en.md pointing to the new workflow

Add missing English translations/content to README.en.md to match README.md feature coverage

The repo has both README.md (Chinese) and README.en.md (English), but open-source projects with international audiences often let the English README fall behind. Given the project has a crowdin.yml localization config already set up, ensuring README.en.md has complete feature descriptions, screenshots, install instructions, and contributor guides matching README.md would significantly lower the barrier for non-Chinese contributors and users, which directly impacts adoption and contribution quality.

• [ ] Do a section-by-section diff between README.md and README.en.md to identify missing sections
• [ ] Translate or write English equivalents for any missing feature descriptions, especially around Steam network acceleration, game management, and account switching features
• [ ] Ensure all badge links in README.en.md point to correct English-language resources (e.g. Crowdin, issue templates like .github/ISSUE_TEMPLATE/bug-report.en.md and .github/ISSUE_TEMPLATE/question.en.md)
• [ ] Add a 'Contributing' section to README.en.md referencing the doc/publish.md build instructions
• [ ] Verify crowdin.yml is configured to keep README.en.md in sync and add it to the Crowdin source files if not already included

Create missing program file structure documentation for Android/Mobile platform

The doc/program-file-structure/ directory contains documentation for Linux.md, Windows.md, and macOS.md, but there is no corresponding file for Android, despite the repo having res/brands/android.svg indicating Android is a supported platform. Additionally xamarin.yml workflow exists suggesting mobile builds. Adding doc/program-file-structure/Android.md (and potentially iOS) would help contributors understand the app's data and config directory layout on mobile, which is critical for debugging storage permission issues and for contributors working on the Android target.

• [ ] Review the existing doc/program-file-structure/Linux.md, Windows.md, and macOS.md to understand the documented structure format
• [ ] Identify the Android-specific app data paths (e.g. /data/data/<package>/, external storage paths) used by the project by inspecting the source or existing build/ scripts
• [ ] Create doc/program-file-structure/Android.md documenting config files, log files, cache, and certificate storage locations on Android
• [ ] Check if iOS is also a target (given `res

Good first issues

1. The doc/program-file-structure/ directory has platform docs (Linux.md, Windows.md, macOS.md) but no equivalent for Android/mobile — if mobile is targeted, add that doc. 2) build/linux/environment_check.sh could be extended to auto-install missing dependencies (currently it only checks) — a good first PR is adding apt/dnf install commands for detected missing libs. 3) CI.yml.bak is a disabled/backed-up workflow with no explanation in the file — document why it was disabled and whether it should be restored or deleted.

Top contributors

• @AigioL — 48 commits
• @rmbadmin — 31 commits
• @Mossimos — 8 commits
• @Lxy829 — 6 commits
• @luojunyuan — 3 commits

Recent commits

• 8612251 — Merge branch 'develop' of https://github.com/BeyondDimension/SteamTools into develop (Mossimos)
• 67f0477 — Update Startup.cs (Mossimos)
• 8ee7e09 — Steam编辑数据支持导入导出 (rmbadmin)
• e464f28 — Merge branch 'develop' of https://github.com/BeyondDimension/SteamTools into develop (AigioL)
• 68d1435 — 🔧 更新预览版本号至 5 (AigioL)
• d42f6ba — 😭 没有办法只能特殊处理github脚本注入问题 (rmbadmin)
• 662a5ac — 🔨 优化脚本注入路径为同源，修复github加速在启用脚本的情况下出现异常 (rmbadmin)
• f422c76 — 挂卡支持黑名单游戏自动排除 (rmbadmin)
• cd85ff7 — 🔧 升级预览版本号，优化登录注册异常处理 (AigioL)
• bd30f0d — 🔧 更新 Common 子模块及预览版本号 (AigioL)

Security observations

• High · Hardcoded Signing Key Files Committed to Repository — WattToolkit.snk, avalonia.snk. The repository contains .snk (Strong Name Key) files: 'WattToolkit.snk' and 'avalonia.snk'. These are signing key files used for .NET assembly strong naming. If these private keys are committed to the repository, any attacker can use them to sign malicious assemblies with the same identity, potentially bypassing trust checks or impersonating legitimate signed assemblies. Fix: Remove .snk files from the repository immediately. Add them to .gitignore. Use CI/CD secrets management (e.g., GitHub Actions secrets) to inject the signing key at build time. Rotate the keys if they have been exposed.
• High · Pre-compiled Binary DLLs and SYS Files in Repository — ref/WinDivert.dll, ref/WinDivert64.sys, ref/libzstd.dll, ref/Interop.IWshRuntimeLibrary.dll. The repository contains pre-compiled binary files: 'ref/WinDivert.dll', 'ref/WinDivert64.sys', 'ref/libzstd.dll', and 'ref/Interop.IWshRuntimeLibrary.dll'. Including binary files in source control without verifiable checksums or build provenance poses a significant supply chain risk. WinDivert is a network packet interception driver — a malicious or tampered version could intercept and manipulate all network traffic. There is no visible integrity verification mechanism for these binaries. Fix: Remove pre-compiled binaries from the repository. Use a verified package manager (NuGet) to obtain these dependencies with cryptographic hash verification. If binaries must be included, document their source, version, and publish SHA256 checksums in a verified manifest. The presence of 'packaging/SHA256.ps1' suggests tooling exists — ensure it is enforced in CI.
• High · Kernel-mode Driver Included as Pre-built Binary — ref/WinDivert64.sys. The file 'ref/WinDivert64.sys' is a kernel-mode Windows driver. Including a pre-built kernel driver in the repository without code signing verification or build reproducibility is extremely dangerous. A tampered kernel driver could be used for rootkit-like behavior, privilege escalation, or complete system compromise. The origin and integrity of this binary cannot be verified from the repository alone. Fix: Obtain WinDivert only from the official, digitally signed release by the original author (reqrypt.org). Verify the digital signature of the driver before distribution. Document the exact version and SHA256 hash. Consider using Windows Driver Signature Enforcement validation in your build/release pipeline.
• Medium · Shell Scripts with Potential Command Injection Risk — build/linux/online_install.sh, build/linux/offline_init.sh, build/linux/environment_check.sh, packaging/build.sh, build/macos/build.sh. Multiple shell scripts exist in the repository (build/linux/.sh, packaging/.sh, build/macos/build.sh). Without reviewing their content, shell scripts that incorporate environment variables or external input without proper quoting/escaping are susceptible to command injection. Scripts like 'online_install.sh' that likely download and execute remote content are particularly risky if they do not verify integrity of downloaded artifacts. Fix: Review all shell scripts for proper input quoting and escaping. Ensure 'online_install.sh' verifies downloaded file integrity via SHA256 checksums before execution. Use 'set -euo pipefail' at the top of all scripts. Avoid using unquoted variables. Prefer package manager installation over curl-pipe-bash patterns.
• Medium · GitHub Actions Workflow Misconfiguration Risk — .github/workflows/publish.yml, .github/workflows/dotnet.yml, .github/workflows/CI.yml.bak. The repository has multiple GitHub Actions workflow files including 'publish.yml' and 'dotnet.yml'. Without reviewing content, publish workflows that use third-party actions with mutable references (e.g., 'uses: actions/checkout@main' instead of a pinned SHA) are vulnerable to supply chain attacks where a compromised action could exfiltrate secrets or inject malicious code into the build. The presence of a disabled workflow 'CI.yml.bak' may also contain outdated or insecure configurations. Fix: Pin all GitHub Actions to specific commit SHAs rather than mutable tags or branches. Audit 'CI.yml

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

Where to read next

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