- Qual é o procedimento a seguir para saber se esse processo é violado / 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 no processo suspeito. Você pode strace o que o syscalls executa e ltrace para ver quais funções de biblioteca compartilhada ele chama ou até gdb como um todo para ver quais instruções ele executa atualmente. Não que, por último, você congele esse processo (no modo padrão), assim como você precisa de um código-fonte de kwin colocado 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 essa configuração no momento da inicialização). Ele permite que você pare todo o sistema, localmente (kdb do kgdb) ou remotamente (kgdb com gdb) e inspecione a memória, registre e salve algumas informações úteis, além de desmontar o código. No entanto, para interpretá-lo efetivamente, você precisa saber pelo menos o básico do x86 asm.
O kernel fornece pelo menos um pseudofile / proc / pid / mem que é ilegível no modo normal, mas link é uma coisa que lê este arquivo esparso com base nos mapeamentos fornecidos em / proc / pid / maps. Você pode então inspecionar arquivo despejado com desmontador. Se você não se importa com o estado do processo, pode forçá-lo a despejar o núcleo com kill -SEGV pid , mas se no momento do lançamento ele não tiver permissão para despejar arquivos principais ( ulimit -c size ), ele não descartará o núcleo, mas ainda morrerá , perdendo qualquer informação que você queira obter.
Há também ferramentas forenses mais especiais voltadas para a mesma tarefa, mas geralmente visam pessoas experientes.
- Esta suposição faz sentido?
Eu não penso assim. Eu me preocupei um pouco se meu fvwm começou a se comportar assim, ou mesmo twm (se eu estivesse acostumado), mas quanto ao kwin (e ao KDE em geral) eu espero esse comportamento porque o KDE de hoje é enorme e uma atividade é "normal" para isso.
Se fosse um comportamento como o fvwm, por exemplo, eu verifiquei primeiro que o processo '/ proc / pid / exe aponta para o binário correto, então verifiquei o tempo de criação desse binário com stat -c %z /path/to/binary , então o alterei se era legítimo ou apressado para o meu sempre pronto kdb se não, congelando o sistema. A maior parte da atividade "desperdiçada" são erros de programas ou inchaço de software.
- Nota: copiei principalmente a pasta
/proc/xxx, 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 mem pseudofile) são ilegíveis quando solicitados de maneira informal.