Dump hygiene: naming, backups, and not flashing the wrong image
Every disaster restore I have ever done started with a folder full of files named nand.bin, nand(1).bin, and newnand.bin. The console does not care about your desktop. You will. This applies to RGH3, leftover Ace V3 RGH1.2, JTAG, and Bad Update dumps alike.
A naming scheme that survives a month
2026-08-19_corona16_orig_cpukey.txt
2026-08-19_corona16_rebuild_kvswap.bin
Board, size, original vs rebuilt, date. Put the CPU key next to the original dump, not in a chat log. If you replace kv.bin, keep the original image read-only. The number of people who overwrite the only clean dump is not small. FATXplorer HDD clones are a different backup class — keep both.
Verify before you write
Compare file sizes against what that board should produce. A 4GB Corona is not a 16MB file with optimism. After a rebuild, confirm the KV you think you installed is the one in the image. Boot XeLL once after an RGH write before you celebrate in Aurora. After a Bad Update dump, do not flash that image to a different motherboard “to test.”
When the original identity is already burned — or cloned
Do not keep flashing the same dump hoping Live will forget. That is not how this platform works. Fix the vault, then keep the new rebuild in the same dated folder. I keep this KV change guide for Xbox 360 next to the dump folder so the order of operations is not a memory test. Process is boring. Bricks are interesting only to other people.
If you are not banned and never will sign in, still do not clone this image onto a second Slim “so they match.” Shared kv.bin is how twenty offline boxes become twenty Live corpses if anyone ever plugs Ethernet in. Dump hygiene is scene hygiene.