欧美vvv,亚洲第一成人在线,亚洲成人欧美日韩在线观看,日本猛少妇猛色XXXXX猛叫

本文內容非商業用途可無需授權轉載，請務必注明作者、微博ID：唐僧_huangliang，以便更好地與讀者互動。

作者簡介：

王之業，現就職于Arcserve，任開發經理。長期從事數據備份與恢復領域研發與管理工作，對行業發展高度關注，同時對數據保護與恢復有自己非常獨到的見解。

原文地址：http://www.docin.com/p-1843467578.html

Windows 其實可以支持多種引導方式。 除了本地硬盤引導外，還有例如PXE引導、iSCSI引導、RAM Disk引導、VHD引導等。但本文將只關注磁盤引導的方式。

這里展示的分區布局是全新安裝的情況。 如果從老系統（例Windows XP）升級上來，則仍然會保持和原來的分區布局一樣。也就是說，Windows 7等可以工作在以前的分區布局上。

BitLocker是微軟Vista時增加的功能。它對整個磁盤卷進行加密保護。后面還會不斷地被提到。在Windows引導過程中，很多地方都在考慮BitLocker的特殊需求。

WinRE，即Windows Recovery Environment。用于修復Windows的引導故障。如果Windows在引導過程中遇到問題，會自動入該環境。

MBR，即Master Boot Record。它是最常見式雖已經（雖然已經有被UEFI引導替代的趨勢）。這里會首先詳細介紹MBR引導的每個階段，直到第一個用戶態進程出現為止。

先上一張圖。 這個圖和上次介紹Grub 2引導過程時展示的圖類似。它主要描述了引導過程的每個階段，以及所涉及磁盤存儲的位置、內存地址和CPU模式的情況。

你可能會注意到MBR的內存載入和PBR是一樣的。確實如此。MBR中的程序代碼將自身從內存0x7C00的位置復制到0x0600的位置，而后把PBR讀入到0x7C00。后面有更多相關介紹。BootMgr首先被載入到內存地址0x20000的位置，而它的后半部分（bootmgr.exe）會被重新定位到0x400000的位置。

TPM，即Trusted Platform Module。一個可以提供秘鑰創建和保存，以及加密解密功能的芯片。Windows的BitLocker就是利用TPM來實現最高安全可靠性的。所以TPM在后面會被多次提到。PCR即Platform Configuration Register，是TPM內部的寄存器。TPM一般有16到24個寄存器。BitLocker使用了其中的8個。

上面只是從BIOS開始介紹引導過程。實際在系統加電后，TPM會首先驗證自身的完整性，然后計算BIOS固件的哈希值，最后才是計算MBR的哈希值。 每一部都會把結果存放在TPM的PCR的不同寄存器中。

MBR是磁盤的第一個扇區。其中包含啟動代碼、磁盤ID，分區表。

有人可能會問，MBR作為從磁盤讀上來的第一塊數據，為什么要放在內存0x7C00的位置，而不是放在內存的開始處，或者內存的結尾處？其實，在最初設計的時候（30多年前），0x7C00就是內存的結尾處。那時候內存只有32KB大小。而內存開始的位置，一般被用于存放中斷向量和BIOS的一些數據。后來，為了保持兼容，這個規則就一直這么延續下來了。

A20地址線是另一個關于“兼容”的故事。A20實際是第21條CPU地址線（計算機的世界里都是從零開始計數的）。它對應的是1MB之后的內存地址。早期的Intel 8086 只能訪問1MB的內存。如果內存尋址超出了1MB，就會重新從零開始（相當與取模計算）。當時有些軟見就利用這個特性來提高內存訪問效率。后續的CPU雖然提高了內存尋址范圍，但為了兼容當時的現有軟件，不得不在CPU處于實模式的時候，繼續模擬8086的行為。遺憾的是，Intel 80286 在出廠后才發現沒有處理好這個兼容問題。當時的PC制造商IBM決定自己在主板上解決這個問題：在A20地址線上加個開關，并讓它缺省處于關閉狀態。估計當時的工程師急于快速解決問題，竟然把對這個開關的控制關聯在了主板的鍵盤控制器上。所以MBR中的代碼會通過向鍵盤控制器的端口發送指令來打開A20地址線。

TCG_CompactHashLogExtendEvent 是TPM規范中定義的例程的名字。MBR代碼通過中斷INT 1A來調用這個例程。

以上是MBR在磁盤上的數據。

從0x0到0x1B7之間為啟動代碼（或者錯誤信息字符串）。從Windows 7到Windows 10，這部分代碼沒有變化。

