Introdution

윈도우 운영체제에 있어 우리가 흔히 직접 실행할 수 있는 프로그램 이외에 우리가 직접 실행하지 않아도 실행되는 프로세스가 있다. 이 중 서비스는 보통 시스템의 시작과 함께 시작되어 윈도우의 핵심 프로세스의 기능을 수행한다. 중요한 만큼 사용자의 개입을 최소화하기 위해 백그라운드에서 동작한다. 프로세스에 대한 제어권을 우리가 갖지 않고 윈도우의 서비스 제어 관리자가 가지고 있기 때문에 일반적인 방법으로 서비스를 분석할 수 없다. 이러한 요인들로 인해 악성코드 제작자는 서비스를 통해 백그라운드라는 점, 사용자 개입의 최소화 등의 이점을 누릴 수 있다. 따라서 이번 문서에서는 서비스가 어떻게 동작하는지, 그리고 이를 분석하기 위해서는 어떠한 방식을 사용해야 하는지에 대하여 알아보자.

Service Control Manager(SCM)

Windows에서 서비스를 실행할 때 중요한 역할을 수행하는 것이 SCM이다. SCM은 Boot시에 시작되는 시스템 프로세스의 일종으로, 서비스를 제공하는 프로그램의 등록, 시작, 종료, 삭제 등과 같은 모든 관리를 담당한다.  일반적으로 아래의 그림과 같이 우리는 Controller를 통해 SCM에게 서비스의 실행, 중지 등을 요청하여 서비스 프로그램을 시작하고 종료할 수 있다. 이렇듯 사용자나 다른 프로그램이 Service를 조작할 경우에는 반드시 SCM을 통해야만 한다. 이를 반대로 말하면 서비스 프로그램은 SCM에서 제어할 수 있는 장치를 넣어둔 프로그램이라 할 수 있다.

서비스 프로그램은 SCM에서 제어할 수 있는 장치를 가지고 있다는 것은 서비스 프로그램의 내부에 SCM에 제어를 요청하거나 연결을 요청하는 API가 존재하고 있다는 것이다. 만약 해당 API들이 없다면 서비스 프로그램은 단순히 일반 프로그램과 다를 바가 없다. 아래는 서비스 프로그램의 간략화된 main()으로 일반적인 프로그램의 main()과는 약간 다른 코드를 갖고 있다. 일반적인 프로그램의 경우 Main()에서부터 메인 스레드를 통해 독자적으로 처리하면 되지만, 이와는 다르게 서비스 프로그램의 경우에는  Main 함수에서 프로그램과 SCM을 연결해주는 StartServiceCtrlDispatcher API를 호출해주어야 한다. 여기서 연결이란 서비스의 진입점을 SCM에게 등록해주는 것으로, 해당 API를 통해 SCM은 서비스의 제어를 가지게 되고 서비스가 정지할 때까지 제어를 돌려주지 않는다.

해당 API의 인자로 지정된 services는 배열의 형태를 가지고 있다. 아래의 코드에서 "TestSvc"는 서비스의 이름을 지정해주는 것이고, TestSvcMain은 해당 서비스 프로그램이 SCM에게 실행을 요청할 내용의 코드이다. 이는 다시 말해 서비스 전용 메인 함수로 SCM은 새롭게 스레드를 생성해서 서비스 메인의 함수를 호출한다. 따라서 우리가 이후에 분석을 할 때에 중점적으로 확인해야 할 부분이 바로 TestSvcMain이 위치한 곳이 된다.

#include <Windows.h>
#include <stdio.h>

int main()
{
    SERVICE_TABLE_ENTRY services[] = {{"TestSvc", TestSvcMain}, {NULL, NULL}};
    if(!StartServiceCtrlDispatcher(services))
    {
        printf("서비스 연결 실패");
        return -1;
    }
    return 0;
}

ServiceMain & Control Handler

서비스 프로그램의 전용 메인 함수(위 예의 TestSvcMain)가 SCM과 연결되어 프로세스가 생성되었지만, SERVICE_START_PENDING 상태가 된다. 이는 정식 서비스로 동작하는 것은 아니며 이를 동작시키기 위해선 자신의 서비스 상태를 지정해주어야 한다. 서비스의 상태를 제어하기 위해 서비스의 메인 함수에서는 RegisterServiceCtrlHandler API를 호출해야 한다. 이는 SCM에 제어 핸들러를 등록하기 위한 API로, SCM은 서비스를 제어할 필요가 있을 때 이 핸들러를 호출하는 방법으로 서비스에 통지한다. 이것이 등록되어야 SCM이 서비스 프로그램을 제어할 수 있다. 

SERVICE_STATUS_HANDLE WINAPI RegisterServiceCtrlHandler( 
    _In_ LPCTSTR            lpServiceName,  
    _In_ LPHANDLER_FUNCTION lpHandlerProc
);

제어 핸들러를 등록하고 SetServiceStatus API를 통해 서비스가 시작 상태가 된 것을 SCM에 통지해야 한다. 시작된 것을 알리고자 할 때는 SERVICE_RUNNING을 인자로 해당 API를 호출하면 된다. 이러한 과정은 서비스 프로세스가 생성되고 1초 이내에 완료될 것을 기대학 때문에 그 이상 시간이 걸릴 경우 미리 설정해주어야 한다. 만약 지정한 시간이 지나도 상태가 갱신되지 않을 경우 SCM은 초기화에 실패했다고 판단하고 서비스를 종료한다. 시간 내에 SetServiceStatus를 통해 SERVICE_RUNNIGN을 지정해주었다면 비로소 정상적인 서비스 프로세스로 동작할 수 있게 된다.

BOOL WINAPI SetServiceStatus(  
    In_ SERVICE_STATUS_HANDLE hServiceStatus,  
    In_ LPSERVICE_STATUS      lpServiceStatus
);

