Binary Steganography Extractor
Extract hidden data from any binary file. Scan mode, brute-force auto-detect, PE section inventory, ZIP comment reader, entropy heatmap, strings scanner, and CTF flag detector. Browser-based binwalk alternative.
Try the demo instantly
Loads a sample EXE with a hidden message already embedded
Drop any binary file here or click to browse
EXE · DLL · ZIP · JAR · APK · ISO · firmware · Max 50 MB
100% Client-Side Processing
Your file is processed entirely in this browser tab. Nothing is uploaded to any server. Works offline after page load.
How to Decode Binary Steganography (5 steps)
- Upload the binary file you want to analyse — EXE, DLL, ZIP, JAR, ISO, or firmware
- Click Scan — see the binary structure and any signals found
- Click Decode or use Brute-Force for unknown methods
- Enter passphrase if the payload was encrypted
- Copy the decoded text or download the hidden file
Frequently Asked Questions
Can this decode binary files encoded with tools other than the Binary Steganography Hider?
Partially. For files encoded with the companion Hider, the BINSTEG v1 header makes extraction fully automatic. For files encoded elsewhere (no standard header), generic extraction looks for known file signatures at the EOF and reads ZIP comment fields directly.
How does Scan Mode work?
The scanner checks each method for a BINSTEG magic header first (92-98% confidence if found and CRC-valid), then falls back to structural signals — file signatures near EOF, non-standard PE/ELF sections, non-empty ZIP comments, or structured content in null-byte runs. No signal found reports low confidence, not a guarantee the file is clean.
Why does entropy analysis flag my PE executable as high-entropy?
Packed or compressed executables have high entropy throughout because packing makes byte distributions uniform. High entropy is a signal to investigate further, not confirmation of steganography — look for spikes specifically in null-adjacent regions or at the EOF.
What should I do if the payload is garbled?
Most likely the payload was AES-256-GCM encrypted — enter the passphrase and try again. If you don't have it, the payload is unreadable by design. If encryption wasn't used, a BINSTEG header CRC mismatch indicates the file was modified after encoding.
Does this work with JAR, APK, and Office files?
Yes. JAR, APK, DOCX, XLSX, PPTX, and ODP files are all ZIP-based, with an EOCD record. The ZIP Comment method extracts from any of these identically.
What's the brute-force priority order?
ZIP Comment → Null Cavity → PE Section → EOF (the four core methods, in that exact order), followed by ELF Section, Raw Offset, and PDF Stream. A valid BINSTEG header found anywhere skips straight to that method.