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. 

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.

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.