一、前言

本文是覆蓋基于虛擬化的安全和設備保護功能的文章的一部分。這些文章的目的是從技術的角度分享這些功能以便更好的理解。這第一篇文章將涵蓋系統引導過程，從Windows bootloader到VTL0啟動。

二、基于虛擬化的安全

基于虛擬化的安全(VBS)是微軟Windows10和Windows Server2016的一個主要的安全特性。例如，DeviceGuard和CredentialGuard都依賴它。DeviceGuard允許系統阻止任何不受信任的程序。同時CredentialGuard允許系統隔離lsass.exe進程，以便阻止類似Mimikatz等工具內存讀取密碼。

這個新功能的主要思想是使用硬件虛擬化技術(例如Intel VT-x)，以便在兩個虛擬機(VM)之間實現強隔離，并且將來功能可能更豐富。這些技術允許虛擬機管理器(VMM)使用擴展頁表(EPT)來對物理頁設置不同的權限。換句話說，一個VM能夠在它的頁表入口(PTE)設置一個物理頁可寫(+W)，并且VMM能夠通過在它的EPT上設置適當的權限來授權或阻止這種行為。

基于虛擬化的安全依賴Hyper-V技術，其將產生不同虛擬信任等級(VTL)的虛擬機。Hyper-V包括一個hypervisor，并且任何操作系統，甚至主操作系統，都包含在VM中。這個主操作系統(Windows)被認為是根VM。Hyper-V信任它且接受像控制其他VM的管理命令。其他的VM可能是“開明的”，如果這樣，則向Hyper-V發送受限消息以便他們自己管理。

VTL是有序號的，更高的是最受信任的。現在有兩個VTL：

1. VTL0，是一個普通的環境，且基本包含標準的Windows操作系統。

2. VTL1，是一個安全的環境，且包含一個微內核和安全的應用程序，稱為trustlet。

圖1 – 基于虛擬化的安全的概覽

CredentialGuard安全機制使用這個技術在VTL1 trustlet(lsaiso.exe，上圖中“Isolated LSA”)中隔離關鍵的lsass.exe進程，甚至使得VTL0內核不能訪問它的內存。只有消息可以從VTL0轉發到隔離的進程，有效的阻止了像Mimikatz這類的密碼和哈希收集工具。

DeviceGuard安全機制使得VTL0內核地址空間的W^X內存緩解(物理頁不能同時具有可執行和可寫權限)，并且接受包含授權代碼簽名者的策略。如果VTL0內核想要使一個物理頁可執行，它必須請求VTL1來改變(圖中的“HVCI”)，它會根據策略校驗簽名。對于用戶模式的代碼，這不起作用，只有VTL0內核才請求簽名驗證。策略在引導啟動時加載，且之后不能修改，只有強制用戶重啟才能加載新的策略。

策略也是被簽名的：在這種情況下，授權簽名者在UEFI變量中設置，且新的策略將校驗這個簽名者。UEFI變量設置他們的Setup和Boot標志，意味著在啟動后他們將無法被訪問和修改。為了清除這些變量，本地用戶必須使用一個自定義的微軟EFI bootloader重啟，在用戶交互操作(通過輸入密碼)后移除他們。

因此，VBS強依賴SecureBoot。引導加載器的完整性必須被校驗，因為它負責加載策略、Hyper-V和VTL1等等。

如果你對設備保護的細節感興趣，你能閱讀這個MDSN的文章：https://blogs.technet.microsoft.com/ash/2016/03/02/windows-10-device-guard-and-credential-guard-demystified/。

我們也鼓勵你閱讀Alex lonescu和Rafal Wojtczuk的BlackHat 2015/2016的演講，將有很大幫助：

http://www.alex-ionescu.com/blackhat2015.pdf

https://www.youtube.com/watch?v=LqaWIn4y26E

https://www.blackhat.com/docs/us-16/materials/us-16-Wojtczuk-Analysis-Of-The-Attack-Surface-Of-Windows-10-Virtualization-Based-Security.pdf

https://www.blackhat.com/docs/us-16/materials/us-16-Wojtczuk-Analysis-Of-The-Attack-Surface-Of-Windows-10-Virtualization-Based-Security-wp.pdf

https://www.youtube.com/watch?v=_646Gmr_uo0

本文中，我們將涵蓋系統引導過程，從Windows bootloader到VTL0啟動。為了分析VBS怎么在引導過程期間初始化自身，下面的Windows 10 1607的一些文件已經被逆向過了：

• Bootmgr.efi：EFI引導加載器(一小部分)
• Winload.efi：EFI Windows加載器
• Hvix.exe：Hyper-V(相當小的一部分)
• Ntoskrnl.exe：NTOS內核
• Securekernel.exe：安全內核
• Ci.dll：VTL0代碼完整性
• Skci.dll：VTL1代碼完整性

