☰

64비트 시스템의 /proc/kcore 구조 및 물리적 메모리와의 관계

tag-icon • tag-icon linux memory 64bit gdb
64비트 시스템의 /proc/kcore 구조 및 물리적 메모리와의 관계

나와 비슷하지만 32비트 컴퓨터에 대한 질문에 대한 많은 답변을 찾았다는 점부터 시작하겠습니다. 그러나 64비트 컴퓨터에서는 아무것도 찾을 수 없습니다. 32비트 시스템에 관한 질문에는 대답하지 마십시오.

Stack Exchange의 많은 소스에 따르면, /proc/kcore그대로 덤프하는 것이 가능합니다(예 dd:/proc/kcore

그런데, 메모리는 첫 번째 MB 를 통해서만 액세스할 수 있다는 것을 알았습니다 /dev/mem. 이는 보안상의 이유입니다. 이 문제를 해결하려면 커널을 다시 컴파일해야 하는데, 저는 그렇게 하고 싶지 않습니다. 제 목적으로는 그렇게 할 수도 없습니다(실행 중인 커널을 사용해야 합니다).

좋아요... /proc/kcore여기에 사용할 수 있는 물리적 메모리의 ELF 코어 파일 덤프가 있습니다 gdb.

gdb /usr/[blah]/vmlinux /proc/kcore

이를 위해 나는할 수 있는하세요...하지만 이건아니요내가하고 싶은 일. 오프라인 분석을 위해 물리적 메모리를 파일로 내보내고 싶습니다. 그런데 문제가 생겼습니다.

우선, /proc/kcore128TB이기 때문에 파일에 직접 덤프할 수 없습니다. 모든 물리적 메모리를 덤프하고 싶지만 모르겠습니다.어디그것은 /proc/kcore3600바이트까지 0이 아닌 데이터만 볼 수 있으며 그 다음에는 (약 40GB) 모든 데이터가 0입니다. 이것이 메모리가 매핑되는 방식과 관련이 있을 수 있다고 생각 /proc/kcore하지만 구조를 이해하지 못하고 지침이 필요합니다.

더 많이 알고 있는 것 같습니다. 주소 지정에는 64비트가 아닌 48비트만 사용된다는 것을 알고 있습니다. 즉, 2 48 = 256TB의 메모리를 사용할 수 있지만... /proc/kcore128TB만 사용할 수 있습니다.제 생각에는주소 지정이 0x0000000000000000부터 0x00007ffffffffff(128TB)까지의 블록과 0xffff800000000000부터 0xffffffffffffffff(128TB)까지의 블록으로 더 나누어지기 때문입니다. 그러면 어떻게든 /proc/kcore128TB가 됩니다. 그런데 그 블록 중 하나는 매핑되고 /proc/kcore다른 하나는 매핑되지 않기 때문일까요? 아니면 다른 이유가 있나요?

예를 들어, sys_call_table의 위치(?)를 gdb구문 분석 하고 찾기 위해 수행할 수 있는 작업은 다음과 같습니다./proc/kcore

(gdb) p (unsigned long*) sys_call_table
$1 = (unsigned long *) 0xffffffff811a4f20 <sys_read>

이는 0xffff8000000000000에서 0xffffffffffffffff까지의 메모리 블록이 의 내용이라는 것을 의미합니까 /proc/kcore? 그렇다면 어떻게 매핑됩니까 /proc/kcore? 예를 들어

dd if=/proc/kcore bs=1 skip=2128982200 count=100 | xxd

0만 표시됩니다(0xffffffffffffffff-0xffffffff811a4f20보다 약간 앞선 2128982200)...

gcore또한 분석을 위해 특정 프로세스의 메모리 덤프를 사용하는 방법도 알고 있습니다 . 프로세스 메모리가 어떻게 생겼는지 볼 수 있다는 것도 알고 있지만.../proc/PID/maps그럼에도 불구하고나는 아직도 전체 물리적 메모리를 버리는 방법을 모른다...그것이 나를 미치게 만든다. 제가 미쳐버리지 않도록 도와주세요... ;)

답변1

많은 검색 끝에 나는 내가 원하는 것을 얻을 수 있는 쉬운 방법은 없다는 것을 스스로 확신하게 된 것 같습니다.

그래서 결국 나는 무엇을 하게 됐나요? 저는 github에서 LiME를 설치했습니다(https://github.com/504ensicsLabs/LiME)

git clone https://github.com/504ensicsLabs/LiMe
cd /LiME/src
make -C /lib/modules/`uname -r`/build M=$PWD modules

위 명령은 lim.ko 커널 모듈을 생성합니다. 그런 다음 다음 명령을 실행하여 전체 메모리 덤프를 가져옵니다.

insmod ./lime.ko "path=/root/temp/outputDump.bin format=raw dio=0"

방금 커널 모듈을 삽입했고 문자열은 출력 파일 위치와 형식을 지정하는 매개변수였습니다. 그리고 작동했습니다! 엄청난.

답변2

이 명령의 출력을 살펴봐야 합니다 sudo readelf -e -g -t /proc/kcore. 각 가상 주소 공간의 오프셋을 가져와 lseek() 및 read()를 통해 덤프할 수 있습니다.

이것을 발견하는 데는 많은 돈이 걸렸습니다. 처음에는 가상 주소 매핑이 읽기 전용인 줄 알았습니다. /dev/kmem과 비슷하지만 쓰기 권한이 없습니다... 내가 읽었을 때 그것은 RAM 액세스가 있는 의사 ELF 파일이었고 ELF 바이너리 유틸리티를 사용하여 액세스할 수 있었고 readelf를 시도했습니다.

괜찮아요.

관련 정보