Форум: "WinAPI";
Текущий архив: 2004.02.29;
Скачать: [xml.tar.bz2];
Вниз
НООК? ! Найти похожие ветки
← →
Невозмутимый (2003-12-23 15:43) [0]Подскажите пожалуйста, как можно (и можно ли вообще) при помощи хука (hook) отловить вызов функции: GetDeviceCap из посторонней программы?! И, если у Вас будет такая возможность, с примером…
← →
Digitman (2003-12-24 08:24) [1]если "посторонняя программа" есть GUI-приложение, то механизм установки глоб.хука можно использовать в части внедрения тела хук-DLL в АП интересующего процесса. В момент инициализации внедряемая библиотека просто перехватывает этот интересующий WinAPI-вызов любым удобным и корректным способом
← →
Невозмутимый (2003-12-24 10:42) [2]Интересно... Большое спасибо за совет, попробую, дело в том, что это действительно GUI-приложение...
← →
Digitman (2003-12-24 11:04) [3]
> Невозмутимый
сей простой способ плох одним - экз-ры хук-библиотеки при установке глоб.хука будут внедрены системой во все без исключения GUI-процессы (существующие и потенциально стартуемые)
т.е. ради простого достижения рез-та приходится жертвовать автоматическим "загаживанием" адр.пространств иных (совершенно не интересующих) процессов кодом и данными экз-ров хук-модуля
теоретически можно вроде бы при инициализации экз-ра хук-модуля в неинтересующем процессе вернуть системе DLL_INIT_FAIL (дабы модуль был тут же выгружен системой из неинтересующего процесса), но реакция системы на такой "финт" на практике весьма непредсказуемая .. в MSDN же мне не удалось найти ни единого комментария по поводу корректности или некорректности применения этго "финта"
← →
Невозмутимый (2003-12-24 11:37) [4]Хм... посмотрю, может на конкретный поток буду ставить хук, либо буду реализовывать через механизм удаленных потоков, используя ф-ций: WriteProcessMemory() и LoadLibrary(); т.е. что будет по времени быстрее, на том и остановлюсь...
Спасибо за уточнение! :)
← →
Digitman (2003-12-24 11:47) [5]
> может на конкретный поток буду ставить хук
как это "на конкретный поток" ?
глоб.хук не позволит тебе указать этот параметр
> механизм удаленных потоков, используя ф-ций: WriteProcessMemory()
> и LoadLibrary();
не пойдет.
в то время как ты сподобишься определить факт запуска целевого процесса и будешь самостоятельно внедрять в его AП код перехвата (с использованием CreateRemoteThread), целевой процесс вполне мог уже к этому моменту не менее 1-го раза вызвать интересующую тебя ф-цию и , вполне возможно, более ее никогда не вызовет ... Тем не менее факт хотя бы однократного вызова ф-ции GetDeviceCap вполне мог быть. а ты его попросту "проморгал", ибо не имеешь возможности "поймать" момент старта целевого процесса, чтобы немедля установить там ловушку вызова
← →
Невозмутимый (2003-12-24 12:47) [6]>как это "на конкретный поток" ? глоб.хук не позволит тебе >указать этот параметр
Дело в том, что была мысль отказаться от идеи "глобального хука", а установить хук на конкретный поток, известного процесса... Но опять - таки, я попадаю в ситуацию, описанную Вами:"в то время как ты сподобишься определить факт запуска целевого процесса ... целевой процесс вполне мог уже к этому моменту не менее 1-го раза вызвать интересующую тебя ф-цию...".
Таким образом, те же "грабли"... Буду дальше думать... :(
← →
Digitman (2003-12-24 13:22) [7]
> установить хук на конкретный поток
хук на поток установить нельзя вообще
а если бы и можно было, почем ты знаешь, какой конкретно кодовый поток однозначно будет вызывать GetDeviceCaps() ? А если более чем один кодовый поток это делает там ?
← →
Невозмутимый (2003-12-24 15:07) [8]>хук на поток установить нельзя вообще
???!!! Хм... мне думается все-таки что можно, хотя согласен немного "гиморно" НО можно...
Но в целом согласен, вот и думаю, поступиться с принципом устойчивости системы вцелом, либо ковыряться в PE-заголовке интересующего меня приложения...
Спасибо за дельный совет, и интерес к моей задаче...
← →
Digitman (2003-12-24 15:19) [9]
> мне думается все-таки что можно
нельзя) ... как ты вообще мыслишь это - "хук на поток" ?
кодовый поток, прежде всего - объект ОС, такой же равноправный объект как "окно" или "процесс"...
как можно вообще установить "хук на объект" ?
хук можно установить на конкретное ДЕЙСТВИЕ, выполняемое тем или иным объектом в том или ином контексте ... или - СОБЫТИЕ, потенциально происходящее с тем или иным объектом при тех или иных условиях
← →
Невозмутимый (2003-12-24 15:39) [10]Возможно я не совсем корректно выразился, поэтому уточню, под выражением: "установить хук на конкретный поток", я подразумевал что - как только ИНТЕРЕСУЮЩИЙ НАС (конкретный) поток получит сообщение, соответствующее заданному типу хука, система автоматически подключит DLL c хуком к ДАННОМУ процессу. Не более и не менее того... :) В отличии от глобального, с указанием идентификатора конкретного потока...
ДА и к слову...
Все! В конечном итоге, реализовал через глобальный хук...
Работает... система стабильна...
Большое СПАСИБО! Удачи!
← →
Digitman (2003-12-24 15:59) [11]
> В отличии от глобального, с указанием идентификатора конкретного
> потока
как раз в случае глобального хука при вызове SetWindowsHookEx() недопустимо передавать последним параметром Id кодового потока, этот параметр должен быть передан со значением 0.
> как только ИНТЕРЕСУЮЩИЙ НАС (конкретный) поток получит сообщение
SetWindowsHookEx() не предусматривает вообще возможность установки хука на сообщения потокам, только - на оконные сообщения
> система автоматически подключит DLL c хуком к ДАННОМУ процессу
да она УЖЕ подключила ! что еще подключать-то ? ведь хук то уже установлен !
либо речи не идет о SetWindowsHookEx() либо я вообще не понимаю твоей логики
← →
Невозмутимый (2003-12-24 16:20) [12]У меня прекрасно работает с параметром 0, по поводу недопустимости Id кодового потока, это уже чисто академический интерес - Если у функции:
function SetWindowsHookEx(idHook: Integer; lpfn: TFNHookProc; hmod: HINST; dwThreadId: DWORD): HHOOK;
Параметр:dwThreadId который по определению: "Определяет идентификатор нити, с которым процедура ловушки должна быть связана. Если этот параметр - нуль, то процедура ловушки связана со всеми существующими нитями",- трактуется как-то иначе, т.е. он должен принимать ТОЛЬКО НУЛЕВОЕ значение, то я конечно говоря о "конкретном" потоке, нес чепуху, однако если этот параметр может принимать значение "идентификатора нити", то мои рассуждения верны, буду попробовать на практике... :)
← →
Digitman (2003-12-24 16:47) [13]там - вникни ! - либо ты указываешь hmod и не указываешь dwThreadId (лок.хук, т.е. хук в контексте тек.процесса) либо - наоборот (глоб.хук, т.е. хук в контексте всех GUI-процессов)
← →
Невозмутимый (2003-12-24 17:12) [14]Уже вник... :)
Снимаю шляпу...
Спасибо за ответы!!!
Страницы: 1 вся ветка
Форум: "WinAPI";
Текущий архив: 2004.02.29;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.011 c