ORPHANWARE 1. What the program does
bzip2 compresses and decompresses files. Compression works in blocks: the input is processed in block sizes from 100k to 900k, each block is transformed with the Burrows-Wheeler transform, then compressed with Huffman coding. Decompression reverses the process and verifies integrity with CRC32 checksums, one per block and one combined value for the stream. The program reads and writes files, or streams between standard input and standard output, and includes a test mode that verifies a compressed file without decompressing it to disk. Behavior matches the documented bzip2 1.0.8 specification in every particular examined; no undocumented modes, no hidden network behavior, no telemetry.
2. Command line interface and flags
- -1 to -9: block size in hundreds of kilobytes, 100k (fastest, least memory) to 900k (best compression).
- -d, --decompress: decompress input. Selected automatically when the program is invoked under the bunzip2 or bzcat names.
- -z, --compress: force compression, the default when invoked as bzip2.
- -t, --test: verify the integrity of compressed files without decompressing them.
- -c, --stdout: write to standard output instead of replacing files.
- -k, --keep: keep the input file instead of deleting it after processing.
- -f, --force: overwrite output files and compress links; required to process files with multiple hard links.
- -s, --small: reduced memory mode for decompression, at the cost of speed.
- -q, --quiet and -v, --verbose: output verbosity; verbose reports the compression ratio and, on decompression, the CRC checks.
- --fast and --best: aliases for -1 and -9.
3. File formats
Input: any byte stream for compression. For decompression, files in bzip2 format, conventionally with the .bz2 extension.
Output: the bzip2 stream format. A stream header beginning with the bytes "BZh" followed by one digit, 1 to 9, recording the block size in hundreds of kilobytes. Each block carries a 48-bit block magic value, its CRC32, and the compressed data; the stream ends with an end-of-stream magic value and the combined CRC32 of all blocks. A file may contain several concatenated streams, which decompress as one continuous output. This format documentation is part of the deliverable: it is what a maintainer, or a migration project, needs to read the data with any other tool.
4. Structure and size
The program separates cleanly into a compression path, a decompression path, the shared block sorting code that dominates its size, and a small command line driver that handles file naming, permissions, and error reporting. There is no configuration file and no database; all state lives in the stream. The full recovery of this target produced 8,127 lines of readable source.
5. Feasibility verdict
Fully recoverable. The binary is a standard optimized build: no packing, no obfuscation, no license enforcement, no undocumented dependencies. Nothing in the binary resists the pipeline. For this sample target the full recovery was in fact completed, as part of the proof set: the recovered source compiled clean and matched the original across thousands of differential fuzz cases with zero divergence. On a client engagement, this section states the verdict and the reasoning before any larger fee is discussed. When the verdict is no, this is where we say so, and why.
6. What full recovery and verification would involve
- Reconstruction of the recovered source into readable, maintainable form, as in the Source Recovery tier.
- Differential verification as in the Verified Recovery tier: thousands of generated cases, random data, edge cases at block boundaries, corrupt-input handling, and the full flag matrix, run against both binaries with outputs compared exactly.
- Known limitations, stated in advance: fuzz testing proves the rebuild matched the original on every case tested, not on every case possible. It is the strongest evidence available, and the report says exactly which cases were covered.
What your report would look like
Identical in structure, specific to your program: what it does in plain language, every flag and option, every file format it touches documented well enough for a maintainer or a migration team to use, an honest verdict on recovery, and the scope and price of the full job stated before you commit to it. If your program cannot be recovered, the report is still the documentation your replacement project will start from.