Canım sıkıldı, yazayım dedim. Keyifli okumalar.

Denuvo nedir, ne değildir?​

Önce bir yanlış anlamayı düzeltelim: Denuvo bir DRM (Digital Rights Management) değil, bir anti-tamper sistemidir. Aradaki fark kritik.

DRM, lisans yönetimini üstlenir "bu oyun bu kullanıcıya ait mi?" sorusunu sorar. Steam, GOG Galaxy, EA App bunlar gerçek DRM'ler. Denuvo ise bu DRM'lerin üzerine oturur ve asıl işi şudur: "kimse bu DRM koduna dokunmasın, analiz etmesin, değiştirmesin."

Denuvo = anti-tamper wrapper. Altındaki gerçek DRM'i korur. Resident Evil Requiem'de tam yığın şöyleydi:
SteamStub > Steam DRM > Capcom Anti-Tamper > VMProtect > Denuvo Anti-Tamper
. 5 katman. Sadece Denuvo değil, Denuvo en üstteki kilit.

Denuvo nasıl çalışır?​

Donanım parmak izi (hardware fingerprint)​

Denuvo'nun temel mekanizması hardware fingerprinting'e dayanıyor. Oyunu başlattığında Denuvo seni tanımak için bilgisayarının kimliğini çıkarıyor. Bunu nasıl yapıyor? Onlarca farklı sistem özelliğini okuyarak:

C++:
// NOT: bunlar tam liste değil, gözlemlenen örnekler
struct DenuvoFingerprint {
 // CPU kimliği
 uint32_t cpuid_vendor[3]; // CPUID leaf 0 "GenuineIntel" / "AuthenticAMD"
 uint32_t cpuid_family_model; // CPUID leaf 1 CPU model/family
 uint32_t cpuid_features; // SSE4, AVX, AES-NI gibi özellikler
 uint64_t cpu_serial; // bazı eski CPU'larda mevcut (Pentium III döneminden)

 // disk
 wchar_t volume_serial[MAX_PATH]; // GetVolumeInformation() ile
 wchar_t disk_model[64]; // WMI: Win32_DiskDrive.Model

 // ağ
 uint8_t mac_address[6]; // GetAdaptersInfo() ile NIC MAC adresi

 // sistem
 wchar_t machine_guid[40]; // HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid
 uint32_t windows_build; // RtlGetVersion() ile
};

Bu verilerden bir hash üretiyor, buna da token Request'i ekleyerek Denuvo sunucularına gönderiyor. Sunucu Steam Ticket'ını Steam'e doğrulatıyor, her şey geçerliyse sana Bu donanıma özel şifreli bir token dönüyor. O tokensız oyun çalışmıyor.
  • Oyun başlar> Hardware Fingerprint toplanır + Steam Ticket alınır.
  • Fingerprint + Ticket Denuvo Sunucularına POST.
  • Denuvo sunucusu, Steam'e Ticket'ı doğrulatır.
  • Cevap: Bu donanıma özel, şifreli Token (sadece o bilgisayarda çalışır)
  • Token, oyun içindeki değerleri Runtime'da çözmek için kullanılır.
  • Denuvo periyodik olarak fingerprint'i tekrar kontrol eder eşleşmezse çöküyor.
Kritik nokta şu: Token donanıma kilitleniyor. başkasının Token'ını kopyalayamazsın, çünkü senin fingerprint'inle eşleşmeyecek ve oyun hata verecek. Yani eski usul "dosyaları kopyala çalıştır" yaklaşımı burada tamamen çöküyor.

Runtime integrity check'leri​

Sadece başlangıçta kontrol etmiyor. Oyun çalışırken de periyodik olarak fingerprint'in hala geçerli olup olmadığına bakıyor. Buna ek olarak oyun kodunun içine yüzlerce farklı noktaya integrity check yerleştiriliyor. Bunlar oyunun normal koduna o kadar karışmış durumda ki hangi çağrının gerçek oyun mantığı, hangisinin Denuvo kontrolü olduğunu ayırt etmek çok zor.

Neden kırmak bu kadar zordu?​

VMProtect katmanı​

Denuvo tek başına yetmez diye üstüne bir de VMProtect ekleniyor genelde. VMProtect ne yapıyor? Oyunun kritik kod bloklarını alıyor ve bunları kendi Custom bytecode formatına çeviriyor. Oyun çalışırken bu bytecode, VMProtect'in içindeki sanal makine yorumlayıcısı tarafından execute ediliyor. Yani gerçek X86-64 instruction'ları yok ortada, özel bir VM var.

C++:
; Normal x86-64 assembly
check_license:
 cmp eax, 1 ; lisans geçerli mi?
 jne license_fail ; değilse atla
 call run_game ; geçerliyse oyunu çalıştır

; VMProtect sonrası yani IDA Pro'da gördüğün şey:
vm_entry:
 push rbp
 mov rsi, 0x7F3A92C1B4E8 ; VM handler tablosuna işaret eder
 mov rdi, 0x4B2E8F11C9A0 ; obfuscated bytecode pointer
 jmp vm_dispatcher ; buradan sonrası sana kapalı
; > vm_dispatcher'ın içi şifrelenmiş bytecode statik analiz burada biter.

IDA Pro veya Ghidra ile Binary'ye girdiğinde düzgün kod yerine "gibberish" görüyorsun. Gerçek mantık VM yorumlayıcısının içinde, Custom opcode'larla şifreli. Her oyun için bu VM farklı konfigürasyonda geliyor.

Self-verifying code yani kendini doğrulayan kod​

Bir integrity Check'i patch'lesen bile diğerleri devreye giriyor. Kod kendi kendini doğrulayabiliyor: "bu Byte'lar değişti mi?" kontrol eden checksum mekanizmaları var. Bir yeri düzeltiyorsun, başka bir yer patlıyor. Whack-a-mole'un software versiyonu.

C++:
// self-verifying mantığının pseudo kodu
void integrity_check_A() {
 uint32_t expected_crc = 0xDEADBEEF; // compile-time'da hesaplanmış
 uint32_t actual_crc = crc32(code_section_start, code_section_size);

 if (actual_crc != expected_crc) {
 // doğrudan crash değil! ince bir şekilde bozuyor.
 // kritik bir game state değişkenini yavaşça bozar
 // ya da 5 dakika sonra başka bir check'i tetikler
 game_state.corruption_flag = 1;
 }
}
// bu check başka bir check tarafından da doğrulanıyor,
// o check de bir başkası tarafından... zincir şeklinde

Denuvo'nun Stack Trick'i yani non-linear stack kullanımı​

Bu Denuvo'nun en zekice numaralarından biri. Normal bilgisayarlarda stack aşağı doğru büyür. Stack Pointer'ın altındaki bellek "boş" kabul edilir. Denuvo bu kurala uymayan bir stack kullanıyor: Hem yukarıya hem aşağıya değer yazıyor. Bu ne anlama geliyor?
Hardware breakpoint koyduğunda, exception handler devreye girer ve exception Context'ini "boş" stack alanına yazıyor ama orası Denuvo'nun veri tuttuğu yer. Veri eziliyor, oyun çöküyor. Böylece standart debugging tekniklerinin büyük çoğunluğu işe yaramaz hale geliyor.

C++:
; normal stack kullanımı vs Denuvo stack trick

; NORMAL: RSP her zaman tahsis edilmiş bölgenin sınırı
; High: [reserved/used memory]
; RSP > [buraya kadar kullanıldı]
; Low: [free space kimse yazmaz]

; DENUVO İLE: RSP'nin ALTINDA da veri var
; High: [reserved]
; RSP > [normal stack data]
; Low: [DENUVO DATA "boş" zannedilen ama dolu]
; ↑ exception handler buraya yazar data corruption

; bu yüzden Maurice Heumann (Hogwarts Legacy araştırması) kendi
; mini debugger'ını yazmak zorunda kaldı exception'ları oyuna
; dispatch etmeden kendisi yakalamak için


CPU privilege ring'leri​

Asıl konuya geldik. Hypervisor Bypass'ı anlamak için önce CPU'nun nasıl organize edildiğini bilmek lazım. Modern X86-64 işlemciler 4 ayrı ayrıcalık seviyesi tanımlıyor, bunlara "ring" deniyor:

1774215351495.webp


Denuvo Ring 3'te çalışan bir oyunu korumak için Ring 0 kernel sürücüleri kullanıyor. Bu yüzden PatchGuard ve DSE gibi korumalar önemli. Ama hypervisor Bypass'ı Ring -1 seviyesine iniyor yani Windows Kernel'ın bile göremediği bir seviye.
  • Ring -2 > UEFI/Firmware: EfiGuard burada çalışır, PatchGuard'ı devre dışı bırakır
  • Ring -1 > Hypervisor: SimpleSvm.sys burada çalışır, CPUID sorgularını yakalar ve manipüle eder
  • Ring 0 > Windows Kernel: hyperkd.sys yüklenir, Denuvo'yu etkisiz kılar
  • Ring 3 > User Space: Oyun çalışır, Denuvo token kontrolü yapar ama sahte ortam görür
  • CPU / Donanım: Aslında hepsi aynı fiziksel makinede
Denuvo gerçek donanım mı görüyor sahte mi hiç anlamıyor. Çünkü onu sorgulayan katmanların hepsi bizim kontrolümüzde. Bu yaklaşıma "environment spoofing" deniyor.

Hypervisor bypass tam olarak ne yapıyor?​

AMD SVM / Intel VT-X hypervisor teknolojisinin temeli​

Modern CPU'lar doğrudan donanım seviyesinde sanallaştırmayı destekliyor. AMD'de buna SVM (Secure Virtual Machine), Intel'de VT-X deniyor. Bu teknoloji sayesinde bir yazılım (hypervisor), işletim sistemini bir sanal makine içinde çalıştırabilir ve ona giden her privileged instruction'ı yakalayabilir.

C++:
// Hypervisor'un CPUID instruction'ını yakalaması
// (AMD SVM üzerinde, SimpleSvm projesinden ilham alınmıştır.)

// Denuvo oyun içinde şunu çalıştırır:
// CPUID leaf 1 > EAX'e CPU family/model/stepping bilgisi döner
// bu değer fingerprint'in parçası

// Normal akış:
// Oyun: CPUID > CPU > gerçek değer döner

// Hypervisor ile:
// Oyun: CPUID > VMEXIT > hypervisor yakaladı! > sahte değer inject et > VMRESUME

void HandleCpuidVmExit(PVIRT_CPU vCpu, PGUEST_CONTEXT guestCtx) {
 CPUID_REGS realResult;
 uint32_t leaf = (uint32_t)guestCtx->Rax;

 // önce gerçek CPUID'yi al
 __cpuidex((int*)&realResult, leaf, (uint32_t)guestCtx->Rcx);

 if (leaf == 0x1) {
 // Denuvo bu leaf'ten stepping/model bilgisi alıyor
 // bu değeri hedef makinenin değeriyle değiştiriyoruz
 realResult.Eax = TARGET_MACHINE_CPUID_EAX;
 realResult.Ebx = TARGET_MACHINE_CPUID_EBX;
 // hypervisor bit'ini temizle "biz bir VM içinde değiliz" de
 realResult.Ecx &= ~(1 << 31); // bit 31 = hypervisor present flag
 }

 // sahte değerleri guest register'larına yaz
 guestCtx->Rax = realResult.Eax;
 guestCtx->Rbx = realResult.Ebx;
 guestCtx->Rcx = realResult.Ecx;
 guestCtx->Rdx = realResult.Edx;

 // oyunu kaldığı yerden devam ettir
 VmxVmResume();
}

CPUID spoofing neden işe yarıyor?​

Denuvo'nun donanım parmak izinin önemli bir parçası CPUID instruction'ından geliyor. Bu instruction normalde Ring 3'ten (user space) çalışabilir ama Ring -1'deki bir hypervisor her CPUID çağrısını yakalayabilir ve dönen değeri değiştirebilir. Denuvo farkında bile değil gerçek donanımla konuştuğunu zannediyor.

EPT hooks belleği gizlice değiştirmek​

Bir de EPT (Extended Page Table) hook mekanizması var. Bu, fiziksel belleğin sanal adres haritalamasını kontrol ediyor. Hypervisor sayesinde Denuvo'nun bellekte yazan kodunu okurken farklı, çalıştırırken farklı içerik göstermek mümkün:

