# mgs_reversing: Metal Gear Solid Integral rebuilt from decompiled C

> mgs_reversing is a reverse engineering project that reconstructs the PlayStation executables of Metal Gear Solid Integral as C source code, with the stated goal that recompiling them produces the same assembly. The main executables are finished; the per stage overlays that the game loads dynamically are the remaining work.

**FoxdieTeam/mgs_reversing** — Metal Gear Solid PSX reimpl repo

- Repository: https://github.com/FoxdieTeam/mgs_reversing
- Stars: 822 · Forks: 68
- Language: C
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/foxdieteam-mgs-reversing

## Matching assembly, not resembling behaviour

The README states the aim in one sentence, and the sentence is what makes the project interesting.

The goal is to completely reverse engineer Metal Gear Solid Integral for PlayStation back to C source code which, when compiled, produces the same assembly code.

That is a much harder and much more useful criterion than getting something that runs. Most reimplementations aim for equivalent behaviour, which leaves the original binary as the only oracle and the new build as an approximation. A project that aims to reproduce the assembly byte for byte has a checkable definition of done: compile the reconstructed C with the original toolchain settings and compare the result with the original executable.

The success criterion also changes what the work looks like. The output is not a tidy modern codebase, it is code that the original compiler accepted, which means the reconstructed functions often look strange, because that is what the original code looked like. The README acknowledges this in the remaining work list, where cleaning up the decompiled code is described as a goal in its own right, separate from finishing the decompilation.

The repository is under the FoxdieTeam organisation, the primary language is C, and the last push was on 2026-10-19, so this is an active project rather than an abandoned one.

## The three main executables are complete

The main executable work is finished, and the README tracks it with checksums and sizes.

The executables SLPM_862.47 and SLPM_862.48 are listed as 100 percent decompiled, at 626 KB, with a SHA256 digest given in the table. The next goals for that artefact are stated as cleaning up the decompiled code, finding cleaner matches and making it shiftable.

SLPM_862.49 is also 100 percent decompiled, at 616 KB, with its own digest. The README explains its relationship to the earlier one: it is based on SLPM_862.47 but with many small changes, especially around the Snake actor, where a variant is used.

Three details in that table are worth noticing.

The checksums are the verification mechanism. Anyone who compiles the reconstructed source can hash the output and compare it against the published digest, which is the concrete form of the project's success criterion.

The sizes are modest for a PlayStation title, which is consistent with the architecture: the main executable holds the engine and the actors that appear throughout the stages, and the bulk of the content lives elsewhere.

And the mention of shiftability points at the endgame of a decompilation project. Once the code matches, the next step is usually to make it compile for a modern target so it can run on hardware that does not exist any more, and that is a different and largely mechanical kind of work.

## Overlays are the remaining work

The README is explicit that decompiling the main executables, while a substantial milestone, leaves a significant amount of work, and that work is the overlays.

Metal Gear Solid Integral dynamically loads additional per-stage executable code required to play a particular stage. The main executable contains the game engine and the most common actors used throughout the stages, and everything else arrives as an overlay when a stage starts.

The overlay table lists them by internal name, with size, a description and a status. The names are the stage identifiers from the original code, and the descriptions make the content obvious: abst is the abstract save and load menu at 46 KB and is done, brf is the briefing at 125 KB and is in progress, camera is the JPEG photo menu at 54 KB and is in progress, change is disc change at 12 KB and is done, d00a is the loading dock cutscene and is done, d01a the heliport cutscene and is done, and so on through the sequence of stage codes and the red variants of the endings and the supply route.

Counting the table, the cutscene and menu overlays are largely finished while the gameplay stage overlays are the ones still in progress. The ranking screen, the briefing, the photo menu and the supply route are named as work in progress in the rows shown.

The second half of the remaining work is stated as making it possible to boot into every game level and cleaning up already decompiled code. Those are different kinds of work: the first is coverage, the second is quality.

## The build and the repository layout