從0x1B8開始的四個字節為磁盤ID，唯一標識當前系統正在使用的一塊磁盤。顯然，只有四個字節，是無法全局唯一標識磁盤的。這里可能有人會有疑問：如果克隆了一個磁盤，并掛接在同一個系統里，那不就重復嗎？Windows在啟用一個磁盤的時候，它的磁盤驅動程序會首先檢查這個磁盤ID。如果發現和現有磁盤重復，就會重新分配一個隨機ID給這個磁盤。

0x1BE到0x1FD之間為4條分區表記錄。每條記錄16個字節。

第一個分區的標志位為0x80，所以是活動分區。MBR代碼會讀入這個分區的第一個扇區，并繼續引導過程。上圖中每個分區的類型都為0x07，即NTFS文件系統的分區。當前基于BIOS的引導方式有兩種磁盤尋址方法：CHS和LBA。CHS即柱面（Cylinder）、磁頭（Head）和扇區（Sector），聽起來與磁盤結構強相關，但也是所有硬件都支持的方法；LAB即Logical Block Addressing，從0開始按扇區數量定位磁盤上的數據塊。應該說現在的硬件也都支持LBA了，但10多年前生產的設備就不一定了。

最后兩個字節即為引導扇區標志位了。

PBR本身在內存0x7C00的位置，512字節長。而它把后續15個扇區讀入到0x7E00的位置，相當于在內存中是緊接著PBR存放的。其實，后續15個扇區中的代碼需要引用PBR代碼中定義的函數。這樣的布局也便于代碼調用。

以上是PBR在磁盤上的數據。以下的介紹將以0x100000作為基址。

開頭3個字節是一條跳轉指令。跳轉到0x54繼續執行。也就是說0x54后面都是代碼了（或者錯誤信息字符串），除了最后兩個字節為引導標志位。從Windows 7到Windows 10，這部分代碼總體上變化不大。

從0x03到0x53之間的空間存儲了文件系統的重要信息。可以和Linux文件系統的super block相對應。

從0x03到0x0A之間的8個字節為文件系統的標志字符串。這里是NTFS文件系統。沒有用完的空間用空格填充。NTFS視整個磁盤卷為固定長度數據塊組成的數組。這個“固定長度數據塊”被稱為cluster。

NTFS將cluster作為磁盤的最小訪問單位。Cluster的大小就記錄在0x0D的位置。Cluster可以對應為Linux文件系統中的block。

MBR代碼在寄存器DL里存儲了當前引導磁盤的驅動器號（一般為0x80）。PBR代碼把這一信息存儲在偏移0x0E（一個字節）對應的內存位置，以供PBR后續代碼及Boot Area代碼使用。

這里就不一一解釋后續的每個字段了。圖中特別給出了File Record Segment（MFT中每個文件記錄占用的字節數）和Index Block（索引塊占用的字節數）的計算方法。特別之處在于如何處理當這些字段為負數的情況。

這里我們把PBR之后的15個扇區稱之為引導區域。它基本上都是代碼（或錯誤信息字符串，預留變量空間）。

這部分代碼在Windows 8的時候做了增強，就是為了支持Windows To Go。Windows To Go就是將整個Windows操作系統安裝在U盤上。然后你就可以把這個U盤插在任何一個電腦上，并讓電腦運行U盤中的操作系統。如果電腦的硬盤上已經安裝了Windows 7操作系統，那你需要修改BIOS中的啟動順序設置，以讓電腦從U盤啟動。如果是Windows 8或之后的操作系統，你可以運行一個命令行“pwlanucher /enable”，然后重啟系統，電腦就會自動從U盤啟動了（原理如上文描述）。其實準確地說，這個命令行只是讓電腦從第二塊可啟動盤上啟動（即使這第二個盤不是U盤，電腦也會從它啟動）。

引導區域的代碼很短，但卻可以讀取NTFS文件系統中的文件。這一方面是代碼寫的精煉，另一方面，NTFS的設計也使得讀取操作可以很簡單。這一節我們快速了解一下NTFS最基本的結構。注意：上圖為示意圖，并非與NTFS內部數據結構一一對應。

NTFS的核心叫做Master File Table（MFT），即主文件表。這是一個由固定長度（一般為1KB）記錄組成的數組。它在磁盤卷上的位置，以及每個記錄的長度都保存的啟動扇區（PBR）里。文件系統中的每個文件（包括元數據文件，目錄和普通文件）都會在MFT中至少對應一條記錄（如果文件屬性很多，則會有多條記錄）。MFT的前幾條記錄固定對應一些重要的元數據文件。例如，第一條記錄描述的就是MFT自身（在NTFS中，任何數據都屬于一個文件，這包括MFT自身，乃至啟動扇區。不存在不屬于任何文件的數據塊。）。描述根目錄的記錄也在其中（NTFS根目錄的名字是一個英文句點。為了看得清楚，上圖中用$Root替代了。），它在MFT中的記錄編號固定為5（記錄號從0開始）。