Reference

https://ko.wikipedia.org/wiki/윈도우_서비스

[API로 배우는 Windows 구조와 원리]

[리버싱 핵심원리]

System Overview

 이번 장에서는 메모리 분석에 영향을 미치는 하드웨어 컴포넌트와 운영체제의 구조에 대한 일반적인 개요를 설명할 것이다. 비록 이번 챕터 이후부터는 운영체제의 부분적인 면과 연관되어 자세히 해당 요소들을 설명할 것이지만, 이번 장에서는 기존 지식에 대한 상기나 간단한 기초에 대해 유용한 배경지식을 줄 것이다. 

Digital Environment

 이 책은 디지털 환경에서 발생되는 이벤트의 분석에 초점이 맞추어져 있다. 물리적인 세계에선 물리적 세계에 대한 지식을 적용하여 조사자들은 조사와 얼마나 혹은 어떻게 특정한 아티팩트들이 관련지어는가에 대한 시야를 얻을 수가 있다. 유사하게 디지털 환경에서는 특정한 명령어로 실행될 수 있는 명령어나 접근될 수 있는 리소스에 대해 이야기 할 수가 있다. 특정한 시스템의 하드웨어 컴포넌트와 이러한 컴포넌트에 의한 충격를 확인할 수 있는 조사자들은 효과적인 조사를 함에 있어서 최고의 포지션을 가지고 분석을 할 수가 있다.

 대부분의 플렛폼에서 하드웨어는 프로세스와 리소스 관리 외부장치와의 의사소통을 다루는 운영체제에 의하여 접근된다. 운영체제는 low-level로 특정한 프로세서나 장치, 시스템에 설치된 메모리 하드웨어를 처리해야만 한다. 일반적으로 운영체제는 high-level 서비스와 유저프로그램에 의하여 하드웨어가 어떻게 접근될 수 있는지를 정의한 인터페이스로 구성되어 있다.

 조사 중에 소프트웨어나 유저가 디지털환경에 생성한 아티팩트를 발견하거나  어떻게 디지털 환경이 해당 아티팩트에 의하여 변화하였는지를 볼 수가 있을 것이다. 시스템의 하드웨어와 운영체제와 친숙한 디지털 조사자들은 이벤트 재구성이나 분석에 있어서 참고하기에 좋은 프레임을 제공한다.

PC Architecture

 이번 섹션에서는 메모리 포렌식에 흥미가 있거나 친숙해지고자하는 기초 하드웨어 조사에 대한 전체적인 개요를 설명할 것이다. 특히, PC의 일반적인 하드웨어 구조에 초점을 맞출 것이며 주로 인텔 기반 시스템과 관련된 용어들을 사용할 것이다. 이러한 용어는 계속 변화하고ㅁ 있으며 상세한 구현은 지속적으로 비용 및 성능을 향상시키기 위해 발전하고 있다. 비록 특정 기술들은 변화하지만 그러한 주요 기능들은 여전히 같은 상태로 남아있다.

Physical Organization

 PC는 다양한 컴포넌트들이 상호연결할 수 있게하며 주변 장치를 위한 커넥터를 제공하는 인쇄 회로 기판으로 구성된다. 이러한 유형의 시스템에서의 메인보드는 의사소통을 위한 시스템의 컴포넌트의 연결을 가능하게 제공한다.이러한 의사소통 채널들은 일반적으로 Computer Busses로 언급이 되며 이번 섹션에서는 조사자들이 친숙해져야만 하는 버스들과 컴포넌트에 초점을 맞출 것이다. Figure 1-1은 이 절에서 설명할 것이 어떻게 일반적으로 구성되어 있는지를 나타내고 있다.

CPU and MMU

 마더보드에 있어서 가장 중요한 두가지 컴포넌트는 프로그램을 실행시키는 프로세서와 임시적으로 실행된 프로그램을 저장하고 있거나 그들의 데이터와 연관된 메인 메모리이다. 프로세서는 공통적으로 Central Processing Unit(CPU)라 언급이 되며 이러한 CPU는 메인 메모리의 명령어를 얻기 위하여 접근을 하거나 이러한 명령어를 실행시키고자 할 때 접근한다.

 메인 메모리로부터 읽는 것은 종종 CPU 자체의 메모리로부터 읽는 것보다 극단적으로 느리다고 할 수 있다. 그 결과 현대의 시스템은 이러한 상이한 차이를 상쇄하는데 도움을 주는 Caches라 하는 여러 빠른 메모리층을 활용하였다.각 캐시의 레벨(L1와 L2 등등)은 해당 이전 것보다 상대적으로 느리며 크다고 할 수 있다. 대부분의 시스템에서 이러한 캐시는 프로세서나 각 핵심 안에 내장되어 있다. 만약 데이터가 캐시에서 발견되지 않는다면, 데이터는 다음 레벨의 캐시나 메인메모리부터 패치가 될 것이다.

 CPU는 데이터가 어디에 저장되어 있는지를 돕기 위하여 memory management unit(MMU)에 의존한다.MMU는 프로세서가 메모리에서 요청하는 해당 주소를 변환하는 하드웨어 유닛이다. 이 장의 뒷부분에서 설명된 바와 같이, 주소 변환을 위한 데이터 구조는 메인메모리에 저장이 되어 있다. 주어진 변환 작업은 여러 메모리 읽기 작업을 요구할 수 있기 때문에 프로세서는 TLB라는 특별한 캐시를 사용한다. (* TLB를 이용하여 MMU가 가상주소를 물리주소로 변환시킴). 각각의 메모리 접근에 앞서 TLB는 비용이 많이 드는 주소 변환 작업을 MMU가 하기 전에 컨설트를 진행한다. 챕터 4에서 어떻게 캐시나 TLB가 메모리 증거에 있어 포렌식 어퀴지션에 영향을 미치는지를 좀더 자세하게 언급을 할 것이다.

