The File That Kept Its Name: What a gzip Header Remembers

A file's name and extension are labels kept by the file system; the bytes inside decide what it really is. Most formats open with a fixed signature, and gzip's is 1F 8B.

After the signature, a gzip header (RFC 1952) is ten bytes: CM (08, deflate), FLG, a four-byte little-endian MTIME, XFL and OS. Each bit of FLG announces an optional field that follows. The command-line gzip sets 08 (FNAME) by default and stores the name of the file it compressed, as plain text ended by a 00 byte, along with that file's modification time.

Renaming the .gz afterwards only changes the label outside. The original name is still the first readable text in the file, which is exactly what file reports as was "...".

• Answering blob.dat. That is the name the intruder gave the archive, the one everybody has been calling it. The question is what was inside.
• Answering gzip. That is the format, the first step. The goal is the stolen file's name.
• Copying one row only. The name starts at offset 0x0A near the end of the first row and wraps onto the second; l_2026-10.csv alone is half of it.
• Reading past the 00 byte. The name ends at the first 00; the bytes after it are compressed data, and any letters there are coincidence.
• Taking MTIME for the theft time. It is the source file's last modification, 30 Oct, not the moment it was copied out.

• Inspect outbound uploads by content (magic bytes), not by name or extension, and flag compressed archives sent to unknown destinations.
• Run file or a signature scanner over every blob found in a staging folder during an incident: it recovers names and dates in seconds and scopes what was taken.
• Keep sensitive exports such as payroll in access-controlled locations with alerts on bulk reads, so one compromised account cannot reach them.
• Remember the field is optional: gzip -n omits the name and time, so a missing FNAME proves nothing.