[𝐃𝐞𝐯𝐥𝐨𝐠] 𝐒𝐡𝐚𝐝𝐨𝐰 𝐏𝐫𝐨𝐣𝐞𝐜𝐭: 𝐀𝐌𝐃 𝐒𝐕𝐌 𝐁𝐚𝐫𝐞-𝐌𝐞𝐭𝐚𝐥 𝐇𝐲𝐩𝐞𝐫𝐯𝐢𝐬𝐨𝐫

(Not: Bu devlog dökümantasyonu, geliştirme sürecindeki karmaşık teknik notlarımın derlenip düzenlenmesi amacıyla yapay zeka (AI) asistanı kullanılarak formatlanmıştır. İçerikteki tüm mimari kararlar, kodlamalar ve donanım testleri şahsıma aittir.)

Selamlar CheatGlobal üyeleri,

Forumda spesifik olarak 'C' programlama kategorisi bulunmadığı için bu konuyu C++ bölümüne açıyorum; ancak geliştirmekte olduğum bu proje tamamen saf C ve Assembly dilleri kullanılarak, donanım spesifikasyonları seviyesinde (low-level) yazılmaktadır.

Güncelleme ve Takip Prosedürü:Geliştirme süreci boyunca konuyu şu şekilde güncelleyeceğim: Büyük çaplı mimari değişiklikleri ve versiyon atlamalarını doğrudan bu ana metni düzenleyerek ekleyeceğim. Küçük çaplı düzeltmeleri (hotfix), l0g çıktılarını veya anlık debug notlarını ise konu altına yorum olarak bırakacağım. Bu yorumlar kesinlikle forumda "mesaj kasma" (post farming) amacı taşımamakta olup, tamamen projenin kronolojik devlog takibini sağlamak içindir.

Proje Durumu ve Tahmini Bitiş:Şu an itibarıyla proje %85 - %90 oranında tamamlanmış durumdadır. Hypervisor geliştirmedeki en zorlu aşama olan "İşletim sistemi boot sürecine sızma ve BSOD (Mavi Ekran) engellerini aşma" kısmı başarıyla geçilmiştir. Kalan %10'luk kısım payload optimizasyonu ve stabilite testleridir. Projenin tahmini bitiş ve stabil Release Candidate (RC) sürümüne ulaşma süresi 2 ila 3 hafta arasıdır.

Giriş (Proje Altyapısı)​

Geliştirmekte olduğum 'Shadow Project', AMD SVM (Secure Virtual Machine) tabanlı bir Bare-Metal Hypervisor mimarisidir. Projenin tüm yükleme, test ve debug süreçleri doğrudan EFI Shell üzerinden yürütülmektedir. İşletim sistemi yüklenmeden önce sistem kontrolünü Ring -1 (Guest Mode) seviyesinde devralmayı hedefleyen bu altyapı, standart Windows API'lerinden bağımsız, tamamen low-level ve firmware tabanlı bir execution modeline sahiptir.

Versiyon Geçmişi (v1'den v10.51'e)​

v1 - v10 (Stealth, Bellek Sanallaştırma & Core Hazırlıkları)Bu aşamada hipervizörün temel yapıtaşlarını ve Ring -1'deki gizlilik (stealth) mekanizmalarını inşa ettim.

• Manual Mapping & Pool Allocation: Windows API'leri kullanımdan çıkarılarak .sys binary'sini non-paged pool bellek alanlarına manuel olarak map ettim. Host ve Guest state'leri için contiguous (ardışık) bellek blokları allocate ettim.
• NPT (Nested Page Tables) & SLAT: AMD-V donanımsal bellek sanallaştırmasını kullanarak NPT yapısını kurdum. SLAT (Second Level Address Translation) mimarisi ile hipervizörün fiziksel bellek ayak izini (RAM üzerindeki alanını) misafir işletim sisteminden (Windows) tamamen gizledim.
• MSRPM & IOPM Entegrasyonu: MSR Permission Bitmap (MSRPM) ve I/O Permission Bitmap (IOPM) yapılarını oluşturarak hangi MSR ve donanım portlarına erişimde #VMEXIT fırlatılacağını ayarladım. Özellikle LSTAR, CSTAR ve EFER MSR'lerini intercept ettim.
• Timing Attack Koruması: RDTSC ve CPUID komutları için özel VMEXIT handler'lar yazdım. RDTSC offset değerlerini manipüle ederek hipervizörün varlığının zamanlama gecikmeleriyle (overhead) tespit edilmesini engelledim.

