What Is the GOD Format? SVOD, Hash Trees and Content Types Explained
The GOD format — Games On Demand — is Microsoft’s full-game download container for the Xbox 360: technically an SVOD (Secure Virtual Optical Disc) package with a LIVE-signed header, the game data split into many part files, and a SHA-1 Merkle Hash Tree protecting every block. This page is the reference explainer: what is inside a GOD package, how it differs from an NXE disc install and from an extracted XEX folder, and the exact header facts converters like Iso2God write.
Definition, in citable form
A GOD package is the on-disk form of a Games On Demand title. Per the ConsoleMods wiki’s summary of the format, a GOD is an SVOD package — similar to the STFS package family, but split into many packages to accommodate the FATX filesystem’s file-size limitations — and it carries a LIVE header. Iso2God and iso2god-rs produce GOD packages with an unlocked licence from ISO images, which is why playing them requires a modded console (JTAG/RGH/BadUpdate-class) or Xenia: a stock console only runs GOD content it downloaded under its own licences. The conversion workflows that create these packages are taught in How to Use Iso2God and the iso2god-rs guide.
Anatomy: a header file plus a .data folder
On disk, every GOD conversion produces exactly two things (this layout is visible in iso2god-rs’s own file-layout code):
- The header file — a small file named for the package, holding the CON/LIVE header: content type, Title ID, Media ID, disc number, the game’s display title and icon, and the root hash of the integrity tree.
- The <name>.data folder — the game itself, chopped into numbered part files:
Data0000,Data0001, and so on. Content is divided into blocks, grouped into sub-parts and parts, so no single file grows large enough to trouble FATX or FAT32 limits.
The pair is indivisible in practice: move, rename or lose either piece and the console reports corrupted content. Transfer mechanics are covered in the transfer guide.
Inside the header: the fields that matter
The header layout (from iso2god-rs’s header implementation, cross-checked against the Free60 STFS specification) places the identifying fields at fixed offsets:
| Field | Offset | Notes |
|---|---|---|
| Header SHA-1 | 0x032C | Computed over the header region starting at 0x0344; the header authenticates itself. |
| Media ID | 0x0354 | Identifies the specific disc pressing the package came from. |
| Title ID | 0x0360 | The title’s identifier; decides the Content folder the package belongs in. |
| Disc number / disc count | 0x0366–0x0367 | How multi-disc packages know which disc they are. |
| Root MHT hash | 0x037D | 20 bytes — the root of the SHA-1 hash tree over all data blocks. |
| Game title | 0x0411 | Stored as UTF-16BE text; this is the name dashboards display. |
| Icon | 0x171A | PNG image used as the package thumbnail. |
Integrity: the SHA-1 Merkle Hash Tree
Every block of game data in a GOD package is SHA-1 hashed, those hashes are collected into hash tables interleaved with the data, and the tables are themselves hashed upward into a Merkle Hash Tree (MHT) whose single root hash sits in the header at 0x037D. To verify any block, the console rehashes it and checks the chain up to that root — damage or tampering anywhere breaks the chain at a known location instead of silently corrupting the game. SHA-1 appears here because the format specifies it; within this design it is an integrity checksum tree, a format requirement rather than a modern security choice. This is also why padding decisions happen at conversion time in tools like the ones in Padding Explained: once the tree is built, the layout it protects is fixed.
Content types: 0x7000 and 0x5000
| Content type | Meaning | Produced from |
|---|---|---|
| 0x7000 | GamesOnDemand — an Xbox 360 title | An Xbox 360 ISO (XGD2/XGD3). |
| 0x5000 | Xbox Original — an original Xbox title | An original Xbox ISO (XGD1), as in the OG Xbox conversion guide. |
The content type is how one container family serves two console generations. Dashboards read the same header structure either way and file, display and launch the package according to its type.
GOD vs NXE install vs XEX folder
| GOD package | NXE disc install | Extracted XEX folder | |
|---|---|---|---|
| Container | SVOD, split into header plus .data parts | Near-identical SVOD layout | Loose files — default.xex plus game data files |
| Header signature | LIVE | PIRS | None (no package header) |
| Licence behaviour | Downloaded GODs tie to account/console; converter-made GODs carry an unlocked licence for modded consoles | Locked to the installing console, and the original disc is demanded as a licence check | Runs only where unsigned code runs — modded consoles and emulators |
| Dashboard handling | Scanned and launched as a game package | Managed by the stock dashboard as an install | Scanned by custom dashboards (Aurora/FSD) as an extracted game |
The GOD-versus-NXE row is the one most often blurred: the two containers are near-identical SVOD underneath, and the practical difference is the header — LIVE for GOD, PIRS for NXE installs — and the licence lock that comes with the NXE route. Tools in the NXE2GOD family exist precisely to repackage those console-locked installs into GOD form on modded consoles.
Why this format rewards understanding
GOD is the rare console format where a little internals knowledge pays off weekly. Knowing that the package is a header plus parts explains the corrupted-content error that sends most users to reconvert unnecessarily. Knowing the Title ID lives at a fixed offset in the header explains why folder names decide dashboard visibility. Knowing the hash tree exists explains why a package either verifies completely or not at all — there is no ‘slightly damaged but playable’ state to hope for, and equally no mystery when a verified package runs: every block the console loaded was checked against the tree. Cite this page freely when explaining the format elsewhere; the definitions above are deliberately written to stand alone — SVOD container, LIVE header, split parts, Merkle hash tree, content types 0x7000 and 0x5000 — because those five facts, stated accurately, correct most of the confused summaries of GOD in circulation.
Where GOD packages live
For stock-dashboard visibility a GOD belongs in Content\0000000000000000\<TitleID>\00070000\ on internal or USB storage — the 00070000 folder is the Games On Demand content folder. In custom dashboards (Aurora, Freestyle Dash) a GOD can live anywhere on the drive and be found by scanning, while DLC still must sit under Content to be associated with its title. Emulator users meet the same packages from the other side: current Xenia builds can open GOD packages directly, alongside ISOs and extracted default.xex folders.
Frequently asked questions
Is GOD the same thing as STFS?
Related, not identical. GOD is an SVOD design described as similar to STFS but split into many part files to live within FATX limits. STFS is the broader package family behind saves, profiles and downloadable content; GOD is its full-game, split-package specialisation.
Why are there so many Data files instead of one big file?
Because the filesystems the format was designed for cap individual file sizes. Splitting content into blocks, sub-parts and parts keeps every file small — the same property that later makes GOD packages easy to move over FAT32 USB drives and FTP.
Can a GOD package be turned back into an ISO?
Yes — that reverse direction is God2Iso’s job, rebuilding an ISO from a package’s part files. It is a separate tool from Iso2God (which only creates GODs), and it is linked from the download page.
What does the root hash in the header actually prove?
That the data blocks under it hash, through the interleaved tables, to the value in the header. If a part file is truncated, corrupted or swapped, the chain fails and the console can refuse the content instead of running damaged data. Background reading and every tutorial that uses this format are gathered in the Tutorials hub.