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

Sunday, October 27, 2013

Intel 8-series Chipset SPI - The new standard for x64 platform firmware storage?

I've just skimmed over the SPI section in the Intel 8-series chipset datasheet. One interesting thing to note is the flash memory organization has been regulated closely. If you recall from the legacy BIOS days, the flash memory used to store the BIOS code is just a plain block of writable bytes. This has changed in the SPI flash memory "regulation" because now we have SPI flash memory that must be divided into several sections based on the SPI flash requirements of the Intel 8-series chipset. I'll get into the details in the near future, but for now, it's enough to know that things have changed in quite a fundamental way :)

Monday, September 16, 2013

System Address Map Initialization in x86/x64 Architecture Part 1 - Article

New article explaining details of PCI-based system address map initialization is up: http://resources.infosecinstitute.com/system-address-map-initialization-in-x86x64-architecture-part-1-pci-based-systems/. This is part one of two articles. I started with PCI because the basic knowledge on the bus protocol is essential before moving to part two which covers present day PCIe systems.

Tuesday, August 27, 2013

AMBA-PCIe Interoperability

The native bus in ARM systems, Advanced Microcontroller Bus Architecture (AMBA)
[see: http://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture] has been interoperable with
PCI Express (PCIe) for several years now. These are related documentation that helps understanding
how it works:
1. Designing an AMBA-based SoC with a PCI Express Interface,
   link: http://www.pcisig.com/developers/main/training_materials/get_document?doc_id=fcb3ebb3b4537c401230b3f3cd71e7895b7c5518

2. Building a Bridge from PCI Express to AMBA 3 AXI On-Chip Bus,
   link: http://www.synopsys.com/dw/dwtb.php?a=pcie_tb_axi
3. This one is even more interesting: Implementing a PCI-Express AMBA interface controller on a Spartan6 FPGA,   link: http://publications.lib.chalmers.se/records/fulltext/176608/176608.pdf
This shows how far the layered design of PCIe could interoperate with AMBA bus from ARM.

Thursday, August 8, 2013

UEFI replacement for BIOS Int 15h AX=E820h Interface

Those who play with low level code are familiar with the BIOS Int 15h AX=E820h interface to query memory map of the system (x86/x64). In fact, it's probably the safest way to do that.

In EFI/UEFI, the interface is replaced by a new function call interface. The function name is GetMemoryMap() and it's part of EFI/UEFI boot services. The definition of this function as follows:
GetMemoryMap (
    IN OUT UINTN *MemoryMapSize,
    OUT UINTN *MapKey,
    OUT UINTN *DescriptorSize,
    OUT UINT32 *DescriptorVersion
The meaning of the parameters as follows:
  • MemoryMapSize; A pointer to the size, in bytes, of the MemoryMap buffer. On input, this is the size of the buffer allocated by the caller. On output, it is the size of the buffer returned by the firmware if the buffer was large enough, or the size of the buffer needed to contain the map if the buffer was too small.
  • MemoryMap; A pointer to the buffer in which firmware places the current memory map. The map is an array of EFI_MEMORY_DESCRIPTORs.
  • MapKey; A pointer to the location in which firmware returns the key for the current memory map.
  • DescriptorSize; A pointer to the location in which firmware returns the size, in bytes, of an individual EFI_MEMORY_DESCRIPTOR.
  • DescriptorVersion; A pointer to the location in which firmware returns the version number associated with the EFI_MEMORY_DESCRIPTOR. See “Related Definitions.”
The definition of the EFI_MEMORY_DESCRIPTOR structure as follows:
typedef struct {
    UINT32 Type;
    UINT64 NumberOfPages;
    UINT64 Attribute;
The description above is based on UEFI Spec. v2.3.1 Errata C.

Wednesday, July 17, 2013


Long time no posting here :-(.

We've got new stuff to look over now: AMI Mega RAC XMS.
This thing is an out-of-band communication "suite" by AMI. Here's the feature article:
continued at: http://www.datacenter-insider.de/themenbereiche/management-planung/system-management/articles/409996/index2.html

Monday, May 20, 2013

BIOS "Chronomancy" Paper

This paper is very interesting: http://www.nosuchcon.com/talks/D2_01_Butterworth_BIOS_Chronomancy.pdf
It researched what to do if you don't trust the BIOS/UEFI ROM contents even in the presence of TPM.

Monday, April 22, 2013

x86/x64 CMOV Instruction vs ARM Conditional Instruction Execution

If you've been programming in x86/x64 assembler for a while now, you'll know the CMOV (Conditional Move) instruction. This instruction was introduced in P6 (Pentium Pro) for compiler optimization.

It seems that the conditional instruction execution in ARM (32-bit only?) predates the P6 CMOV instruction debut. Conditional instruction execution of course speeds up comparison statements in many occasions in our code. 

Now, did Intel "copied" the technique from the RISC world and applied it to x86 back then? 
IIRC, P6 (Pentium Pro) was the first Out-Of-Order CPU core from Intel. I recall that this architecture was more RISC-like on the inside.

Tuesday, March 26, 2013

(First-Party) DMA Malware Paper

This paper is really interesting: http://www.stewin.org/papers/dimvap15-stewin.pdf
Abstract (excerpt): ... Modern computers contain dedicated hardware such as network and graphics cards. Such devices implement independent execution environments but have direct memory access (DMA) to the host runtime memory. In this work we introduce DMA malware, i. e., malware executed on dedicated hardware to launch stealthy attacks against the host using DMA. DMA malware goes beyond the capability to control DMA hardware.

We implemented DAGGER, a keylogger that attacks Linux and Windows platforms. Our evaluation conrms that DMA malware can efficiently attack kernel structures even if memory address randomization is in place. DMA malware is stealthy to a point where the host cannot detect its presence. We evaluate and discuss possible countermeasures and the (in)effectiveness of hardware extensions such as input/output memory management units (IOMMU).

For me, the very interesting finding on the paper is the presence of ARCtangent Microcontroller which (acts as the DMA "engine". The vendor of this "vague" MCU is quite hard to come by on G$$gle search. It turns out that ARC International is a subsidiary of Synopsys now. These are the relevant links:


http://www.synopsys.com/dw/ipdir.php?ds=arc_mpu (I think the paper probably talks about this chip)


PS: "First Party" DMA is also known as Bus Mastering

Friday, March 22, 2013

DOS Protected Mode Interface (DPMI)

DPMI is outdated by today's standard of course. However, in certain situation it comes handy. I've been looking for documents/standards/specifications from my early days of BIOS reversing that could explain most of the 32-bit code I'd seen on the BIOS.

One of the most intriguing terms were the memory related terms, e.g. high memory, upper memory, etc. I came to think that there were no standard(s) at all which govern the use of the term. However, upon reading the DPMI specification, I finally realize that the "gaps" (in my knowledge) between the 16-bit code and 32-bit code on the BIOS are covered by the DPMI specification. Well, not all of them of course because there are still the voodoo mode. But, nonetheless, a large fraction of the missing link is in the DPMI.

For those interested on the spec. This is the link: http://homer.rice.edu/~sandmann/cwsdpmi/dpmispec1.pdf.

Have a nice weekend :-)

Sunday, February 17, 2013

Thoughts on Memory Allocation in Firmware (Particularly BIOS/UEFI related)

Memory allocation in firmware is basically not the same as one we would find on applications running in an OS because it's an "OS-free" environment. Therefore, the the benefits of OS protection for "memory allocation gone wild" is virtually non-existent. This puts codes running as part of the firmware execution at more risk compared to code running inside an OS. I have yet to put more scrutiny on the TianoCore (UEFI) implementation for memory allocation functions. Probably, it's much better than those in legacy BIOS modules or other related firmware predating it.

I have particular notes on routines akin to C language malloc(), free() and circular buffer handling functions. Calls to malloc() function in firmware level code is usually quite safe because several malloc()  implementations that I read, implements a sort of rudimentary exception handling which would bail out one module execution if not enough space is found when code in the "requesting" module asks for heap memory. However, there are still lingering possible of error when the module lost a reference to allocated memory due to pointer reassignment. I have yet to see bad behaving code like this. But it seems, the assumption on the malloc() implementation is that these things never happened!

As for circular buffers, this kind of thing is in use mostly to talk to storage devices and other "block" devices which transfers quite large amount of bytes in "block"s. Circular buffer implementations could use contiguous memory space if the code that initialize it found one such an available area. However, it could also be implemented as circular linked-list of fragmented chunks which are not necessarily adjacent in the physical memory. This is where things get interesting. A logic bug in function calling the one of the circular buffer function could result to access in the wrong physical memory address. That could happen if a calling function assumes that the circular buffer is implemented as contiguous physical memory chunks instead of a linked memory chunks (not necessarily contiguous in physical memory addresses). In this case, the developer who code the function calling the circular buffer implementation should be blamed as he/she didn't foresee an impending chaos he/she created. Unfortunately, I have yet to see "exception handling" on firmware-level code dealing with such things.

Friday, February 8, 2013

Reversing Applications Running on DOS Extender

Some BIOS/Firmware-related utilities are running in DOS "extender" mode, i.e. 32-bit Flat Protected mode. Reversing this kind of executable is not quite as straight forward as other DOS programs. Some of them "bind" the DOS "extender" binary with the core application executable into one "integrated" executable. A further optimization that you might find is executable compression before "bind"ing the executable to the DOS "extender". How would you deal with this kind of binary? Well, to be honest. It's not quite easy, but I found these steps help:

  1. Unbind the DOS "extender" from the "integrated" executable. For this, you can use the SUNSYS Bind Utility which is part of the DOS32A DOS extender. It's freely available at http://dos32a.narechk.net/index_en.html. Using the SUNSYS Bind utility, you can obtain the real executable. Usually in the form of LE executable. 
  2. (This step is optional, depending on the condition of the "unbound" executable). If the LE executable is compressed with UPX, you can use the UPX utility to decompress the executable to obtain the real executable. The UPX utility supports decompressing executables packed with UPX, with the -d command.
After the step(s) above, everything is business as usual for the reversing ;-). This trick is probably handy in some situations. Anyway, if you need to boot to DOS to run DOS32A utility, you can use an empty flashdisk and boot to DOS (or Windows 98) from it. The HP USB Disk Storage Format Tool is handy on this situation.

Friday, January 25, 2013

Gizmo Board (AMD G-series APU)

Has anyone play with this thing: http://www.gizmosphere.org/why-gizmo/ ? It's very interesting because it uses Coreboot out of the box instead of Legacy-BIOS/UEFI. Well, I'm not sure whether it's possible to use UEFI as it's payload or not (Coreboot support UEFI as its payload).

But from embedded development point of view, just boot straight to Linux from Coreboot ;-). Linux drivers will take care of the rest of system initialization. The interesting thing is, the kit also provides an "explansion" board to tap into the I/O of the x64 system (the AMD G-Series APU), well, I exagerrated a bit, I meant you could hook directly to the I/O which very probably connects to the "southbridge" of the entire system.

Anyway, from pure raw performance point-of-view, this is a real raw power  monster to play with. But, I'm not sure how it compares to BeagleBoard when playing with signal processing. But surely for computer vision stuff, it's certainly very powerful given that OpenCV is tuned for x86 (x64?) architecture by default.

I think it's also an interesting platform to play with Coreboot and to understand the inner working of modern day x86/x64 processor.

Thursday, January 10, 2013

UEFI EDK II on ARM (BeagleBoard) and My Next Article

I haven't been checking out TianoCore for a while and when I did, I stumbled upon this: http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=BeagleBoardPkg. It's an interesting proposition for UEFI-on-ARM research and the likes. 

As for the next article, I'm still looking for a suitable EFI Option ROM to work with. My previous candidates didn't live-up to expectation as they were quite unworkable given the free time I have to work on the article. 

Stay tuned.