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

Saturday, November 12, 2011

BIOS/UEFI-related Full-scale and Module-level Reverse Engineering with IDA Pro

Over the past several months, I've been intensively researching BIOS-related binaries. The primary tool I used is still IDA Pro. However, I noted that the speed at which my understanding of the binary evolves still nowhere near what it should be. Therefore, I have been evaluating my method for a while and come-up with these steps:

  1. Make sure you know the context at which the certain part(s) of the BIOS/UEFI binary executes. This way, you can maximize the presence of documentations or specifications related to that particular part of the binary.
  2. Mark "alleged" data structures (arrays, structures, etc.) with readable names. Do not worry about changing the names later as long as you keep track of where they are located if they are global variables.
  3. Create IDA Pro structures which would help improve readability of your disassembly. Again, do not worry too much about correctness at this point because you will know it further down the line. The bottom line is reverse code engineering consists of repeated refinement steps which improves the understanding of the code along the way. The point is you needto create clues for further refinement steps.
  4. Zoom-out function graph (not function call-graph but the single function graph) to get the "big picture" of the function elements especially to recognize loops and branches. This way, it's faster to understand the function. Refine the "alleged" data structure as needed, as you go through the function analysis. Also don't forget to give meaningful name to the function.
  5. (Optional). If you think writing C/C++ code as representation for the function could help, then do so. In my case, it helps tremendously, especially because th binary I'm working with is compiled with C compiler (evident from the stack and parameter usage).
  6. Making standardized information in the anterior line of the first function instruction helps tremendously. I think at least these information should be there:
    • Function name, preferably along with its starting address. The address is important because name could change as our understanding evolves during the reverse engineering activity. It's particularly important because the documentation generated from the reverse engineering surely refers to several key functions.
    • Function description, i.e. what it does in general sense.
    • Function parameters (input and output).
    • Data structures and global variables modified by the function.
  7. Kris Kaspersky-style commenting is rather useful for me. He places a lengthy (but enlightening comment) below specific lines. For example:
    main           proc near                 ; CODE XREF: start+AF?p
           push   esi
           push   8
           call   ??2@YAPAXI@Z               ; operator new(unit)
           ; Using the new operator, we allocate 8 bytes for the instance of
           ; some object. Generally, it's not very certain at all that memory
           ; is allocated for an object (there might be something like
           ; char *x = new char[8]), so let's not, consider this assertion
           ; as dogma, and accept it as a working hypothesis.
           ; Further analysis will show how matters actually stand.
           mov    esi, eax
           add    esp, 4
    I found that this commenting style helps especially when we have just starting with the reverse engineering task.
  8. The use of virtual machine could help because it enables us to debug certain BIOS/UEFI part(s). For example: pci option rom debugging with seabios.
  9. The remaining thing which I'm still not used to is: How to use the function call graphs effectively?

Thursday, November 3, 2011

BIOS Disassembly Ninjutsu Uncovered 2nd Edition Works/Research Update

It's been "dormant" months on this front for a couple of months. Well, actually I'm working on BIOS and middleware stuff and keeping-up with real life.

Now, into the BIOS Disassembly Uncovered 2nd Edition matters. After working on BIOS related research and stuff these last few months I realized that there are a lot of research and works need to be done before I could continue writing stuff for the book. You may ask why? Well, first and foremost. The first book is an important hallmark in my life. Therefore, I won't just "write another book" for the second edition. I prefer it to be "groundbreaking", rather than just mediocre. A lot of subjects still needs research, particularly in the area of Coreboot, UEFI and cryptographic stuff related to BIOS/UEFI and other firmware in general. I found it rather surprising that after the publication of the first book, there has been quite a "surge" in BIOS-related protection out there (at least judging from patent applications). I know it has been researched prior to the first book. But, perhaps, its publication accelerates some of them.

Ok. So now, I would reiterate that I'm more than merely enthusiastic about the second edition book. But, after reflecting on present condition and the current state of the research I don't want to be rushed and produce a mediocre book. I actually want it to be much better than the first because back then I was newbie. I even barely able to use IDA Pro properly despite being able to write several not so complex IDA Pro plugin.

If you have any inquiries, especially in cryptographic-related BIOS stuff. Let me know. Perhaps, you have a link to sample binary out there I haven't know of?


Monday, October 17, 2011

PCI "Generic" Option ROM Debugging with SeaBIOS, Coreboot and IDA Pro

In this post, I assume the PCI Option ROM is named TEST.ROM. Which is an option ROM not tied to particular hardware.  The debugging environment consists of two machines, either virtual or physical. In my particular setup, I used two physical machines. The debugging “host” runs Windows 7 64 with IDA Pro as a remote debugger. The “target (gdb server)” runs Linux—with Qemu as the “real” target of the debugging in the Linux machine. The sole reason to use Linux in the “target” is to enable rebuilding Coreboot and SeaBIOS which acts as the “container” of the target PCI option ROM. The steps to prepare the debugging environment as follows:
  1. Configure and build SeaBIOS.
    1. Run make menuconfig in SeaBIOS root source directory. If you’re downloading SeaBIOS as Coreboot payload, it’s located at <coreboot_source_path>/payloads/external/SeaBIOS/seabios.
    2. Enable CONFIG_OPTIONROMS, CONFIG_PMM, CONFIG_COREBOOT_FLASH when you run make menuconfig.
    3. Configure debug level to 8 (CONFIG_DEBUG_LEVEL)
    4. Save your changes and quit from the configuration menu (make menuconfig).
    5. Build SeaBIOS by invoking make.
  2. Configure and build Coreboot.
    1. Run make menuconfig in Coreboot root source directory.
    2. Disable both CONFIG_VGA_ROM_RUN and CONFIG_PCI_ROM_RUN as either of these options will confuse the virtual machine (Qemu) and possibly modify the contents of the PCI option ROM at runtime (debugging). Producing unwanted side effects.
    3. Configure SeaBIOS binary not as ordinary payload, but as an ELF payload. Configure CONFIG_PAYLOAD_FILE to point to the SeaBIOS ELF file, i.e. <seabios_source_path>/out/bios.bin.elf.
    4. Save your changes and quit from configuration menu (make menuconfig).
    5. Build Coreboot by invoking make.
  3. Insert TEST.ROM as CBFS component to Coreboot ROM file. The following are the steps to insert the PCI option ROM (the steps could be scripted):
    1. Combine TEST.ROM as CBFS component to Coreboot ROM with this command (invoked from Coreboot source code root directory):
                  ./build/cbfstool build/coreboot.rom add <path_to_TEST_ROM> genroms/test.rom raw
    2. Check whether everything is OK with this command:
                 ./build/cbfstool build/coreboot.rom print
  4. Run Qemu utilizing the newly built Coreboot ROM file as its BIOS (configured to stop and wait for the GDB connection).
    qemu –m 128 –bios <path_to_coreboot_rom> -hda linux.img –net none –nographic –s –S 
    The –net none option disables gPXE option ROM from Qemu to load. The gPXE option ROM complicates the analysis a bit. Therefore, it’s better to get rid of it.
    NOTE: If Qemu gPXE option ROM is enabled (default), the TEST.ROM option ROM would always be loaded at C980h segment. If Qemu gPXE option ROM is disabled, the TEST.ROM option ROM would always be loaded at C900h segment.
  5. Run IDA Pro and connect via GDB remote debugging.
    1. Configure IDA Pro debugger to run in x86 16-bit mode.
    2. Attach to the qemu machine via Debugger|Attach|Remote GDB Debugger menu. Configure the IP address of your virtual or physical target machine there (which runs Qemu) and set the debugger specific option to run 16-bit code.
    3. When stopped at reset vector (FFFF:FFF0), create your required memory regions (Debugger|Debugger Options…|Set Specific Options|Memory Map)
    4. Configure breakpoints as needed.
    5. Run (press F9) and debug.
That's it. Now you can debug the "generic" option ROM to your hearts content :-)

Friday, September 2, 2011

Desktop Management Interface (DMI) Access Interface

Well, I should make an article about this later because it doesn't make it to my first edition book. First, let me emphasize that we're looking at the DMI Access Interface from the BIOS execution context, not from within an OS context. The DMI v2.0 specification (www-pc.uni-regensburg.de/hardware/TECHDOK/BIOS_DMI_20.PDF) "vaguely" states that the interface to the DMI from the BIOS execution context as follows:
To prevent the proliferation of interfaces for accessing information embedded in the System BIOS, the Desktop Management BIOS Specification will follow the System Device Node model used by Plug and Play, and use Plug and Play BIOS functions to access DMI information. Plug and Play functions 50h-5Fh have been assigned to the DMI BIOS Interface.
Well, it's not immediately clear what does it mean by "Plug and Play functions 50h-5Fh". A closer look into the PnP BIOS spec v1.0A (www.osdever.net/documents/PNPBIOSSpecification-v1.0a.pdf) reveals the crux of the matter. When you read through the PnP BIOS spec v1.0A, what you will find in section 4.4 is a description to the PnP BIOS entry point. Furthermore, try to find function "number" higher than PnP function 43h and you're out of luck. Now, from the description in the DMI v2.0 spec snippet above it's now clear that the higher function "number" (above 43h) is relegated to another spec (presumably after the PnP BIOS spec was ratified). One of them is the DMI spec. PnP BIOS spec was published in 1994, while the DMI spec v2.0 was published in 1996. Therefore, accessing the DMI "services" in BIOS code (or ring-0 code in an OS) is carried-out via PnP BIOS interface at function 50h to 5Fh. It seems all of this past effort was part of the DMTF standardization (I'm not 100% sure).

Friday, August 26, 2011

License for the source code in the Low Cost Embedded x86 Teaching Tool article

I haven't had the time to update the copyright notice in the Low Cost Embedded x86 Teaching Tool. However, if you want to use it (and modify it) for your own purposes, you could do so under the Gnu Public License (GPL) version 2 which mandates you to relase your changes. Coreboot project have been using some part of it for their use under the GPL. I'm going to update the license notice in the article ASAP. Cheers.

Sunday, August 14, 2011

IOMMU Specification from Intel and AMD

This is just a dump of the links to download AMD and Intel IOMMU specification. For those of you new to IOMMU, a good introductory is at http://en.wikipedia.org/wiki/IOMMU.

Now, the specs:

AMD specs: http://support.amd.com/us/Processor_TechDocs/34434-IOMMU-Rev_1.26_2-11-09.pdf and http://support.amd.com/us/Processor_TechDocs/48882.pdf

Intel spec: http://download.intel.com/technology/computing/vptech/Intel%28r%29_VT_for_Direct_IO.pdf

Just a note that Intel calls the IOMMU as Virtualization Technology for Directed IO (VT for Directed I/O).

Saturday, August 6, 2011

"Frying" Another USB-to-IDE Converter

Last wednesday was the second time I fried another USB-to-IDE converter device due to buggy ATA command that was sent to the IDE device (a DVD-ROM Drive). I'm not really sure which command that causes it to happen. But, now is the time to look into ATA command set much deeper. Well, this is just a precaution for guys/girls out there working with *-to-IDE converter device. Be very careful with ATA command that you send to the IDE device. Apparently, the problem was the "offending" ATA command corrupt the firmware inside the converter. I haven't look very detailed into what type of chip used in the converter. Probably MIPS-based or ARM-based microcontroller. Too bad I don't have JTAG debugger to see what exactly happens.

Saturday, July 30, 2011

Memory Management in Legacy BIOS

