프로세스 해킹/크랙 여부를 분석하는 절차

Question

이 프로세스가 크랙/해킹되었는지 확인하기 위해 따라야 할 절차는 무엇입니까?

현재 실행 중인 시스템에서 단일 프로세스가 수행하는 작업을 확인하는 유일한 방법은 해당 프로세스를 디버그하거나 전체 시스템(커널)을 디버그하는 것입니다. 첫 번째 방법은 다소 쉬우며 여러 도구를 사용하면 의심되는 프로세스에서 실시간으로 해당 작업을 수행할 수 있습니다. strace어떤 syscall이 수행하는지, ltrace어떤 공유 라이브러리 함수가 호출되는지, 또는 gdb전체적으로 현재 실행되는 명령이 무엇인지 확인할 수 있습니다 . 후자의 경우 해당 프로세스를 (기본 모드에서) 동결할 뿐만 아니라 kwingdb가 프로세스를 로드하고 중지된 줄을 표시할 수 있도록 올바른 위치에 배치하는 소스 코드가 필요합니다. 그렇지 않으면 특수 명령이 포함된 기계 명령어만 표시됩니다.

커널을 디버그하려면 이미 실행 중인 시스템의 상황에서는 불가능할 수도 있는 특별한 설정이 필요합니다(부팅 시 이러한 설정이 준비되지 않은 경우). 이를 통해 전체 시스템을 로컬로(kgdb의 kdb) 또는 원격으로(gdb로 kgdb) 중지하고 메모리, 레지스터를 검사하고 일부 유용한 정보를 덤프하고 코드를 분해할 수 있습니다. 그러나 이를 효과적으로 해석하려면 최소한 x86 asm의 기본 사항을 알아야 합니다.

커널은 일반 모드에서는 읽을 수 없는 최소한 의사 파일 /proc/pid/mem을 제공하지만https://github.com/silynx/lynxware/blob/master/dumpmem.c/proc/pid/maps에 제공된 매핑을 기반으로 이 희소 파일을 읽는 래퍼입니다. 그런 다음 디스어셈블러를 사용하여 덤프된 파일을 검사할 수 있습니다. 프로세스 상태에 관심이 없다면 를 사용하여 강제로 코어를 덤프할 수 있지만 kill -SEGV pid시작 시 코어 파일 덤프가 허용되지 않은 경우( ulimit -c size) 코어를 덤프하지 않지만 여전히 종료되어 정보의 일부가 손실됩니다. 당신은 얻고 싶어합니다.

동일한 작업을 목표로 하는 더 많은 특수 포렌식 도구도 있지만 일반적으로 경험이 풍부한 사람들을 대상으로 합니다.

이 가정이 말이 되나요?

나는 그렇게 생각하지 않습니다. 내 fvwm이 그런 식으로 작동하기 시작하거나 심지어 twm(내가 익숙했다면)에 대해 조금 걱정했지만, kwin(그리고 일반적으로 KDE)에 관해서는 오늘날의 KDE가 거대하기 때문에 그런 동작이 있을 것으로 예상합니다. 활동은 "정상"입니다.

예를 들어 fvwm에서 그러한 동작이 발생했다면 먼저 해당 프로세스의 /proc/pid/exe가 올바른 바이너리를 가리키는지 확인한 다음 를 사용하여 해당 바이너리의 생성 시간을 확인한 다음 stat -c %z /path/to/binary합법적이거나 내 kdb가 항상 준비되어 있지 않으면 시스템이 정지됩니다. "낭비되는" 활동의 대부분은 프로그램 버그나 소프트웨어 팽창입니다.

참고: 폴더를 대부분 복사했기 /proc/xxx때문에 꽤 많은 정보가 있습니다.

/proc 파일은 순전히 가상이고 그 중 일부 중요한 파일(예: 의사 파일)은 일반적인 방식으로 요청할 때 읽을 수 없기 때문에 이는 의미가 없습니다 mem.

Answer 1

이 프로세스가 크랙/해킹되었는지 확인하기 위해 따라야 할 절차는 무엇입니까?