DLL ( Dynamic Link Library )

DLL은 동적 링크 라이브러리(Dynamic Link Library)의 약자로 일반적으로 확장자가 DLL인 파일이다. 라이브러리라는 말에서 알 수 있듯이 다른 프로그램에서 이용하는 함수들을 모아둔 것이다. 하지만 표준 C 라이브러리 같은 일반 라이브러리의 파일과는 구조나 사용법이 다소 다르다. 일반 라이브러리는 소스코드를 컴파일한 결과로 생성되는 객체 파일(.OBJ)을 그대로 모아둔 것이다. 링커는 이 중에서 필요한 함수가 포함된 객체 파일을 꺼내서 실행 파일에 결합하는 '정적 링크' 방식이다.

아래 그림은 정적 링크를 나타내는 것으로 C/C++ 프로그램의 소스 코드를 기계어 코드로 변환하는 컴파일 단계를 거치게 된다. 여기서 C/C++에는 수많은 표준함수들이 존재하고 있는데 이들은 표준 라이브러리 파일 안에 어셈블리 코드의 형태로 담겨 있다. 소스 코드는 하나 이상 존재할 수가 있는데, 링크 단계는 이 여러 개의 소스 파일들이 하나의 실행 파일로 구성해낸다. 이때 각각의 소스파일에서 호출한 표준 함수들을 표준 라이브러리에서 가져와 실행파일에 붙여준다. 이러한 과정을 링크 과정이라 한다. 그리고 이러한 방식이 바로 '정적 링크'이다. 

하지만 많은 표준 함수를 사용할수록 프로그램의 크기가 커지게 되며, 똑같은 함수를 사용한다고 하더라도 이러한 정적 링크 방식은 각 프로그램마다 링크 과정에서 라이브러리를 가져와 프로그램 안에 저장하기 때문에 이는 비효율적이라 할 수 있다.

정적 링크 방식과는 다르게 DLL은 '동적 링크'에 방식으로, 이는 링크 시에 실행 파일에 결합되는 것이 아니라 프로그램 실행 시에 DLL도 함께 프로그램의 메모리 공간으로 읽어와 호출될 주소 등을 적절하게 바꾸는 것을 말한다. 일단 읽어온 DLL 함수는 프로그램 내부 함수처럼 호출할 수 있다. DLL은 실행 파일과 다른 파일이므로 필요한 시점에 메모리로 읽어오고 불필요하면 메모리에서 내릴 수 있다.

이러한 방식으로 인해 DLL은 여러 장점을 갖게 된다. 우선 여러 프로그램에서 동시에 사용할 수 있다는 것이다. 정적 링크 방식은 자신이 가진 코드를 자기 혼자만 사용하지만, 동적 링크 방식은 하나의 DLL로 존재하여 다른 프로그램에게 라이브러리를 제공해준다. 실행 파일은 DLL에 있는 함수를 Import하게 되는 것이고, DLL은 실행파일에게 함수를 Export 해주게 되는 것이다.

단, 함수나 변수가 실행 파일 안에 포함되지 않았기 때문에, 사용하고자 하는 함수나 변수를 컴파일러나 링커에게 알려주어야 한다. 만약 Export에 대한 정보가 없다면 실행파일은 DLL의 함수를 Import 할 수 없게 된다. 그러므로 위와 같이 Export 하는 함수에 대한 정보가 DLL에 기록되어 있어야 한다.

DLL Binding

EXE 파일은 사용하고자 하는 DLL의 함수를 메모리에 같은 메모리상에 올리게 되는데 이때 IAT에는 실제 사용하고자 함수들의 주소가 오게 된다. 다시 말해, 파일에서 IAT는 실제 함수의 주소를 가리키고 있지 않다. 왜냐하면 사용하고자 하는 함수의 주소를 아직 알 수 없기 때문이다. 하지만 메모리에 올라오면서 PE 로더는 IAT에 사용하고자 하는 함수의 실제 주소를 올려주므로 우리는 아무런 의심 없이 사용할 수 있다. 하지만 이러한 작업은 프로그램의 초기화 시간을 지연시키므로 MS는 이러한 제약을 피할 수 있도록 하나의 기능을 제공한다. 바로 IAT에 함수의 주소를 기록하는 작업을 미리 수행하여 로딩 시의 속도 향상을 도모하도록 한다. 이 과정을 바로 DLL 바인딩이라고 하며, 바인드 된 실행 파일의 IAT는 실제 함수의 주소를 가리키고 있게 된다.

우선 위의 표는 일반적인 파일의 Import Section 정보로 INT와 IAT가 같은 곳을 가리키고 있는 것을 확인할 수 있다. INT의 첫 번째 함수인 GetDriveTypeA인 0x307C의 이름의 위치를 IAT에서도 똑같이 가리키고 있다. 메모리에 올라오면서 IAT에 실제 주소가 기록되어 변경된다.

위의 표는 같은 파일에 바인딩을 실시한 후의 모습으로 INT는 기존과 동일한 모습을 하고 있지만 IAT의 경우 Data에 실제 함수의 주소가 위치한 것을 확인할 수 있다. 이처럼 바인딩을 하게 되면 실제 함수의 주소를 가지게 되는 것을 알 수 있다.

DLL Relocation

DLL 재배치에 대하여 알아보기 전에 먼저 ImageBase에 대하여 알아보자. ImageBase란 PE 구조에서 해당 PE 파일이 PE 로더에 의해 메모리에 로드될 때 로드시키고자 하는 메모리의 주소가 된다. 보통 EXE 파일의 경우 0x4000000이며 DLL 파일의 경우 0x10000000이다.

하지만 위에서 말한 것과 같이 하나의 EXE 파일은 여러 라이브러리를 필요로 하는 경우가 일반적이기 때문에, 여러 DLL을 메모리에 올리고자 한다. 이 경우 DLL들의 ImageBase가 중첩된다면 하나의 메모리 주소에 여러 DLL이 존재할 수 없으므로 사용할 수 없게 된다. 다행히 DLL 재배치를 통해 원하는 ImageBase에 이미 다른 DLL이 올라와 있다면, 다른 주소에 맵핑될 수가 있다.

하지만 이러한 재배치 작업이 일어나면 PE 로더는 부차적인 작업을 수행해야 한다. DLL의 주소를 바꾸어 올리는 것뿐만 아니라, 해당 DLL의 Code Section의 일부 내용을 수정해야만 한다. 이에 대해 아래의 표를 보자. 아래의 표는 Relocation Section의 내용으로 하단 두 줄에 RVA가 있는 것을 확인할 수 있다. 일반적으로 이 주소가 가리키는 부분은 0x????????과 같은 4 Bytes의 주소를 나타내는 것으로 PE 구조에 기록되어 있는 ImageBase에 맞게 주소가 설정되어 있다. 하지만 ImageBase와 다른 곳에 로드되면 이 주소들은 ImageBase에 로드된 다른 DLL을 가리키게 되는 문제가 발생하므로 값을 수정해주어야 한다.

다행히 이러한 주소 값의 수정을 사용자가 직접 하나하나 하는 것이 아니라 PE 로더가 재배치 섹션을 확인하여 알아서 수정해준다. 하지만 여기서 몇 가지 문제점이 존재하게 된다. 우선 재배치 정보가 가리키고 있는 값들은 대개 어떤 주소에 관한 값으로, 이러한 값들이 대개 코드 섹션에 위치하고 있다는 것이다. 따라서 이 값을 PE 로더가 수정하기 위해선 해당 섹션에 Write 속성을 추가한 뒤 수정을 하고, 수정을 마치면 다시 원래의 속성으로 되돌려야 한다는 것이다. 이에 더해 위 예에서는 2개의 값만 나타냈지만, 실제로는 더 많은 경우가 많기 때문에 PE 로더는 그 많은 주소의 값들을 직접 찾아 수정해주어야 한다. 만약 하나의 EXE 파일에 여러 DLL에 대하여 이러한 작업을 수행해야 한다면, 프로그램을 실행하기 위한 초기화 시간이 길어질 수 있다.

DLL Delay Loading & DLL Forwarding

DLL Delay Loading

상기의 이유들로 초기화 시간이 길어질 수 있다는 것에 대하여 알 수 있었다. 사실 하드웨어의 성능이 상향된 요즘은 별 상관이 없지만, 윈도우는 이러한 초기화 시간을 줄이기 위한 또 다른 방안을 구비해놓았다. 바로 DLL 지연 로딩으로, 단어에서와 같이 DLL을 프로그램 실행 시에 로드하는 것이 아니라 지연하여 로딩하는 것이다.

지연 로딩은 암시적 로딩에서의 간편함과 명시적 로딩에서의 유연함, 이 두 장점을 취하고자 하는 방식으로 EXE 작성에서 DLL 링크 시에는 암시적인 방식으로, 실제 런타임에서 사용 할 때는 명시적인 방식으로 작동하도록 한 것이다. 쉽게 말해 프로그램을 실행 시에 메모리에 매핑되는 것이 아니라 해당 DLL의 Export 함수들 중 하나가 최초로 실행될 때 그 시점에 해당 DLL을 로드해서 가상 주소 공간에 매핑한다는 것이다.

DLL Forwarding

DLL의 Export Function Forwarding이란 Export하고자 하는 함수를, 그 기능을 대신하는 다른 DLL 내에 정의된 함수의 호출로 대체하는 것이다. 글로 설명하는 것보다는 직접 코드를 확인 것이 더 좋으므로 일반적인 경우의 DLL의 Export 함수의 주소를 확인해보자. 아래의 표와 같이 Export하는 함수의 주소로 이동을 하면 해당 함수의 내용이 존재하고 있는 것을 확인할 수 있다. 즉, 자신의 DLL 안에 해당 코드를 그대로 잘 가지고 있는 것이다.

이번에는 DLL Forwarding이 적용된 DLL의 내용을 확인해보자. 위 표와는 다른 DLL이기는 하지만 Export 하는 함수의 주소로 이동하여 확인해보면 심히 코드가 짧다는 것을 알 수 있다. Export 하고자 하는 함수의 이름 "LpkEditControl"과 함께 0x1000261C를 호출하는 것을 확인할 수 있다.

0x1000261C에는 다시 아래와 같은 내용이 있으며, 10002634를 호출한 다음, 이전에 인자로 전달 받았던 Export하고자 하는 함수의 이름과 함께 GetProcAddress를 통해 주소를 구하고자 하는 것이다.

해당 10002634를 따라가다 보면 시스템 디렉터리의 경로를 구한 뒤, 해당 Export 함수를 가진 대상(포워딩 대상)을 LoadLibarary API를 통해 로드하는 것을 확인할 수 있다. 이를 통해 해당 DLL이 로드되고 위의 과정에서와 같이 GetProcAddress를 통해 해당 함수가 로드되는 것이다.

DLL 포워딩이 그렇다면 어느 곳에 사용될 수 있을까? 필자는 악성코드에 관심이 많으므로 악성코드를 대상으로 설명하겠다. 악성코드는 문서의 형태로 존재할 수도 있고 실행파일의 형태로 존재할 수도 있다. 하지만 이 글의 취지에 맞게 DLL로 구성된 경우 악성코드 제작자는 매우 유용하게 DLL 포워딩을 사용할 수 있다. 악성코드 제작자 그 누구도 자신이 만든 애지중지한 파일이 누가 보아도 '악성'으로 보이고 싶지는 않을 것이다. 그렇기에 정상 파일인 것처럼 위장을 하게 되는데, DLL의 경우 실제 Export 하는 함수의 내용을 구현할 수 있어야 한다는 것이다. 물론 실제 DLL의 내용을 Ctrl+C/Ctrl+V를 통해 사용할 수는 있겠지만 이는 결코 좋은 방법이 아니다.

이 기능을 사용하면 해당 포워딩 설정을 실제 DLL 파일로 해놓으면 너무나 쉽게 정상적인 기능을 모두 구현할 수 있게 된다. 결국 정상적인 기능을 수행하면서, DllMain()에는 자신이 원하는 기능을 수행하도록 하면 이는 완벽한 위장이 된다. 물론 실제 시스템 DLL이 먼저 로드되는 상황이 발생되면 안되므로 DLL 로딩 순서를 변경하여 실행파일과 같은 디렉터리에 있는 악성 DLL을 먼저 로드하도록 하여 이를 로드시키면 모든 것은 끝이 난다.

Conclusion

단순하게 DLL을 이론만 공부했던 때에는 위의 기능들이 어떻게 사용되는지 별로 관심이 없었다. 하지만 실제로 악성 DLL을 분석해보고 난 뒤 너무나 부족한 지식을 가지고 있다고 다시 한 번 느끼게 되어 이렇게 기억하고자 정리해보았다. 이외에도 분석을 통해 어떠한 부분이 부족한지 더 자세히 알게 되어 너무나 유익하였다.

약간의 후기를 공유하자면 이론으로 알고 있던 내용이 어떻게 코드나 어셈블리어로 적용되는지 반드시 확인을 해보자. 이론으로는 자세히 알고 있더라도 그 부분을 무심코 지나칠 수 있다는 것을 뼈저리게 느끼게 되었다.

Reference

http://www.sck.pe.kr/c-cgi/whatisdll.htm

