 | | | | |
| Защита от несанкционированного использования программ, написанных на Delphi |
Полный текст материала
Цитата или краткий комментарий: | «... Эта статья написана для людей, знающих основные подходы к реализации защиты программ от несанкционированного использования. Здесь мы обсудим реализацию некоторых процедур на Delphi. ...» |
Важно:- Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
- Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
- При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
- Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.
Всегда легче осудить сделанное, нежели сделать самому. Поэтому, пожалуйста, соблюдайте правила Королевства и уважайте друг друга.
Добавить свое мнение.
| | | Содержит полезные и(или) интересные сведения | | [1] | 7 | 63.6% | | | | | Ничего особенно нового и интересного | | [2] | 4 | 36.4% | | | | | Написано неверно (обязательно укажите почему) | | [3] | 0 | 0% | |
Всего проголосовали: 11 | | | | Все понятно, материал читается легко | | [1] | 7 | 87.5% | | | | | Есть неясности в изложении | | [2] | 1 | 12.5% | | | | | Непонятно написано, трудно читается | | [3] | 0 | 0% | |
Всего проголосовали: 8 |
[Контроль целостности кода]
Отслеживать это обсуждение 
Всего сообщений: 814-09-2010 01:10Мне кажется, в этом вопросе можно добиться хороших результатов, если посвятить 2-3 года преимущественно взлому, а не кодингу, тогда многие вопросы отпадут. Статья написана в 2003, тогда такие методы может и имели смысл, но суть взлома поясняется в первом комментарии. Сейчас требования начальных знаний для взлома, мне кажется, сильно возросли, т.к. стало повсеместной практикой использовать пакеры и протекторы (по сравнению с 2003 г.), суть работы которых и есть шифровка и дешифровка участков кода... Не сильный в этих делах специалист, но мне кажется хорошего результата можно добиться если реализовать для целей защиты виртуальную машину, структура которой будет генерироваться для каждого релиза программы. Сложность для крекера будет представлять изучение используемых команд, плюс где-то читал, что есть такие виртуальные машины, которые нельзя расшифровать в принципе (обосновывается математически), правда не помню как называются. Интересно, кто-нибудь что-нибудь подобное делал?
В моем случае вопрос защиты остро не стоит, т.к. разрабатываем софт для предприятий, а на каждом предприятии есть свой царь и заморочки других царей ему не интересны. Правда был один случай, когда сделали копию программы на 1С, чего добились не знаю, т.к. сотрудничество с ними прекратили... |
|
01-09-2010 01:07| познавательно. вкупе с комментариями |
|
24-10-2003 10:12Я согласен со всеми замечаниями.
Не зламываемого кода не существует. (Кому интересно математическое док-во. пишите-отвечу.) ЕДИНСТВЕННОЕ(!) средство от взлома известно давно - взлом защиты должен быть дороже чем стоимость программы(читайте "Проект АКМ" на этом же сайте. Весьма полезные статьи).
По поводу защиты.
Избавиться от команды сравнения легко(опять же "Проект АКМ").
F.E.:
var
Key:string;
procedure ReadKey;
begin
if not ReadKeyFromFileOrReestre(Key) then begin
Key:=InputBox(...);
SaveKeyToFileAndReestre(Key);
end;
end;
procedure VerySecretProc;
begin
try
Decode(@BeginSecretCode,LengthSecretCode,Key);
...
finally
Code(@BeginSecretCode,LengthSecretCode,Key);
end;
end;
И все.
Заметьте. Ключ лежит в открытом виде. Его защищать уже не надо.
Единственое замечание - алгоритм должен быть таким, что имея его подобрать ключь невозможно/очень сложно.
Если у клиентов будут разные ключи (и алгоритмы шифрования?)
то вот вам и решение. |
|
01-10-2003 06:50Данный подход не проходит в случае если защищается код в dll, которая может быть загружена по другому базовому адресу, чем указанный при ее компиляции. Если в шифруемом коде есть команды использующие абсолютную адресацию относительно базового адреса,
Например(mov eax, [MyDataSegment + MyStringAddress]), то при загрузке программы, загрузчик операционной системы по таблице перемещений подправляе эти команды.
Если в момент загрузки код зашифрован, то загрузкик его не сможет поправить. Следовательно нужно либо самому писать загрузчик, либо не шифровать команды использующие абсолютную адресацию.
|
|
18-09-2003 13:01>MrWhite
не обязательно шифровать процедуру с текстовыми предупреждениями. Шифруемая процедура может просто сравнивать 2 переменные, или 2 массива или выполнять любые другие операции. Например, в прилагаемом или хранящемся в EXE ключе хранится хэш ряда условий, а в зашифрованной процедур мы делаем хэш текущих условий и сравниваем.
Так что поиск незашифрованной строки теряет смысел. А если надо выводить строки - то вариантов несколько, например вызывать для этого внешнюю процедуру или выводить строку в зашифрованном виде, а расшифровку делать непосредственно в OnShow (или что-то подобное) визуального обьекта с самостоятельной прорисовкой результата. Таким образом незашифрованные строки вообще нигде не хранятся. |
|
18-09-2003 09:35Как заведомо определить, что последовательность байтов используеющихся в качестве меток уникальна? Как узнать что после изменения кода и его компиляции рна не повториться, причем раньше нужного нам?
В принципе можно функцию защиты вобще ваташить в дллку, раз скомпилировав, а потом менять код самой программы сколько влезет. Но не знаю, видимо подменить дллку будет еще проще взломщику. Вообще я не специалист в этом вопросе, но материал в принципе полезный. |
|
16-09-2003 14:01Для mrWhite:
Собственно при загрузке файла код все еще зашифрован. Он может расшифровываться непосредственно перед использованием кода, а потом снова зашифровываться. Поэтому хакеру нужно знать момент, в который код находится в расшифрованном состоянии. Установка точек останова на функции типа ShowMessage то же может быть неэффективной, поскольку защищаемый код может вообще их не содержать, а например сравнивать содержимое 2-х переменных и завершать программу при неравенстве.
Хотя в общем ты прав и невзламываемого кода наверно не существует. |
|
16-09-2003 12:41Этот метод может подойти для защиты текстовых строк от редактирования (изменение копирайтов и т.д.), но для кракера сложности не представляет. Не найдя строку об истечении времени работы в файле, можно легко найти ее в расшифрованном виде в памяти процесса отладчиком, а уж по ней весь код процедуры.
|
|
|
|
