Скрыть запуск приложения

Как бы хорошо не был скрыт процесс, а ProcessNotifyRoutine все равно выдаст его запуск. Возможно ли этого избежать?

 

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

 

Не, внедриться проблем нет. Дело в самом принципе - можно ли запустить процесс так, чтоб о факте его запуска ни кто не пронюхал?...

 

это смотря как запускать. если через create_process, то _никак_, поскольку кто угодно может перехватить ее, тоже самое относится к запуску через shell. факт запуска процесса всегда остается фактом и даже чтобы куда-то внедряться, перед этим нужно запустить процесс... но! можно пойти и другим путем. достаточно просто кинуть dll в нужное место.
слабое место винды в том, что порядок поиска несистемных dll таков:
1) директория приложения
2) текущая директория
3) системная/winnt директория
4) path

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

 

Вариант с DLL интересен. Но опять не то
Меня, в частности, интересует взгляд из ядра - где, например лежит список ProcessNotifyRoutines? Можно было бы перед запуском его затерать, а потом восстанавливать. Или кто именно запускает NotifyRoutine - наверняка, можно, грубо говоря, "заnopить" нужный call...

 

Просто даже если начать ковырять ядро - я даже не знаю, собственно, в какую сторону рыть-то...

 

>> где, например лежит список ProcessNotifyRoutines

Код (Text):

1. PAGE:005552FA ; NTSTATUS __stdcall PsSetCreateProcessNotifyRoutine(PCREATE_PROCESS_NOTIFY_ROUTINE NotifyRoutine,BOOLEAN Remove)
2. PAGE:005552FA                 public PsSetCreateProcessNotifyRoutine
3. PAGE:005552FA PsSetCreateProcessNotifyRoutine proc near
4. PAGE:005552FA
5. PAGE:005552FA NotifyRoutine   = dword ptr  8
6. PAGE:005552FA Remove          = byte ptr  0Ch
7. PAGE:005552FA
8. PAGE:005552FA                 mov     edi, edi
9. PAGE:005552FC                 push    ebp
10. PAGE:005552FD                 mov     ebp, esp
11. PAGE:005552FF                 push    ebx
12. PAGE:00555300                 xor     ebx, ebx
13. PAGE:00555302                 cmp     [ebp+Remove], bl
14. PAGE:00555305                 push    esi
15. PAGE:00555306                 push    edi
16. PAGE:00555307                 jz      short loc_55536E
17. PAGE:00555309                 mov     edi, offset unk_489D60 ; его аддресс в этой переменной

 

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

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

лучше _четко_ сформулируй задачу, какие _цели_ ты преследуешь,
а вот осуществить это можно множеством способов и без модификации
ядра, которое не нужно трогать, особенно на x86-64 где патч-гуард,
который, впрочем, ломается с 99.99999% вероятностью путем добавления
нескольких байт, чтобы сохранить контрольную сумму, правда, говорят,
что в последних версиях висты там что-то поменялось в защите и я еще
не смотрел что именно... от ms можно ждать всего чего угодно ;(

 

Cr4sh
в книге:
Maybe self-improvement isn't the answer.
Maybe self-destruction is the answer.

в фильме:
Self-improvement is masturbation.
And self-destruction.

 

kaspersky
да, у меня немного вольный перевод, но смысл думаю отражает верно =)

почему, если подобная фишка нужна скажем для ядерного руткита, то перехват PspCreateProcessNotifyRoutine-обработчиков из того списка вполне приемлимый вариант...

 

Cr4sh
а) смысл отражен неверно
б) ЧП этого не писал
в) зачем ядерному руткиту создавать свой процесс?
г) проникать в ядро по любому придется _до_ его модификации
д) зачем все так усложнять?!

 

Я, просто, немного "не с того конца" задал вопрос. ИМХО, у данной методики есть не одно применение.
Одно из это, как уже заметил Cr4sh, перехват PspCreateProcessNotifyRoutine-обработчиков. А так же их "обезвреживание". Для кернелмод-руткитов самое оно - т.е. "незаметно" ставим драйвер и при следующей перезагрузке можно будет не только скрыть запускаемый процесс, но и "притарить" факт его запуска.

Гм... цели чисто дZенские, ни чего конкретного я пока не пишу.

Ну так легких путей не ищем...

 

securitylab.ru посмотри - там статья пробегала где-то в ноябре прошлого года (с тестовым драйвером который очищает этот список, обходя таким образом фаеры)

 

ECk
Спасибо. То что нужно.
http://www.securitylab.ru/analytics/254727.php

 

Twister
<Вариант с DLL интересен. Но опять не то
Меня, в частности, интересует взгляд из ядра - где, например лежит список ProcessNotifyRoutines? Можно было бы перед запуском его затерать, а потом восстанавливать. Или кто именно запускает NotifyRoutine - наверняка, можно, грубо говоря, "заnopить" нужный call...
>
Видиш ли в чём дело. Я не совсем понимаю для какой цели тебе это надо. Как-либо изменять код ядра не советую, если за тобой будут охотиться с антируткитом, поскольку бинарники могу сравнить. Благо, это применимо пока что только к коду, к данным частично.
PsRunCreateProcessNotifyRoutine находится в PspCreateProcess, если я не ошибаюсь. Тебе достаточно найти PsRunCreateProcessNotifyRoutine, найти там указатель на колбэки и просто затереть их нулями. Благо, размер массива фиксированный, так что ничего левого не затрёшь.

 

Twister

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

а там где есть потоки всегда можно найти и структуру принадлежащую процессу(EPROCESS). Задача почти тривиальная. см. EPROCESS & ETHREAD.

 

Вот, накидал небольшую программку, которая показывает список процедур уведомления и позволяет их по выбору "обезвреживать". На данный момент совместима только с ХР. Брать здесь (с исходниками): http://twister.orgfree.com/projects/
У меня есть только два вопроса.
1. В списке в ядре на самом деле хранятся не адреса процедур, а что-то другое. Чтобы понять как это "что-то" преобразовать в адрес, пришлось немного поковырять айсом ядро. Так что же все-таки там храниться?
2. Просьба к счастливым обладателям w2k и w2k3 - если не влом, подскажите адрес массива NotifyRoutines для этих осей. Ну можно и для висты, если что...

 

Хм, вообще то она у меня даже драйвер не может загрузить. А если грузиться вручную - выдает bsod, ИМХО смещения в ядре так явно забивать константами не лучший вариант.

Функция из которой ты получил этот адресок под w2k3 точно такая же, под 2000 она реализована несколько иначе. Под вистой, естественно, тоже наверняка другая реализация.

Вообще то я не понимаю зачем руткиту процесс. ИМХО это извращение и скрытие процесса представляет чисто спортивный интерес. Снос нотифи рутин вообще вызывает вопрос: когда ты их будешь сносить они уже зарегистрируют твой старт, какой толк? Если только для процессов - см. выше. Безспорно - Notify Routine must die. Но не проще ли их обмануть? Никаких патчей ядра... Подумай как реализованы алгоритмы обработки данных от этих нотифи. Как антируткит определяет, что драйвер или процесс пропали? Гы, все очень просто =)

 

<Как антируткит определяет, что драйвер или процесс пропали? Гы, все очень просто =)>

Отмониторив! как вариант.

 

Ну так и пошли ему нотификацию, что ты выгрузился.