Методы обнаружения трассировки

leo
_basmp_
Отлично. Спасибо.

 

Привет),
Athlon XP, 1.49 GHz
1) ~1963
2) ~1008

 

blast
Привет. Спасибо.

 

Clerk
у меня вообще ехе не запускаеться(вин 2008)

 

Почему не запускается ?

 

Clerk

Отнимать или не отнимать - не принципиально, это влияет только на то как в итоге принимать решение о наличии трассировки и какие задавать допуски

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

 

leo

Конечно. Например и так заюзать:

Код (Text):

1. IsTracerActive proc uses ebx
2.     Call QueryInterruptPerformance
3.     mov ebx,eax
4.     Call QueryStrayPerformance
5.     mov ecx,1024
6.     xor edx,edx
7.     mul ecx
8.     div ebx
9.     add eax,512
10.     xor edx,edx
11.     shr eax,10
12.     dec eax
13.     setz al
14.     movzx eax,al
15.     ret
16. IsTracerActive endp

В буфере и аффинити однозначно.

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

 

Athlon64 3000+, XP SP2
Запустил 4 раза:
1945 1070
1951 1024
1961 1021
2001 1030

 

MikDay
Благодарю.
С этим понятно. Непонятно почему не запускается у dead_body.

 

Это типа Windows Server 2008 ?
Есть у кого ядро(и ntdll.dll), плиз залейте.

 

Pentium M 1.7

;-------------- Без трассировки
4095 1881
3839 2148
3550 2042

;-------------- С трассировкой (OllyDbg)
3982 3982
4223 4399
3838 3814

 

Однозначно варя.

Оля не умеет такое делоть.

 

на реальной винде, XPSP2.

чего не умеет? трассировать?

 

Странные значения какието.
Так как надо не умеет. Там используется стандартный медленный отладочный механизм предоставляемый сервисами.

Можешь говорить что угодно и я не поверю, такое просто невозможно!

 

Совпадение, почему бы и нет? остальные результаты тоже не сильно отличаются.

 

Clerk

Эх... хотелось бы позлорадствовать на тему юзермодный отладчик vs ядерный отладчик. Но, к сожалению, Вы просто забываете, как OllyDebug трассирует. Она не ставит TF. По умолчанию она ставит одноразовые int3 на каждую следующую инструкцию.
Кстати, как Вам такие результаты (которые без трассировки) для P4 3.4 HT?

Без трассировки:
1896 1048
2014 8344
2174 1287
2357 9457
Трассировка в обход под Olly:
1980 1999
1954 2010
2026 1992
1999 1956

 

Уфф...
Я в пустое говорю ?
1. Вывод кривой. Время под трассировкой меньше быть не может.
2. Что вы трассируете под олей, если вторая часть этого exe - трассировщик DD
3.
l_inc
Вы просто не знаете.
Делаем: Int 2A / pushfd / pop eax / бряк и жмём в оле Ctrl+F11(Trace Into). Увидим что бит EF.TF взведён в Eax.
Нормальный:

 

Clerk

Я вообще-то о том, что трассировка под Olly, - это на самом деле не трассировка, а просто запуск программы на исполнение. К тому же по умолчанию Olly вообще не допустит передачу управления вашему VectoredHandler. Соответственно TF не будет взведён и значения получатся одинаковыми (или похожими), т.к. никакой трассировки не будет. Отсюда и результаты, полученные 2FED.

Вот результаты для P4 3.4 HT для next:
1838 1054
2214 1103
1995 956
2027 943
Уж слишком колеблются значения.

 

l_inc
Трассировка под олей - нормальная трассировка использующая TF, только минус - слишком медленно и слишком просто обнаружить. Результаты 2FED - я им не верю.
Разность этих значений приближается к 10^3. Достаточно просто доказать факт трассировки.

 

Больше можно не обсуждать тему временных задержек, предположение насчёт константы оказалось верным.