因此讓我們來深入到VBS引導過程中，從winload.efi的執行開始，到ntoskrnl.exe的入口點執行。

三、引導過程

引導過程可以總結為5個必須的步驟：

• Bootmgr.efi是第一個加載的組件。由SecureBoot驗證并執行
• Bootmgr.efi加載并校驗winload.efi
• Winload加載并校驗VBS配置
• Winload加載并校驗Hyper-V和VTL0/VTL1內核組件
• Winload退出EFI模式，啟動Hyper-V

1. Bootmgr.efi

當系統開始引導，bootmgr.efi是第一個被加載執行的。它的完整性和簽名已經由Secure Boot UEFI代碼校驗過。為了能夠識別過期的簽名，DBX數據庫包含了過期的簽名(截至2016年底，這個數據庫包含了71個黑名單和未知的SHA256的哈希值)。在bootmgr.efi的最后，執行將轉到winload.efi的入口點：OslpMain/OslMain。

OslpMain首先調用OslpPrepareTarget，其是winload.efi的核心函數。它將初始化hypervisor，內核等。但是先會使用OslSetVsmPolicy初始化VBS配置。

2. VBS策略加載

OslSetVsmPolicy首先校驗VbsPolicyDisabled EFI變量的值(參見下面的微軟命名空間)。如果設置了，這個變量是0，意味著沒有憑據保護配置將要加載。這個EFI變量因此將在引導時禁用憑據保護(并且能夠在VTL0 ring3調用設置權限)。如果沒有設置，配置將從SYSTEM注冊表的hive中加載，并且由BlVsmSetSystemPolicy調用執行，其將讀取和更新VbsPolicy EFI 變量。相應的值被存儲到全局變量BlVsmpSystemPolicy中。如果UEFI鎖開啟，這個EFI變量被設置，并且不能通過winload.efi禁用(它不能移除它，只能使用自定義的EFI代碼才能)。

函數OslpPrepareTarget也會調用OslpProcessSIPolicy(被調用兩次，第一次直接從函數OslInitializeCodeIntegrity中調用)。OslpProcessSIPolicy使用3個EFI變量“pools”來校驗SI策略簽名。每個pool包含3個EFI變量，第一個包含策略，第二個包含版本，第三個包含授權的策略更新簽名者。例如，對于C:\Windows\System32\CodeIntegrity\SIPolicy.p7b，變量是Si，SiPolicyVersion和SiPolicyUpdateSigners。如果“version”和“update signers”變量被設置，系統將增強SI策略簽名：它必須是存在且正確的簽名，否則引導將失敗。通過BlSiPolicyIsSignedPolicyRequired函數來驗證它自己。

3種策略和相關的變量總結如下：

我們不確定“revokeSiPolicy”和“skuPolicy”的目的，但是他們似乎和普通的“SiPolicy”使用類似。

3. Hyper-V和內核組件的加載

執行將轉移到OslArchHypervisorSetup函數，其需要使用與執行的步驟相應的參數來調用，從0開始。在第一次，它將初始化Hyper-V(加載hvloader.efi且通過HvlpLaunchHvLoader執行它)。SecureBoot設置通過OslInitializeCodeIntegrity來校驗。

OslpPrepareTarget然后加載NTOS內核(ntoskrnl.exe)，并且使用OslpLoadAllModules函數來加載hal.dll和mcupdate.dll模塊。然后“Local Key”和“Identification Key”由OslVsmProvisionLKey和OslVsmProvisionIdk函數加載。

此時，NTOS內核初始化了但還沒喲啟動。以步驟“0”為參數的OslVsmSetup被調用(與OslArchHypervisorSetup一樣：以“步驟”為參數)，首先校驗Hyper-V已經啟動，然后初始化OslVsmLoaderBlock(參數在初始化期間由安全內核提供)。然后，OslVsmSetup加載安全內核(securekernel.exe)，并且通過OslpVsmLoadModules函數加載它依賴的skci.dll(OslLoadImage再次被用來校驗他們的簽名)。EFI變量OslLoaderIndications第一位被設置為1。

最后，OslVsmSetup函數再次被調用，但是參數是步驟“1”。這個觸發了OslVsmLoaderBlock的初始化。

當函數OslpPrepareTarget返回后，VBS參數已經被驗證完了，并且NTOS和安全內核都被加載了。他們的入口點地址被存儲在全局變量OslpVsmSystemStartup和OslEntryPoint中(securekernel.exe和ntoskrnl.exe)以便將來使用。

四、微軟EFI變量

VBS EFI變量屬于命名空間：{0x77FA9ABD, 0x0359, 0x4D32, 0xBD, 0x60, 0x28, 0xF4, 0xE7, 0x8F, 0x78, 0x4B}。這些變量有他們的“Boot”和“Setup”屬性設置，因此在EFI引導階段后他們的訪問和修改是不被允許的。

