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

Saturday, December 12, 2009

BIOS Disassembly Ninjutsu Uncovered 2nd Edition is in the works!

I've just signed up with No Starch Press. And after discussing the last state of the original book, I decided to just go ahead and make a new edition because I considered the coverage in todays bus protocol implementation in the original book lacking so much. I will try to give enough coverage on HyperTransport and PCI Express. QPI will have a section devoted for it but probably not too deep because I don't have its in-depth technical documentation at the moment. Probably the coverage on UEFI/TianoCore won't be sufficient in the new edition due to lack of time to explore the subject. The current schedule is very tight. I planned to switch the discussion in BIOS reversing more toward AMIBIOS because it has been more widespread recently. Of course Award BIOS will have its place as well. If you have any ideas, please drop it in the comment section. I'd like to hear about it.

Monday, December 7, 2009

Running Hexworkshop with Wine

Another indispensable BIOS modification tool is Hexworkshop. Well, there are lots of binary file editor in Linux but none of them lives up to Hexworkshop feature sets and ease of use yet (at least based on my experience).  

Fortunately, it works just fine under wine albeit sometimes with noticeable--but not distracting--slowdowns. Here is the screenshot of Hexworkshop 

Anyway, the difference between the AMI BIOS tools and Hexworkshop, lies in their installation method. You have to "install" Hexworkshop to wine (by using the winefile utility or other similar means) prior to using it, while AMI BIOS tools are just fine to invoke directly from the shell, such as:

pinczakko@opusera:~/work_in_progress$ wine AMIBCP_V3.37.exe
That's it. Now, I can mess with AMI BIOS file in Linux.

AMI BIOS Modification in Linux

Since I have a rather weird 3G modem that doesn't work correctly in Windows, I have to use Linux (x86_64) to get online. This is a drawback when I want to do some BIOS modification, until just now. I experimented with Windows AMI BIOS tools recently in my Slamd64 Linux installation with wine. The result is promising. The BIOS binary produced by the AMI BIOS tools runs just fine, equal to modifying the BIOS in Windows. Well, there is some warning of unimplemented filename related API when I run MMTOOL but overall, it works just fine.

Below is AMIBCP screenshot running under wine in Linux

Below is the screenshot of MMTOOL running under wine in Linux

Perhaps, you noticed the weird font rendering. Well, I can't get the font right yet on applications running under wine in my system.

So, now I can do BIOS modification in Linux (at least AMIBIOS) without having to resort to the "painful" Windows installation in my machine. 

Sunday, November 22, 2009

TianoCore, UEFI and Coreboot

After a short glimpse over several mainstream BIOS binaries from several different motherboards, I came to conclusion that the move to UEFI is basically a slow incremental process. I think that most mainstream BIOS binaries at least still have the "compatibility mode code", which is a code path to "legacy BIOS" code, i.e. the BIOS code used in say Award 6.00PG or early AMIBIOS 8 base code. On the other hand TianoCore has not been much adopted outside of Intel. It's because some (if not most) relevant industry players view it as moving too fast and doesn't have stable code base. I don't think it has a stable "API" yet for others to "hook" their specific functions into it. Coreboot is in an entirely different league. I love the structure of Coreboot, only 16 machine code instructions prior to flat Protected Mode. This explains its fast boot time compared to the competition. However, for the time being Coreboot is geared more toward computing clusters and embedded industrial boards. I haven't dig too deep into Coreboot for a better judgement. More on it later.

Wednesday, November 4, 2009

AMI BIOS Reverse Engineering Article

My AMI BIOS Reverse Engineering article is available online now: http://sites.google.com/site/pinczakko/pinczakko-s-guide-to-ami-bios-reverse-engineering-1 Might want to read it Anyway, it's much more condensed than the Award BIOS RE article. Well, this is part of my English edition book. I decided to release it because the NDA has been lifted. Note: Some of today's AMI BIOS binary used segment 4000h instead of 2771h for the "POST entry point" in the system BIOS even though all of them use the same AMIBIOS8 code base. The BIOS dissected in my article dates back to circa 2005, some changes happened since then.

Thursday, September 24, 2009

Pinczakko Official Website relocation to Google Sites Completed

