Crc32 как посчитать контрольную сумму
Перейти к содержимому

Crc32 как посчитать контрольную сумму

  • автор:

Crc32 как посчитать контрольную сумму

Автономное учреждение Республики Марий Эл

  • Учреждение
  • Об учреждении
  • Состав органов управления
  • Виды деятельности
  • Учредительные документы
  • Квалификационный состав сотрудников
  • Противодействие коррупции
  • Результаты работы
  • Закупки
  • Охрана труда
  • Политика в отношении обработки персональных данных
  • Вакансии
  • Телефонный справочник
  • Контакты и реквизиты
  • Нормативные акты
  • Порядок оказания услуг
  • Проведение гос. экспертизы проектной документации и результатов инженерных изысканий
  • Проведение негосударственной экспертизы проектной документации
  • Экспертное сопровождение
  • Экспертное сопровождение, осуществляемое до направления проектной документации на экспертизу
  • Проведение согласования проектов заданий на архитектурно-строительное проектирование
  • Реестр заключений
  • Правила работы в личном кабинете
  • Личный кабинет ЕЦПЭ

Контактная информация

Адрес: 424002,Республика Марий Эл,
г. Йошкар-Ола, бульвар Победы, 5
Тел. (8362) 30-44-74, 30-44-75
Тел./факс (8362) 30-44-74, 30-44-75
E-mail: mail@marexpert.ru

© 2011 АУ РМЭ УГЭПД
424002, РМЭ, г. Йошкар-Ола, бульвар Победы, 5
Тел. (8362) 30-44-74, E-mail: mail@marexpert.ru

МЫ В СОЦСЕТЯХ:

Сайт разработан компанией «Цитрус»

Ассоциация экспертиз России

Расчет в ИУЛ контрольной суммы файлов по алгоритму CRC32

В соответствии с приказом Минстроя России от 26 мая 2020 г. № 282/пр контрольную сумму файлов, представленных для проведения экспертизы/проверки и описанных в информационно-удостоверяющих листах, необходимо рассчитывать по алгоритму CRC32-IEEE.

В связи с этим в представляемых с 15 февраля 2021 года информационно-удостоверяющих листах следует указывать контрольные суммы файлов, рассчитанные по алгоритму расчета CRC32 (а не по MD5, как было ранее). Для подсчета значений контрольной суммы возможно применение специализированных программных средств, например, HashTab и другие, находящиеся в свободном доступе. Также в личном кабинете заявителя Единой цифровой платформы экспертизы реализован функционал для расчета контрольной суммы файлов, контрольная сумма файла отображается рядом с размером файла.

Простой расчет контрольной суммы

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

Чтобы упростить алгоритм, без потери качества, нужно немного «битовой магии», что интересная тема сама по себе.

Без контрольной суммы, передавать данные опасно, так как помехи присутствуют везде и всегда, весь вопрос только в их вероятности возникновения и вызываемых ими побочных эффектах. В зависимости от условий и выбирается алгоритм выявления ошибок и количество данных в контрольной сумме. Сложнее алгоритм, и больше контрольная сумма, меньше не распознанных ошибок.

Причина помех на физическом уровне, при передаче данных.

Вот пример самого типичного алгоритма для микроконтроллера, ставшего, фактически, промышленным стандартом с 1979 года.

Расчет контрольной суммы для протокола Modbus

