调试由启用 ASLR 的系统生成的 coredump

发布于 2025-01-18 02:09:02 字数 768 浏览 3 评论 0原文

我的生产中有一个从远程目标中提取的核心。由于目标缺少GDB服务器,因此我需要在自己的计算机上进行调试。在本地,我有相应的工具,调试符号和源代码。

问题是,当我将此核心加载到GDB中时,最多(如果不是全部)无法解决地址和符号:

#15 0x00007ffc78fd87a0 in ?? ()
#16 0x0000000002147bb0 in ?? ()
#17 0x00007ffc78fd8740 in ?? ()
#18 0x0000000000000006 in ?? ()
#19 0x0000332d70667351 in ?? ()
#20 0x00000000021612a0 in ?? ()
#21 0x00007ffc78fd8760 in ?? ()
#22 0x0000000000000006 in ?? ()
#23 0x0000332d70667351 in ?? ()
#24 0x00000000021612a0 in ?? ()
#25 0x0000000000000012 in ?? ()
#26 0x00000000021468e0 in ?? ()

如果我将应用程序的某些模块重新编译,则使用-no-pie -fno-pie-pie,该精确模块的帧可用。但是,这不是一个选择。目标是生产,需要启用此安全功能。

我的主要目标是在另一台计算机中以某种方式调试此系统,因为我唯一会从崩溃中遇到的是我可以提取的核心。有什么办法解决的吗?我想念什么吗?也许,在应用程序运行到Coredump时使用的确切内存偏移的某种方式; GDB将以某种方式阅读。

I have a coredump extracted from a remote target in production. I need to debug it on my own computer since the target lacks gdb-server. Locally, I have the corresponding tooling, debug symbols and source code.

The problem is that when I load this core into gdb most, if not all, addresses and symbols are not resolved:

#15 0x00007ffc78fd87a0 in ?? ()
#16 0x0000000002147bb0 in ?? ()
#17 0x00007ffc78fd8740 in ?? ()
#18 0x0000000000000006 in ?? ()
#19 0x0000332d70667351 in ?? ()
#20 0x00000000021612a0 in ?? ()
#21 0x00007ffc78fd8760 in ?? ()
#22 0x0000000000000006 in ?? ()
#23 0x0000332d70667351 in ?? ()
#24 0x00000000021612a0 in ?? ()
#25 0x0000000000000012 in ?? ()
#26 0x00000000021468e0 in ?? ()

If I recompile some module of the application with -no-pie -fno-PIE, the frames for that exact module become available. However, that is not an option. The target is in production and needs this security feature enabled.

My main goal is to have some way of debugging this system post-mortem in another computer since the only thing I'll have from a crash is a coredump that I can extract. Is there any way around this? Am I missing something? Perhaps, some way of embedding the exact memory offsets that were used when the application was running to the coredump; in a way that gdb will read.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

_蜘蛛 2025-01-25 02:09:02

两天后,我才弄清楚了。新秀错误。

我在应用程序的.DEBUG版本上而不是应用程序本身呼叫GDB:

$ cd ~/sysroot
$ x86_64-linux-gdb usr/bin/.debug/app -c <path_to_dump>

而不是:

$ cd ~/sysroot
x86_64-linux-gdb usr/bin/app -c <path_to_dump>

过去2天,我一直从Bash历史记录中重复使用该命令,这给了我一个假阳性。我纠正了它,所有符号都显示。

After two days and I've just figured it out. A rookie mistake.

I was calling gdb on the .debug version of the app instead of the app itself:

$ cd ~/sysroot
$ x86_64-linux-gdb usr/bin/.debug/app -c <path_to_dump>

instead of:

$ cd ~/sysroot
x86_64-linux-gdb usr/bin/app -c <path_to_dump>

I've been reusing that command from bash history for the past 2 days and it was giving me a false positive. I corrected it and all symbols show up.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文