Base64 Decode and Unzip: Handling Compressed Payloads

The order matters

Data is compressed first, then Base64-encoded — because compression produces binary and Base64 makes binary text-safe. Unwrapping therefore reverses it: decode first, decompress second.

Doing it the other way round fails immediately, since a Base64 string is text and gzip will not recognise it.

Recognising what you have

Decode and look at the first bytes. 1F 8B is gzip. 50 4B 03 04 is a ZIP container. 78 9C or 78 DA is raw zlib/deflate, which is what SAML and many cookies use — and which needs inflate, not gunzip.

The distinction between gzip and raw deflate causes most of the failures here: they are related formats with different headers, and using the wrong one gives an unhelpful error.

Doing it

# gzip
base64 -d payload.b64 | gunzip

# ZIP archive — needs a real file
base64 -d payload.b64 > archive.zip && unzip archive.zip

# raw deflate (SAML, cookies)
base64 -d payload.b64 | python3 -c \
  "import sys,zlib; sys.stdout.write(zlib.decompress(sys.stdin.buffer.read(), -15).decode())"

The -15 window argument is what selects raw deflate with no header. Omit it and zlib expects its own header, which SAML payloads do not have.

Going the other way

To produce such a payload, compress then encode — and note the ordering interacts with encryption. If data must be both compressed and encrypted, compress first, encrypt second, encode last.

One caveat worth knowing: compressing attacker-influenced data together with a secret leaks information through the compressed length. That is the basis of the CRIME and BREACH attacks, and it is why some protocols disabled compression entirely.