UMSKT: a research toolkit for pre-2012 Microsoft licensing mechanisms

What the project is actually for

The repository description is one sentence: an open source toolkit designed to research Microsoft Pre-Vista licensing mechanisms. The README's own FAQ tightens that to researching and experimenting with retro Microsoft product licensing for products released before 2012. There is no claim of official Microsoft involvement and no claim of legality for any particular use, which is worth noticing because the category of software this falls into usually comes with louder framing.

UMSKT is AGPL-3.0 licensed, written in C++, sits at 2,353 stars and 242 forks, and had 31 open issues at the last check. The author list in the README names twelve contributors, from z22 and MSKey through Endermanch, who is the person behind the XPKeygen project the README points at for the actual explanation of how the algorithms work. That pointer matters: UMSKT is the executable implementation, XPKeygen is the writeup. If you want to understand what the code is computing rather than how to run the binary, that is where the reasoning lives.

The repository is organised in a way that shows the multi-platform intent. `src/` holds the implementation, `cmake/` the build system support files, `build/` the build directory the README tells you to cd into, `doc/` documentation, and `extras/` auxiliary material. Two files at the root tell you more than the directory listing does: `keys.json`, which is the data the program reads to know what it is generating keys for, and a `LICENSE` file matching the AGPL-3.0 the metadata reports.

One CMake project targeting six platforms and a web build

The README's build section is four steps, and the second one is unusual enough to trip people up: you clone, then you `cd` into the build directory that already exists in the repository, then run CMake pointing at the parent.

git clone https://github.com/UMSKT/UMSKT
cd UMSKT/build
cmake ..
make

The development requirements listed above it are `build-essential` (which the README breaks down into `cmake`, `make`, `gcc` and `g++`) and `git`. Nothing exotic, which is consistent with a project that has to compile on a DOS-era toolchain as well as a current macOS.

The CI badges at the top of the README map out the real target list. There is a Windows x86 and x64 workflow, a Windows ARM workflow, a macOS workflow, a Linux workflow, a DOS DJGPP workflow, and a FreeBSD workflow whose badge is deliberately greyed out and marked unmaintained. That one badge is the honest version of the compatibility story: six targets are built continuously and the seventh is not. The tree also contains `Dockerfile.windows`, `Dockerfile.djgpp` and `Dockerfile.emscripten`, so a web build via Emscripten is part of the intended surface even though the README's badge table does not list it as a supported download.

System requirements are spelled out per platform, which is unusual and helpful. DOS needs an i386 or better, MS-DOS 6.22 or later, and can run under Windows NT 4.0 via NTVDM. Windows x86 and x64 need an i686 or better and Windows XP or later, with a warning that processors barely meeting the XP minimum may not work and that the DOS build via NTVDM is the fallback. Windows ARM64 needs Windows 11 21H2. macOS needs the latest version on either Apple Silicon or x86_64, and Linux needs a modern ARM, x86 or x86_64 processor.

The Docker build produces a single static binary

The plain `Dockerfile` in the repository root is a three-stage build that is worth reading even if you never use Docker, because it documents what the program actually depends on. The first stage starts from Alpine and installs a very short list:

RUN apk add --no-cache \
  bash \
  build-base \
  cmake \
  git \
  musl-dev \
  openssl-dev \
  openssl-libs-static

musl plus static OpenSSL is the entire native dependency surface. That matters for a project whose portability claim extends to DOS: it means the code is not linking against glibc anywhere, which is what makes the same binary buildable on a DOS toolchain and a modern Linux distribution.

The later stages are short enough to read in one sitting. The build stage copies the source to `/src`, creates `/src/build`, and runs `cmake -DMUSL_STATIC=ON ..` followed by `make`. Note that the Docker build passes `-DMUSL_STATIC=ON` explicitly, which is the flag that forces static linking, and that flag is not mentioned in the README's manual build steps. Anyone reproducing the Docker binary by hand will not get an identical result unless they pass it too. The final stage is `FROM scratch`, copying only the built `umskt` executable out, so the resulting image contains a single binary and nothing else.

The last line of the file is the invocation hint, `docker build -o type=tar,dest=umskt.tar .`, which tells you the project expects a tarball export rather than a runnable image, since there is no entrypoint to serve.

The documented workflow: generate, then telephone-activate

The README's usage section is deliberately short. Step one is downloading a binary, with two paths: using the Actions tab, which requires a GitHub account, or taking a tagged release from the releases page, which does not. There is a note about extraction and `chmod +x umskt` on UNIX-like systems, and a macOS-specific warning about unsigned executables requiring Control-click and Open.

