REDIVIVUS

Diablo II: Lord of Destruction · 1.14d · Game.exe

Diablo II 1.14d, recovered as C++ source that builds.

Not a reimplementation that behaves like the game. The shipped executable, taken apart function by function, regenerated as C++, and compiled into a working d2.exe again.

Source on GitHub Discord

As of 57380e2. Recompiled with Visual C++ 2005 SP1, the compiler that built 1.14d, and compared function by function; see the README.

The original game code split by how closely the rebuild matches it: whole functions identical, identical instructions, same instruction with other operands, different, tables and padding, not compared
Every byte of the original game code, by how closely the recompiled code matches it. What each kind of match means

The tree is compiled with Visual C++ 2005 SP1, the compiler that built 1.14d, and each function’s machine code is compared with the same function in the shipped Game.exe, with addresses compared by what they name. A function counts as identical only when every byte matches. Small functions match far more often than large ones, so the share by count is higher than the share by size. The instructions figure also counts instructions that already match inside functions that still differ elsewhere; as a control, pairing each function with a wrong one from the same source file scores about 7%, so the matching instructions come from the reconstruction, not from boilerplate. The C runtime and compiler-generated exception code are left out. Details in BYTE-MATCHING.md

01What it is

The whole game. Patch 1.14 linked the client, the game server, D2Common, Storm, Fog and the rest into one Game.exe; that executable is what is recovered here, with the old module names as its directories.

Builds
Every translation unit compiles with strict C++17, no -fpermissive. Links with no undefined symbol.
Runs
Menus, character creation and single player: walk, fight, change areas.
Reconstructed
Names, types and structure are reconstructions, recovered by reverse-engineering. Some functions read like a decompiler wrote them, because one did.
Not finished
Some areas still crash, and Battle.net does not work yet. Known issues

The same idea as Devilution, and how it was made →

02How it works

  1. Ghidra1.14d Windows and Mac. Every function named, typed and given a calling convention.
  2. ghidra-reconstructDecompiles via ghidra-mcp, parses to a C++ syntax tree, undoes decompiler artifacts.
  3. Source treeC++17, one directory per module: D2Client, D2Game, D2Common, Storm, Fog…
  4. d2.exemingw-w64, CMake, Ninja. Run it next to your own 1.14 install.

Every crash is traced to its cause and fixed where it belongs: usually in the Ghidra database, sometimes in the generator, rarely by hand.

Build

cmake -S . -B build -G Ninja \
  -DCMAKE_TOOLCHAIN_FILE=cmake/mingw-i686.cmake
cmake --build build

Needs i686-w64-mingw32-g++, CMake and Ninja.

Run

d2.exe -w

From your own Diablo II: LoD 1.14 folder, next to Game.exe. The repository holds no game data.

Building and running · Build with the original compilers →

03Read the databases with your agent

The Ghidra databases behind the tree are open to read for any AI agent, through a read-only MCP server. Give your agent one line:

Fetch and execute the instructions from https://redivivus.app/agent-setup/prompt.md
  • Serverhttps://ghidra.redivivus.app/mcp, sign-in with GitHub
  • Programswin (1.14d Game.exe, ground truth) and mac
  • AgentsClaude Code, Codex, Cursor, Copilot and anything that speaks MCP. Per-agent setup

04Contribute via proposals

  1. ProposeYour agent submits a name, type or prototype with evidence. It is checked live against the databases.
  2. ReviewThe maintainer approves or rejects it, with a comment.
  3. AppliedIt lands in Ghidra and the regenerated tree, committed with you as the git author.

How proposals work · all proposals → · Code fixes as pull requests, crashes as issues with the crash report.