순전히 우연히, 컴퓨터를 사용하지 않을 때 특정 프로세스가 한 코어의 100%를 차지하는 경우가 있다는 것을 발견했습니다. CPU를 사용할 때는 1% 미만이지만 컴퓨터가 IDL에 있을 때는(예: 화면이 꺼져 있고 한동안 아무도 없습니다. 컴퓨터를 터치하면 프로세스가 CPU를 과도하게 사용하기 시작하고 입력이 화면을 깨우자마자 프로세스가 다시 "정상"이 됩니다.
어떤 프로세스가 CPU를 많이 차지하고 있는지 기록하는 스크립트를 만들었고 그 결과는 kwin(cmdline= kwin-session1011dcae5a5000144224709....)
화면이 꺼져 있을 때 창 관리자가 CPU를 100% 사용하면 안 된다는 말을 들었기 때문에 내 컴퓨터에 크랙/해킹이 있는지 찾고 있습니다.
내 질문은 다음과 같습니다
- 프로세스가 손상/해킹되었는지 확인하려면 어떤 절차를 따라야 합니까?
- 이 가정이 의미가 있나요?
참고: 대부분의 폴더를 복사했기 /proc/xxx때문에 꽤 많은 정보가 있습니다.
답변1
- 프로세스가 손상/해킹되었는지 확인하려면 어떤 절차를 따라야 합니까?
현재 실행 중인 시스템에서 단일 프로세스가 수행하는 작업을 확인하는 유일한 방법은 해당 프로세스를 디버깅하거나 전체 시스템(커널)을 디버깅하는 것입니다. 첫 번째 방법은 매우 간단하며 의심스러운 프로세스에 대해 실시간으로 이 작업을 수행할 수 있는 여러 도구가 있습니다. strace어떤 시스템 호출을 수행하는지 확인할 수 있고 , ltrace어떤 공유 라이브러리 기능을 호출하는지, 심지어 gdb현재 전체적으로 실행 중인 명령도 확인할 수 있습니다. 후자의 경우 프로세스를 정지시키는 것이 아니며(기본 모드에서) kwingdb가 프로세스를 로드하고 중지된 줄을 표시할 수 있도록 올바른 위치에 소스 코드가 필요합니다. 그렇지 않으면 특수 명령이 포함된 기계 명령어만 표시됩니다.
커널을 디버깅하려면 특별한 설정이 필요합니다. 이는 이미 실행 중인 시스템의 경우에는 불가능할 수 있습니다(해당 설정이 부팅 시 준비되지 않은 경우). 이를 통해 전체 시스템을 로컬(kgdb의 경우 kdb) 또는 원격으로(kgdb 및 gdb) 중지하고 메모리를 검사하고, 등록하고, 일부 유용한 정보를 덤프하고, 코드를 분해할 수 있습니다. 하지만 효과적으로 설명하려면 최소한 x86 asm의 기본을 이해해야 합니다.
커널은 최소한 일반 모드에서는 읽을 수 없는 의사 파일 /proc/pid/mem을 제공하지만https://github.com/siblenx/lynxware/blob/master/dumpmem.c/proc/pid/maps에 제공된 매핑을 기반으로 이 스파스 파일을 읽는 래퍼입니다. 그런 다음 디스어셈블러를 사용하여 덤프된 파일을 검사할 수 있습니다. 프로세스 상태에 관심이 없다면 .kill -SEGV pidulimit -c size
동일한 작업에 대해 보다 전문화된 포렌식 도구가 있지만 일반적으로 숙련된 인력을 대상으로 합니다.
- 이 가정이 의미가 있나요?
난 그렇게 생각하지 않아. 내 fvwm이 그렇게 작동하기 시작하거나 심지어 twm(익숙해지면)도 조금 걱정됩니다. 하지만 kwin(및 일반적으로 KDE)에 관해서는 오늘 KDE 이후로 이렇게 작동하고 싶습니다. 꽤 큰 활동입니다. 그것은 "정상적인" 활동입니다.
예를 들어, fvwm이 이런 식으로 동작하는 경우 먼저 프로세스의 /proc/pid/exe가 올바른 바이너리를 가리키는지 확인한 다음 stat -c %z /path/to/binarykdb를 사용하여 해당 바이너리의 생성 시간을 확인합니다. 그렇지 않으면 시스템이 정지됩니다. 대부분의 "낭비" 활동은 프로그래밍 버그나 소프트웨어 팽창입니다.
- 참고: 대부분의 폴더를 복사했기
/proc/xxx때문에 꽤 많은 정보가 있습니다.
/proc 파일은 순전히 가상 파일이고 일부 중요한 파일(예: mem의사 파일)은 무작위로 요청할 때 읽을 수 없기 때문에 이는 의미가 없습니다.