영어로 읽기

다음을 통해 공유


PE 메타데이터

이 문서에서는 PE 이미지의 CFG(Control Flow Guard) 메타데이터에 대한 추가 세부 정보를 제공합니다. PE 이미지의 CFG 메타데이터 구조에 대해 잘 알고 있다고 가정합니다. PE 이미지의 CFG 메타데이터에 대한 개략적인 설명서는 PE 형식 항목을 참조하세요.

  • 유효한 간접 호출 대상인 함수는 부하 구성 디렉터리에 연결된 GuardCFFunctionTable에 나열되며 간결함을 위해 GFIDS 테이블이라고도 합니다. 유효한 CFG 호출 대상에 대한 정보를 포함하는 RVA(상대 가상 주소)의 정렬된 목록입니다. 일반적으로 이러한 주소는 함수 기호를 사용하는 주소입니다. CFG 적용을 원하는 이미지는 GFIDS 테이블에서 가져온 모든 주소 함수 기호를 열거해야 합니다. GFIDS 테이블의 RVA 목록을 올바르게 정렬해야 합니다. 그렇지 않으면 이미지가 로드되지 않습니다. GFIDS 테이블은 4 + n 바이트의 배열이며 n은 ((GuardFlags 및 IMAGE_GUARD_CF_FUNCTION_TABLE_SIZE_MASK) IMAGE_GUARD_CF_FUNCTION_TABLE_SIZE_SHIFT) >> 에 의해 제공됩니다. "GuardFlags"는 부하 구성 디렉터리의 GuardFlags 필드입니다. 이를 통해 향후 CFG 호출 대상에 추가 메타데이터를 연결할 수 있습니다. 현재 정의된 유일한 메타데이터는 호출 대상에 메타데이터가 있는 경우 각 GFIDS 항목에 연결된 선택적 1바이트 추가 플래그 필드("GFIDS 플래그")입니다. 두 가지 GFIDS 플래그가 정의되어 있습니다.

       
    IMAGE_GUARD_FLAG_FID_SUPPRESSED/0x1 호출 대상이 명시적으로 표시되지 않음(CFG를 위해 유효한 것으로 취급하지 않음)
    IMAGE_GUARD_FLAG_EXPORT_SUPPRESSED/0x2 호출 대상은 내보내기가 표시되지 않습니다. 자세한 내용은 내보내기 표시 안 함 참조

    향후 호환성을 위해 도구는 아직 정의되지 않은 GFIDS 플래그를 설정해서는 안 되며, 다른 플래그 또는 추가 메타데이터에 대한 의미가 아직 할당되지 않았기 때문에 현재 정의된 1바이트 이상의 추가 GFIDS 추가 메타데이터 바이트를 포함해서는 안 됩니다. 최신 Windows 10 OS 버전에서 Ntdll.dll과 같은 이진 파일의 GFIDS 테이블을 덤프하여 추가 메타데이터 바이트를 포함하는 이미지의 예를 찾을 수 있습니다.

    도구는 레이블을 처리할 수 있는 어셈블러 코드에 대한 추가 고려 사항이 있을 수 있는 유효한 호출 대상으로 함수 기호만 선언해야 합니다. 기록상의 이유로 어셈블러 코드는 PROC 또는 .altentry 이외의 코드 레이블을 링커에 의해 CFG 호출 대상으로 변환되지 않을 수 있습니다.

    또한 기록상의 이유로 코드는 GFIDS 테이블에 포함되는 것을 방지하기 위해 의도적으로 코드를 데이터로 선언할 수 있습니다. 예를 들어 한 개체 파일은 기호를 코드로 구현할 수 있으며 다른 개체 파일은 유효한 CFG 대상 레코드를 생성하지 않고 기호의 주소를 가져오기 위해 기호를 데이터로 선언할 수 있습니다. 호환성을 위해 도구 집합에서 이 방법을 지원하는 것이 좋습니다.

  • CFG를 지원하고 CFG 검사 수행하려는 이미지는 IMAGE_GUARD_CF_INSTRUMENTED 및 IMAGE_GUARD_CF_FUNCTION_TABLE_PRESENT GuardFlags 비트를 설정해야 하며 이미지 헤더에서 IMAGE_DLLCHARACTERISTICS_GUARD_CF DllCharacteristics 비트를 설정해야 합니다.

  • 부하 구성 디렉터리가 두 개의 함수 포인터를 보급합니다. GuardCFCheckFunctionPointer 및 GuardCFDispatchFunctionPointer(후자는 AMD64와 같은 특정 아키텍처에 대해서만 지원됨). 이러한 함수 포인터는 CFG 보안이 유효하려면 메모리만 읽도록 가리킵니다. 운영 체제의 DLL 로더는 이미지를 로드하는 동안 일시적으로 메모리를 다시 보호하여 함수 포인터를 저장합니다. 일반적인 사용법은 IAT(가져오기 주소 테이블)가 포함된 동일한 섹션에 병합하는 것입니다. GuardCFCheckFunctionPointer는 첫 번째 정수 인수 레지스터(x86의 ECX)에서 함수 포인터를 사용하여 호출할 수 있는 OS 로더 제공 기호의 주소를 제공합니다. 이 기호는 성공 시 반환되거나 호출 대상이 유효한 CFG 대상이 아닌 경우 프로세스를 중단합니다. GuardCFDispatchFunctionPointer는 RAX 등록에서 호출 대상을 사용하고 호출 대상에 대한 CFG 검사 및 비상 분기 최적화 호출을 수행하는 OS 로더 제공 기호의 주소를 제공합니다(레지스터 R10/R11은 GuardCFDispatchFunctionPointer에서 사용하도록 예약되고 정수 인수 레지스터는 최종 호출 대상에서 사용하도록 예약됨). 이미지에 있는 CFG 기호의 기본 주소는 "jmp rax" 명령을 실행하는 가드가 표시되지 않는 기호(또는 GFIDS 테이블 기호에서 완전히 생략됨)를 반환하는 함수(GuardCFCheckFunctionPointer)를 가리킵니다. AMD64 GuardCFDispatchFunctionPointer의 경우 이미지를 CFG 인식 운영 체제에 로드하고 CFG를 사용하도록 설정하면 OS DLL 로더가 적절한 함수 포인터를 설치합니다. 이 포인터는 이전 버전과의 호환성을 유지합니다. CFG 디스패치 기능을 사용하지 않으려는 경우 이미지는 부하 구성에서 GuardCFDispatchFunctionPointer에 대해 0을 제공할 수 있습니다. 이러한 아키텍처가 결국 어떤 형태로든 CFG 디스패치 메커니즘을 지원하는 경우 향후 호환성을 위해 AMD64가 아닌 아키텍처에 대해 이 작업을 수행해야 합니다. Windows 8.1 AMD64는 CFG 디스패치를 지원하지 않으며 GuardCFDispatchFunctionPointer에 대한 기본 함수 포인터를 그대로 둡니다. CFG 디스패치는 Windows 10 이상 운영 체제에서만 지원됩니다.

  • 사용자 모드 CFG는 ASLR(주소 공간 레이아웃 임의화)으로 표시된 이미지에만 적용할 수 있습니다(Microsoft 링커와 함께 /DYNAMICBASE 옵션으로 지정됨). 이는 OS가 기본적으로 ASLR 인프라에 연결된 CFG를 내부적으로 처리하는 방식 때문입니다. 일반적으로 CFG 사용자는 첫 번째 단계로 이미지에 대해 ASLR을 사용하도록 설정해야 합니다. 도구는 OS가 항상 ASLR을 설정하지 않고 CFG를 무시하지만 일반적으로 둘 다 동시에 설정해야 한다고 가정해서는 안 됩니다.

컴파일러 지시문

  • 호출 대상은 __declspec(guard(suppress)) 한정자 또는 /guardym:symname,S 링커 지시문(예: asm 코드)을 사용하여 명시적으로 표시되지 않는 것으로 표시될 수 있습니다. 이렇게 하면 호출 대상이 GFIDS 테이블에 포함되지만 OS가 호출 대상을 유효하지 않은 것으로 처리하는 방식으로 표시됩니다. 일부 이전 운영 체제에서 사용하도록 설정된 특정 애플리케이션 검증 도구 계측과 같은 일부 비프로덕션 시나리오에서는 억제된 호출 대상을 유효한 것으로 처리할 수 있지만 일반적으로 이러한 시나리오는 프로덕션 시나리오가 아닐 것으로 예상됩니다. 이 지시문은 일반 CFG 규칙에 포함되더라도 유효한 호출 대상으로 간주해서는 안 되는 "위험한" 함수에 주석을 적용하는 데 유용합니다.

  • 코드는 __declspec(guard(nocf)) 한정자를 사용하여 CFG 검사 원하지 않음을 나타낼 수 있습니다. 이렇게 하면 컴파일러가 전체 함수에 대한 CFG 검사 삽입하지 않도록 지시합니다. 컴파일러는 이 지시문을 CFG 검사 원하지 않는 것으로 표시된 인라인 함수에 의해 기여된 코드로 전파하는 데 주의해야 합니다. 이 방법은 일반적으로 프로그래머가 "CFG와 동등한" 보호를 수동으로 삽입한 특정 상황에서만 드물게 사용됩니다. 프로그래머가 읽기 전용 메모리 참조를 통해 주소를 가져오고 인덱스가 함수 테이블 제한으로 마스킹되는 일부 읽기 전용 함수 테이블을 통해 호출한다는 것을 알고 있습니다. 이 방법은 인라인되지 않고 함수 포인터를 통해 호출하는 것 이상의 작업을 수행하는 작은 래퍼 함수에도 적용될 수 있습니다. 이 지시문을 잘못 사용하면 CFG의 보안이 손상될 수 있으므로 프로그래머가 지시문을 사용하는 데 매우 주의해야 합니다. 일반적으로 이 사용은 하나의 함수만 호출하는 매우 작은 함수로 제한됩니다.

