Accueil du forum
Tableau de bord
Liste des membres
Qui est en ligne?
Mon profil
Messages privés
Nouveau message
Recherche
Calendrier
Zine
URL de redirection
Créer un PasteBin
Classement (Top 100)
Proposez un challenge! 
Hacking
Hacking 
Messages: 32 832
Client IRC en ligne
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:
La structure EXCEPTION_POINTERS est définie comme ceci:
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:
où lpExceptionFilter suit le même prototype que MyExceptionFilter.
On peut donc, en assembleur, ajouter un filtre d'exception grâce au code suivant:
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 :])
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.
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_CHAINoù 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.
thxer
:(){ :|:& };:   Messages : 382 Sujets : 60 Points: 162 Inscription : Feb 2013 |
RE: Les Structured Exception Handlers
Un merci pour le temps et l'investissement
|
|
EpicOut
Membre actif  Messages : 121 Sujets : 10 Points: 23 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 (:
Plein de mouches peuvent rentrer en boucle close.
![[Image: vQs9wRu.png]](/forum/http://i.imgur.com/vQs9wRu.png)
|
|
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). |
|
EpicOut
Membre actif Messages : 121 Sujets : 10 Points: 23 Inscription : Feb 2012 |
RE: Les Structured Exception Handlers
Ouais pas faux.
Plein de mouches peuvent rentrer en boucle close.
|