wowemulation-dev: Three Open Tools Split the WoW Emulation Stack

By Indie Kings | October 17, 2026

Updated October 17, 2026: The wowemulation-dev project on GitHub ships three independent tools that each handle one stage of running a World of Warcraft client against a server you control: a decompiler that reconstructs Blizzard's protobuf contracts from the client binaries, a from-scratch Lua 5.1.1 interpreter written in Rust, and a Rust patcher that points a legally installed client at a personal home server. Per the protobuf-decompiler README, clients from build 70032 onward are not supported because Blizzard upgraded the protobuf runtime compiled into the game for the first time in over a decade.

Image: wowemulation-dev repository card. Credit: GitHub, wowemulation-dev.

Three tools, three different jobs

A reader would summarize the wowemulation-dev toolkit like this: one program rips the protobuf contract out of Blizzard's client binaries, another rebuilds the Lua 5.1.1 runtime WoW uses for its scripting, and a third takes an original client off your own legal installation and points it at a server you run yourself. The toolkit feels overwhelming on first contact because each piece answers a different question, and none of the three READMEs assumes you know the other two. Per the project's footnotes, all three are independent implementations based on reverse engineering and are not affiliated with Blizzard Entertainment.

The org is wowemulation-dev on GitHub, and two of the three READMEs describe the work as a nights-and-weekends effort by one person who lists sustained development funding as a goal. The stack splits cleanly: protobuf-decompiler is C++ with a CMake build, rilua is Rust with zero external dependencies, and wow-patcher is Rust with a Cargo build. All three build from source only.

• protobuf-decompiler: extracts and reconstructs .proto files from reflection metadata compiled into client binaries, per its README.
• rilua: a from-scratch Rust interpreter of Lua 5.1.1 targeting behavioral equivalence with the PUC-Rio reference interpreter, per its README.
• wow-patcher: a Rust client patcher that redirects a WoW executable's login, keys, and certificate bundle toward a personal server, per its README.

The protobuf ripper and where it stops

Per the protobuf-decompiler README, the tool reconstructs .proto files from Google Protocol Buffers reflection metadata that was compiled into binaries, and it was designed for World of Warcraft client analysis. It works in four recorded steps: it searches executable files for embedded protobuf descriptors, parses the reflection metadata using protobuf internal APIs, resolves dependencies between message types with a recorded two-pass resolution, and generates .proto files that keep the original structure and imports. The output is a readable contract, not just a data dump.

The version boundary is the notable news. Per the README, Blizzard upgraded the protobuf runtime compiled into WoW clients for the first time in over a decade, so the current release is the last one that supports the old fork. Binaries embed a version string, and the README spells it exactly as blizzard_protobuf.version, which is how a tool (or a person) tells two eras apart at a glance.

Per the README, the 2.6.1 based descriptor handling silently discards edition era fields such as FeatureSet and edition, which is why binaries from build 70032 onward cannot be reconstructed faithfully. Future releases of the decompiler will target newer protobuf versions. In the meantime, the supported window covers retail 6.0.2 through retail build 12.1.0.69933 and WoW Classic 1.13.2 through MoP Classic build 5.5.3.66290.

The project is MIT licensed and builds on Linux and macOS for x86_64 and ARM64 with CMake, a C++17 compiler, and Boost. Per the same notes, Windows builds are currently not supported in CI because of protobuf 2.6.1 compatibility requirements, the code uses pointer arithmetic into protobuf internal structures, and it contains intentional memory leaks to avoid protobuf double free issues. Those are engineering choices, not accidents, and the README states them plainly.

A Lua 5.1.1 rebuilt in Rust

Per the rilua README, this is a from-scratch Lua 5.1.1 interpreter written in Rust that targets behavioral equivalence with the PUC-Rio reference interpreter, meaning executed Lua code must produce identical results. It has zero external dependencies and uses only Rust's standard library, and it can also run in the browser as a compiled WASM build. The compile and run story in one sentence: its riluac tool compiles Lua source scripts into bytecode chunks that are byte compatible with the PUC-Rio toolchain, the rilua command runs scripts or a REPL, and both are built from source with Cargo and used as an embeddable library for Rust applications.

The choice of Lua 5.1.1 is not nostalgia. Per the README, World of Warcraft's addon system uses Lua 5.1.1, where unpack is a global (it moved to table.unpack in 5.2), all numbers are 64 bit floats (integers arrived in 5.3), and there is no goto keyword (added in 5.2). The interpreter reproduces all of that, including all 17 metamethods and every one of the nine standard libraries.

The compatibility claims are concrete. Per the README, the virtual machine implements 38 register based opcodes matching the PUC-Rio encoding, binary chunks load in both directions, and all 23 official Lua 5.1.1 test files pass, including the all.lua runner that completes in roughly 3 seconds in release mode. Performance sits at about 1.7 times slower than the reference interpreter, measured on an AMD Ryzen 7 8840U in release mode as the median of 10 runs, which the README argues is negligible for configuration and game scripting workloads.

The engineering difference from binding wrappers like mlua is where the safety sits. Per the README, the garbage collector, compiler, and VM contain no unsafe blocks, with unsafe confined to declared C library interfaces and module loading, whereas the mlua project itself acknowledges containing a large amount of unsafe code bridging C error handling and Rust ownership. rilua propagates errors as typed results that keep the call stack intact instead of unwinding it, and an optional dynamic module feature lets hosts load Rust built modules rather than C libraries. Two limitations are stated: the interactive debug.debug() function is a stub, and C library loading is rejected by default with an incompatible ABI message unless the Rust module feature is enabled.

The use cases map to emulation directly, per the README: running and testing WoW addons outside the game client, embedding server side scripting for emulators such as CMaNGOS, TrinityCore, and AzerothCore, and simulating the client's restricted Lua sandbox and its taint system. The project is dual licensed under Apache 2.0 or MIT.

