Linux中Time Travel Debugging (TTD)

admin 2024年9月21日22:43:49评论5 views字数 5059阅读16分51秒阅读模式
创建: 2024-09-14 16:54
更新: 2024-09-19 12:14
https://scz.617.cn/unix/202409141654.txt
目录:

    ☆ 背景介绍
    ☆ 测试用例
    ☆ GDB原生反向执行
    ☆ rr
        1) 编译rr源码
        2) 检查rr可用性
        3) 测试rr
    ☆ UDB
    ☆ 讨论

☆ 背景介绍

Windows有相当成熟的Time Travel Debugging (TTD)工具,Linux也有类似的,比如rr、UDB等。但GDB原生反向执行算不得TTD,不能脱离目标进程存在,不能反复鞭尸。

本文以同一个测试用例简单演示这三种技术,它们的共同点是,反向执行相关命令几乎一样,尽管实现原理并不相同。

本文假设读者具有GDB调试基础,未做任何前置科普。

☆ 测试用例

这是Frank Tetzel提供的一个测试用例:

int main int argc, char * argv[] )
{
    unsigned int    array[32];
    unsigned int    i;

    for ( i = 0; i < sizeof(array); i++ )
    {
        array[i]    = i;
    }
    return 0;
}
$ gcc -static -Wall -pipe -O0 -g3 -fno-stack-protector -o testcase_0_dbg testcase_0.c

编译时指定-O0,以免优化for循环,指定-fno-stack-protector,刻意破坏RetAddr。

$ ./testcase_0_dbg
Segmentation fault (core dumped)

☆ GDB原生反向执行

gdb -q -nx ./testcase_0_dbg

(gdb) start
(gdb) record
(gdb) c
Continuing.
Process recordfailed to record execution log.

Program stopped.
0x0000002700000026 in ?? ()

本例在start处执行record,开始录制,调试实际目标时,可在任意关注的位置开始record。

(gdb) info record
Active record target: record-full
Record mode:
Lowest recorded instruction number is 1.
Highest recorded instruction number is 775.
Log contains 775 instructions.
Max logged instructions is 200000.

记录了775条指令,若从此处反向执行,将从"Record mode"切换至"Replay mode",可用"info record"查看。

栈中RetAddr被写成0x2700000026

(gdb) x/1gx $rsp-8
0x7fffffffe0f8: 0x0000002700000026

先禁用硬件数据断点,再对之设数据断点,反向执行,找出谁写的:

(gdb) set can-use-hw-watchpoints 0
(gdb) watch *0x7fffffffe0f8

缺省情况下,数据断点用硬件断点。但"Replay mode"中无论正向执行、反向执行,硬件数据断点均不工作,设也白设。正确做法是,先禁用硬件数据断点,再设数据断点,如上。

开始反向执行:

(gdb) rc

Watchpoint 2: *0x7fffffffe0f8

Old value = 38
New value = 4201402
0x000000000040176d in main (argc=1, argv=0x7fffffffe2c8) at testcase_0.c:15
15              array[i]    
= i;

找到修改RetAddr的代码,查看i变量:

(gdb) i locals i
i = 38

局部变量i预期最大32,现已38,源代码有问题

(gdb) x/1gx &array[i]
0x7fffffffe0f80x0000000000401bba

这是RetAddr所在,RetAddr应为0x401bba

☆ rr

1) 编译rr源码

在Ubuntu 22中执行:

apt-get install ccache cmake make g++-multilib gdb 
pkg-config coreutils python3-pexpect manpages-dev git 
ninja-build capnproto libcapnp-dev zlib1g-dev
git clone https://github.com/rr-debugger/rr.git rr
mkdir rrobj && cd rrobj
cmake -DCMAKE_BUILD_TYPE=Release ../rr
make -j8
ls -l ./bin/rr
./bin/rr help

2) 检查rr可用性

若在虚拟机中使用rr,有必要检查rr可用性,检查Guest环境是否符合要求。

要求Guest内核版本大于等于4.7,用"uname -r"确认。以root身份执行

perf stat -e br_inst_retired.conditional true |& grep br_inst_retired

若br_inst_retired为0,表示Guest环境不符合要求。

3) 测试rr

针对testcase_0_dbg进行录制:

$ _RR_TRACE_DIR=/tmp /path/rrobj/bin/rr record ./testcase_0_dbg
rr: Saving execution to trace directory `/tmp/testcase_0_dbg-0'.
Segmentation fault

上述命令相当于Windows的TTD.exe或tttracer.exe。

调试rr录制结果:

$ /path/rrobj/bin/rr replay /tmp/testcase_0_dbg-0

0x0000000000401620 in _start ()
(rr) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x0000002700000026 in ?? ()

(rr) x/1gx $rsp-8
0x7ffcca701928: 0x0000002700000026
(rr) set can-use-hw-watchpoints 0
(rr) watch *0x7ffcca701928
(rr) rc (一次rc)
(rr) rc (二次rc)
Continuing.

Watchpoint 1: *0x7ffcca701928

Old value = 38
New value = 4201402
0x000000000040176d in main (argc=1, argv=0x7ffcca701b08at testcase_0.c:15
15              array[i]    = i;
(rr) i locals i
i = 38
(rr) p/x &array[i]
$1 = 0x7ffcca701928
(rr) x/1gx &array[i]
0x7ffcca701928: 0x0000000000401bba

相比GDB原生反向执行,rr的优势是可保存录制结果,可反复鞭尸。但就本例而言,rr没有优势,比GDB原生反向执行慢。

☆ UDB

参看

https://undo.io/udb-free-trial
/path/UDB/Undo-Suite-x86-8.0.0/live-record 
-q 
--tmpdir-root /tmp 
--disable-aslr 
--record-on entry 
--save-on always 
-o /path/testcase/0/testcase_0_dbg.record 
/path/testcase/0/testcase_0_dbg

上述命令相当于Windows的TTD.exe或tttracer.exe。复杂目标的录制结果可能很大,应指定适当的--tmpdir-root与-o参数。

UDB与rr、TTD.exe有个不同,既可用live-record直接录制,也可在调试过程中用"urecord+usave"录制保存,后一种方式可针对某个区段精确录制,此处未演示。

/path/UDB/Undo-Suite-x86-8.0.0/udb 
-q 
--checkupdates never 
--keyfile /path/UDB/Undo-Suite-x86-8.0.0/key 
--tmpdir-root /tmp 
-nx 
-ex "set history save off" 
--sessions no 
--load /path/testcase/0/testcase_0_dbg.record
0x0000000000401620 in _start ()

The debugged program is at the beginning of recorded history. Start debugging
from here orto proceed towards the enduse:
    continue - to replay from the beginning
    ugo end  - to jump straight to the end of history
start 1> ugo end
0x0000002700000026 in ?? ()
end 3,874> x/1gx $rsp-8
0x7fffffffdfc80x0000002700000026

UDB有个last命令,跳至指定表达式最后一次变动的代码所在:

end 3,874> last *0x7fffffffdfc8
Searching backward for changes to 0x7fffffffdfc8-0x7fffffffdfcc for the
expression:
  *0x7fffffffdfc8

Was = 38
Now = 4201402
0x000000000040176d in main (argc=1, argv=0x7fffffffe1a8) at testcase_0.c:15
15              array[i]    = i;
973,784> i locals i
i = 38

last命令省了"watch+rc",一步到位。

UDB也可像GDB、rr那样,watch+rc,此处未演示。与GDB原生反向执行及rr不同,UDB反向执行前设置数据断点,不必先禁用硬件数据断点,这与UDB实现方式相关。

☆ 讨论

UDB用JIT技术执行目标代码,rr用CPU性能计数器。UDB兼容性好、依赖少、适用场景多。rr对CPU有要求,虚拟机中很容易碰上幺蛾子,限制了适用场景。

UDB官方文档提及一个限制:

Modifying instructions and executing them immediately (without an intervening branch or system call) is not supported.

不太确定它所谓的"Self-modifying code"与我们常见的"壳"、shellcode等等是何关系。我们用UDB,不只是常规软件排错,更可能分析恶意代码。测过一些场景,有些壳可以录制,有些壳录制时崩溃。我的测试中,UDB录制失败的,rr同样录制失败,UDB录制成功的,rr同样录制成功。但是,网友CZW用UDB分析2024年3月底的xz/liblzma后门,那次rr失败了。优先推荐UDB。

原文始发于微信公众号(青衣十三楼飞花堂):Linux中Time Travel Debugging (TTD)

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2024年9月21日22:43:49
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   Linux中Time Travel Debugging (TTD)https://cn-sec.com/archives/3186295.html

发表评论

匿名网友 填写信息