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.
Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.
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.
Article Link: Update: search-for-compression.py Version 0.0.8 | Didier Stevens