How to Fix Ethernet Built-In 9 on Legacy Hackintosh Builds

When a Hackintosh installer fails to detect your onboard Ethernet controller during macOS setup, the installer log often shows a single cryptic line: Ethernet [Built-In] – not found. On legacy builds targeting Snow Leopard through High Sierra, this check is performed by the EthernetBuiltIn property in IORegistry. Setting it to Yes (value 0x01) at the correct IORegistry node is essential for iCloud, iMessage, FaceTime, and App Store authentication. Yet many guides oversimplify the process, leading to kernel panics or non-functional networking. This article details the exact mechanism, the pitfalls of misapplied patches, and how to verify the property on real hardware.

What Is Ethernet Built-In 9?

The term “Ethernet Built-In 9” refers to a specific IORegistry property key (built-in) with a value of 0x01 placed under the IONetworkingController class node. The “9” is not a version number but a shorthand used in early Clover and Chameleon forums to denote the ninth documented method for injecting the property via device-properties strings. On boards where the standard device-properties injection fails (e.g., some Intel ICH9 and ICH10 southbridges), method 9 uses a custom device-id override combined with a built-in property at the PciRoot(0x0)/Pci(0x1C,0x0)/Pci(0x0,0x0) path. This method is rarely needed on modern hardware but remains relevant for X58, P55, H55, and G41 boards running macOS 10.6–10.13.

Identifying When Method 9 Is Required

Before applying any patch, confirm that your Ethernet controller is otherwise functional. Boot into macOS installer or a known-working installation, open Terminal and run:

ioreg -l | grep -i "built-in"

If the output shows "built-in" = Yes under a node matching your PCI Ethernet device path, the property is already set. If it does not appear at all, or appears under the wrong node, your system will fail Apple’s network authentication checks even if DHCP obtains an IP address.

Method 9 is typically needed when:

• The Ethernet controller is an Intel 82574L, 82579V, or Realtek RTL8111 series on an ICH9/ICH10 southbridge.
• Standard device-properties injection (methods 1–8) yields a kernel panic at AppleIntelE1000 or AppleRTL8169Ethernet.
• The IORegistry shows the Ethernet node under IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI but without the built-in property.

Applying the Patch in Clover (r5123 and Earlier)

For Clover-based installs, method 9 is implemented via a custom config.plist entry under DeviceProperties → Add. Navigate to the correct PCI path for your Ethernet controller. On most legacy boards with the first PCIe slot dedicated to the onboard NIC, the path is PciRoot(0x0)/Pci(0x1C,0x0)/Pci(0x0,0x0). Under that path, add:

<key>built-in</key>
<data>AQAAAA==</data>

The AQAAAA== is base64 encoding of the 32-bit integer 0x01. Some guides incorrectly specify AA== (8-bit) which macOS interprets as a boolean false. Always use the 4-byte data type.

If your controller uses a device ID not natively recognized by Apple’s kexts, inject the correct device-id and vendor-id in the same dictionary. For example, for an Intel 82574L with device ID 0x10D3, add:

<key>device-id</key>
<data>0wAAAA==</data>

Verify the base64 encoding with a known tool — a single off-by-byte error will cause the kext to ignore your entry.

Verifying the Injection

After applying the patch, reboot and run the ioreg command again. The expected output should include a line similar to:

"built-in" = <01000000>

under the correct IONetworkingController node. If the property appears under a parent bridge node instead of the Ethernet device itself, iCloud authentication will still fail. Use ioreg -l -w 0 | grep -A5 "IONetworkingController" to inspect the full dictionary.

If the property still does not appear, check the Clover boot log (/EFI/CLOVER/misc/debug.log) for lines beginning with DeviceProperties:. A missing entry indicates the path string in your config.plist does not match the actual PCI topology. Re-read the device path using gfxutil -f Ethernet from the Clover shell or from macOS using gfxutil (available in the Clover package).

Risks and Data Safety

Modifying config.plist or injecting device properties carries the risk of a non-booting system. Always keep a backup of your working config.plist on a separate USB drive. If the system kernel panics after applying method 9, boot with -x (safe mode) and revert the DeviceProperties addition. In rare cases, an incorrect device-id injection can cause the Ethernet kext to load for a non-existent controller, leading to a panic loop that requires booting from a recovery USB to remove the entry.

For users running dual-CPU configurations on X79 or X99, method 9 sometimes conflicts with ACPI tables that enumerate multiple PCI root bridges. In those scenarios, the property must be applied under the correct root bridge — usually PciRoot(0x0) for the first CPU’s PCIe lanes. Our earlier guide on 10Gb Ethernet on a Legacy Hackintosh: A Practical Guide for X79, X99, and Z170 covers the additional complexity of multi-root PCI topologies.

Ethernet Built-In 9 in Chameleon and Enoch

For bootloaders predating Clover, method 9 is applied via org.chameleon.Boot.plist using the EthernetBuiltIn key set to Yes. However, Chameleon’s implementation only injects the property at the first IONetworkingController it finds, which on boards with multiple NICs may target the wrong device. To force the correct device, use the device-properties string approach with gfxutil to generate a hex string that includes the built-in property at the exact path. Generate the string with:

gfxutil -o -n -a built-in -t data 01000000 -p PciRoot(0x0)/Pci(0x1C,0x0)/Pci(0x0,0x0)

Paste the resulting hex string into device-properties in your boot plist. This method bypasses Chameleon’s automatic detection and is the only reliable way on boards with multiple PCIe-to-PCI bridges.

Troubleshooting Sleep/Wake and Ethernet

A correctly injected built-in property also affects power management. On legacy boards, the built-in flag signals to IOEthernetController that the interface is internal, enabling proper wake-on-LAN (WOL) support. If sleep works but the Ethernet controller does not reinitialize after wake, the property may be missing or the controller’s IONameMatch entry may be incorrect. Check the kernel log (log show --predicate 'eventMessage contains "Ethernet"' --last boot) for lines like Ethernet [RealtekRTL8111]: link up after wake. If absent, re-apply the injection with the correct data length and verify the device path.

For users struggling with sleep/wake issues on Sierra or High Sierra builds, the interplay between Ethernet properties and ACPI power states is documented in our dedicated guide: Fixing Sleep/Wake Issues on Legacy Hackintosh Builds (Sierra & High Sierra). That article covers SSDT patches that complement the built-in injection.

Testing with Real Hardware: GA-P55A-UD3R

On a Gigabyte GA-P55A-UD3R (Intel P55 chipset, ICH10R southbridge) running macOS 10.12.6, the onboard Realtek RTL8111D required method 9 because the standard Clover DeviceProperties → Add entry at PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x0) (the path reported by gfxutil) was ignored by the AppleRTL8169Ethernet kext. After adding the built-in key with base64 AQAAAA== at that exact path and injecting device-id 0x8168 (the ID recognized by the kext), iMessage activation succeeded and WOL functioned correctly after sleep. Without the built-in property, the interface appeared in System Preferences but iCloud login returned “An unknown error occurred.”

Final Verification Checklist

Before considering the patch complete, confirm each of these points:

1. built-in appears under the correct IONetworkingController node in IORegistry.
2. The data value is exactly 01000000 (4 bytes).
3. The controller’s device-id matches a known Apple kext or is injected.
4. iCloud/iMessage login succeeds on first attempt (allow 30 seconds after boot).
5. Wake-on-LAN works after at least three sleep/wake cycles.

If any check fails, revert the injection and test with a different PCI path — some BIOS implementations enumerate the onboard NIC under a different bridge depending on which PCIe slot is populated.