每條MFT記錄有固定的開始標志“FILE”和結束標志0xFFFFFFFF。他們之間的數據即為該記錄的實際內容。文件的各種信息是以不同的屬性來分類描述的。例如：標準信息屬性（類型0x10）里包含了文件的各種時間戳和權限。當然我們最關心的是文件名字和數據的位置，它們被分別記錄在類型為0x30和0x80（目錄為0xA0）的屬性里。與文件名字一同記錄的還有該文件的父目錄的MFT號。

如圖所示，對于一個文件，如果它的數據足夠少，就直接把數據存儲在MFT記錄剩余的空間里。否則，MFT記錄的屬性里會包含一個結構數組指明數據在磁盤卷上的位置。數組中的每個結構體描述了文件數據的一個連續的部分。結構體的第一個成員是開始VCN（Virtual Cluster Number，以cluster塊為單位，在文件內部的偏移）；第二個成員是開始LCN（Logical Cluster Number，以cluster塊為單位，在磁盤卷上的偏移）；第三個成員為當前結構體所描述的連續cluster的數量。其實這只是為了便于說明原理的示意圖。為了節省空間，NTFS在實踐中采取下面的結構：

{

size; //一個字節，無符號整數，決定后續兩個成員的長度

cluster_count; //cluster的數量，無符號整數，長度由size的低4位決定

relative_lcn; //相對于前一個LCN的位置，有符號整數，長度由size的高4位決定

}

當此結構體是數組中第一個元素的時候，relative_lcn的值為文件系統的LCN；而當其為后續元素時，relative_lcn的值為相對于前一個元素所指明的LCN的相對位置。負數向前偏移，正數向后偏移。

目錄可以被認為是包含一系列文件和子目錄名字列表的文件，只是它的內容是以B樹結構來存儲的。這是為了能夠在目錄中快速查找文件。B樹的每個節點會保存多條目錄索引塊。每個目錄索引塊描述了一個文件或子目錄。每個目錄索引塊中當然得有文件名，還有就是該文件的MFT號（用于找到這個文件在MFT中的記錄）。此外還有文件大小和時間戳等信息，這是便于在目錄瀏覽時，能快速列出文件的最基本信息（但這顯然給文件的寫操作帶來了麻煩）。

了解了以上信息，你可能已經想到如何在文件系統中找到根目錄下的BootMgr文件了。一個最簡單的方法：枚舉MFT中的所有記錄，直到找到一個文件名為BootMgr，并且父目錄MFT號為5的記錄。在運氣比較差的時候，這個方法的效率會比較低，可能需要枚舉所有的文件和目錄才能找到BootMgr。

看起來，通過解析根目錄的內容來獲得BootMgr在MFT中的位置并不是必須的。但Windows的代碼實現似乎還是解析了根目錄（筆者沒有完整分析這部分匯編代碼）。

現在終于到了C語言寫的程序了（此前的程序都是用匯編語言直接寫的）。

BootMgr存在于系統保留分區的根目錄。無論最終操作系統是32位的還是64位的，它都是由以下幾部分組成：16位實模式代碼（startup.com），16字節頭信息（包括：壓縮算法簽名BMCI或BMXH，壓縮前后數據的長度，壓縮數據的偏移），8KB的PE格式的資源數據，經過壓縮的32位PE格式的bootmgr.exe代碼。

Startup.com中的代碼會解壓bootmgr.exe并驗證其數據完整性。

BootMgr具備對NTFS文件系統的解析功能。所以它可以從磁盤卷上讀取文件。為了提高系統的易用性，BootMgr會記錄系統引導的每個階段的結果，以便在下次引導時可以對上次引導遇到的問題自動進行處理（例如進入修復模式）。這意味著它還需要能夠寫文件。要知道一個文件系統最復雜的部分就是對寫操作的支持。為了簡化實現，\Boot\bootstat.dat是一個空間預分配文件。BootMgr可以先得到這個文件在磁盤卷上所占用的數據塊列表，然后按塊直接寫磁盤卷。

bootstat.dat文件大小為固定64KB。文件開頭為16字節的文件頭信息，記錄了文件的版本和有效數據長度等信息。其后是引導事件記錄。每條記錄由記錄頭（包含時間、記錄長度和錯誤代碼等信息）和記錄數據組成。BootMgr階段可能出現的錯誤包括無法載入系統引導程序、無法載入BCD文件、以及BCD配置錯誤等。