Windows 시스템 실행파일의 구조와 원리 [한빛미디어]

지난 2005년 경부터 일부 피싱에 사용된 Unicode RLO 방식을 이용하여 악성코드의 확장자를 다른 형태로 보이도록 하는 형태의 악성코드가 지속적으로 나타나고 있다. 유니코드란 아스키 코드보다 더 크게 모든 문자를 표현하는 문자셋이라 할 수 있다. 각 나라마다 고유의 문자들이 있는데 이를 ASCII 문자로만으로는 표현할 수가 없다.

일반적으로 문자는 왼쪽에서 오른쪽으로 읽지만, 일부 국가에서는 오른쪽에서부터 문자를 읽기도 한다. 이를 컴퓨터에 표현하기 위한 Unicoode는 바로 0x202E로 "Right to Left Override"라는 문자이다. 해당 문자에 대한 정보는 아래와 같다.

이전부터 악성 파일과 관련되어 모르는 exe 파일은 열어보아서는 안된다라는 내용의 이야기는 많이 들을 수 있었다. 그렇기에 일반적인 사용자들도 더 이상 모르는 실행 파일을 함부로 실행시키지는 않는다. 그렇기에 공격자들은 이러한 확장자를 감추려 하거나 변조하는 등으로 사용자를 속이려 한다. 유니코드 확장자 변조에는 위에서 언급한 0x202E가 사용된다. 아래 파일을 보자.

위 그림에서 볼 수 있듯이 파일의 이름은 "testrcs.mp4"이다. 일반적으로 보았을 때 그냥 정상적인 MP4 파일과 같이 볼 수 있다. 하지만 우측의 파일 유형을 보면 '화면보호기(scr)'로 나타나는 것을 확인할 수 있다. 어떻게 된 것일까? CMD를 통해 해당 디렉터리에서 파일의 이름을 다시 확인해보자.

CMD를 통해 확인한 결과에서는 "test 4pm.scr"로 나타나는 것을 확인할 수 있다. 바로 test라는 문자열과 4pm 이라는 문자열 사이에 0x202E가 들어가 있는 것이다. 그렇기에 0x202E 이후의 내용 "4pm.scr"은 반전되어 "rcs.mp4"로 나타내는 것이다. 이를 통해 scr파일을 mp4파일로 착각하도록 할 수 있다.

그렇다면 직접 실습을 진행해보자. 우선 RLO 유니코드 문자를 가지고 와야하는데 이는 0x202E로 바로 나타내도 되지만 편리하게 문자열 셋에서 구할 수가 있다. Windows+R을 입력한 뒤 나타나는 창에 charmap을 입력해보자. 그렇다면 아래와 같은 문자표가 나타난다.

그 다음 '고급 보기'를 체크하여 나타나는 항목에서 유니코드로 이동에 "0x202E"를 입력해준다. 그렇다면 아래의 그림과 같이 나타나는데 해당 문자를 복사해주면 준비가 끝난다.

두 개의 파일 1234abcd.mal과 2234abcd.mal을 준비한다. 그리고 두 번째 파일에서 원하는 부분에 해당 문자를 복사해보자. 아래와 같이 "2234ablam.dc"로 출력되는 것을 확인할 수가 있다. 

이와 같이 확장자를 변조할 수가 있으며, 이에 추가적으로 해당 실행파일이 아이콘 또한 변조된 이름과 같이 보이게 하면 자연스럽게 실행을 유도할 수가 있다. 따라서 어떠한 파일이든 다운을 받았다면 실행을 시키지 말고, 파일의 이름을 한번 의심해보고 반드시 파일의 유형까지 확인해보아야 한다.

Reference

http://egloos.zum.com/voidns/v/2409436

http://cleverdj.tistory.com/48

http://viruslab.tistory.com/1986

http://www.fileformat.info/info/unicode/char/202e/index.htm

http://jvinci.tistory.com/228

PE구조의 이해.pdf

개요

우리가 컴퓨터로 무엇인가 작업하기 위해서는 언제나 특정 프로그램을 실행시킨다. 이러한 실행 파일 또는 응용 프로그램이라 불리는 EXE 파일 말고도 프로그램 실행을 위한 DLL 파일도 프로그램 실행 시에 같이 물려 메모리 상에 로드된다. 이러한 EXE 파일 관련 DLL 파일들이 메모리 상에 로드되면서 비로소 프로그램이라는 것이 사용 가능하게 되고 이렇게 로드된 하나의 EXE와 여러 개의 관련 DLL들이 소위 운영체제론에서 이야기하는 하나의 프로세스를 구성하게 된다.

그림 1. HxD로 본 PE 구조

이러한 실행 파일들은 항상 MZ라는 식별 가능한 문자로 시작하는데 이는 무의미한 문자가 아니라 PE(Portable Executable)구조로 된 PE 파일들을 나타낸다. PE파일은 이름과 같이 플랫폼에 관계없이 Win32 운영체제가 돌아가는 시스템이면 어디서든 실행 가능하다는 의미를 지니고 있다. 따라서 우리는 이러한 PE파일의구조를 중점적으로 알아볼 것이다

PE 파일의 전체 구조

PE 파일의 전체적인 구조에 대하여 알아보자. PE 파일은 아래의 그림과 같은 형태로 "MZ"가 위치하고 있는 IMAGE_DOS_HEADER를 시작으로 프로그램의 많은 정보를 구조체 형태로 포함하고 있다. 도스 헤더의 경우 PE파일임을 구별할 수 있도록 시작 부분에 "MZ" Signature(4D5A)로 시작한다. 그 다음 도스 스텁이 나오는데 이는 필수적이지 않은 존재로 16 Bit 환경에서 출력될 문자열인 "This program cannot be run in DOS mode"라는 문자열 등을 포함하고 있다.

그림 2. 일반적인 PE 구조의 형태

그 다음 본격적인 "PE" Signature(5045)가 존재하고 있는 IMAGE_NT_HEADERS로 이 부분은 크게 IMAGE_FILE_HEADER와 IMAGE_OPTIONAL_HEADER 두 부분으로 나눌 수가 있다. FILE 헤더의 경우 PE 파일에 대한 파일 정보를 나타내고 OPTIONAL 헤더의 경우 PE 파일이 메모리에 로드될 때 필요한 모든 정보들을 담고 있다. OPTIONAL_HEADER 내에는 기본 필드들과 함께 주요 섹션들의 위치와 크기를 나타내는 IMAGE_DATA_DIRECTORY 구조체 배열을 담고 있다. 이에 대해선 추후에 더 자세히 설명할 것이다.

그림 3. PE View로 본 IMAGE_DATA_DIRECTORY

IMAGE_DATA_DIRECTORY를 끝으로 IMAGE_SECTION_HEADER가 여러 개 나오는데, 이는 섹션 테이블로 각 섹션의 위치와 크기 등의 정보를 포함하고 있다. MZ헤더부터 섹션 테이블까지 PE 파일 헤더라 하며, PE 헤더 뒷부분부터는 실제 코드나 데이터들이 성격에 맞게 각각의 섹션에 위치하고 있다.

PE 분석을 위한 개념 정리

PE 파일 구조를 분석하기 전에 알아야할 내용들에 대하여 언급할 것이다. RVA, Section, MMF, VSA에 대하여 알아보자.

  RVA (Relative Virtual Address)

RVA는 상대적 가상 주소로 파일 Offset과는 다른 개념이다. Offset은 파일에서의 위치를 나타낼 때 사용하는 개념이지만 RVA는 가상 주소 공간 상의 위치를 나타낼 때 사용하는 개념으로 메모리 상에서의 PE의 시작 주소에 대한 오프셋으로 생각하면 된다. 그렇다면 메모리에서는 왜 Offset이나 VA가 아닌 RVA로 나타낼까?

이는 PE 파일이 지정된 베이스 위치(ImageBase)를 기준으로 로딩된다는 보장이 없기 때문이다. EXE 파일의 경우 일반적으로 파일이 지정된 위치에 로드된다. DLL의 경우 일반적으로 ImageBase 값이 0x1000000으로 설정되어 있지만 하나의 프로세스에는 여러 개의 DLL이 존재하고 있기 때문에 ImageBase를 기준으로 할 경우 중첩된다. 이러한 중첩을 방지하기 위해 DLL Relocation이 존재하고 있으며 이러한 이유로 인해 절대 주소가 아닌 상대 주소를 사용한다. 만약 ImageBase가 0x2000000이며 RVA 값이 0x1234라고 한다면 가상 주소의 값은 0x02001234이 되는 것이다.

  Section

PE 파일에서 섹션은 PE가 가상 주소 공간에 로드된 다음 실제 내용을 담고 있는 블록들이다. 대표적인 내용으로는 명령어 코드와 데이터이며, 그 외에 실행에 관련된 여러 정보들이 섹션에 배치된다. 대표적으로 언급할만한 섹션들에 대하여 간단히 알아보자.

그림 4. 대표적인 섹션의 종류

  VAS (Virtual Address Space)

마지막으로 고려할 것은 파일로 존재하는 PE구조와 이것이 메모리에 올라올 때 주어지는 가상 주소 공간(VAS)에서의 PE 구조에 대한 관계이다. 이를 위해 MMF(Memory Mapped File)에 대하여 먼저 알아보자. 32비트 환경에서 프로세스는 4GB의 VAS를 갖는데, 이 가상 공간을 실제의 물리적인 기억 장치와 연결시켜 주는 것이 가상 메모리 관리자(Virtual Memory Manager, VMM)이다. 여기서 물리적 기억장치는 RAM 뿐만 아니라 하드디스크 상의 특정 파일(기본적으로는 PageFile.sys)을 포함한다. 이와 함께 페이징 기법을 통해 프로세스에게 실제로 4GB의 주소 공간을 가진 것처럼 사용할 수 있다.

페이징 파일과 RAM 그리고 VAS는 VMM에 의해 관리되며 프로세스에 속한 특정 스레드가 가상 주소 공간 내의 특정 번지에 접근하고자 할 때, VMM은 해당 번지의 페이지를 페이징 파일과 매핑시켜 준다. 매핑된 페이지는 접근 가능한 상태가 되며, 여기서 이러한 페이징은 반드시 PageFile.sys하고만 이루어져야 하는 것은 아니라 일반 파일을 메모리에 맵핑하여 이에 대해 페이징 할 수 있다. 이처럼 일반적인 파일이 PageFile.sys의 역할을대신하는 경우를 MMF라고 한다. 이제 MMF를 사용하기 위한 함수에 대하여 알아보자.

그림 5. CreateFileMapping API

CreateFileMapping API는 운영체제에게 매핑을 수행할 파일의 물리 저장소를 알려주기 위한 API이다. 이를 통해 지정 파일을 파일 매핑 오브젝트와 연결시키며, 파일 매핑 오브젝트를 위한 충분한 물리 저장소가 존재한다는 것을 확인시킨다.

hFile의 경우 CreateFile()과 같은 API를 통해 얻은 파일의 핸들로 물리 저장소로 사용할 파일의 핸들을 주어야한다. flProtect는 MMF의 페이지 속성을 지정하는데 PAGE_READONLY, PAGE_READWRITE, PAGE_WRITECOPY와 같은 세 가지 보호 속성을 기본으로 가진다. 이 세 가지 보호 속성 외에 다섯 가지 메모리 매핑 파일만의 속성을 추가로 지정할 수 있다.

그림 6. flProtect 항목

하지만 파일 매핑 오브젝트를 생성한다 하더라도, 시스템은 곧바로 프로세스의 주소 공간 상에 영역을 예약하지 않는다. 그렇기에 파일의 데이터에 접근하기 위한 영역을 프로세스 주소 공간 내에 확보해야 하며, 이 영역에 임의의 파일을 물리 저장소로 사용하기 위한 커밋 단계를 거쳐야 하며 이를 위해 사용하는 API가 바로 MapViewOfFile이다.

그림 7. MapViewOfFile API

첫 번째 인자는 CreateFileMapping으로 얻은 핸들을 넘겨주면 되고 두 번째 인자에 사용할 수 있는 항목은 아래와 같다. 세 번째와 네 번째 인자의 경우 파일의 어디부터 매핑할 것인지 지정해주는 것으로 파일의 오프셋 값은 반드시 시스템의 할당 단위의 배수여야 한다. 마지막 인자의 경우 얼마만큼 해당할지 설정하는 것으로 값이 0일 경우 오프셋으로부터 파일의 끝까지 구성한다.

그림 8. dwDesiredAccess 항목

이렇게 MMF를 형성할 수 있으며 프로세스 주소 공간 내에 매핑된 데이터 파일을 더 이상 유지할 필요가 없다면 UnmapViewOfFile 함수를 호출하여 영역을 해제해 주어야 한다. 사용되는 인자는 하나뿐이며 해제할 영역의 주소를 넘겨주면 된다.

그림 9. UnmapViewOfFile API

마지막으로 이전에 얻어온 파일 오브젝트와 파일 매핑 오브젝트가 올바르게 반환이 이루어질 수 있도록 CloseHandle API를 호출해주어야 한다. 사용되는 인자는 역시 하나로 핸들을 넘겨주어야 한다.

그림 10. CloseHandle API

