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

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.

Sunday, July 12, 2015

The State of My Firmware Research

Well, I decided to post this because I've been over-promising and under-delivering for several years now.

Straight to the matter, I've been leaving my firmware research work in a state of hibernation for almost a year now due to a (some?)  product development work I'm still working on as of now (which I cannot elaborate further). It's not that I feel firmware is not interesting anymore. On the contrary, I feel it's far more interesting now than it used to be due to the raise of connected embedded systems (now re-badged as Internet of Things a.k.a "rather intelligent" data collection systems). The main problem for me is finding time to work on this research again as it's unfortunately not my day job.

As for my work on the continuation of my BIOS Disassembly book project. I will try to find time for that, but I don't want to over-promise on it. Hopefully this clears things up. 

Monday, March 2, 2015

Remote Access in Legacy BIOS

In this post I'm going to talk about Remote Access in Legacy BIOS via serial console. I aware some (or most) of you are aware that BIOS has provided management console via serial port for a long time. I have the opportunity to modify a customer custom Geode board BIOS to add support for Serial Console a few years ago. It's a quite nifty but rather buggy implementation though (I meant the serial console module). This one is from AMIBIOS Core8. This is the screen shot from minicom in Arch Linux.

As you can see, the terminal looks like how you would expect it when accessed via real keyboard. Unfortunately, some function keys are not working as expected. You can configure the serial port just like you'd expect on old BIOS with serial port support, i.e. the BAUD rate, flow control, bit-ness (8-bit), etc.. The Remote Access menu in the picture is where one would configure the serial port setting for the remote access (serial console).

I'm "dusting-off" this old board from storage because it's quite a nice board to tinker with. I almost forgot that it has remote BIOS access feature back then. Basically, it works like Linux serial terminal in most embedded Linux boards out there. But, this one is limited. I think many enterprise-class motherboard has this feature back in the day and also today because it's a very crucial feature for remote manageability especially if you have thousands of machine to work with. Keep watching this one guys ;-). It's gonna be interesting..

Saturday, July 12, 2014

How Boot Firmware Development and Driver Development Differs--PCI Bus Implementation Case Study

This post is not BIOS/UEFI specific per-se. However, it has a very close relation to it because it delves deep into Windows device driver architecture.

Most of BIOS/UEFI modules are aware of the CPU architecture, motherboard chipset and all supporting logic in which it runs. However, the same assumption cannot be made for an OS, such as Windows. Therefore, BIOS/UEFI modules mostly can take for granted the CPU and bus architecture in which it will run. The same is not true for a device driver. For example, a PCI or PCIe explansion card can be used in the same operating system but runs on entirely different CPU architecture. This means device driver creator couldn't and shouldn't assume the CPU architecture and bus architecture in which it will eventually run.

This series of posts by Windows PnP subsystem developer is very enlightening in this respect:
http://blogs.msdn.com/b/doronh/archive/2010/05/05/arbitration-and-translation-part-1.aspx
http://blogs.msdn.com/b/doronh/archive/2010/05/06/translation-and-windows.aspx
http://blogs.msdn.com/b/doronh/archive/2010/05/06/arbitration-and-translation-part-3.aspx

This hopefully shed some light in system software developments :)