编译与二进制学习#

预处理：Preprocessing#

预处理器主要处理以 # 开头的预处理指令。

1
#include <iostream>
2

3
#define ADD(a, b) ((a) + (b))
4

5
int main() {
6
    int x = ADD(10, 20);
7
}

预处理主要做三件事：

• #include：把头文件内容展开到当前文件。
• #define：进行宏替换。
• #if、#ifdef：根据条件决定哪些代码参与后续编译。
• 编译后拿到main.i，仍然是可读的文本。

比如我们利用下面的命令进行观察：

1
g++ -E main.cpp -o main.i

-E 表示只进行预处理。

打开 main.i，你会发现它可能非常大，因为 <iostream> 等头文件被展开了。总共3完多行，而我们的源码就7行！

贴一点出来，如下

1
namespace std
2
{
3

4
# 64 "D:/mingw64/lib/gcc/x86_64-w64-mingw32/15.2.0/include/c++/iostream" 3
5
  extern istream cin;
6
  extern ostream cout;
7
  extern ostream cerr;
8
  extern ostream clog;
9

10

11
  extern wistream wcin;
12
  extern wostream wcout;
13
  extern wostream wcerr;
14
  extern wostream wclog;
15
# 87 "D:/mingw64/lib/gcc/x86_64-w64-mingw32/15.2.0/include/c++/iostream" 3
16

17
}
18
# 2 "tmp.cpp" 2
19

20
# 5 "tmp.cpp"
21
int main() {
22
    int x = ((10) + (20));
23
}

编译#

编译阶段会分析 C++ 语法和语义，然后生成汇编代码。这时候编译器就会接手，然后做一些优化了。

1
g++ -S -O0 -fno-inline tmp.cpp -o tmp.s

-S 表示生成汇编后停止。

产出的汇编如下

1
  .file  "tmp.cpp"
2
  .text
3
  .globl  main
4
  .def  main;  .scl  2;  .type  32;  .endef
5
  .seh_proc  main
6
main:
7
.LFB2190:
8
  pushq  %rbp
9
  .seh_pushreg  %rbp
10
  movq  %rsp, %rbp
11
  .seh_setframe  %rbp, 0
12
  subq  $48, %rsp
13
  .seh_stackalloc  48
14
  .seh_endprologue
15
  call  __main
16
  movl  $30, -4(%rbp)
17
  movl  $0, %eax
18
  addq  $48, %rsp
19
  popq  %rbp
20
  ret
21
  .seh_endproc
22
  .def  __main;  .scl  2;  .type  32;  .endef
23
  .ident  "GCC: (x86_64-posix-seh-rev1, Built by MinGW-Builds project) 15.2.0"

汇编Assembly#

汇编器负责把 .s 中的汇编指令编码成机器码，并生成目标文件 .o。

1
g++ -c -O0 -fno-inline main.cpp -o main.o

-c 表示只编译到目标文件，不进行最终链接。

最终会变成二进制字节。

这里要建立一个重要认识：

汇编代码是机器指令的可读表示；机器码才是 CPU 真正执行的内容。

链接#

链接器（ld 或 link.exe）负责把多个目标文件以及所需的库“拼”在一起，解决所有未定义的符号引用。根据你想要的产物不同，链接方式也不同：

• 生成 .exe（可执行文件）：链接器会把你的目标文件与启动代码（负责调用 main 函数）以及静态库（如 .lib 或 .a）合并。如果使用静态链接，库代码会被直接复制进 .exe 里，文件较大但独立；如果使用动态链接，.exe 里只保留一个指向外部 .dll 或 .so 的引用。
• 生成 .so（共享库/动态库）：在 Linux 上通常用 g++ -shared -fPIC 来生成。-fPIC 生成位置无关代码，使得这个 .so 文件可以被加载到进程内存的任意位置执行，从而能被多个程序共享。

1. .o：目标文件#

.o 是编译后的中间产物，通常还没有完成最终链接。

它可能包含：

• 已经生成的机器指令。
• 数据区。
• 符号表。
• 重定位表。
• 调试信息。

比如：

1
int add(int a, int b) {
2
    return a + b;
3
}

编译：

1
g++ -c math.cpp -o math.o

此时 math.o 中已经有 add 的机器代码，但它不一定能独立运行。

为什么？

因为 .o 可能引用了其他目标文件或外部库中的函数、变量。这些引用还需要链接器解决。

2. 可执行文件：Executable#

例如：