이렇게 MMF를 사용하는 방법에 대하여 알아보았다. 사실 이 MMF에 대하여 공부하며 어느 곳에 사용해야하는 것인지 의문을 가질 수가 있다. 이렇게 MMF에대하여 자세히 알아본 이유가 무엇일까? 바로 Windows는 EXE나 DLL 등의 실행 파일을 로드할 때 MMF를 이용한다. 즉, PE 파일을 페이징 파일로 복사하는 것이 아니라 그 파일 자체를 페이징 파일로 사용한다는 것이다.

그림 11. 파일과 프로세스에서의 PE 시작점

위 두 개의 바이너리를 보자. 파일에서의 바이너리와 할당된 가상 주소에서의 바이너리가 주소만 다르지 내용은 같다는 것을 확인할 수 있다. 이는 해당파일 자체가 그대로 가상 주소 공간에 매핑된다는 것으로, EXE나 DLL 와 같은 PE 파일을 실행할 때 PE 파일 내에 정의된 바와 같이 가상 주소 공간에 매핑된다는 것이다. 지금까지 PE의 개략적인 구조와 RVA, Section, 그리고 PE와 MMF의 관계에 대해 알아보았다. 다음 장부터는 구체적으로 PE 파일에 대하여 알아보자.

IMAGE_DOS_HEADER & IMAGE_DOS_STUB

PE 파일에서 가장 처음으로 등장하는 영역은 바로 도스 헤더와 도스 스텁 영역이다. 도스 헤더에는 총 64 Bytes로 19개의 필드를 갖지만, 실제로 중요한 필드는 단 두 개뿐이다. e_magic 필드는 MZ 헤더의 시그니처가 존재하는 필드로 PE 파일이 맞는지 아닌지 체크할 때 사용되며, 이는 도스 헤더의 시작을 알리는 코드라 할 수 있다. e_lfanew 필드는 NT헤더의 시작 위치를 나타내는 값으로 해당 오프셋을 확인해보면 NT 헤더의 시그니처인 "PE"가 존재하고 있다.

그림 12. IMAGE_DOS_HEADER 구조체

IMAGE_DOS_STUB은 아래와 같은 형태를 띄고 있으며 큰 의미를 갖지 않는다. 아래의 표를 보면 식별 가능한 문자열이 존재하고 있는데 이는 MS-DOS나 윈도우 3.1에서 실행하게 되면 바로 이 문장을 출력한다. MS-DOS 스텁은 위 문장을 출력하기 위한 16비트 도스용 응용 프로그램이라 할 수 있다.

그림 13. 예제.exe의 IMAGE_DOS_STUB

이렇게 도스 헤더와 도스 스텁에 대하여 알아보았는데, 결국 이 두 구조체에서 필수적인 항목은 단 두개 뿐인 것이다. 다시 말해, 다른 필드의 항목들은 모두 NULL이 되어도 상관없다는 것이다. 한번 직접 코드를 비교해보자. 아래는 불필요한 항목들을 제거하지 않은 상태의 코드와 불필요한 항목들을 제거한 다음의 코드를 비교한 것이다.

그림 14. 필수적이지 않은 요소 제거

코드를 이렇게 수정을 해도 프로그램이 정상적으로 구동되는 것을 확인할 수 있을 것이다. 각 필드 마다 의미를 가지고 있기는 하지만, PE 구조에서는 이러한 정보들이 존재하지 않더라도 정상적으로 구동하도록 되어있다.

IMAGE_NT_HEADER

IMAGE_DOS_HEADER의 e_lfanew 필드 값에 해당하는 위치에 IMAGE_NT_HEADER가 존재하고 있다. 해당 구조체에는 PE와 관련된 주요 필드들이 위치해 있다. 우선 해당 위치에는 PE Signature, IMAGE_FILE_HEADER, IMAGE_OPTIONAL_HEADER로 분류할 수 있다. 아래의 구조체를 확인해보자.

그림 15. IMAGE_NT_HEADER 구조체

  IMAGE_FILE_HEADER

IMAGE_FILE_HEADER에는 해당 PE 파일과 관련된 내용이 존재하고 있는 20 Bytes로 구성된 구조체이다. 첫 번째 필드에는 CPU의 ID를 나타내는 것으로 세 가지 주요 타입은 다음과 같이 Intel 386의 경우 0x014C, Intel 64의 경우 0x200, AMD64의 경우 0x8664의 값을 갖는다. 두 번째 필드의 경우 본 파일에서 섹션의 수를 나타내는 것이며 세 번째 필드 TimeDataStamp는 파일이 OBJ 형식의 파일이면 컴파일러가, EXE나 DLL과 같은 PE 파일이라면 링커가 해당 파일을 만들어낸 시간을 의미한다.

PointerToSymbolTable의 경우 COFF 심벌의 파일 오프셋을 나타내는 것으로, 이 필드는 컴파일러에 의해 생성되는 OBJ 파일이나 디버그 모드로 만들어져 COFF 디버그 정보를 가진 PE 파일에서만 사용된다. 그 다음 NumberOfSybols는 PointerToSymbolTable 필드가 가리키는 COFF 심벌 테이블 내의 심벌 수를 나타낸다. IMAGE_FILE_HEADER 다음에는 IMAGE_OPTIONAL_HEADER가 이어서 나오는데 바로 해당 구조체의 크기를 나타내는 것이 SizeOfOptionalHeader 필드이다. 마지막으로 Chracteristics 필드는 해당 PE 파일에 대한 특정 정보를 나타내는 플래그로 주요 항목 몇 가지가 [그림 17]과 같다.

그림 16. IMAGE_FILE_HEADER 구조체

그림 17. Characteristics의 주요 PE 특성

  IMAGE_OPTIONAL_HEADER

IMAGE_FILE_HEADER의 뒷부분에 나오는 IMAGE_OPTIONAL_HEADER 구조체에는 메모리에 올라갈 때 참조해야 할 주요한 필드들이 위치하고 있다. 해당 구조체는 총 224 Bytes의 크기를 갖으며 많은 필드가 위치해있다. 아래의 구조체를 보자.

그림 18. IMAGE_OPTIONAL_HEADER 구조체

첫 번째 필드인 Magic은 IMAGE_OPTIONAL_HEADER를 나타내는 Signature로 32비트 PE의 경우 0x010B이고, 64비트 PE의 경우 0x020B, ROM 이미지 파일에 대해서는 0x0107의 값을 갖고 있는 것을 확인할 수 있다. MajorLinkerVersion과 MinorLinkVersion는 본 파일을 만들어낸 링커의 버전을 나타낸다. SizeOfCode의 경우 코드 섹션(.text) 섹션의 크기이며 SizeOfInitializedData, SizeOfUninitializedData의 경우 각각 코드 섹션을 제외한 "초기화된 데이터 섹션의 크기"와 "초기화되지 않은 데이터 섹션의 크기"를 나타낸다.

AddressOfEntryPoint는 로더가 실행을 개시할 주소를 나타낸다. 이 주소는 RVA로서 보통 .text 섹션 내의 특정 번지가 된다. 이 필드의 값은 프로그램이 처음으로 실행될 코드를 담고 있는 주소이다. 즉, 프로그램이 로드된 후 이 프로세스의 메인 스레드 문맥의 EIP 레지스터가 가질 수 있는 최초의 값이라 할 수 있다. BaseOfCode, BaseOfData의 경우 각각 첫 번째 코드 섹션이 시작되는 RVA, 데이터 섹션이 시작되는 RVA를 의미한다.

ImageBase 필드는 해당 PE가 가상 주소 공간에 매핑될 때 매핑시키고자 하는 메모리 상의 시작 주소이다. 일반적으로 EXE 파일의 ImageBase 값은 0x400000이며 DLL의 경우 0x1000000이지만, DLL의 경우 하나의 VAS에 여러 DLL이 존재할 수 있으므로 DLL Relocation을 필요로 하게 된다.

PE 파일은 섹션으로 나뉘어져 있는데 파일에서 섹션의 최소단위를 나타내는 것이 FileAlignment이며 메모리에서 섹션의 최소단위를 나타내는 것이 SectionAlignment이다. 각 섹션의 시작 주소는 언제나 각 필드의 배수가 되는 주소가 되도록 보장해야 한다.

MajorOperatingSystemVersion, MinorOperatingSystemVersion은 해당 PE를 실행하는데 필요한 운영체제의 최소 버전을 의미한다. MajorImageVersion과 MinorImageVersion은 유저가 정의 가능한 필드로, 제작할 때 PE 파일에 제작자가 버전을 기입할 수 있도록 하는 것이다. MajorSubsystem과 MinorSubsystem은 본 PE를 실행하는데 필요한 서브시스템의 최소 버전을 의미한다. Win32VersionValue는 이전엔 예약 필드였지만 VC++ 7.0부터는 이름을 가지게 되었다. 하지만 거의 사용되지 않으며 보통 0으로 설정된다.

SizeOfImage는 PE 파일이 메모리에 로딩되었을 때의 전체 크기를 담고 있으며 이 값은 SectionAlignment 필드 값의 배수가 되어야 한다. SizeOfHeaders는 PE 헤더의 전체 크기를 나타내는 것으로 이 값 역시 FileAlignment의 배수가 되어야 한다.

CheckSum 필드는 이미지의 체크섬 값을 의미한다. PE 파일의 체크섬 값은 IMAGEHELP.DLL의 CheckSymMappedFile API를 통해서 얻을 수 있다. 체크섬 값은 커널 모드 드라이버나 어떤 시스템 DLL의 경우 요구된다. 그 이외의 경우라면 보통 0으로 설정된다. 그리고 Subsystem 필드의 경우 sys 파일과 같이 디바이스 드라이버 같은 경우 1의 값을 가지고 Windows GUI 프로그램의 경우 윈도우 기반 응용프로그램의 경우 2, 마지막으로 CMD와 같은 콘솔 기반 응용프로그램은 3의 값을 갖는다.

DllCharacteristics 필드는 원래 PE가 DLL이라는 전제 하에 어떤 상황에서 DLL 초기화 함수가 호출되어야 하는지를 지시하는 플래그였다. 하지만 지금은 대부분 0으로 설정되어 있는 것을 확인할 수 있다.

SizeOfStackReserve, SizeOfStackCommit, SizeOfHeapReserve, SizeOfHeapCommit 필드에 대하여 알아보자. 프로세스는 가상 주소 공간에 자신만의 스택과 힙을 별도로 가진다. 따라서 프로세스 생성 시 시스템은 언제나 메인 스레드를 위한 디폴트 스택과 프로세스를 위한 디폴트 힙을 해당 프로세스 내에 생성시켜주는데, 이 스택과 힙의 크기와 속성에 관계된 설정을 이 필드들에 지정하게 된다. PE가 메모리에 로드될 때 시스템은 이 필드의 값을 참조하여 해당 프로세스에 디폴트 스택과 힙을 만들어준다.

LoaderFlags 필드는 이전에는 디버깅 지원에 관계된 목적으로 존재하는 것 같지만, 현재는 0으로 설정된다. NumberOfRvaAndSize 필드는 바로 뒤에 나오는 IMAGE_DATA_DIRECTORY 구조체 배열의 원소 개수를 의미하는데, 이 값은 항상 16(0x10)이다.

그림 19. IMAGE_DATA_DIRECOTRY 구조체

IMAGE_DATA_DIRECTORY는 구조체의 배열로, 배열의 각 항목마다 정의된 값을 가지게 된다. 각 항목은 위와 같이 VirtualAddress와 Size 필드로 구성되어 있으며 각 16개의 구조는 다음과 같은 의미를 가진다.

그림 20. IMAGE_DATA_DIRECTORY ENTRY

  IMAGE_SECTION_HEADER

PE 헤더 바로 다음엔 IMAGE_SECTION_HEADER가 나온다. 섹션 헤더는 각 섹션의 속성이 정의되어 있는 구조체로 각 섹션 헤더 마다 40 Bytes로 구성된다. 각 필드에 대하여 알아보자.

그림 21. IMAGE_SECTION_HEADER 구조체

Name 필드는 섹션의 아스키 이름을 나타내며 만약 섹션의 이름이 8 Bytes를 넘을 경우 8 Bytes 이후의 문자열은 잘린 뒤 이 필드 값을 채운다. 또한 이 값은 섹션의 이름을 참고할 용도뿐이라 해당 이름을 바꾸어도 프로그램의 실행에는 아무런 지장이 없다.

PhysicalAddress필드는 이전엔 OBJ 파일에서 섹션의 물리적인 번지를 지정했지만, 지금은 사용되지 않아 0으로 지정되어 있다. VirtualSize 필드는 메모리에서 섹션이 차지하는 크기를 나타낸다. VirtualAddress는 PE에서 해당 섹션을 매핑시켜야 할 가상 주소 공간 상의 RVA를 가지고 있다. SizeOfRawData는 파일에서 섹션이 차지하는 크기를 나타낸다. 그리고 PointerToRawData는 파일에서 해당 섹션의 위치를 나타낸다.

PointerToRelocations는 본 섹션을 위한 재배치 파일 오프셋으로 OBJ 파일에서만 사용되고 실행파일에서는 0이 된다. PointerToLinenumbers는 본 섹션을 위한 COFF 스타일의 라인 번호를 위한 파일 오프셋이다.

