《Ophion》CE繁體中文化腳本下載 隱形Hypervisor技術整理、VT-x虛擬化繞過檢測機制

Ophion 隱形Intel VT-x Hypervisor 快速閱讀精華

• 🚀 核心定位：Type-2 隱形Hypervisor，專為繞過EAC/BE等反作弊系統設計
• 💡 技術亮點：採用「CPU支援VMX但韌體鎖定關閉」的欺騙模型，一致性無破綻
• 🔑 關鍵機制：
  
  • CPUID快取與位元遮罩（清除ECX[31]超級管理器標誌）
  • TSC補償計時攻擊防禦（僅攔截CPUID後的RDTSC）
  • Private Host CR3/IDT隔離（防止NMI劫持與頁表污染）
  • MSR透明化處理（IA32_FEATURE_CONTROL偽造）
  • 除錯暫存器隔離（DR0-DR3/DR6影子保存）
• ⚠️ 重要提醒：本文僅供教育與安全研究用途，技術細節請自行承擔法律責任

本文章目錄

• 前言介紹
  
• 隱形機制核心
  
• CPUID快取與遮罩
  
• TSC計時補償
  
• MSR透明化
  
• 除錯暫存器隔離
  
• Private Host隔離
  
• 檔案下載點 🔽
  
• 常見問題Q&A

前言介紹：為什麼Ophion能隱形？

玩過競技遊戲的玩家一定知道，EAC（Easy Anti-Cheat）、BE（BattlEye）這類反作弊系統有多嚴格。它們會掃描你的系統，檢查有沒有Hypervisor（虛擬機監控器）在運作——因為很多外掛都靠Hypervisor來隱藏自己。

問題來了：傳統Hypervisor根本藏不住。CPUID一查就露餡，RDTSC計時一看就破功，CR4暫存器一讀就知道VMX啟動了。這也是為什麼市面上多數「隱藏」方案都撐不了多久。

Ophion的解法完全不同。它不搞「假裝不存在」，而是打造一個「真實存在但合理關閉」的系統狀態——就像一臺公司電腦，CPU確實支援虛擬化，但IT部門用韌體鎖死了。這個故事從頭到尾都講得通，沒有任何矛盾點。

👉 GM後台版 遊戲 推薦 ⬇️⬇️⬇️ 快速玩各種二次元動漫手遊app

隱形機制核心：The Stealtd Model

Ophion的隱形不是單一技巧，而是一整套互相驗證的系統謊言。每個檢測向量看到的都是同一個故事：

檢測項目	裸機真實值	Ophion回報值
CPUID.1.ECX[5]	1（VMX支援）	1（保留真實值）
CPUID.1.ECX[31]	0（無Hypervisor）	0（清除隱藏）
CPUID.1.ECX[6]	視機型而定	0（與FEATURE_CONTROL一致）
IA32_FEATURE_CONTROL	Lock=1, VMX=0	Lock=1, 全部=0（韌體鎖定）
VMX MSRs (0x480-0x493)	真實硬體值	直通真實值
CR4.VMXE	0（未啟動）	影子值=0，實際=1（雙重狀態）
VMX指令	#UD（未定義操作碼）	注入#UD（符合預期）

關鍵在於「一致性」。反作弊不只看單一數值，它會交叉比對——如果CPUID說VMX不支援，但MSR 0x480又能讀出值，這就是破綻。Ophion讓每個查詢都指向同一個結論：這臺電腦確實支援虛擬化，但被鎖死了，沒人在用。

CPUID快取與遮罩：對抗葉片枚舉攻擊

為什麼CPUID 0x40000000是致命弱點？

VMAware、hvdetecc這類檢測工具會玩一個把戲：比較「無效葉片」的回傳值。在Intel CPU上，任何超出範圍的CPUID葉片都會回傳最後一個有效標準葉片的資料。例如CPUID(0x13371337)和CPUID(max_leaf+1)應該長得一模一樣。

但多數Hypervisor會特別處理0x40000000這個「Hypervisor保留範圍」——回傳"Hyper-V"或"KVM"字串，或是直接填零。檢測工具一比較：「0x13371337回傳A，0x40000000回傳B → 有Hypervisor！」

Ophion的快取策略