1
g++ main.cpp -o app

链接器会把所需目标文件和库组织起来，生成可以被操作系统装载执行的文件。

Linux/Android 通常使用 ELF 格式。

它有程序入口、程序头表、加载所需信息等。

3. .so：共享库#

.so 是 Shared Object，也就是共享库。

Android NDK 开发中经常生成它：

1
$CXX -std=c++17 -O0 -g -fno-inline \
2
    -fPIC -shared native.cpp \
3
    -o libnative.so

几个参数：

.so 通常不是直接由用户双击运行的程序，而是由其他程序或动态加载器装载。

注意：现代 Linux 的 PIE 可执行文件也常使用 ET_DYN，因此不能单凭 ET_DYN 就断定它一定是 .so。

常见 Section#

注意，具体 Section 是否存在、名称和组织形式会受编译器、链接器、链接选项和目标架构影响。

转成十六进制看看

我们可以看到前面是个.ELF，后面基本就看不懂了。

.symtab 和 .dynsym#

两者区别：

• .symtab：面向链接和分析的普通符号表，可能包含较完整的符号。
• .dynsym：动态链接器需要使用的动态符号表，通常只包含动态链接相关符号。

如果执行：

1
strip libnative.so

普通符号信息可能被剥离。

但动态链接需要的符号信息通常仍然保留。

所以你会遇到这样的情况：

• IDA 看不到很多函数的源码名称。
• 但仍然能看到 malloc、memcpy、JNI_OnLoad 等动态符号。

为什么需要动态链接？#

例如你的程序调用：

1
#include <cstring>
2

3
int main() {
4
    char a[] = "hello";
5
    char b[16]{};
6
    std::memcpy(b, a, sizeof(a));
7
}

memcpy 是 C 标准库提供的函数。

你的程序通常不需要把 memcpy 的完整实现复制进自己的二进制文件。

而是可以在运行时通过动态链接找到系统库中的实现。

1
libnative.so需要调用 memcpy
2
    |
3
动态链接器解析依赖和符号
4
    |
5
libc.so提供 memcpy 的实现
6
    |
7
完成地址解析和必要的重定位
8
    |
9
程序可以调用目标函数
10
通过相应的调用入口到达实际实现

什么是重定位？#

先看一个简单场景。

文件 A：

1
extern int global_value;
2

3
int get_value() {
4
    return global_value;
5
}

文件 B：

1
int global_value = 123;

编译 a.cpp 时，编译器知道需要访问 global_value，但它还不知道这个变量最终会放在哪里。

因为真正的地址要等链接阶段才能确定。

所以目标文件中会保留：

• 一条需要修正的指令或数据引用。
• 一个指向 global_value 的符号引用。
• 一条重定位记录，告诉链接器这个位置需要处理。

这就是重定位的核心思想：

把代码或数据中尚未确定的地址引用，修正为最终正确的地址或地址相关值。

静态重定位与动态重定位#

可以先这样区分：

例如，链接器在生成 .so 时无法确定它未来会被映射到哪个进程虚拟地址。

动态体现在第一次运行或者加载时，动态链接器把libc.so加载到内存里，然后填充GOT表，把所需要的函数地址写进去，比如printf。

所以需要结合加载基址进行地址修正。

这就引出了 PIC（Position Independent Code，位置无关代码）。

为什么 .so 常使用 PIC？#

假设一个共享库中有函数：

1
int global_value = 123;
2

3
int get_value() {
4
    return global_value;
5
}

如果机器代码直接写死：

1
global_value 的绝对虚拟地址 = 0x70001000

那么这个 .so 换一个加载地址，代码就可能访问错误位置。

因此共享库通常采用位置无关代码。

ARM64 下常见的思路是通过 PC-relative 寻址访问附近的数据，或通过 GOT 间接访问全局符号。

概念示意：

1
adrp x8, :got:global_value
2
ldr  x8, [x8, :got_lo12:global_value]
3
ldr  w0, [x8]
4
ret

这只是说明一种典型的 GOT 访问模式，实际汇编会受到编译器、链接器、代码模型和符号可见性等影响。

PLT 和 GOT#

先记住：

• PLT（Procedure Linkage Table）：函数调用的跳转入口机制。
• GOT（Global Offset Table）：保存运行时地址等信息的表。

1
1.业务代码调用 memcpy@plt
2
2.PLT 跳转入口，间接跳转到 GOT 指定的地址
3
3.GOT 表项，保存解析后的目标地址或解析入口
4
4.ibc.so 中的 memcpy，实际执行函数