NumberOfRelocations는 PointerToRelocations 필드가 가리키는 구조체 배열의 원소 개수를 나타내며, NumberOfLinenumbers는 PointerToLinenumbers 필드가 가리키는 구조체 배열의 원소 개수를 나타낸다.

마지막으로 Characteristics는 해당 섹션의 속성을 나타내는 플래그의 집합으로 아래와 같은 속성 값이 존재하고 있다.

그림 22. IMAGE_SECTION_HEADER 속성 값

.code 섹션의 경우 주로 CNT_CODE, MEM_EXECUTE, 그리고 MEM_READ 속성 값을 가지며 .data 섹션과 .idata 섹션의 경우 CNT_INITALIZED_DATA, MEM_READ, 그리고 MEM_WRITE의 속성 값을 가진다.

Section

각 PE 파일마다 가지는 섹션은 다를 수 있지만, 대부분 섹션은 유사한 기능을 한다. 그러므로 이러한 각 섹션에 대하여 알아보자.

  Code Section

코드 섹션 또는 텍스트 섹션은 컴파일러나 어셈블러가 최종적으로 생성하는 일반 목적 코드가 존재하는 섹션으로 실행 명령어들이 이곳에 존재하고 있다. 우선 예제 파일을 통해 실제 코드 섹션의 내용을 확인해보자. 아래의 바이너리와 같이 우리가 읽을 수 없는 코드로 이루어져 있기 때문에 우리는 기계어를 해석하기 위하여 디스어셈블러와 같은 도구를 사용하여야 한다.

그림 23. 예제.exe의 .text 섹션

디스어셈블러를 통해 해당 섹션의 내용을 확인하면 아래와 같은 명령어가 위치해있는 것을 알 수 있다. 이러한 명령어들이 하나 하나 실행되면서 프로그램의 정의된 대로 동작하게 된다. 실행의 흐름을 위하여 EIP 레지스터에는 실행할 명령어의 위치가 담겨 있다.

그림 24. 예제.exe의 .text 섹션 – 어셈블리 코드

그렇다면 왜 파일에서의 위치(Offset)은 0x600인데 메모리에서의 위치(RVA)는 401000일까? 아무 이유 없이 이렇게 메모리에 올라오는 것이 아니라, 이전에 언급한 바와 같이 ImageBase나 해당 섹션의 RVA, PointerToRawData 등에 의해 메모리에 올라오면서 정의된 대로 위치하게 되는 것이다. 해당 프로그램의 필드 값 몇가지를 확인해보자.

그림 25. 예제.exe의 몇 가지 필드 값

우선 코드 섹션의 PointerToRawData는 0x600으로 파일에서 해당 섹션의 위치가 0x600임을 알려준다. 그렇기에 해당 위치를 확인해보면 실행할 코드가 존재하고 있는 것을 확인할 수 있다. 메모리에서 해당 섹션의 위치는 RVA인 0x1000으로 이에 ImageBase 값을 더하면 위 그림에서의 주소인 0x401000임을 알 수가 있다. 이처럼 RVA와 RAW(Offset)의 주소의 관계는 직접 코드를 파일에서 수정하고자 할 때와 같은 경우에, 이를 변환할 줄 알아야 한다.

코드 섹션에 실행을 위한 명령어들이 있다고 하여 .text 섹션의 첫 부분이 프로그램의 실행을 위한 첫 명령어가 아니다. 흔히 디버거를 통해 프로그램의 시작 부분으로 이동되는 주소는 Entry Point로 IMAGE_OPTIONAL_HEADER의 AddressOfEntryPoint에 ImageBase를 더한 위치가 프로그램의 시작 주소가 된다.

  Data Section

데이터 섹션은 그 종류가 여러 가지이다. 일반적으로 .data라는 이름을 가진 섹션이 존재하며 이 안에 .idata나 .edata, 또는 .rdata 섹션이 존재하기도 한다. 이에 대해서는 뒤에서 상세히 다룰 것이다. 데이터 섹션은 그 속성이 읽기/쓰기 가능한 섹션으로 전역 변수나 정적 변수를 정의하게 되면 이러한 변수들이 이 섹션에 위치하게 된다.

아래는 실제 예제 프로그램의 데이터 섹션이다. 해당 데이터 섹션에는 ASCII 형태의 문자열들이 존재하고 있는 것을 확인할 수 있다.

그림 26. 예제.exe의 .data Section

데이터 섹션과 유사 .rdata 섹션은 읽기 전용 데이터 섹션으로 해당 섹션 헤더를 확인해보면 MEM_WRITE 속성이 존재하지 않는 것을 확인할 수 있다. 따라서 이 섹션에 무엇인가 기록하고자 하면 시스템은 예외를 나타내며 프로그램이 종료될 것이다. 또한 .rdata 섹션은 이러한 용도뿐만아니라 다른 섹션들이 병합되는 곳이기도 하다. 이후에 나올 .edata나 .idata 섹션이 .rdata섹션에 병합되는 경우도 종종 있다는 것을 잊지 말자.

  Export Section

Export 섹션은 주로 DLL에서 나타나는 섹션으로 자신이 가진 함수의 기능을 외부 프로그램이 사용할 수 있도록 제공하는 것이 목적이다. 만약 A.exe와 B.exe라는 프로그램이 존재할 때 두 프로그램 모두 TEST_Function()이라는 함수를 정의하여 사용하고 있다고 가정하자. 두 프로그램에 있어 TEST_Function을 각각 써넣어주는 것보단 용량이나 이후 관리를 위하여 TEST_Function()을 가진 DLL을 하나 만든 다음 이를 Import하여 사용할 수 있다. 반대로 해당 DLL은 Export를 제공하는 것이다.

먼저 Export Section의 IMAGE_EXPORT_DIRECTORY 구조체에 대하여 알아보자. 해당 구조체는 Export Section에서 가장 중요한 정보들을 담고 있는 구조체이며, IAT와는 다르게 PE 파일 당 하나만 존재한다. 해당 필드의 목록은 아래의 그림과 같다.

그림 27. IMAGE_EXPORT_DIRECTORY 구조체

첫 번째부터 필드는 사용되지 않으며 두 번째 필드는 해당 파일이 생성된 시간을 나타낸다. 그 다음 버전과 관련된 필드 역시 사용되지 않는다. 다섯 번째 Name필드는 해당 DLL의 이름을 나타내는 ASCII 코드 문자열의 위치를 지시하는 RVA이다. 파일에서 해당 DLL의 이름은 RVA를 RAW로 변환해주면 해당 Offset에서 이름을 확인할 수 있다. Base 필드는 Export된 함수들에 대한 서수의 시작 번호이다.

NumberOfFunctions는 뒤에 나오는 AddressOfFunctions 필드가 가리키는 RVA 배열의 원소 개수를 나타낸다. AddressOfFunctions는 export된 함수들의 함수 포인터를 가진 배열을 가리킨 RVA 값으로 이 함수 주소들은 본 모듈 내에서 각각 export된 함수에 대한 엔트리 포인터이다.

NumberOfNames는 AddressOfNames 필드가 가리키는 RVA 배열의 원소 개수와 AddressOfNameOrdinals 필드가 가리키는 서수 배열의 원소 개수를 동시에 나타낸다. AddressOfNames 필드는 export된 함수의 심벌을 나타내는 문자열 포인터 배열을 가리키는RVA 값이고, AddressOfNameOrdinals는 export된 모든 함수들의 서수를 담고 있는 배열에 대한 포인터이다.

여기서 NumberOfNames와 NumberOfFunctions은 다를 수 있는데 보통 NumberOfFunctions 필드가 더 크거나 같다. 하지만 실제 export된 함수의 정확한 개수는 NumberOfNames 필드의 값이다. 이렇게 IMAGE_EXPORT_DIRECTORY에 대하여 알아보았다. 아래는 실제 DLL 파일의 .edata 섹션을 분석한 내용이다.

그림 28. 예제.dll의 .edata 섹션

IMAGE_EXPORT_DIRECTORY 구조체 외에 3개의 Export Table이 존재하는 것을 확인할 수 있다. 하나는 Export 함수 포인터 테이블이며 다른 하나는 Export 함수 이름 포인터 테이블, 마지막으로 Export 함수 서수 테이블임을 알 수가 있다.

  Import Section

DLL의 입장에서는 함수를 Export 해주었다면 반대로 그 함수를 사용하기 위해선 다른 실행파일에서 이를 Import 해주어야 한다. 이렇게 사용하고자 import 하는 함수들과 그 DLL에 대한 정보를 가지고 있는 것이 바로 임포트 섹션이다. 아래 IMAGE_IMPORT_DESCRIPTOR 구조체를 확인해보자.

그림 29. IMAGE_IMPORT_DESCRIPTOR 구조체

우선 첫 번째 필드인 Characteristics 필드는 더 이상 사용하지 않고 OriginalFirstThunk라는 이름의 필드로 사용한다. OriginalFirstThunk 필드는 INT(Import Name Table)의 RVA 주소 값을 가지고 있다. 그 다음 TimeDataStamp는 시간과 날짜를 나타내며, 바인딩되지 않을 경우 항상 0이다. ForwarderChain 필드는 바인딩 여부와 관계되는 필드로 바인딩 되지 않은 이미지의 경우 0 이며 바인딩된 경우 이 값은 0이 아니다. Name 필드는 import된 DLL의 이름이 존재하는 RVA 값을 가진다. 마지막으로 FirstThunk 필드는 IAT(Import Address Table)의 RVA 주소 값을 가지고 있다.

이러한 구조는 로드하는 DLL의 수만큼 존재하며 맨 마지막에는 NULL로 채워진 해당 구조체가 존재하므로 배열의 끝을 알려준다. IMAGE_IMPORT_DESCRIPTOR의 필드 항목을 통해 알 수 있는 INT와 IAT의 값을 확인해보자.

그림 30. INT와 IAT

여기서 INT와 IAT가 동일한 값을 가리킨다는 것을 알 수 있다. 하지만 메모리에 올라오면서 PE 로더가 IAT엔 실제 함수의 명령어 위치를 채워주게 되며, INT에는 파일에서와 마찬가지로 임포트하는 함수의 이름을 가리키고 있다. 그렇다면 메모리에서 IAT 기록되어 있는 함수의 주소는 어떻게 얻어오는 것일까? 크게 네 단계로 나눌 수가 있다. 아래의 그림을 보자.

그림 31. IAT에 함수 주소 기록 과정

우선 로더는 A.EXE 파일이 필요로 하는 DLL을 로드하고자 한다. 이를 위해 Import 섹션의 존재하고 있는 IMAGE_IMPORT_DESCRIPTOR(IID)를 통해 어떠한 DLL을 필요로 하는지 이름을 얻는다. 그리고 해당 DLL들을 LoadLibrary API를 통해 메모리에 올리고자 한다. 해당 DLL을 찾은 프로세스는 DLL을 매핑하기 위한 공간을 확보한 다음 ImageBase에 지정된 주소로 매핑을 시도하며, 만약 해당 주소에 매핑하지 못한 경우 재배치를 하여 다른 주소에 매핑을 한다.

매핑이 되었다면 로더는 IID의 OriginalFirstThunk 필드를 통해 INT에 존재하고 있는 함수에 대한 정보를 얻어온다. 그 다음으로 로더는 해당 함수들의 함수 포인터 즉, 함수의 시작 주소를 얻고자 획득하고자 한다.

로더는 dll의 Export 섹션에서 IMAGE_EXPORT_DIRECTORY 구조체를 참고하여 AddessOfName 멤버를 통해 해당 함수의 이름을 비교하여 원하는 함수의 이름을 찾는다. 이때 몇 번째 인덱스에 존재하는지 확인을 한 다음 AddressOfNameOrdinals 필드를 참조한다. Ordinal 배열에서 해당 인덱스 번호에 맞는 값을 찾은 뒤, AddressOfFunctions 멤버를 이용해 EAT에서 해당 인덱스 번호에 맞는 함수의 시작 주소(RVA)를 얻는다.

마지막으로 해당 함수의 포인터를 획득한 다음 로더는 중요한 과정을 수행하게 되는데, 바로 위 과정을 통해 얻은 함수의 포인터(함수의 시작 주소)를 저장하는 것이다. IID의 FirstThunk 필드 값을 통해 IAT의 주소를 얻을 수가 있고, 첫 번째 과정에서 읽은 것과 같은 함수에 세 번째 과정에서 얻은 함수의 시작 주소를 기록하게 된다.

이러한 과정을 통해 파일에서 IAT는 INT와 같은 곳을 가리키지만, 메모리에서는 INT와는 전혀 다른 실제 함수의 시작 위치를 가리키고 있게 된다. 다시 말해, IAT는 PE 파일 이미지로 존재할 때와 실제로 프로세스 주소 공간 내로 매핑되었을 때의 내용이 달라진다. DLL 바인딩을 할 경우 DLL을 로딩하기 전에, IAT에 실제 함수의 주소를 고정시켜버리게 되어 프로그램이 실행될 때마다 이러한 과정을 거치지 않게 된다.

  Relocation Section

