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

[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