Yum_Yum

[Digital Forensic] 볼륨과 파티션

파일 시스템이 위치하는 볼륨과 파티션 구조를 모르고서는 파일 시스템을 정확히 분석해낼 수 없다.

대부분 파티션과 볼륨을 혼용하여 사용하는데 정확히 구분하면 이는 잘못된 사용이다.

(1) 볼륨

• 운영체제나 응용 프로그램이 데이터를 저장해 사용하도록 주소가 지정된 섹터들의 집합

• 섹터들이 연속적이지 않다라는 뜻을 가짐

볼륨은 다음과 같이 두 가지 개념을 가진다.

• 여러 개의 저장 볼륨에서 한 개의 저장 볼륨으로 조합하는 것 (더 작은 볼륨들로 나뉘거나 더 큰 볼륨으로 합쳐질 수 있음)

• 저장 볼륨들을 독립적인 파티션들로 분할하는 것

Windows와 Unix의 볼륨 사용 차이

• Windows 경우 C, D와 같은 드라이브 문자가 있으나, Unix의 경우 이러한 문자들이 없음

• Unix는 / 로 시작하는 루트 디렉토리가 존재하며, 하위에 다른 디렉토리나 볼륨 위치

볼륨 분석은 조사관이 수행한다기 보다는 도구에 의해 일반적으로 진행된다.

분석 기술은 의외로 간단하며, 분석 도구들의 분석 방법을 살펴보면 대부분 파티션 테이블의 위치를 확인하고 그 값을 읽어 그 정보를 출력하여 준다.

테이블에는 파티션 시작, 마지막 섹터 값, 파티션 유형 등의 정보가 들어 있으며 이 정보를 토대로 파티션 시스템(이미지)에서 각 볼륨들을 파악한다.

그리고 일관성 검사라는 것이 있는데 이 검사는 파티션을 제외한 영역에 증거가 존재하는지 조사하는 기능이다.

조사관은 파티션 테이블을 확인하여 파티션의 시작과 마지막 섹터를 확인하고 각 파티션들을 목록화하여 파티션 사이에 할당되지 않은 섹터가 있는지 확인하여 그곳에 증거가 없는지 분석하여야 한다.

위 그림은 DOS 파티션 내부 파일 시스템 파티션을 보기 쉽게 그림으로 표현한 것이다.

이러한 정보들로 파티션 내부의 파일 시스템 파티션을 추출할 수 있으며 도구로는 dd를 사용할 수 있다.

dd의 사용 방법은 다음과 같다.

dd if=<DOS 파티션 이미지> of=<추출 결과 저장 파일명> bs=<한번에 읽어 들일 블록 크기>  skip=<건너 뛸 길이> count=<길이>

위와 같이 파티션 내부 파일 시스템 파티션을 추출해도 되지만 요즘 도구들은 파티션과 파일 시스템 분석을 모두 하여 데이터까지 조사관에게 보여줘 특별한 경우가 아니라면 위와 같이 일일이 파일 시스템을 이미지에서 분리해내지 않아도 된다.

대표적으로는 AccessData의 FTK와 Guidance의 EnCase가 있다.

(2) 파티션

• 볼륨 색터들의 연속적인 것

• 일반적으로 파티션은 파티션 테이블이라는 것을 가짐

• 흔히 파티션을 구성할 때, 볼륨의 레이아웃을 구성하는 것을 말하는 데 레이아웃을 구성하기 위해서는 파티션 테이블 값이 절대적으로 필요

• 파티션 테이블이 잘못된 값을 갖는다면 볼륨 레이아웃은 정상적으로 작동하지 않음

• 파티션 테이블에도 부가적인 필드들이 존재하며, 필드들의 값은 볼륨 레이아웃 구성과 관련이 없어 값이 잘못되도 상관 없음

2-1. 도스 파티션

• 우리가 흔히 사용하는 컴퓨터 파티션 형식

• 자주 사용하고 흔히 접하는 도스 파티션은 정확한 명세가 제공되지 않음

• Microsoft는 이런 파티션 시스템을 MBR(Master Boot Record) 디스크라고 부름

• 도스 파티션은 도스, 윈도우, 리눅스 IA32 기반 FreeBSD와 OpenBSD 시스템에서 사용

• 흔한 시스템이지만 의외로 복잡한 구성을 가짐ㅁ

• 도스 파티션을 사용하는 Disk는 512Byte 섹터 내의 MBR을 갖고 있음

MBR에는 다음과 같은 정보가 있다.

1) 부트코드

2) 파티션 테이블

• 파티션 시작 CHS 주소

• 파티션 마지막 CHS 주소

• 파티션 시작 LBA 주소

• 파티션 섹터 수

• 파티션 타입

• 플래그

3) 시그니처

CHS(Cylinder, Head, Sector)는 8GB 이하 디스크에서만 사용이 가능하며, LBA는 TB(TeraByte) 크기의 디스크까지 사용 가능하다.

파티션 타입은 파일 시스템을 나타내는 것으로, Ext, NTFS, HFS+ 등이 있다.

운영체제들은 운영체제별로 파티션 타입이 다르며 리눅스는 파티션을 마운트할 때에 파티션 타입을 참조하지 않아 NTFS 파티션 타입이어도 리눅스 파티션 타입인 FAT으로 파티션을 마운트한다.

이와 달리 윈도우 경우 파티션 타입을 참조하여 NTFS 타입이 아니면 마운트하지 못한다.

위와 같은 방법으로 파티션을 숨길 수 있는 방법이 있다.

간단히 설명하자면, 파티션 타입에 1비트를 변조하여 윈도우에서 파티션을 인식하지 못하게 하는 것이다.

플래그는 파티션 부팅 여부를 나타내는 항목이며, 컴퓨터가 부팅할 때 운영체제가 어떤 파티션에 위치하고 있는지 구분할 때 사용된다.

MBR은 4개의 파티션만 표현할 수 있으며 4개의 엔트리를 이용하여 파티션들이 할당된 디스크 구조를 표현할 수 있다.

하지만 사용자에 따라 4개 이상의 파티션이 필요할 때가 있으며, 이러한 경우를 위해 확장 파티션 개념이 생겼다.

확장 파티션 개념은 3개의 파티션은 기본적인 파티션으로 두고 나머지 1개의 파티션을 확장 파티션으로 만들고 그 안에 또 다른 파티션들을 만드는 것이다.

예를 들어 12GB의 디스크에 6개 파티션을 구성하려고 하면 확장 파티션 개념으로 해야 할 것이다.

부 파티션 앞에 있는 MBR들은 위 [그림 3]과 같은 방법으로 모두 부 파티션과 부 확장 파티션을 갖게 된다.

부 파티션 1, 2를 만들고 부 확장 파티션 1을 만들게 되며 대부분의 OS에서는 세 번째 파티션을 무시하게 되어 '부 확장 파티션1'이 인식이 되지 않는다. (크기를 잘못 인식하는 경우도 발생)

확장 파티션에는 파티션 테이블 엔트리에서 사용되는 특별한 타입들이 있는데 위와 같이 복잡한 구조가 된 것은 확장 파티션 타입이 여러 가지 종류가 있으며 파티션 사이를 구분하기 어렵기 때문이다.

부트 코드

• MBR 섹터 내에 1~446 바이트에 존재하며, 나머지는 파티션 테이블 엔트리

• MBR 파티션 테이블을 처리한 후 부팅 플래그가 있는 파티션을 찾고 부팅 가능한 파티션의 첫 번째 섹터를 찾은 후 운영체제 코드를 실행시킴

• 이 영역에 바이러스 침투 시, OS 부팅 시 바이러스도 함께 OS 부팅 시 매번 실행되는 것

• 부트코드를 수정하면 OS 멀티 부팅이 가능

MBR

• 512 Byte 크기의 구조체를 사용

• 첫 446Byte는 어셈블리 부트 코드를 위해 예약이 되어 있음

MBR은 다음 표와 같은 내용들을 담고 있다.

MBR은 기본적으로 4개의 파티션을 파티션 테이블 엔트리(16Byte)로 표현할 수 있어 파티션 테이블 엔트리가 4개이다.

각 파티션 레이아웃을 구성하는 파티션 테이블 엔트리의 구조는 다음과 같다.

부팅 플래그는 반드시 필요한 것은 아니다.

하나의 운영체제가 설치되어 있는 시스템(부팅 플래그 default : 0x80)이라면 부팅 플래그가 필요해지며, 여러 운영체제를 멀티 부팅하는 시스템이라면 사용자가 OS 부팅을 선택하기 때문에 이러한 경우에는 부팅 플래그가 필요 없다.

위 표에서 CHS 항목 두 가지가 있는데 이 항목들은 최신 시스템에서는 필수적이지 않다.

파티션 타입은 파일 시스템 타입을 구분짓기 위해 필요한 항목이다.

주요 파티션 타입 목록은 다음 표와 같다.

확장 파티션 MBR 또한 위 MBR의 구조와 다를 바가 없으나 시작 섹터의 주소가 디스크 특정 지점의 상대적 주소이기 때문에 파티션 테이블 엔트리가 조금 다르다.

• 부 파일 시스템 엔트리 시작 주소는 현태 파티션 테이블 주소에서 상대적 주소

• 부 확장 파티션 엔트리 시작 주소는 주 확장 파티션에서 상대적

요즘은 디스크 레이아웃을 분석해 주는 도구들이 많이 개발되어 있어 조사관들이 사건 조사하기 편하게 해주기는 하지만 도스 파티션 경우 흔하게 접할 수 있는 파티션 시스템이므로 도스 파티션애 대해서는 필히 알고 있어야 한다.

2-2. 애플 파티션

• 도스 파티션보다 적게 사용되지만 사용자가 증가하고 있는 추세이며 여러 장비들에 애플 파티션이 적용

• 매킨토시 시스템에는 파티션 맵이라고 하는 이미지가 있는데 이것은 매킨토시 시스템이 파일들을 전송하기 위해 사용하는 디스크 이미지

• 파티션 맵 이미지 디스크는 윈도우 zip 파일, 유닉스 tar 파일과 유사한 형태

• 파티션 맵은 데이터 영역 위치, 부트 코드 위치 등의 데이터를 가짐

[그림 4]에서 보는 것처럼 파티션 맵은 첫 번째 엔트리가 자신의 엔트리이고 나머지 엔트리가 파티션 엔트리이다.

파티션 맵에서 파티션 맵 엔트리는 파티션 맵의 최대 크기를 나타낸다.

파티션 맵은 MBR과 동일하게 512Byte 크기이며, 여러 구조체로 구성되고 두 번째 섹터에서 시작한다.

