聊一聊 .NET高级调试 中必知的符号表
一：背景1. 讲故事
在高级调试的旅行中，发现有不少人对符号表不是很清楚，其实简而言之符号表中记录着一些程序的生物特征，比如哪个地址是函数(签名信息)，哪个地址是全局变量，静态变量，行号是多少，数据类型是什么 等等，目的就是辅助我们可视化的调试，如果没有这些辅助我们看到的都是一些无意义的汇编代码，逆向起来会非常困难，这一篇我们就来系统的聊一聊。
二：程序编译的四个阶段
1. 案例代码
要想理解符号表，首先需要理解 代码文件 是如何变成 可执行文件 的，即如下的四个阶段。
[*]预处理阶段
[*]编译阶段
[*]汇编阶段
[*]链接阶段
为了能够看到每一个阶段，用 gcc 的相关命令手工推进，并用 chatgpt 写一段测试代码，包含全局变量，静态变量，函数等信息。
#include <stdio.h>
#define PI 3.1415926
int global_var = 10;
void func() {
static int static_var = 5;
printf("global_var = %d, static_var = %d PI=%f\n", global_var, static_var,PI);
global_var++;
static_var++;
}
int main() {
func();
func();
return 0;
}接下来用 gcc --help 命令查看下需要使用的命令列表。
# gcc --help
Usage: gcc file...
Options:
-E Preprocess only; do not compile, assemble or link
-S Compile only; do not assemble or link
-c Compile and assemble, but do not link
-o <file> Place the output into <file>
...2. 预编译阶段
预处理主要做的就是代码整合，比如将 #include 文件导入，将 #define 宏替换等等，接下来使用 gcc -E 进行预处理。
# gcc main.c -E -o main.i
# ls
main.cmain.i
可以看到这个 main.c 文件已经膨胀到了 858 行了。
3. 编译阶段
前面阶段是把代码预处理好，接下来就是将C代码编译成汇编代码了，使用 gcc -S 即可。
# gcc main.c -S -o main.s -masm=intel
# ls
main.cmain.imain.s
从图中可以看到汇编代码中也有很多辅助信息，比如 global_var 是一个 @object 变量，类型为 int，在 .rodata 只读数据段中，目的就是给汇编阶段打辅助。
4. 汇编阶段
有了汇编代码之后，接下来就是将 汇编代码 转成 机器代码，这个阶段会产生二进制文件，并且会构建 section 信息以及符号表信息，可以使用 gcc -c 即可。
# gcc main.c -c -o main.o -masm=intel
# ls
main.cmain.imain.omain.s二进制文件模式默认是不能可视化打开的，可以借助于 objdump 工具。
# objdump
-h, --headersDisplay the contents of the section headers
-t, --syms Display the contents of the symbol table(s)
# objdump -t main.o
main.o: file format elf64-x86-64
SYMBOL TABLE:
0000000000000000 l df *ABS* 0000000000000000 main.c
0000000000000000 l d.text 0000000000000000 .text
0000000000000000 l d.data 0000000000000000 .data
0000000000000000 l d.bss 0000000000000000 .bss
0000000000000000 l d.rodata 0000000000000000 .rodata
0000000000000004 l O .data 0000000000000004 static_var.2179
0000000000000000 l d.note.GNU-stack 0000000000000000 .note.GNU-stack
0000000000000000 l d.eh_frame 0000000000000000 .eh_frame
0000000000000000 l d.comment 0000000000000000 .comment
0000000000000000 g O .data 0000000000000004 global_var
0000000000000000 g F .text 0000000000000058 func
0000000000000000 *UND* 0000000000000000 printf
0000000000000058 g F .text 000000000000001f main在上面的符号表中看到了 func函数以及 static_var 和 global_var 以及所属的 section。
5. 链接阶段
这个阶段主要是将多个二进制代码文件进一步整合变成可在操作系统上运行的可执行文件，可以使用 gcc -o 。
# gcc main.c -o main
# ls
mainmain.cmain.imain.omain.s
# ./main
global_var = 10, static_var = 5 PI=3.141593
global_var = 11, static_var = 6 PI=3.141593
# objdump -t main
main: file format elf64-x86-64
SYMBOL TABLE:
...
0000000000601034 g O .data 0000000000000004 global_var
0000000000601034 g O .data 0000000000000004 global_var
...
000000000040052d g F .text 0000000000000058 func
...相比汇编阶段，这个阶段的 符号表 中的第一列都是有地址值的，是相对模块的偏移值，比如说： module+0x000000000040052d 标记的是 func 函数。
上面是 linux 上的可执行文件的符号表信息，有些朋友说我是 windows 平台上的，怎么看符号表信息呢？
三：Windows 上的 pdb 解析
1. 观察 pdb 文件
上一节我们看到的是 linux 上 elf格式 的可执行文件，这一节看下 windows 平台上的PE文件 的符号表信息是什么样的呢？有了前面四阶段编译的理论基础，再聊就比较简单了。
在 windows 平台上 符号表信息 是藏在 pdb 文件中的，这种拆开的方式是有很大好处的，如果需要调试代码，windbg 会自动加载 pdb 文件，无调试的情况下就不需要加载 pdb 了，减少了可执行文件的大小，也提升了性能。
接下来用 SymView.exe 这种工具去打开 pdb 文件，截图如下：
从图中可以看到，符号表信息高达 10968 个，并且 func 函数的入口地址是在 module +0x11870 处，相当于做了一个标记，接下来我们拿这个func做一个测试。
2. 有 pdb 的 func 函数
首先说一下为什么通过 exe 可以找到 pdb，这是因为 PE 头的 DIRECTORY_ENTRY_DEBUG 节中记录了 pdb 的地址。
只要这个路径有 pdb 就可以在 windbg 运行中按需加载了，然后通过 u MySample.exe+0x11870 观察，截图如下：
图中显示的非常清楚，地址 00fd1870 就是 func 的入口地址，让一个无意义的地址马上有意义起来了，哈哈~~~
3. 无 pdb 的 func 函数
这一小节是提供给好奇的朋友的，如果没有 pdb，那汇编上又是一个什么模样，为了找到 func 的入口地址，我们内嵌一个 int 3 ，然后把 pdb 给删掉，代码如下：
int main() {
__asm {
int 3;
}
func();
func();
return 0;
}
从图中可以看到，func 标记已经没有了，取而代之的都是 module+0xxx，这就会给我们逆向调试带来巨大的障碍。
三: 总结
总而言之，符号表就是对茫茫内存进行标记，就像百度地图一样，让我们知道某个经纬度上有什么建筑，让无情的地理坐标更加有温度，让世界更美好。
来源:https://www.cnblogs.com/huangxincheng/archive/2023/12/12/17897278.html
免责声明：由于采集信息均来自互联网，如果侵犯了您的权益，请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容，谢谢合作！
页:
[1]