在VMXON之前，Ophion先偷問CPU一個明顯無效的問題：

__cpuidex(cpu_info, 0x13371337, 0);
g_stealtd_cpuid_cache.invalid_leaf[0] = cpu_info[0];
// ... 快取全部四個暫存器

之後任何無效葉片的查詢，都從快取拿答案——位元組級完全一致，沒有任何差異。範圍判定涵蓋：

• 0x40000000-0x4FFFFFFF（Hypervisor保留區）
• max_std_leaf+1 到 0x7FFFFFFF（標準與擴展之間的間隙）
• 0x80000000以上超出max_ext_leaf的範圍

Leaf 1 位元遮罩

兩個關鍵位元被動手腳：

if (leaf == 1 && g_stealtd_enabled)
{
    cpu_info[2] &= ~((1 << 31) | (1 << 6));
}

• ECX[31]（Hypervisor Present）：Windows自己會檢查這個位來決定是否啟用Hyper-V優化，所有反作弊都盯著它
• ECX[6]（SMX/TXT）：必須與IA32_FEATURE_CONTROL一致，否則「說有SMX但控制暫存器說沒有」就是破綻

TSC計時補償：打斷RDTSC+CPUID+RDTSC攻擊

經典計時攻擊的原理

檢測工具會這樣玩：

RDTSC → 記錄時間T1
CPUID          ← 這個指令會觸發VM-exit
RDTSC → 記錄時間T2
delta = T2 - T1

裸機上CPUID約80-200週期（P-Core）或~350週期（E-Core/Gracemont）。但Hypervisor要VM-exit→處理→VM-entry，動輒500-2000+週期。時間差就是罪證。

「陷阱下一個RDTSC」策略

Ophion不搞全域TSC_OFFSET偏移（那會累積漂移、搞爛單調性、最後觸發看門狗逾時）。它只做一件事：在CPUID VM-exit後，武裝一個單次RDTSC陷阱。

步驟拆解：

• CPUID處理開始時，記錄當前TSC到vcpu->tsc_cpuid_entry
• 動態啟用RDTSC exiting（原本硬體直通）
• 下一個RDTSC觸發VM-exit，回傳補償值：快取中的裸機CPUID成本 + 原始TSC偏移
• 立即解除武裝，恢復硬體直通

tsc = vcpu->tsc_cpuid_entry
    + g_stealtd_cpuid_cache.bare_metal_cpuid_cost
    + (UINT64)(INT64)offset_raw;

vcpu->tsc_rdtsc_armed = FALSE;
// 關閉RDTSC exiting，回到硬體直通

如果中間插進了外部中斷、NMI？陷阱自動解除，攻擊鏈被打斷。bare_metal_cpuid_cost在VMXON前校準：200次圍籬RDTSC→CPUID→RDTSC取最小值，排除排程雜訊。

結果：零漂移、零單調性問題、近乎零效能影響。

MSR透明化：讓暫存器讀取無懈可擊

IA32_TIME_STAMP_COUNTER (MSR 0x10)

這個MSR被MSR bitmap攔截。問題是：__rdtsc()在VMX root模式回傳原始硬體TSC，不帶VMCS偏移。所以處理器得手動補上：

case 0x10:
{
    size_t tsc_offset_raw = 0;
    __vmx_vmread(VMCS_CTRL_TSC_OFFSET, &tsc_offset_raw);
    msr.Flags = (UINT64)((INT64)__rdtsc() + (INT64)tsc_offset_raw);
    break;
}

根據Intel SDM 27.6.5節，「Use TSC offsetting」本來就該讓RDTSC、RDTSCP、RDMSR(0x10)得到一致結果。這個攔截只是為了讓TSC補償路徑也能覆蓋RDMSR-based計時攻擊。

IA32_FEATURE_CONTROL (MSR 0x3A)

運作中的Hypervisor需要EnableVmxOutsideSmx=1，但這會被 guest 讀到。Ophion讀取真實MSR後「消毒」：

feat.Lock = 1;
feat.EnableVmxInsideSmx = 0;
feat.EnableVmxOutsideSmx = 0;
// ... 全部清零，符合「韌體鎖定」故事

寫入？注入#GP，MSR已鎖定，很合理。

VMX Capability MSRs (0x480-0x493)

Intel SDM明確規定：這些MSR只要CPUID.1.ECX[5]=1就存在，不管VMX是否啟用。Ophion保留ECX[5]=1，所以這些MSR應該能讀到真實硬體值——它也真的直通__readmsr()。

寫入一律#GP，架構上就是唯讀。

合成MSRs (0x40000000+)

Hyper-V、KVM會在這範圍暴露介面MSR。裸機上讀這些？#GP。Ophion對整個範圍讀寫都注入#GP，「這臺電腦沒有Hypervisor，所以沒有合成MSR」——故事一致。

除錯暫存器隔離：DR0-DR3/DR6的影子保存

檢測工具怎麼玩DR陷阱？

• 設定DR0為已知位址
• 在CPUID後面放個指令，設定TF（Trap Flag）
• 執行CPUID（觸發VM-exit）
• 檢查DR6：應該看到BS（Single-Step）+ B0（Breakpoint 0 matched）

裸機上CPU自動處理這個。但Hypervisor的VM-exit處理可能會亂動DR暫存器，回來DR6就不對了——破綻。

Ophion的解法：完整影子狀態

VMCS會自動存取DR7，但DR0-DR3和DR6不會。Ophion在每個VCPU結構裡開影子欄位：

// VM-exit一進來就保存，趁還沒被亂動
vcpu->guest_dr0 = __readdr(0);
// ... dr1, dr2, dr3, dr6

// ... 處理器執行，C程式碼可能亂動DR ...

// VMRESUME前還原
__writedr(0, vcpu->guest_dr0);
// ... 全部寫回去

MOV DR指令讀寫影子欄位而非硬體。DR7走VMCS硬體路徑。DR4/DR5在CR4.DE=0時別名到DR6/DR7，CR4.DE=1時注入#UD。

Pending Debug Exceptions處理

Hypervisor推進RIP後，必須自己檢查硬體中斷點是否匹配新RIP——裸機上CPU自動做，VM-exit後得自己來：

for (int i = 0; i < 4; i++)
{
    // 檢查DR7啟用位元、執行型中斷點（R/W=00）
    // 比較DRn與new_rip
    // 匹配就設定對應的B0-B3位元
}
if (bp_matched)
    pending |= bp_matched | PENDING_DEBUG_ENABLED_BP;

沒這一步，CPUID後面的硬體中斷點會靜悄悄失效——又是破綻。

Private Host隔離：CR3與IDT的防禦工事

Private Host CR3：防止EAC啟動時凍結

問題：VMCS的HOST_CR3指向系統行程頁表。Guest模式程式碼（含反作弊驅動）可能污染核心PTE，導致Hypervisor在主機模式觸發分頁錯誤。

hostcr3_build() 深度複製核心分頁表：
- 讀取PsInitialSystemProcess->DirectoryTableBase
- 對每個存在的核心PML4項目（256-511）：遞迴複製PDPT→PD→PT
- 大分頁（1GB、2MB）原樣複製，葉項目仍指向同塊實體記憶體
- 修正自參照PML4項目指向私有PML4
- 使用者空間項目（0-255）清零，主機模式不跑使用者程式碼

關鍵在「自參照修正」。Windows用一個PML4項目指回自己來做分頁表自映射。沒更新這個，私有分頁表還會參照原始PML4：

if ((our_pml4 & PTE_PFN_MASK) == pml4_pa)  // 指向原始PML4
{
    our_pml4 = (our_pml4 & ~PTE_PFN_MASK) | g_host_pml4_pa;
}

實體分頁表頁面用MmGetVirtualForPhysical()映射，而非MmMapIOSpace。前者適用所有RAM支援的PFN，不需要取消映射；後者在某些虛擬化環境會失敗。

Private Host IDT：阻擋NMI劫持

更陰險的攻擊：Guest模式程式碼腐化IDT項目，然後觸發NMI。NMI不可遮罩，VM-exit處理期間也會送達——CPU會走被腐化的處理器，在ring 0 VMX-root模式執行攻擊者控制的程式碼。

Ophion的hostidt_build()配置私有IDT：