또 모든 파티션을 배치할 때까지 구조체를 계속 할당한다.

파티션 데이터 구조체들은 연속적인 섹터들 내에 구성되며, 각 맵 엔트리는 전체 파티션 수를 나타낸다.

다음은 애플 파티션 맵 엔트리 오프셋 구조이다.

위 표의 데이터 구조체 항목들 중 파티션 상태 영역이 있는데 이 필드는 다음 표의 목록들 중 하나의 값을 가진다.

조사할 때 파티션 맵은 두 번째 섹터에서 시작하므로 애플 디스크의 파티션들을 구분하려면 두 번째 섹터에서 파티션 맵의 데이터 구조체들을 통해 정보를 수집해야 한다.

애플 디스크의 파티션들을 분석할 경우 고려해야 할 사항으로는 파티션 맵의 구조체 데이터들 중 사용되지 않는 필드들이 있어 적은 양의 데이터가 사용되지 않는 필드에 숨겨질 수 있다.

또 파티션 데이터 구조체와 파티션 맵 끝 사이 섹터에 데이터가 숨겨질 수도 있다.

2-3. BSD 파티션

• 컴퓨터 포렌식 조사 대상에는 BSD 시스템들이 많이 속함 (리눅스도 마찬가지)

• IA32 기반 하드웨어(x86/i386)를 사용하며 자체 분할 시스템을 사용

• IA32 기반 하드웨어를 사용하기 때문에 MS 제품들과 같은 디스크에 공존할 수 있도록 설계됨

• 도스 파티션보다 간단하기 때문에 이해하는 데 매우 쉬움

• 단점으로 애플 파티션 맵보다는 약간의 한계점을 가짐

• 도스 파티션과 공존할 수 있기 때문에 도스 파티션에서 생성한 볼륨에 위치할 수 있음

• 즉 '주 도스 파티션'이 될 수 있음

BSD 파티션의 핵심은 디스크 레이블(Disk Label)이다.

최소 크기는 276Byte이며 BSD 파티션 두 번째 섹터에 위치한다.

일부 IA32가 아닌 시스템들은 첫 번째 섹터에 위치하기도 한다.

디스크 레이블의 구조체들은 디스크 하드웨어 명세서를 포함하고, 8개 또는 16개의 BSD 파티션 테이블을 포함한다.

애플 파티션 맵과 다르게 BSD 파티션 테이블은 크기가 고정적이다.

BSD 파티션 테이블의 엔트리 항목들은 다음과 같다.

• BSD 파티션 시작 섹터 주소 : 도스 파티션이나 디스크 레이블에서의 상대적 주소가 아닌 디스크 시작 주소에서의 상대적 주소

• BSD 파티션 크기

• 파티션 타입 : BSD 파티션에 있는 파일 시스템 타입을 구분할 때 쓰이는 항목

• UFS 파일 시스템 조각 크기

• 블록당 UFS 파일 시스템 조각의 수

• UFS 실린더 그룹 당 실린더 개수 

마지막 3개 항목은 UFS 파일 시스템을 포함할 때만 사용된다.

BSD 파티션은 구조체 하나를 읽어서 전체 파티션 구조를 파악한다.

2-4. FreeBSD

• 하나의 디스크에서 도스 파티션과 BSD 파티션 둘 다 사용할 수 있도록 되어 있음

• FreeBSD에서 도스 파티션은 '슬라이스'라는 용어로 불리며, BSD 파티션은 '파티션'으로 불림

• 디스크 레이블 구조체는 FreeBSD 도스 파티션에 있으며, 그 구조체는 도스 파티션 내 존재하는 BSD 파티션 레이아웃을 구성하는데 쓰임

• FreeBSD는 각 파티션과 슬라이스에 특별한 장치 이름을 부여하는데 슬라이스의 경우 디스크 기본 이름에 's'와 번호를 부여

• 파티션의 경우 슬라이스 이름에 알파벳으로 순서를 매김

파티션의 경우 이름을 줄일 수도 있는데 다음 그림과 같다.

BSD 파티션은 이름에 따라 특별한 의미를 갖게 되는데 'a' 라는 이름을 할당 받은 파티션의 경우 보통 부트 코드가 위치하고 있는 파티션이 된다.

'b' 이름을 할당 받은 파티션은 보통 스왑 공간을 나타내며, 'c' 이름을 할당 받은 파티션은 보통 전체 슬라이스를 나타내고, 'd' 이름을 할당 받은 파티션은 보통 어떠한 파티션도 될 수 있는 파티션을 나타낸다.

하지만 이 이름 부여 원칙은 절대적이 아니며 수정이 가능하다.

2-5. OpenBSD (NetBSD)

• 원래 OpenBSD 코드와 NetBSD 코드는 함께 있었지만 지금은 따로 분리 됨 (같은 구조라고 보면 됨)

• OpenBSD에서는 도스 파티션이 단지 OpenBSD 파티션의 시작 부분을 확인시켜 주기 위해서만 사용되기 때문에 OpenBSD 커널이 적재되어 실행되면 도스 파티션은 무시

• 이름 할당 방법은 FreeBSD와 동일하지만, 슬라이스 개념은 없음

• BSD 시스템 부트 코드는 첫 번째 섹터에 위치 (항상 이런 것은 아님)

BSD 파티션에서 디스크 구조 정보를 가지고 있는 디스크 레이블의 구조는 다음 표와 같다.

BSD 파티션 레이아웃 오프셋 구조는 다음과 같다.

파일 시스템 타입은 BSD 파티션이 위치한 파일 시스템의 타입값을 가지며 목록은 다음과 같다.

FreeBSD와 OpenBSD 파일 시스템은 4.2BSD FFS(타입값:7)이며, 적어도 해당 시스템에서 Swap 파티션은 하나 이상 있어야 한다.

2-6. 솔라리스 파티션

• 솔라리스 운영체제는 대용량 서버와 데스크탑용으로 나누어져 있지만 대부분 대용량 서버에서 많이 사용하는 운영체제

• 그렇기 때문에 침해사고 조사 시 솔라리스 운영체제를 많이 볼 수 있어 파티션에 대한 이해 필요

• 솔라리스 모든 버전들은 BSD 디스크 레이블과 비슷한 구조 사용

• Sparc 솔라리스와 i386 솔라리스로 나뉘며, 두 종류의 파티션 데이터 구조 역시 다름

솔라리스에서는 각 파티션을 지칭하는 용어로 '슬라이스'를 사용한다.

솔라리스 설치 시에 디스크에 디스크 레이블을 솔라리스가 생성하게 되며, 정확히 설치되는 위치는 하드웨어 플랫폼에 따라 다르며, 생성되는 디스크 레이블에는 파티션 최대 개수 정보가 들어 있다.

디스크 레이블은 Sparc 시스템의 경우 최대 개수 8개, i386 시스템의 경우 16개이며, 각 파티션은 다음과 같은 항목들을 가진다.

• 파티션 시작 위치

• 파티션 크기

• 플래그 세트

• 플래그 세트 크기

• 파티션 타입

플래그의 경우 파티션이 읽기 전용인지 스왑(Swap) 공간처럼 마운트가 불가능한지 판단하게 해 주는 항목이다.

파티션 타입 항목은 다른 시스템 파티션과 다르게 파티션 파일 시스템 타입을 설명하는 항목이 아닌 파티션 마운트 지점을 설명하는 항목이다.

솔라리스 파티션의 경우 이름 할당 방법이 다른 시스템 파티션들과는 조금 다르다.

다음과 같은 규칙을 적용하여 이름을 할당한다.

Sparc 시스템

• Sparc 시스템 디스크 레이블 구조체는 디스크 1번째 섹터에 생성

• 2번째 섹터부터 16번째 섹터까지는 부트 코드가 위치하는 부트 블록

• 부트 블록 바로 다음 섹터부터는 파일 시스템 등을 저장하는 파티션 영역

다음은 기본적인 Sparc 시스템의 디스크 레이아웃이다.

Sparc 디스크 레이블은 파티션 모든 정보를 직접적으로 담고 있지는 않으며 두 개의 구조체에 파티션 정보를 나누어 저장한다.

sparc VTOC(Volume Table Of Contents)라는 구조체와 파티션 디스크 맵이라는 구조체로 나뉘어 저장된다.

먼저 디스크 테이블의 항목들로부터 살펴 보면 다음 표와 같다.

파티션 정보를 저장하는 VTOC 구조체는 다음 표와 같다.

뭔가 많아 보이지만, 결국 담고 있는 정보는 파티션 개수와 파티션 타입, 플래그, 부트 정보, 시그니처, 파티션 타임스탬프이다.

파티션 타입에는 다음과 같은 값들이 저장된다.

또 파티션 플래그 값에는 두 가지 값이 있는데 값과 설명은 다음과 같다.

• 1 : 파티션이 마운트 되지 않음을 뜻함

• 128 : 읽기 전용 파티션을 뜻함

이번에는 디스크 맵 구조체 구조이다.

위와 같이 디스크 맵 구조체는 간단한 구조이다.

하지만 위 구조로 봐서는 시작 위치를 정확히 알 수 없기 때문에 섹터로 변환하는 작업이 필요하다.

실린더 주소는 디스크 내 각 플래터 주소 트랙들의 집합이다.

실린더를 섹터로 변환하는 계산식은 다음과 같다.

트랙 당 섹터 수 x 헤드 수 x 실린더 = 실린더 당 섹터 수

트랙당 섹터 수(438 ~ 439)와 헤드 개수(434 ~ 437)는 VTOC 구조체와 디스크 맵을 포함하고 있는 디스크 레이블에서 확인할 수 있다.

i386 시스템

• 해당 시스템을 디스크으 셀치할 때는 하나 이상 도스 파티션이 생성되어야 함

• 일반적으로 도스 파티션 타입 부트 파티션 1개와, 파일 시스템을 사용하는 도스 파티션 타입의 파티션이 생성되어야 함

• 부트 파티션은 당연히 시스템 시작에 필요한 부트 코드를 포함하고 있어야 함

해당 시스템 디스크 레이블은 도스 파티션 타입 파일 시스템 2번째 섹터에 위치하며, 디스크 레이블이 위치한 파티션의 i386 파티션들을 설명한다.

i386 파티션은 반드시 도스 파티션 시작 이후에 시작해야 하며, i386 시스템은 리틀 엔디안 방식을 사용한다.

i386 시스템의 디스크 레이블은 512바이트 크기이며, 모든 파티션 정보가 Sparc 시스템과 달리 디스크 레이블 한 곳에 모여있고 CHS 주소를 사용하여 정보를 저장한다.

