Nikolaj’s ZeroNights UEFI video online

The video of Nikolaj Schlej from ZeroNights is now online!

Sources and slides are here:


William Leara reviews UEFI Tool

William Leara, a firmware engineer at Dell, has a new blog post on Nikolaj Schlej’s UEFI Tool. He shows how to use it, starting with using Intel’s Flash Programing Tool (FPT) to acquire a BIOS image. Lots of screenshots of the various menu UI components of this GUI tool.

“It is extremely useful for interrogating and manipulating the components of a UEFI BIOS image.  Download it and give it a test drive today!”

Full post:

UEFITool/UEFIExtract/UEFIFind updated

Nikolaj Schleg has updated UEFI Tool, and UEFI Extract and UEFI Find, with a fe new features and fixes:

*  improved parsing of Intel flash descriptor
* improved detection of Tiano/EFI 1.1 compression type
* added 2 UEFI capsule GUIDs used by Lenovo
* solved potential crash on very low memory available
* UEFIExtract and UEFIFind update to include the latest parser changes

Alpha version of new UEFITool 0.30.0_alpha19 released for early adopters, still no image editing possible in this release.

Fast Boot, instead of UEFI Secure Boot

There may be some situations where Secure Boot is not useful, and Fast Boot is an alternative, which is fast but NOT SECURE. Here’s a quick summary by Nikolaj Schleg (aka CodeRush) of what is needed to disable Secure Boot and enable Fast Boot with use on Windows systems:

The best way to decrease boot time is to switch to UEFI boot, disable CSM, enable FastBoot and disable SecureBoot, because it takes some time to check a signature of your bootloader, and it will be checked on every boot.
If you remove all SecureBoot keys, the SecureBoot will switch into so called “Setup Mode”, where you can add your own keys without having a private parts of older ones (that are only available to Microsoft and ASUS, in your case). AMI-based UEFIs have a “standard” keys in default map, so don’t worry about losing the keys – you can easily restore them from Security->SecureBoot Settings setup page.
What you need to do:
1. Disable CSM.
2. Enable FastBoot.
3. Enable (better protection from bootkits, a bit slower boot time) or disable (a bit faster boot time, the same security level you have now with CSM) SecureBoot.
4. Don’t touch the keys, they are fine by default.
5. Reinstall Windows in UEFI mode.


Full post:

There’s another guide for Windows 8.x here:

More on disabling Secure Boot keys:

More on disabling Secure Boot:

And for a bit of contrasting — yet still informative — advice, here’s how to disable Fast Boot:

Some more on Fast Boot and Windows:

Car hackers take note at the use of Fast Boot (instead of Secure Boot) in Windows Automotive stack, in above MSDN docs. Yikes.


SwiftOnSecurity on Windows/UEFI security

There’s a new guide to securing Windows systems. I enjoyed it because step 2 of the steps are firmware-centric, excerpted below, view the original doc, the excerpted formatting is a bit mangled, sorry.

I wish the advice mentioned using CHIPSEC to do security tests to see if system came from OEM with unfixable security flaws, and to use CHIPSEC or other tools — perhaps via LUV-live or directly — to save  a NIST SP-147-style ‘golden image’ of your ROM, doing periodic offline/forensic examination of your ROM images with CHIPSEC, UEFI Firmware Parser, and other tools. (I have no input as to the non-firmware Windows-centric input in the list.)

1.) Update BIOS
For best compatibility and security you should update your computer’s BIOS. A modern BIOS (really UEFI) is a full operating system that runs below and at the same time as Windows, and it needs patches too. People who built computers in the early 2000’s will tell you BIOS updates are risky, and they were, but not anymore. They deliver fixes, features, and security updates you won’t hear about on the news. Even new computers/motherboards need updates. If you’re starting from scratch, do the BIOS update after installing Windows 10. You can find the BIOS update tool on your manufacturer’s driver page for your computer model. You will need to reboot for it to take effect. If you have a Surface, BIOS updates are delivered through Windows Update.

