benilla rebuilds the World of Warcraft 1.12.1 client in Rust, formats and protocol included

A client that reads your install instead of shipping its own

benilla is a complete World of Warcraft 1.12.1 client, written from scratch in Rust and Bevy. The README is explicit about the boundaries: every file format, the network protocol and the interface engine are written from scratch, with no original client code, no third-party WoW crates and no bundled game assets.

What that means in practice is that benilla is a player that talks to a 1.12.1 server over the original protocol and reads the game's data from your own 1.12.1 install. It needs a client build 5875, in any locale, and it only reads it. The stock interface runs from the FrameXML inside that install at runtime, so the language of the interface follows the language of your client, while development happens on English clients.

The feature scope is large because the game is large. The README lists character creation, questing and professions, dungeons and raids, battlegrounds and honor, groups, guilds, trade, mail and the auction house, all on the stock 1.12 interface and with addons.

Two documents make the project unusually legible. docs/MAP.md maps every crate and subsystem, and docs/DEVIATIONS.md lists everywhere benilla differs from 1.12.1, and the README notes that both are generated from the code, so they cannot drift out of date.

The status line is blunt: complete and fully playable, with the long tail of small features that separates a working client from a finished one tracked as issues.

The asset stack, read byte by byte

The part that makes this a serious engineering project rather than a game clone is the format layer. The README lists readers for the whole asset stack: the MPQ patch chain, BLP, DBC, ADT, WDT, WDL, M2 and WMO, wired into Bevy as an asset source.

Each of those is a real format with real complexity. The MPQ patch chain is the container system the game distributes its data in, and reading it correctly means applying patches in order. BLP is the texture format. DBC files are the tabular game data, and ADT, WDT and WDL are the terrain tile formats for the world. M2 and WMO are the models.

Because the world renderer runs with no game attached, and the format readers and the UI engine core are plain Rust with no Bevy in them, the asset code is usable as a library rather than only as part of the game. That separation is a deliberate structural decision, and it is visible in the dependency graph rather than in prose.

The reverse engineering work is not hidden either. What the real client does is read at its bytes in benilla-re, the reverse engineering project benilla is built against, and the comments in the code cite client addresses, which means the implementation decisions are traceable rather than folklore.

FrameXML and Lua, so the stock interface and addons still run

The interface layer is the most surprising part of the design. benilla implements a FrameXML and Lua engine, and it runs the stock 1.12 interface off your install's patch chain. Third-party 1.12 addons run too, with the README naming Questie, pfUI, Bagnon, Bartender2 and most others.

That decision changes what a player gets. Instead of a reimplementation of the interface, you get the actual interface from your own client, with your own addons, which is why addons such as Questie for quest tracking keep working. The price is that benilla is bound to the 1.12 UI, so where the client diverged the project follows the Classic Era client's behaviour for the options window and the ESC menu rather than 1.12's.

The world and model layers are where Bevy does its work: terrain streamed out to the horizon, portal-culled buildings with interior lighting, doodads and ground clutter, swimmable water, sky and weather, and the client's own day and night lighting, fog and gamma. Models are GPU-skinned with the full animation controller, particles, ribbons and spell visuals, and characters run end to end with customization, the armor composite, weapons with their enchant glows, forms, stealth and mounts.

Movement is networked in both directions, with the server-granted modes from slow fall to roots, a follow camera with collision, and the vehicles that make the world traversable, boats, zeppelins and taxi flights.

The original protocol, and a Warden it does not answer

Networking covers the game end to end. The README describes SRP6 authentication through world-session crypto and the object mirror into the ECS, and then the game content itself: movement and chat through combat, spells, groups and raids, quests, trade, mail, the auction house and battlegrounds.

The object mirror is the interesting phrase. In this client the game world arrives as a stream of object updates that are written into the entity component system, which is why movement and combat are described as networked in both directions rather than as request and response calls.

One line in the README deserves careful reading. benilla does not answer Warden, so a server that enforces it disconnects the session after its timeout, and the project notes that vmangos ships with Warden off. Warden is the anti-cheat system, and the project's position on it is stated in the same place as its other limits: not planned.

That is a compatibility statement, not a capability one. The same paragraph lists what is not planned at all, which is other expansions or client versions, alongside Warden. So benilla is deliberately a 1.12.1 client and nothing else.

For development, the server it is built against is vmangos, and the README says cMaNGOS and the other 1.12.1 cores speak the same protocol. The server defaults to localhost:3724, the stock auth port.