가져오기 처리

  • IAT를 통한 호출은 CFG 보호를 사용하면 안 됩니다. IAT는 최신 이미지에서만 읽습니다(IAT가 자체 페이지에 있어야 하는 경우 PE 헤더에 선언된 것으로 가정). IAT를 사용하여 보호 기능이 표시되지 않는 함수에 도달할 수 있으므로 이는 정확성 요구 사항입니다. IAT를 통한 읽기 전용 메모리 보호는 이미지 가져오기 스냅이 확인된 후 호출 대상 바인딩을 변경할 수 없으며 바인딩 해상도가 세분화되므로 CFG의 메모리 보호만 대체합니다.

  • 보호된 지연 로드: 지연 부하 IAT를 통한 호출은 표준 IAT와 동일한 이유로 CFG 보호를 사용하면 안 됩니다. 지연 로드 IAT는 자체 섹션에 있어야 하며 이미지는 IMAGE_GUARD_CF_PROTECT_DELAYLOAD_IAT GuardFlags 비트를 설정해야 합니다. 이는 Windows 8 이상 운영 체제에 네이티브 운영 체제의 지연 부하 지원을 사용하는 경우 내보내기 확인 중에 운영 체제의 DLL 로더가 지연 로드 IAT에 대한 보호를 변경해야 했음을 나타냅니다. 이 단계의 동기화는 네이티브 운영 체제 지연 부하 지원이 사용 중인 경우(예: ResolveDelayLoadedAPI) 운영 체제 DLL 로더에서 관리되므로 다른 구성 요소는 선언된 지연 로드 IAT에 걸쳐 있는 페이지를 다시 보호해서는 안 됩니다. 이전의 사전 CFG 운영 체제와의 호환성을 위해 도구는 지연 로드 IAT를 이미지 헤더에서 읽기/쓰기로 보호되는 자체 섹션(canonically ".didat")으로 이동하고 IMAGE_GUARD_CF_DELAYLOAD_IAT_IN_ITS_OWN_SECTION 플래그를 설정하는 옵션을 사용하도록 설정할 수 있습니다. 이 설정으로 인해 CFG 인식 운영 체제 DLL 로더가 이미지 로드 중에 메모리만 읽도록 IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT 테이블이 포함된 전체 섹션을 다시 보호합니다. CFG 지원을 앞둔 운영 체제에서 이미지를 실행하는 데 신경 쓰지 않는 경우 자체 섹션에 지연 로드 IAT를 배치하는 옵션이 필요하지 않을 수 있지만 도구는 이미지에 필요한 최소 운영 체제 지원을 기반으로 해당 결정을 내려야 합니다.

    이미지가 운영 체제의 기본 지연 부하 지원을 사용하지 않는 경우에도 보호된 지연 부하 관련 GuardFlags 비트를 설정할 수 있습니다. 이 구성에서 운영 체제 로더는 플랫폼에서 지원하는 경우 런타임에만 읽기로 지연 부하 IAT를 보호하기 위한 지원을 제공하고, 지연 부하 IAT의 보호를 동기화하고 관리하는 이미지의 내부 지연 부하 확인 스텁의 책임이 됩니다. 부하 구성 테이블이 읽기 전용 메모리(권장)에 저장되는 경우 이미지의 GuardFlags 필드에 보호된 지연 로드 IAT 비트의 존재 또는 부재는 이미지의 내부 지연 부하 확인 스텁에 대한 내부 힌트로 지연 부하 IAT를 보호해야 하는지 여부를 나타내는 데 유용할 수 있습니다.

    CFG를 사용하는 경우 보호된 지연 로드를 기본적으로 사용하도록 설정하는 것이 좋습니다. 이전 운영 체제 버전에서 실행되고 운영 체제의 기본 지연 부하 지원을 사용하는 이미지는 이전 버전과의 호환성을 위해 자체 섹션 지원에서 지연 부하 IAT를 사용할 수 있습니다. 이는 지연 로드 IAT를 읽기 전용으로 표시하고 다른 섹션과 병합하는 것과 반대됩니다. 이 섹션은 보호된 지연 부하를 이해하지 못하고 네이티브 지연 부하 확인 지원을 제공하는 이전 운영 체제에서 중단됩니다. 모든 Windows 10 릴리스 및 CFG를 지원하는 첫 번째 Windows 8.1/Windows Server 2012 R2 빌드(즉, 2014년 11월 업데이트)는 운영 체제에서 보호된 지연 부하에 대한 지원을 도입합니다.