然而轉儲他們是可能的，以便在逆向分析中使用。與VBS相關的EFI變量和他們響應的用法總結如下：

為了轉儲這些變量的內容，關閉安全啟動和使用一個簡單的EFI自定義的引導啟動器(gnu-efi和VisualStudio能完美實現)。一些變量轉儲如下：

五、Hyper-V和安全內核啟動

回到OslpPrepareTarget，現在開始執行啟動Hyper-V和分割VTL0及VTL1空間。這個過程總結如下：

Winload在“第一個“Hyper-V VM中運行

Winload調用安全內核的入口點(EP)

securekernel初始化自身，請求Hyper-V內存保護

securekernel請求VTL1驗證

Hyper-V啟用VTL1(“第二個“VM)，在ShvlpVtlEntry中返回

通過ShvlpVtlReturn，securekernel(現在是VTL1)返回到winload(現在是VTL0)

Winload調用ntoskrnl入口點

下面是securekernel初始化前后的狀態(VTL0 VM是藍色塊，VTL1是綠色塊，Hyper-V是橙色塊)：

圖2 – securekernel初始化前后的狀態對比

繼續執行，通過調用OslFwpKernelSetupPhase1退出EFI模式，并且以“1“參數調用OslArchHypervisorSetup啟動Hyper-V。Hvix64通過向HvlpSavedRsp保存的RSP啟動并且將HvlReturnFromHypervisor傳給hvix64。當HvlpReturnFromHypervisor被命中，使用cpuid指令來驗證啟動，并且RSP被重置。我們確實處在第一個虛擬機中，其將很快變成VTL1。

OslVsmSetup再次被調用(step“2”)：

• 校驗VBS參數
• 驗證Hyper-V正確運行
• 修改OslVsmLoaderBlock設置
• 在相同塊中復制OslVsmLKeyArray(Local Key)和OslVsmIdk(“Identification Key”)

調用儲存在OslpVsmSystemStartup中的安全內核的入口點，指定OslVsmLoaderBlock和它的大小為參數。

然后安全內核將執行它的初始化，并且將調用SkmiProtectSecureKernelPages以便安裝它自己的內存，但是也注冊Hyper-V時間攔截例程(HyperGuard和它的Skpg*前綴的例程)。根據http://www.sandpile.org/x86/msr.htm，對MSR的操作由SkpgxInterceptMsr攔截處理：

0x1B(APIC_BASE) 
0x1004(?) 
0x1005(?) 
0x1006(?) 
0x100C(?) 
0xC0000080(EFER) 
0xC0000081(STAR) 
0xC0000082(LSTAR) 
0xC0000083(CSTAR) 
0xC0000084(FMASK) 
0xC0000103(TSC_AUX) 
0x174(SEP_SEL) 
0x175(SEP_RSP) 
0x176(SEP_RIP) 
0x1a0(MISC_ENABLE) 

我們的假設是這個處理器的設置是為了捕獲VTL0中CPL轉變，來阻止關鍵的MSR修改。還有兩個其他的例程，SkpgxInterceptRegisters和SkpgInterceptRepHypercall。前者可能是攔截CRXXX注冊操作的方法(例如，寫CR4能禁用SMEP)，后者是攔截未授權的調用(然而這些只是猜測)。

關于HyperGuard，似乎通過SkpgVerifyExtents執行VTL0完整性校驗。SkpgHyperguardRuntime被調用，可能是計劃執行的(使用SkpgSetTimer)。

HyperGuard處理器和回調函數被復制到SkpgContext(由SkpgAllocateContext和SkpgInitializeContext初始化)。

記住上個章節只是個假設，可能是錯誤的，因為我們現在沒能在VTL1 HyperGuard/PatchGuard例程中花費太多時間。

在初始化的最后，安全內核將執行兩個調用：

• 0x0F，ShvlEnableVpVtl，指定一個ShvlpVtl1Entry函數指針
• 0x12，ShvlpVtlCall，它不會在任何其他地方使用，并且使用它自己的跳板函數(在下篇文章給出更多細節)。

ShvlpVtl1Entry以SkpPrepareForReturnToNormalMode結束，并且這個過程會使Hyper-V開啟VTL0和VTL1，回到ShvlpVtl1Entry，再回到winload.efi進入到VTL0的上下文。

最終，當回到winload.efi的主函數，將通過OslArchTransferToKernel執行NTOS的入口點,它使用OslEntryPoint調用入口點。

然后執行下一個操作，就像Windows在正常環境中啟動，只是現在NTOS內核知道了VBS相關的組件(如設備保護)。

六、總結

基于虛擬化的安全是Windows10安全功能的一個關鍵組件。通過VBS的安全內核的初始化，我們希望這個文章將給想要深入分析這個功能的逆向者幫助。

在第二部分，我們將涵蓋VTL0和VTL1怎么內核通信和Hyper-V調用怎么實現。