Interview with LegbaCore (and: their OpROM checker ships!)

A while ago, I emailed Corey and Xeno of LegbaCore, and sent them a few questions for an ‘interview’ for this blog. Well, here’s the results (also see EOM for URLs):

Q: This October in Singapore you’re giving 3-days of training at HITB. Besides new Apple EFI skills, can you give us some other new things that’ll be in this training?
A: The course introduces the basics of evaluating firmware and SMM on modern platforms for security vulnerabilities, as well as for potential compromises. Specifically we work through methodologies for identifying whether or not your system contains publically known vulnerabilities (which a great majority of them do). We also introduce a firmware forensic and reverse engineering methodology for identifying potential firmware compromises… so say if you got comprised by something like the hacking team UEFI rootkit, we’d talk about the tools and procedures that would be useful for identifying and analyzing this threat both on one particular system and at scale across your enterprise.
    The most important point of the training is it will be focused on real hardware that is deployed in real environments. A large portion of the course will involve evaluating the hardware that students bring with them. This way if you’re in charge of malware detection/response in an enterprise, you’ll walk away with actionable information related to the hardware you are deploying on your network.

Q: You had a Twitter post a few weeks (months?) back, saying that you were going to start releasing information about OEM systems’s vulnerabilities. What’s up with that project, I’m eager to see this data, as Consumer Reports and other computer review sources are useless for this most crucial pre-sales information. Any chance you could give a teaser of this information, perhaps one new OEM model released in the last 6 months that’s insecure? 🙂
A: We anticipate that the project to start making some vendors’ firmware security failings more apparent (via a public website) will probably kick off in early 2016. We want to give all vendors that we think may have an interest in improving their security a chance to either talk with us about working with them, or show that they can make measurable security improvements on their own within this timeframe.

Q: You had a Twitter post a few days ago, pointing to a new LegbaCore Github repository for a new Option ROM checking tool. This sounds very interesting! What kinds of Option ROM(s) will it support? What platform(s) will it run on? When can we expect initial release?
A: It will only integrity check the Apple Thunderbolt to Ethernet adapter’s option ROM. It will work in conjunction with a port of the linux tg3 kernel driver to run on Macs to dump the OROM. The “ethtool” command can also be run to dump the OROM on linux systems that have a thunderbolt port and the tg3 driver available. The tool will be released to coincide with the talk at BlackHat, August 6th.

Q: Beyond this new Option ROM checker, does LegbaCore have any additional tool plans in the works? If so, any details to reveal?
A: Our current thinking on tools is that we expect that we will make clean-slate “best effort” tools freely available at some point in the future. These tools would be like all typical security tools, being not particularly trustworthy, and thus vulnerable to attacker subversion. They would mostly be useful for catching attackers as they first enter into the domain, and are not particularly sophisticated. However we will only make those tools available once we have commercial-grade tools available, that have a trust argument for why these paid tools have the ability to stand up to sophisticated and well-resourced adversaries. And in the background we will work with vendors to add capabilities such as SMM Dual Monitor mode, which significantly strengthen the trust arguments

Q: The Copernicus release is mostly Windows-centric, but also includes a cross-platform, tool in the release. Will the new LegbaCore github tree include a open source bios_diff project, perhaps to get open source patches for improved BIOS parsing beyond EFIPWN, perhaps like that in UEFITool?
A: While continues to provide the only simple, semantically aware integrity checking capability for BIOS, it has a number of issues. E.g. in the context of our latest work, it simply doesn’t work to integrity check Apple firmware, because Apple firmware update structure does not look the same as the structure on-disk.

Q: Post-October/HITB, what’s the next LegbaCore BIOS/UEFI security training event you’ll be giving?
A: Later in October I’ll be offering a similar training at Ruxcon breakpoint. Beyond that we are fairly busy with private training engagements.

Q: Any hints what kind of new firmware vulnerability research you’re working on, and when we might see some of the results?
A: We are branching out to the security of peripheral devices such as network cards, HDs/SSDs, embedded controllers, GPUs, the Intel Management Engine, etc. We are shooting to have our first talk on one of these topics around December.

Q: Recently Stephan of coreboot mentioned that in the past MITRE said that Chrome OS firmware was more secure than UEFI. Both coreboot+depthcharge’s Verified Boot and UEFI’s Secure Boot both seem pretty similar, in terms of PKI usage. Have you an opinion on the security strength of either of these firmware solutions?
A: We have never evaluated CoreBoot to any level of depth. Hardware-wise, we like the Chromebook requirement to provide physical write protection for the flash chip via a screw. The way that Chromebooks supposedly root their boot trust in the embedded controller hardware, as described to us, sounded like a good idea. But without having actually spent time looking at the platforms, we cannot say much in terms of the security (or lack thereof) relative to UEFI-based systems.

