По чистой случайности я обнаружил, что иногда процесс занимает 100% одного ядра, когда я отхожу от компьютера: при использовании ЦП он ниже 1%, но когда компьютер находится в режиме IDL, то есть экран выключен и никто не трогает ПК некоторое время, этот процесс иногда начинает интенсивно использовать ЦП. Как только любой ввод пробуждает экран, процесс снова становится «нормальным».
Я создал скрипт для регистрации процесса, потребляющего много ресурсов ЦП, и обнаружил, что он kwin(cmdline = kwin-session1011dcae5a5000144224709.....)
Что-то мне подсказывает, что оконный менеджер не должен использовать 100% ЦП, когда экран выключен, поэтому я ищу любые способы взлома моего компьютера.
Мой вопрос:
- Какую процедуру необходимо выполнить, чтобы узнать, взломан ли этот процесс?
- Имеет ли это предположение смысл?
Примечание: я скопировал большую часть /proc/xxxпапки, поэтому у меня довольно много информации.
решение1
- Какую процедуру необходимо выполнить, чтобы узнать, взломан ли этот процесс?
Единственный способ увидеть, что делает отдельный процесс в работающей системе, — это отладить этот процесс или отладить всю систему (ядро). Первый способ довольно прост, и несколько инструментов позволяют сделать это в реальном времени на подозреваемом процессе. Вы можете увидеть, straceкакие системные вызовы он выполняет, и ltraceувидеть, какие функции разделяемой библиотеки он вызывает, или даже gdbв целом увидеть, какие инструкции он выполняет в данный момент. Не то чтобы для последнего вы заморозили этот процесс (в режиме по умолчанию), а также вам нужен исходный код, kwinразмещенный в правильном месте, чтобы gdb мог загрузить его и показать вам строку, на которой он остановился. В противном случае он покажет вам только машинные инструкции со специальными командами.
Для отладки ядра вам нужна специальная настройка, которая, вероятно, невозможна для ситуации уже работающей системы (если она не была подготовлена к такой настройке во время загрузки). Она позволяет вам остановить всю систему локально (kdb kgdb) или удаленно (kgdb с gdb) и проверить память, регистры и выгрузить некоторую полезную информацию, а также разобрать код. Однако для эффективной интерпретации вам нужно знать как минимум основы x86 asm.
Ядро предоставляет как минимум псевдофайл /proc/pid/mem, который не читается в обычном режиме, ноhttps://github.com/siblynx/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псевдофайл) не могут быть прочитаны при случайном запросе.