North and Southbridge

 CPU는 메인 메모리와 소통을 관리하는데 있어서 메모리 컨트롤러에 의존하게 된다. 이러한 메모리 컨트롤러는 프로세서들과 장치들로부터 시스템 메모리에 동시에 요구되는 요소의 중재를 책임지고 있으며 프로세서 안에서 통합된거나 분리된 칩으로 구성될 수 있다. 오래된 PC에서는CPU는 프론트-사이드-버스를 사용하는 northbridge와 연결되었고 이러한 northbridge는 메모리 버스를 통해 메인 메모리와 연결이 되었다. 네트워크 카드나 디스크 컨트롤러와 같은 장치들은 southbridge나 I/O 컨트롤러 허브라 불리는 다른 칩을 통하여 연결이 되었으며 이러한 허브는 CPU와 메모리에 접근하기 위해 노스브리지에 단일로 연결되었다. 

 성능의 향상이나 새로운 시스템들의 비용을 줄이는 것은 현재 프로세서와 통합된 메모리 컨트롤러와 연관된 중요한 기능이다. 이전 사우스 브리지에서 구현된 나머지 칩셋들은 플랫폼 컨트롤러 허브라 잘 알려준 칩으로 고려된다.

Direct Memory Access(DMA)

 전체적인 기능의 향상을 위해서 대부분의 현대 시스템은 I/O 장치들에게 프로세서의 개입 없이 시스템 메모리에 저장된 데이터를 직접 변환하는 기능을 제공하고 있다. 이러한 기능은 direct memory access(DMA)라 뷸린다. DMA가 속되기 전에 CPU는 I/O 변환이나 중개의 역할을 하는데 전체적을 사용되었다. 하지만 현대의 아키텍처에서 CPU는 데이터 변환을 시작하거나 데이터 변환을 위하여 DMA 컨트롤러를 허용하거나 혹은 I/O 장치가 CPU로부터 독립적으로 실행될 수 있게 한다.

 게다가 시스템 퍼포먼스에 있어서 그것은 명백히 영향을 주는데, DMA는 메모리 포렌식에 있어서 중요한 파급효과를 갖는다. 이는 기계에서 동작중인 신뢰할 수 없는 소프트웨어를 포함하지 않는 주변 장치로부터 물리적인 메모리의 내용에 대해 직접 접근할 수 있는 메커니즘을 제공한다. 예를 들어 PCI 버스는 장치들이 변환을 시작하도록 하는 버스의 조정을 요구할 수 있는 버스 마스터를 실행할 수 있는 장치들을 지원한다. 그 결과 버스마스터 기능 및 DMA를 지원하는 PCI 장치는 CPU를 포함하지 않고 시스템 메모리에 액세스 할 수 있다. 

 다른 예로 IEEE 1394 인터페으스는 공통적으로 방화벽에 대하여 언급한다. 이 IEEE 1394 호스트 컨트롤러 칩은 주변 장치와 빠른 속도로 연결될 수 있도록 확정된 peer-to-peer 시리얼을 제공한다. IEEE1394 인터페이스가 일반적으로 higher-end systems에서 나타남에도 불구하고 우리는 확장된 카드를 사용하는 노트북이나 데스크탑을 인터페이스에 추가할 수가 있다.

Volatile Memory (RAM)

 PC의 메인 메모리는 프로세서가 접근하거나 저장할 수 있는 데이터나 코드들을 저장하고 있는 random access memory(RAM)과 함께 구성이 된다. 연속적으로 저장장치에 접근하는 디스크와는 대조적으로, 매체에서 데이터가 어디에 저장되어 있는지에 상관 없이 일저안 접근 시간을 갖는 기능을 하는 것이 바로 임의 접근이다. 대부분의 PC의 메인 메모리는 Dynamic RAM(DRAM)의 형태를 갖고 있다. 그것은 데이터의 한 비트의 저장을 위한 축전기의 배출과 충전의 사이에서 차이를 갖기에 동적이다. 이러한 상태를 유지하기 위하여 축전기는 "refreshed" 되어야만 하며 이는 일반적으로 메모리 컨트롤러에서 진행한다. 

 RAM은 접근할 수 있는 데이터를 유지하기 위해서는 전원이 요구되기 때문에 휘발성 메모리라 할 수 있다. 그러므로 콜드 부트 공격의 경우를 제외하고는 전원이 차단되면 휘발성 메모리는 손실된다. 이는 시스템의 현재 상태와 관련이 되는 증거를 보존하고자 한다면 "전원을 뽑아"라는 말이 사고대응에서 적절치 못하다고 할 수 있는 이유이다.

CPU Architectures

 이전에 언급한 바와 같이 CPU는 컴퓨터 시스템의 가장 중요한 요소이다. 악성코드가 컴퓨터 보안과 어떻게 타협하는지에 대한 이해와 물리 메모리로부터 구조를 효율적으로 추출하기 위해 메모리 접근을 위해 CPU가 제공하는 프로그래밍 모델에 대한 이해가 필요하다. 비록 이전의 섹션에서 하드웨어의 물리구조에 초점을 맞추었다면 이번 섹션에서는 운영체제에 드러나는 논리구조에 초점을 맞출 것이다. 이번 섹션은 메모리 분석을 위하여 밝혀진 몇가지 기능들에 강조를 할 것이며 CPU 구조와 관련된 몇가지 주제에 대한 언급으로 시작할 것이다. 특히, 해당 섹션에서는 32-bit(IA-32)와 64-bit(Intel 64) 구조에 초점을 맞출 것이다.

