Почему CRC32 файла не рассчитывается и равен FFFFFFFF?

Question

[DEVELOPER]

Здравствуйте, уважаемые коллеги. Несколько вопросов по теме вопроса:

1. Почему же всё-таки CRC32 файла вне зависимости от расширения не рассчитывается в то время, когда остальные алгоритмы работают исправно?
2. Что означает результат "FFFFFFFF"?
3. Как альтернативными путями рассчитать CRC32 файла в 11-12 Мб?
4. Что можно изменить в файле, если результаты расчёта его CRC32 равны FFFFFFFF?

Предполагаю, что в файле заложена какая-то мина, которая мешает срабатыванию алгоритма CRC32 и зацикливает его. Или я не прав? Это только мои домыслы.
Всем большое спасибо за развёрнутые и пояснительные ответы.
Помните, что этот топик сможет помочь не только мне, но и многим интересующимся кодерам и иже с ними, поэтому прошу отвечать максимально полно.

Answer 1

[15432]

1. Почему же всё-таки CRC32 файла вне зависимости от расширения не рассчитывается в то время, когда остальные алгоритмы работают исправно?

Он рассчитывается.

2. Что означает результат "FFFFFFFF"?

Число 0xFFFFFFFF, в десятичной системе 4294967295

3. Как альтернативными путями рассчитать CRC32 файла в 11-12 Мб?

можно взять другой полином, например, CRC-32 CCIT, тогда получится другой результат

4. Что можно изменить в файле, если результаты расчёта его CRC32 равны FFFFFFFF?

Изменение значения любого байта в файле приведет к другому значению CRC32. Имя и расширение не является содержимым файла и на хеш не влияет.

Предполагаю, что в файле заложена какая-то мина, которая мешает срабатыванию алгоритма CRC32 и зацикливает его. Или я не прав? Это только мои домыслы.

Да нет, скорей всего в конце файла уже записано значение CRC32 всех предыдущих байт, из-за чего получается такой эффект. Можете считать это своеобразной проверкой целостности. Если CRC32 файла не будет равно 0xFFFFFFFF, файл будет считаться повреждённым. Видел такое в прошивках устройств.

Comments

[DEVELOPER]

Здравствуйте 15432. Спасибо за ваш ответ.

Число 0xFFFFFFFF, в десятичной системе 4294967295

Я могу другими десятками способов рассчитать, чему будет равно число 0xFFFFFFFF, это за ответ не считаю. Файлы разные, а число одно. Что вынуждает формировать результат 0xFFFFFFFF при расчёте контрольной суммы? Это ошибка или что?

можно взять другой полином, например, CRC-32 CCIT, тогда получится другой результат

По поводу полинома CRC-32 CCIT. Его значение при расчёте КС "нормального" файла (с КС, равной 40FAB603) должно совпадать со значением КС файла, рассчитанной с помощью алгоритма CRC32?

Имя и расширение не является содержимым файла и на хеш не влияет.

Вы наверное хотели написать: "...и на контрольную сумму не влияют"?
Т.е. получается, если в конце бинарного файла уже существует контрольная сумма из 20 байт, то алгоритм срабатывать не будет?

Вы не могли бы посмотреть, что вызывает такую ошибку с расчёте КС файла? Что приводит к такому результату?

[15432]

Я могу другими десятками способов рассчитать, чему будет равно число 0xFFFFFFFF, это за ответ не считаю. Файлы разные, а число одно. Что вынуждает формировать результат 0xFFFFFFFF при расчёте контрольной суммы? Это ошибка или что?

Да ничего, просто вот действительно такая сумма CRC32 у ваших данных. Есть утилиты, которые сделают вам файл хоть с CRC32 0x00000000 (например, CD диски с Windows именно такой CRC32 имеют). Модификацией 4 любых байт в файле вы можете задать ему любой CRC32

По поводу полинома CRC-32 CCIT. Его значение при расчёте КС "нормального" файла (с КС, равной 40FAB603) должно совпадать со значением КС файла, рассчитанной с помощью алгоритма CRC32?

Нет, алгоритмы различаются, соответственно, суммы тоже.

Вы наверное хотели написать: "...и на контрольную сумму не влияют"?

Да, на CRC32 влияет только содержимое файла. Имя и прочие атрибуты не являются частью содержимого и не участвуют в вычислении контрольной суммы

Т.е. получается, если в конце бинарного файла уже существует контрольная сумма из 20 байт, то алгоритм срабатывать не будет?

дак срабатывает алгоритм. и правильно всё вычисляет. у всех ваших файлов реально контрольная сумма 0xFFFFFFFF. И скорее всего это происходит потому что последние 4 байта файла - CRC32 всех остальных байт. Сам алгоритм CRC32 так устроен, что если на вход подать |данные|crc32 данных|, то вычисленное значение получится 0xFFFFFFFF

Нет никаких "ненормальных" файлов, никто не обманывает ваш алгоритм подсчёта контрольных сумм. Просто формат самого файла так устроен, что его контрольная сумма всегда равна 0xFFFFFFFF.

[DEVELOPER]

Модификацией 4 любых байт в файле вы можете задать ему любой CRC32

Да, кстати. Я сам до этого дошёл, без подсказок )) Любые 4 байта из 20-ти.

Нет, алгоритмы различаются, соответственно, суммы тоже.

Я так и полагал. Этот вариант не подходит.

так срабатывает алгоритм. и правильно всё вычисляет. у всех ваших файлов реально контрольная сумма 0xFFFFFFFF. И скорее всего это происходит потому что последние 4 байта файла - CRC32 всех остальных байт. Сам алгоритм CRC32 так устроен, что если на вход подать |данные|crc32 данных|, то вычисленное значение получится 0xFFFFFFFF

У считал, что у моих фалов не может быть КС равна 0xFFFFFFFF, если только она не приведена к этому значению принудительно, что кстати тоже может иметь место быть, но для чего? По аналогии с CD-дисками Windows.......

если на вход подать |данные|crc32 данных|, то вычисленное значение получится 0xFFFFFFFF

Т.е. это железное правило алгоритма, а не частное мнение? Тогда я это учту на будущее. Спасибо за науку.

формат самого файла так устроен, что его контрольная сумма всегда равна 0xFFFFFFFF

Т.е. это специально делает (этого добивается) автор этих файлов?

[15432]

Самый простой пример. Возьмём текстовый файл с надписью "hello"
68 65 6C 6C 6F
Его CRC32 равен 3610A686.
Инвертируем его (логическое NOT), получаем C9EF5979
Допишем это значение в конец файла:
68 65 6C 6C 6F 79 59 EF C9
И вуаля, у нас CRC32 всего файла теперь равен 0xFFFFFFFF

у вас то же самое, в каждом вашем файле. формат такой.

и дописывается оно не для "обмана", а для проверки. получатель берёт файл, вычисляет контрольную сумму и проверяет, верная ли она. именно это я и указал в ответе

[DEVELOPER]

15432, Круто! Большое спасибо! Вы просто уникум!

[jcmvbkbc]

Я сам до этого дошёл, без подсказок )) Любые 3 байта из 20-ти.

SSLHTML, кажется ещё не совсем дошёл. Изменить 3 байта можно 2²⁴ способами, а разных значений CRC32 -- 2³².

[DEVELOPER]

jcmvbkbc, спасибо за подсказку. У меня опечатка. Конечно 4. Просто время было 4 ночи и я уже был не совсем внимателен )) Исправил.