앞서 논의한 바와 같이 로더는 실행 파일을 로드할 때 지정된 ImageBase에 실행 파일 이미지를 로드하고자 한다. 하지만 해당 주소에 이미 다른 실행 파일 이미지가 로드되어 있는 경우 중첩되어 그 주소를 사용할 수는 없다. 이런 경우 로더는 매핑 가능한 다른 주소를 찾아 해당 주소에 로드해야한다. 대부분의 DLL은 0x10000000 영역이 기본 ImageBase로 처음에 로드되는 DLL의 경우 상관 없지만 두 번째부터는 다른 주소를 사용해야만 한다.

로딩 주소가 바뀌게 되면 절대 주소를 사용한 것은 반드시 바뀐 주소에 해당하는 값으로 고쳐 주어야 한다. 그렇지 않으면 0x10000000에 로딩된 다른 DLL의 메모리 영역을 참조하게 된다. PE에서는 이렇게 고쳐 주어야 하는 곳을 재배치 섹션에 모아서 저장해 두고 있다. 재배치 섹션의 구조를 한번 살펴보자.

그림 32. IMAGE_BASE_RELOCATION 구조체

기준 재배치 섹션은 단순한 구조를 가지고 있다. VirtualAddress 필드는 기준 재배치가 시작되어야 할 메모리 상의 번지에 대한 RVA이다. 실제 갱신할 위치의 표현은 "기준 RVA+재배치 Offset"으로 구성되고 이때 기준 RVA에 해당하는 것이 이 필드의 값이다. 재배치 섹션 내의 재배치 블록은 4K 단위의 구조체를 포함하는 블록이 존재하기에 나뉘어지는데, 이때 SizeOfBlock 필드의 값은 자신을 포함하고 있는 구조체의 크기를 말한다.

이 뒤에는 재배치가 적용되어야 할 대상에 해당하는 가상 주소에 대한 정보를 담은 WORD 타입의 배열이 온다. 해당 배열의 각 엔트리는 두 필드로 구성되는데 하나는 재배치 타입이며, 다른 하나는 재배치 오프셋이다.

그림 33. TypeOffset 엔트리 구조

재배치 타입의 경우 거의 큰 의미가 없는 값으로 Win32 PE의 경우 3, Win64의 경우 10이 된다. 가끔 재배치 그룹의 마지막 엔트리에 이 필드의 값이 0인 경우가 있는데 이는 해당 구조체가 4 바이트 단위로 정렬되기 때문에 이것을 맞추어 주기 위한 패딩으로 사용될 뿐이다.

다음으로 재배치 오프셋은 재배치할 대상의 번지 값에 대한 오프셋이다. 오프셋의 기준은 위에서 언급하였던 IMAGE_BASE_RELOCATION 구조체의 VirtualAddress 필드의 값이 된다. 따라서 실제로 갱신되어야 할 위치의 RVA는 VirtualAddress 필드 값에 재배치 오프셋 값을 더한 결과가 된다.

재배치 오프셋이 12 Bit 밖에 되지 않아 기준이 되는 VirtualAddress로부터 4095만큼까지만 접근이 가능하다. 그렇다면 그 이상으로 떨어진 지점은 어떻게 표현할까? 새로 VirtualAddress를 지정해주면 된다. 즉 하나 이상의 VirtualAddress 필드가 존재할 수 있으며 이에 따라 각 배열이 뒤에 붙게 된다.

재배치는 다음의 과정으로 이루어진다. 만약 ImageBase의 값과 실제 로드될 주소가 다른 경우 그 값의 차이인 델타 값을 구한다. 예로 원래는 0x10000000에 로드될 a.dll이 0x15000000에 로드되었다면 델타 값은 0x05000000이 된다. 그 다음 아래와 같은 재배치 섹션을 확인해보자.

그림 34. a.dll의 재배치 섹션

VirtualAddress 필드 값이 0x10000인 것을 확인할 수 있다. 해당 섹션은 .text 섹션으로 TypeOffset를 따라가보자. 해당 RVA 0x10000의 RAW는 0x600으로 재배치 오프셋인 0xE15과 0xE41를 각각 더하면 TypeOffset[0]이 나타내는 파일에서의 주소는 0x1215와 0x1241이 된다. 해당 값을 확인해보자.

그림 35. 재배치 해야할 주소 확인

이 위치에 있는 것이 무엇을 뜻하는지 어셈블리어로 확인해보자. 첫 번째 TypeOffset[0]은 MOV 명령어의 오퍼랜드로 사용되고 두 번째 TypeOffset[1]은 CALL 명령어에 사용되는 것을 확인할 수 있다.

그림 36. 재배치 할 주소의 명령어

재배치 해야할 값을 찾았으니 이제 이 값에 위에서 구한 델타 값 0x05000000을 각각 더해주게 된다. 따라서 0x1215에 있는 값은 0x15000000에 매핑된 이후 [0x6DE40318+0x05000000]이 되며, 0x1241에 있는 값은 매핑된 이후 [0x6DD705E4+0x05000000]이 된다. 이와 같이 재배치 섹션은 어떠한 값을 바꾸어야 하는지 알려주는 역할을 한다.

하지만 기준 재배치를 수행해야 할 상황이 되었을 때 발생할 수 있는 문제점 또한 존재한다. 크게 두 가지 문제점이 있는데 첫째로, 로더는 재배치 섹션을 스캔하면서 재배치 섹션 내에 존재하는 각 오프셋이 가리키는 위치의 해당 모듈의 코드를 모두 수정해야한다. 이것은 응용프로그램의 초기화 시간을 더 늘어나게 만든다.

둘째로, 로더가 재배치 섹션의 엔트리가 지시하는 해당 번지 값을 수정할 때 발생하는 문제가 있다. 갱신되어야 할 해당 주소 공간의 번지 값은 .text 섹션에 존재하는데, 코드 섹션의 경우 Write 속성이 없기 때문에 결국 번지 값을 수정하기 위해 섹션의 속성을 변경해야만 한다.

API Hooking

위 과정에서 본 것과 같이 IAT는 읽을 수 있을 뿐만 아니라 쓰기 속성을 가지고 있다. 따라서 이러한 속성을 이용해 기존의 API에 대한 호출을 자신이 정의한 API로 향하도록 변경할 수 있다. 이를 API 후킹이라 한다. 이번 장에서는 DLL 인젝션을 진행하는 방법과 IAT 후킹에 대하여 알아보자.

  DLL Injection

몇 가지 인젝션 방법 중 세 가지 방법에 대하여 알아보자. 우선 DLL 인젝셕은 다른 프로세스에게 강제로 DLL을 로딩시키도록 하는 것으로, 원하는 기능을 수행하는 DLL을 다른 프로세스에 매핑시켜 원하는 동작을 수행하도록 한다. 여러 방법 중 우선 CreateRemoteThread API를 이용하는 방법에 대하여 알아보자.

흔히 DLL을 자신의 프로세스에 로드하기 위해서는 LoadLibrary API를 사용한다. 하지만 다른 프로세스에게 LoadLibrary API를 사용하여 DLL을 로드 시킬 수가 없으므로 CreateRemoteThread API를 통해 다른 프로세스에게 스레드를 실행시키도록 하여 DLL을 로드시킬 수 있다.

그림 37. CreateRemoteThread API

위에는 CreateRemoteThread API의 인자로 어떠한 것이 있는지 나타내는 것으로 중요한 항목은 바로 네 번째 인자인 lpStartAddress이다. 해당 파라미터는 스레드가 수행할 함수의 주소를 넘겨주는 것으로 다른 프로세스에서 수행할 함수의 주소를 말한다. 바로 여기에 LoadLibrary API의 주소를 주고, 다섯 번째 인자에 로드시키고자 하는 DLL의 이름을 넘겨주면 된다.

다음으로 레지스트리를 통해 쉽게 DLL Injection하는 방법에 대하여 알아보자. 바로 AppInit_DLLs라는 레지스트리 키로 여기에 인젝션하고자 하는 DLL의 경로를 기입해준 뒤 재부팅을 시행하면, 재부팅하면서 실행되는 모든 프로세스에 해당 DLL을 인젝션 시켜준다. 위 CreateRemoteThread가 하나의 프로세스를 지정해주는 것과는 다르게 모든 프로세스에 시행된다는 점이 차이난다고 할 수 있다. 해당 경로는 다음 과 같다.

그림 38. AppInit_DLLs Registry Key

마지막으로 알아본 DLL 인젝션 방법은 윈도우 운영체제가 제공하는 API를 사용하는 방법이다. 윈도우 운영체제는 사용자에게 GUI를 제공해주고, 사용자는 제공받은 GUI를 이용하여 원하는 동작을 수행할 수 있다. 동작을 수행하는데 있어 마우스나 키보드와 관련된 동작을 수행하게 되는데 이러한 동작은 윈도우 운영체제가 Event Driven 방식으로 처리한다. 다시 말해 이러한 동작을 이벤트로 발생시켜 운영체제가 그 이벤트에 맞는 메시지를 해당 응용 프로그램에게 전달하여 처리하는 방식이다.

아래 그림을 보면 메시지 후킹이 어떤 지점에서 이루어지는지 볼 수 있다. 사용자가 어떠한 행위를 했을 때 이벤트가 발생되고, 이벤트 발생으로 인해 OS에서 응용 프로그램으로 보낼 메시지들이 OS Message Queue에 추가된다. 운영체제는 해당 이벤트가 어떤 응용 프로그램에서 발생했는지 파악한 다음, OS 큐에서 메시지를 꺼내 해당 응용 프로그램의 메시지 큐에 전달한다. 해당 응용 프로그램은 자신의 응용 프로그램 메시지 큐에 해당 메시지가 추가된 것을 확인하고 해당 이벤트 핸들러를 호출한다. 이러한 방식으로 윈도우는 메시지를 전달한다.

그림 39. 메시지 전달 방식

윈도우 운영체제어서는 이러한 메시지를 후킹하기 위한 API인 SetWindowsHookEx()를 기본적으로 제공한다. 이 API는 훅 체인에 응용 프로그램이 정의한 후크 프로시저를 설치하며 이를 통해 사용자는 특정 유형의 이벤트를 모니터링 할 수 있다.

그림 40. SetWindowsHookEx API

만약 해당 API를 구현하는 HookKey.dll이 존재하며 이를 실행하기 위한 HookMain.exe를 제작하였다고 가정하자. HookMain.exe를 실행하면 HookKey.dll이 해당 프로세스의 메모리에 로드되며 SetWindowsHookEx()가 호출된다. 이렇게 메시지 후킹이 걸린 상테에서, 다른 프로세스가 해당 이벤트를 발생시킨다면 HookKey.dll은 그 프로세스에서도 로딩된다.

그림 41. SetWindowsHookEx를 이용한 후킹

이러한 방법들을 통해 원하는 DLL을 프로세스에 인젝션 할 수 있다.

  IAT Hooking

IAT는 위에서 자세히 설명한 바와 같이 Import Address Table로, 메모리에 매핑되면서 PE 로더가 IAT에 실제 함수의 주소를 기록해준다. 다시 말해 파일에서의 IAT는 실제 함수의 주소를 가리키고 있는 것이 아니며 일반적으로 INT와 같은 곳을 가리키고 있다. 하지만 메모리에 올라온 뒤에는 해당 프로그램이 사용하고자 하는 함수의 주소가 기록되어 있다.

IAT 후킹은 바로 이 IAT에 기록되어 있는 주소를 바꿔 원하는 함수의 주소로 가도록 하는 것이다. 이를 통해 다양한 파라미터나 리턴 값을 조작하는 등의 작업을 수행할 수 있다. 그렇다면 일반적으로 API가 호출되는 상황에 대하여 먼저 알아보자.

그림 42. 일반적인 API 호출 과정

위 예에서 Sleep API를 호출하고자 할 때 바로 CALL 명령어를 통해 763410FF(Sleep함수)를 호출하는 것이 아니라 DS:[43B168]을 참조해 해당 주소에 있는 763410FF라는 주소를 얻어 이를 호출한다. 그렇다면 왜 바로 CALL 763410FF라 하지 않을까? 이는 DLL의 특성 상 운영체제 버전이나 언어, 서비스 팩에 따라 DLL의 버전이 다르며 해당 함수의 위치가 달라지기 때문에 IAT에 매핑된 주소를 참조하여 함수를 호출하도록 하는 것이다. 바로 43B168가 IAT의 한 부분으로 Sleep 함수의 실제 주소가 메모리에 올라오면서 기록된 것이다.

따라서 IAT를 후킹한다는 것, 좀 더 구체적으로 IAT에서 Sleep()을 후킹하는 것은 바로 해당 API의 실제 주소를 가지고 있는 IAT의 주소(43B168)에 위치한 주소 값을 바꾸는 것이다. 후킹된 모습은 다음과 같다.

그림 43. 후킹된 API 호출 과정

이전과 똑같이 Sleep()을 호출하기 위해 IAT를 참조하게 된다. 하지만 해당 IAT는 후킹되어 기존의 Sleep() 함수의 주소가 아닌, 후킹 함수의 주소(0x401020)를 가리키고 있다. 결국 프로세스는 Sleep()을 호출했지만 후킹된 주소로 넘어가게 되며, 후킹된 주소에서 파라미터를 변조한 후 원래의 Sleep() 함수로 진입하게 된다.

