纯粹是偶然，我发现当我离开计算机时，有时某个进程占用了一个核心的 100%：当使用 CPU 时，它低于 1%，但是当计算机处于 IDL（即屏幕关闭且有一段时间没有人接触电脑，这个过程有时会开始大量使用 CPU。一旦任何输入唤醒屏幕，该过程就会再次变得“正常”。
我创建了一个脚本来记录哪个进程占用大量CPU，我发现它是kwin（cmdline = kwin-session1011dcae5a5000144224709.....）
有人告诉我，当屏幕关闭时，窗口管理器不应该使用 100% CPU，所以我正在寻找对我的计算机的任何破解/黑客攻击。
我的问题是：
- 要知道该进程是否被破解/黑客入侵，需要遵循什么程序？
- 这个假设有道理吗？
注意：我复制了大部分/proc/xxx文件夹，因此我有相当多的信息。
答案1
- 要知道该进程是否被破解/黑客入侵，需要遵循什么程序？
查看单个进程在当前运行的系统中执行的操作的唯一方法是调试该进程，或调试整个系统（内核）。第一个相当简单，有几个工具可以让您在可疑的进程上实时执行此操作。您可以strace它执行哪些系统调用，并ltrace查看它调用哪些共享库函数，甚至可以gdb作为一个整体来查看它当前执行的指令。并不是说对于后者，您将冻结该进程（在默认模式下），并且您需要kwin放置在正确位置的源代码，以便 gdb 能够加载它并向您显示它停止的行。否则它只会显示带有特殊命令的机器指令。
要调试内核，您需要一个特殊的设置，这对于已经运行的系统的情况来说可能是不可能的（如果在启动时没有准备好进行此类设置）。它允许您本地（kgdb 的 kdb）或远程（kgdb 和 gdb）停止整个系统，并检查内存、寄存器、转储一些有用的信息以及反汇编代码。然而，要有效地解释它，您至少需要了解 x86 asm 的基础知识。
内核至少提供了一个伪文件/proc/pid/mem，它在正常模式下不可读，但是https://github.com/siblenx/lynxware/blob/master/dumpmem.c是一个包装器，它根据 /proc/pid/maps 中提供的映射读取这个稀疏文件。然后您可以使用反汇编程序检查转储的文件。如果你不关心进程状态，你可以使用 强制它转储核心kill -SEGV pid，但是如果在启动时不允许转储核心文件 ( ulimit -c size)，它不会转储核心，但仍然会死掉，丢失任何信息你想要得到。
还有更多针对同一任务的特殊取证工具，但它们通常针对经验丰富的人员。
- 这个假设有道理吗？
我不这么认为。我有点担心我的 fvwm 是否开始表现得像那样，甚至 twm （如果我习惯了），但至于 kwin （以及一般的 KDE），我希望它有这种行为，因为今天的 KDE 非常庞大，一项活动对于它来说是“正常的”。
例如，如果 fvwm 出现这种行为，我首先检查该进程的 /proc/pid/exe 指向正确的二进制文件，然后使用 检查该二进制文件的创建时间stat -c %z /path/to/binary，然后跟踪它是否合法或冲到我的始终准备好 kdb，如果没有，则会冻结系统。大多数“浪费”的活动是程序错误或软件膨胀。
- 注意：我复制了大部分
/proc/xxx文件夹，因此我有相当多的信息。
这是没有意义的，因为 /proc 文件是纯粹虚拟的，其中一些重要的文件（如mem伪文件）在以随意的方式请求时是不可读的。