控制进程执行

实现目标：continue运行到下个断点

运行到下个断点处，可以理解为一系列的singlestep操作，直到判断PC处对应的指令为0xCC为止，然后再singlestep一次。

但是不用这么麻烦，操作系统提供了ptrace(PTRACE_COND,...)操作，允许我们直接运行到下个断点处。但是在执行上述调用前，同样要检查下当前PC-1地址处的数据是否为0xCC，如果是则需要将其替换为原始指令数据。

代码实现

continue命令执行时，首先检查当前PC-1处数据是否为0xCC，如果是则说明这里之前是个多字节指令，但是被指令patch添加了断点，需要还原回原始数据。

然后，我们再执行PTRACE_COND操作请求操作系统恢复执行被调试进程，进程运行到断点处停下来。

最后，我们通过wait等待并检查下被调试进程停下来，然后输出当前PC值。注意当前PC值是执行了0xCC指令之后的值，因此PC=断点地址+1。

file: cmd/debug/continue.go

package debug

import (
    "fmt"
    "syscall"

    "github.com/spf13/cobra"
)

var continueCmd = &cobra.Command{
    Use:   "continue",
    Short: "运行到下个断点",
    Annotations: map[string]string{
        cmdGroupKey: cmdGroupCtrlFlow,
    },
    Aliases: []string{"c"},
    RunE: func(cmd *cobra.Command, args []string) error {
        fmt.Println("continue")

        // 读取PC值
        regs := syscall.PtraceRegs{}
        err := syscall.PtraceGetRegs(TraceePID, &regs)
        if err != nil {
            return fmt.Errorf("get regs error: %v", err)
        }

        buf := make([]byte, 1)
        n, err := syscall.PtracePeekText(TraceePID, uintptr(regs.PC()-1), buf)
        if err != nil || n != 1 {
            return fmt.Errorf("peek text error: %v, bytes: %d", err, n)
        }

        // read a breakpoint
        if buf[0] == 0xCC {
            regs.SetPC(regs.PC() - 1)
            // TODO refactor breakpoint.Disable()/Enable() methods
            orig := breakpoints[uintptr(regs.PC())].Orig
            n, err := syscall.PtracePokeText(TraceePID, uintptr(regs.PC()), []byte{orig})
            if err != nil || n != 1 {
                return fmt.Errorf("poke text error: %v, bytes: %d", err, n)
            }
        }

        err = syscall.PtraceCont(TraceePID, 0)
        if err != nil {
            return fmt.Errorf("single step error: %v", err)
        }

        // MUST: 当发起了某些对tracee执行控制的ptrace request之后，要调用syscall.Wait等待并获取tracee状态变化
        var wstatus syscall.WaitStatus
        var rusage syscall.Rusage
        _, err = syscall.Wait4(TraceePID, &wstatus, syscall.WALL, &rusage)
        if err != nil {
            return fmt.Errorf("wait error: %v", err)
        }

        // display current pc
        regs = syscall.PtraceRegs{}
        err = syscall.PtraceGetRegs(TraceePID, &regs)
        if err != nil {
            return fmt.Errorf("get regs error: %v", err)
        }
        fmt.Printf("continue ok, current PC: %#x\n", regs.PC())
        return nil
    },
}

func init() {
    debugRootCmd.AddCommand(continueCmd)
}

在cmd/debug/step.go的基础上简单修改下就可以实现continue操作，详见源文件cmd/debug/continue.go。

代码测试

首先启动一个进程，获取其pid，然后通过godbg attach <pid>对目标进程进行调试，等调试会话就绪后，我们输入dis（dis是disass命令的别名）进行反汇编。

要验证continue命令的功能，首先要dis反汇编查看指令地址，然后再break添加断点，然后再continue运行到断点。

需要注意的是，添加断点时要简单看下汇编指令的含义，因为考虑到代码执行时的分支控制逻辑，我们添加的断点并不一定在代码实际的执行路径上，所以可能不能验证continue运行到断点的功能（但是仍然可以验证运行到进程执行结束）。

为了验证运行到下个断点，我多次运行dis、step，直到发现有一段指令可以连续执行，中间没有什么跳转操作，如下图所示：

godbg> dis
...
godbg> dis
...
godbg> dis
0x42e2e0 cmp $-0x4,%eax                 ; 从这条语句开始执行
0x42e2e3 jne 0x24c
0x42e2e9 mov 0x20(%rsp),%eax
0x42e2ed test %eax,%eax                 ; 首字节被覆盖成0xCC，PC=0x42e2ed+1
0x42e2ef jle 0xffffffffffffffbe
0x42e2f1 movq $0x0,0x660(%rsp)
0x42e2fd mov 0x648(%rsp),%rbp
0x42e305 add $0x650,%rsp
0x42e30c retq
0x42e30d movq $0x0,0x30(%rsp)
godbg>

然后我们尝试break添加断点、continue运行到断点：

godbg> b 0x42e2ed
break 0x42e2ed
添加断点成功
godbg> c
continue
continue ok, current PC: 0x42e2ee

我们在第4条指令0x42e2ed test %eax,%eax处添加断点，断点添加成功后，我们执行c(c是continue的别名）来运行到断点处。运行到断点之后，输出当前的PC值，前面有分析过，PC=0x42e2ee=0x42e2ed+1，因为被调试进程是在执行了0x42e2ed处的指令0xCC才停下来的，完全符合预期。

更多相关内容

continue命令有多重要？相当重要，特别是对于符号级调试器而言。

源代码向汇编指令的转换过程中，一条源代码语句可能对应着多条机器指令，当我们：

  • 逐语句执行时；
  • 进入、退出一个函数时（函数有prologue、epilogue）；
  • 进入、退出一个循环体时；
  • 等等；

要实现上述源码级调试就必须要借助对源码及指令的理解，恰到好处的在正确的地址处设置断点，然后配合continue来实现。

我们将在符号级调试器一章中更详细地研究这些内容。

results matching ""

    No results matching ""