Я бы вообще предпочел подход, при котором CRC исключается из проверки.Но если по какой-то причине это невозможно, есть обходной путь:
Вам необходимо зарезервировать 8 байтов, 4 для CRC и 4 для данных компенсации.Сначала заполните зарезервированные байты определенным фиктивным значением (скажем, 0x00
).Затем вычислите CRC в первые 4 байта и, наконец, измените остальные 4 байта, чтобы CRC файла остался прежним.
Подробнее о выполнении этого вычисления: Реверсивный CRC32
Я фактически использовал это в одном из моих проектов :
Я разрабатывал формат файла на основе zip.Первый файл в архиве хранится в несжатом виде и служит заголовочным файлом.Это также означает, что он хранится с фиксированным смещением в файле.Пока что довольно стандартный и похожий, например, на ePub.
Теперь я решил включить в заголовок хэш sha1, чтобы дать каждому файлу уникальный идентификатор на основе контента и для проверки целостности.Поскольку заголовок и, следовательно, хэш sha1 находятся в известном смещении в файле, маскировать его при хешировании тривиально.Поэтому я вставил фиктивный хеш и создал zip-файл, затем хешировал файл и заполнил реальный хеш.
Но теперь возникает проблема: Zip сохраняет CRC всех содержащихся файлов.И не только в одном месте, которое было бы легко замаскировать при хешировании sha1, но и во втором месте с переменным смещением в конце файла.Поэтому я решил пойти с подделкой CRC, чтобы получить сильный хеш, а zip получил действительный CRC32.
И так как я уже подделывал CRC для окончательного файла, я решил подделать его для исходного заголовкафайл тоже не повредит.Таким образом, все файлы в этом формате теперь начинаются с заголовочного файла, который имеет CRC 0xD1CE0DD5
.