Audio Steganography Extractor

Audio steganography does not necessarily leave an obvious label. Some methods store framing information or a header (this tool's Spread Spectrum method writes an 8-byte one), while others rely on the extraction settings alone, so decoding means trying the supported methods and judging which result looks like real content. This extractor runs them, interprets each result (text, a recognised file type, encrypted-looking data, or noise) and ranks them so the most plausible answer comes first.

That judgement matters because every method will produce something. Reading the lowest bit of random audio gives random bytes. The tool therefore checks each candidate for a valid length, readable text, a recognised file signature or a CTF flag pattern before it calls it a find.

Auto-Detect makes ten logical attempts: seven LSB presets (1-bit both channels, 2-bit both, 1-bit left, 1-bit right, 3-bit both, 4-bit both, and 1-bit both channels MSB-first), then Echo Hiding, Phase Coding and one Spread Spectrum attempt with the default seed 42. That single attempt searches the spreading factors 256 to 8192 sample frames per bit itself (a factor is accepted only when the header's stored factor, length and checksum agree) and, if nothing matches at the original alignment, a shifted start. These internal factor checks are not counted as separate attempts.

It does not try every possible combination. A payload hidden with 2-bit LSB on the left channel only, or with Spread Spectrum under a custom seed, will not appear in the Auto-Detect list. Standard mode lets you choose the LSB bit depth and channel yourself; Forensic mode adds the LSB bit order and the Spread Spectrum seed.

You can upload an MP3: your browser decodes it to PCM and the tool analyses that. But lossy MP3 encoding generally destroys LSB payloads embedded in the original WAV, so recovery from the converted file is unlikely. Phase Coding and Spread Spectrum payloads made by this tool's encoder survived MP3 128–320 kbps in our tests (not Opus, which destroyed all four methods in our test), but recovery depends on the encoder, bitrate, carrier and decoding alignment, so they are worth trying on a converted file.

The tool attempts to decode the MP3 at its own sample rate, read from its first frame. If your browser cannot use that rate, the tool falls back to its default rate and warns you: the audio is then resampled, which changes the sample sequence, and block-based methods (Echo, Phase, Spread) are unlikely to extract. The fallback is not the only way resampling can happen: audio that was resampled before it reached this tool has the same effect, and resampling is not handled (see Limitations). Codec delay or padding is a separate problem: it shifts where a payload starts, which Phase Coding and Spread Spectrum can search for but LSB cannot. If you know the hidden data is in the MP3's own tags or frames, use the MP3 Steganography Extractor instead.

The interpreter looks at the extracted bytes in a fixed order. A recognised file signature (PDF, ZIP, PNG, JPEG, GIF, MP3 (only with an ID3 tag), WAV/RIFF, ELF, or the two-byte 'MZ' used by Windows executables) is reported as that file type with a download button. Bytes with entropy under 6 bits per byte that are mostly printable ASCII, or strictly valid UTF-8 that is almost all printable (accents, CJK, emoji), are reported as text. Data that matches the exact layout of this toolkit's AES-256-GCM payloads (a length field that agrees with the data size, then a salt and IV), or whose entropy is above 7.4 bits per byte, is reported as probably encrypted — the cue to enter a password. The layout check exists because short messages cannot reach 7.4 bits per byte even when they are encrypted. Very low entropy with few printable characters is reported as noise, which usually means there is no payload at that setting.

The text is also scanned for CTF flag formats: FLAG{}, HTB{}, picoCTF{}, CTF{}, CHTB{}, THM{}, VULNHUB{}, rootme{}, and a generic pattern of two to eight capital letters followed by braces. Be aware that the generic pattern can match ordinary words in braces, so check a hit before trusting it.

First, check the entropy reading. High entropy can indicate encrypted or compressed data, but it does not prove a payload is encrypted. If the extracted bytes match this toolkit's encrypted-payload layout, try the password used by the encoder. If you have the password and decryption still fails, the bytes were probably altered after embedding, or you decoded with the wrong algorithm or settings.

If the result is noise at every setting, the file may simply not contain a payload this tool made. Try the Steganography Detector to test for statistical signs of hidden data, the WAV Steganography Extractor for DeepSound and RIFF-chunk methods, and inspect the spectrogram for a visible image or text, which is a different technique from the ones here.

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 Audio Steganography Hider page.