(1) 악성코드 분석가 입장에서 본 PE 구조
1. 악성코드와 PE(Portable Executable)파일의 조우
PE 파일이라 부르는 형식은 플랫폼에 관계없이 Win32 운영체제 시스템이면 어디든 실행 가능한 프로그램을 뜻한다. PE 파일(*.EXE, *.DLL)의 실행을 위해서는 운영체제에 실행 파일의 정보를 제공할 필요가 있는데, 예를 들면 실행 파일의 기계어 코드 위치, 아이콘 및 그림파일 등의 위치, 해당 파일이 실행될 수 있는 플랫폼의 종류, 운영체제가 파일을 실행 시킬 때 첫 시작 코드의 위치 등 수많은 정보를 제공하여야 한다. 이와 같은 다양한 정보들이 저장된 곳이 PE 파일의 처음에 위치한 PE 헤더 구조체이다.
악성 코드를 분석하여 보면 PE 헤더 구조체에 흥미로운 정보들이 많이 존재하고 있음을 알 수 있다. 악성 코드의 크기를 줄이기 위해 헤더 정보를 속이거나, 바이러스에 감염되어 원본 파일의 헤더가 변경 되기도 한다. 또한 특정 악성코드만의 고유한 정보가 숨어 있기도 하며, 일반 정상파일에서는 있을 수 없는 값들이 들어 있기도 하다.
2. 현재의 악성코드가 DOS 시절의 헤더를 이용한다?
PE 파일은 IMAGE_DOS_HEADER 구조체로 시작한다. 이는 DOS 시절에 사용되던 실행 파일의 헤더로서 실행 파일이 DOS에서 실행 되었을 때 DOS 운영체제에 알려줘야 할 정보들이 담겨 있다. 다음은 IMAGE_DOS_HEADER 구조체이다.
typedef struct _IMAGE_DOS_HEADER // DOS .EXE header
{
WORD e_magic; // Magic number
WORD e_cblp; // Bytes on last page of file
WORD e_cp; // Pages in file
WORD e_crlc; // Relocations
WORD e_cparhdr; // Size of header in paragraphs
WORD e_minalloc; // Minimum extra paragraphs needed
WORD e_maxalloc; // Maximum extra paragraphs needed
WORD e_ss; // Initial (relative) SS value
WORD e_sp; // Initial SP value
WORD e_csum; // Checksum
WORD e_ip; // Initial IP value
WORD e_cs; // Initial (relative) CS value
WORD e_lfalc; // File address of relocation table
WORD e_ovno; // Overlay number
WORD e_oemid; // OEM identifier (for e_oeminfo)
WORD e_oeminfo; // OEM information; e_oemid specific
WORd e_res2[10]; // Reserved words
LONG e_lfanew; // File address of new exe header
} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;
그러나, 이것은 DOS 운영체제를 위해 제공하는 정보들이기 때문에 현재 Windows 환경에서는 필요치 않다. 대다수의 필드들은 무시되며 e_magic 및 e_lfanew 필드만이 유용한 정보가 된다. e_magic 필드는 IMAGE_DOS_HEADER의 시작을 나타내는 것으로 항상 'MZ'라는 문자열로 시작을 한다. 그리고 e_lfanew 필드는 IMAGE_DOS_HEADER 다음에 나오는 헤더 파일의 오프셋 값을 가지고 있다. 그 외의 필드들은 Windows에서 파일을 실행시켰을 때 이용되지 않는다. 다음 [그림 3-1]은 일반적인 실행 파일의 IMAGE_DOS_HEADER의 값이다.
[그림 3-1] IMAGE_DOS_HEADER 정보
이 위의 값들은 만일 DOS Mode 실행 시 Dos Stub 실행을 목적으로 지정된 값들로 이 헤더 뒤에 따르는 문자열 "This program cannot be run in DOS mode"을 출력해 주기 위해 지정된 값들이다. Dos가 아닌 Windows 모드에서 실행 시켰을 경우에는 이용되지 않는다. 그러나 몇몇 악성코드를 분석하다 보면 실제 사용되지 않는 필드 값들이 악성코드에 의해 사용 되고 있는 흥미로운 사실을 발견할 수 있다. 다음 [그림 3-2]는 악성코드에서 많이 사용되는 실행압축 방식의 하나인 Upack의 IMAGE_DOS_HEADER 부분이다.
[그림 3-2] Upack의 IMAGE_DOS_HEADER 정보
앞서 설명한 IMAGE_DOS_HEADER 와는 확연한 차이를 보인다. e_magic 및 e_lfanew 필드 이외의 값들이 'KERNEL32.DLL', 'LoadLibraryA', 'GetProcAddress' 등의 문자열로 채워진 것을 확인 할 수 있다. 이들 문자열들은 동적링크를 위한 함수 호출에 필요한 문자열들로 실행압축인 Upack에서 필요한 라이브러리 함수(DLL)들을 가져다 쓰는 루틴을 위해 존재한다. 여기서는 범용 실행압축 모듈인 Upack을 통해 실제 이용되지 않는 필드들을 활용하는 사례를 다루었지만, 악성코드들 역시 필요한 정보들의 보관을 위해 IMAGE_DOS_HEADER의 빈 공간을 적절히 이용하고 있다.
3. e_lfanew 필드가 IMAGE_DOS_HEADER 범위 안을 가리키고 있다?
IMAGE_DOS_HEADER의 e_lfanew 필드는 다음에 올 헤더 위치의 파일 오프셋을 가리키고 있다. 즉, 실제 PE 파일의 시작이라고 할 수 있는 IMAGE_NT_HEADER의 시작 오프셋 값을 가지고 있다. 다음 [그림 3-3]은 일반적인 실행 파일의 e_lfanew 필드의 값인 0x0000000E 위치의 값을 보여준다.
[그림 3-3] IMAGE_DOS_HEADER의 e_lfanew 정보
위 그림과 같이 일반적인 실행 파일은 다음에 올 헤더 위치의 파일 오프셋을 가리키고 있다. 0x000000E0 위치에 있는 헤더는 IMAGE_NT_HEADER로써 다음과 같은 구조체로 정의가 되어 있다.
typedef struct _IMAGE_NT_HEADERS
{
DWORD Signature;
IMAGE_FILE_HEADER FileHeader;
IMAGE_OPTIONAL_HEADER32 OptionalHeader;
} IMAGE_NT_HEADER32, *PIMAGE_NT_HEADER32;
첫 필드인 Signature는 PE 헤더의 시작을 알리는 값으로 'PE'라는 문자열이 들어가게 된다. 그렇기 때문에 IMAGE_DOS_HEADER의 e_lfanew 필드가 가리키는 위치를 가보면 'PE\0\0'과 같은 문자열이 나타나게 된다. IMAGE_FILE_HEADER와 IMAGE_OPTIONAL_HEADER32는 PE 구조체의 세부적인 값들로 지정된 구조체이다. 그럼 e_lfanew 필드는 언제나 자신보다 뒤에 있는 영역을 가리키고 있는 것일까? 일반적인 실행파일의 경우 그렇다고 할 수 있다. 그러나 몇몇 악성코드들에서는 다음 [그림 3-4]와 같은 모습이 보여지기도 한다.
[그림 3-4] 악성코드에서의 특이한 e_lfanew 정보의 예
일반적인 실행파일과 다르게 IMAGE_DOS_HEADER의 e_lfanew 필드가 자신보다 앞의 영역을 가리키고 있다. 이와 같이 다소 일반적이지 않은 형태로 구조체가 정의 되더라도 각 필드에 맞는 값들이 채워진다면 운영체제가 파일을 읽어 들여서 실행하는 것에는 문제가 되지 않는다. 특히 IMAGE_DOS_HEADER의 첫 필드와 마지막 필드를 제외하고는 현재 이용되지 않기 때문에 전혀 문제가 되지 않는다. 단, IMAGE_NT_HEADER 구조체의 시작이 앞으로 이동하게 되면 e_lfanew 필드 값이 PE 헤더 값과 겹치게 되므로, e_lfanew 필드 값과 매칭되는 PE 헤더의 값(BaseOfData)에 문제가 없어야만 한다.
다음 [그림 3-5]를 살펴보면 IMAGE_DOS_HEADER의 e_lfanew 필드는 파일 오프셋으로 0x00000010을 가리키고 있다. 그리고 IMAGE_NT_HEADER의 앞부분에 위치한 이용되지 않는 IMAGE_DOS_HEADER의 영역에 'KERNEL32.DLL' 문자열을 숨겨 두었다. IMAGE_NT_HEADER를 보면 PE 헤더의 시작 뒤를 보면 파일 오프셋 0x0000002A 부분부터 'LoadLibraryA' 문자열이 있는 것을 확인할 수 있다.
[그림 3-5] 악성코드가 삽입한 IMAGE_DOS_HEADER 내의 문자열 정보
해당 영역은 IMAGE_NT_HEADER에 멤버로 등록된 구조체인 IMAGE_OPTIONAL_HEADER의 영역으로 각 대칭되는 필드는 다음 그림 [3-6]과 같다.
[그림 3-6] IMAGE_OPTIONAL_HEADER 정보
Major Linker Version, Minor Linker Version, SizeOfCode, SizeOfInitializedData, SizeOfUninitializedData의 값이 된다. Major 및 Minor Linker Version 필드는 실행파일을 만든 링커의 버전을 담고 있으며, SizeOfCode 필드는 모든 코드 섹션들의 사이즈를 합한 크기이다. SizeOfInitializedData 필드는 코드 섹션을 제외한 초기화된 데이터 섹션의 전체 크기를 나타내며, SizeOfUninitializedData 필드는 초기화되지 않은 데이터 섹션의 바이트 수를 나타낸다. 일반적인 실행파일의 경우 이러한 값들은 거의 쓰이지 않는다.
4. 다른 컴퓨터의 정상적인 실행 파일과 내 컴퓨터의 정상적인 실행 파일이 다르다?
일반적으로 같은 플랫폼에서의 같은 실행 파일의 경우 직접 링커를 통해 실행 파일을 만들지 않는 이상(즉, 일반적으로 제공되는 어플리케이션을 설치했을 경우에는) 같은 속성을 가지게 된다. 그러나 이 실행 파일 헤더의 특정 몇몇 부분이 다를 경우에는 실행 파일이 감염 되었음을 의심해 볼 수 있다. [그림 3-7]과 [그림 3-8]에서 진단명 Tufic.C에 감염 전후의 explorer.exe 파일의 차이를 확인해볼 수 있다.
[그림 3-7] Tufic.C 감염 전 Number of Sections 정보
[그림 3-8] Tufic.C 감염 후 Number of Sections 정보
[그림 3-7]은 Tufic.C 감염되기 이전의 IMAGE_NT_HEADER에 속한 IMAGE_FILE_HEADER의 값이며, [그림 3-8]은 감염된 이후의 모습이다. 박스안의 NumberOfSections 필드를 살펴보면 감염된 이후에 값이 1만큼 증가한 것을 확인 할 수 있다. Tufic.C는 원본 파일의 맨 뒤에 바이러스를 첨가 시키는 Appending 바이러스의 한 유형으로 바이러스를 추가할 부분을 만들기 위해 섹션의 수를 하나 증가시켜 놓은 것이다.
[그림 3-9] Tufic.C 감염후 추가된 섹션 정보
[그림 3-9]는 추가된 섹션 헤더의 모습이다. 여기에서 상당히 많은 악성코드 정보를 얻을 수 있으며, 이러한 정보는 악성코드 분석에 큰 도움을 준다. 우선 섹션의 이름은 .adate임을 알 수 있다. Tufic.C와 같이 바이러스 감염 시 섹션 이름을 특정 문자열로 주게되면, 바이러스 감염여부에 대한 기초적인 판단 정보가 되기도 한다. VirtualSize는 감염 파일이 운영체제에 의해 로드 되었을 때, 이 섹션의 이미지상의 크기를 나타내어 준다.
이것은 바이러스 코드의 길이를 짐작 할 수 있다. RVA는 실행 파일이 운영체제에 의해 로드 되었을 때 메모리상의 위치 정보이며, 감염 파일을 분석할 때 바이러스 코드를 확인 할 수 있다. SizeOfRawData는 파일상에서 섹션의 크기에 대해 알 수 있으며, 치료할 때 사용 된다. PointerToRawData는 파일상의 섹션 위치를 알 수 있으며 이것 또한 치료할 때 사용 된다. Characteristics은 해당 섹션의 속성을 나타내는 플래그의 집합이다.
바이러스가 생성한 섹션의 플래그는 IMAGE_SCN_CNT_CODE, _EXECUTE, _READ, _WRITE 등의 속성이 지정되어 있으며 각각은 '코드를 포함하고 있다', '실행 가능한 섹션이다', '읽기 가능 섹션이다', '쓰기 가능 섹션이다'는 것을 의미한다. [그림 3-10]에서와 같이 섹션 정보 이외에 수정되는 것이 더 있는지 확인을 해 보면 중간 부분에서와 같이 몇 개의 필드가 수정된 것을 확인할 수 있다.
[그림 3-10] Tufic.C 감염 전/후의 IMAGE_OPTIONAL_HEADER 정보
IMAGE_NT_HEADER에 속해 있는 IMAGE_OPTIONAL_HEADER32 구조체의 필드 값들이다. 왼쪽이 감염 이전의 explorer.exe 파일이며, 오른쪽이 감염 이후의 explorer.exe 파일이다. 감염 전/후를 비교해 보면, 세 부분이 바뀐 것을 확인 할 수 있는데, 첫 번째 SizeOfCode는 앞서 설명과 같이 모든 코드 섹션의 사이즈를 합한 크기이며 그 크기가 증가한 것을 확인 할 수 있다. 또한 맨 마지막의 SizeOfImage는 운영체제가 이 실행 파일을 로드할 때 확보/예약해야 할 메모리상의 크기를 가리킨다. 이 또한 SizeOfCode가 증가한 크기만큼 증가한 것을 확인 할 수 있다.
중요한 것은 AddressOfEntryPoint 인데 이 부분은 운영체제가 실행 파일을 로드 했을 때, 이 실행 파일의 코드 시작점을 나타낸다. Tufic.C에 감염 되었을 경우에는 이와 같이 코드 진입점이 변경되며 변경된 코드 진입점은 바이러스의 시작 주소를 가리키게 된다. 이것은 바이러스 분석에 결정적 자료가 된다.(물론 이처럼 AddressOfEntryPoint 필드를 변경하지 않고, 실제 시작 코드를 변경하는 바이러스들도 존재한다.) 변경된 원본 AddressOfEntryPoint는 바이러스가 나중에 원본 파일을 정상 실행 시키기 위해서 임의의 위치에 백업을 해 둔다.
5. Import Address Table 정보를 이용한 악성코드 분석
DLL(Dynamic Link Library)은 서로 다른 프로그램이 실행된 후 공통적으로 사용하는 함수들을 하나로 묶어두고 이를 필요로 할 때 동적으로 링크하여 사용하는 공유 라이브러리 파일이다. 각각의 프로그램에서 하나의 함수를 공통적으로 사용하게 되므로 메모리가 절약되고, 주 프로그램과 함께 컴파일 되는 정적 링크에 비해 상대적으로 작은 사이즈를 가지는 잇점이 있다.
최대한 간략하게 만들어야 하는 악성코드 역시 필요한 함수를 동적 링크 하는 것이 일반적이므로, 함께 링크되는 DLL 함수 정보를 살펴보면 악성코드가 의도하는 목적을 유추할 수 있다. PE 구조에서 해당 정보를 보관하고 있는 Import Address Table을 찾아가 보기로 한다.
1) PE 파일의 시작(e_magic)에서 0x3C 만큼 이동하면 IMAGE_NT_HEADERS 시작 오프셋 값(e_lfanew)을 찾을 수 있다
2) IMAGE_NT_HEADERS 시작 오프셋(Signature)에서 0x80 만큼 이동한 지점이 Import Directory RVA 구조체 정보이다. 구조체 엔트리에 대한 의미는 WinNT.H 파일에 다음과 같이 정의되어 있다.
typedef struct _IMAGE_DATA_DIRECTORY {
DWORD VirtualAddress;
DWORD Size;
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;
[그림 3-11] Import Directory RVA 정보
3) Import Directory RVA에 대한 FileOffset으로 이동하면 동적으로 링크하는 DLL 파일들의 구조체(IMAGE_IMPORT_DESCRIPTOR)정보를 확인할 수 있다. 다음은 Win-Trojan/Backdoor.40960.B 에서 동적으로 링크하는 DLL 및 그에 따른 함수(Import Address Table) 정보를 일부 발췌한 것이며, 이를 통해 해당 악성코드는 URL 접속 및 정보유출, 불특정 파일 다운로드 등의 증상을 유추해 볼 수 있겠다.
● urlmon.dll: Internet Explorer의 구성요소로, 웹사이트에서 반환된 URL과 정보를 처리한다
● WS2_32.dll: Windows Socket API, WSAStartup 함수를 통해 DLL을 로딩하여 사용한다
[그림 3-12] IMAGE_IMPORT_DESCRIPTOR 정보 (Win-Trojan/Backdoor.40960.B)
[그림 3-13] Import Address Table 정보 (Win-Trojan/Backdoor.40960.B)
6. Import Address Table 정보를 은닉한 악성코드 분석
레지스트리 및 파일 I/O, 소켓연결, 프로세스 관련 함수 호출은 악성코드들이 즐겨 사용하며,이를 통하여 안티바이러스 프로그램 및 분석가들도 악성 여부를 판단하는 기초 자료로 사용한다.
이러한 특성을 인지한 악성코드 제작자들은 치료백신 업데이트 및 분석 지연을 목적으로 DLL 정보 및 호출함수 정보를 은닉하게 되는데 실행압축(Packer), 암호화(Encrypt)등을 사용하는 것이 일반적이며, 일부 악성코드는 PE 구조체의 Import Address Table 정보를 메인루틴 에서 생성하기도 한다.
1) GetProcAddress() 함수주소 획득
호출 함수들의 주소정보 획득을 위해서 DLL 핸들, 함수명을 인자값으로 GetProcAddress()를 호출하며, GetProcAddress() 함수에 대한 주소정보는 메인루틴 상의 kernel32.dll 에서 획득한다. 다음은 Win32/MaDang 에서 GetProcAddress() 함수 주소를 획득하는 과정을 보여준다.
[그림 3-14] GetProcAddress 함수에 대한 주소획득 과정 (Win32/MaDang)
2) 함수명 추출을 위한 서브루틴 호출
LoadLibrary()를 통해 DLL핸들이 확보되면, GetProcAddress() 인자값으로 사용할 함수명을 추출해야 하는데, Win32/MaDang 에서는 다소 변칙적인 함수호출 과정을 이용한다. 일반적인 함수 호출은 서브루틴이 호출되면 복귀주소(Return Address)가 스택에 쌓이고(PUSH) 서브루틴 종료시 복귀주소를 스택에서 꺼내어(POP) 메인루틴으로 복귀하는 과정을 밟는다. 다음은 Win32/MaDang 에서 위와 같은 함수호출 과정으로 스택에 쌓인 값이 복귀주소를 가리키지 않고 함수명을 가리킬 수 있음을 보여준다.
[그림 3-15] 함수명 추출을 위한 서브루틴 호출 과정 (Win32/MaDang)
3) 호출 함수들의 주소정보 획득
다소 변칙적인 함수호출 과정을 통해 필요한 함수명이 스택에 저장되었고 DLL핸들 또한 확보되었다. 최종적으로 GetProcAddress() 함수 호출을 통해 메인루틴에서 사용될 함수들의 주소정보를 모두 획득하면 Import Address Table 이 완성된다.
[그림 3-16] 호출 함수들의 주소정보 획득 과정 (Win32/MaDang)
7. PE(Portable Executable) 구조체와 악성 코드 분석가의 조우
악성코드를 분석하다 보면 이 이외에도 많은 흥미로운 것들을 발견할 수 있다. 그러나 앞에서 언급을 했듯이 모든 악성코드들이 이러한 특성들을 가지고 있는 것은 아니며, 정상 파일은 이러한 특성을 가지지 않는 것은 아니다. 다만 악성코드들에서 발생 빈도가 더 높을 뿐이다.
이러한 정보들은 악성코드의 악의적인 동작들과는 관계가 없는 것들은 많지만, 악성코드를 분석하고 악성/정상을 판단하는 것에 결정적인 힌트가 되어 주기도 한다. 또한 각 악성코드만의 PE 헤더 특성을 악성코드 진단에 이용할 수 있으며 바이러스와 같은 경우에는 정상파일을 감염시켜 PE 헤더의 내용을 바꾸는 동작을 수행할 가능성이 높기 때문에 치료함수를 제작하기 위해서 이러한 PE 헤더의 바뀐 부분에 대한 파악이 중요하다. 그러므로 PE 구조체와 악성코드 분석은 떼어낼래야 뗄 수 없는 관계이다.
[출처] 안철수연구소 ASEC
