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.
Leave a Reply (comments are moderated)