How jnietzsche/wemod-pro-unlocker works
1. This repository is a Windows-only patcher for the WeMod desktop app. Its purpose is entirely local: detect the installed WeMod files, modify the app’s packaged JavaScript/resources, and make the client behave as if the user has Pro.
2. The codebase is split into three main deliverables:
- a Rust CLI in cli/
- a .NET/WPF GUI in gui/
- a separate Go-based updater in updater/
There is also a static/ directory holding a prebuilt GUI installer (gui-x64.msix).
3. The core architectural boundary is “user interface vs. patching engine.”
The CLI and GUI are different front ends, but both ultimately perform the same class of work: operate on the local WeMod installation on disk and invoke patch/update logic.
4. The Rust CLI is the most explicit implementation of the patching pipeline. Its modules suggest these responsibilities:
- folders.rs, files.rs: locate and manipulate the WeMod install tree
- versions.rs: handle version-specific path/layout differences
- patches.rs: apply the actual unlock modifications
- asar.rs: unpack/repack Electron-style asar archives
- fetchIntercept.js, vendorPatch.js: JavaScript patch payloads inserted into the app bundle
- updates.rs: check or fetch updates for the unlocker itself
5. The CLI ships with native helper binaries in cli/bin/, including asar.exe and wemod-pro-unlocker-updater.exe. That indicates the Rust code orchestrates external executables for archive editing and self-update/distribution support rather than implementing everything in pure Rust.
6. The GUI is a separate WPF application under gui/WMPU-GUI/. Its main runtime pieces are:
- MainWindow.xaml/.cs: the user-facing control surface
- Utils/UnlockManager.cs: coordinates the unlock/patch flow
- Utils/UpdateManager.cs: handles updater interactions
- Assets/asar.exe: bundled helper used to edit the WeMod archive
The GUI is a thin orchestration layer over the same local patching workflow.
7. The GUI’s Windows packaging matters architecturally: WMPU-GUI.csproj, Package.appxmanifest, and app.manifest show it is intended to be installed and run as a Windows desktop app, not as a browser app or service. WindowsSystemDispatcherQueueHelper.cs suggests it also contains some Windows-specific UI/runtime plumbing.
8. The updater is its own standalone component in updater/, written in Go. Since it has a separate module (go.mod) and compiled binary, it is likely used for release/update distribution or self-update logic, independent of the main patching UI. The presence of wemod-pro-unlocker-updater.exe in both CLI-related trees reinforces that updater execution is a first-class part of the system.
9. crates.io-wrapper/ looks like a packaging shim around the updater binary for Rust distribution. In architecture terms, it is not part of the unlock flow itself; it exists to publish or bundle the updater in a form suitable for the Rust ecosystem.
10. The data flow is simple and local:
user launches CLI or GUI → tool discovers the installed WeMod directory and version → helper binary and patch scripts modify the WeMod app bundle/ASAR contents → the local app is left in a patched state → optional update path checks for a newer unlocker build, likely via GitHub releases.
11. The main external dependency boundary is the filesystem plus Windows process/runtime behavior. Network access appears secondary and only for update distribution, not for the unlock behavior itself. The repository does not contain any backend server or persistent service.
12. For an architecture diagram, the most important boxes are:
- End-user entry points: CLI, GUI
- Local patching engine: version/file discovery, ASAR manipulation, JS patch payloads
- Native helpers: asar.exe, updater executable
- Distribution/update path: Go updater, release artifacts, MSIX installer
- Target system: installed WeMod app on Windows
Main entry points: main.rs CLI · patches.rs Patch core · MainWindow.xaml.cs GUI · UnlockManager.cs Unlock manager
Components 19
Front ends
User-facing entry points for local unlock/patch workflows.
- CLI · Command-line front end that drives the local patching workflow.
cli/src/main.rs - GUI · Desktop control surface for the unlock flow.
gui/WMPU-GUI/MainWindow.xaml.cs - Unlock manager · Coordinates GUI-side patch and unlock actions.
gui/WMPU-GUI/Utils/UnlockManager.cs - Update manager · Handles GUI-side interaction with update and distribution logic.
gui/WMPU-GUI/Utils/UpdateManager.cs
Patch engine
Shared discovery, archive editing, version handling, and payload application logic.
- Install discovery · Finds the installed WeMod tree and relevant files.
cli/src/folders.rs - File ops · Reads, writes, and reshapes local application files.
cli/src/files.rs - Version rules · Handles version-specific path and layout differences.
cli/src/versions.rs - ASAR tool · Unpacks and repacks Electron-style application archives.
cli/src/asar.rs - Patch core · Applies the main unlock modifications to the app bundle.
cli/src/patches.rs - Fetch patch · Injected JavaScript patch content for request interception.
cli/src/fetchIntercept.js - Vendor patch · Injected JavaScript patch content for app behavior changes.
cli/src/vendorPatch.js - Self update · Checks or fetches newer unlocker builds.
cli/src/updates.rs - asar.exe · Bundled executable used to edit archives from CLI or GUI.
cli/bin/asar.exe
Update and distribution
Standalone updater and packaging artifacts used to ship or refresh the tool.
- Updater exe · Standalone updater binary used by the CLI and packaging paths.
cli/bin/wemod-pro-unlocker-updater.exe - Go updater · Standalone updater component built from its own module.
updater/main.go - Crates wrapper · Packaging layer around the updater binary for Rust distribution.
crates.io-wrapper/src/main.rs - MSIX package · Prebuilt GUI installer used for Windows deployment.
static/gui-x64.msix
Target system
The installed WeMod application and its local Windows runtime environment.
- WeMod app · Installed local WeMod desktop application being modified on disk.
- Windows runtime · Local Windows filesystem, process, and packaging environment.
Connections 23
- CLI → Install discovery: finds install · CLI starts by locating the installed WeMod tree.
- CLI → File ops: reads/writes · CLI performs local filesystem manipulation.
- CLI → ASAR tool: edits archive · CLI invokes archive unpack/repack operations.
- CLI → Patch core: applies unlock · CLI drives the main patch sequence.
- CLI → Self update: checks updates · CLI can trigger unlocker update logic.
- Install discovery → Version rules: resolves layout · Discovery consults version-specific rules.
- Version rules → File ops: guides paths · Version handling informs file selection and edits.
- Patch core → Fetch patch: injects · Patch core applies the fetch interception payload.
- Patch core → Vendor patch: injects · Patch core applies the vendor behavior payload.
- Patch core → ASAR tool: repackages · Patch core relies on archive editing to rewrite app resources.
- ASAR tool → asar.exe: delegates · Archive work is offloaded to the bundled helper executable.
- Patch core → WeMod app: modifies · The unlock flow changes the installed WeMod app on disk.
- GUI → Unlock manager: drives · GUI actions are coordinated through the unlock manager.
- Unlock manager → Install discovery: finds install · GUI uses the same local discovery path as the CLI.
- Unlock manager → Patch core: applies unlock · GUI orchestration feeds the shared patching workflow.
- GUI → Update manager: updates · GUI routes update actions through the update manager.
- Update manager → Updater exe: launches · GUI-side update handling uses the standalone updater executable.
- Updater exe → Go updater: implements · The executable is produced by the Go updater project.
- Crates wrapper → Updater exe: packages · Rust packaging shim wraps the updater binary for distribution.
- MSIX package → GUI: installs · The MSIX artifact distributes the WPF GUI.
- Windows runtime → WeMod app: hosts · The target app and all patching activity live within Windows.
- CLI → Windows runtime: runs on · The CLI depends on Windows process and filesystem behavior.
- GUI → Windows runtime: runs on · The GUI depends on Windows packaging and UI runtime behavior.