휴대용 실행 파일

Portable Executable
노트북 어플리케이션 또는 Windows 프리 인스톨 환경과 혼동하지 말아 주세요.
휴대용 실행 파일
파일 이름 확장자
.acm,.ax,.cpl,.dll,.drv,.efi,.exe,.mui,.ocx,.scr,.sys,.tsp
인터넷 미디어 유형
application/vnd.flash. 포터블[1]
개발자현재: Microsoft
포맷의 종류바이너리, 실행 파일, 오브젝트, 공유 라이브러리
확장원DOS MZ 실행 파일
커피

PE(Portable Executable) 형식은 32비트 및 64비트 버전의 Windows 운영 체제에서 사용되는 실행 파일, 개체 코드, DLL 및 기타 파일 형식입니다.PE 형식은 Windows OS 로더가 랩된 실행 가능 코드를 관리하는 데 필요한 정보를 캡슐화한 데이터 구조입니다.여기에는 링크, API 내보내기 및 가져오기 테이블, 리소스 관리 데이터 및 스레드 로컬 스토리지(TLS) 데이터를 위한 동적 라이브러리 참조가 포함됩니다.NT 운영 체제에서는 EXE, DLL, SYS(디바이스 드라이버), MUI 및 기타 파일 형식에 PE 형식을 사용합니다.Unified Extensible Firmware Interface(UEFI; Unified Extensible Firmware Interface) 사양에서는 EFI [2]환경에서 PE가 표준 실행 파일 형식이라고 명시되어 있습니다.

Windows NT 운영 체제에서 PE는 현재 x86-32, x86-64(AMD64/Intel 64), IA-64, ARM 및 ARM64 명령 집합 아키텍처(ISA)를 지원합니다.Windows 2000 이전에는 Windows NT(및 PE)가 MIPS, Alpha 및 PowerPC ISA를 지원했습니다.PE는 Windows CE에서 사용되기 때문에 MIPS, ARM(썸 포함) 및 SuperH ISA의 여러 [3]변형을 계속 지원합니다.

PE와 유사한 형식은 ELF(Linux 및 대부분의 Unix 버전에서 사용)와 Mach-O(macOS 및 iOS에서 사용)입니다.

역사

Microsoft는 Windows NT 3.1 운영 체제의 도입과 함께 16비트 NE 형식에서 PE 형식으로 이행했습니다.Windows 95/98/ME 및 Windows 3.1x에 추가된 Windows 32s를 포함한 이후의 Windows 버전은 모두 파일 구조를 지원합니다.이 포맷은 DOS 기반 시스템과 NT 시스템 간의 갭을 메우기 위해 제한된 레거시 지원을 유지하고 있습니다.예를 들어, PE/COFF 헤더에는 DOS 실행 가능 프로그램이 포함되어 있습니다.이것은 디폴트로 「이 프로그램은 DOS 모드로 실행할 수 없습니다」(또는 이와 유사합니다)라고 하는 메시지를 표시하는 DOS 스터브입니다.다만, 프로그램의 완전한 DOS 버전(나중에 주목되는 것은 Windows 98 SE [4]인스톨러입니다).이것은 지방 2진법의 한 형태를 구성합니다.PE는, 변화하는 Windows 플랫폼에도 계속 대응합니다.일부 확장 기능에는 가 포함됩니다.NET PE 형식(아래 참조), PE32+[5]라고 하는64비트 주소 공간을 지원하는 버전 및 Windows CE 사양.

기술적 세부사항

레이아웃

휴대용 실행 파일 32비트 구조

PE 파일은 다이나믹링커에 파일을 메모리에 매핑하는 방법을 지시하는 다수의 헤더와 섹션으로 구성됩니다.실행 가능한 이미지는 각각 다른 메모리 보호를 필요로 하는 여러 영역으로 구성됩니다.따라서 각 섹션의 시작은 [6]페이지 경계에 맞춰야 합니다.예를 들어 일반적으로 .text 섹션(프로그램 코드를 보유)은 execute/readonly로 매핑되고 .data 섹션(글로벌 변수를 보유)은 no-execute/readwrite로 매핑됩니다.그러나 공간 낭비를 방지하기 위해 다른 섹션은 디스크에 페이지 정렬이 되어 있지 않습니다.다이내믹 링커 작업의 일부는 [7]각 섹션을 메모리에 개별적으로 매핑하고 헤더에 기재되어 있는 지시에 따라 결과 영역에 올바른 권한을 할당하는 것입니다.

