Есть алго подсчета crc. Можно ли каким нить макаром прошить crc-ехешника в нем самом?
Имеется ввиду след:
при запуске файл считает свое црц и если не совпадает - завершает работу?
Я ниче не могу придумать толком, есть одна идея, но не совсем то, что нужно:

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

Есть еще варианты?

Пардон, но после "забубенивания" црс измениться - вот с этим у меня проблема...
или я неправильно понял?

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

по теории для 100% ответа надо 8 байт (если црц 4 байта), т.е. в таком случае я никогда не переберу все варианты, наверное....

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

авторЗаписывай уж в ini-файл, какая разница. Тот, кто знает что такое CRC, сможет выдрать его и из ini-файла, и из exe-файла, и из рееестра...
выдрать! пускай - я могу его на тайтл повесить. Но поменять-то ниче нельзя будет.
автора руки на что ?
Конструктивнее, конструктивнее, товарищ :)

here что-то похожее (я так хочу). Но там утверждают, что 4 байта - достаточно для корректировки результата. Я читал - 8 минимум.
А чтоб ваще без них?

авторА какой смысл. Если даже это случайно получится, т.е станет невозможно изменить программу, то что помешает злоумышленнику проделать тоже. Т.е подправить ,сакжем, ветвление на проверке пароля, пересчитать CRC и записать. Без полного перебора алгоритма нет. Т.е это трудно сделать как тебе, так и ему!
Резонно. Гм... Не знаю чего и сказать...
автор Стоит попробовать подобрать начальное значение CRC так, чтобы оно совпадало с самим собой.
О... Это нереально.
авторА ещё можно использовать шифрование с ассиметричным ключём. Т.е пудличным расшифровываем и смотрим соответствие CRC.
Хм... вариант.
Т.е. зашифровать црс, при проверке его расшифровывать.
Ключ на шифрование у меня дома и его никто не знает...
Интересный вариант. Очень даже. Буду так делать.

Осталось проверить, хватит ли 4 байта для подбора црц.

Gluk (Kazan) H.A.M.Конструктивнее, конструктивнее, товарищ :)

Блин, какой ты утомительный

1. Используем MD5, в hex-е чтобы було подлинее
2. В исходнике объявляем константу, нужной длины с известной нам лабудой
3. после компиляции ищем лабуду, подписываем все кроме нее и бубуним подпись на ее место
4. При запуске (подпись нам известна из константы), ищем свой файл, ищем в нем известную нам подпись, подписываем все кроме нее, сравниваем и кричим ай яй яй ежель не совпадет
5. От кракеров это все одно не защитит, но от тупой вирусни - запросто
Блин, какой ты утомительный. Это я и сам сделать могу.
Меня интересовал вариант, чтобы сама объявленная константа с црц также учавствовала в подсчете црц. Иначе я не вижу смысла во всем этом.
А варианты с дописыванием и подгоном - я так понял все фигня.
Если же ничего не дописывать, то не для всякого ехе найдется такое црц, чтоб при его вставке и участии в рассчете получить его же.
Единственное - шифрование црц несимметр. алго. Я уже выбрал сий путь.

Всем спасибо за участие.

авторты неправильно понял. никто никогда не подписывает саму подпись.
это бред.
Не такой уж и бред. Я подписал. Хватило 4 байта для подбора.
Просто, мне кажется, мы не можем понять друг друга.
Вот что я сделал (пока просто хеш вместо асимметричного шифра):
1. сделал подпись на 4 байта в ехе - preHashCRC - придумал просто с неба
2. сделал лабуду на 4 байта в ехе - CORRECTOR
3. при запуске проверяем: hashvalueof(preHashCRC) == getCRC("EXEname.exe");
4. вторая программка перебирает все варианты для CORRECTOR, чтобы hashvalue(preHashCRC) == getCRC("EXEname.exe");

Я думал 4 байта для CORRECTOR будет мало. Хватило :)
Но я все еще думаю, что мне повезло.
Не всегда выйдет так, что CORRECTOR подберется. Он ведь и сам уч-ет в рассчете CRC.
В опсчем, я так понял - гиблое это дело. Все равно ломается. Но теперь ломальщику надо еще и хеш алгоритм вычленять из проги - это все чего можно добиться. Насчет шифрования выйдет точно также.....

2 модератор:
не я первый начал. обещаю не поддаваться на провокации впредь.

авторАхх какие мы все благородные, пребываю в умилении.
Зря ты так...
авторОбъясни мне смысл подписывания подписи. Или объясни чем хуже вариант с подписыванием всего кроме подписи (коим все пользуются) и я тут же тебе зауважаю и буду на всех кглах пропагандировать твой патентованный метод поиска коллизий (для MD5 это будет конечно потруднее, но по последним исследованиям нет ничего невозможного).
Все кроме подписи подписывать я не хочу. Взломщик проделает точно тот же путь, что проделал я для подгона црц. Но, как я уже понял, в любом случае мне для подбора тоже один путь - перебор. Так что я не далеко ушел.
авторНамеки относительно последующего использования ассиметричной криптографии воспринимаю исключительно как растопыривание пальцев. IMHO ассиметричное шифрование 4 байтного CRC МАРАЗМ
А вот тут я считаю ты не прав. Оторвемся от шифрования и возьмем простой хеш, чтобы было проще:
в файле храниться значение ХЭШ КОТОРОГО есть ЦРС. Это значение м.б. 100 байт, килобайт - неважно. Важно то, что если взломщик после своих манипуляций сможет подогнать ЦРЦ под правильный, ему надо знать как из этого ЦРЦ получить ТЕ БАЙТЫ, хэш которых даст это значение, что почти нереально уже при 8 байтах.
Но: он может тоже написать эти байты от балды, а потом подгонять ЦРЦ к их хэшу. В этом случае ему придеться дополнительно выдирать алгоритм хэширования.
С хэшем просто понятнее - но с шифрованием аналогично. И это не мой патентованный метод. Не надо такого тона, будто я вчера кинул друга, а сегодня всем рассказываю какие мы были хорошие друзья.

Den_di ...
Да, но это не так просто как подбор хэшей/црц.
И вообще: любую защиту можно сломать. Достаточно той, затраты на взлом которой будут больше стоимости ПО (:
авторНепонятно, что будет по смете стоить дороже - разработка софта или защиты к нему
Смотря какой софт.
Данная тема поднята, к примеру, в контексте разработки ПО, которое будут использовать другие авторы для защиты собственных программ. Может даже чего-нибудь и получится (: