标签: elf

是否可以使用程序集创建新的 ELF 可执行文件？我想制作一个“空”的可执行文件并在之后填充其代码部分。

我们有一个没有ELF头的Linux内核二进制文件,我们的引导加载程序将根据来自ELF头的计算加载内核映像(早期的QNX内核映像有ELF头),但由于我们的Linux内核映像没有一个ELF头,我们的引导加载程序拒绝将此内核映像加载到内存中.

由于某些原因,我们没有更改引导加载程序代码的选项,因此我们唯一的选择是将ELF标头插入具有特定入口点的Linux BIN文件中.

实现它的方法是什么？

我正在研究ELF文件格式,所以我编译了一个小程序,从生成的可执行文件中转储了节头及其内容.

ELF头包含入口点地址,该地址指向.text部分的开头.

我还发现包含静态数据的.data部分和包含只读数据的.rodata ...我希望堆栈也有一个部分,但我找不到该部分.

我也期望在某些时候ESP设置在某个部分的顶部,但我在反汇编中找不到类似的东西.

那么ESP如何获得其初始值？

我试图找到ELF文件的基地址.我知道您可以使用readelf查找程序入口点和不同的部分详细信息(基址,大小,标志等).

例如,x86体系结构的程序基于链接器的0x8048000.使用readelf我可以看到程序入口点,但输出中没有特定字段告诉基地址.

$ readelf -e test
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x8048390
  Start of program headers:          52 (bytes into file)
  Start of section headers:          4436 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes) …

在我的程序中,我想确定文件是否是ELF(可执行和可链接格式)类型.如何使用C语言函数识别文件是否是elf文件？

在装载机部分引用"连接器和装载机"

"加载时重定位比链接时重定位要简单得多,因为整个程序作为一个单元重新定位.[...]将程序读入内存后,加载程序查询目标文件中的重定位项并修复项目指向的记忆位置"

也许我误解了这一点,这只是在一些架构中,但我的问题是:在ELF格式中指定哪些项目需要在加载时重定位？我怎么查询这个清单？

我有以下选择

parser = OptionParser()
parser.add_option('-a', '--all', action='store_true', dest='all', help='writes all header information')
parser.add_option('-h', '--file-header', action='store_true', dest='head',  help='prints the elf file header information')
parser.add_option('-l', '--program-header', action='store_true', dest='prog',  help='prints the program header')
parser.add_option('-S', '--section-header', action='store_true', dest='sec',  help='prints the section header')

运行脚本时,我收到错误消息:

 optparse.OptionConflictError: option -h/--file-header: conflicting option string(s): -h

我知道通常-h是保留显示帮助.但我正在尝试为一些特殊的精灵文件编写一个ELF文件阅读器,因此我想使用相同的命令readelf.并且readelf使用-h来打印标题信息.

是否有可能在选项解析器中覆盖-h选项或者是否已修复？

问题场景:简单来说,我们是否有一个Trace32命令从加载到目标的ELF文件中读取符号(及其内容)？我们有这种特殊情况,其中ELF文件的特定于应用程序的调试符号是ELF中'.noload'部分的一部分,这意味着符号/内容是ELF文件的一部分(使用readelf -a xxxx读取时可用). elf_file_name)但不是生成的最终二进制图像的一部分,即ELF文件中的'.noload'部分在生成闪存到目标内存的xxx.bin时被剥离.

• ".noload"部分中的调试符号是静态分配的值,这些值在运行时不会更改.
• 当我尝试读取'.noload'部分的调试符号部分时(在编译成二进制文件并加载到Trace32之后),我在trace32弹出窗口中看到'MMU fail'标记,这意味着trace32正在尝试从内存中读取符号内容但是是不可访问的,因为'.noload'部分的符号部分根本没有加载,尽管它们已映射地址.

任何输入:
- 我需要一个trace32命令的帮助,该命令可以直接读取ELF文件中的符号内容而不是目标内存.
- 还不确定我是否可以在练习脚本中使用'readelf'？如果我们对上述查询没有任何解决方案,可以在这方面提供帮助吗？

我在64位linux机器上编译了以下程序:

#include <stdio.h>

main()
{
    int a = 12345;

    if (a == 12346)
        printf ("YES\n");

    return;
}

如果我使用hexdump输出二进制文件,我可以找到12346(十六进制为303a),但不能找到12345值(0x3039).这是为什么？

(小端或大端应该在找到该值时没有区别)

好吧，我已经在程序集中编写了一个引导加载程序，并尝试从中加载C内核。

这是引导程序：

bits 16
xor ax,ax
jmp 0x0000:boot

extern kernel_main

global boot
boot:
    mov ah, 0x02             ; load second stage to memory
    mov al, 1                ; numbers of sectors to read into memory
    mov dl, 0x80             ; sector read from fixed/usb disk ;0 for floppy; 0x80 for hd
    mov ch, 0                ; cylinder number
    mov dh, 0                ; head number
    mov cl, 2                ; sector number
    mov bx, 0x8000           ; load into es:bx segment :offset of buffer
    int 0x13                 ; …