inVtero.net
inVteroCore.0.1
https://github.com/ShaneK2/inVtero.net/blob/master/quickdumps/publish.zip
Linux utilise des serveurs de symboles pour la résolution de type, ça marche ;)
Découvrez la version inVteroCore pour assurer l'intégrité de XEN et VMWare sous Linux (ou partout où CORECLR s'exécute, OSX et FBSD)
##$ IMPORTANT (utilisateurs Windows sur .NET) => Vous devez avoir msdia140.dll enregistré "cmd /c regsvr32 msdia140.dll" (voir zip)
Aucune configuration nécessaire, complètement dynamique / typage canard
Nouvelle interface utilisateur pour les formats pris en charge par l'édition de mémoire (dés/assemblage et correctif). Utilisez "Loader()" sur une instance vtero comme ;
Loader(test(MemList))
Modifiez la chaîne MemoryDump pour qu'elle pointe vers un vidage de mémoire. Exemple de parcours de vidage mémoire et explication du système de type dans analyse.py, voir 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)
Rechercher/extraire des processus, des hyperviseurs (y compris imbriqués) dans des vidages de mémoire à l'aide de techniques d'introspection de machine virtuelle indépendantes de la microarchitecture. Outils d'analyse de mémoire physique multiplateformes et multi-architectures hautes performances.
| Version x64 |
|---|
Quickdumps est un exemple d'utilisation de l'API inVtero.net pour extraire et valider la mémoire physique.
De la façon dont nous initialisons notre traduction d'adresse virtuelle en adresse physique, il n'y a aucune dépendance sur le format du fichier d'entrée. N'importe quel .DMP, .RAW, .DD devrait convenir. Malheureusement, si le format de capture sous-jacent utilise une certaine forme de stockage d'extensions (c'est-à-dire ne consomme pas de stockage physique pour les pages NULL ou NON PRÉSENTES), votre kilométrage peut varier. Il existe de nombreux outils pour convertir les vidages de mémoire, la volatilité - rekal sont de bons points de départ. BITMAP. Les fichiers DMP sont en cours pour faciliter l'analyse des liveumps (actuellement, les choses fonctionnent mieux si vous effectuez un écran bleu lancé manuellement avec un vidage complet configuré ou si vous utilisez un outil de type dd brut tiers).
Plusieurs concepts sont utilisés pour garantir que nous interagissons avec l'utilisateur uniquement lorsque cela est nécessaire. De la même manière, pour le projet Actaeon github @eurecom-s3/actaeon, un objectif principal est de localiser et d'exploiter la page VMCS afin de localiser l'EPTP (pointeur de table de pages étendu) configuré qui est nécessaire pour localiser les pages physiques appartenant à un instance de système d'exploitation invité. Google @google/rekall rekal a ensuite implémenté une implémentation plus étendue qui nécessite que l'utilisateur exécute un module du noyau Linux sur le système à l'origine d'un vidage mémoire donné, destiné à construire un profil spécialisé pouvant être utilisé pour ensuite l'importer dans un rekal local. profil qui vous permettra ensuite d'isoler/extraire la mémoire invité d'un dump d'hôte physique.
Lors de CanSecWest/DC22, j'ai présenté une technique de haute qualité (basée sur l'interaction de la couche la plus basse entre les couches mm du processeur et du système d'exploitation) pour identifier tout processus exécuté sur un système en inspectant des instantanés de mémoire physique. Ce mécanisme est basé sur ce qu'on appelle le pointeur automatique (Windows) ou le pointeur de répertoire de pages récursif (*BSD) qui est toujours censé être trouvé (sauf si votre système Windows a un mm fortement modifié/corrigé, ou simplement un noyau personnalisé pour * BSD). Le résultat net est que nous connaissons toutes les valeurs données du registre CR3. Étant donné que le VMCS contient au moins 1 valeur CR3 connue (une seconde peut être émulée ou remappée dynamiquement), nous sommes convaincus qu'un vidage mémoire complet peut être effectué sans rien connaître de la version du système d'exploitation sous-jacent (par exemple XP (64 bits) -> Win2016). cohérent) ou microarchitecture.
La force brute gagne toujours en fin de compte ! C'est du moins ce que j'entends... Dans tous les cas, si un mappage VMCS inconnu est trouvé (index EPTP), les quickdumps émettront un ensemble de valeurs/index possibles. La liste est généralement petite, 10 à 20 au maximum. Une fonctionnalité à venir consiste à automatiser les tentatives pour chaque valeur possible jusqu'à ce que celle qui « fonctionne » soit trouvée. Cela devrait garantir que nous travaillerons sur les microarchitectures de processeur à venir sans aucune modification de code (ou je configurerai probablement certaines classes qui les spécifient pour vous simplifier la vie). Quoi qu’il en soit, le forçage brutal devrait être assez rapide. J'essaie de tirer le meilleur parti des processeurs multicœurs, donc si vous avez des cœurs supplémentaires, ils bénéficieront probablement d'un entraînement si vous analysez un énorme dump avec de nombreuses machines virtuelles.
Exemple exécuté à partir d'un ordinateur portable :
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]
Dans l'exemple ci-dessus, l'EPTP de VMWARE se trouve à l'index 14 dans son VMCS.
* Nous verrons si celui-ci est éliminé, mais pour le moment, il ne s'agit que de vider la mémoire du noyau de chaque couche. Travailler sur l'espace utilisateur à partir des machines virtuelles du système d'exploitation invité.
Beaucoup de TODO mais je vais en ajouter dès que possible. Le principal problème en ce moment est que j'hésite vraiment à ajouter quoi que ce soit fourni par le système d'exploitation, même si cela serait d'une grande aide. Je pense qu'un contexte suffisant est disponible pour éviter d'ajouter des dépendances logiques au système d'exploitation. J'aime la façon dont Rekal s'engage à le faire, mais il semble que leurs archives de profils soient également très volumineuses, donc un peu des deux.
Il y a encore un peu de nettoyage à faire. Il s'agit encore d'une version alpha, mais elle se développera activement.
Étendez-vous à des types EPTP plus connus afin qu'aucune force brute ne soit requise
Je vais créer un index bitmap PFN pour déterminer automatiquement les exécutions (actuellement, si vous essayez de vider/interroger quoi que ce soit après une exécution, cela posera des problèmes ou sera manqué, etc. Nous l'ajouterons ensuite pour garantir que nous obtenons des vidages complets à 100 % .
S'abstenir d'utiliser les structures logiques du système d'exploitation pour prendre en charge l'analyse de la mémoire. Il est probable que la plupart des structures, données, codes et objets des couches du système d'exploitation puissent être manipulés par un attaquant afin de détourner les efforts d'un analyste.
Fonctionnalité à venir pour restituer une carte d'intégrité pour les pages de codes qui peuvent être mappées à des valeurs de hachage de bloc/page cryptographiquement sécurisées (c'est-à-dire SHA256 ou TIGER192). Nos résultats indiquent des taux de vérification pré-win10 supérieurs à 99 %, la mémoire volatile post-win10 est pratiquement attestable à 100 %. Cela élimine les tâches de conjecture substantielles et les inconnues dues à la manipulation/révision/démontage manuel traditionnel de la mémoire lors de la tentative de détection/analyse de plusieurs gigaoctets d'entrée.
Documentation
Implémentation de l'interface graphique
