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?