Microsoft-Activation-Scripts/MAS

MAS — Rust port

An idiomatic Rust re-architecture of the Microsoft Activation Scripts. This is a re-architecture, not a line-by-line transliteration: the batch scripts' goto/errorlevel/global-set style is replaced with typed enums, Result error flow, and a single trait boundary between portable logic and Windows internals.

Architecture

src/
  model.rs              Product / Method / LicenseStatus enums + the real SPP GUIDs
  error.rs              typed Error/Result (replaces errorlevel + colored echoes)
  data/kms_hosts.rs     ported data tables
  platform/
    mod.rs              `Spp` trait — the ONE seam to Windows; safe API over FFI
    stub.rs             non-Windows backend (read-only no-ops; privileged ops error)
    windows_backend.rs  real WMI/COM backend (cfg(windows) + feature "winapi")
  activation/
    status.rs            Check_Activation_Status.cmd  [ported: read path]
    online_kms.rs        Online_KMS_Activation.cmd    [ported: orchestration]
    hwid.rs / kms38.rs   HWID_Activation.cmd          [scaffold + spec]
    ohook.rs             Ohook_Activation_AIO.cmd     [scaffold + spec]
    tsforge.rs           TSforge_Activation.cmd       [scaffold + spec]
  cli/                  the interactive menu (MAS_AIO front-end)

Every Windows effect — WMI calls, ClipUp, registry — lives behind [platform::Spp]. The rest of the crate is OS-independent and unit-tested.

Build & test

# Portable core — builds and tests on any OS, zero dependencies:
cargo test

# Real Windows backend (WMI/COM via the `windows` crate):
cargo build --release --features winapi --target x86_64-pc-windows-msvc

The Windows backend is written against windows 0.58 from the documented SPP WMI contract. It has not been compiled on the porting host (Linux has no Windows target) — expect to shake out minor windows-crate signature drift on a real Windows build. The portable core (menus, model, data, orchestration) is compiled and tested (20 passing).

Port status & roadmap

The three deepest activators are not fakeable; each carries its analyzed spec in the module docs as the roadmap:

Module	Why it's hard (from analysis)
TSforge	Byte-exact reverse-engineered SPP trusted-store (data.dat: RSA/AES/HMAC, per-block CRC32/SHA-256, per-OS alignment). A faithful port ≈ porting LibTSforge to a pure libtsforge crate + thin FFI to swap data.dat.
Ohook	Ships two reverse-engineered SPP-client DLLs (sppc32/64.dll, pinned SHA-256) that forward to the renamed genuine DLL. The blobs are assets, not code; the portable planner + license install is the port.
status	The rich detail uses the undocumented SLC private ABI (SLGet*Information, 40-byte struct stride, KUSER_SHARED_DATA @0x7FFE02C8). The WMI backend here covers the common case; the SLC path is a future direct-FFI slice.

HWID/KMS38 are a shorter hop: generate GenuineTicket.xml (portable) and delegate to ClipUp.exe + ClipSVC (the script does the same — the ticket consumption is closed Windows behavior).

What is deliberately faithful

• SPP ApplicationID GUIDs, WMI class names, method + parameter names, and LicenseStatus codes are the real Microsoft values (see model.rs tests).
• Online KMS falls through a host list exactly like the script; --kms-host overrides it.
• Nothing reports "activated" that didn't actually activate — unported paths return a typed Unsupported error instead of lying.