Détection de Packer

I.    Introduction

Les auteurs de logiciels malveillants utilisent plusieurs astuces pour éviter la détection et l'analyse. L'une des méthodes les plus courantes consiste à utiliser un programme de compression, un outil qui compresse, crypte et / ou modifie le format d'un fichier malveillant que l'on nomme packer. Les packers peuvent également être utilisés à des fins légitimes, par exemple pour protéger un programme contre l'analyse ou la copie de bloc.

Toutes ces astuces diminuent les chances de détection par des logicielles anti-malware et permettent d'éviter l'analyse par des chercheurs en sécurité.

Les emballeurs rendre plus difficile l'analyse et l'inverse ingénierie en mode statiques  pour des analystes en sécurité dans le but de retarder l'identification du comportement du logiciels malveillants et d'augmenter le temps requis pour une analyse des parties fondamentales. La complexité des packers varie et il existe une quantité important de packer que ce soit des packers clé en main dit standard que de packers privés.

II.    Type d'emballeurs

Un packer peut agir simplement comme une armure pour protéger le binaire. Il est plus pratique pour les attaquants d’utiliser un programme de compression plutôt que d’implémenter directement une protection dans le code étant moins coûteux. Les logiciels malveillants avancés codés par des groupes de cybercriminels organisés utilisent plutôt des programmes d’emballage personnalisés et aussi implémentent une protection complexe au sein de fichiers malveillants en plus pour crée plusieurs couche de protection.

Nous allons concentrer sur les packers standard, il existe plusieurs formats de packer connus et reconnus : UPX, FSG, Armadillo, Themida, Petite, etc.

Avant de pouvoir décompresser ( Unpacker ) un programme ayant était compressé, il faut pouvoir déterminer qu'elle packer a été utiliser pour compresser notre échantillons.

C'est la vocation de cette article.

III.    Les logiciels de détection de packer

Il existe une multitude de programme conçu pour analyser un binaire et de déterminer si le binaire est packé ou pas.C'est programme permettre de connaître qu'elle parker a été utiliser sur le binaire.

Voici une liste non exhaustive d'outil permettant de déterminer si un binaire est packé.

1) PEiD V0.95

Il est l'un des plus populaire pour l'analyseur de fichier exécutables.

L'analyse est effectuée sur la base de données de signatures interne et externe.

Il existe plusieurs niveaux d'analyse allant du plus rapide au plus profond. l'intérêt également est la fonctionnalité étendre par des plugins externes la base de signature.

Les signatures étant stockées dans un fichier texte séparé, vous pouvez donc facilement y ajouter vos propres fichiers et aussi comprendre ce comment est construit les signature.

 

2) Detect it Easy V0.65 (DiE)

Il est très proche de PEiD sur la partie scan de packer. Mais il fournit également certaines fonctions utiles pour l'analyse du PE :visualiser les importations, les sections, visualiser d'un fichier en mode hexadécimal, désassembler ( basique ), l'afficher des caractéristiques de base de PE. Et les classique hachage MD5 et le CRC-32.

Il dispose également de la fonctionnalité étendre le programme avec des plugins externe.

 
 

3) RDG Packer Detector V0.76

Celui-ci est un détecteur de packer au sens propre, vous pouvez aller sur le site suivant : http://www.rdgsoft.net/ pour télécharger le programme. Nous trouvons simple à utiliser. Il reconnaît bien les Packers à la différence d'autre plus ancien.

Est le bon outil pour cette tache de détection.

  
 

4) ExeInfo PE

Il est également dans la même vaine que PEiD avec quelque fonction complémentaire

Idée d'ajouter l'information sur l'outil pouvant servir à Unpacker le binaire est bien pour des débutant.

 

 

5) file insPEctor XL

Lui est un analyseur ancien des années 2000. Définit de manière heuristique les packers et les compilateurs de fichiers exécutable.

Il affiche aussi les données de base des tables d'en-tête, de section, d'importation et d'exportation du PE. En plus de l'analyseur.

Il inclut des fonction d'ajouté une section vide à un fichier ou de nouvelles fonctions d'importation, une calculatrice RVA à décalage,la modification de la date et l'heure d'un fichier, rediriger l'OEP.

Il devient moins utile pour la détection de packer que pour ses fonctions sur le PE

Dans la capture cela ce voit, il détecte bien UPX. Mais sur une signature ancienne.

