CH720149A2 - Analyse itérative de fichiers pour la détection des logiciels malveillants - Google Patents

Abstract

L'invention a pour objets un système (100) et une méthode d'analyse anti-malware comprenant des techniques itératives (106-110) qui combinent l'analyse statique et dynamique de programmes ou de fichiers non fiables. Ces techniques sont utilisées pour identifier les fichiers malveillants en collectant de manière itérative de nouvelles données pour l'analyse statique par l'analyse dynamique du temps d'exécution.

Description

Domaine technique

[0001] L'invention concerne la sécurité informatique, notamment l'analyse statique et dynamique et la détection des logiciels malveillants.

Contexte

[0002] En sécurité informatique, les stratégies de détection des logiciels malveillants peuvent être classées en fonction du moment où elles interviennent dans l'exécution du logiciel malveillant. Il s'agit des stratégies de pré-exécution, d'exécution et de post-exécution. Bien que l'analyse avant exécution („PE“) soit souvent utile, elle a des difficultés avec un large éventail d'échantillons de logiciels malveillants chiffrés ou emballés.

[0003] L'un des problèmes est le manque de résolution en termes d'utilisation de l'analyse PE pour de tels échantillons chiffrés ou emballés. Les méthodes courantes utilisent des méthodes d'exécution comportementales et la collecte d'événements. L'analyse PE n'est pas utilisée pleinement dans de tels cas et le taux de détection n'en est pas amélioré.

[0004] Le terme „analyse statique“ fait référence aux techniques d'analyse de programmes basées sur la structure des logiciels. Les méthodes classiques d'analyse statique analysent et désassemblent les fichiers exécutables portables et créent des arbres d'attributs, y compris les certificats, les en-têtes, les bibliothèques, les importations, le nom, la taille et d'autres attributs. Ces arbres sont utilisés pour classer les fichiers exécutables comme malveillants. Mais les analyseurs de fichiers statiques classiques ont des difficultés lorsque les logiciels malveillants sont chiffrés. En raison de ce cryptage, le code ne peut pas être analysé efficacement avec l'analyse statique.

[0005] Lorsque l'analyse statique n'est pas efficace, l'analyse dynamique peut être utilisée comme alternative. L'objectif de l'analyse dynamique est de tester un fichier non fiable en l'exécutant dans un environnement sûr, de sorte que la véritable nature du fichier soit révélée au moment de l'exécution. L'émulation, le sandboxing et d'autres méthodes similaires sont des exemples d'outils traditionnels d'analyse dynamique du comportement.

[0006] Un émulateur peut analyser en profondeur une application, mais il a certaines limites. Les émulateurs ne peuvent pas émuler un système original avec une précision de 100 %. Certains logiciels malveillants peuvent tester l'environnement d'exécution et arrêter l'exécution si un émulateur est détecté. De plus, les émulateurs utilisent des ressources système et prennent beaucoup de temps pour l'analyse. Ceci est bien connu et certains fichiers malveillants contiennent des boucles factices pour prolonger le temps d'exécution et d'émulation. Ces boucles font que l'émulateur quitte l'analyse avant que le code malveillant ne s'exécute.

[0007] Un bac à sable est un environnement isolé et sécurisé qui est utilisé pour tester et analyser l'exécution de fichiers. Comme un émulateur, un bac à sable ne correspond pas exactement au système informatique cible et l'exécution de fichiers potentiellement malveillants dans un bac à sable peut différer de l'exécution dans l'environnement cible. Le sandboxing est également un processus gourmand en ressources qui ne peut être réalisé efficacement dans un environnement en temps réel. Néanmoins, le sandboxing peut être utilisé en complément de méthodes d'analyse statique plus légères.

[0008] Un analyseur de comportement du système est une méthode permettant de contrôler l'exécution du fichier sur un ordinateur cible. Il trace les appels d'API, les threads, les opérations de lecture et d'écriture, et toutes les autres opérations qui permettent de détecter les logiciels malveillants. Le problème est que ces méthodes ne sont pas légères. Elles chargent le système et dégradent les performances.