C++:
// EPT hook kavramı dual-view technique
// Denuvo bir bellek sayfasını kontrol ettiğinde:

// READ view (integrity check okurken): > orijinal kod görünür, checksum geçer
// EXEC view (kod çalışırken): > patch'li kod çalışır, kontrol geçilir

// bu sayede memory integrity kontrolleri atlatılır
// çünkü "okunan" ve "çalışan" byte'lar farklı!

// Kaynak: momo5502'nin Hogwarts Legacy araştırmasında 2000+ hook kullanıldı
// EPT hook'lar bunun önemli bir bölümünü oluşturuyordu.

Boot-to-Game saldırı zinciri​

Şimdi Resident Evil Requiem Hypervisor V2 crack'inin tam ne yaptığını adım adım görelim. Bunu RD945 adlı güvenlik araştırmacısı statik analiz yaparak belgeledi.

Adım 0 - UEFI katmanı: EfiGuard (Ring -2)​

Her şeyden önce, PC açılmadan önce UEFI aşamasında müdahale ediliyor. EfiGuard, açık kaynaklı bir UEFI bootkit. Yaptığı iş: Windows boot prosesine girmek ve iki kritik korumayı devre dışı bırakmak:
  • PatchGuard (KPP Kernel Patch Protection): Windows kernel'ının değiştirilip değiştirilmediğini periyodik olarak kontrol eden mekanizma. Imzasız sürücü yüklemeyi, kernel structure'ları değiştirmeyi engelliyor.
  • DSE (Driver Signature Enforcement): sadece Microsoft tarafından imzalanmış sürücülerin yüklenmesine izin veriyor. Imzasız sürücü yükletmiyor normalde.
EfiGuard bu ikisini UEFI aşamasında, Windows daha başlamadan devre dışı bırakıyor. Böylece sonraki adımlarda imzasız kernel sürücüleri yüklenebiliyor.

Adım 1 Hypervisor: SimpleSvm.sys (Ring -1)​

SimpleSvm açık kaynaklı bir AMD SVM hypervisor implementasyonu. Bu sürücü yüklendiğinde Windows'u bir sanal makine içine alıyor ama Windows'un bundan haberi yok. Bundan sonra:

  • Her CPUID instruction > VMEXIT > spoofed değer döner.
  • Her MSR (Model-Specific Register) erişimi >intercept > manipüle edilebilir.
  • Denuvo'nun "ben bir VM'de miyim?" kontrolü > hayır, gerçek donanımdasın yanıtı alır.

C++:
// SimpleSvm'in VMCB (Virtual Machine Control Block) konfigürasyonu
void ConfigureVmcb(PVMCB vmcb) {
 // hangi olayları yakalayacağız?
 vmcb->ctrl.intercept_cpuid = 1; // tüm CPUID çağrıları
 vmcb->ctrl.intercept_msr = 1; // MSR okuma/yazmaları
 vmcb->ctrl.intercept_rdtsc = 0; // timing saldırılarını önlemek için bazen 1

 // EPT benzeri nested page table kurulumu (AMD'de NPT)
 vmcb->ctrl.np_enable = 1;
 vmcb->ctrl.ncr3 = (uint64_t)NestedPageTableBase >> 12;

 // guest başlangıç durumu = mevcut sistem durumu
 // Windows "fark etmeden" VM içine alındı
 CopyCurrentState(&vmcb->save);
}

Adım 2 Kernel Driver: hyperkd.sys (Ring 0)​

EfiGuard DSE'yi kapattı, SimpleSvm Hypervisor'u kurdu. Şimdi Hyperkd.sys adlı özel kernel sürücüsü yükleniyor. Ghidra analizi şunu gösterdi: Bu sürücünün 762 fonksiyonu olan hyperhv.dll'e ince bir wrapper. Temel görevleri:

C++:
// Goldberg emülatörünün yaptığının basitleştirilmiş hali.
// steam_api64.dll'in sahte implementasyonu

