[Linux] 메모리 덤프(Memory Dump)#01

[Linux] 메모리 덤프(Memory Dump)#02

 

[Memory Dump란?]

메모리 덤프란 시스템의 물리 메모리(휘발성 메모리) 내용을 파일로 저장하는 작업을 말합니다. 이 파일은 실제 메모리 구조와 동일하게 저장되어, 침해사고 분석이나 악성코드 분석, 디지털 포렌식 등 다양한 분야에서 핵심적인 단서를 제공합니다.

이번 글에서는 MagnetForensics에서 개발한 Linux용 메모리 덤프 도구인 DumpIt-Linux에 대해 자세히 알아보겠습니다.

1. 왜 메모리 덤프가 중요한가?
시스템이 침해된 시점의 메모리에는 다음과 같은 중요한 정보가 남아있습니다:

  • 실행 중인 악성코드의 흔적
  • 네트워크 연결 정보
  • 암호화되지 않은 계정 정보
  • 각종 민감 데이터

실시간 분석을 하면 메모리 상태가 변할 수 있기 때문에, 최대한 원본 그대로의 메모리 이미지를 확보하는 것이 중요합니다.

 

2. 리눅스에서의 메모리 덤프 방법
  > 과거 방식: /dev/mem, /dev/kmem

  • 리눅스는 모든 리소스를 파일로 다루기 때문에, 예전에는 /dev/mem이나 /dev/kmem을 통해 메모리에 접근할 수 있었습니다. 하지만 보안상의 이유로 최신 커널에서는 이 접근이 제한되거나 아예 제거되었습니다.

 

  > 현재 방식: 커널 모듈(LKM) 및 /proc/kcore 활용

  • 그래서 등장한 것이 LiME, AVML, DumpIt-Linux 등과 같은 메모리 덤프 도구입니다. 이들은 커널 모듈(LKM, Loadable Kernel Module)이나 /proc/kcore 인터페이스를 활용하여, 시스템의 동작을 방해하지 않으면서 메모리 덤프를 수행할 수 있습니다.

 

3. DumpIt-Linux란?
 - DumpIt-Linux는 MagnetForensics에서 개발한 오픈소스 Linux 메모리 획득 도구입니다. 이 도구는 Rust 언어로 개발되었으며, /proc/kcore를 활용하여 메모리 덤프를 생성합니다.
 - Windows용 DumpIt과 동일한 철학을 따라, Microsoft Crash Dump 형식과 완전히 호환되는 Windows 버전과는 달리, DumpIt-Linux는 Linux ELF Core 형식을 사용하여 gdb, crash, drgn과 완전히 호환됩니다.
 - DumpIt-Linux 공식 GitHub
https://github.com/MagnetForensics/dumpit-linux

4. DumpIt-Linux의 장점

  • 상호 운용성: 생성된 출력 파일은 인기 있는 Linux 디버깅 및 문제 해결 도구들과 호환됩니다 (gdb, crash, drgn)
  • 오픈 파일 형식: 새로운 파일 형식에 의존하지 않고, Linux ELF CORE 파일을 생성하여 다양한 도구와의 상호 운용성을 보장합니다
  • 압축 지원: 초고속 zstandard 압축 알고리즘을 사용하는 .tar.zst 아카이브 형식을 활용합니다
  • Rust 기반: 메모리 안전성을 보장하며, 추가적인 원격 스트리밍 옵션으로 확장 가능합니다
  • 사용자 공간 동작: /proc/kcore에 의존하므로 Linux 커널 모듈이 필요하지 않습니다. 단, root 권한은 필요합니다
  • 커널 의존성 없음: LiME와 달리 커널 버전별 빌드가 필요하지 않아 대규모 환경에서 유리합니다

 

5. 설치 및 빌드
 - 시스템 요구사항
  > DumpIt-Linux를 빌드하기 위해서는 다음이 필요합니다:

  • Rust 프로그래밍 언어
  • pkg-config
  • liblzma-dev

 

 - Ubuntu/Debian 계열 설치

필수 패키지 설치
# apt install build-essential liblzma-dev

Rust 설치
# curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

소스 코드 다운로드
# git clone https://github.com/MagnetForensics/dumpit-linux.git
# cd dumpit-linux

빌드
# cargo build --release

 

 - Amazon Linux/CentOS 계열 설치

필수 패키지 설치
# yum install xz-devel

Rust 설치
# curl https://sh.rustup.rs -sSf | sh -s -- -y
# source "$HOME/.cargo/env"

빌드
# git clone https://github.com/MagnetForensics/dumpit-linux.git
# cd dumpit-linux
# cargo build --release

 

빌드가 완료되면 target/release 디렉토리에 실행 파일이 생성됩니다.

6. 사용방법
 - 기본 사용법

기본 압축 아카이브 생성 (권장)
# ./dumpitforlinux

특정 경로에 저장
# ./dumpitforlinux /path/to/memory_dump.tar.zst

Raw 형식으로 저장
# ./dumpitforlinux -r /tmp/memory_dump.raw

표준 출력으로 내보내기
# ./dumpitforlinux -0 > memory_dump.raw

 

 - 명령어 옵션

DumpIt (For Linux - x64 & ARM64) 0.1.0
사용법: dumpitforlinux [OPTIONS] [Output Path]

옵션:
  -0, --to-stdout    파일 대신 stdout으로 출력
  -r, --raw          압축 아카이브 대신 단일 코어 덤프 파일 생성
  -v, --verbose      파싱 중 추가 출력 표시
  -p, --pipe         명명된 파이프에 출력 작성
  -h, --help         도움말 정보 출력
  -V, --version      버전 정보 출력

 

 - 압축 해제
  > 생성된 압축 파일을 해제하려면 다음 명령어를 사용합니다:

# tar -I zstd -xvf filename.tar.zst

 

7. Memory Dump 분석 전 준비사항
 - Memory Dump 분석 전 복사본을 생성하여 분석작업을 진행하도록 합니다. 이때 빠지지않고 해야되는 중요한 것은 해시값을 계산하는 것입니다:

해시값 계산
# md5sum memory_dump.raw
# sha1sum memory_dump.raw  
# sha256sum memory_dump.raw

 - 이렇게 얻은 Memory Dump 파일은 Volatility 등의 분석툴을 사용하여 분석할 수 있습니다.

 

8. 분석 도구와의 호환성

 - DumpIt-Linux로 생성한 메모리 덤프는 다음 도구들과 호환됩니다:

 - crash 도구 사용

crash 설치
# apt install crash
# apt-get install linux-image-`uname -r`-dbgsym

crash로 덤프 분석
# crash  /usr/lib/debug/boot/vmlinux-`uname -r`</path to dump>

 

 - drgn 도구 사용

drgn 설치 및 사용
# pip3 install drgn
# drgn -c </path to dump>

Google Container OS의 경우 심볼 파일과 함께
# drgn -c dump.core -s vmlinux-version

 

 - gdb 사용
  > ELF Core 형식으로 생성되므로 표준 gdb로도 분석이 가능합니다.

 

9. DumpIt-Linux vs 다른 도구 비교
 - DumpIt-Linux vs LiME

항목 DumpIt-Linux LiME
설치/배포 단일 실행 파일, 배포 간편 커널 모듈 빌드 필요, 배포 번거로움
커널 의존성 없음 커널 버전별 빌드 필요
지원 환경 x86_64, aarch64 등 다양한 배포판 리눅스/안드로이드, 다양한 커널
권한 root 필요 root 필요
한계 /proc/kcore 접근 제한 시 미동작 가능 모듈 로딩 제한 시 미동작 가능

 

 - DumpIt-Linux vs AVML
  > DumpIt-Linux와 AVML은 모두 /proc/kcore를 사용하는 유사한 접근 방식을 취합니다. 둘 다 커널 모듈이 필요하지 않으며 대규모 환경에 적합합니다.

10. 주의사항 및 제한사항

 - 제한사항

  • /proc/kcore에 대한 접근이 제한된 환경에서는 동작하지 않을 수 있습니다
  • 커널 lockdown이 활성화된 환경에서는 추가 고려사항이 필요할 수 있습니다
  • Root 권한이 반드시 필요합니다

 

 - 보안 고려사항

  • 메모리 덤프 파일은 시스템 RAM 크기와 동일한 용량을 차지하므로 충분한 저장 공간이 필요합니다
  • 메모리 덤프는 민감한 정보를 포함할 수 있으므로 안전한 위치에 저장해야 합니다
  • 원격 시스템에서 덤프를 수행할 때는 네트워크를 통한 전송 시 보안을 고려해야 합니다

 

11. 결론
DumpIt-Linux는 전통적인 LiME의 복잡한 커널 모듈 빌드 과정을 제거하고, 간편한 단일 실행 파일로 Linux 메모리 획득을 가능하게 하는 기본적인 도구입니다. Rust 언어로 개발되어 메모리 안전성을 보장하며, ELF Core 형식을 사용하여 기존 Linux 디버깅 도구들과의 완벽한 호환성을 제공합니다.

특히 대규모 환경에서 다양한 커널 버전을 지원해야 하는 상황에서 DumpIt-Linux의 커널 의존성 없는 설계는 매우 유용합니다. 침해사고 대응이나 포렌식 조사에서 신속하고 안정적인 메모리 수집이 필요한 경우 DumpIt-Linux는 훌륭한 선택이 될 것입니다.

반응형

[Linux] 메모리 덤프(Memory Dump)#01

[Linux] 메모리 덤프(Memory Dump)#03

 

[Memory Dump 란?]
메모리 덤프란 시스템의 물리 메모리(휘발성 메모리) 내용을 파일로 저장하는 작업을 말합니다. 이 파일은 실제 메모리 구조와 동일하게 저장되어, 침해사고 분석이나 악성코드 분석, 디지털 포렌식 등 다양한 분야에서 핵심적인 단서를 제공합니다.
 

이번 글에서는 리눅스 환경에서 메모리 덤프를 안전하게 획득하는 방법으로 AVML(Acquire Volatile Memory for Linux)에 대해 자세히 알아보겠습니다.


1. 왜 메모리 덤프가 중요한가?
시스템이 침해된 시점의 메모리에는 다음과 같은 중요한 정보가 남아있습니다.
 - 실행 중인 악성코드의 흔적
 - 네트워크 연결 정보
 - 암호화되지 않은 계정 정보
 - 각종 민감 데이터
실시간 분석을 하면 메모리 상태가 변할 수 있기 때문에, 최대한 원본 그대로의 메모리 이미지를 확보하는 것이 중요합니다.
 

2. 리눅스에서의 메모리 덤프 방법
과거 방식: /dev/mem, /dev/kmem
 - 리눅스는 모든 리소스를 파일로 다루기 때문에, 예전에는 /dev/mem이나 /dev/kmem을 통해 메모리에 접근할 수 있었습니다. 하지만 보안상의 이유로 최신 커널에서는 이 접근이 제한되거나 아예 제거되었습니다.

현재 방식: 커널 모듈(LKM) 활용
 - 그래서 등장한 것이 fmem, LiME, AVML 등과 같은 커널 모듈 기반 메모리 덤프 도구입니다. 이들은 커널 모듈(LKM, Loadable Kernel Module)로 동작하여, 시스템의 동작을 방해하지 않으면서 메모리 덤프를 수행할 수 있습니다.

 

