Вопрос знатокам от неуча.

Такие отладчики ring3 как OllyDbg, W32Dasm и TD32 элементарно обнаруживаются по значению адреса функции Win API в таблице импорта.
Если процесс загружен ОС, то в таблице импорта стоит непосредственно адрес функции из системной dll, скажем kernel32:
JMP dword ptr [X]
...
X:
dd Y //где Y - адрес функции в kernel32

Отладчики же вместо реального адреса Y отсылают нас к "thunk to kernel32":
Y:
PUSH Z //где Z - адрес функции в kernel32
JMP ??? /где ??? - адрес какой-то функции в kernel32 (лень было разбираться какой)

Суть обнаружения таких отладчиков проста:
если Y < GetModuleHandle('kernel32') - мы под отладчиком.
Еще интересный факт - если сделать два разных объявления одной импортируемой функции, то отладчик создает для них разные thunk. Отсюда второй вариант обнаружения отладчика: если для разных объявлений одной функции адреса Y не равны - мы под отладчиком.

Хотелось бы знать: все ли отладчики ring3 используют такие thunk и для чего, или в том же OllyDbg есть опция, исключающая такую переадресацию ?

Переходники делают не отладчики а ОС когда отладчик чепляется к процессу - это надо чтобы ставить бряки на апишки (в сам kernel32.dll отладчик ring-3 естесно писать не может).

„Переходники делают не отладчики а ОС когда отладчик чепляется к процессу “
Т.е. ты хочешь сказать что в уже запущенном процессе при выполнении attachdebugger (или как оно там) ось быстренько перестроит ему таблицу импорта ? Или переходники впихиваются только если сделать createprocess с флагом debug ?

Что-то не пойму, никакие переходники не появляются, и адреса у 2х MessageBoxA одинаковые. (под OllyDbg)
Или я что-то не так делаю? :(

1498235794__hello.exe

> Т.е. ты хочешь сказать что в уже запущенном процессе
> при выполнении attachdebugger (или как оно там) ось
> быстренько перестроит ему таблицу импорта ?

Эээ, скорее нет, чем да :)
Проверять неначем:

Windows 9x doesn't implement copy-on-write, thus operating system attempts to keep away the debuggers from stepping into functions above the 2-GB frontier. That is the reason why GetProcAddress() returns a debug thunk instead of the actual address.

„That is the reason why GetProcAddress() returns a debug thunk instead of the actual address“
ага, т.е. под 98й результат функции GPA будет отличатся в зависимости от наличия либо отсутствия отладчика. Я правильно понимаю ?

leo „Хотелось бы знать: все ли отладчики ring3 используют такие thunk и для чего, или в том же OllyDbg есть опция, исключающая такую переадресацию ?“

В Олли я не нашёл похожего , а вот в Softsnoop есть опция "Don't trap Imports of the following dlls:"

„Отладчики же вместо реального адреса Y отсылают нас к "thunk to kernel32":
Y:
PUSH Z //где Z - адрес функции в kernel32
JMP ??? /где ??? - адрес какой-то функции в kernel32 (лень было разбираться какой) “

Чем это ты высмотрел ? Вот два разных примера вызова ф-ции , ты можешь показать , где нас Олли обманывает ?

FF15 7A304000 CALL DWORD PTR DS:[<&user32.MessageBoxA>]
DS:[0040307A]=77E38098 (user32.MessageBoxA)
msgbox.<ModuleEntryPoint>+0E

E8 0E000000 CALL <JMP.&user32.MessageBoxA>
FF25 08204000 JMP DWORD PTR DS:[<&user32.MessageBoxA>]
DS:[00402008]=77E38098 (user32.MessageBoxA)
Local call from 00401477

Дык, Dr.Golova уже всё написал - только для мастдаев так происходит, в NT такого с импортом не происходит..


ЗЫ
Мой MessageBox в 9х и без дебаггера не запускается:

