WAV Steganography Hider

A WAV file is a RIFF container: a 'fmt ' chunk that describes the audio, a 'data' chunk of samples, and optional chunks for metadata. This tool reads your file, converts every sample to a 16-bit number, embeds the message, and writes a brand-new 16-bit PCM WAV. Nothing from the original container is kept except channels, sample rate and the samples, and 8-bit, 24-bit and 32-bit inputs lose resolution in the conversion (24-bit input becomes 16-bit, reducing the sample-data size by one third for the same number of samples; the total output size also depends on the rebuilt container and any added chunks).

Apart from the stego-lsb layout, every method first writes a 160-bit header into the lowest bit of the first 160 samples, so even RIFF Chunk Injection and Spectrogram Encoding change up to 160 samples by 1. In our test of RIFF Chunk Injection on a stereo file 80 of 8,000 samples changed. The header is what lets the Extractor find the method, bit depth, channels, password flag and length without any settings.

LSB in PCM Samples is the default. In our seven-file tests, LSB and PRNG data survived a plain lossless WAV re-export, Spectrogram tones stayed readable when the block could be located, and RIFF Chunk Injection did not survive it. PRNG Sample Selection stores the same number of bits at positions chosen from your passphrase; with no passphrase the seed is 0, so the positions are fixed and public. Both write 1, 2 or 3 bits per sample, so at 3 bits a sample can move by up to 7 out of 32,768.

RIFF Chunk Injection is not steganography in the strict sense: the payload sits in its own chunk that any chunk viewer lists, and any editor that rewrites the file removes it. In our tests it did not survive even a plain WAV re-export. Spectrogram Encoding is meant to be seen: it appends audible tone bursts (this adds 0.16 seconds per stored byte), which is the classic CTF trick of a message visible in a spectrogram. The stego-lsb layout exists to exchange files with the real stego-lsb program.

The payload is first optionally deflated, then optionally AES-256-GCM encrypted, then optionally wrapped with Reed-Solomon parity. The 20-byte header is: the letters WAVS, a version byte (1), the method, the bit depth, the channel mode (left, right or both), an encryption flag, a compression flag, the Reed-Solomon level (0, 10, 20 or 30), a compatibility code, the stored payload length (4 bytes, little-endian) and a CRC-32 of the first 16 bytes. The CRC detects accidental change; it does not authenticate anything.

LSB writes the payload bits least-significant-bit first into the lowest bits of consecutive samples starting at sample 160. PRNG does the same at positions drawn with a Mulberry32 generator seeded from the passphrase (FNV-1a hash), keeping the positions in ascending order; if the generator cannot find enough distinct positions near full capacity, the lowest unused positions fill the rest. RIFF Chunk Injection writes the stored bytes into a 'steg' chunk placed after 'fmt ' and before 'data'. Spectrogram Encoding appends the tone block described above. The stego-lsb layout skips the header and the stored-bytes pipeline entirely and writes the message most-significant-bit first into bit 8 of each sample from the first sample.

LSB and PRNG hold (usable samples − 160) × bits ÷ 8 bytes. 'Usable samples' is every sample for both channels, or every other sample for left-only or right-only stereo. The capacity bar subtracts what is stored beyond your text: 48 bytes for a password, 2 bytes plus the name for a hidden file, and Reed-Solomon parity; deflate is not predicted, the encoder checks the compressed size. The figure is tested against the real encoder at the exact limit for every method, bit depth, password and Reed-Solomon combination, with the written file decoded independently. One byte more is refused with a message.

Spectrogram Encoding has no fixed capacity; it adds 0.16 seconds of audio per stored byte, so a 1,000-byte message adds 160 seconds. RIFF Chunk Injection adds no separate limit of its own; file-size and browser-memory limits still apply. The stego-lsb layout holds samples ÷ 8 bytes.

If you set a password, the payload is encrypted before it is hidden, in your browser, with the Web Crypto API. The cipher is AES-256 in GCM mode. The 256-bit key is derived from your password with PBKDF2 using HMAC-SHA-256 and 100,000 iterations. Every encryption generates a fresh random 16-byte salt and a fresh random 12-byte IV with the browser's cryptographically secure random generator (crypto.getRandomValues), so encrypting the same message twice gives different bytes. The stored layout is a 4-byte length, the salt, the IV, then the ciphertext followed by a 16-byte authentication tag — 48 bytes added in total. The tag means a wrong password, or any change to the ciphertext, makes decryption fail instead of returning garbage.

These are standard, widely used primitives, but this implementation has not had an independent audit, and using them does not make the system unbreakable. Their limits matter. Anyone who finds the hidden data can copy the ciphertext and try passwords against it offline, so your password is the real defence: use a long random passphrase, not a word or a date. The key derivation uses 100,000 PBKDF2-HMAC-SHA-256 iterations. This is below OWASP's commonly cited 600,000-iteration recommendation for password storage. That recommendation is not a direct requirement for this file-encryption format, but the lower count makes a strong, unique password especially important. The iteration count is fixed in the code and is not written into the file, so raising it requires a new, versioned format so that files already made can still be opened.

Encryption hides what the data says, not that it exists, and it does not hide the length: AES-GCM ciphertext is the same length as the plaintext, and the encrypted layout adds a fixed 48 bytes of overhead: its own 4-byte length field, the salt, the IV and the authentication tag, separate from any length or framing the tool puts around it. No padding is added. There is no key file and no way to recover a forgotten password. We have not measured key-derivation time on phones or older devices, so very large batches or slow devices may take noticeably longer per file. The tool is intended for educational and personal use; do not rely on it as the only protection for sensitive information, or against a well-resourced adversary.

After embedding, the tool reads the message back from the samples it just produced and compares it with your payload. If they differ no file is produced. This check works on the samples in memory before the WAV is written, so it confirms the embedding, not the final file on disk.

Reed-Solomon (RS-10, RS-20, RS-30) adds parity so that scattered changed bytes in the stored data can be repaired. It cannot repair a file that was re-encoded by a lossy codec, because that changes almost every sample. It is switched off in the stego-lsb layout, which has no place for it.