Предотвращение приложения C# из процесса kill

Question

Как защитить свое приложение C# от кого-то, убивающего его процесс через taskman или программно?

Вот мой сценарий:

App А представляет собой приложение MFC, разработанный другой командой. Он имеет неопубликованный текстовый удаленный интерфейс, который включен через бэкдор.

Я разрабатываю приложение B, приложение C# WinForms, которое взаимодействует с A. B, обеспечивает бэкдор A, когда ему нужен удаленный доступ, закрывает его по завершении (или при сбое).

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

B использует localhost для взаимодействия с A, поэтому меня не беспокоит сценарий отключения питания.

Я ищу решение, которое не включает в себя изменение A.

Я не ожидал, чтобы быть в состоянии остановить Темную Tangent (хотя это будет бонус), но прямо сейчас деточка сценария может иметь свой путь с этим проектом :)

Эти приложения работают на Windows XP, но и в ближайшее время поддержка Vista, 7. &

заранее спасибо, Jim

Answer 1

Вы не можете - до тех пор, пока пользователь имеет право называть TerminateProcess в вашей программе, вы не можете предотвратить завершение процесса End Process в диспетчере задач. Raymond Chen опубликовал на этом некоторое время назад: http://blogs.msdn.com/b/oldnewthing/archive/2004/02/16/73780.aspx

Answer 2

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

Answer 3

Короткий ответ: вы не можете и не должны.

Длинный ответ: вы можете попробовать запустить второй «вспомогательный» процесс, который проверяет каждые x секунд, если ваше приложение все еще работает. Если это не так, он перезапускает его.

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

Answer 4

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

Если важно, чтобы ваше приложение продолжало работать, вы всегда можете создать службу Windows, которая «проверяет» приложение для обеспечения его работы (вы можете использовать именованные каналы, сокеты, файлы pid ... независимо). если служба обнаруживает, что процесс умер, тогда он может просто перезапустить его. это, вероятно, ваш лучший выбор.

Answer 5

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

Необходимые шаги при выключениях программы приводят к легкому прорыву программ. Даже если вы можете помешать кому-то убить вашу программу через диспетчер задач, вы не можете остановить их от выключения компьютера или даже вытащить кабель из стены. Любая задача, которая так жизненно важна для завершения, будет потеряна. А что, если есть власть? Снова ваша задача не будет завершена, и ваш жизненный код очистки не будет запущен.

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

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

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

Answer 6

Я думаю, что все пропустили точку. Если я правильно прочитал (после вашего редактирования), вы хотите узнать, когда вас «убили», чтобы вы могли изящно закрыть его?

Пункт «убийство» заключается в том, что вы «не можете» его остановить. Конечно, обходные пути, например, использование второго приложения для оживления убитого приложения, но это не имеет никакого отношения к простому изложению изящно.

Лучшим подходом является либо запуск службы (чтобы вы не могли быть убиты, просто попросили закрыть), либо реструктурировать работу вашего приложения, чтобы не было необходимости «убирать», прежде чем он уйдет. Когда приложение закрывается, большинство ресурсов, которые оно хранит, автоматически очищается, так что это только ваши собственные данные, которые вы должны закрыть. Подходы, которые вы можете попробовать, следующие:

• Часто фиксируйте свое состояние на диск, чтобы не потерять много (или что-либо), если вы неожиданно уходите. (Не забудьте очистить все потоки ввода-вывода, чтобы убедиться, что они привязаны к диску)
• Сохраните информацию на диске, которая позволяет вам обнаружить неожиданное завершение работы при следующей запуске вашей программы, чтобы она могла обнаруживать и исправлять любые проблемы возможно, были вызваны убийством.
• Сообщите своим пользователям, чтобы они не были идиотами, и прекратите свое приложение. Тыкаешь их в глаза, если они игнорируют тебя. Обычно после не более двух раз они слушают :-)

Answer 7

Когда приложение инициируется в первый раз, вы не можете выполнить третий ap/процесс, который работает в фоновом режиме, и пытается обратный вызов в приложение B каждый раз ofter, поэтому, когда приложение B закрыто. App C может видеть это и выполняет процедуру закрытия бэкдора App A.

Так что, когда приложение B успешно закрывается через предполагаемую кнопку Закрыть это отключит App C от проверки App B все еще работает отлично ...

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

Также, если приложение B проверяет приложение C, а затем, если приложение C исчезло, приложение B закроет бэкдор, если это возможно.

Как говорят другие, это не может быть хорошей идеей.

Answer 8

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

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

Имеет то преимущество, что он соответствует предполагаемому дизайну операционной системы.

Answer 9

@Jim

Если приложение А может получать модификации запросов

1. Предпочтительно, я бы архитектуры, где зарегистрированы все приложения Б при открытии лазейки и необходимы для пинга App A с регистрацией с интервалом, так что приложение А может закрыть собственный бэкдор, если приложение Б не сообщит ему, что ему все еще нужен доступ. Это все еще не совсем безопасно, но приложение А не должно быть структурировано с таким интерфейсом без какого-либо саморегулирования для «надежных» средств связи.

2. Или вы можете предложить App A изменить, чтобы проверить действительные процессы, и если ни один из них не найден, пока он открыт, он закрывается (это подделывается, поскольку оно обрабатывается именем).

В противном случае, похоже, что приложение B должно закрывать бэкдор как можно чаще, когда ему не нужен немедленный доступ.

Требование к приложению B обеспечить безопасность доступа к приложению A действительно плохой модели.