Techniques anti-retour (Partie 2)

Dans la première partie, nous avons discuté de certaines techniques courantes utilisées par les auteurs de logiciels malveillants pour protéger leurs applications contre l'ingénierie inverse. Dans cette deuxième partie, nous examinerons d'autres méthodes et techniques utilisées pour détecter et empêcher la rétro-ingénierie.

Détection du débogueur :

Technique de synchronisation d'exécution du code :

Lorsque vous utilisez un débogueur pour analyser un exécutable, nous utilisons parfois une exécution en une seule étape pour parcourir certaines instructions d'assemblage, le temps d'exécution sera beaucoup plus long que l'exécution normale, prenons ce code comme exemple :

Au début du code, nous avons un appel à la fonction « GetTickCount » qui renvoie le nombre de millisecondes écoulées depuis le démarrage du système. Le code jusqu'à l'exécution de la fonction « ShellExecuteW » prendra 30 à 47 millisecondes comme je l'ai mesuré sur ma machine. Après cela, nous appelons à nouveau la fonction " GetTickCount " pour obtenir l'heure, puis obtenir la différence entre les deux valeurs d'appels, et si elle dure plus de 70 millisecondes, quittez le processus, sinon imprimez le message.

Il existe d'autres API Windows qui peuvent être utilisées pour obtenir du temps, telles que :

• GetLocalTime().
• GetSystemTime().
• QueryPerformanceCounter().

Les points d'arrêt logiciels sont une technique anti-débogage courante utilisée par les acteurs malveillants pour rendre plus difficile la rétro-ingénierie de leurs logiciels malveillants. Cette technique consiste à insérer une instruction de code spécifique, connue sous le nom de point d'arrêt, dans le programme à un emplacement spécifique. Lorsque le programme est exécuté, le point d'arrêt entraîne l'arrêt du programme, ce qui rend difficile pour un débogueur d'analyser le comportement du programme.

Une façon d'implémenter un point d'arrêt à l'aide du langage d'assemblage consiste à utiliser l' int 3instruction. Cette instruction est une interruption logicielle qui provoque l'arrêt de l'exécution du programme et le transfert du contrôle au débogueur. Voici un exemple d'utilisation de l' int 3instruction en C++ :

Points d'arrêt matériels :

Les points d'arrêt matériels sont un type de technique anti-débogage qui utilise des fonctionnalités matérielles spécialisées du processeur pour détecter et empêcher le débogage d'un programme. Cette technique consiste à définir un point d'arrêt sur une adresse mémoire ou un registre spécifique, puis à demander au processeur de déclencher une interruption chaque fois que le programme accède ou modifie l'adresse ou le registre spécifié.

L'exemple ci-dessous montre comment vérifier si un point d'arrêt matériel est défini :

Une valeur différente de zéro dans l'un des registres de débogage peut suggérer que le processus est exécuté sous un débogueur avec un ensemble de points d'arrêt matériel.

Auto-débogage :

Est une technique utilisée par les auteurs de logiciels malveillants pour empêcher un débogueur de s'attacher au processus ou de vérifier si le processus est sous un débogueur. Cela implique d'utiliser un débogueur pour déboguer le programme lui-même, afin de détecter et d'empêcher d'autres débogueurs de s'attacher au programme.

Vous trouverez ci-dessous un exemple d'instance qui crée une deuxième instance du processus et crée un événement nommé avec le nom "debugger_present". La deuxième instance du processus essaiera d'attacher un débogueur au processus parent et s'il échoue, il définira l'événement qui indiquera au processus parent qu'un autre débogueur lui est attaché :

UnhandledExceptionFilter()

Si un programme rencontre une exception qui n'est gérée par aucun gestionnaire d'exception enregistré, la fonction kernel32!UnhandledExceptionFilter() sera appelée. Il est possible d'enregistrer un filtre d'exception non géré personnalisé à l'aide de kernel32!SetUnhandledExceptionFilter(). Cependant, si le programme est en cours de débogage, le filtre personnalisé ne sera pas appelé et l'exception sera transmise au débogueur à la place. Par conséquent, si le contrôle est passé au filtre d'exception non géré, on peut en déduire que le programme ne s'exécute pas sous un débogueur :

merci d'avoir pris le temps de lire ceci jusqu'à la prochaine fois.

D'après Infosec Writeups : Il se passe beaucoup de choses chaque jour dans l'Infosec qu'il est difficile de suivre. Rejoignez notre newsletter hebdomadaire pour obtenir toutes les dernières tendances Infosec sous la forme de 5 articles, 4 fils de discussion, 3 vidéos, 2 dépôts et outils GitHub et 1 alerte d'emploi GRATUITEMENT !