在WinDbg里，你可能會發現WinLoad被載入到內存的地址似乎是固定的。實際上并非如此。BootMgr有一套內存管理函數。需要用到內存的地方會先分配，再使用，不用了就釋放。WinLoad鏡像所占用的內存也是如此。在WinLoad被載入前，已經有很多內存分配和釋放的調用。如果把釋放函數的代碼在內存中修改為空函數，就可以發現WinLoad被載入的地址明顯后移。這說明WinLoad被載入內存的地址并非是固定的。

一個操作系統可以有很多方法確保數據安全，但前提是操作系統自身的代碼沒有被修改過。為此，從BootMgr開始，每個模塊都會對其載入的可執行程序做數字簽名驗證。BootMgr內置了根公鑰，用于驗證后續載入模塊（如WinLoad.exe）的數字簽名。但BootMgr只能自己驗證自己。這顯然是一個“雞生蛋，蛋生雞”的問題。從這個角度看，當沒有諸如TPM或UEFI Secure Boot等外部支持的情況下，BootMgr是整個Windows操作系統的安全薄弱環節。

BCD文件同時為BootMgr、WinLoad和Windows內核提供配置參數。它告訴BootMgr系統引導程序（WinLoad.exe）的位置；告訴WinLoad應該使用哪一個內核程序；而WinLoad則會把BCD文件中配置的內核參數傳遞給內核。BCD文件中可以保存多組配置信息。

從BootMgr開始，我們可以用WinDbg調試引導過程。微軟為BootMgr和WinLoad提供了函數符號。這對了解引導過程的一些細節會很有幫助。使BootMgr以及后續的WinLoad和Windows內核進入調試模式的參數也是記錄在BCD文件中。（關于調試引導過程的細節會在后面的“高級話題”中介紹）

這里特別關注了系統磁盤和系統引導程序的路徑是如何被記錄的。左邊黑窗口是bcdedit輸出的內容。這里描述的系統磁盤是經過bcdedit翻譯之后的結果。內部存儲情況要看右邊注冊表中的內容。我們可以看出，Windows在這個階段是通過Disk ID來識別磁盤，通過相對磁盤開始位置的偏移來識別卷。

到此終于要單獨介紹一下BitLocker了。前面幾乎每一節都有BitLocker的身影。

對于一臺計算機來講，衡量其安全性需要考察兩個階段：在操作系統正常運行之后，可以由操作系統的安全策略（如賬戶登錄，權限控制等）和文件級別的加密來確保用戶數據的安全；而在操作系統正常運行之前，就需要像類似于BitLocker這樣的功能。它的重要功能之一就是確保操作系統本身是安全的（未被篡改），否則后續的安全的價值都會大打折扣。BitLocker可以用于加密操作系統所在的磁盤卷，也可以用于加密數據磁盤卷。

BitLocker用FVEK加密數據，再用VMK加密FVEK。這樣的策略是為了便于更換秘鑰。當有更換秘鑰的需求時，只需要更換VMK，而FVEK可以保持不變。要知道FVEK的變化意味著需要解密然后重新加密整個磁盤卷，難免要花很長時間。

BitLocker可以利用TPM來提高安全性。引導過程每個階段的代碼（或在固件里，或在磁盤上）都被計算了哈希值，并存于TPM的PCR寄存器里。這些哈希值與TPM內部的秘鑰一起被用于解密VMK：只有它們和加密VMK時的值相一致時，才有可能解密成功。這可以阻止引導的早期階段的安全攻擊（在MBR等匯編語言階段植入惡意程序）。這也意味著硬盤與計算機主板之間的綁定：即使把硬盤拔下來，再插到其他機器上，也是無法解密的。其實，這種方法甚至意味著你對BIOS設置做一點改動，都會導致無法解密。這個時候恢復秘鑰就派上用場了。

BitLocker的最高安全策略是用TPM(what it is) + USB Key (what you have) + PIN(what you know)來保護VMK。當然也可以只以一個口令來保護VMK。Windows缺省的安全策略并不允許在沒有TPM支持的情況下使用BitLocker保護系統所在的磁盤卷。如果你很想嘗試一下BitLocker但又沒有支持TPM的計算機，可以使用gpedit.msc修改如下安全策略，之后就可以使用口令來保護系統所在的磁盤卷了。

BitLocker不僅可以用于本地硬盤卷的加密，還可以用于U盤的加密。

