【我所認知的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壓縮後的二進位截圖。
圖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”而已。
</s
分享到:
相关推荐
下附软件文档部分说明:<br>Overview:<br> Functions provided by the library<br> Outline of typical usage<br>Basic library usage:<br> Data formats<br> Compression details<br> Decompression details<br> ...
不同于lee模型的,udf源代码,似乎比lee模型可以更精确
在这个名为"Compression-and-decompression.rar_decompression"的压缩包中,包含了两个关于压缩与解压缩的源码,一个是C++实现的RAR文件解压缩,另一个是使用MFC(Microsoft Foundation Classes)编写的ZIP文件压缩...
综上所述,"test.zip_decompression"项目涉及到了图像处理的关键技术,包括图像压缩与解压缩的原理和实现,特别是MATLAB编程在其中的应用。通过对图像进行分块、变换、量化等操作,实现了数据的高效存储和传输。同时...
综上所述,LZOAccel-D是一款高度优化的无损数据解压缩IP Core,不仅具备强大的解压缩性能和错误处理能力,而且还易于集成到现有的FPGA系统中。无论是对于需要高效数据处理的应用场景,还是对于希望减轻CPU负担的设计...
综上所述,"idct.rar_decompression" 的核心是基于DCT的图像解压缩技术,涉及了JPEG编码流程中的关键步骤——逆离散余弦变换。这个程序设计不仅需要理解和实现DCT与IDCT的数学原理,还要关注程序效率、内存管理、...
在这个“compression-and-decompression.rar_Huffman coding_decompression”项目中,开发者实现了一个基于Huffman编码的文件压缩和解压缩程序。这个程序不仅能够压缩文件,还能够计算压缩率,这是衡量压缩效果的一...
Initialization of a JPEG decompression object. The error manager must already be set up in case memory manager fails.
本项目"Image-Compression-Decompression-In-Java-master.zip_decompression"专注于使用Java实现图像的分形压缩与解压缩算法。下面我们将深入探讨这个话题。 首先,分形压缩是一种基于图像自相似性的无损压缩方法。...
compression and decompression
在实际应用中,像"compression and decompression.doc"这样的文档可能会详细阐述这些技术的实现细节,包括具体算法的步骤、参数设置、优化策略等。理解并掌握这些知识对于开发视频处理软件、优化传输效率或进行...
电脑还原系统报错出现:Decompression error Abort-.docx 本文档主要讲述了电脑还原系统报错出现 Decompression error Abort 的解决方法。该问题发生在还原系统镜像文件快完成的时候,出现 Decompression error ...
【标题】"jnd.rar_JND_decompression_其他" 提示我们关注的是一个与 JND(Java Naming and Directory Interface)相关的压缩文件,该文件可能包含了关于 JND 的学习资料和案例,但没有提及解压密码。 【描述】"D8...
标题"rle.rar_RLE_decompression"指的是使用RLE压缩算法的文件进行了压缩,文件名为"rle.rar",这通常是一个RAR格式的压缩文件,其中包含了经过RLE压缩的数据。RAR是一种流行的压缩格式,支持多种压缩算法,RLE可能...
ppp_deflate.c - interface the zlib procedures for Deflate compression and decompression (as used by gzip) to the PPP code.
本文将深入探讨标题为"Compression/Decompression-开源"的项目,该项目专注于优化txt文本文件的压缩。 首先,我们来看看"Compression.exe"和"Decompression.exe"这两个文件。它们分别代表了压缩和解压缩的执行程序...
在"Decompression.zip"这个例子中,文件名列表仅有一个"Decompression",这可能是一个包含多个源代码文件的压缩包,供开发者参考学习。 解压ZIP文件时,程序会读取ZIP文件头中的信息,识别出每个存档项的位置和压缩...
标题中的"Deskfilter_FIRfilter_decompression_lake3me_"暗示了这个压缩包与数字信号处理有关,特别是涉及FIR滤波器(Finite Impulse Response Filter)的压缩和解压缩技术,以及可能的一个名为"lake3me"的特定算法...