к сожалению, я не могу говорить на русском :(
some links to award BIOS article that I made:
Award BIOS code injection. Explains how to inject your code/procedure into award BIOS.
Award BIOS Reverse Engineering. This is a stripped down of the old article I upload here last year. (handled by ivp).
Award BIOS File Structure. Explanation of the components inside award bios binary.
Root: чуть подправил мессагу
п.с. Эх, напишу ли я свое подобное по ами да по фениксу? ;) По аварду дааавно есть подобное (недописанное), просто с появлением когда-то вышеуказанной статьи интерес дописывать шибко пропал... :)
А тут я отчасти виноват - сел за перевод статьи Pinczakko (в качестве рыбы для материала) хз когда, да только всякие изменения в жизни малость отвлекли, каюсь... :oops:
Low_Cost_Embedded_x86_Teaching_Tool
Объясняет как построить "PCI Expansion ROM" использование инструменты GNU :wink:
CHANGE LOG
-------------------
1. Table of Contents improved for better navigation.
2. BIOS chip addressing improved.
3. Added new sections:
[list]
[*] "Relocatable" Hardware Port explanation
[*] Expansion ROM Handling explanation
[/list:u]
4. Better code interpretation :wink:
5. Compressed version of the article can be downloaded as well
Поправочка (кто-то скажет - опровержение :) ) - правильно будет так:
...в большинстве биосов Award 4.5x 2Mbit/4Mbit. Во всех остальных (как бы и есть - реальное большинство ;) ) - c самого начала файла биоса.
Адреса и входные точки этих процедур задаются после *BBSS* - уже фиг вспомню по каким смещением - чуток копните бутблок - там все есть.
Хм, видимо - описка, правильно будет:
...E000:0000h - F000:FFFFh.
В разных версиях Аварда и по древности и по производителям - нет единого адреса (биоспатчер, например, сканирует все возможные для поиска, где живет awardext.rom). Для старых 4.5х обычно действительно 6000:0000h - 6000:xxxx, но именно "обычно". Ибо это может быть что угодно и 1000:0 и 2000:0 и даже 5000:0. Во всех современных - в подавляющем большинстве - 1000:0.
В общем это так - результат беглого просмотра-таки этого действительно крайне полезного документа. :) Ибо если читать его подробно - видимо, придется дописывать свое... ;)
П.с. ни в коем случае не рассматривать как попытку "придраться" к нашему почетному обитателю ромбай-форума из далекой страны господина Кука :).
С точностью до наоборот - это попытка привлечь внимание всех, кому интересна эта тема. Просто дело в том, что уже теперешняя версия биоскоммандера, в плане - его модуль декомпилятора биоса - разбирает авард по косточкам, с комментариями. На выходе генерируется файл *.idc, в котором уже описываются тысячи (без преувеличения) различных смещений, переменных и констант. Т.е. получить файл биоса (для IDA, конечно) с разбивкой на функции, при чем, главные из них уже имеют правильные имена с комментариями по применению - дело всего нескольких минут. :)
Для чего это нужно? Вам - может и не нужно. А тому, кому нужно найти _конкретную_ проблему в биосе и ее решение - не придется сидеть и неделями просто "ручками" декомпилировать, читая, в том числе и вышеописанный документ... Ну, как минимум - это мне. :)
Да. Декомпилятор работает с банальнейшими _текстовыми_файликами_, где на примитивном а-ля сиподобном языке (с возможностью вставки прямого сишнго текста от иды и даже ассемблера в будущем) можно редактировать и добавлять собственные переменные для поиска. Т.е. - разобрались как работает какая-то часть биоса - добавили ее описание в файл декомпилятора - и больше не будете повторять эту операцию с любым другим биосом. И вам удобно и другим польза.
Если вы разобрались с каким-то фрагментом, который уже есть в базе - можно его закомментировать, опять же и для себя польза и другие скажут спасибо. Для стимулирования - могу ввести авторство комментариев. :)
В любом случае, некоторые части аварда уже декомпилируются практически на сто процентов. Если же взяться вместе - возможность перекомпилировать любой случайный биос - будет вовсе не фантастика, а банальная реальность... ;)
-- EDIT --
I've done correcting the issue you said above.
That's great. I've been thinking about it for a while and I know it can be done with IDA Pro. Actually I've already working on similar IDA plugin for some time, but still have some time constraint on it coz I'm working on it alone and I'm so busy this last few months :wink:.
Anyway, I decided to write the Award BIOS Reverse Engineering Guide back then so that more people will have access to such a knowledge. I only update the article when I have spare time in the weekend or so. We both have started this thing since bpoint working on it in 2002 IIRC. And you even may have started sometime before I started my own work. I've logged some of your conversation with bpoint (in his forum):wink:, to learn something from it. I hope you won't get mad because of it :lol:. But, back then I have no working knowledge in assembly language and I decided that I have to make an article that will "accelerate" others (like me back then) in learning this thing. I mean their learning curve won't be as steep as me with the presence of such an article :wink:
там есть код для изменения файла win.ini (или system.ini) для Win9x, в-общем из BIOS(!) в windows копируется программа-звонилка, которая заходит на сайт, принадлежавший Phoenix, если найду выложу куда-нибудь распакованный nnoporm. загрузочный экран у таких биосов графический - на белом фоне значки памяти, харда,и зелеными буквами там чего-то пишется Checking CPU,HDD и т.д. и еще показывается время.
OK, let me clarify, there is nothing wrong with the main concept explained in the article, i.e. the method used to inject new code into Award BIOS. But, there is something that can mislead people in the particular implementation explained there in the last section (Possible Downside and Its Workaround). I've made a "critical update" to address the issue in the latest version of the article in the following link:
Award BIOS Code Injection
To summarise, the issue is: in the original article I've claimed that the bug due to the race condition (in the sample injected-code) has been addressed, whereas, further experiment don't say so. Thus, I've carried out further experiments last week to find out the problem and has come-up with a thoroughly tested solution, i.e. a reworked patch.
well, I'll just paste the relevant code here to clarify.
#The sample injected-code in the original article (nasm syntax):
[code:1]
;---------------- BEGIN TWEAK.ASM --------------------------------------------------------------
BITS 16 ;just to make sure nasm prefix 66 to 32 bit instructions, we're assuming the uP
;is in 16 bits mode up to this point (from the boot state)
section .text
start:
pushf
push eax
push dx
mov eax,ioq_reg ;patch the ioq register of the chipset
mov dx,in_port
out dx,eax
mov dx,out_port
in eax,dx
or eax,ioq_mask
out dx,eax
mov eax,dram_reg ;patch the DRAM controller of the chipset,
mov dx,in_port ;i.e. the interleaving part
out dx,eax
mov dx,out_port
in eax,dx
or eax,dram_mask
out dx,eax
mov eax,bank_reg ;Allow pages of different bank to be active simultanoeusly
mov dx,in_port
out dx,eax
mov dx,out_port
in eax,dx
or eax,bank_mask
out dx,eax
mov eax,tlb_reg ;Activate Fast TLB lookup
mov dx,in_port
out dx,eax
mov dx,out_port
in eax,dx
or eax,tlb_mask
out dx,eax
pop dx
pop eax
popf
clc ;indicate that this POST routine successful
retn ;return near to the header of the rom file
section .data
in_port equ 0cf8h
out_port equ 0cfch
dram_mask equ 00020202h
dram_reg equ 80000064h
ioq_mask equ 00000080h
ioq_reg equ 80000050h
bank_mask equ 20000840h
bank_reg equ 80000068h
tlb_mask equ 00000008h
tlb_reg equ 8000006ch
;---------------- END TWEAK.ASM --------------------------------------------------------------
[/code:1]
This code causes the system to hang in certain circumstances.
#The reworked injected-code (fasm syntax)
[code:1]
;------------------------------ file: mem_optimize.asm -----------------------------------
use16
start:
pushf
cli
mov cx, 0x50 ;patch the ioq register of the chipset
call Read_PCI_Bus0_Byte
or al, 0x80
mov cx, 0x50
call Write_PCI_Bus0_Byte
mov cx, 0x64 ;DRAM Bank 0/1 Interleave = 4-way
call Read_PCI_Bus0_Byte
or al, 2
mov cx, 0x64
call Write_PCI_Bus0_Byte
mov cx, 0x65 ;DRAM Bank 2/3 Interleave = 4-way
call Read_PCI_Bus0_Byte
or al, 2
mov cx, 0x65
call Write_PCI_Bus0_Byte
mov cx, 0x66 ;DRAM Bank 4/5 Interleave = 4-way
call Read_PCI_Bus0_Byte
or al, 2
mov cx, 0x66
call Write_PCI_Bus0_Byte
mov cx, 0x67 ;DRAM Bank 6/7 Interleave = 4-way
call Read_PCI_Bus0_Byte
or al, 2
mov cx, 0x67
call Write_PCI_Bus0_Byte
mov cx, 0x68 ;Allow pages of different bank to be active simultanoeusly
call Read_PCI_Bus0_Byte
or al, 0x44
mov cx, 0x68
call Write_PCI_Bus0_Byte
mov cx, 0x69 ;Fast DRAM Precharge for Different Bank
call Read_PCI_Bus0_Byte
or al, 0x8
mov cx, 0x69
call Write_PCI_Bus0_Byte
mov cx, 0x6C ;Activate Fast TLB lookup
call Read_PCI_Bus0_Byte
or al, 0x8
mov cx, 0x6C
call Write_PCI_Bus0_Byte
popf
clc ;indicate that this POST routine successful
retn ;return near to the header of the rom file
;-- Read_PCI_Byte__ --
;in: cx = dev_func_offset_addr
;out: al = reg_value
Read_PCI_Bus0_Byte:
mov ax, 8000h
shl eax, 10h
mov ax, cx
and al, 0FCh
mov dx, 0CF8h
out dx, eax
mov dl, 0FCh ; '?'
mov al, cl
and al, 3
add dl, al
in al, dx
retn
;-- Write_Bus0_Byte --
;in: cx = dev_func_offset addr
;al = reg_value to write
Write_PCI_Bus0_Byte:
xchg ax, cx
shl ecx, 10h
xchg ax, cx
mov ax, 8000h
shl eax, 10h
mov ax, cx
and al, 0FCh
mov dx, 0CF8h
out dx, eax
add dl, 4
or dl, cl
mov eax, ecx
shr eax, 10h
out dx, al
retn
;------------------------------ file: mem_optimize.asm -----------------------------------
[/code:1]
This new patch (injected-code) is working flawlessly during the "patch-integrity" test, i.e. more than a hundred boot-reboot cycle :wink:
sorry for the inconvenience.
greetz,
Pinczakko