Les Structured Exception Handlers

[supersnail]

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(
  _In_  struct _EXCEPTION_POINTERS *ExceptionInfo
);

La structure EXCEPTION_POINTERS est définie comme ceci:

Code C :

typedef struct _EXCEPTION_POINTERS {
  PEXCEPTION_RECORD ExceptionRecord;
  PCONTEXT          ContextRecord;
} EXCEPTION_POINTERS, *PEXCEPTION_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 {
    struct *_SEH_CHAIN Next;
    LPEXCEPTION_FILTER lpExceptionFilter;
} SEH_CHAIN, PSEH_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 :


push MyExceptionFilter
push dword[fs:0]
mov [fs:0], esp
 

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
extern MessageBoxA
extern ExitProcess

section .data readable writeable
    title db "Everything works",0
    message db "THE GAME FAGGOT",0
    trololo2 db "Second SEH handler", 0
    normal db "Normal execution taken", 0

section .idata readable writeable

section .text readable writeable executable
global _start

; Fonction permettant de faire une boîte de message rapidement
MsgBox:
    push ebp
    mov ebp, esp
    push 16
    push title
    push dword[ebp+8]
    push 0
    call MessageBoxA
    leave
    ret 4

;Point d'entrée du prog
_start:
        ; Création de la structure de SEH
    push _seh
    push dword[fs:0]
        ; Ajout du SEH à la tête de la liste
    mov [fs:0], esp
        ; On déclenche une exception pour appeler le SEH
    int 3
    _normal:
    push normal
    call MsgBox
    _exit:
    call ExitProcess
    ret

; Ici notre premier filtre
_seh:
    push message
    call MsgBox
        ; On crée un 2ème SEH
    mov eax, [fs:0]
    lea eax, [eax+4]
    mov dword[eax], _seh2
        ; SEHception
    int3
    jmp _exit
   
_seh2:
        ; On récupère le champ CONTEXT de la structure EXCEPTION_POINTERS
    mov eax, [esp+0ch]
        ;  On récupère l'adresse de CONTEXT.Eip
    lea eax, [eax+0B8h]
        ; On remplace EIP par l'adresse du label _normal
    mov dword[eax], _normal
        ; On continue
    mov eax, 0
    ret
 

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.

• http://uninformed.org/index.cgi?v=5&a=2&p=4
  
• https://www.ethicalhacker.net/features/r...nt-process
  
• http://msdn.microsoft.com/en-us/library/...zty51.aspx
  
• http://msdn.microsoft.com/en-us/library/...85%29.aspx