изначально предназначался для контроля
Алгоритм CRC16/ 32 изначально предназначался для контроля целости данных от непреднамеренных искажений и широко используется в проводных и беспроводных сетях, магнитных и оптических носителях, а так же микросхемах постоянной или перешиваемой памяти. "Надежность" CRC32 оценивается как 2^32 == 4.294.967.296, то есть вероятность, что контрольная сумма искаженного файла "волшебным" образом совпадает с оригиналом оценивается (в среднем) как один против четырех миллиардов раз. Отсюда следует, что передав восемь миллиардов пакетов через сильно зашумленный канал, мы рискуем получить пару "битых" пакетов, чьи искажения останутся необнаруженными. Но ведь в действительности все совсем не так!!! Природа большинства физических помех и дефектов такова носит групповой характер, с которым CRC32 легко справляется и в реальной жизни никакие искажения от CRC32 не ускользают!!! Отнюдь не глупые ученые и инженеры над этим работали!
Но вот алгоритм CRC32 просочился в массы! Программисты (все мы учились понемногу чему ни будь и как ни будь) стали применять хеширование в зашитых механизмах, призванных обеспечить информационную безопасность и противостоять против предумышленных искажений. Другими словами — защитить от хакерских атак. Машинный код, контролирующий свою целостность через CRC, не очень-то полезен, поскольку контрольная сумма храниться непосредственно в теле программы. Модифицировав программу, хакер рассчитывает новое значение контрольной суммы, корректирует поле CRC (а найти его в отладчике/дизассемблере совсем не проблема) и… защитный механизм продолжает считать, что в "Багдаде все спокойно".
Скажу откровенно: наличие механизмов самоконтроля серьезно раздражает хакеров и препятствует пошаговой трассировке step-by-step, при которой отладчик внедряет CCh после каждой команды. Однако, хакеров лучше не злить. Разъяренный хакер взрывоопасен! Размахивая soft-ice словно топором и прикрываясь дизассемблером как щитом, он находит и поле контрольной суммы, и тот код который ее контролирует, после чего обоим настает конец.
Кстати говоря, "правильная" контрольная сумма должна быть равна нулю. Это закон! Именно так работает механизм самоконтроля BIOS'ов. В этом случае контрольная сумма нигде не хранится, но к содержимому прошивки добавляются четыре (в CRC16 – два) байта, рассчитанных так, чтобы контрольная сумма всего контролируемого блока обращалась в ноль. В этом случае ломать защиту становится намного труднее (ведь поля контрольной суммы нет!), но… все-таки возможно. Достаточно установить аппаратную точку останова на модифицированную команду (в soft-ice это делается так: "bpm adders R") и отладчик приведет нас с коду, который вычисляет контрольную сумму и на каком-то этапе выносит заключение CRC OK или CRC не OK.
Обычно хакеры "отламывают" непосредственно сам проверяющий механизм, чтобы программа работала независимо от того, какой у нее CRC, однако, этот способ срабатывает не везде и не всегда. Вспомним спор, возникший в конференции SU.VIRUS, по поводу инспектора AdInfo: может ли вирус заразить файл так, чтобы его контрольная сумма осталась неизменной? Может! Даже если весь файл проверяется целиком от ушей до хвоста! Чуть позже мы покажем как это сделать, а сейчас рассмотрим другой случай: клиент серверную систему, в которой ключевой файл (условно называемый "сертификатом") находится у клиента, а его контрольная сумма храниться и проверяется на сервере. В состав сертификата может входить все, что угодно: название организации, IP-адрес клиента, его "рейтинг", уровень "полномочий" в системе и т. д. и т. п. Весьма распространенный подход, не правда ли? Чтобы повысить уровень своих полномочий клиент должен модифицировать файл сертификата, что с неизбежностью влечет за собой изменение контрольной суммы, скрупулезно проверяемой сервером, взломать который значительно сложнее, чем подправить пару байт в hiew'е!
Защита подобного типа растут как грибы (вот хорошая статья на эту тему "Тайна золотого ключика или Особенности системы лицензионных ключей, используемой компанией Software AG": http://www.wasm.ru/article.php?article=saglickey), разработчики которых свято верят в CRC32, забыв о том, что он страхует только от ненамеренных искажений, то есть искажений, которые происходят случайно и затрагивают один или несколько хаотичным образом разбросанных байт.
Информационная стойкость CRC32 равна 4 байтам и от этого никуда не уйти. Именно столько байт требуется внедрить в модифицированный файл (или дописать их к нему), чтобы его контрольная сумма полностью сохранилась, независимо от того, сколько байт было изменено! Естественно, эти четыре корректирующих байта должны быть рассчитаны по специальному алгоритму, но это потребует совсем немного времени (в смысле — вычислительных ресурсов). Самое интересное, что методики "подделки" CRC широко известны и описаны во множестве руководств, а у популярной утилите PEiD даже имеется плагин, специально предназначенный для этой цели!
