Asterix
реальный дебаггер имеет кое-какие полезные фичи(например Olly), которые по моему мнению позволят уйти от такой проверки
Не понял, какие фичи и от чего уйти?
Если речь об демонстрируемом способе, то я ж уже говорил, что если дебаггер вызывает WaitForDebugEvent он оповещается ОБО ВСЕХ исключениях, хочет он этого или нет, что и можно зафиксировать.
Можно это обойти? Легко, например как предложил Володя.

Но дело то не в этом, а вот в чем...
Для чего делается патч IsDebuggerPresent? Да для того, чтобы загрузить прогу, скажем, в Olly, расставить брейкпоинты, запустить, и потягивать пивко в ожидании долгожданного события. Приведенный пример показывает, что в этом случае можно и на грабли наступить, но не более того!

Т.е. дебаггер обнаружен XXX число раз что-ли?
Ну да. Проверка делается в цикле. Ты сорцы вообще смотрел? :))

А кто тебе сказал, что Asterix тоже хорошо умеет Delphi готовить? :)

Max
Ну вот и сделай реальную прогу которая при запуске под Olly скажет мне что она под отладчиком и пусть это будет в MessageBox, типа "Debugger Found" или "Debugger Not Found", не думаю что она будет больше той работы что ты проделал уже написав две.

> Ну да. Проверка делается в цикле. Ты сорцы вообще смотрел? :))

То что такты замеряются в цикле это и ежу понятно, но зачем мне выводить инфу о том что "Дебаггер найден 2000 раз", дебаггер то у меня один ???

volodya
Достаточно хорошо для того чтобы понять что в асм вставках написана процедура подсчёта тактов проца ;-)

Max
Кстати, не совсем в тему, может ты знаешь как в Дельфи сделать процедуру без пролога и эпилога.

Max

Хотя судя по всему твой метод работает!
При простом запуске test.exe показывает Debugger Found 0.
Под Olly соответственно не ноль.

Max

Вобщем взял на себя смелость сам переделать твой исходник, вот что получилось..


_1003600493__ring3modif.rar

Привет всем.
Я на форуме новичок, так что могу говорить или банальности, или глупости, или и то и другое одновременно - поэтому просьба в случае чего пинать только руками, без ног :)

Сначала о мелочах:
Asterix
как в Дельфи сделать процедуру без пролога и эпилога.

Если мне не изменяет память (я уже тоже не люблю Delphi), достаточно написать нечто вроде

procedure proc1({аргументы по вкусу});assembler;
begin//возможно, здесь не begin, а сразу asm - не помню
//здесь код на ассемблере
end;

Ну и теперь о наболевшем. Насколько я знаю (а опыт у меня, увы, небольшой), в большинстве случаев генерятся именно "тупые" исключения, по которым сразу заметно, что они установлены с единственной целью - вызвать обработчик исключения (например, те же int 3 или mov [0],eax). Притом они именно генерятся, а не вдумчиво пишутся руками, и не в очень больших количествах. Замеченный мной рекорд - 18 штук подряд, все однотипные.

В таких случаях обработчики исключений вызывают подозрение, и возникает естественное желание их проанализировать, а в идеале даже пропатчить прогу так, чтобы они просто не вызывались - и отладка будет надежнее проходить, и прога будет быстрее работать :)

Так что пихать измерение времени в обработчик исключения - идея, конечно, любопытная. Но по-моему, гораздо "опаснее" выглядит измерение времени "где-нибудь в другом месте", хотя и реализовывать его сложнее.

RobinFood

procedure proc1({аргументы по вкусу}):...;assembler;
asm
....
end;

Само-собой этот вариант пройденный мной этап, он не работает, пролог/эпилог всё-равно генерятся ;-)

А что до удаления кода вызывающего исключения, ну.. ну..,
достаточно напихать что-нибудь нужное именно в обработчик исключения, то бишь выполнение каких-нибудь полезных действий для нормальной работы программы, и тогда при удалении тобой int3 или mov [0], eax прога будет падать :-)

Asterix
Само-собой этот вариант пройденный мной этап, он не работает, пролог/эпилог всё-равно генерятся ;-)

Гм... ну, тогда я даже и не знаю... Есть, конечно, совсем тупой вариант - подлинковывать obj-файлы, сгенеренные другим компилером.

И есть вариант немного поумнее - переходить на MSVC и пользоваться
__declspec(naked) или #define PROC1 __asm ... :)
Хотя и тут есть свои минусы - это будет сбивать с толку оптимизатор, и инициализация регистров будет дублироваться.

достаточно напихать что-нибудь нужное именно в обработчик исключения, то бишь выполнение каких-нибудь полезных действий для нормальной работы программы, и тогда при удалении тобой int3 или mov [0], eax прога будет падать :-)

Ну, я все-таки не настолько глуп, чтобы просто заменять int 3 на nop. Я же написал, что буду анализировать обработчики :) А огромных извратных обработчиков в больших количествах мне (пока, к счастью) видеть не доводилось. Разве что кто-то начнет делать в каждом обработчике виртуальную машину... ;)

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

Тогда посмотри Xlock - реализация running line под Windows. Инструкции генерируются на стеке кодогенератором и раскриптовываются в SEH-обработчике, который, заодно, после кажой инструкции поднимает TF-флаг. Я об этой защите пишу в третьих упаковщиках. Если когда-нибудь их вообще напишу. (Dr.Golova, спасибо :))

Инструкции генерируются на стеке кодогенератором и раскриптовываются
Хе-хе, недолго будет жить эта защита, а точнее до прихода SP2 в XP (ес-но для Athlon64)

Ты хочешь сказать, запрет выполнения кода на стеке?

запрет выполнения кода на стеке?
Угу

http://msdn.microsoft.com/security/default.aspx?pull=/library/en-us/dn wxp/html/securityinxpsp2.asp

в том и дело, что всё зависит от конкретного PC-OS и всё это
просто сгодитья для время-препровождения..

**
current threshold is patterntime*130000
debugger found 11 times of 259
patterntime = 74
excepttime = 9327748
minpatterntime = 74 (minpatterntime * 130000 = 9620000)
minexcepttime = 73073
maxpatterntime = 200
maxexcepttime = 9327748

>> запрет выполнения кода на стеке

а как VirtualProtec-то Ж)

je_

Это сгодиться для большинства ОС и процов, которые поддерживают команду rdtsc ;-)
У меня на 98-й прекрасно всё определяется, также Max, по его словам, тестировал на разных OC.