benilla-re: 37,967 Function Rows Cover WoW 1.12.1.5875
By Indie Kings | October 17, 2026
Updated October 17, 2026: benilla-re is a public reverse engineering of the World of Warcraft 1.12.1 client, the exe from the 2006 vanilla release, read at its bytes and cited by address. Per the official repository README, everything ships as plain files that need no WoW install, so anyone building a client, a server, a mod or a format reader starts from the same documented ground.
Image: benilla-re repository card. Credit: GitHub, samwhosung.
What benilla-re is
Per the official repository README, benilla-re is the reverse engineering of the World of Warcraft 1.12.1 client, meaning the original exe of that build, which the README identifies as build 5875. The work is done at the byte level: each claim about what the program does is tied to an address in that exe, and each address has a name, a signature, and a one line meaning. The README describes the result as the reference behind benilla, a from scratch 1.12.1 client in Rust, and says it is written for anyone else who needs to know what the client does: another client, a server, a client mod, a format reader.
The unit of work is unusual for a game client. A symbol row in the table covers one function, global, struct or field, and per README it carries the name, the owning system, the signature, what the thing means, how sure the project is about that, and the specific finding inside the repository that derives the name from the bytes. Per README, a census tool walks the section of the exe that holds program code and puts a row in the table for every function start it finds, so the coverage is complete rather than cherry picked.
The target is old on purpose. Version 1.12.1 build 5875 is the final client of vanilla World of Warcraft, released in 2006. Blizzard Entertainment has since replaced it many times over, but that binary is the one the private server ecosystem, the addon tooling and the era faithful projects still treat as the base of what they rebuild. A byte level map of it, published and cited, is the kind of artifact that field has been assembling in fragments for years.
The address site
The README points to a browsing site, built from the same symbol data and deployed to GitHub Pages, described in prose here without a link. It holds one page per function, global and struct, one per system, and one per Lua function, event, CVar and opcode, with a search box over names and addresses. The README gives the addressing convention plainly: append the mark `?0x5e6853` to the site to jump to whatever row holds that address, whether it is a function start, an instruction inside a function, or a byte inside a global's extent. Every page URL is built from the address alone, so a claim in the docs can link itself straight to the location that decides it.
Per README, an address page shows the row's name, signature or type, its meaning, its confidence and its proof, the claim of the finding it links to, plus its callers, callees and test. A system page carries the system's docs, its coverage counts and its rows. The README says the site is plain HTML with one stylesheet and one script, reads on a phone and in a dark theme, and is rebuilt by a workflow that runs on every push, so the site and the symbol table never drift apart.
Bring your own client: what the exe is needed for
The README's licensing and legal posture starts with one line: "Bring your own client. Nothing here comes from a WoW install." The symbol table, the documentation, the tables, the site and the export files are all plain files. Nothing in the repository ships game data or a copy of the game binary, so the project itself is documentation and tooling only.
Only three parts read the actual game exe, and per README they read it from `WoW/WoW.exe` in your own copy of 1.12.1.5875: the tests, the table generators, and the instruction listing. Those parts refuse any other build, since every address in the data is keyed to that one binary. A copy of the client obtained legally is therefore required only if you want to run the checks or regenerate the tables yourself; reading the documentation, searching the site and using the exports needs no WoW install at all.
Per README, the whole repository is dual licensed under MIT or Apache 2.0 at your option, covering the code, the symbol table, the docs and the tables. One dependency sits outside that: the test only use of a Unicorn emulator binding carries its GPL 2.0 terms, per README, and applies to the tests rather than to the reference data itself.
Who it is written for, and what each of them gets
The README's "Start here" section is a routing list by audience, and per README each entry names the artifacts built for that use. The breadth is the point: the same byte level ground is meant to answer questions from five different directions at once.
| You are building | Per README, you start from | What it holds |
|---|---|---|
| A patch, dll, loader or fix inside the client | The export bundle and the address site | A C header of every struct at its real layout plus typed function pointers, symbol files to grep, and databases that import the names |
| A session in Ghidra, IDA, Binary Ninja or x64dbg | The same export | An import for each tool that applies the names and types while keeping names your database already has |
| A server or an emulator | The opcode tables and the network, object layer, spell and movement docs | Handler coverage, what the client reads from each message, and what it checks before sending one |
| 1.12 addons | The Lua, event and CVar tables | Every Lua function with its argument count, every event with where it fires, every CVar with default and help text |
| A format reader | The model, terrain, database and archive system docs | What the client itself reads from the M2, WMO, ADT, DBC and MPQ families, and the record layouts |
| Another client entirely | The systems index and the Rust crates | Per mechanism docs for each system, and reimplementations of the client's computations |
Two boundaries keep the ambitions honest. Per README, slash commands and most of what the player sees the interface do are written in the interface code shipped inside the game install, not the exe, so a question about those starts there and comes to the reference for the engine side: the Lua function, the opcode it sends, the event it fires. And the README separates what the client itself reads from what it computes, with each audience getting the part it needs rather than a merged file.
How every claim is graded
Per README, the method document states the ground rule: the binary decides, every claim states its confidence and proof, and a contradiction is settled at the bytes rather than at authority. Each symbol row is marked either verified at the bytes or inferred, and a verified claim carries further grading: one independent reading of the bytes, two independent readings reconciled, or a test that runs the exe's own code against the reimplementation in an emulator and compares the results bit for bit. A check command in the repository holds the data to those rules, per README, and with the exe present it also verifies function sizes against the listing, every table against its generator, and every test a row names.
The tables are regenerated rather than hand written. Per README, each table is rebuilt from your exe by a generator in the tools directory, which is why those generators are among the parts that need your legally obtained copy of the client. The committed tables are the reference record, and regenerating them against your own binary is a verification step, not a requirement.
The most explicit honesty marker is in the README's own numbers for matching the names onto other builds, shown in the next section. The project counts what it cannot distinguish rather than hiding it: on the reference build, per README, more than twenty three thousand of thirty seven thousand rows are marked as indistinguishable by their bytes, because thunks, static initializers and one line accessors look identical. A reference that admits its blind spots is the opposite of the usual scattered guess, and that admission is part of why the rest of its claims can be checked rather than trusted.
Mapping the names onto other builds
Every row is keyed to 1.12.1.5875, but per README a modified 1.12 client, versions 1.12.2 and 1.12.3, and builds from 1.6 to 1.11 keep most function bytes. A signature table therefore gives each function row a byte pattern with wildcards where the bytes depend on where the code sits, cut to the shortest length that occurs only once in the executable sections of the reference build. A matcher command reads any Windows executable, searches for those patterns, and writes out where each named function was found, why that placement is trusted, and what could not be placed.
Per README, the matcher scores its own placements in three grades: pattern, meaning the function's own bytes were unique and found once; call, meaning a found function's call goes there and the bytes agree; and order, meaning the row's position is bounded by already placed neighbours. Weaker grades are explicitly called leads to check rather than proof. On the reference build itself the README reports the following step by step totals.
| Matching step on build 5875 | Functions found | New at this step | Left ambiguous | At a wrong address |
|---|---|---|---|---|
| Byte patterns | 14,383 | 14,383 | 23,584 | 0 |
| Following call targets | 17,254 | 2,871 | 20,713 | 0 |
| Address order between placed neighbours | 21,243 | 3,989 | 16,724 | 0 |
Per README, nine synthetic builds of the reference binary test the matcher: bytes shifted by an odd amount, with odd padding, with neighbour pairs swapped, with functions duplicated, with calls redirected into the middle of a function, with thunk calls swapped, with functions deleted, and with new function prologues. Across all nine, the README reports zero placements at a wrong address, with conflicts and remaining ambiguity varying by case. The README is explicit about the limit: these are synthetic builds, changed the way a compiler would not, and no real second build has been run through the matcher yet.
Where it sits among the client projects
The repository positioning is stated in its first paragraph: benilla-re is the reference behind benilla, the from scratch 1.12.1 client in Rust. This site covered benilla when that client's own README claimed the full game on a stock 1.12 interface with addons, reading data only from a player supplied legal install. The reference underneath is what makes such a clean room claim checkable: the crates in the reference repository reimplement the client's computations and are tested in an emulator against the exe's own code, per README, so behavior is verified rather than assumed.
Downstream, this site also covered Vanilla VR, the full body VR client for the 1.12 game, which is built on benilla and inherits that verified path. The chain runs from the bytes of a 2006 binary, through a documented map of those bytes, to two independently built clients that play on era faithful ground.
Per README, contributions are structured the same way as the data: names, findings, corrections and checks are welcome, a gap or a wrong finding needs no exe to report, and community contributed names from a disassembly database carry a marker in each row so provenance stays visible. Community names are the ecosystem's shared prior; the byte level grading decides how far each one is trusted.
Our take
In our view, the interesting claim of benilla-re is not coverage but reproducibility. Private World of Warcraft client research has circulated for two decades as forum lore: a name, a hex offset pasted out of context, a guess that was never re checked. Publishing symbol data where every entry names its own evidence, and grading those entries so a reader knows exactly which ones were verified at the bytes, turns that lore into something a second person can audit. The honest line the README draws about matches, that the matcher's weaker grades are leads rather than proof, and that no real second build has been tested yet, is exactly the posture that makes the rest of the work credible. Our opinion: for anyone working on 1.12 code, this map is a public good, and the field would benefit from more references written this way.
FAQ
What exactly is benilla-re?
Per the official repository README, it is the reverse engineering of the World of Warcraft 1.12.1 client, meaning the exe of build 5875, read at its bytes and cited by address, published as the reference behind the benilla Rust client and open to everyone else in the ecosystem.
Do I need a World of Warcraft install to use it?
No for most of it. Per README, the symbol table, docs, tables, site and exports are plain files that need no exe; only the tests, the table generators and the listing read your own copy of 1.12.1.5875, and they refuse any other build.
Does the repository ship any game data or binaries?
No. Per README and per the scope of the project, nothing comes from a WoW install, and the repository contains documentation, symbol data and tooling only. You need your own legally obtained 1.12.1 client if you want to run the checks or regenerate the tables yourself.
Who is the reference written for?
Per README, five audiences: anyone patching or injecting into the client, anyone reversing it in the usual disassembly tools, anyone writing a server or emulator, addon writers, file format readers, and anyone building another client entirely.
How reliable is the data?
Each row is graded: verified claims rest on one or two independent byte readings or a bit for bit test against the exe's own code, while inferred rows are leads. Per README, more than 23,000 of 37,967 function rows are openly marked as indistinguishable by bytes on the reference build, so the limits are counted, not hidden.
Is this related to Blizzard Entertainment?
It is about Blizzard Entertainment's 2006 client, but it is an independent reference project, per README, and it ships none of the company's data or binaries.
Bottom Line
benilla-re documents a 2006 game client the way a threat research team documents a binary: every function named, every address cited, every claim graded by the evidence behind it, per the repository README. Nothing from a World of Warcraft install ships with it, so the reference stays clean legally, and the parts that touch the binary use your own legally obtained copy of 1.12.1.5875. For client reversers, server writers, addon authors and format readers working on the 1.12 era, one published map now serves them all, and the reference behind benilla is already proving the model by feeding a from scratch client and, downstream, a VR client built on it.
Sources
Per the official benilla-re repository README for all feature, scope, license and matching claims above. Repository: benilla-re README. Standing: per README.