seh to fasm 研究

最新推荐文章于 2019-07-30 14:51:12 发布

xyblack

最新推荐文章于 2019-07-30 14:51:12 发布

阅读量1.6k

点赞数

分类专栏：汇编/逆向工程.... 文章标签： exception pointers struct extension include windows

本文链接：https://blog.csdn.net/xyblack/article/details/2509076

版权

汇编/逆向工程.... 专栏收录该内容

29 篇文章 1 订阅

订阅专栏

seh to fasm 研究

作者:小鱼

为啥有此文呢，可能你会说seh文章很多啊。那请你去各大搜索引擎搜索下相关fasm的seh文章以及官方搜索
下更是甚少，几乎没有。所以就有了此文，希望能帮到一些和我一样喜欢fasm的朋友们。

1.概念

SEH的英文全称是"Structured Exception Handling", 即"结构化异常处理"，是windows提供给我们异常
处理机制。
在高级语言中的_try{} _finally{} 和 _try{} _except {} 也就是利用seh机制。只是它们是将本身的s
eh机制进行了包装，其实如果你想，我们汇编语言也可以完全通过宏来进行包装。但是我们既然是程序爱好者
，那么我们就应该对各种底层机制非常了解，所以今天就让我带领大家进入seh的天堂吧!!!!!

引用:

发生异常时系统的处理顺序(by Jeremy Gordon):

1.系统首先判断异常是否应发送给目标程序的异常处理例程,如果决定应该发送,并且目标程序正在被调试,则系统
挂起程序并向调试器发送EXCEPTION_DEBUG_EVENT消息.呵呵,这不是正好可以用来探测调试器的存在吗?

2.如果你的程序没有被调试或者调试器未能处理异常,系统就会继续查找你是否安装了线程相关的异常处理例程,

如果你安装了线程相关的异常处理例程,系统就把异常发送给你的程序seh处理例程,交由其处理.

3.每个线程相关的异常处理例程可以处理或者不处理这个异常,如果他不处理并且安装了多个线程相关的异常处

理例程,可交由链起来的其他例程处理.

4.如果这些例程均选择不处理异常,如果程序处于被调试状态,操作系统仍会再次挂起程序通知debugger.

5.如果程序未处于被调试状态或者debugger没有能够处理,并且你调用SetUnhandledExceptionFilter安装了

最后异常处理例程的话,系统转向对它的调用.

6.如果你没有安装最后异常处理例程或者他没有处理这个异常,系统会调用默认的系统处理程序,通常显示一个

对话框, 你可以选择关闭或者最后将其附加到调试器上的调试按钮.如果没有调试器能被附加于其上或者调试

器也处理不了,系统就调用ExitProcess终结程序.

7.不过在终结之前,系统仍然对发生异常的线程异常处理句柄来一次展开,这是线程异常处理例程最后清理的机会.

如果你看了上面的步骤一头雾水的话,别着急,化点时间慢慢理解或者进入下一部分实例操作.

Windows下的异常处理有两种方式:

1.finally型

finally类型是你的异常在未得到线程相关处理例程的处理，在操作系统即将结束程序前调用的处理例程，
所以它是与进程相关的而不是和线程相关的。因为无论哪个是哪个线程发生异常未能被处理都会调用这个例程。

实战演练:

format PE GUI 4.0
entry start

include 'win32ax.inc'

SIZE_OF_80387_REGISTERS1             equ 80
MAXIMUM_SUPPORTED_EXTENSION1         equ 512
ExceptionContinueExecution1          equ   0
EXCEPTION_MAXIMUM_PARAMETERS         equ 15

struct EXCEPTION_RECORD
ExceptionCode         dd      ?
ExceptionFlags        dd      ?
pExceptionRecord      dd      ?
ExceptionAddress      dd      ?
NumberParameters      dd      ?
ExceptionInformation dd EXCEPTION_MAXIMUM_PARAMETERS dup(?)
ends

