# binwalk cannot find gzip sections

I am starring at the following exe file, see main page here. It seems pretty clear (using -E entropy option) that the exe contains compressed section. For some reason binwalk is not capable of finding the start of those sections.

Here is what I have:

$binwalk -v -B PmsDView.exe Scan Time: 2016-09-22 14:42:04 Target File: /tmp/PmsDView.exe MD5 Checksum: 911d92675f559a40400f7ca2b69c8544 Signatures: 344 DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 Microsoft executable, portable (PE) 2015 0x7DF Copyright string: "Copyright 1995-2005 Mark Adler "  However it seems like they are using gzip: $ hexdump -C PmsDView.exe
000007a0  30 00 30 00 31 00 35 00  00 00 00 00 4c 64 72 47  |0.0.1.5.....LdrG|
000007b0  65 74 50 72 6f 63 65 64  75 72 65 41 64 64 72 65  |etProcedureAddre|
000007c0  73 73 00 00 6e 74 64 6c  6c 00 00 00 00 00 00 00  |ss..ntdll.......|
000007d0  20 69 6e 66 6c 61 74 65  20 31 2e 32 2e 33 20 43  | inflate 1.2.3 C|
000007e0  6f 70 79 72 69 67 68 74  20 31 39 39 35 2d 32 30  |opyright 1995-20|
000007f0  30 35 20 4d 61 72 6b 20  41 64 6c 65 72 20 00 00  |05 Mark Adler ..|


Am I missing something ? Or did they mask the gzip signature ?

Binwalk did not find the zlib blob because it is also encrypted. It uses the following code to decrypt the compressed data. The decryption uses a table stored in the stack, which is filled with generated values before the loop.

Thus, you have to reverse the decryption code or save the decompressed data from the memory.

• could you recommend a tool to dump data from memory to file ? – tibar Sep 23 '16 at 7:36
• Try ProcDump – ebux Sep 23 '16 at 7:44

Please refer to https://en.wikibooks.org/wiki/Reverse_Engineering/File_Formats for the following example:

inflate 1.1.3 Copyright 1995-1998 Mark Adler


It is a good bet to assume that at least parts of the file are ZIP compressed. Further probing might reveal that the file does not contain a complete ZIP archive, but just a section which is compressed with the ZIP deflate algorithm, and supposed to be decompressed with the ZIP inflate algorithm (likely version 1.1.3, as the output of strings revealed). Therefore, the fictitious file might be further separated into its components by using a custom tool which iteratively applies the inflate algorithm to the file, until the generated result makes some sense (e.g. until the result contains some recognizable clear text strings).

It seems to be the very same case for new, except that your inflate's version is 1.2.3