3.) Configure BIOS
This is important and is something nobody talks about. From the boot of your computer, press the setup hotkey. It may be F1, F2, F8, F10, Del, or something else to get into SETUP mode. In the BIOS: Set a setup password. Make it simple, this is only to prevent malicious modification by someone in front of the computer or by a program trying to corrupt it. Change boot to/prioritize UEFI. Disable everything except UEFI DVD, UEFI HDD, and USB UEFI if you plan on using a USB stick to install Windows. Enable the TPM (if available) and SecureBoot (if available) options. This is super important. Disable 1394 (FireWire) and ExpressCard/PCMCIA (if you’re on a laptop) as a layer to further mitigate DMA attacks. This isn’t as important anymore, but if you don’t use them you might as well turn it off. If you want, and if the computer offers it, you can enable a System and HDD password. We will be using BitLocker to protect the disk, but this is an extra layer you can add if you want. I don’t. If you don’t use webcam or microphone, you may be able to turn them off in the BIOS. Save settings and shut down.

The Linux Foundation has some UEFI-centric, Linux-centric desktop advice, which has some overlaps in security methods to the above UEFI-centric, Windows-centric desktop advice:

The Crypto Party Handbook also has some related advice, for security/privacy-minded use. The Secure Desktop mailing list is the center of the universe for this, where the handful of Linux distributions that focus on secure/privacy as their main features, hang out. If you care about a secure OS, you should be using one of theirs, not an OS where security is not their primary concern.

[I need to find some similar security hardening checklist for ChomeOS-based, coreboot-based systems, instead of Windows-based UEFI/BIOS-based systems,  talking about ensuring TPM on x86/x64, using coreboot with Verified Boot, specifics on how to best adopt those keys, like how Nikolaj shows us how to adopt UEFI Secure Boot keys, and others show how to use MOK. Any tips appreciated, please leave a Comment (see left) or send email (see above right). Thanks.]

screenshot-taking UEFI DXE driver

Nikolaj has written a UEFI DXE driver that takes screenshots. In addition to a useful new UEFI tool (since taking pre-OS screenshots outside of a VMM are often a PITA), the article is a nice introduction to EFI development. Attackers can use techniques like this to capture display activity in the background, just like they do in OS-level malware.

UEFI DXE driver to take screenshots from GOP-compatible graphic console: This DXE driver tries to register keyboard shortcut (LCtrl + LAlt + F12) handler for all text input devices. The handler tries to find a writable FS, enumerates all GOP-capable video devices, takes screenshots from them and saves the result as PNG files on that writable FS. The main goal is to be able to make BIOS Setup screenshots for systems without serial console redirection support, but it can also be used to take screenshot from UEFI shell, UEFI apps and UEFI bootloaders.

See the readme and the blog post (in Russian) for more information:

Nikolaj’s UEFI SecureBoot tutorial

CodeRush has a new tutorial on UEFI SecureBoot:
Taming UEFI SecureBoot tutorial

[…] let’s talk about how to make a UEFI SecureBoot not work for the benefit of Microsoft, as it is often set at default, and for the good of us. If you’re wondering how to generate their own your own keys for SecureBoot how to install them instead of the standard (or with them), you sign your favorite EFI-boot, how to prevent loading of unsigned or signed other people’s key code, it looks like the interface to configure SecureBoot at AMI, Insyde and Phoenix, […]

It is in Russian, use a translation tool if you can’t read Russian (like me). The article has multiple examples and screenshots of multiple UEFI implementations, and includes some UEFI links at the end that I’ve never seen before, exciting!’s/

Nikolaj uploads Zero Nights sources

Nikolaj has updated his Zero Knights presentation, and added sources and other presentation materials on the Github site:


Nikolaj’s ZeroNights presentation available

Congratulations to Nikolaj on his first presentation! His presentation is now available!

The section on Protections is especially worth reading!

SysMagazine: English translations of Nikolaj’s UEFI security series

I just noticed “Sysmagazine geek daily blog: a translation of the popular Russian IT blog,”. So, it contains English translated versions of Nikolaj’s Russian UEFI security series on I’d been using Google Translate, this is slightly easlier to use. Here’s the English version of Nikolaj’s series:

Here’s the original series:

In the last part of the series, he lists various people of interest, but not much about himself.  Nikolaj’s UEFI Tool is consistently at the top of Github’s active list for UEFI. More popular than Intel CHIPSEC, or the TianoCore Git mirrors. UEFItool is also one of the better maintained tools in the field of firmware security, very active at fixes. I’d put him near the top of the list, along with ITL, LegbaCore, and Intel ATR/CHIPSEC team, as a prime source of firmware security knowledge. He’ll be speaking at ZeroNights in Moscow this December on UEFI…

Nikolaj on UEFI Security, part 7!

Nikolaj has written a 7th part to his 6-part series on UEFI security!

It covers AMD security processors, Intel STM, Intel SGX, TPM 2.0, and other current technologies.

There is mention at the end of an upcoming article on taming Secure Boot, generating your own keys, looking forward to that!

UEFItool 0.21.2 released

UT 0.21.2 (18 additions and 8 deletions)
– fixed a bug with tailed files extraction and replacing (#35)
– fixed a bug with wrong source of padding after all Intel image regions (#34)

Nikolaj on UEFI security, part 5

Nikolaj’s part 5 of his series on UEFI security. Google Translation of first paragraph:

On safety UEFI, Part Five

After a short break, we continue to talk about the safety of UEFI. This time we will focus on technology SecureBoot, its pros and cons, about the attacks on her and protect them. For the first time we are talking about SecureBoot standard UEFI 2.2 in 2011, but finally all the aspects have been implemented in version 2.3.1C in early 2012. The main developer of the technology has been Microsoft, which once said that to obtain a certificate of Windows 8 Ready for his not yet released the new operating system requires the implementation and integration SecureBoot by default on all new PCs. This announcement sparked a wave of sharp criticism from the supporters of the free software, which is successfully sunk, and until Habra. If you’re wondering what exactly ended confrontation MS and the community as SecureBoot looks after almost 4 years of growing up, and the attacks on him are still possible – welcome under the cut.


Nikolaj Schlej series on UEFI security!

Nikolaj Schlej, of UEFITool fame, has a series of articles on UEFI security; so far there are 4 parts to this series. It is written in Russian. If you can’t use translation tools effectively — like me — this series is a good time to start to learn. Here’s the excerpted output of Google Translate of the first paragraph of part 1:

In this article, we will focus on models of threats and attack vectors on UEFI, as well as protection against overwriting the contents of the chip BIOS – the most devastating of the possible consequences of an attack. If you are curious about how to protect UEFI and which vulnerabilities in it and remain uncorrected in most modern systems – welcome under the cut.

part 1:

part 2:

part 3:

part 4:

UEFITool 0.21.0 released

Nikolaj Schlej has released  UEFITool v0.21.0.

Features improved Skylake support, among other things:
– added support for new Intel descriptor type, based on [this](;a=commit;h=1f7fd720c81755144423f2d4062c39cc651adc0a) coreboot commit, thanks to lordkag for issue #32
– solved a bug with incorrect volume free space item placement during volume replace, now works as expected
– solved an issue with incorrect Aptio capsule parsing introduced in 0.20.8

UEFITool 0.20.8 released

Nikolaj Schlej has released a new version of UEFITool:

159 additions and 61 deletions:

– data after the latest region of Intel image is in tree now
– added Intel, Lenovo and Toshiba-specific capsule GUIDs to the list of known GUIDs
– fixed bogus “File with invalid size” message while working on almost full volumes
– pressing Cancel on “Open in new window” dialog now works as expected

Nikolaj Schlej to speak on UEFI at ZeroNights

Nikolaj Schlej, firmware security researcher and creator of UEFITool, will be speaking at ZeroNights 2015 in November 25-26 in Moscow, Russia, his first security conference presentation! His presentation is called “UEFI: Fix it yourself”, and he’s one of a handful of people that can accomplish that. 🙂