Xbox 360 Says Your GOD Content Is Corrupted: What to Check
When an Xbox 360 reports your GOD content as corrupted, it usually means one of three things: part of the package never arrived, the package’s built-in integrity check found data that does not match, or — the one nobody expects — the console is a stock machine refusing an unlocked package it was never going to accept. This guide separates those cases so you fix the right one.
If the game does not appear in the library at all, that is a placement problem, not corruption — start with our guide to a GOD game not showing on Xbox 360. Corruption is what you get when the console can see the package but will not trust or launch it.
How the console knows something is wrong: the hash tree, in plain language
A GOD package is not one big file. Inside the .data folder, the game is stored as many data blocks, and interleaved with them are hash tables: every block of data has a SHA-1 fingerprint recorded alongside it, those fingerprints are themselves fingerprinted into higher-level tables, and a single root hash sits in the package header. When the console loads the content, it can walk this tree — technically a Merkle Hash Tree — and check that the data still matches the fingerprints recorded when the package was built.
That design has a practical consequence for troubleshooting: the check is all-or-nothing about completeness. One missing or altered part file breaks the chain between the data and the root hash, and the console reports the whole package as corrupted even if 99% of the game is present and fine. “Corrupted” therefore usually means “incomplete or changed since conversion”, not “the game is ruined.”
Cause 1: An incomplete transfer (the most common one)
- Compare the package on the console with the package on your PC: the header file plus the
.datafolder, and inside it every Data part file, in sequence, with no gaps. - A copy interrupted by a USB dropout, a full drive, a sleeping PC or an FTP session that ended early typically loses parts at the end — or truncates one. File counts and total size should match the PC original.
- Delete the console copy and re-copy the complete package in one go, then test again before you change anything else.
- If the copy repeatedly arrives incomplete, change the route: a different USB device, a wired FTP transfer, or the internal drive instead of removable media.
Cause 2: Bad or failing USB media
Removable media that is starting to fail produces exactly this symptom: files that copy without an obvious error but do not read back the same. If one game after another goes “corrupted” on the same USB stick or external drive while the same packages work from the internal drive, believe the pattern and retire the media. The same applies to a PC-side drive that is failing: if the source package on your PC is itself incomplete, every copy of it will fail the hash check. In that case, reconvert from the original ISO — the conversion errors guide covers bad source images — rather than copying a broken package more carefully.
Cause 3: The package was changed after conversion
Because integrity is checked against fingerprints taken at build time, editing, trimming or “tidying” a package after conversion can break it. Do not rename the header file or the .data folder (they must keep matching names), do not move parts between packages, and do not mix discs’ part files in one folder. If you want a different padding setting, reconvert from the ISO with that setting — see the padding explained guide — instead of modifying a finished package.
Cause 4: It is a stock console refusing an unlocked package
This is the case that wastes the most weekends. Iso2God produces GOD packages with an unlocked licence, intended for modded consoles — JTAG, RGH or a BadUpdate-class exploit — or for Xenia emulation. A stock retail Xbox 360 only runs GOD content it downloaded itself, signed and licenced to that console and account. Presented with an unlocked package, a stock console rejecting or flagging it is behaving exactly as designed. No amount of re-copying changes that, because nothing is actually damaged. If your test console is unmodified, the honest fix is to test on the modded console the package was made for, or on PC in Xenia.
A repair order that works
| Step | Check | If it fails |
|---|---|---|
| 1 | Are all Data parts present, matching the PC copy? | Re-copy the complete package in one transfer |
| 2 | Does the same package work from a different drive or device? | Suspect the USB media or drive; replace it |
| 3 | Does a fresh conversion from the original ISO work? | Suspect the old package or the source ISO; reconvert |
| 4 | Is the console actually modded (JTAG/RGH/BadUpdate-class)? | On a stock console, refusal is expected behaviour, not corruption |
Frequently asked questions
Can a corrupted GOD package be repaired in place?
Usually you do not repair it — you replace it. Re-copy the complete package from your PC, or reconvert from the original ISO if the PC copy is also incomplete. The hash tree means a package is either whole and matching, or it is not trusted.
Why does the console say corrupted when all the files look present?
Presence is not the same as matching. A part file can be present but truncated or altered, and the hash-tree check will fail it. Compare total size and part count against a known-good copy, or simply re-copy/reconvert to be sure.
My game worked, then went corrupted after I moved it. What happened?
Most likely the header file and its .data folder were separated or renamed during the move, or a part was lost in the transfer. Restore both together with their original matching names — the placement rules are in our game not showing guide.
Could the converter have made a bad package?
A conversion that completed from a good ISO produces a self-consistent package. If conversions themselves are failing or stalling, work through our conversion errors guide. Otherwise, suspect the transfer and the media first. More help is on the Troubleshooting hub, and clean converters are linked from our download page.
Isolate the fault with one known-good test
When several explanations are still open, run one controlled test before changing anything else: take a package you know is good — ideally a fresh conversion you have just made from a verified ISO — copy it by the same route to the same device, and try it. If the known-good package also reports as corrupted, the fault sits in the shared part of the chain: the media, the transfer route or the console’s expectations. If it works, the fault is inside the original package, and reconverting that one game is the whole job. This single comparison replaces a lot of guesswork, because corruption reports all look identical on the dashboard even though their causes live in completely different places.
Two things not to do while you troubleshoot: do not keep re-copying the same suspect package over and over in the hope the console changes its mind — a hash check that fails will keep failing on identical data — and do not delete your PC-side originals until the console copy is verified working. Your PC package and the source ISO are your clean source of truth; everything on the console is replaceable from them.