WAV Steganography Extractor

First it reads the lowest bit of the first 160 samples and checks for the WAVS header and its CRC-32. A valid header gives the method, bit depth, channels, password flag and length, so nothing needs to be configured. If the payload was encrypted you are asked for the passphrase. Decryption either succeeds or fails authentication, and a wrong passphrase and damaged encrypted data give the same failure, so you get an error rather than unauthenticated garbage text.

Without a header the Extractor reads 13 listed settings and scores each by how readable the result is: a file signature of 3 or more bytes, flag shapes, printable text. Three of the listed settings (the plain 1-bit both-channel read, the 'DeepSound 2.x format' entry and the 'interleaved L/R' entry) read exactly the same samples, so there are 11 distinct reads. A result is shown only if it passes a plausibility check, which helps reject implausible results; none of the seven clean recordings was reported as carrying a message, but see the false-positive rate below.

In our tests (npm run test:measure:scan:wav), 70 of 70 header-less messages (a 25-character flag and a 38-character sentence, each hidden with five of the listed settings: 1 bit on both, left and right channels, 2 bits and 3 bits on both, in seven real recordings: five macOS system sounds, one of them mono, and one speech clip) were returned by the ranked scan, and none of the seven clean recordings was reported as carrying a message. A wider run of 12 sentences gave 420 of 420. These results apply to the tested messages, carriers and settings; they do not measure how often arbitrary WAV files or unknown methods are found. An earlier version of the scoring ranked the single-channel read of a message hidden on both channels (every second bit, which looks like capital-letter gibberish) above the true read in 1 of 420; the score now rewards text-like opening runs.

It cannot find messages shorter than 10 readable characters, encrypted payloads that have no header, headerless payloads whose positions depend on a passphrase, or settings outside the 13 listed. Header-based PRNG files are read when the correct passphrase is given. Manual mode overrides the header's method, bit depth and channels with the ones you choose and reads the first 4,096 bytes from sample 0. For Spectrogram it decodes tone slots from the start of the file only: there is no field for a block offset, so a spectrogram viewer can help you see where a block sits, but this Extractor can decode it only if it starts at the beginning (this tool's own Spectrogram files are found through their header). PRNG extraction requires the correct passphrase to reproduce the sample positions. Manual mode also needs the payload length: a usable header provides it, and without one this Extractor cannot determine the PRNG payload length.

Samples shows a chi-square test of the lowest bit (even or odd) over the first 100,000 samples, using a chi-square test with one degree of freedom. A low p-value is evidence against an even 50/50 split, but silence, synthetic audio and very quiet recordings also produce uneven bits, so it does not identify the cause. A high p-value does not establish that the audio is natural or encrypted. The test does not say whether a message is hidden. Chunks lists the RIFF chunks and marks those that are not standard. Spectrogram describes 4 to 8 kHz energy variation and DeepSound reports the marker.

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.