이와 같은 IAT 후킹은 간단하게 이루어지면서도 해당 프로세스에서 후킹한 함수를 호출할 때마다 후킹 함수를 지나가게 되므로 강력하다고 할 수 있다.

Windows_API_Hooking.pdf

목차

1    Intro. 4

2    Prior Knowledge. 5

2.1    What is an API?. 5

2.2    What is an API Hooking?. 6

3    User Mode Hooking. 7

3.1    IAT Hooking. 7

3.2    Message Hooking. 13

4    Kernel Mode Hooking. 15

4.1    System Call 15

4.2    INT 0x2E Hooking. 16

4.3    SYSENTER Hooking. 19

4.4    SSDT Hooking. 22

5    Conclusion. 26

6    Reference. 27

그림

그림 1. User Mode & Kernel Mode. 5

그림 2. 정상호출과 후킹된 호출... 6

그림 3. PE View로 본 IAT. 7

그림 4. Sleep API 7

그림 5. 메모리에서 Sleep API 8

그림 6. Sleep API in IAT. 8

그림 7. 코드 패치... 9

그림 8. 호출할 함수 주소 변경... 9

그림 9. 함수 호출 - Debugger 10

그림 10. Sleep이 호출하는 주소 변경... 10

그림 11. Code Cave를 사용한 후킹... 11

그림 12. (C) 단계 원래 명령어와 조작된 명령어... 11

그림 13. 조작 코드... 12

그림 14. Ntdll.dll의 API 12

그림 15. 메시지 전달 방식... 13

그림 16. SetWindowsHookEx API 14

그림 17. DLL Injection. 14

그림 18. System Call 과정... 15

그림 19. INT 0x2E와 SYSENTER. 16

그림 20. IDT 구조... 17

그림 21. INT 0x2E의 ISR(KiSystemService) 17

그림 22. IDT 주소와 각 엔트리 구조... 18

그림 23. IDT 0x2E 번째 Entry. 18

그림 24. IDT Entry 0x2E 후킹... 19

그림 25. Read MSR 0x176. 20

그림 26. Write MSR 0x176. 20

그림 27. 정상적인 SYSENTER 진입... 21

그림 28. 후킹 된 SYSENTER 진입... 21

그림 29. 전체적인 시스템 호출 과정... 22

그림 30. SSDT Hooking 과정... 23

그림 31. KeServiceDescriptorTable 구조... 24

그림 32. SSDT를 통한 Native API 접근... 24

그림 33. SSDT Hooking. 25

KiSystemService가 호출될 때 EAX에는 사용자 영역에서 요청한 서비스 번호가 저장되어 있으며, EDX에는 이러한 서비스에 사용될 인자가 저장되어있다. 이러한 시스템 호출 번호(EAX)에 맞게 KeServiceDescriptorTalbe에서 Native API의 주소를 가지고 온다. 그 후 시스템 호출을 종료하고 다시 사용자 모드로 복귀하게 되는데, 이러한 과정은 아래의 그림과 같다.

그림 29. 전체적인 시스템 호출 과정

결국 SSDT(KiServiceTable)에서 서비스 호출 번호에 맞는 주소를 얻은 다음 이를 호출하는 형태로 진행되는 것이다. 그렇다면 SSDT Hooking은 어느 부분을 후킹해야 하는 것일까? 위 그림의 과정에서 설명하자면 바로 GetFuncAddress 과정에서 후킹한다고 할 수 있다. SYSENTER를 통해 KiFastCallEntry로 진입한 후 서비스 번호에 맞는 서비스 루틴을 SSDT에서 얻어온다. 따라서 SSDT에 존재하고 있는 각 서비스 루틴의 주소를 조작하므로 후킹을 진행할 수 있다. 이를 표현한 그림은 아래와 같다.

그림 30. SSDT Hooking 과정

해당 시스템 호출의 서비스 루틴을 가지고 오는 과정에서 SSDT를 참조하는데, SSDT의 해당 번호가 나타내는 주소를 후킹하므로 우리가 원하는 흐름으로 조작할 수 있다. 위 그림을 예로 시스템 호출이 요청되었을 때 서비스 번호가 저장되어 있는 EAX의 값이 0xAD라면 SSDT에서 0xAD가 가리키는 서비스 루틴의 주소 0xCCCCCCCC가 반환되어 이를 호출한다. 하지만 만약 공격자가 SSDT를 후킹하여 0xDDDDDDDD로 서비스 루틴의 주소를 변경하였다면, 시스템 호출 0xAD가 발생할 때마다 0xDDDDDDDD를 지나가게 된다.

KeServiceDescriptorTable은 네 가지 항목을 가지고 있는 구조체로 아래 그림과 같이 나타나는 것을 확인할 수 있으며 중요한 첫 번째 항목과 네 번째 항목에 대하여 알아보자. 첫 번째 항목은 KiServiceTable(SSDT)의 주소를 담고 있는 항목으로 이 값을 통해 SSDT에 접근하여 Native API의 주소를 얻을 수가 있으며. 네 번째 항목은 ParamTableBase는 KiArgumentTable의 주소 값을 담고 있는데, 이들 각각은 SSDT의 Native API와 일 대 일로 대응한다.

그림 31. KeServiceDescriptorTable 구조

SSDT의 주소는 첫 번째 항목의 값인 0x80503b8c로 해당 주소를 확인해보면 여러 주소들이 존재하고 있는 것을 아래와 같이 확인할 수 있다. 각 값들은 Native API의 실제 주소이며 해당 주소를 확인해보면 Native API의 이름을 같이 볼 수 있다.

그림 32. SSDT를 통한 Native API 접근

시스템 호출을 통해 커널 모드로 진입할 때 EAX에는 요청한 서비스 번호를 저장하고 있고 EDX에는 인자로 사용될 포인터를 포함하고 있다고 하였다. 그러므로 어떠한 Native API를 요청하는지 알기 위해선 SSDT의 주소에 [EAX*4]를 더해주면 그 주소를 알 수 있다. 실제 SSDT Hooking도 이와 같은 방식으로 진행한다. 그렇다면 이제 실제 SSDT의 주소를 변경해보자.

SSDT를 통해 접근할 수 있는 Native API 함수 5개의 주소를 변경해보자. WinDBG를 사용하기 때문에 특정 주소 값을 수정하기 위한 "ed" 명령어를 사용하였으며, 기존의 주소를 아무 의미 없는 값들로 변경하였다. 그 후 SSDT를 확인해보면 위 그림 32에서 확인할 수 있던 주소들이 내가 수정한 값으로 변경되어 있는 것을 확인할 수 있다.

그림 33. SSDT Hooking

이렇게 후킹을 하면 해당 Native API가 요청될 때마다 후킹된 주소로 넘어가게 된다. 위 실습은 아주 극단적인 예를 보여주기 위한 과정으로 바로 블루 스크린이 나타난다. 실제 후킹 공격을 진행하기 위해선 메모리 쓰기 보호(Write Protect)를 해제하는 작업을 추가해야 하며, 매크로와 같은 방식을 통해 공격을 진행한다.

Conclusion

사용자 영역 후킹과 커널 영역 후킹에 대해 디버거를 통해 접근해보며 어떻게 후킹이 이루어지는지 알아보았다. 실제 공격을 하는데 있어 디버거를 사용하는 것보다는 프로그래밍을 통해 쉽게 공격이 이루어질 수 있도록 한다. 그렇기에 다른 사람들의 글 대부분이 이러한 프로그래밍에 초점을 맞추고 어떻게 코드를 설계하는지, 코드가 의미하는 것이 어떤 내용인지 잘 설명하고 있으므로 이후에 코드와 관련된 내용을 학습하면 더 좋을 것이다.

필자도 코드를 통해 어떻게 동작하겠구나 생각해볼 수 있었지만 직접 디버거를 통해 접근해볼 때마다 "여기를 수정하면 어떻게 될까?"라는 등 좀 더 깊이 있는 생각을 해볼 수가 있었다. 이후에는 여기서 다루지 못한 후킹들에 대하여 추가로 학습해볼 것이며 윈도우 운영체제와 관련된 내용을 더 공부해보아야겠다는 생각을 할 수가 있었다.

Reference

[+] 리버싱 핵심 원리(악성 코드 분석가의 리버싱 이야기) |이승원|인사이트|2012.09.30

[+] http://blog.naver.com/ikariksj/140056467421    

[+] http://www.codeproject.com/Articles/2082/API-hooking-revealed

[+] http://www.reversecore.com/23

[+] http://yokang90.tistory.com/58

[+] http://xcoolcat7.tistory.com/542

[+] http://egloos.zum.com/maxtrain/v/2775961

[+] http://kernel32.tistory.com/15

[+] https://msdn.microsoft.com/en-us/library/windows/desktop/ms644990(v=vs.85).aspx

[+] https://blogs.msdn.microsoft.com/kocoreinternals/2009/03/16/idt-isr/

[+] https://en.wikipedia.org/wiki/Model-specific_register

[+] http://amur.tistory.com/entry/커널모드에서-유저모드-분석하기

3장에서는 사용자 모드 후킹에 대하여 알아보았다면 이번 장에서는 커널 모드 후킹에 대하여 알아볼 것이다. 커널 모드에서 이루어지는 후킹의 경우 단순히 JMP 명령어를 설치하는 것이 아니라, 특정한 구조체에 포함된 값을 수정하는 등 작업을 수행해야 하기 때문에 아무래도 사용자 모드의 후킹보다 복잡하다. 이제 이러한 커널 모드 후킹에 대하여 알아보자.

System Call

운영체제는 사용자 모드(Ring 3)와 커널 모드(Ring 0)라는 두 가지 형태의 권한이 존재하고 있다. 이렇게 분리되는 이유는 다양하지만, 아무래도 보안과 관련된 점 또한 매우 중요하다. 만약 분리되어 있지 않을 경우 어떠한 프로세스든지 운영체제의 핵심 기능을 조작할 수 있게 되므로 이를 방지하기 위해선 분리되는 것이 좋다. 그렇기에 커널 모드에서는 사용자 모드를 조작할 수 있지만, 반대로 사용자 모드에서 커널 모드는 조작할 수가 없다.

하지만 커널 영역에 접근할 수 없다는 것은 해당 프로세스가 디스크의 내용을 읽을 수가 없게 되고 그 외에도 하드웨어나 프로세스에 직접 접근할 수 없게 된다. 그렇다면 어떻게 우리가 제작한 사용자 모드의 프로그램이 프로세스나 디스크와 관련된 작업을 수행할 수 있을까? 이는 바로 시스템 호출(System Call)을 사용하여 사용자 모드의 프로세스가 커널 영역에 접근을 요청할 수 있기 때문이다.

그림 18. System Call 과정

위 그림과 같이 응용프로그램이 Kernel32.dll의 API를 호출하면 해당 API는 Ntdll.dll의 함수를 호출한다. 그리고 호출된 Ntdll.dll은 자신이 커널에 요청해야 할 서비스 번호를 가지고 시스템 호출을 진행하며 이 과정이 바로 응용프로그램이 커널에게 시스템 자원 접근을 요청하는 과정이다. 이때 지정한 서비스를 요청하기 위해 EAX에 원하는 서비스 번호를 저장하고 EDX에는 이 서비스에 사용될 인자를 가리키는 포인터를 넘겨준다. 이러한 과정을 통해 커널에서는 어떠한 서비스가 필요한지, 어떠한 인자를 넘겨주었는지 알 수가 있다.

System Call은 "INT 0x2E"와 "SYSENTER" 두 가지 명령어로 나누어진다. 이렇게 나누어지는 기준은 바로 Windows XP 이전과 이후로, 이전에는 INT 0x2E를 사용하였으며, XP부터는 SYSENTER를 사용한다. INT 0x2E의 경우 상대적으로 무거운 인터럽트를 진행하므로 클럭 수를 많이 소모하였기 때문에, 이를 보완하기 위해 SYSENTER가 나온 것이다. 이러한 차이 외에 앞으로 진행할 후킹 과정에서도 차이점을 가지므로 이에 대하여 알아보자.

그림 19. INT 0x2E와 SYSENTER

우선 INT 0x2E의 경우 IDT(Interrupt Descriptor Table)을 참조하여 바로 System Service Dispatch(KiSystemService)로 간다. 하지만 SYSENTER는 SYSENTER_EIP(MSR)를 참조하여 KiFastCallEntry로 진행한 다음 KiSystemService로 간다. 마지막으로 INT 0x2E의 경우 IRET라는 명령어로 커널 모드에서 다시 사용자 모드로 복귀하고, SYSENTER의 경우 SYSEXIT라는 명령어를 통해 사용자 모드로 복귀한다. 이것이 별로 중요하게 느껴지지 않을 수 있지만, 후킹을 진행할 때 두 명령어에 따라 후킹 지점이 달라진다. 이러한 각 후킹 방법에 대해서는 바로 뒤에서 알아보자.

INT 0x2E Hooking

INT 0x2E는 인터럽트 0x2E로 IDT에 정의된 인터럽트 서비스 루틴(ISR)을 수행한다. 여기서 IDT는 256개의 Entry로 이루어진 배열로 엔트리 하나당 하나의 인터럽트에 대응하며 각 인터럽트는 IDT로부터 처리할 함수의 주소(ISR)을 전달받는다. 각 엔트리에는 지정된 값이 담겨 있으며 WinDBG로 확인했을 경우 아래와 같은 모습을 볼 수가 있으며 INT 0x2E의 경우 IDT에서 바로 KiSystemService를 가리키고 있는 것을 확인할 수 있다.