다음은 i386 시스템의 디스크 레이블 구조체의 구조이다.

위 표를 보면 디스크 레이블에는 16개의 파티션 엔트리가 있는데 이 파티션 엔트리들의 구조는 다음 표와 같다.

i386 시스템에서의 파티션 타입과 플래그의 값들은 Sparc 시스템과 동일하다.

i386 시스템의 파티션을 확인하기 위해서는 디스크 레이블의 VTOC 부분을 참고해야 하며 해당 파티션 레이아웃은 파티션 엔트리를 참고하면 된다.

GPT 파티션

• 대부분 고성능 서버에서 쓰임

• IA64 시스템들은 IA32 시스템처럼 BIOS가 있지 않아 EFI(Extensible Firmware Interface) 시스템을 사용

GPT 파티션을 사용하는 디스크 기본 구조는 다음과 같다.

1)보호용 MBR

• 하나의 엔트리 만을 가진 파티션 테이블을 포함한 도스 파티션이 위치해 있으며 해당 엔트리는 EFI GPT 디스크를 위한 것

• 해당 파티션은 과거 컴퓨터 디스크를 재구성하기 위해 존재

2) GPT 헤더

• 위 그림처럼 두 번째 섹터에 위치

• GPT 디스크가 생성될 때 고정된 파티션 테이블 위치와 크기를 정의하는 항목 등이 포함

3) 파티션 테이블

• 여러 개의 엔트리가 있으며 해당 엔트리들은 파티션 영역의 파티션들의 타입 등을 정의하는 항목들을 포함

• 윈도우의 경우 GPT 헤더 다음 위치하는 파티션 테이블에 포함되는 엔트리 갯수를 128개로 제한함

4) 파티션 영역

• GPT 디스크 중에서 가장 큰 공간이며, 파티션 할당에 필요한 섹터들을 포함

• 파티션과 파티션 영역을 혼동하여서는 안 됨

• 이 영역은 GPT 헤더에 의해 정의

5) 백업 영역

• 해당 영역은 파티션에 문제가 발생하였을 경우를 대비하여 GPT 헤더와 파티션 테이블을 복사한 복사본이 존재

GPT 헤더의 오프셋 구조는 다음과 같다.

GPT 파티션은 위 표의 오프셋 구조들을 이용하여 디스크 전체 레이아웃을 정의한다.

다음 표는 GPT 헤더에서 정의한 파티션 테이블의 각 엔트리들이 오프셋 구조이다.

GUID는 128bit로 파티션 내용을 구분하는 데 사용된다.

인텔과 MS에서 정의한 GUID 값이 있는데 그 값들은 다음 표와 같다.

위 표가 인텔에서 정의한 GUID이고, 아래 표가 MS에서 정의한 GUID이다.

MS에서 정의한 파티션 중 예약 파티션은 임시 파일을 보관하기 위한 파티션이고 주 파티션은 우리가 알고 있는 하나의 파일 시스템을 사용하는 파티션이다.

해당 파티션을 지원한느 분석 도구는 아직까지 많지 않다.

하만 앞으로 64bit 시스템이 주를 이루어 사용하는 날이 얼마 남지 않아 해당 시스템에 대한 분석 도구의 지원이 절실할 때이다.

해당 시스템을 가지는 디스크를 분석할 때에는 다른 파티션들과 같이 비할당 영역의 데이터를 찾아 반드시 분석해야 한다.

# Reference 

http://www.yes24.com/Product/Goods/8511539

[Digital Forensic] 하드디스크와 데이터 수집

(1) 하드 디스크 구조

비휘발성의 보조 기억 장치라고 설명할 수 있는 하드 디스크의 일반적 구조는 다음과 같다.

1-1. Platter (플래터)

• 위 그림에 원판으로 된 부분이며, 데이터가 기록되는 부분

• 금속 재질로, 데이터를 기록하기 위해 산화철 등의 자성체로 양면 코딩

• 하드 디스크에는 한 개 또는 그 이상의 플래터들이 부착 가능

• 많이 부착되면 될수록 용량은 커지지만 안정성에 대한 문제 증가

1-2. Spindle (스핀들)

• 플래터의 회전을 담당하는 부분

• 초기에는 볼 베어링이 사용되었지만, 최근에는 동압 유체 베어링이 많이 사용

• 동압 유체 베어링은 완전한 원형 회전을 하게 하여 트랙 밀도를 높임

1-3. Actuator (액추에이터)

• Actuator Head가 데이터를 읽을 수 있도록 Actuator Arm을 움직이도록 하는 부분

• 구동을 위해 네오디뮴 자석을 사용하고, 누설 자속을 줄이기 위해 스테핑 모터를 사용 > 데이터 손실로 인해 헤드 파킹이 필요

• 요즘은 음성 코일 방식을 사용 > 전원이 차단되어도 스핀들 모터의 관성에 의해 헤드가 제자리로 돌아가 헤드파킹이 필요 없어짐

1-4. Head (헤드)

• 데이터를 읽고 쓰는 부분으로 플래터와의 간격이 마이크로미터 단위로 떨어져 데이터를 읽고 씀

• 만약 플래터와 맞부딪힌 상태에서 스핀들 모터가 구동되어 헤드가 플래터에 닿는 경우 데이터 손상

• 헤더 기록 방식에는 수직 기록 방식과 수평 기록 방식이 있음

수직 기록 방식 : 데이터를 수직으로 기록하여 수평 기록 방식에 비해 플래터 당 기록 밀도를 훨씬 높일 수 있고, 자성의 손실이 거의 없어 데이터 수명 또한 긺

수평 기록 방식 : 데이터를 수평으로 기록하여 자기장을 입히는 기록 도체를 수평으로 눕혀놓고 그 기록 도체에 자기장을 입혀 데이터를 기록하는 방식

(2) 하드 디스크 저장 방식

2-1. CHS 방식

• 실린더(Cylinder), 헤드(Head), 섹터(Sector) 세 가지 요소를 이용한 방식

• 물리적 주소 할당 방식

• 실린더, 헤드, 섹터에 번호를 할당해 그 주소를 이용해 데이터를 찾아 읽고 쓰는 방식

• 과거에 사용되었으며 용량이 커지는 현대 하드 디스크에 맞지 않는 한계를 보임

• 요즘에는 쓰이지 않으며, CHS가 지원하는 용량의 임베디드(embeded) 하드 디스크들은 아직 이 방식 사용

2-2. LBA 방식

• CHS 한계로 인해 고안된 방식

• 모든 섹터에 논리적 고유 번호를 할당하는 방식

2-3. ZBR (Zone Bit Recording)

• 요즘 사용하는 방식으로, 외부 트랙 길이가 내부 트랙 길이보다 길다는 점에서 착안하여 길이가 긴 트랙일수록 섹터를 많이 할당하도록 만드는 방식

• CHS와 LBA 경우에는 트랙의 섹터 수가 모두 동일

• ZBR은 트랙 길이마다 섹터 수가 다르기 때문에 데이터를 읽고 쓸 때 트랙에 섹터 수를 정확히 알고 있어야 함

(3) 하드 디스크 숨김 영역

• 사용자 임의적 설정을 통해 숨김 영역을 설정할 수 있고 하드 디스크 제조 공정에서 숨김 영역이 생성 되어 설정 된 상태로 판매 되어 일반 사용자가 사용할 수도 있음

• 악성코드나 하드 디스크에 대한 지식이 있는 사용자는 숨김 영역에 중요 데이터를 숨길 수 있음

• 분석 대상 시스템에서 조사관이 흔적을 찾을 때 분석 영역 중 고려해야 하는 영역 중 하나

• 하드 디스크 덤프 파일을 획득할 시에 하드 디스크 덤프 도구가 숨김 영역까지 덤프하는지 알아보고 사용해야 함

• 숨김 영역을 덤프하지 못한다면 중요 데이터를 놓칠 수 있기 때문

3-1. HPA (Host Protected Area)

• 데이터를 저장할 수 있는 영역이지만, 일반 사용자가 볼 수 없는 영역

• 숨겨진 영역이며, 설정은 ATA 명령으로 가능

• ATA-4에서 추가되었으며, 사용자가 하드 디스크를 포맷하거나 삭제했을 때도 데이터를 보존할 수 있는 영역

• 하드 디스크 끝에 위치하며, 하드 디스크 재설정에 의해서만 접근 가능

HPA는 다음과 같은 두 명령어 결과값 차이를 보고 존재 유무 파악이 가능하다.

1) READ_NATIVE_MAX_ADDRESS

• 물리적 주소 최대값을 반환하여 주는 명령어 (항상 이런 결과는 아님)

2) IDENTIFY_DEVICE

• 사용자 영역(HPA 영역 앞 부분) 끝을 반환하여 주는 명령어

HPA 영역 설정은 SET_MAX_ADDRESS 명령어를 통해 이루어지며, 이 명령어 기능은 사용자가 접근할 수 있는 최대 주소를 설정한다.

HPA 영역 제거는 READ_NATIVE_MAC_ADDRESS 결과를 SET_MAC_ADDRESS 입력 값으로 이용하면 된다.

HPA 제거할 때에는 완전 제거와 임시 제거가 있으며, 완전 제거는 말 그대로 완전 제거되는 것이고, 임시 제거는 SET_MAC_ADDRESS 명령어 설정을 휘발성 비트 설정으로 하여 하드 디스크가 재설정되거나 전원이 재공급된 이후에 HPA 영역이 다시 복구되게끔 한다.

3-2. DCO (Device Configuration Overlay)

• ATA-6에서 추가된 기능이며 HPA와 동일한 기능을 하는 영역

• 컴퓨터에서 어떠한 기능을 제공하는지 IDENTIFY_DEVICE 명령어를 통해 확인하는데 DCO 기능은 자신의 기능을 IDENTIFY_DEVICE 명령어 결과값에 추가하지 않아 기능이 존재하지 않는 것처럼 보임

• 지원 기능 목록 말고도 디스크 크기도 보여주는데 여기서 DCO 영역이 제외된 크기가 보여짐

• HPA 영역도 있을 시에 HPA 영역도 제외

명령어 중에 DEVICE_CONFIGURATION_IDENTIFY 명령어의 기능은 디스크 크기와 실제 명령어 목록을 반환하여 준다. 

위 명령어와 IDENTIFY_DEVICE 명령어를 비교하여 DCO 탐지가 가능하다.

또 READ_NATIVE_MAX_ADDRESS 결과와 DEVICE_CONFIGURATION_IDENTIFY 결과를 비교하여 DCO 영역을 찾아 낼 수 있다.