v10.19 (İlk UART İletişimi)

• Hipervizörün Ring -1 seviyesindeki ilk tepkilerini okuyabilmek için Tera Term üzerinden seri iletişimi kurdum. Raw I/O portları (0x3F8) üzerinden donanımla ilk başarılı veri aktarımını sağladım.

v10.30 (Fiziksel Hardware Debugging)

• Geliştirme sürecini sanal makinelerden (VM) fiziksel donanıma taşıdım. Anakart üzerinde fiziksel UART kablolamasını ve pin bağlantılarını bizzat yaparak host makine üzerinden gerçek zamanlı donanım loglamasını başlattım.

v10.35 - v10.40 (EFI Shell Yükleme ve BSOD Sorunu)

• EFI Shell üzerinden yüklenen loader modülü ile UEFI ExitBootServices (EBS) fonksiyonuna hook atmayı denedim. Winload.efi'nin PatchGuard öncesi bütünlük testleri bu kancayı tespit ederek 0xc000000d (Geçersiz Parametre) BSOD hatasına neden oldu.
• Çözüm: EBS Hooking yöntemini tamamen terk ettim. Bunun yerine UEFI'nin standart EVT_SIGNAL_EXIT_BOOT_SERVICES olay bildirim sistemine (event callback) geçiş yaparak firmware seviyesinde meşru bir sıçrama (jump) noktası oluşturdum.

v10.41 - v10.48 (UART Trace Çakışması)

• Tera Term ekranında sürekli akan anlamsız E0E0E0 karakter verisi tespit ettim.
• Yapılan low-level analiz sonucunda bu durumun bir Core crash (Triple Fault) olmadığını doğruladım. EFI Loader içinde unutulan eski trace makrolarının UART baud rate (115200) senkronizasyonunu bozduğunu tespit ettim. UART init prosedürünü yeniden yapılandırarak temizledim.

v10.49 - v10.50 (Milyon Dolarlık Hata: The Bit Swap)

