Чисто алгоритм вот: Код (Text): GetCRC32A proc lpString:DWORD pushad xor eax,eax mov edi,lpString @@: scasb jnz @B dec edi sub edi,lpString push edi push lpString call GetCRC32 mov [esp+7*4],eax popad ret GetCRC32A endp ;##################################### ;##################################### GetCRC32 proc lpData, dwDataSize:DWORD pushad xor eax,eax mov edx,lpData mov ecx,dwDataSize jecxz @4 not eax @1: xor al,[edx] inc edx mov bl,8 @2: shr eax,1 jnc @3 xor eax,0EDB88320h @3: dec bl jnz @2 loop @1 not eax @4: mov [esp+7*4],eax popad ret GetCRC32 endp А если ты имеешь ввиду, что считать в файле и т.д., то не знаю
Что значит открыть? Передаешь функции указатель на участок памяти и ее размер... Что тут вызывает сложность?
если файл небольшой то можно его весь загрузить в память, но имхо эффективнее читать файл блоками где-то по 256 байт, код тогда будет например таким Код (Text): ;eax=crc32 предыдущего блока или 0 для первого блока GetCRC32 proc lpData, dwDataSize:DWORD pushad mov edx,lpData mov ecx,dwDataSize jecxz @4 not eax @1: xor al,[edx] inc edx mov bl,8 @2: shr eax,1 jnc @3 xor eax,0EDB88320h @3: dec bl jnz @2 loop @1 not eax @4: mov [esp+7*4],eax popad ret GetCRC32 endp
если ты про поле checksum в PE хидере то там алго не такой, существует одноимённая функция в imagehlp корая реверсится за пару минут, а CRC32 для файла считается точно так-же как и для памяти, просто нужно прочитать файл в память. Но иногда поступают не так, иногда просто добавляют некоторые байты в конец для того чтобы crc равнялось нулю, но это в прочем уже не по теме
