Rebuilding the 2014 Mac League of Legends client

This project recreates the source code of League of Legends version 4.17, the 32-bit Mac client from 2014, so that the game can be compiled again from source. The original program is the reference: each rebuilt function is compiled and compared, instruction by instruction, with the same function in the original.

—of the game's code has been rebuilt so that it compiles to exactly the same machine code as the original.

The game's code, by share of size

Last measured 2026-10-19 06:45 UTC. A match means the compiled code is identical to the original; it does not mean the rebuilt game has been run or is playable, which is not measured here. Shares are rounded down.

Loading the function inventory…

Measurement definitions

What the words mean

Matches exactly: The rebuilt function compiles to the same machine instructions as the original, and refers to the same things (technical term: instruction-exact). This is the headline progress number.
Matches and fully proven: Matches exactly, and four further checks pass: the data it reaches, every reference it makes, its error-handling records and the private helpers it owns are all shown to match the original (technical term: four-component verification). The current milestone is 100% of Game/ matching and fully proven.
Proven assuming in-bounds indexes: Matches exactly, and the four checks pass only if one assumption holds: that the original program's array and table indexes stay inside their arrays, where the original code itself does not show it. The original is known to read past some arrays, so this is shown as its own figure and is not counted as fully proven.
Still different: The function has been rebuilt and compared, but its compiled code is not identical yet. It is work in progress, not a defect in the original.
No verdict yet: Nothing to compare yet, or the comparison could not reach a result. Missing proof is not counted as a match.
Similarity: How close a non-matching function is, as a percentage of shared instructions. A diagnostic only: a high similarity never counts as a match.
Relinking: To produce a complete program, functions that are not rebuilt yet are borrowed from the original binary. Borrowed code earns no credit here.
Not measured: Whether the rebuilt program runs, its data layout, initialization order and runtime behavior are outside these measurements.

Technical details: measurements, backlog and function explorer

Current milestone

Game/

Reconstruct Game and its generated support to enable a client rebuild through relinking.

Fixed Game summary, checked against the embedded snapshot:

Game obligations: 33,209 / 33,537 instruction-exact functions; 7,059,816 / 7,422,856 bytes. Verified: 32,985 functions / 6,863,992 bytes. Verified assuming in-bounds indexes (separate, not verified): 152 functions / 99,520 bytes.

Progress by

A match requires a native comparison result; similarity never establishes a match. Full verification checks code and reached data, reference coverage, exception metadata (EH/LSDA) and private-helper ownership. Independent data, ABI/layout, compact-unwind integration, storage ownership, initialization and runtime behavior remain separate. Native instruction evidence: 41,278 / 67,377 current observations.

Game backlog and independent audits

All Game functions, including generated support. These totals do not follow the explorer filters. Observed differences need diagnosis; unknowns are missing proof, not demonstrated source defects.

Verification diagnostics (overlapping)

Each function is counted once per component and diagnostic. Examples open the bound function details. Repeated messages can have different underlying causes.

Component / result	Diagnostic	Functions / bytes	Examples

Independent data, ABI and initializer audits

Object owning Game functions	Compiled data roots: equal / different / unknown	Unclassified storage	Recorded ABI: equal / different / unknown	Initializer emission presence

Initializer presence does not prove actions, order or runtime behavior. Full root records, producer slots and evidence hashes are retained in the native verification JSON.

Linked code providers (static relink)

Which code the linked program currently takes from the reconstruction and which it borrows from the original binary, by reason.

Retaining original code keeps the relinked image complete; it does not earn reconstruction or verification credit. Original data and metadata are retained by the current code-only replacement class.

Explore every function

Search Min similarity (%) Min size (B) Group by