3. AVML(Acquire Volatile Memory for Linux)란?
LiME와 유사한 메모리 덤프 도구로, Microsoft에서 개발한 오픈소스 휘발성 메모리 획득 도구입니다. 번거로운 커널 모듈 빌드 과정 없이, 단일 실행 파일만으로 다양한 환경에서 메모리 덤프를 안전하게 획득할 수 있습니다. LiME보다 더 다양한 배포판 지원, 실행파일 제공, 최신 커널 호환성 등에서 장점이 있습니다.
AVML 공식 GitHub

 

4. AVML의 장점
 - 커널 버전 무관: LiME와 달리, 커널 모듈을 빌드하거나 커널 버전에 맞출 필요가 없습니다. 단일 바이너리로 바로 실행할 수 있습니다.
 - 간편한 배포: 실행 파일 하나만 복사하면 되기 때문에, 수십~수백 대의 서버에서도 빠르게 배포 및 사용이 가능합니다.
 - 루트 권한만 있으면 OK: root 권한으로 실행하면, /proc/kcore 등 시스템 인터페이스를 활용해 메모리를 추출합니다.
 - 대규모 환경에 적합: 커스텀 커널이 많은 대규모 환경에서도 별도 준비 없이 바로 사용할 수 있습니다.

 

[사용방법]

AVML을 다운로드 합니다.

# mkdir avml; cd avml
# wget https://github.com/microsoft/avml/releases/latest/download/avml
# chmod +x avml
# ./avml /tmp/mem.raw
# ls -alh /tmp/mem.raw
-rw------- 1 root root 4.0G May 21 21:24 /tmp/mem.raw

 

Memory Dump 분석 전 복사본을 생성하여 분석작업을 진행하도록 합니다. 이때 빠지지않고 해야되는 중요한 것은 해시값을 계산하는 것입니다. md5sum 이나 shasum 을 사용해서 해시값을 계산하면 됩니다.

# md5sum mem.img
db5fd6e1dabb055f8bc77fd67d95b588 mem.raw

# sha1sum mem.img
0a67af1d5fdc59bf42f4ae93d97580135786fe3c mem.raw

# sha256sum mem.raw
63e5814134a140691b452ac6e353bab73458263709da4cebd2fd6484d33b8954 mem.img

 

이렇게 얻은 Memory Dump 파일은 Volatility 등의 분석툴을 사용하여 분석할 수 있습니다.

 

[AVML vs LiME 간단 비교]

항목 AVML LiME
설치/배포 단일 실행 파일, 배포 간편 커널 모듈 빌드 필요, 배포 번거로움
커널 의존성 없음 커널 버전별 빌드 필요
지원 환경 x86_64, aarch64 등 다양한 배포판 리눅스/안드로이드, 다양한 커널
권한 root 필요 root 필요
한계 /proc/kcore 접근 제한 시 미동작 가능 모듈 로딩 제한 시 미동작 가능
반응형

◎ Windows hibernation files

자세한 내용은 [Windows] 메모리 덤프 형식(Memory Dump Format) 글에서 확인해주세요.

 

[최대절전모드]

> 1단계

최대절전모드의 시스템메모리는 일반적으로 c:\hiberfil.sys 파일에 저장됩니다. 최대절전모드를 사용 중인지 모르는 상태에서 종료해야된다면, 관리자권한으로 cmd를 실행한 뒤 아래 명령어로 최대절전모드를 켜고, 컴퓨터를 종료하면 됩니다.

 > powercfg /h on
 > shutdown /f /h

• powercfg /h on : powercfg는 전원관리 명령어, /h는 hibernate(최대절전모드), on은 설정 켜기입니다.

• shutdown /f /h : shutdown은 시스템 종료 명령어, /f는 강제종료, /h는 대기모드입니다.

 

> 2단계

저장장치를 분리해서 Linux 컴퓨터에서 hiberfil.sys 파일을 USB에 복사합니다.

 

> 3단계

제작사 홈페이지에서 Comae 툴킷을 다운받아서 Hibr2Bin.exe 이용해 hiberfil.sys 파일을 압축되지 않은 바이너리로 변환합니다.

일반적으로 Windows 10 응용 프로그램의 경우 다음과 같이 실행합니다.

 > Hibr2Bin /PLATFORM X64 /MAJOR 10 /MINOR 0 /INPUT hiberfil.sys /OUTPUT mem.bin

아래는 옵션 설명입니다.

 

> 4단계

이미지를 분석합니다.

 

◎ Expert witness format

EnCase 상용소프트웨어가 필요하기 때문에 생략합니다.

 

◎ HPAK Format

HBGary Responder 상용소프트웨어가 필요하기 때문에 생략합니다.

반응형

◎ Windows crach dump

※ 주의: 강제로 BSOD(Blue Screen of Death)가 발생하여 덤프 후 자동으로 다시 시작됩니다.

자세한 내용은 [Windows] 메모리 덤프 형식(Memory Dump Format) 글에서 확인해주세요.

 

• Complete 메모리 덤프

• Kernel 메모리 덤프

• Small 메모리 덤프

 

[크래시 덤프 생성 설정]

설정 - 시스템 - 정보로 이동합니다.

고급 시스템 설정을 선택한 다음 고급 탭을 선택합니다.

시작 및 복구 영역에서 설정을 선택합니다.

디버깅 정보 쓰기에서 원하는 덤프 형식을 지정합니다.

덤프파일 위치는 변경가능합니다.

 