DCO 영역 생성은 DEVICE_CONFIGURATION_SET 명령어로 하며, 삭제는 DEVICE_CONFIGURATION_RESET 명령어로 할 수 있다.

만약 HPA 영역까지 존재한다면 디스크 논리적 구조와 각 명령어들이 출력하는 결과물들이 있는 곳은 다음과 같다.

포렌식 관점에서 보았을 때 이런 영역들은 상당히 성가시다.

혹여 유효 데이터가 해당 영역에 위치하고 있는데 해당 영역까지 디스크를 복사하지 않거나 분석하지 않으면 그 유효한 데이터를 얻지 못할 수도 있기 때문이다.

그래서 대부분 디스크 복제 도구나 장비들은 해당 영역이 있는지 파악한 후에 영역이 존재하면 해당 영역까지 복제를 시도한다.

(4) 데이터 수집

• 하드 디스크에서 데이터를 분석하기 위한 단계 중 이 데이터 수집 단계가 필수적

4-1. 컨트롤러의 직접 접근

• 하드 디스크 컨트롤러는 하드 디스크와 연결되어 있고 리본 케이블로 하드 디스크에 명령을 내림

• 소프트웨어는 하드 디스크 컨트롤러를 통해 디스크 데이터에 접근할 수 있으며, 이때 소프트웨어는 하드 디스크 컨트롤러의 주소 지정, 데이터를 읽고 쓰기 위한 명령어 등 세부적 사항을 모두 알고 있어야 함

• 속도면에서는 좋지만 소프트웨어 개발 시 부담이 많이 가는 접근법

4-2. 컨트롤러의 BIOS 접근

• BIOS를 통해 디스크 데이터에 접근하게 되면 컨트롤러 직접 접근법에서 알아야 했던 하드 디스크의 모든 세부 사항을 소프트웨어가 인식하고 있지 않아도 됨

• 소프트웨어는 BIOS 하드 디스크 서비스들을 사용하기 위해 섹터 주소와 섹터 크기 같은 데이터를 CPU 레지스터 내부로 적재하고, 소프트웨어 인터럽트 명령어 0x13(INT13h)을 실행하면 됨

INT13h : 데이터를 읽고 쓰고 하기 위한 질의들을 포함하는 명령어

원래 INT13h의 경우 CHS 방식에서 사용하던 명령어여서 8.1GB까지만 읽고 쓸 수 있어 LBA 방식에는 맞지 않아 '확장 INT13h'라는 것이 새로 추가되었다.

지금까지의 설명을 보면 소프트웨어 입장에서 BIOS를 통한 접근법이 좋아 보이지만, 조사관 입장에서는 시스템과 도구에 따라 다르게 보일 수 있다. 

이유는 다음과 같다.

접근법의 차이

• 결론부터 말하면 BIOS 접근법은 시스템과 도구에 따라 정확한 결과를 얻지 못할 수 있다.

BIOS에서 확장 INT13h를 사용하지 않고 기존 CHS 방식 INT13h를 사용한다면 위와 같은 현상이 발생한다.

소프트웨어가 BIOS를 통해 디스크 크기가 몇이냐고 명령을 내렸다면 대상은 10GB 디스크일 때 INT13h를 사용하는 BIOS일 경우 8.1GB로 인식하기 때문에 결과값을 8.1GB로 돌려줄 것이다.

만약 이 명령이 모든 디스크 데이터를 복사하라는 명령이었다면 10GB에서 8.1GB 크기 데이터만 복사해 올 것이다.

이렇게 되면 2GB 데이터를 수집하지 못하는 것이다.

직접 접근법의 경우 BIOS 상관 없이 LBA 형식 확장 INT13h를 사용해 디스크 크기를 정확하게 알아낼 수 있다.

위 그림과 같은 문제로 자신이 사용하는 도구가 어떤 접근법을 가지고 데이터를 수집하는지 파악해 놓고 있어야 하며, 만약 BIOS를 사용한다면 어떤 INT13h 명령어를 사용하는지 알아야 한다.

4-3. 동적 수집

• 분석 대상 시스템 운영체제가 동작한는 상태에서 데이터를 수집하는 것

• 이 방법은 매우 신뢰성이 떨어짐

• 악의적인 공격자나 루트킷 등에 의해 운영체제가 변조되었을 가능성이 있기 때문에 변조된 운영체제를 통해 수집된 데이터 또한 엉뚱한 데이터나 증거가 남아 있지 않을 수도 있기 때문 

4-4. 정적 수집

• 이동 장치로 부팅하여 분석 대상 시스템의 데이터를 수집하는 것을 말함

• 즉, 분석 대상 시스템 운영체제 도움 없이 시스템 데이터를 수집하는 것

• 신뢰성이 높은 이동 저장장치를 이용하여 부팅한 후 대상 시스템에서 데이터를 수집함

• 악의적인 공격자나 루트킷 등이 하드웨어를 변조했을 가능성도 있지만 운영체제 변조 가능성보다는 낮음

분석 대상 시스템의 디스크 섹터 중 불량 섹터가 존재하여 도구가 불량 섹터를 읽는 도중 오류가 발생하면 데이터 수집에 차질이 생길 수 있다.

모든 수집 도구는 이러한 상황을 대처할 줄 알아야 하며 일반적 방법으로는 불량 섹터를 0으로 덮어 버리는 것이다.

이렇게 함으로써 오류 발생 요인 제거와 불량 섹터 위치를 정확하게 판별할 수 있게 된다.

데이터 수집 시에는 유의 사항이 있으며, 바로 HPA 영역과 DCO 영역이다.

이 부분들을 탐지하지 못한다면 중요한 데이터를 얻지 못할 수도 있다.

그래서 HPA영역을 탐지하는데 도움을 주는 도구들이 존재하며, HPA 영역을 탐지할 수 있는 수집 도구는 다음과 같다.

• BXDR

• diskstat

• DRIVEID

• hpa

DCO 영역을 탐지하는 도구로는 Image MASSter Solo 2가 있다.

데이터 수집 시에 저장하는 영역은 디스크와 파일로 나뉠 수 있다.

하지만 디스크에 저장하는 방식에 문제점이 있어 요즘은 대부분 CD-ROM이나 이동 저장장치에 분석 대상 디스크를 파일로 저장한다.

(4) 데이터 쓰기 방지 장치

• 무결성은 증거 투명성을 보장하는 것으로 데이터 수집 시에 중요하게 여겨야 할 부분 중 하나

• 만약 디스크 데이터를 수집하거나 복제할 때 그 과정에서 원본 내용이 변경되면 무결성은 보장 받지 못함

• 그렇기 때문에 디지털 데이터를 수집할 때에는 쓰기 방지 장치라는 것을 사용함

• 디스크 데이터를 수집하거나 복제하는 데 사용하는 장비나 도구가 원본 디스크 데이터에 접근해 어떤 행위를 하던 도중 오류나 다른 원인으로 인해 원본 데이터를 손상시키는 일을 방지하기 위해 사용하는 장치

쓰기 방지 장치에는 하드웨어/소프트웨어 종류가 있으며, 이 두 종류 모두 원본 디스크 데이터와 디스크 데이터에 접근하는 장치 사이에 위치하여 입/출력을 제어한다.

하드웨어 쓰기 방지 장치의 경우는 [그림 5]에서 수집 도구와 디스크 사이에 쓰기 방지 장치가 위치한다고 생각하면 된다. (BIOS는 X)

하드웨어 쓰기 방지 장치는 대부분 연결 포트 인터페이스(SATA, IDE, Firewire, USB 등)를 지원하고, 장치 연결 후 동작 하기 전 먼저 숨김 영역인 HPA나 DCO를 제거하기 위해 제거에 관한 명령어들을 원본 디스크 데이터쪽으로 전송한다.

이러한 이유로 주로 소프트웨어 쓰기 방지 장치보다는 하드웨어 쓰기 방지 장치를 사용한다.

또 소프트웨어 쓰기 방지 장치는 [그림 5]에서 수집 도구와 BIOS 사이에 위치하여 BIOS 인터럽트 테이블에 INT13h 엔트리의 주소를 쓰기 방지 장치 주소로 수정해 운영체제에서 INT13h를 호출했을 때 쓰기 방지 장치가 호출되게 끔하여 작동한다.

대표적 쓰기 방지 장치는 다음과 같다.

1) 하드웨어 쓰기 방지 장치

• ICS Drive Lock

• Tableau Write Blockers 

• Wiebe Tech Write Blockers

2) 소프트웨어 쓰기 방지 장치

• SAFE Block XP

• MacForensicLab Write Controller

# Reference

http://www.yes24.com/Product/Goods/8511539

[Digital Forensic] 메모리 분석 (2)

(4) 프로세스

• 메모리 분석에서 제일 중요한 것은 프로세스를 찾는 것

• 특히 루트킷에 의해 숨겨진 프로세스를 찾는 것은 안티 루트킷 도구들과 메모리 분석으로 할 수 있는데, 안티 루트킷 도구를 사용하면 조사 환경에 어떠한 영향을 주기 때문에 포렌식 관점에서 메모리 분석보다 좋지 못한 방법 (무조건은 아님)

메모리에서 프로세스를 찾기 전에 프로세스가 어떻게 정보를 저장하고 어떻게 관리가 되는지부터 공부해야 한다.

윈도우에서는 EPROCESS라는 구조체로 프로세스의 모든 정보가 들어가 있다.

다음은 포렌식 관점에서 볼 때, 중요한 EPROCESS 구조체이다.

1) PCB (Process Control Block)

• DISPATCHER_HEADER, 디렉토리 테이블 주소, KTHREAD 목록, 우선 순위, 커널/유저 CPU 시간 등에 대한 정보를 가짐

2) CreateTime

• 프로세스가 종료된 시간 정보를 가짐

• 64bit 윈도우 시간 형식을 지님

3) ExitTime

• 프로세스가 시작된 시간 정보를 가짐

• 64bit 윈도우 시간 형식을 지님

4) UniqueProcessId

• 프로세스 ID 값을 가지고 있음

5) ActiveProcessLinks

• ActiveProcess List를 구성하는 이중 링크드 리스트

6) ObjectTable

• 오브젝트 핸들 테이블의 위치를 가리키는 포인터 값

7) WorkingSet Page

• 프로세스의 WorkingSetPage

• WorkingSet은 어떤 특수 프로세스 전용으로 할당된 물리적 메모리 페이지 그룹

8) PEB (Process Environment Block)

• 프로세스 실행에 필요한 정보들을 담고 있음

