BMP Steganography Extractor

This Extractor reads data written by the BMP Steganography Hider. Pixel LSB and Palette LSB data use one layout: a 4-byte little-endian length, then (normally) a header starting with the bytes STGB, then the payload, with bits stored lowest-first. Data written by another BMP tool uses a different layout, so this Extractor will not read it even if it is also LSB-based. For other LSB layouts try the LSB Extractor or a general tool such as zsteg or StegSolve.

Reserved Bytes is a separate, much smaller layout and does not follow the one above: the BMP file header's reserved bytes 6 to 9 hold one length byte (1 to 3) and up to 3 data bytes, with no 4-byte length, no STGB signature and no encryption.

BMP pixel data is physically stored in B, G, R (and A) byte order. The Extractor takes the selected channels in the fixed order R, G, B, Alpha inside each pixel, the same order the Hider uses, and visits pixels in file order (a bottom-up BMP's bottom row first) or in the seeded shuffle for Random order. Palette LSB instead reads each colour-table entry's bytes in file order: blue, green, red.

A BMP must be uncompressed. RLE-compressed files and 32-bit BMPs with unusual colour masks (not the standard BGRA layout) are rejected; 32-bit BMPs with standard BI_BITFIELDS masks are read like ordinary 32-bit files.

Quick mode runs Auto-Detect: Pixel LSB at 1, 2, 3 and 4 bits (R+G+B, sequential order), Palette LSB at 1 bit, and Reserved Bytes, in that order. It skips Palette LSB if the BMP has no colour table and Pixel LSB for BMPs under 8 bits per pixel. It does not try 6 or 8 bits, a different channel selection (for example Blue only), a random pixel order, or Palette LSB at 2 to 4 bits, because the header that records those settings can only be read after the bits have been found with the right settings. In our tests a file hidden with random order, with Blue only, or at 6 bits was not found by Auto-Detect and was recovered immediately in Forensic mode with matching settings.

An attempt counts as a success in two steps. First the bits must start with a plausible length: more than zero and no larger than the image can hold (Reserved Bytes instead needs its length byte to be 1, 2 or 3). Then the extracted bytes are checked. If they begin with the STGB signature (the four bytes S-T-G-B followed by a version byte of 1 or 2; there is no checksum, so this is about a 1 in 2 billion coincidence), the attempt is accepted as a real Hider file even when its payload is low-entropy or mostly unprintable (for example a file of zeros) and everything after it (error correction, decryption) is reported honestly, including "Data is encrypted. Please provide a password." or a failed decryption. If there is no signature, the bytes are still accepted unless they look like noise (fewer than 30% printable characters and a byte entropy below 3 bits), and the result page then shows a warning that no STGB signature was found.

That second path can produce false positives. For a random-looking image, the chance that a random 32-bit length happens to fit inside an 800 × 600 image at 1 bit (180,000 bytes) is about 180,000 ÷ 2^32, roughly 1 in 24,000 per attempt, if the low bits were random; real images are not random and smaller images have worse odds. Reserved Bytes is more exposed, because any BMP whose reserved byte 6 is 1, 2 or 3 matches. Treat any result without the signature notice cleared as unconfirmed.

In Forensic mode, choose the method, then set the bit depth (Pixel LSB: 1, 2, 3, 4, 6 or 8; Palette LSB: 1 to 4). For Pixel LSB you also choose the channels (R, G, B, and Alpha on 32-bit files) and the pixel order. If the order is Random (seeded), enter the seed number the Hider showed after encoding. A wrong seed does not produce an error message of its own: you get unreadable data or a "payload length" error, the same as any wrong setting.

The Forensic mode switch "Plausible deniability payload" is for BMPs made with the Hider's headerless option: there is no STGB signature to find, so it must be told the exact method and settings. The separate "Plausible Deniability Decode: Decoy + Real Payload" section tries the two-layer scheme: it always shows the decoy (red channel) and, if you enter the passphrase, the real payload (green channel).

If the payload was encrypted, the Extractor needs the same password. A result whose bytes look random (entropy above 7.4 bits per byte, or the layout of an encrypted payload) is reported as "Possibly encrypted or compressed data". That is a clue, not proof: compressed data looks the same, and this label does not mean the payload really is encrypted.

The password is turned into a key with PBKDF2-HMAC-SHA-256 (100,000 iterations) and the salt stored in the payload, and the AES-256-GCM authentication tag then checks it. A wrong password and a damaged payload both simply report failure, so the tool cannot tell you which it was, and there is no way to recover a forgotten password. The full description, including what this scheme does not protect, is on the BMP Steganography Hider page.