SEH handlers - Page 1

Un peu de contexte: je travaille sur une application quelconque qui s'unpack au demarrage, a coup d'injection de callbacks TLS, et d'exceptions SEH. ()

Sur un CPU de bureau classique (typiquement un 8086), il se passe quoi exactement en userland quand le CPU tombe sur hlt?
D'apres la doc, et ce que je comprend, la main est passee au kernel. Tant qu'un autre interrupt n'est pas execute, le programme est en pause.

Mais ca c'est si le programme est en ring 0. En userland, il se passe quoi? Une exception est generee? Je pars du principe que oui, puisque c'est ce qu'IDA me dit. Du coup, je pars dans les TIB pour trouver le handler d'exception. Sur IDA, ca se fait avec Ctrl+S, et on va dans TIB.



D'apres ce que je sais des SEH, on a plus ou moins une chaine de pointeurs, sauf qu'ici j'ai un pointeur vers 0x10000 en debut de chaine. (0x0FFFFFFFF marque la fin de la chaine d'exceptions). A ce pointeur 0x10000, je devrais avoir un autre pointeur. Sauf que j'ai un nullptr. Du coup, il se passe quoi? L'exception est ignoree, ou c'est cense crash si et seulement si un debuggeur est attache? A noter que je triche avec un breakpoint qui ecrase eax = 0 dans kernel32_IsDebuggerPresent...

[EDIT] de plus, un breakpoint place au debut de ntdll_NtContinue n'est jamais declenche (Cette fonction est appellee a la fin de chaque handler SEH)

Warpten (./1) :
En userland, il se passe quoi? Une exception est generee?

Oui, la doc le confirme :

HLT—Halt

Protected Mode Exceptions
#GP(0) If the current privilege level is not 0.

Pour les SEH, je ne sais pas, je n'ai jamais creusé de ce côté. À ta place je coderais une petite application de test pour voir ce que ça fait concrètement.

nickel. du coup, j'suis alle voir dans ntdll, et les pointeurs vers les handler sont encodes (RltEncodePointer). aucune idee pourquoi. du coup c'est bon j'ai mon pointeur, plus qu'a comprendre tout ca, parce que tout est encore obfusque avec des acces non alignes...

Pour le SEH pour les exceptions CPU, tout ce que je sais, c'est que Windows installe des handlers pour les exceptions CPU qui les convertissent en exceptions SEH, le format d'exceptions natif de Windows. Le matériel ne produit pas directement du SEH, c'est une convention logicielle de Windows. Mais à cause de la conversion que fait Windows, si tu veux pouvoir attrapper des exceptions du CPU, il te faut gérer les exceptions SEH.

Bon, je crois avoir compris tout le lot. A defaut de comprendre mon handler SEH, j'ai mis un breakpoint dans NtContinue et regarde ou EIP pointait.

Je me suis retrouve ici.

.text:00405FD0 55                      push    ebp
.text:00405FD1 8B EC                   mov     ebp, esp
.text:00405FD3 0F BE 42 01             movsx   eax, byte ptr [edx+1]
.text:00405FD7 8B 55 08                mov     edx, [ebp+arg_0]
.text:00405FDA 0F BE 09                movsx   ecx, byte ptr [ecx]
.text:00405FDD 0F BE 52 02             movsx   edx, byte ptr [edx+2]
.text:00405FE1 33 C2                   xor     eax, edx
.text:00405FE3 8B 55 0C                mov     edx, [ebp+arg_4]
.text:00405FE6 0F BE 52 03             movsx   edx, byte ptr [edx+3]
.text:00405FEA 33 C2                   xor     eax, edx
.text:00405FEC 33 C1                   xor     eax, ecx
.text:00405FEE 5D                      pop     ebp
.text:00405FEF C2 08 00                retn    8

Le probleme que j'affronte actuellement, c'est que pour une raison qui m'echappe, mon debuggeur est incapable d'aller plus loin que movsx eax, [edx + 1] (qui revient a un simple mov eax, 1). Que ce soit continue, step over ou step in, il coince sur cette instruction... J'ai cru a un trap debuggeur apres m'etre rendu compte que mon point d'arret dans IsDebuggerPresent etait parti, mais meme avec, le controle retourne dans cette fonction...

[EDIT] Et hexrays est totalement perdu

int __stdcall sub_405FD0(int a1, int a2)
{
  int v2; // edx@0
  _BYTE *v3; // ecx@0

  return *v3 ^ *(a2 + 3) ^ *(a1 + 2) ^ *(v2 + 1);
}