void crc_calculating(unsigned char puchMsg, unsigned short usDataLen) /*##Расчёт контрольной суммы##*/ < < unsigned char uchCRCHi = 0xFF ; /* Инициализация последнего байта CRC */ unsigned char uchCRCLo = 0xFF ; /* Инициализация первого байта CRC */ unsigned uIndex ; /* will index into CRC lookup table */ while (usDataLen--) /* pass through message buffer */ < uIndex = uchCRCHi ^ *puchMsg++ ; /* Расчёт CRC */ uchCRCLo = uchCRCLo ^ auchCRCHi[uIndex] ; uchCRCHi = auchCRCLo[uIndex] ; >return (uchCRCHi ; /* Table of CRC values for low–order byte */ static char auchCRCLo[] = < 0x00, 0xC0, 0xC1, 0x01, 0xC3, 0x03, 0x02, 0xC2, 0xC6, 0x06, 0x07, 0xC7, 0x05, 0xC5, 0xC4, 0x04, 0xCC, 0x0C, 0x0D, 0xCD, 0x0F, 0xCF, 0xCE, 0x0E, 0x0A, 0xCA, 0xCB, 0x0B, 0xC9, 0x09, 0x08, 0xC8, 0xD8, 0x18, 0x19, 0xD9, 0x1B, 0xDB, 0xDA, 0x1A, 0x1E, 0xDE, 0xDF, 0x1F, 0xDD, 0x1D, 0x1C, 0xDC, 0x14, 0xD4, 0xD5, 0x15, 0xD7, 0x17, 0x16, 0xD6, 0xD2, 0x12, 0x13, 0xD3, 0x11, 0xD1, 0xD0, 0x10, 0xF0, 0x30, 0x31, 0xF1, 0x33, 0xF3, 0xF2, 0x32, 0x36, 0xF6, 0xF7, 0x37, 0xF5, 0x35, 0x34, 0xF4, 0x3C, 0xFC, 0xFD, 0x3D, 0xFF, 0x3F, 0x3E, 0xFE, 0xFA, 0x3A, 0x3B, 0xFB, 0x39, 0xF9, 0xF8, 0x38, 0x28, 0xE8, 0xE9, 0x29, 0xEB, 0x2B, 0x2A, 0xEA, 0xEE, 0x2E, 0x2F, 0xEF, 0x2D, 0xED, 0xEC, 0x2C, 0xE4, 0x24, 0x25, 0xE5, 0x27, 0xE7, 0xE6, 0x26, 0x22, 0xE2, 0xE3, 0x23, 0xE1, 0x21, 0x20, 0xE0, 0xA0, 0x60, 0x61, 0xA1, 0x63, 0xA3, 0xA2, 0x62, 0x66, 0xA6, 0xA7, 0x67, 0xA5, 0x65, 0x64, 0xA4, 0x6C, 0xAC, 0xAD, 0x6D, 0xAF, 0x6F, 0x6E, 0xAE, 0xAA, 0x6A, 0x6B, 0xAB, 0x69, 0xA9, 0xA8, 0x68, 0x78, 0xB8, 0xB9, 0x79, 0xBB, 0x7B, 0x7A, 0xBA, 0xBE, 0x7E, 0x7F, 0xBF, 0x7D, 0xBD, 0xBC, 0x7C, 0xB4, 0x74, 0x75, 0xB5, 0x77, 0xB7, 0xB6, 0x76, 0x72, 0xB2, 0xB3, 0x73, 0xB1, 0x71, 0x70, 0xB0, 0x50, 0x90, 0x91, 0x51, 0x93, 0x53, 0x52, 0x92, 0x96, 0x56, 0x57, 0x97, 0x55, 0x95, 0x94, 0x54, 0x9C, 0x5C, 0x5D, 0x9D, 0x5F, 0x9F, 0x9E, 0x5E, 0x5A, 0x9A, 0x9B, 0x5B, 0x99, 0x59, 0x58, 0x98, 0x88, 0x48, 0x49, 0x89, 0x4B, 0x8B, 0x8A, 0x4A, 0x4E, 0x8E, 0x8F, 0x4F, 0x8D, 0x4D, 0x4C, 0x8C, 0x44, 0x84, 0x85, 0x45, 0x87, 0x47, 0x46, 0x86, 0x82, 0x42, 0x43, 0x83, 0x41, 0x81, 0x80, 0x40 >; > > 

Не слабый такой код, есть вариант без таблицы, но более медленный (необходима побитовая обработка данных), в любом случае способный вынести мозг как программисту, так и микроконтроллеру. Не во всякий микроконтроллер алгоритм с таблицей влезет вообще.

Давайте разберем алгоритмы, которые вообще могут подтвердить целостность данных невысокой ценой.

Бит четности (1-битная контрольная сумма)

На первом месте простой бит четности. При необходимости формируется аппаратно, принцип простейший, и подробно расписан в википедии. Недостаток только один, пропускает двойные ошибки (и вообще четное число ошибок), когда четность всех бит не меняется. Можно использовать для сбора статистики о наличии ошибок в потоке передаваемых данных, но целостность данных не гарантирует, хотя и снижает вероятность пропущенной ошибки на 50% (зависит, конечно, от типа помех на линии, в данном случае подразумевается что число четных и нечетных сбоев равновероятно).
Для включения бита четности, часто и код никакой не нужен, просто указываем что UART должен задействовать бит четности. Типично, просто указываем:

включение бита четности на микроконтроллере

void setup() < Serial.begin(9600,SERIAL_8N1); // по умолчанию, бит четности выключен; Serial1.begin(38400,SERIAL_8E1); // бит четности включен Serial.println("Hello Computer"); Serial1.println("Hello Serial 1"); >

Часто разработчики забывают даже, что UART имеет на борту возможность проверки бита четности. Кроме целостности передаваемых данных, это позволяет избежать устойчивого срыва синхронизации (например при передаче данных по радиоканалу), когда полезные данные могу случайно имитировать старт и стоп биты, а вместо данных на выходе буфера старт и стоп биты в случайном порядке.

8-битная контрольная сумма

Если контроля четности мало (а этого обычно мало), добавляется дополнительная контрольная сумма. Рассчитать контрольную сумму, можно как сумму ранее переданных байт, просто и логично

Естественно биты переполнения не учитываем, результат укладываем в выделенные под контрольную сумму 8 бит. Можно пропустить ошибку, если при случайном сбое один байт увеличится на некоторое значение, а другой байт уменьшится на то же значение. Контрольная сумма не изменится. Проведем эксперимент по передаче данных. Исходные данные такие:

  1. Блок данных 8 байт.
  2. Заполненность псевдослучайными данными Random($FF+1)
  3. Случайным образом меняем 1 бит в блоке данных операцией XOR со специально подготовленным байтом, у которого один единичный бит на случайной позиции.
  4. Повторяем предыдущий пункт 10 раз, при этом может получится от 0 до 10 сбойных бит (2 ошибки могут накладываться друг на друга восстанавливая данные), вариант с 0 сбойных бит игнорируем в дальнейшем как бесполезный для нас.

на 256 отправленных телеграмм с ошибкой, одна пройдет проверку контрольной суммы. Смотрим статистику от виртуальной передачи данных, с помощью простой тестовой программы:

Статистика

1: 144 (тут и далее — вероятность прохождения ошибки)
1: 143
1: 144
1: 145
1: 144
1: 142
1: 143
1: 143
1: 142
1: 140
Общее число ошибок 69892 из 10 млн. итераций, или 1: 143.078

Или условный КПД=55%, от возможностей «идеальной» контрольной суммы. Такова плата за простоту алгоритма и скорость обработки данных. В целом, для многих применений, алгоритм работоспособен. Используется одна операция сложения и одна переменная 8-битовая. Нет возможности не корректной реализации. Поэтому алгоритм и применяется в контроллерах ADAMS, ICP, в составе протокола DCON (там дополнительно может быть включен бит четности, символы только ASCI, что так же способствует повышению надежности передачи данных и итоговая надежность несколько выше, так как часть ошибок выявляется по другим, дополнительным признакам, не связанных с контрольной суммой).

Не смотря на вероятность прохождения ошибки 1:143, вероятность обнаружения ошибки лучше, чем 1:256 невозможна теоретически. Потери в качестве работы есть, но не всегда это существенно. Если нужна надежность выше, нужно использовать контрольную сумму с большим числом бит. Или, иначе говоря, простая контрольная сумма, недостаточно эффективно использует примерно 0.75 бита из 8 имеющихся бит информации в контрольной сумме.

Для сравнения применим, вместо суммы, побитовое сложение XOR. Стало существенно хуже, вероятность обнаружения ошибки 1:67 или 26% от теоретического предела. Упрощенно, это можно объяснить тем, что XOR меняет при возникновении ошибке еще меньше бит в контрольной сумме, ниже отклик на единичный битовый сбой, и повторной ошибке более вероятно вернуть контрольную сумму в исходное состояние.

Так же можно утверждать, что контрольная сумма по XOR представляет из себя 8 независимых контрольных сумм из 1 бита. Вероятность того, что ошибка придется на один из 8 бит равна 1:8, вероятность двойного сбоя 1:64, что мы и наблюдаем, теоретическая величина совпала с экспериментальными данными.

Нам же нужен такой алгоритм, чтобы заменял при единичной ошибке максимальное количество бит в контрольной сумме. Но мы, в общей сложности, ограниченны сложностью алгоритма, и ресурсами в нашем распоряжении. Не во всех микроконтроллерах есть аппаратный блок расчета CRC. Но, практически везде, есть блок умножения. Рассчитаем контрольную сумму как произведение последовательности байт, на некоторую «магическую» константу:

CRC=CRC + byte*211 

Константа должна быть простой, и быть достаточно большой, для изменения большего числа бит после каждой операции, 211 вполне подходит, проверяем:

Статистика
1: 185
1: 186
1: 185
1: 185
1: 193
1: 188
1: 187
1: 194
1: 190
1: 200

Всего 72% от теоретического предела, небольшое улучшение перед простой суммой. Алгоритм в таком виде не имеет смысла. В данном случае теряется важная информация из отбрасываемых старших 8..16 бит, а их необходимо учитывать. Проще всего, смешать функцией XOR с младшими битами 1..8. Приходим к еще более интенсивной модификации контрольной суммы, желательно с минимальным затратами ресурсов. Добавляем фокус из криптографических алгоритмов

CRC=CRC + byte*211 CRC= CRC XOR (CRC SHR 8); // "миксер" битовый, далее его применяем везде CRC=CRC AND $FF; //или просто возвращаем результат как 8, а не 16 бит 
  • Промежуточная CRC для первого действия 16-битная (после вычислений обрезается до 8 бит) и в дальнейшем работаем как с 8-битной, если у нас 8-битный микроконтроллер это ускорит обработку данных.
  • Возвращаем старшие биты и перемешиваем с младшими.

Статистика
1: 237
1: 234
1: 241
1: 234
1: 227
1: 238
1: 235
1: 233
1: 231
1: 236

Результат 91% от теоретического предела. Вполне годится для применения.

Если в микроконтроллере нет блока умножения, можно имитировать умножение операций сложения, смещения и XOR. Суть процесса такая же, модифицированный ошибкой бит, равномерно «распределяется» по остальным битам контрольной суммы.

CRC := (CRC shl 3) + byte; CRC := (CRC shl 3) + byte; CRC:=(CRC XOR (CRC SHR 8)) ; // как и в предыдущем алгоритме 

Статистика
1: 255
1: 257
1: 255
1: 255
1: 254
1: 255
1: 250
1: 254
1: 256
1: 254

На удивление хороший результат. Среднее значение 254,5 или 99% от теоретического предела, операций немного больше, но все они простые и не используется умножение.

Если для внутреннего хранения промежуточных значений контрольной суммы отдать 16 бит переменную (но передавать по линии связи будем только младшие 8 бит), что не проблема даже для самого слабого микроконтроллера, получим некоторое улучшение работы алгоритма. В целом экономить 8 бит нет особого смысла, и 8-битовая промежуточная переменная использовалась ранее просто для упрощения понимания работы алгоритма.

Статистика
1: 260
1: 250
1: 252
1: 258
1: 261
1: 255
1: 254
1: 261
1: 264
1: 262

Что соответствует 100.6% от теоретического предела, вполне хороший результат для такого простого алгоритма из одной строчки:

CRC:=CRC + byte*44111; // все переменные 16-битные 

Используется полноценное 16-битное умножение. Опять же не обошлось без магического числа 44111 (выбрано из общих соображений без перебора всего подмножества чисел). Более точно, константу имеет смысл подбирать, только определившись с предполагаемым типом ошибок в линии передачи данных.

Столь высокий результат объясняется тем, что 2 цикла умножения подряд, полностью перемешивают биты, что нам и требовалось. Исключением, похоже, является последний байт телеграммы, особенно его старшие биты, они не полностью замешиваются в контрольную сумму, но и вероятность того, что ошибка придется на них невелика, примерно 4%. Эта особенность практически ни как не проявляется статистически, по крайней мере на моем наборе тестовых данных и ошибке ограниченной 10 сбойными битами. Для исключения этой особенности можно делать N+1 итераций, добавив виртуальный байт в дополнение к имеющимся в тестовом блоке данных (но это усложнение алгоритма).

Вариант без умножения с аналогичным результатом. Переменная CRC 16-битная, данные 8-битные, результат работы алгоритма — младшие 8 бит найденной контрольной суммы:

CRC := (CRC shl 2) + CRC + byte; CRC := (CRC shl 2) + CRC + byte; CRC:=(CRC XOR (CRC SHR 8)); 

Результат 100.6% от теоретического предела.

Вариант без умножения более простой, оставлен самый минимум функций, всего 3 математических операции:

CRC:=byte + CRC; CRC:=CRC xor (CRC shr 2); 

Результат 86% от теоретического предела.

В этом случае потери старших бит нет, они возвращаются в младшую часть переменной через функцию XOR (битовый миксер).

Небольшое улучшение в некоторых случаях дает так же:

  • Двойной проход по обрабатываемым данным. Но ценой усложнения алгоритма (внешний цикл нужно указать), ценой удвоения времени обработки данных.
  • Обработка дополнительного, виртуального байта в конце обрабатываемых данных, усложнения алгоритма и времени работы алгоритма практически нет.
  • Использование переменной для хранения контрольной суммы большей по разрядности, чем итоговая контрольная сумма и перемешивание младших бит со старшими.
16-битная контрольная сумма

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

Следующий вариант 16 бит, и теоретическая вероятность ошибки переданных данных 1:65536, что намного лучше. Надежность растет по экспоненте. Но, как побочный эффект, растет количество вспомогательных данных, на примере нашей телеграммы, к 8 байтам полезной информации добавляется 2 байта контрольной суммы.

Простые алгоритмы суммы и XOR, применительно к 16-битной и последующим CRC не рассматриваем вообще, они практически не улучают качество работы, по сравнению с 8-битным вариантов.

Модифицируем алгоритм для обработки контрольной суммы разрядностью 16 бит, надо отметить, что тут так же есть магическое число 8 и 44111, значительное и необоснованное их изменение ухудшает работу алгоритма в разы.

CRC:=CRC + byte16*44111; //все данные 16-битные CRC:=CRC XOR (CRC SHR 8); 

Статистика
1: 43478
1: 76923
1: 83333
1: 50000
1: 83333
1: 100000
1: 90909
1: 47619
1: 50000
1: 90909

Что соответствует 109% от теоретического предела. Присутствует ошибка измерений, но это простительно для 10 млн. итераций. Так же сказывается алгоритм создания, и вообще тип ошибок. Для более точного анализа, в любом случае нужно подстраивать условия под ошибки в конкретной линии передачи данных.

Дополнительно отмечу, что можно использовать 32-битные промежуточные переменные для накопления результата, а итоговую контрольную сумму использовать как младшие 16 бит. Во многих случаях, при любой разрядности контрольной суммы, так несколько улучшается качество работы алгоритма.

32-битная контрольная сумма

Перейдем к варианту 32-битной контрольной суммы. Появляется проблема со временем отводимым для анализа статистических данных, так как число переданных телеграмм уже сравнимо с 2^32. Алгоритм такой же, магические числа меняются в сторону увеличения

CRC:=CRC+byte32*$990C9AB5; CRC:=CRC XOR (CRC SHR 16); 

За 10 млн. итераций ошибка не обнаружена. Чтобы ускорить сбор статистики обрезал CRC до 24 бит:

CRC = CRC AND $FFFFFF; 

Результат, из 10 млн. итераций ошибка обнаружена 3 раза

Статистика
1: 1000000
1: no
1: no
1: no
1: 1000000
1: no
1: 1000000
1: no
1: no
1: no

Вполне хороший результат и в целом близок к теоретическому пределу для 24 бит контрольной суммы (1:16777216). Тут надо отметить что функция контроля целостности данных равномерно распределена по всем битам CRC, и вполне возможно их отбрасывание с любой стороны, если есть ограничение на размер передаваемой CRC.

Для полноценных 32 бит, достаточно долго ждать результата, ошибок просто нет, за приемлемое время ожидания.

Вариант без умножения:

CRC := (CRC shl 5) + CRC + byte; CRC := (CRC shl 5) + CRC; CRC:=CRC xor (CRC shr 16); 

Сбоя для полноценной контрольной суммы дождаться не получилось. Контрольная сумма урезанная до 24 бит показывает примерно такие же результаты, 8 ошибок на 100 млн. итераций. Промежуточная переменная CRC 64-битная.

64-битная контрольная сумма

Ну и напоследок 64-битная контрольная сумма, максимальная контрольная сумма, которая имеет смысл при передачи данных на нижнем уровне:

CRC:=CRC+byte64*$5FB7D03C81AE5243; CRC:=CRC XOR (CRC SHR 8); // магическое число 1..20 

Дождаться ошибки передачи данных, до конца существования вселенной, наверное не получится 🙂

Метод аналогичный тому, какой применили для CRC32 показал аналогичные результаты. Больше бит оставляем, выше надежность в полном соответствии с теоретическим пределом. Проверял на младших 20 и 24 битах, этого кажется вполне достаточным, для оценки качества работы алгоритма.

Так же можно применить для 128-битных чисел (и еще больших), главное подобрать корректно 128-битные магические константы. Но это уже явно не для микроконтроллеров, такие числа и компилятор не поддерживает.

Комментарии

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

Рекомендую к использованию в микроконтроллерах, или для проверки целостности любых переданных данных. Вполне рабочий метод, уже как есть, не смотря на простоту алгоритма.

Мой проект по исследованию CRC на гитхаб.

Далее интересно было бы оптимизировать алгоритм на более реальных данных (не псевдослучайные числа по стандартному алгоритму), подобрать более подходящие магические числа под ряд задач и начальных условий, думаю можно еще выиграть доли процента по качеству работы алгоритма. Оптимизировать алгоритм по скорости, читаемости кода (простоте алгоритма), качеству работы. В идеале получить и протестировать образцы кода для всех типов микроконтроллеров, для этого как-раз и нужны примеры с использованием умножения 8, 16, 32 битных данных, и без умножения вообще.

  • Промышленное программирование
  • Программирование микроконтроллеров

Как посчитать контрольную сумму CRC32, CRC16, CRC8

Print Friendly, PDF & Email

Как посчитать контрольную сумму CRC32, CRC16, CRC8

В интернете существует большое количество вариантов расчёта контрольной суммы CRC. Но что же собственно такое контрольная сумма и почему она рассчитывается именно так? Давайте разберёмся. А заодно напишем программу, которая будет рассчитывать CRC с заданными параметрами.

1 Теория, лежащая в основе расчёта CRC

Для начала давайте немного разберёмся в теории. Итак, что же такое CRC ? Если кратко, это одна из разновидностей подсчёта контрольной суммы. Контрольная сумма – это метод проверки целостности принятой информации на стороне приёмника при передаче по каналам связи. Например, одна из простейших проверок – использование бита чётности. Это когда суммируются все биты передаваемого сообщения, и если сумма оказывается чётной, то в конец сообщения добавляется 0, если нечётной – то 1. При приёме также подсчитывается сумма битов сообщения, и сравнивается с принятым битом чётности. Если они отличаются, значит при передаче возникли ошибки, и передаваемая информация была искажена.

Но такой способ определения наличия ошибок – очень неинформативный и срабатывает не всегда, т.к. при искажении нескольких битов сообщения, чётность суммы может не измениться. Поэтому существует множество более «продвинутых» проверок, в том числе CRC.

По сути, CRC – это не сумма, а результат деления некого объёма информации (информационного сообщения) на константу, а точнее – остаток от деления сообщения на константу. Тем не менее, CRC исторически также называют «контрольная сумма». В значение CRC вносит вклад каждый бит сообщения. То есть, если хотя бы один бит исходного сообщения изменится при передаче, контрольная сумма тоже изменится, причём существенно. Это большой плюс такой проверки, так как он позволяет однозначно определить, исказилось исходное сообщение при передаче или нет.

Что такое исходное сообщение – понятно. Это непрерывная последовательность битов произвольной длины.

Что за константа, на которую мы должны делить исходное сообщение? Это некоторое число также любой длины, но обычно используются числа, кратные 1 байту – 8, 16 или 32 бита. Просто так легче считать, ведь компьютеры работают именно с байтами, а не с битами.

Константу-делитель обычно записывают в виде полинома (многочлена) вот таким образом: x 8 + x 2 + x 1 + x 0 . Здесь степень числа «x» означает позицию бита-единицы в числе, начиная с нулевой, а старший разряд указывает на степень полинома и отбрасывается при интерпретации числа. То есть записанное ранее число – это не что иное как 100000111 в двоичной системе счисления.

Обычно при записи многочлена старший разряд подразумевается, но не пишется. То есть вышеуказанный многочлен можно было бы записать в двоичной системе как (1)00000111. В скобках я указал подразумеваемый старший разряд числа. Поэтому говорят, что многочлен равен 7 в десятичной системе счисления (111b = 7d).

Вот ещё пример: (x 16 +) x 15 + x 2 + x 0 = (1)1000000000000101 = 0x8005 = 32773.

Обычно используются некие стандартные многочлены для разных типов CRC. Вот некоторые из них:

Алгоритм CRC Образующий многочлен
CRC-16 0x8005
CRC-16-CCITT 0x1021
CRC-16-DNP 0x3D65
CRC-32-IEEE 802.3 0x04C11DB7
CRC-32C 0x1EDC6F41
CRC-32K 0x741B8CD7

В посвящённой расчёту CRC статье на Википедии есть большая таблица образующих полиномов.

Так как же считать контрольную сумму? Существует базовый метод – деление сообщения на полином «в лоб» – и его модификации в целях уменьшения количества вычислений и, соответственно, ускорения расчёта CRC. Для начала мы рассмотрим именно базовый метод.

В общем виде деление числа на многочлен выполняется по такому алгоритму. Алгоритм вычисления контрольной суммы CRC:

  1. Создаётся массив (регистр), заполненный нулями, равный по длине разрядности (степени) полинома.
  2. Исходное сообщение дополняется нулями в младших разрядах, в количестве, равном числу разрядов полинома.
  3. В младший разряд регистра заносится один старший бит сообщения, а из старшего разряда регистра выдвигается один бит.
  4. Если выдвинутый бит равен «1», то производится инверсия битов (операция XOR, исключающее ИЛИ) в тех разрядах регистра, которые соответствуют единицам в полиноме.
  5. Если в сообщении ещё есть биты, переходим к шагу 3).
  6. Когда все биты сообщения поступили в регистр и были обработаны этим алгоритмом, в регистре остаётся остаток от деления, который и является контрольной суммой CRC.