Finally, I have finished moving all of the BIOS related articles which were written in English to the new site: http://sites.google.com/site/pinczakko. This is to anticipate the closing down of Geocities next month. Now, you can read the BIOS articles in the new site, including the venerable Award BIOS Reverse Engineering article. Cheers :D

Friday, August 7, 2009

Pinczakko Official Website in Geocities will be moved to Google sites

I'm in the process of moving all of the contents in my geocities website to http://sites.google.com/site/pinczakko/. It's a work in progress and hopefully completed in the end of September this year. About a month away from the goecities closing date. The website has been a corner stone of my work since 2002 and it's a very memorable learning path for me. Below is the screenshot of the opening page which will reminds where everything starts BIOS-wise My priority in the "reorganization" plan is the much read "Pinczakko's Guide to Award BIOS reverse engineering" article. Many people will recognize the title of the article as a "makeover" of the "Hitchhiker's Guide to The Galaxy" book. Yes, indeed. I haven't read the book in it's entirety but its title inspires me somehow ;-).

Tuesday, June 30, 2009

BIOS Disassembly Ninjutsu English Edition Status Update

After much waiting finally I received the contract termination document for the English edition of BIOS Disassembly Ninjutsu Uncovered. I plan to print the book in Indonesia and make it available again for those interested. The book will differ a bit from the book published by A-List in which it will contain a tad more materials because the original (unedited) manuscript actually a bit more than 450 pages ,i.e. 579 pages to be exact but it has to be cut-down to 450 pages due to the contract terms. However, the Russian version of the book is based on the complete manuscript and doesn't contain such a restriction.

All in all, I will announce when the book is ready to be sold and where it will be sold and how to purchase one, considering that I live in Indonesia. If anyone has idea how I can make it available, don't hesitate to give your comments. I'd love to hear it.


I'm currently in talks with NoStarch Press to re-publish the book, very probably with some content revisions and updates. Stay tuned.

Monday, June 8, 2009

Pinczakko Guide to Award BIOS Reverse Engineering

0. Side Note

It's very time consuming to relocate this article from the old Geocities website to this blog. Therefore, I opted to relocate it to Google sites. You can read it at: http://sites.google.com/site/pinczakko/pinczakko-s-guide-to-award-bios-reverse-engineering

This blog post is a work in progress. This reminder will be removed once this lengthy detailed post is completed.

A more detailed tutorial on BIOS Reverse engineering is in my book. The book is not just a compilation of the articles I wrote in this blog and the old Geocities website. It's much more than that and it has a fundamental explanation on issues regarding the BIOS security aspect and analysis. I regard it more like a "log-book" about the work that I've done through the last couple of years in BIOS subject, including undisclosed research results. It provides a thorough tutorial on Award BIOS version 6.00PG reverse engineering as well as AMI BIOS version 8 reverse engineering. Moreover, the basics and fundamental concepts is explained in detail in the first part of the book. Therefore, newbies will find it very helpful. Here it is (at the moment, the book is out of print):

my book cover

It takes quite a lot of effort to finish this book due to the excessive amount of material I wrote in it. Nonetheless, this is just the starting point. I plan to update the book some time in the future. The TIANO Core/UEFI has been gaining momentum recently and also the advances in LinuxBIOS are not minor either. These advances should take the BIOS technology one step above the ladder.

1. Foreword

I would like to welcome you to the darkside of a working example of spaghetty code, The Award BIOS. This article is not an official guide to award bios reverse engineering nor it's compiled by an Award Corp. insider. I'm just an ordinary curious person who really attracted to know how my computer BIOS works. I made this article available to the public to share my findings and looking for feedback from others since I'm sure I've made some "obscure mistakes" that I didn't realize during my reverse engineering process. There are several possibilities that make you reading this article now, perhaps you are an old-time BIOS hacker, perhaps you are a kind of person who really love "system programming" like me or you are just a curious person who like to tinker. One thing for sure, you'll get most of out of this article if you've done some BIOS hacking before and looking forward to improve your skill. However, I've made a prerequisite section below to ensure you've armed yourself with knowledge needed to get most out of this article.

You may be asking, why would anyone need this guide ? indeed, you need this guide if you found yourself cannot figure out how award BIOS code works. In my experience, unless you are disassembling a working BIOS binary, you won't be able to comprehend it. Also, you have to have the majority (if not all) of your mainboard chips datasheets. The most important one is the chipset datasheet.