함수 맞춤

  • 주소가 지정되어 GFIDS 테이블에 포함된 함수는 가능하면 16바이트 정렬되어야 합니다. 이것이 항상 가능하지는 않을 수도 있습니다. 예를 들어 일부 어셈블러가 생성할 수 있는 비 CFG 인식 도구에 의해 하나의 단위로 함께 어셈블된 개체 파일의 일부인 비 COMDAT 함수의 경우 파일을 생성한 도구의 사용자는 맞춤을 적절하게 설정해야 합니다. 도구는 사용자가 적절한 수정 작업을 수행할 수 있도록 이 상황에서 진단 경고를 실행하도록 선택할 수 있습니다. 그 이유는 CFG가 빠른 CFG 검사 효율성을 위해 16바이트 경계에서 호출 대상을 유효하거나 유효하지 않은 것으로 표시하기 때문입니다. 함수가 16 바이트 정렬되지 않은 경우 전체 16 바이트 슬롯이 유효한 것으로 표시되어야하며, 함수의 시작 부분에 있지 않은 코드로 잘못 정렬된 호출을 호출할 수 있으므로 안전하지 않습니다. 이 시나리오는 프로젝트에 CFG를 처음 도입할 때 상호 운용성을 용이하게 지원합니다. 비 CFG 인식 이미지는 마찬가지로 호환성을 위해 호출 대상 맞춤에 유효한 것으로 표시됩니다. 이전과 같이 잘못된 호출 대상이 있으면 CFG의 보안 이점이 감소하므로 CFG가 이미지에 필요한 경우 도구가 GFIDS 테이블의 모든 항목에 대해 16바이트 경계에 자동으로 맞춰야 합니다. GFIDS 테이블에 없는 기호에는 CFG에 대한 특정 맞춤이 필요하지 않습니다.