在一些 ELF 环境中，第一次调用可能经过动态链接器的延迟绑定流程：

1. 调用 PLT 入口。
2. PLT 跳转到 GOT 中的初始解析入口。
3. 动态链接器解析目标符号。
4. 将解析出的地址写入相应 GOT 表项。
5. 后续调用可以直接跳转到解析后的目标。

但要注意：

• 并不是所有函数调用都使用 PLT。
• 并不是所有平台都默认启用延迟绑定。
• Android Bionic 的链接行为和具体链接选项可能与常见 Linux glibc 环境不同。
• AArch64 常见的 PLT/GOT 代码形态与 x86-64 不同。

1. 为什么需要名称修饰？#

先看两个函数：

1
int add(int a, int b) {
2
    return a + b;
3
}
4

5
float add(float a, float b) {
6
    return a + b;
7
}

在 C++ 中，这两个函数可以同时存在，因为它们的参数类型不同。这叫函数重载，之前讲过的哦。

但问题来了：编译后，机器层面需要区分这两个函数。

如果它们都只叫 add，链接器就无法仅凭名字区分它们。

于是 C++ 编译器会对函数名进行编码，把：

• 命名空间
• 类名
• 函数名
• 参数类型
• 某些成员函数限定信息

编码进符号名称中。

这就是 Name Mangling。

比如上面两个函数就可能再GCC里被编译成

1
_Z3addii
2
_Z3addff
3

4
_Z3addii
5
│ │   │ └── i：int
6
│ │   └──── i：int
7
│ └────── 3add：长度为 3 的名字 add
8
└──────── C++ 修饰符前缀

命名空间被修饰#

源码：

1
namespace NativeLab {
2
    int add(int a, int b) {
3
        return a + b;
4
    }
5
}

可能修饰成：

1
_ZN9NativeLab3addEii
2

3
N：嵌套名称。
4
9NativeLab：长度为 9 的命名空间名。
5
3add：长度为 3 的函数名。
6
E：嵌套名称结束。
7
ii：两个 int 参数。

类成员函数被修饰#

例如：

1
class User {
2
public:
3
    void setAge(int age);
4
    int getAge() const;
5
};

成员函数的符号名称不仅需要包含函数名和参数类型，还需要包含类作用域和必要的成员函数限定信息。

典型 Itanium ABI 风格的反修饰结果可能是：

1
_ZN4User6setAgeEi
2
_ZNK4User6getAgeEv

1. ABI 到底是什么？#

ABI，全称 Application Binary Interface，应用二进制接口。

你可以把它理解为：

已经编译成机器码的不同模块之间，必须遵守的一套底层约定。

例如，模块 A 编译了：

1
int add(int a, int b);

模块 B 调用了：

1
int result = add(10, 20);

它们要能够正常协作，就必须对很多事情达成一致：

• 函数符号名称是什么？
• 参数放在哪里？
• 返回值放在哪里？
• 栈如何使用？
• 类对象如何布局？
• 虚函数表如何组织？
• 异常如何传播？
• RTTI 如何表示？

下面是两个容易混淆的概念。

ABI有价值的规定可以总结为下面几点

① Name Mangling

符号名称如何编码。比如 _ZN9NativeLab3addEii。

② Calling Convention

参数放在哪些寄存器或栈位置，返回值如何传递，谁负责保存寄存器。

③ Object Layout

类成员偏移、对齐、虚表指针、基类子对象位置等。

④ Virtual Dispatch

虚函数表、虚表指针、this 调整 thunk 等。

⑤ RTTI / Exception ABI

运行时类型信息、异常展开、构造和析构相关约定。

优化一：常量折叠（Constant Folding）#

源码：

1
int calculate() {
2
    int a = 10;
3
    int b = 20;
4
    return a + b;
5
}

直觉上，你可能认为机器码应该有：

1
MOV W0, #10
2
MOV W1, #20
3
ADD W0, W0, W1
4
RET

但编译器发现：

1
10 + 20 = 30

所以可能直接生成：

1
MOV W0, #30
2
RET

甚至如果调用结果也不会被观察到，整个函数都可能被删除。

这叫常量折叠。

逆向启示： 你可能根本看不到源码中的加法指令，因为编译器已经提前算完了。

优化二：死代码删除（Dead Code Elimination）#

源码：