extern "C" bool SteamAPI_Init() {
 // gerçek Steam'e bağlanmak yerine:
 g_steam_user = new FakeSteamUser();
 g_steam_apps = new FakeSteamApps();
 // oyun bunun sahte olduğunu anlayamıyor
 return true;
}

extern "C" bool SteamApps_BIsSubscribedApp(AppId_t appID) {
 return true; // "evet, bu oyun lisanslı"
}

// configs.app.ini dosyasına bakılıyor:
// unlock_all=0 < tüm DLC'leri açma, tespit riskini azalt
// spesifik DLC ID'leri listeleniyor

Tüm bu katmanlar bir arada çalışınca Denuvo şunu görüyor: "Steam geçerli, donanım tokenıyla eşleşiyor, integrity Check'ler temiz." oyun açılıyor.

Neden bu kadar sürdü?​

Teknik engeller​

Hypervisor tabanlı yaklaşımın "neden yeni" olduğu sorusunun cevabı şu: Hypervisor yazmak Çok zor. Bir hypervisor geliştirici olmak için şunları derinlemesine bilmen gerekiyor:

  • AMD SVM veya Intel VT-X CPU uzantılarının binary seviyesinde nasıl çalıştığını,
  • VMCB/VMCS yapılarını, VMEXIT kodlarını, guest/host state geçişlerini,
  • Windows kernel Internals'ı, (KPCR, KUSER_SHARED_DATA, PTE yapıları)
  • PatchGuard'ın nasıl çalıştığını ve nasıl bypass edileceğini,
  • UEFI Firmware geliştirme ve Secure Boot mekanizmaları,
  • Denuvo'nun hangi sistem çağrılarını kullandığını ve hangilerini manipüle etmek gerektiğini,

HyperDbg​

Bu süreçte belirleyici olan şey HyperDbg'nin gelişmesi. HyperDbg, açık kaynaklı bir hypervisor-based debugger projesi. Bu proje, hypervisor geliştirmenin bir çerçevesini sunarak o alandaki entry Barrier'ı önemli ölçüde düşürdü. RE/Crack topluluğu bu çerçeveyi adapt etti.

MKDEV ekibinin kullandığı hyperhv.dll'in fonksiyon imzaları HyperDbg açık kaynak projesiyle büyük ölçüde örtüşüyor araştırmacı bunu statik analizle doğruladı.

EMPRESS neden tek başınaydı?​

EMPRESS 2018–2024 arasında Denuvo'nun en güncel sürümlerini kırıyordu. Yaptığı şey hypervisor değil, klasik ama aşırı ileri seviye tersine mühendislikti. Her oyun için yüzlerce saatlik manuel analiz. Hogwarts Legacy'yi bypass eden Maurice Heumann 5 ay harcadı, o da sadece çalıştırana kadar getirebildi, production crack değildi.

"The first news about hacks appeared in December 2025. A test bypass of Persona 5 Royal appeared, where pirates directly talked about betting on the hypervisor." — ixbt.Games güvenlik analizi

Yani tam geçiş Aralık 2025'te oldu. Ondan önce hypervisor yaklaşımı teoride vardı ama kimse Denuvo'yu bypass edecek kadar ileri götürememişti.

Denuvo gerçekten performansı öldürüyor mu?​

"Denuvo FPS'ini düşürüyor" gaming forumlarında yıllardır tekrarlanan bir şikayet. Gerçek ne?

Momo5502'nin Hogwarts Legacy ölçümü​

Hogwarts Legacy araştırmasında Maurice Heumann, Denuvo'nun oyuna kaç kez müdahale ettiğini hook'larla saydı. Sonuç şaşırtıcıydı:

  • Normal gameplay sırasında Denuvo müdahalesi: Birkaç saniyede bir, nadir.
  • Yoğunlaştığı anlar: Sahne geçişleri ve loading Screen'ler.
  • Her Frame'de çalışan başka DRM'lerin aksine Denuvo çok daha pasif.

1774216015898.webp


Bu ne anlama geliyor? Normal Gameplay'de Denuvo neredeyse hiç çalışmıyor. Ama Stutter'ın en çok hissedildiği yerler tam da sahne geçişleri ve loading süreçleri yani Denuvo'nun yoğun çalıştığı anlar. Bu bağlantı rastlantı değil.

