JPEG Steganography Extractor

It reads the four layouts the JPEG Steganography Hider writes: F5 (a passphrase-shuffled matrix code in the DCT coefficients), JSteg (the low bit of every eligible coefficient, in file order), and the JPEG Comment and APP3 segments, which carry a text header. It also reads the Hider's two Plausible Deniability features, each through its own control in Forensic mode (see Plausible Deniability Files below).

Auto-Detect checks the Comment and APP3 headers first. If neither is present it tries F5 once, with the passphrase you typed or, if you typed none, with the built-in default key, then JSteg. It accepts a result only if the bytes read as text, as one of the file types in the table below, or as this tool's encrypted layout; unknown binary data can therefore be missed, and a payload may exist even when Auto-Detect reports nothing. For files made by other tools, such as steghide, use the Steghide Extractor; for metadata fields such as EXIF or XMP use the EXIF Data Extractor.

Two separate operations use the passphrase, and they use different keys. F5 ordering: the permutation key is the SHA-256 hash of the passphrase, and it decides the order in which F5 visits the coefficients. When the Hider is given no passphrase the permutation key is a fixed default built into the tool (the text StegoToolkit), so the order is the same for every file and the Extractor needs nothing from you; that default gives no secrecy against anyone who knows the tool, and it is not an encryption key. Payload encryption: PBKDF2-HMAC-SHA-256 (100,000 iterations) derives the AES-256-GCM key from the same password, and the payload is encrypted whenever a passphrase was used. The Extractor must be given the same passphrase for both. A wrong passphrase does not give a password error: it reads the coefficients in the wrong order, the length field does not fit the image, and the result is the message that the passphrase is wrong, the data was hidden without one, or the file holds no F5 data. The same happens for a file with no F5 data at all.

The Hider has two Forensic-mode deniability features. Plausible Deniability Mode (F5 only) puts a plain decoy comment in the Comment segment and hides the real, encrypted message with F5 without this tool's header; read it with Deniability Mode (F5) switched on and the passphrase. The panel Plausible Deniability — Decoy + Real Payload writes a plain decoy comment and an AES-256-GCM encrypted real payload hidden with JSteg; read it with Plausible Deniability Decode. In that panel the decoy needs no password and the real layer needs one passphrase; a blank passphrase shows only the decoy, and a wrong one shows the decoy and reports the real layer as not decrypted. Neither feature is found by Auto-Detect or the normal F5 or JSteg reads (checked in the tests), and each control reads only its own kind of file.

The scan runs before you decode and is detection, not extraction: nothing it shows is a decoded message. For JSteg it computes the pairs-of-values chi-square test over the coefficient values 2k and 2k+1 and reports the highest p-value over growing windows from the start of the coefficient walk: near 1 means the pairs look equalised, as they do after JSteg writes random-looking bits; near 0 means the observed coefficient pairs differ substantially from the equalised distribution the test expects after JSteg. A low p-value does not prove the image is clean: it only means the expected equalisation was not observed. HIGH is above 0.8, MEDIUM above 0.3. A p-value is a hint, not proof: other coefficient distributions can look similar, and it falls as a JSteg file is filled only partly. On 60 clean synthetic photos in our test set the p-value was below 0.001 for the 54 that had enough eligible coefficients (the other 6 are too small for the test and report that), and 7 of 9 JSteg files were flagged (conditions on the Hider page); that is an observation on one test set, not a general rate for clean JPEGs.

The F5 indicator counts the zero share of the luminance AC coefficients and compares it with a fixed expectation for the estimated quality (table below). The score is the difference times 500, at most 80, and it is MEDIUM above 50; its confidence is always LOW. The expectations are rough guesses, not a validated model, and the indicator does not separate F5 from clean photographs: it was MEDIUM on 45 of 60 clean test photos and on 5 of 9 F5 files. Treat it as a reason to try a decode, nothing more.

Brute-Force is a fixed list of extraction steps, not a password search. It tries Comment, then JSteg, then F5 with your passphrase (skipped when you typed none), then F5 with the default key, then the CTF heuristic, and stops at the first hit that passes the same plausibility checks as Auto-Detect. It never guesses or cracks a passphrase: a wrong passphrase finds nothing. The CTF heuristic is the last step. It is an F5 read (with your passphrase, or the default key) followed by a raw JSteg read that skips the plausibility checks, so it can show an unknown binary payload or, rarely, noise. It does not implement the steghide algorithm and cannot extract steghide files.

For F5 and JSteg the Hider encrypts first, then wraps the encrypted bytes in Reed-Solomon, then adds a one-byte flag (0 = not encrypted, 1 = encrypted) and the method's length. The Extractor undoes this in reverse: it checks the flag, repairs a Reed-Solomon wrapper (marker RSC2), then verifies AES-256-GCM with your password. Comment and APP Extension have no flag byte: their text header says NONE or AES256GCM, and the Base64 that follows is the stored bytes, which are then unwrapped in the same order (Reed-Solomon, then AES). The Hider page lists the Reed-Solomon header, the parity per block (10, 20 or 30 bytes per 223) and the repair limits (5, 10 or 15 changed bytes per block). If blocks cannot be repaired the result says how many and shows those bytes as found; with a password the authentication then fails and you see a decryption failure. The 16-byte header, the length field and the flag are not repaired.