Step two is running `umskt`, or `--help` / `-h` for the options. Step three is where the documentation gets specific, and it is scoped to `Retail` and `OEM` only. After installation you are prompted to activate, and the documented path is to select the telephone activation method, then run the tool against the Installation ID the activation wizard provides:

umskt -i <Installation ID>

Two variants follow. For a non-Windows product you add `-m <Product>`, where the README lists `OFFICEXP`, `OFFICE2K3`, `OFFICE2K7`, `PLUSDME` and `OFFICEACC`. For Office 2003 and 2007 you add both `-m <Product>` and `-p <Product ID>`. Step four is, in the README's word, profit.

That telephone activation path is the only end-to-end user workflow the project documents, and it is worth being precise about what it covers. It covers Retail and OEM Windows, and Office 2003 through 2007. It does not cover volume licensing, it does not cover anything released in or after 2012, and the project states plainly that its scope stops there. Everything about how the confirmation ID is derived from the Installation ID is delegated to the XPKeygen writeup linked in the FAQ.

Serial ranges, BINK versions, and what the releases actually changed

The release notes are more informative than the README here, and they explain the shape of the recent work. v0.3.5-beta, published 2026-05-09, adds support for custom serials and serial ranges for BINK2002 keys, with the example `-s 123456,999999` and Windows Server 2003 named as a target. The distinction the notes draw between the two BINK generations is the interesting part: for BINK1998 the tool picks a random serial inside the range, while for BINK2002 it searches for a key that falls within the range, and the notes say plainly that a shorter range takes longer to satisfy.

The release notes also recommend a range over a single value for BINK2002, noting that a single serial still works but you will be waiting a while. That is a performance characteristic of the search, not a correctness requirement.

The same release bundles compressed executables for Windows and DOS, a bug fix, new BINK codes 0x46 and 0x47, and BINK2002-specific action tests. v0.3.4-beta, published 2025-07-21, is the one that changed the interface: it added pipe support when generating confirmation IDs, explicitly so the output can be chained into another tool with a one-liner. Anyone scripting against UMSKT should read that note, because it is the difference between parsing terminal output and not.

The project's development cadence is visible in the issues. The README has a Plan of Action section that points at issue #8 for updates, opened in response to what it calls exponential interest in the project. A single tracking issue for direction is a reasonable choice for a codebase with this many platforms to keep building, and it means the roadmap lives outside the repository.

Where the README stops: ports, chat, and the data file

Three things sit at the edge of the documentation and are easy to miss. First, the README maintains a Known Ports table with two entries: a Rust port by Alex Page at `anpage/umskt-rs` and a Python port by techguy16 at `techguy16/umsktpy`. If you want to read the algorithms in a language you already use, or you want to embed the functionality without shelling out to a C++ binary, those are the places to look, and neither is documented further in this repository.

Second, `keys.json` at the repository root. It is not explained in the README at all, which is a genuine documentation gap rather than a contradiction. The file's name and its position next to `LICENSE` suggest it is the table the program reads to know which products and key families it recognises, and if you are extending the tool with a new BINK variant that is the first file to open. Everything else in the tree is either code, build system, documentation or CI.

Third, the community links at the top of the README: a Discord invite, a libera.chat channel named `#mspid`, and a Zulip instance at umskt.zulipchat.com. The presence of three separate platforms suggests an active contributor community rather than a single maintainer answering issues, which matches a project at 242 forks with 31 open issues.

What the README does not settle is worth stating plainly. It does not explain the licensing mathematics, it does not document `keys.json`'s schema, it does not give a flag reference beyond the handful of options in the usage section, and it does not say what the `-a` and `-b` style short flags mean that appear in the release notes' examples. The repository is at 2,353 stars, was last pushed 2026-06-27, and is not archived, so it is a live project with a documentation surface that has not fully caught up to the code.

Editorial conclusion

UMSKT is interesting as an interoperability and archival project rather than as a way to license anything. It builds one CMake project into binaries for DOS, Windows x86 and x64, Windows ARM64, macOS, Linux and WebAssembly, it ships a docker build that produces a scratch-image binary, and its last push was 2026-06-27 with v0.3.5-beta out on 2026-05-09. The README is candid about what it does not cover: it hands the activation mathematics off to Enderman's XPKeygen writeup rather than explaining it, which means the algorithm details live one repository over. Start with the build steps in the README if you want to compile it, read the release notes for v0.3.5 if you care about serial ranges, and treat the telephone activation section as the only concrete user workflow the project documents.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. UMSKT/UMSKT on GitHub