6) Stud_PE

Il est un très bon programme, en plus d’analyser la manière dont un fichier est compressé, il affiche de nombreuses autres informations utiles sur le PE: sections, ressources, tables d’import et d’exportation, en-tête DOS.

L'éditeur HEX intégré à Stud_PE met en évidence les champs d'en-tête de fichier sélectionnés, ce qui est très pratique pour analyser sa structure.

Les fonctionnalités peuvent être étendue à l'aide de plug-ins, et les plug-ins de PEiD sont compatible également à l'outil.

IV.    Analyse d'un packer standard UPX

A partie d'un programme simple, nous allons le packé à partir de deux version de UPX, pour obtenir deux échantillons de référence.

Nous avons pris simple programme affichant une MessageBox, crée a partir de visual studio avec un projet SDK.

Nous mettons le code source correspondant de ce petit programme.

// WinBasic.cpp : Defines the entry point for the application. #include "stdafx.h" int APIENTRY WinMain(HINSTANCE hInstance,                                           HINSTANCE hPrevInstance,                                           LPSTR     lpCmdLine,                                           int       nCmdShow) {             MessageBox(0, "Hello", "Msg Title Basic Win", MB_OK);             return 0; }

Nous avons utilisé Upx290 et Upx308 dans notre démonstration. Vous pouvez les télécharger à partir des urls suivant:

https://sourceforge.net/projects/upx/files/upx/3.08/

https://sourceforge.net/projects/upx/files/upx-beta/2.90/

De là nous avons générés deux échantillons de notre référence, l'un avec Upx 290 et l'autre avec Upx 308. Vous trouverez en dessous la capture pour la génération

 Nous les avons renommé et positionné dans un répertoires "Echantillons" pour la suite.

Nous avons passé l'un des échantillons ( WinBasicIcon_PackedToUpx308 ) dans différent outils de détection de packers. Nous mettons la capture en dessous:

 

 

Nous avons entouré en rouge les parties qui nous intéresse à expliquer.

Il utilise la détection statique, elle consiste à analyser le code du fichier sans exécuter ce dernier. On note dans nos deux exemples l'utilisation de la détection par signature.

Il s’agit de détection qui correspond à des portions de code significative du binaire permettant une identification de la famille du packer et dans une plus grande mesure de la version du packer utilisé.

Et qui sont dans notre cas les premiers opcode du binaire pointé par EntryPoint du PE.

Comme l'outils nous donne l'adresse ou l'offset file pointant l'Entrypoint du PE. Il nous sera assez simple de valider cela. Dans notre exemple la valeur indiqué est 0x00004910.

En utilisant un outil pour la lecture des binaires maison, on peut voir que cela correspond bien.

 Nous obtenons la séquence suivante:

60 BE 00 A0 40 00 8D BE 00 70 FF FF 57 EB 0B 90 8A 06 46 88 07 47 01 DB 75 07 8B 1E 83 EE FC 11 DB 72 ED B8 01 00 00 00 01 DB 75 07 8B 1E 83 EE FC 11 DB 11 C0 01 DB 73 EF 75 09 8B 1E 83 EE FC 11 DB 73 E4 31 C9 83 E8 03 72 0D C1 E0 08 8A 06

Mais, elle n'est pas exploitable directement lié au différents Opcode présent utilisant des référence à des adresses propre au  programme.

Nous avons passer ce code dans l'une de nos outils pour désassemblée les opcodes et nous avons également indiqué ce qui sont relatif à des positions pouvant changer. Les éléments problématique sont soulignée en bleu dans la capture en dessous.

Nous utilisons une notation pour l'écriture de la signature ou  les octets à  ne pas prendre en compte son remplacé par ?? ou  peut trouver d'autre représentation  avec XX dans certains outils. Cela nous donne la chaîne suivante.

"60 BE ?? ?? ?? ?? 8D BE ?? ?? ?? ?? 57 EB 0B 90 8A 06 46 88 07 47 01 DB 75 07 8B 1E 83 EE FC 11 DB 72 ED B8 01 00 00 00 01 DB 75 07 8B 1E 83 EE FC 11 DB 11 C0 01 DB 73 EF 75 09 8B 1E 83 EE"

Nous avons intégrer dans notre base de donnée ces signatures de packer dont UPX308 à notre outils "EzSearchPackers.exe".

