C++ 同一文件的不同CRC32校验和

基本上，我有一个导入一些DLL和一些Python库的应用程序。 我做了另一个应用程序来计算这些文件的CRC32，我在我的主应用程序中添加了这个列表，因为我想让它检查这些文件。 问题是，有时主应用程序会检测到DLL或库被修改，即使它没有被修改。这不是每次都会发生，我想知道为什么会发生？什么可以确定CRC32校验和不同？这是因为我的应用程序加载了这些DLL，或者是外部的东西，比如病毒或其他什么

以下是主应用程序和CRC32列表中的应用程序的代码：

#include "boost/crc.hpp"
#include "boost/filesystem/operations.hpp"
#include "boost/filesystem/path.hpp"
#include "boost/progress.hpp"
#include "boost/integer.hpp"

using namespace std;
namespace fs = boost::filesystem;

int CheckCRC32(LPCSTR szFileName, DWORD dwCRC32)
{
    if (!fs::exists(szFileName))
        return 1;

    DWORD dwResult = 0;
    boost::crc_32_type result;
    std::streamsize const buffer_size = 1024;
    ifstream file(szFileName, std::ios_base::binary);

    if (file)
    {
        do
        {
            char buffer[buffer_size];
            file.read(buffer, buffer_size);
            result.process_bytes(buffer, file.gcount());
        } while(file);
    }
    else
        return 1;

    dwResult = result.checksum();
    if (dwResult <= 0)
        return 1;

    if (dwResult != dwCRC32)
        return 2;

    return 0;
}

---

另外，如果您有其他解决方案来做这些事情，或者您有此方法的解决方案，请告诉我。

我并不真正信任您的1024字节固定缓冲区和您选择的调用顺序。要么您打算只将文件的前1024字节用于crc，要么这可能已经是问题所在。另一方面，如果您crc的文件小于1024个，则取决于file.read的行为

只是为了给你一个选择，这里的代码为一个低层次的选择。如果使用此版本获得相同的crc值，则取决于我的初始crc值0是由书本提供的，还是需要使用另一个起始值

#include <Windows.h>
#include <cstdint>
#include <string>
#include <vector>

static uint32_t crc32_tab[] = {
    0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f,
    0xe963a535, 0x9e6495a3, 0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
    0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91, 0x1db71064, 0x6ab020f2,
    0xf3b97148, 0x84be41de, 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
    0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 0x14015c4f, 0x63066cd9,
    0xfa0f3d63, 0x8d080df5, 0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
    0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b, 0x35b5a8fa, 0x42b2986c,
    0xdbbbc9d6, 0xacbcf940, 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
    0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116, 0x21b4f4b5, 0x56b3c423,
    0xcfba9599, 0xb8bda50f, 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
    0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, 0x76dc4190, 0x01db7106,
    0x98d220bc, 0xefd5102a, 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
    0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818, 0x7f6a0dbb, 0x086d3d2d,
    0x91646c97, 0xe6635c01, 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
    0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457, 0x65b0d9c6, 0x12b7e950,
    0x8bbeb8ea, 0xfcb9887c, 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
    0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2, 0x4adfa541, 0x3dd895d7,
    0xa4d1c46d, 0xd3d6f4fb, 0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
    0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9, 0x5005713c, 0x270241aa,
    0xbe0b1010, 0xc90c2086, 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
    0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, 0x59b33d17, 0x2eb40d81,
    0xb7bd5c3b, 0xc0ba6cad, 0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
    0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683, 0xe3630b12, 0x94643b84,
    0x0d6d6a3e, 0x7a6a5aa8, 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
    0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe, 0xf762575d, 0x806567cb,
    0x196c3671, 0x6e6b06e7, 0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
    0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5, 0xd6d6a3e8, 0xa1d1937e,
    0x38d8c2c4, 0x4fdff252, 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
    0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60, 0xdf60efc3, 0xa867df55,
    0x316e8eef, 0x4669be79, 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
    0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f, 0xc5ba3bbe, 0xb2bd0b28,
    0x2bb45a92, 0x5cb36a04, 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
    0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a, 0x9c0906a9, 0xeb0e363f,
    0x72076785, 0x05005713, 0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
    0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21, 0x86d3d2d4, 0xf1d4e242,
    0x68ddb3f8, 0x1fda836e, 0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
    0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c, 0x8f659eff, 0xf862ae69,
    0x616bffd3, 0x166ccf45, 0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
    0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db, 0xaed16a4a, 0xd9d65adc,
    0x40df0b66, 0x37d83bf0, 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
    0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, 0xbad03605, 0xcdd70693,
    0x54de5729, 0x23d967bf, 0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
    0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d
};

uint32_t
crc32(uint32_t crc, const void *buf, size_t size)
{
    const uint8_t *p = static_cast<const uint8_t*>(buf);

    crc = crc ^ ~0U;

    while (size--)
        crc = crc32_tab[(crc ^ *p++) & 0xFF] ^ (crc >> 8);

    return crc ^ ~0U;
}

bool Crc32OfFile(const char * pathToFile, uint32_t &result)
{
    bool success = false;
    HANDLE hFile = 
        ::CreateFileA
            ( pathToFile
            , GENERIC_READ
            , FILE_SHARE_READ
            , NULL
            , OPEN_EXISTING
            , FILE_ATTRIBUTE_NORMAL|FILE_FLAG_SEQUENTIAL_SCAN
            , NULL
            );
    if (INVALID_HANDLE_VALUE != hFile)
    {
        DWORD fileSize = ::GetFileSize(hFile, NULL);
        std::vector<uint8_t> buffer;
        buffer.resize(fileSize);
        DWORD bytesRead = 0UL;
        if (::ReadFile(hFile, &buffer[0], buffer.size(), &bytesRead, NULL))
        {
            if (bytesRead == fileSize)
            {
                result = crc32(0UL, &buffer[0], buffer.size());
                success = true;
            }
        }
        ::CloseHandle(hFile);
    }
    return success;
}

---

处理此类问题的一种方法是将其与执行相同操作的替代实现进行比较。尝试使用非boost替代方案，看看其行为是否相同。CrC32功能也非常丰富，您可以找到一个易于使用的功能。对于文件操作，只需转到本机CreateFile、ReadFile。。。或者使用cstdio。如果你看到了同样的效果，至少你知道从你使用的有趣的库中得到的不是有趣的东西。加载DLL不应影响磁盘上的内容。可能问题在于您为dwCRC32传递的数字？这些文件的大小是缓冲区大小1024的倍数吗。你会得到一个额外的读取，将在缓冲区中放入零字节，crc_32_类型是否处理这种情况？@BitTickler boost中的crc生成器应该已经足够了-它是一个广受好评的库。你是认真的吗？basic_istream:：read对文件长度小于所传递的计数参数的情况有很好的定义。@n0rd这就是为什么他这么快就找到了问题的解决方案。他没有捕获异常，没有检查返回值，然后想知道会发生什么。他还检查了DWORDs，假设STL不正确地实现了basic_istream:：read。对于任何广泛使用的STL实现，这种假设在99.9%的情况下都是错误的。解释一下这里使用的CRC32可能会有所帮助。CRC是对CRC低阶字节的右移异或，向右循环8次。它是多项式0x104C11DB7，将其反转并右移1位到0xEDB88320。请注意索引0x80=0xEDB88320处的表项。@n0rd我认为您缺少几个9。