What format is a Phantom Blade Zero save file?

It is a custom container called PBZS, version 3. It starts with the ASCII magic "PBZS", a version byte, a flags byte, a 16-bit slot count and a 32-bit directory size, followed by an AES-256-GCM encrypted directory and one encrypted block per slot.

Is the save encrypted?

Yes. The directory and every slot are sealed with AES-256-GCM, using a 12-byte nonce and a 16-byte tag per block. Without the key the file is opaque, the slot names themselves are inside the encrypted directory.

Is the decryption key stored in the save?

No. The key is derived from bytes inside PBZ.exe. The save can only prove a candidate key is correct, by authenticating the directory, which is why an editor needs the executable and cannot work from the .sav alone.

Can I check a save is valid without the key?

Partly. You can verify the magic bytes, the version, the slot count, and that the file tiles exactly into a directory plus that many sealed blocks. You cannot verify what is inside the slots without the key.

PBZS v3 Save Format. What Is Inside a Phantom Blade Zero .sav

The header

The first 12 bytes are the only part you can read without a key:

Offset	Size	Meaning
`0`	4	Magic, the ASCII bytes `PBZS`.
`4`	1	Container version. `3` is the current one.
`5`	1	Flags. Observed as `1`.
`6`	2	Slot count, little-endian 16-bit.
`8`	4	Directory size in bytes, little-endian 32-bit, including its own 44-byte preamble.

Those five fields are enough to tell a real save from a mis-saved download. If the opening four bytes are not the PBZS magic, the file is not a Phantom Blade Zero save at all, whatever it happens to be named on disk.

The directory block

Immediately after the header sits the directory, which is itself a sealed block. Every sealed block in the format shares one framing:

PBZS 01 01 00 00   |  nonce (12 bytes)  |  tag (16 bytes)  |  ciphertext

That is an 8-byte block header, then the AES-GCM nonce, then the authentication tag stored out of line, then the ciphertext. Note the tag position: the format keeps the tag before the ciphertext, which is the reverse of what most libraries hand you. Anything parsing this has to move 16 bytes before it can decrypt.

The directory plaintext is a table of slot rows, each shaped like:

uint16 nameLen | name (UTF-8) | algorithm | flag | uint32 size | uint32 offset | uint32 blockSize

So the slot names, the ManualSave rows and the account-level __Advanced__ row, are inside the encrypted part. You cannot list a save's slots without the key.

Slot blocks and compression

Each slot is its own sealed block, pointed at by offset and blockSize in the directory row. The algorithm byte says how the plaintext was compressed before sealing:

Value	Meaning
0	Stored raw.
1	zlib.
2	Oodle Kraken, stored-block framing.

An algorithm byte of 2 does not mean the slot is unreadable: the frame still describes a plain stored block, which is why an editor can round-trip a slot it cannot recompress. Slot plaintext is JSON. Inventory quantities, weapon grades, equipment IDs and the account wardrobe are all just fields in that JSON, which is why editing is a matter of rewriting specific keys rather than understanding a binary format.

Why the key is not in the file

The AES-256-GCM key is not stored anywhere in the container. It is derived from a 64-byte slice inside PBZ.exe, the first 32 bytes XOR the second 32 bytes produce the key. The save's role is to prove a candidate key: if the key is right, the directory authenticates; if it is wrong, decryption fails outright.

That design is why any save editor needs the executable. It also means the appendix of an edited save can never leak the key, the file simply does not contain it. The editor on this site follows exactly that rule: it reads the executable locally, derives the key, and accepts it only after the directory authenticates.

What you can verify without a key

A file that tiles cleanly is almost certainly intact:

The first four bytes read PBZS and byte 4 is 3.
12 + directorySize lands exactly on a sealed block boundary.
Walking block to block from there reaches the end of the file with no leftover bytes.
The number of blocks after the directory equals the slot count in the header.

Run those four checks before you trust any download, including the ones on this site. They cost a few seconds and they separate a truncated file from a genuine one, which is the question people actually want answered.

All three starter saves on this site satisfy those checks. That tells you they are genuine PBZS v3 containers, it does not tell you what is inside them, because that still needs the key.