How to Read and Inject PCI Device IDs on Legacy Hackintosh

Boot a legacy Hackintosh for the first time and open System Information under the PCI section. What you see is a raw dump of how macOS sees your hardware. Every entry—vendor ID, device ID, revision ID, class code—is a fingerprint the kernel uses to decide which driver to load, or whether to load one at all. Get these identifiers wrong, or fail to inject them when macOS expects something else, and you'll likely find your motherboard's Ethernet port unrecognized, an audio codec staying silent, or a SATA controller refusing to negotiate AHCI.

This guide covers how to read PCI device lists on systems running macOS 10.9 through 10.15, cross-reference those IDs against Apple's native drivers, and use injection methods to substitute a device ID that macOS trusts. All examples assume you're working with a Clover bootloader configuration; OpenCore users will find the same principles apply under DeviceProperties, though the syntax differs slightly.

What the PCI Device List Actually Shows

In macOS, open System Information (About This Mac > System Report) and click PCI. The table lists every device on the PCI bus that the operating system has detected, along with its assigned slot name, driver, vendor, and a set of hex codes. The critical columns are:

• Vendor ID – Four hex digits identifying the chipset manufacturer. 0x8086 is Intel, 0x1002 is AMD (ATI), 0x10DE is NVIDIA, 0x168C is Qualcomm Atheros.
• Device ID – Four hex digits identifying the specific chip model. For example, Intel I217-V Ethernet shows 0x153B.
• Revision ID – Two hex digits indicating the stepping of the silicon. Sometimes a later revision of the same chip needs a different kext.
• Class Code – A six-digit hex code that tells macOS what kind of device it is: 0x020000 is Ethernet, 0x040300 is audio, 0x010601 is AHCI SATA, 0x030000 is VGA-compatible graphics.

If a device appears in the list but shows “No driver loaded” in the Driver column, that's your first clue that macOS does not have a native kext matching that vendor/device pair. The same table also reveals devices that macOS sees but cannot assign a functional driver—often the case with Realtek Ethernet controllers or older Intel HD Audio codecs on unsupported chipsets.

Mapping Device IDs to Known Working Configurations

Before you inject anything, you need a baseline. The safest approach is to match your hardware against a configuration that Apple actually shipped. For example, a Z77-based motherboard with Intel HDA audio (codec ID 0x80862806) corresponds to the same controller used in iMac13,x systems. A Realtek ALC892 codec, on the other hand, appears in no genuine Mac—so you must spoof its device ID to one that Apple's AppleHDA kext recognizes.

I maintain a personal reference table for the most common legacy chipsets. Here is a condensed version for three frequently encountered controllers on LGA1155 and LGA2011 boards:

Notice that the Realtek Ethernet device ID does not change; what matters is that the kext you load recognizes that ID. For audio, the codec's device ID stays the same, but you must also inject a layout-id property so AppleALC knows which audio path configuration to apply. Getting the layout wrong produces no sound or distorted output.

Reading the PCI List to Diagnose a Failed Ethernet

Imagine you have a Gigabyte GA-Z77X-UD5H with an Intel 82579V Ethernet controller. You boot macOS High Sierra and find no network. Open System Information > PCI. Look for a device with class code 0x020000. If it shows Vendor 0x8086 and Device 0x1503, that is the 82579V—a chip that Apple used in several iMac models. It should work natively. But if the entry shows “No driver loaded”, the problem is likely a missing or misconfigured AppleIntelE1000e.kext in your EFI/CLOVER/kexts/Other folder, or a conflict with another Ethernet kext.

If instead the device ID reads 0x153B (I217-V) but your board actually has the older 82579V, someone may have replaced the chip or you might be reading the wrong entry. Cross-check the slot location: PCI Slot 1, built-in Ethernet, or something similar. The physical location in the table often helps disambiguate multiple network controllers.

Injecting Device Properties via Clover

Clover's Devices section in config.plist lets you override vendor-id, device-id, and subsystem-id for any PCI device, identified by its full ACPI path (for example, _SB.PCI0.RP01.PXSX). The most reliable method, however, is to use the AddProperties method under the ACPI section, which applies properties before the kernel enumerates the device. Here is a concrete example for spoofing a Broadcom BCM94360CS2 Wi-Fi card that is detected as an unsupported AirPort device:

<key>AddProperties</key>
<array>
    <dict>
        <key>Device</key>
        <string>RP01.PXSX</string>
        <key>Key</key>
        <string>device-id</string>
        <key>Value</key>
        <data>4331</data>
        <key>Comment</key>
        <string>Spoof BCM94360CS2 device ID</string>
    </dict>
</array>

This injects device-id 0x4331 (Broadcom BCM4331 used in Apple's AirPort Extreme) into the device at that ACPI path. Without the injection, macOS sees the native Broadcom ID and refuses to bind the AirPort driver. The same technique works for audio codecs: inject device-id matching an Apple-supported HDA device, then add layout-id separately.

For a full walkthrough of injecting properties for AMD and NVIDIA GPUs, including framebuffer patches that depend on device ID spoofing, see the article on Legacy Hackintosh Graphics Injection: AMD, NVIDIA, Intel GPU Properties.

Class Code Injection for Unusual Controllers

Some PCI devices, especially FireWire controllers or third-party SATA chips (like Marvell 88SE9128), have a class code that macOS misinterprets. You can override the class-code property in the same AddProperties block. For example, a Marvell controller that shows up as class 0x010400 (RAID) might need to be forced to 0x010601 (AHCI) to work with the native AppleAHCIPort kext.

To find the correct class code for your device, look up the PCI SIG specification or check what class code Apple uses for a similar device in a real Mac. Injection of class code is rare but essential when dealing with add-on cards that the OS refuses to drive.

Verifying Injection Success

After you apply changes to config.plist and reboot, open System Information > PCI again. The device you patched should now show the injected vendor-id or device-id in the appropriate column, and the Driver column should list the kext that macOS loaded. If the driver still says “No driver loaded”, the injection might have failed because the ACPI path in your config.plist does not match the actual path the firmware assigned. Use IORegistryExplorer to confirm the device's location in the I/O registry tree—the path in Clover must exactly match the name under IOService.

Sleep and Wake Implications

Injecting device IDs can affect power management. If you spoof a device to one that macOS expects to see on a different PCI topology, the system may fail to enter sleep or wake properly. This is especially true for Ethernet controllers that participate in Wake-on-LAN. If you encounter sleep issues after a device ID injection, check whether the device's power state transitions are handled by the driver. For Radeon HD 7870 users, the AGPM edits described in Fix Sleep/Wake on Hackintosh: Editing AGPM for Radeon HD 7870 can complement device property injection to stabilize sleep.

Risks and Backup Strategy

Every time you modify config.plist or add a new kext, you risk a kernel panic at boot. Before editing, copy your current EFI folder to a FAT32 USB drive that you can boot from if the system becomes unbootable. Also keep a known-good config.plist on the same drive. For audio injection specifically, testing with a bootable USB installer of the same macOS version avoids corrupting your working installation.

Device ID injection is a reversible process—remove the property, reboot, and the hardware returns to its native identity. The danger lies in applying multiple overlapping patches that conflict. Start with one device at a time, confirm it works, then move to the next.

When you have a stable set of injected properties, save the config.plist and the corresponding kexts in a dedicated folder named after the motherboard model and macOS version. That archive becomes your recovery reference if you later update the bootloader or switch to a different macOS build.