Перехват создания сервиса

Интересует каким образом можно узнать кто "физически" создает сервис, а именно делает наподобие CreateProcess,
чтобы можно было сделать перехват создания сервиса процессом для модификации кода сервиса до старта точки входа.
Экспериментировал я на win7 с сервисом type: Share Process, при запуске сервиса апишками аля StartService,... создается физически новый процесс svchost.exe с новым pid и с сервисной дллкой, первое что пришло в голову - это посмотреть pid процесса родителя, им оказался services.exe в этот процесс установил api монитор и что только не перехватывал CreateProcessW/CreateProcessInternalW/NtCreateProcess/NtCreateProcessEx/NtCreateUserProcess/NtResumeThread - но ничего интересного это не дало, services.exe явно не принимает "физического" участия в создание этого процесса, такое ощущение что кто-то другой его полностью создает физически, а в PEB записывает родителя services.exe.
У кого какие мысли есть по поводу природы создания сервиса ? может сервисный процесс полностью создается в ядре или все-таки какой-то юзермодный процесс запускает его?

 

тоже экспериментировал, bp в r3 на NtResumeThread, NtResumeProcess ничего не дал. видимо загрузчик сервисов расположен в ядре.

 

svchost.

 

NtLoadDriver хукать пробовали?
Если не ошибаюсь, StartService сводится именно к NtLoadDriver

 

также экспериментировал с Procmon , в нем очень наглядно видно кто кого запускает и т.д. - опция Show Process and Thread Activity , но опять данный сервисный процесс там появляется из ниоткуда
StartService пляшет вокруг вызова NdrClientCall2 , которая собсно и стартует сервис

 

Могу ошибаться, но насколько я помню, вызов происходит в контексте csrss.

 

Перепутал с CoCreateInstance()

http://wasm.ru/forum/viewtopic.php?pid=327409#p327409

 

to gaeprust:
сможет ли как-то помочь мне эта писанина по твоей ссылке ? я так понимаю что ты хочешь сказать что его запускает один из процессов svchost ? но это не отобразилось в procmon, к сожаленью пытался я заинжектить дллку апи монитора в svchost.exe (ntsvcs, Plug&Play,...) и именно в этот процесс не прокатило почему-то. Моя цель - словить момент создания сервиса чтобы "пропатчить" его до начала выполнения, пока я не вижу реального решения на данный момент.

 

Только что проверил на xpsp3, при старте юзермодных сервисов вызывается services.exe->ZwCreateProcessEx.
svchost тут скорее следствие чем причина, это задается в реестре->ImagePath.
Не врубаюсь в чем у вас проблема))

Сдается мне что ваши апи мониторы просто не ставят хуки в services.exe...

 

Вопрос патчинга это уже ваша фантазия))
Можно проследить как в ZwCreateProcessEx передаются флаги и сделать саспендед->поставить APC. Можно указать свой дебаг порт и тогда вообще полный контроль =)

 

karabas_barabas
Вам onSide верно говорит. В ядерном отладчике брейк на сервис, создающий процесс. Потом смотрим текущий процесс и колстек. Да и вобще есть специальные средства диагностики, как например SystemObjectInformation, возвращающую информацию об родителе, ProcessHandleTracing возвращающая колстек на момент создания обьекта и пр. Да и процессы это юзермодные, с которыми олли чудесно справляется.

 

я даже не сомневаюсь что на XP все так просто, данный вопрос больше волнует меня для систем >= Vista , там все по-другому, монитор работает отлично т.к. перехватывал создание services.exe процесса taskhost.exe

 

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

Ну и несколько сносок:

