p1) IAT 테이블 2

now, let's start this over but look in it more in detail. 일단 시작하고 더 자세히 들여다 보자.
 First of all : when an executable is first loaded, 우선 실행가능한 (파일)이 처음으로 로드 될 때
the Windows loader is responsible for reading in the files PE structure 윈도우 로더는 PE파일 구조를 읽고 and loading the executable image into memory. 실행가능한 이미지를 메모리로 로드해야 한다. One of the other steps it takes is to load all of the dlls 그리고 다음으로 다른 모든 dll들을 로드하는데 that the application uses 어플리케이션에서 쓰는 것들이다.
and map them into the process address space. 프로세스 주소 공간에 있는 맵 또한 로드한다.
The executable also 실행가능한 것(파일)은 또한
lists all of the functions 모든 함수들을 보여준다.
it will require from each dll. 그것들은 다른 dll에서 요구될 것이다.
Because the function addresses are not static, 왜냐면 함수 주소는 고정된게 아니기 때문이다.
a mechanism was developed that 메카니즘은 다음과 같이 개발되어졌다.
allows for these variables to be changed without needing to alter all of the compiled code at runtime. 실행시간에 컴파일된 코드들이 고쳐지지 않고 이 변수들이 바뀌는게 가능하도록
This was accomplished through the use of an import address table (IAT). 이것은 IAT를 통해서 완성되었다. This is a table of function pointers filled in by the windows loader  이것은 윈도우 로더에 의해 채워진 펑션 포인터들의 테이블이다.
as the dlls are loaded.  dll이 로드될 때 When the application was first compiled, 어플이 처음 컴파일 될 때 it was designed 그것은 디자인 된다.
so that none of the API calls use direct hardcoded addresses 그래서 어떤 코드도 주소가 바로 고정되어 사용되지 않는다.
but rather work through a function pointer. 그래서 함수 포인터를 이용한다.Conventially this pointer table can be accessed in several ways. 몇가지 방법으로 이 포인터 테이블은 액세스 될 수 있다.
Either directly by a call[pointer address] or via a jmp thunk table. By using the pointer table, the loader does not 직접 호출이나 점프 테이블을 통해서. 포인터 테이블을 이용할 때 윈도우즈 로더는 need to fixup all of the places in the code that want to use the api call, all it has to do is add the pointer to a 코드 위치를 모두 고쳐 API호출을 할 필요가 있다.  single place in a table and its work is done. 모든 추가된 포인트는 테이블의 한곳을 나타내고 제대로 동작한다.