- What is the procedure to follow to know if this process is cracked/hacked?
The only way to see what a single process does in a currently running system is to debug that process, or debug the whole system (kernel). The first is rather easy, and several tools allow you to do that live on the suspected process. You can strace what syscalls does it perform and ltrace to see what shared library functions does it call, or even gdb as a whole to see what instructions it currently executes. Not that for latter you will freeze that process (in default mode) as well as you need a source code of kwin laying in right place so gdb will able to load it and show you a line where it did stop. Otherwise it will show you only machine instruction with special commands.
To debug the kernel you need a special setup which is not probably possible for a situation of already running system (if it was not prepared for such a setup at boot time). It permits you to stop the whole system, locally (kgdb's kdb) or remotely (kgdb with gdb) and inspect memory, registers, and dump some useful information as well as disassembling the code. However to interpret it effectively you need to know at least the basics of x86 asm.
The kernel provides at least a pseudofile /proc/pid/mem which is unreadable in normal mode, but https://github.com/siblynx/lynxware/blob/master/dumpmem.c is a wrapper thing that reads this sparse file based on mappings provided in /proc/pid/maps. You can then inspect dumped file with disassembler. If you don't care about process state, you can force it to dump core with kill -SEGV pid, but if at launch time it was not permitted to dump core files (ulimit -c size), it will not dump core but will still die, losing any bits of info you want to get.
There are also more special forensics tools aimed at same task, but they usually target experienced people.
- Does this supposition make sense?
I don't think so. I'd worried about a bit if my fvwm started to behave like that, or even twm (if I used to it), but as for kwin (and KDE in general) I expect that behavior from it because today's KDE is huge and such an activity is "normal" for it.
If it was such a behavior with fvwm for example, I'd first checked that process' /proc/pid/exe points to right binary, then checked creation time of that binary with stat -c %z /path/to/binary, then straced it if it was legitimate or rushed to my always ready kdb if not, freezing the system. Most of "wasted" activity is program bugs or software bloat.
- Note: I copied mostly the
/proc/xxx folder so I have quite some information.
This does not makes sense because /proc files are purely virtual, and some important of them (like the mem pseudofile) are unreadable when requested in casual way.