Tekken 7 ve Sonic Mania gibi spesifik vakalar​

Bazı oyunlarda performans etkisi ölçülebilir düzeyde kanıtlandı. Tekken 7 ve Sonic Mania Plus'ta Denuvo'nun kaldırılmasının ardından belirli bölümlerde kayda değer performans artışı gözlemlendi. Ars Technica'nın Sam Machkovech, bunu detaylıca inceledi.

Ama bu oyun başına değişiyor. Denuvo ne kadar agresif entegre edilmiş, hangi code Path'lere yerleştirilmiş bunlara bağlı. "Denuvo her oyunda FPS öldürür" veya "Denuvo hiçbir oyunda sorun yaratmaz" ikisi de yanlış.

Güvenlik riski şu anki Bypass'in tehlikeleri​

Burada dürüst olmak lazım. Hypervisor bypass yöntemi, kullanıcı için ciddi güvenlik riskleri taşıyor ve bu önemsenmemesi gereken bir şey değil.

Devre dışı bırakılan korumalar​

Şu an itibarıyla kullanılan yöntemin çalışması için:
  • Secure Boot devre dışı bırakılıyor (bazı versiyonlarda)
  • PatchGuard devre dışı bırakılıyor
  • Driver Signature Enforcement (DSE) devre dışı bırakılıyor
Bunların hepsi bir sebepten var. UEFI Rootkit'leri ve Firmware seviyesinde saldırılar, sistem yeniden kurulsa bile hayatta kalabiliyor. DSE olmadan imzasız kernel sürücüsü yükleniyor sana gelen paketin içine kötü amaçlı bir driver eklenseydi, o da kernel seviyesinde çalışıyor demek.

Mevcut analizler, MKDEV ekibinin dağıttığı paketin içinde genel amaçlı zararlı yazılım bulunamadığını gösterdi. Bu dağıtım zincirinin güvenilirliğini garanti etmiyor. Aynı tekniği kullanan başka birinin paketi içinde keylogger veya miner olabilir ve sen bunu hiçbir araçla tespit edemezsin.

Kirigiri'nin yeni yaklaşımı​

"Kirigiri" takma adlı bir hacker, Mart 2026'da Secure Boot'u devre dışı bırakmayı gerektirmeyen yeni bir yaklaşım duyurdu. Windows güvenlik politikaları aracılığıyla bypass Driver'ını güvenilir kaynak olarak kaydetme yöntemi. Bu yaklaşım plug-and-play'e yakın bir kullanım hedefliyor: Arşivi aç, klasöre bırak, çalıştır.

Eğer bu gerçekleşirse, Denuvo'nun yeni sürümlere karşı da hızla etkisiz hale gelmesi kaçınılmaz. O noktada yayıncılar için "30 günlük pencere" stratejisi de çöker.

Sonuç: DRM savaşları nereye gidiyor?​

Denuvo her zaman kendini "kırılamaz" olarak değil, "yeterince uzun süre dayanır" olarak pazarladı. Mantığı şuydu: Büyük oyunların satışının %80'i ilk 30 günde gerçekleşiyor, o pencerede crack yoksa Denuvo işini yaptı.

Bu pencere artık 1 güne indi. Resident Evil Requiem, 5 katman DRM'e rağmen çıkışının ertesi günü bypass edildi. Voices38 adlı bir başka araştırmacı ise hypervisor değil klasik tersine mühendislik yöntemiyle Doom: The Dark Ages'i (2025) kırdı.

Denuvo muhtemelen kısa vadede yok olmayacak. Yayıncılar başka yöntemlere geçebilir, sunucu taraflı doğrulama (always-online), kernel-level anti-cheat benzeri sürekli bağlantı gereksinimleri gibi. Ama bu yaklaşımların da kendi sorunları var: Meşru kullanıcıları etkiler, internet kesintisinde oyun kapanır, privacy ihlali tartışmaları çıkar.

En önemli gelişme şu: Hypervisor Bypass'ı, Denuvo'yu kırmak için değil, sistemi spoof etmek için kullanıyor. Bu paradigma değişimi. Artık korunan kodu anlamaya çalışmıyorsun korunan kodun baktığı ortamı manipüle ediyorsun. Bu, güvenlik araştırmacılarının ve DRM geliştiricilerinin yıllardır üzerinde çalıştığı "kim daha derin?" yarışmasının yeni turu.