Le moyen de stockage est assez basique un simple fichier INI, vous trouverez beaucoup de ce format. Lié à son utilisations comme moyen de déclarer vos propres signatures dans plusieurs outils comme Peid.

De là, nous avons passer notre échantillon "WinBasicIcon_PackedToUpx308.exe" à l'analyse au travers de notre propre détecteur de packer ( EzSearchPackers.exe ).

Et nous avons bien l'identification que le programme est paqueté avec le packer UPX 3.08 avec la détection par la signature crée au dessus.

Notre outils fournit deux informations distinct sur deux techniques. L'une basé sur le nom des sessions pour déterminer rapidement si des noms de sections correspondant à des nommages prédéfini dans notre cas UPX1 et une base de signatures présenté au dessus.

Mais l'outil permet aussi d'obtenir la vu sur les octets de pointé par l'EntryPoint et de pouvoir afficher le codes assembleur et les octets en hexadecimal pour construire de nouvelle signature lors d'analyse de malware.

De même les signatures référence peuvent être lister , nous reviendrons sur ce point

dans un autre article sur la construction d'une base de signature référentielle.

  

V.    Conclusions

L'intérêt de connaître si un binaire est paqueté ou non et qu'elle IDE a permit de le générer

réduit l'investigation et surtout permet de réduire le temps pour analyse du code. Car s'il est paqueté, vous devrez neutraliser cette couche en le dépaquetant avant de pouvoir analyse le binaire au niveau fonctionnelle au travers du PE ou d'une étude statique.

Comprendre les processus de reconnaissance par signature est importante. Car la technique étant lié à une identification d'un bloc d'opcode , elle est donc empirique  et elle est dépendante de la bonne qualité des signatures. Nous aborderons ce point dans un prochaine article. Car vous trouvez sur Internet une quantité de base de signature, mais beaucoup ne sont pas de qualité ou sont un agrégat de N bases ou incluant des volumes de doublons important

Il faut donc faire une passe a travers des outils pour construire base de signature représentatif

Et non une concaténation de base de signature.

De plus vous verrez des signature contradictoire ou associé à de mauvais packer.

Donc comprendre la technique c'est éviter de perdre du temps sur une mauvaise piste d'investigation lors de l'étude d'un malware.

Concepte de l'Imphash

I.    Introduction

Dans la sécurité de l'information , plus particulièrement dans l'analyse des logiciels malveillants , imphash ( "Imports Hash" ) est le résultat d'une somme de contrôle d'un texte créé à partir des fonctions importées (Import Address Table)  d'un exécutable windows via une partie inclus dans le PE (Portable Executable), à l'aide de l'algorithme MD5 , une idée venant des chercheurs de Mandiant en 2004.

Afin de fournir un mécanisme permettant la recherche d'autres copies ou variante d'un programme malveillants au sein d'une même famille, car les auteurs de logiciels malveillants ne modifient pas les fonctions de la bibliothèque qu'ils utilisent lors de la génération de nouvelle souche. c’est-à-dire lorsqu’ils compilent à nouveau le même programme malveillant, générant ainsi de nouveau exécutable. Dans ce cas, bien que le hachage du fichier change lié au fait qu'il est fait quelques modifications dans le code.

A contrario,s'il n'ont pas intégrer de nouveau appel d'Api au sein du  programme, l'emphash restera le même pour les différents variant ou version.

Et dela nous pouvons dire qu'ils sont fonctionnellement proche et font partie de la même famille du malware.

I.    L'algorithme de calcul de l'Imphash

Le texte à partir duquel la somme de contrôle MD5 est calculée est formé comme suit:

1. Analyse la table d'importation (IT) ou la table des importations de fonctions exécutables PE, qui contient un enregistrement des fonctions importées par cet exécutable et ses bibliothèques respectives.
2. Pour chaque fonction trouvée, il préfixe son nom avec le nom de la bibliothèque (DLL) où il se trouve sans son extension, mais en maintenant le point. Par exemple, si l'exécutable importe la fonction DeleteCriticalSection () à partir de la bibliothèque KERNEL32.DLL, cette importation réécrite serait KERNEL32.EnterCriticalSection .
3. Si la fonction n'est pas importée nominativement, on essaie de la résoudre avec une base de données locale et, si cela n'est pas possible, son numéro ordinal est utilisé.
4. Convertit le texte en minuscule, obtenu kernel32.entercriticalsection .
5. Répétez l'intégralité de l'algorithme pour les autres fonctions importées par le binaire, en concaténant le résultat avec le précédent, séparés par des virgules.
6. Enfin calcule le hash MD5 du texte final résultant.

II.          Exemple conceptuel

Prenons comme exemple un exécutable PE qui importe les fonctions suivantes, dans cet ordre:

• EnterCriticalSection (), à partir de KERNEL32.DLL
• MessageBoxA (), à partir de USER32.DLL
• CreateWindowExA (), à partir de USER32.DLL

Quiconque souhaite calculer l'emphash de cet exécutable doit calculer le hachage MD5 de la chaîne suivante (sans prendre en compte les caractères de nouvelle ligne):

  kernel32.entercriticalsection, user32.messageboxa, user32.createwindowexa

Le résultat de l'exemple est 2e4b75f13408b52416d9c846d1189ae6. Il est donc possible de faire le même calcul pour différents fichiers afin de trouver d'autres copies de la même famille. C'est une méthode de recherche de fichiers similaires.

Nous avons implémenté, cela dans une tools avec génération de la chaîne avant l'appel de l'algorithme MD5.

qui nous permet de teste l'exemple indiqué du dessus, voici le résultat obtenu en dessous:

 

 Nous fessons pareil pour un échantillon "AntiFireWall.exe", cela nous donne son Imphash

pour ce fichier qui est "94802f07a877e9817802657426aadd80". Voir la capture en dessous:

 

Dans le cas de ce fichiers la chaîne résultante, construit à partir de l'IAT est la suivante:

kernel32.closehandle,kernel32.createfilea,kernel32.createfilemappinga,kernel32.createprocessa, kernel32.createremotethread,kernel32.getfilesize,kernel32.getprocaddress,kernel32.loadlibrarya, kernel32.mapviewoffile,kernel32.unmapviewoffile,kernel32.virtualallocex,kernel32.virtualprotect, kernel32.writeprocessmemory

Nous voyons que programme n'appel que des APIs de module Kernel32.dll

Kernel32.dll => Apis using : 13 - CloseHandle - CreateFileA - CreateFileMappingA - CreateProcessA - CreateRemoteThread - GetFileSize - GetProcAddress - LoadLibraryA - MapViewOfFile - UnmapViewOfFile - VirtualAllocEx - VirtualProtect - WriteProcessMemory

Nous allons vérifier l'imphash que génére un tier au travers du site VirusTotal 

( https://www.virustotal.com/#/home/upload ) en poussant notre échantillon de test.

Si nous retrouvons notre Imphash et aussi connaitre plus de détaille sur le binaire au niveau de sa note.

Nous avons bien le même Imphash que celui calculer par "VirusTotal". Il est intéressant de voir que l'échantillons atteint une note 33/65 , voir la capture qui suit:

 

Il remonte qu'il est décrit assez souvent comme un "Trojan". Nous rentrerons dans l'analyse plus profondément sur ce binaire dans un prochain article sur la structure PE.

Si on regarde de plus près, sachant qu'il utilise des bases données virale et qu'il apparaît des noms identiques ou distinct entre les anti-virus.

On peut ce dire que Ad-Aware , ALYac , BitDefender , Emsisoft , F-Secure , GData , eScan utilise la même source ou base de référence étant donnée que la référence fournit est identique "Trojan.Generic.11937180"

Cela peut peut-être intéressant de creusé cela , les relation entre les Anti-virus et leurs source est leurs référence utilisé.

I.    Conclusions

L'intérêt est de pouvoir catégorisé des exécutables en fonction du type Api importé et donc utilisé dans le dit programme.

en ce basant sur l'IAT qui contient la liste des bibliothèques et des fonctions Api liées dynamiquement du binaire et présent au sein de celui-ci utiliser pendant l'exécution du processus. L'idée est donc la suivante: si deux binaires ont le même “imphash”, il y a de fortes chances qu'ils aient des objectifs similaires par le fait qu'il utilise le même jeu d'Api.

Mais attention, il faut pas oublier que le malware peut garder dynamiquement les Apis qu'il souhaites ans avoir a passer par le mécanisme de IAT.

en passant par GetModuleHandle(..) et GetProcAddress(..) ou pas des fonctions customs comme dans les shellcodes

Cette article avez en premier, pour but de vous familiarisé avec Imphash et qu'elle élément cela peut apporté dans une analyse virale et comprendre sa construction.

les Hashs du Malware Emotet

I.    Introduction

Emotet est classifié comme malware dans la catégorie cheval de troie ( Trojan ) , mais c'est 

un cheval de troie évolué et modulaire. Il fonctionne principalement comme un téléchargeur ou un dropper pour introduire d'autre programme malveillant.

Dans cette quelque ligne, nous allons revoir celui-ci, en  regardant uniquement la partie hash des processus servant a détecté les environnements virtualisés.
Le code utilisé sert à faire de l'anti-virtualisation au travers de la détection des processus trahissant
l'existance d'une machine virtuel type Vmware,HyperV, VirtualBox, VirtualPC ... etc.

I.    Algorithme de création des hashs

A partir d'information disparate existant sur le web, nous avions crée un tools permettant de disposer de l'algorithme de hash de Emotet en C++ pour cette partie des hashs représentant des noms de processus

Nous avions réalise ce programme pour déterminer les hashs non précisé sur le web.

Lorsque nous avons rechercher des informations sur ses hashs.

Il y avait que quatre processus ou l'on disposé du hash résultant que nous avons remis en dessous dans ce tableau

Nom du processus	Hash
vboxservice.exe	0xBCF398B5
vmacthlp.exe	0x2C967737
vmtoolsd.exe	0xE3EBFE44
vboxtray.exe	0x61F15513

Hors la liste des hashs était bien plus importante et contenait 15 hashs. Mais en cherchant, il y a pas informations accessible sur ses hashs. Hors N sites re pointant sur la même source initiale. 

Nous les avons remis en dessous dans un tableaux en C

DWORD MalwareEmotetListHashOfProcessNameTrackEnvirVirtualMachine [] = { 0xBCF398B5, // vboxservice.exe  ( VBoxService.exe ) 0x61F15513,   // vboxtray.exe 0xD8806134,  0xC96D800E,                         0x7D87B67D,        0x2C967737,  //vmacthlp.exe 0x0C7F2BD9, 0x8BFF04B8,             0xEF88AA77, 0x2023EE05,  0x87725BFC, 0xB6521E80,              0xAFED9FB6,                        0x4EBEEE4C,                                    0xE3EBFE44    //vmtoolsd.exe };

Nous avons des outils permettant de casser par force brute les hashs lors de nos études de hashs inconnue.

Nous avons passer les hashs de la liste du malware Emotet au travers d'un outil dédier

Cela nous a donné les résultats suivant:

Hash	Nom des processus possibles
0xBCF398B5	VBoxfsadam.exe VBoxahjoonf.exe VBoxjuxoebt.exe VBoxkptqtid.exe VBoxservice.exe       ( VirtualBox )
0x61F15513	vboxtray.exe             ( VirtualBox ) ehfyehe.exe xbbrbvt.exe zunorwq.exe
0xD8806134	vboxsvc.exe               ( VirtualBox )
0xC96D800E	vbbhxlfij.exe  prl_bfygksb.exe           vboxrqpddne.exe virtualbox.exe           ( VirtualBox ) vmgfltzwj.exe
0x7D87B67D	vmnat.exe                   ( VMware Workstation )
0x2C967737	vmacthlp.exe              ( VMware )
0x0C7F2BD9	vmware-authd.exe
0x8BFF04B8	vmware-pijkpde.exe  xenfzejmkd.exe vmwareqsftnsl.exe  vmnetdhcp.exe           ( VMware Workstation ) xennocobee.exe                crfxdeo.exe lklcejb.exe
0xEF88AA77	vmware-usbarbitrator64.exe  ( VMware )
0x2023EE05	vmware-hostd.exe                    ( VMware )
0x87725BFC	vmware-tray.exe                      ( VMware )
0xB6521E80	vmware.exe                              ( VMware )
0xAFED9FB6	vmwarealiucwl.exe  vmware-buyiuib.exe prl_oyfbmvq.exe prl_dthnebc.exe               <! Bizarre/ Non encore déterminer !> Vuoietee.exe
0x4EBEEE4C	vmczpsvvj.exe      vmwarelamxmoy.exe   vmware-vmx.exe     (VMware Workstation 7)
0xE3EBFE44	vmtoolsd.exe            ( VMware )

Voici une capture de l'outil que nous avons réalisé pour effectuer la recherche des noms de processus pouvant correspondant au hash du malware.

Analyse de hash Emotet

 

Nous mettons l'algorithme correspondant du malware Emotet

DWORD CalcCustomHashEmotet(const char* pProcessName) {                             DWORD dwHash = 0x00000000;             int i=0;             do             {                         char c = pProcessName[i];                         if( c >=  'A' && c <=  'Z' ) c = c + 0x20;                         dwHash = dwHash * 0x0019660D + c + 0x3C6EF35F;                                                 i++ ;             }while(pProcessName[i]!=0x00);             return dwHash; }

Dans exemple nous avons pris "VBoxservice.exe" qui donne le hash 0xBCF398B5

Lors d'une analyse, cela permet d'avoir un point d'accroche pour croiser les mécanismes utilisé par d'autres malwares.

I.    Les processus traqué pour Anti-VM

Nous remettons quelques processus de la listes que cherche Emotet

Cela permet de reconstruire le mode de détection de Anti-VM et croisé l'ordonancement avec la logique du développeur sur le tableau des hashs.

vboxtray.exe est un processus appartenant au "VirtualBox Guest Additions de Sun Microsystems" et donc trahi que le Windows est hébergé par VirualBox. Il est là pour gérer plus éléments d'intération dont la gestion du copier-coller

VBoxService.exe est un processus appartenant également à "VirtualBox Guest Additions de Sun Microsystems" et aussi trahi que le Windows est hébergé par VirualBox. Il est là pour la synchronisation avec l'hôte en autre.

vboxsvc.exe est un processus appartenant également à "VirtualBox" présent dans les processus d'une virtual machine hébergé par VirtualBox

Vmnat.exe fournit les services NAT aux machines virtuelles exécutées dans VMware Workstation.

vmacthlp.exe ( Vmware Physical Disk Helper Service ) et trahi que le windows est hébergé par Wmware.

Pour l'ensemble ce sont des composants des moteurs de virtualisation et ses processus sont déjà connu pour être moyen de tracer la présent d'environnement virtuel et faire de l'anti-VM au sein des malwares. Il n'y a pas de réel nouveauté dans les processus recherché. Le seul qui pour l'instant n'est pas encore déterminer suite à l'analyse est le hash 0xAFED9FB6.

Mais vu les autres l'intérêt de continuer semble pas utile. Tous simplement par le développeur au vu du tableau les a ranger dans l'ordre des moteurs de virtualisation et doit théoriquement décrire un processus pour VMware.

II.          IV Autre malwares

Il existe une multitude de méthode pour détecter les environnements d'analyse et cela est propre à beaucoups de malware. citons au autres exemple de malware "Rebhip" est capable de détecter toutes les machines virtuelles populaires ainsi que des outils d’analyse automatisés disponibles au public, tels que ThreatExpert, Anubis, CWSandbox et JoeBox. En termes de détection de VM, il est également capable de détecter VMWare, Virtual PC et Virtual Box tous comme Emotet.

Nous allons donc plutôt chercher vers d'autre partie du malware des éléments à investigué et regarder d'autre malware pour expliquer des technique Anti-VM différentes.

III.     Conclusions

L'intérêt de tracer la méthode utiliser par un malware pour détecter la présence d'une virtual machine et là pour pouvoir la neutralisé et rendre Anti-VM au sein du code du malware non impactant pour l'analyse tous en restant dans l'environnement virtualisé. Il existe différentes méthodes qui son donc à désactiver pour duper le malware pour qu'il effectue l'action pour là quelle il a été conçu tous en étant dans un contexte d'étude sécurisé . 

La méthode de Anti-VM que l'on vient de voir utilisant la partie analyse des processus pour trahir l'existence d'un environnement virtualisé est très courant et l'une des plus simple à mettre en place. Vous trouverez couramment cette technique lors de l'étude d'un malware.

Comprendre les processus recherché pour trahir la présent d'une machine virtuel et importante. Car les techniques étant similaire d'un malware à l'autre, il est plus simple de trouver d'une liste de processus correspondant à l'anti-vm utiliser dans un autre malware et aussi de trouver des hashs correspondant. le gain de temps n'est pas négligeable et vous permet de vous concentrer uniquement sur ce nouveau ou non trouvé de déterminer les algo de Hash s'ils sont standard ou non.