Назовём этот метод расчёта CRC метод побитового сдвига или простой метод.

Рисунок иллюстрирует деление исходной последовательности битов на число (1)00000111, или многочлен x 8 + x 2 + x 1 + x 0 .

Схематичное представление вычисления CRC

Кстати, проверить правильность расчёта CRC очень просто. В пункте (2) описанного алгоритма мы должны вместо дополнения исходного сообщения нулями дополнить его битами рассчитанной контрольной суммы, а остальное оставить как есть. Теперь остаток от деления дополненного сообщения на полином должен равняться нулю – это и есть признак верно рассчитанной контрольной суммы. Отличный от нуля остаток свидетельствует об ошибке.

Осталась ещё пара моментов, о которых стоит сказать. Как вы могли заметить, сообщение можно разделить на любое число. Как его выбрать? Существует ряд стандартных полиномов, которые используются при вычислении CRC. Например, для CRC32 это может быть число 0x04C11DB7, а для CRC16 это может быть 0x8005.

Кроме того, в регистр в начале вычислений можно записать не нули, а какое-то другое число. (И это рекомендуется делать: так повышается надёжность определения начала передачи сообщения, если, например, сообщение имеет в начале нулевые биты).

Также при расчётах непосредственно перед выдачей финальную контрольную сумму CRC можно поделить на какое-то другое число.

