gdb调试进入函数内部_Cisco ASA系列第三讲：调试Cisco ASA固件

 摘要: 

各位小伙伴们大家好，在Cisco ASA系列文章第二讲中，我们主要讲解了手动提取和重新打包Cisco ASA固件的常规方法。今天，我将和大家分享调试Cisco ASA固件文件的具体过程。

我们开发了一个小的工具框架，可使用GDB调试大多数Cisco ASA固件文件，同时支持真实的ASA设备和仿真设备(使用GNS3)。这些工具可以使我们自动启动设备上的特定固件，启动时在gdb中设置明确的断点，预加载某些分析工具等等。如果您对这些工具的感兴趣，可以直接跳转至本文结尾查看。

01

gdb调试

大多数固件已经包含gdbserver二进制文件。我们调试时需要考虑ASA是真实的还是仿真的。实际ASA和模拟ASA之间的主要区别需要通过gdb连接到的端口来区分。实际设备将使用串行端口进行调试，而GNS3实例将通过TCP / IP(远程登录)进行调试。

假设我们提取了第二讲中详细介绍的ASA固件，并且其进行了修补以便gdbserver在启动时进行连接。我们在启动时将会得到以下信息：

调试模拟的ASA

当我们启动gdb时，它会指示我们连接到lina可执行文件，并设置其依赖的库的路径。然后，我们连接到远程gdbserver：

$ gdb --quiet(gdb) file _asav941-200.qcow2.extracted/rootfs/asa/bin/linaReading symbols from _asav941-200.qcow2.extracted/rootfs/asa/bin/lina...(no debugging symbols found)...done.(gdb) set solib-absolute-prefix _asav941-200.qcow2.extracted/rootfs/(gdb) target remote 192.168.5.1:12005Remote debugging using 192.168.5.1:12005Reading symbols from _asav941-200.qcow2.extracted/rootfs/lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.0x0000003655201190 in ?? () from _asav941-200.qcow2.extracted/rootfs/lib64/ld-linux-x86-64.so.2

默认情况下，lina进程由于看门狗机制，不允许我们对其进行调试，并且会触发如下所示的信号：

(gdb) cContinuing.Thread 2 received signal SIG38, Real-time event 38.[Switching to Thread 1512]0x00000036556e7da7 in epoll_pwait () from _asav941-200.qcow2.extracted/rootfs/lib64/libc.so.6(gdb) cContinuing.Thread 8 received signal SIG38, Real-time event 38.[Switching to Thread 1513]0x00000036556e7da7 in epoll_pwait () from _asav941-200.qcow2.extracted/rootfs/lib64/libc.so.6

为了调试它并避免任何类似的触发信号，我们需要在启动前将内部固件变量clock_interval设置为零，然后再继续执行，如Exodus Intel [1]所述：

(gdb) set *0x03cc1d00 = 0(gdb) cContinuing.

02

IDA同步

我们在第二讲中说过，大多数ASA固件文件在lina中没有符号，这点在加载lina时在上面的gdb跟踪中得到了证实。我们使用ret-sync简化调试，ret-sync是将调试器(在我们的情况下为gdb)与IDA Pro进行同步的框架。我们添加了一些合并在主存储库中的功能[2]。

(gdb) source asa_sync.py [sync] HOST, PORT: 192.168.5.1, 9100[sync] BIN_NAME: asav941-200.qcow2[sync] MAPPING: [[4194304, 128455000, 124260696, 'asav941-200.qcow2|lina']][sync] commands added(gdb) sync[sync] Tunnel to IDA initializing...[sync] sync is now enabled with host 192.168.5.1[sync] pid: 200

我们在ret-sync中添加了一些gdb命令，例如：

• cc：继续到IDA Pro中的光标位置

• bbt：从IDA Pro请求符号后的beautiful backtrace

• patch：修补IDA中的一些字节以反映实时信息

bt和bbt之间的差异如下所示：

(gdb) bt#0 0x0000000000a91a73 in ?? ()#1 0x0000000000a6d994 in ?? ()#2 0x0000000000a89125 in ?? ()#3 0x0000000000a8a574 in ?? ()#4 0x000000000044f83b in ?? ()#5 0x0000000000000000 in ?? ()(gdb) bbt#0 0x0000000000a91a73 in IKE_GetAssembledPkt ()#1 0x0000000000a6d994 in catcher ()#2 0x0000000000a89125 in IKEProcessMsg ()#3 0x0000000000a8a574 in IkeDaemon ()#4 0x000000000044f83b in sub_44F7D0 ()#5 0x0000000000000000 in ()

虽然pwndbg [3]是一个能够增强gdb体验的优秀插件, 但我们决定不使用。问题是，由于我们是依靠串行线调试实际的硬件的，所以它的速度非常慢，pwndbg需要在内存中进行大量读/写操作以增强gdb体验，并添加所有额外的命令/输出。

03

寻找地址

 记录功能 

我们的分析最初集中在没有符号的ASA 9.2.4上。但是，正如Exodus Intel [1]指出的那样，您可以使用调试字符串和IDA Python脚本来重命名几个函数，这是分析嵌入式固件时的常用方式。您需要确定日志记录功能的所有交叉引用，并找到调试字符串参数。尽管该字符串不会您提供所有功能，但它通常会遵循某种调用函数的模式。