Address Spaces

 CPU가 메인 메모리에 저장되어 있는 데이터에 접근하거나 명령어를 실행시키기 위하여 그 데이터의 유니크한 주소에 대하여 지정하여야만 한다. 이 책에서 논의되는 프로세서는  바이트 시퀀스로서 메모리에 접근되거나 바이트 어드레싱을 활용한다. 주소공간은 메모리에 한정된 만큼 할당되어 저장된 데이터의 확인을 위하여 사용되는 다양한 주소의 범위를 나타낸다.특히 이 책에서는 8-bit(1Byte)로 정의된 시스템에 초점을 맞추고 있으며 이러한 주소체계는 일반적으로 0으로 시작해서 할당 메모리의 마지막 바이트의 오프셋에서 끝을 보인다. 실행중인 프로그램에 노출된 단일 연속된 주소 공간은 선형 주소 공간이라고 불린다. 이 책에서 언급되는 메모리 모델과 그들이 사용하는 페이징에 기초하여 우리는 가상 주소와 선형 주소라는 용어를 사용한다. 우리는 프로세서가 실제 메모리에 액세스 요청하는 주소를 물리적인 물리적인 주소 공간이라는 용어를 사용한다. 이 주소들은 선형 주소를 물리주소로 변환하거나 하나 또는 그 이상의 페이지 테이블을 사용하여 얻어진다. 이후의 섹션에서는 어떻게 메모리 주소 공간이 다른 프로세서 구조에서 구성이 되는지에 대하여 이야기 할 것이다.           (+ raw와 padded 메모리 덤프를 다룰 때, 물리 주소는 본질적으로 메모리 덤프 파일에서 오프셋으로 나타낸다.)

Intel IA-32 Architecture

 IA-32구조는 공통적으로 32비트 컴퓨테이션을 지원하는 x86 구조를  참고한다. 특히 이는 명령어 셋과 인텔 32비트 프로세스를 위한 프로그래밍 환경을 지정한다. IA-32에서는 바이트 어드레싱에서 리틀 엔디언 메커니즘을 사용하며 IA-32 프로세서에서 동작중인 소프트웨어는 선형 주소 공간과 물리 주소 공간을 4GB까지 갖을 수가 있고, 이후에 볼 수 있듯이 IA-32 Physical Address Extension(PAE)에서는 물리 주소의 크기를 64GB까지 확장할 수가 있다. 이번 섹션과 이 책의 나머지 부분에서는 가상 메모리와 페이징, 특권 권하느 세그멘테이션과 같은 긴능을 지원하는 IA-32구조의 protected-mode 작업에 초점을 맞출 것이다. 이것은 프로세서와 현대 실행되는 운영체제에서의 기본 상태이다.

Registers

 IA-32 구조에서는 CPU가 프로세싱에서 임시 저장공간으로 사용하는 레지스터라 불리는 매우 빠른 메모리의 작은 규모를 정의하고 있다.각 프로세서의 핵심은 지역적, 여ㄴ산적 몇몇 레지스터들은 프로세서의 행동을 조정하는데에 목적을 두고 있다. 

 EIP 레지스터는 다음에 실행될 명령어의 선형주소를 포함하고 있으며 IA-32 구조는 프로세서와 실행중인 작업의 특성의 상태를 나타내는 다섯 개의 컨트롤 레지스터들이 존재한다. CR0은 페이징 가능한 플래그를 포함한 프로세서의 운영 모드를 조정하는 플래그를 포함하고 있으며 CR1은 접근할 수 없는 예악된 공간이며 CR2는 페이지 폴트로 야기되는 선형주소를 포함하고 있다. CR3는 주소 변환에 사용 되는 초기 구조의 물리적인 주소를 포함하고 있으며 이는 새로운 작업이 스케쥴 될 때 내용이 스위치 되는 동안에 업데이트 된다. CR4는 PAE를 포함한 건축 확장을 가능하게 하기 위하여 사용 된다.

Segmentation

 IA-32 프로세스는 두개의 메모리 관리 메커니즘을 구현한다. 하나는 세그멘테이션이고 다른 하나는 페이징이다. 우선 세그멘테이션에 대하여 먼저 알아보면 세그멘테이션은 32-bit 선형 주소를 여러개의 다양한 길이의 세그먼트로 나눈세그먼트에 의해 구분된 다. 모든 IA-32메모리 참고는 16비트의 세그먼트 셀렉터와 32비트 오프셋를 사용하여 어드레스된다. 세그먼트 디스크립터는 주어진 세그먼트에 따른 권한과 유형, 사이즈, 지역을 정의한는 메모리 레지던트 데이터 구조이다. 각 프로세서의 핵심은 각각 GDT와 LDT라 불리는 세그먼트 디스크립터들의 테이블을 가리키는 GDTR과 LDTR을 포함한다. CS, SS, DS, ES, FS, GS와 같은 세그먼트 레지스터들은 항상 다양한 세그먼트 셀렉터들을 포함하고 있다.

 세그멘테이션이 필수 적인 반면에 이 책에서 언급되는 운영 체제들은 베이스 어드레스 제로와 함께 중복된 세그먼트의 집합을 정의하므로 세그먼트 어드레싱을 감춘다. 이에 의해 단일 연속 "flat" 어드레스 공간을 만든다. 하지만 세그멘테이션 보호는 여전히 각 세그먼트를 위하여 강요되며 분리된 세그먼트 디스크립터들은 데이터와 코드를 참고할때 사용되어야만 한다.

* 대부분의 운영체제들이 IA-32 세그멘테이션 모델의 많은 장점을 더이상 갖지 않기 때문에 분리된 어드레싱은 64 비트 모델에서는 사용할 수가 없다.

Paging

 페이징은 선형 주소 공간의 가상화 기능을 제공한다. 이는 디스크 저장소와 물리 메모리의 거대한 규모와 함께 가상화된 거대한 선형 주소 공간 실행 환경을 생성한다. 각 32비트 선형 주소 공간은 임의의 순서로 메모리에 맵핑 될 수 있는 페이지라는 고정된 길이 공간의 섹션으로 나누어 진다. 프로그램이 선형 주소에 접근을 시도할 때, 이러한 맵핑은 선형 주소를 물리 주소로 변환하는데 사용하는 메모리 레지던트 page directories와 page table을 사용한다. Fihure 1-2에서와 같이 4KB 페이지의 일반적인 시나리오에서는 32비트 가상 주소는 물리 페이지와 연관이 있거나 페이징 계층 구조에서 인덱스로서 사용되는 세 부분의 섹션으로 나누어진다.

 또한 IA-32 구조에서는변환에 있어 페이지 디렉터리를 요구하는 4MB의 페이지를 지원한다. 다른 프로세스를 위해 다른 페이징 구조를 사용하는 것은 운영체제가 가상화된 선형 주소 공간을 통한 단일-프로그램 환경의 특성을 가진 각 프로세스를 제공하게 할 수 있다. Figure 1-3에서는 물리 주소에서 오프셋으로 가상 주소가 변환된 비트에 대하여 확인할 수가 있다.

page directory entry(PDE) 주소를 선정하는 것은 가상 주소로 부터 31:22비트와 CR3 레지스터로부터 31:12비트를 조합하여야 한다. 게다가 PDE로부터 31:12비트와 가상 주소의 21:12 비트를 결합하여 PTE를 위치시켜야 한다.마지막으로 PTE의 31:12비트와 가상 주소의 11:0비트를 결합하므로 물리주소를 얻을 수가 있다. 이렇게 매뉴얼로 주소를 변환하는 작업으로서 다음 섹션에 적용된 계산을 볼 수가 있을 것이다.

Address Translation

 가상 메모리를 제공하는 CPU 구조의 완전한 지원을 위해서, 볼라틸리티 같은 메모리 포렌식 소프트웨어는 가상 주소 공간을 계산하여야만 하고, 자연스럽게 가상주소에서 물리주소의 변환을 다룰 수 있어야 한다. 수동으로 주소 변환을 하는 것은 어떻게 해당 툴이 동작하는지 이해하는 것과 예상치 못한 동작의 발생 대처에 대한 배경지식을 굳건히 하는데 도움을 줄 것이다.

 이러한 작업을 위하여 ENG-USTXHOU-148을 분석중이라 가정할 것이다. 분석을 하는 동안 가상주소 0x10016270에 대한 참조를 발견하고 PID 1024의 svchost.exe안에 있다는 것을 확인하였다. 이 PID 1024의 CR3에 기초한 페이지 디렉터리는 0x7401000 이다. 이 때 우리는 가까운 근접 공간에 있는 다른 데이터가 무엇인지를 보여주는 물리주소를 찾고자 한다.

 첫 단계로 0x10016270이라는 가상 주소는 주소비트 범위를 가지고 진행을 할 것이기 때문에 헥사값을 바이너리의 형태로  변환하여야 한다. 이를 변환하면 다음과 같다.     0001 0000 0000 0001 0110 0010 0111 0000

 다음으로는 변환 과정에서 사용하는 관련된 오프셋으로 주소를 분해하여야 한다. 이에 대해서는 아래의 테이블 1-1과 같다.

그림 1-2와 1-3에서 보았듯이 PDE의 물리 주소를 4바이트의 엔트리 사이즈에 의한 페이지 디렉터리 인덱스를 곱하여서 계산해야하고 그런 다음 페이지 디렉터리 베이스 0x7401000을 더하여야 한다. 가상 주소로 부터의 10비트는 페이지디렉터리에서 1024엔트리까지 나타낼 수가 있다. 

PDE address = 0x40 * 4 + 0x7401000 = 0x7401100

 이 다음, PDE address에 저장된 물리주소로 부터의 값을 읽을 수 있어야 하며 여기선 값이 리틀 엔디언 방식으로 저장되어 있다는 것을 고려하여야 한다. 이 지점에서, PDE의 값이 0x17bf9067이라 할 것이다. 그림 1-3에 기초하여 PDE의 31:12 비트는 페이지 테이블의 베이스 물리 주소를 제공한다는 것을 알 수가 있으며 가상 주소의 21:12비트는 1024(2^10) 엔트리의 페이지 테이블이 구성되어 있기 때문에 페이지 테이블 인덱스를 제공한다. 이제 페이지 테이블에 따른 4바이트의 엔트리 크기를 PTE의 물리주소에 곱하여야 하며 그런 후 페이지 테이블 베이스를 더하여야 한다.

PTE address = 0x16 * 4 + 0x17bf9000 = 0x17bf9058

 PTE의 값은 0x170b6067에 저장되어 있다할 때, 그림 1-3에서와 같이 우리는 PTE로부터 물리주소가 31:12과 가상주소 11:0비트에서 오는 것을 알 수가 있다. 그러므로 마지막 물리주소 변환은 다음과 같다.

Physical address = 0x170b6000 + 0x270 = 0x170b6270

 이러한 변환을 끝낸 후에 우리는 가상주소 0x10016270이 물리주소 0x170b6270으로 변환되어 있는 것을 확인할 수가 있다. 아래의 그림 1-4는 이러한 과정들이 포함되어 그래피컬하게 나타낸 것이다. 이러한 메모리 샘플에서 바이트 오프셋을 찾을 수가 있고 이에 근접한 관련 아티팩트를 찾을 수가 있다. 이것은 항상 가상 주소에서 접근되어지는 볼라틸리티의 IA32PageMemory와 같은 프로세스이다. 다음 내용에서 , 어떻게 프로세스가 더 큰 가상주소공간을 지원하기 위해 확장하는지를 볼 수가 있다. 이에 대한 전반적인 과정은 그림 1-4를 참고하면 된다.

