gpt4 book ai didi

gdb - 核心转储注释部分

转载 作者:行者123 更新时间:2023-12-04 14:59:58 32 4
gpt4 key购买 nike

关注我关于 manually generating a core dump file 的问题,我决定潜入它并弄脏我的手。

我能够构建基本的核心转储结构,并将死程序的内存恢复到大 LOAD 部分内的核心转储中。在 GDB 中调试时,我的变量又回来了,没问题。
棘手的部分来了,我如何让 GDB 检索有关程序崩溃时所在位置的信息。

我知道核心转储的注释部分包含此信息(cpu 寄存器等)。这是 objdump -h 为“真实”核心转储提供的内容:

core.28339:     file format elf32-i386

Sections:
Idx Name Size VMA LMA File off Algn
0 note0 000001e8 00000000 00000000 000000f4 2**0
CONTENTS, READONLY
1 .reg/28339 00000044 00000000 00000000 00000150 2**2
CONTENTS
2 .reg 00000044 00000000 00000000 00000150 2**2
CONTENTS
3 .auxv 000000a0 00000000 00000000 0000023c 2**2
CONTENTS
4 load1a 00001000 08010000 00000000 00001000 2**12
CONTENTS, ALLOC, LOAD, READONLY, CODE
.. other load sections ...

感谢 readelf,我发现那些 .reg 部分包含从某些结构映射的数据:
Notes at offset 0x000000f4 with length 0x000001e8:
Owner Data size Description
CORE 0x00000090 NT_PRSTATUS (prstatus structure)
CORE 0x0000007c NT_PRPSINFO (prpsinfo structure)
CORE 0x000000a0 NT_AUXV (auxiliary vector)

有人可以指导我如何构建 Notes 部分吗?
我尝试将这些结构直接写入我的文件,但没有用,而且我显然在这里遗漏了一些东西。
我看了 Google Coredumper code并取了一些,但写注释部分并不是那么简单,欢迎任何关于它确切包含的内容及其格式的详细信息。

编辑 #1:遵循第一条评论

我发现我的 Elf 文件的结构如下:
  • Sprite 头 ElfW(Ehdr)
  • 程序头文件(Ehdr.e_phnum 乘以 ElfW(Phdr)),这里我基本上用了一个 PT_NOTE 和一个 PT_LOAD 头文件
  • 注意部分:
  • 部分的标题 (ElfW(Nhdr))
  • 部分名称(.n_namesz 长)
  • 节的数据(.n_descsz long)
  • 包含我所有程序内存的程序部分

  • 然后我将不得不放置 3 个笔记记录,一个用于 prstatus,一个用于 prpsinfo,另一个用于辅助向量。

    这似乎是正确的方法,因为 readelf 为我提供了与上面使用真实核心转储得到的输出类似的输出。

    编辑 #2 :获得正确的结构后

    我现在正在为组成笔记记录的不同结构而苦苦挣扎。

    这是我在核心转储上运行 eu-readelf --notes 时得到的结果:
    Note segment of 540 bytes at offset 0x74:
    Owner Data size Type
    CORE 336 PRSTATUS
    CORE 136 PRPSINFO
    CORE 8 AUXV
    NULL

    这是我在真实核心转储上运行相同命令时得到的结果:
    Note segment of 488 bytes at offset 0xf4:
    Owner Data size Type
    CORE 144 PRSTATUS
    info.si_signo: 11, info.si_code: 0, info.si_errno: 0, cursig: 11
    sigpend: <>
    sighold: <>
    pid: 28339, ppid: 41446, pgrp: 28339, sid: 41446
    utime: 0.000000, stime: 0.000000, cutime: 0.000000, cstime: 0.000000
    orig_eax: -1, fpvalid: 0
    ebx: -1 ecx: 0 edx: 0
    esi: 0 edi: 0 ebp: 0xffb9fcbc
    eax: -1 eip: 0x08014b26 eflags: 0x00010286
    esp: 0xffb9fcb4
    ds: 0x002b es: 0x002b fs: 0x0000 gs: 0x0000 cs: 0x0023 ss: 0x002b
    CORE 124 PRPSINFO
    state: 0, sname: R, zomb: 0, nice: 0, flag: 0x00400400
    uid: 9432, gid: 6246, pid: 28339, ppid: 41446, pgrp: 28339, sid: 41446
    fname: pikeos_app, psargs: ./pikeos_app
    CORE 160 AUXV
    SYSINFO: 0xf7768420
    SYSINFO_EHDR: 0xf7768000
    HWCAP: 0xbfebfbff <fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe>
    PAGESZ: 4096
    CLKTCK: 100
    PHDR: 0x8010034
    PHENT: 32
    PHNUM: 2
    BASE: 0
    FLAGS: 0
    ENTRY: 0x80100be
    UID: 9432
    EUID: 9432
    GID: 6246
    EGID: 6246
    SECURE: 0
    RANDOM: 0xffb9ffab
    EXECFN: 0xffba1feb
    PLATFORM: 0xffb9ffbb
    NULL

    有人对为什么我的笔记记录无法正确阅读有任何线索或解释吗?
    我认为这可能是由于偏移量不正确,但是为什么会正确列出记录?

    谢谢 !

    最佳答案

    前段时间在我将 CRIU 图像转换为核心转储的项目中遇到了同样的麻烦。它完全是用python编写的(即使 Sprite 结构也在ctypes中),因此可以用作指南。见 https://github.com/efiop/criu-coredump 。IE。在这里可以看到一切的结构https://github.com/efiop/criu-coredump/blob/master/criu_coredump/core_dump.py .

    关于gdb - 核心转储注释部分,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17972945/

    32 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com