3 hope these are considered improvements by Ange, too :)
source | link

The first element of the exception handlers' chain is pointed by the first member of the Thread Information Block (TIB), in turn a member of the Thread Environment Block (TEB), which is always located atpointed to by fs:0. (It means that fs - a selector - is defined so that fs:0 points to the actual address, whichwhich is also reachable 'directly' - via something like ds:7efdd00., depending on the OS version etc)

  1. the first two push define areserve stack space for the structure _EXCEPTION_REGISTRATION_RECORD on the stack.

    1. the new top handler
    2. the previous top handler, which was until now at fs:[0]
  2. the mov sets the current stack position as the new structure. When an exception happens, next will be now the first called handler.

  3. int3 triggers an exception instantaneously (there are many other kinds of exception triggers).

  4. as an exception is triggered, Windows dispatches the exception to the first handler, and the next one if it's not handled, until one of them has handled it.

keeping full control: break on KiUserExceptionDispatcherKiUserExceptionDispatcher

KiUserExceptionDispatcher is the Windows API handling all user-mode exceptions. Setting a breakpoint there guarantees that you keep full control - but then, you're in the middle of a Windows API ;)

The first element of the exception handlers' chain is pointed by the first member of the Thread Information Block, which is always located at fs:0. (It means that fs - a selector - is defined so that fs:0 points to the actual address, which is also reachable 'directly' - via something like ds:7efdd00.)

  1. the first two push define a structure _EXCEPTION_REGISTRATION_RECORD on the stack.

    1. the new top handler
    2. the previous top handler, which was until now at fs:[0]
  2. the mov sets the current stack position as the new structure. When an exception happens, next will be now the first called handler.

  3. int3 triggers an exception instantaneously (there are many other kinds of exception triggers).

  4. as an exception is triggered, Windows dispatches the exception to the first handler, and the next one if it's not handled, until one of them has handled it.

keeping full control: break on KiUserExceptionDispatcher

KiUserExceptionDispatcher is the Windows API handling all exceptions. Setting a breakpoint there guarantees that you keep full control - but then, you're in the middle of a Windows API ;)

The first element of the exception handlers' chain is pointed by the first member of the Thread Information Block (TIB), in turn a member of the Thread Environment Block (TEB), which is pointed to by fs:0 (which is also reachable 'directly' - via something like ds:7efdd00, depending on the OS version etc)

  1. the first two push reserve stack space for the structure _EXCEPTION_REGISTRATION_RECORD.

    1. the new top handler
    2. the previous top handler, which was until now at fs:[0]
  2. the mov sets the current stack position as the new structure. When an exception happens, next will be now the first called handler.

  3. int3 triggers an exception instantaneously (there are many other kinds of exception triggers).

  4. as an exception is triggered, Windows dispatches the exception to the first handler, and the next one if it's not handled, until one of them has handled it.

keeping full control: break on KiUserExceptionDispatcher

KiUserExceptionDispatcher is the Windows API handling all user-mode exceptions. Setting a breakpoint there guarantees that you keep full control - but then, you're in the middle of a Windows API ;)

2 SafeSEH mention
source | link

In 32bits versions of Windows, they can be set on the fly, without any pre-requirement (unless the binary is compiled with /SafeSEH).

In 32bits versions of Windows, they can be set on the fly, without any pre-requirement.

In 32bits versions of Windows, they can be set on the fly, without any pre-requirement (unless the binary is compiled with /SafeSEH).

1
source | link

TL;DR

  1. the first 3 lines set an exception handler (an 'error catcher')

  2. the int3 generates an exception

  3. execution resumes at next


Explanation

this trick is (ab)using Structured Exception Handling, a mechanism to define exception handlers, typically by compilers when try/catch blocks are used.

In 32bits versions of Windows, they can be set on the fly, without any pre-requirement.

The first element of the exception handlers' chain is pointed by the first member of the Thread Information Block, which is always located at fs:0. (It means that fs - a selector - is defined so that fs:0 points to the actual address, which is also reachable 'directly' - via something like ds:7efdd00.)

So here is what happens:

  1. the first two push define a structure _EXCEPTION_REGISTRATION_RECORD on the stack.

    1. the new top handler
    2. the previous top handler, which was until now at fs:[0]
  2. the mov sets the current stack position as the new structure. When an exception happens, next will be now the first called handler.

  3. int3 triggers an exception instantaneously (there are many other kinds of exception triggers).

  4. as an exception is triggered, Windows dispatches the exception to the first handler, and the next one if it's not handled, until one of them has handled it.

flowchart of Exception handling

Following execution

This is done here under OllyDbg 1.10. YMMV.

As we want to go through exceptions ourselves, we have to ask OllyDbg not to handle them:

  1. go to debugging options: Alt-O, tab Exceptions

  2. unselect INT3 breaks

And when an exception is triggered, we have to enforce that execution is done via exceptions (see below).

Here are 3 methods of increasing level to follow the exception handling execution safely:

step by step: set a breakpoint manually

As the handler has just been set on the stack, you can manually set a breakpoint then run.

  1. select the new handler address on the stack

    new handler on the stack

  2. Right-click or F10

    • select Follow in Dump
  3. in the dump window, open the menu (same shortcut)

    • select BreakPoint, then Hardware, on execution
  4. Execute: menu Debug/Run / shortcut F9 / command-line g

  5. Exceptions will be triggered

  6. Execute with exception handling: shortcut Shift-F9 / command-line ge.

shortcut: execute until exception handler via command-line

  • as the address is on the stack, the easiest way is to type via the command line ge [esp+4], which means, Go with Exceptions, until the 2nd address on the stack is encountered. Thus, no need to set and unset a breakpoint.

    • in the case of a more complex example, where the address might not be obvious on the stack anymore, then the absolute formula would be ge ds:[fs:[0]+4], which just gets the actual address from the TIB.

keeping full control: break on KiUserExceptionDispatcher

KiUserExceptionDispatcher is the Windows API handling all exceptions. Setting a breakpoint there guarantees that you keep full control - but then, you're in the middle of a Windows API ;)

In this case, you can ask OllyDbg to skip exceptions, as you will still break execution manually in any cases. You might also want to combine that with a script.

Of course, some advanced code might check that you set a breakpoint on it before triggering an exception.