Résumé

[0009] Pour surmonter ces problèmes rencontrés dans l'art antérieur, l'invention prévoit un procédé selon la revendication 1, un système selon la revendication 9 et un support de stockage selon la revendication 14. D'autres perfectionnements sont décrits dans les revendications dépendantes. Selon un aspect de l'invention, l'analyse statique et l'analyse dynamique peuvent être combinées pour analyser des fichiers potentiellement malveillants, y compris des fichiers chiffrés. Par exemple, lors de l'analyse statique, l'entropie du corps du fichier peut être estimée afin de conclure de manière préliminaire que le fichier est suspect, puisque de nombreux blocs de données sont chiffrés. Après avoir obtenu un verdict préliminaire, des méthodes dynamiques sont utilisées pour augmenter la précision du verdict. Les méthodes dynamiques révèlent la nature des fichiers non fiables en révélant leur comportement d'exécution. Par exemple, si un fichier écrase son propre en-tête lorsqu'il commence à s'exécuter ou possède d'autres attributs qui dissimulent sa nature, ce comportement observé contribue à la conclusion que le fichier est malveillant. La classification peut être basée sur des technologies d'apprentissage automatique.

[0010] Divers intercepteurs au niveau des systèmes sont utilisés avec des points de flux de contrôle spéciaux, tels que la création de threads/processus, le mappage de fichiers, etc., qui permettent de réestimer le verdict pour une application. Le verdict réestimé, donné par un modèle d'analyse PE formé à l'apprentissage automatique, utilise les données extraites de la mémoire de l'application, et non du fichier sur le disque. Dans ce contexte, la mémoire de l'application comprend les nouvelles régions de code où s'exécute le code décrypté. Plusieurs itérations sont utilisées pour obtenir des résultats de plus en plus précis. Une méthode utilise la synergie de l'analyse statique et dynamique pour obtenir des verdicts plus précis que ne le permettent les méthodes conventionnelles.

[0011] La méthode utilise un service d'analyseur PE, un pilote, un système de fichiers et des requêtes au système de fichiers. Le pilote communique avec le service en mode utilisateur, qui invoque une évaluation du modèle PE et obtient un verdict actualisé de l'analyseur PE. Le pilote peut utiliser le crochet du mode utilisateur pour définir le point de contrôle dans le flux de code pour réestimer le modèle.

[0012] Les nouvelles régions de code avec du code non emballé ou décrypté sont détectées à l'aide d'analyseurs de pile et de crochets en mode utilisateur qui fonctionnent avec l'API de la mémoire virtuelle du processus. Ces nouvelles régions de code sont ajoutées à l'ensemble de données du modèle pour entraîner le modèle ou calculer le nouveau verdict.

[0013] Par ailleurs, les nouvelles régions de code sont rassemblées dans des segments de données non initialisés de Portable Exécutable. Ces segments de données non initialisés, également appelés segments „BSS“, servent d'espace de stockage pour des variables non initialisées qui ne nécessitent pas d'espace disque réel.

[0014] La même combinaison de crochets en mode pilote et en mode utilisateur est utilisée pour entraîner le modèle d'analyse PE avec l'ensemble des échantillons de logiciels malveillants emballés ou chiffrés. Les verdicts actualisés de l'analyseur PE sont utilisés par le produit de sécurité des points finaux pour améliorer la détection des logiciels malveillants.

[0015] Une analyse anti-malware du fichier peut être effectuée lors de l'exécution d'un fichier exécutable sur un système informatique cible. L'analyse statique du fichier est effectuée avec un arbre d'attributs de fichier par lequel les fichiers sont classés comme malveillants avec une précision spécifiée. L'analyse dynamique du fichier est effectuée de manière itérative si l'analyse statique ne permet pas de classer le fichier avec la précision spécifiée. L'analyse dynamique comprend l'interception de l'opération de déchiffrement des blocs de données pendant l'exécution du code du fichier et la mise à jour de l'arbre des attributs du fichier en tenant compte des blocs de données chiffrés. Ensuite, l'analyse statique du fichier est effectuée à nouveau sur la base de l'arbre des attributs du fichier mis à jour. Les étapes d'interception et de mise à jour du fichier sont répétées jusqu'à ce que le fichier soit classé avec la précision spécifiée.

[0016] Les blocs de données peuvent être décryptés dans la mémoire existante allouée à une application, dans un nouveau tampon dans la mémoire allouée ou dans un tampon existant de l'application. La mémoire tampon est une zone de stockage temporaire, généralement un bloc de mémoire, dans laquelle des éléments sont placés en attendant d'être transférés ou modifiés depuis un dispositif d'entrée ou vers un dispositif de sortie, ou depuis d'autres blocs de mémoire en vue de leur traitement.

[0017] Les étapes de décryptage des blocs de données interceptés et de mise à jour de l'arbre des attributs de fichiers peuvent être répétées plus de trois fois, plus de cinq fois ou plus de dix fois.

[0018] L'analyse d'un fichier peut dépendre d'un second fichier non fiable qui a été modifié à partir de ce fichier après son exécution. Le second fichier non fiable peut être le résultat de l'exécution du premier fichier, lorsque les en-têtes, les blocs de données ou le corps du fichier du premier fichier sont modifiés ou qu'un nouveau fichier est créé.

[0019] L'exécution du dossier peut être gelée après l'analyse de données supplémentaires du dossier.

[0020] Une zone donnée d'un tampon peut être rendue exécutable, l'exécution étant commutée sur la zone donnée.

Résumé des figures

[0021] La figure 1 montre une vue d'ensemble d'un système permettant de mettre en oeuvre l'analyse PE.

[0022] La figure 2 montre les étapes de l'analyse statique-dynamique itérative d'un objet inconnu.

[0023] La figure 3 montre les étapes permettant d'effectuer une analyse statique-dynamique itérative d'un objet inconnu dans le contexte de l'apprentissage automatique.

[0024] La figure 4 montre les détails d'un exemple d'analyse statique-dynamique itérative effectuée dans un environnement d'exécution.

Description détaillée

[0025] La mise en oeuvre de l'analyse itérative des logiciels malveillants utilise des techniques statiques et dynamiques pour surmonter les obstacles à la détection. Ces obstacles sont intégrés aux logiciels malveillants par leurs créateurs, qui connaissent bien les méthodes de détection utilisées par les systèmes anti-malware.

[0026] L'analyse itérative est conçue pour utiliser des techniques statiques et dynamiques de manière sélective afin d'améliorer les taux de détection et de surmonter ainsi les propriétés anti-détection que l'on trouve dans les logiciels malveillants sophistiqués. Par exemple, lorsque le code malveillant principal d'un fichier non fiable est exécuté, il peut inclure des moyens d'éviter la détection. Les méthodes dynamiques telles que l'émulation et le sandboxing peuvent être contournées si le malware peut détecter un environnement d'exécution virtualisé qui ne correspond pas à son environnement cible. Une autre tactique d'évasion de la détection utilisée par les logiciels malveillants est l'obscurcissement. L'obfuscation prend du code et le rend illisible par des moyens conventionnels. Elle retarde également la détection et rend le code moins sensible à l'ingénierie inverse. L'empaquetage est un type d'obfuscation utilisé par les logiciels malveillants qui utilisent un empaqueteur. Un packer est un outil qui modifie le formatage du code en compressant ou en cryptant les données.

[0027] Les fichiers cryptés ou emballés requièrent des protocoles d'analyse des logiciels malveillants différents de ceux connus de l'art antérieur. L'exécution d'un logiciel malveillant crypté commence par le chargement et l'exécution d'un fichier malveillant présumé. Dans le cas typique, la nature du fichier ne peut être déterminée avec suffisamment de précision car le corps du fichier est crypté ou emballé. Pour pallier ce problème, les blocs de données sont décryptés dans un nouveau tampon de la mémoire allouée. Ou bien les blocs de données peuvent être décryptés dans un tampon existant, ce qui rend la zone donnée exécutable et fait basculer l'exécution vers la zone donnée. Ce cycle peut avoir de nombreuses itérations avant que le code malveillant ne commence à s'exécuter. Le déchiffrement se déroule donc par étapes, les blocs de données étant lus à partir des blocs de données chiffrés et écrits dans la mémoire existante de l'application ou dans un nouveau tampon.

[0028] Par ailleurs, des segments de données non initialisés (BSS) sont utilisés pour le décryptage. L'empaquetage vise souvent les fichiers exécutables. Le processus d'empaquetage peut générer un nouvel en-tête et transformer le fichier original. Le fichier original transformé est copié dans le nouveau fichier. Un stub est ajouté au nouveau fichier. Lorsque le fichier est un exécutable, le stub inverse la transformation pendant l'exécution.

[0029] Les fichiers de programme de Microsoft Windows utilisent le format Portable Exécutable. Ce format a été introduit pour la première fois dans Windows NT 3.1 et des extensions ont été réalisées pour des formats binaires supplémentaires, notamment .NET et le support 64 bits. Il s'agit du format binaire standard pour les fichiers EXE et DLL dans le système d'exploitation Windows. Linux Executable and Linkable Format („ELF“) est un format similaire pour les fichiers exécutables dans les environnements Linux. Dans les descriptions suivantes, le formatage Windows sera utilisé à des fins d'illustration, mais les techniques décrites peuvent être utilisées avec tout format de fichier dont la structure est similaire.

[0030] L'évidement de processus est une méthode d'exécution de code dans l'espace d'adressage d'un processus actif. Cette opération est généralement réalisée en créant un processus dans un état suspendu, puis en démappant ou en „vidant“ sa mémoire. Cette opération peut avoir lieu dans des segments de données non initialisés (BSS). La détection peut être réalisée en activant le bit d'exécution de manière à pouvoir accéder au répertoire qui le contient.

[0031] L'écrasement de l'en-tête d'un exécutable portable est une technique utilisée par les logiciels malveillants au moment de l'exécution pour éviter la détection. Par exemple, le fichier original comprend un en-tête, une section de code et d'autres sections, telles que .data ou .rsrc. Au cours du processus d'empaquetage, un fichier exécutable entièrement nouveau peut être généré avec un nouvel en-tête. Le fichier original peut être transformé par compression ou cryptage ou une combinaison des deux. Pendant le chargement, le fichier emballé démarre et est mappé en mémoire virtuelle. Le stub de déballage est appelé pour inverser les opérations de compression ou de cryptage si nécessaire. Le fichier original est ensuite restauré en mémoire, avec un nouvel en-tête. Lorsqu'un en-tête de fichier est modifié au moment de l'exécution, cela prouve que le fichier en question a été emballé.

[0032] Les techniques d'analyse statique et dynamique affectent différemment les performances globales du système. Par exemple, un analyseur PE statique peut classer le fichier exécutable portable (fichier PE) lorsqu'il dispose des données déchiffrées du fichier PE chargé en mémoire plus rapidement et plus efficacement que l'analyse dynamique du même fichier tout en atteignant un taux de détection élevé.

[0033] La figure 1 montre un aperçu d'un système 100 pour la mise en oeuvre de l'analyse PE.

[0034] Le système anti-malware 100 comprend un service d'hébergement d'analyseur PE 102 pour analyser une application malveillante potentielle 104. Le service d'analyse PE 102 génère une analyse à l'accès 106 en tant qu'itération 0 et continue avec les itérations 1 (108) à N (110). Ces éléments et le hooker UM 112 en mode utilisateur sont situés dans le mode utilisateur 114.

[0035] Le mode noyau 116 comprend le pilote de noyau 122 qui exploite les commandes d'entrée et de sortie E/S du crochet UM 112 et la liaison 120 entre les résultats 122 du crochet UM 112 et le service d'analyse PE 102. La liaison 120 transmet les résultats 124 vers le haut à l'analyseur PE 102. Les demandes 126 descendantes du service d'analyse PE 102 comprennent des demandes de régions de processus de la mémoire pour l'analyse PE. Le mode utilisateur se distingue du mode noyau en ce que les applications s'exécutent en mode utilisateur, tandis que les composants centraux du système d'exploitation s'exécutent en mode noyau.

[0036] La figure 2 illustre le procédé 200 permettant d'effectuer une analyse statique-dynamique itérative d'un dossier inconnu.

[0037] Le processus commence par l'interception du début de l'exécution du fichier à l'étape 202, puis la récupération des attributs du fichier à l'étape 204. Sur la base de ces attributs, une analyse statique est effectuée à l'étape 206. Les résultats préliminaires de l'analyse statique génèrent un classement de sécurité 208, une classification des fichiers par attributs à l'aide d'un algorithme d'apprentissage automatique sur une collection de fichiers connus 210 et permettent de faire correspondre 212 des attributs de fichiers avec des logiciels malveillants connus à partir de listes noires de certificats, de bibliothèques, de structures de code et de hashsums suspects.

[0038] Le résultat du classement 208, de la classification 210 et de la correspondance 212 est le verdict 214 de l'analyse statique. Ce verdict peut ou non être suffisamment précis pour classer le fichier en question selon un niveau de confiance prédéterminé (ou une précision spécifiée). Le niveau de confiance peut dépendre d'une politique de sécurité et de la classe du fichier. Par exemple, un niveau de sécurité élevé devrait correspondre à un niveau de confiance ne dépassant pas un pour cent des erreurs de type I, et un niveau de sécurité modéré devrait correspondre à un niveau de confiance ne dépassant pas un pour cent des erreurs de type II. S'il est déterminé à l'étape 216 que le verdict permet une classification comme logiciel malveillant avec une précision spécifique, alors l'exécution du fichier est terminée à l'étape 218 et la détection du fichier malveillant est enregistrée à l'étape 220. Si le verdict 214 ne permet pas la classification, une détermination est faite à l'étape 222 pour savoir si une vérification supplémentaire est nécessaire conformément au verdict 214. Si ce n'est pas le cas, l'analyse du fichier est arrêtée et le fichier est libéré pour exécution à l'étape 224.

[0039] Une vérification supplémentaire est nécessaire lorsqu'un logiciel malveillant ne peut pas être identifié avec une précision spécifique au moyen d'un classement de sécurité 208, d'une classification de fichier 210 ou d'une correspondance 212 des attributs de fichier avec des logiciels malveillants connus provenant de listes noires de certificats, de bibliothèques, de structures de code et de hashsums suspects. Lorsqu'une vérification supplémentaire est nécessaire pour classer le fichier, par exemple lorsque le niveau de confiance est inférieur au niveau prédéfini, ou lorsque d'autres moteurs de détection de logiciels malveillants fournissent un verdict différent des classifications, le processus itératif commence à l'étape 226 avec l'exécution d'une partie du fichier. Des opérations d'accrochage sont utilisées à l'étape 228 pour identifier des attributs supplémentaires du fichier. Les opérations d'accrochage modifient ou augmentent l'application en cours d'exécution en interceptant les appels de fonction ou les messages ou événements transmis entre les composants logiciels. Le code utilisé à cette fin est généralement appelé „hook“.

[0040] L'exécution du fichier est arrêtée à l'étape 230 et les attributs du fichier PE précédemment collectés à partir de l'analyse statique générée à l'étape 206 sont mis à jour à l'étape 232. Pour l'analyse itérative, l'exécution est arrêtée afin que l'exécution d'un seul fichier puisse être testée jusqu'à N fois sans avoir à exécuter complètement tout le code associé au fichier en question.

[0041] La figure 3 illustre le procédé 300 permettant d'effectuer une analyse statique-dynamique itérative d'un fichier inconnu dans le contexte de l'apprentissage automatique.

[0042] Le processus commence à l'étape 302 lorsqu'une nouvelle analyse de fichier PE est lancée. Les attributs du fichier PE sont reçus à l'étape 304 et évalués à l'étape 306 pour déterminer si l'ensemble d'attributs est suffisant, par exemple lorsque l'ensemble d'attributs permet de classer le fichier avec un niveau de confiance supérieur à celui prédéfini ou est constitué d'un ensemble d'attributs de valeur minimale, pour former le système à identifier le fichier en question. Sinon, à l'étape 308, le fichier PE est exécuté dans un environnement informatique sécurisé. Des exemples d'environnements informatiques sécurisés comprennent un émulateur, un bac à sable, une machine de test dédiée, une machine déconnectée de tout réseau, ou d'autres environnements où la capacité des logiciels malveillants à se propager est limitée. Des opérations de crochetage sont effectuées pour identifier des attributs de fichier supplémentaires à l'étape 310. Ces attributs supplémentaires sont utilisés à l'étape 312 pour mettre à jour l'ensemble original d'attributs. Le processus itératif se poursuit jusqu'à ce que l'évaluation de l'étape 306 produise un résultat positif. Lorsqu'un résultat positif est obtenu, un analyseur de fichiers à apprentissage automatique est entraîné sur les fichiers collectés à l'étape 314, y compris les nouveaux attributs collectés basés sur les fichiers PE. Les fichiers et attributs collectés sont utilisés pour mettre à jour un ensemble de règles de détection à l'étape 316.

[0043] La figure 4 montre les détails d'un exemple d'analyse statique-dynamique itérative 400 effectuée dans un environnement d'exécution 402. Cet environnement comprend des objets système fonctionnant en mode utilisateur 404 et en mode noyau 406 : l'analyseur PE 408 et l'application 410 fonctionnant en mode utilisateur 404, et le pilote de sécurité du noyau 434. Le mode utilisateur se distingue du mode noyau en ce que les applications s'exécutent en mode utilisateur, tandis que les composants centraux du système d'exploitation s'exécutent en mode noyau. L'application 410 s'exécute à partir du fichier PE 412, qui comprend des blocs de données chiffrées 414. Au fur et à mesure de son exécution, l'application 410 révèle le code 416, les bibliothèques 418 et les données 420. Le décryptage des blocs s'effectue de manière itérative dans le tampon 0 (422), qui exécute les blocs décryptés 426, et continue en montant vers le tampon N (428) et les blocs décryptés 430. En variante, le décryptage de bloc peut avoir lieu dans le bloc de données 420.

[0044] Le hooker 432 fonctionne en mode utilisateur 404 sous le contrôle du pilote de sécurité du noyau 434. Comme dans d'autres exemples, le hooker 432 modifie ou augmente l'application en cours d'exécution en interceptant les appels de fonction ou les messages ou événements transmis entre les composants logiciels et les transmet au pilote de sécurité du noyau 434 qui envoie une commande, un message ou un événement à l'analyseur PE 408.

[0045] Les attributs de fichier PE initiaux 436 sont collectés par l'analyseur PE 408 avec les attributs de fichier PE collectés par première itération 438 à travers les étapes des attributs de fichier PE collectés par N itérations 440. L'analyseur de malware d'attributs de fichiers 442, dirigé par le contrôleur d'itération 444, évalue les attributs de fichiers PE initiaux 436 et les attributs de fichiers collectés par itération 438, 440.

[0046] Certains logiciels malveillants ne créent pas de tampon pour décrypter les blocs. Dans ce cas, les données peuvent être décryptées dans les pages de mémoire existantes. Par exemple, le bloc de code 416 et le bloc de données 420 sont utilisés pour le décryptage.

[0047] Bien que certains fichiers décompressés restaurent le fichier original en mémoire, les logiciels malveillants peuvent également restaurer le fichier original à une adresse mémoire différente. Dans ce cas, l'activité liée au second fichier est analysée, en se concentrant sur la modification du premier fichier à l'étape initiale, immédiatement après le démarrage.

[0048] Une autre technique consiste à geler la poursuite de l'exécution d'un fichier après l'obtention de données supplémentaires, comme des blocs de données, des en-têtes, des blocs de code ou des données écrites dans le tampon de l'application. Par exemple, tous les threads du processus peuvent être gelés.

[0049] La collecte itérative des attributs des fichiers PE à l'aide de méthodes dynamiques se poursuit jusqu'à la création d'un arbre d'attributs de fichiers suffisant pour tirer une conclusion sur le fichier en question.

[0050] Les techniques itératives décrites ci-dessus sont applicables aux environnements informatiques où les machines ou les réseaux des utilisateurs sont susceptibles de rencontrer des logiciels malveillants ayant la capacité d'échapper à la détection, en particulier ayant la capacité d'échapper à la détection d'une manière qui rend l'analyse statique peu fiable ou incomplète.

Claims (14)

1. Procédé mis en oeuvre par ordinateur pour un balayage anti-malware itératif, le procédé étant exécuté sur un processeur, le procédé comprenant. a. effectuer une analyse anti-malware d'un fichier lors de l'exécution du fichier sur un système informatique cible ; b. effectuer une analyse statique du fichier, dans laquelle l'analyse statique fonctionne avec un arbre d'attributs de fichiers par lequel les fichiers sont classés comme malveillants avec une précision spécifiée ; c. effectuer une itération de l'analyse dynamique du fichier si l'analyse statique ne permet pas de classer le fichier avec la précision spécifiée ; d. intercepter une opération de décryptage de blocs de données pendant l'exécution du code de fichier, e. mise à jour de l'arbre des attributs du fichier en tenant compte des blocs de données déchiffrés ; f. effectuer une analyse statique du fichier sur la base de l'arbre mis à jour des attributs du fichier, et g. en répétant les étapes d. et e. jusqu'à ce que le dossier soit classé avec la précision spécifiée.

2. Procédé de la revendication 1 comprenant en outre la répétition des étapes d'interception et de mise à jour 3 fois ou plus.

3. Procédé de la revendication 1 ou 2, comprenant en outre l'étape consistant à décrypter des blocs de données dans une mémoire nouvelle ou existante.

4. Procédé de la revendication 1, comprenant en outre l'étape consistant à analyser le fichier et un second fichier non fiable, dans lequel le second fichier non fiable a été modifié à partir du fichier après exécution.

5. Le procédé de la revendication 3, comprenant en outre l'étape consistant à geler l'exécution du fichier suite à l'analyse de données de fichier supplémentaires du second fichier non fiable.

6. Procédé de la revendication 4 ou 5, comprenant en outre la répétition des étapes d'interception et de mise à jour au moins 3 fois.

7. Procédé de l'une quelconque des revendications précédentes, comprenant en outre l'étape consistant à décrypter des blocs de données dans une mémoire nouvelle ou existante.

8. Le procédé de l'une quelconque des revendications précédentes, comprenant en outre le fait de rendre exécutable une zone donnée et de commuter l'exécution sur la zone donnée.

9. Système pour la détection dynamique et statique itérative d'un fichier potentiellement malveillant par un anti-malware, le système comprenant a. un analyseur d'exécutable ; b. une application d'accrochage en mode utilisateur configurée pour intercepter l'opération de décryptage de blocs de données pendant l'exécution du code de fichier ; c. une structure de données pour stocker au moins un attribut de fichier collecté par l'analyse statique du fichier potentiellement malveillant ; et d. une structure de données pour stocker au moins un attribut de fichier collecté à partir de l'analyse dynamique du fichier potentiellement malveillant.

10. Le système de la revendication 9 comprenant en outre un nouveau tampon de mémoire allouée pour décrypter les blocs de données du fichier potentiellement malveillant.

11. Le système de la revendication 9, comprenant en outre un tampon existant pour décrypter les blocs de données du fichier potentiellement malveillant.

12. Le système de la revendication 9, comprenant en outre une mémoire existante pour le décryptage des blocs de données du fichier potentiellement malveillant.

13. Système de l'une quelconque des revendications 9 à 12 pour la détection d'un second fichier non fiable, dans lequel le second fichier non fiable a été modifié à partir du fichier potentiellement malveillant après exécution.

14. Support de stockage lisible par ordinateur stockant une pluralité de codes informatiques pour mettre en oeuvre les étapes du procédé de l'une quelconque des revendications 1 à 8.