그림 20. IDT 구조

이 과정을 요약하면, XP 이전 버전에는 응용프로그램이 API를 호출하면 Ntdll.dll의 Zw*, Nt* 함수를 호출하게 된다. 이러한 함수는 결국 INT 0x2E를 통해 운영체제에게 커널 모드 작업을 요청한다. 이때 INT 0x2E가 IDT에서 KiSystemService의 주소를 참조하여 진행하는 것이다. 따라서 우리가 후킹 해야 할 부분은 바로 IDT이다. IDT가 가리키는 2E의 주소로 가보면 실제로 KiSystemSerive가 존재하고 있는 것을 아래와 같이 확인할 수 있다.

그림 21. INT 0x2E의 ISR(KiSystemService)

IDT를 후킹 할 것이므로 우선 IDT의 주소를 알아야 하는데, IDTR 레지스터에 IDT의 Base Address와 IDT의 크기가 저장되어 있다. WinDBG를 통해 알 수 있는 방법은 IDTR 레지스터의 값(주소)를 출력하거나 "!idt"를 통해 해당 주소를 알아낼 수가 있다. IDT의 Entry 구조는 아래 그림과 같이 8 바이트씩으로 이루어져 있으며 Entry가 가리키는 ISR의 주소가 하위 2바이트, 상위 주소 2바이트로 나누어져 있다.

그림 22. IDT 주소와 각 엔트리 구조

하나의 엔트리가 8바이트로 이루어져 있다는 것을 확인했다. 그렇다면 우리가 찾고자 하는 엔트리는 0x2E 번째 엔트리이므로 IDT Base Address에 0x170을 더한 위치에 존재하고 있다. 아래 결과와 같이 8003f570부터 해당 엔트리가 존재하고 있다. 하위 2바이트와 상위 2바이트를 조합하여 INT 0x2E의 ISR은 8053f481이라는 것을 알 수 있다.

그림 23. IDT 0x2E 번째 Entry

이제 우리가 어떤 주소(8003f570)를 후킹 해야 하는지 알았으니, 본격적인 후킹을 진행해보자. 이번 후킹 역시 프로그래밍을 통해 진행하는 것이 아니라 원리를 이해하기 위해 커널 디버거 WinDBG를 통해 진행할 것이다. 해당 0x2E의 ISR을 FFFFFFFF로 조작하는 과정으로 "0000"으로 채운 곳은 오프셋이 아닌 부분으로 구분을 위해 "0"으로 채운 것이다.

그림 24. IDT Entry 0x2E 후킹

이처럼 IDT가 후킹 된 상황에서 INT 0x2E를 통한 시스템 호출(System Call)이 발생하면 사용자 모드에서 커널 모드로 넘어갈 때 후킹된 주소로 가게 된다. 실제 후킹도 이와 같은 과정으로 진행되며, 대신 IDT의 주소를 얻을 때 "sidt" 명령어를 사용하여 주소를 얻는다. Sidt 명령어는 IDT의 주소를 저장하고 있는 IDTR 레지스터의 값을 참조하여 값을 얻어 온다. 또한 디버거를 통해 수정하는 것이 아니라 프로그래밍을 통해 수정하고자 할 때, 인터럽트를 비활성화("CLI" 명령어)해야 한다. 그리고 후킹이 완료되면 인터럽트를 다시 활성화("STI" 명령어) 시켜 정상적으로 구동되게끔 해야 한다.

SYSENTER Hooking

윈도우 XP 이상의 버전에서는 INT 0x2E가 아닌 SYSENTER를 사용한다. 시스템 호출이 요청되면 NTDLL은 EAX 레지스터에 해당 시스템 호출의 번호를 저장하고 EDX 레지스터에는 인자로 사용될 주소를 넣어준다. 그리고 SYSENTER 명령을 실행하여 커널 영역으로 들어오게 되는데, 이때 바로 커널로 들어가는 것이 아니라 실행될 커널의 주소(KiFastCallEntry)를 SYSENTER_EIP(MSR 0x176 레지스터)에서 참조하여 KiFastCallEntry 로 넘어가게 되는 것이다.

MSR은 Model-Specific Register로 디버깅이나 프로그램 실행 추적, 컴퓨터 성능 모니터링, 특정 CPU 기능 전환에 사용되는 각종 제어 레지스터x86 명령어의 집합이다. 이러한 집합 중 MSR 0x176에는 IA_SYSENTER_EIP(KiFastCallEntry)가 존재하고 있으며, MSR에 접근하고자 할 때는 "rdmsr", "wrmsr" 명령어를 통해 접근할 수가 있다. 우리가 찾아야 할 것은 MSR 0x176이며 다음과 같은 결과를 얻을 수가 있다.

그림 25. Read MSR 0x176

MSR 0x176이 제대로 KiFastCallEntry를 가리키고 있는 것을 확인할 수 있다. 바로 이 부분의 값을 바꾸어 SYSENTER를 후킹 할 수 있다. MSR 레지스터를 읽을 때는 rdmsr 명령어로 읽었다면, MSR 레지스터의 값을 변경할 때는 "wrmsr" 명령어를 사용하면 된다. 아래의 그림을 보자.

그림 26. Write MSR 0x176

실제로 위와 같이 옳지 않은 주소로 변경하면 당연히 블루 스크린을 맞이할 수 있을 것이다. 그렇다면 abex'sCrackMe01.exe를 가지고 직접 코드의 흐름을 조작하여 보자. 우선 아래의 코드는 정상적인 흐름을 나타낸다. Ntdll.dll의 함수를 추적하여 들어가보면 KiFastSystemCall이라는 부분을 볼 수 있는데 이는 SYSENTER 명령어를 통해 KiFastCallEntry로 가기 위한 부분이다. KiFastSystemCall에는 SYSENTER 명령어가 위치하고 있는 것을 확인할 수 있다.

그림 27. 정상적인 SYSENTER 진입

정상적인 SYSENTER의 흐름을 wrmsr을 통해 조작해보자. MSR 0x176를 11111111 로 수정하므로 비정상적인 흐름으로 동작하도록 수정하였다. 그리고 이전과 같이 SYSENTER 명령어를 실행하기 전에 원래 MSR 0x176(KiFastCallEntry)의 주소에 BP를 설정한 다음 진행을 해보자. 정상적인 흐름이라면 KiFastCallEntry 에서 멈추어야 하지만, 조작된 MSR 0x176이 가리키는 주소 11111111로 흐름이 바뀌었다.

그림 28. 후킹 된 SYSENTER 진입

이러한 방법을 통해 SYSENTER Hooking(또는 MSR Hooking)을 진행할 수 있으며, 실제 11111111에 후킹 함수가 존재할 경우 시스템 호출이 발생할 때마다 후킹 함수를 지나가게 된다. 공격자의 입장에서 이러한 System Call Hooking을 진행하며 후킹 함수에 과도한 조건을 걸어놓는다면 시스템 성능이 크게 하락하여 사용자가 쉽게 알아차릴 수 있을 것이다.

  Intro

리버싱을 하는 데 있어 흔히 "Art of Reversing is an API Hooking"이라는 말과 같이 API 후킹은 리버싱의 꽃이라 일컬어진다. 어떤 윈도우 응용프로그램을 개발하기 위해서 우리는 다양한 종류의 언어나 도구를 사용할 수가 있다. 이런 언어나 도구를 사용하여 개발하는 방법은 다르더라도 결국, 개발된 프로그램의 내부로 들어가면 윈도우 운영체제가 제공하는 API를 호출한다.

이러한 API는 사용자 영역뿐만 아니라 커널 영역에서도 Native API의 형태로 존재하기 때문에 API 후킹을 이해하는 것은 윈도우의 많은 부분을 조작할 수 있음을 의미한다. 따라서 이번 문서에서는 API 후킹에 대한 이해를 도모하며, 기본적인 후킹의 방법에 대해 이해하므로 다른 후킹 방법 또한 낯설지 않도록 하는 것이 목적이다.

단, 후킹을 진행하는 자세한 코드들은 포함하지 않고, 어느 부분을 어떠한 방식으로 후킹 하는지 중점적으로 살펴볼 것이다. 코드들의 경우 다른 좋은 소스가 많으므로 그러한 요소들을 찾아보면 좋을 것이다. 이제부터 API 후킹에 대해 알아보자.

Prior Knowledge

이번 장에서는 구체적인 API 후킹에 대하여 알아보기 전에 우리가 알고 있는 API가 무엇인지 다시 한 번 정리해보고 API 후킹의 기본적인 개념에 대하여 알아볼 것이다.

  What is an API?

API란 Application Programming Interface의 약자로 단어 자체만으로는 무슨 뜻인지 이해하기 힘들다. 쉽게 말해 운영체제가 응용프로그램을 위해 제공하는 함수의 집합으로 응용프로그램과 디바이스를 연결해주는 역할을 한다. 좀 더 구체적으로 응용프로그램이 메모리, 파일, 네트워크, 비디오, 사운드 등 시스템 자원을 사용하고 싶더라도 이들에 대해 직접 접근할 수가 없다. 이러한 시스템 자원은 운영체제가 직접 관리하며 보안이나 효율 등 여러 면에서 사용자 응용프로그램이 접근할 수 없도록 막아놓았기 때문이다.

따라서 사용자 응용프로그램이 시스템 커널에게 이러한 시스템 자원의 사용을 요청해야 하며, 이 방법이 바로 MS 제공한 Win32 API를 이용하는 것이다. 즉 API 함수 없이는 프로세스, 스레드, 메모리, 파일, 네트워크, 레지스트리 등 시스템 자원에 접근할 수 있는 프로그램을 만들 수가 없다. 아래 그림은 32비트 Windows OS의 프로세스 메모리를 간략히 나타낸 그림이다.

그림 1. User Mode & Kernel Mode

실제 응용프로그램 코드를 실행하기 위해서는 많은 DLL이 로딩된다. 모든 프로세스는 기본적으로 kernel32.dll이 로딩되며, kernel32.dll은 ntdll.dll을 로딩한다. 바로 이 ntdll.dll의 역할이 사용자 모드에서 커널 모드로 요청하는 작업을 수행한다. 이러한 방식을 통해 시스템 자원에 접근할 수 있게 되는 것이다.

  What is an API Hooking?

API 후킹에 관해 이야기하기 전에 후킹에 대하여 먼저 알아보자. 후킹이란 이미 작성되어 있는 코드의 특정 지점을 가로채서 동작 방식에 변화를 주는 기술이라 할 수 있다. Hook이라는 단어 자체가 낚싯바늘 같은 갈고리 모양을 가지는데 이를 통해 무엇인가를 낚아채는 것과 같이 컴퓨터에서도 무엇인가를 낚아채는 형태로 사용될 수 있다.

그렇다면 API를 후킹 한다는 말은 무슨 뜻일까? 바로 Win32 API가 호출되는 중간에서 가로채어 제어권을 얻어낸다는 것이다. 그렇다면 어느 시점에 가로채는지 궁금할 수가 있다. API 후킹에는 많은 기법이 존재하는데 이러한 분류가 주로 어떤 방식을 사용하는지, 그리고 바로 어느 지점에서 가로채는지에 따라 분류되므로 이에 대해서는 각 방식에서 자세히 알아볼 것이다. 기본적인 후킹의 개념은 아래의 그림과 같다.

그림 2. 정상호출과 후킹된 호출

정상적인 경우 A 단계가 진행된 다음에 B가 진행되어야 하지만, 후킹 된 호출의 경우 A 단계 다음에 B가 진행되는 것이 아니라 C가 진행된 뒤 B가 진행된다. 이를 통해 A의 요청을 조작하거나 특정한 조건에만 B가 실행되도록 조작할 수가 있다. 위와 같은 방식으로 API를 후킹 하면 그 함수의 기능을 사용하지 못하게 할 수도 있고 어떻게 사용하는지 감시만 할 수도 있다. 심지어 전혀 다른 내용으로 바뀌게끔 할 수도 있다.

User Mode Hooking

Windows에서는 크게 사용자 모드(User Mode)의 후킹과 커널 모드(Kernel Mode)의 후킹으로 나누어진다. 이번 장에서는 사용자 영역에서 어떻게 API 호출이 이루어지는지, 그리고 어떻게 이들을 후킹할 수 있는지에 대하여 알아보자.

  IAT Hooking

3.1.1 IAT(Import Address Table)

IAT후킹은 IAT(Import Address Table)를 후킹 하는 것으로, IAT는 쉽게 말해 해당 프로그램이 어떤 라이브러리에서 어떤 함수를 사용하고 있는지를 기술한 테이블이다. 예를 들어, 어떤 프로그램이 Kernel32.dll의 GetDriveType API를 호출한다면 해당 API를 사용하기 위한 주소를 IAT에서 참조할 수 있다.

그림 3. PE View로 본 IAT

