❌

Reading view

Update: search-for-compression.py Version 0.0.8

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.

  •  

Update: rtfdump.py Version 0.0.14

This update adds option -C (–combinations). When this option is used together with -j (–jsonoutput), 2 extra versions of each stream are added. One with option -H enabled, and one with option -H and -S enabled.

rtfdump_V0_0_14.zip (http)
MD5: D9BBA8F83E04D4FD25268E7A2BB4653E
SHA256: DB852CEDA1AE368FF32C1D12951A02BD7A4E36C74632D0D1F790C700FB298689

  •  
❌