0vercl0k/clairvoyanceVisualisiere den virtuellen Adressraum eines Windows-Prozesses auf einer Hilbert-Kurve.
Clairvoyance (/klɛərˈvɔɪəns/; vom französischen clair für klar und voyance für Vision) von Wikipedia.
clairvoyance erzeugt eine farbige Visualisierung des Seitenschutzes eines gesamten 64-Bit-Prozessadressraums (Benutzer- und Kernelmodus), der auf einem Windows-64-Bit-Kernel läuft.
Um den eindimensionalen Raum, also den Adressraum, in eine zweidimensionale Visualisierung zu überführen, wird die Hilbert-Kurve verwendet. Jedes farbige Pixel im obigen Bild stellt den Seitenschutz (UserRead, UserReadWrite, usw.) einer 4-KB-Seite im virtuellen Speicher dar.
Der Adressraum wird direkt berechnet, indem die vierstufige Seitentabellenhierarchie eines Prozesses manuell aus einem Kernel-Crash-Dump geparst wird, der mit WinDbg erzeugt wurde.
Schließlich gibt das Programm eine Datei mit den Metadaten aus, die erforderlich sind, um sie auf einer zweidimensionalen Leinwand anzuzeigen sowie die virtuelle Adresse zu berechnen, die einem bestimmten hervorgehobenen Pixel entspricht.
Kompilierte Binärdateien sind im Releases-Bereich verfügbar. Ein Online-Viewer wird ebenfalls unter 0vercl0k.github.io/clairvoyance gehostet.
Besonderer Dank geht an:
Zur Erzeugung des Kernel-Crash-Dumps wird empfohlen, WinDbg, KDNet mit dem Befehl .dump /f zu verwenden.
Sobald der Dump erfasst wurde, kannst du seinen Pfad zusammen mit der physischen Adresse des gewünschten Page-Directory an clairvoyance übergeben:
./clairvoyance <dump path> [<page dir pa>]
Dies erzeugt eine Datei mit der Erweiterung clairvoyance, die du anschließend im Browser unter 0vercl0k.github.io/clairvoyance anzeigen kannst, oder indem du den gh-pages-Zweig auscheckst, auf dem der Viewer gehostet wird.
Die CI baut clairvoyance unter Linux mit clang++-11 und unter Windows mit Microsofts Visual Studio 2019.
Um es selbst zu bauen, kannst du die Skripte in build/ verwenden:
(base) clairvoyance\build>build-msvc.bat
(base) clairvoyance\build>cmake ..
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19042.
-- Configuring done
-- Generating done
-- Build files have been written to: clairvoyance/build
(base) clairvoyance\build>cmake --build . --config RelWithDebInfo
Microsoft (R) Build Engine version 16.8.2+25e4d540b for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
clairvoyance.vcxproj -> clairvoyance\build\RelWithDebInfo\clairvoyance.exe
Building Custom Rule clairvoyance/CMakeLists.txt
Das Folgende sind Dinge, die ich in einem Kernel-Crash-Dump bemerkt habe, der von einer Hyper-V-VM von Windows erzeugt wurde:
kd> vertarget
Windows 10 Kernel Version 18362 UP Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Edition build lab: 18362.1.amd64fre.19h1_release.190318-1202
Machine Name:
Kernel base = 0xfffff805`36800000 PsLoadedModuleList = 0xfffff805`36c432f0
Debug session time: Sat Jul 25 10:00:19.637 2020 (UTC - 8:00)
System Uptime: 0 days 0:18:53.609
Windows scheint keine riesigen Seiten (1 GB) zu verwenden, oder zumindest habe ich in keinem der von mir gesammelten Dumps eine gesehen.
Große Seiten werden in großer Zahl verwendet, um einige Kernel-Executables wie den Windows-Kernel nt abzubilden:
kd> ? nt
Evaluate expression: -8773703827456 = fffff805`36800000
VA:0xfffff80536800000, PA:0x2400000 (KernelReadWriteExec, Large, PML4E:0xd5745f80, PDPTE:0x42080a0, PDE:0x4209da0, PTE:0x0)
Es gibt auch eine Reihe von Kernel-Lese-, Schreib- und ausführbaren Seiten, die keine großen Seiten sind, was etwas überraschend war. Mir war bewusst, dass der Kernel / HAL mithilfe großer Seiten abgebildet werden konnte und dass diese krwx waren. Der Grund dafür ist, dass 2 MB so groß sind, dass sie sowohl ausführbare als auch Datensektionen umfassen; das bedeutet, dass die Seite beschreibbar und ausführbar sein muss.
Die einzige öffentliche Erwähnung, die ich dazu finden konnte, ist in diesem Blogpost (danke `Ivan):
Ich habe Microsoft kontaktiert, das behauptete, dies sei beabsichtigt, da „in manchen Fällen der Kernel mit großen Seiten abgebildet wird“ und dass dies durch die Aktivierung des virtualisierungsbasierten Schutzes (VBS) verhindert werden könne.
Eine Reihe großer Kernel-Speicherbereiche wird auf dieselbe physische Seite abgebildet (mit Nullen gefüllt):
VA:0xffffc27ef4401000, PA:0x4200000 (KernelRead, Normal, ...)
VA:0xffffc27ef4402000, PA:0x4200000 (KernelRead, Normal, ...)
VA:0xffffc27ef4403000, PA:0x4200000 (KernelRead, Normal, ...)
...
VA:0xffffc27ef63fb000, PA:0x4200000 (KernelRead, Normal, ...)
VA:0xffffc27ef63fc000, PA:0x4200000 (KernelRead, Normal, ...)
VA:0xffffc27ef63fd000, PA:0x4200000 (KernelRead, Normal, ...)
VA:0xffffc27ef63fe000, PA:0x4200000 (KernelRead, Normal, ...)
VA:0xffffc27ef63ff000, PA:0x4200000 (KernelRead, Normal, ...)
Hier ist eine kleinere (die Region ist nicht vollständig zusammenhängend, es gibt ein paar Lücken):
VA:0xffffc27ed2201000, PA:0x4300000 (KernelRead, Normal, ...)
VA:0xffffc27ed2202000, PA:0x4300000 (KernelRead, Normal, ...)
VA:0xffffc27ed2203000, PA:0x4300000 (KernelRead, Normal, ...)
...
VA:0xffffc27ed25fc000, PA:0x4300000 (KernelRead, Normal, ...)
VA:0xffffc27ed25fd000, PA:0x4300000 (KernelRead, Normal, ...)
VA:0xffffc27ed25fe000, PA:0x4300000 (KernelRead, Normal, ...)
VA:0xffffc27ed25ff000, PA:0x4300000 (KernelRead, Normal, ...)
Dies ist nur ein Abschnitt, der einige der coolen Muster zeigt, die man in manchen Regionen eines Adressraums sehen kann.
Page-Heap-Allokationen und ihre Guard-Seiten sehen ziemlich cool aus und sind leicht zu erkennen:
Kernel-Stacks haben ebenfalls eine schöne erkennbare Form aufgrund ihrer Größe und ihrer Guard-Seiten:
Die Systemcache-Region im Kernel sieht in den Dumps, die ich gesehen habe, wie ein Nebel aus:
Axel '0vercl0k' Souchet