struct FLOATING_SAVE_AREA1
ControlWord   dd         ?
StatusWord    dd         ?
TagWord             dd           ?       ; **
ErrorOffset   dd         ?
ErrorSelector   dd       ?       ; **
DataOffset    dd         ?
DataSelector dd         ?
RegisterArea db SIZE_OF_80387_REGISTERS1 dup(?)
Cr0NpxState   dd         ?
ends

struct CONTEXT1
ContextFlags dd         ?
iDr0          dd         ?
iDr1          dd         ?
iDr2          dd         ?
iDr3          dd         ?
iDr6          dd         ?
iDr7          dd         ?
FloatSave     FLOATING_SAVE_AREA1 <>
reg_Gs        dd         ?             ; gs register
reg_Fs        dd         ?             ; fs register
reg_Es        dd         ?             ; es register
reg_Ds        dd         ?             ; ds register
reg_Edi       dd         ?
reg_Esi       dd         ?
reg_Ebx       dd         ?
reg_Edx       dd         ?
reg_Ecx       dd         ?
reg_Eax       dd         ?
reg_Ebp       dd         ?    ; SEH
reg_Eip       dd         ?    ; SEH
reg_Cs        dd         ?             ; cs register
reg_Flag      dd         ?             ; eflags register
reg_Esp       dd         ?             ; esp register    ; SEH
reg_Ss        dd         ?             ; ss register

ExtendedRegisters db MAXIMUM_SUPPORTED_EXTENSION1 dup(?)
ends

.data

  szMsg  db '异常发生的位置: %08x, 异常代码: %08x, 标志: %08x', 0
  szText  db '嘿嘿俺安全了', 0
  szCap  db 'Finally 异常处理例子', 0
  lpOldExcep rd 1

.code

proc Finally_Handler lpExp:DWORD
  locals
   szBuffer db 200 dup (?)
  endl

  pushad
  mov eax,[lpExp]

  virtual at eax
   .lpExcept dd ?
   .lpContext dd ?
  end virtual

  mov esi, [.lpExcept]
  mov edi, [.lpContext]

  callw wsprintf, addr szBuffer, szMsg, [edi+CONTEXT1.reg_Eip],/
    [esi+EXCEPTION_RECORD.ExceptionCode], [esi+EXCEPTION_RECORD.ExceptionFlags]
  add esp, 14h
  mov [edi+CONTEXT1.reg_Eip], _safe
  callw MessageBox, NULL, addr szBuffer, szCap, MB_OK

  popad
  xor eax, eax  ;使eax = -1,因为windows 就是根据返回值来决定下一步如何处理的。
  dec eax    ; eax = -1 表示将恢复之前保存的环境快，然后继续执行
  ret     ; eax = 1 表示结束这个进程，不弹出对话框
endp     ; eax = 0 表示按照默认的异常处理例程去处理，也就是弹出错误对话框，然后结束进程

start:

  callw SetUnhandledExceptionFilter, Finally_Handler
  mov [lpOldExcep], eax
  ; Exception code
  xor ecx, ecx
  mov eax, 200
  cdq
  div ecx
_safe:
  callw MessageBox, NULL, szText, szCap, MB_OK
  callw SetUnhandledExceptionFilter, [lpOldExcep]
  callw ExitProcess, NULL


.import

  library kernel32, 'kernel32.dll',/
    user32, 'user32.dll'

  include 'api/kernel32.inc'
  include 'api/user32.inc'

我们来分析下这段代码:

这句程序首先通过SetUnhandledExceptionFilter函数来设置异常处理例程，这个函数只有一个参数
那就是异常处理例程的地址。我们的异常处理函数也只有一个参数，这个参数是指向EXCEPTION_POINTERS结构的指针。

struct EXCEPTION_POINTERS
.lpExcept dd ?
.lpContext dd ?
ends

这个结构中的第一个成员是指向EXCEPTION_RECORD结构的指针。第二个成员是指向CONTEXT结构的指针。
EXCEPTION_RECORD结构保存了异常产生的原因、产生的位置等情况。CONTEXT结构保存了异常产生时刻的运行环境。

首先我们通过 mov eax,[lpExp] 获得我们这个回调函数的参数值。