И последнее. Байты сообщения при записи в регистр могут помещаться как старшим битом «вперёд», так и наоборот, младшим. И результирующая CRC также может выдаваться, начиная со старшего бита или с младшего.

Изменение порядка битов в байте на обратный назовём «обращение», «реверс» или «отзеркаливание» байта.

Итого имеются 6 параметров, которые влияют на значение контрольной суммы:

  • порядок CRC;
  • образующий многочлен (его иногда называют «генераторный полином», переводя с английского буквально);
  • начальное содержимое регистра;
  • значение, с которым производится финальное XOR;
  • реверс байтов информационного сообщения;
  • реверс байтов CRC перед финальным XOR.

2 Расчёт контрольной суммы CRC методом побитового сдвига

На основании всего вышеизложенного, давайте напишем функцию на языке Visual Basic .NET, которая будет рассчитывать контрольную сумму CRC, принимая ряд параметров, которые я описал выше, и возвращая значение CRC в виде 32-разрядного беззнакового числа.

Код расчёта CRC методом побитового сдвига на языке VB.NET

''' ''' Возвращает контрольную сумму типа CRC, рассчитанную методом побитового сдвига. ''' ''' Входная последовательность байтов (исходное сообщение). ''' Образующий многочлен разрядности width. ''' Порядок CRC в битах, 8/16/32. Public Shared Function GetCrc_Simple(ByVal bytes As Byte(), ByVal poly As UInteger, Optional ByVal width As Integer = 32, Optional ByVal initReg As UInteger = &HFFFFFFFFUI, Optional ByVal finalXor As UInteger = &HFFFFFFFFUI, Optional ByVal reverseBytes As Boolean = True, Optional ByVal reverseCrc As Boolean = True) As UInteger Dim widthInBytes As Integer = width \ 8 'Дополняем сообщение width нулями (расчёт в байтах): ReDim Preserve bytes(bytes.Length - 1 + widthInBytes) 'Создаём очередь битов из сообщения: Dim msgFifo As New Queue(Of Boolean)(bytes.Count * 8 - 1) For Each b As Byte In bytes Dim ba As New BitArray() If reverseBytes Then For i As Integer = 0 To 7 msgFifo.Enqueue(ba(i)) Next Else For i As Integer = 7 To 0 Step -1 msgFifo.Enqueue(ba(i)) Next End If Next 'Создаём очередь из битов начального заполнения регистра: Dim initBytes As Byte() = BitConverter.GetBytes(initReg) Dim initBytesReversed As IEnumerable(Of Byte) = (From b As Byte In initBytes Take widthInBytes).Reverse Dim initFifo As New Queue(Of Boolean)(width - 1) For Each b As Byte In initBytesReversed Dim ba As New BitArray() If Not reverseBytes Then For i As Integer = 0 To 7 initFifo.Enqueue(ba(i)) Next Else For i As Integer = 7 To 0 Step -1 initFifo.Enqueue(ba(i)) Next End If Next 'Сдвиг и XOR: Dim register As UInteger = 0 'заполняем width-разрядный регистр нулями. Do While msgFifo.Count > 0 Dim poppedBit As Integer = CInt(register >> (width - 1)) And 1 'определить перед сдвигом регистра. Dim shiftedBit As Byte = Convert.ToByte(msgFifo.Dequeue) If initFifo.Count > 0 Then Dim b As Byte = Convert.ToByte(initFifo.Dequeue) shiftedBit = shiftedBit Xor b End If register = register > (32 - width)) 'маскируем младшие разряды. Return crc End Function ''' ''' Обращает заданное число младших битов переданного числа. ''' ''' Число, которое требуется «отзеркалить». ''' Сколько младших битов обратить, 0..32. ''' ''' Например: reflect(&H3E23, 3) == &H3E26. Private Shared Function reflect(ByVal inpValue As UInteger, Optional ByVal bitsToReflect As Integer = 32) As UInteger Dim t As UInteger = inpValue Dim reflected As UInteger = inpValue For i As Integer = 0 To bitsToReflect - 1 Dim bm As UInteger = bitMask(bitsToReflect - 1 - i) If (t And 1) = 1 Then reflected = reflected Or bm Else reflected = reflected And Not bm End If t >>= 1 Next Return reflected End Function ''' ''' Возвращает наибольший разряд числа. ''' ''' Число, разрядность которого следует определить. ''' Private Shared Function bitMask(ByVal number As Integer) As UInteger Dim res As UInteger = (1UI End Function 

Как вы могли заметить, в данной реализации расчёта CRC используется LINQ , так что соответствующая ссылка должна быть добавлена в проект.

Предлагаемая программа плохо масштабируема. То есть она работает хорошо при вычислении контрольной суммы CRC для коротких сообщений, длиной до нескольких десятков килобайтов. Я писал её с целью только продемонстрировать работу простого алгоритма, и не занимался оптимизацией. При расчёте CRC для длинного сообщения, размером десятки или сотни мегабайтов, программа будет сильно загружать процессор и память, т.к. всё сообщение целиком загружается в очередь. Этому способствует метод преобразования числа в битовую последовательность, используя Queue(Of Boolean). Для работы с такими большими сообщениями желательно реализовать промежуточный буфер, который будет передавать сообщение в программу небольшими порциями.

Зато у этой программы есть одно преимущество: она может быть использована для расчёта CRC любого порядка, не обязательно 8, 16 или 32. Это может быть CRC5 или CRC49. Только для чисел больше 32-х разрядов нужно изменить соответствующим образом входные параметры – допустим, poly передавать не как UInteger, а как ULong, или передавать его в виде битового массива (тогда теоретически порядок CRC вообще будет неограничен).

3 Расчёт контрольной суммы CRC табличным методом

Для сокращения числа вычислений из предыдущего метода – метода побитового сдвига – придуманы некоторые оптимизации.

В частности, сдвигают не по одному биту за раз, а сразу по несколько. Наибольшую популярность снискали варианты, в которых сообщение сдвигается на число битов, кратное числу битов в байте: 8, 16 или 32, т.к. с байтами легче работать (не нужны дополнительные преобразования). При этом идея алгоритма осталась та же: сдвиг и исключающее ИЛИ с содержимым регистра.

Кроме того, оказывается, что часть расчётов можно провести заранее и записать в массив – таблицу, из которой по мере необходимости будет браться нужное число. Такой метод расчёта назвали табличный метод расчёта CRC.

Я не буду здесь вдаваться в теорию, она довольно сложна и много раз описана в других статьях. В частности, очень хорошее и подробное описание бинарной арифметики, лежащей в основе расчёта CRC, и описание табличного метода, даётся в статье Ross N. Williams: «A Painless Guide to CRC Error Detection Algorithms». Рекомендую к прочтению обязательно! Оригинальный текст – в приложении к статье, а русский перевод легко найти в интернете.

Ну что же, пришло время для самой программы. Она будет несколько длиннее предыдущей. По сути, это реализация алгоритма из указанной статьи в стиле объектно-ориентированного программирования. Опять же будем писать программу на моём любимом языке программирования VB.NET. Я назвал этот класс RocksoftCrcModel, по названию компании, в которой работал автор указанной статьи.

Код расчёта CRC табличным методом на языке VB.NET

''' ''' Реализует алгоритм расчёта CRC методом Rocksoft^tm Model CRC. ''' Public Class RocksoftCrcModel #Region "PROPS AND FIELDS" ''' ''' Таблица предвычисленных значений для расчёта контрольной суммы. ''' Public ReadOnly CrcLookupTable(255) As UInteger ''' ''' Порядок CRC, в битах (строго 8, 16 или 32). ''' Изменение этого свойства ведёт к пересчёту таблицы. ''' Public Property CrcWidth As Integer Get Return _CrcWidth End Get Set(value As Integer) If _CrcWidth <> value Then _CrcWidth = value _TopBit = getBitMask(_CrcWidth - 1) _WidMask = (((1UI ''' Образующий многочлен. ''' Изменение этого свойства ведёт к пересчёту таблицы. ''' Public Property Polynom As UInteger Get Return _Polynom End Get Set(value As UInteger) If _Polynom <> value Then _Polynom = value generateLookupTable() End If End Set End Property Private _Polynom As UInteger = &H4C11DB7 ''' ''' Обращать ли байты сообщения? ''' Изменение этого свойства ведёт к пересчёту таблицы. ''' Public Property ReflectIn As Boolean Get Return _ReflectIn End Get Set(value As Boolean) If _ReflectIn <> value Then _ReflectIn = value generateLookupTable() End If End Set End Property Private _ReflectIn As Boolean = True ''' ''' Начальное содержимое регистра. ''' Public Property InitRegister As UInteger Get Return _InitRegister End Get Set(value As UInteger) If _InitRegister <> value Then _InitRegister = value End If End Set End Property Private _InitRegister As UInteger = &HFFFFFFFFUI ''' ''' Обращать выходное значение CRC? ''' Public Property ReflectOut As Boolean Get Return _ReflectOut End Get Set(value As Boolean) If _ReflectOut <> value Then _ReflectOut = value End If End Set End Property Private _ReflectOut As Boolean = True ''' ''' Значение, с которым XOR-ится выходное значение CRC. ''' Public Property XorOut As UInteger Get Return _XorOut End Get Set(value As UInteger) If _XorOut <> value Then _XorOut = value End If End Set End Property Private _XorOut As UInteger = &HFFFFFFFFUI #End Region '/PROPS AND FIELDS #Region "READ-ONLY PROPS" ''' ''' Возвращает старший разряд полинома. ''' ReadOnly Property TopBit As UInteger Get Return _TopBit End Get End Property Private _TopBit As UInteger = getBitMask(CrcWidth - 1) ''' ''' Возвращает длинное слово со значением (2^width)-1. ''' Private ReadOnly Property WidMask As UInteger Get Return _WidMask End Get End Property Private _WidMask As UInteger = (((1UI ''' Конструктор, инициализированный параметрами по умолчанию для алгоритма CRC32. ''' Public Sub New() generateLookupTable() End Sub ''' ''' Инициализирует новый экземпляр параметрической модели CRC с настраиваемыми параметрами. ''' ''' Разрядность контрольной суммы в битах. ''' Полином. ''' начальное содержимое регистра. ''' Обращать ли входящие байты сообщения? ''' Обратить ли CRC перед финальным XOR. ''' Конечное значение XOR. Public Sub New(ByVal width As Integer, ByVal poly As UInteger, Optional ByVal initReg As UInteger = &HFFFFFFFFUI, Optional ByVal isReflectIn As Boolean = True, Optional ByVal isReflectOut As Boolean = True, Optional ByVal xorOut As UInteger = &HFFFFFFFFUI) Me.CrcWidth = width Me.Polynom = poly Me.InitRegister = initReg Me.ReflectIn = isReflectIn Me.ReflectOut = isReflectOut Me.XorOut = xorOut generateLookupTable() End Sub #End Region '/CTOR #Region "ВЫЧИСЛЕНИЕ CRC" ''' ''' Вычисляет значение контрольной суммы переданного сообщения. ''' ''' Исходное сообщение, для которого нужно посчитать контрольную сумму. Public Function ComputeCrc(ByRef message As Byte()) As UInteger Dim registerContent As UInteger = InitRegister 'Содержимое регистра в процессе пересчёта CRC. For Each b As Byte In message registerContent = getNextRegisterContent(registerContent, b) Next Dim finalCrc As UInteger = getFinalCrc(registerContent) Return finalCrc End Function ''' ''' Вычисляет значение контрольной суммы переданного сообщения и возвращает его в виде массива байтов. ''' ''' Исходное сообщение, для которого нужно посчитать контрольную сумму. Public Function ComputeCrcAsBytes(ByRef message As Byte()) As Byte() Dim crc As UInteger = ComputeCrc(message) Dim crcBytes As Byte() = BitConverter.GetBytes(crc) Dim crcBytesOrdered(crcBytes.Length - 1) As Byte For i As Integer = 0 To crcBytes.Length - 1 crcBytesOrdered(i) = crcBytes(crcBytes.Length - 1 - i) Next Return crcBytesOrdered End Function ''' ''' Обрабатывает один байт сообщения (0..255). ''' ''' Содержимое регистра на предыдущем шаге. ''' Значение очередного байта из сообщения. Private Function getNextRegisterContent(ByVal prevRegContent As UInteger, ByVal value As Byte) As UInteger Dim uValue As UInteger = value If ReflectIn Then uValue = reflect(uValue, 8) End If Dim reg As UInteger = prevRegContent reg = reg Xor (uValue End Function ''' ''' Возвращает значение CRC для обработанного сообщения. ''' ''' Значение регистра до финального обращения и XORа. Private Function getFinalCrc(ByVal regContent As UInteger) As UInteger If ReflectOut Then Dim res As UInteger = XorOut Xor reflect(regContent, CrcWidth) Return res Else Dim res As UInteger = XorOut Xor regContent Return res End If End Function #End Region '/ВЫЧИСЛЕНИЕ CRC #Region "РАСЧЁТ ТАБЛИЦЫ" ''' ''' Вычисляет таблицу предвычисленных значений для расчёта контрольной суммы. ''' Private Sub generateLookupTable() For i As Integer = 0 To 255 CrcLookupTable(i) = generateTableItem(i) Next End Sub ''' ''' Рассчитывает один байт таблицы значений для расчёта контрольной суммы ''' по алгоритму Rocksoft^tm Model CRC Algorithm. ''' ''' Индекс записи в таблице, 0..255. Private Function generateTableItem(ByVal index As Integer) As UInteger Dim inbyte As UInteger = CUInt(index) If ReflectIn Then inbyte = reflect(inbyte, 8) End If Dim reg As UInteger = inbyte End Function #End Region '/РАСЧЁТ ТАБЛИЦЫ #Region "ВСПОМОГАТЕЛЬНЫЕ" ''' ''' Возвращает наибольший разряд числа. ''' ''' Число, разрядность которого следует определить, степень двойки. Private Function getBitMask(ByVal number As Integer) As UInteger Dim res As UInteger = 1UI End Function ''' ''' Обращает заданное число младших битов переданного числа. ''' ''' Число, которое требуется обратить («отзеркалить»). ''' Сколько младших битов числа обратить, 0..32. ''' Например: reflect(0x3E23, 3) == 0x3E26. Private Function reflect(ByVal value As UInteger, Optional ByVal bitsToReflect As Integer = 32) As UInteger Dim t As UInteger = value Dim reflected As UInteger = value For i As Integer = 0 To bitsToReflect - 1 Dim bm As UInteger = getBitMask(bitsToReflect - 1 - i) If (t And 1) = 1 Then reflected = reflected Or bm Else reflected = reflected And Not bm End If t >>= 1 Next Return reflected End Function #End Region '/ВСПОМОГАТЕЛЬНЫЕ End Class 