[전체 메모리 덤프]

저장위치 : %SystemRoot%\Memory.dmp

 

[커널 메모리 덤프]

저장위치 : %SystemRoot%\Memory.dmp

 

[작은 메모리 덤프]

저장위치 : %SystemRoot%\Minidump 폴더

 

[수동 메모리 덤프 생성 방법]

Microsoft Sysinternals NotMyFault 도구를 사용하여 덤프를 생성할 수 있습니다.

 > notMyfault64.exe /crash

또는

> notmyfault64.exe /getdumptype = full
> notmyfault64.exe /crash 0x01

 

 

[Notmyfault 소개]

Notmyfault는 Windows 시스템에서 크래시, 중단 및 커널 메모리 누수를 유발하는 데 사용할 수 있는 도구입니다. 장치 드라이버 및 하드웨어 문제를 식별하고 진단하는 방법을 배우는 데 유용하며 오작동하는 시스템에서 블루 스크린 덤프 파일을 생성하는 데 사용할 수도 있습니다. 다운로드 파일에는 32비트 및 64비트 버전과 Nano 서버에서 작동하는 명령줄 버전이 포함되어 있습니다.

 

 

notmyfaultc64.exe 크래시 crash_type_num

crash type:
      0x01: High IRQL fault (Kernel-mode)
      0x02: Buffer overflow
      0x03: Code overwrite
      0x04: Stack trash
      0x05: High IRQL fault (User-mode)
      0x06: Stack overflow
      0x07: Hardcoded breakpoint
      0x08: Double Free

 

notmyfaultc64.exe hang hang_type_num

hang type:
      0x01: Hang with IRP
      0x02: Hang with DPC

 

반응형

◎ RAW memory dump

자세한 내용은 [Windows] 메모리 덤프 형식(Memory Dump Format) 글에서 확인해주세요.

 

• Windd

• DumpIt

• Magnet Ram Capture

• Winpmem

• Belkasoft Live RAM Capturer

• FTK Imager

 

[Windd]

Unix 용 dd의 윈도우 버전이라고 보면 되겠습니다. win32dd(win64dd)는 MoonSols 사의 무료 메모리 덤프 툴입니다. 윈도우 XP, Vista 그리고 Win7 x86, x86_64를 지원합니다. 윈도우 10 22H2는 지원하지 않습니다(BSOD 발생).

 

[DumpIt]

win32dd와 win64dd의 기능을 하나로 통합한 MoonSols 사의 무료 메모리 덤프 툴입니다. MoonSols 사의 dumpit은 역시나 윈도우 10 22H2는 지원하지 않습니다(BSOD 발생)만, Comae 사(Magnet Forensics 사에 인수됨)의 dumpit은 윈도우 10 22H2를 지원합니다. 더블클릭하면 메모리덤프 진행여부를 묻고 진행 시 Dumpit이 실행된 폴더에 크래시 덤프 파일을 저장합니다.

제작사 홈페이지에서 다운받을 수 있습니다.

  > MoonSols Dumpit

  > Magnet(Comae) Dumpit

 

[Magnet Ram Capture]

Magnet Forensics 사가 Comae 사를 인수하기 전에 배포한 툴입니다. Comae 사를 인수한 이후 Magnet Forensics 사의 홈페이지에서 Magnet Ram Capture 내용 대신 Dumpit 내용을 보여주고 있습니다.

 

※ MoonSols 사의 홈페이지도 접속이 안되고, MoonSols 사의 Windd와 Dumpit은 왜 업데이트가 안되는건지 궁금해서 만든이(Mathieu Suiche)를 검색해봤습니다.  Mathieu Suiche(1988년 9월 22일 출생)는 프랑스의 해커 이자 기업가로 MoonSols 사의 창립자이자 VMWare 사에 의해 인수되기 전 CloudVolumes 사의 공동 창립자입니다. 이후 Comae 사를 설립하였으며, 회사는 Magnet Forensics 사에 인수되었습니다. 현재는 Magnet Forensics 사의 Incident Response R&D 이사로 재직하고 있습니다.

 

[Winpmem]

Google의 Rekall 프로젝트(오픈소스 메모리분석 프레임워크)에 속해 있다가 현재는 독립한 무료 메모리 덤프 툴입니다. 마지막 릴리즈가 2020년 10월인데 윈도우 10 22H2를 지원합니다. CMD창을 관리자모드로 실행하고 아래 명령어를 입력하면 메모리 덤프를 진행합니다.

 > winpmem_mini_x64_rc2 memdump.raw

Github에서 다운받을 수 있습니다.

 

 

[Belkasoft Live RAM Capturer]

Belkasoft 사의 메모리덤프 툴입니다. 더블클릭으로 메모리 덤프가 가능합니다. 윈도우 10 22H2를 지원합니다.

제작사 홈페이지에서 다운받을 수 있습니다.

 

 

[FTK Imager]

Exterro 사의 메모리덤프 툴입니다. FTK Imager를 설치하고 일반적으로 "C:\Program Files\AccessData\FTK Imager" 폴더를 USB에 복사하면 독립실행이 가능합니다. 메모리덤프를 진행하기 원하는 시스템에 USB를 연결하고 FTK Imager.exe를 더블클릭하면 GUI에서 File - Capture Memory메뉴를 통해 메모리 덤프가 가능합니다. 윈도우 10 22H2를 지원합니다.

제작사 홈페이지에서 다운받을 수 있습니다.

반응형

[Memory Dump 란?]
Memory Dump 는 System의 물리 Memory 를 File 형태로 저장하는 방법으로, 해당 File 의 구조는 실제 물리 Memory 구조와 동일합니다. 침해사고 분석 시 침해 시스템에 실시간 분석을 수행하면 해당 명령어로 인해 Memory 의 상태 및 Data 가 변경됩니다. 

