Por pura casualidad, descubrí que un proceso ocupa el 100% de un núcleo a veces cuando estoy lejos de mi computadora: cuando uso la CPU, está por debajo del 1%, pero cuando la computadora está en IDL, lo que significa que la pantalla está apagada y nadie toca la PC por un tiempo, este proceso algunas veces comienza a hacer un uso intensivo de la CPU. Tan pronto como cualquier entrada active la pantalla, el proceso volverá a ser "normal".
Creé un script para registrar qué proceso consume mucha CPU y descubrí que es kwin(cmdline = kwin-session1011dcae5a5000144224709.....)
Algo me dice que un administrador de ventanas no debería usar el 100% de la CPU cuando la pantalla está apagada, así que estoy buscando cualquier crack/pirateo en mi computadora.
Mi pregunta es:
- ¿Cuál es el procedimiento a seguir para saber si este proceso está crackeado/hackeado?
- ¿Tiene sentido esta suposición?
Nota: Copié principalmente la /proc/xxxcarpeta, así que tengo bastante información.
Respuesta1
- ¿Cuál es el procedimiento a seguir para saber si este proceso está crackeado/hackeado?
La única forma de ver qué hace un solo proceso en un sistema actualmente en ejecución es depurar ese proceso o depurar todo el sistema (kernel). La primera es bastante fácil y varias herramientas le permiten hacerlo en vivo en el proceso sospechoso. Puede saber stracequé llamadas al sistema realiza y ltracever qué funciones de biblioteca compartida llama, o incluso gdben su conjunto para ver qué instrucciones ejecuta actualmente. No es que para este último congelará ese proceso (en modo predeterminado) y necesitará un código fuente colocado kwinen el lugar correcto para que gdb pueda cargarlo y mostrarle una línea donde se detuvo. De lo contrario, sólo le mostrará instrucciones de la máquina con comandos especiales.
Para depurar el kernel necesita una configuración especial que probablemente no sea posible en una situación en la que el sistema ya se está ejecutando (si no estaba preparado para dicha configuración en el momento del arranque). Le permite detener todo el sistema, localmente (kdb de kgdb) o remotamente (kgdb con gdb) e inspeccionar la memoria, los registros y volcar información útil, además de desensamblar el código. Sin embargo, para interpretarlo eficazmente es necesario conocer al menos los conceptos básicos de x86 asm.
El kernel proporciona al menos un pseudoarchivo /proc/pid/mem que es ilegible en modo normal, perohttps://github.com/sablynx/lynxware/blob/master/dumpmem.ces un contenedor que lee este archivo disperso basándose en las asignaciones proporcionadas en /proc/pid/maps. Luego puedes inspeccionar el archivo volcado con el desensamblador. Si no le importa el estado del proceso, puede forzarlo a volcar el núcleo con kill -SEGV pid, pero si en el momento del lanzamiento no se le permitió volcar los archivos principales ( ulimit -c size), no volcará el núcleo pero aún así morirá, perdiendo toda la información. quieres conseguir.
También existen herramientas forenses más especiales destinadas a la misma tarea, pero normalmente están dirigidas a personas con experiencia.
- ¿Tiene sentido esta suposición?
No me parece. Me preocupaba un poco si mi fvwm comenzara a comportarse así, o incluso twm (si estuviera acostumbrado), pero en cuanto a kwin (y KDE en general) espero ese comportamiento porque el KDE actual es enorme y tal. una actividad es "normal" para ella.
Si se tratara de ese comportamiento con fvwm, por ejemplo, primero verifiqué que el proceso /proc/pid/exe apunta al binario correcto, luego verifiqué el tiempo de creación de ese binario con stat -c %z /path/to/binary, luego lo seleccioné si era legítimo o lo apresuré a mi siempre listo kdb si no, congelando el sistema. La mayor parte de la actividad "desperdiciada" son errores de programa o exceso de software.
- Nota: Copié principalmente la
/proc/xxxcarpeta, así que tengo bastante información.
Esto no tiene sentido porque los archivos /proc son puramente virtuales y algunos de ellos importantes (como el mempseudoarchivo) son ilegibles cuando se solicitan de manera casual.