The GPG Blob: Reading an OpenPGP Packet Tag From One Byte
O desafio
Uma ferramenta de exfiltração deixou data.bin num host comprometido e a equipe registrou como binário bruto. Só o primeiro byte revela o formato. Abra-o no visualizador hexadecimal, compare esse byte com as tags de pacote de referência e digite o formato real.
O que você vai aprender
- 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
Habilidades testadas
Pré-requisitos
- Basic familiarity with GPG / OpenPGP as a public-key encryption tool
- Comfort reading individual hex byte values
Como funciona
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.
Erros comuns
- 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.
Como se proteger
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.