이는 Memory 로부터 얻을 수 있는 중요한 정보를 놓칠 수 있는 가능성이 존재하므로 분석에 불리하게 작용할 수 있습니다. 이 같은 실시간 분석의 단점으로 인해 침해사고 시점의 휘발성 Data 를 File 로 간직하여 Memory 에 변화를 주지 않으면서 분석을 하기위해 Memory Dump 를 수행합니다. 

◎ Windows 에서 Memory Dump
Windows 운영체제에서 메모리 덤프는 수집방법에 따라 파일 형식이 달라지지만 일반적으로 사용되는 메모리 덤프형식은 5가지가 있습니다.
• RAW memory dump.
• Windows crash dump.
• Windows hibernation files.(최대 절전 모드 파일)
• Expert witness format (EWF).
• HPAK format.

[RAW memory dump]
RAW 메모리 덤프는 가장 일반적으로 사용되는 메모리 덤프 형식입니다. RAW 메모리 덤프에는 headers, metadata, magic values 이 포함되어 있지 않습니다.

원시 형식에는 일반적으로 의도적으로 건너뛴 메모리 범위(예: 디바이스 메모리)나 수집 도구에서 읽을 수 없는 메모리 범위에 대한 패딩이 포함되어 공간 무결성(데이터 간 상대적 오프셋)을 유지하는 데 도움이 됩니다.

[Windows crach dump]
모든 Windows 운영체제는 컴퓨터 충돌 시 컴퓨터의 상태에 대한 정보를 덤프하도록 구성되어 있습니다. 이러한 크래시 덤프는 _DMP_HEADER 또는 _DMP_HEADER64구조로 시작됩니다.
Windows 크래시 덤프에는 세가지 형식의 메모리 덤프를 사용할 수 있습니다.
> Complete 메모리 덤프
이 메모리 덤프는 the largest kernel-mode 메모리 덤프 파일입니다.  이 메모리 파일에는 실제 메모리에 있던 모든 내용이 포함되어 있습니다. 이 메모리 덤프에는 플랫폼 펌웨어에서 사용하는 물리적 메모리가 포함되어 있지 않습니다.
> Kernel 메모리 덤프
이 커널 모드 메모리 덤프에는 메모리 캡처 시 커널에서 사용된 모든 내용이 포함되어 있습니다. 이 파일에는 커널에서 사용된 콘텐츠만 포함되어 있으므로 이 메모리 덤프는 전체 메모리 덤프보다 훨씬 작습니다. 이 메모리 덤프에는 할당되지 않은 메모리나 사용자 모드 응용 프로그램에 할당된 메모리가 포함되지 않으므로 분석 범위를 좁힐 수 있습니다.
> Small 메모리 덤프
이름에서 알 수 있듯이 Windows 크래시 덤프에서 생성할 수 있는 가장 작은 메모리 덤프 파일입니다.
이 메모리 파일에는 다음 내용이 포함됩니다.
• 버그 확인 메시지와 매개변수, 기타 블루스크린 데이터
• 충돌이 발생한 프로세서에 대한 프로세서 컨텍스트(PRCB)
• 충돌이 발생한 프로세스에 대한 프로세스 정보 및 커널 컨텍스트(EPROCESS)
• 충돌이 발생한 스레드에 대한 스레드 정보 및 커널 컨텍스트(ETHREAD)
• 충돌이 발생한 스레드에 대한 커널 모드 호출 스택. 16KB보다 길면 최상위 16KB만 포함
• 로드된 드라이버 목록

크래시 덤프가 생성될 수 있는 이유는 다음과 같습니다.
• Blue Screens
• CrashOnScrollControl
• Debuggers

그러나 위의 모든 방법이 법의학에 적합한 것은 아닙니다.

[Windows hibernation files]
최대 절전 모드는 컴퓨터의 상태를 유지하면서 컴퓨터의 전원을 끄는 것입니다. 최대 절전 모드 시 컴퓨터는 RAM(Random Access Memory)의 내용을 하드 디스크나 기타 비휘발성 저장소에 저장하며, 컴퓨터를 다시 시작하면 최대 절전 모드에 들어가기 전과 똑같은 상태가 됩니다. 컴퓨터에서 최대 절전 모드가 활성화되면 메모리 전체 덤프 내용이 포함된 최대 절전 모드 파일이 시스템 폴더 아래에 생성됩니다.

[Expert witness format]
EnCase 소프트웨어로 메모리를 획득할 때 사용하는 형식입니다. 이 형식은 EnCase 소프트웨어에서 사용하지만, 그 인기로 인해 표준화된 파일 형식 중 하나가 되었습니다. 이 파일 형식은 EnCase 소프트웨어에서 메모리 파일을 분석하기 위해 사용하는 파일 형식이므로 사용할 수 있는 도구는 몇 가지뿐입니다. 조사자는 다음과 같은 EWF 메모리 덤프 분석 방법을 숙지하고 있어야 합니다.
• EWFAddressSpace
• Mounting with EnCase
• Mounting with FTK Imager

[HPAK Format]
HPAK Format은 HBGary 소프트웨어에서 사용하는 파일 형식입니다. HPAK를 사용하면 대상 시스템의 물리적 메모리와 페이지 파일을 동일한 출력 파일에 포함할 수 있습니다. HPAK Format은 독점 형식이므로 HBGary 도구로만 생성할 수 있습니다.

 

[Windows] 메모리 덤프#01
[Windows] 메모리 덤프#02
[Windows] 메모리 덤프#03

반응형

