коллега задал интересный вопрос :
дословно "если у нас есть процесс без очереди сообщений (типа консольного) под 98, то поставить хук не удается"

вообще говоря, хук для него не самоцель, его интересовал вопрос внедрения в такой процесс в широком смысле, вплоть до использования Kernel mode компонентов. Сам я ничего вспомнить-подсказать тут не сумел, но вопрос остался занозой...

наконец решил эту занозу удалить , но поиск навскидку ничего мне не принес

может быть Гуру, уже наверняка отвечавшие тут, не сочтут за труд просветить нас в этом вопросе

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

V>коллега задал интересный вопрос :
V>дословно "если у нас есть процесс без очереди сообщений (типа консольного) под 98, то поставить хук не удается"
V>вообще говоря, хук для него не самоцель, его интересовал вопрос внедрения в такой процесс в широком смысле, вплоть до использования Kernel mode компонентов. Сам я ничего вспомнить-подсказать тут не сумел, но вопрос остался занозой...

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

Здравствуйте, Plutonia Experiment, Вы писали:

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

спасибо, забыл только сказать что такие способы не очень катят (где нужно перегружаться и т.п.)
по идее процесс уже _может быть_ запущен. В этом случае есть варианты?

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

V>В этом случае есть варианты?

Есть "тяжелая" артиллерия. ::DebugActiveProcess().
Это единственный способ получить хендл нити из
чужого процесса в Win9x. А нам нужен полный список
всех нитей этого приложения.

Дальше все просто

• SuspendThread(все нити приложения)
  
• ReadProcessMemory(сохраняем) + WriteProcessMemory(пишем наш код)
  
• GetThreadContext(к-л нити).
  
• SetThreadContext(на записанный код). + ResumeThread().
  Это позволит нам выполнить код, закинутый в пункте 2.
  
• SuspendThread(этой нити)
  
• SetThreadContext(какой был).
  
• WriteProcessMemory(сохраненный код)
  
• ResumeThread(все нити приложения)

Павел.
P.S. Не стоит оно того.

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

V>коллега задал интересный вопрос :
V>дословно "если у нас есть процесс без очереди сообщений (типа консольного) под 98, то поставить хук не удается"

V>вообще говоря, хук для него не самоцель, его интересовал вопрос внедрения в такой процесс в широком смысле, вплоть до использования Kernel mode компонентов. Сам я ничего вспомнить-подсказать тут не сумел, но вопрос остался занозой...
самый простой вариант IMHO — вписать в процесс небольшой загрузчик, выделяющий память и подгружающий основной код. А также, переставить на этот загрузчик вектор функции WriteFile/ReadFile/WriteConsole/ReadConsole в секции импортов — большинство консольных прог часто используют эти вызовы

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

eax>самый простой вариант IMHO — вписать в процесс небольшой загрузчик

Нельзя ли подровнее, что значит "вписать в процесс небольшой загрузчик"?
Павел.

V>>коллега задал интересный вопрос :
V>>дословно "если у нас есть процесс без очереди сообщений (типа консольного) под 98, то поставить хук не удается"
V>>вообще говоря, хук для него не самоцель, его интересовал вопрос внедрения в такой процесс в широком смысле, вплоть до использования Kernel mode компонентов. Сам я ничего вспомнить-подсказать тут не сумел, но вопрос остался занозой...

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

Я тот коллега, который задавал этот вопрос.
Через реестр dll'ки подгружаются только в те процессы, которые импортируют user32.dll, т.е. все равно есть некоторое ограничение. Ну и перезагружаться не хочется. К тому же строчка, где хранится список этих dll'ек ограничена какой-то маленькой длиной, сейчас точно не вспомню какой.

БП>Есть "тяжелая" артиллерия. ::DebugActiveProcess().
БП>Это единственный способ получить хендл нити из
БП>чужого процесса в Win9x. А нам нужен полный список
БП>всех нитей этого приложения.

Этот вариант не подходит по причине того, что если мы один раз сделали на процесс DebugActiveProcess, то detach сделать мы уже не сможем. А если например нужно встраивать свой код в любой запускаемый процесс в системе, то вообще все плохо

eax>самый простой вариант IMHO — вписать в процесс небольшой загрузчик, выделяющий память и подгружающий основной код. А также, переставить на этот загрузчик вектор функции WriteFile/ReadFile/WriteConsole/ReadConsole в секции импортов — большинство консольных прог часто используют эти вызовы
eax>
А если стоит ограничение что менять exe'шник нельзя? К тому же есть процессы, которые отрицательно относятся к изменению себя на диске.
А если вы говорили не про прямое изменение exe на диске, то проясните пожалуйста ситуацию.

Здравствуйте, Блудов Павел, Вы писали:

eax>>самый простой вариант IMHO — вписать в процесс небольшой загрузчик

БП>Нельзя ли подровнее, что значит "вписать в процесс небольшой загрузчик"?
БП>Павел.

Перебираешь модули процесса (ModuleFirst/ModuleNext в win9x; EnumProcessModules в winnt).
В каждый из модулей в свободное место между секциями пытаешься вписать загрузчик (VirtualProectEx, WriteProcessMemory) . 100% гарантии нет,
но в сам EXE и однократно загруженные DLL писать обычно можно.

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


eax>>самый простой вариант IMHO — вписать в процесс небольшой загрузчик, выделяющий память и подгружающий основной код. А также, переставить на этот загрузчик вектор функции WriteFile/ReadFile/WriteConsole/ReadConsole в секции импортов — большинство консольных прог часто используют эти вызовы
eax>>
M>А если стоит ограничение что менять exe'шник нельзя? К тому же есть процессы, которые отрицательно относятся к изменению себя на диске.
M>А если вы говорили не про прямое изменение exe на диске, то проясните пожалуйста ситуацию.

