ELF entry point和装载地址

简介: 为了研究ELF文件装载到内存的哪里,以及从哪里开始运行程序,环境:ubuntu12.04 64位,gcc4.6.3。 使用的源代码是: #include void hello(void){ exit(42);}int mai...

为了研究ELF文件装载到内存的哪里,以及从哪里开始运行程序,环境:ubuntu12.04 64位,gcc4.6.3。

使用的源代码是:

#include <stdlib.h>

void hello(void)
{
        exit(42);
}

int main(void)
{
        return 24;
}

程序并不是从main函数开始执行的,gcc -o main main.c时,默认会连接libc.so(可以指定-nodefaultlib, -nostdlib取消连接),并且会添加一个启动代码_start函数(可以指定-nodefaultlib, -nostdlib不添加启动代码),用于初始化,并提供main函数的argc, argv等参数,_start函数中会调用main函数。

readelf -d main可以看到,程序链接了libc.so.6:

$ readelf -d main

Dynamic section at offset 0xe50 contains 20 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x400390
 0x000000000000000d (FINI)               0x4005c8

objdump -d main可以看到,程序中有个_start函数,_start的地址是4003d0:

$ objdump -d main | grep _start
  400394:	e8 63 00 00 00       	callq  4003fc <call_gmon_start>
00000000004003b0 <__libc_start_main@plt-0x10>:
00000000004003c0 <__libc_start_main@plt>:
00000000004003d0 <_start>:
  4003f4:	e8 c7 ff ff ff       	callq  4003c0 <__libc_start_main@plt>
readelf -h main | grep Entry可以看到:

  Entry point address:               0x4003d0
程序的入口地址是0x4003d0,也就是_start函数的地址,程序装载到内存后,从0x4003d0(_start)开始执行。


那么,我不想执行_start函数呢,可以通过ld的参数-e指定入口函数,使用gcc -o main mian.c -Wl,-ehello编译,-Wl用于指定后面的参数是给ld的,-e指定入口函数是hello。

注意hello不能直接return,因为返回地址是错误的,会导致coredump;hello应当使用exit()函数退出程序。./main得到:

$ ./main
$ echo $?
42
objdump -d main | grep hello查看hello的地址:

$ objdump -d main | grep hello
00000000004004f4 <hello>:
readelf -h main | grep Entry查看程序的入口地址:

$ readelf -h main | grep Entry
  Entry point address:               0x4004f4
证明了-Wl,-ehello可以指定程序的入口函数为hello。



那么程序的入口地址0x4004f4是怎么来的呢?

0x4f4其实是hello函数在ELF文件中的偏移量,可以通过hexdump -C main | grep -A5 -B5 4f0查看到

$ hexdump -C main | grep -A5 -B5 4f0
000004a0  0b 20 00 ff 14 c5 38 0e  60 00 48 8b 05 77 0b 20  |. ....8.`.H..w. |
000004b0  00 48 39 d8 72 e2 c6 05  63 0b 20 00 01 48 83 c4  |.H9.r...c. ..H..|
000004c0  08 5b 5d c3 66 66 66 2e  0f 1f 84 00 00 00 00 00  |.[].fff.........|
000004d0  48 83 3d 70 09 20 00 00  55 48 89 e5 74 12 b8 00  |H.=p. ..UH..t...|
000004e0  00 00 00 48 85 c0 74 08  5d bf 48 0e 60 00 ff e0  |...H..t.].H.`...|
000004f0  5d c3 90 90 <span style="color:#ff0000;">55 48 89 e5  bf 2a 00 00 00 e8 fe fe</span>  |]...UH...*......|
00000500  <span style="color:#ff0000;">ff ff</span> 55 48 89 e5 b8 18  00 00 00 5d c3 90 90 90  |..UH.......]....|
00000510  48 89 6c 24 d8 4c 89 64  24 e0 48 8d 2d 03 09 20  |H.l$.L.d$.H.-.. |
00000520  00 4c 8d 25 fc 08 20 00  4c 89 6c 24 e8 4c 89 74  |.L.%.. .L.l$.L.t|
00000530  24 f0 4c 89 7c 24 f8 48  89 5c 24 d0 48 83 ec 38  |$.L.|$.H.\$.H..8|
00000540  4c 29 e5 41 89 fd 49 89  f6 48 c1 fd 03 49 89 d7  |L).A..I..H...I..|
然后objdump -d main | grep -A5 -B5 hello查看hello对应的机器码:

