inVtero.net
inVteroCore.0.1
https://github.com/ShaneK2/inVtero.net/blob/master/quickdumps/publish.zip
Linux verwendet Symbolserver zur Typauflösung, es funktioniert einfach ;)
Schauen Sie sich die inVteroCore-Version an, um Integrität für XEN und VMWare unter Linux (oder überall dort, wo CORECLR ausgeführt wird, OSX und FBSD) bereitzustellen.
##$ WICHTIG (Windows-Benutzer unter .NET) => Sie müssen msdia140.dll registriert haben „cmd /c regsvr32 msdia140.dll“ (siehe ZIP)
Keine Konfiguration erforderlich, völlig dynamisch/Duck-Typing
Neue Benutzeroberfläche für die Speicherbearbeitung (Dis/Assemble und Patch) unterstützter Formate. Verwenden Sie „Loader()“ auf einer vtero-Instanz wie;
Loader(test(MemList))
Ändern Sie die MemoryDump-Zeichenfolge so, dass sie auf einen Speicherauszug verweist. Beispiel für einen Memory-Dump-Walking und eine Erläuterung des Typsystems in „analysate.py“, siehe WalkProcListExample()
quickdumps
>>> MemList = [ "c:\temp\win10.64.xendump" ]
>>> test(MemList)
++++++++++++++++++++++++++++++ ANALYZING INPUT [c:tempwin10.64.xendump] ++++++++++++++++++++++++++++++
PART RUNTIME: 00:00:08.5211677 (seconds), INPUT DUMP SIZE: 4,303,692,448.00 bytes.
SPEED: 466,980 KB / second (all phases aggregate time)
++++++++++++++++++++++++++++++ DONE WITH INPUT [c:tempwin10.64.xendump] ++++++++++++++++++++++++++++++
>>> Loader(vtero)
Suchen/Extrahieren von Prozessen und Hypervisoren (einschließlich verschachtelter) in Speicherauszügen mithilfe von Mikroarchitektur-unabhängigen Virtual Machine Introspection-Techniken. Plattformübergreifende, leistungsstarke Tools zur Analyse des physischen Speichers mit mehreren Architekturen.
| x64-Version |
|---|
Quickdumps ist ein Beispiel für die Verwendung der inVtero.net-API zum Extrahieren und Validieren von physischem Speicher.
Bei der Art und Weise, wie wir unsere virtuelle in physische Adressübersetzung initialisieren, gibt es keine Abhängigkeiten vom Eingabedateiformat. Alle .DMP-, .RAW- und .DD-Dateien sollten in Ordnung sein. Es gibt leider einen großen Nachteil: Wenn das zugrunde liegende Erfassungsformat irgendeine Form von Extent-Speicher verwendet (d. h. keinen physischen Speicher für NULL- oder NOT PRESENT-Seiten verbraucht), kann Ihr Kilometerstand variieren. Es gibt viele Tools zum Konvertieren von Speicherauszügen, Volatilitätsauszügen und Rekals sind einige gute Ausgangspunkte. BITMAP. DMP-Dateien sind im ToDo enthalten, um die Analyse von Livedumps zu erleichtern (derzeit funktioniert es am besten, wenn Sie einen manuell initiierten Bluescreen mit konfiguriertem vollständigen Dump durchführen oder ein Raw-DD-Typ-Tool eines Drittanbieters verwenden).
Es kommen mehrere Konzepte zum Einsatz, um sicherzustellen, dass wir nur bei Bedarf mit dem Benutzer interagieren. Ähnlich wie beim Actaeon-Github-Projekt @eurecom-s3/actaeon besteht ein Hauptziel darin, die VMCS-Seite zu lokalisieren und zu nutzen, um den konfigurierten EPTP (Extended Page Table Pointer) zu lokalisieren, der zum Lokalisieren der physischen Seiten benötigt wird, die zu a gehören Gastbetriebssysteminstanz. Google @google/rekall rekal implementierte anschließend eine umfangreichere Implementierung, die erfordert, dass der Benutzer ein Linux-Kernelmodul auf dem System ausführt, von dem ein bestimmter Speicherauszug stammt, um ein spezielles Profil zu erstellen, das dann zum Importieren in ein lokales Rekal verwendet werden kann Profil, mit dem Sie dann den Gastspeicher von einem physischen Host-Dump isolieren/extrahieren können.
Während CanSecWest/DC22 habe ich eine hochwertige Technik (basierend auf der Interaktion der untersten Schicht zwischen der CPU- und der OS-mm-Schicht) vorgestellt, um jeden auf einem System laufenden Prozess durch Überprüfung von Snapshots des physischen Speichers zu identifizieren. Dieser Mechanismus basiert auf dem sogenannten Selbstzeiger (Windows) oder rekursiven Seitenverzeichniszeiger (*BSD), von dem erwartet wird, dass er immer gefunden wird (es sei denn, Ihr Windows-System verfügt über einen stark modifizierten/gepatchten MM oder einfach einen benutzerdefinierten Kernel für *). BSD). Das Nettoergebnis davon ist, dass wir alle gegebenen CR3-Registerwerte kennen. Da das VMCS mindestens einen bekannten CR3-Wert enthält (ein zweiter kann emuliert oder dynamisch neu zugeordnet werden), können wir sicher sein, dass ein umfassender Speicherauszug durchgeführt werden kann, ohne etwas über die zugrunde liegende Betriebssystemversion zu wissen (z. B. XP(64bit) -> Win2016). konsistent) oder Mikroarchitektur.
Brutale Gewalt gewinnt am Ende des Tages immer! Zumindest habe ich das gehört ... Wenn eine unbekannte VMCS-Zuordnung (EPTP-Index) gefunden wird, geben Quickdumps auf jeden Fall eine Reihe möglicher Werte/Indizes aus. Die Liste ist normalerweise klein, höchstens 10–20. Eine bevorstehende Funktion besteht darin, Versuche für jeden möglichen Wert zu automatisieren, bis einer gefunden wird, der „funktioniert“. Dies sollte sicherstellen, dass wir für kommende CPU-Mikroarchitekturen ohne Codeänderungen arbeiten (oder ich werde wahrscheinlich einige Klassen einrichten, die diese spezifizieren, um das Leben einfacher zu machen). Wie dem auch sei, Brute-Force sollte recht schnell vonstatten gehen. Ich versuche, das Beste aus Multi-Core-CPUs herauszuholen. Wenn Sie also zusätzliche Kerne haben, werden diese wahrscheinlich eine Belastung bekommen, wenn Sie einen großen Speicherauszug mit vielen VMs analysieren.
Beispiellauf von einem Laptop aus:
Process CR3 [00000002DD41F000] File Offset [0000000293A12000] Diff [FFFFFFFFB65F3000] Type [Windows]
159 candiate process page tables. Time so far: 00:01:01.4826693, second pass starting. rate: 32588.149 MB/s
Hypervisor: VMCS revision field: 16384 [00004000] abort indicator: NO_ABORT [00000000]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
Hypervisor: Windows CR3 found [00000000016A0000)] byte-swapped: [00006A0100000000] @ PAGE/File Offset = [00000001262DA000]
[435][00000000006F0054]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [00000001308D3000]
[14][000000007433301E]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [0000000130AD1000]
[14][000000007433301E]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [00000001314CF000]
[14][000000007433301E]
Hypervisor: VMCS revision field: 0 [00000000] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000016A0000)] byte-swapped: [00006A0100000000] @ PAGE/File Offset = [0000000160643000]
[106][00000000001E001C]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [0000000195922000]
[14][000000007433301E]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [00000001959A3000]
[14][000000007433301E]
159 candiate VMCS pages. Time to process: 00:02:51.8973861
Data scanned: 34,171,150,654.00Second pass done. rate: 1277.967 MB/s▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
grouping and joinging all memory
Scanning for group correlations
MemberProces: Groupt 1 Type [Windows] Group Correlation [100.000 %] PID [1AB000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [16A0000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [1FCA000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [62AB000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [34CE8000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [37300000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [7DCC6000]
Finished Group 1 collected size 48 next group
Scanning for group correlations
MemberProces: Groupt 2 Type [FreeBSD] Group Correlation [100.000 %] PID [65C8000]
MemberProces: Groupt 2 Type [FreeBSD] Group Correlation [100.000 %] PID [6B51000]
MemberProces: Groupt 2 Type [FreeBSD] Group Correlation [100.000 %] PID [6CC9000]
Im obigen Beispiel befindet sich das EPTP von VMWARE im VMCS an Index 14.
* Wir werden sehen, ob ich dieses Problem bekomme, aber im Moment wird nur der Kernel-Speicher von jeder Ebene ausgegeben. Arbeiten am Benutzerbereich von Gastbetriebssystem-VMs.
Viele TODOs, aber ich werde sie so schnell wie möglich hinzufügen. Das Hauptproblem im Moment ist, dass ich wirklich zögere, irgendetwas hinzuzufügen, das vom Betriebssystem bereitgestellt wird, selbst wenn es eine große Hilfe wäre. Ich denke, dass ausreichend Kontext vorhanden ist, um das Hinzufügen logischer Betriebssystemabhängigkeiten zu vermeiden. Mir gefällt, wie Rekal dies verspricht, aber es scheint, dass ihr Profilarchiv auch sehr groß ist, also ein bisschen von beidem.
Es gibt noch ein wenig Aufräumarbeiten. Dies ist noch Alpha, wird aber aktiv weiterentwickelt.
Erweitern Sie es auf bekanntere EPTP-Typen, sodass keine rohe Gewalt erforderlich ist
Ich werde einen PFN-Bitmap-Index erstellen, um Läufe automatisch zu bestimmen (derzeit wird es Probleme verursachen oder übersehen werden, wenn Sie versuchen, nach einem Lauf etwas zu sichern/abzufragen). Wir werden dies als nächstes hinzufügen, um sicherzustellen, dass wir 100 % umfassende Dumps erhalten .
Es ist zu unterlassen, logische Betriebssystemstrukturen zur Unterstützung der Speicheranalyse zu verwenden. Es ist wahrscheinlich, dass die meisten Strukturen, Daten, Codes und Objekte der Betriebssystemebene von einem Angreifer manipuliert werden können, um die Bemühungen eines Analysten in die falsche Richtung zu lenken.
Kommende Funktionalität zum Rendern einer Integritätskarte für Codepages, die auf kryptografisch sichere Block-/Seiten-Hash-Werte (z. B. SHA256 oder TIGER192) zurückgebildet werden kann. Unsere Ergebnisse deuten darauf hin, dass die Überprüfungsraten vor Win10 über 99 % lagen, der flüchtige Speicher nach Win10 ist praktisch zu 100 % nachweisbar. Dies eliminiert erhebliches Rätselraten und Unbekanntes aufgrund der herkömmlichen manuellen Handhabung/Überprüfung/Zerlegung des Speichers beim Versuch, mehrere Gigabyte an Eingaben zu erkennen/zu analysieren.
Dokumentation
GUI-Implementierung