내보내기 표시 안 함

  • CFG ES(CFG 내보내기 억제)는 프로세스에서 dllexport 기호이고 GetProcAddress에서 아직 동적으로 확인되지 않았기 때문에 유효한 호출 대상이 CFG 용도로 유효하지 않은 것으로 간주됨을 나타내는 선택적 모드입니다. 이렇게 하면 시스템 DLL 내보내기에서 CFG의 노출 영역이 줄어듭니다. 내보내기 억제에는 적격 "내보내기 억제됨" dllexport 호출 대상을 IMAGE_GUARD_FLAG_EXPORT_SUPPRESSED GFIDS 플래그로 표시하여 전달하는 작업이 포함됩니다 . Dllexport 기호 및 PE 이미지 진입점은 GFIDS 테이블을 생성하기 위해 도구에서 사용하는 주소로 암시적으로 고려해야 합니다. 내보내기 기호가 16바이트 정렬되어 있고 dllexport가 아닌 다른 이유 없이 주소가 지정된 경우 함수 테이블에서 내보내기 표시 안 함 GFIDS 플래그로 표시할 수 있습니다. 16바이트 정렬되지 않은 호출 대상은 IMAGE_GUARD_FLAG_EXPORT_SUPPRESSED GFIDS 플래그로 표시해서는 안 되며 GetProcAddress 시간에 유효한 호출 대상으로만 동적으로 사용하도록 제한할 수 없습니다.

    CFG ES를 지원하는 이미지에는 부하 구성 디렉터리의 일부로 GuardAddressTakenIatEntryCount에서 개수를 제공하는 GuardAddressTakenIatEntryTable이 포함됩니다. 이 테이블은 구조적으로 GFIDS 테이블과 동일한 형식으로 지정됩니다 . 동일한 GuardFlags IMAGE_GUARD_CF_FUNCTION_TABLE_SIZE_MASK 메커니즘을 사용하여 IAT 테이블을 가져온 주소에서 추가 선택적 메타데이터 바이트를 인코딩하지만 모든 메타데이터 바이트는 IAT 테이블을 가져온 주소에 대해 0이어야 하며 예약되어 있습니다. IAT 테이블에서 가져온 주소는 호출 대상을 가져온 기호 주소로 가져온 가져오기 펑크의 정렬된 RVA 배열을 나타냅니다. 이 구문은 CFG ES를 사용하여 원격 모듈에 존재하고 dllexports인 주소를 가져온 기호를 지원합니다. 이러한 코드 구문의 예는 다음과 같습니다.

    mov rcx, [__imp_DefWindowProc]
    call foo ; where foo takes the actual address of DefWindowProc.
    

    이러한 모든 가져오기 펑크를 열거하여 운영 체제 로더가 이미지를 로드하고 가져오기를 스냅할 때 적절한 호출 대상을 유효하게 만들 수 있도록 해야 합니다. 주소를 가져온 가져오기 펑크가 없는 경우 테이블과 개수는 0이 될 수 있습니다.

    모듈은 IMAGE_GUARD_CF_EXPORT_SUPPRESSION_INFO_PRESENT GuardFlags 비트를 설정하여 가져온 IAT 테이블의 주소에서 가져온 모든 주소를 열거했으며 CFG ES에 적합한 모든 내보내기가 IMAGE_GUARD_FLAG_EXPORT_SUPPRESSED GFIDS 플래그로 표시됨을 나타냅니다. 이러한 펑크가 0일 수 있으며 이러한 dllexport 기호도 0일 수 있습니다. 일부 호출 대상이 DLL 로드 시간에 있어야 할 때 유효하지 않을 수 있으므로 IAT 테이블을 가져온 주소를 기본하지 못하면 정확성 문제가 될 수 있습니다.

    모듈은 IMAGE_GUARD_CF_ENABLE_EXPORT_SUPPRESSION GuardFlags 비트를 설정하여 프로세스에 CFG ES를 사용하도록 설정하려고 함을 나타냅니다. 실제로 이것은 오늘날 EXE에게만 의미가 있습니다. CFG ES를 사용하도록 설정하는 프로세스는 CFG ES로 빌드되지 않은 DLL을 로드해서는 안 되며, IAT 기호를 가져온 서명되지 않은 주소로 인해 런타임 오류가 발생할 수 있습니다. CFG ES를 사용하도록 설정하는 지원은 CFG를 사용하도록 설정하는 별도의 옵트인 옵션이어야 합니다. CFG ES 메타데이터를 제공하는 것은 안전하며 기본적으로 CFG에서 권장되지만 도구 집합은 올바른 메타데이터를 생성하도록 주의해야 합니다. 그렇지 않은 경우 생성된 이미지가 CFG ES 프로세스에서 제대로 실행되지 않을 수 있습니다. 이러한 지원은 CFG ES를 적용하는 테스트 프로세스에서 철저히 테스트해야 합니다. 운영 체제 기본 제공 시스템 DLL은 CFG ES를 이해하는 최신 Windows 10 운영 체제 버전에 대한 CFG ES 메타데이터를 지원합니다. 이 지원 이전의 운영 체제 버전은 CFG ES를 전혀 이해하지 못하며 이미지의 CFG ES 관련 지시문을 무시합니다. 이러한 이미지는 이전 운영 체제 버전과 여전히 호환됩니다.

    CFG ES 지원은 도구 집합 관점에서 선택 사항이지만, CFG ES를 원하는 프로세스에서 이미지를 실행할 수 있는 충분한 정보를 열거하기 위한 지원을 도구 집합에 포함하는 것이 좋습니다. 멘션 대부분의 프로세스가 아직 CFG ES를 사용하도록 설정하지 않으므로 도구 집합 지원을 철저히 테스트하여 CFG ES와 호환되는지 확인해야 합니다.