в память через WriteProcessMemory

А>Перебираешь модули процесса (ModuleFirst/ModuleNext в win9x; EnumProcessModules в winnt).
А>В каждый из модулей в свободное место между секциями пытаешься вписать загрузчик (VirtualProectEx, WriteProcessMemory) . 100% гарантии нет,
А>но в сам EXE и однократно загруженные DLL писать обычно можно.

Ну этот вариант тоже довольно таки ограничен, например: Windows 95/98/Me: You cannot use VirtualProtectEx on any memory region located in the shared virtual address space (from 0x80000000 through 0xBFFFFFFF).
Остается писать только в сам EXE. А если места нет между секциями или его очень мало???

А вообще лучше переформулировать задачу — нужно цепляться ко всем процессам, которые запускаются, сразу, т.е. до того как мы перешли на entry point.

Да, забыл добавить. Скорее всего нет решения для моей проблемы только через user mode, ищется решение на уровне ядра.

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


А>>Перебираешь модули процесса (ModuleFirst/ModuleNext в win9x; EnumProcessModules в winnt).
А>>В каждый из модулей в свободное место между секциями пытаешься вписать загрузчик (VirtualProectEx, WriteProcessMemory) . 100% гарантии нет,
А>>но в сам EXE и однократно загруженные DLL писать обычно можно.

M>Ну этот вариант тоже довольно таки ограничен, например: Windows 95/98/Me: You cannot use VirtualProtectEx on any memory region located in the shared virtual address space (from 0x80000000 through 0xBFFFFFFF).
M>Остается писать только в сам EXE. А если места нет между секциями или его очень мало???
а много и не надо — нужно вызвать всего 3 API функций. в 100 байт можно уложиться, если на асме писать

M>А вообще лучше переформулировать задачу — нужно цепляться ко всем процессам, которые запускаются, сразу, т.е. до того как мы перешли на entry point.
Это можно и из ring3 сделать: влезаешь описанным выше способом во все процессы и перехватываешь CreateProcessA/W

M>>Ну этот вариант тоже довольно таки ограничен, например: Windows 95/98/Me: You cannot use VirtualProtectEx on any memory region located in the shared virtual address space (from 0x80000000 through 0xBFFFFFFF).
M>>Остается писать только в сам EXE. А если места нет между секциями или его очень мало???
eax>а много и не надо — нужно вызвать всего 3 API функций. в 100 байт можно уложиться, если на асме писать
100 байт или 1000 какая разница, если места вообще ноль, то ничего не получится. Кстати, а зачем вообще искать свободное место, никто нам не мешает переписать произвольный код в процессе(конечно сделав копию где-нибудь у себя), например начиная с entry point, а потом при исполнении своего кода вернуть все обратно. В этом случае даже ModuleFirst/ModuleNext не нужны, exe'шники всегда по одному адресу 0x400000 грузятся.

M>>А вообще лучше переформулировать задачу — нужно цепляться ко всем процессам, которые запускаются, сразу, т.е. до того как мы перешли на entry point.
eax>Это можно и из ring3 сделать: влезаешь описанным выше способом во все процессы и перехватываешь CreateProcessA/W
Ага, похоже это будет работать, единственно что мне не нравится в данном подходе — куча действий. Програмисты как известно делают баги, а тут любой баг приводит к неработоспособности системы. Поэтому было бы здорово найти более красивый способ (правда если писать код для ядра там еще более страшны баги...).
Спасибо за помощь!

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


M>>>Ну этот вариант тоже довольно таки ограничен, например: Windows 95/98/Me: You cannot use VirtualProtectEx on any memory region located in the shared virtual address space (from 0x80000000 through 0xBFFFFFFF).
M>>>Остается писать только в сам EXE. А если места нет между секциями или его очень мало???
eax>>а много и не надо — нужно вызвать всего 3 API функций. в 100 байт можно уложиться, если на асме писать
M>100 байт или 1000 какая разница, если места вообще ноль, то ничего не получится. Кстати, а зачем вообще искать свободное место, никто нам не мешает переписать произвольный код в процессе(конечно сделав копию где-нибудь у себя), например начиная с entry point, а потом при исполнении своего кода вернуть все обратно.
Я так пробовал — система становится нестабильной. Проще писать в самый конец ImageSize. Там, как правило, есть свободное место из-за того, что обычно ObjectAlign(выравнивание в памяти)>FileAlign (выравнивание в памяти)

> В этом случае даже ModuleFirst/ModuleNext не нужны, exe'шники всегда по одному адресу >0x400000 грузятся.
Большинство, но не все.

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

свободное место из-за того, что обычно ObjectAlign(выравнивание в памяти)>FileAlign (выравнивание в памяти)
^^^^ FileAlign (выравнивание в файле)
сорри

>Там, как правило, есть свободное место из-за того, что обычно ObjectAlign(выравнивание в памяти)>FileAlign (выравнивание в памяти)
Да. "но как правило это не всегда"


>> В этом случае даже ModuleFirst/ModuleNext не нужны, exe'шники всегда по одному адресу >0x400000 грузятся.
eax>Большинство, но не все.
Ага, соглсаен, забыл про вариант когда base address специально устанавливают другой. А попадались ли вам реальные такие exe'шники???

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

>>> В этом случае даже ModuleFirst/ModuleNext не нужны, exe'шники всегда по одному адресу >0x400000 грузятся.
eax>>Большинство, но не все.
M>Ага, соглсаен, забыл про вариант когда base address специально устанавливают другой. А попадались ли вам реальные такие exe'шники???
в дистрибутивах новых виндов практически все .exe имеют imagebase = 0x1000000