• BaseAddress, Module List, Heap/Stack 정보가 들어 있음

만약 메모리 덤프 파일에서 프로세스를 찾는다면 PCB와 ActiveProcessLinks 항목을 주로 이용할 것이며, 프로세스 정보를 찾는다면 나머지 필드들과 PEB 항목을 주로 이용할 것이다.

EPROCESS의 PCB 항목 데이터 타입을 보면 KPROCESS라고 되어 있는데 이 또한 구조체로서 EPROCESS의 하부 구조체이다.

KPROCESS는 프로세스의 스케줄링 관련 정보를 저장하고 있으며, KPROCESS 하부 구조체 중 DISPATCHER_HEADER라는 하부 구조체가 있는데 이 구조체는 프로세스들 사이의 동기화에 필요한 구조체이며 메모리 덤프에서 오브젝트를 찾을 때 중요한 역할을 한다.

커널 영역에 있는 또 다른 구조체인 ETHREAD, KTHREAD는 위 구조체들과 구조는 같으나 다루고 있는 대상이 스레드라는 점에서만 차이가 있다.

4-1. PEB

• EPROCESS의 하부 구조체 중 하나로, 프로세스의 환경 설정 값을 가짐

• 하지만 직접 값을 가지고 있지는 않으며, 사용자 영역에 있는 PEB에 대한 포인터 값만을 가짐

• 커널 영역에 속하는 PEB를 사용자 영역에 하나 더 두고 그것을 포인터 값으로 가지는 이유는 PEB에 저장되는 데이터는 사용자 모드로 접근하는 이미지 로더, 힙 매니저, 윈도우 시스템 DLL 파일이 필요로 하는 정보이기 때문

• 그렇기 때문에 커널 영역에 있으면 접근하지 못하므로 사용자 영역에 저장하는 것

4-2. ActiveProcessLink

• 환형 이중 링크드 리스트로 이루어짐

• 이 항목을 통해 프로세스의 목록을 얻을 수 있음

환형 이중 링크드 리스트 : 이중 링크드 리스트에 PsActiveProcessLink라는 커널 전역변수를 추가해 순환 구조를 만들어 준 것

PsActiveProcessLink : ActiveProcessLink와 같은 구조로 되어 있으며, 이 변수에 접근하려면 커널 프로세스 권한 필요

ActiveProcessLink : 작업 관리자를 열면 System(4)라는 프로세스를 볼 수 있는데 이 프로세스는 윈도우 커널을 의미하며, 언제나 ActiveProcessLink의 첫 번째 프로세스가 됨

4-3. DKOM (Direct Kernel Object Manipulation)

• 커널 오브젝트(EPROCESS)를 수정하여 프로세스를 숨기는 방법

• 정상적인 프로세스 환형 이중 링크드 리스트에서 숨기고자 하는 프로세스를 환형 이중 링크드 리스트에서 빼내는 것

• 일반적으로 ActiveProcessLink를 참조하여 프로세스 목록을 얻는 도구들은 숨겨진 프로세스를 찾을 수 있음

숨겨진 프로세스는 자신을 가리키도록 만드는데 이렇게 하는 이유는 숨겨진 프로세스에 의해 BSOD가 일어나지 않게 하기 위함이다.

커널이 프로세스를 관리하기 위해 참조하는 ActiveProcessLink에서 제외되면 커널의 관리를 받지 못하므로 프로세스가 종료되야 하는데 종료되지 않는 이유는 다음과 같다.

• 숨겨진 해당 프로세스가 점유하고 있는 자원이 회수되지 않고 메모리에 그대로 남아 있기 때문에 프로세스는 생존할 수 있는 것

• 윈도우는 프로세스 단위가 아닌 스레드 단위로 처리 기준을 정해 놓았기 때문에 프로세스가 종료되더라도 스레드만 살아있으면 얼마든지 어떠한 행위의 동작이 가능

4-4. 커널 오브젝트 검색 방법

1) 리스트 워킹

• 하나의 단서를 근거로 하여 목적지까지 거슬러 올라가는 방법

• 어떤 프로세스의 ActiveProcessLink를 알고 있다면 앞이나 뒤의 프로세스를 계속 찾다 보면 결국 다시 처음 출발하였던 곳으로 돌아올 것이고, 그 동안 거쳐왔던 프로세스를 나열하면 프로세스 목록이 얻어지는 것

• 하지만 DKOM 기법을 이용하면 이 검색 방법으로는 숨겨진 프로세스를 찾을 수 없음

2) 또 다른 리스트 워킹

• 명칭은 위와 같지만 다른 리스트 워킹 방법

• 이 기법은 EPROCESS가 아닌 또 다른 커널 구조체인 KPCR을 기초로 함

• KPCR은 XP, 2003에서 가상 주소 0xFFDFF000에 위치하며 KPCR의 확장 영역인 KPCRB는 같은 버전에서 0xFFDFF120에 위치

• KPCRB는 EPROCESS의 KTHREAD 구조체에 대한 포인터 값이 들어 있어 KPCRB를 통해 KTHREAD를 알면 EPROCESS의 위치도 알 수 있음

• 이 방법은 위 기존 리스트 워킹 방법과 마찬가지로 DKOM 기법이 적용된 프로세스는 찾지 못하며, Vista 이후 버전들의 KPCR 주소가 컴퓨터마다 달라 Vista 이후 버전에는 적용하기 힘듦

3) 패턴 매칭

• 리스트 워킹 한계 극복을 위해 개발된 기법

• 해당 방법의 기본 원리는 Windows의 프로세스와 스레드의 일정한 구조를 이용한 것

• 예로, 모든 커널 오브젝트는 OBJECT_HEADER라는 구조체를 공통적으로 가지고 있으며, 이를 이용해 메모리에서 오브젝트를 찾을 수 있음

(5) 메모리 분석

이전에는 메모리 분석이라고 하면 문자열 검색이나 파일 카빙 정도에 그쳤지만, 요즘은 메모리 연구가 계속 되어 메모리에서 추출할 수 있는 데이터와 그 방법들이 많아져 전문 도구까지 개발되어 사용자들에게 배포되었다.

파일 카빙 : 바이너리 데이터로부터 의미있는 데이터를 획득하는 기법으로 의미 있는 데이터를 선별해 추출한다는 것이 일반 추출과 구분지어 줌

5-1. volatility

• 해당 도구는 메모리 분석 툴로, 다양한 기능과 플러그인을 제공하는 CLI 도구이며, 파이썬 기반으로 만들어 짐

• 해당 도구에서 프로세스 목록을 얻는 방법은 pslist와 psscan이 있음 (pstree도 방법 중 하나)

• pslist와 psscan 옵션 결과는 덤프 이미지에 따라 다를 수 있으며, pslist는 리스트 워킹 방식을 사용하기 때문에 숨겨진 프로세스를 찾지 못하는 반면, psscan 옵션은 패턴 매칭 방식을 사용하여 숨겨진 프로세스까지 찾아 줌

• 속도면에서는 pslist가 더 빠르지만 결과물 면에서는 psscan이 더 좋음

• 네트워크 연결 정보는 connections, connscan 옵션을 사용하면 정보를 얻을 수 있음

그런데 connections와 connscan 옵션 결과가 다르게 나오기도 한다.

이유는 connections 옵션이 제대로 실행이 되지 않았기 때문이며, 윈도우 보안패치 때문이다.

해당 도구는 여러가지 플러그인을 추가할 수 있도록 되어 있고, 이 도구를 모듈로 또 다른 도구를 제작할 수도 있다.

실제로 외국 전문가들은 해당 도구 플러그인을 만들어 추가 후 사용하고 있기도 하고, 국내에서는 해당 도구 플러그인을 이용해 간단 스크립트를 만들어 작업을 자동화하기도 한다.

5-2. Redline

• Memoryze 도구의 업그레이드 버전으로 GUI 버전

• .net(닷넷) 프레임워크를 기반으로 제작되었으며, 포터블 형식으로 폴더만 외장장치로 복사하여 다른 시스템에사 사용할 수 있는 장점을 가짐

• 하지만 지원하지 못하는 이미지 버전 등이 있어 아직 모든 시스템에 적용할 수 있는 것은 아니며, 구동하려는 시스템에 .NET(닷넷) 프레임워크가 설치되어 있지 않다면 실행되지 않음

Redline은 4가지(Quick, Standard, Full, Custom) 분석 모드를 지원하고 있고, MRI core 리포트부터 여러 가지 리포트를 보여준다.

프로세스 목록은 물론 핸들, 실행 명령어, 네트워크 연결 정보, 후킹, 드라이버 목록 등의 정보를 보여준다.

해당 도구는 프로세스 별로 핸들, 네트워크 정보 등을 볼 수 있도록 되어 있어 편리하다.

메모리에서는 유효한 데이터를 얼마든지 찾을 수 있으며, 암호화가 되지 않은 채로 저장되어 충분히 유효한 데이터를 찾을 수 있다.

이런 이유로 침해사고가 발생했을 시에 휘발성 정보 수집도 중요하지만 메모리 덤프 파일을 획득하는 것도 중요하다.

메모리 덤프를 수행하였을 때 데이터가 얼마나 남아있는가에 따라 얻을 수 있는 데이터의 양이 달라지기 때문이다.

# Reference

http://www.yes24.com/Product/Goods/8511539

[Digital Forensic] 메모리 분석 (1)

메모리 분석에 관련된 이야기들은 대부분 윈도우와 관련되어 있으며, 각 OS별로 메모리를 사용하고 관리하는 데 차이가 있기 때문에 당연히 메모리 구조에서도 차이가 있기 마련이다.

그렇기 때문에 모든 OS 메모리 구조를 다루지는 못하여 제일 우리 일상 생활에서 밀접한 Windows OS에 관한 메모리 분석을 다루며, 포렌식에서 빼놓을 수 없는 부분이 바로 메모리 분석이다.

메모리에는 프로세스가 사용한 데이터, 프로세스 자체, 웹 브라우저를 통해 전송된 정보, 복호화 된 데이터 등이 기록되어 있다.

메모리 분석 연구는 파일 시스템 분석이나 레지스트리 분석과 비교하였을 때는 아직 부족하지만 현재 수준에서도 시스템의 많은 정보를 얻을 수 있는 부분이 메모리이기 때문에 메모리에 대해 반드시 알고 시스템 정보를 찾고 찾은 정보를 사용할 줄 알아야 한다.

(1) 메모리 분석의 관심 & 장점과 단점

1-1. 하드디스크에서 실행되지 않고 메모리 상에서 바로 실행되는 악성코드의 존재