Each artefact has a documented build command, and both main executables are driven by a Python script at the root of the repository.

The standard build is a single command, python build.py, and the VR variant executable adds a variant argument, python build.py with the variant set to vr_exe. The consistency of that interface suggests the script knows which sources belong to which executable, which is what you would expect from a project that maintains three related builds from one source tree.

The repository layout is small and tells you what the project is. The source directory holds the reconstructed C, the asm directory holds assembly, which is the reference material and the comparison target, the build directory is where output goes, and the um directory is present as a separate area whose contents the README does not describe.

The tooling around it is what you would expect from a team that cares about matching. There is a .clang-format configuration and a clang-format-all script, so the reconstructed C is formatted consistently, and there is an .editorconfig. The appveyor configuration points at Windows continuous integration, which is the right platform choice for a toolchain that has to reproduce a PlayStation era build. And there is a .git-blame-ignore-revs file, which is the mechanism for telling Git to ignore specific commits when they rewrite history, the standard practice in decompilation projects where the history is repeatedly reshaped as matches improve.

That last file is a small but telling detail. It says the project treats its commit history as a working artefact rather than a record.

## Licence, limits and the state of the work

Two things are conspicuously absent from the README, and both matter for anyone considering using this repository.

The first is a licence. The repository listing does not classify one, and the README does not state the terms. That is unsurprising given the subject, since the original game is copyrighted and a derived work carries questions that the project does not answer. It does mean that if you are looking for code you can reuse in your own project, the answer here is that you need to ask rather than assume, and the licence question should be settled before you read the source as a reference.

The second is a playable game. What the repository produces is reconstructed executables, and to do anything with them you need the original game, which means the data discs. There is no asset pipeline, no cutscene viewer, no emulator bundled, and no release artefacts, since the repository has no GitHub releases either.

So the honest framing is that this is a preservation and research project. Its output is a source tree that matches a 1998 binary, plus the tooling to verify that claim, and its value to most readers is as an example of how a serious decompilation project is run and documented rather than as a thing you can install.

The state of the work, as of the last push on 2026-10-19, is that the three main executables are complete and the overlays are partially complete, with the gameplay stage overlays still to be finished.

## Conclusion

mgs_reversing is the project to follow if you care about game preservation or about decompilation as a discipline, because it states its success criterion precisely, matching assembly rather than resembling behaviour, and it publishes the checksums that let anyone verify that claim. It is the wrong thing to expect a playable game from, since the repository ships reconstructed executables rather than assets, and it is the wrong dependency for anything commercial, since the licence is not stated and the underlying game is copyrighted. Verify first which of the three main executable revisions you need and that the overlay you care about has reached the decompiled state, then rebuild with the documented build script and compare the output against the published checksum before assuming a change is correct.

## FAQ

### What is mgs_reversing?

It is a reverse engineering project that reconstructs the PlayStation executables of Metal Gear Solid Integral as C source code, with the stated goal that recompiling that source produces the same assembly code as the original binaries.

### How far along is the decompilation?

The README states that the SLPM_862.47, SLPM_862.48 and SLPM_862.49 main executables are 100 percent decompiled, while the per stage overlays remain work in progress, and that the remaining goals are booting into every game level and cleaning up the already decompiled code.

### What are overlays in this context?

They are the additional per-stage executable modules the game dynamically loads to play a particular stage. The main executable holds the game engine and the most common actors, and everything else arrives as an overlay.

### How do you build the reconstructed executables?

The README lists a Python build script at the repository root for the main executable, with a variant argument used for the VR variant executable, and each artefact is listed with its size and SHA256 digest so a rebuilt output can be checked against the original.

## Sources

- [FoxdieTeam/mgs_reversing on GitHub](https://github.com/FoxdieTeam/mgs_reversing)
- [Issues](https://github.com/FoxdieTeam/mgs_reversing/issues)
- [README](https://github.com/FoxdieTeam/mgs_reversing/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/foxdieteam-mgs-reversing