format	PE GUI	4.0 at 400000h

data	import
	dd	RVA ExitProcess, 0, 0, RVA k32, RVA ExitProcess
	dd	RVA MessageBox, 0, 0, RVA u32, RVA MessageBox
	dd	RVA MessageBox2, 0, 0, RVA u32, RVA MessageBox2
	dd	0, 0, 0, 0, 0
k32	db	'kernel32',0
u32	db	'user32',0
EP	db	0,0, 'ExitProcess',0
MB	db	0,0, 'MessageBoxA',0
MB2	db	0,0, 'MessageBoxA',0

align 4
ExitProcess 	dd	RVA EP, 0
MessageBox 	dd	RVA MB, 0
MessageBox2 	dd	RVA MB2, 0

end data

entry	$
	push	64
	push	text
	push	caption
	push	0	
	mov	eax,[MessageBox]
	add	eax,[MessageBox2]
	shr	eax,1	
	call	eax

	push	0
	call	[ExitProcess]

caption:	db 'Test',0
text:		db 'hello',0

„Дык, Dr.Golova уже всё написал“

Пришлось мне снова поставить Magic Gooddy , чтоб перевести :)

„Мой MessageBox в 9х и без дебаггера не запускается:“

Ну так он рассчитан только на ХР видимо :) Зачем ты .dll убрал ?

Тьфу , нашёл win95 чтоб проверить , .dll там не причём . Это видимо нужно только для w2k :)
Теперь понятно о чём речь .

FF15 04174000 CALL DWORD PTR DS:[<&kernel32.GetModuleH>
DS:[00401704]=82B3E120, (Thunk to KERNEL32.GetModuleHandleA)

Возвращаясь к постановке вопроса:
Как я понял, переадресация используется только в Win9x,
а в NT таблица импорта всегда указывает на адрес функции ситемной dll независимо от наличия отладчика. Так ?

Тогда еще парочка наивных вопросов:
В Win9х процедура переадресации вызова при наличии отладчика формирует и хранит в fs:[20] цепочку (двухсвязный список) состояний fs:[0] и регистров CPU. Соответсвенно 1) fs:[20] != 0 - наличие отладчика и 2) под этот список выделяется дополнительный блок памяти => другой вариант контроля по VirtualQuery.
Вопрос: а как обстоит дело в NT, XP и т.п.?
1) что лежит по адресу fs:[20] ?
2) не распределяет ли ОС или отладчик в пространстве процесса дополнительных блоков памяти, которые можно обнаружить VirtualQuery ?

регистр fs указывает на текущий TIB (Thread Information Block). В отличие от 9х по смещению 20h там содержицца не DebugContext а processID текущего процесса. Именно оттуда значение берет ф-ция GetCurrentProcessId (сразу скажу шо это для НТ - полез в свою ХР проверить там код немножко другой
Disassembly of Function GetCurrentProcessId (0x77E768E9)
; *** GetCurrentProcessId (310) ***
SYM:GetCurrentProcessId
0x77E768E9: 64A118000000 mov eax,fs:[0x18]
0x77E768EF: 8B4020 mov eax,dword ptr [eax+0x20]
0x77E768F2: C3 ret *********************
)
Поэтому еще проверить надо.

Разобрался - по смещению 18h в TID содеожится указатель в копию его в памяти (туда кстати ссылается псевдорегистр TID в отладчике в ВЦ). Зачем так сложно то?

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

Да, с TIB и TEB в общих чертах понятно
(см. Volodya "Об упаковщиках в последний раз" ч.2).

А как насчет бредовой идеи анализа блоков памяти.
Неужели для отладочных целей не создаются новые блоки
или не изменяется статус существующих. Может кто че подскажет.

Или на досуге создать свою memory map и сравнить с OllyDbg ?

А чем тебе IsDebuggerPresent не угодил? Он тоже из тиба берет инфу. Или идея именно в том чтоб сделать как еще не делали?