LSB Extractor

An LSB decoder (extractor) reverses LSB hiding. Hiding with the least-significant-bit method overwrites the lowest bit (or lowest few bits) of colour values with message bits. Extraction reads those same bits back in the same order and packs them into bytes. To do that it must know the bit depth (how many low bits per value), the channels (R, G, B, sometimes A), the pixel order (raster order, or a shuffled order), and how the bits were packed into bytes. An image made by this site's LSB Embedder carries a 20-byte header that records most of that; an image from anywhere else does not, so the Extractor has to be told or has to try common settings.

The tool decodes your image in a Web Worker and reads its raw RGBA pixels. A browser canvas cannot hand back exact colour values for transparent or partly transparent pixels, so bits stored under transparency may not be readable here. Everything is read from the image as saved: a JPEG copy of the image no longer holds LSB data, because JPEG rewrites every pixel.

Take the red, green and blue values of the first pixels in raster order and keep only the lowest bit of each. Pixels (200, 101, 50), (200, 100, 50) and (202, 103, 52) give 0, 1, 0, 0, 0, 0, 0, 1 (from the first eight values). Group eight bits per byte, most significant bit first: 01000001 is 65, the letter A. That is Ranked Scan setting 1 (RGB, 1-bit, MSB-first). If the output is gibberish, change one thing at a time: pack the bits LSB-first instead (zsteg calls this 'lsb'; the same eight bits would read 10000010 = 130), use a single channel (settings 3-5), two bits per value (settings 6 and 10), include Alpha (setting 7), or start from the last pixel (setting 9). In zsteg's naming, 'b1,rgb,msb,xy' is setting 1 and 'b1,rgb,lsb,xy' is setting 2; we checked the 1-bit layouts against images we built, not against the zsteg program.

The Embedder writes a 20-byte header in pixels 0–53, 1 bit per R, G, B: magic 'LSTG', version, variant (sequential, PRNG or Blue channel), channel bitmask, bit depth, encryption flag, compression flag, stored length (4 bytes, little endian) and a CRC-32 of the first 16 bytes. The Extractor trusts the header only when the CRC matches and the stored length fits the image at the recorded settings. The CRC-32 is an integrity check against accidental change, not authentication: anyone can write a header with a valid CRC. The header is also rejected when its version is not 1, its variant is not 0–2, its bit depth is not 1–4, a flag is not 0 or 1, or its channel mask is empty. A bad CRC is reported as such, and a random image almost never passes: 32 bits of magic plus a 32-bit CRC.

With a valid header the payload is read, decrypted if the flag says so (a missing password and a wrong password are reported separately), inflated if the compression flag is set (a failure is reported, not hidden), and then classified. For PRNG images the pixel order is rebuilt from the password (seed 0 when none was used), so the same password is needed for the pixel positions as well as for decryption.

The ranked scan tries these 10 settings, each from the first pixel: 1. RGB 1-bit MSB-first; 2. RGB 1-bit LSB-first; 3. B 1-bit MSB-first; 4. R 1-bit MSB-first; 5. G 1-bit MSB-first; 6. RGB 2-bit MSB-first; 7. RGBA 1-bit MSB-first; 8. RB 1-bit MSB-first; 9. RGB 1-bit MSB-first from the last pixel backwards; 10. RGB 2-bit LSB-first. 'LSB-first' means the first extracted bit becomes bit 0 of the byte, as in zsteg's 'lsb' order. It reads the first 512 bytes per setting; if they start with a plausible little-endian length it returns that block, otherwise the leading readable text or the first 256 bytes.

A reading counts as found only with evidence: a file signature (PNG, JPEG, GIF, ZIP, PDF, MP3 with ID3, WAV, ELF, MP4), flag-shaped text, or at least 10 readable characters from the start. Anything else is shown as 'weak candidates' because ten random-looking readings always produce a highest score. In our tests none of the unmodified images we tried was reported as found: synthetic photo-like and flat images, and 8 crops of a real photograph. The scan cannot see messages shorter than 10 characters, encrypted data without a header (it looks like noise), other bit depths or channel mixes, shuffled pixel orders, or data stored in a different file format or in other bits of the file. Layouts were verified with images we built to the same layout, not with the zsteg or stegolsb programs themselves.

Payload type is decided from the extracted bytes: a full file signature gives a file type; otherwise well-formed UTF-8 made of printable characters (accents, CJK and emoji included) is text; everything else is binary. A short 'GIF…' or 'PK…' text is not mistaken for a file because the full signature (GIF8, PK\x03\x04) is required. The name of a hidden file is not stored by the Embedder, so the download is named after the detected type.

Flag detection scans decoded text for FLAG{…}, CTF{…}, HTB{…}, picoCTF{…}, THM{…} and any 2–8 capital letters followed by braces, plus bare hexadecimal strings of 32 or more characters (hash-style flags). The match must be printable ASCII, so noise does not produce flags. A match is a pattern, not proof that it is the challenge's flag.

Work down this list in order. (1) Is the file still the original? A JPEG conversion recovered 0 of 8 messages in our tests, while PNG, BMP and TIFF copies kept all 8; if you only have a re-saved or resized copy, the bits are gone. (2) Is there an LSBSTEG header? The green card on the settings step says so. With a header the settings are exact, so a failure there is a password, compression or damage problem, each reported separately. (3) No header: try Manual mode with the bit depth, channels and byte packing you expect, including LSB first. The ranked scan only covers 10 settings and cannot see messages under 10 characters. (4) Look at the bit planes in Forensic mode for a low plane that shows text or a pattern. (5) If the image shows no sign of LSB data, the message may be elsewhere: in metadata, after the end of the file, or in a frequency-domain method — try the Steganography Detector, the Zsteg tool or the Image Steganography Extractor.

Each of R, G and B holds 8 bit planes, from bit 7 (most significant, the picture's shape) down to bit 0 (least significant). The viewer draws all 24 as black-and-white images and prints the binary entropy of its share of 1s (1.0 when exactly half the values have the bit set, about 0.5 when 11% or 89% do, 0 when all agree; planes below 0.5 are outlined). The number ignores where the 1s are, so a noisy plane and a striped plane with the same share score the same. Large images are shown at reduced size, sampled by nearest neighbour; the statistics are computed on the same sampled image.

Higher bit planes often show the picture's broad structure, while lower planes hold fine detail, noise or hidden patterns; how one-sided a plane is depends on the image (flat graphics and screenshots can have one-sided low planes with nothing hidden). Neither a plane's entropy nor its appearance proves that data is hidden. What to look for is a low plane that looks like noise, text or a regular pattern while the planes next to it look smooth. A random payload that fills a region pushes that region's LSB value toward 1.0. Alpha planes are not shown.