Запретить завершение процесса

[M.A.R.K]

Всем привет.

Пишу программу, нужно сделать так, чтобы процесс нельзя было завершать...
Бывает, завершаешь какой-нибудь процесс в Win. Task Manager, а он не "стреляется"... (так же хочу)
Я пробовал добавлять в свой процесс, ACE с маской доступа PROCESS_ALL_ACCESS, исключающую PROCESS_TERMINATE.
Но результатов это не дало...

Подскажите, как это можно сделать (желательно без перехвата API)...

Заранее благодарен.

[alibek]

А тестировал из под пользователя или из под админа?

[M.A.R.K]

alibek, конечно

[alibek]

Ну тогда да.

[M.A.R.K]

alibek
Так способ с ACE не подходит?

[nekeda]

я думал такое только в анекдотах бывает

[ALX_2002]

1) Сотни раз уже обсуждалась эта изъеденная молью тема. )



2) Отличный диалог ))

xxx: Тестил из под юзера или из под админа ?
yyy: Конечно !!!
xxx: Ааа... Ну тогда ДААА !!!

[M.A.R.K]

Спрашиваю еще раз...
Данную задачу можно реализовать путем правки ACE и т.д. ?

[Денис]

ALX_2002

xxx: Тестил из под юзера или из под админа ?
yyy: Конечно !!!
xxx: Ааа... Ну тогда ДААА !!!

На башорг ушло?

[ALX_2002]

Спрашиваю еще раз...
Данную задачу можно реализовать путем правки ACE и т.д. ?

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

Инфа

ALX_2002

xxx: Тестил из под юзера или из под админа ?
yyy: Конечно !!!
xxx: Ааа... Ну тогда ДААА !!!

На башорг ушло?

Башорг уже переполнен )

[ANDLL]

ALX_2002, ты не в теме.
Автору - может быть вечером(не известно правда каким) посмотрю. По идее должно быть можно(а почему нет?)

[ANDLL]

Вобщем, судя по тестам, администратор может завершить любой процесс, несмотря на его ACL

[M.A.R.K]

ANDLL
Большое спасибо.
1. Выходит нужен перехват ZwTerminateProcess (Для админской учетки)
2. ACL подходит для пользовательских учеток? (Для гостевой учетки)

[ANDLL]

2. ACL подходит для пользовательских учеток? (Для гостевой учетки)

Гость кажеться вообще не может редактировать ACL своих процессов.

[Twister]

Подскажите, как это можно сделать (желательно без перехвата API)...

Без перехвата стопроцентный способ только один - разубедить систему в том, что это процесс.

Теперь на пальцах:

Есть в ядре такая табличка, называется PspCidTable. Она хранит в себе списки потоков и
процессов и именно по этой таблице ориентируются такие функции, как OpenProcess/Thread.
Организована она как HANDLE_TABLE (здесь описывать структуру не буду - читайте
ms-rem'a на васме).

Так вот: если пробежаться по этой табличке и удалить (а точнее занулить) все записи,
связанные с нашим процессом (т.е. потоки включительно), то процесс уже не убить ни как -
сама система не сможет этого сделать. Правда есть один недостаток - такой процесс уже не
сможет порождать другие потоки (а, следовательно, и процессы!). На счет окон не помню -
кажись все нормально.

Хотел было нарыть готовый код (писал драйверок на асме), но что-то на работе его нет.
Вечером дома посмотрю, если кому интересно.


Касаемо остальных методов сделать процесс неубиваемым:

1. Хуки.
В юзермоде от них толку нет. В ядре побольше, но тоже мало - можно подгрузить ядро с диска и
вызвать нехученную ZwTerminateProcess.

2. Deadlock.
При использовании хэндла именованого канала, работающего в блокируещем режиме, возникает
дидлок и поток на всегда замерает. Толку от этого метода нет, так как нет проку от неработающего потока.

3. IRP
Если послать драйверу IRP, но не вернуть его (бесконечный цикл в драйвере), то вызывающий поток (и, следовательно. процесс) тоже станет неубиваемым. От такого потока тож нет толку +
на одноядерной машине загрузка камня процессом System стремится к 100%.

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

5. Права.
Ну тут все понятно - если сидеть под администратором (как делает большинство) и получить SeDebugPrivilege, то можно убить даже критические системные процессы.

6. Подмена PID
Можно сменить PID своего процесса на 4 - тогда из юзермода его уже не убить. Зато некоторые проги начинают реально глючить - виндовый TaskMan, PETools и другие начинают находить много разных и интересных процессов в системе.

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

[alibek]

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

[Twister]

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

Ну, во первых, не сечас, а давно - так еще InterBase, кажись, работал.

Не вижу ни чего сложного: Замораживаем первый. Убиваем второй. Убиваем первый. Все с помощью ProcessExplorer.

[alibek]

Замораживаем первый, и второй его размораживает.
Убиваем второй, и его респаунит первый.

[Twister]

Ну знач надо заморозить сразу два, причем попоточно. Опять же - в юзермоде сложно будет заморозить сразу все потоки в обоих приложениях, так что есть шанс "не успеть". А в ядре - без проблем. Чуть задираем IRQL, чтоб нас ни кто не прервал, и работаем себе на здоровье.

Вообщем, это получается борьба с ветряными мельницами - убить можно все. Тем более, я еще не описывал способы завершения процессов. А их довала: документированные, недокументированные и основаные на глюках самого приложения.

[alibek]

Так это я и имел ввиду под "вручную сложно".

[Twister]

Вот те сорцы, о которых я говорил, если кому надо...