Apple’s eficheck…

Ok. So you use Clover with an AMI or Phoenix BIOS. Well. In that case you may be interested in this:
Image of AM and Phoenix BIOS cleanup code
This is part of routines that wipe data in the generated dump, but why would Apple do this for AMI/Phoenix BIOS? That is PC only ROM?!?

Edit: Privacy matters, and that is why Apple clears certain sensible areas.

Oh yeah. I should add that this can be found in this binary: /usr/libexec/firmwarecheckers/eficheck

usage: eficheck: [ --save -b  ]
                 [ --cleanup -b  ]
                 [ --generate-hashes [ -b  ] [ -p  ] ]
                 [ --integrity-check [ -h  [ -b  ] ] ]
                 [ --show-hashes [ -h  ] | [ -b  ] ]

	  'eficheck --save -b firmware.bin'
		 Save this system's EFI firmware as firmware.bin
	  'eficheck --cleanup -b firmware.bin'
		 Overwrite the EFI variables portion of the firmware, enabling the file to be shared for analysis
	  'eficheck --generate-hashes'
		 Analyze the current system's installed EFI firmware, and store the hashes into hash file(s) in current folder
		 File name(s) will be selected according to image's EFI version(s)
	  'eficheck --generate-hashes -b firmware.bin'
		 Analyze the firmware.bin, and store the hashes into hash file(s) in current folder
	  'eficheck --generate-hashes -p /usr/local/allowlists'
		 Analyze the current system's installed EFI firmware, and store the hashes into hash file(s) in /usr/local/allowlists folder
	  'eficheck --integrity-check'
		 Attempt to automatically determine which firmware you are running, and integrity check against the appropriate file, and report any differences
	  'eficheck --integrity-check -h /usr/libexec/firmwarecheckers/eficheck/EFIAllowListShipping.bundle/allowlists/IM171.88Z.0105.B08.1604111319.0.ealf'
		 Compare the current system's EFI firmware against the Apple-provided expected measurements for an "iMac17,1" at firmware revision B08, and report any differences
	  'eficheck --integrity-check -h hash.ealf -b firmware.bin'
		 Compare the given hash file against against the given firmware image and report any differences
	  'eficheck --show-hashes'
		 Print the hashes for the current system's installed EFI firmware to stdout
	  'eficheck --show-hashes -b firmware.bin'
		 Print the hashes for the given firmware.bin to stdout
	  'eficheck --show-hashes -h allowlist.ealf'
		 Print the hashes for the given allowlist.ealf to stdout

Data is downloaded from: and the initial package (EFIAllowListAll.pkg) can be downloaded here. Which was later replaced with a new update, available here. You can find the local allow list at:


There is also EFIAllowListInternal.pkg for Apple engineers, but that is not a public download.

_IsInternalOsBuild calls csr_check(CSR_ALLOW_APPLE_INTERNAL) to differentiate between public and internal OS builds.

It works with /System/Library/Extensions/eficheck.kext which matches via PCI device-id’s with one of the Intel LPC Controller/eSPI Controllers in this list:


So what is this? What does it mean?

Well. Apple is likely using eficheck as an extra layer of security. To verify your EFI ROM (checksum) against the original one in their EFI ROM database, with the checksum of files that were produced by Apple. Or that you are using some modified copy of their EFI ROM firmware. This may mean that your EFI ROM has been tampered with, or that it somehow got damaged. Which is when your broken EFI ROM is invalidated and then you will see this dialog:

Image of the eficheck dialog
Honestly. I personally had never seen it, but there you have it. Thanks to @stroughtonsmith. Anyway. Just don’t click “Send to Apple” on a hack. Or wait. Let’s just click that button and wait and see if the ROM’s checksum shows up in a next update – this may as well be a fully automated process, like Apple used to add unsigned kexts to OSKextExcludeList (think AppleKextExcludeList.kext).

But seriously. Does eficheck --integrity-check even work with a Clover setup? What is the console output that you get when you run it? And in case that works for you, then my next question would be; Is your personal/identifiable data really removed?

There is one other thing that I’d like to figure out, and that is why Apple reads the PlatformUUID. That should not be required. Not ever.

Edit: I changed the title after I figured out what this binary does, and it is good, be it a start only.

The LaunchDaemon can be found at:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">

Run every seven days.

28 thoughts on “Apple’s eficheck…

  1. The cleanup option should be harmless – it should be cleaning up NVRAM variables in the dump files (which may contain stuff like system serial numbers/etc). eficheck was in the 10.12.4/10.12.5 betas too.

    • Thanks. I know when eficheck was added (I never said that it was new) and what it does, but the real question is: why is Apple interested in PC BIOS dumps? There is no need for Apple to cleanup data from PC BIOS dumps, because seriously; why would they even look at it?

      • Perhaps it’s a simple case of code reuse. There were some strings (in the 10.12.4 version at least) that indicated that it was written by LegbaCore (firmware security consulting group that was acquired by Apple last year). LegbaCore did do consulting work for some OEMs, so it’s possible that they reused existing functionality.

      • Makes perfect sense.

        They are looking for tampered firmware. Read about the NSA hacks and how they persist. There are also reported hacks via ethernet controllers.

        You need to clean up the user-specific EFI strings. Your name can be found in Back to My Mac’s EFI variables. Also things like SN and UUID for privacy.

  2. Apple is pro hackintosh folks! We’re a huge part of there customer base… Indirectly! That extract is just proof of it… They help us fix crapy bios code.

  3. I got that “potential problem” dialog a few days ago (my system is completely wrecked and barely runs since High Sierra DP5). I didn’t pay attention but I will if I get it again.

  4. 1) I get the dialog on my Clover setup embarrassingly often (both Sierra and High Sierra). Of course, I’ve never sent it out. On Sierra it started appearing either with 10.12.5 or 10.12.6.

    2) Got the dialog once on a real 15″ 2011 Macbook Pro running High Sierra. Sent it to Apple: maybe they introduced a bug into my firmware or something.

  5. Pingback: new Apple tools: eficheck (and nvm) | Firmware Security

  6. Just got the prompt to send an error report on High Sierra. Running on Clover, but definitely haven’t seen this before. Does this mean there’s something wrong with my SMBIOS that’s triggering it?

    • Just to update that even though I get the following output (using Clover), I still get the prompt to send the report to Apple:

      /usr/libexec/firmwarecheckers/eficheck/eficheck –integrity-check
      IntegrityCheck: EFI version not found

    • The dialog is triggered after the EFI check against the checksums in a database with known EFI versions. You may use the correct EFI version (string) but the checksum of your BIOS won’t match with the one in the database. This is nothing to worry about.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s