【我所認知的BIOS】—>Decompression

【我所認知的BIOS】—>Decompression

By LightSeed

2009-5-22

存在於BIOS的bin檔中的內容大多都是以模組的形式存在的。總所周知存在於裏面的模組都是有被壓縮的。這張我們就來探討一下關於模組的壓縮與解壓過程。這個章節裏同樣是針對於理解Awxxx公司的code。

1、LHA

1.1 LHA的背景

LHA是一種檔壓縮電腦軟體，也是此壓縮格式的名稱，其對應的副檔名有.lha及.lzh。發明人為日本的業餘程式設計師吉崎榮泰。擔任內科醫師的吉崎榮泰利用業餘時間，在奧村晴彥所發明的演算法的基礎上開發了名為LHarc的檔壓縮軟體及壓縮格式，1988年首次於網路上公開。1990年左右全面改寫程式，並改名為LHA。現在可能在別的國家用的不多了，但是在日本它仍是常見的壓縮格式之一。（來源於網路）

1.2 LZH的格式

要說明，LZH的header一共有三中級別。Level-0， Level-1和 Level-2。他們的數據格式如圖1。

圖1 Level-0， Level-1和 Level-2的格式區別

Level-0， Level-1和 Level-2的格式中各個byte的對應數據如下麵的三個列表。

level-0

Offset   Length   Contents

  0      1 byte   Size of archived file header (h)

  1      1 byte   Header checksum

  2      5 bytes  Method ID

  7      4 bytes  Compressed size (n)

 11      4 bytes  Uncompressed size

 15      4 bytes  Original file date/time (Generic time stamp)

 19      1 byte   File attribute

 20      1 byte   Level (0x00)

 21      1 byte   Filename / path length in bytes (f)

 22     (f)bytes  Filename / path

 22+(f)  2 bytes  CRC-16 of original file

 24+(f) (n)bytes  Compressed data

level-1

Offset   Length   Contents

  0      1 byte   Size of archived file header (h)

  1      1 byte   Header checksum

  2      5 bytes  Method ID

  7      4 bytes  Compressed size (n)

 11      4 bytes  Uncompressed size

 15      4 bytes  Original file date/time (Generic time stamp)

 19      1 byte   0x20

 20      1 byte   Level (0x01)

 21      1 byte   Filename / path length in bytes (f)

 22     (f)bytes  Filename / path

 22+(f)  2 bytes  CRC-16 of original file

 24+(f)  1 byte   OS ID

 25+(f)  2 bytes  Next header size(x) (0 means no extension header)

[ // Extension headers

         1 byte   Extension type

     (x)-3 bytes  Extension fields

         2 bytes  Next header size(x) (0 means no next extension header)

]*

        (n)bytes  Compressed data

level-2

Offset   Length   Contents

  0      2 byte   Total size of archived file header (h)

  2      5 bytes  Method ID

  7      4 bytes  Compressed size (n)

 11      4 bytes  Uncompressed size

 15      4 bytes  Original file time stamp(UNIX type, seconds since 1970)

 19      1 byte   Reserved

 20      1 byte   Level (0x02)

 21      2 bytes  CRC-16 of original file

 23      1 byte   OS ID

 24      2 bytes  Next header size(x) (0 means no extension header)

[

         1 byte   Extension type

     (x)-3 bytes  Extension fields

         2 bytes  Next header size(x) (0 means no next extension header)

]*

        (n)bytes  Compressed data

針對於其中Method ID有對應的解釋，見表1

表1 LHA的壓縮方法ID代表的意義

"-lh0-"	No compression
"-lh1-"	4k sliding dictionary(max 60 bytes) + dynamic Huffman + fixed encoding of position
"-lh2-"	8k sliding dictionary(max 256 bytes) + dynamic Huffman (Obsoleted)
"-lh3-"	8k sliding dictionary(max 256 bytes) + static Huffman (Obsoleted)
"-lh4-"	4k sliding dictionary(max 256 bytes) + static Huffman + improved encoding of position and trees
"-lh5-"	8k sliding dictionary(max 256 bytes) + static Huffman + improved encoding of position and trees
"-lh6-"	32k sliding dictionary(max 256 bytes) + static Huffman + improved encoding of position and trees
"-lh7-"	64k sliding dictionary(max 256 bytes) + static Huffman + improved encoding of position and trees
"-lzs-"	2k sliding dictionary(max 17 bytes)
"-lz4-"	No compression
"-lz5-"	4k sliding dictionary(max 17 bytes)
"-lhd-"	Directory (no compressed data)

2、解壓縮詳解

2.1解壓縮的準備知識

2.1.1 Cbrom的壓縮

AWxxx的code整個燒入ROM的BIOS.bin檔其實大多都是由cbrom以模組的形式壓入的。比如說我手上板子的BIOS就一共有8個模組。見圖2

 

圖2  BIOS模組

由圖中可知，不管是System BIOS還是PCI rom都是以模組的形式壓入到bin檔裏的。並且在cbrom壓入的過程中，會有相應的一些格式。這個結構如表2。

表2 被cbrom壓入的模組header

Offset from 1st byte	Offset in Real Header	Contents
00h	N/A	The header length of the component. It depends on the file/component name.
01h	N/A	The header 8-bit checksum, not including the first 2 bytes (header length and header checksum byte).
02h - 06h	00h - 04h	LZH Method ID (ASCII string signature). In my BIOS it's "-lh5-" which means: 8k sliding dictionary(max 256 bytes) + static Huffman + improved encoding of position and trees.
07h - 0Ah	05h - 08h	compressed file/component size in little endian dword value, i.e. MSB at 0Ah and so forth
0Bh - 0Eh	09h - 0Ch	Uncompressed file/component size in little endian dword value, i.e. MSB at 0Eh and so forth
0Fh - 10h	0Dh - 0Eh	Decompression offset address in little endian word value, i.e. MSB at 10h and so forth. The component will be decompressed into this offset address (real mode addressing is in effect here).
11h - 12h	0Fh - 10h	Decompression segment address in little endian word value, i.e. MSB at 12h and so forth. The component will be decompressed into this segment address (real mode addressing is in effect here).
13h	11h	File attribute. My BIOS components contain 20h here, which is normally found in LZH level-1 compressed file.
14h	12h	Level. My BIOS components contain 01h here, which means it's a LZH level-1 compressed file.
15h	13h	component filename name length in byte.
16h - [15h+filename_len]	14h - [13h+filename_len]	component filename (ASCII string)
[16h+filename_len] - [17h+filename_len]	[14h+filename_len] - [15h+filename_len]	file/component CRC-16 in little endian word value, i.e. MSB at [HeaderSize - 2h] and so forth.
[18h+filename_len]	[16h+filename_len]	Operating System ID. In my BIOS it's always 20h (ASCII space character) which don't resemble any LZH OS ID known to me.
[19h+filename_len] - [1Ah+filename_len]	[17h+filename_len] - [18h+filename_len]	Next header size. In my BIOS it's always 0000h which means no extension header.

值得一提的是，表中畫藍線的地方。這是被壓入bin檔中，模組將要被解壓縮到哪里去的地址。由於Cbrom是Awxxx出的工具，在解壓縮的過程中也是與之默契配合的。（筆者：基本上由cbrom壓入的模組，在解壓位址中都是在4000段中，至於具體位置會有點變化。這個會和index有關係。）見截圖3，它是在板子上BIOS.bin的system BIOS被cbrom壓縮後的二進位截圖。

 

 

 

解压缩的segment

圖3 bios.bin的二進位截圖

圖中可以清楚地看到表2中對應的各個offset的內容。不過還有一個有趣的事情就是每個被cbrom壓縮進BIOS.bin的模組最後一個byte必定是“00”。這是因為LHA壓縮產生的格式。您可以參見圖4看看我手上的BIOS bin檔中各個模組的最後一個位元組。我列出了幾個截圖，如果要查看每個模組的最後一個byte，可用ultraedit查看。

 

圖4 模組在bin檔中的last byte都為“00”

4、解壓縮過程

解壓縮的過程其實是很複雜的，我簡單地描述一下吧。（筆者，這個過程也不是我個人的力量，我參考了《Pinczakko's Guide to Award BIOS Reverse Engineering》這本書，在這裡也向大家強烈推薦。在後續的blog中我想我會逐一和大家分享和介紹一下這本書的各個章節。我很佩服這位作者。）

