function CalculateCRC32(var buffer;const size:longword):longword;
var i:integer;
data:tdata absolute buffer;
begin
result:=0;
for i:=0 to size-1 do result:=(result shr 8) xor (CRC32Table[byte(result) xor data]);
end;
Алгоритм CRC32. Предыдущий контекст.
Здравствуйте!
Столкнулся с такой проблемой - не могу найти в гугле информации по поводу того, как правильно считать хэш от нескольких блоков данных (к примеру, файлы каталога). Никак не получается отрыть алгоритм, который бы учитывал результат предыдущего подсчета CRC32 при подсчете хэша от нового блока данных. М/б кто знает ресурс, или сталкивался с такой задачей - прошу помочь.
Заранее благодарен.
P.S.
Если есть сорцы, то слейте на sholah_weras@мейл.ру
Столкнулся с такой проблемой - не могу найти в гугле информации по поводу того, как правильно считать хэш от нескольких блоков данных (к примеру, файлы каталога). Никак не получается отрыть алгоритм, который бы учитывал результат предыдущего подсчета CRC32 при подсчете хэша от нового блока данных. М/б кто знает ресурс, или сталкивался с такой задачей - прошу помочь.
Заранее благодарен.
P.S.
Если есть сорцы, то слейте на sholah_weras@мейл.ру
вам хочется хеш от нескольких блоков данных как если бы они были одним последовательным непрерывным блоком?
Здравствуйте, Phodopus.
Да, именно так и хочется. Если рассказать подробнее, то дело выглядит так - я беру файл из каталога, маплю его (MapViewOfFile - http://msdn.microsoft.com/en-us/library/aa366761(VS.85).aspx) и передаю указатель на стартовый адрес объекта в ф-ию подсчета хэша.
Затем беру второй файл каталога, так же маплю его и передаю в ф-ию подсчета хэша (и в этом случае уже должен учитываться предудщий результат работы ф-ии) и т.д.
За это время в Сети нашел несколько вариантов (как правило, в ф-ии есть доп параметр типа prevCRC), но хэш с эталонным не совпадает. М/б у Вас есть проверенный алгоритм?
Да, именно так и хочется. Если рассказать подробнее, то дело выглядит так - я беру файл из каталога, маплю его (MapViewOfFile - http://msdn.microsoft.com/en-us/library/aa366761(VS.85).aspx) и передаю указатель на стартовый адрес объекта в ф-ию подсчета хэша.
Затем беру второй файл каталога, так же маплю его и передаю в ф-ию подсчета хэша (и в этом случае уже должен учитываться предудщий результат работы ф-ии) и т.д.
За это время в Сети нашел несколько вариантов (как правило, в ф-ии есть доп параметр типа prevCRC), но хэш с эталонным не совпадает. М/б у Вас есть проверенный алгоритм?
Похоже на работу непрерывного архива. Я бы посмотрел, как это делает 7-Zip. Ещё есть такое, сам пока не пользовал.
2 Freeman
Как-то много там асма, тем более для предпосчитанной таблицы. Несколько версий видел, там десяток, может, два строк кода. Хотя все-равно спасибо, посмотрю что выдает.
Хотя, опять таки, не пахнет там подсчетом хэша с использованием предыдущего результата.
Как-то много там асма, тем более для предпосчитанной таблицы. Несколько версий видел, там десяток, может, два строк кода. Хотя все-равно спасибо, посмотрю что выдает.
Хотя, опять таки, не пахнет там подсчетом хэша с использованием предыдущего результата.
Гм, koders.com лежит что-то, не могу сравнить локальную версию и ту, что выложена.
Цитата: Sholah_Weras
Как-то много там асма, тем более для предпосчитанной таблицы.
Там в каментах есть такое:
Код:
Да, видел.
Но, как вы могли заметить - result каждый раз берется обнуленный. Т.е. никакой связи с предыдущим CRC :D
Ох, вроде и несложный момент, а времени много угробил. Перепроверю-ка я свой код чтоли...
Но, как вы могли заметить - result каждый раз берется обнуленный. Т.е. никакой связи с предыдущим CRC :D
Ох, вроде и несложный момент, а времени много угробил. Перепроверю-ка я свой код чтоли...
Цитата:
...но хэш с эталонным не совпадает.
А CRC32 для обычных неприрывных файлов у вас совпадает? Вот юнит, который я сам давно использую (через таблицу).
Правда, я не знаю, как им использовать предыдущий результат, но методом научного тыка попробовал бы вместо C := $FFFFFFFF; поставить C := not PrevCRC32; (чисто из-за сходства $FFFFFFFF = not 0).
Кстати, я точно знаю, что хэширование adler32 (юзается в zlib) поддерживает такую неприрывную генерацию и будет работать правильно, ибо функция находится в самом юните zlib (соответственно, её писать не придётся).
Обычно если есть выбор, что использовать: CRC или Adler - я выбираю последнее.
Не стал создавать новую тему.
Просто интересно, можно ли подсчитать контролльную сумму дампа, в которую она же и включена?
Однажды, как защита от взлома, я хотел подсчитать контрольную сумму не только основного кода, но и четырёх байтов этой суммы.
Т.е. в идеале, программа запускается и тупо подсчитывается сумма всего кода, а затем проверяется:
CALL CRC_Calc
CMP EAX,0x????????
Где ??? - какрас эталон сравнения, который также участвовал при подсчёте суммы.
Не знаю как сказать. Короче.
Может ли контрольная сумма включать саму себя?
Спасибо!
Просто интересно, можно ли подсчитать контролльную сумму дампа, в которую она же и включена?
Однажды, как защита от взлома, я хотел подсчитать контрольную сумму не только основного кода, но и четырёх байтов этой суммы.
Т.е. в идеале, программа запускается и тупо подсчитывается сумма всего кода, а затем проверяется:
CALL CRC_Calc
CMP EAX,0x????????
Где ??? - какрас эталон сравнения, который также участвовал при подсчёте суммы.
Не знаю как сказать. Короче.
Может ли контрольная сумма включать саму себя?
Спасибо!
Цитата: Vertecs
Может ли контрольная сумма включать саму себя?
Нет, конечно, иначе она будет всегда разная. Обычно её место просто забивают 4 нулями (или другой константой), и после подсчёта подставляют туда хэш.
Цитата: Sholah_Weras
я беру файл из каталога, маплю его
а скажите мне, как вы будете считать CRC от файла > 2Гб ?
Цитата: Sholah_Weras
М/б у Вас есть проверенный алгоритм?
конечно есть, но я уверен что он и у вас есть.
Цитата: Vertecs
Однажды, как защита от взлома, я хотел подсчитать контрольную сумму не только основного кода, но и четырёх байтов этой суммы.
Не тем занимаетесь, делайте тогда уж цифровую подпись :)
[QUOTE=Phodopus;329699]а скажите мне, как вы будете считать CRC от файла > 2Гб ?
А что, есть какие-то проблемы? Я писал бинарный диффер, и мог открывать файлы и больше 2-4-10 Гб
Нашел нужную реализацию CRC32. Кому надо, могу выложить.
А что, есть какие-то проблемы? Я писал бинарный диффер, и мог открывать файлы и больше 2-4-10 Гб
Нашел нужную реализацию CRC32. Кому надо, могу выложить.
Цитата: Sholah_Weras
А что, есть какие-то проблемы? Я писал бинарный диффер, и мог открывать файлы и больше 2-4-10 Гб
Проблема замаппить 2Гб на 32х битной системе
Цитата: Phodopus
Проблема замаппить 2Гб на 32х битной системе
А, ну дык, гранулярность ведь)
Цитата: Sholah_Weras
А, ну дык, гранулярность ведь)
Вы не поняли. Для того чтобы посчитать CRC файла 2Гб на 32х-битной системе его придется разбить на блоки и считать сумму поблоково, а потом как-то вычислять итоговую. А ваша задача точно к этому же и сводится.
Цитата: Phodopus
Вы не поняли. Для того чтобы посчитать CRC файла 2Гб на 32х-битной системе его придется разбить на блоки и считать сумму поблоково, а потом как-то вычислять итоговую. А ваша задача точно к этому же и сводится.
Вы не поняли, это я и имел в виду. Гранулярность, в том контексте - разбивка на части и маппинг по очереди.
Цитата: Sholah_Weras
Вы не поняли, это я и имел в виду. Гранулярность, в том контексте - разбивка на части и маппинг по очереди.
Так в чем тогда проблема, и считали бы CRC от нескольких файлов таким же образом.
Цитата: Proger_XP
Нет, конечно, иначе она будет всегда разная. Обычно её место просто забивают 4 нулями (или другой константой), и после подсчёта подставляют туда хэш.
Перефразирую вопрос:
Какова вероятность того, что в дампе может находиться последовательность, точно соответствующая его CRC? ;)
И как тогда можно это алгоритмически организовать?