Running it needs your own client and a data path

There are no prebuilt downloads, so the way to try benilla is to build it. The requirements are a 1.12.1 client for the game data, a 1.12.1 server, stable Rust and a C compiler. The compiler is needed because some dependencies build with C, and the platform specifics differ: on macOS the Xcode command line tools, on Linux the ALSA and udev development packages and pkg-config, on Windows the MSVC build tools that the Rust installer sets up.

The run command is short, and the only input is where the game data lives:

WOW_DATA=/path/to/WoW/Data cargo run --release -p benilla

On Windows the same thing is done in PowerShell by setting the environment variable for the session. WOW_DATA names the install's Data folder, and a link named WoW at the repository root does the same job, with ln -s on Unix and a junction on Windows, which the README notes needs no admin rights.

The connection settings are equally plain. WOW_HOST points the client at another server, with a port suffix for a remapped one, or you can set it from the Realmlist button on the login screen, which remembers it. Credentials go in at the login screen, or you set WOW_USER and WOW_PASS to skip it.

Settings, screenshots and addons live in a benilla-config/ directory at the repository root, and a 1.12 addon goes into benilla-config/AddOns/. Releases are tags, so you check out a tag to run that release, while main is the development tip.

A Cargo workspace that fights Bevy's default features

The workspace root is where the engineering decisions are visible. The members are all crates under crates/, the workspace package version is 0.2.0, the edition is 2021, and the licence is MIT OR Apache-2.0. There is a clippy lint override for too_many_arguments, with the comment explaining that a Bevy system's parameter list is its dependency declaration.

The interesting part is Bevy itself. The workspace dependency spells out the default features without audio:

bevy = { version = "0.18.1", default-features = false, features = [
    "default_app",
    "default_platform",
    "2d_bevy_render",
    "3d_bevy_render",
    "ui_api",
    "ui_bevy_render",
    "scene",
    "picking",
] }

The reason is in the comment next to it: the 2d, 3d and ui features each pull bevy_audio and vorbis, and the client mixes through kira instead. The rule is spelled out as adding a feature by name and never 2d, 3d or ui, because a plugin that takes bevy with its default features brings the audio stack back too.

The patch section is more telling still. Two crates are patched from the third_party directory: kira, patched to compute spatial gains and volume tweens per output chunk rather than per sample frame, and alsa, described as a lock-only stand-in so that a stale alsa-sys does not conflict with the newer cpal. The repository root has a third_party/ directory, and each patch carries its own BENILLA.md explaining the change.

It is the kind of dependency surgery you only see in a project where the audio path is a hard requirement rather than an optional extra.

A foundation for forks, with no Blizzard content

The README positions benilla as a faithful 1.12.1 client and the foundation people build on. There are no prebuilt downloads, and the reason is stated plainly: a packaged build, a particular server's changes or anything 1.12.1 never had belongs in a fork, and forks are welcome, with GitHub listing every public fork.

The content question is handled just as plainly. benilla is an independent fan project, not affiliated with or endorsed by Blizzard Entertainment, and it ships no Blizzard content at all: no art, models, sounds, maps, MPQ contents or FrameXML. You provide your own legally obtained 1.12.1 client, and the stock interface runs off its FrameXML at runtime. The few files under crates/benilla-app/assets/ui/ are the project's own, adapters over stock files plus the settings windows and the script error log that benilla draws itself.

Our own code is licensed under MIT or Apache 2.0, with both LICENSE-MIT and LICENSE-APACHE at the repository root. World of Warcraft is a trademark of Blizzard Entertainment.

On activity, the last push was on 2026-10-20, and the single tagged release is v0.2.0, benilla 0.2.0, from 2026-09-27. The work continues on main, which is the development tip, and the community runs on Discord with a YouTube devlog playlist linked from the README.

Editorial conclusion

benilla fits retro players and researchers who want a client they can read, modify and fork, and it fits engine developers who want a Rust and Bevy codebase with a working network protocol, a full asset pipeline and a FrameXML and Lua interface layer to experiment with. It is the wrong tool if you want a ready-made game, since there are no prebuilt downloads and you must supply a legally obtained 1.12.1 client yourself, and it is the wrong tool for a server that enforces Warden, because the client does not answer it. Verify first that your 1.12.1 client build is 5875 or compatible, that the server you connect to does not enforce Warden, and that you are willing to build from source with a stable Rust toolchain, a C compiler and the platform audio packages.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. samwhosung/benilla on GitHub