Import 테이블

주의사항 중 하나는 Import Address Table(IAT; Import 주소 테이블)입니다.IAT는 응용 프로그램이 다른 모듈의 함수를 호출할 때 룩업테이블로 사용됩니다.서수에 의한 Import와 이름에 의한 Import의 양쪽 모두의 형식이 될 수 있습니다.컴파일된 프로그램은 의존하는 라이브러리의 메모리 위치를 알 수 없기 때문에 API 호출이 이루어질 때마다 간접적인 점프가 필요합니다.다이내믹 링커는 모듈을 로드하고 모듈을 결합할 때 IAT 슬롯에 실제 주소를 기입하여 대응하는 라이브러리 함수의 메모리 위치를 가리킵니다.이로 인해 모듈 내 콜비용이 대폭 상승하여 퍼포먼스 저하가 발생하지만 다음과 같은 중요한 이점이 있습니다.로더에 의해 Copy-on-Write로 변경해야 하는 메모리 페이지 수가 최소화되어 메모리와 디스크 I/O 시간이 절약됩니다.컴파일러가 콜이 모듈간(dllimport Atribute 경유)인 것을 미리 알고 있으면 간접 콜 opcode가 [7]되는 보다 최적화된 코드를 생성할 수 있습니다.

재배치

PE 파일에는 일반적으로 위치에 의존하지 않는 코드가 포함되어 있지 않습니다.대신 우선 기본 주소로 컴파일되어 컴파일러/링커에 의해 출력되는 모든 주소는 미리 고정됩니다.PE 파일을 원하는 주소로 로드할 수 없는 경우(이미 다른 사용자가 파일을 가져갔기 때문에), 운영 체제는 기본 파일을 다시 로드합니다.여기에는 모든 절대 주소를 다시 계산하고 새 값을 사용하도록 코드를 수정하는 작업이 포함됩니다.로더는 우선 로드 주소와 실제 로드 주소를 비교하여 델타 값을 계산하여 이를 수행합니다.이 주소는 메모리 위치의 새 주소를 표시하기 위해 우선 주소에 추가됩니다.베이스 재배치는 목록에 저장되며 필요에 따라 기존 메모리 위치에 추가됩니다.그 결과 생성된 코드는 이제 프로세스에 비공개되어 더 이상 공유할 수 없게 되었습니다.따라서 이 시나리오에서는 DLL의 메모리 절약 이점이 많이 상실됩니다.또한 모듈의 로딩 속도도 크게 느려집니다.이 때문에, 가능한 한 리베이스링은 회피해 주세요.또, Microsoft 가 출하하는 DLL 에는, 오버랩 되지 않게 사전에 계산된 베이스 주소가 있습니다.따라서 rebase가 없는 경우 PE는 매우 효율적인 코드의 이점을 가지고 있지만 rebase가 존재하는 경우 메모리 사용률에 대한 타격은 비쌀 수 있습니다.이는 완전히 위치에 의존하지 않는 코드를 사용하는 ELF와 메모리 사용량을 줄이기 위해 실행 시간을 교환하는 글로벌 오프셋 테이블과 대조됩니다.

.NET, 메타데이터 및 PE 형식

.NET 실행 파일의 PE 코드 섹션에는 CLR 가상 머신의 시작 엔트리를 호출하는 stub가 포함되어 있습니다._CorExeMain또는_CorDllMain에mscoree.dllVisual Basic 실행 파일과 비슷합니다.그러면 가상 시스템이 를 사용합니다.NET 메타데이터가 존재하며, 그 루트는IMAGE_COR20_HEADER('CLR 헤더'라고도 함)는 다음과 같이 지정됩니다.IMAGE_DIRECTORY_ENTRY_COMHEADER[8] PE 헤더의 데이터 디렉토리에 엔트리를 입력합니다. IMAGE_COR20_HEADER는 PE의 옵션 헤더와 매우 유사하며 기본적으로 CLR [3]로더에 대한 역할을 수행합니다.