$ objdump -d main | grep -A5 -B5 hello
  4004f0:	5d                   	pop    %rbp
  4004f1:	c3                   	retq
  4004f2:	90                   	nop
  4004f3:	90                   	nop

00000000004004f4 <hello>:
  4004f4:	<span style="color:#ff0000;">55</span>                   	push   %rbp
  4004f5:	<span style="color:#ff0000;">48 89 e5</span>             	mov    %rsp,%rbp
  4004f8:	<span style="color:#ff0000;">bf 2a 00 00 00</span>       	mov    $0x2a,%edi
  4004fd:	<span style="color:#ff0000;">e8 fe fe ff ff</span>       	callq  400400 <exit@plt>
证明了这一点。

然后0x400000是什么呢?

这个是ELF装载到内存时的起始位置,可以通过ld的参数-Wl,-Ttext-segment,0x400000指定,比如我们gcc -o main main.c -Wl,-ehello -Wl,-Ttext-segment,0x4200000编译程序,给程序换一个装载地址,然后readelf -h main | grep Entry得到:

Entry point address:               0x42004f4

hello在文件中的偏移依然为0x4f4,然后加上装载地址0x4200000就可以得到程序执行的入口地址:0x42004f4。

objdump -d main | grep hello -A 10可以看到装载地址变了,程序的PC指针位置也都改变了(因为我们编译的main是地址相关的ELF):

$ objdump -d main | grep hello -A 10
00000000042004f4 <hello>:
 <span style="color:#ff0000;background-color: rgb(204, 204, 204);">42004f4</span>:	55                   	push   %rbp
 <span style="color:#ff0000;">42004f5</span>:	48 89 e5             	mov    %rsp,%rbp
 <span style="color:#ff0000;">42004f8</span>:	bf 2a 00 00 00       	mov    $0x2a,%edi
 <span style="color:#ff0000;">42004fd</span>:	e8 fe fe ff ff       	callq  4200400 <exit@plt>

0000000004200502 <main>:
 4200502:	55                   	push   %rbp
 4200503:	48 89 e5             	mov    %rsp,%rbp
 4200506:	b8 18 00 00 00       	mov    $0x18,%eax
 420050b:	5d                   	pop    %rbp


注意

1、-Ttext-segment指定的必需是一个页对齐的地址。

2、动态库的装载位置不是固定的,一般可以认为动态库的-Ttext-segment=0,没有使用;如果想直接运行.so的话(glibc里面很多.so都可以直接运行),需要为.so指定ld-linux.so(.so默认没有指定):
gcc -shared -fPIC -o libx.so x.c -Wl,--dynamic-linker=some_ld_linux.so.x
或者代码里面写:const char my_interp[] __attribute__((section(".interp"))) = "/lib/ld-linux.so.3"; //需要保证这个ld-linux.so存在且能用

可以使用readelf -l查看.inter段,也就是指定的ld-linux.so

3、-Ttext-segment并不是指定.text段的加载位置,而是指定整个elf的加载位置。

如果想指定.text段的加载位置,可以:
       -Tbss=org
       -Tdata=org
       -Ttext=org
           Same as --section-start, with ".bss", ".data" or ".text" as the
           sectionname.
4、gcc -Wl,-Ttext-segment=0x400000 -Wl,-Ttext=0x800000  -o x x.c这样是可以的,但是如果-Ttext指定的比较小,要么程序无法运行,要么可能和其他段冲突。加完-Ttext之后,.text段以及后面的段,在文件中的偏移会变大不少,中间填充的0是为了加载到内存后的页对齐,在内存中的加载位置都会从-Ttext指定的位置开始。