Этот код полностью готов к использованию, можно брать и применять. Пользоваться данной программой так:

  • создать экземпляр класса RocksoftCrcModel(), передав в конструктор параметры модели CRC;
  • для расчёта контрольной суммы, вызвать метод данного объекта ComputeCrc() или ComputeCrcAsBytes(), передав в качестве параметра информационное сообщение, для которого необходимо посчитать контрольную сумму;
  • если меняются параметры модели CRC, таблица автоматически пересчитывается, и новый экземпляр класса можно не создавать.

Приведу пример использования данного класса для алгоритма CRC16. В качестве сообщения message будем использовать массив байтов, который представляет собой строку «123456789» в коде ASCII, которая используется во многих онлайн-калькуляторах CRC:

Dim crcModel As New RocksoftCrcModel(16, &H8005, 0, True, True, 0) Dim message as Byte() = Dim crc As UInteger = crcModel.ComputeCrc(message)

Данная реализация расчёта CRC была проверена мною путём сличения со многими онлайн-калькуляторами CRC (назовём это «слабой» проверкой, именно такое определение дано в вышеуказанной статье, когда проверка осуществляется на основании сравнения рассчитанной контрольной суммы с эталонной, при одинаковых исходных параметрах и сообщении).

Для любителей C# перепишем данный класс таким образом:

Код расчёта CRC табличным методом на языке C# (разворачивается)

using System; namespace CRC < /// Реализует алгоритм расчёта CRC методом Rocksoft^tm Model CRC. public class RocksoftCrcModel < /// Таблица предвычисленных значений для расчёта контрольной суммы. public readonly uint[] CrcLookupTable; private int _CrcWidth; private uint _Polynom; private bool _ReflectIn; private uint _InitRegister; private bool _ReflectOut; private uint _XorOut; private uint _TopBit; private uint _WidMask; /// /// Порядок CRC, в битах (8/16/32). /// Изменение этого свойства ведёт к пересчёту таблицы. /// public int CrcWidth < get < return this._CrcWidth; >set < if (this._CrcWidth == value) return; this._CrcWidth = value; this._TopBit = this.getBitMask(checked (this._CrcWidth - 1)); this._WidMask = (uint) ((int) checked (unchecked ((uint) (1 > /// /// Образующий многочлен. /// Изменение этого свойства ведёт к пересчёту таблицы. /// public uint Polynom < get < return this._Polynom; >set < if ((int) this._Polynom == (int) value) return; this._Polynom = value; this.generateLookupTable(); >> /// /// Обращать байты сообщения? /// Изменение этого свойства ведёт к пересчёту таблицы. /// public bool ReflectIn < get < return this._ReflectIn; >set < if (this._ReflectIn == value) return; this._ReflectIn = value; this.generateLookupTable(); >> /// Начальное содержимое регистра. public uint InitRegister < get < return this._InitRegister; >set < if ((int) this._InitRegister == (int) value) return; this._InitRegister = value; >> /// Обращать выходное значение CRC? public bool ReflectOut < get < return this._ReflectOut; >set < if (this._ReflectOut == value) return; this._ReflectOut = value; >> /// Значение, с которым XOR-ится выходное значение CRC. public uint XorOut < get < return this._XorOut; >set < if ((int) this._XorOut == (int) value) return; this._XorOut = value; >> /// Возвращает старший разряд полинома. public uint TopBit < get < return this._TopBit; >> /// Возвращает длинное слово со значением (2^width)-1. /// /// private uint WidMask < get < return this._WidMask; >> /// /// Конструктор, инициализированный параметрами по умолчанию для алгоритма CRC32. /// public RocksoftCrcModel() < base..ctor(); this.CrcLookupTable = new uint[256]; this._CrcWidth = 32; this._Polynom = 79764919U; this._ReflectIn = true; this._InitRegister = uint.MaxValue; this._ReflectOut = true; this._XorOut = uint.MaxValue; this._TopBit = this.getBitMask(checked (this.CrcWidth - 1)); this._WidMask = (uint) ((int) checked (unchecked ((uint) (1 /// /// Инициализирует новый экземпляр параметрической модели CRC с настраиваемыми параметрами. /// /// Разрядность контрольной суммы в битах. /// Полином. /// начальное содержимое регистра. /// Обращать ли входящие байты сообщения? /// Обратить ли CRC перед финальным XOR. /// Конечное значение XOR. public RocksoftCrcModel(int width, uint poly, uint initReg = 4294967295, bool isReflectIn = true, bool isReflectOut = true, uint xorOut = 4294967295) < base..ctor(); this.CrcLookupTable = new uint[256]; this._CrcWidth = 32; this._Polynom = 79764919U; this._ReflectIn = true; this._InitRegister = uint.MaxValue; this._ReflectOut = true; this._XorOut = uint.MaxValue; this._TopBit = this.getBitMask(checked (this.CrcWidth - 1)); this._WidMask = (uint) ((int) checked (unchecked ((uint) (1 /// Вычисляет значение контрольной суммы переданного сообщения. /// Исходное сообщение, для которого нужно посчитать контрольную сумму. /// public uint ComputeCrc(ref byte[] message) < uint num1 = this.InitRegister; byte[] numArray = message; int index = 0; while (index < numArray.Length) < byte num2 = numArray[index]; num1 = this.getNextRegisterContent(num1, num2); checked < ++index; >> return this.getFinalCrc(num1); > /// /// Вычисляет значение контрольной суммы переданного сообщения и возвращает его в виде массива байтов. /// /// Исходное сообщение, для которого нужно посчитать контрольную сумму. /// public byte[] ComputeCrcAsBytes(byte[] message) < byte[] bytes = BitConverter.GetBytes(this.ComputeCrc(ref message)); byte[] numArray = new byte[checked (bytes.Length - 1 + 1)]; int num1 = 0; int num2 = checked (bytes.Length - 1); int index = num1; while (index > return numArray; > /// Обрабатывает один байт сообщения (0..255). /// Содержимое регистра на предыдущем шаге. /// Значение очередного байта из сообщения. private uint getNextRegisterContent(uint prevRegContent, byte value) < uint num1 = (uint) value; if (this.ReflectIn) num1 = this.reflect(num1, 8); uint num2 = prevRegContent ^ num1 > while (num3 /// Возвращает значение CRC для обработанного сообщения. /// Значение регистра до финального обращения и XORа. /// private uint getFinalCrc(uint regContent) < if (this.ReflectOut) return this.XorOut ^ this.reflect(regContent, this.CrcWidth); return this.XorOut ^ regContent; >/// Вычисляет таблицу предвычисленных значений для расчёта контрольной суммы. private void generateLookupTable() < int index = 0; do < this.CrcLookupTable[index] = this.generateTableItem(index); checked < ++index; >> while (index /// /// Рассчитывает один байт таблицы значений для расчёта контрольной суммы /// по алгоритму Rocksoft^tm Model CRC Algorithm. /// /// Индекс записи в таблице, 0..255. private uint generateTableItem(int index) < uint num1 = checked ((uint) index); if (this.ReflectIn) num1 = this.reflect(num1, 8); uint num2 = num1 > while (num3 /// Возвращает наибольший разряд числа. /// Число, разрядность которого следует определить, степень двойки. /// private uint getBitMask(int number) < return (uint) (1 /// Обращает заданное число младших битов переданного числа. /// Число, которое требуется обратить ("отзеркалить"). /// Сколько младших битов числа обратить, 0..32. /// /// Например: reflect(0x3E23, 3) == 0x3E26. private uint reflect(uint value, int bitsToReflect = 32) < uint num1 = value; uint num2 = value; int num3 = 0; int num4 = checked (bitsToReflect - 1); int num5 = num3; while (num5 >= 1; checked < ++num5; >> return num2; > > >