• Sistemde [FATAL] Cannot clear SVMDIS! Hardware locked. hatası tespit ettim. BIOS üzerinden IOMMU ayarlarını aktif etmeme rağmen hata devam etti.
• AMD APM (Architecture Programmer's Manual) Volume 2 spesifikasyonlarını inceleyerek kod analizine gittim. VM_CR (0xC0010114) register'ı maskelenirken Bit 3 (LOCK) ile Bit 4 (SVMDIS) değerlerini ters (swap) yazdığımı belirledim. Kod, SVMDIS yerine donanımsal LOCK bitini sıfırlamaya çalışıyordu. Bit pozisyonlarını düzelterek SVM kilidini bypass ettim.

v10.51 (Hybrid Debug Mimarisinin Kurulması)

• Loader (EFI) Aşaması: ASRock boot logosu aktifken GOP (Graphics Output Protocol) üzerinden VMCB fiziksel adresini, Entry Point (EP) değerini ve bellek pool adreslerini ekrana (sarı metin formatında) yazdırdım (Visual Preflight).
• Core (Hypervisor) Aşaması: ExitBootServices tetiklendiği an ekran yazdırma servislerinin bellekten silinmesi sebebiyle oluşabilecek olası bir Triple Fault'u önlemek için, Core tarafındaki tüm UEFI ConOut çağrılarını tamamen kaldırdım. Sistemi tam bir sessizliğe (Radio Silence) alarak, hipervizör seviyesindeki tüm debug işlemlerini sadece raw UART port I/O üzerine yönlendirdim.

Geliştirmeler devam ettikçe ana metni ve yorumları güncelleyeceğim.

eline sağlık

sigmabilge' Alıntı:

eline sağlık

Genişletmek için tıkla ...

teşekkür ederim,aslında bunu bir vgc/vgk emulator haline dönüştürüp forumda paylaşmayı planlıyorum,ancak riotun hızından korkuyorum ve herkes için private build almam gerekiyor ayrıca kullanım sınırı koymalıyım ki bunun için de haftalık ve günlük keyler paylaşmam gerek forumda o da reversala yol açar ki bunu istemem o yüzden biraz arada kaldım.

böyle bir projeyi yapabilen ai'a ihtiyaç duymadan tanıtabilir diye düşünüyorum ama eline sağlık

Plox1ed' Alıntı:

böyle bir projeyi yapabilen ai'a ihtiyaç duymadan tanıtabilir diye düşünüyorum ama eline sağlık

Genişletmek için tıkla ...

teşekkür ederim,anlaşılır olması için yani donanım bilgisi olmayan arkadaşlara yönelik anlatım için yapay zeka kullandım

v10.52 (Granular UART Tracing & VMEXIT Diagnostics)​

Sistemin ASRock logosundaki donma (hang) noktasını tespit edebilmek amacıyla, Loader'dan Core'a geçiş ve VMRUN öncesi/sonrası süreçleri kapsayan agresif bir izleme (tracing) ağı kurdum.

• Zero-Dependency Logging: svm_core.c içine hiçbir UEFI servisine veya kütüphaneye bağımlılığı olmayan RawUartPrint fonksiyonunu entegre ettim. Bu sayede sistem kararsız olsa bile 0x3F8 I/O portu üzerinden ham veri akışını sağladım.
• Diagnostic Milestones: Takip sürecini 9 kritik noktaya böldüm:
  • [L1]: Loader'dan Core'a sıçrama anı doğrulaması.
  • [C0] - [C1]: Core entry point ve SVM dispatch başlangıcı.
  • [C2] - [C4]: NPT ve Bitmap yapılandırma aşamaları.
  • [C5] - [C6]: Host CR3 (Identity Mapping) değişim öncesi ve sonrası kontrolü.
  • [C7]: VMRUN komutunun ateşlenmesi (Pre-flight completion).
  • [C8]: Misafir (Guest) işletim sisteminin başarıyla geri dönmesi.
• VMEXIT Panic Broadcast: ShadowSvmExitHandler fonksiyonunu güncelledim. Eğer CPU, VMCB tutarlılık hatası (#VMEXIT_INVALID) verirse, bu durum artık sessiz bir donma yerine UART üzerinden X-[EXIT_CODE] formatında anlık olarak raporlanacak.
• Baud Rate Consistency: Tüm boot zinciri boyunca 115200 baud hızının korunması için UART init prosedürlerini stabilize ettim.

v10.53 (EFER.SVME Bit Manipulation & Core Synchronization)

v10.52 sürümüyle birlikte Loader-to-Core geçişini (Stage 2 Transition) başarıyla tamamladım. UART logları üzerinden yapılan doğrulamada çekirdek entry point'ine ulaşıldığı ve donanım kilitlerinin (VM_CR) bypass edildiği kesinleşti. Mevcut durumdaki son kritik engel, VMRUN öncesi işlemci durumunun valide edilmesidir.

• EFER.SVME Pulse Fix: İşlemcinin EFER (Extended Feature Enable Register - 0xC0000080) MSR'si üzerindeki 12. bitin (SVME) pasif olduğu (0) tespit edildi. Bu durum, donanım seviyesinde sanallaştırma komutlarının (VMRUN, VMLOAD vb.) Invalid Opcode veya Triple Fault ile sonuçlanmasına neden olur.
• Core Logic Update: Çekirdek girişinde SVME bitini zorla (force set) aktif eden ve VMCB State-Save alanındaki misafir register'ları ile senkronize eden Assembly rutinlerini entegre ettim.
• Consistency Check: Misafir (Guest) durumundaki EFER değerinin, ana makine (Host) EFER değeriyle çakışmaması için tutarlılık kontrollerini (Consistency Checks) svm_core.c seviyesinde optimize ettim.

Şu an projenin %93 aşamasındayım. Bir sonraki adım, SVME bitinin 'Pulsed' (1) olarak loglanması ve ilk VMRUN ateşlemesinin gerçekleştirilmesidir.

bu forumda bare metal yazısının b'sini görebileceğim aklıma gelmezdi eğer gerçekten iyi bir işse helal olsun ve tabii ki yapay zeka desteksiz yapılmışsa

enbabapro1' Alıntı:

bu forumda bare metal yazısının b'sini görebileceğim aklıma gelmezdi eğer gerçekten iyi bir işse helal olsun ve tabii ki yapay zeka desteksiz yapılmışsa

Genişletmek için tıkla ...

3 aydır geliştiriyorum ve paylaşmayı düşünmüyordum,cidden ben de forumdakilerin anlayacağını düşünmüyordum.yaklaşık 3 yıldır da sadece assembly ve c öğreniyorum umarım topluma katkı sağlar bu proje

hagaj' Alıntı:

es

Genişletmek için tıkla ...

teşekkür ederim iyi forumlar

küçük poclar

v10.54 (MSR EFER Manipulation Success & The Event Horizon)

v10.53 denemesinde kritik bir eşiği geçtim. İşlemcinin EFER.SVME (Bit 12) kilidini yazılımsal olarak manipüle ederek 1 (SUCCESS) konumuna getirdim. Bu, donanımın artık Ring -1 komutlarını kabul ettiği anlamına gelen "Point of No Return" noktasıdır.

• SVME Activation Verified: UART logları üzerinden POST-ACTIVATION EFER.SVME PULSE: 1 onayı alındı. İşlemci artık resmi olarak SVM modunda çalışıyor.
• VMRUN Execution Point: Sistemin bu noktadan sonra askıda kalması (hang), VMRUN komutunun ateşlendiğini ancak Misafir (Guest) işletim sistemi durumunun (VMCB State-Save) tutarsızlıklar nedeniyle Windows çekirdeğini resume edemediğini gösteriyor.
• Consistency Audit: Şu anki odak noktam; VMCB içindeki CR0, CR3, CR4 ve EFER register'larının misafir ve ana makine arasındaki senkronizasyonunu AMD APM Vol 2 standartlarına göre normalize etmek.

Projenin %95'i tamamlandı. Şu an sadece Ring -1'den Windows'un kapısını çalma aşamasındayım.
Ekstra olarak :
v10.53 sürümünde EFER.SVME bitini başarılı bir şekilde 1 (SUCCESS) konumuna getirerek donanımın sanallaştırma kilidini tamamen açtım. Şu an sistem "Execution Horizon" (Olay Ufku) noktasında; yani hipervizör çekirdeği VMRUN komutunu ateşliyor ancak işlemci misafir (guest) durumuna geçerken bir tutarsızlık tespit edip sistemi askıya alıyor.

• Pre-Run Telemetry: VMRUN öncesi CR3, CR0 ve CR4 register'larını UART üzerinden anlık olarak izlemeye aldım. Amacım, AMD mimarisinin katı "VMCB Consistency Checks" kurallarını ihlal eden gizli bir register değerini tespit etmek.
• Instruction Wrapping: AsmSvmLaunch rutinini [C7] (Pre-Flight) ve [C8] (Post-Flight) loglarıyla çevreledim. Bu, sistemin donma noktasının VMRUN anı mı yoksa misafirden geri dönüş (exit) anı mı olduğunu kesinleştirecek.
• Memory State Synchronization: Misafir işletim sistemi ile ana makine (host) arasındaki register senkronizasyonunu AMD APM Vol 2 standartlarına göre manuel olarak revize ettim.

@enbabapro1 dost takipte kal yükleyip stealth yapacağım daha sonra vds ve oto keygen mekanizmaları ekleyeceğim belki publarım bile

v10.55 (Pre-Activation Audit & Pipeline Stabilization)

v10.54 diagnostik testlerinde sistemin EFER.SVME aktivasyonundan milisaniyeler sonra, henüz audit loglarını basamadan askıda kaldığı (hang) tespit edildi. Bu durum, "Sanallaştırma Modu"na geçiş anındaki işlemci state-save tutarsızlığına işaret ediyor.

• Audit Execution Shift: RawUartPrintHex64 üzerinden aldığım hex dump bloklarını, SVME aktivasyonunun öncesine (Pre-Pulse) kaydırdım. Amacım, donma yaşanmadan önceki son "temiz" register durumunu (CR0-CR4) yakalamak.
• Pipeline Flushing: SVME bitinin manipülasyonundan sonra işlemci pipeline'ında oluşabilecek instruction mismatch (komut uyumsuzluğu) hatalarını önlemek için seri bariyerler ve CPUID bazlı senkronizasyon adımları ekledim.
• Telemetry Validation: UART Hex printer'ın stabilitesini doğrulamak adına çekirdek girişine ham veri doğrulama (Smoke Test) rutinleri entegre ettim.

Projenin %95 aşamasındayım.

Ne amaçla kullanılacak bu hocam bana pek samimi gelmedi