전체 시스템 메모리를 덤프하는 방법


9

VirtualBox를 시작한 후 컴퓨터가 느려지고 OOM으로 인해 완전히 중단되었습니다. 일반적으로 OOM은 공간을 확보하기 위해 강제 종료 프로세스를 시작해야하지만 이것은 발생하지 않았습니다 (이것이 두 번째로 발생했습니다).

텍스트 편집기에서 저장하지 않은 중요한 작업이 있었으므로 SysRq+를 사용하여 현재 콘솔의 모든 프로세스를 종료 한 후 시스템 RAM에서 다시 찾으려고했습니다 K. 해당 머신은 대상 디스크로 SSD를 사용하여 Linux x86_64 3.7.5를 실행하는 8GiB RAM이 장착 된 랩톱입니다.

첫 번째 시도는 dd if=/dev/mem of=memory이지만 1MiB의 데이터를 읽은 후 실패했습니다. 다음으로 시도 dd if=/dev/fmem of=memory bs=1M했지만 3010461696 바이트 (정확하게 2871 MiB)를 읽은 후에 중지되었습니다. 보고 후 /proc/mtrr(아래 그림 참조), 나는 추가하기로 결정했습니다 skip=4096. 결국 3MiB / 초의 속도로 읽기가 느려지므로 중단했습니다 (파일 5.8GiB). (적어도 파일의 마지막 100MiB에 FFs 가 포함되어 있음 )

reg01: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
reg02: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg03: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back
reg04: base=0x200000000 ( 8192MB), size= 1024MB, count=1: write-back
reg05: base=0x23c000000 ( 9152MB), size=   64MB, count=1: uncachable
reg06: base=0x0b4000000 ( 2880MB), size=   64MB, count=1: uncachable
reg07: base=0x0b8000000 ( 2944MB), size=  128MB, count=1: uncachable

텍스트 편집기에서 몇 시간 동안 열어 놓은 데이터를 찾을 수 없으므로 덤프를 수행하는 동안 일부 메모리를 건너 뛰었다 고 생각합니다. 내 목표 (사용자 공간 프로그램에서 데이터 복구)를 감안할 때 시스템 메모리를 파일로 덤프하는 가장 효율적인 방법은 무엇입니까? 그러한 덤프를 수행하는 동안 고려해야 할 몇 가지 사항은 무엇입니까?


/ proc / kmem도 사용해 보셨습니까? 복사하는 동안 변경되기 때문에 그다지 가치가 없습니다.
ott--

@ ott-- CONFIG_DEVKMEM는 비활성화되어 있으며, 소스 코드를 보면 무제한 액세스를 허용하는 것 같지만 이것이 최선의 방법이라고 확신하지는 않습니다 (IO mem access?)
Lekensteyn

2
아마도 편집기의 메모리를 얻었지만 인식하지 못했습니다. 메모리 덤프에서 데이터 구조를 재구성하는 것은 어려울 수 있습니다. 가장 먼저해야 할 일은 커널 데이터 구조에서 메모리 매핑을 재구성하는 것입니다 (기존의 법의학 도구가있을 것입니다) 관심있는 프로세스의 가상 메모리를 얻을 수 있습니다. 실제 메모리에 많은 분리 된 4kB 페이지를 분산시킵니다. 그러면 텍스트가 하나의 연속 된 얼룩에 있지 않을 수 있으며 UCS4 또는 다른 표현을 사용할 수 있으며 별도의 청크에 선이나 다른 블록을 저장할 수 있습니다.
Gilles 'SO- 악마 그만'

1
@Gilles +1, 일단 프로세스가 종료되면 커널은 작업 디스크립터를 해제 할 것으로 예상합니다.-> 주소 공간 매핑을 잊어 버립니다. 데이터 표현에 관해서는, 쉽게 나무가 될 수 있습니다 (JVM에 의해 충분한 운이 할당 됨).
peterph

그래서 당신은 거기에 없을 수도있는 몇 킬로바이트의 텍스트를 찾기 위해 기가 바이트의 데이터를 파헤칠 것입니까? 바늘, 건초 더미를 만나십시오. 당신이 이것에 보낸 시간에 당신은 텍스트를 다시 입력했을 수 있습니다. 처음에 그 정도가 많으면 텍스트 편집기가 정기적으로 백업을 저장하도록 구성되어 충돌이 발생하더라도 많이 잃지 않도록해야합니다.
psusi

답변:


4

이 프로젝트를 확인하십시오 : foriana

Foriana는 (FOrensic Ram Image ANAlyzer)

입력 : (물리적) RAM 출력 덤프 : 다양한 정보

버전 1.0은 i386 / x86_64 / arm linux / bsd 커널의 메모리 덤프에서 프로세스 및 모듈을 나열 할 수 있으며 덤프에서 선형 메모리를 읽는 옵션을 제공합니다.

커널 모듈 fmem이 있습니다 :

Fmem은 커널 드라이버이며 / dev / fmem 장치를 만듭니다. / dev / fmem은 / dev / mem (물리적 메모리에 대한 직접 액세스)과 같은 방식으로 동작하지만 / dev / mem에 제한이 없습니다. / dev / fmem을 통해 전체 물리적 메모리를 덤프 할 수 있습니다.

나는 그것을 사용했고, 꽤 쉽게 컴파일했다.


asker는 시도했다 /dev/fmem.
Tobu

3

ddrescue액세스 할 수없는 데이터를 건너 뛸 수있는 유사한 프로그램 을 사용하고 싶을 수도 있습니다 . dd conv=noerror도움이 될 수도 있습니다. 수퍼 유저에서도이 질문을 확인하십시오 .

더 중요한 것은 OOM 상황에 처한 경우 커널이 요청하는 응용 프로그램 이외의 페이지에서 커널을 스왑 아웃하여 느려졌을 가능성이 큽니다. 따라서 데이터를 원한다면 대신 스왑을 확인하십시오 /dev/mem-기회가있을 것입니다. 마찬가지로 OOM 킬러가 시작되지 않고 수동으로 프로세스를 종료하는 경우 일단 편집자가 먼저 종료되면 메모리 배고픈 프로세스가 여전히 해당 페이지를 가져 오기 위해 약간의 시간이 걸릴 수 있습니다.

주석의 질에 의해 언급 한 바와 같이 당신이 쉽게 당신이 살해 프로세스의 주소 공간 매핑을 재구성하기 위해 관리하는 경우에도 찾을 수 없습니다 있도록 데이터를 쉽게, 일부 특수 구조에있을 수 필요한 모든을 찾을 정도로 운이 페이지는 그대로 유지됩니다.


1
나는 전에 SU 대답을 보았습니다. 그것이 fmem을 찾은 방법입니다. ddrescue256 페이지 (1MiB)는 하드 코딩 된 제한이므로 도움이되지 않습니다. OOM 상태가 될 것으로 예상되지만 OOM 킬러는 시작되지 않았습니다 ( pastebin.com/DvYTCcRK ). 일주일 전에 같은 문제가 발생했습니다 (여전히 Linux 3.7.5, 재부팅하지 않고 램으로 만 일시 중단됨). SSD가 있기 때문에 스왑 파일 / 파티션이 없습니다. (스왑 = 60 (기본값)).
Lekensteyn
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.