The GPG Blob: Reading an OpenPGP Packet Tag From One Byte
The challenge
An exfil tool dropped data.bin on a compromised host and the team logged it as raw binary. Only the very first byte gives the format away. Open it in the hex viewer, compare that byte to the reference packet tags, and type the real format.
What you'll learn
- Explain that OpenPGP binary packets are framed by a tag byte, not a long magic string
- Recognise that a leading byte with the 0x80 bit set marks an OpenPGP packet header
- Identify 0x85 as the start of a public-key-encrypted session key packet
- Distinguish a GPG blob from ZIP, GZIP, and PNG by their differing first bytes
- Triage an unknown binary by reading just enough of the header to classify it
Skills tested
Prerequisites
- Basic familiarity with GPG / OpenPGP as a public-key encryption tool
- Comfort reading individual hex byte values
How it works
Most formats announce themselves with a multi-byte magic number, but OpenPGP (the standard behind GPG) is framed differently: a binary OpenPGP stream is a sequence of packets, and each packet starts with a single tag byte. In that byte the most significant bit (0x80) is always set to mark a packet boundary, and the remaining bits encode the packet type and length format.
Here the first byte is 0x85. Because 0x80 is set, this is a packet header; the tag it carries identifies a public-key-encrypted session key packet - the very thing you see at the front of a message encrypted with someone's public key (gpg --encrypt in binary, non-armored mode). So a file logged as opaque data.bin is actually a GPG-encrypted blob, and only that first byte was needed to tell.
The decoys are all formats with conventional multi-byte magics: ZIP is 50 4B 03 04, GZIP is 1F 8B, and PNG is 89 50 4E 47. None of those match a leading 0x85. This is the subtle end of file identification: when there is no obvious ASCII signature, the structure of a single framing byte is still enough to name the format.
Common mistakes
- Looking for a four-byte ASCII magic. OpenPGP does not have one; the signal is the single tag byte, so scanning for printable text finds nothing.
- Dismissing it as random binary. The 'bin' extension and high-entropy body tempt you to give up, but byte 0 is structured.
- Confusing it with GZIP. GZIP also looks like compressed binary, but it starts with
1F 8B, not85. - Over-reading the header. You do not need to parse the whole packet; the tag byte alone classifies the format.
How to defend against it
Defenders should detect encrypted blobs by structure and treat unexpected GPG output as a possible exfiltration or staging artifact.
- Run content-based detection that understands OpenPGP packet framing, not just multi-byte magics, so binary GPG blobs are classified rather than logged as 'unknown binary'.
- Alert when GPG-encrypted files appear in locations or workflows that do not normally produce them, a common pre-exfiltration packaging step.
- Monitor for unexpected
gpg/openpgptool execution on servers that have no business encrypting data. - Inventory which keys can decrypt such blobs so an incident responder can determine the intended recipient.