Migrating AMIBIOS 1B Module Utilities Source Code to GitHub

A long time ago (read: 10+ years) I created some small, mostly BIOS-related, utilities and dumped the source code on the web. I even forgot that they're there in my website (https://sites.google.com/site/pinczakko/source-code). Fortunately, over time, some people come across those source code and found the source code useful for them. Some of them asked question or give suggestions. Therefore, I decided to gradually move the code over to GitHub and update the code as well, so that the code would still be compile-able with present day toolchain.

Some of the utilities are small utilities to parse, extract and modifies AMIBIOS8 1B (main) module--akin to original.tmp in (legacy) Award BIOS. You need to use AMI Module Management Tool (MMTool) to obtain the 1B module from AMI BIOS binary file.

The utilities source code are now in Github: https://github.com/pinczakko/AMIBIOS8_1B_Utils. The code is POSIX compliant. I haven't test it against Mingw-w64 cross compiler to produce Windows binary--I recall that I used mingw (32-bit) on Windows to write the code back then. The code compiled just fine in Arch Linux gcc toolchain as of July 2017. Therefore, the code can produce Linux/Unix executable just fine.

I don't really remember the exact time when I wrote the utilities. But, it was wrtitten in 2010 and used in one of my project(s) in that year for one of my client(s). Those projects requires AMIBIOS8 binary modification. That's the reason I wrote the utility.

For the time being, feel free to play with it and modify it. I plan to add support for cross compilation with Mingw-w64 later on. If you tested the code on real AMIBIOS8 binary, I'd like to know the result ;-).

Anyway, the code is GPL v2-licensed (kudos to Gabor Stefanik for reminding me to put proper licensing note).

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

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.

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

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.