NPT-hook detection via single-step redirection¶

Bir code page'inin read view'ı ile execute view'ının uyuşmamasını zorlayarak NPT/EPT tabanlı bir stealth hook'u tespit etme — şüphelenilen page boyunca single-step yap ve execution'ın sıradan bir read'in döndürdüğünden farklı byte'lara yönlendirildiğini gözlemle ya da yeniden yönlendirmenin maliyeti olan ekstra VM-exit latency'sini ölç.

Mechanism¶

Note

Bir NPT-based hook (ya da Intel EPT-based stealth hook) tek bir asimetriye dayanır: page, orijinal byte'lar olarak read edilir ama hooked kopya olarak execute edilir, çünkü SLAT fetch ve read'i farklı physical frame'lerden servis eder. Bir detector'ın provoke edebileceği şey tam olarak bu asimetridir. "Bu page neyi execute ediyor" ile "bu page neyi read ediyor"u karşılaştırabiliyorsan, bir ayrışma un-hooked memory'de var olmayan bir fetch/read ayrımını kanıtlar.

Yeniden yönlendirme de bedava değildir: her execute fault'u, permission toggle'ı ve single-step replay'i bir VM-exit'tir. Bu yüzden byte'ları okumadan bile, şüpheli bölgeyi zamanlamak (örn. ona yapılan bir call etrafında RDTSC) hook'un known-clean bir page'e kıyasla overhead'ini açığa çıkarır. Detector'ın dayandığı invariant: bir page'i yeniden yönlendirmek ya da single-step etmek zorunda olan bir hypervisor, o page'i hem content hem latency'de native ile birebir aynı davranır hâle getiremez.

Walkthrough¶

Public reference: Maurice Heumann, "Detecting Hypervisor-assisted Hooking," artı secret.club introspection yazısı. Kavramsal probe'lar:

Content divergence: şüphelenilen page'in byte'larını oku, sonra aynı address'te fiilen execute edilen byte'ları gözlemlemeyi ayarla (örn. kendi kontrollü single-step / debug exception akışın ile). Execute edilen byte'lar != read edilen byte'lar ise, bir hook vardır.
Timing probe: known-clean bir code page'ine yapılan bir call için RDTSC cycle sayımlarını baseline'la, sonra şüphelenilen hooked fonksiyon için aynısını yap. Israrla süren ekstra cycle'lar (NPT fault'u + single-step replay'inden) yeniden yönlendirmeyi işaret eder:
```
t0 = rdtsc(); call clean_stub();    dt_clean = rdtsc() - t0;
t0 = rdtsc(); call suspect_func();  dt_suspect = rdtsc() - t0;
# dt_suspect >> dt_clean  => candidate hook
```
Single-step davranışıyla doğrula: belirli bir address'te single-stepping altında yeniden fault veren / tuhaf davranan bir page, hook'un instruction-replay path'iyle tutarlıdır.

Beklenen gözlemlenebilir: hooked page'ler read/execute content uyuşmazlığı ve/veya tekrarlanabilir bir latency primi gösterir; temiz page'ler göstermez.

Warning

Timing gürültülüdür — çok sayıda sample, sabit CPU affinity'si ve known-clean bir baseline kullan. Sofistike bir hook timing'i normalize etmeye çalışabilir; content divergence daha güçlü sinyaldir.

Detection¶

Bu zaten bir tespit tekniğidir. Bir karşı-tespit notu olarak, bu tür probe'ların farkında olan hypervisor'lar latency'yi gizlemeye ya da tutarlı byte'lar servis etmeye çalışabilir, dolayısıyla birden çok sinyali birleştir (content + timing + single-step anomalileri).

Mitigation¶

Defender'lar/AV: SLAT hook'larını yüzeye çıkarmak için read-vs-execute content check'lerini ve timing baseline'larını integrity tooling'ine dahil et.
Tespit edilmeden kalmak zorunda olan hypervisor yazarları temel bir maliyetle karşılaşır: yeniden yönlendirme ve single-stepping, tamamen silinemeyen bir timing kalıntısı bırakır.

References¶

Maurice Heumann — "Detecting Hypervisor-assisted Hooking." https://momo5502.com/posts/2022-05-02-detecting-hypervisor-assisted-hooking/
secret.club — "Hypervisors for Memory Introspection and Reverse Engineering." https://secret.club/2025/06/02/hypervisors-for-memory-introspection-and-reverse-engineering.html