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 ;-)

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 https://firmware.intel.com/develop/server-development-kit. 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: https://github.com/tianocore/tianocore.github.io/wiki/EDK%20II%20White%20papers.
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 (http://www.nextplatform.com/category/hyperscale/). 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.

Thursday, May 26, 2016

BIOS Disassembly Ninjutsu PDF Moved to GitHub

The primary download site for BIOS Disassembly Ninjutsu PDF (free) is now moved to https://github.com/pinczakko/BIOS-Disassembly-Ninjutsu-Uncovered  (direct download at https://github.com/pinczakko/BIOS-Disassembly-Ninjutsu-Uncovered/archive/master.zip). The previous download at 4shared is a malware-invested place, thus the change.

The addendum to the book is also included in the GitHub repository.

Monday, April 18, 2016

Moving Winflashrom code to Github

I ported Coreboot (formerly LinuxBIOS) flashrom utility to Windows a long time ago as my activity in Google Summer of Code and named it winflashrom. Because code.google.com will be shutdown this year, I moved the code to github: https://github.com/pinczakko/winflashrom.

This is old news because the code haven't been updated for years. However, it might still relevant for those who want to port flashrom or other similar utility to present day Windows. I haven't developed Windows driver anymore since Windows Server 2003. I'm not even sure if WDM-style driver is still in use in Windows. But, I might be returning to develop Windows driver this year. So, yeah, you (and I) never know.

Friday, January 1, 2016

Looking into The State of Firmware Security in Russia

I think every major industrialized country has its own policies in preventing malicious IT equipment and products to enter their premises, let alone being used within the country. In this post, we will look into one of Russian computer hardware maker, Kraftway (http://www.kraftway.ru/en/). This company might be a bit obscure to you. But, I think it serves quite a big chunk of the Russian and possibly CIS market. It was even visited by Dmitry Medvedev when he was still President.
This company is interesting for two things:
  • It is not just a "box" mover. It tailors the machines it made to meet the customer requirements. Among its in-house expertise is custom firmware, including UEFI firmware. If you look at this page: http://www.kraftway.ru/en/products-and-solutions/, at the end of it, you can see that it has in-house expertise to work on UEFI security modules and Trusted BIOS (whatever that might imply). Another thing that catches my attention is this: 
In 2010 the company signed an agreement with a telecom giant Cisco establishing a special procedure for the certification of Cisco products in Obninsk manufacturing facilities. Kraftway ensures that Cisco products comply with the requirement of the Federal Technical and Export Control Service on information security. Such certified products can be used in systems processing sensitive or confidential information. In 2012 Kraftway launched the production of Fujitsu PCs with a trusted BIOS and all-in-one PCs based on the Russian processor Elbrus.
I'm not so sure what does the statement meant by "requirements". Perhaps, it includes firmware-level compliance of some sort. You can look at the whole thing over here
  • The second thing is Kraftway also made PC based on the Russian homegrown Elbrus CPU (http://www.kraftway.ru/en/about/milestones/). Of course, in the process, it creates the firmware alongside experts from MCST. The premise for using Elbrus CPU is national security needs and "sensitive" computing needs. So, it's understandable. 
Well, I recall that Dell also did the very same thing as Kraftway with respect to firmware and hardware customization. Dell puts crypto-stuff in the firmware even before UEFI hits the market for some of its server product. Perhaps, that's not meant to be used by the masses, only certain customers.

Anyway, scrutinizing the firmware code or creating a custom ones is highly logical for "sensitive" (high-security) computing gear. Every major developed country do that. IIRC, Germany has its own Coreboot Laptop for that kind of purpose. Even China and Taiwan is doing that as well, albeit I haven't yet found writings on that.