【问题标题】:How to protect threads (of my process) from termination [closed]如何保护线程(我的进程)免于终止[关闭]
【发布时间】:2018-06-01 07:01:56
【问题描述】:

我编写了一个 Windows 服务来完成一项关键工作。 我的程序有 5 个线程执行一项关键工作,我不希望它们被终止。

我使用进程黑客,在线程选项卡中,我可以终止 5 个线程中的任何一个,而不会导致整个程序终止(因为程序只是容器) 当用户或黑客(我的程序是一个安全程序,用户可能想让它不起作用)终止一个线程(如果线程被挂起但没有策略阻止或修复终止,我会恢复线程)时,关键工作没有完成线程数)

如何保护这 5 个线程不被终止?
(我已经让程序本身很关键,但是当线程可以轻松终止时它确实没有价值)

【问题讨论】:

  • 就像 Eric Lippert 说的:stackoverflow.com/questions/16968581/…
  • 与其给你的用户安全权限去做你不希望他们做的事情,然后编写一个以同等权限运行的程序来试图阻止他们,你应该实际上授予用户执行您不希望他们能够执行的操作的权限。安全系统的存在是有原因的,使用它。
  • 我不会杀死线程。我会先暂停它,然后冻结它。你的关键工作不会完成。
  • @emaditaj 这是一个不可能的问题。根据定义不可能。无论你试图做什么,它总是会被打败的。您需要为您的问题使用合适的解决方案,一个实际上能够解决问题的解决方案,即实际上不授予用户安全权限来执行您不希望他们能够做的事情。
  • 你真的搞错了。特权用户可以进行特权行为。别担心。让安全系统发挥作用。

标签: c# multithreading security winapi


【解决方案1】:

我找到了解决问题的方法。

首先让我解释一下我是如何做到这一点的:

我创建了 2 个看门狗线程,第一个 重新创建 5 个线程和 WatchDogThread2 在终止时,第二个对 看门狗 1这让我花了很长时间,因为 Thread.IsAlive 总是返回 true,即使线程被终止最终使用 Thread.Join() 并且 join 正在工作)。

当一个看门狗线程在终止之后运行时,它正在重新创建丢失的线程。但在 10-30 秒后,exception 在与看门狗无关的部分被抛出。

我重试了很多次,也做了一些调试。
经过 30-50 次尝试和编辑后,我发现这个异常被抛出在代码的随机部分中,而不仅仅是特定部分

于是我开始研究异常

ExecutionEngineException

我发现当代码中的某些内容出错时,CRL 会抛出此错误。 首先,我认为这个问题是由 watchdogs 之一引起的,所以我更改了几次,但 error 仍然存在(只是时间到了被抛出改变了一点)。
所以我完全删除它们并启动程序并终止一个 5 线程。
这次什么都没有发生

我又做了几次修改,发现不使用看门狗时也会发生此异常。 异常发生在看门狗 2-3 分钟而不是 10-30 秒之后

我再次进行了研究,微软在 MSDN 上写道,如果完成了 垃圾收集,有时会发生这种情况。我禁用垃圾排序并不再收到异常。

我写了另一个线程,强制 Garbage 每 0.5 秒 进行一次整理,并在线程终止后看到程序收到 ExecutionEngineException 并崩溃。

这是垃圾排序的解决方案,因此整个过程崩溃并重新启动/BSOD 发生。


最终解决方案

如果线程终止并触发垃圾回收,则 CRL 抛出 ExecutionEngineException
只需每 0.5 秒进行一次手动垃圾排序,这样程序就会崩溃并重新启动。

代码:

Thread t1 = new Thread(delegate () {  
    while (true) { 
        System.GC.Collect(); 
        Thread.Sleep(500); 
    } 
}); 

t1.Start();

您可以启动其中两个线程以获得更高的安全性(如果用户终止 t1,垃圾收集将在 0-10 分钟后触发,在此期间他会做任何您想做的事情)。

【讨论】:

  • 500 毫秒是攻击者在有机会启动其哨兵之前终止您的看门狗线程的 加载 时间。特别是,因为您(过度依赖)异常。任何调试器都可以设置为在引发异常时中断。这不是解决方案。顺便说一句,我不知道 "CRL" 是什么。
  • crl=Common Language Runtime .net 代码首先被转换为 crl足够和自动编写的工具来特别终止我的软件,但我不考虑使用进程黑客之类的工具防止手动攻击,为此编写工具的攻击者可以绕过我认为不是我的目标的任何保护
  • 公共语言运行时缩写为 CLR,而不是 CRL。我会评论您的其余评论,但由于完全缺乏标点符号,我无法理解其中的任何内容。
猜你喜欢
  • 2012-01-29
  • 2010-12-09
  • 1970-01-01
  • 2020-09-19
  • 2012-06-28
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-09-05
相关资源
最近更新 更多