I’ve noticed when a zlib compressed chunk of data is followed by other data, search-for-compression.py will not always be able to detect the compressed chunk. This is caused by the fact that the other data generates a decompression error, and the complete chunk is disregarded.

I’ve added a new option to try to solve this: -S

Option -S takes a value, a positive number. It’s the size of the decompression buffer. By default, its value is 0.

When you try -S 100 for example, search-for-compression.py will try to decompress up to 100 bytes. If that succeeds, then we assume that we found compressed data, and search-for-compression.py will try to decompress the remainder of the data until either a decompression error occurs, or there is no more data. But when an error occurs, search-for-compression.py will revert to the last decompression without error, and report that.

search-for-compression.py is still in my beta repository.