码迷,mamicode.com
首页 > 其他好文 > 详细

软件调试

时间:2020-04-04 11:40:13      阅读:110      评论:0      收藏:0      [点我收藏+]

标签:ati   目的   也会   setevent   isp   lap   报告   key   guide   

Windows内核分析索引目录:https://www.cnblogs.com/onetrainee/p/11675224.html

软件调试

1.调试程序如何与被调试程序 
2. 调试事件的采集
3. 调试事件的处理流程
4. 异常的调试流程
5. 软件断点
6. 内存断点
7. 硬件断点
8. 单步异常与单步步过
9. 硬件HOOK

 

1.调试程序如何与被调试程序 

技术图片

  1)API建立存在两种方式

    ①CreateProcess

    ②DebugActiveProcess

  2) 调试器如何创建调试对象 - Kernel32!DebugActiveProcess函数分析

    技术图片

    ① DbgUiConnectToDbg函数分析:

      其函数分析如下:简单的就是调用zw函数进零环,在零环创建一个内核对象然后返回三环。

      其内核模块创建的具体细节,可以搜索nt!CreateDebugObject函数。

      技术图片

     ② DebugObject数据结构如下

       typedef struct _DEBUG_OBJECT {
            KEVENT EventsPresent;
            FAST_MUTEX Mutex;
            LIST_ENTRY EventList;
            ULONG Flags;
       } DEBUG_OBJECT, *PDEBUG_OBJECT;

    ③ DebugObject 创建完之后放在那里

      如何我们查看Kernel32!DebugActiveProcess函数时,我们发现虽然调用DbgUiConnectToDbg创建一个DEBUG_OBJECT,但我们并没有看到该结构体。

      其返回值是一个是否调用成功,那存放在哪里了呢?我们查看其zwCreateDebugObject的反汇编,如下:

      我们可以得出,其存放在当前调试器线程的 Teb+0xF24 的位置中。

      技术图片

  3)被调试进程与调试进程建立关系 - Kernel32!DebugActiveProcess函数分析

     ①DbgUiConnectToDbg函数分析:

      我们之前分析过该函数通过调用 DbgUiConnectToDbg() 创建调试对象,现在我们分析其是如何与被调试进程建立联系的。

      分析如下,很明显调用一个DbgUiDebugActiveProcess()函数来建立联系的。

      技术图片

     ② ntdll!DbgUiConnectToDbg函数分析:

      分析如下图所示,这样再结合我们对于调试器的行为,则很好理解。

      技术图片

    ③ Nt!NtDebugActiveProcess函数分析:

      如下图,进入内核之后,先做的就是通过三环句柄来获取进程对象与调试对象,然后调用一个函数,在函数内部将其关联起来。

      技术图片

     ④nt!DbgkpSetProcessDebugObject函数分析

      该函数内容很多,但很容易看出核心操作就是将进程的DebugPort中传入DEBUG_OBJECT的地址,如下所示:

      技术图片

  4总结:

    要牢记大体流程,通过 DebugActiveProcess 来进行具体分析。

    首先,先调用内核创建一个调试对象,返回三环句柄,将句柄存储在Teb+0xF24中;之后将被调试程序的句柄与调试对象句柄一起传入零环中,在零环_EPROCESS.DebugPort中。

    值得注意的是:调试器是通过句柄与被调试对象建立连接的,而被调试程序是在内核中建立连接的,一个_TEB,一个_EPROCESS,这是建立的关键区别。

    技术图片

2. 调试事件的采集

  1)调试事件在哪儿

    如下:其是_DEBUG_OBJECT结构体,看存在一个 EventList,其就是一个调试事件链表。

    被调试程序各种事件发往调试对象的EventList中,然后由调试器接收并进行处理,其大体流程就是这个样子。

     typedef struct _DEBUG_OBJECT {
        KEVENT EventsPresent;
        FAST_MUTEX Mutex;
          LIST_ENTRY EventList; +0x30
       ULONG Flags;
     } DEBUG_OBJECT, *PDEBUG_OBJECT;

  2)何为调试事件?

    被调试进程所做的任何一件事,难道都要报告被调试器吗?当然不是,其存在如下七种调试事件:

    typedef enum _DBGKM_APINUMBER
    {
      DbgkmExceptionApi = 0, // 异常
      DbgkmCreateThreadApi = 1, // 创建线程
      DbgkmCreateProcessApi = 2, // 创建进程
      DbgkmExitThreadApi = 3, // 退出线程
      DbgkmExitProcessApi = 4, // 进程退出
      DbgkmLoadDllApi = 5, // 映射DLL
      DbgkmUnloadDllApi = 6, // 反映射DLL
      DbgkmErrorReportApi = 7, // 内部错误(已废弃)
      DbgkmMaxApiNumber = 8, // 这组常量的最大值 (已废弃)
    } DBGKM_APINUMBER;

  3)如何生成调试事件?(调试事件采集函数)

    我们下面介绍一组函数,其是Dbg**函数,其在各个活动事件的必经之路上。

    当被调试程序正在这些事件的一种,其都会经过这些函数,然后其检查是否处于被调试状态,如果处于就发送事件到链表中。

    技术图片

     ① Nt!DbgKpSendApiMessage函数分析

      该函数首先要判断该线程是否要暂停,然后调用DbgkpQueueMessage,该函数将生成调试事件,然后加入到调试对象链表中。

      其中我们可以得出一个反调试思路:这里是线程暂停的关键地方,我们可以保护我们的程序,hook该地方,当程序执行到这里,如果发现是我们的进程,则不暂停,

        这样,其就算接收到我们的调试事件了,也不会暂停我们的程序。

      技术图片

     ② Nt!DbgKpQueueMessage函数分析

      该函数主要目的是生成调试事件,根据传入过来的有关信息来填写,之后使用KeSetEvent。

      其中的详细过程可以在《等待对象》,那一节查看。

      技术图片

        技术图片

 