Şimdi Ring -2 (UEFI) artık oyuna dahil oldu. Bunun altında ne var? Teorik olarak SMM (System Management Mode) var ama oraya girmek için fiziksel donanım erişimi gerekiyor.

Şimdilik. :)
 
Son düzenleme:
Virüs konusu açılmışken.

Bunun aynısını Kaspersky'de yapman daha zor çünkü onun anti tamper'i direk dumplamayı bile engelliyor driverla, böylece zararlı davranışlar engellenir ve sürekli sistemi izliyor. HyperDbg kendi antivirüs projemde kullanıyorum ama her özelliğini entegre etmedim daha. Onun yerine bütün Windows API'lerini hooklama gibi açık kaynakta pek görmediğim şeyler var çünkü çoğu virüs bootkit değildir ve olsa dahi önce Windows API'sini kullanıp girmek zorunda.
Secure Boot için imzalı driver lazım veya CVE açığı.

UEFI Secure Boot kapatınca artık her driverı yükleyebiliyorsun. EDK2 veya gnu-efi, uefi-rs gibi projelerle rahatça .efi dosyası oluşturabiliyor. Fakat işletim sistemi boşuna yazılmadı, fidye yazılımı bile bulaşsa üst seviye şifreleme yapman için EDK2 kullanman gerekli. İşletim sisteminde bunu cart diye yapabiliyorsun fakat izlenmen daha kolay.

Virüslerin en çok zorlandığı şey 1) Secure Boot'u geçmek (bu 2.ye kıyasla çok zor) 2) UAC Bypass.

Birde diğer hypervisiorlarla çakışabilir senin hypervisior'un yanlış bilmiyorsam.
 
Virüs konusu açılmışken.

Bunun aynısını Kaspersky'de yapman daha zor çünkü onun anti tamper'i direk dumplamayı bile engelliyor driverla, böylece zararlı davranışlar engellenir ve sürekli sistemi izliyor. HyperDbg kendi antivirüs projemde kullanıyorum ama her özelliğini entegre etmedim daha. Onun yerine bütün Windows API'lerini hooklama gibi açık kaynakta pek görmediğim şeyler var çünkü çoğu virüs bootkit değildir ve olsa dahi önce Windows API'sini kullanıp girmek zorunda.
Secure Boot için imzalı driver lazım veya CVE açığı.

UEFI Secure Boot kapatınca artık her driverı yükleyebiliyorsun. EDK2 veya gnu-efi, uefi-rs gibi projelerle rahatça .efi dosyası oluşturabiliyor. Fakat işletim sistemi boşuna yazılmadı, fidye yazılımı bile bulaşsa üst seviye şifreleme yapman için EDK2 kullanman gerekli. İşletim sisteminde bunu cart diye yapabiliyorsun fakat izlenmen daha kolay.

Virüslerin en çok zorlandığı şey 1) Secure Boot'u geçmek (bu 2.ye kıyasla çok zor) 2) UAC Bypass.

Birde diğer hypervisiorlarla çakışabilir senin hypervisior'un yanlış bilmiyorsam.

Kaspersky kısmı doğru, BYOVD ile imzalı ama açıklı bir driver yükleyip Kaspersky'nin driver'ını disable eden teknikler belgelenmiş durumda. Tamamen geçilmez değil.

Windows API hooking kısmında da açık kaynakta kapsamlı yokluğu konusunda haklısın. Çoğu proje ya SSDT hooking ya minifilter ya da ETW event callback'lere takılıyor, hepsini birden yapan yok neredeyse. Senin projen bu boşluğu kapatmaya çalışıyorsa mantıklı bir hedef. HyperDbg'nin EPT hook altyapısı burada avantaj sağlıyor çünkü SSDT hooking aksine PatchGuard'a takılmıyor.