• 이러한 경우 아무리 하드 디스크를 이미지 파일로 이미징하여 분석한다고 하더라고 악성 파일의 실행 원본 파일이나 흔적을 하드 디스크에서 찾을 수 없으므로, 당연히 실행되고 있는 메모리 영역을 분석해야 함

1-2. 사용자 응용 프로그램 프라이버시 보호 기능 강화

• 요즘 암호화나 개인정보보호 프로그램이 일반화되어 많이 사용되고 있으며, 이러한 프로그램들은 일반 사용자의 개인 파일들을 보호하기도 하지만 일반 사용자 시스템에 침투한 악성코드 조차도 보호하는 경우가 발생

• 이러한 일이 발생하는 이유는 당연히 개인정보보호 프로그램이 악성코드 판별 기능이 없기 때문

• 이러한 상황에서 악성코드를 분석하려면 메모리 영역을 분석해야만 하며, 실행 파일들은 암호화가 되어 있거나 보호를 받고 있다고 하더라도 메모리 영역에서는 복호화가 되어 실행되기 때문에 원본 파일 그대로를 메모리 영역에서 얻을 수 있음

1-3. 안티 포렌식 기술의 확산 > 하드 드라이브에 존재하고 있는 데이터의 무결성 불완전

• 안티 포렌식 기술은 좋다고 할 수도 있고 나쁘다고 할 수도 있음

• 예로, 루트킷의 경우는 나쁘다고 할 수 있지만 데이터 완전 삭제 기술 같은 경우에는 일반 사용자에게 개인정보 파일들을 유출되지 못하도록 하는 기술이기 때문에 좋다고 할 수도 있음

• 루트킷이나 데이터 완전 삭제 경우 하드 디스크의 데이터 무결성(원본)을 저해하는 행위이기 때문에 무결성이 저해되기 전 데이터는 하드 디스크가 아니면 메모리에서 밖에 복구하지 못함

• 하지만 메모리에 있는 데이터도 완전한 데이터가 아니며, 아예 얻지 못하는 것보다는 일부라도 얻어 분석에 도움이 되는 것이 좋기 때문에 메모리 영역을 분석해 데이터를 추출하는 것 

위와 같은 이유로 포렌식 관점에서의 메모리 분석 분야가 관심받기 시작했지만 아직까지는 발전 단계가 낮으며, 메모리 분석에 관심을 가진 시간이 짧을 뿐더러 메모리 분석을 하기 위한 선행 지식이 너무 방대하고 메모리 구조는 OS마다 다르고 세부적으로 패치에 따라 달라질 수 있기 때문에 아직까지 발전 단계가 낮은 것이다.

메모리 분석과 Live Response를 비교해 봤을 때, 메모리 분석 과정이 Live Response 과정에 포함될 수 있으며 메모리 분석을 통해 얻는 정보는 대부분 Live Response에 정보와 일치하기 때문이다.

하지만 메모리 분석을 위한 선행 지식이나 기술들을 봤을 때, Live Response 과정에 메모리 분석을 넣는 것은 조사관 판단에 달려 있으며, 얻어지는 정보가 비슷하거나 일치한다고 하여 메모리 분석을 Live Response로 대체하는 것은 불가능하며, 반대 경우도 마찬가지이다. (이론적 가능 > 현실적 불가능)

Live Response는 메모리 분석과 비교하였을 때 다음과 같은 단점을 지닌다.

1) 도구 신뢰성 저하

• Live Response 도구들은 대부분 윈도우에서 기본적으로 제공하는 API에 의존

• 그렇기에 악의적인 해커나 악성 프로그램이 윈도우 DLL 파일을 변조하거나 교체한다면, 그 DLL을 사용하는 Live Response 도구 결과는 신뢰성이 떨어짐 

2) 분석 반복성 없음

• Live Response 정보는 모두 휘발성으로 시간이 지나고 다시 같은 방법으로 수집하여도 데이터가 일치한다고 보장하지 못함

• 이로 인해 Live Response 데이터가 합법적 절차를 통해 수집되었다는 증명을 못할 수도 있음

• 객관적 증명을 하려면 동일 환경에서 동일한 수행이나 입력이 되었을 때, 동일한 결과가 나와야 하지만 Live Response는 그렇지 못함

3) 분석 다양성 없음

• 조사관은 하나의 휘발성 정보 수집을 위해 여러 방법을 사용해야 함

• 이유는 휘발성 정보를 증거나 참고용으로 제출 > 상대편에서 반박 시, 객관적 증명을 하기 위해 다른 방법으로 조사하여 동일한 결과값을 얻은 증거를 제출해야 함

• Live Response는 수행 과정에서는 여러 방법을 사용해 정보를 수집 가능하지만, 그 조사가 끝나고 나면 다시 정보를 수집할 방법이 없음 (물론 반박을 대비해 여러 방법을 사용하여 정보를 수집하면 좋지만, 경과 시간 등을 비교해 봤을 때 좋은 방법은 아님)

위와 같이 Live Response는 단점을 가지고 있는 반면 메모리 분석은 Live Response에 대해 다음과 같은 장점을 가진다.

1) 도구 신뢰성 보장

• 메모리 분석을 위해 사용되는 API는 윈도우 프로세스/메모리에 관련된 API가 아닌, 파일 시스템 API이기 때문에 API 변조와 상괸이 없어 얻어진 결과에 대해 신뢰성을 가질 수 있음 

2) 분석 반복성 보장

• 메모리 분석 대상은 변하지 않는 것이기 때문에 언제든지 조사를 반복 가능

• Live Response와 달리 언제든지 동일한 입력 값을 통해 동일한 결과를 얻을 수 있음 

3) 분석 다양성 보장

• 메모리 분석 대상은 조사가 끝나도 존재 (Live Response는 존재 X)

• 언제든지 다른 조사 방법이나 새로운 조사 방법을 적용하여 조사를 다시 할 수 있음

결론으로는, 한쪽으로 치우치는 분석을 시도하기 보다는 서로 성호작용하는 분석을 수행하는 것이 가장 중요하다.

(2) 메모리 분석에 앞서 알아두어야 할 사항

2-1. 메모리 덤프 개요

• 메모리 분석에 앞서 해야 할 작업은 메모리 내용이 가장 순수한(변조되지 않은) 메모리 덤프 파일을 시스템으로부터 얻는 것

• 메모리 덤프 방법으로는 하드웨어 이용 방법, 소프트웨어 도구 이용 방법, OS 크래시 덤프 이용 방법, 하이버네이션 파일 이용 방법이 있음

• 각 방법은 장점, 단점이 있어 조사관 판단에 따라 상황에 맞게 적절하게 사용해야 함

2-2. 하드웨어 이용 메모리 덤프

• 하드웨어 덤프 수행 시, DMA 기능을 이용해 OS 특성에 상관없이 메모리 덤프를 수행 가능

• 응용 프로그램을 실행하는 것이 아니기에, 시스템 메모리에 어떤 영향도 미치지 않아 소프트웨어 방식보다는 조금 더 정확한 메모리 덤프 가능

• 하지만, 메모리 덤프 과정의 안전성이 검증되지 않아 시스템에 크래시를 일으킬 수 있고, 최신 마더보드 경우 MIMO 기능을 가지는 데 악의적 사용자가 이 기능을 이용해 메모리 덤프 과정을 방해할 가능성 있음 

DMA (Direct Memory Access) : CPU 도움없이 메모리 접근 방법으로 입출력장치들이 많이 쓰며, 이 기능으로 입출력장치와 CPU 속도차 개선 (메모리 맵핑(Mapping)은 OS가 아닌 하드웨어에서 이루어 짐)

MIMO (Memory Mapped I/O) : I/O를 하기 위한 특별 장치없이 레지스터 설정만으로 메모리와 맵핑하여 입출력이 가능하게 하는 기능

하드웨어를 이용한 메모리 덤프 방법 종류는 다음과 같다.

1) PCI 장치

• 일반적으로 잘 알려진 메모리 덤프 방법

• Tribble이라는 기기를 사용하며, 이 장치는 실험적인 장치이므로 구매 불가능

2) FireWire 장치

• IEEE 1394 인터페이스 사용

• 윈도우에서도 사용 가능하며, 대상 컴퓨터에 무언가를 설치할 필요가 없고 PCI 장치 방법보다 간편

하드웨어를 이용한 방법은 실습할 방법이 없으므로 설명만으로 공부해야 한다.

직접 실습해보기 위해서는 개인적으로 하드웨어 장비 구비하거나 회사를 통해 하드웨어 장비를 구해 실습해보는 방법 밖에 없다.

2-3. 소프트웨어 이용 메모리 덤프

• 즉석에서 메모리 덤프를 만들 수 있다는 가장 좋은 점을 가짐

• 하드웨어 방법보다는 소프트웨어 방법이 좀 더 많이 쓰임

• 단점으로는 메모리 덤프용 소프트웨어들은 대부분 OS의 API에 의존하며, 악의적인 사용자가 API를 조작하게 되면 메모리 덤프 결과도 조작되는 셈

하드웨어를 이용한 메모리 덤프는 얻어지는 결과에 대해서는 좋지만 그 과정에 제약 사항이 많고 검증되지 않은 기법들이어서 보통 소프트웨어를 통한 메모리 덤프를 수행한다.

소프트웨어를 통한 메모리 덤프에는 다음과 같은 방법들이 존재한다.

1) DD

• 유닉스 도구 중 하나로 GNU License로 배포

• 사용법이 간단하며, 결과물이 좋음

• 유닉스 도구를 기초로 하여 윈도우에서도 적용 가능한 윈도우 버전도 존재

• 사용자가 접근 가능한 모든 데이터를 바이트 또는 블록 단위로 복사

• 복사하려는 영역을 OS가 인식하지 못하거나, 사용자 권한이 낮아 접근하지 못하는 영역이거나, 지원하는 API가 없는 경우를 제외하고는 모든 시스템 데이터 덤프 가능

• 커널 메모리 경우 /dev/kmem 장치를 입력으로 덤프하고, 시스템 메모리 경우 /dev/mem 장치를 입력하여 덤프를 시도

• 포맷 이미지는 Raw 데이터 포맷 이미지라고 하여 대부분 포렌식 도구에서 이 포맷을 지원

• 장점으로는 데이터 형태를 그대로 덤프한다는 것이고, 단점은 부가 정보가 제공되지 않아 분석하는 데 시간이 오래 걸림

2) KntDD

• 메모리 덤프를 네트워크로 전송하는 기능을 포함