Physical Address Extension

 IA-32 구조의 페이징 메카니즘은 PAE를 지원한다. 이 확장은 4GB보다 더 큰 물리주소를 지원하는 프로세서를 허용한다. 비록 프로그램이 여전히 4GB 이상의 선형주소를 소유하지만, 메모리 관리 유닛은 확장된 64GB 물리 주소 공간에 해당 주소를 맵핑한다. PAE를 사용할 수 있는 시스템에서는 선형 주소는 다음의 4가지 인덱스로 나누어 진다.

1. Page directory pointer table(PDPT) 2. Page directory(PD) 3. Page table(PT) 4. Page offset

그림 1-5는 32비트 PAE를 사용하여 4KB 페이지를 주소변환하는 예를 보여주고 있다. 여기서 주요 차이점은 페이지 디렉터리 포인터 테이블이라 불리는 페이징 구조 계층에서 이전과는 다른 단계가 소개되어진다는 점이다. 이러한 변경 사항을 감안할 때, CR3 레지스터는 현재 페이지 디렉터리 포인터 테이블의 물리주소를 포함하고 있다.

 그림 1-6은 32비트 PAE 페이징에서 사용되는 페이징 구조 주소에 대한 포멧을 보여준다. PAE가 사용 가능할 때, 첫번째 페이징 테이블은 오직 4(2^2)엔트리이다. 가상주소로 부터의 31:30 해당 비트는 페이지 디렉터리 포인터 테이블 엔트리(PDPTE)를 선택한다. 29:21비트는 512(2^9)PDEs로부터 선택하기 위한 인덱스이다. 만약 PS 플래그가 설정되어 있다면, PDE는 2MB 페이지를 맵핑한다. 그렇지 않으면 20:12비트에서 추출한 9비트가 512(2^9) PTE들로부터 선택되어진다. 모든 엔트리가 사용가능하며 주소가 4KB로 맵핑된다고 가정할 때 가상주소의 마지막 12비트는 PA에 상응하는 페이지에 대한 오프셋을 지정한다.

Intel 64 Architecture

 인텔 64구조에서의 실행환경은 IA-32와 유사하지만 몇 가지 다른 점이 존재한다. IA-32 구조에서 강조했던 레지스터들은 여전히 인텔 64구조에서도 존재하고 있긴 하지만 64비트로 확장되었다는 점이다. 가장 중요한 변화는 인텔 64가 64비트 선형주소를 지원한다는 점인데 그 결과, 인텔64구조는 2^64까지 확장된 주소를 지원한다. 이 글을 쓰는 시점에서 해당 구조의 가장 중요한 요점은 64비트 엔트리를 지원하지 못한다는 것이며 오직 48비트 선형주소를 지원한다는 것을 주의하여야 한다. 그 결과로 이러한 시스템에서의 가상주소는 규범적인 형태를 갖는다. 이는 63:48 비트가 앞의 47비트의 상태에 따라 모두 1이나 0으로 설정이된다는 것을 의미한다. 예를 들어 0xfffffa800ccc0b30이라는 주소는 47비트가 설정되어 있기 때문에 63:48 비트를 갖는다.(이 또한 부호확장으로 알려져 있다.)

 메모리 포렌식에서 직접적인 영향을 갖기 때문에 이러한 메모리 관리의 변화에 초점을 맞추는 것은 중요하다. 가장 중요한 차이점은 페이지 맵 레벨 4(PML4)라 불리는 페이징 구조의 추가적인 단계를 현재 인텔 64 구조가 지원한다는 것이다. 페이징 구조 계층에서의 모든 엔트리는 64비트이며, 이것들은 1GB나 2MB나 4KB의 크기의 페이지로 가상주소에서 맵핑될 수 있다는 것이다. 아래의 그림 1-7은 64비트/IA-32e 페이징을 사용한 4KB 페이지를 변환하는 주소의 예를 보여준다.

 그림 1-8은 64비트/IA-32e paging에서 사용되는 페이징 구조 주소에 대한 형태를 보여준다. 페이징 구조는 각 각 512엔트리(2^9)로 구성되며 이들은 48비트 가상주소로부터 얻어지는 다음의 범위에 따라 추출된 값에 의하여 나타내어진다. 

PML4E offset : Bits 47:39,  PDPTE offset : Bits 38:30,  PDE offset : Bits 29:21,  PTE offset : Bits 20:12

 어떻게 다른 페이징 구조 엔트리 플래그가 모메리 포렌식에 영향을 미치는지에 대해 자세하게 궁금하다면, 인텔 매뉴얼이나 볼라틸리티 AMD64PagedMemory 주소 공간을 확인하는 것이 좋다.

Interrupt Descriptor Table

 PC 아키텍처는 종종 특권 모드 소프트웨어 루틴을 조정하기 위해 컨트롤을 통과시키거나 프로세스 실행을 중단하기 위한 메커니즘을 제공한다. IA-32와 인텔 64구조에서는 이 루틴이 Interrupt Descriptor Table(IDT) 안에 저장되어 있다. 각 프로세서는 자신의 IDT는 256 8-바이트 또는 16-바이트엔트리로 구성되어 있으며 첫 32엔트리들은 예외와 인터럽트를 위해 정의된 프로세서에 대한 예약되어있다. 각 엔트리는 특정 예외나 인터럽트를 조정할 수 있는 Interrupt service routine의 주소를 포함하고 있다.이러한 예외나 인터럽트에 대한 이벤트에 있어서 지정된 인터럽트 번호는 IDT 인덱스의 역할을 하며 CPU는 각각의 핸들러를 호출한다.

 대부분의 인터럽트 발생 후, 운영체제는 인터럽트 된 곳에서 실행을 재개할 것이다. 예를 들어, 만약 스레드가 사용할 수 없는 메모리 페이지에 접근하고자 시도한다면 이는 페이지 폴트를 생성한다. 0xE 핸예외 번호는 x86이나 인텔64구조에서 페이지 폴트를 조정한다. 그러므로, 0xE IDT 엔트리는 운영체제의 페이지 폴트 핸들러에 대해 나타내는 기능을 포함하고 있다. 페이지 폴트 핸들러가 실행되면 제어는 메모리 페이지에 접근하려는 스레드를 반환할 수 있다. 또한 운영체제는 시스템 콜이나 디버거 브레이크포인트나 다른 폴트들을 포함하는 수 많은 이벤트들에 대한 핸들러를 IDT에 저장하고 있다.

