PROFILPELAJAR.COM

Portable Executable
파일 확장자	.acm, .ax, .cpl, .dll, .drv, .efi, .exe, .mui, .ocx, .scr, .sys, .tsp
인터넷 미디어 타입	application/vnd.microsoft.portable-executable
개발	현재 마이크로소프트
포맷 종류	이진, 실행 파일, 오브젝트, 공유 라이브러리
다음으로부터 확장	DOS MZ 실행 파일; COFF

PE 포맷(Portable Executable)은 윈도우 운영 체제에서 사용되는 실행 파일, DLL, object 코드, FON 폰트 파일^[2] 등을 위한 파일 형식이다. PE 포맷은 윈도우 로더가 실행 가능한 코드를 관리하는데 필요한 정보를 캡슐화한 데이터 구조체이다. 이것은 링킹을 위한 동적 라이브러리 참조, API 익스포트와 임포트 테이블, 자원 관리 데이터 그리고 TLS 데이터를 포함한다. 윈도우 NT 운영체제에서, PE 포맷은 EXE, DLL, SYS (디바이스 드라이버), 그리고 다른 파일 종류들에서 쓰인다. 통일 확장 펌웨어 인터페이스 (EFI) 설명서는 PE가 EFI 환경에서 표준 실행 파일 형식이라고 언급한다.^[3]

윈도우 NT 운영 체제에서, PE는 현재 IA-32, IA-64, x86-64 (AMD64/Intel64), 그리고 ARM instruction set architectures (ISAs)를 지원한다. 윈도우 2000 이전에서, 윈도우 NT는 (그리고 PE) MIPS, Alpha, 그리고 파워PC ISAs를 지원했다. PE가 윈도우 CE에서 사용되므로 이것은 MIPS, ARM (Thumb 포함), 그리고 SuperH ISA의 변형들을 지원하고 있다.

PE와 비슷한 형식으로 ELF (리눅스와 대부분의 다른 유닉스 버전들) 와 Mach-O (Mac OS X)가 있다.

역사

마이크로소프트는 윈도우 NT 3.1 운영 체제의 도입과 함께 PE 포맷으로 옮긴다. 윈도우의 이후 버전들도 이 형식을 지원한다. 이 형식은 도스와 NT 시스템 사이의 차이를 연결하기 위한 한정된 유산을 가지고 있다. 예를 들면, PE/COFF 헤더들은 아직도 MS-DOS 실행 파일을 포함한다. 기본적으로 이것은 "This program cannot be run in DOS mode" 메시지를 보여주는 스텁이다.^[4] PE는 또한 윈도우 플랫폼의 변화를 계속해서 지원한다. 이것들은 .NET PE 포맷, PE32+로 불리는 64비트 버전 (가끔은 PE+), 그리고 윈도우 CE를 위한 명세서가 있다.

기술적 세부사항

레이아웃

PE 파일은 동적 링커에게 파일을 메모리로 어떻게 매핑할지 설명하는 많은 헤더들과 섹션들로 이루어져 있다. 실행 가능한 이미지는 (각각 다른 메모리 보호를 요구하는) 여러 다른 영역으로 이루어져 있다. 그래서 각 섹션의 시작은 반드시 페이지 경계에 맞춰 정렬되어야 한다. 예를 들면, 전형적인 .text 섹션(프로그램 코드를 가지는)의 경우 execute/readwrite으로 매핑되어야 하고 .data 섹션(전역 변수들을 가지는)의 경우 no-execute/readwrite로 매핑되어야 한다. 그러나 공간 낭비를 피하기 위해서, 다른 섹션들은 디스크에서 페이지 정렬되어 있지 않다. 동적 링커의 일 중 하나는 각 섹션을 개별적으로 메모리에 매핑하고, 헤더에 있는 지시에 따라 그곳에 정확한 권한을 할당하는 것이다.

임포트 테이블

