Перейти к содержанию

Антиотладочные хитрости в Delphi


Рекомендуемые сообщения

Я хотел бы узнать подробно как в Дельфях написать в прогу антиотладочные хитрости. o_0 Например, если у вас во время запуска трейнера уже запущены отладочные проги(такие как: Cheatengine, OllyDbg, MHS и другие подобные отладчики), то как сделать так чтобы трейнер ругался и молча закрывал их :mad: или вообще не запускался? :rolleyes:

Ссылка на комментарий
Поделиться на другие сайты

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

Ссылка на комментарий
Поделиться на другие сайты

Если я не "вру", отладчики ипользуют некоторые прерывания совместно с регистрами отладки. Когда происходит отладка, то можно узнать по этим прерываниям и по изменениям регистров. Выполнять это нужно как-то в нулевом кольце с вылетом в бсод. Возможно, это отобьёт желание копаться даже Софт-Айсом.

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

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

Ссылка на комментарий
Поделиться на другие сайты

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

Ссылка на комментарий
Поделиться на другие сайты

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

Я точно не знаю, но вроде мои мысли верные.

Ссылка на комментарий
Поделиться на другие сайты

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

Ссылка на комментарий
Поделиться на другие сайты

Я конечно спорить не буду, я читал об кольцах защиты, но как-то люди были не профи (где-то они услышали, где-то прочитали, кто-то им сказал) Почему-то мне кажется что можно осуществить доступ через дырки в драйверах: переполнение стека и выполнения данных как кода... правда проще другой метод. Свой драйвер написать, который проверяет отладку процесса трейнера и если отладка есть, то схлопываем систему. Загрузка драйвера в систему без её перезагрузки возможна, это я точно знаю: MHS и cheat engine могут это делать :)

Ссылка на комментарий
Поделиться на другие сайты

Чтобы драйвер мог быть загружен во время работы - он должен быть написан по принципам Plug'n'Play. Но в этом, в принципе, сложностей практически нет.

Ссылка на комментарий
Поделиться на другие сайты

  • 2 года спустя...

Зачем изобретать велосипед? Есть огромное количество протекторы которые позволяют защитить программу от отладчиков, вирусов от патчев и от диссамблирования!

Например VMProtect, или попроще но не менее мощная ORiEN

Ссылка на комментарий
Поделиться на другие сайты

Всем здесь присутствующим прекрасно известно про существование пакеров и протекторов. Суть в том, что рассматриваются теоретические вопросы написания собственных алгоритмов, а не вопросы использования алгоритмов чужих. А следуя Вашей логике, можно сказать, что наши участники и трейнеры зря пишут - ведь можно же не изобретать велосипед и взять уже готовый.

Ссылка на комментарий
Поделиться на другие сайты

×
×
  • Создать...

Важная информация

Находясь на нашем сайте, Вы автоматически соглашаетесь соблюдать наши Условия использования.