①                在bootblock的階段，BIOS code會把BIOS ROM裏面的全部二進位元檔都copy到RAM的高端地址。

②                首先解壓縮System BIOS這個模組。因為之後的操作都是在這個模組解壓縮出來的code中運行的。方法是code会首先搜索到第一个‘-lh’的字串，那么从这里开始必定是system BIOS的压缩模块。把他解压缩出来。（因为它是最重要的模块，所以必定被放在BIOS bin中的第一位置）。那么每个模块被解压缩出来的code是放到了哪里呢？这个就要参照表2中的header格式，在offset 11H~12H处就存放着解压出来的code将要存放的位置。kernel在处理的时候当然也会自动地把解压出来的code放在相应的地方。（笔者：提醒一下，在所有被壓進去的模組中，只有system BIOS模組是放在了5000H：0000H處，而其他模組都是被放在了4000H：0000H處。不信的話大家可以查看你自己手上的BIOS bin文件。可以詳細核對一下。當然前提必須是AWxxx的BIOS。）

③                解壓縮出來後的數據會最終被放到5000：0-6000：0處。然後程式會jmp到這裡來執行

④                進入POST過程，逐個把需要處理的模組解壓出來放到4000H：0000H處，然後再從這裡copy到目的RAM中，再做initial相應的設備。

5、壓縮實戰

http://download.pchome.net/utility/pack/download-4012.html 處可以下載到LHA.exe 這個軟體，讓我來和大家演練一下。CBROM把模組壓入到BIOS bin檔中的時候是調用了LHA這個軟體來做到的。

LHA的使用介紹就看看它的幫助應該就沒有問題了。我們先自己手動做一個LZH的檔吧，看看它的檔頭和之前我們探討是否一致。見圖5

 

圖5 用LHA創建壓縮檔過程

上面的大致操作是，先dir（查看當前目錄下）是否有sample.lzh的檔，返回資訊提示“file not found”。然後通過lha a sample.lzh sample.txt命令創建一個壓縮檔。

Lha：是指用LHA.exe這個軟體

A：  是指創建一個文檔

sample.lzh：壓縮檔的名字

sample.txt：被壓縮檔的名字

最後是查看是否存在sample.lzh文件，確實是存在的。而且壓縮比為52%。那麼我們來查看一下這個壓縮檔的檔頭格式，看看是否是我們bios中所看到的景象。見圖6

 

圖6 查看一下sample.lzh內容

圖6中，綠線框可以看到，出現了“-lh5”字樣，對比表格我們發現這就是我們BIOS中出現的格式。

到了我需要提醒一下的是，LHA在壓縮檔的時候，如果我們申明壓縮的級別那麼它是默認為level-1的，所以壓縮的method是“5”出現的是“-lh5” 那麼我們怎麼才能得到“-lh0”呢？（因為在BIOS code解壓縮的過程中會對這個進行處理，原因是“-lh0” 的壓縮方式其實就是沒壓縮。在解壓的時候可以直接copy，這樣的話可要快多了。）下面就讓我來展示一下怎麼製作“-lh0” 檔。如果大家有source code的話可以去看看，在解壓縮引擎中是否有對“0” 和“5”的判斷。

圖7展現了我操作LHA製作“-lh0”的壓縮level檔。

 

圖7 製作“-lh0”壓縮檔的過程

在命令行中出現了“-z”的字樣，z是zero compress的縮寫。壓縮比為100%，其實就是沒有壓縮。我們用debug查看它的時候看的很清楚出現了“-lh0”的字樣。這就證明了在source code的判斷確實是有這種情況存在的。只是平時被壓縮到bios bin檔中的格式都是“-lh5”而已。

 

至此，關於壓縮的這部份理解我的探討就這個地步，當然至於CBROM是怎麼用LHA的我還是不是很清楚，但是用LHA來實現bios bin文件中的格式我已經在這篇文章中有詳細的闡述了。如果對於這個壓縮還有什麽問題需要探討，我很希望能成為你的探討夥伴。