1
int test() {
2
    int a = 10;
3
    int b = 20;
4
    int c = a + b;
5

6
    return 100;
7
}

变量 a、b、c 的结果都没有被使用。

因此编译器可能直接生成：

1
MOV W0, #100
2
RET

你在 IDA 里找不到：

1
int c = a + b;

不是 IDA 漏掉了，而是它已经被编译器删除了。

优化三：函数内联（Inlining）#

源码：

1
__attribute__((noinline))
2
int add(int a, int b) {
3
    return a + b;
4
}

这里的 noinline 是 GCC/Clang 常见扩展，用于阻止该函数被内联。

去掉它：

1
int add(int a, int b) {
2
    return a + b;
3
}
4

5
int main() {
6
    return add(10, 20);
7
}

优化后，调用点可能直接变成：

1
MOV W0, #30
2
RET

原来的：

1
BL add

可能完全不存在。

这意味着：

• 源码中有函数。
• 但最终二进制中可能没有独立函数入口。
• 函数逻辑可能被直接合并进调用者。

优化四：循环展开（Loop Unrolling）#

源码：

1
int sum() {
2
    int result = 0;
3

4
    for (int i = 0; i < 4; i++) {
5
        result += i;
6
    }
7

8
    return result;
9
}

原本是循环：

1
初始化 i
2
判断 i < 4
3
执行加法
4
i++
5
跳回判断

编译器可能把循环展开：

1
int sum() {
2
    int result = 0;
3
    result += 0;
4
    result += 1;
5
    result += 2;
6
    result += 3;
7
    return result;
8
}

还可能继续常量折叠成直接返回 6。

优化五：寄存器分配（Register Allocation）#

源码：

1
int calculate(int a, int b) {
2
    int x = a + b;
3
    int y = x * 2;
4
    return y;
5
}

源码有三个变量：

• a
• b
• x
• y

但机器代码不一定为它们分配四个独立的栈变量。

编译器可能让中间结果一直存在寄存器里：

1
ADD W0, W0, W1
2
LSL W0, W0, #1
3
RET

这里甚至没有栈内存访问。

这就是寄存器分配和表达式简化的结果。

优化六：尾调用优化（Tail Call Optimization）#

源码：

1
int add(int a, int b);
2

3
int wrapper(int a, int b) {
4
    return add(a, b);
5
}

普通理解是：

1
wrapper
2
  调用 add
3
  add 返回
4
  wrapper 返回

但编译器可能优化为：

1
B add

而不是：

1
BL add
2
RET

这叫尾调用优化。

原因是 wrapper 调用 add 后不再做任何工作，可以直接把控制权交给 add。

优化七：结构体和内存访问优化#

源码：

1
struct Data {
2
    int a;
3
    int b;
4
};
5

6
int get(Data* p) {
7
    return p->a + p->b;
8
}

在 IDA 中，你可能看到：

1
LDR W8, [X0]
2
LDR W9, [X0,#4]
3
ADD W0, W8, W9
4
RET

这时你可以推测：

• X0 是结构体地址。
• offset 0 处是 a。
• offset 4 处是 b。

但如果编译器知道某些成员值是常量，或结构体对象只在局部范围内使用，优化可能进一步消除内存访问。

所以结构体布局分析最好结合：

• 源码（如果有）。
• 调试信息。
• 多处访问偏移。
• 构造函数和调用点。
• 汇编与数据交叉引用。

还有两个需要补充的概念：

去虚化（Devirtualization）

例如：

1
Dog dog;
2
Animal* p = &dog;
3
p->speak();

如果编译器能确定 p 一定指向 Dog，它可能直接调用 Dog::speak()，不再通过 vtable 间接调用。

向量化（Vectorization）

例如循环对数组逐项相加，编译器可能使用 SIMD 指令一次处理多个元素，而不是每次只处理一个元素。

这时 IDA 里可能看到 LD1、ADD V... 等向量指令，源码却只是一个普通的 for 循环。

1
int add(int a, int b) {
2
    return a + b;
3
}
4

5
extern "C" int c_add(int a, int b) {
6
    return a + b;
7
}

1
extern "C"

1
g++ -c -O0 test.cpp -o test.o
2
nm test.o

1
_Z3addii
2
c_add

1
extern "C"
2
JNIEXPORT jint JNICALL
3
Java_com_example_app_MainActivity_nativeAdd(
4
    JNIEnv* env,
5
    jobject thiz,
6
    jint a,
7
    jint b
8
) {
9
    return a + b;
10
}