My Award BIOS hacking/patching Guide

[Pinczakko]

It's a very technical article, however somebody might find it useful. Here's the link : My Award BIOS Reverse Engineering Article

A snippet of it's contents :

Table of Contents



* Foreword

* Prerequisite

	  o PCI BUS

	  o ISA BUS

* Some Hardware "Peculiarities"

* Some Software "Peculiarities"

* Our Tools of Trade

* Award BIOS File Structure

* Disassembling the BIOS

	 1. Bootblock

	 2. System BIOS a.k.a Original.tmp

Still in "beta-version" but I think it's already "operational". Happy reading and hacking

[Angry_Games]

gonna copy this to the Overclocking section so more 'tweakers' will see it

 

feedback is good to help you get it out of beta right?

[slavik]

OMFG!!!!

 

YOU ARE THE OWNAGE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 

you own!!!! u have no clue to how happy I am ... btw, I learned x86 asm and have MASM 6.15 ... hehehe

 

time to code my own hacks!!!! like those programs to change various settings ...

 

now I gotta stick it all into C code ...

[slavik]

just one question ... how did you get the names of the subroutines???

[Pinczakko]

Originally posted by Angry_Games

gonna copy this to the Overclocking section so more 'tweakers' will see it

 

feedback is good to help you get it out of beta right?

Definetely. Thank you for the help

[Pinczakko]

Originally posted by slavik

just one question ... how did you get the names of the subroutines???

At first it's a guessing work, I mean I name it with the name that I suspect is the right name, and when I finished tinkering with it and found it's not suitable (for the routine), then I change it. Sometimes the name is also a bit weird, and it's just since I've been accustomed to it for several days, I don't wanna change it . Also there's some not so obvious reason .

[slavik]

any chance of you to code your own BIOS??? for the nf2 chipset?

[Pinczakko]

my board is not a nf2 chipset, it's intel 865PE . Coding my own BIOS,hmmmm .... let me see. It's quite hard to do so, and I think for the time being I'm not capable enough to do it, may be in the next 1 or 2 years, I'll be able to do it, it needs such a lot of technical specialty and needs quite a lot of time for the debugging. I'm still in the process of learning. I think I'm already on the right track . For the time being, I'm only able to do "massive" modification to my BIOS and I've done it to my older board, you can look at my previous works in my website to see what I've done to my BIOS . Actually I'm thinking about completely replacing it with a custom LinuxBIOS that I code. LinuxBIOS is much more cleaner than another x86 BIOS I've seen so far. AMI BIOS is better than Award BIOS in terms of coding style, but Linux BIOS is better than this two kinds of BIOS.

[slavik]

btw, your BIOS modifications, do they include adding options to the BIOS set up screen???

[Pinczakko]

well, not really. But it should be quite easy or quite hard to do so . Adding option to the BIOS setup screen is accomplished in two ways :

1. The option is already there (available in the BIOS binary) but disabled. In this type of stuff, you can use Modbin to activate the disabled item.

2. The option is not available at all (even within the BIOS binary). In this type of stuff, you have to disassemble the BIOS and "patching" the POST jump table or probably some other "display related routine" that I haven't locate yet . I think Mike Tedder a.k.a bpoint (core developer of award_bios_editor software) knows more about this than me, since one of award_bios_editor feature already emulate the setup screen. So, the simplest way to understand the mechanism is to study award_bios_editor source code (I haven't finish reading and grasping it). Note that award_bios_editor is now opensource! .It's availabe for download from award_bios_editor official website at : http://awdbedit.sourceforge.net/

[Pinczakko]

one reader responded with a very interesting information as follows.

 

written in my article :

 

There are couples of tricky areas in the BIOS code due to the execution of some of its parts in ROM. I'll present some of my findings below.

 

call instruction is not available during bios code execution from within BIOS ROM chip. This is due to call instruction uses/manipulate stack while we don't have writeable area in BIOS ROM chip to be used for stack. What I mean by manipulating stack here is the "implicit" push instruction which is executed by the call instruction to "write/save" the return address in the stack. As we know clearly, address pointed to by ss:sp at this point is in ROM, meaning: we can't write into it. If you think, why don't use the RAM altogether ? the DRAM chip is not even available at this point. It hasn't been tested by the BIOS code, thus we haven't know if RAM even exists!

 

 

Mark_Larson (a reader of the article) :

 

Sort of. On current Intel processors there is a feature called Cache As Ram. It allows you to use your cache as if it were RAM before memory is initialized. Cache As Ram is only supported on the latest processors. On older processors in some BIOSes a trick was used to "fake" a stack in the cache. This allowed the BIOS programmer to do CALLs and RETs without memory having been set up. You fake a stack in the cache and then disable the cache. All accesses to the stack come from the cache. The fake stack never gets removed from the cache because the cache is disabled. AMI first did this about 8 years ago.

 

 

further explanation from Mark Larson

I'll expand a bit on both parts.

 

1) Cache As Ram - Intel basically allows you to set the cache to respond to memory acceses from a certain memory range. For instance you could set the memory range 1000h:0 for 8k to be your stack in Cache as Ram. When the processor accesses anything in the 8k range of 1000h:0 it will get the information from the cache. So setting up a stack somewhere is trivial. That allows you to do CALLs and RETs

 

2) "Faking a stack" -

A) Make sure the L1 is enabled and on and the L2 cache is off.

 

B) Have 1K ( or however big you want your stack to be), set aside as data in the BIOS ROM chip. Doesn't matter what the 1k of data is, as long as you don't use it for anything else.

 

C) Read that data in, forcing it to go into the L1 cache ( rep lods).

 

D) Disable the L1 cache.

 

E) Now set up the stack through the appropriate commands to point to the data that you just read in.

 

F) All accesses to the stack now go through the cache, but the data never gets removed from the cache since it's disabled.

 

G) Having the cache disabled doesn't really mean it's "disabled". What it means is that nothing new can be added to the cache. It still responds to all "hits" with the appropriate data.

 

As a variation, you can do this with the code in the BIOS ROM as well, and use both the L1 and L2. I only used the L1 to make it easier to illustrate. There is actually an MSR on P3 and earlier processors ( I think it got added in the pentium pro), that lets you directly write to the cache. A lot of 3rd party testing tools use this to test the cache. It works like a memory test. You write a pattern and read it back via this MSR. But you can also use it to load up the data or code you want to use directly into the cache. You can also use that mechanism to create the stack in the cache. However it won't work on P4's. So the above method is more robust, since it works in all cases. AMI if I remember right used the MSR method. Look in Book 3 of any of the processor manuals in the appendix under MSRs ( appendix B). In my P4 book it's under the section "MSRs in the P6 Family Processors". It spans multiple MSRs starting at 88h. Keep in mind that this is no longer on the P4.

[Guest Hellfire]

I've been reading it, and it has been a really good read. Now I can see why the call function probably will not work when injecting code into the main bios. I've also read all of my main bios hacking pages ;p

 

Thanks,

Pinczakko