Fixing built-in Property for Ethernet on Legacy Hackintosh

The built-in property in an IORegistry entry for Ethernet controllers is one of those details that can silently break a Hackintosh build. When macOS sees built-in set to a value other than Yes (or 1) for a network interface, it may refuse to hand off the interface to the en0 slot, treat it as an external PCIe card, or fail to activate services like AirDrop, iMessage, and FaceTime. On legacy systems running Sierra through Mojave, the most common symptom is a network interface that appears in System Information but never gets assigned en0 — instead it lands on en1, en2, or drops off entirely after sleep.

The built-in property at offset 8 in the IORegistry node for PCIe Ethernet controllers trips up many builders using older motherboards with Realtek RTL8111, Intel I217-V, or Broadcom BCM57781 chipsets. Here’s how to inspect it, why it matters, and how to correct it using ACPI patches or device-properties injection in Clover and OpenCore.

What Is built-in and Why Offset 8?

In the IORegistry, every PCI device node has a set of properties that describe its capabilities and configuration. The built-in property is a boolean (or numeric) flag that tells macOS whether the device is soldered onto the motherboard or attached via an expansion slot. For onboard Ethernet controllers, Apple’s drivers expect built-in to be present and set to Yes (or 1). Without it, the system treats the controller as removable, which can break network service ordering and sleep/wake behavior.

Offset 8 refers to the byte position within the property data where the value is stored. When you dump the IORegistry entry for a Realtek RTL8111 on a Z77 board, you might see:

"built-in" = <00>

That <00> — a single zero byte — is the problem. macOS interprets <00> as false. The correct value is <01> (or <01000000> depending on the data type). The “8” in the common phrase built-in 8 refers to the length in bits of the property when stored as a byte — not a bitmask, but a single-byte boolean value. Some older Clover configurations mistakenly injected <01> at the wrong offset, causing the property to be ignored.

Inspecting Your Current State

Before applying any fix, confirm the current value of built-in for your Ethernet controller. Boot your Hackintosh, open Terminal, and run:

ioreg -l | grep -A10 "IOName.*ethernet" | grep "built-in"

If that returns nothing, search by vendor ID. For Realtek 8168/8111:

ioreg -l | grep -A20 "pci10ec,8168" | grep "built-in"

You should see output like:

"built-in" = <01>

If you see <00> or no built-in property at all, the interface will not be assigned en0 reliably. On some boards, the property is missing entirely from the IORegistry node, which also causes the same symptoms.

Fixing built-in via Device Properties (Clover and OpenCore)

The cleanest method for most legacy builds is to inject the property using the bootloader’s device-properties system. This avoids modifying ACPI tables and survives OS updates (as long as the bootloader config remains intact).

Finding the Correct PCI Path

First, locate the PCI device path for your Ethernet controller. In Terminal:

ioreg -r -c IONetworkController | grep "IOPathMatch"

For a typical Realtek controller on a Z77 board, the path might look like:

PciRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x0)

Copy this path exactly. In Clover’s config.plist, navigate to DeviceProperties → Add. Add a new dictionary keyed by the full PCI path. Inside that dictionary, add an entry with key built-in and type Data with value 01 (or 01000000 for 32-bit integer if you prefer consistency with Apple’s typical format). In OpenCore, the same structure applies under DeviceProperties → Add.

Example for Clover/OpenCore:

<key>PciRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x0)</key>
<dict>
    <key>built-in</key>
    <data>AQAAAA==</data>
</dict>

The AQAAAA== is base64 for 01000000 (four bytes, little-endian). If you prefer a single byte, use AQ== — though some macOS versions expect the 32-bit integer form. Test both if one fails.

ACPI-Based Fix for Stubborn Cases

Some motherboards — particularly Gigabyte Z77 and Z87 models — override the built-in property via ACPI _DSM methods in the DSDT. In that case, injecting via device properties may be overwritten at boot. You can verify this by dumping the DSDT:

iasl -d DSDT.aml