예외 처리 및 해제

  • .pdata 등록의 예외 처리기 정보로 지정된 __C_specific_handler 같은 언어별 처리기는 GFIDS 테이블에서 유효한 호출 대상으로 표시해서는 안 됩니다. 대신 읽기 전용 메모리를 트래버스하여 조회합니다. 마찬가지로 Microsoft C 언어별 처리기는 읽기 전용 메모리 검색을 사용하여 예외 처리기에 대한 재미 집합을 찾으므로 GFIDS 테이블에서 해당 funclets를 유효한 호출 대상으로 선언하지 않습니다.

  • 긴 점프 처리(AMD64와 같은 x86이 아닌 대상의 경우): CFG를 사용하여 컴파일하고 setjmp()/longjmp()를 지원하는 도구 집합은 SEH(구조적 예외 처리)와 상호 운용하는 "안전한 긴 점프"로 긴 점프를 구현해야 합니다. 즉, 제공된 예외 레코드의 상태 코드와 ExceptionInformation[0]이 가리키는 표준 _JUMP_BUFFER STATUS_LONGJUMP 있는 RtlUnwindEx에 대한 호출로 긴 점프가 구현됩니다. 점프 해제 대상은 해제의 TargetIp이어야 합니다. 점프 버퍼는 긴 점프가 완료된 후 운영 체제에서 복원되는 레지스터 컨텍스트를 나타냅니다. STATUS_LONGJUMP 사용하여 호출될 때 RtlUnwind(Ex)는 CFG에 고유한 특별한 의미를 줍니다. 긴 점프 대상(_JUMP_BUFFER. 립 또는 _JUMP_BUFFER. ARM64의 Lr)은 읽기 전용 메모리의 운영 체제에서 기본 로드된 모듈 목록에서 조회됩니다. 점프 대상에 대한 포함 모듈("대상 모듈")에 GuardFlags 필드에 IMAGE_GUARD_CF_LONGJUMP_TABLE_PRESENT 플래그가 설정된 경우 부하 구성 디렉터리에는 부하 구성 GuardLongJumpTargetCount 필드에 지정된 요소 개수에 대해 GuardLongJumpTargetTable whith가 있습니다. 이 테이블은 구조적으로 GFIDS 테이블과 동일한 형식으로 지정되며 동일한 GuardFlags IMAGE_GUARD_CF_FUNCTION_TABLE_SIZE_MASK 메커니즘을 사용하여 긴 점프 테이블의 선택적 추가 메타데이터 바이트를 인코딩합니다. 모든 메타데이터 바이트는 긴 점프 테이블에 대해 0이어야 하며 예약되어 있습니다.

    긴 점프 테이블은 유효한 긴 점프 대상인 정렬된 RVA 배열을 나타냅니다. 긴 점프 대상 모듈이 GuardFlags 필드에 IMAGE_GUARD_CF_LONGJUMP_TABLE_PRESENT 설정하는 경우 모든 긴 점프 대상을 LongJumpTargetTable에 열거해야 합니다. 모듈에 긴 점프 대상이 없더라도 도구 집합이 CFG에 대해 긴 점프 강화를 지원하는 경우에도 IMAGE_GUARD_CF_LONGJUMP_TABLE_PRESENT 플래그를 설정해야 합니다. 이는 이미지에 긴 점프 대상이 없고 운영 체제에서 긴 점프 대상 검사 수행할 수 없는 표시가 없는 위치에 유효한 긴 점프 대상이 있을 수 있다고 가정해야 하는 이전 이미지가 아님을 명시적으로 의미합니다.

    CFG가 지원되는 경우 기본적으로 긴 점프 강화를 사용하도록 설정하는 것이 좋습니다. 이는 Microsoft 컴파일러의 처리입니다. 긴 점프 강화(Windows 10 이전 버전 또는 이전 Windows 10 버전)를 이해하지 못하는 운영 체제는 긴 점프 강화 검사 수행하지 않고 긴 점프 강화 메타데이터를 무시하므로 긴 점프 강화는 이전 운영 체제 릴리스와 이전 버전과 호환됩니다.

    커널 모드 이미지의 경우 가드 긴 점프 대상 테이블은 dis카드able 섹션에 포함되어서는 안 됩니다. 가드 긴 점프 대상 테이블은 보안 속성이 유효하려면 항상 읽기 전용 메모리에 저장되어야 합니다.

COFF 정보

  • 개체 파일이 CFG를 준수하는지 여부를 선언하는 개체 파일 표시가 있습니다. CFG를 준수하는 개체 파일은 IAT 메타데이터를 가져온 주소뿐만 아니라 명시적으로 생성하는 유효한 호출 대상을 나열합니다. CFG를 준수하지 않는 개체 파일에는 함수 기호의 시작을 가리키는 재배치를 찾기 위해 obj 파일의 COFF 재배치를 검사하여 유추된 호출 대상이 있어야 합니다. 이는 유효한 CFG 호출 대상을 과도하게 적용할 수 있으므로 도구가 CFG를 인식하는 obj 파일을 표시하고 CFG로 컴파일하는 경우 CFG obj 파일 메타데이터를 포함하는 것이 좋습니다.

  • CFG 컴파일 모드에 대해 채워야 하는 CFG 강화된 긴 점프에 대한 긴 점프 대상을 선언하는 개체 파일 표시가 있습니다.