Скрытие процесса в TaskMgr.

Здрасте.
Необходимо скрыть процесс в диспетчере задач. Условия:
o Ринг 3. Можем исполнять код в контексте целевого процесса, соответственно доступна вся его память, контекст потоков, можем ставить векторные обработчики исключений и пр.
o Секции кода изменять нельзя, ибо палится детекторами типо рку, гмера и пр.
o Для примера возьмём XP.

 

ладно уж, рассказывай чего изобрел

 

RET
Помогите решить задачу.

 

я, ещё в институте когда учился, делал так: внедрял длл, сплайсил функцию zwquerysysteminformation... можно сделать повыше, допустим периодически проверять и убирать из списка (что на окне) нужные процессы, ну или там попробовать к оконным сообщениям списка прицепиться... это вроде просто, но ты же не любишь, чтобы просто)))

 

Rel
Код нельзя менять, шадов не используем. Как есчо ?

 

ээээ.......только код?,тогда можно дерьмо метод - замена в таблице импорта,ЛоадЛибрари и ГетПрокАдрес,какбы дополнительно обрабатываются,но это через жопу....

 

1nsidE
Кодосекции менять нельзя, говорю же. Секции данных и остальную память менять можно вобщем.

 

Просто идея: Поставить аппаратный брейкпойнт на возврат из NtQuery.. , векторным хэндлером SleepEx -- т.к. второй параметр, который ему передадут -- адрес возврата в ntdll, то он будет alertable и из скрываемого процесса можно ставить всем потокам apc в очередь. Ему мы уже можем передать параметр, поставим в apc -- SendMessage а параметр ему -- хэндл окна которое мы создадим в скрываемом процессе. Теперь, т.к. sendmessage -- блокирующий вызов то когда мы получим его в наш процесс -- таск мэнеджер будет ожидать возврата нами значения, мы в этот время анализируем в нем стек, на ложные апц-срабатывания, корректируем его, т.к. там с параметрами мы не подходящие функции выбирали и правим данные, которые нам надо =) Может я чего-то не учел?

 

Velheart
В таком случае апк не нужно затрагивать, вех вызывается в контексте потока, в котором исключение возникло. Можно извлечь из стека ссылку на слепок, изменить его и отпустить тред. Но этот способ не хотелось бы юзать.

 

Да, но мы же не можем хэндлеру передать произвольный параметр. Т.е. нам тогда нужно внедрить свой код в таск менеджер и сделать его вех-хэндлером.. Или разрешено выделять память для выполнения в ап таск менеджера, а нельзя только менять уже загруженные кодовые секции?

 

Velheart

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

 

Посмотри в строну RtlQueryProcessDebugInformation на первый взгляд там вызывается много разных коллбеков возможно получится законтролить в секции данных а там уже найти в стеке возврат из CreateToolHelp32snapshot и подменить адрес.

 

blast
Эта функа не юзается, непосредственно вызывается сервис для получения слепка.

 

RtlQueryProcessDebugInformation - сводится к созданию удаленного потока с последующим получением содержимого PEB. CreateToolHelp32snapshot - это вообще прикладная надстройка.

 

..а внедряемая и собирающая инфу уже готовая RtlpQueryProcessDebugInformationRemote

 

а зачем скрывать процесс, если можно создать потоки в уже существующих процессах?

 

GoldFinch
Это не важно, нужно скрыть уже запущенный процесс.

 

Clerk

Какой именно "этот"? VEH или hardware breakpoint? Если второе, то исключение можно и по-другому генерировать... например, ограничить лимит сегмента ds, чтобы KUSER_SHARED_DATA.SystemCall туда не попадал.

 

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

 

Clerk
Так дело только в локальности для потока? Тогда можно наложить, например, PAGE_GUARD на страницу с вызовом. В обработчике, разумеется, проверять какая функция была вызвана.