Deimos-Public: the Marathon tool that treats leaks like a bug

A binary-first archive for artists and archivists, built to surface unreleased game data without normalizing spoilers, panic, or copycat leak culture.

7 min read · cohaereo/Deimos-Public

A stark archive room shows a locked cabinet of game files sitting alone in a white space. One drawer is open just enough to suggest models, textures, and metadata, while a hand holds a square rubber stamp at the edge of the frame. The image explains the project’s central tension: it is built for access, but it insists that access still has boundaries.
Deimos is framed like a vault you can open, but not one you are allowed to loot.
Key Takeaways

At cohaereo/Deimos-Public, the public surface is the point. Deimos promises a way into Marathon's internal assets, then immediately narrows the moral frame around that access. It is a tool for artists and archivists that treats leak culture as a failure mode, not a feature.

The tool that opens the vault and posts a warning

That contradiction is why Deimos-Public stands out. Most extraction tools are judged on how much they can dump. Deimos is judged on whether it can expose enough to be useful without becoming a shortcut for spoilers.

Don't expect everything to work yet Deimos - The Marathon tool that does everything [!CAUTION] 👁 For your eyes only Please keep in mind that this tool is meant for artists and archival purposes only.

Project README, Repository documentation · cohaereo/Deimos-Public README

The README is not decorative. It is the product's first UX layer, and it tells the reader that the tool is meant for archival work, not for content sniping.

A WSJ-style hedcut portrait of the GitHub maintainer behind Deimos-Public, based on the public avatar. The portrait is a reminder that the public repo has a visible human author even though the release surface is larger than the source tree.

What Deimos-Public actually is

This repository does not behave like a conventional open-source codebase. The public tree is a release hub and documentation layer, while the useful bits live in compiled downloads and assets. That structure changes how you read the project: the README, the release artifacts, and the policy language are doing the work of a product page.

That matters because the maintainer is not pretending the project is neutral. The binary-first distribution and the warning language are both part of the same design choice: make the tool usable, but keep the public contract visible.

The anti-leak contract

Using Deimos to leak content will reduce the likelihood of future public releases, and I may stop its development altogether at any time if misuse continues.

Project README, Repository documentation · cohaereo/Deimos-Public README

The strongest policy language is blunt enough to be actionable. Deimos does not frame misuse as an abstract community concern. It names the consequence.

That is more than a moral stance. It is a product constraint. When a tool is built around a fragile release cadence, the social layer becomes part of the architecture.

How the pipeline turns a black box into something readable

The real trick is not just unpacking data. It is pairing access with a visible boundary around what that access is for.

The likely pipeline is straightforward in concept, even if the implementation is not public: a proprietary package gets parsed, unpacked, normalized, previewed, and exported. The important twist is that the policy gate rides alongside the data path, so the system can support archival use without pretending downstream behavior is someone else's problem.

A close-up workbench shows a jagged proprietary file being fed into a machine that splits it into cleaner asset streams. One stream becomes a mesh shape, one becomes a texture sheet, and one becomes a metadata stack, while a hinged side gate stays shut over a darker branch. The image explains that Deimos is a translator, not just a dump button.
The useful move is translation, from a hostile container into something humans can inspect.

That is the useful mental model. Deimos is not just an extractor. It is a translator that turns a hostile container into readable assets, then draws a line around what that readability is for.

Why this is different from ordinary extractors

Tool typePrimary goalWhat it exposesPolicy postureBest fit
Deimos-PublicInspect and archive Marathon assetsParsed packages, previews, and exports, plus a visible warning boundaryMakes misuse explicit and threatens to pull back if the community abuses itArtists, archivists, and careful reverse engineers
Ordinary game asset extractorsGet raw files out of a packageWhatever the format can be unpacked intoUsually neutral or silent on downstream useModders who want breadth more than curation
Pure archive viewers or browsersLet people browse without changing muchMetadata and previews, sometimes not full exportsLower risk, but also less powerResearchers who need inspection, not full extraction
A split composition shows two ways of handling the same game assets. The left side dumps raw shapes, tiles, and documents into a tangled heap, while the right side arranges the same materials into neat archival trays beside a closed gate. The image explains the difference between brute-force extraction and curated preservation.
The real contrast is not feature count. It is whether the tool treats boundaries as part of the job.

Most tools in this category optimize for raw access. Deimos optimizes for access plus framing. That makes it less like a bulk dumping utility and more like a curated interface for preservation work.

What this repo says about preservation work in messy places

Preservation is rarely clean. The people building the tools often have to navigate spoilers, fandom pressure, and the fact that every capability can be pointed in the wrong direction. Deimos-Public is interesting because it makes that tension explicit instead of hiding behind generic open-source language.