The GPG Blob: Reading an OpenPGP Packet Tag From One Byte
Le défi
Un outil d'exfiltration a déposé data.bin sur un hôte compromis et l'équipe l'a noté comme binaire brut. Seul le tout premier octet trahit le format. Ouvrez-le dans la visionneuse hexadécimale, comparez cet octet aux balises de paquet de référence, et indiquez le vrai format.
Ce que tu vas apprendre
- 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
Compétences testées
Prérequis
- Basic familiarity with GPG / OpenPGP as a public-key encryption tool
- Comfort reading individual hex byte values
Comment ça marche
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.
Erreurs fréquentes
- 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.
Comment s'en protéger
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.