Данная программа на C# не тестировалась мной, в отличие от предыдущей, написанной на VB.NET. Этот код получен через декомпиляцию предыдущего. Если в нём обнаружатся какие-то ошибки, то пишите в комментариях или мне на почту, исправлю.

Прикладываю к статье полностью рабочий и готовый к использованию файл RocksoftCrcModel.vb с реализацией расчёта контрольной суммы CRC, который мы тут рассмотрели, а также RocksoftCrcModel.cs на C#.

Полную и самую последнюю версию кода можно скачать с репозитория на GitHub.

4 «Взлом» контрольной суммы CRC32 и CRC16

Кратко затронем вопрос «взлома» CRC32. И прежде всего давайте определимся с понятием «взлом» применительно к данному вопросу.

Если задача определения контрольной суммы некоторого массива данных – прямая задача, то «взлом» – это обратная задача, а именно: подгонка контрольной суммы под определённый массив данных.

Допустим, вы имеете файл и рассчитали его контрольную сумму. Вам нужно изменить в нём произвольное число байтов, сохранив при этом контрольную сумму. Сделать это совсем не сложно.

Для начала нужно посчитать обычным образом контрольную сумму CRC32, CRC16 или любую другую, какая вам нужна, для этого изменённого файла. Пусть это будет C1. Теперь нужно добавить такое же число нулевых байтов в конец файла, которое содержится в контрольной сумме (для CRC32 – 4 байта, для CRC16 – 2 байта, и т.д.). Можно простым перебором подобрать такое число C2, которое мы и запишем в эти нулевые байты. Ведь понятно, что полный диапазон всех допустимых значений CRC32 укладывается в 2 32 ~ 4,295 млрд. То есть за 4 с небольшим миллиарда итераций расчёта контрольной суммы с начальным содержимым регистра, равным С1, мы брутфорсом («в лоб», методом грубой силы) подберём нужное значение. При современных вычислительных мощностях это не составит проблемы. А уж «взломать» с помощью перебора CRC16 вообще дело нескольких секунд.