WinLoad.exe一般位于C:\Windows\System32\WinLoad.exe。順便說一句，你在C:\Windows下看到的大多數文件（EXE, DLL, MUI等）都是到C:\Windows\winsxs里對應文件的硬連接。也就是說這些文件本身被安裝在C:\Windows\winsxs目錄下。Windows用這種方法來解決可執行程序不同模塊之間版本的匹配問題。進一步的細節可以在網上搜索一下。

系統注冊表文件在引導過程中扮演著非常重要的角色。除了少數一些文件是WinLoad根據內置列表載入之外，其他大部分文件都是根據注冊表的配置載入的。

Windows的注冊表不僅從外觀上看像是文件系統（通過regedit.exe瀏覽），其內部結構也像是一個文件系統。它把全部空間按4KB分塊管理，就像是文件系統的“cluster”。這也是它分配空間的最小單元。文件開頭的4KB叫base block，記錄了全局重要信息（以字符串“regf”為簽名標記），就像是文件系統的引導扇區。一個或多個4KB組成一個bin，就像是文件系統的“run”或“extent”。Bin可以被認為是cell的容器。它的開頭為32字節的頭部信息（以字符串“hbin”為簽名標記），緊隨其后就是一個或多個cell。一個cell包括4字節的長度信息和變長的數據信息。Cell用于存儲單個key，或value，或注冊表中的其他對象。當然，用了一段時間之后，注冊表文件也會像文件系統那樣出現碎片。

除BCD外，Windows系統的注冊表文件都存在于C:\Windows\System32\config目錄下。如果你開啟了“顯示隱藏文件”功能，你會發現每個注冊表文件都伴隨有多個日志文件。這些日志文件用于確保注冊表更新后保持數據一致性。Windows每隔5秒鐘將內存中對注冊表的修改刷新到日志文件，然后再將日志的內容刷新的注冊表文件中。如果在刷新注冊表文件過程中出現系統故障，可以在系統重啟后根據日志文件從頭再次刷新。

WinLoad實際上會載入兩個注冊表文件: SYSTEM 和 ELAM（從Windows 8開始）。前者用于保存系統配置，后者是那些需要早期載入的反病毒驅動程序的配置（早期載入以監控引導型驅動程序）。WinLoad會將這兩個注冊表文件整個讀入內存（所以他們的大小是有限制的）。然后，如果需要的話，根據日志重新刷新內存中的注冊表（WinLoad是不會寫注冊表的）。

Ntoskrnl.exe即是Windows內核程序。HAL.dll名字的含義為Hardware Abstraction Layer，是內核用于跟硬件交互的函數庫。每種硬件平臺會有自己的HAL.dll。CI.dll用于代碼完整性校驗；PSSHED.dll是一個與硬件錯誤報告相關的動態庫；BootVID.dll用于支持VGA顯示模式。還有其他一些文件，這里沒有都列出來。

WinLoad會驗證它載入的程序的數字簽名。它會將每個程序的簽名和存在于硬盤上的catalog文件（C:\Windows\System32\catroot目錄下）中的標準簽名進行對比。如果比較失敗，就停止引導，打印錯誤信息以及出問題的文件的名字。為了確保catalog文件沒有被修改過，WinLoad還需要驗證catalog文件的數字簽名。而用于驗證的公鑰證書就內置在WinLoad文件內部。WinLoad自身的數字簽名可以被BootMgr驗證，所以不用擔心有人修改WinLoad的代碼繞過這些驗證。

bootstat.dat文件在這里再次出現，只是這次它是在C:\Windows目錄下。這個文件會被WinLoad、內核以及第一個用戶態程序smss.exe共享使用。它的作用是讓WinLoad了解上次引導（或關機）的情況，以決定是否顯示對應的選項（系統修復、安全模式等）。它的格式和BootMgr的那個bootstat.dat文件基本相同，只是在64KB的前面加了一段長度為0x800字節的數據。所以它的大小固定為66KB。目前還不清楚這額外0x800字節的用途。

注：本文只代表作者個人觀點，與任何組織機構無關，如有錯誤和不足之處歡迎在留言中批評指正。進一步交流技術，可以加我的QQ/微信：490834312。如果您想在這個公眾號上分享自己的技術干貨，也歡迎聯系我：）

尊重知識，轉載時請保留全文。感謝您的閱讀和支持！《企業存儲技術》微信公眾號：huangliang_storage

原文鏈接：http://mp.weixin.qq.com/s?__biz=MzAwODExNjI3NA==&mid=2649775489&idx=1&sn=d8f460a7273255cd27e4778c6dacf6fa&chksm=83773cdcb400b5ca368a9e4c3e8510273fe906dce8d72e7c4e9da475f25bd5ba54507f5fdf8d#rd