IAT 후킹은 바로 이 IAT에서 후킹하고자 하는 함수 주소를 내가 원하는 함수(이후 후킹 함수)로 교체하고, 후킹 함수에서 파라미터나 리턴 값을 조작하고 원래 함수를 호출하는 방법이 바로 IAT 후킹이다. 가장 쉬우면서도 안정적인 방법이라 일반적으로 자주 사용되는 후킹 방식이다. 그렇다면 일반적으로 API가 호출되는 상황을 보자.

그림 4. Sleep API

Sleep()를 호출할 때 직접 호출하지 않고 0x43B168 주소에 있는 값을 가져와서 호출한다. 0x43B168 주소는 해당 프로그램의 IAT 메모리 영역으로 0x76AE7990이라는 값이 존재하고 있다. 이제 이 값이 바로 해당 프로세스 메모리에 로딩된 Kernel32.dll의 Sleep 함수의 주소이다.

그렇다면 왜 0x40104F에서는 CALL 0x76AE7990이라 하지 않고 다른 곳을 참조하는 하여 접근하는 것일까? 이는 운영체제 버전이나, 어떤 언어, 서비스 팩이냐에 따라DLL의 버전이 다르며, 해당 함수의 위치가 달라지기 때문이다. 모든 환경에서 Sleep() 함수 호출을 보장하기 위해 컴파일러는 Sleep()의 실제 주소가 저장될 위치(0x43B168)를 준비하고 CALL DWORD PTR DS:[43B168]을 적어두기만 한다. 그 후 파일이 실행되는 순간 PE Loader가 0x43B168 위치에 Sleep() 함수의 주소를 입력해준다.

3.2.2 Hook

그렇다면 이러한 IAT의 개념에 대해 알아보았지만, 대체 이 부분 중 어느 곳을 후킹 해야 한다는 것인가 의문을 가질 수 있다. 위의 Sleep 함수를 예로, 사용자 모드에서 Sleep API가 호출되는 과정은 아래의 그림과 같이 나타낼 수 있다.

그림 5. 메모리에서 Sleep API

(A)는 3.2.1에서 이야기한 바와 같이 해당 함수를 사용하기 위한 주소 공간을 만들어 놓은 것이다. 이렇게 만들어 놓은 주소에 프로그램이 실행되며 PE 로더가 Sleep 함수의 주소를 채워 넣는다. 여기서 만들어진 주소 공간 43B168은 RVA 값이며, 이에 해당하는 파일 Offset은 39168이다. 39168은 바로 IAT 의 Sleep 함수가 위치한 Offset이다.

그림 6. Sleep API in IAT

만약 (A)에 존재하고 있는 값인 43B168을 다른 값으로 바꾸면 어떻게 될까? 직접 Sleep 함수를 호출하는 부분에 IsDebuggerPresent API의 IAT 주소를 넣어보자. 주소는 위 그림에서와 같이 Offset 39164이므로 이는 RVA 43B164가 된다. 이제 아래와 같이 코드를 패치해보자.

그림 7. 코드 패치

원래 Sleep()을 호출하던 부분에 IsDebuggerPresent()의 IAT 주소로 변경을 해주었다. 그렇다면 이제 위에서 언급한 바와 같이 PE 로더가 0x40104F에서 호출하는 함수의 주소를 0x43B164에서 참조하기 때문에 아래의 그림처럼 IsDebuggerPresent()가 위치하게 된다.

그림 8. 호출할 함수 주소 변경

이를 정리하자면, 프로그램이 사용하고자 하는 API를 호출할 때 해당 명령어에는 "CALL DWORD PTR DS:[IAT에 존재하는 해당 함수의 RVA]"로 나타내며, 프로그램이 실행되면서 실제 주소가 해당 DS:[RVA]에 올라오게 된다. 따라서 위와 같이 (A)를 후킹 하기 위해선 DS:[HookFunc]로 바꿔주어야 한다..

이번에는 (B)의 경우를 생각해보자. (A)는 프로그램이 실행되기 이전 파일의 형태에서 조작이 가능하였지만 (B)의 경우 파일이 실행되면서 43B168에 실제 Sleep API의 주소를 가지고 온다. 그러므로 (B) 부분은 파일이 아닌 프로세스일 경우에만 조작이 가능함을 알 수가 있다. 따라서 쉽게 DLL Injection과 같은 기법을 통해 프로세스의 메모리를 조작할 수 있지만, 이번 문서는 코드와 관련된 부분은 최대한 제외하고 원리를 이해함을 목적으로 할 것이기 때문에 필자는 디버거를 통해서 접근할 것이다.

그림 9. 함수 호출 - Debugger

위 그림을 보면 Sleep 함수를 호출할 때 43B168을 참조하며, IsDebuggerPresent 함수를 호출할 때는 43B164를 참고하는 것을 확인할 수 있다. 아래 덤프 영역을 보면 각각 해당하는 함수의 주소가 PE 로더에 의해 지정된 것을 확인할 수 있다. Sleep 함수가 가리키는 곳에는 76AE7990이 위치하며 다른 곳에는 76AEB0B0가 위치하고 있다. 해당 지점에는 각 함수의 실제 실행과 관련된 부분이 존재하고 있다. 따라서 이 위치를 변경하면 후킹을 진행할 수 있다. 만약 43B168(Sleep)에 76AEB0B0를 넣어주면 어떻게 될까?

그림 10. Sleep이 호출하는 주소 변경

위 그림처럼 분명 디버거는 Sleep()이라고 나타내지만 하단의 DS에서 가리키는 곳은 KERNEL32.IsDebuggerPresent 이다. 이를 통해 디버거 또한 IAT를 기준으로 주석에 나타내주는 것임을 알 수가 있다. 그렇다면 좀 더 심화 학습을 진행해보자. 흔히 코드 케이브(Code Cave)라 할 수 있는 방법을 여기에 적용해볼 수가 있다.

코드 케이브에 대해 간단히 설명하자면 해당 프로세스의 빈 공간에 사용자가 정의한 코드를 넣어준 뒤, 이 부분으로 프로그램이 전개되도록 하는 방식이다. 예제 프로그램에서 빈 공간은 Sleep이 호출되는 윗부분에 존재하고 있다. 따라서 Call 명령어를 통해 DS:[43B168]을 참조하게 되는데, 이때 43B168은 코드 케이브의 위치인 401023이 존재하고 있다. 401023에서 Sleep API의 인자로 사용되기 위해 스택에 저장되어 있는 값을 증가시키므로 흐름을 방해한다. ADD 명령 다음에는 원래의 기능을 수행하기 위해 조작되기 이전 값인 76AE7990로 점프를 해주면 된다.

그림 11. Code Cave를 사용한 후킹

이렇게 조작을 했는데 과연 제대로 프로그램이 동작할까? 당연히 제대로 동작한다. 이전 (A)에서는 IAT에 존재하는 다른 API로 변경하는 것만 진행했지만, 이번 과정에서는 인자로 전달되는 값을 직접 수정할 수가 있다. 이는 사용자로부터 입력 받은 값을 조작하여 특정한 함수의 흐름을 조작할 수 있는 것과 같이 다른 면에도 유용하게 활용할 수 있다. (B)에 적용한 방식은 (C)의 시작 부분을 JMP Hook_Address로 이동하여 유사하게 적용할 수 있다.

(C)의 경우 실제 함수의 명령어들이 위치하고 있다. 따라서 이 부분을 후킹 하기 위해서는 명령어를 조작하여야 하는데 어떻게 조작해야 할까? (C)의 내용은 밑에 그림과 같다. 자세히 보면 상단의 세 명령어의 OPCODE는 총 5 바이트이다. 바로 이 부분을 조작하므로 우리는 원하는 함수를 후킹할 수 있다. 아래의 그림을 보자.

그림 12. (C) 단계 원래 명령어와 조작된 명령어

Sleep() 함수의 원래 주소 7673A6B0의 명령어를 JMP 명령어로 변경한 것을 확인할 수 있다. 이렇게 변경된 Sleep()함수는 호출될 때마다 해당 부분으로 이동하게 되며 공격자가 의도한 대로 흐름이 변경될 것이다. 필자가 의도한 조작은 아래 그림과 같이 Sleep() 함수의 시간 값을 증가시킨 다음, 원래대로 코드를 복원하고 복원된 지점으로 이동하는 것이다.

그림 13. 조작 코드

이렇게 코드가 아닌 어셈블리로 조작한 것은 글을 읽는 사람들의 이해를 돕고자 진행한 것이다. 실제로 이렇게 하는 사람은 거의 없으며, 특히 42000E에서 원래대로 코드를 복원하는 부분은 VirtualProtect로 권한을 변경하여 진행하는 등 어셈블리로 진행할 경우 복잡하게 이루어지기 때문에 넣지 않았다. 하지만 실제 C/C++와 같은 언어로 후킹 함수를 제작할 때는 더욱 편리할 것이다.

마지막으로 예제를 통해 진행한 각 방식의 차이에 대하여 알아보자. (A)를 후킹 할 때 해당 주소의 코드를 직접 변경하였는데, 이로 인해 해당 주소가 아닌 지점에서 Sleep()을 호출할 경우 정상적인 Sleep()이 호출된다. 반면에 (B)의 경우 IAT가 가리키는 DS에 존재하는 값을 변경하였고, 이로 인해 Sleep() 함수를 호출하는 모든 곳이 조작된 DS를 가리킨다. 따라서 (B)의 방식의 경우 해당 프로세스에서 Sleep() 함수는 후킹 된 코드 케이브를 지나가게 된다. 마찬가지로 (C) 또한 실제 Sleep() 함수의 부분을 JMP 명령어로 조작하였기 때문에 해당 프로세스의 모든 Sleep() 함수가 후킹된 것이다.

특히 (C)의 방식은 Ntdll.dll의 함수도 조작이 가능하다. 아래의 그림을 보면 실제 Ntdll.ZwDelayExecution을 호출하는 것을 확인할 수 있으며, 해당 부분의 실제 코드의 5 바이트를 JMP 명령어로 수정하여 원하는 후킹을 진행할 수가 있다.

그림 14. Ntdll.dll의 API

단, 이러한 IAT후킹의 경우, 후킹 하고자 하는 함수가 IAT에 존재해야만 후킹할 수 있기 때문에 동적으로 API를 로드(예로, GetProcAddress API 등을 통해)하는 경우 IAT를 참조하지 않아 IAT 후킹을 사용할 없다. 또한 IAT는 프로세스마다 각각 존재하기 때문에 a.exe의 IAT를 후킹하였다고 b.exe까지 후킹 된 것이 아님을 유의해야 한다.

  Message Hooking

윈도우 운영체제는 사용자에게 GUI를 제공해주고, 사용자는 제공받은 GUI를 이용하여 원하는 동작을 할 수 있다. 동작을 수행하는데 있어 마우스를 움직이거나 클릭, 또는 키보드 버튼을 누르게 되는데 이러한 동작은 윈도우 운영체제가 Event Driven 방식으로 처리한다. 다시 말해 이러한 동작을 이벤트로 발생시켜 운영체제가 그 이벤트에 맞는 메시지를 해당 응용프로그램에게 전달하여 처리하는 방식이다.

아래 그림을 보면 메시지 후킹이 어떤 지점에서 이루어지는지 나타낸 것이다. 사용자가 어떠한 행위를 했을 때 이벤트가 발생되고, 이벤트 발생으로 인해 OS에서 응용프로그램으로 보낼 메시지들이 OS Message Queue에 존재하고 있다. 예를 들어 키보드 입력 이벤트가 발생하면 WM_KEYDOWN 메시지가 OS Message Queue에 추가된다. 운영체제는 해당 이벤트가 어느 응용프로그램에서 발생했는지 파악한 다음, 큐에서 메시지를 꺼내어 해당 응용프로그램의 메시지 큐에 전달한다. 해당 응용프로그램은 자신의 Application Message Queue에 WM_KEYDOWN 메시지가 추가된 것을 확인하고 해당 이벤트 핸들러를 호출한다. 이러한 방식으로 윈도우는 메시지를 전달한다.

그림 15. 메시지 전달 방식

재미있는 사실은 윈도우 운영체제에서 이러한 메시지 훅기능을 기본적으로 제공한다는 것이다. 바로 SetWindowsHookEx API가 그 주인공으로 훅 체인에 응용프로그램이 정의한 후크 프로시저를 설치하며 이를 통해 사용자는 특정 유형의 이벤트를 모니터링 할 수 있다.

그림 16. SetWindowsHookEx API

만약 해당 API를 구현하는 HookKey.dll이 존재하며 이를 실행하기 위한 HookMain.exe를 제작하였다고 가정하자. HookMain.exe를 실행하면 HookKey.dll이 해당 프로세스에 로드되며 SetWindowsHookEx()가 호출된다. 이렇게 메시지 후킹이 걸린 상태에서, 다른 프로세스가 해당 이벤트를 발생시킨다면 HookKey.dll은 그 프로세스에서도 로딩이 된다.

그림 17. DLL Injection

위 그림과 같이 나타낼 수 있으며, 다시 말해 후킹 된 이벤트가 발생하는 모든 프로세스에 DLL 인젝션이 일어나는 것이다. 이러한 방식을 통해 메시지를 후킹할 수 있으며, 이는 DLL 인젝션의 한 방법으로 사용할 수 있다.