The purpose of this article is to clean up the mess and positioned as a handy reference for myself and the reader as we are going through the BIOS disassembling session. I'm not held responsible about the correctness of any explanation in this article, you have to cross-check what I wrote here and what you have in your hand. Note that what I explain here based on 2Mbit(256KB) award bios version 4.51PGNM which I have. You can check it against award bios version 6.0PG or 6.0 to see if it's still valid. I'll working on that version when I have enough time. As an addition, I suggest you to read this article throughly from beginning to end to get most out of it.

[+/-] details

2. Prerequisite

First, I would like to thank to the readers of the earlier "beta-version" of this article, from whom I consider that this part of the article should be included.

I have to admit that BIOS is somehow a state of the art code that requires lots of low level x86 knowledge that only matter to such a small audience such as operating system developer, BIOS developer, driver writer, possibly exploit and virus writer (yes exploit and virus writer! coz they are curious people). Due to this fact, there are couple of things that I won't explain here and it's your homework that you should do to comprehend this guide. They are :

  • The most important thing is you have to be able to program and understand x86 assembly language. If you don't know it, then you'd better start learning it. I'm using masm syntax throughout this article.
  • Protected mode programming. You have to learn how to switch the x86 machine from real mode to protected mode. This means you need to learn a preliminary x86 protected mode OS development. I've done it in the past, that's why I know it pretty good. You can go to www.osdever.net and other x86 operating system developer site to get some tutorials to make yourself comfortable. The most important thing to master is how the protected mode data structures work. I mean how Global Descriptor Table (GDT), Interrupt Descriptor Table (IDT), also x86 control and segment registers work. BIOS, particularly award BIOS uses them to perform its "magic" as later explained in this article.
  • What x86 "Unreal-Mode" is. Some people also call these mode of operation "Voodoo-mode" or "Flat real-mode ". It's an x86 state that's between real-mode and protected-mode. This is partially explained below.
  • x86 "direct hardware programming". You need to know how to program the hardware directly, especially the chips in your motherboard. You can practice this from within windows by developing an application that directly access the hardware. This is not a must, but it's better if you master it first. You also have to know some x86 bus protocol, such as PCI and ISA. I'll explain a bit about the bus protocols below.
  • You have to be able to comprehend part (if not all) of the datasheets of your motherboard chip. Such as the northbridge and southbridge control registers.

[+/-] details

2.1. PCI BUS

We'll begin with the PCI bus. I've been working with this stuff for quite a while. The official standard for the PCI bus system is maintained by a board named PCISIG (PCI Special Interest Group). This board actually is some sort of cooperation between Intel and some other big corporation such as Microsoft. Anyway, in the near future PCI bus will be fully replaced by a much more faster bus system such as Arapahoe (PCI-Express a.k.a PCI-e) and Hypertransport. But PCI will still remain a standard for sometime I think. I've read some of the specification of the Hypertansport bus, it's backward compatible with PCI. This means that the addressing scheme will remains the same or at least only needs a minor modification. This also holds true for the Arapahoe. One thing I hate about this PCI stuff is that the standard is not an open standard. Thus, you gotta pay a lot to get the datasheets and whitepapers. This become my main reason providing you with this sort of tute.

First, PCI bus is a bus which is 32 bits wide. This imply that communicating using this bus should be in 32 bits addressing mode. Pretty logical isn't it? So, writing or reading to this bus will require 32 bits addresses. Note that eventhough there is a 64-bit PCI bus, it's not natively supported, since PCI uses a dual address cycle to implement it. So, we can say that PCI primarily a 32-bit bus system.

Second, this bus system is defined in the port CF8h - CFBh which acts as the configuration address port and port CFCh - CFFh which acts as the configuration data port. These ports are used to configure the corresponding PCI chip, i.e. reading/writing the PCI chip configuration register values.

Third, this bus system force us to communicate with PCI chips with the following algorithm (from host CPU point of view):

  1. Write the target bus number, device number, function number and offset/register number to the Configuration Address Port and set the Enable bit in it to one. In plain english, write the address of the register you're willing to read/write into the PCI address port.
  2. Perform a one-byte, two-byte, or four-byte I/O read from or a write to the Configuration Data Port. In plain english, write/read the data you're willing to read/write into the PCI data port.