Fidye yazılımı + EDK2 konusuna gelecek olursak da; LockBit, BlackCat, ALPHV hepsi tamamen user space'te çalışıyor ve AES-256 + ChaCha20 ile gayet "üst seviye" şifreleme yapıyor. EDK2'ye gerek yok. UEFI seviyesine çıkmanın asıl değeri şifreleme gücü değil, stealth ve persistence. MBR/VBR'ı şifreleyen eski Petya tipi şeyler de vardı ama o da UEFI değildi.

Secure Boot > UAC sıralaması doğru. UAC bypass için fodhelper, eventvwr, mock directories gibi onlarca documented teknik var ve büyük çoğunluğu hala çalışıyor. Secure Boot'u geçmek için ya imzalı cert lazım ya da CVE (CVE-2022-21894) ya da fiziksel erişim.

Hypervisor çakışması konusunda da kısmen haklısın. Eğer hedef sistemde Hyper-V veya VBS açıksa Intel VT-x / AMD SVM zaten kullanımda demek. SimpleSvm tipi bir type-1 hypervisor bunu CPUID ile tespit ediyor ve bazıları nested virtualization'a düşüyor, bazıları crash yapıyor. Windows 11'de VBS default açık geliyor artık, bu yüzden mevcut bypass'ların bir kısmı VBS açık sistemlerde sorun yaşıyor. HyperDbg bu konuda nested virt desteğiyle biraz daha iyi durumda ama tam değil.
 
Kaspersky kısmı doğru, BYOVD ile imzalı ama açıklı bir driver yükleyip Kaspersky'nin driver'ını disable eden teknikler belgelenmiş durumda. Tamamen geçilmez değil.

Windows API hooking kısmında da açık kaynakta kapsamlı yokluğu konusunda haklısın. Çoğu proje ya SSDT hooking ya minifilter ya da ETW event callback'lere takılıyor, hepsini birden yapan yok neredeyse. Senin projen bu boşluğu kapatmaya çalışıyorsa mantıklı bir hedef. HyperDbg'nin EPT hook altyapısı burada avantaj sağlıyor çünkü SSDT hooking aksine PatchGuard'a takılmıyor.

Fidye yazılımı + EDK2 konusuna gelecek olursak da; LockBit, BlackCat, ALPHV hepsi tamamen user space'te çalışıyor ve AES-256 + ChaCha20 ile gayet "üst seviye" şifreleme yapıyor. EDK2'ye gerek yok. UEFI seviyesine çıkmanın asıl değeri şifreleme gücü değil, stealth ve persistence. MBR/VBR'ı şifreleyen eski Petya tipi şeyler de vardı ama o da UEFI değildi.

Secure Boot > UAC sıralaması doğru. UAC bypass için fodhelper, eventvwr, mock directories gibi onlarca documented teknik var ve büyük çoğunluğu hala çalışıyor. Secure Boot'u geçmek için ya imzalı cert lazım ya da CVE (CVE-2022-21894) ya da fiziksel erişim.

Hypervisor çakışması konusunda da kısmen haklısın. Eğer hedef sistemde Hyper-V veya VBS açıksa Intel VT-x / AMD SVM zaten kullanımda demek. SimpleSvm tipi bir type-1 hypervisor bunu CPUID ile tespit ediyor ve bazıları nested virtualization'a düşüyor, bazıları crash yapıyor. Windows 11'de VBS default açık geliyor artık, bu yüzden mevcut bypass'ların bir kısmı VBS açık sistemlerde sorun yaşıyor. HyperDbg bu konuda nested virt desteğiyle biraz daha iyi durumda ama tam değil.
Üst seviye şifreleme derken diskin tamamını UEFI'dan şifrelemek yoksa işletim sistemi sayesinde üst düzey şifrelemeyi gene yapabilirsin. Onun dışında kendimi anlatabilmişim sanırım. Evet bende her şeyi bir arada yapan bir açık kaynak proje görmedim.
Kaspersky BYOVD ile kapanabiliyor orası doğru. Zaten driver yetkisi alınca antivirüslerin başı genelde belaya girer ve driverı kapatmaya gerek kalmadan korunan kullanıcı seviyesi programı kapatabilirsin böylece kernel kalır yalnız başına.
Birde haklısın sistemde kalmak içinde yapıyorlar UEFI virüslerini ve normal kullanıcı takılıyor bunu silmekte.