• 메모리 덤프를 윈도우 크래시 덤프 포맷으로 변환하는 기능을 가짐

• 이 도구는 보안 회사, 정부 기관에서만 제공되어 일반인들은 사용할 수 없음

3) MDD

• 메모리 덤프만을 위해 만들어진 도구

• Windows XP SP2 이후 버전에서도 문제없이 수행 가능하지만 업데이트가 되지 않음

4) WIN32(64)DD

• 이 도구 역시 MDD처럼 메모리 덤프 전용으로 개발된 도구

• 많은 기능을 포함하며, 지원하는 윈도우 버전이 많음

• 기본적으로 Raw 포맷을 지원하며, 추가로 크래시 포맷과 하이버네이션 포맷을 지원

• 네트워크 전송 기능도 갖고 있으며, 64bit 시스템도 지원하고 4GB 이상의 메모리 덤프도 지원

5) FastDD

• win32dd보다 속도가 빠름

• 32bit 시스템과 64bit 시스템 모두 지원

6) 기타 상용 도구

• FastDump : CLI 기반 도구

• Pro Discover IR : 메모리 덤프 전용이 아닌 침해사고용으로 개발된 도구

• EnCase Enterprise : Guidance software사에서 제작

• AccessData Enterprise : 기업 환경에서의 네트워크에 있는 컴퓨터 메모리 덤프를 수집하는 데 목적

대부분 상용 도구들은 메모리 덤프 전용이 아닌 복합적 기능이 구현된 도구들이다.

그렇기에 가격도 비싸 개인적으로 메모리 덤프만 할 것이라면 굳이 구입할 필요는 없다.

2-4. OS Crash Dump

• OS가 시스템에 일어난 오류 문제 원인을 찾기 위해 생성하는 메모리 덤프

• 크래시 덤프는 Windows Server 2008 R2 이상 버전에서는 무조건 생성되며, Windows 7 이상 버전에서는 해당 로컬 컴퓨터가 Active Directory 도메인에 가입되어 있으면 무조건 생성

• HKEY_LOCAL_MACHINE의 AlwaysKeepMemorydump의 값이 1이면 Windows Server 2008 R2가 아니거나 도메인에 가입되어 있지 않아도 크래시 덤프는 무조건 생성

크래시 덤프 생성 과정

• BSOD (BlueScreen Of Death)이 발생하면 OS는 오류 문제를 찾기 위해 메모리를 덤프하여 파일로 저장

• 일반적으로 XP 경우, 디스크의 2GB의 여유 저장 공간이 있으면 크래시 덤프 파일을 생성 (메모리 크기 + 300MB 크기로 생성)

• Win 7의 경우 디스크의 25GB 이상 여유 공간이 있어야만 크래시 덤프 파일 생성

• 크래시 덤프 파일을 생성할 때 조건으로 디스크 여유 공간이 25GB 이상인지 확인

• 이는 이전 Windows 버전에서 디스크 용량이 충분하지 못한 상황에서 메모리 덤프를 막아 시스템 리소스 낭비를 줄이자는 의도

일반적으로 크래시 덤프 파일은 다음 과정을 통해 생성

1. SystemRoot에 존재하는 PageFile.sys에 메모리를 기록

2. PageFile.sys의 내용을 이용 > 크래시 덤프 파일 생성

PageFile.sys : SystemRoot에 존재하는 시스템 파일로, 메모리에서 swap되는 page들을 저장하는 파일 (휘발성 성격의 메모리 데이터를 비휘발성 성격으로 갖고 있는 파일)

크래시 덤프는 메모리 덤프 방법 중 가장 순수한 메모리 덤프 파일을 얻을 수 있는 방법이다.

하지만 메모리 덤프 파일을 얻기 위한 방법이 복잡하고 메모리 전체 덤프를 언제나 얻을 수 있는 것은 아니다.

또 OS마다 크래시 덤프 발생 조건이 다르게 설정되어 있어 분석 대상 시스템에 크래시 덤프 파일 생성 설정이 되어 있지 않다면 해당 방법을 사용하기가 매우 모호하다.

크래시 덤프 종류

1) 작은 메모리 덤프

• 오류가 발생한 원인을 밝히기 위한 최소한의 정보만을 기록

• 부트 볼륨에 최소한 2MB 이상 페이지 파일이 있어야 함

2) 커널 메모리 덤프

• 할당되지 않은 메모리 영역과 사용자 모드로 동작 중인 프로그램들에 메모리 영역을 제외한 커널 모드와 HAL (Hardware Abstraction Layer) 메모리 영역만을 기록

• 포렌식 관점에서는 사용자 모드 프로그램의 메모리 영역을 기록하지 않아 중요하진 않지만, 오류 수정하는데 적합한 덤프

3) 전체 메모리 덤프

• 메모리 전체를 기록

• 부트 볼륨에 전체 메모리 크기에 1MB를 더한 만큼의 페이지 파일이 있어야 함

• 32bit 환경에서는 2GB 이상의 메모리는 덤프할 수 없음

2-5. 하이버네이션 (Hibernation)

• 시스템에 일정 시간이 지나도 아무런 입력이 없을 때 OS가 모든 메모리 데이터를 하드 드라이브에 기록

• 시스템 구동에 필요한 최소 전원 공급만을 남겨둔 채 필요 없는 전원을 차단하는 기능

• 기능 목적은 호율적 전원 관리

• Sleep mode와 유사하지만, 몇 가지 차이가 있음

슬립 모드와 하이버네이션 차이

• 슬립 모드(Sleep mode)는 메모리의 데이터가 손실되지 않도록 계속 전원을 공급하는 방식

• 하이버네이션은 메모리의 데이터를 하드 드라이브에 기록하고 시스템 구동에 필요하지 않은 전원들을 모두 차단

결과적으로 슬립 모드와 하이버네이션 차이점은 메모리의 데이터를 유지하는 방식과 전원 차단에 있다.

이로 인해 슬립 모드의 경우에는 다시 시스템을 원상태로 복구하는 시간이 짧은 반면에 하이버네이션은 슬립 모드보다 오래 걸린다.

하이버네이션 장점 

• OS에서 제공하는 기능으로 메모리 덤프 파일을 만들기 때문에 추가적인 프로그램이나 장비가 필요하지 않음

• OS 기능을 이용하기 때문에 크래시 덤프와 견줄 정도의 순수한 메모리 덤프 파일을 얻을 수 있음

하이버네이션 단점

• 하이버네이션 파일이 존재한다 하더라도 침해사고 발생 전에 생긴 파일일 수도 있음

• 메모리를 전체적으로 덤프하는 것도 아니며, OS뿐만이 아닌 마더보드도 이 기능을 지원해야 함

• 제일 중요한 점은 일반 PC 경우에 이 기능이 기본 설정으로 비활성화 되어 있음

하이버네이션 기능 수행 조건

• CMOS와 OS 설정에서 하이버네이션 설정이 되어 있어야 함

• 시스템에 얼마간의 입력이 없어야 하며, 서비스나 프로세스에 의해 입력이 있어서도 안 됨

하이버네이션으로 인해 생성되는 파일은 hiberfil.sys이며, pagefile.sys와 같은 위치에 저장되어 있다.

참고로 하이버네이션 기능을 사용하여 메모리 분석을 하면 좋지만, 필요성을 느끼지 못한다면 굳이 할 필요는 없다.

(3) 가상 메모리 구조

3-1. 가상 메모리 정의

• 물리적 실체를 가지고 있지 않은 메모리

• OS가 만들어낸 논리적인 형태의 메모리를 뜻함

• 가상 메모리에 저장된 데이터라고 해서 가상으로 저장할 수는 없으며, 가상 메모리의 데이터는 물리 메모리나 하드 드라이브에 저장

• 가상 메모리는 VAS라는 것을 OS로부터 할당 받음

VAS (Virtual Address Space) : 가상 메모리에 할당되는 주소를 뜻하며, 물리 메모리의 주소와는 다른 주소

32bit 시스템 경우, 4GB 크기의 가상 메모리 영역을 할당 받으며, 64bit 시스템의 경우에는 이론적으로 17EB의 가상 메모리 영역을 할당 받지만, 64bit의 경우 할당 받는 영역의 크기가 너무 크고 비효율적이어서 8TB 정도로 제한을 한다.

가상 메모리 크기는 시스템의 bit에 따라 정해져 있으며 프로세스 크기에 따라 변하지 않고 무조건적으로 정해진 크기가 할당된다.

또한 프로세스는 자신에게 할당된 가상 메모리의 영역을 자신의 것으로만 생각하고 단편화 되지 않은 연속적 주소 공간으로 인식한다.

그렇기 때문에 시스템에 상관없이 매번 고정 크기의 가상 메모리를 할당받아 프로세스는 시스템마다 다른 메모리 크기의 한계를 느끼지 않고 실행될 수 있는 것이다.

메모리 덤프를 하면 사용자 영역에 있는 데이터들은 불완전 형태로 덤프되는 경우가 있고 커널 영역은 온전 형태로 덤프 되는 경우가 있는데 이러한 경우는 가상 메모리와 사용자 영역에서 데이터가 물리적 메모리와 페이지 파일을 오고 가기 때문이다.

프로세스가 사용하는 데이터가 오랫동안 사용되지 않을 경우 페이지 파일에 저장해두고 필요할 경우 다시 물리적 메모리에 적재하여 사용하는 방식 때문에 불완전하게 덤프 되는 것이다.

커널 영역의 경우 시스템에 필요한 데이터들이고, 자주 사용되는 것들이기 때문에 페이지 파일에 저장하지 않고 물리 메모리에 저장되기 때문에 온전하게 덤프 되는 것이다.

가상 메모리와 물리적 메모리 주소는 맵핑이 되어 있는데 가상 메모리 어떤 데이터의 주소가 다른 프로세스의 가상 메모리의 어떤 데이터 주소와 같다고 하더라도 물리적 메모리에서의 주소는 다르기 때문에 서로 충돌이 일어나거나 데이터를 덮어 씌우지 않는다.

3-2. 가상 메모리와 물리적 메모리 사이 주소 변환

• 가상 메모리 주소는 32bit 시스템에서는 32bit 길이를 가짐

• 가상 주소가 물리 주소로 변환될 때에는 2개의 테이블과 한 개의 오프셋을 거쳐 변환됨

• 위 변환 과정을 거치는 이유는 4GB 가상 메모리와 페이지 프레임 단위로 구성되어 있는 실제 메모리 사이 맵핑 정보를 하나의 표로 만들게 되면 4MB 정도가 되는 표가 만들어짐

