Все знают, что если поменять хотя бы 1 бит данных, то значение crc сильно меняется. Так вот некоторые программы для проверки своей целостности выделяют 2/4 байта в себе под значения crc. И когда считают эту хешу перепрыгивают через те байты. Можно ли выдумать алгоритм, которые посчитает crc файла с этими байтами. Ессено кроме тотального перебора, тем более не факт, что и он сможет подобрать.

Можно ли выдумать алгоритм, которые посчитает crc файла с этими байтами.

8-/ Можно. В алгоритме их не перепрыгивай.

Да но они ведь то же влияют на crc!
Тут типа crc (пусть это == 80 80 80 80 h) посчитан и дописан в конец файла:
some_data_АААА
crc("some_data_") == "АААА"

а теперь мы посчитаем те самые 4 байта (какие еще не изветсно :-) ), то есть уже в зависимости от этого crc (пусть == 81 81 81 81h).
some_data_ББББ
crc("some_data_ББББ") == "ББББ"

а именно:
типа вначале был бинарик:
ХХ ХХ ХХ ХХ ... ХХ
crc от него == 12 34 56 78
если к нему прибавить какие-то 4 байта (которые после станут crc НОВОГО бинарика) то всё круто ))
ХХ ХХ ХХ ХХ ... ХХ YY YY YY YY
crc("ХХ ХХ ХХ ХХ ... YY YY YY YY") = YY YY YY YY

Мне надовсего лишь найти те игриковые 4 байта.

Да как же так можно объяснять проблему? Мать-перемать, я щаз взвою. Ты скажи, ЧЕГО ТЕБЕ НАДО? Тебе надо подправить байтики в файле так, чтобы CRC остался тем же самым? Это возможно. Или что-то еще? Я ни звезды понять не могу!

задача: есть строка байт
строка = [что-то там..][X][что-то там еще..]
где X - 32-битное число
как найти такое X, чтобы выполнялось X = CRC(строка)

Оно ?

утилита для коррекции подобных случаев:

http://reng.ru/board/viewtopic.php?t=1637&highlight=crc&sid=9eef4f19b84639e56a121a8c391ba1ea

а вот тут я даже не стану притворяться, что много понял :(

http://reng.ru/board/viewtopic.php?t=1700&highlight=crc&sid=9eef4f19b84639e56a121a8c391ba1ea

Теорию чисел учить надо :(

bogrus
неа.
это я и сам могу написать.
мне нужен предполседний пост
volodya
Пасибо, а теория чисел нужна :-) дабы через 3 месяца будет. Будем писать.

То есть нада чтобы

crc( bytes_1 + CRC + bytes_2) = CRC
???

Если так, то по-моему далеко не для каждых пар bytes_1 и bytes_2 такое число найдется.
Зато проверить мона все-таки не перебором а матикой.

Или я вообще не про то подумал? ;)

B_108
Правильно подумал. Конечно не для каждой пары. Но можно оптимизировать перебор до 5 минут :-)
crc считается последовательно (байт за байтом) ==> будем пихать его значение в зад файла, а length(bytes_2) = 0. Таким образом сводим задачу к перебору 2^32 числа :-(

dShell
Конечно не для каждой пары. Но можно оптимизировать перебор до суток :-)
оптимизировать что ?
ведь не всегда же такое возможно,
а bytes_1 и bytes_2, как я понимаю, менять же нельзя ?

если нельзя, тогда можно рассчитать CRC от этих кусочков
и написать более оптимизированный вариант, когда у тебя есть

crc(bytes_1),CRC_X,crc(bytes_2)

думаю все будет довольно быстро

а вообще, лучше сразу у RElf'а спросить :) думаю он все разъяснит

Х=CRC(5A84E58D[8DE765A0]5A84E58D)=8DE765A0

Я правильно понял , что если например вместо 5A поставить 5B , то потом нужно найти новый Х ?

если нельзя, тогда можно рассчитать CRC от этих кусочков

И что ты потом будешь с ними делать? :) Складывать? :)

volodya
так продолжить можно с любого места,
конечно же, я имел в виду то, что придется
переписать немного саму ф-цию расчета CRC,
тобишь одной ф-ций расчета CRC32(buf,len) не обойдешься

Русский народ простых путей не ищет :)