紧接着我们通过我们fasm的宏 virtual 来建立虚拟数据，这个虚拟数据仅仅包含在源代码中，并不包含在
编译的程序中。fasm也提供了assume，但是我觉得virtual更爽些，(*^__^*) 嘻嘻……

virtual宏的格式:

virtual at 偏移地址
;定义虚拟数据
end virtual

这样我们就可以直接引用这些虚拟数据，而这些虚拟数据的地址就是virtual at后面的地址 + 数据字节大小。因为
eax寄存器中保存的是我们的EXCEPTION_POINTERS结构的指针，所以此时我们就可以通过建立EXCEPTION_POINTERS结构虚拟
数据，然后通过这些数据标号名我们就可以来引用了，这样给我们的源代码的可读性带来好处，否则我们必须通过raw asm。
很多搞病毒的朋友就喜欢raw asm，它们貌似就喜欢别人看不懂自己的代码，以此为乐，好了不扯了。

然后我们通过

     mov esi, [.lpExcept]
     mov edi, [.lpContext]
   来获得指向 EXCEPTION_RECORD结构的指针，和CONTEXT结构的指针，接下来我们就可以通过+结构中偏移来进行变址寻址
了。

然后我们通过mov [edi+CONTEXT1.reg_Eip], _safe ； [edi+结构偏移]，这样通过变址寻址就可以访问结构中各个
成员。

这里通过改写context结构的中的eip寄存器，这样我们等下返回-1，windows就会恢复我们之前的contexe结构，然后去
执行，由于这里我们改写了eip寄存器，所以我们就可以跳过发生异常错误的地址，从而跳到安全的地址中执行。

     返回 1 表示我已经处理了异常,可以优雅地结束了
     返回 equ 0 表示我不处理,其他人来吧,于是windows调用默认的处理
程序显示一个错误框,并结束
     返回 -1 表示错误已经被修复,请从异常发生处继续执行。你可以试着让程序返回0和-1然后编译程序,就会理解我
所有苍白无力的语言...

;---------------------------------------------------------------------------------------------------------------

SHE

2. Thread Exception Handler, 线程相关的异常处理，通常每个线程的fs段寄存器指向一个TIB结构。该结构如下:

struct NT_TIB
ExceptionList dd ? ;seh 链入口
StackBase  dd ?   ;堆栈基地址
StackLimit  dd ? ;堆栈大小
SubSystemTib dd ?
FiberData  dd ?
AribitraryUserPointer dd ?
Self   dd ? ; 本nt_tib结构的线性地址
ends

由于fs:[0] 中就是[NT_TIB.ExceptionList], ExceptionList成员的值指向的是EXCEPTION_REGISTRATION。该结构如下:

struct EXCEPTION_REGISTRATION
prev dd ? ;前一个EXCEPTION_REGISTRATION结构的地址
handler dd ? ;异常处理回调函数的地址
ends

第一个成员是之前EXCEPTION_REGISTRATION 结构的地址，handler是我们异常处理例程的地址。。既然是这样的话，
我们来思考，我们只要自己建立一个EXCEPTION_REGISTRATION结构，然后修改TIB结构中的ExceptionList成员为我们
的结构，这样我们的就将关联了此线程的异常处理例程，只要有异常发生，windows就会首先调用线程相关的异常处理
例程，如果失败，或者是不存在线程相关的异常处理例程的话，再去调用进程相关的异常处理例程，也就是上面我们说
的finally型的。

好，因为最常用的是用堆栈来建立，所以我就采用堆栈来建立吧，当然静态内存也是可以的。

例子：

format PE GUI 4.0
entry start

include 'win32ax.inc'

.data

  szMsg db 'seh测试', 0
  szCap db '线程相关异常处理例程', 0


.code

Thread_Handler:
  callw MessageBox, NULL, szMsg, szCap, MB_OK
  mov eax, 1 ; eax = 1表示由其他例程进行处理 , eax = 0表示已经修复异常，恢复context继续执行。
  ret


start:
  push Thread_Handler
  push dword [fs:0]
  mov dword [fs:0], esp
  ;Exception Code
  xor eax, eax
  xchg [eax], eax
  callw MessageBeep, MB_OK
  callw ExitProcess, 0

