# Xodus reimplements the Xbox PC package format so the games can run on Linux > A Rust project that logs into your own Xbox account, downloads MSIXVC packages, decrypts them and obtains the licenses needed to launch them, plus a service process that exposes a socket for the rest of the stack. The README is blunt about the state of the work, including the titles that do not work. **xodus-gaming/xodus** — The great gaming migration to Linux and macOS - Repository: https://github.com/xodus-gaming/xodus - Stars: 1,815 · Forks: 72 - Language: Rust - License: GPL-3.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/xodus-gaming-xodus ## What the project does, stated in one line Xodus is a Rust project aiming to bring XBOX PC games to Linux and possibly Mac devices, and the README's own summary of its current state is the most useful sentence in the document: the project can now login, download packages and obtain licenses for games. Those three verbs are the whole scope, and they are worth separating because each one is a hard problem on its own. Logging in means implementing the device login and the user login and the XBOX authorization flow. Downloading means fetching MSIXVC packages from the store. Obtaining licenses means producing the ticket material a launch needs, which the CLI surfaces as a separate command that dumps CIKs for use with XvdTool. The README then says these parts are still quite scattered around, and that sentence is an accurate description of a project that is working but not yet unified. The checklist in the project state section shows how much is done. Device login, user login and XBOX authorization are ticked. MSIXVC download is ticked. On-demand .exe decryption is ticked and is linked to an issue about it. MSIXVC2 support is not ticked, and is linked to its own issue. So the pattern is clear. The current format of Xbox PC packages is handled end to end, and the next format is not yet supported. That single open checkbox is the most important fact for anyone planning to use it, because a game shipped in the new format is simply out of reach. There is a caution at the top of the README that frames everything. This is an unofficial project, to be used at your own risk, and it is not affiliated with, endorsed by or sponsored by Microsoft or XBOX, with all trademarks, product names and company names or logos mentioned being the property of their respective owners. ## Four crates, and a socket as the integration point The project structure is four crates, and the split tells you how the pieces are meant to fit together. ``` . ├── msixvc - [rlib] common rlib crate for utilities for parsing MSIXVC and XSP files ├── xodus - [rlib] common rlib crate that contains core xodus functionality, API calls abstractions and utilities ├── xodus-cli - [bin] CLI currently used for iterating over new xodus features └── xodus-service - [bin] service process exposing a xodus.sock for IPC communication, it takes care of xgameruntime.dll integration. ``` The two libraries are the reusable parts. The `msixvc` crate is the format layer, utilities for parsing MSIXVC and XSP files. The `xodus` crate is the core, with the API call abstractions and utilities. The two binaries are the two ways to reach them. The `xodus-cli` is described as currently used for iterating over new xodus features, which is an honest description of a command line tool that doubles as the development harness for the library behind it. The `xodus-service` is the one designed for the long term. It exposes a `xodus.sock` for IPC communication and it takes care of the `xgameruntime.dll` integration. And there is a note explaining the intent. The `xodus-service` aims to become a main point of integration, and all xodus clients will connect to it to interact with games and XBOX services. That is the architecture in one sentence. The Windows specific runtime integration lives in one process, that process is reachable over a Unix socket, and every other tool in the stack talks to it that way. It is the same shape as the design of Proton and similar compatibility layers, where the Windows-only pieces are isolated behind an interface rather than scattered through the codebase. The workspace metadata reflects a Rust project on a recent toolchain, with `rust-version = "1.98.0"`, resolver 3, and the members taken from `crates/*`. The shared dependencies are a small, deliberate set: `reqwest` with json and stream features, `tokio` with full and tracing, `thiserror`, `chrono`, `base64`, `uuid`, and the `tracing` family with `tracing-subscriber` configured for an environment filter. There is also a patch section, and the patched dependency is not a crates.io package. `ntfs` is redirected to a fork in the project's own organisation, which tells you the stock crate did not do what the project needed and a fork was the answer. A `[patch.crates-io]` entry like that is a maintenance commitment, because the fork has to keep working as the upstream evolves. ## The CLI is the surface you will actually use The command list is short and each command maps to one of the hard problems the project is solving. ``` Usage: xodus-cli Commands: download Download msixvc or xsp files for a given game license Dump CIKs for use with XvdTool extract Extract locally stored msixvc file login streaming Download and extract the game through streaming algorithm clep Generate or decrypt base64-encoded CLEP challenge data sp-license Decode SPLicenseBlock help Print this message or the help of the given subcommand(s) Options: -h, --help Print help -V, --version Print version ``` `download` gets the msixvc or xsp files for a game, and `extract` handles a locally stored msixvc file, so you can work on a package you already have without hitting the network. `license` dumps CIKs for use with XvdTool, which is the piece the runtime needs to believe you own the title. The `clep` command generates or decrypts base64-encoded CLEP challenge data, and `sp-license` decodes an SPLicenseBlock, so the two are the license and the challenge side of the same mechanism. `streaming` downloads and extracts a game through the streaming algorithm, which is the path for large titles that are delivered as a stream rather than as a package. The presence of `login` as a command rather than as a step in the others tells you the authentication is a separate, reusable operation rather than something buried in the download path. Building and running it is three commands. ```bash cargo build --release --workspace ``` ```bash cargo run -- --help ``` ```bash cargo run --bin xodus-service ``` The first builds every crate in release mode, the second runs the CLI in debug, and the third runs the service binary. The prerequisites section is specific about what you need: Rust 1.98 or later, and the CLI relies on wry and tao to show a login page, with a pointer to the wry platform considerations documentation. The service relies on `protoc` to compile the `proto/` definitions, so you need that installed for your platform. The wry and tao dependency is worth understanding. A login page has to be a real window with a real web view, and on Linux that is where the toolkit dependencies get awkward, which is why the README points at the platform considerations rather than pretending it is uniform. ## The CPU requirement will bite on older hardware There is a warning that is more concrete than most, and it deserves attention before you build. For better performance when decrypting MSIXVC files, the `aes` and `ssse3` features are enabled on `x86_64`, and the `aes` feature is enabled on `aarch64`. This means the program will crash with an illegal instruction error when running on a CPU which does not support those instructions, with a link to the AES instruction set page and the note that every processor from 2011 onwards should be supported. So the build is not portable to older hardware, and the failure is a crash rather than a slow path. That is a deliberate trade: the decryption is the hot loop, the hardware instructions make it fast, and the project chose speed over compatibility for a workload that is a one-off download rather than something that runs constantly. There is also a debugging recipe, and it uses one of the more useful tokio features. ```bash RUSTFLAGS="--cfg tokio_unstable" cargo run --features tokio_console ``` Debug and profile `xodus-cli` or `xodus-service` with tokio-console, which visualises the task graph of an async runtime and is close to the only sane way to understand where an async program is spending its time. The `tokio_unstable` cfg flag is the part to remember, because without it the tokio-console feature does not build. That is a small but very common friction point with tokio's unstable tooling. Special thanks go to two projects, XvdTool.Streaming and CikExtractor by LukeFZ, which are the prior art for the streaming algorithm and for the CIK extraction respectively. ## What still does not work, said plainly The FAQ is where the project is most honest, and it is the section to read before you plan to use it. On Minecraft Bedrock, the answer is that while Xodus is quickly maturing there is still a lot of work to support it from the Wine standpoint to provide the necessary XBOX Services to games, with a TL;DR of soon. The wording is a promise without a date, which is the honest form of that answer. On which games will be supported, the answer is that the project hopes to manage most of the catalogue, and the limitation is that the game has to be GDK and in MSIXVC format. So support is bounded by the format, not by the publisher. And a prominent unsupported title is named, Gears of War 4. On XBOX Backward Compatibility on PC, the answer is that while Xodus is capable of downloading and running those titles, it is possible these games will work only after additional patches to wine, dxvk or vkd3d-proton. That is the crucial sentence for an adopter, because it means the project supplies the acquisition and licence side, and the compatibility side still needs work in the graphics stack. Put together with the fact that MSIXVC2 support is an open issue, the picture is of a project that has solved the hardest part of the pipeline, the account, the store, the package format and the licence, and that is now working through the format transition and the runtime compatibility. The topic list is short, gaming-software, xbox and xbox-game-pass, and the licence is GPL-3.0, with the default branch `main` and the last push on 2026-10-06 with the repository not archived. There are no GitHub releases, so the version history is in the commits and in the Discord, which the README points to for anyone wanting to get involved, along with the open GitHub issues. ## Conclusion Adopt Xodus if you are working on making Xbox PC titles run on Linux and you already own the games and the hardware to test them, since the project supplies the download, decryption and license plumbing the runtime still lacks. Do not adopt it as a way to play games you do not have a licence for, and do not expect a finished experience, because the README lists MSIXVC2 support as still open and names a prominent unsupported title. Verify first that your title is in the MSIXVC format the project handles, that your CPU supports the AES instruction set the build enables, and that the extra Wine, DXVK or VKD3D Proton patches a game may need are available for it. ## FAQ ### What does Xodus do? It is a Rust project aiming to bring XBOX PC games to Linux and possibly Mac devices. The project can now login, download packages and obtain licenses for games, and it is an unofficial project used at your own risk with no affiliation to Microsoft or XBOX. ### Which games does Xodus support? The project hopes to support most of the catalogue, with the limitation that the game has to be GDK and in MSIXVC format, and Gears of War 4 is named as a prominent unsupported title. MSIXVC2 support is still an open issue. ### What are the crates in the Xodus project? msixvc is a library for utilities parsing MSIXVC and XSP files, xodus is the library with core functionality and API call abstractions, xodus-cli is the command line binary used for iterating over new features, and xodus-service is the service process exposing a xodus.sock for IPC and handling xgameruntime.dll integration. ### What do I need to build Xodus? Rust 1.98 or later. The CLI relies on wry and tao to show a login page, and xodus-service relies on protoc to compile the proto definitions, so you need protoc installed for your platform. ### Will Xodus run on an older processor? Probably not. The aes and ssse3 features are enabled on x86_64 and the aes feature on aarch64 for faster MSIXVC decryption, so the program crashes with an illegal instruction error on a CPU without those instructions. The README notes every processor from 2011 onwards should be supported. ## Sources - [Issues](https://github.com/xodus-gaming/xodus/issues) - [License: GPL-3.0](https://github.com/xodus-gaming/xodus/blob/main/LICENSE) - [README](https://github.com/xodus-gaming/xodus/blob/main/README.md) - [xodus-gaming/xodus on GitHub](https://github.com/xodus-gaming/xodus) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xodus-gaming-xodus