Kesinlikle güvenilir bir yol yok, hayır.
Her iki durumda da tam bir döküme ihtiyacınız olacak, ancak sorun şu ki, kötü amaçlı yazılımlar, çekirdek içindeki sorumlu işlevleri bağlayabilir ve neyin atılacağını değiştirin. Burada dikkate alınması gereken birkaç şey var.
Kötü amaçlı yazılım ilk etapta bağlantı kurmak için önemsiz bir yöntem kullanıyorsa bunu tespit edebilirsiniz . Adresin bir tramboline veya başka bir yüklenmiş görüntünün içine (veya hatta sayfasız havuzdaki birinin dışına) değiştirildiğini varsayalım, o zaman kolayca algılayabilirsiniz . Basitçe tüm modülleri numaralandırabilir ve içinde adresin SSDT'nin içinde bulunduğu modülü bulmaya çalışabilirsiniz. Bir trambolin durumunda, nereye atladığını / çağırdığını görmek için oradaki talimatları sökmeniz gerekecektir.
udis86 gibi amaca uygun birçok kitaplık var.
Ancak, kötü amaçlı bir yazılım sinsi ise, doğal boşlukları kullanabilir belleğe yüklendiğinde bir yürütülebilir dosyanın (çekirdek gibi) içinde. Muhtemelen bildiğiniz gibi, bir PE dosyasının (
ntoskrnl.exe ve arkadaşlar gibi) diskte ve bellekte farklı şekilde temsil edilme şekli. Disk üzerindeki dosya biçimi daha kısadır. Belleğe yüklenen bölümler, PE başlığında açıklanan belirli bir şekilde hizalanır. Bu şekilde, bir bölümün gerçek boyutu (son) ile doğru şekilde hizalanmış bölüm boyutu ("dolgu") arasında büyük olasılıkla boşluklar olacaktır. Bu, bir trambolin gibi bir şeyi gizlemek veya basit bir trambolinden daha fazla kabuk kodu bırakır. Bu nedenle, yukarıdaki gibi saf bir kontrol - yani modülleri numaralandırma ve SSDT işlevlerinin çekirdek görüntüsünün içine işaret edip etmediğini kontrol etme - çalışmayacaktır. Az önce anlattıklarımı yapacak kadar sofistike kötü amaçlı yazılımlar tarafından atlanırdı.
Tahmin edebileceğiniz gibi bu, kötü amaçlı yazılım / kötü amaçlı yazılımdan korunma her şeyde olduğu gibi, her şeyin hızla silahlanma yarışına dönüştüğü anlamına gelir. Şiddetle önereceğim şey, bir çekirdek hata ayıklayıcı eklemeniz (akla Firewire üzerinden
WinDbg geliyor) ve araştırırken virüs bulaşmış (veya virüs bulaştığı iddia edilen) makineyi belirsizlikte tutmanızdır. Siz bağlıyken ve hata ayıklayıcıya girdiğinizde, hata ayıklayıcı hiçbir şey yapamaz. Bu, bir sistemde canlı hata ayıklamak için kullanılabilir ve - kötü amaçlı yazılımın
kdcom 'u da manipüle edecek kadar gizli olmadığını varsayarsak - değerli ölçümler elde etmek için - doğrudan bir çökme dökümü oluşturmak için de kullanılabilir (WinDbg yardımına bakın ). Bir makinenin, sergilediği belirtiler nedeniyle enfekte olduğuna dair kesin kanıtınız varsa, büyük olasılıkla kötü amaçlı yazılımın çok karmaşık olmaması ve özetlediğim özel durumu önemsemeniz gerekmez. Ancak, bu özel durumun, gizlemek için kullanılan pek çok olası durumdan yalnızca biri olarak kabul edilebileceğini unutmayın. Çok uzun lafın kısası: İstediğinizi yapmanın kesinlikle güvenilir bir yolu yoktur.
Bazen söylendi - ve doğrudur - saldırganın sadece birini bulması gerekir Savunan, bilinen saldırı vektörlerini yalnızca sınırlı sayıda savunabilir. Bundan çıkarılacak ders, kötü amaçlı yazılımdan koruma endüstrisi olarak (benim çalıştığım) her zaman sistemde hiçbir şey bulamadığımızı iddia edebiliriz, ancak bunu iddia etmenin yanlış olduğunu sistem temiz.
Klavye sürücü (ler) inin bir BSOD'ye neden olduğu söylenebilir:
HKLM \ CurrentControlSet \ Services \ kbdhid \ Parameters
veya (eski PS / 2 klavyeler için)
HKLM \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Parameters
Ve orada
CrashOnCtrlScroll adlı bir
REG_DWORD öğesini
1 olarak ayarlayın.
Bir sonraki yeniden başlatmanın ardından mavi ekranı Ctrl + ScrollLk + ScrollLk ile zorlayabilirsiniz. Bu durumda hata kontrol kodu
0xE2 (
MANUALLY_INITIATED_CRASH ) olacaktır.
Yan not: Ben de okudum ama hiç görmedim bir çekirdek hata ayıklama oturumunda kendimde veya herhangi bir FLOSS uygulamasında, bazı yöntemlerin çekirdeği diskteki görüntüden yeniden yüklemeye ve onu ilk başlatma adımlarından geçmeye çalışarak bir "gölge" SSDT oluşturması. Bu daha sonra bozulmamış olacak ve orijinal SSDT'den tek bir hamlede her şeyi "çözmek" için kullanılabilir. Yine, bunun uygulandığını görmedim, ancak dahili bilgilerime göre bir olasılık görünüyor. Elbette bu, bir kök setinin işlevlerini tespit etme / çözme fikrinde, virüs bulaşmış bir sistemin bellek dökümünü alma amacınızdan çok daha fazla işe yarar.
Daha incelikli bozulma türlerini tespit edebilecek başka bir yöntem de WinDbg'yi (canlı bir sistemde veya kilitlenme dökümünde) kullanmak ve
chkimg her bir çekirdek modülünü denetlemek için komut, örneğin:
chkimg -d nt
Bu, çekirdeğin bozulmamış bir kopyasını MS Symbol sunucusundan indirir ve raporlar bellek içi sürümden herhangi bir farklılık. Bunun muhtemelen iş parçacığı başına SSDT'ye yerleştirilen herhangi bir kancayı algılamayacağını unutmayın.