As a note, as far as I know every bus/communication protocol implemented in chip design today uses similar algorithm to communicate with another chip which has a different bus protocol.

With the above definition, now I'll provide you with an x86 assembly code snippet that shows how to use those configuration ports.

No. Mnemonic (masm syntax) Comment
1 pushad save all the contents of General Purpose Registers
2 mov eax,80000064h put the address of the PCI chip register to be accessed in eax (offset 64h device 00:00:00 or hostbridge)
3 mov dx,0CF8h put the address port in dx. Since this is PCI, we use CF8h as the port to open an access to the device.
4 out dx,eax send the PCI address port to the I/O space of the processor
5 mov dx,0CFCh put the data port in dx. Since this is PCI, we use CFCh as the data port to communicate with the device.
6 in eax,dx put the data read from the device in eax
7 or eax, 00020202 modify the data (this is only example, don't try this in your machine, it may hang or even destroy your machine)
8 out dx,eax send it back ....
9 ............ -
10 popad pop all the saved register
11 ret return...

I think the code above clear enough. In line one the current data in the processors general purpose registers were saved. Then comes the crucial part. As I said above, PCI is 32 bits bus system hence we have to use 32 bits chunk of data to communicate with them. We do this by sending the PCI chip a 32 bits address through eax register, and using port CF8h as the port to send this data. Here's an example of the PCI register (sometimes called offset) address format. In the routine above you saw :

mov eax,80000064h
the 80000064h is the address. The meaning of these bits are:
bit position 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
binary value 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0 0
hexadecimal value 8 0 0 0 0 0 6 4
  • The 31st bit is an enable bit. If this bit sets, it means that we are granted to do a write/read transaction through the PCI bus, otherwise we're prohibited to do so, that's why we need an 8 in the leftmost hexdigit.
  • Bits 30 - 24 are reserved bits.
  • Bits 23 - 16 is the PCI Bus number.
  • Bits 15 - 11 is the PCI Device number.
  • Bits 10 - 8 is the PCI Function Number.
  • Bits 7 - 0 is the offset address.

Now, we'll examine the previous value that was sent. If you're curious, you'll find out that 80000064h means we're communicating with the device in bus 0, device 0 , function 0 and at offset 64. Actually this is the memory controller configuration register of my mainboard's Northbridge. In most circumstances the PCI device that occupy bus 0, device 0, function 0 is the Hostbridge, but you'll need to consult your chipset datasheet to verify this. This stuff is pretty easy to be understood, isn't it ? The next routines are pretty easy to understand. But if you still feel confused you'd better learn assembly language a bit, since I'm not here to teach you assembly (!_!) . But, in general they do the following jobs: reading the offset data then modifying it then writing it back to the device, if not better to say tweaking it (^__^) .

[+/-] details

2.2. ISA BUS

AFAIK, ISA bus is not a well standardized bus. Thus, any ISA device can reside virtually almost anywhere in the system's 16-bit I/O address space. My experience with ISA bus is very limited. I've only play with two chips this time around, the first is the CMOS chip and the second one is my mainboard's hardware monitoring chip, i.e. Winbond W83781D. Both chips uses the same "general algorithm" as mentioned above in the PCI BUS:

  1. Send the address of the part of the device you're willing to read/write at first. Only after that your access to send/receive data through the data port to/from the device will be granted.
  2. Send/receive the data to be read/write through the data port.

My hardware monitoring chip defines port 295h as its address port (a.k.a index port) and port 296h as its data port. CMOS chip defines port 70h as its address port and port 71h as its data port.

[+/-] details

3. Some Hardware Peculiarities

Due to its history, the x86 platform contains lots of hacks, especially its BIOS. This is due to the backward compatiblity that should be maintained by any x86 system. In this section I'll try to explain couple of stuff that I found during my BIOS disassembly journey that reveal these peculiarities.

[+/-] details

3.1. BIOS Chip Addressing

The most important chips which responsible for the BIOS code handling are the southbridge and northbridge. In this respect, the northbridge is responsible for the system address space management, i.e. BIOS shadowing, handling accesses to RAM and forwarding transaction which uses BIOS ROM as its target to the southbridge which then eventually forwarded to BIOS ROM by southbridge. While the southbridge is responsible for enabling the ROM decode control, which will forward (or not) the memory addresses to be accessed to the BIOS ROM chip. The addresses shown below can reside either in the system DRAM or in BIOS ROM chip, depending on the southbridge and northbridge register setting at the time the BIOS code is executed.

Physical Address Also Known As Used by Address Aliasing Note
000F_0000h - 000F_FFFFh F_seg / F_segment 1 Mbit, 2 MBit, and 4 MBit BIOS alias to FFFF_0000h - FFFF_FFFFh in all chipset just after power-up
000E_0000h - 000E_FFFFh E_seg / E_segment 1 Mbit, 2 MBit, and 4 MBit BIOS alias to FFFE_0000h - FFFE_FFFFh in some chipset just after power-up

The address ranges shown above contain the BIOS code and pretty much system specific. So, you have to consult your chipset datasheets to understand it. Also, note that the address above which will be occupied by the BIOS code during runtime (after BIOS code executes) is only F_seg i.e. F_0000h - F_FFFFh. However, certain operating system might "trash" this address and use it for their own purposes. The addresses written above only reflect the addressing of the BIOS ROM chip to the system address space when it's set to be accessed by the BIOS code or another code that accesses the BIOS ROM chip directly. The mainboard chipsets are responsible for the mapping of certain BIOS ROM chip area to the system address space. As we will see later, this mapping can be changed by programming certain chipset registers.

BIOS chip with capacity bigger than 1 Mbit, i.e. 2 Mbit and 4 Mbit chips has a quite different addressing for their lower bios area, i.e. C_seg, D_seg and other lower segment(s). In most cases, this area is mapped to near-4GB address range. This address range is handled by the norhtbridge analogous to the PCI address range. In this scheme the chipset behaves as follows:

  • The northbridge acts as the address forwarder, meaning: it responds to this "special" memory address in different fashion compared to "normal" memory address which is forwarded directly to RAM. On the contrary, this "special" memory address is forwarded by the northbridge to the southbridge to be decoded.
  • The southbridge acts as the address decoder, meaning: it decodes this "special" memory addresses into the right chip "beneath" it, such as the BIOS chip. In this respect, the southbridge will return "void" (bus address cycle termination) if the address range is not being enabled to be decoded in the southbridge configuration registers.
Below is an example:
Physical Address Also Known As Used by Address Aliasing Note
000F_0000h - 000F_FFFFh F_seg / F_segment 1 Mbit, 2 MBit, and 4 Mbit BIOS alias to FFFF_0000h - FFFF_FFFFh in all chipset just after power-up
000E_0000h - 000E_FFFFh E_seg / E_segment 1 Mbit, 2 Mbit, and 4 Mbit BIOS alias to FFFE_0000h - FFFE_FFFFh in some chipset just after power-up
FFFD_0000h - FFFD_FFFFh D_seg / D_segment 2 Mbit, and 4 Mbit BIOS -
FFFC_0000h - FFFC_FFFFh C_seg / C_segment 2 Mbit, and 4 Mbit BIOS -
FFF8_0000h - FFFB_FFFFh - 4 Mbit BIOS -

The conclusion is: modern day chipsets performs an emulation for F_seg and E_seg handling. This is a proof that modern day x86 systems maintains backward compatibility. However, this "kludge" sometimes referred to as the thing of the past that vendors should've been removed from x86 systems.

Below is the VIA693A chipset (Northbridge) system memory map just after system power-up as written in its datasheet.

      Table 4. System Memory Map
Space Start    Size  Address Range      Comment
DOS   0        640K  00000000-0009FFFF  Cacheable
VGA   640K     128K  000A0000-000BFFFF  Used for SMM
BIOS  768K     16K   000C0000-000C3FFF  Shadow Ctrl 1
BIOS  784K     16K   000C4000-000C7FFF  Shadow Ctrl 1
BIOS  800K     16K   000C8000-000CBFFF  Shadow Ctrl 1
BIOS  816K     16K   000CC000-000CFFFF  Shadow Ctrl 1
BIOS  832K     16K   000D0000-000D3FFF  Shadow Ctrl 2
BIOS  848K     16K   000D4000-000D7FFF  Shadow Ctrl 2
BIOS  864K     16K   000D8000-000DBFFF  Shadow Ctrl 2
BIOS  880K     16K   000DC000-000DFFFF  Shadow Ctrl 2
BIOS  896K     64K   000E0000-000EFFFF  Shadow Ctrl 3
BIOS  960K     64K   000F0000-000FFFFF  Shadow Ctrl 3
Sys   1MB            00100000-DRAM Top  Can have hole
Bus   D Top          DRAM Top-FFFEFFFF
Init  4G-64K   64K   FFFEFFFF-FFFFFFFF  000Fxxxx alias
The most important thing to take into account here is the address aliasing, as you can see the FFFE_FFFFh- FFFF_FFFFh address range is an alias into 000Fxxxxh, this is where the BIOS ROM chip address mapped (at least in my mainboard, cross check with yours). But, we also have to consider that this only applies at the very beginning of boot stage (just after reset). After the chipset reprogrammed by the BIOS, this address range will be mapped into system DRAM chips. We can consider this as the Power-On default values. As a note, the majority of x86 chipsets use this address aliasing scheme, at least for the F-segment address range.

Another fact that we have to take into account: most chipset only provides default addressing scheme for F-segment just after power-up in its configuration registers, other "BIOS ROM segment(s)" remains inaccessible. The addressing scheme for these segments will be configured later by the bootblock code by altering the related chipset registers (in most cases the southbridge registers). The chipset that's being dissected here also belongs to this group.

Modern day systems connect the BIOS ROM chip to the southbridge through LPC(Low Pin Count) interface. However, the southbridge described in this article don't have such a interface. It's an old chipset and still uses ISA BUS to interface with the BIOS ROM chip.

[+/-] details

3.2. Obscure Hardware Port

Some "obscure" hardware port which sometimes not documented in the chipset datasheets described below. Note that these info's were found from Intel ICH5, VIA 586B and VIA596B datasheet.

I/O Port address     Purpose
92h                  Fast A20 and Init Register
4D0h                 Master PIC Edge/Level Triggered (R/W)
4D1h                 Slave PIC Edge/Level Triggered (R/W)

Table 146. RTC I/O Registers (LPC I/F D31:F0)
I/O Port Locations    If U128E bit = 0            Function
70h and 74h           Also alias to 72h and 76h   Real-Time Clock (Standard RAM) Index Register
71h and 75h           Also alias to 73h and 77h   Real-Time Clock (Standard RAM) Target Register
72h and 76h                                       Extended RAM Index Register (if enabled)
73h and 77h                                       Extended RAM Target Register (if enabled)


1. I/O locations 70h and 71h are the standard ISA location for the real-time clock. The map for this bank is
   shown in Table 147. Locations 72h and 73h are for accessing the extended RAM. The extended RAM bank is
   also accessed using an indexed scheme. I/O address 72h is used as the address pointer and I/O address
   73h is used as the data register. Index addresses above 127h are not valid. If the extended RAM is not
   needed, it may be disabled.
2. Software must preserve the value of bit 7 at I/O addresses 70h. When writing to this address, software 
   must first read the value, and then write the same value for bit 7 during the sequential address write. 
   Note that port 70h is not directly readable. The only way to read this register is through Alt Access 
   mode. If the NMI# enable is not changed during normal operation, software can alternatively read this bit 
   once and then retain the value for all subsequent writes to port 70h.

The RTC contains two sets of indexed registers that are accessed using the two separate Index and
Target registers (70/71h or 72/73h), as shown in Table 147.

Table 147. RTC (Standard) RAM Bank (LPC I/F D31:F0)
Index   Name
00h     Seconds
01h     Seconds Alarm
02h     Minutes
03h     Minutes Alarm
04h     Hours
05h     Hours Alarm
06h     Day of Week
07h     Day of Month
08h     Month
09h     Year
0Ah     Register A
0Bh     Register B
0Ch     Register C
0Dh     Register D
0Eh-EFh 114 Bytes of User RAM

[+/-] details

3.3. "Relocatable" Hardware Port

There are several kinds of hardware port that is relocatable in the system I/O address space. In this BIOS, those ports include SMBus-related ports and Power-Management-Related ports. These ports has certain base address. This so called base address is controlled via programmable base address register. SMBus has SMBus base address register and Power-Management has Power-Management I/O base address register. Since these ports are programmable, the bootblock routine initializes the value of the base address registers in the very beginning of BIOS routine execution. Due to the programmable nature of these ports, one must start reverse engineering of BIOS in the bootblock to find out which port address(es) used by these programmable hardware ports. Otherwise one will be confused by the occurence of "weird" ports later during the reverse engineering process. An example of this case provided below.

Address    Hex                  Mnemonic

F000:F604 BE C4 F6                  mov   si, 0F6C4h          ; addr of chipset reg mask
F000:F607                         next_PCI_reg:               ; CODE XREF: Chipset_Reg_Early_Init+29
F000:F607 2E 8B 0C                  mov   cx, cs:[si]
F000:F60A BC 10 F6                  mov   sp, 0F610h
F000:F60D E9 F8 00                  jmp   Read_PCI_Byte
F000:F60D                         ; ---------------------------------------------------------------------------
F000:F610 12 F6                     dw 0F612h
F000:F612                         ; ---------------------------------------------------------------------------
F000:F612 2E 22 44 02               and   al, cs:[si+2]
F000:F616 2E 0A 44 03               or    al, cs:[si+3]
F000:F61A BC 20 F6                  mov   sp, 0F620h
F000:F61D E9 02 01                  jmp   Write_PCI_Byte
F000:F61D                         ; ---------------------------------------------------------------------------
F000:F620 22 F6                     dw 0F622h
F000:F622                         ; ---------------------------------------------------------------------------
F000:F622 83 C6 04                  add   si, 4
F000:F625 81 FE 04 F7               cmp   si, 0F704h          ; are we done yet?
F000:F6F4 48 3B                     dw 3B48h                  ; B#0 D#7 F#3: PwrMngmt&SMBus - PwrMngmt IO Base Addr lo_byte
F000:F6F6 00                        db 0                      ; and mask
F000:F6F7 00                        db 0                      ; or mask
F000:F6F7                                                     ;
F000:F6F8 49 3B                     dw 3B49h                  ; B#0 D#7 F#3: PwrMngmt&SMBus - PwrMngmt IO Base Addr hi_byte
F000:F6FA 40                        db 40h                    ; and mask
F000:F6FB 40                        db 40h                    ; PwrMngmt IO Base Addr = IO Port 4000h
F000:F643 B9 90 3B                  mov   cx, 3B90h           ; B#0 D#7 F#3: PwrMngmt&SMBus - SMBus IO Base Addr lo_byte
F000:F646 B0 00                     mov   al, 0               ; set SMBus IO Base lo_byte to 00h
F000:F648 BC 4E F6                  mov   sp, 0F64Eh
F000:F64B E9 D4 00                  jmp   Write_PCI_Byte
F000:F64B                         ; ---------------------------------------------------------------------------
F000:F64E 50 F6                     dw 0F650h
F000:F650                         ; ---------------------------------------------------------------------------
F000:F650 B9 91 3B                  mov   cx, 3B91h           ; B#0 D#7 F#3: PwrMngmt&SMBus - SMBus IO Base Addr hi_byte
F000:F653 B0 50                     mov   al, 50h ; 'P'       ; set SMBus IO Base hi_byte to 50h,
F000:F653                                                     ; so, now SMBus IO Base is at port 5000h !!!
F000:F655 BC 5B F6                  mov   sp, 0F65Bh
F000:F658 E9 C7 00                  jmp   Write_PCI_Byte
F000:F658                         ; ---------------------------------------------------------------------------
F000:F65B 5D F6                     dw 0F65Dh

F000:F66A BA 05 40                  mov   dx, 4005h           ; access ACPI Reg 05h
F000:F66D B0 80                     mov   al, 80h ;        ; setting reserved bit?

Certainly, there are more relocatable hardware ports than those described here, but at least you've been given the hints about it. So that, once you found code in the BIOS that seems to be accessing "weird" ports, you'll know where to go.

[+/-] details

3.4. Expansion ROM Handling

There are couples of more things to take into account, such as the Video BIOS and other expansion ROM handling. I'll try to cover that stuff later when I've done dissecting BIOS code that handle it. But here's the basic run-down of PCI Expansion ROM handling in BIOS:

  1. System BIOS detect all PCI chip in the system and initialize its BARs(Base Address Registers). Once initialization completes, the system will have a usable system-wide addressing scheme.
  2. By using the system-wide addressing scheme, system BIOS then copies the implemented PCI Expansion ROM into RAM one by one in the expansion ROM area (C000:0000h - D000:FFFFh) and execute it there until all of the PCI expansion ROM have been executed/initialized.

ISA Expansion ROM is not relevant these days. Therefore it's not discussed here.

[+/-] details

Tuesday, April 21, 2009

BIOS Binary File Editing with Vim in Linux

I didn't realize it until just now that Vim actually has a quite neat binary file editing mode. Let's have a quick look into this mode. First, you have to start Vim and tell it explicitly that you want to edit a binary file. This is important because if you don't do it, the file is guaranteed to be tampered by Vim in a way that you don't expect it to. To do it, open the file by using the '-b' switch like this:
vim -b [file name]
For example let's have a look at a sample BIOS file:
pinczakko@opusera:~/temp/bios_reversing$ vim -b 8IPE775P.BIN
This is the result: Now, that doesn't look like a convenient way of editing a binary file. Therefore, let's convert it into a better looking file called the xxd file by using the following Vim command:
This is what we got: At this point, you can edit the hex values in the middle column shown in the figure above. The drawback of Vim is the changes cannot be reflected immediately in the other columns. Assuming that you have finished editing the binary file, you should convert the xxd file back to its original binary form. This is accomplished with the following vim command:
:%!xxd -r
After that, you should save it back with the
Vim command. The help that comes with Vim explain the details of the procedure in section 23.4, under section 23 (Editing Other Files). More experiments still need to be done to ensure that Vim is reliable enough for binary editing. But this is a very good starting point.

Thursday, April 2, 2009

My BIOS Security Presentation on AI3 Meeting 2006

With all the fuss around BIOS rootkit in CanSecWest, I have to say that it's already a long known fact. In 2006 I presented the possibility in AI3 Meeting in ITB (Bandung Institute of Technology). These are the presentation contents: [+/-] Read Details

Tuesday, February 17, 2009

Fujitsu-Siemens BIOS File Structure

This is a quick post. Will be updated later. Just being here to remind me (haven't write it anywhere yet).

The Fujitsu-Siemens BIOS binary distributed in its website is not a plain BIOS binary which you can flash directly to their motherboard without using its propietary tool. The BIOS file structure is quite peculiar from other vendors. Here it is:

| Some unidentified header (yet) |
|   "real" BIOS binary           |
| 1-byte 8-bit checksum          |
In quick inspection, the header ends at offset 0x70 from the beginning of the BIOS file distributed by Fujitsu-Siemens. The particular BIOS I'm working on contains an altered AMI BIOS

Sunday, February 8, 2009

A Gentle Introduction to BIOS File Structure

The BIOS File Structure in its purest form will look like this:

|        Bootblock          |
|Compressed BIOS components |
The bootblock code responsible for decompression of the compressed BIOS components and to do a very early platform initialization, just enough to make the BIOS decompression process to run flawlessly and to do BIOS recovery procedure in certain bad BIOS flash scenarios. Mind you that not all of BIOS bad flash scenario can be recovered.

As far as I know, BIOS from Award-Phoenix (and its older ancestors Award, Inc. and Phoenix Technologies), AMI BIOS Inc., and all other BIOS vendors use this BIOS file structure. This BIOS file structure maybe used in the binary file of BIOS distributed directly by hardware vendors. However, it's possible that the BIOS distributed by the vendor has been altered in some way in order to do some more sanity checks during the BIOS flashing process. In the latter case, the BIOS file format won't be exactly as shown above, but it will probably compressed, or given some particular information preprended, inserted, or appended into the BIOS binary file distribution.

Welcome to The BIOS Blog

I started this blog in order to organize all of my rumblings on BIOS which are still hosted in www.geocities.com/mamanzip right now. Moving them into a blog will reduce the "pain" when I want to add new information regarding the x86 BIOS materials. As such, this blog will be focused on the x86 BIOS things, particularly: reverse engineering, code injection and modification in general. That's it for now.