AccueilđŸ‡«đŸ‡·Chercher

Analyse des logiciels malveillants

L'analyse des logiciels malveillants (« malware » en anglais) permet de déterminer leurs fonctionnements et leurs impacts potentiels. C'est une tùche essentielle dans la sécurité informatique, elle fournit la compréhension nécessaire pour concevoir des contre-mesures efficaces et des stratégies d'atténuation contre les différents logiciels malveillants.

Contexte

Les logiciels qui « remplissent dĂ©libĂ©rĂ©ment les intentions nuisibles d'un attaquant » sont qualifiĂ©s de logiciels malveillants. Ils sont destinĂ©s Ă  accĂ©der aux systĂšmes informatiques et aux ressources rĂ©seau, perturber les opĂ©rations informatiques, et recueillir des informations personnelles sans le consentement du propriĂ©taire du systĂšme crĂ©ant ainsi une menace Ă  la disponibilitĂ© de l'Internet, l'intĂ©gritĂ© de ses hĂŽtes et la vie privĂ©e de ses utilisateurs. Les logiciels malveillants regroupent plusieurs variantes comme le virus, le ver, le cheval de Troie, le rootkit, la backdoor, le botnet, les espiogiciels, l'adware, etc. Ces classes de logiciels nuisibles ne sont pas mutuellement exclusives, ce qui signifie qu'un maliciel particulier peut rĂ©vĂ©ler les caractĂ©ristiques de plusieurs classes en mĂȘme temps[1].

Les attaquants exploitent les vulnérabilités dans les services Web, les navigateurs et les systÚmes d'exploitation, ou utilisent des techniques d'ingénierie sociale pour inciter les utilisateurs à exécuter le code malveillant afin de propager les logiciels malveillants. Les auteurs de logiciels malveillants utilisent des techniques d'obfuscation telles que l'insertion de code mort, la réaffectation de registre, le réordonnancement de sous-programme, la substitution d'instructions, la transposition de code et l'intégration de code pour échapper à la détection par les défenses traditionnelles telles que les pare-feux, les antivirus et les passerelles qui utilisent généralement des techniques basées sur les signatures et ne peuvent pas détecter les exécutables malveillants qui utilisent ces techniques. Les éditeurs d'antivirus commerciaux ne sont pas en mesure d'offrir une protection immédiate pour les logiciels de type zero-day, car ils doivent les analyser pour créer leurs signatures[2].

Pour surmonter la limitation des mĂ©thodes basĂ©es sur les signatures, des techniques d'analyse de logiciels nuisibles sont suivies, qui peuvent ĂȘtre statiques ou dynamiques. Les techniques d'analyse des logiciels malveillants aident les analystes Ă  comprendre les risques et les intentions associĂ©s Ă  un Ă©chantillon de code malveillant. Les informations ainsi obtenues peuvent ĂȘtre utilisĂ©es pour rĂ©agir aux nouvelles tendances dans le dĂ©veloppement de logiciels malveillants ou pour prendre des mesures prĂ©ventives afin de faire face aux menaces futures. Les fonctionnalitĂ©s dĂ©rivĂ©es de l'analyse des logiciels malveillants peuvent ĂȘtre utilisĂ©es pour regrouper les logiciels malveillants inconnus et les classer dans leurs familles existantes[2].

Avant de crĂ©er les signatures pour les maliciels nouvellement arrivĂ©s, ceux-ci doivent ĂȘtre analysĂ©s afin de comprendre les risques et les intentions associĂ©s. Le programme malveillant et ses capacitĂ©s peuvent ĂȘtre observĂ©s soit en examinant son code ou en l'exĂ©cutant dans un environnement sĂ»r[2].

Analyse statique

L'analyse d'un programme malveillant sans l’exĂ©cuter se nomme l'analyse statique. Les modĂšles de dĂ©tection utilisĂ©s en analyse statique sont la comparaison de signatures de chaine de caractĂšres, sĂ©quence d'octets n-grams, appels syntaxique de bibliothĂšque, diagramme de flux de contrĂŽle, frĂ©quence de distribution des opcodes. L’exĂ©cutable malveillant doit ĂȘtre dĂ©chiffrĂ© ou dĂ©compressĂ© pour procĂ©der Ă  une analyse statique[2].

DĂ©compilation

La dĂ©compilation offre une technique attractive pour aider l'analyse de malware en permettant celle-ci d'ĂȘtre effectuer Ă  haut niveau afin d'avoir une forme plus abstraite du code binaire. La dĂ©compilation consiste Ă  la collection de mĂ©canismes de rĂ©cupĂ©ration abstraite afin de remonter des abstractions haut niveau qui ne sont pas lisibles dans le code binaire. Les analyses manuelles et automatiques peuvent ĂȘtre effectuĂ©es sur du code de programme dĂ©compilĂ© afin de rĂ©duire le temps requis pour l'analyse. Vis-Ă -vis de cet objectif, la communautĂ© scientifique a abordĂ© des principes de mĂ©thodes pour la rĂ©cupĂ©ration d'abstraction de haut niveau nĂ©cessaire pour la reconstitution du code source. Cela inclut la rĂ©cupĂ©ration des types de donnĂ©es, le flux de contrĂŽle de structure haut niveau tel que la construction de if-then-else et de boucle while par exemple depuis le code binaire. MalgrĂ© des avancĂ©es significatives, les Ă©tats de l'art sur les dĂ©compilateurs crĂ©ent un code vraiment complexe et ne se concentre pas sur la lisibilitĂ©. Cependant, certains dĂ©compilateurs existent afin d'amĂ©liorer la lecture du code dĂ©compilĂ© et le rendre plus facile Ă  comprendre. Ainsi, ils accĂ©lĂšrent la rĂ©troconception de programme malveillant[3].

Signature numérique

La dĂ©tection basĂ©e sur la signature numĂ©rique est la technique la plus largement utilisĂ©e par les anti-virus. Une signature est une sĂ©quence d'octets qui peut ĂȘtre utilisĂ©e pour identifier un logiciel malveillant spĂ©cifique. Les anti-virus basĂ©s sur la dĂ©tection de signature doivent maintenir un dĂ©pĂŽt de signatures de maliciels dĂ©jĂ  connus et celui-ci doit ĂȘtre mis Ă  jour frĂ©quemment dĂšs qu'une nouvelle menace est dĂ©couverte[4]. Les deux algorithmes MD5 et SHA1 sont utilisĂ©s pour gĂ©nĂ©rer la signature de hachage d'un fichier exĂ©cutable (16 octets pour MD5 et 20 octets pour SHA1)[5].

La dĂ©tection basĂ©e sur la signature est facile, plutĂŽt rapide et efficace contre les types de malware ordinaire. L'inconvĂ©nient de cette mĂ©thode et qu'elle nĂ©cessite une mise-Ă -jour de la base de donnĂ©es des signatures et que si la signature d'un maliciel n'est pas prĂ©sent dans celle-ci, le fichier ne sera pas dĂ©tectĂ© comme malveillant. De plus, une simple technique d'obfuscation peut ĂȘtre utilisĂ©e pour changer la signature d'un mĂȘme malware et par consĂ©quent, Ă©chapper Ă  la dĂ©tection de signature[4].

ChaĂźnes de caractĂšres

Les chaßnes de caractÚres sont des propriétés facilement interprétables. Ces chaßnes peuvent refléter l'intention et l'objectif de l'attaquant car elles contiennent souvent des informations sémantiques importantes d'un comportement malveillant. Par exemple la chaßne suivante :

<html><script language=‘javascript’>window.open(‘readme.eml’)

existe toujours dans le ver Nimda, montrant que le ver essaye d'infecter les scripts. Un autre exemple est la chaĂźne &gameid=%s&pass=%s;myparentthreadid=%d;myguid=%s qui indique les intentions de l'attaquant qui sont de dĂ©rober le mots de passe d'un jeux-vidĂ©o en ligne et de les renvoyer au serveur. Par ailleurs, les chaĂźnes de caractĂšres sont des fonctionnalitĂ©s robustes et il n'est pas facile pour le crĂ©ateur du malware d'Ă©chapper Ă  la dĂ©tection par chaĂźnes de caractĂšres. La raison est que mĂȘme si des variantes de logiciels malveillants peuvent ĂȘtre gĂ©nĂ©rĂ©es en recompilant ou en adoptant des techniques d'obfuscation, modifier toute la table d'interprĂ©tation des chaĂźnes de caractĂšres n'est pas pratique dans la majoritĂ© des programmes[6].

N-grammes

Les n-grammes sont toutes les sous-chaßnes de caractÚre de longueur N dans le code du programme. Par exemple, la séquence "82EDD875" est segmentée en 5-grammes :

  • 82EDD
  • 2EDD8
  • EDD87
  • DD875

Au cours de la derniÚre décennie, de nombreuses recherches ont effectué une détection de logiciels malveillants inconnus basée sur le contenu du code binaire[6].

Opcodes

Un opcode (pour operational code) est une sous partie d'une instruction en langage machine qui identifie les opérations qui sont exécutées. Plus précisément, un programme est défini par une série d'instructions assembleur ordonnés. Une instruction est une paire composée d'un code opérationnel et d'une opérande ou d'une liste d'opérandes. Par exemple :

mov ebx ebx
add eax 1
xor eax eax
call sub_401BCD

Les segments d'instruction peuvent souvent montrer les fonctionnalitĂ©s d'un programme. Des Ă©tudes ont montrĂ© qu'en pratique, les Ă©chantillons d'un logiciel malveillant dĂ©rivĂ© du mĂȘme code source, ou qui proviennent d'une mĂȘme famille de logiciels malveillants partagent souvent un grand nombre de blocs ou segments d'instructions en commun[6].

Graphe de flot de contrĂŽle

Les graphes de flot de contrÎle représentent le flux d'exécution d'un programme. Ils sont beaucoup utilisés dans l'analyse de logiciel et ont été aussi énormément étudiés[6].

Outils

Des outils de dĂ©sassemblage, debug et de capture de mĂ©moire-vive peuvent ĂȘtre utilisĂ©s afin d'inverser et analyser la pile d’exĂ©cutables sous Windows. Les outils de dĂ©sassemblage et de debug tel que IDA Pro et OllyDbg affiche le code du programme malveillant sous forme d'instructions assembleur x86 Intel, ce qui fournit des idĂ©es sur l'intention du malware et ce qu'il fait. De mĂȘme que cela permet d'identifier l'attaque via les modĂšles utilisĂ©s par le malware. Les outils de capture de mĂ©moire-vive comme LordPE et OllyDump sont utilisĂ©s afin d'obtenir du code protĂ©gĂ© localisĂ© dans la mĂ©moire du systĂšme et l'enregistrer dans un fichier. C'est une technique particuliĂšrement utile pour analyser des exĂ©cutables qui sont chiffrĂ©s par exemple car ils sont difficiles Ă  dĂ©sassembler[7].

Logiciel malveillant avancé

Un logiciel malveillant avancé contient une variété de mécanismes codés spécifiquement pour rendre sa détection et son décryptage difficile. Le tableau ci-dessous illustre trois approches pour échapper à l'analyse statique :

Type Description
Chiffré Dans cette approche, qui consiste à utiliser le chiffrement, un programme malveillant chiffré est généralement composé du déchiffreur et du corps principal du programme chiffré. Le déchiffreur récupÚre le corps principal du programme chaque fois que le fichier infecté est exécuté. Pour chaque infection, en utilisant une clé différente, le logiciel malveillant rend la partie chiffrée unique, cachant ainsi sa signature. Cependant, le principal problÚme de cette approche est que le déchiffreur reste constant de génération en génération. Cela permet aux scanners antivirus de détecter ce type de malware en fonction du modÚle de code du déchiffreur[8].
Polymorphe Le malware polymorphe parvient Ă  crĂ©er un nombre incalculable de dĂ©crypteurs distincts Ă  l'aide des mĂ©thodes d’offuscation, y compris l'insertion de code mort, la rĂ©affectation de registre, et plus encore. MĂȘme si les malwares polymorphes peuvent efficacement contrecarrer la correspondance des signatures, leur corps constant qui apparaĂźt aprĂšs le dĂ©chiffrement peut ĂȘtre utilisĂ© comme une source importante pour la dĂ©tection[8].
MĂ©tamorphe Le malware mĂ©tamorphique a Ă©tĂ© proposĂ© comme une nouvelle approche au malware polymorphe. Notez que ce malware utilise au mieux les techniques d’offuscation pour faire Ă©voluer son corps vers de nouvelles gĂ©nĂ©rations, qui ont l'air diffĂ©rentes mais fonctionnent essentiellement de la mĂȘme maniĂšre. Pour une telle Ă©volution, il devrait ĂȘtre capable de reconnaĂźtre, d'analyser et de muter son propre corps chaque fois qu'il se propage. Il est important que le logiciel malveillant mĂ©tamorphique ne rĂ©vĂšle jamais son corps constant dans la mĂ©moire en raison de ne pas utiliser le chiffrement. Cela rend ce type de malware difficile Ă  dĂ©tecter pour les scanners antivirus[9].

Offuscation

L'idĂ©e de base est que certaines instructions du code original sont remplacĂ©es par des fragments de programme qui sont sĂ©mantiquement Ă©quivalents mais plus difficiles Ă  analyser, ou que des instructions supplĂ©mentaires sont ajoutĂ©es au programme et ne modifient pas son comportement[10]. À l'origine, cette technologie visait Ă  protĂ©ger la propriĂ©tĂ© intellectuelle des dĂ©veloppeurs de logiciels, mais elle a Ă©tĂ© largement utilisĂ©e par les auteurs de logiciels malveillants pour Ă©chapper Ă  la dĂ©tection. Pour Ă©viter les scanners antivirus, les malwares, dans les nouvelles gĂ©nĂ©rations, Ă©voluent leur corps grĂące Ă  la technique d'obfuscation[8].

Les techniques d’offuscation de binaire, qui transforment les binaires des logiciels malveillants en fichiers binaires auto-compressĂ©s et Ă  structure unique, sont conçues pour rĂ©sister Ă  l'ingĂ©nierie inverse et rendent ainsi l'analyse statique trĂšs coĂ»teuse et peu fiable. De plus, lorsqu'on utilise des exĂ©cutables binaires (obtenus en compilant du code source) pour l'analyse statique, les informations telles que, la taille des structures de donnĂ©es ou des variables, se perdent, compliquant ainsi l'analyse du code malveillant[11].

Le tableau ci-dessous présente les techniques d'obfuscation couramment utilisées dans les logiciels malveillants :

Technique Description
Constante opaque Les valeurs constantes sont omniprésentes dans le code binaire, que ce soit la cible d'une instruction de flux de contrÎle, l'adresse d'une variable ou un opérande d'une instruction arithmétique. Dans sa forme la plus simple, une constante est chargée dans un registre. Une technique d'obfuscation importante est basée sur l'idée de remplacer cette opération de chargement par un ensemble d'instructions sémantiquement équivalentes difficiles à analyser statiquement[10]. Exemple :
int zero[32] = { z_31, z_30, ... , z_0 };
int one[32] = { o_31, o_30, ... , o_0 };
int unknown = load_from_random_address();
int constant = 0;
for (i = 0; i < 32; i++) {
	if (bit_at_position(unknown, i) == 0)
		constant = constant ^ zero[i];
	else
		constant = constant ^ one[i];
}
constant = constant | set_ones;
constant = constant & set_zeros;
Émulation L'Ă©mulation est une approche gĂ©nĂ©rale d’exĂ©cution d'un programme Ă©crit pour une interface de matĂ©riel sous adjacente d'une autre. Un programme d’offuscation qui utilise l'Ă©mulation convertit un programme binaire pour une architecture d'ensemble d'instructions rĂ©elles, telle que x86, en un programme de bytecode Ă©crit pour un ISA virtuel gĂ©nĂ©rĂ© alĂ©atoirement et associĂ© Ă  un Ă©mulateur qui Ă©mule ce programme[12].
Insertion de code mort L'insertion de "code mort" est une technique qui consiste à ajouter des instructions inefficace voir sans effet au programme afin de changer son apparence sans aucune modification sur son comportement. Un exemple est l'ajout d'instructions NOP dans le code original d'un programme. Cependant, certains anti-virus peuvent contrepasser cette technique en supprimant les instructions inutiles durant l'analyse ce qui rend le programme détectable par signature[13].
Réaffections de registre L'offuscation par réaffections des registres consiste à intervertir les registres utilisés par les instructions entre plusieurs générations du programme. Cela permet de garder le comportement identique en changeant à nouveau sa signature. Un exemple serait qu'un programme utilise les registres suivants dans cette ordre: EAX, EBX et EDX, l'ordre serait changé de la façon suivante: EBX, EDX et EAX[13].
RĂ©organisation des sous-programmes La rĂ©organisation du sous-programme obscurcit un code original en changeant l'ordre de ses sous-programmes de maniĂšre alĂ©atoire. Cette technique peut gĂ©nĂ©rer n! diffĂ©rentes variantes, oĂč n est le nombre de sous-programmes[13].
Remplacement d'instructions La technique utilisant le remplacement d'instructions fait évolué le code original d'un programme en remplaçant certaines instructions par d'autres qui sont équivalentes pour le comportement. Par exemple, on pourrait remplacer un XOR par un SUB et un MOV par un PUSH/POP[14].
Transposition de code La transposition de code rĂ©organise les sĂ©quences d'instructions du code original sans impacter son comportement. Il existe pour cela deux mĂ©thodes qui permettent ce changement. La premiĂšre consiste Ă  mĂ©langer les instructions de façon alĂ©atoire et de retrouver l'ordre d’exĂ©cution original en y insĂ©rant des branches inconditionnel ou des instructions JUMP. Cependant, il n'est pas difficile de contrecarrer cette mĂ©thode car le programme original peut facilement ĂȘtre retrouvĂ©. La seconde mĂ©thode consiste a gĂ©nĂ©rer un nouveau programme en choisissant et en rĂ©organisant les instructions indĂ©pendantes qui n'ont pas d'impact sur les autres. Du fait que trouver les instructions indĂ©pendantes crĂ©er un problĂšme complexe, cette mĂ©thode est difficile Ă  implĂ©menter mais peut rendre aussi la dĂ©tection compliquĂ©e[14].
Intégration de code L'intégration de code a été introduite par le malware Zmist sur Win95. La technique consiste à prendre un programme sain comme cible et d'intégrer le code du malware dans celui-ci. Zmist commence par décompiler le programme ciblé en objets gérables et ajoute parfaitement son propre code entre eux puis réassemble le code en une nouvelle génération du programme. C'est une des méthodes les plus sophistiqué dans l'offuscation ce qui rend la détection difficile[14].

Bien qu'il soit concevable d'amĂ©liorer l'analyse statique pour traiter des techniques d'obfuscation plus avancĂ©es, il y a une limite fondamentale Ă  ce qui peut ĂȘtre dĂ©cidĂ© statiquement[15]. L'Ă©volution des techniques d'Ă©vasion utilisĂ©es par les auteurs de logiciels malveillants pour contrecarrer l'analyse statique a conduit au dĂ©veloppement de l'analyse dynamique[11] car la plupart des transformations d'obfuscation deviennent inefficaces une fois le code exĂ©cutĂ©[16].

Analyse dynamique

Analyser le comportement d'un code malveillant (les interactions avec le systÚme) pendant qu'il est exécuté dans un environnement contrÎlé (machine virtuelle, simulateur, émulateur, sandbox, etc) est appelé analyse dynamique[11].

L'analyse dynamique est plus efficace comparĂ©e Ă  l'analyse statique et ne requiert pas la rĂ©tro-conception du programme. Cette analyse dĂ©voile le comportement naturel du malware qui rĂ©sisterait mieux Ă  l'analyse statique. Cependant, cela coĂ»te beaucoup de temps et de ressources ce qui soulĂšve des problĂšmes d'Ă©volutivitĂ©. L'environnement virtuel, dans lequel le malware est exĂ©cutĂ©, est diffĂ©rent d'un environnement rĂ©el et le malware peut adopter un comportement artificiel plutĂŽt que son comportement naturel. De plus, il arrive que le comportement du malware ne soit dĂ©clenchĂ© que dans certaines conditions (Ă  une date systĂšme spĂ©cifique ou via une commande spĂ©cifique) et ne puisse pas ĂȘtre dĂ©tectĂ© dans un environnement virtuel[11].

Techniques

Plusieurs techniques peuvent ĂȘtre appliquĂ©es pour rĂ©aliser une analyse dynamique comprenant la surveillance des appels de fonctions, l'analyse des paramĂštres de fonction, le suivi de flux d'information, les traces d'instructions, etc[11].

Le tableau ci-dessous donne un aperçu des diffĂ©rentes techniques qui peuvent ĂȘtre utilisĂ©es :

Technique Description
Activité du registre Les activités du registre incluent l'ajout, la modification ou la suppression des fichiers de registre par certains processus[5].
Trafic réseau Le trafic réseau donne des informations à propos de la source et la destination ainsi que sur des détails des paquets de données[5].
Emplacement de démarrage automatique Certains exécutables s'installent dans divers endroits tels que le registre, le dossier de démarrage, etc.[5]
Appels d'API systÚme En général, les applications et les services invoquent l'API (pour Application Programmable Interface) pour l'exécution. L'appel d'API fournit des informations sur l'ID de thread, le nom de la DLL effectuée par les appels d'API et fournit également des détails sur le nom du paramÚtre qui passe, des valeurs de retour[5].
Image mémoire L'adresse mémoire donne des détails sur l'adresse d'instruction, l'adresse de processus, etc., de la mémoire principale, qui permet de détecter un comportement malveillant[5].

Analyse dans l'espace utilisateur / noyau

Analyser le programme malveillant dans l'espace utilisateur permet une approche d'analyse qui collecte des données, par exemple les invocations d'appels de fonctions ou les appels d'API. Une telle approche peut avoir facilement accÚs à toutes les structures de mémoire et aux informations de haut niveau fournies par le systÚme d'exploitation. La possibilité de cacher des informations à l'analyse dans l'espace utilisateur est vraiment limitée. Par exemple, cacher un processus ou le chargement d'une bibliothÚque aux autres processus tournants sur la machine n'est généralement pas possible depuis l'espace utilisateur. Cette limitation n'est pas aussi restrictive quand l'analyse d'un composant est sur l'espace noyau. Les outils d'analyse accédant aux fonctions au niveau du noyau peuvent collecter divers informations, comme les invocations d'appels systÚme et peuvent cacher leurs présences au logiciel malveillant qui s'exécute seulement dans l'espace utilisateur[17].

Analyse dans un Ă©mulateur

ExĂ©cuter un programme Ă  l'intĂ©rieur d'un environnement Ă©mulĂ© permet Ă  un composant d'analyse de contrĂŽler chaque aspect de l’exĂ©cution du programme. Selon la partie de l'environnement d'exĂ©cution Ă©mulĂ©, plusieurs formes d'analyse sont disponibles. Émuler le processeur et la mĂ©moire dans une sandbox permet d'exĂ©cuter du code potentiellement malveillant sans craindre des effets nĂ©fastes sur le vrai systĂšme. Un binaire est exĂ©cutĂ© dans une sandbox en lisant de façon successive les instructions et en rĂ©alisant les opĂ©rations Ă©quivalentes dans l'environnement virtuel Ă©mulĂ©. Tous les effets secondaires fait par l'exĂ©cutable sont contenus dans la sandbox. Beaucoup d'anti-virus emploient l'Ă©mulation de processeur et de mĂ©moire pour surmonter les difficultĂ©s imposĂ©es par les exĂ©cutables offusquĂ©s ou chiffrĂ©s. Pour analyser un potentiel binaire chiffrĂ©, il est exĂ©cutĂ© dans un environnement Ă©mulĂ© et si l'anti-virus dĂ©tecte une sĂ©quence non chiffrĂ©e, les signatures sont appariĂ©es sur le contenu de la mĂ©moire non chiffrĂ©e contenue dans la mĂ©moire Ă©mulĂ©e[17].

Analyse dans une machine virtuelle

Une machine virtuelle (VM) est une duplication efficace et isolĂ©e d'une vraie machine. Le moniteur de machine virtuelle (VMM) est responsable de la gestion de cette copie aux programmes et est responsable du matĂ©riel sous-jacent. En pratique, cela signifie qu'aucune machine virtuelle ne peut accĂ©der aux matĂ©riels avant que la VMM le lui assigne. Un composant d'analyse implĂ©mentĂ© dans la VMM a l'avantage d'ĂȘtre invisible par les programmes analysĂ©e. GĂ©nĂ©ralement, un tel composant d'analyse est soit directement intĂ©grĂ© Ă  la VMM ou dans sa propre machine virtuelle[18].

Outils

Avant d'exécuter un échantillon de malware, les outils appropriés à la surveillance sont[11] :

  • Process Monitor (pour le systĂšme de fichier et la surveillance du registre)
  • Process Explorer (pour la surveillance des processus)
  • Wireshark (pour la surveillance rĂ©seau)
  • Regshot (pour la dĂ©tection de changement dans le systĂšme).

Plusieurs outils automatique pour l'analyse dynamique existent en ligne, par exemple :

  • Norman Sandbox
  • CWSandbox
  • Anubis
  • Ether
  • ThreatExpert

Les rapports d'analyse générés par ces programmes donnent en profondeur une compréhension sur le comportement du malware et des éclaircissements sur les actions faites par celui-ci. L'analyse systÚme doit avoir une représentation appropriée des malwares, qui sont par la suite utilisés pour la classification selon leur similitude ou leurs fonctionnalités semblables[11].

Contre-mesures

L’offuscation d’exĂ©cutable n'est pas une solution efficace contre une analyse dynamique car celle-ci ne se base pas sur la signature du binaire ou les instructions produitent par celui-ci mais elle se focalise sur son comportement et il reste le mĂȘme avec ou sans offuscation.

Une des contre-mesures existantes pour l'analyse dans un émulateur est la suivante : Pour un échantillon malveillant qui veut détecté qu'il est exécuté dans un environnement émulé, il doit réaliser une opération sur un composant qui n'existe pas ou n'est pas suffisamment simulé dans le systÚme. Par exemple, l'émulateur peut avoir un comportements différent d'un vrai processeur dans le cas d'une faille connu sur les CPU (si le bug n'est pas pris en considération par l'émulation)[17].

Des instances de malware essayent de dĂ©tecter la plateforme d'analyse dans laquelle ils se trouvent, le cas Ă©chĂ©ant, le malware s'arrĂȘte simplement ou va exĂ©cuter un comportement non suspect pour tromper l'analyse[19].

Dysfonctionnement de la machine virtuelle

Faire dysfonctionner la machine virtuelle est un moyen facile de s'Ă©chapper de l’analyse. Par exemple, certains bugs Ă©taient prĂ©sents dans l'Ă©mulateur QEMU et l'un de ces bug Ă©tait "QEMU NE2000 MTU heap overflow". Exploiter ce bug rendait la machine virtuelle instable et dysfonctionner jusqu'Ă  l'arrĂȘt anormal de celle-ci[20].

Attaque sur le temps

L'attaque sur le temps vise pour le logiciel malveillant à différencier s'il se trouve sur une machine virtuelle ou non. En effet, les performances des applications sont différentes d'un vrai systÚme à un virtuel. Généralement, les performances d'une machine virtuelle sont plus lente qu'une machine réelle. Quelques techniques Anti-VM consistent à exploiter ces attaques sur le temps.

Ces attaques mesurent le temps d'exĂ©cution des instructions pour identifier si l'environnement oĂč ils se trouvent correspond Ă  une machine virtuelle. Un autre type d'attaque vise le cache d'une machine virtuelle. En effet, sur une vraie machine, une mĂȘme instruction aura un temps d'exĂ©cution selon que le cache est activĂ© ou non, sans cache, les performances seront plus mauvaises. Sur une machine virtuelle, le temps d'exĂ©cution sera le mĂȘme avec ou sans cache. Par consĂ©quent, l'utilisation de ces attaques peuvent servir Ă  dĂ©voiler l'environnement sur lequel le logiciel malveillant se trouve[20].

Empreinte d'un périphérique virtuel

Les empreintes d'une machine peuvent ĂȘtre utilisĂ©es comme moyen Anti-VM pour identifier l'environnement virtuel sur lequel le malware se trouve. En effet, les machines virtuelles crĂ©ent des pĂ©riphĂ©riques matĂ©riel avec des identifiants spĂ©cifiques qui peuvent ĂȘtre utilisĂ©s afin d'identifier la machine virtuelle[20] (par exemple, VMware utilise les tags "Logic BT-958" et "pcnet32" pour le pĂ©riphĂ©rique VGA et la carte rĂ©seau).

Exploitation d'un bug sur la machine virtuelle

Certaines machines virtuelles possĂšdent des bugs connus qui peuvent ĂȘtre utilisĂ©s pour vĂ©rifier l'environnement. L'entreprise VMware avait annoncĂ© que leurs produits avaient un bug qui permettait de sortir de la machine virtuelle. SI un attaquant peut accĂ©der aux fichiers de la machine hĂŽte depuis la machine virtuelle, cela donne l'opportunitĂ© de contrĂŽler et d'infecter la vraie machine[20].

Lutte Anti-VM

Les malware Anti-VM vont avoir un comportement différent selon l'environnement s'il est réel ou virtuel. Certaines solutions utilisent un algorithme appelé algorithme de distance de comportement (behavior distance algorithm) afin de distinguer si un malware est Anti-VM ou non. Cet algorithme compare la distance de comportement en estimant la variation du comportement des logiciels malveillants Anti-VM à partir d'environnements réels et virtuels. Pour cela, il utilise des séquences d'appel systÚme et mesure la distance comportementale entre deux processus. Cette approche est capable de détecter des attaques de mimétisme avec de faibles faux positifs. Un moniteur de processus est aussi utilisé afin de collecter ces évÚnements[21].

Analyse hybride

Les approches d'extraction d’analyse statiques et dynamiques ont leurs propres avantages et limites. ComparĂ©e Ă  l'analyse dynamique, l'approche statique est moins coĂ»teuse et peut couvrir tous les chemins de code (y compris les morceaux de programme qui ne sont pas toujours exĂ©cutĂ©s), fournissant ainsi une caractĂ©risation plus prĂ©cise et complĂšte des fonctionnalitĂ©s du programme.

Cependant, cela coute de haute performance en raison de techniques de mutation de bas niveau (comme l'offuscation ou le chiffrement). Au contraire, l'analyse dynamique résiste à l'obfuscation de bas niveau et convient à la détection de variantes de logiciels malveillants et de nouvelles familles, mais exécute souvent mal sur les échantillons de logiciels malveillants basés sir des déclencheurs. En outre, l'analyse dynamique est coûteuse et non évolutive en raison de sa couverture limitée.

Selon les statistiques de Comodo Cloud Security Center, environ 80 % des Ă©chantillons de fichiers peuvent ĂȘtre bien reprĂ©sentĂ©s Ă  l'aide d'une analyse statiques alors que seulement environ 40 % des Ă©chantillons de fichiers peuvent s'exĂ©cuter avec une analyse dynamique. En raison de leurs avantages et inconvĂ©nients respectifs, aucune approche statiques ou dynamiques ne peut fournir une solution parfaite Ă  l'extraction de caractĂ©ristiques dans l'analyse de logiciels malveillants. Par consĂ©quent, une approche globale intĂ©grant Ă  la fois l'analyse statique et dynamique et bĂ©nĂ©ficiant des avantages des deux serait souhaitable. L'analyse hybride est une approche qui combine les avantages respectifs de l'analyse statique et de l'analyse dynamique. Par exemple, le logiciel malveillant chiffrĂ© peut d'abord passer par un analyseur dynamique tel que PolyUnpack, oĂč les parties de code masquĂ© d'une instance de logiciel malveillant chiffrĂ© sont extraits en comparant l'exĂ©cution du programme malveillant avec son modĂšle de code statique. Une fois que les morceaux de code cachĂ© sont dĂ©couverts, un analyseur statique peut continuer l'analyse du logiciel malveillant[22].

Approche forensique

Les Ă©tapes de l'approche forensique dans l'analyse de logiciels malveillants.

Cette approche intĂšgre Ă  la fois l'analyse statique et les approches forensiques de la mĂ©moire et propose des amĂ©liorations, qui fournit de meilleurs rĂ©sultats. La raison en est la rĂ©sistance de certains Ă©chantillons de logiciels malveillants Ă  rĂ©vĂ©ler leur comportement prĂ©vu en raison du cryptage et de leur nature compacte. Par consĂ©quent, l'approche de l'analyse des logiciels malveillants statiques et les approches forensiques peuvent ĂȘtre combinĂ©s pour surmonter les problĂšmes de comportement et de chiffrement. L'outil Volatility est utilisĂ© dans cette mĂ©thode[23].

L'analyse forensique se fait en quatre Ă©tapes :

  1. Préparation d'un environnement virtuel
  2. Analyse statique sur un logiciel malveillant
  3. Génération d'un dump mémoire
  4. Analyse de la mémoire

Par la suite, les résultats sont comparés et vérifiés avec les résultats obtenus sur l'outil en ligne de VirusTotal, qui est un outil d'analyse de malwares en ligne.

Classification

Apprentissage automatique

Diverses approches d'apprentissage automatique ont été proposées, pour détecter et classer des échantillons inconnus dans des familles de logiciels malveillants connus ou pour les analyser, telles que[11] :

De nombreux chercheurs préfÚrent maintenant travailler sur des techniques dynamiques afin d'améliorer la précision et l'efficacité de la classification des logiciels malveillants[24].

Analyse phylogénétique

L'analyse phylogénétique est l'étude des similitudes et des différences dans la structure du programme pour trouver des relations au sein de groupes de logiciels, fournissant des informations sur les nouvelles variantes de logiciels malveillants non disponibles à partir de la détection de logiciels malveillants basés sur les signatures. Un exemple de solution utilisant cette analyse est la solution DECODE.

Les principales technologies de DECODE :

  • CrĂ©ation d'une empreinte digitale d'un spĂ©cimen de logiciel malveillant Ă  l'aide d'une analyse statique.
  • Un systĂšme de classification Ă©volutif et prĂ©cis pour regrouper des centaines de milliers d'Ă©chantillons de logiciels malveillants dans une taxonomie de logiciels malveillants.
  • Un systĂšme de classification Ă©volutif et prĂ©cis pour trouver le code partagĂ©, au niveau des sous-programmes individuels, sur des dizaines de milliers d'Ă©chantillons
  • Plusieurs algorithmes pour reconstruire des lignĂ©es d'Ă©chantillons de logiciels malveillants connexes[25]

Références

  1. Gandotra 2014, p. 56
  2. Gandotra 2014, p. 57
  3. Yakdan 2016, p. 158
  4. Damodaran 2017, p. 2
  5. Deka 2016, p. 3
  6. Ye 2017, p. 12
  7. Gandotra 2014, p. 57-58
  8. You 2010, p. 297
  9. You 2010, p. 297-298
  10. Moser 2007, p. 422
  11. Gandotra 2014, p. 58
  12. Sharif 2009, p. 94
  13. You 2010, p. 298
  14. You 2010, p. 299
  15. Moser 2007, p. 430
  16. Moser 2007, p. 429
  17. Egele 2008, p. 13
  18. Egele 2008, p. 14-15
  19. Egele 2008, p. 18
  20. Sun 2011, p. 912-913
  21. Sun 2011, p. 913
  22. Ye 2017, p. 14
  23. Rathnayaka 2017, p. 1146
  24. Gandotra 2014, p. 59-60
  25. Jilcott 2015, p. 1

Annexes

Bibliographie

  • (en) Ekta Gandotra, Divya Bansal et Sanjeev Sofat, « Malware Analysis and Classification: A Survey », Journal of Information Security, vol. 2014,‎ (ISSN 2153-1242, DOI 10.4236/jis.2014.52006, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (en) Manuel Egele, Theodoor Scholte, Engin Kirda et Christopher Kruegel, « A Survey on Automated Dynamic Malware-analysis Techniques and Tools », ACM Comput. Surv., vol. 44, no 2,‎ , p. 6:1–6:42 (ISSN 0360-0300, DOI 10.1145/2089125.2089126, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (en) A. Moser, C. Kruegel et E. Kirda, « Limits of Static Analysis for Malware Detection », Twenty-Third Annual Computer Security Applications Conference (ACSAC 2007),‎ , p. 421–430 (DOI 10.1109/acsac.2007.21, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (en) Anusha Damodaran, Fabio Di Troia, Corrado Aaron Visaggio et Thomas H. Austin, « A comparison of static, dynamic, and hybrid analysis for malware detection », Journal of Computer Virology and Hacking Techniques, vol. 13, no 1,‎ , p. 1–12 (ISSN 2263-8733, DOI 10.1007/s11416-015-0261-z, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (en) GrĂ©goire Jacob, HervĂ© Debar et Eric Filiol, « Behavioral detection of malware: from a survey towards an established taxonomy », Journal in Computer Virology, vol. 4, no 3,‎ , p. 251–266 (ISSN 1772-9890 et 1772-9904, DOI 10.1007/s11416-008-0086-0, lire en ligne, consultĂ© le )
  • (en) M. Sharif, A. Lanzi, J. Giffin et W. Lee, « Automatic Reverse Engineering of Malware Emulators », 2009 30th IEEE Symposium on Security and Privacy,‎ , p. 94–109 (DOI 10.1109/sp.2009.27, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (en) K. Yakdan, S. Dechand, E. Gerhards-Padilla et M. Smith, « Helping Johnny to Analyze Malware: A Usability-Optimized Decompiler and Malware Analysis User Study », 2016 IEEE Symposium on Security and Privacy (SP),‎ , p. 158–177 (DOI 10.1109/sp.2016.18, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (en) Yanfang Ye, Tao Li, Donald Adjeroh et S. Sitharama Iyengar, « A Survey on Malware Detection Using Data Mining Techniques », ACM Comput. Surv., vol. 50, no 3,‎ , p. 41:1–41:40 (ISSN 0360-0300, DOI 10.1145/3073559, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (en) M. K. Sun, M. J. Lin, M. Chang et C. S. Laih, « Malware Virtualization-Resistant Behavior Detection », 2011 IEEE 17th International Conference on Parallel and Distributed Systems,‎ , p. 912–917 (DOI 10.1109/icpads.2011.78, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (en) Rakesh Singh Kunwar et Priyanka Sharma, « Malware Analysis: Tools and Techniques », Proceedings of the Second International Conference on Information and Communication Technology for Competitive Strategies, ACM, iCTCS '16,‎ , p. 144:1–144:4 (ISBN 9781450339629, DOI 10.1145/2905055.2905361, lire en ligne, consultĂ© le )
  • (en) Xu Chen, J. Andersen, Z. M. Mao et M. Bailey, « Towards an understanding of anti-virtualization and anti-debugging behavior in modern malware », 2008 IEEE International Conference on Dependable Systems and Networks With FTCS and DCC (DSN),‎ , p. 177–186 (DOI 10.1109/dsn.2008.4630086, lire en ligne, consultĂ© le )
  • (en) Daniel A Quist et Lorie M Liebrock, « Reversing Compiled Executables for Malware Analysis via Visualization », Information Visualization, vol. 10, no 2,‎ , p. 117–126 (DOI 10.1057/ivs.2010.11, lire en ligne, consultĂ© le )
  • (en) Chan Lee Yee, Lee Ling Chuan, M. Ismail et N. Zainal, « A static and dynamic visual debugger for malware analysis », 2012 18th Asia-Pacific Conference on Communications (APCC),‎ , p. 765–769 (DOI 10.1109/apcc.2012.6388211, lire en ligne, consultĂ© le )
  • (en) S. Jilcott, « Scalable malware forensics using phylogenetic analysis », 2015 IEEE International Symposium on Technologies for Homeland Security (HST),‎ , p. 1–6 (DOI 10.1109/ths.2015.7225311, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (en) I. You et K. Yim, « Malware Obfuscation Techniques: A Brief Survey », 2010 International Conference on Broadband, Wireless Computing, Communication and Applications,‎ , p. 297–300 (DOI 10.1109/bwcca.2010.85, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (en) C. Rathnayaka et A. Jamdagni, « An Efficient Approach for Advanced Malware Analysis Using Memory Forensic Technique », 2017 IEEE Trustcom/BigDataSE/ICESS,‎ , p. 1145–1150 (DOI 10.1109/trustcom/bigdatase/icess.2017.365, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (en) D. Deka, N. Sarma et N. J. Panicker, « Malware detection vectors and analysis techniques: A brief survey », 2016 International Conference on Accessibility to Digital World (ICADW),‎ , p. 81–85 (DOI 10.1109/icadw.2016.7942517, lire en ligne, consultĂ© le ) Document utilisĂ© pour la rĂ©daction de l’article
  • (en) Ioan Cristian Iacob, « Reverse Engineering Malicious Applications », Journal of Mobile, Embedded and Distributed Systems, vol. VII, no. 2, 2015,‎ , p. 65-86 (lire en ligne)
  • (en) Min Gyung Kang, Pongsin Poosankam et Heng Yin, « Renovo: A Hidden Code Extractor for Packed Executables », Proceedings of the 2007 ACM Workshop on Recurring Malcode, ACM, wORM '07,‎ , p. 46–53 (ISBN 9781595938862, DOI 10.1145/1314389.1314399, lire en ligne, consultĂ© le )
  • (en) Thomas Rupprecht, Xi Chen, David H. White et Jan Tobias MĂŒhlberg, « POSTER: Identifying Dynamic Data Structures in Malware », Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, ACM, cCS '16,‎ , p. 1772–1774 (ISBN 9781450341394, DOI 10.1145/2976749.2989041, lire en ligne, consultĂ© le )
  • (en) W. M. Khoo et P. Lio, « Unity in Diversity: Phylogenetic-inspired Techniques for Reverse Engineering and Detection of Malware Families », 2011 First SysSec Workshop,‎ , p. 3–10 (DOI 10.1109/syssec.2011.24, lire en ligne, consultĂ© le )
  • (en) Chih-Hung Lin, Hsing-Kuo Pao et Jian-Wei Liao, « Efficient dynamic malware analysis using virtual time control mechanics », Computers & Security, vol. 73,‎ , p. 359–373 (DOI 10.1016/j.cose.2017.11.010, lire en ligne, consultĂ© le )
  • (en) Shabnam Aboughadareh, Christoph Csallner et Mehdi Azarmi, « Mixed-Mode Malware and Its Analysis », Proceedings of the 4th Program Protection and Reverse Engineering Workshop, ACM, pPREW-4,‎ , p. 1:1–1:12 (ISBN 9781605586373, DOI 10.1145/2689702.2689703, lire en ligne, consultĂ© le )
  • (en) F. Daryabar, A. Dehghantanha et N. I. Udzir, « Investigation of bypassing malware defences and malware detections », 2011 7th International Conference on Information Assurance and Security (IAS),‎ , p. 173–178 (DOI 10.1109/isias.2011.6122815, lire en ligne, consultĂ© le )
  • (en) Zachary D Sisco, Patrick P Dudenhofer et Adam R Bryant, « Modeling information flow for an autonomous agent to support reverse engineering work », The Journal of Defense Modeling and Simulation: Applications, Methodology, Technology, vol. 14, no 3,‎ , p. 245–256 (DOI 10.1177/1548512916670784, lire en ligne, consultĂ© le )
  • (en) Cory Q. Nguyen et James E. Goldman, « Malware Analysis Reverse Engineering (MARE) Methodology & Malware Defense (M.D.) Timeline », 2010 Information Security Curriculum Development Conference, ACM, infoSecCD '10,‎ , p. 8–14 (ISBN 9781450302029, DOI 10.1145/1940941.1940944, lire en ligne, consultĂ© le )
  • (en) M. Alazab, M. A. Kadiri, S. Venkatraman et A. Al-Nemrat, « Malicious Code Detection Using Penalized Splines on OPcode Frequency », 2012 Third Cybercrime and Trustworthy Computing Workshop,‎ , p. 38–47 (DOI 10.1109/ctc.2012.15, lire en ligne, consultĂ© le )
  • (en) M. H. Alaeiyan et S. Parsa, « Automatic loop detection in the sequence of system calls », 2015 2nd International Conference on Knowledge-Based Engineering and Innovation (KBEI),‎ , p. 720–723 (DOI 10.1109/kbei.2015.7436133, lire en ligne, consultĂ© le )
  • (en) R. A. Nolan et P. P. Chen, « MCARTA: A Malicious Code Automated Run-Time Analysis framework », 2012 IEEE Conference on Technologies for Homeland Security (HST),‎ , p. 13–17 (DOI 10.1109/ths.2012.6459819, lire en ligne, consultĂ© le )
  • (en) M. Bombardieri, S. CastanĂČ, F. Curcio et A. Furfaro, « Honeypot-Powered Malware Reverse Engineering », 2016 IEEE International Conference on Cloud Engineering Workshop (IC2EW),‎ , p. 65–69 (DOI 10.1109/ic2ew.2016.16, lire en ligne, consultĂ© le )
  • (en) M. Shudrak et V. Zolotarev, « The New Technique of Decompilation and Its Application in Information Security », 2012 Sixth UKSim/AMSS European Symposium on Computer Modeling and Simulation,‎ , p. 115–120 (DOI 10.1109/ems.2012.20, lire en ligne, consultĂ© le )
  • (en) Guillaume Bonfante, Jose Fernandez, Jean-Yves Marion et Benjamin Rouxel, « CoDisasm: Medium Scale Concatic Disassembly of Self-Modifying Binaries with Overlapping Instructions », Proceedings of the 22Nd ACM SIGSAC Conference on Computer and Communications Security, ACM, cCS '15,‎ , p. 745–756 (ISBN 9781450338325, DOI 10.1145/2810103.2813627, lire en ligne, consultĂ© le )
  • (en) Min Gyung Kang, Heng Yin, Steve Hanna et Stephen McCamant, « Emulating Emulation-resistant Malware », Proceedings of the 1st ACM Workshop on Virtual Machine Security, ACM, vMSec '09,‎ , p. 11–22 (ISBN 9781605587806, DOI 10.1145/1655148.1655151, lire en ligne, consultĂ© le )
  • (en) Blake Anderson, Curtis Storlie, Micah Yates et Aaron McPhall, « Automating Reverse Engineering with Machine Learning Techniques », Proceedings of the 2014 Workshop on Artificial Intelligent and Security Workshop, ACM, aISec '14,‎ , p. 103–112 (ISBN 9781450331531, DOI 10.1145/2666652.2666665, lire en ligne, consultĂ© le )
  • (en) S. Burji, K. J. Liszka et C. C. Chan, « Malware analysis using reverse engineering and data mining tools », 2010 International Conference on System Science and Engineering,‎ , p. 619–624 (DOI 10.1109/icsse.2010.5551719, lire en ligne, consultĂ© le )
  • (en) GĂ©rard Wagener, Radu State et Alexandre Dulaunoy, « Malware behaviour analysis », Journal in Computer Virology, vol. 4, no 4,‎ , p. 279–287 (ISSN 1772-9890 et 1772-9904, DOI 10.1007/s11416-007-0074-9, lire en ligne, consultĂ© le )
  • (en) Guillaume Bonfante, Jean-Yves Marion, Fabrice Sabatier et AurĂ©lien Thierry, « Code synchronization by morphological analysis », 7th International Conference on Malicious and Unwanted Software (Malware 2012),‎ , p. 1-9 (lire en ligne)
  • (en) Murray Brand, Craig Valli et Andrew Woodward, « Malware Forensics: Discovery of the Intent of Deception », Journal of Digital Forensics, Security and Law, Vol. 5(4),‎ , p. 1-12 (ISSN 1558-7223, lire en ligne)
  • (en) X. Li, P. K. K. Loh et F. Tan, « Mechanisms of Polymorphic and Metamorphic Viruses », 2011 European Intelligence and Security Informatics Conference,‎ , p. 149–154 (DOI 10.1109/eisic.2011.77, lire en ligne, consultĂ© le )
  • (en) Matthieu Kaczmarek, « Malware Instrumentation Application to Regin Analysis », The Journal on Cybercrime & Digital Investigations, vol. 1, no 1,‎ (ISSN 2494-2715, DOI 10.18464/cybin.v1i1.2, lire en ligne, consultĂ© le )
  • (en) A. Jadhav, D. Vidyarthi et Hemavathy M, « Evolution of evasive malwares: A survey », 2016 International Conference on Computational Techniques in Information and Communication Technologies (ICCTICT),‎ , p. 641–646 (DOI 10.1109/icctict.2016.7514657, lire en ligne, consultĂ© le )
  • (en) Y. Gao, Z. Lu et Y. Luo, « Survey on malware anti-analysis », Fifth International Conference on Intelligent Control and Information Processing,‎ , p. 270–275 (DOI 10.1109/icicip.2014.7010353, lire en ligne, consultĂ© le )

Articles connexes

Liens externes

Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplĂ©mentaires peuvent s’appliquer aux fichiers multimĂ©dias.