3. 调试事件的处理流程

  现在,被调试进程的所有调试事件都会发送到DebugEventList中,我们在编写调试器时,使用一个循环来循环遍历是否产生新的消息。

  void main() {

   DebugActiveProcess/CreateProcess;

   while(Alive){

    WaitForDebugEvent(&debugEvent,WaitTime);

    switch(DebugEvent.dwDebugEventCode)

    { .... }

    ContinueDebugEvent();

   }

  }

  1)WaitForDebugEvent、ContinueDebugEvent函数

    循环遍历该事件链表,如果存在事件就会取出来,处理完之后然后等待进一步执行。

    当处理完成之后,调用ContinueDebugEvent让被调试程序恢复执行,这个很好理解。

  2)发送虚假信息

    我们在调试过程时,会看见发送虚假的调试对象,这是为什么呢?

    很简单,我们及时以ActiveDebugProcess附加的方式调试进程,也可以看到其进程的线程以及各种模块加载的情况。

    这样很奇怪,进程模块加载已经完成了,为什么还能接收到加载信息呢,其实就是依赖于这组函数。

    当以附加的形式添加信息时,其会发送虚假的信息给调试器,让其可以显示出调试信息,但其不会中断,这很容易理解。

    技术图片

 

4.异常的调试流程

  如下图,用户层出现的异常调试流程,之前我们提到过异常处理流程,可其是如何发送给三环的调试器呢?

  注意③⑤,其调用的函数DbgKForwardException函数,该函数就是异常的收集函数,之后的流程我们上面已经分析过。

  技术图片

 

 

5. 软件断点

  硬件断点,众所周知是CC指令,INT 3 中断,0x80000003异常码。

  我们查看 Trap03,很明显看出其执行流程,我们之后学过异常和处理程序,接下来就知道怎么做了。

  技术图片

 

 

6. 内存断点

  内存断点本质就是调用 VirtualProtectEx 函数来修改页的属性(PTE),将其属性修改为写,当进行读的时候,会触发异常,然后执行异常的分发流程。

  其内存断点触发时执行 Trap0E 号中断函数,我们分析该中断,发现其也是调用CommonDispatchException函数,0xc0000006来触发异常。

  技术图片

 

 

7. 硬件断点

  1)CPU的Dr调试寄存器

    硬件断点本质调用CPU的Dr0~7,8个调试寄存器。

    其相关属性如下图,其中Dr0~Dr3存储断点地址,Dr4~Dr5保存,Dr6~Dr7设置Dr0~Dr4相关寄存器的属性。

    因为断点地址只记录在Dr0~Dr3中,因此硬件断点最多只能记录四个。

    技术图片

  2)硬件断点的处理程序

    硬件断点如果被检测,则会走Trap01中断,触发0x80000004中断(软件断点为0x8000003中断),其派发如下图

     技术图片

  3)硬件断点的单步异常与TF位产生的单步异常区分

    硬件断点产生的是单步异常,通过TF位也会产生单步异常。(单步异常我们之后会讲)

    那操作系统到底如何区分其单步异常是如何产生的呢?答案是通过Dr6寄存器的有关属性(B0~B4)。

  4)代码写硬件断点的时机

    调用GetThreadContext()和SetThreadContext(),获取线程上下文和设置线程上下文来,然后对Dr寄存器进行有关设置。

    有一点需要注意的,在调用SetThreadContext(),应该暂停其他线程,否则可能出现设置错误。

 

8. 单步异常与单步步过

  1)单步异常:

    ①单步异常的实现:

      我们在使用调试器时肯定使用过单步异常(OD的F7),如果让我们来设置,肯定执行一行代码来设置软件断点或硬件断点。

      但是CPU在设计之初已经考虑过我们这个需求了,其Eflag.TF位就是用来标识的,CPU每运行一次代码,会检查该标志位。

      如果将其设置为1,其就会触发一次单步异常,走Trap01中断(与硬件断点的执行顺序是一样的)。

    ②单步异常的代码实现:

      先设置软件断点,将被调试线程断开,调用GetThreadContext()和SetThreadContext()来修改TF位后继续运行。

  2)单步步过

    ①单步步过的实现:

      单步步过是调试器编写者去实现,并不会像单步步入一样可以通过修改TF位实现。

      根据反汇编引擎动态计算,如果下一条指令是CALL类指令,则在其再下一条指令设置断点,然后运行。

      因此,通过硬件断点或软件断点都可以实现,自己有自己的思路就好。

    ②通过反调试干掉单步步过:

      根据单步步过的反调试思路,我们可以设置大量嵌套无用函数,在里面动态修改返回地址,最后并不会执行call函数的下一个地址,

      而单步步过在call下一个地址下断点,这样该程序就会跑飞,很好理解这种原理。

 

9.硬件HOOK

  其核心原理就是修改线程的Dr寄存器,然后再加入一个VEH异常处理函数。

  其中VEH是全局异常,我们在自己的进程添加,在其他线程也可以获取到。

  我们在VEH异常处理程序中先判断当前EIP是否是要hook的地址,如果是则执行hook代码,之后再还原进去,其实就是这个样子,很好理解。

 

软件调试

标签:ati   目的   也会   setevent   isp   lap   报告   key   guide   

原文地址:https://www.cnblogs.com/onetrainee/p/12627607.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!