目录
相关文章
|
Java API 数据处理
使用Java内存映射(Memory-Mapped Files)处理大文件
NIO中的内存映射 (1)什么是内存映射文件 内存映射文件,是由一个文件到一块内存的映射,可以理解为将一个文件映射到进程地址,然后可以通过操作内存来访问文件数据。说白了就是使用虚拟内存将磁盘的文件数据加载到虚拟内存的内存页,然后就可以直接操作内存页数据。
7046 0
|
编译器 数据安全/隐私保护 开发者
4.6 x64dbg 内存扫描与查壳实现
LyScript 插件中默认提供了多种内存特征扫描函数,每一种扫描函数用法各不相同,在使用扫描函数时应首先搞清楚不同函数之间的差异,本章内容将分别详细介绍每一种内存扫描函数是如何灵活运用,并实现一种内存查壳脚本,可快速定位目标程序加了什么壳以及寻找被加壳程序的入口点。软件查壳的实现原理可以分为静态分析和动态分析两种方式。静态分析是指在不运行被加壳程序的情况下,通过对程序的二进制代码进行解析,识别出程序是否被加壳,以及加壳的种类和方法。动态分析是指通过运行被加壳程序,并观察程序运行时的行为,识别程序是否被加壳,以及加壳的种类和方法。
161 0
|
存储 安全 算法
4.2 x64dbg 针对PE文件的扫描
通过运用`LyScript`插件并配合`pefile`模块,即可实现对特定PE文件的扫描功能,例如载入PE程序到内存,验证PE启用的保护方式,计算PE节区内存特征,文件FOA与内存VA转换等功能的实现,首先简单介绍一下`pefile`模块。pefile模块是一个用于解析Windows可执行文件(PE文件)的Python模块,它可以从PE文件中提取出文件头、节表、导入表、导出表、资源表等信息,也可以修改PE文件的一些属性。可以用于分析针对Windows平台的恶意软件、编写自己的PE文件修改工具等场景。
137 0
4.2 x64dbg 针对PE文件的扫描
|
Linux
【Linux】关于Bad magic number in super-block 当尝试打开/dev/sda1 时找不到有效的文件系统超级块
【Linux】关于Bad magic number in super-block 当尝试打开/dev/sda1 时找不到有效的文件系统超级块
379 0
|
C++
error LNK2001: 无法解析的外部符号 _ft_sdf_renderer_class/ _ft_bitmap_sdf_renderer_class
error LNK2001: 无法解析的外部符号 _ft_sdf_renderer_class/ _ft_bitmap_sdf_renderer_class
113 0
|
Java 图形学
Unity打包符号表 使用ndk addr2line.exe+符号表 将崩溃内存地址解析成函数名
符号表的路径,符号表发布出来的时候是一个zip文件要把它解压出来,里面会有两个文件:arm64-v8a(64位)、armeabi-v7a(32位)不过unity默认打包出来的都是64位的程序,所以这个前面加上你的真实路径+arm64-v8a\libil2cpp.sym.so就可以了。
|
Java Linux
从JVM heap dump里查找没有关闭文件的引用
背景 最近排查一个文件没有关闭的问题,记录一下。 哪些文件没有关闭是比较容易找到的,查看进程的fd(File Descriptor)就可以。
1510 0
|
NoSQL
gdb打印结构体member offset
linux的crash有个好处就是可以方便打印结构体成员变量的offset, 有时候对汇编的时候, 需要偏移, 可惜crash需要一个活体才行, 不能单纯的vmlinux, 因为它就是这么设计的 gdb天生没有这个功能, 不过python可以实现 cat offset.py import gdb class Offsets(gdb.Command): def __in
2915 0
|
Linux C语言
利用__attribute__((section()))构建初始化函数表【转】
转自: https://mp.weixin.qq.com/s?__biz=MzAwMDUwNDgxOA==&mid=2652663356&idx=1&sn=779762953029c0e0946c22ef2bb0b754&chksm=810f28a1b678a1b747520ba3ee47c9e...
1760 0