nt!_PEB
+0x000 InheritedAddressSpace : UChar
+0x001 ReadImageFileExecOptions : UChar
+0x002 BeingDebugged : UChar
+0x003 SpareBool : UChar
+0x004 Mutant : Ptr32 Void
+0x008 ImageBaseAddress : Ptr32 Void
+0x00c Ldr : Ptr32 _PEB_LDR_DATA
+0x010 ProcessParameters : Ptr32 _RTL_USER_PROCESS_PARAMETERS
+0x014 SubSystemData : Ptr32 Void
+0x018 ProcessHeap : Ptr32 Void
+0x01c FastPebLock : Ptr32 _RTL_CRITICAL_SECTION
+0x020 FastPebLockRoutine : Ptr32 Void
+0x024 FastPebUnlockRoutine : Ptr32 Void
+0x028 EnvironmentUpdateCount : Uint4B
+0x02c KernelCallbackTable : Ptr32 Void
+0x030 SystemReserved : [1] Uint4B
+0x034 AtlThunkSListPtr32 : Uint4B
+0x038 FreeList : Ptr32 _PEB_FREE_BLOCK
+0x03c TlsExpansionCounter : Uint4B
+0x040 TlsBitmap : Ptr32 Void
+0x044 TlsBitmapBits : [2] Uint4B
+0x04c ReadOnlySharedMemoryBase : Ptr32 Void
+0x050 ReadOnlySharedMemoryHeap : Ptr32 Void
+0x054 ReadOnlyStaticServerData : Ptr32 Ptr32 Void
+0x058 AnsiCodePageData : Ptr32 Void
+0x05c OemCodePageData : Ptr32 Void
+0x060 UnicodeCaseTableData : Ptr32 Void
+0x064 NumberOfProcessors : Uint4B
+0x068 NtGlobalFlag : Uint4B
+0x070 CriticalSectionTimeout : _LARGE_INTEGER
+0x078 HeapSegmentReserve : Uint4B
+0x07c HeapSegmentCommit : Uint4B
+0x080 HeapDeCommitTotalFreeThreshold : Uint4B
+0x084 HeapDeCommitFreeBlockThreshold : Uint4B
+0x088 NumberOfHeaps : Uint4B
+0x08c MaximumNumberOfHeaps : Uint4B
+0x090 ProcessHeaps : Ptr32 Ptr32 Void
+0x094 GdiSharedHandleTable : Ptr32 Void
+0x098 ProcessStarterHelper : Ptr32 Void
+0x09c GdiDCAttributeList : Uint4B
+0x0a0 LoaderLock : Ptr32 Void
+0x0a4 OSMajorVersion : Uint4B
+0x0a8 OSMinorVersion : Uint4B
+0x0ac OSBuildNumber : Uint2B
+0x0ae OSCSDVersion : Uint2B
+0x0b0 OSPlatformId : Uint4B
+0x0b4 ImageSubsystem : Uint4B
+0x0b8 ImageSubsystemMajorVersion : Uint4B
+0x0bc ImageSubsystemMinorVersion : Uint4B
+0x0c0 ImageProcessAffinityMask : Uint4B
+0x0c4 GdiHandleBuffer : [34] Uint4B
+0x14c PostProcessInitRoutine : Ptr32 void 
+0x150 TlsExpansionBitmap : Ptr32 Void
+0x154 TlsExpansionBitmapBits : [32] Uint4B
+0x1d4 SessionId : Uint4B
+0x1d8 AppCompatFlags : _ULARGE_INTEGER
+0x1e0 AppCompatFlagsUser : _ULARGE_INTEGER
+0x1e8 pShimData : Ptr32 Void
+0x1ec AppCompatInfo : Ptr32 Void
+0x1f0 CSDVersion : _UNICODE_STRING
+0x1f8 ActivationContextData : Ptr32 Void
+0x1fc ProcessAssemblyStorageMap : Ptr32 Void
+0x200 SystemDefaultActivationContextData : Ptr32 Void
+0x204 SystemAssemblyStorageMap : Ptr32 Void
+0x208 MinimumStackCommit : Uint4B

typedef struct _KPROCESS
{
     DISPATCHER_HEADER Header;
     LIST_ENTRY ProfileListHead;
     ULONG DirectoryTableBase;
     ULONG Unused0;
     KGDTENTRY LdtDescriptor;
     KIDTENTRY Int21Descriptor;
     WORD IopmOffset;
     UCHAR Iopl;
     UCHAR Unused;
     ULONG ActiveProcessors;
     ULONG KernelTime;
     ULONG UserTime;
     LIST_ENTRY ReadyListHead;
     SINGLE_LIST_ENTRY SwapListEntry;
     PVOID VdmTrapcHandler;
     LIST_ENTRY ThreadListHead;
     ULONG ProcessLock;
     ULONG Affinity;
     union
     {
          ULONG AutoAlignment: 1;
          ULONG DisableBoost: 1;
          ULONG DisableQuantum: 1;
          ULONG ReservedFlags: 29;
          LONG ProcessFlags;
     };
     CHAR BasePriority;
     CHAR QuantumReset;
     UCHAR State;
     UCHAR ThreadSeed;
     UCHAR PowerState;
     UCHAR IdealNode;
     UCHAR Visited;
     union
     {
          KEXECUTE_OPTIONS Flags;
          UCHAR ExecuteOptions;
     };
     ULONG StackCount;
     LIST_ENTRY ProcessListEntry;
     UINT64 CycleTime;
} KPROCESS, *PKPROCESS;