Можно ли разместить нулевые байты в середине или начале файла? Можно. К операции XOR применим сочетательный закон: a XOR (b XOR c) = (a XOR b) XOR c, поэтому можно с успехом разбить файл на 3 части: до вставки, после вставки, и сама вставка. Посчитать CRC для первых двух частей (C1 и C2 на иллюстрации), объединить их операцией XOR, заполнить этим числом начальное содержимое регистра, а затем «сбрутфорсить» CRC оставшейся третьей части X.

+-----------------+-----+---------+ | c1 | x | c2 | +-----------------+-----+---------+

Есть более интеллектуальный и изящный способ подогнать CRC под нужное значение. Суть его в том, что вместо последовательного перебора всех подряд значений мы «прокручиваем назад» несколько раз (по числу байтов или битов контрольной суммы) наш табличный алгоритм или алгоритм побитового сдвига до тех пор, пока CRC не будет желаемой. На эту тему есть подробные и качественные материалы в сети.

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

5 Программа для расчёта контрольной суммы по алгоритмам CRC32, CRC16 и CRC8

На основе приведённого алгоритма была написана программа – калькулятор для расчёта контрольных сумм по алгоритмам CRC32, CRC16 и CRC8 . Внешний вид окна приведён на рисунке. Программа работает под ОС Windows и требует .NET версии 3.5 .

Программа для расчёта контрольной суммы по алгоритмам CRC32, CRC16 и CRC8

Программа позволяет рассчитывать CRC массива байтов (введённого в поле «Сообщение») или указанного файла. Все рассмотренные выше параметры контрольной суммы настраиваются через интерфейс программы.

Ну и напоследок выкладываю ссылки на архив, в архиве лежат: программа «Калькулятор CRC», оригинальная статья «A Painless Guide to CRC Error Detection Algorithms», класс RocksoftCrcModel() на Visual Basic.NET и на C#.

Итак, подведём итоги. В этой статье мы:
– узнали, что такое контрольная сумма CRC и какие бывают её виды;
– научились считать CRC методом побитового сдвига и табличным методом;
– узнали алгоритмы «взлома» CRC и сделали вывод об области применимости контрольной суммы типа CRC.

Скачать программу «Калькулятор контрольной суммы CRC»

2023.05. Добавил версию 1.2 калькулятора. Пароль на архив – soltaurus.

Скачать вложения:

  • Калькулятор контрольной суммы CRC (8747 Скачиваний)
  • Калькулятор контрольной суммы CRC v1.2 (696 Скачиваний)

Калькулятор контрольной суммы CRC32

Этот простой инструмент рассчитает контрольную сумму строки CRC32.

Reference this content, page, or tool as:

«Калькулятор контрольной суммы CRC32» at https://miniwebtool.com/ru/crc32-checksum-calculator/ from miniwebtool, https://miniwebtool.com/

Другие сопутствующие инструменты:

Хэширование и контрольные суммы:

  • Калькулятор контрольной суммы Adler32
  • Калькулятор контрольной суммы CRC32
  • Генератор хэшей MD5
  • Генератор хэшей SHA1
  • Генератор хэшей SHA224
  • Генератор хэшей SHA256
  • Генератор хэшей SHA384
  • Генератор хэшей SHA512

Избранные инструменты:

Калькулятор контрольной суммы CRC32

Встроить этот инструмент

скопируйте исходный код

Совет. Виджеты адаптированы для мобильных устройств. Если установленная ширина больше ширины экрана устройства, она будет автоматически скорректирована до 100% ширины экрана. В режиме предварительного просмотра ширина ограничена 500 пикселями. Вы можете изменить ширину данных на любое значение в соответствии с макетом вашего сайта.

Встраивая инструмент miniwebtool на свой веб-сайт, вы соглашаетесь с нашими Условия обслуживания.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *