Взаимодействие с dll, внедренными в "чужие" консольные проги
От: Unsacrificed  
Дата: 24.12.09 06:14
Оценка:
Необходимо выполнение неких операций в контексте других приложений, причем действия должны запускаться из "моего" приложения. Для GUI приложений это реализовано через hook типа WH_GETMESSAGE (к приложению цепляется dll обрабатывающая этот hook и обрабатывает посылаемые "моим" приложением сообщения). Для консольных приложений (а точнее приложений без очереди событий) такое не проходит, отсюда вопрос: как реализовать такое взаимодействие для приложений без очереди событий (консольных)?
dll hook взаимодействие
Re: Взаимодействие с dll, внедренными в "чужие" консольные п
От: alexey_ma Израиль  
Дата: 24.12.09 07:35
Оценка: 1 (1)
Здравствуйте, Unsacrificed, Вы писали:

U>Необходимо выполнение неких операций в контексте других приложений, причем действия должны запускаться из "моего" приложения. Для GUI приложений это реализовано через hook типа WH_GETMESSAGE (к приложению цепляется dll обрабатывающая этот hook и обрабатывает посылаемые "моим" приложением сообщения). Для консольных приложений (а точнее приложений без очереди событий) такое не проходит, отсюда вопрос: как реализовать такое взаимодействие для приложений без очереди событий (консольных)?

Можно попробовать добраться до консоли не из хука, а снаружи, из Вашего процесса. AttachConsole и т.д. Console Functions.
Если все же нужно внедряться в косольный процесс то можно попробовать использовать не хуковый метод внедрения а, например, способ с CreateRemoteThread, и соответственно, взаимодействие между Вашим процессом и удаленным потоком организовать не сообщениями, а с помощью MemoryMapFile, Pipe, MailSlots и т.п.
Уточните какие консольные приложения Вы имеете ввиду? Если это какие либо terminal emulation то стоит копнуть в сторону hllapi или ehllapi. Большенство широко используемых терминалов их поддерживают.( с этими api можно работать напрямую, из внешнего процесса).
Re: Взаимодействие с dll, внедренными в "чужие" консольные п
От: мыщъх США http://nezumi-lab.org
Дата: 24.12.09 07:37
Оценка:
Здравствуйте, Unsacrificed, Вы писали:

U>Необходимо выполнение неких операций в контексте других приложений, причем действия должны запускаться из "моего" приложения. Для GUI приложений это реализовано через hook типа WH_GETMESSAGE (к приложению цепляется dll обрабатывающая этот hook и обрабатывает посылаемые "моим" приложением сообщения). Для консольных приложений (а точнее приложений без очереди событий) такое не проходит, отсюда вопрос: как реализовать такое взаимодействие для приложений без очереди событий (консольных)?


открыть пайп — не вариант? а вообще же средств для организации IPC (inter process communication) очень много. те же сокеты, например. зачем эти извраты с хуками я так и не понял.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[2]: Взаимодействие с dll, внедренными в "чужие" консольны
От: Unsacrificed  
Дата: 24.12.09 07:41
Оценка:
Здравствуйте, alexey_ma, Вы писали:

_>Уточните какие консольные приложения Вы имеете ввиду? Если это какие либо terminal emulation то стоит копнуть в сторону hllapi или ehllapi. Большенство широко используемых терминалов их поддерживают.( с этими api можно работать напрямую, из внешнего процесса).


Смысл в том, что мне необходимо взаимодействовать с любыми приложениями (будь то cmd или far к примеру, вот только не уверен).
Re[2]: Взаимодействие с dll, внедренными в "чужие" консольны
От: Unsacrificed  
Дата: 24.12.09 07:46
Оценка:
Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, Unsacrificed, Вы писали:


U>>Необходимо выполнение неких операций в контексте других приложений, причем действия должны запускаться из "моего" приложения. Для GUI приложений это реализовано через hook типа WH_GETMESSAGE (к приложению цепляется dll обрабатывающая этот hook и обрабатывает посылаемые "моим" приложением сообщения). Для консольных приложений (а точнее приложений без очереди событий) такое не проходит, отсюда вопрос: как реализовать такое взаимодействие для приложений без очереди событий (консольных)?


М>открыть пайп — не вариант? а вообще же средств для организации IPC (inter process communication) очень много. те же сокеты, например. зачем эти извраты с хуками я так и не понял.


Средства конечно есть, но то(те) приложения, с в контексте которых нужно выполнять действия писаны не мной (они вообще могут быть любыми — far, notepad, paint и др.), т.е. прям в них я не могу внести функционал взаимодействия с моим приложением.
Re[3]: Взаимодействие с dll, внедренными в "чужие" консольны
От: ononim  
Дата: 24.12.09 07:48
Оценка:
U>Средства конечно есть, но то(те) приложения, с в контексте которых нужно выполнять действия писаны не мной (они вообще могут быть любыми — far, notepad, paint и др.), т.е. прям в них я не могу внести функционал взаимодействия с моим приложением.
То есть по русски говоря вы просто не знаете как заинжектить свою длл другим способом кроме хуков. Вы погуглите способов предостаточно.
Как много веселых ребят, и все делают велосипед...
Re[2]: Взаимодействие с dll, внедренными в "чужие" консольны
От: Unsacrificed  
Дата: 24.12.09 07:53
Оценка:
Здравствуйте, alexey_ma, Вы писали:

_>Если все же нужно внедряться в косольный процесс то можно попробовать использовать не хуковый метод внедрения а, например, способ с CreateRemoteThread, и соответственно, взаимодействие между Вашим процессом и удаленным потоком организовать не сообщениями, а с помощью MemoryMapFile, Pipe, MailSlots и т.п.


Тут есть нюанс — я хочу, чтобы взаимодействие проходило с любым приложением, которое только запущено, и, как я понимаю, глобальный хук автоматически будет охватывать вновь запущенные приложения, в то время как CreateRemoteThread, видимо, нужно будет запускать если запустилось ещё одно приложение (что надо ещё отловить). В целом я думаю это осуществимо, но надеюсь найти более простое решение.
Re[3]: Взаимодействие с dll, внедренными в "чужие" консольны
От: мыщъх США http://nezumi-lab.org
Дата: 24.12.09 07:53
Оценка:
Здравствуйте, Unsacrificed, Вы писали:

U>Здравствуйте, мыщъх, Вы писали:


М>>Здравствуйте, Unsacrificed, Вы писали:


U>>>...к приложению цепляется dll...


М>>открыть пайп — не вариант? а вообще же средств для организации IPC (inter process communication) очень много. те же сокеты, например. зачем эти извраты с хуками я так и не понял.


U> Средства конечно есть, но то(те) приложения, с в контексте которых нужно выполнять действия писаны не мной

U> т.е. прям в них я не могу внести функционал взаимодействия с моим приложением.
ну раз dll прицепили, то из dll можно сделать все, что угодно. в том числе и заюзать пайп. а если заюзать сокеты, то управлять можно будет и с другой планеты
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[3]: Взаимодействие с dll, внедренными в "чужие" консольны
От: alexey_ma Израиль  
Дата: 24.12.09 07:55
Оценка: 1 (1)
Здравствуйте, Unsacrificed, Вы писали:

U>Здравствуйте, alexey_ma, Вы писали:


_>>Уточните какие консольные приложения Вы имеете ввиду? Если это какие либо terminal emulation то стоит копнуть в сторону hllapi или ehllapi. Большенство широко используемых терминалов их поддерживают.( с этими api можно работать напрямую, из внешнего процесса).


U>Смысл в том, что мне необходимо взаимодействовать с любыми приложениями (будь то cmd или far к примеру, вот только не уверен).

В случае с обычной виндоусячьей консолью рулят Console Functions (ИМХО).
Про любые — это Вы погорячились. Даже оконных приложений — десятки разновидностей, плюс баги/особенности гуя и т.п. и т.д... Я уже несколько лет занимаюсь подобной пургой ( взаимодействованием между нашей программой и "любым" сторонним приложением), а проблем с каждым годом только прибавляется
Re[4]: Взаимодействие с dll, внедренными в "чужие" консольны
От: Unsacrificed  
Дата: 24.12.09 08:00
Оценка:
Здравствуйте, ononim, Вы писали:

O>То есть по русски говоря вы просто не знаете как заинжектить свою длл другим способом кроме хуков. Вы погуглите способов предостаточно.


Тут есть нюанс — я хочу, чтобы взаимодействие проходило с любым приложением, которое только запущено, и, как я понимаю, глобальный хук автоматически будет охватывать вновь запущенные приложения. Вот как автоматом цеплять ддл ко всем приложениям (в т.ч. и вновь создающимся) с минимумом усилий и ресурсозатрат?
Re[3]: Взаимодействие с dll, внедренными в "чужие" консольны
От: alexey_ma Израиль  
Дата: 24.12.09 08:04
Оценка:
Здравствуйте, Unsacrificed, Вы писали:

U>Тут есть нюанс — я хочу, чтобы взаимодействие проходило с любым приложением, которое только запущено, и, как я понимаю, глобальный хук автоматически будет охватывать вновь запущенные приложения, в то время как CreateRemoteThread, видимо, нужно будет запускать если запустилось ещё одно приложение (что надо ещё отловить). В целом я думаю это осуществимо, но надеюсь найти более простое решение.

Даже в этом случае не обязательно общаться с хуком посредством сообщений, организуйте другой IPC.
Кроме того, на мой взгляд более правильно мониторить создание процессов/потоков/окон и внедряться только туда куда действительно нужно.
Re[4]: Взаимодействие с dll, внедренными в "чужие" консольны
От: Unsacrificed  
Дата: 24.12.09 08:08
Оценка:
Здравствуйте, alexey_ma, Вы писали:

U>>Смысл в том, что мне необходимо взаимодействовать с любыми приложениями (будь то cmd или far к примеру, вот только не уверен).

_>В случае с обычной виндоусячьей консолью рулят Console Functions (ИМХО).
_>Про любые — это Вы погорячились. Даже оконных приложений — десятки разновидностей, плюс баги/особенности гуя и т.п. и т.д... Я уже несколько лет занимаюсь подобной пургой ( взаимодействованием между нашей программой и "любым" сторонним приложением), а проблем с каждым годом только прибавляется

К сожалению верю. Для себя провел какую-никакую классификацию: есть проги, обрабатывающие очередь сообщений и не обрабатывающие. Под первую группу попадают видимо если не все, то большинство прог с GUI и к ним я применил указанный выше метод с hook (вроде работает со всеми GUI, которые я пробовал, кроме Visual Studio). А вот с теми прогами, что не обрабатывают очередь сообщений (а это видимо все или большинство консольных приложений) что делать не знаю.
Re[4]: Взаимодействие с dll, внедренными в "чужие" консольны
От: Unsacrificed  
Дата: 24.12.09 08:19
Оценка:
Здравствуйте, alexey_ma, Вы писали:

_>Даже в этом случае не обязательно общаться с хуком посредством сообщений, организуйте другой IPC.


А вот тут можно по-подробней??? Загрузил dll, использовал одну из её функций для глобального хука. Если я использую хук WH_GETMESSAGE, то послав сообщение я, по сути, запуская как раз свою функцию в чужом контексте. Можно пример с указанием тип хука и как заставить этот хук инициирует IPC и будет его слушать???

_>Кроме того, на мой взгляд более правильно мониторить создание процессов/потоков/окон и внедряться только туда куда действительно нужно.


Внедрять нужно везде, где пользователь может что-то ввести с клавы — мне видиться мониторить в этом случае не самым удобным вариантом.
Re[5]: Взаимодействие с dll, внедренными в "чужие" консольны
От: alexey_ma Израиль  
Дата: 24.12.09 08:34
Оценка:
Здравствуйте, Unsacrificed, Вы писали:

U>Здравствуйте, alexey_ma, Вы писали:


_>>Даже в этом случае не обязательно общаться с хуком посредством сообщений, организуйте другой IPC.


U>А вот тут можно по-подробней??? Загрузил dll, использовал одну из её функций для глобального хука. Если я использую хук WH_GETMESSAGE, то послав сообщение я, по сути, запуская как раз свою функцию в чужом контексте. Можно пример с указанием тип хука и как заставить этот хук инициирует IPC и будет его слушать???

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

_>>Кроме того, на мой взгляд более правильно мониторить создание процессов/потоков/окон и внедряться только туда куда действительно нужно.


U>Внедрять нужно везде, где пользователь может что-то ввести с клавы — мне видиться мониторить в этом случае не самым удобным вариантом.

Чего Вы все-таки делаете (в двух словах) ?
Re: Взаимодействие с dll, внедренными в "чужие" консольные п
От: Unsacrificed  
Дата: 24.12.09 08:37
Оценка:
Кстати, программы для переключения раскладки клавиатуры (например PuntoSwitcher) используют хуки, и их деятельность распространяется пусть не на абсолютно все, но вроде как на абсолютное большинство программ — как в них может быть реализована работа с приложениями без очереди сообщений???
Re[6]: Взаимодействие с dll, внедренными в "чужие" консольны
От: Unsacrificed  
Дата: 24.12.09 08:54
Оценка:
Здравствуйте, alexey_ma, Вы писали:

_>Создайте в хуке свой собственный поток, который стоит и ждет например поименнованного эвента, в Вашем процессе делаете SetEvent этому самому эвенту, хуковый поток просыпаеться и вызывает нужную Вам функцию в чужом контексте и опять уходит в ожидание. Если нужны какие-то дополнительные параметры для выполнения функции в хуковом потоке, то можете записать их в поименованный мап файл перед тем как сделать SetEvent, соответственно хуковый поток проснувшись по эвенту сначала читает нужные ему данные из мап-файла а потом выполняет функцию в чужом контексте, и если нужно передать какие либо результаты выполнения обратно в Ваш процесс, то в тот же мап эти результаты пишет.


Допустим написал функцию хука, которая создает поток (пока не пойму какой тип хука это будет). Потом установил этот хук (setwindowshookex), но ведь чтобы функция хука запустилась нужны некие события (в зависимости от типа хука — например нажатие клавиши клавиатуры/мыши или получение сообщения) и пока эти события не произойдут функция не запустится и не создаст поток. Или я где-то не прав???

_>Чего Вы все-таки делаете (в двух словах) ?

Пытаюсь переключать язык (раскладку клавиатуры).
Re[4]: Взаимодействие с dll, внедренными в "чужие" консольны
От: Unsacrificed  
Дата: 24.12.09 09:05
Оценка:
Здравствуйте, мыщъх, Вы писали:

М>ну раз dll прицепили, то из dll можно сделать все, что угодно. в том числе и заюзать пайп. а если заюзать сокеты, то управлять можно будет и с другой планеты


Я установил hook (одна функция в dll файле) и я не знаю как нормально заставить эту функцию запуститься хотя бы единожды чтобы что-то сделать (например запустить поток и начать слашать сокет). Если говорим о приложениях с обработкой очереди сообщений, то я ставлю хук типа WH_GETMESSAGE и использую сообщения для запуска, а если программа не использует очередь — тогда то как?
Re[7]: Взаимодействие с dll, внедренными в "чужие" консольны
От: alexey_ma Израиль  
Дата: 24.12.09 09:11
Оценка: 2 (1)
Здравствуйте, Unsacrificed, Вы писали:

U>Допустим написал функцию хука, которая создает поток (пока не пойму какой тип хука это будет). Потом установил этот хук (setwindowshookex), но ведь чтобы функция хука запустилась нужны некие события (в зависимости от типа хука — например нажатие клавиши клавиатуры/мыши или получение сообщения) и пока эти события не произойдут функция не запустится и не создаст поток. Или я где-то не прав???

Везде правы, но можно сделать по другому. Хуковая процедура вообще может ничего не делать( кроме конечно CallNextHook). Тип хука тоже не столь важен. Самый простой способ такой : пишите класс который в кострукторе создает нужный вам поток, а в хуковой длл обьявляете глобальную переменную типа этого класса, таким образом Вы сможете запустить поток не из хуковой процедуры.
И еще, если Вы большой любитель сообщений, то можно создать в кострукторе этого класса невидимое окно которому сможете посылать свои сообщения, в обработчиках которых будете выполнять нужные вам действия, таким образом Вам даже поток не понадобится.

_>>Чего Вы все-таки делаете (в двух словах) ?

U>Пытаюсь переключать язык (раскладку клавиатуры).
А зачем, мало их что-ли ?
Re[8]: Взаимодействие с dll, внедренными в "чужие" консольны
От: Unsacrificed  
Дата: 24.12.09 09:24
Оценка:
Здравствуйте, alexey_ma, Вы писали:

_>Везде правы, но можно сделать по другому. Хуковая процедура вообще может ничего не делать( кроме конечно CallNextHook). Тип хука тоже не столь важен. Самый простой способ такой : пишите класс который в кострукторе создает нужный вам поток, а в хуковой длл обьявляете глобальную переменную типа этого класса, таким образом Вы сможете запустить поток не из хуковой процедуры.

_>И еще, если Вы большой любитель сообщений, то можно создать в кострукторе этого класса невидимое окно которому сможете посылать свои сообщения, в обработчиках которых будете выполнять нужные вам действия, таким образом Вам даже поток не понадобится.

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

_>А зачем, мало их что-ли ?


Было интересно, как переключать программно раскладки в Windows, что плавно перешло в работу с хуками, а теперь уже интересно, реально ли это сделать более или менее нормально (чтобы работало) — с целью самообразования.
Re[9]: Взаимодействие с dll, внедренными в "чужие" консольны
От: alexey_ma Израиль  
Дата: 24.12.09 09:38
Оценка:
Здравствуйте, Unsacrificed, Вы писали:


U>Т.е. несмотря на то, что подгружал я dll в своей программе, для каждой проги, куда я повесил хук, будет создаваться свой экземпляр класса??? Тогда, если я не ошибаюсь, мне достаточно просто в конструкторе этого класса вызвать функцию чтения из очереди сообщений и очередь будет создана автоматом (т.е. даже создавать окно по-моему не надо) — я попробую данный вариант, он именно то, что я искал (лишь бы получилось).

Зкземпляр класса будет создаваться в каждом процессе куда загруженна хуковая длл. Если нужны одельный экземпляр для потока то можно попробовать поиграться с DllMain, типа на DLL_THREAD_ATTACH создавать зкземпляр класса по new, на DLL_THREAD_DETACH делать ему delete.
Я с очередями не пробовал, возможно получится.

_>>А зачем, мало их что-ли ?


U>Было интересно, как переключать программно раскладки в Windows, что плавно перешло в работу с хуками, а теперь уже интересно, реально ли это сделать более или менее нормально (чтобы работало) — с целью самообразования.

Ну чтож, удачи
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.