防止C＃app被进程杀死

Question

如何保护我的C＃应用​​程序免受通过taskman或以编程方式终止其进程的人的侵害？

以下是我的情景：

App A是由另一个团队开发的MFC应用程序。它有一个未发布的基于文本的远程接口，可通过后门启用。

我正在开发应用程序B，一个与A交互的C＃WinForms应用程序。当需要远程访问时，A启用A后门，在完成时（或失败时）关闭它。

我正在探索用户可以滥用B以获取A隐藏功能的方式，例如在启用A的远程接口后杀死B的进程。当发生这种情况时，我想最后有机会让B关闭A的后门。

B使用localhost与A进行交互，所以我并不担心掉电情况。

我正在寻找一种不涉及改变A的解决方案。

我不希望能够阻止Dark Tangent（虽然这会是一个奖励），但是现在一个脚本小子可以用这种设计：）

这些应用程序在Windows XP上运行，但很快也会支持Vista＆amp; 7。

提前致谢， 吉姆

Answer 1

  

我愿意在尝试时关闭应用，但需要先做一些事情。

在程序关闭时执行必要的步骤会导致程序容易破坏。即使您可以阻止某人通过任务管理器杀死您的程序，您也无法阻止他们关闭计算机，甚至无法将电缆拉出墙壁。无论完成任何如此重要的任务都将失去。如果停电怎么办？同样，您的任务将无法完成，您的重要清理代码将无法运行。

相反，你应该让你的程序在任何时候对失败都很有用。使用事务，并始终以原子方式将状态保存到文件中 - 确保始终至少有一个有效的数据副本。不要以暂时无效的方式覆盖重要文件。

最后，您可以在程序中添加一个对话框，当它们尝试关闭它时，会警告它们程序需要正常关闭。如果你快速关机，用户将不想杀死它并让它正常终止。如果你的关机需要很长时间，那么人们会试图杀死它。如果你对用户很好，他们也会对你很好。

如果快速关闭意味着用户将丢失一些未完成的工作，然后警告他们并给他们机会等待任务完成，但如果他们真的想退出你的程序然后让他们退出。

Answer 2

你真的，真的，真的不想这样做。它让用户非常生气！但是，如果它应该是服务，则将其作为服务帐户运行，并且不向用户授予管理员权限。

Answer 3

您不能 - 只要用户有权在您的程序上调用TerminateProcess，就无法阻止End Process在任务管理器中立即终止您。 Raymond Chen不久前发布了这个帖子：http://blogs.msdn.com/b/oldnewthing/archive/2004/02/16/73780.aspx

Answer 4

简短回答：你不能，也不应该。

答案很长：您可以尝试启动第二个“帮助程序”过程，如果您的应用程序仍在运行，则每隔x秒检查一次。如果不是，则重新启动它。

如果您希望进程运行很长时间，请不要信任用户使其保持运行，请考虑使用Windows服务。它们是为此而设计的。

Answer 5

我认为每个人都错过了这一点。如果我正确阅读（在你编辑之后），你想知道什么时候你被“杀死”，这样你可以优雅地关闭？

“杀戮”的意思是你“不能”阻止它。当然有一些解决方法，例如使用第二个应用程序来恢复已杀死的应用程序，但这与仅仅能够正常关闭无关。

最好的方法是作为服务运行（因此您不能被杀死，只是被要求关闭），或者重新调整应用程序的工作方式，以便它不需要“整理”之前它退出了。当一个应用程序退出时，它所拥有的大多数资源都会被自动清理，因此只有您自己的数据才能完全关闭。您可以尝试的方法是：

• 经常将您的状态提交到磁盘，以便在您意外退出时不会损失太多（或任何东西）。 （请记住刷新所有I / O流以确保它们已提交到磁盘）
• 将信息保存到磁盘，允许您在下次程序运行时检测到意外关闭，以便能够检测并纠正因杀死而导致的任何问题。
• 告诉您的用户不要成为白痴，并妥善退出您的应用程序。如果他们不理你，就把他们捅在眼里。通常在不超过两次之后他们会听： - ）

Answer 6

为了防止您的应用程序被终止，您将应用程序作为其他用户（即作为服务或另一个用户）运行用户帐户），并将用户限制为标准用户。

这样，没有任何恶意用户可以杀死您的进程，因为只有管理员可以杀死它，这显然是您不信任任何人的权限。

它具有遵循操作系统的预期设计的优点。

Answer 7

@Jim

如果App A可以收到修改请求

1. 优选地，我会建立一个架构，其中所有应用程序B都是在打开后门时注册的，并且需要在一定时间间隔内对应用A进行注册，以便应用A可以在应用B未通知它时关闭它自己的后门它仍然需要访问。这仍然不是完全安全的，但App A不应该采用这种界面，而不需要对“安全”通信方式进行某种自我调节。

2. 或者，您可以建议修改App A以检查有效进程，如果在后门打开时找不到任何进程，则它将被关闭（这是可欺骗的，因为它按处理名称进行）。

否则，听起来App B应该在不需要立即访问时尽可能频繁地关闭后门。

要求应用B提供对App A的访问安全性确实是一个糟糕的模型。

Answer 8

据我所知，你不能，即使你真的不应该。想象一下如果你不能强制杀死一个应用程序会有多烦人。

如果您的应用程序继续运行很重要，您可以随时创建一个“ping”应用程序以确保它正在运行的Windows服务（您可以使用命名管道，套接字，pid文件......等等）。如果服务检测到进程已经死亡，那么它可以重新启动它。这可能是你最好的选择。

Answer 9

当应用程序第一次启动时，您可能无法执行在后台运行的第3个ap /进程并尝试每次都回调到App B，因此当App B关闭时... App C可以看到并执行一个程序来关闭App A的后门。

因此，当App B通过预期的关闭按钮成功关闭时，它将禁用App C检查App B仍然正常工作...

我现在不是最好的C＃，但看着你的问题，这可能是我试图做的一种方式..

此外，如果App B检查App C，那么如果App C已经关闭，App B将关闭后门，如果可以的话。

正如其他人所说，这可能不是一个好主意。