"implausible uncompressed size"
This usually means the input is not an SAP wrapper at all. A common mistake is passing a compiled executable, a random binary dump, or an already recovered output file back into the tool.
Most failures come from a few practical causes: the file is not actually an SAP BLOB, it belongs to a different legacy SAP format, the export is truncated, or the output file already exists and overwrite protection stops the write.
This usually means the input is not an SAP wrapper at all. A common mistake is passing a compiled executable, a random binary dump, or an already recovered output file back into the tool.
This repository targets the newer SAP wrapper variant: an 8-byte header, followed by a few padding bits, in front of a raw DEFLATE stream. Older MaxDB-oriented or legacy SAP formats can require different decoding logic.
The tool does not overwrite files silently. Use --force
only when you intentionally want to replace an existing output file.
.pdf
That does not mean decompression failed. The CLI and web UI try to infer
the recovered payload type from magic bytes. If the type cannot be
identified with enough confidence, the fallback extension is
.bin.
The recovered payload is not necessarily a PDF. Depending on the source data, it may be an image, ZIP archive, Office document, XML file, text, or arbitrary binary data.
--identify-type fails on an output fileThe identification mode expects an SAP-compressed input BLOB. It is not a general-purpose file-type tool for arbitrary files that have already been decompressed.
# Analyze only sapblob example.blob --analyze # Detect the recovered payload type without writing a file sapblob example.blob --identify-type # Recover the payload with automatic best-effort extension detection sapblob example.blob # Write to an explicit output path sapblob example.blob --output recovered.bin # Overwrite an existing output file intentionally sapblob example.blob --output recovered.pdf --force