Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "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
4-94235
BaDeVlad
2003-12-22 09:05
2004.02.29
Окно в BackGround е


1-93851
Budy
2004-02-16 14:25
2004.02.29
Реестр


1-93836
RUS
2004-02-16 10:23
2004.02.29
Таблица с полем в виде memo


1-93997
tipman
2004-02-16 09:24
2004.02.29
Передача динамическиго массива в процедуру....


7-94207
Aleksey
2003-12-12 06:20
2004.02.29
Shell в





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский