Les Structured Exception Handlers
|
12-11-2013, 15h18
Message : #1
|
|
supersnail
Éleveur d'ornithorynques Messages : 1,609 Sujets : 71 Points: 465 Inscription : Jan 2012 |
Les Structured Exception Handlers
I - Introduction
Dans cet article, nous allons nous intéresser aux Structured Exception Handlers, abrégés SEH par la suite pour des raisons évidentes de fainéantise. Ces SEH sont donc un moyen de gérer les exceptions qui peuvent survenir lors du déroulement d'un programme sous Windows (plus précisément un thread, les SEH sont locaux à un thread). Les langages tels que C++ implémentent justement les blocs try/catch/finally à l'aide de ces SEH, tout comme certains malwares ou packers utilisent ces mécanismes afin de rendre leur analyse plus fastidieuse. II - Mise en place d'un SEH "simple" Une manière "convenable" de créer un "SEH" est d'appeler la fonction "SetUnhandledExceptionFilter" qui va définir notre propre gestionnaire d'erreurs, lequel sera appelé par UnhandledExceptionFilter si on l'a défini. Cependant, cette fonction de gestion d'erreur sera cepandant globale au processus, et non juste au thread la définissant, et sera remplacée si on fait un appel à SetUnhandledExceptionFilter avec une autre gestionnaire d'erreurs. Notre gestionnaire d'erreur doit avoir comme prototype: Code C :
LONG WINAPI MyExceptionFilter( La structure EXCEPTION_POINTERS est définie comme ceci: Code C :
typedef struct _EXCEPTION_POINTERS { Le champ ExceptionRecord est un pointeur vers une structure de type EXCEPTION_RECORD contenant diverses informations sur l'exception qui a été déclenchée et dont la documentation est disponible ici. L'autre champ est un pointeur vers une structure de type CONTEXT, qui contient le contexte d'exécution du thread, et notamment les valeurs de tous les registres de ce thread au moment où l'exception a eu lieu, et que l'on peut modifier à notre aise. Par ailleurs, la valeur de retour de notre gestionnaire d'erreur indique quelles opérations à effectuer, décrites dans la documentation de la fonction, mais généralement une valeur de retour de 0xffffffff (c'est-à-dire -1) ou 0 a pour but de redonner la main au programme, avec le CONTEXT modifié (s'il l'a été) par notre gestionnaire d'exceptions. Il est ainsi possible de "brouiller les pistes" et de masquer un saut en passant par des gestionnaires d'exception qui vont remplacer la valeur de EIP par l'adresse où on voudrait aterrir. III - Mise en place d'une chaîne de SEH En plus de définir un gestionnaire d'exceptions qui sera appelé lors d'une exception inconnue qui survient lors de l'exécution de l'application, il est possible de "chaîner" les SEH. Les SEH sont en fait une liste chaînée dont la tête est stockée dans le premier champ d'une structure partiellement documentée se nommant le "Thread Information Block", et dont la queue est tout simplement notre fonction UnhandledExceptionFilter qui se charge d'appeler le gestionnaire d'erreur défini grâce à la fonction présentée au-dessus ! L'avantage du chaînage d'exceptions est que la gestion d'exceptions devient locale au thread et non globale au processus (chaque thread ayant son TIB), et qu'il est possible d'ajouter/enlever des gestionnaires d'exception au gré des besoins, ce qui se révèle assez utile lorsqu'on a besoin d'implémenter des try/catch. Un maillon de la chaîne de SEH est décrit par la structure suivante: Code C :
typedef struct _SEH_CHAIN { où lpExceptionFilter suit le même prototype que MyExceptionFilter. On peut donc, en assembleur, ajouter un filtre d'exception grâce au code suivant: Code ASM :
Ce code va créer la "structure" SEH_CHAIN sur la pile en y plaçant d'abord l'adresse du filtre puis le pointeur vers l'élément suivant de la chaîne, avant de remplacer la tête par le sommet de la pile. Ainsi toute nouvelle exception lancée (ou déclenchée) dans le thread courant sera traitée par MyExceptionFilter, puis "descendra" jusqu'à UnhandledExceptionFilter qui est à la queue de la chaîne. IV - Application des SEH Pour illustrer mes propos, je vous propose un snippet de code permettant d'illustrer la partie précédente (libre à vous de l'adapter pour comprendre la 1ère partie :]) Code ASM :
BITS 32 Je vous laisse évidemment déterminer ce que fait ce code V - Liens utiles Pour finir cette randonnée, voici une petite liste de liens pour approfondir le sujet.
Mon blog
Code : push esp ; dec eax ; inc ebp ; and [edi+0x41],al ; dec ebp ; inc ebp "VIM est merveilleux" © supersnail |
|
12-11-2013, 22h35
Message : #2
|
|
thxer
:(){ :|:& };: Messages : 382 Sujets : 60 Points: 162 Inscription : Feb 2013 |
RE: Les Structured Exception Handlers
Un merci pour le temps et l'investissement
|
|
13-11-2013, 13h20
Message : #3
|
|
Banni Messages : 121 Sujets : 10 Points: 22 Inscription : Feb 2012 |
RE: Les Structured Exception Handlers
Sympatoche l'article, je me le garde sous le coude quand j'aurais besoin de faire chier les reverse engineers avec mon crackme (:
|
|
13-11-2013, 22h15
Message : #4
|
|
Horgh
Membre actif Messages : 197 Sujets : 4 Points: 91 Inscription : Mar 2012 |
RE: Les Structured Exception Handlers
(13-11-2013, 13h20)EpicOut a écrit : Sympatoche l'article, je me le garde sous le coude quand j'aurais besoin de faire chier les reverse engineers avec mon crackme (: >implying les exceptions sont dérangeantes. Il y a l'option d'olly pour disable tout ou partie des exceptions ; et dans certains cas comme pour les versions 1.x d'asprotect ça peut devenir un avantage pour unpacker le programme. Ca peut être à la rigueur utile contre les émulateurs, mais contre quelqu'un qui RE ça n'a pas tellement d'intérêt (à part peut-être si on s'en sert pour effacer les DR registers). |
|
14-11-2013, 14h05
Message : #5
|
|
Banni Messages : 121 Sujets : 10 Points: 22 Inscription : Feb 2012 |
RE: Les Structured Exception Handlers
Ouais pas faux.
|
|
« Sujet précédent | Sujet suivant »
|
Utilisateur(s) parcourant ce sujet : 6 visiteur(s)