• NMI（向量2）：設定per-VCPU待處理旗標，IRETQ返回。VM-exit處理器檢查旗標，下次exit時注入NMI給guest
• #DF（向量8）/#GP（向量13）：主機模式無法恢復，停機
• 其他所有向量：預設處理器停機。任何非預期到達VMX-root的都是bug

VMCS HOST_IDTR.base指向私有IDT，而非OS IDT。Guest腐化系統IDT不影響主機模式中斷傳遞。

VMCALL閘道與指令封鎖

VMCALL用三暫存器簽名驗證：

if (regs->r10 != 0x48564653ULL ||       // 'HVFS'
    regs->r11 != 0x564d43414c4cULL ||   // 'VMCALL'
    regs->r12 != 0x4e4f485950455256ULL)  // 'NOHYPERV'
    注入#UD;

CPL檢查：從VMCS讀取guest CS存取權，DPL必須為0（ring 0專用）。使用者模式VMCALL得#UD。

所有其他VMX指令（VMCLEAR、VMPTRLD、VMREAD、VMWRITE、VMXON、VMXOFF、VMLAUNCH、VMRESUME、INVEPT、INVVPID、GETSEC）一律注入#UD——這與guest看到的CR4.VMXE=0一致，裸機上VMXE未設定時執行VMX指令本來就會#UD。

檔案下載與使用說明

所有站內附件皆會附上安全掃描報告
請會員查看純淨度百分比後判斷使用



相關檔案須知：
取得檔案前，請先詳細閱讀文章內容
避免不必要錯誤與誤會發生。
也可多參考文章討論樓層內容
了解附件檔案相關討論資訊。

【此文章部分內容隱藏中】    解除隱藏說明教學點擊下方 繼續閱讀文章 後
請仔細觀看文章內容 並依照指示進行下一步
最後完成解除隱藏後
系統會回到此文章自動顯示隱藏內容~

繼續閱讀

編譯需求：

• Windows 10/11 x64
• Visual Studio 2022 + Windows Driver Kit (WDK)
• Intel Core i5-14400F或同級以上（14代Intel測試通過）
• BIOS開啟VT-x（Intel Virtualization Technology）

重要聲明：本工具僅供安全研究與教育用途。編譯與使用可能違反遊戲服務條款，請自行評估法律風險。完整技術文件與VMCS配置、EPT設計、中斷處理等細節請參考GitHub專案原始碼。

常見問題Q&A

Q：Ophion能保證100%繞過所有反作弊嗎？

沒有任何工具能保證。Ophion在EAC/BE測試通過，但反作弊持續更新。這是軍備競賽，不是一勞永逸的解決方案。

Q：為什麼CR4.VMXE寫入後讀回顯示0？這不是破綻嗎？

這是已知權衡。裸機上寫入VMXE=1再讀回會看到1，Ophion的影子值會剝離VMXE顯示0。但不隱藏VMXE是更常見、更容易被檢測的向量。兩害相權取其輕。

Q：AMD CPU能用嗎？

Ophion是Intel VT-x專屬設計。AMD需要SVM（AMD-V）架構的Hypervisor，技術細節完全不同。

Q：TSC補償會影響系統效能嗎？

幾乎不會。只有CPUID後的第一個RDTSC會觸發VM-exit，其他所有RDTSC都硬體直通。校準的bare_metal_cpuid_cost讓補償值精準貼合裸機行為。

Q：Private Host CR3的靜態快照有什麼風險？

核心PTE在載入後若動態變更，私有分頁表不會追蹤。但所有主機模式配置（VMM堆疊、點陣圖等）都在快照前完成，實務上影響極小。

Q：檢測工具hvdetecc、VMAware是什麼？

開源Hypervisor檢測工具，用各種啟發式方法找虛擬化痕跡。Ophion的設計目標就是讓這些工具回報「未檢測到Hypervisor」。

Q：我可以修改原始碼加入更多功能嗎？

可以，專案採開源授權。但任何修改都可能破壞隱形機制的一致性，建議深入理解Intel SDM（軟體開發者手冊）後再動手。

Q：Ophion跟商業Hypervisor（如VMware、Hyper-V）有什麼不同？

商業Hypervisor追求功能完整與效能，不隱藏存在。Ophion是研究導向的隱形專案，犧牲部分功能換取檢測規避能力。