经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置:技术经验 » 程序设计 » ASP.net » 查看文章
聊一聊 .NET高级调试 中必知的符号表
来源:cnblogs  作者:一线码农  时间:2023/12/13 9:10:17  对本文有异议

一:背景

1. 讲故事

在高级调试的旅行中,发现有不少人对符号表不是很清楚,其实简而言之符号表中记录着一些程序的生物特征,比如哪个地址是函数(签名信息),哪个地址是全局变量,静态变量,行号是多少,数据类型是什么 等等,目的就是辅助我们可视化的调试,如果没有这些辅助我们看到的都是一些无意义的汇编代码,逆向起来会非常困难,这一篇我们就来系统的聊一聊。

二:程序编译的四个阶段

1. 案例代码

要想理解符号表,首先需要理解 代码文件 是如何变成 可执行文件 的,即如下的四个阶段。

  • 预处理阶段
  • 编译阶段
  • 汇编阶段
  • 链接阶段

为了能够看到每一个阶段,用 gcc 的相关命令手工推进,并用 chatgpt 写一段测试代码,包含全局变量,静态变量,函数等信息。

  1. #include <stdio.h>
  2. #define PI 3.1415926
  3. int global_var = 10;
  4. void func() {
  5. static int static_var = 5;
  6. printf("global_var = %d, static_var = %d PI=%f\n", global_var, static_var,PI);
  7. global_var++;
  8. static_var++;
  9. }
  10. int main() {
  11. func();
  12. func();
  13. return 0;
  14. }

接下来用 gcc --help 命令查看下需要使用的命令列表。

  1. [root@localhost data]# gcc --help
  2. Usage: gcc [options] file...
  3. Options:
  4. -E Preprocess only; do not compile, assemble or link
  5. -S Compile only; do not assemble or link
  6. -c Compile and assemble, but do not link
  7. -o <file> Place the output into <file>
  8. ...

2. 预编译阶段

预处理主要做的就是代码整合,比如将 #include 文件导入,将 #define 宏替换等等,接下来使用 gcc -E 进行预处理。

  1. [root@localhost data]# gcc main.c -E -o main.i
  2. [root@localhost data]# ls
  3. main.c main.i

可以看到这个 main.c 文件已经膨胀到了 858 行了。

3. 编译阶段

前面阶段是把代码预处理好,接下来就是将C代码编译成汇编代码了,使用 gcc -S 即可。

  1. [root@localhost data]# gcc main.c -S -o main.s -masm=intel
  2. [root@localhost data]# ls
  3. main.c main.i main.s

从图中可以看到汇编代码中也有很多辅助信息,比如 global_var 是一个 @object 变量,类型为 int,在 .rodata 只读数据段中,目的就是给汇编阶段打辅助。

4. 汇编阶段

有了汇编代码之后,接下来就是将 汇编代码 转成 机器代码,这个阶段会产生二进制文件,并且会构建 section 信息以及符号表信息,可以使用 gcc -c 即可。

  1. [root@localhost data]# gcc main.c -c -o main.o -masm=intel
  2. [root@localhost data]# ls
  3. main.c main.i main.o main.s

二进制文件模式默认是不能可视化打开的,可以借助于 objdump 工具。

  1. [root@localhost data]# objdump
  2. -h, --[section-]headers Display the contents of the section headers
  3. -t, --syms Display the contents of the symbol table(s)
  4. [root@localhost data]# objdump -t main.o
  5. main.o: file format elf64-x86-64
  6. SYMBOL TABLE:
  7. 0000000000000000 l df *ABS* 0000000000000000 main.c
  8. 0000000000000000 l d .text 0000000000000000 .text
  9. 0000000000000000 l d .data 0000000000000000 .data
  10. 0000000000000000 l d .bss 0000000000000000 .bss
  11. 0000000000000000 l d .rodata 0000000000000000 .rodata
  12. 0000000000000004 l O .data 0000000000000004 static_var.2179
  13. 0000000000000000 l d .note.GNU-stack 0000000000000000 .note.GNU-stack
  14. 0000000000000000 l d .eh_frame 0000000000000000 .eh_frame
  15. 0000000000000000 l d .comment 0000000000000000 .comment
  16. 0000000000000000 g O .data 0000000000000004 global_var
  17. 0000000000000000 g F .text 0000000000000058 func
  18. 0000000000000000 *UND* 0000000000000000 printf
  19. 0000000000000058 g F .text 000000000000001f main

在上面的符号表中看到了 func函数以及 static_varglobal_var 以及所属的 section。

5. 链接阶段

这个阶段主要是将多个二进制代码文件进一步整合变成可在操作系统上运行的可执行文件,可以使用 gcc -o

  1. [root@localhost data]# gcc main.c -o main
  2. [root@localhost data]# ls
  3. main main.c main.i main.o main.s
  4. [root@localhost data]# ./main
  5. global_var = 10, static_var = 5 PI=3.141593
  6. global_var = 11, static_var = 6 PI=3.141593
  7. [root@localhost data]# objdump -t main
  8. main: file format elf64-x86-64
  9. SYMBOL TABLE:
  10. ...
  11. 0000000000601034 g O .data 0000000000000004 global_var
  12. 0000000000601034 g O .data 0000000000000004 global_var
  13. ...
  14. 000000000040052d g F .text 0000000000000058 func
  15. ...

相比汇编阶段,这个阶段的 符号表 中的第一列都是有地址值的,是相对模块的偏移值,比如说: 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 给删掉,代码如下:

  1. int main() {
  2. __asm {
  3. int 3;
  4. }
  5. func();
  6. func();
  7. return 0;
  8. }

从图中可以看到,func 标记已经没有了,取而代之的都是 module+0xxx,这就会给我们逆向调试带来巨大的障碍。

三: 总结

总而言之,符号表就是对茫茫内存进行标记,就像百度地图一样,让我们知道某个经纬度上有什么建筑,让无情的地理坐标更加有温度,让世界更美好。

图片名称

原文链接:https://www.cnblogs.com/huangxincheng/p/17897278.html

 友情链接:直通硅谷  点职佳  北美留学生论坛

本站QQ群:前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

W3xue 的所有内容仅供测试,对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接(目前9元/月)请联系QQ:27243702 沸活量
皖ICP备17017327号-2 皖公网安备34020702000426号