VMware 주요 확장자에 대한 설명

.log – 가상 머신(Virtual Machine)에 대한 일반적인 활동 기록 파일

.vmdk – 게스트 운영체제(Guest OS)에 대한 실질적인 가상 하드 드라이브(Virtual Hard Drive)

.vmem – 게스트 운영체제에 대한 실질적인 가상 페이징 파일(Virtual Paging File)

.vmsn – VMware에서 생성하는 스냅샷(Snapshot) 파일로, 게스트 운영체제에 대한 상태 저장

.vmsd – VMware에서 생성한 스냅샷 파일에 대한 메타데이터(Metadata) 기록 파일

.nvram – 게스트 운영체제에 대한 바이오스(BIOS) 정보 기록 파일

.vmx – 게스트 운영체제에 대한 설정 기록 파일

.vmss – 게스트 운영체제를 일시 중지(Suspend) 상태로 변경할 경우, 당시의 게스트 운영체제 상태를 저장한 파일

 

VMware 가 가지고 있는 위와 같은 주요 확장자 파일들 중 메모리 덤프 파일은 .vmem 확장자를 가진 파일입니다. VMware 이미지에서 .vmem 확장자 파일을 추출하기 위해서는 현재 메모리 상태를 저장해야 됩니다. 실행 중인 이미지를 일시 중지(Suspend) 시키면 .vmem 파일이 생성되는데 해당 폴더에서 .vmem 파일을 복사하면 됩니다.

VMware 이미지는 메모리덤프를 위해 별도의 유틸리티가 필요 없네요.

반응형

[Windows] 메모리 덤프 형식(Memory Dump Format)
[Windows] 메모리 덤프#01
[Windows] 메모리 덤프#02
[Windows] 메모리 덤프#03

[Linux] 메모리 덤프(Memory Dump)#02
[Linux] 메모리 덤프(Memory Dump)#03

 

[Memory Dump 란?]

Memory Dump 는 System의 물리 Memory 를 File 형태로 저장하는 방법으로, 해당 File 의 구조는 실제 물리 Memory 구조와 동일합니다. 침해사고 분석 시 침해 시스템에 실시간 분석을 수행하면 해당 명령어로 인해 Memory 의 상태 및 Data 가 변경됩니다. 

 

이는 Memory 로부터 얻을 수 있는 중요한 정보를 놓칠 수 있는 가능성이 존재하므로 분석에 불리하게 작용할 수 있습니다. 이 같은 실시간 분석의 단점으로 인해 침해사고 시점의 휘발성 Data 를 File 로 간직하여 Memory 에 변화를 주지 않으면서 분석을 하기위해 Memory Dump 를 수행합니다. 

 

[Linux 에서 Memory Dump]

Linux는 운영체제의 모든 Resource 를 File 형태로 다룹니다. Linux 에서 Memory 접근은 장치 File 을 통해 이루어집니다.

 

과거에는 /dev/mem과 /dev/kmem 통해 직접적으로 리눅스 시스템에서 Memory 를 확보 할 수 있었으나, 보안상의 이유로 최신 커널에서는 이 액세스가 제한되거나 제거되었습니다. 하지만 fmem 이나 LiME(Linux Memory Extractor) 과 같은 프로젝트에서 로드 가능한 커널 모듈이 개발되어 Memory Dump 가 가능하게 되었습니다 . 

 

Linux 는 Kernel 과 함께 동작하는 많은 기능을 Module 의 형태로 제공합니다. 현재 Load 된 Module 을 확인하려면 lsmod 명령을 이용하면 됩니다. Module 은 insmod 명령으로 운영체제가 동작 중인 상태에서 쉽게 Load 할 수 있고, rmmod 로 쉽게 제거할 수 있습니다.

 

Kernel 은 Version 에 따라 구조가 달라질 수 있습니다. Kernel 은 운영체제의 핵심이므로 Kernel 동작을 방해하지 않으려면 Kernel Module 은 이러한 구조와 운영체제 환경에 잘 맞아야 합니다. Kernel 을 직접 다룰 수 있기 때문에 잘못하면 Kernel 의 기능을 오동작시키거나 정지시킬 수도 있습니다. 그래서 보통 Linux Kernel Module 은 Load 시킬 운영체제 환경에서 직접 Compile 합니다.

 

[LiME]