Getting an original client onto a home server

Per the wow-patcher README, this is a Rust patcher written so you can run the WoW client on your own computer and connect to a personal server at home, and the project states plainly that you must own the client and expansions you want to play. The patcher modifies WoW executables by redirecting the login portal, replacing cryptographic keys, and injecting a custom certificate bundle. It patches files on disk with no in client memory modifications, supports Windows, macOS, and Linux, offers a dry run mode for previewing changes, and automatically detects the client version so it applies only the patches that specific build needs.

The three recorded components, per the README: login redirection replaces the internal address .actual.battle.net with .localhost so the game looks for a login portal on the local network; identity verification swaps the 256 byte RSA key that authenticates the client's Certificate Bundle for a custom one, letting the client trust certificates you provide for your server; and for older clients from the 1.13.2 era, the patcher additionally rewrites the URL used to download certificates at startup. Default output names the patched executable to help Blizzard filter community server traffic out of automated client telemetry, per the project's own FAQ.

Per the README, build numbers in that table are the values the client reports at its login screen, catalogued by the Warcraft Wiki community. A separate runtime launch command in the repository documentation selects its strategy from the client's file version: retail 12.x and later use a newer strategy with verified Windows x64 recipes for retail 12.0.7.68887 and 12.1.0.69587, while older lines keep the existing runtime strategy, and builds with unverified recipes are rejected before a process starts. Per that documentation, executable and loader SHA 256 hashes must match a recorded recipe before launch, and the legacy certificate mode flag is rejected on 1.13.x clients.

The requirements are narrow, per the README: the target server must present a valid TLS certificate that chains to a trusted root CA in your system trust store, and the portal setting in the client's WTF/Config.wtf file must use a hostname, not a bare IP address. TrinityCore compatible defaults ship with the patcher, and the acknowledgments credit Fabian from Arctium for the underlying knowledge along with the TrinityCore team.

Ownership, scope, and what is not in the repos

All three repositories build from source and distribute code, not game content. Per their READMEs, the decompiler reads metadata out of a client's own binaries, rilua is an independent implementation of a public scripting language spec, and wow-patcher operates on an executable you supply from your own installation. All three carry explicit not affiliated with Blizzard Entertainment footnotes.

The wow-patcher README makes the ownership condition explicit: you must own the client and expansions you want to play. That aligns these tools with how other reverse engineering repositories are evaluated, where the artifact under study is legally the user's. Nothing in any of the three READMEs asks readers to acquire game files, and the patcher's defaults assume a copy that arrived through retail channels on Linux, macOS, or Windows.

For a reader mapping the three jobs together: the decompiler tells emulation developers what Blizzard's servers and clients agreed to say to each other, rilua lets addon logic run without launching the game, and the patcher closes the loop by making an owned retail client trust a server the reader controls. Each tool stands alone, which is exactly why the toolkit reads as three projects rather than one.

Our take: The wowemulation-dev collection earns our attention because it is honest about its seams. Rather than one monolithic private server kit, it gives the protocol contract, the scripting runtime, and the client redirect as separate, buildable tools with stated limitations, and every limitation we checked is written down where we could find it. We would rather cover a toolchain that documents its boundary build by build than one that claims compatibility it cannot verify. Anyone using this stack should treat the ownership requirement as a floor, not a suggestion.

FAQ

Do these tools require an original World of Warcraft client?
Yes. The wow-patcher README states you must own the client and expansions you want to play, and the decompiler operates on binary files from a client you provide. None of the three repositories distributes game content or client assets.

Why does protobuf-decompiler stop at client build 70032?
Per the README, Blizzard upgraded the protobuf runtime compiled into clients from a 2.6.1 fork to a 6.30.1 fork with editions support, the first such upgrade in over a decade. The older descriptor handling silently discards edition era fields, so newer builds cannot be reconstructed faithfully.

How can you tell which protobuf version a client binary embeds?
The README states binaries embed a version string written exactly as blizzard_protobuf.version, and it tags builds up to 69933 as protobuf_blz-2.6.1.13 and build 70032 onward as protobuf_blz-6.30.1.

Is rilua compatible with real WoW addon code?
Per its README, rilua targets the exact Lua 5.1.1 dialect WoW addons use, implements all nine standard libraries and 38 reference opcodes, and passes all 23 official Lua 5.1.1 test files. Binary chunks produced by its compiler load in the PUC-Rio interpreter and vice versa.

Does wow-patcher modify the game in memory?
Per its README, the patcher modifies files on disk only, with a dry run mode for previewing changes. The separate runtime launch command scans a suspended process at startup but leaves the executable on disk unchanged, per the repository documentation.

What licenses cover the three tools?
protobuf-decompiler is MIT licensed. rilua and wow-patcher are each dual licensed under Apache 2.0 or MIT, at the user's option, per their READMEs.

Bottom Line

wowemulation-dev's three tools divide WoW emulation into protocol, runtime, and connection, and each one documents its own limits: the decompiler ends at client build 70032 because Blizzard finally changed its embedded protobuf, rilua passes the full official Lua 5.1.1 test suite while running about 1.7 times slower than the reference, and the patcher reaches verified client lines from 1.13.x through retail 12.x recipes. Expect to bring your own legally installed client, build from source, and read all three READMEs because the docs do not assume crossover knowledge.

Sources

Per the protobuf-decompiler repository README, the entry describes supported WoW versions and the protobuf version support boundary.

Per the rilua repository README, the entry describes the Rust Lua 5.1.1 implementation, its standard libraries, and testing.

Per the wow-patcher repository README, the entry describes client redirection, supported builds, and ownership requirements.