"TT_EnableWriteUnprotector" = "Type: plist boolean\nFailsafe: false\nDescription: Permit write access to UEFI runtime services code.\n\nThis option bypasses RˆX permissions in code pages of UEFI runtime services by removing write protection (WP) bit from CR0 register during their execution. This quirk requires OC_FIRMWARE_RUNTIME protocol implemented in OpenRuntime.efi.\n\nNote: This quirk may potentially weaken firmware security. Please use RebuildAppleMemoryMap if the firmware supports memory attributes table (MAT). Refer to the OCABC: MAT support is 1/0 log entry to determine wheter MAT is supported.";
"TT_FixupAppleEfiImages" = "Type: plist boolean\nFailsafe: false\nDescription: Fix errors in early Mac OS X boot.efi images.\n\nModern secure PE loaders will refuse to load boot.efi images from Mac OS X 10.4 and 10.5 due to these files containing WˆX errors and illegal overlapping sections.\n\nThis quirk detects these issues and pre-processes such images in memory, so that a modern loader can accept them.\n\nPre-processing in memory is incompatible with secure boot, as the image loaded is not the image on disk, so you cannot sign files which are loaded in this way based on their original disk image contents. Certain firmware will offer to register the hash of new, unknown images - this would still work. On the other hand, it is not particularly realistic to want to start such early, insecure images with secure boot anyway.\n\nNote 1: The quirk is only applied to Apple-specific ‘fat’ (both 32-bit and 64-bit versions in one image) .efi files, and is never applied during the Apple secure boot path for newer macOS.\n\nNote 2: The quirk is only needed for loading Mac OS X 10.4 and 10.5, and even then only if the firmware itself includes a modern, more secure PE COFF image loader. This includes current builds of OpenDuet.";
"TT_FixupAppleEfiImages" = "Type: plist boolean\nFailsafe: false\nDescription: Fix errors in early macOS boot.efi images.\n\nModern secure PE loaders will refuse to load boot.efi images from macOS 10.4 to 10.12 due to these files containing WˆX errors (in all versions) and illegal overlapping sections (in 10.4 and 10.5 32-bit versions only).\n\nThis quirk detects these issues and pre-processes such images in memory, so that a modern loader will accept them.\n\nPre-processing in memory is incompatible with secure boot, as the image loaded is not the image on disk, so you cannot sign files which are loaded in this way based on their original disk image contents. Certain firmware will offer to register the hash of new, unknown images - this would still work. On the other hand, it is not particularly realistic to want to start these early, insecure images with secure boot anyway.\n\nNote 1: When enabled, this quirk is applied to all Apple-specific Fat binaries (both 32-bit and 64-bit versions in one image) and to any other Apple-signed boot images that are not being processed for Apple secure boot.\n\nNote 2: The quirk is never applied during the Apple secure boot path for newer macOS. The Apple secure boot path includes its own separate mitigations for boot.efi WˆX issues.\n\nNote 3: This quirk is needed for macOS 10.4 to 10.12 (and higher, if Apple secure boot is not enabled), but only when the firmware itself includes a modern, more secure PE COFF image loader. This applies to current builds of OpenDuet and to OVMF if built from audk source code.";
/* woE-nK-MFN */
"TT_ForceBooterSignature" = "Type: plist boolean\nFailsafe: false\nDescription: Set macOS boot-signature to OpenCore launcher.\n\nBooter signature, essentially a SHA-1 hash of the loaded image, is used by Mac EFI to verify the authenticity of the bootloader when waking from hibernation. This option forces macOS to use OpenCore launcher SHA-1 hash as a booter signature to let OpenCore shim hibernation wake on Mac EFI firmware.\n\nNote: OpenCore launcher path is determined from LauncherPath property.";
"TT_EnableWriteUnprotector" = "Type: plist boolean\nFailsafe: false\nDescription: Permit write access to UEFI runtime services code.\n\nThis option bypasses RˆX permissions in code pages of UEFI runtime services by removing write protection (WP) bit from CR0 register during their execution. This quirk requires OC_FIRMWARE_RUNTIME protocol implemented in OpenRuntime.efi.\n\nNote: This quirk may potentially weaken firmware security. Please use RebuildAppleMemoryMap if the firmware supports memory attributes table (MAT). Refer to the OCABC: MAT support is 1/0 log entry to determine wheter MAT is supported.";
"TT_FixupAppleEfiImages" = "Type: plist boolean\nFailsafe: false\nDescription: Fix errors in early Mac OS X boot.efi images.\n\nModern secure PE loaders will refuse to load boot.efi images from Mac OS X 10.4 and 10.5 due to these files containing WˆX errors and illegal overlapping sections.\n\nThis quirk detects these issues and pre-processes such images in memory, so that a modern loader can accept them.\n\nPre-processing in memory is incompatible with secure boot, as the image loaded is not the image on disk, so you cannot sign files which are loaded in this way based on their original disk image contents. Certain firmware will offer to register the hash of new, unknown images - this would still work. On the other hand, it is not particularly realistic to want to start such early, insecure images with secure boot anyway.\n\nNote 1: The quirk is only applied to Apple-specific ‘fat’ (both 32-bit and 64-bit versions in one image) .efi files, and is never applied during the Apple secure boot path for newer macOS.\n\nNote 2: The quirk is only needed for loading Mac OS X 10.4 and 10.5, and even then only if the firmware itself includes a modern, more secure PE COFF image loader. This includes current builds of OpenDuet.";
"TT_FixupAppleEfiImages" = "Type: plist boolean\nFailsafe: false\nDescription: Fix errors in early macOS boot.efi images.\n\nModern secure PE loaders will refuse to load boot.efi images from macOS 10.4 to 10.12 due to these files containing WˆX errors (in all versions) and illegal overlapping sections (in 10.4 and 10.5 32-bit versions only).\n\nThis quirk detects these issues and pre-processes such images in memory, so that a modern loader will accept them.\n\nPre-processing in memory is incompatible with secure boot, as the image loaded is not the image on disk, so you cannot sign files which are loaded in this way based on their original disk image contents. Certain firmware will offer to register the hash of new, unknown images - this would still work. On the other hand, it is not particularly realistic to want to start these early, insecure images with secure boot anyway.\n\nNote 1: When enabled, this quirk is applied to all Apple-specific Fat binaries (both 32-bit and 64-bit versions in one image) and to any other Apple-signed boot images that are not being processed for Apple secure boot.\n\nNote 2: The quirk is never applied during the Apple secure boot path for newer macOS. The Apple secure boot path includes its own separate mitigations for boot.efi WˆX issues.\n\nNote 3: This quirk is needed for macOS 10.4 to 10.12 (and higher, if Apple secure boot is not enabled), but only when the firmware itself includes a modern, more secure PE COFF image loader. This applies to current builds of OpenDuet and to OVMF if built from audk source code.";
/* woE-nK-MFN */
"TT_ForceBooterSignature" = "Type: plist boolean\nFailsafe: false\nDescription: Set macOS boot-signature to OpenCore launcher.\n\nBooter signature, essentially a SHA-1 hash of the loaded image, is used by Mac EFI to verify the authenticity of the bootloader when waking from hibernation. This option forces macOS to use OpenCore launcher SHA-1 hash as a booter signature to let OpenCore shim hibernation wake on Mac EFI firmware.\n\nNote: OpenCore launcher path is determined from LauncherPath property.";
"TT_EnableWriteUnprotector" = "Type: plist boolean\nFailsafe: false\nDescription: Permit write access to UEFI runtime services code.\n\nThis option bypasses RˆX permissions in code pages of UEFI runtime services by removing write protection (WP) bit from CR0 register during their execution. This quirk requires OC_FIRMWARE_RUNTIME protocol implemented in OpenRuntime.efi.\n\nNote: This quirk may potentially weaken firmware security. Please use RebuildAppleMemoryMap if the firmware supports memory attributes table (MAT). Refer to the OCABC: MAT support is 1/0 log entry to determine wheter MAT is supported.";
"TT_FixupAppleEfiImages" = "Type: plist boolean\nFailsafe: false\nDescription: Fix errors in early Mac OS X boot.efi images.\n\nModern secure PE loaders will refuse to load boot.efi images from Mac OS X 10.4 and 10.5 due to these files containing WˆX errors and illegal overlapping sections.\n\nThis quirk detects these issues and pre-processes such images in memory, so that a modern loader can accept them.\n\nPre-processing in memory is incompatible with secure boot, as the image loaded is not the image on disk, so you cannot sign files which are loaded in this way based on their original disk image contents. Certain firmware will offer to register the hash of new, unknown images - this would still work. On the other hand, it is not particularly realistic to want to start such early, insecure images with secure boot anyway.\n\nNote 1: The quirk is only applied to Apple-specific ‘fat’ (both 32-bit and 64-bit versions in one image) .efi files, and is never applied during the Apple secure boot path for newer macOS.\n\nNote 2: The quirk is only needed for loading Mac OS X 10.4 and 10.5, and even then only if the firmware itself includes a modern, more secure PE COFF image loader. This includes current builds of OpenDuet.";
"TT_FixupAppleEfiImages" = "Type: plist boolean\nFailsafe: false\nDescription: Fix errors in early macOS boot.efi images.\n\nModern secure PE loaders will refuse to load boot.efi images from macOS 10.4 to 10.12 due to these files containing WˆX errors (in all versions) and illegal overlapping sections (in 10.4 and 10.5 32-bit versions only).\n\nThis quirk detects these issues and pre-processes such images in memory, so that a modern loader will accept them.\n\nPre-processing in memory is incompatible with secure boot, as the image loaded is not the image on disk, so you cannot sign files which are loaded in this way based on their original disk image contents. Certain firmware will offer to register the hash of new, unknown images - this would still work. On the other hand, it is not particularly realistic to want to start these early, insecure images with secure boot anyway.\n\nNote 1: When enabled, this quirk is applied to all Apple-specific Fat binaries (both 32-bit and 64-bit versions in one image) and to any other Apple-signed boot images that are not being processed for Apple secure boot.\n\nNote 2: The quirk is never applied during the Apple secure boot path for newer macOS. The Apple secure boot path includes its own separate mitigations for boot.efi WˆX issues.\n\nNote 3: This quirk is needed for macOS 10.4 to 10.12 (and higher, if Apple secure boot is not enabled), but only when the firmware itself includes a modern, more secure PE COFF image loader. This applies to current builds of OpenDuet and to OVMF if built from audk source code.";
/* woE-nK-MFN */
"TT_ForceBooterSignature" = "Type: plist boolean\nFailsafe: false\nDescription: Set macOS boot-signature to OpenCore launcher.\n\nBooter signature, essentially a SHA-1 hash of the loaded image, is used by Mac EFI to verify the authenticity of the bootloader when waking from hibernation. This option forces macOS to use OpenCore launcher SHA-1 hash as a booter signature to let OpenCore shim hibernation wake on Mac EFI firmware.\n\nNote: OpenCore launcher path is determined from LauncherPath property.";
"TT_EnableWriteUnprotector" = "Type: plist boolean\nFailsafe: false\nDescription: Permit write access to UEFI runtime services code.\n\nThis option bypasses RˆX permissions in code pages of UEFI runtime services by removing write protection (WP) bit from CR0 register during their execution. This quirk requires OC_FIRMWARE_RUNTIME protocol implemented in OpenRuntime.efi.\n\nNote: This quirk may potentially weaken firmware security. Please use RebuildAppleMemoryMap if the firmware supports memory attributes table (MAT). Refer to the OCABC: MAT support is 1/0 log entry to determine wheter MAT is supported.";
"TT_FixupAppleEfiImages" = "Type: plist boolean\nFailsafe: false\nDescription: Fix errors in early Mac OS X boot.efi images.\n\nModern secure PE loaders will refuse to load boot.efi images from Mac OS X 10.4 and 10.5 due to these files containing WˆX errors and illegal overlapping sections.\n\nThis quirk detects these issues and pre-processes such images in memory, so that a modern loader can accept them.\n\nPre-processing in memory is incompatible with secure boot, as the image loaded is not the image on disk, so you cannot sign files which are loaded in this way based on their original disk image contents. Certain firmware will offer to register the hash of new, unknown images - this would still work. On the other hand, it is not particularly realistic to want to start such early, insecure images with secure boot anyway.\n\nNote 1: The quirk is only applied to Apple-specific ‘fat’ (both 32-bit and 64-bit versions in one image) .efi files, and is never applied during the Apple secure boot path for newer macOS.\n\nNote 2: The quirk is only needed for loading Mac OS X 10.4 and 10.5, and even then only if the firmware itself includes a modern, more secure PE COFF image loader. This includes current builds of OpenDuet.";
"TT_FixupAppleEfiImages" = "Type: plist boolean\nFailsafe: false\nDescription: Fix errors in early macOS boot.efi images.\n\nModern secure PE loaders will refuse to load boot.efi images from macOS 10.4 to 10.12 due to these files containing WˆX errors (in all versions) and illegal overlapping sections (in 10.4 and 10.5 32-bit versions only).\n\nThis quirk detects these issues and pre-processes such images in memory, so that a modern loader will accept them.\n\nPre-processing in memory is incompatible with secure boot, as the image loaded is not the image on disk, so you cannot sign files which are loaded in this way based on their original disk image contents. Certain firmware will offer to register the hash of new, unknown images - this would still work. On the other hand, it is not particularly realistic to want to start these early, insecure images with secure boot anyway.\n\nNote 1: When enabled, this quirk is applied to all Apple-specific Fat binaries (both 32-bit and 64-bit versions in one image) and to any other Apple-signed boot images that are not being processed for Apple secure boot.\n\nNote 2: The quirk is never applied during the Apple secure boot path for newer macOS. The Apple secure boot path includes its own separate mitigations for boot.efi WˆX issues.\n\nNote 3: This quirk is needed for macOS 10.4 to 10.12 (and higher, if Apple secure boot is not enabled), but only when the firmware itself includes a modern, more secure PE COFF image loader. This applies to current builds of OpenDuet and to OVMF if built from audk source code.";
/* woE-nK-MFN */
"TT_ForceBooterSignature" = "Type: plist boolean\nFailsafe: false\nDescription: Set macOS boot-signature to OpenCore launcher.\n\nBooter signature, essentially a SHA-1 hash of the loaded image, is used by Mac EFI to verify the authenticity of the bootloader when waking from hibernation. This option forces macOS to use OpenCore launcher SHA-1 hash as a booter signature to let OpenCore shim hibernation wake on Mac EFI firmware.\n\nNote: OpenCore launcher path is determined from LauncherPath property.";
"TT_EnableWriteUnprotector" = "Type: plist boolean\nFailsafe: false\nDescription: Permit write access to UEFI runtime services code.\n\nThis option bypasses RˆX permissions in code pages of UEFI runtime services by removing write protection (WP) bit from CR0 register during their execution. This quirk requires OC_FIRMWARE_RUNTIME protocol implemented in OpenRuntime.efi.\n\nNote: This quirk may potentially weaken firmware security. Please use RebuildAppleMemoryMap if the firmware supports memory attributes table (MAT). Refer to the OCABC: MAT support is 1/0 log entry to determine wheter MAT is supported.";
"TT_FixupAppleEfiImages" = "Type: plist boolean\nFailsafe: false\nDescription: Fix errors in early Mac OS X boot.efi images.\n\nModern secure PE loaders will refuse to load boot.efi images from Mac OS X 10.4 and 10.5 due to these files containing WˆX errors and illegal overlapping sections.\n\nThis quirk detects these issues and pre-processes such images in memory, so that a modern loader can accept them.\n\nPre-processing in memory is incompatible with secure boot, as the image loaded is not the image on disk, so you cannot sign files which are loaded in this way based on their original disk image contents. Certain firmware will offer to register the hash of new, unknown images - this would still work. On the other hand, it is not particularly realistic to want to start such early, insecure images with secure boot anyway.\n\nNote 1: The quirk is only applied to Apple-specific ‘fat’ (both 32-bit and 64-bit versions in one image) .efi files, and is never applied during the Apple secure boot path for newer macOS.\n\nNote 2: The quirk is only needed for loading Mac OS X 10.4 and 10.5, and even then only if the firmware itself includes a modern, more secure PE COFF image loader. This includes current builds of OpenDuet.";
"TT_FixupAppleEfiImages" = "Type: plist boolean\nFailsafe: false\nDescription: Fix errors in early macOS boot.efi images.\n\nModern secure PE loaders will refuse to load boot.efi images from macOS 10.4 to 10.12 due to these files containing WˆX errors (in all versions) and illegal overlapping sections (in 10.4 and 10.5 32-bit versions only).\n\nThis quirk detects these issues and pre-processes such images in memory, so that a modern loader will accept them.\n\nPre-processing in memory is incompatible with secure boot, as the image loaded is not the image on disk, so you cannot sign files which are loaded in this way based on their original disk image contents. Certain firmware will offer to register the hash of new, unknown images - this would still work. On the other hand, it is not particularly realistic to want to start these early, insecure images with secure boot anyway.\n\nNote 1: When enabled, this quirk is applied to all Apple-specific Fat binaries (both 32-bit and 64-bit versions in one image) and to any other Apple-signed boot images that are not being processed for Apple secure boot.\n\nNote 2: The quirk is never applied during the Apple secure boot path for newer macOS. The Apple secure boot path includes its own separate mitigations for boot.efi WˆX issues.\n\nNote 3: This quirk is needed for macOS 10.4 to 10.12 (and higher, if Apple secure boot is not enabled), but only when the firmware itself includes a modern, more secure PE COFF image loader. This applies to current builds of OpenDuet and to OVMF if built from audk source code.";
/* woE-nK-MFN */
"TT_ForceBooterSignature" = "Type: plist boolean\nFailsafe: false\nDescription: Set macOS boot-signature to OpenCore launcher.\n\nBooter signature, essentially a SHA-1 hash of the loaded image, is used by Mac EFI to verify the authenticity of the bootloader when waking from hibernation. This option forces macOS to use OpenCore launcher SHA-1 hash as a booter signature to let OpenCore shim hibernation wake on Mac EFI firmware.\n\nNote: OpenCore launcher path is determined from LauncherPath property.";
