Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

НООК? ! [D5, D7, Win95/98, Win2k, WinXP]

Невозмутимый © (2003-12-23 15:43:00)

Подскажите пожалуйста, как можно (и можно ли вообще) при помощи хука (hook) отловить вызов функции: GetDeviceCap из посторонней программы?! И, если у Вас будет такая возможность, с примером…

Невозмутимый (2003-12-24 17:12:00) [1]

Уже вник... :)
Снимаю шляпу...
Спасибо за ответы!!!

Digitman (2003-12-24 16:47:00) [2]

там - вникни ! - либо ты указываешь hmod и не указываешь dwThreadId (лок.хук, т.е. хук в контексте тек.процесса) либо - наоборот (глоб.хук, т.е. хук в контексте всех GUI-процессов)

Невозмутимый (2003-12-24 16:20:00) [3]

У меня прекрасно работает с параметром 0, по поводу недопустимости Id кодового потока, это уже чисто академический интерес - Если у функции:
function SetWindowsHookEx(idHook: Integer; lpfn: TFNHookProc; hmod: HINST; dwThreadId: DWORD): HHOOK;
Параметр:dwThreadId который по определению: "Определяет идентификатор нити, с которым процедура ловушки должна быть связана. Если этот параметр - нуль, то процедура ловушки связана со всеми существующими нитями",- трактуется как-то иначе, т.е. он должен принимать ТОЛЬКО НУЛЕВОЕ значение, то я конечно говоря о "конкретном" потоке, нес чепуху, однако если этот параметр может принимать значение "идентификатора нити", то мои рассуждения верны, буду попробовать на практике... :)

Digitman (2003-12-24 15:59:00) [4]

> В отличии от глобального, с указанием идентификатора конкретного
> потока

как раз в случае глобального хука при вызове SetWindowsHookEx() недопустимо передавать последним параметром Id кодового потока, этот параметр должен быть передан со значением 0.

> как только ИНТЕРЕСУЮЩИЙ НАС (конкретный) поток получит сообщение

SetWindowsHookEx() не предусматривает вообще возможность установки хука на сообщения потокам, только - на оконные сообщения

> система автоматически подключит DLL c хуком к ДАННОМУ процессу

да она УЖЕ подключила ! что еще подключать-то ? ведь хук то уже установлен !

либо речи не идет о SetWindowsHookEx() либо я вообще не понимаю твоей логики

Невозмутимый (2003-12-24 15:39:00) [5]

Возможно я не совсем корректно выразился, поэтому уточню, под выражением: "установить хук на конкретный поток", я подразумевал что - как только ИНТЕРЕСУЮЩИЙ НАС (конкретный) поток получит сообщение, соответствующее заданному типу хука, система автоматически подключит DLL c хуком к ДАННОМУ процессу. Не более и не менее того... :) В отличии от глобального, с указанием идентификатора конкретного потока...

ДА и к слову...
Все! В конечном итоге, реализовал через глобальный хук...
Работает... система стабильна...
Большое СПАСИБО! Удачи!

Digitman (2003-12-24 15:19:00) [6]

> мне думается все-таки что можно

нельзя) ... как ты вообще мыслишь это - "хук на поток" ?

кодовый поток, прежде всего - объект ОС, такой же равноправный объект как "окно" или "процесс"...

как можно вообще установить "хук на объект" ?

хук можно установить на конкретное ДЕЙСТВИЕ, выполняемое тем или иным объектом в том или ином контексте ... или - СОБЫТИЕ, потенциально происходящее с тем или иным объектом при тех или иных условиях

Невозмутимый (2003-12-24 15:07:00) [7]

>хук на поток установить нельзя вообще
???!!! Хм... мне думается все-таки что можно, хотя согласен немного "гиморно" НО можно...
Но в целом согласен, вот и думаю, поступиться с принципом устойчивости системы вцелом, либо ковыряться в PE-заголовке интересующего меня приложения...
Спасибо за дельный совет, и интерес к моей задаче...

Digitman (2003-12-24 13:22:00) [8]

> установить хук на конкретный поток

хук на поток установить нельзя вообще
а если бы и можно было, почем ты знаешь, какой конкретно кодовый поток однозначно будет вызывать GetDeviceCaps() ? А если более чем один кодовый поток это делает там ?

Невозмутимый (2003-12-24 12:47:00) [9]

>как это "на конкретный поток" ? глоб.хук не позволит тебе >указать этот параметр

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

Таким образом, те же "грабли"... Буду дальше думать... :(

Digitman (2003-12-24 11:47:00) [10]

> может на конкретный поток буду ставить хук

как это "на конкретный поток" ?
глоб.хук не позволит тебе указать этот параметр

> механизм удаленных потоков, используя ф-ций: WriteProcessMemory()
> и LoadLibrary();

не пойдет.
в то время как ты сподобишься определить факт запуска целевого процесса и будешь самостоятельно внедрять в его AП код перехвата (с использованием CreateRemoteThread), целевой процесс вполне мог уже к этому моменту не менее 1-го раза вызвать интересующую тебя ф-цию и , вполне возможно, более ее никогда не вызовет ... Тем не менее факт хотя бы однократного вызова ф-ции GetDeviceCap вполне мог быть. а ты его попросту "проморгал", ибо не имеешь возможности "поймать" момент старта целевого процесса, чтобы немедля установить там ловушку вызова

Невозмутимый (2003-12-24 11:37:00) [11]

Хм... посмотрю, может на конкретный поток буду ставить хук, либо буду реализовывать через механизм удаленных потоков, используя ф-ций: WriteProcessMemory() и LoadLibrary(); т.е. что будет по времени быстрее, на том и остановлюсь...
Спасибо за уточнение! :)

Digitman (2003-12-24 11:04:00) [12]

> Невозмутимый

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

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

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

Невозмутимый (2003-12-24 10:42:00) [13]

Интересно... Большое спасибо за совет, попробую, дело в том, что это действительно GUI-приложение...

Digitman (2003-12-24 08:24:00) [14]

если "посторонняя программа" есть GUI-приложение, то механизм установки глоб.хука можно использовать в части внедрения тела хук-DLL в АП интересующего процесса. В момент инициализации внедряемая библиотека просто перехватывает этот интересующий WinAPI-вызов любым удобным и корректным способом

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »