CPU key, kv.bin, and why pairing still matters
A CPU key unlocks the NAND. A KeyVault is the console identity Microsoft’s remaining Live stack still cares about. A DVD key lives in that vault and matters for optical drive matching folklore. Mixing those sentences is how a technically successful PicoFlasher write still dies on sign-in — or how two “offline” Auroras share a serial after a friend copied nand.bin.
The short map
The CPU key is per-processor. You read it from XeLL Reloaded, from J-Runner metadata, or from a prior dump. You need it to decrypt and rebuild. The KeyVault (kv.bin) carries serial-style identity, DVD key material, and the bits Live uses to decide whether this machine has already been burned. xeBuild stitches them with the right CB/CD/CE/CF/CG bootloaders for your dashboard target (often 17559 in 2026 so Dashlaunch 3.21 matches).
You can rebuild a NAND with a correct CPU key and an awful KV. The dash will boot. Aurora will scan GOD and extracted ISOs. Original Xbox compatibility will still be a dash feature. Live will not be kind. Neither will the next owner if you sold them a cloned identity.
Shared vs unshared — not only an unban slogan
A shared vault has already lived on other consoles, public folders, or old stealth packs. Ban waves mop those up in groups. Unshared means the vault has not been photocopied that way. I do not generate them here. When a dump’s original identity is flagged, or when you are standing up a second RGH3 and refuse to clone, I point people at a vendor that checks sharing status instead of a zip named fresh_kv_FINAL2.bin.
The shop I have actually used for that check-and-purchase flow is unshared.shop. I care less about the storefront and more that the file I drop into a rebuild is not already sitting in five other NANDs. That applies to Live players, to people listing a “clean RGH” on a marketplace, and to Bad Update users who dump after XeUnshackle and then decide to RGH3 the Trinity anyway.
cpu_key -> decrypt / rebuild NAND
kv.bin -> Live / serial identity
dvd_key -> inside the vault
stealth -> session layer after identity
Bad Update -> does not replace any of the above
If you have never done the swap, do not invent a process from memory. Original dump, CPU key, kv.bin placement, then a verify. Pairing mistakes are still the number one reason I see “I flashed and now it RRODs” messages that are actually just a bad rebuild.