• 프로세스마다 이러한 표를 만들어 메모리에 적재하면 메모리 낭비이고, 안 올리면 맵핑 속도가 크게 저하된다는 문제점이 발생

위와 같은 이유로 윈도우는 가상 메모리와 물리 메모리 사이의 맵핑을 2개 테이블로 나누고, 그 중 첫 번째 테이블(페이지 디렉토리 테이블)만 메모리에 보관하고 나머지 하나의 테이블을 필요할 때만 메모리에 적재한다.

메모리는 페이지(page)라는 단위로 불리는 일정 크기 단위를 사용하여 물리적 메모리를 관리하는데 가상 주소와 물리 주소의 맵핑 또한 이 페이지를 기준으로 이루어진다.

3-3. 가상 주소를 이용해 물리 주소 찾기

• 각각의 페이지는 첫 번째 페이지부터 0번호가 매겨지며, 이 번호를 페이지 프레임 넘버(Page Frame Number)라고 함

가상 주소의 구조는 다음과 같다.

가상 주소 = 페이지 디렉토리 인덱스 (10bit) + 페이지 테이블 인덱스 (10bit) + 바이트 주소 인덱스 (12bit) = 32bit

다음과 같은 정보를 이용하여 OS는 가상 주소를 토대로 물리 주소를 찾을 수 있다.

1. 페이지 디렉토리의 엔트리에 저장된 페이지 테이블 주소를 읽고 해당 주소에 있는 페이지 테이블로 이동 > 그 후 가상 주소에 존재하는 페이지 테이블 인덱스 값으로 해당 페이지 테이블에서 해당하는 인덱스를 찾아 그 값을 읽고, 페이지 테이블 엔트리는 물리적 주소의 페이지 프레임 주소가 들어 있음 (페이지 프레임으로 이동)

2. 가상 주소의 페이지 디렉토리 인덱스 값에서 현재 프로세스의 페이지 디렉토리의 엔트리를 찾고 그 값을 읽음 > 페이지 디렉토리 엔트리에는 페이지 테이블의 주소 정보가 들어 있음 (페이지 테이블로 이동)

3. 페이지 디렉토리의 엔트리에 저장된 페이지 테이블 인덱스 값으로 페이지 테이블 엔트리를 찾아 그 값을 읽음 > 페이지 테이블 엔트리에는 물리적 주소의 페이지 프레임 주소가 들어 있음 (페이지 프레임으로 이동)

4. 가상 주소 마지막 부분에 있는 바이트 주소 인덱스를 이용 > 실제 찾고자 하는 물리적 메모리의 주소로 이동하고 필요한 만큼 데이터를 읽음

프로세스마다 페이지 디렉토리를 갖고 있으며, 이거의 물리적 주소는 KPROCESS 구조 안에 저장되어 있다가 Context Switching이 발생하면 CR3 레지스터로 복사된다.

실제 프로세스 오브젝트는 가상 메모리에서 보이는 것과는 달리 물리적 메모리에 단편화 되어 저장되는데 흩어져 엤는 프로세스 데이터를 가상 주소를 근거로 찾으려면 반드시 페이지 디렉토리의 물리적 주소가 필요하다.

KPROCESS 구조 안에 페이지 디렉토리의 물리적 주소가 아닌 가상 주소가 저장되어 있다면 가상 주소와 물리 주소의 맵핑은 불가능하다.

# Reference

http://www.yes24.com/Product/Goods/8511539

[Reversing] 함수 호출 규악(Calling Convention)

(1) 함수 호출 규약

1-1. 함수 호출 규약이란?

• Calling Convention은 우리말로 '함수 호출 규약'이라고 부름

• "함수를 호출할 때 파라미터를 어떤 식으로 전달하는가?"에 대한 일종의 약속 

이전에 이미 함수 호출 전에 파라미터를 스택을 통해서 전달한다는 것을 진행하였다.

스택이란 프로세스에서 정의된 메모리 공간이며 아래 방향(주소가 줄어드는 방향)으로 자란다.

또한 PE 헤더에 그 크기가 명시되어 있으며, 즉 프로세스가 실행될 때 스택 메모리의 크기가 결정된다.

(malloc / new 같은 동적 메모리 할당과는 다름)

스택에 저장된 값은 임시로 사용하는 값이기 때문에 더 이상 사용하지 않는다고 하더라도 값을 지우거나 하면 불필요하게 CPU 자원을 소모한다.

어차피 다음 번에 스택에 다른 값을 입력할 때 저절로 덮어쓰는 데다가 스택 메모리는 이미 고정되어 있기 때문에 메모리 해제를 할 수도 없고 할 필요도 없다.

스택 메모리는 고정되어 있고 ESP로 스택의 현재 위치를 가리키는데, 만약 ESP가 스택의 끝을 가리킨다면 더 이상 스택을 사용할 수 없다.

함수 호출 후에 ESP(스택 포인터)를 어떻게 정리하는지에 대한 약속이 바로 함수 호출 규약이다.

주요한 함수 호출 규약은 다음과 같다.

• cdecl

• stdcall

• fastcall

# 참고

• Caller(호출자) : 함수를 호출한 쪽

• Callee(피호출자) : 호출을 당한 함수

예로, main() 함수에서 print() 함수를 호출하였다면 Caller는 main()이고, Callee는 printf()가 되는 것이다.

1-1-1. cdecl

• cdecl 방식은 주로 C언어에서 사용되는 방식

• Caller에서 스택을 정리하는 특징을 가짐

[그림 2]의 내용은 다음과 같다.

• 401013 ~ 40101C 주소 영역의 코드를 보면, add() 함수의 파라미터 1, 2를 역순으로 스택에 입력

• add() 함수(401000)를 호출 후 ADD ESP, 8 명령으로 스택을 정리 

이와 같이 Caller인 main() 함수가 자신이 스택에 입력한 함수 파라미터를 직접 정리하는 방식이 cdecl이다.

cdecl 방식의 장점은 C언어의 printf() 함수와 같이 가변 길이 파라미터를 전달할 수 있다는 것이다.

이러한 가변 길이 파라미터는 다른 Calling Convention에서는 구현이 어렵다.

1-1-2. stdcall

• stdcall 방식은 Win32 API에서 사용

• Callee에서 스택을 정리하는 것이 특징

• C언어는 기본적으로 cdecl 방식이지만, stdcall 방식으로 컴파일하려면 '_stdcall' 키워드를 붙여주면 됨

[그림 4]의 내용은 다음과 같다.

• 스택의 정리는 add() 함수 마지막(40100A)의 RETN 8 명령에서 수행

• RETN 8 명령 의미는 RETN + POP 8바이트

• 즉 리턴 후 지정된 크기만큼 ESP를 증가시키는 것

이와 같이 Callee인 add() 함수 내부에서 스택을 정리하는 방식이 stdcall 방식이다.

stdcall 방식의 장점은 호출되는 함수(Callee) 내부에 스택 정리 코드가 존재하므로 함수를 호출할 때마다 ADD, ESP, XXX 명령을 써줘야 하는 cdecl 방식에 비해 코드 크기가 작아진다.

Win32 API는 C언어로 된 라이브러리지만, 기본 cdecl 방식이 아닌 stdcall 방식을 사용한다.

이는 C 이외의 다른 언어(Delphi(Pascal), Visual Basic 등)에서 API를 직접 호출할 때 호환성을 좋게 하기 위한 것이다.

1-1-3. fastcall

• 기본적으로 stdcall 방식과 같지만, 함수에 전달하는 파라미터 일부(2개까지)를 스택 메모리가 아닌 레지스터를 이용하여 전달한다는 것이 특징

• 어떤 함수의 파라미터가 4개라면, 앞의 두 개의 파라미터는 각각 ECX, EDX 파라미터를 이용하여 전달 

fastcall의 장점은 이름 그대로 좀 더 빠른 함수 호출이 가능하다.

(CPU 입장에서는 멀리 있는 메모리보다 CPU와 같이 붙어있는 레지스터에 접근하는 것이 훨씬 더 빠름)

그런데 호출 자체만 보면 빠르지만, ECX, EDX 레지스터를 관리하는 추가적인 오브헤드가 필요한 경우가 있다.

가령 함수 호출 전에 ECX, EDX에 중요한 값이 저장되어 있다면 백업해 놓아야 한다.

또한 함수 내용이 복잡하다면 ECX, EDX 레지스터를 다른 용도로 사용할 필요가 있을 때 역시 이들이 가지고 있는 파라미터 값을 어딘가에 따로 저장할 필요가 생긴다.

# Reference

http://www.yes24.com/Product/Goods/7529742

[Reversing] Process Explorer

(1) Process Explorer - 최고의 작업 관리자

1-1. Process Explorer

• Windows 운영체제에서 최고의 프로세스 관리 도구

• sysinternals의 Mark Russinovich가 만든 프로세스 관리 유틸리티

• Mark Russinovich는 Windows 운영체제에 대한 해박한 지식을 갖고 있으며, 유용한 유틸리티들을 만들어 공개

• Windows 운영체제 초창기에 정보를 별로 구할 수 없던 시스템 드라이버 개발자들에게 소스 코드를 공개

다운로드 사이트 : https://docs.microsoft.com/ko-kr/sysinternals/downloads/process-explorer

Process Explorer 실행 화면의 특징은 다음과 같다.

• Windows 작업 관리자와는 비교할 수 없는 뛰어난 화면 구성을 보여줌

• 화면 위 좌측에는 현재 실행 중인 프로세스들을 Parent/Child의 트리 구조료 표시

• 우측에는 프로세스 각각의 PID, CPU 점유율, 등록 정보 등을 보여줌 (옵션 통해 추가 가능)

• 화면 아래(옵션)에는 선택된 프로세스에 로딩된 DLL 정보 또는 해당 프로세스에서 오픈한 object handle을 표시

1-2. Process Explorer 장점

Process Explorer의 장점은 다음과 같다.

• Parent / Child 프로세스 트리 구조

• 프로세스 실행 / 종료 시 각각의 색깔(초록, 빨강) 표시

• 프로세스 Suspend / Resume 기능 (실행 중지 / 재개)

• 프로세스 종료(kill) 기능(Kill Process Tree 기능 지원)

• DLL / Handle 검색 (프로세스에 로딩된 DLL 또는 프로세스에서 점유하는 Handle 검색)

이 외에도 다양한 기능이 존재하지만, 위에 나열된 것이 특별하게 리버싱할 때 많이 사용되는 기능이다.

추가로 꾸준한 업데이트(버그, 수정, 기능 추가)도 큰 장점이다.

# Reference

http://www.yes24.com/Product/Goods/7529742