RDM/2 The Russian Electronic Developer Magazine  
RDM/2 Русский электронный журнал разработчика  
ДомойОт редактораПишите намОбратная связьRU/2

Защита программ от взлома.

Несколько советов на тему:
"Как защитить программу от взлома"
Вероятно, все понимают, что никакая защита не спасёт программу от взлома. Однако можно принять специальные меры, которые затруднят работу взломщика и, возможно, заставят его отступить.
Предлагаемые советы по защите программы, конечно не защитят от профессионала, но против чайников они дают почти 100% защиту.
Следование правилам издложенным с этой статье не сложно и не требует много дополнительного времени, но вероятность взлома вашей программы значительно снизится.
Если не принимать специальных мер, то для взлома программы достаточно набора lxlite + hiew. отладчик может потребоваться только для вычисления регистрационного кода.

Общие замечания

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

Этапы защиты:
1) получение ключа (имя/регистрационный код)
2) проверка достоверности ключа
3) принятие решения о том зарегистрирована программа или нет (наиболее уязвимый этап).

Задача взлома программы заключается в
1) отыскании защитного программого кода и
2) его нейтрализации

Соответственно необходимо затруднить выполнение этих подзадач.

Правила (внизу каждого правила - против чего защищает)

1. /exepack:2 и никакой информации для отладчика чтобы чайник не мог просто пропатчить
В связи с lxlite - не очень актуально.
(нейтрализация, отыскание)

2. Строки типа "unregistered" - в ресурсы.

Поскольку иначе они получают статический адрес в сегменте данных и место кода, где такая строка используется легко находится, а от этого места обычно недалеко до кода где принимается "решение" о зарегистрированности.
(отыскание)

3. Функция проверки ключа должна сама быть проверена:

На заведомо неверный ключ она должна сообщать об ошибке. Причем ее работа может зависеть от значений некоторых глобальных переменных.
(нейтрализация, защита от простейшего изменения возвращаемого значения)

4. Функция проверки ключа должна преобразовывать и регистрационный код и имя. иначе под отладчиком очень легко определяется регистрационный код, соответствующий произвольному имени или имя коду.

имя - преобразование -> с1 \
+ некая операция сравнения -> решение
код - преобразование -> с2 /
(нейтрализация)

5. При защите от отладчика с помощью установки своих exception handlers (DosSetExceptionHandler) и последующей генерацией exceptions (int3, mov [0],0 etc) надо чтобы handler занимался полезной работой: т.е. если его не вызвали, то программа не должна работать.
(нейтрализация)

6. Вызывать функцию проверки ключа надо вызывать не в основном потоке, а через посылку сообщения какому нибудь окну или запуском другого потока через семафор.

main() {
  hsemCheck = createSem();
  resetsem(hsemCheck)
  _beginthread( checker, ...)

  .... do something ...

  // check the key here
  postsem( hSemCheck)

  ....

  checker:
  for( ;;) {
    waitsem( hsemChecker);
    load regname, regcode
    check( regcode, regname);
  }
}
(отыскание)

7. Лучше ко всем данным относящимся к проверке обращатся через указатели. В том числе ф-цию проверки вызывать через указатель на нее.
(отыскание, в HIEW будет практически невозможно отыскать места вызова этой функции)

8. Ф-цию проверки вызывать в нескольких местах (не ограничиватся однократным вызовом и установкой глобальной переменной Registered = 1)
(нейтрализация)

9. При вводе кода/имени через диалоговое окно их не надо сразу проверять, а лучше передать их в сообщении другому окну, а ответ то окно пусть тоже возвращает через сообщение.
(отыскание и нейтрализация)

Пример

Примером неудачной защиты является например последняя версия программы PM123 v1.0. Здесь по шагам расписывается процесс снятия защиты - 5 пунктов.

1. lxlite
2. в hiew ищем строку unregistered
(нарушено правило 2)
3. в hiew ищем ссылки на адрес найденной строки
(нарушено правило 2)
4. в коде рядом со ссылкой есть jne после вызова функции
(нарушены правила 6 и 9)
5. смотрим эту функцию и меняем код возврата из нее на 1
(xor eax,eax на jmp short ... )
(нарушено правило 3)

И вся работа автора по проверке 32хсимвольного (!) ключа
оказывается напрасной.

Критерий качественной защиты
Чтобы снять хорошую защиту требуется писать дополнительный код, а для снятия плохой - достаточно убрать существующий.

Виталий Пеленёв AKA sunlover
Vitali.Pelenyov@dpt.ustu.ru
vitali@cosmos2.dpt.ustu.ru

---
Интересные ссылки:

---

---
Комментариев к странице: 0 | Добавить комментарий
---
Редактор: Дмитрий Бан
Оформление: Евгений Кулешов
(C) Russian Underground/2