在 x86 上使用 GDB 而不调试符号？
如何使用 GDB 在 32 位 x86 处理器上调试没有调试符号的程序？ 检查函数参数、局部变量、解析指针对于了解如何操作非常有用。 其目的并不是真正将其用于逆向工程，因为我有时懒得安装调试符号，并且很高兴知道如何从 gdb 中获取一些基本信息。
How do I use GDB to debug a program which do not have debugging symbols on a 32-bit x86 processor? Inspecting the function arguments, local variables, resolving pointers would be useful to know how to do.
The intention is not really to use this for reverse engineering, as I'm sometimes just too lazy to install the debugging symbols and would be great to know how to get some basic information out of gdb.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
首先，你可以这样做；
这将在 libc 的 crt0 代码中设置一个断点，并允许您在 main 之前中断，即使目标二进制文件已被完全删除。
这将使您在大多数用户代码之前进入断点处的运行状态。 然后，您可以随心所欲地单步执行、反汇编、转储内存等。
这适用于所有平台，您询问 IA-32 / x86 的事实并不重要。
To start out, you can do;
that will setup a breakpoint in libc's crt0 code and allow you to break before main, even if the target binary is totally stripped.
That will get you to a running state at a breakpoint before most user code. You can then single step, dissasemble, dump memory etc... to your heart's content.
This works on all platforms, the fact your asking about IA-32 / x86 does not matter.
如果没有调试符号，则只能在 ASM 级别进行调试。 好吧，您会获得更多一点信息，但是除非您了解一点 ASM 和编译器生成的代码，否则您不会走得太远。 如果您知道自己在做什么，这将使您可以对局部变量等进行简单的检查。
如果您有源代码，那么重新编译它就会容易得多。
Without debugging symbols, you can only debug at the ASM level. Ok you get a bit more information, but you're not going to get very far unless you understand a bit of ASM and the code the compiler generates. This will let you do a simple inspection of local variables etc if you know what you're doing.
If you have the source, it's going to be far easier just to recompile it.
您所能做的就是查看寄存器和堆栈的内容 - 您必须通过推断事物的用途来完成所有操作，正如 Draemon 提到的那样。
All you can do is look at registers and the contents of the stack - you'll have to do everything by inferring what things are used for, as Draemon mentions.
嗯，绝对最重要的是您能够展开堆栈。 可通过三种方式确保这一点：
使用
-g构建调试符号在执行 C++ 的系统上通过表展开异常（现在可能有任何ELF？），
-funwind-tables标志将告诉它生成这样的表，无论语言如何，并且 GDB 可以使用这些表（至少，对于 x86 linux 可以）。或者，如果失败，至少确保
-fomit-frame-pointer未启用Well, the absolutely most important thing is that you be able to unwind the stack. There are three ways this can be ensured:
Build debugging symbols with
-gOn systems that do C++ exception unwinding via tables (probably anything ELF these days?), the
-funwind-tablesflag will tell it to generate such tables regardless of language, and GDB can use these tables (at least, with x86 linux it can).Or, failing those, at least make sure that
-fomit-frame-pointerisn't enabled