Короче говоря, дельта SFN <= NL. Это определяет наличие Bp-фреймов в процедурах. Что это даёт. Имея NL целевой процедуры, относительно текущей, мы получим SFN необходимый для бактрейса. Так мы найдём целевой стековый фрейм и заменив в нём адрес возврата при возврате получим управление, это называется стековой маршрутизацией или Post-редиректом. Как определять SFN. Для этого нужно знать NL и проверить каждую процедуру на формирование Bp-фрейма. Обычно это излишне.
1. Описываем графом CreateProcess().
2. Определяем уровень вложенности исходной процедуры относительно целевой(всякий двиг при трассировке графа должен определять NL), так как виньапи имеют stdcall-конвенцию и колбек тоже, то SFN = f(NL). Статическим анализом мы определим необходимую дельту. Определение дельты не надёжно, так как возможно, хотя и маловероятно изменение прототипа процедур.
3. Из колбека выполняем стековю маршрутизацию. NL определён в 3, либо не известен. Если не известен, то выполняем бактрейс и проверяем вхождение(принадлежность) Ip каждого фрейма описанной в графе процедуре CreateProcess().
4. При найденном фрейме выполняем маршрутизацию - загружаем в фрейм ссылку на хэндлер. Так как прототип фиксирован, то данная манипуляция абсолютна стабильна.
5. После возврата получаем управление и делаем с процессом что угодно.
6. Так как процесс может быть создан запущенным(!CREATE_SUSPENDED, это утверждение инвалидно - остановлен главны тред), то нужно его остановить. Это можно выполнить посредством динамической маршрутизации. Кратко говоря это трейс + бактрейс. Если NL(NtCreateProcessEx) <= BreakIp, то выполняем трейс, иначе бактрейс).
7. Так как морфер не все писали, то нужно решение попроще. Релоцируем модуль и патчим его. Оригинальная проекция не изменна. Модифицируем стаб. Это переключение треда на отморфленный код. Так как код не изменяется, а меняется база, то свич примитивен: Ip' = Ip + Delta.
8. Все пункты выше требует повышение NL. Для этого необходимо получить останов гдето внутри целевой апи. Можно использовать Ldr-колбеки. Автор использовал апи RtlAllocateHeap(), внутри которой получаем останов(способов стопяцот, поиск по васму).
9. Профит. Абсолютный недетект перехватчика.

Вопросы ?

 

Кстате я выше написал про извлечение аргументов из стека, но забыл упомянуть часто задаваемый вопрос про NtCreateProcess. Как определить имя экзе из которого создаётся процесс. Извлекаем из стека хэндл секции(Section Handle), проецируем её и извлекаем имя посредством NtQueryVirtualMemory(MemoryMappedFilenameInformation, MapBase). NtQuerySection не возвратит имя экзе.

 

"привад тру хек мана" всплывают кусками, но разве кто сомневался, и причиной этому не интерес, оно ведь всегда всплывает

 

Ну не знаю ... мне, например, ответ понравился.
А это выдержки откуда?
Полный источник можно? Чтобы с содержанием,
постановкой задачи, решением и заключительной благодарностью. )))

 

Какие-то все пассивные)) Вспомнил про этот топик, решил глянуть на виртуалке. Правда там семерка, а не виста.
Неужели вам тяжело просто похукать ф-ции создания процесса и посмотреть что вызывается? SCM находится в services.exe это же написано у Руссиновича, что в 4 что в 5 издании.

Вобщем вызывается ZwCreateUserProcess =) А taskhost тут никаким боком, так же как и svchost, я же писал что это задается в реестре.

 

спс за интересный и подробный пост, но проблемы в технике установки перехвата абсолютно нет.

специально накидал тестовую прогу, которая будет останавливать сервис и снова его запускать http://www.sendspace.com/file/1dk4fh
пробовал перехватывать апи-монитором и olly в процессе services.exe на 2 компах - результат 0 , брейки на CreateProcessW/CreateProcessInternalW/NtCreateProcess/NtCreateProcessEx/NtCreateUserProcess/NtResumeThread/NtWriteVirtualMemory
не срабатывают, система WIN7+SP1+UAC

 

Юзайте кернел отладчик, либо напишите свой инжект в services.exe и хуки заодно. Вызывается CreateProcessW.
http://s44.radikal.ru/i106/1105/da/dd67cfd3160e.jpg
скрин

 

karabas_barabas
Поправочка - с патчем кода проблем наверно нет. И со снятием его тоже нет никаких проблем. И с обнаружением. А значит не приемлимо