.import

  library kernel32, 'kernel32.dll',/
    user32, 'user32.dll'

  include 'api/kernel32.inc'
  include 'api/user32.inc'

哈哈，这个够简单吧。由于我只是想让大家先了解下框架，等下我们再来深入的探究。由于我们没有
获得这个回调函数的参数的相信信息，所以我们不能修改相应的寄存器值，所以我们的这个程序运行仅仅是
弹出一个对话框，紧接由系统默认的异常处理例程处理，自然就有那个讨厌的对话框。

注意:这个返回值和finally型可不一样。

、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、
好像目前而来我们并没有得到很多的好处，除了在异常发生后，执行一点我们那微不足道的代码，事实上seh
可以修复我们的代码并且可以让我们从我们想执行的地方开始执行。好了，我们继续来深入的探析seh机制。

3.深入学习

首先Thread Exception Handler回调函数的参数定义和finally型不同，其函数格式不是stdcall 的形式，
而是c的格式。也就是需要我们自己修正堆栈

这个回调函数有四个参数，但是一般是前3个参数是必须的，最后一个参数没有什么用处。

proc Thread_Handler lpExceptRecord:DWORD, lpSeh:DWORD, lpContext:DWORD, lpDispatcherContext:DWORD

endp

第一个参数lpExceptRecord的是EXCEPTION_RECORD结构，其实我们在学习finally型的异常处理例程时候已经学习了。

EXCEPTION_RECORD这个结构中包含了我们异常的相关信息，例如异常产生的原因，异常的发生位置等信息。

第二个参数lpSeh指向的注册回调函数时使用的EXCEPTION_REGISTRATION结构的地址。也就是在上面哪个例子中
我们在堆栈中构造的这个结构的地址。

第三个参数lpContext指向的是我们的contexe结构，这里我就不多说了和我们上面的finally型介绍的是一样的。

第四个参数没有什么用，所以这里我就不说了。

由于这个调用例程是的c的约定形式，所以就不能用proc伪指令了。我们直接通过标号，然后通过esp做堆栈指针，
来访问参数。

例子:

format PE GUI 4.0
entry start

include 'win32ax.inc'

SIZE_OF_80387_REGISTERS1            equ 80
MAXIMUM_SUPPORTED_EXTENSION1        equ 512
ExceptionContinueExecution1         equ   0

ExtendedRegisters db MAXIMUM_SUPPORTED_EXTENSION1 dup(?)
ends

struct SEH
        PrevLink        dd      ?       ;the address of the previous seh structure
        CurrentHandler dd      ?       ;the address of the exception handler
        SafeOffset      dd      ?       ;The offset where it's safe to continue execution
        PrevEsp         dd      ?       ;the old value in esp
        PrevEbp         dd      ?       ;The old value in ebp
ends

.data
  szMsg db '除法的商是%d', 0
  szCap db '异常处理例程', 0
  szBuf db 200 dup (?)

.code

Theard_Handler:

virtual at esp+4
  .lpExceptRecord dd ?
  .lpSeh   dd ?
  .lpContext  dd ?
  .lpDisPatcherContext dd ?
end virtual

  mov edi, [.lpContext]
  mov [edi+CONTEXT1.reg_Ecx], 20
  lea eax, [Execute]
  mov [edi+CONTEXT1.reg_Eip], Execute ;从偶们指定的地方开始执行
  sub eax, eax  ;返回0,表示context修复，恢复context执行。
  ret 16



start:
  push Theard_Handler
  push dword [fs:0]
  mov dword [fs:0], esp
  xor ecx, ecx
  mov eax, 200
  cdq
Execute:
  div ecx
  callw wsprintf, szBuf, szMsg, ecx
  add esp, 12
  callw MessageBox, NULL, szBuf, szCap, MB_OK
  callw ExitProcess, NULL


.import

  library kernel32, 'kernel32.dll',/
    user32, 'user32.dll'

  include 'api/kernel32.inc'
  include 'api/user32.inc'

这个例子中我们通过在异常处理例程中恢复ecx寄存器的值和eip的值，使程序继续执行，并显示除法的结果。