LiME 은 Joe Sylve 가 만든 툴이며 리눅스뿐만 아니라 안드로이드와 같은 리눅스 기반 디바이스의 Memory 를 덤프 할 수 있습니다. 안드로이드의 Memory 를 처음으로 Full Dump 를 한 도구이며 TCP 를 통해서도 Memory 를 덤프할 수 있습니다. Memory 를 획득하는 과정에서 Kernel 과 User 간의 상호작용을 최소화하여 획득 도구에 의한 Memory 의 훼손을 최소화 시켰습니다. LiME 은 다음의 웹페이지 (https://github.com/504ensicsLabs/LiME) 에서 다운로드 할 수 있습니다.

 

LiME 은 바이너리없이 소스로 배포되므로 직접 Compile 해야합니다. 먼저 미리 Compile 된 LKM 이 있는지 확인하거나 가상 컴퓨터에서 컴파일 및 테스트를 먼저 수행하는 것이 좋습니다. LiME 이 미리 Compile 한 LKM 를 확인할 수 있는 평판이 좋은 사이트 중 하나는 Cert.org 의 Linux Forensics Tools Repository(https://forensics.cert.org/) 입니다. Red Hat Enterprise Linux, CentOS 및 Fedora 를 위한 사이버포렌식 도구의 RPM 정보를 제공합니다.

 

:: 장점 ::

  • LKM 에 컴파일 된 LiME 은 크기가 작습니다.
  • 프로세스를 다시 시작할 필요가 없습니다.
  • LKM 에 신속하게 추가/제거 할 수 있습니다.
  • Memory Dump 를 로컬 디스크에 쓰지 않고 네트워크를 통해 전송할 수 있습니다.
  • Memory Dump 는 Volatility 와 호환됩니다.

 

:: 단점 ::

  • 실행파일이 아닌 컴파일방식으로 Memory Dump 를 수행하는 부분은 시스템이 변조되기 때문에 무결성이 손실될 수 있습니다.

 

[사용방법]

LiME 을 다운로드하고 컴파일을 합니다.

make 전에는 리눅스 개발 환경에서 컴파일, 링크, 빌드 등에 필요한 필수적인 도구들을 모아놓은 build-essential 패키지가 설치 되어있어야 합니다.

[root@vmtest ~]# apt-get install build-essential

 

폴더를 만들고 LiME을 다운로드해 압축을 해제하고 빌드합니다.

[root@vmtest ~]# mkdir lime; cd lime
[root@vmtest lime]# wget https://github.com/504ensicsLabs/LiME/archive/master.zip
[root@vmtest lime]# unzip master.zip 
[root@vmtest lime]# cd LiME-master
[root@vmtest lime]# cd src 
[root@vmtest src]# make
….
make -C /lib/modules/2.6.32-431.5.1.el6.x86_64/build M=/root/lime/src modules

[root@vmtest src]# ls lime*.ko
lime-2.6.32-431.5.1.el6.x86_64.ko

 

방법1. 로컬 시스템에 Memory 를 추출합니다.

추출된 결과파일을 저장할 경로와 이름, 파일형식을 지정해줍니다.

[root@vmtest ~]# insmod lime-2.6.32-431.5.1.el6.x86_64.ko "path=/tmp/mem.img format=raw"

"File exists"에러가 발생하면 "rmmod lime"을 입력하여 모듈을 언로드 후 다시 실행하면 동작합니다.

 

:: 옵션 ::

path 를 이용하여 물리 메모리 이미지를 파일로 저장할 수 있으며 또한 원격지 서버로 전송할 수 있습니다. 

ex. 파일경로와 파일이름 혹은 tcp:<port>

format 은 메모리 이미지의 포맷을 결정하는 옵션입니다. 

ex. raw : RAW 포맷 이미지, lime : LiME 포맷 이미지

 

방법2-1. 원격 시스템에 Memory 를 추출합니다.

LiME의 가장 큰 장점은 로컬 디스크 또는 실제 파일에 대한 출력에만 국한되지 않는다는 것입니다. 로컬 시스템에 path=/tmp/mem.img 와 같이 출력 경로를 지정하는것 대신 path=tcp:4444 와 같이 TCP 서비스를 작성합니다.

[root@vmtest ~]# insmod lime-2.6.32-431.5.1.el6.x86_64.ko "path=tcp:4444 format=lime"

 

그리고 netcat을 사용하여 원격 시스템에 연결하여 메모리 이미지를 조사용 랩톱으로 전송할 수 있습니다. 

[User@laptop ~]# nc target.server.com 4444 > /tmp/mem.img

 

방법2-2. 원격 시스템에 Memory 를 추출합니다.

조사용 랩톱에서 netcat 을 이용해 포트 80 포트를 오픈합니다.

[User@laptop ~]# nc –l 80 > /tmp/mem.img

 

원격 시스템에 LiME LKM을 실행하고 포트 4444에서 TCP 연결을 대기하도록 구성합니다.

[root@vmtest ~]# insmod lime-2.6.32-431.5.1.el6.x86_64.ko "path=tcp:4444 format=lime"

 

원격 시스템의 다른 셸에서 netcat 을 이용하여 조사용 랩톱 (60.70.80.90은 랩톱 IP 주소)의 80 포트로  메모리 이미지를 전송합니다.

[root@vmtest ~]# nc localhost 4444 | nc 60.70.80.90 80

 

Memory Dump 정보를 확인합니다.

[root@vmtest ~]# ls -lah /tmp/mem.img 
-r--r--r--. 1 root root 1.0G Mar 9 08:11 /tmp/mem.img
[root@vmtest ~]# strings /tmp/mem.img | head -n 3
EMiL
root (hd0,0)
kernel /vmlinuz-2.6.32-431.5.1.el6.x86_64 ro root=/dev/mapper/vg_livecd-lv_root rd_NO_LUKS 

 

Memory Dump 가 완료되었으면 커널 모듈을 제거합니다.

[root@vmtest ~]# rmmod lime

 

Memory Dump 분석 전 복사본을 생성하여 분석작업을 진행하도록 합니다. 이때 빠지지않고 해야되는 중요한 것은 해시값을 계산하는 것입니다. md5sum 이나 shasum 을 사용해서 해시값을 계산하면 됩니다.

[root@vmtest ~]# md5sum mem.img
db5fd6e1dabb055f8bc77fd67d95b588 mem.img


[root@vmtest ~]# sha1sum mem.img
0a67af1d5fdc59bf42f4ae93d97580135786fe3c mem.img


[root@vmtest ~]# sha256sum mem.img
63e5814134a140691b452ac6e353bab73458263709da4cebd2fd6484d33b8954 mem.img

 

이렇게 얻은 Memory Dump 파일은 Volatility 등의 분석툴을 사용하여 분석할 수 있습니다.

 

 

[별첨]

LiME Github에서 2020년 8월 26일 이후 더 이상 유지 관리되고 있지 않다고 해서 우분투 24.04에서 테스트 해봤습니다.

[root@vmtest ~]# uname -a
Linux swordfish 6.11.0-25-generic #25~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 15 17:20:50 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

 

경고가 뜨긴 하지만 커널 모듈 빌드는 완료됩니다.

[root@vmtest src]# make
make -C /lib/modules/6.11.0-25-generic/build M="/root/lime/LiME-master/src" modules
make[1]: Entering directory '/usr/src/linux-headers-6.11.0-25-generic'
warning: the compiler differs from the one used to build the kernel
  The kernel was built by: x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
  You are using:           gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
  CC [M]  /root/lime/LiME-master/src/disk.o
/root/lime/LiME-master/src/disk.c:45:5: warning: no previous prototype for ‘setup_disk’ [-Wmissing-prototypes]
   45 | int setup_disk(char *path, int dio) {
      |     ^~~~~~~~~~
/root/lime/LiME-master/src/disk.c:77:6: warning: no previous prototype for ‘cleanup_disk’ [-Wmissing-prototypes]
   77 | void cleanup_disk(void) {
      |      ^~~~~~~~~~~~
  CC [M]  /root/lime/LiME-master/src/hash.o
/root/lime/LiME-master/src/hash.c:53:5: warning: no previous prototype for ‘ldigest_init’ [-Wmissing-prototypes]
   53 | int ldigest_init(void) {
      |     ^~~~~~~~~~~~
/root/lime/LiME-master/src/hash.c:97:5: warning: no previous prototype for ‘ldigest_update’ [-Wmissing-prototypes]
   97 | int ldigest_update(void *v, size_t is) {
      |     ^~~~~~~~~~~~~~
/root/lime/LiME-master/src/hash.c:142:5: warning: no previous prototype for ‘ldigest_final’ [-Wmissing-prototypes]
  142 | int ldigest_final(void) {
      |     ^~~~~~~~~~~~~
/root/lime/LiME-master/src/hash.c:172:5: warning: no previous prototype for ‘ldigest_write_tcp’ [-Wmissing-prototypes]
  172 | int ldigest_write_tcp(void) {
      |     ^~~~~~~~~~~~~~~~~
/root/lime/LiME-master/src/hash.c:189:5: warning: no previous prototype for ‘ldigest_write_disk’ [-Wmissing-prototypes]
  189 | int ldigest_write_disk(void) {
      |     ^~~~~~~~~~~~~~~~~~
/root/lime/LiME-master/src/hash.c:215:6: warning: no previous prototype for ‘ldigest_clean’ [-Wmissing-prototypes]
  215 | void ldigest_clean(void) {
      |      ^~~~~~~~~~~~~
  LD [M]  /root/lime/LiME-master/src/lime.o
  MODPOST /root/lime/LiME-master/src/Module.symvers
  CC [M]  /root/lime/LiME-master/src/lime.mod.o
  LD [M]  /root/lime/LiME-master/src/lime.ko
  BTF [M] /root/lime/LiME-master/src/lime.ko
Skipping BTF generation for /root/lime/LiME-master/src/lime.ko due to unavailability of vmlinux
make[1]: Leaving directory '/usr/src/linux-headers-6.11.0-25-generic'
strip --strip-unneeded lime.ko
mv lime.ko lime-6.11.0-25-generic.ko

 

경고를 해결해 보겠습니다.

lime.h에 아래 선언들을 추가하세요

[root@vmtest src]# vi lime.c
...
#ifndef _LIME_DISK_H
#define _LIME_DISK_H

#include <linux/types.h>

int setup_disk(char *path, int dio);
void cleanup_disk(void);
ssize_t write_vaddr_disk(void *v, size_t is);

#endif

// hash
int ldigest_init(void);
int ldigest_update(void *v, size_t is);
int ldigest_final(void);
int ldigest_write_tcp(void);
int ldigest_write_disk(void);
void ldigest_clean(void);

// deflate
int deflate_begin_stream(void *out, size_t outlen);
int deflate_end_stream(void);
ssize_t deflate(const void *in, size_t inlen);
...

 

다음 줄을 main.c에서 수정하세요.

extern int ldigest_clean(void); // 수정 전
extern void ldigest_clean(void); // 수정 후

[root@vmtest src]# vi main.c
...
extern void ldigest_clean(void);
...

 

build.sh을 별도로 만드세요.

[root@vmtest src]# vi build.sh
#!/bin/bash

# build
make -C /lib/modules/$(uname -r)/build M="$(pwd)" CC=x86_64-linux-gnu-gcc-13 modules

# processing
if [ -f lime.ko ]; then
  strip --strip-unneeded lime.ko
  mv lime.ko lime-$(uname -r).ko
  echo "Done: lime-$(uname -r).ko created"
else
  echo "Error: lime.ko not found"
fi

[root@vmtest src]# chmod +x build.sh
[root@vmtest src]# ./build.sh
make: Entering directory '/usr/src/linux-headers-6.11.0-25-generic'
  LD [M]  /root/lime/LiME-master/src/lime.ko
  BTF [M] /root/lime/LiME-master/src/lime.ko
Skipping BTF generation for /root/lime/LiME-master/src/lime.ko due to unavailability of vmlinux
make: Leaving directory '/usr/src/linux-headers-6.11.0-25-generic'
Done: lime-6.11.0-25-generic.ko created

 

정상적으로 메모리가 덤프됩니다.(2025.05.20)

[root@vmtest src]# insmod lime-6.11.0-25-generic.ko "path=/tmp/mem.img format=raw"
[root@vmtest src]# ls -la /tmp/mem.img
-r--r--r-- 1 root root 4294367232 May 20 23:35 /tmp/mem.img

 

 

반응형

+ Recent posts