—-[End of interview.]

Thanks Corey and Xeno!

The code was added 5 days ago, and I missed it!

Upcoming training:

Stephan’s comment on coreboot security:

MITRE Copernicus

So far, in this new blog, I’ve been mostly focusing on open source tools and open source operating systems, so I’ve not focused on MITRE’s Windows-centric non-open source tool, Copernicus[1]. But the tool is extremely powerful, and deserves more attention.

“Copernicus is the first tool to provide BIOS configuration management and integrity checking capabilities throughout an enterprise. The tool is implemented as a kernel driver that creates a file containing the BIOS dump and a file containing the raw configuration information. When deployed in enterprise environments, scripts can send the raw BIOS dump and configuration information to a server for post-processing. This processing can indicate whether a given BIOS differs from an expected baseline, and it can also indicate whether the BIOS or the computer’s System Management RAM (where some code loaded by BIOS continues running after boot).”

An excerpt from a G+ post in 2013 from Dragos Ruiu on Copernicus:

“IMHO Copernicus BIOS verification tool, is one of the most important new security tools in recent history. We’ve already found some persistent BIOS malware that survives re-flashing with it.”

I wish it were available for Linux, not just for Windows, so I could use it! And I wish it were open source (alas, all security tools are not): trusting any native kernel driver on your system, or especially to deploy to all systems in you enterprise, whether it is natively installed or from another boot media, has issues. I hope licensees from MITRE have the option to review the code and compile it themselves.

[Intel’s CHIPSEC also has some similar features. When run as an OS-present tool — instead of a live-boot or UEFI Shell booted — CHIPSEC also includes a native driver on Windows, and on Linux. With CHIPSEC, the kernel driver sources are provided.]

If you have Windows-based enterprise, you should investigate out Copernicus.

Windows-centric code aside, Copernicus distribution includes, which works on Linux. This is a wonderful tool[2].

Even if you don’t care about Windows, you should study the Copernicus research, is it amazing.

Two of the creators of Copernicus have left MITRE and have started LegbaCore. Their last talk on using Copernicus at RSA conference last month[3] was excellent, talking about using Copernicus usage in enterprises.

More Information:


Tool mini-review:

I recently became of a tool that I didn’t know worked on Linux:, included with Copernicus. The MITRE Corporation’s Copernicus is a very powerful firmware security tool. I’ve been focusing more on non-Windows tools and open source tools, so I’ve not been giving Copernicus tools enough emphasis, something I’ll correct in future posts. I’ll start with this post, on, which is distributed with Copernicus. This tool is not Copernicus-centric, nor Windows-centric.

If you’ve a dump of a BIOS ROM image, created by CHIPSEC or Copernicus or Coreboot’s FlashROM, you can use to help determine what has changed. The tool parses the EFI Firmware Filesystem, to break out the files. It can also do smart diff’ing based on GUIDs in case files were added/removed, and will provide additional semantically relevant things like the file name, PE sections, and size of differences found (where each is applicable.)

This tool is a very useful addition to your open source firmware security toolbox.

This free tool does have some limits, EFIPWN is not as good as the newer UEFITool w/r/t some parsing. Perhaps someone has time to integrate UEFTool into a newer version of this tool? 🙂

Usage: [-crs] [-i IGNORE] [-d [-a [-p]] [-n [-u UNIQUE]] [-l SIZELIMIT] [-m NUMBYTES]] [-o OUT] [-e EFIPWN] <file1> [<file2>] (-h | –help)

The files are BIOS dumps to be compared.  <file2> may be a single file, or it may be a directory which contains several BIOS dumps against which we will diff <file1>.  Also, <file1> can be a directory by itself.  In this case, the first file found in this directory will be compared against all of the others.

  -c            delete the directories when the diff is complete
  -r            reuse parsed directories previously generated by EFIPWN if they appear to exist
  -s            print out all sha1 hashes of files in BIOS dump
  -i IGNORE     file containing list of regular expressions (one per line) for filenames we should ignore
  -d            do hash diffing of extracted files
  -a            print all unique ranges per file
  -n            print number of unique bytes per file
  -u UNIQUE     exclude diffs which have less than UNIQUE unique bytes for both files
  -l SIZELIMIT  dont compute unique ranges or bytes on files which exceed this size
  -p            print the PE information about diffs if the files are PE files
  -m NUMBYTES   merge regions which are within NUMBYTES of eachother
  -o OUT        output directory [default: temp]
  -e EFIPWN     the location of EFIPWN files [default: EFIPWN]

More information: