Windows上的ZLIB：gzopen / gzwrite / gzclose生成阉割输出文件/防病毒？

Question

我几天来一直在追逐一个非常神秘的虫子，这似乎围绕着（ZLIB library）;它每个月左右发生一次，并且仅在某些特定的生产环境中发生。以下是代码的作用：

1. 程序调用{​​{1}}写入文件gzopen。
2. 程序将数据写入文件，执行多个X。
3. 程序最终调用gzwrite来刷新文件。

通常，一切正常，文件gzclose有效;它以CRC和源流的长度正确终止。

但是，在其中一个失败中，我发现X已损坏：数据的开头是正确的，但从偏移X开始，每个字节都为空。即使编码CRC和长度的最后八个字节也是零。但是，文件大小合适！更糟糕的是：同一系统在几分钟前成功压缩了一个非常相似的文件。

注意：我们使用的ZLIB.DLL版本为1.1.3;是的，我知道，它包含一些安全漏洞，我们应该升级到最新的ZLIB 1.2.3，但我不想在我的设置中更改任何内容，直到我找到归零的原因。

我认为我已经排除了内存损坏（顺便说一句，腐败的内存堆如何能够充分地干扰0x00302000，它只会将零写入输出流？这是否合理？），循环打开/写入/关闭流是简单的，并没有揭示我可以发现的任何缺陷，代码不分配/释放/混乱ZLIB中的结构（这可能是一个问题，因为ZLIB链接到另一个C库而不是我的应用程序DLL），所以我只能怀疑系统中的其他元素。

不知何故，我倾向于对C库（CRTDLL.DLL），Win32 API，NTFS堆栈，I / O堆栈，低级设备驱动程序，硬盘固件和硬盘本身充满信心...是的，我也倾向于认为Visual C ++ 2008产生了正确的二进制文件，至少在这种情况下; - ）

那么，我怀疑防病毒软件可能是罪魁祸首吗？它应该对ZLIB持谨慎态度，因为至少卡巴斯基认为DLL是一种可能的威胁。但是，如果（错误地）发现感染，那么防病毒软件只是简单地写入零而不是数据，这在政治上是正确的吗？或者这可能是防病毒软件中的一个错误？

或者我完全忽略了这一点？

Answer 1

在不知道其他任何事情的情况下，我会怀疑你的代码，而不是反病毒代码。

将正确长度的数据写入文件需要一个简单的错误，但是传入一个不正确的缓冲区，导致“全零”作为文件中的数据。

很难发现的简单错误有时会导致非常大的混乱，就像你一样。

如果我正在排除故障，我会：

• 简化简化简化，直到问题停止。然后逐步增加复杂性。
• 检查你的指针和指针算术
• 检查你是否正在冲洗＆amp;正确关闭文件
• 使用在分配的缓冲区中存储标记字节的分配器，如0xAA而不是0x00。这样您就可以看到它是否是正在写入文件的（归零）缓冲区。
• 在调试器中逐步完成所有操作

在正常情况下，GZIP的数据永远不会有一连串的零。这些将折叠成字典和长度代码。