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

Monday, December 12, 2016

BIOS Disassembly Ninjutsu Uncovered on Play Store

Somebody has just put BIOS Disassembly Ninjutsu Uncovered "scanlation" on Play Store. Well, it's not really manga "scanlation" quality. But, I'm rather surprised someone put the effort to do that: https://play.google.com/store/apps/details?id=com.appjik.book.bios. You might want to give it a try. 

In my opinion, the PDF version in github is much more readable. Perhaps, I should make it available on Play Store, or is there anyone want to volunteer to do that? Cheers.


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: http://www.xenatera.com/bunnie/proj/anatak/xboxmod.html). IIRC, the was using one of Arium ICE products. Arium was acquired by another company, see: http://www.asset-intertech.com. 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: http://www.loper-os.org/?p=1667. 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 https://en.wikipedia.org/wiki/In-circuit_emulation

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: https://github.com/facebook/openbmc and https://code.facebook.com/posts/1601610310055392/introducing-openbmc-an-open-software-framework-for-next-generation-system-management/. 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 ;-)