Memory management during POST in "legacy" BIOS is not well known to most system programmers. Probably, only a handful knows that this kind of routine even exists. Perhaps, you would ask why would anyone need a memory manager in BIOS level? Well, as you know, memory space in 16-bit environment is scarce. Moreover, BIOS modules are getting bigger and if all of them loaded at the same time to the 1 MB space available in 16-bit mode, we will run out of space very easily. The solution is obviously a memory manager. But, how would you go about creating a memory manager while everyone are developing propietary BIOS codes? As in other branch of software development. You create a standard interface for the memory manager, leaving out the details to implement the standard to the BIOS vendors. This is exactly what happens.

The standard for memory management during POST in BIOS code execution is the Post Memory Manager (PMM) specification. The document for this specification is rather hard to come by. PMM is a relatively short specification.

An in-depth coverage of the subject is currently in preparation for an upcoming article at the Pinczakko Official Website.

Facebook Comment Feature Now Available

Hi guys, Facebook commenting is now enabled in this blog. I hope this enables better communication with the blog audience. Another news is that I'm going to do cross-referencing to Pinczakko Official Website from here. I'm back to writing articles now that it has been several years dormant. The last article I wrote was on the DLL support in Award BIOS. Well, it has been a long time ago.

Wednesday, July 20, 2011

The Long Silence and News on the Second Edition Book

Hi guys. It's been a very long silence since March. Well, real life got in the way. I was busy with a middleware project and the need to learn from scratch made it very difficult to allocate time for the BIOS research. Well, now I'm back researching BIOS again full-throttle at least 3 days per week. Therefore, the book content would be coming in the coming weeks hopefully. I have several semi-official works in BIOS baking in the kitchen. You will see some of it in the new book. Just FYI, the first book took 5 years for the research because I'm complete noob in (believe it or not) computer. Not just programming but using computer as well. It took several years just to learn to write Windows Device Drivers for experiments. Certainly a lot has changed since those years. Therefore, several months of research I think would be sufficient this time around as long as I can keep my "mood level" and "focus" to finish this one. Thanks for the suggestions in my post from last March. I'm preparing a reworked ToC to accomodate those ideas. Regarding my plan to release the first edition of the book for free. I'm still doing some cautious reading on the contract to see whether it will violate my contract or not. Actually, I stopped receiving royalties in mid-2010. However, I don't want to violate any IP transferred to my publisher as per the contract.

Wednesday, March 9, 2011

Latest State of The BIOS Disassembly Book

Hello guys. First I would like to apologize for the very late delivery of the book. I've been dragging my feet with other works over the past few months and hadn't been able to do considerable work on the book. Anyway, I have discussed everything with my publisher and co-author Luis Miras and we decided that we should push forward much more aggressively. Well, I decided to do a "restart" because the first four chapters that I have finished last year requires a lot of rework. If you have ideas on new stuff which you think should be included, feel free to talk about it in the comment section. Thanks. Darmawan

Sunday, January 9, 2011

Happy New Year and Update on BIOS Disassembly Ninjutsu Uncovered 2nd Edition

Hi Guys. First I'd like to say Happy New Year to you all. About BIOS Disassembly Ninjutsu Uncovered 2nd Edition, I want to apologize because I couldn't finish the book last year despite my best effort. It's not a vaporware :P, as I've worked on several chapters already. It's too bad that I was very busy last year and couldn't allocate enough time to finish it. However, there was one positive side to the delay. I finally had a chance to work with official BIOS source code from one of the BIOS vendor (under NDA). This gives me a unique insight on how much exactly an "insider" (a.k.a BIOS developer) knows about the BIOS code itself. I can tell you that it's exactly as what I've suspected since long ago (even before BIOS Disassembly Ninjutsu Uncovered), even if you have the source code, BIOS code still has a very steep learning curve, you need to know (literally) dozens of hardware protocol specifications. It's not just about the code itself but about the background knowledge needed to understand them all. Well, at least in one respect, the second edition of the book would provide a unique point of view.