Por pura casualidade, descobri que um processo está ocupando 100% de um núcleo às vezes quando estou longe do computador: Ao usar a CPU, fica abaixo de 1%, mas quando o computador está IDL, ou seja, a tela está desligada e ninguém toca no PC por um tempo, esse processo às vezes começa a fazer uso intensivo da CPU. Assim que qualquer entrada ativar a tela, o processo voltará ao “normal”.
Criei um script para registrar qual processo consome muita CPU e descobri que é kwin(cmdline = kwin-session1011dcae5a5000144224709.....)
Algo me diz que um gerenciador de janelas não deve usar 100% da CPU quando a tela está desligada, então estou procurando por algum crack/hack no meu computador.
Minha pergunta é:
- Qual é o procedimento a seguir para saber se este processo foi crackeado/hackeado?
- Essa suposição faz sentido?
Nota: copiei principalmente a /proc/xxxpasta, por isso tenho algumas informações.
Responder1
- Qual é o procedimento a seguir para saber se este processo foi crackeado/hackeado?
A única maneira de ver o que um único processo faz em um sistema atualmente em execução é depurar esse processo ou depurar todo o sistema (kernel). O primeiro é bastante fácil e várias ferramentas permitem que você faça isso ao vivo no processo suspeito. Você pode saber stracequais syscalls ele executa e ltracever quais funções de biblioteca compartilhada ele chama, ou mesmo gdbcomo um todo para ver quais instruções ele executa atualmente. Não que por último você irá congelar esse processo (no modo padrão), assim como você precisa de um código-fonte kwincolocado no lugar certo para que o gdb possa carregá-lo e mostrar uma linha onde ele parou. Caso contrário, ele mostrará apenas instruções de máquina com comandos especiais.
Para depurar o kernel você precisa de uma configuração especial que provavelmente não é possível para uma situação de sistema já em execução (se ele não estiver preparado para tal configuração no momento da inicialização). Ele permite que você pare todo o sistema, localmente (kgdb's kdb) ou remotamente (kgdb com gdb) e inspecione a memória, os registros e despeje algumas informações úteis, além de desmontar o código. No entanto, para interpretá-lo de forma eficaz, você precisa conhecer pelo menos o básico do x86 asm.
O kernel fornece pelo menos um pseudoarquivo /proc/pid/mem que é ilegível no modo normal, mashttps://github.com/sablynx/lynxware/blob/master/dumpmem.cé um wrapper que lê esse arquivo esparso com base nos mapeamentos fornecidos em /proc/pid/maps. Você pode então inspecionar o arquivo despejado com o desmontador. Se você não se importa com o estado do processo, você pode forçá-lo a despejar o núcleo com kill -SEGV pid, mas se no momento da inicialização não for permitido despejar os arquivos principais ( ulimit -c size), ele não irá despejar o núcleo, mas ainda morrerá, perdendo qualquer pedaço de informação você deseja obter.
Existem também ferramentas forenses mais especiais destinadas à mesma tarefa, mas geralmente têm como alvo pessoas experientes.
- Essa suposição faz sentido?
Eu não acho. Eu estava um pouco preocupado se meu fvwm começasse a se comportar assim, ou mesmo twm (se eu estivesse acostumado), mas quanto ao kwin (e ao KDE em geral), espero esse comportamento porque o KDE de hoje é enorme e tal uma atividade é "normal" para isso.
Se fosse esse comportamento com fvwm, por exemplo, eu primeiro verifiquei se o processo /proc/pid/exe aponta para o binário correto, depois verifiquei o tempo de criação desse binário com e stat -c %z /path/to/binaryrastreei-o se era legítimo ou apressado para o meu sempre pronto kdb, caso contrário, congela o sistema. A maior parte das atividades “desperdiçadas” são bugs de programas ou excesso de software.
- Nota: copiei principalmente a
/proc/xxxpasta, por isso tenho algumas informações.
Isso não faz sentido porque os arquivos /proc são puramente virtuais e alguns deles importantes (como o mempseudoarquivo) são ilegíveis quando solicitados de maneira casual.