import address table (IAT) 섹션은 응용 프로그램이 다른 모듈에서 함수를 호출할 때 검색 테이블로 사용된다. 이것은 서수에 의한 들여오기나 이름에 의한 들여오기가 될 수 있다. 컴파일 된 프로그램은 의존하는 라이브러리의 메모리 위치를 모르기 때문에 API 호출 시 간접적인 점프가 요구된다. 동적 링커가 모듈을 로드하고 연결시키고, 실제 주소를 IAT에 넣는다. 그 후 상응하는 라이브러리 함수의 메모리 위치를 가리키게 된다. 비록 이 추가로 인해 모듈 내부의 호출에도 추가적인 점프가 요구되지만 이것은 중요한 이점을 가진다. 로더에 의해 변경되며 copy-on-write가 요구되는 메모리 페이지들의 수가 최소화돼서 메모리와 디스크의 입출력 시간을 절약할 수 있다. 만약 컴파일러가 호출이 모듈 내부에서 일어나는 것이라고 미리 안다면 더 최적화된 코드를 생산할 수도 있다.

재배치

PE 파일들은 위치 독립적 코드를 포함하지 않는다. 대신에 선호되는 우선되는 베이스 주소로 컴파일되고, 모든 주소들은 그 전에 고정된다. 만약 PE 파일이 우선되는 주소에 로드될 수 없다면(다른게 이미 위치하고 있는 경우) 운영 체제는 베이스 주소를 바꾼다. 이것은 모든 절대 주소를 다시 계산하고 새로운 값을 사용하도록 코드를 바꾸는 것을 포함한다. 로더는 이것을 우선되는 주소와 실제 로드될 주소를 비교하고 델타 값을 계산함으로써 수행한다. 그 후 우선되는 주소에 새로운 주소의 위치에 대한 값이 더해진다. 베이스 재배치들은 메모리 위치에 목록화되고 저장된다. 결과 코드는 이제 프로세스에 사적이 되고 공유될 수 없게 됨으로써 DLL의 수많은 메모리 절약 이점이 사라진다. 또한 모듈을 로딩하는 시간도 매우 느려지게 된다. 이 이유로 이러한 재배치는 가능한 한 피해지며, 마이크로소프트에서 나온 DLL들은 겹쳐질 수 없게 만들어져 있다.

다른 운영 체제에서의 사용

x86의 유닉스 계열 운영체제들에서 몇몇 윈도우 바이너리들은 와인으로 돌아갈 수 있다. 맥 OS X 10.5는 PE 파일들을 로드하고 분석할 수 있는 기능을 갖지만 윈도우와 호환은 되지 않는다.^[5]

같이 보기

각주

↑ Andersson, Henrik (2015년 4월 23일). “application/vnd.microsoft.portable-executable”. IANA. 2017년 3월 26일에 확인함.
↑ “UEFI Specification, version 2.4” (PDF). ^{[깨진 링크(과거 내용 찾기)]}, a note on p.18, states that "this image type is chosen to enable UEFI images to contain Thumb and Thumb2 instructions while defining the EFI interfaces themselves to be in ARM mode."
↑ “UEFI Specification, version 2.4” (PDF). ^{[깨진 링크(과거 내용 찾기)]}, a note on p.18, states that "this image type is chosen to enable UEFI images to contain Thumb and Thumb2 instructions while defining the EFI interfaces themselves to be in ARM mode."
↑ E.g. Microsoft's linker has /STUB switch to attach one
↑ Chartier, David (2007년 11월 30일). “Uncovered: Evidence that Mac OS X could run Windows apps soon”. 《Ars Technica》. 2016년 2월 11일에 확인함. ... Steven Edwards describes the discovery that Leopard apparently contains an undocumented loader for Portable Executables, a type of file used in 32-bit and 64-bit versions of Windows. More poking around revealed that Leopard's own loader tries to find Windows DLL files when attempting to load a Windows binary.