Search for your Ethernet device’s _ADR (address). For a device at PCI slot 0x1c,0x4, the address is 0x001C0004. Look for a Method (_DSM, 4, NotSerialized) block that contains built-in. If present, you have two options: either patch the DSDT to return 0x01 instead of 0x00, or rename the method so macOS falls back to the bootloader’s injected properties.

Patching the DSDT is riskier and should only be done if you have a backup of the original firmware. For most users, the device-properties injection is sufficient. If you do need to patch, look for a line like:

Return (Buffer (0x01)
{
     0x00
})

Change 0x00 to 0x01. Recompile with iasl -da DSDT.dsl, place the resulting DSDT.aml in EFI/CLOVER/ACPI/patched/ (or OC/ACPI/ for OpenCore), and reboot.

Testing the Fix

After applying the injection or ACPI patch, reboot and verify the property:

ioreg -l | grep -A10 "IOName.*ethernet" | grep "built-in"

You should now see <01>. Open System Information → Network. The built-in Ethernet should appear as en0. If it still shows as en1, check that no other interfaces (Wi-Fi, Bluetooth PAN, Thunderbolt Bridge) are claiming en0 first. You can reorder interfaces by deleting the /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist file and rebooting — but only after confirming built-in is set correctly. Without the property fix, reordering will only be temporary.

Known Caveats by Chipset and macOS Version

• Realtek RTL8111/8168 (most boards): The open-source RealtekRTL8111.kext by Mieze does not require built-in for basic functionality, but without it the interface will not get en0 on Sierra and later. Inject the property as described.
• Intel I217-V / I218-V (Haswell): These work with IntelMausiEthernet.kext. The built-in property is usually set by the firmware, but some OEM BIOS versions omit it. Check with ioreg and inject if missing.
• Broadcom BCM57781 (X79/X99): Often found on server-grade boards. The AppleBCM5701Ethernet.kext handles these, but the built-in property may be <00> due to ACPI _DSM. Inject or patch as needed.
• macOS High Sierra (10.13) and Mojave (10.14): Both enforce the built-in check more strictly than Sierra. A missing property can cause the interface to be ignored entirely after wake from sleep. If you experience “Network: Ethernet — Cable Unplugged” after sleep despite the cable being connected, check built-in first.

Interaction with Sleep and Power Management

The built-in property also affects how macOS handles the Ethernet controller during sleep. When built-in is Yes, the system knows the controller is an internal device and can reinitialize it after wake without re-enumerating the PCI bus. If the property is missing or No, macOS may power-gate the controller and fail to bring it back online, resulting in a “self-assigned IP” or “no link” state until a full reboot. This is especially common on X79 and X99 dual-CPU builds, where the PCIe topology is complex. For a deeper look at sleep issues on those platforms, see our Dual-CPU X99 Hackintosh Update: High Sierra, Clover r5123, and What to Watch For.

Verifying Without Reboot

If you want to test the effect of changing built-in without rebooting, you can use ioctl calls via a small C utility — but that is outside the scope of this guide. A safer method is to use nvram to set a boot argument that forces the property, though this only works with certain kexts. In practice, the cleanest approach is to edit your bootloader config, reboot, and verify. Always keep a backup of your working config.plist before editing.

Risks and Backup Strategy

Modifying device properties in config.plist is low-risk — a malformed entry will simply cause the bootloader to skip that injection, and your system will boot with the previous state. ACPI patching carries more risk: a syntax error in the DSDT can cause a kernel panic at boot. Always keep a backup of your original DSDT and have a recovery USB stick with a known-good configuration. If you are new to ACPI patching, start with device-properties injection first. For guidance on editing power-management tables without breaking your system, the AGPM Editing for Legacy Hackintosh: A Practical Guide covers similar precautions.

Fix the built-in property first, then troubleshoot iMessage and FaceTime — without a correct value, even a valid serial number won’t work because macOS won’t assign en0. A typical scenario: you have a perfectly configured SMBIOS but Ethernet still shows as en1 and iMessage fails. That’s the built-in issue. Patch it, reboot, and the interface moves to en0 — then you can check the rest of your iMessage setup.