출처 : http://www.nirsoft.net/kernel_struct/vista/KPROCESS.html

typedef struct _EPROCESS
{
     KPROCESS Pcb;
     EX_PUSH_LOCK ProcessLock;
     LARGE_INTEGER CreateTime;
     LARGE_INTEGER ExitTime;
     EX_RUNDOWN_REF RundownProtect;
     PVOID UniqueProcessId;
     LIST_ENTRY ActiveProcessLinks;
     ULONG QuotaUsage[3];
     ULONG QuotaPeak[3];
     ULONG CommitCharge;
     ULONG PeakVirtualSize;
     ULONG VirtualSize;
     LIST_ENTRY SessionProcessLinks;
     PVOID DebugPort;
     union
     {
          PVOID ExceptionPortData;
          ULONG ExceptionPortValue;
          ULONG ExceptionPortState: 3;
     };
     PHANDLE_TABLE ObjectTable;
     EX_FAST_REF Token;
     ULONG WorkingSetPage;
     EX_PUSH_LOCK AddressCreationLock;
     PETHREAD RotateInProgress;
     PETHREAD ForkInProgress;
     ULONG HardwareTrigger;
     PMM_AVL_TABLE PhysicalVadRoot;
     PVOID CloneRoot;
     ULONG NumberOfPrivatePages;
     ULONG NumberOfLockedPages;
     PVOID Win32Process;
     PEJOB Job;
     PVOID SectionObject;
     PVOID SectionBaseAddress;
     _EPROCESS_QUOTA_BLOCK * QuotaBlock;
     _PAGEFAULT_HISTORY * WorkingSetWatch;
     PVOID Win32WindowStation;
     PVOID InheritedFromUniqueProcessId;
     PVOID LdtInformation;
     PVOID VadFreeHint;
     PVOID VdmObjects;
     PVOID DeviceMap;
     PVOID EtwDataSource;
     PVOID FreeTebHint;
     union
     {
          HARDWARE_PTE PageDirectoryPte;
          UINT64 Filler;
     };
     PVOID Session;
     UCHAR ImageFileName[16];
     LIST_ENTRY JobLinks;
     PVOID LockedPagesList;
     LIST_ENTRY ThreadListHead;
     PVOID SecurityPort;
     PVOID PaeTop;
     ULONG ActiveThreads;
     ULONG ImagePathHash;
     ULONG DefaultHardErrorProcessing;
     LONG LastThreadExitStatus;
     PPEB Peb;
     EX_FAST_REF PrefetchTrace;
     LARGE_INTEGER ReadOperationCount;
     LARGE_INTEGER WriteOperationCount;
     LARGE_INTEGER OtherOperationCount;
     LARGE_INTEGER ReadTransferCount;
     LARGE_INTEGER WriteTransferCount;
     LARGE_INTEGER OtherTransferCount;
     ULONG CommitChargeLimit;
     ULONG CommitChargePeak;
     PVOID AweInfo;
     SE_AUDIT_PROCESS_CREATION_INFO SeAuditProcessCreationInfo;
     MMSUPPORT Vm;
     LIST_ENTRY MmProcessLinks;
     ULONG ModifiedPageCount;
     ULONG Flags2;
     ULONG JobNotReallyActive: 1;
     ULONG AccountingFolded: 1;
     ULONG NewProcessReported: 1;
     ULONG ExitProcessReported: 1;
     ULONG ReportCommitChanges: 1;
     ULONG LastReportMemory: 1;
     ULONG ReportPhysicalPageChanges: 1;
     ULONG HandleTableRundown: 1;
     ULONG NeedsHandleRundown: 1;
     ULONG RefTraceEnabled: 1;
     ULONG NumaAware: 1;
     ULONG ProtectedProcess: 1;
     ULONG DefaultPagePriority: 3;
     ULONG PrimaryTokenFrozen: 1;
     ULONG ProcessVerifierTarget: 1;
     ULONG StackRandomizationDisabled: 1;
     ULONG Flags;
     ULONG CreateReported: 1;
     ULONG NoDebugInherit: 1;
     ULONG ProcessExiting: 1;
     ULONG ProcessDelete: 1;
     ULONG Wow64SplitPages: 1;
     ULONG VmDeleted: 1;
     ULONG OutswapEnabled: 1;
     ULONG Outswapped: 1;
     ULONG ForkFailed: 1;
     ULONG Wow64VaSpace4Gb: 1;
     ULONG AddressSpaceInitialized: 2;
     ULONG SetTimerResolution: 1;
     ULONG BreakOnTermination: 1;
     ULONG DeprioritizeViews: 1;
     ULONG WriteWatch: 1;
     ULONG ProcessInSession: 1;
     ULONG OverrideAddressSpace: 1;
     ULONG HasAddressSpace: 1;
     ULONG LaunchPrefetched: 1;
     ULONG InjectInpageErrors: 1;
     ULONG VmTopDown: 1;
     ULONG ImageNotifyDone: 1;
     ULONG PdeUpdateNeeded: 1;
     ULONG VdmAllowed: 1;
     ULONG SmapAllowed: 1;
     ULONG ProcessInserted: 1;
     ULONG DefaultIoPriority: 3;
     ULONG SparePsFlags1: 2;
     LONG ExitStatus;
     WORD Spare7;
     union
     {
          struct
          {
               UCHAR SubSystemMinorVersion;
               UCHAR SubSystemMajorVersion;
          };
          WORD SubSystemVersion;
     };
     UCHAR PriorityClass;
     MM_AVL_TABLE VadRoot;
     ULONG Cookie;
     ALPC_PROCESS_CONTEXT AlpcContext;
} EPROCESS, *PEPROCESS;