The BIOS Blog

Welcome to the dark corner of BIOS reverse engineering, code injection and various modification techniques only deemed by those immensely curious about BIOS

Thursday, September 22, 2016

Down to Silicon Level Debugging

First off, I'm not a "forward" BIOS/UEFI engineer. At least not one who worked officially in a BIOS/UEFI software development company or motherboard company. I did got an official access to AMIBIOS Core8 source code and tools back then under NDA for one of my clients to customize it for a custom x86 motherboard. But, that's as far as I got into the game. This is relevant to this post as I don't know exactly the process of silicon level firmware development validation. The farthest I went was a sort of "Serial ICE" with Coreboot and also debugging via Power-On Self Test (POST) code passed over serial port in AMIBIOS Core8. That was it. I didn't even manage to do debugging via PCI POST card, but I presume it would be similar to its "redirected" cousin in the serial port. There is another way to do firmware debugging, via JTAG pins, and by using In-Circuit Emulator (ICE). Despite having been an Electrical Engineering student, I'm not yet familiar with those territories. But, AFAIK both are as good as if not more powerful firmware debugging technique compared to using Serial ICE or POST card.

Let's focus on the ICE part. There was at least one mistake I did in my BIOS book that I didn't realize due to my handicap in not having an ICE and its related skills. You can see it in the quoted errata below (it's also in the addendum part of my book over at github):

The address aliasing mentioned in Chapter 4 section 4.1.1 page 4 (the paging messed-up in the PDF) should cover both E-segment and F-Segment (E_0000h-F_FFFFh), not just the last 64-KB segment. Somebody used a sort of CPU logic analyzer to confirm this fact.
The guy who tipped me over about this was using an expensive ICE to validate the fact above. I'm not exactly sure how he tapped all of the "wires" on the chipsets and the CPU itself, but very probably similar in principle to what "Bunnie" did to the first XBox version (see: IIRC, the was using one of Arium ICE products. Arium was acquired by another company, see: However, their ICE products live on as (very probably) the ScanWorks and SourcePoint line of products from asset-intertech. These ICE products used to cost north of $20k a piece back then. I don't know about it at the moment though. With an ICE, you essentially put the CPU in a "hard" debug mode, where you can freeze it in a way ordinary debugger cannot because there is no OS or firmware required for that to happen.

Anyway, I was quite surprised to find a "low cost" version of this kind of ICE over at: Well, I'd like to thank to whoever posted a comment about this ICE in my previous post. It's very interesting nonetheless ;-).

Anyway, for the uninitiated, a (not so) useful background is at

Wednesday, August 31, 2016

Base-board Management Controller (BMC) Firmware Security

The security of the BMC firmware is very important, as compromising it means unfettered remote access to the target machine. There has been research into this area in the not too distant past:
All of them are interesting in their own right. Perhaps, Bonkoski's one is the most comprehensive? I don't know. I haven't dig into all of the papers myself.

Anyway, one of the most interesting development in BMC is OpenBMC, see: and Is it going to grant you access to Facebook-class infrastructure (from afar) if you find a flaw in it? Well, I don't think so, as it must've been protected by giant "firewall" in front of it. But, doing a code review on OpenBMC for flaws certainly a good exercise.

As a side note, let's not forget about Fujitsu, one of the most "underrated" server producer on the market. As a parting gift, let's look at what Fujitsu has in store in its BMC:

Fujitsu integrated Remote Management Controller TCP/UDP ports

Thursday, August 18, 2016

Firmware/BIOS-related Patent Filings

I don't know if security researchers are used to looking at patent filings--because I'm not officially one of them. However, I found that reading and trying to understand firmware/BIOS-related patent filings is enlightening. It is also interesting because the filings are related to each other via cross-referencing, which make the activity all the more interesting, given enough time to dig into it. Among other thing, it provides a view ahead in this cat and mouse game of protecting and breaking firmware. These are some of my picks (not necessarily new ones):
The one that interest me the most is the last one because it's a sort of insight into Baseboard Management Controller (BMC) stuff. I hope you enjoy the patent filings as much as I do ;-)

Saturday, July 23, 2016

UEFI Boot from Web

I think I've been living under a rock in these last few months and not exactly following UEFI development. Nonetheless, I managed to spot this stuff over at What's interesting is the SDK supports "Firmware Boot from Web" so to speak. This is the relevant excerpt:
The Intel® Server Board S1200RP UEFI Development Kit supports Pre-Execution Environment (PXE) boot for IPV4 and IPV6 networking using on-board and add-in networking devices. Because of added initialization time, network boot for the four onboard networking devices is disabled by default in firmware setup. Users can enable PXE boot for on-board networking by enabling the ’EFI Network’ setting in the firmware setup menu.
EDKII Menu -> Advanced -> Network Configuration
As of SDV.RP.B6, the Intel® Server Board S1200RP UEFI Development Kit supports UEFI HTTP and HTTPS boot. These features are described in whitepapers located on the Tianocore github wiki:
Well, it could be double-edged sword from security standpoint. It depends on who you ask and what it's being used for.

Anyway, this is my take on this:

  • My "educated" guess is: This stuff emerge from Intel collaboration with the so-called Hyperscalers--Hyperscalers is what some people call them ( The Hyperscalers (Google, Facebook, Amazon, Azure, Alibaba, Baidu, Tencent) are running lots of web servers. Therefore, it makes sense for them to make it possible for their machines to boot just off of the webservers instead of preparing another "PXE Boot server" due to the prevalent web server in their bit barns. I think that Intel wants to trickle-down the same stuff into the masses, but as the first step, the Enterprise sector is what Intel targets.
  • Present day flash (is it still Flash??) memory used for firmware storage is spacious enough to cram a (compressed?) HTTP/HTTPS client into it. It would hardly possible to do that just several years ago due to the space constraint in the firmware chip on the motherboard. I didn't say this is impossible years ago because I have worked with extremely limited firmware space in non-PC platform that somehow managed to cram HTTP server into space less than 1MB, along with hardware configuration software stuff. 
  • This made it possible to boot from the cloud if anyone wants to implement such a stuff. But, it would entails a huge security "nightmare" if you ask me.