[Zlib-devel] Fwd: Avast reports minigzip_d.exe is infected

[Török Edwin]

On 09/20/2011 04:23 PM, Jan Seiffert wrote:
> 2011/9/20 Cosmin Truta <cosmin at cs.toronto.edu>:
>> MinGW puts some small initialization code in the executable, for the
>> benefit of Java (gcj) and C++ (g++), which, for C apps, is never used.
>> It's innocuous, and the space occupied is very little. Could that
>> trigger the attention of an antivirus? It's odd, because that code
>> isn't just in minigzip_d.exe. All the PE executables (zlib1.dll,
>> example_d.exe, minigzip_d.exe) have that in.
>>
> 
> I would guess that some virus uses some self compress by zlib and they
> accidentally added some zlib code to the signature.
> But your guess is as good as mine.

Or some MinGW startup/runtime code from the particular version you used.
For example's MinGW pseudo-relocations calls VirtualProtect, and some libgcc_s wrapper calls GetProcAddress.

> 
>> Could it be possible that minigzip_d.exe carried a real virus? I'd
>> have to re-download the precise MinGW tool versions that I used when I
>> built the DLL package, so that I can rebuild and compare.
>>
> 
> You can't.
> At least not bitexact as you need for a simple hash-compare or binary compare.
> GCC has a "seed" for every compile, and it can alter the output in
> little ways, from Metadata (i think the time of compile ends up in the
> binary, at least by altering the seed) right down to instruction
> sequence in certain cases (ex. it is mostly unimportant in which order
> registers are push-/poped in the pro-/epilogue).
> The GCC guys "pin" the seed to a fixed value if they need to compare stuff.
> See the GCC manual under "-frandom-seed"

If the tool version and compile flags are identical then the generated code shouldn't be
that different.
You should be able to compare the disassembly and PE structure,
any malicious code should stand out. (for example compare output of 'i686-w64-mingw32-objdump -d minigzip_d.exe | colrm 1 40')

What version of MinGW did you use to compile minigzip_d.exe?
(with gcc 4.6.1. I get a 13312 file, and with 4.2.1 I get 7168).

Best regards,
--Edwin