루트 구조 자체를 포함한 CLR 관련 데이터는 일반적으로 공통 코드 섹션에 포함되어 있습니다..text. 메타데이터, 임베디드 리소스, 강력한 이름 및 네이티브 코드 상호 운용성을 위한 몇 개의 디렉토리로 구성되어 있습니다.메타데이터 디렉토리는 모든 고유 항목을 나열하는 테이블 세트입니다.어셈블리의 NET 엔티티(유형, 메서드, 필드, 상수, 이벤트 및 이들 및 다른 어셈블리 간의 참조 포함).

다른 운영 체제에서 사용

PE 포맷은 React OS에서도 사용됩니다.OS는 Windows와의 바이너리 호환성을 목적으로 하고 있습니다.SkyOS와 BeOS R3를 포함한 많은 다른 운영 체제에서도 사용되고 있습니다.하지만 결국 스카이OS와 BeOS 모두 [citation needed]ELF로 넘어갔다.

Mono 개발 플랫폼은 Microsoft 와 바이너리 호환성을 의도하고 있습니다.NET Framework는 Microsoft 구현과 동일한 PE 형식을 사용합니다.마이크로소프트사의 크로스 플랫폼도 마찬가지입니다.NET 코어

x86(-64) Unix 계열 운영체제에서는 Windows 바이너리(PE 형식)를 Wine으로 실행할 수 있습니다.또한 HX DOS Extender는 네이티브 DOS 32비트 바이너리에 PE 포맷을 사용합니다.또, 어느 정도 DOS 로 기존의 Windows 바이너리를 실행할 수 있기 때문에, DOS 용 와인과 동등하게 동작합니다.

IA-32 및 x86-64 Linux에서는 loadlibrary에서 [9]Windows의 DLL을 실행할 수도 있습니다.

Mac OS X 10.5에는 PE 파일을 로드 및 해석하는 기능이 있지만 Windows와 [10]바이너리 호환성은 없습니다.

UEFI 및 EFI 펌웨어는 응용 프로그램의 Windows ABI x64 호출 규칙뿐만 아니라 휴대용 실행 파일도 사용합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Andersson, Henrik (2015-04-23). "application/vnd.microsoft.portable-executable". IANA. Retrieved 2017-03-26.
  2. ^ 페이지 15의 주에서는 "EFI 인터페이스 자체를 ARM 모드로 정의하면서 UEFI 이미지에 Thumb 및 Thumb2 명령을 포함할 수 있도록 하기 위해 이 이미지 유형이 선택되었습니다."라고 기술되어 있습니다"UEFI Specification, version 2.8B" (PDF)..
  3. ^ a b "PE Format (Windows)". Retrieved 2017-10-21.
  4. ^ 예: Microsoft 링커에 /STUB 스위치가 있습니다.
  5. ^ 실행 가능한 코드가 32비트인지 64비트인지 확인하려면 IMAGE_FILE_HEADER의 Machine 필드를 확인합니다.(PE 트릭 설명: 카르스텐 한이 맨눈으로 32와 64비트를 구분하는 것)
    실행 파일의 주소가 32비트인지 64비트인지를 확인하려면 IMAGE_OPTION_HEADER의 Magic 필드를 확인합니다.10B는16 PE32 파일을 나타내고 20B는16 PE32+ 파일을 나타냅니다.( Microsoft.com )
  6. ^ "The Portable Executable File From Top to Bottom". Retrieved 2017-10-21.
  7. ^ a b "Peering Inside the PE: A Tour of the Win32 Portable Executable File". Retrieved 2017-10-21.
  8. ^ 이 엔트리는 이전에 COM+ 어플리케이션의 COM+ 메타데이터에 사용되었기 때문에 이름은 다음과 같습니다.
  9. ^ "GitHub - taviso/Loadlibrary: Porting Windows Dynamic Link Libraries to Linux". GitHub.
  10. ^ Chartier, David (2007-11-30). "Uncovered: Evidence that Mac OS X could run Windows apps soon". Ars Technica. Retrieved 2007-12-03. ... 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.

외부 링크