[原创]从零手写 ARM64 自定义 Linker-Android安全-看雪安全社区

[原创]从零手写 ARM64 自定义 Linker

发表于: 2026-7-17 15:58 38994

[原创]从零手写 ARM64 自定义 Linker

北袅

2026-7-17 15:58

38994

# 从零手写 ARM64 自定义 Linker

## 前言

学完 ELF 文件格式和 Android linker 的加载流程后,一直有种意犹未尽的感觉——原理看懂了,却没动手实操一遍,总觉得稍有遗憾。本文就是把这次从零实现的完整过程记录下来,拆解其中的思路与落地。一是温习前面所学,把散落的知识点串成一条完整链路;二是为后续理解主流加壳、脱壳的手法打地基——知己知彼,方能百战不殆。本文只是建立好这个地基,而地基之上的种种骚操作,或许在下一篇文章中会出现？

## 环境

真机 Pixel 3、Android 12，架构 arm64-v8a；编译使用 NDK 25.1.8937393。as版本：2026.1.1

## 大体思路

整体目标很清晰：不借助系统的 dlopen/dlsym，用 C++ 手写一个 ARM64 加载器，把一个 .so 从文件变成内存里可调用的代码，最终通过自己实现的符号查找拿到导出函数地址并成功调用。

在做法上，先用系统 dlopen 跑通一次目标 so，留作后续比对的标准答案。之后照着系统 linker 的真实流程，把整条链路拆成几个阶段逐一实现。

装载，是按 program header 的描述把 so 的各个段映射进内存，并算出文件地址到内存地址的关键偏移 load\_bias，后面每一步都要用它换算地址。解析 dynamic 段，是遍历其中的各个 tag，把符号表、字符串表、重定位表、初始化函数这些散落的元信息收集进自己的 soinfo 结构。符号查找，是手写 gnu\_hash 的查找算法，按名字从 so 里定位符号地址；对本 so 未定义的外部符号如 printf，则采用受控的兜底解析。重定位，是遍历两张 RELA 表，按 ARM64 的四种类型逐条修正内存中的地址，把 GOT 填成正确的函数地址。初始化，是按先 DT\_INIT 后 DT\_INIT\_ARRAY 的顺序，手动触发 so 的构造函数。最后收官，实现自己的 dlsym，从加载好的 so 里查出导出函数 add 的地址，强转成函数指针调用，验证结果与系统 dlopen 一致。

## **环境准备与目标 SO 构建**

### 目标 SO 的交叉编译

创建libtarget.c文件，写入以下内容：

```c
#include <stdio.h>

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

static const char* g_msg = "hello from libtarget";

__attribute__((constructor))
static void my_constructor(void) {
    printf("[target] my_constructor called (init_array), g_msg=%s\n", g_msg);
}
```

去NDK路径下找这个cmd命令

```c
D:\environment\_SDK\ndk\25.1.8937393\toolchains\llvm\prebuilt\windows-x86_64\bin\aarch64-linux-android31-clang.cmd
```

如果找不到可以使用这个命令去检索（搜哪个磁盘下面的path后的路径就换成哪个）

```c
Get-ChildItem -Path D:\ -Recurse -Filter "aarch64-linux-android31-clang.cmd" -ErrorAction SilentlyContinue | Select-Object -First 1 -ExpandProperty FullName
```

```c
& "把找到的路径粘贴到这里" -shared -fPIC -o "$PWD\libtarget.so" "$PWD\libtarget.c"
```

```c
& "D:\environment\_SDK\ndk\25.1.8937393\toolchains\llvm\prebuilt\windows-x86_64\bin\aarch64-linux-android31-clang.cmd" -shared -fPIC -o "$PWD\libtarget.so" "$PWD\libtarget.c"
```

![image](upload/attach/202607/951483_CTP42CFR488V7RC.png)

像这样啥也没输出就是成功了，目录下会产出一个libtarget.so。

![image](upload/attach/202607/951483_WYTHJQMEW3KFK7K.png)

### 用系统 dlopen 跑通一次

as创建一个Native项目

![image](upload/attach/202607/951483_EWUM328FE89JFNG.png)

---

在左侧 `app/src/main/` 上右键 → New → Directory,输入 `jniLibs/arm64-v8a`(一次性带斜杠创建两层)。然后把那个编好的 `libtarget.so` 复制进 `app/src/main/jniLibs/arm64-v8a/libtarget.so`。

这里创建的是arm64的 需要在真机上运行

![image](upload/attach/202607/951483_Y6CQN87S25TTB3B.png)

#### MainActivity： 去除掉了没用的内容尽可能保证代码干净一点

这里private native void runLoaderRef() 去手敲 然后用ALT+回车去创建

![image](upload/attach/202607/951483_BPGZDXGQVVYFTCX.png)

```c
package com.example.myapplication;

import androidx.appcompat.app.AppCompatActivity;

import android.os.Bundle;
import android.widget.TextView;

import com.example.myapplication.databinding.ActivityMainBinding;

public class MainActivity extends AppCompatActivity {

static {
        System.loadLibrary("myapplication");
    }

@Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        runLoaderRef();
    }

private native void runLoaderRef();
}
```

#### native-lib.cpp:

```c
#include <jni.h>
#include <string>
#include <dlfcn.h>
#include <unistd.h>
#include <android/log.h>

#define LOG(...) __android_log_print(ANDROID_LOG_INFO, "myloader", __VA_ARGS__)

extern "C"
JNIEXPORT void JNICALL
Java_com_example_myapplication_MainActivity_runLoaderRef(JNIEnv *env, jobject thiz) {
    // TODO: implement runLoaderRef()
    LOG("======1.5 loader_ref start ======");
    LOG("pid=%d", getpid());

void *h = dlopen("libtarget.so", RTLD_NOW);
    if (!h) {
        LOG("dlopen FAILED:%s", dlerror());
        return;
    }
    LOG("dlopen OK, handle=%p", h);

typedef int (*add_t)(int, int);
    add_t add_fn = (add_t) dlsym(h, "add");
    if (!add_fn) {
        LOG("dlsym(add) FAILED: %s", dlerror());
        dlclose(h);
        return;
    }
    LOG("dlsym(add) = %p", (void *) add_fn);

int r = add_fn(3, 4);
    LOG("add(3,4) = %d (expect 7)", r);

LOG("===== 1.5 loader_ref end =====");
};
```

运行测试：

![image](upload/attach/202607/951483_X8GJSZUQ6DGMQ9M.png)

## **程序骨架：soinfo 结构与主流程**

> 目标：不实现任何实际加载逻辑，先把整个程序的类结构、调用链、数据结构搭出来，能编译能跑能打印，确立后续所有代码的填充位置。

### 精简版 soinfo 结构体

新建 `cpp/soinfo.h`。

#### 被裁剪的字段

本文只保留加载并调用单个 SO 所需的字段，其余一并裁去。

fini\_func / fini\_array（析构相关）裁去，加载后的 SO 不支持优雅卸载。本文不涉及卸载，进程退出时由系统回收。

TLS 字段（线程局部存储）裁去，SO 若使用 `__thread` 变量将崩溃。目标 SO 未使用。

符号版本字段（verdef / verneed）裁去，无法处理带符号版本的 SO。目标 SO 不含此类信息。

ARM\_exidx（异常处理表）裁去，C++ 异常展开可能出错。目标 SO 为 C 代码且不抛异常。

sysv hash 字段裁去，目标 SO 仅含 gnu\_hash。

next 指针与 soinfo 链表裁去，该结构用于串联全部已加载 SO 以支持全局符号查找。本文只加载单个 SO，无此需要。

这里按照类型分成五个组方便后续的字段新增与修改

```c
#ifndef MYLINKER_SOINFO_H
#define MYLINKER_SOINFO_H

#include <elf.h>
#include <link.h>
#include <cstddef>
#include <cstdint>
#include <vector>
#include <string>

typedef void (*linker_ctor_function_t)(void);

class soinfo {
public:
//    组一：装载信息
    const char *name; 
    ElfW(Addr) base;  
    size_t size;      
    ElfW(Addr) load_bias;   
    const ElfW(Phdr) *phdr;  
    size_t phnum;

//    组二：符号信息
    const char *strtab;     
    ElfW(Sym) *symtab;

size_t gnu_nbucket;
    uint32_t *gnu_bucket;
    uint32_t *gnu_chain;
    uint32_t gnu_maskwords;  
    uint32_t gnu_shift2;      
    ElfW(Addr) *gnu_bloom_filter;
    uint32_t gnu_symndx;

//    组三：重定位信息
    ElfW(Rela) *rela;           
    size_t rela_count;

ElfW(Rela) *plt_rela;       
    size_t plt_rela_count;

//    组四：初始化信息
    linker_ctor_function_t init_func;         
    linker_ctor_function_t *init_array;       
    size_t init_array_count;

//    组五：依赖与状态
    ElfW(Dyn) *dynamic;           
    std::vector<std::string> needed_names;  
    bool constructors_called;      
    uint32_t flags;

bool load(const char *path);      
    bool parse_dynamic();             
    bool relocate();                  
    void call_constructors();         
    ElfW(Addr) lookup_symbol(const char *name);

};

#endif
```

### MyLinker 调用链框架

这节主要就是将框架和流程跑通 不需要做具体的内容实现 搭建宏观上的调用链 然后在后续填坑就行

新建 `cpp/mylinker.h`

```c
#ifndef MYLINKER_MYLINKER_H
#define MYLINKER_MYLINKER_H

#include "soinfo.h"

class Mylinker {
public:
    soinfo *dlopen(const char *path);

ElfW(Addr) dlsym(soinfo *si, const char *name);
};

#endif
```

新建 `cpp/mylinker.cpp`

这里是没有find_library步骤的。系统要在一堆路径找到so文件、检查是否加载过、处理依赖....

我们这里只加载一个so 并且知道路径，因此不需要find_library这个逻辑。

```c
#include "mylinker.h"
#include <android/log.h>

#define LOG(...)__android_log_print(ANDROID_LOG_INFO,"myloader",__VA_ARGS__)

soinfo *Mylinker::dlopen(const char *path) {
    LOG("[dlopen] === start:%s ===", path);

soinfo *si = new soinfo();
    si->name = path;

if (!si->load(path)) {
        LOG("[dlopen] load failed");
        delete si;
        return nullptr;
    };

if (!si->parse_dynamic()) {
        LOG("[dlopen] parse_dynamic failed");
        delete si;
        return nullptr;
    }

if (!si->relocate()) {
        LOG("[dlopen] relocate failed");
        delete si;
        return nullptr;
    }

si->call_constructors();

LOG("[dlopen] === done: %s === ", path);
    return si;
}

ElfW(Addr) Mylinker::dlsym(soinfo *si, const char *name) {
    LOG("[dlsym] lookup: %s", name);
    return si->lookup_symbol(name);
}
```

新建 `cpp/soinfo.cpp`

这里先做空实现和日志打印就行

```c
#include "soinfo.h"
#include <android/log.h>

#define LOG(...)__android_log_print(ANDROID_LOG_INFO,"myloader",__VA_ARGS__)

bool soinfo::load(const char *path) {
    LOG("[load] entering (path=%s)", path);
    return true;
}

bool soinfo::parse_dynamic() {
    LOG("[parse_dynamic] entering ");
    return true;
}

bool soinfo::relocate() {
    LOG("[relocate] entering ");
    return true;
}

void soinfo::call_constructors() {
    LOG("[call_constructors] entering ");
}

ElfW(Addr) soinfo::lookup_symbol(const char *name) {
    LOG("[lookup_symbol] entering ");
    return 0;
}
```

在cmakelists里面新增这两个.cpp文件

![image](upload/attach/202607/951483_WN5HBQVXNDESVXH.png)

修改native-lib.cpp

将系统的dlopen替换成自己dlopen去加载so

```c
#include <jni.h>
#include <android/log.h>
#include "soinfo.h"
#include "mylinker.h"
#define LOG(...) __android_log_print(ANDROID_LOG_INFO, "myloader", __VA_ARGS__)

extern "C"
JNIEXPORT void JNICALL
Java_com_example_myapplication_MainActivity_runLoaderRef(JNIEnv *env, jobject thiz) {
    Mylinker linker;
    soinfo* si = linker.dlopen("libtarget.so");
    if (!si) {
        LOG("my dlopen failed");
        return;
    }

ElfW(Addr) add_addr = linker.dlsym(si,"add");
};
```

![image](upload/attach/202607/951483_SJCM2XV6SXCAJD2.png)

一个小坑：这里写完这节的逻辑后最好先在菜单 **Build → Clean Project**,然后 **Build → Rebuild Project**,再运行。

不然有可能跑的还是旧的app就会出现下图这样 运行流程对不上

![image](upload/attach/202607/951483_77E3UC76DJRV9DR.png)

### ELF 文件头的读取与校验

native-lib.cpp 改回带参数版本,并把绝对路径传给 dlopen

```c
extern "C" JNIEXPORT void JNICALL
Java_com_example_myapplication_MainActivity_runLoaderRef(
        JNIEnv* env, jobject, jstring nativeLibDir) {
    const char* dir = env->GetStringUTFChars(nativeLibDir, nullptr);
    std::string path = std::string(dir) + "/libtarget.so";
    env->ReleaseStringUTFChars(nativeLibDir, dir);

MyLinker linker;
    soinfo* si = linker.dlopen(path.c_str());
    if (!si) { LOG("my dlopen failed"); return; }
    linker.dlsym(si, "add");
}
```

MainActivity.java 对应改成传参

```c
runLoaderRef(getApplicationInfo().nativeLibraryDir);
private native void runLoaderRef(String nativeLibDir);
```

![image](upload/attach/202607/951483_MNF3DWWH4YAZ2H3.png)

接下来实现 `soinfo::load` 的第一段，只做到读文件头与校验。

soinfo.cpp 顶部补头文件:

```c
#include <fcntl.h>      
#include <unistd.h>     
#include <cstring>     
```

soinfo 中新增两个字段保存 fd 与文件头，装载阶段需跨函数使用。

```c
// soinfo.h 组一里加:
int         fd = -1;          
ElfW(Ehdr)  header;           
```

soinfo.h 成员方法里加一个声明:

```c
bool verify_elf_header();
```

load 实现如下，依次打开文件、读取 ELF 文件头、校验。

```c
bool soinfo::load(const char* path) {
    LOG("[load] entering (path=%s)", path);

fd = open(path, O_RDONLY);
    if (fd == -1) {
        LOG("[load] open failed: %s", path);
        return false;
    }

ssize_t n = read(fd, &header, sizeof(header));
    if (n != sizeof(header)) {
        LOG("[load] read ehdr failed, got %zd bytes", n);
        close(fd);
        return false;
    }

if (!verify_elf_header()) {
        close(fd);
        return false;
    }

LOG("[load] header OK: entry=0x%lx phoff=%lu phnum=%d",
        (unsigned long)header.e_entry,
        (unsigned long)header.e_phoff,
        header.e_phnum);
    return true;   
}

```

verify_elf_header 沿用系统 linker 的校验逻辑，逐项确认文件为 64 位、小端、ARM64 的共享库，任一不符即返回 false。

```c
bool soinfo::verify_elf_header() {
    if (memcmp(header.e_ident, ELFMAG, SELFMAG) != 0) {
        LOG("[verify] bad magic, not ELF");
        return false;
    }
    if (header.e_ident[EI_CLASS] != ELFCLASS64) {   
        LOG("[verify] not ELFCLASS64");
        return false;
    }
    if (header.e_ident[EI_DATA] != ELFDATA2LSB) {
        LOG("[verify] not little-endian");
        return false;
    }
    if (header.e_type != ET_DYN) {
        LOG("[verify] not ET_DYN (type=%d)", header.e_type);
        return false;
    }
    if (header.e_machine != EM_AARCH64) {           
        LOG("[verify] not EM_AARCH64 (machine=%d)", header.e_machine);
        return false;
    }
    if (header.e_version != EV_CURRENT) {
        LOG("[verify] bad version");
        return false;
    }
    return true;
}
```

运行结果：

![image](upload/attach/202607/951483_JJK8Z294RYWG4WX.png)

![image](upload/attach/202607/951483_SYHKMBQWTEKQQCM.png)

## **装载：手动映射 SO 至内存**

> 本节手动实现段的映射流程，使加载器映射的段能在 /proc/pid/maps 中被观察到。为便于调试，先采用 file-backed 方式打通整条链路。

### 读取 Program Header Table

先定义页对齐宏，新建 `cpp/linker_common.h`。PAGE\_START 向下取整到页边界，PAGE\_END 向上取整，PAGE\_OFFSET 取页内偏移。

```c
#ifndef MYLINKER_COMMON_H
#define MYLINKER_COMMON_H

#include <elf.h>
#include <link.h>

// Pixel3 / Android12 是 4KB 页
#define PAGE_SIZE 4096
#define PAGE_MASK (~(PAGE_SIZE - 1))

// 向下对齐到页边界
#define PAGE_START(x)  ((x) & PAGE_MASK)
// x 在所在页内的偏移
#define PAGE_OFFSET(x) ((x) & (PAGE_SIZE - 1))
// 向上对齐到页边界
#define PAGE_END(x)    PAGE_START((x) + (PAGE_SIZE - 1))

#endif

```

soinfo.h 新增字段与方法声明。此处的 phdr\_table 指向从文件临时映射读到的 PHT，与前面声明的 phdr 不同——后者指向 SO 映射进内存后、内存中的 PHT。

```c
// 组一里加:临时映射 PHT 用
void*  phdr_mmap = nullptr;   
size_t phdr_mmap_size = 0;
const ElfW(Phdr)* phdr_table = nullptr;

// 方法声明:
bool read_program_headers();
```

soinfo.cpp 补充头文件与实现。mmap 的 offset 参数必须页对齐，而 e\_phoff（64）并非页对齐，因此将起点向下对齐到 page\_min（0），映射一整页，再令 phdr\_table 指向页内 `PAGE_OFFSET(64) = 64` 处。

```c
#include <sys/mman.h>
#include "linker_common.h"

bool soinfo::read_program_headers() {
    phnum = header.e_phnum;

ElfW(Addr) phdr_start = header.e_phoff;
    size_t     phdr_size  = phnum * header.e_phentsize;

ElfW(Addr) page_min   = PAGE_START(phdr_start);
    ElfW(Addr) page_max   = PAGE_END(phdr_start + phdr_size);
    size_t     map_size   = page_max - page_min;

void* mmap_result = mmap(nullptr, map_size, PROT_READ,
                             MAP_PRIVATE, fd, page_min);
    if (mmap_result == MAP_FAILED) {
        LOG("[read_phdr] mmap failed");
        return false;
    }

phdr_mmap      = mmap_result;
    phdr_mmap_size = map_size;

phdr_table = reinterpret_cast<const ElfW(Phdr)*>(
        reinterpret_cast<char*>(mmap_result) + PAGE_OFFSET(phdr_start));

LOG("[read_phdr] mapped %zu phdrs at %p", phnum, phdr_table);
    return true;
}

```

在 load 里调用

![image](upload/attach/202607/951483_EGD5RGVF3WHK4SJ.png)

这里可以在read\_program\_headers 的 return 前把PHT的段进行遍历打印看看是不是对的

```c
    for (size_t i = 0; i < phnum; i++) {
        const ElfW(Phdr)* p = &phdr_table[i];
        LOG("  phdr[%zu] type=%u vaddr=0x%lx memsz=0x%lx flags=0x%x",
            i, p->p_type,
            (unsigned long)p->p_vaddr,
            (unsigned long)p->p_memsz,
            p->p_flags);
    }
```

打印结果与预期一致，没啥问题。

![image](upload/attach/202607/951483_NPGD6PK2R8RFMHA.png)

### 计算 load\_size 并预留地址空间

一个 SO 可能包含多个 PT\_LOAD 段，它们在虚拟地址空间中彼此间隔固定。为保证这些段映射后相对位置正确，须先一次性预留一块足以容纳全部段的连续地址空间，再逐段填入。预留空间的大小 load\_size，等于最高段末尾（向上页对齐）减去最低段起始（向下页对齐）。

load\_bias 是文件虚拟地址到内存实际地址的偏移，等于 mmap 返回的真实起始地址减去页对齐后的最小 p\_vaddr，后续所有地址换算均依赖它。

soinfo.h 新增一个方法声明。

```c
bool reserve_address_space();
```

实现分四步。先遍历所有 PT\_LOAD 段，求出最小的 p\_vaddr 和最大的 p\_vaddr + p\_memsz；再将两端页对齐，低地址向下、高地址向上，二者之差即 load\_size；随后以 PROT\_NONE、匿名方式一次性 mmap 出这块连续空间，此时只占位、不设权限、不映射内容；最后由预留空间的起始地址与页对齐后的最小 p\_vaddr 算出 load\_bias。之所以用 PROT\_NONE 占位，是因为此处目的仅是圈定一段连续且不被其他分配占用的地址范围，段的真实内容与权限留待下一节逐段映射时覆盖。

soinfo.cpp 实现:

```c
bool soinfo::reserve_address_space() {
    ElfW(Addr) min_vaddr = UINTPTR_MAX;
    ElfW(Addr) max_vaddr = 0;
    bool found_load = false;

for (size_t i = 0; i < phnum; i++) {
        const ElfW(Phdr)* p = &phdr_table[i];
        if (p->p_type != PT_LOAD) {
            continue;
        }
        found_load = true;

if (p->p_vaddr < min_vaddr) {
            min_vaddr = p->p_vaddr;
        }
        if (p->p_vaddr + p->p_memsz > max_vaddr) {
            max_vaddr = p->p_vaddr + p->p_memsz;
        }
    }

if (!found_load) {
        LOG("[reserve] no PT_LOAD found");
        return false;
    }

min_vaddr = PAGE_START(min_vaddr);
    max_vaddr = PAGE_END(max_vaddr);

size = max_vaddr - min_vaddr;

void* start = mmap(nullptr, size, PROT_NONE,
                       MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
    if (start == MAP_FAILED) {
        LOG("[reserve] mmap reserve failed, size=%zu", size);
        return false;
    }

base = reinterpret_cast<ElfW(Addr)>(start);

load_bias = base - min_vaddr;

LOG("[reserve] base=0x%lx size=0x%lx load_bias=0x%lx (min_vaddr=0x%lx)",
        (unsigned long)base,
        (unsigned long)size,
        (unsigned long)load_bias,
        (unsigned long)min_vaddr);

return true;
}
```

在load函数调用

```c
    if (!reserve_address_space()) {
        close(fd);
        return false;
    }
```

![image](upload/attach/202607/951483_P4Y9PBFMCP5NRHC.png)

![image](upload/attach/202607/951483_XRFBZB3WS2D6RNP.png)

### PT\_LOAD 段的映射与 BSS 补零

前面以 PROT\_NONE 预留了一块连续空地，本节将每个 PT\_LOAD 段映射进去并设置权限。段在内存中的位置为 `load_bias + p_vaddr`，load\_bias 至此首次参与地址换算。

映射同样使用 mmap，但与预留时不同：带 fd 真实读取文件，带 MAP\_FIXED 指定地址，权限取自段本身，形式为 `mmap(对齐后的 load_bias+p_vaddr, 段长, 段权限, MAP_FIXED|MAP_PRIVATE, fd, 对齐后的 p_offset)`。

MAP\_FIXED 要求映射到指定地址，不允许系统另择位置——段与段之间的相对距离在编译期已固定，不能改变。之所以能这样用，是因为该地址范围已在上一节被 PROT\_NONE 占下，此处以真实内容覆盖。因此顺序不可颠倒，必须先预留后映射。

地址与文件偏移都需页对齐，而 p\_vaddr、p\_offset 未必对齐，处理方式是两者一并向下取整到页边界。二者能够对应，是因为 ELF 保证同一段的 p\_vaddr 与 p\_offset 具有相同的页内偏移。权限由 p\_flags 的 PF\_R/W/X 转为 PROT\_R/W/X，代码段为 r-x，数据段为 rw-。

BSS 补零仅在 memsz 大于 filesz 时发生，且最易遗漏。filesz 是段在文件中的大小，memsz 是段在内存镜像中的大小，二者之差即 BSS，需以零填充。上面的 mmap 只映射了 filesz，其余分两种情况补齐：一是段尾不足一页的部分，从 filesz 处到本页末尾，该范围已被 mmap 读入但属文件的脏数据，用 memset 清零；二是超出一页的部分，另做一次匿名 mmap（fd \= -1）补齐零页。

soinfo.h 新增一个方法声明，其后在 soinfo.cpp 中实现（其中 flags\_to\_prot 负责将 p\_flags 转为 mmap 的权限位）。

```c
bool load_segments()
```

soinfo.cpp 实现:

```c
static int flags_to_prot(ElfW(Word) p_flags) {
    int prot = 0;
    if (p_flags & PF_R) prot |= PROT_READ;
    if (p_flags & PF_W) prot |= PROT_WRITE;
    if (p_flags & PF_X) prot |= PROT_EXEC;
    return prot;
}

bool soinfo::load_segments() {
    for (size_t i = 0; i < phnum; i++) {
        const ElfW(Phdr)* p = &phdr_table[i];
        if (p->p_type != PT_LOAD) {
            continue;
        }

ElfW(Addr) seg_start = load_bias + p->p_vaddr;
        ElfW(Addr) seg_file_end = seg_start + p->p_filesz; 
        ElfW(Addr) seg_mem_end  = seg_start + p->p_memsz;

ElfW(Addr) seg_page_start = PAGE_START(seg_start);
        ElfW(Addr) file_page_start = PAGE_START(p->p_offset);
        ElfW(Addr) file_end_aligned = PAGE_END(seg_file_end);
        size_t map_size = file_end_aligned - seg_page_start;

int prot = flags_to_prot(p->p_flags);

void* seg = mmap(reinterpret_cast<void*>(seg_page_start),
                         map_size, prot,
                         MAP_FIXED | MAP_PRIVATE, fd, file_page_start);
        if (seg == MAP_FAILED) {
            LOG("[load_seg] mmap seg[%zu] failed", i);
            return false;
        }

LOG("[load_seg] seg[%zu] vaddr=0x%lx -> mem=0x%lx size=0x%zx prot=%d",
            i, (unsigned long)p->p_vaddr,
            (unsigned long)seg_page_start, map_size, prot);

if (p->p_memsz > p->p_filesz) {
            ElfW(Addr) zero_start = seg_file_end;
            ElfW(Addr) zero_page_end = PAGE_END(seg_file_end);
            if (zero_start < zero_page_end) {
                memset(reinterpret_cast<void*>(zero_start), 0,
                       zero_page_end - zero_start);
            }

ElfW(Addr) mem_end_aligned = PAGE_END(seg_mem_end);
            if (mem_end_aligned > zero_page_end) {
                void* zero_map = mmap(
                        reinterpret_cast<void*>(zero_page_end),
                        mem_end_aligned - zero_page_end, prot,
                        MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
                if (zero_map == MAP_FAILED) {
                    LOG("[load_seg] bss anon mmap failed seg[%zu]", i);
                    return false;
                }
            }
        }
    }
    return true;
}
```

在 load 里调用(接在 reserve\_address\_space 之后):

```c
    if (!reserve_address_space()) {
        close(fd);
        return false;
    }

if (!load_segments()) {
        close(fd);
        return false;
    }
```

![image](upload/attach/202607/951483_M4PUCRBDWCZXWTU.png)

### 内存中 Program Header 的定位

读取 Program Header Table 一节曾为读 PHT 临时 mmap 了文件头所在的一页（phdr\_mmap）。如今各段已映射进内存，PHT 作为文件内容也随之进入镜像，本节在镜像中重新定位它，存入 phdr，再释放此前那份临时映射。

不继续沿用临时映射有两个原因：其一，它本就约定用完即弃；其二，后续查找 dynamic、symtab 等一律以 load_bias + p_vaddr 在镜像内换算地址，若混用一份镜像外的 PHT，概念上并不统一。系统 linker 同样在镜像中重新定位，此处与之保持一致。

定位有两种方式，按优先级选取。首选 PT\_PHDR 段，它专门记录 PHT 自身在内存中的位置，存在时直接取 load_bias + p_vaddr，最为准确。若无 PT\_PHDR，则退而取 p\_offset 为 0 的第一个 PT\_LOAD 段：ELF 文件头位于文件起始，PHT 紧随其后，这一区域必被某个从偏移 0 起始的 PT\_LOAD 映入内存，地址为 load_bias + p_vaddr + e_phoff。两种方式算出的是同一地址，PT\_PHDR 更为直接。

此处有一个顺序需注意：遍历查找 PT\_PHDR 时用的仍是 phdr\_table（指向临时映射），因此必须先算出新地址存好，最后再 munmap 临时映射。若顺序颠倒，phdr\_table 将成为悬空指针。

find\_phdr 是 load 的最后一步，成功后即可 close(fd)——各段已在内存中，不再依赖文件描述符。

soinfo.h 新增一个方法声明，其后在 soinfo.cpp 中实现。

```c
bool find_phdr();
```

soinfo.cpp 实现:

```c
bool soinfo::find_phdr() {
    const ElfW(Phdr)* phdr_in_mem = nullptr;

for (size_t i = 0; i < phnum; i++) {
        const ElfW(Phdr)* p = &phdr_table[i];
        if (p->p_type == PT_PHDR) {
            phdr_in_mem = reinterpret_cast<const ElfW(Phdr)*>(
                    load_bias + p->p_vaddr);
            LOG("[find_phdr] via PT_PHDR");
            break;
        }
    }

if (phdr_in_mem == nullptr) {
        for (size_t i = 0; i < phnum; i++) {
            const ElfW(Phdr)* p = &phdr_table[i];
            if (p->p_type == PT_LOAD && p->p_offset == 0) {
                phdr_in_mem = reinterpret_cast<const ElfW(Phdr)*>(
                        load_bias + p->p_vaddr + header.e_phoff);
                LOG("[find_phdr] via PT_LOAD(offset=0)");
                break;
            }
        }
    }

if (phdr_in_mem == nullptr) {
        LOG("[find_phdr] cannot locate phdr in memory");
        return false;
    }

phdr = phdr_in_mem;

LOG("[find_phdr] phdr in memory = %p (phnum=%zu)", phdr, phnum);

if (phdr_mmap != nullptr) {
        munmap(phdr_mmap, phdr_mmap_size);
        phdr_mmap = nullptr;
        phdr_mmap_size = 0;
        phdr_table = nullptr;
    }

return true;
}
```

在 load 里调用(接在 load\_segments 之后,这也是 load 的最后一步):

```c
    if (!load_segments()) {
        close(fd);
        return false;
    }

if (!find_phdr()) {
        close(fd);
        return false;
    }

close(fd);
    LOG("[load] done: base=0x%lx load_bias=0x%lx", 
        (unsigned long)base, (unsigned long)load_bias);
    return true;

```

![image](upload/attach/202607/951483_CE5NMD3A9F3HA7B.png)

## **解析 Dynamic 段**

> 本节遍历 dynamic 段，采用 ARM64 的 tag 集合，将散落在文件各处的元信息收集进 soinfo。

### PT\_DYNAMIC 的定位

装载阶段已将 SO 搬入内存，但符号表、重定位表、构造函数等所在位置尚未可知——这些信息全部记录在 dynamic 段中，是整个链接过程的信息中枢。本节只做一件事：定位 PT\_DYNAMIC，算出其内存地址存入 dynamic，作为后续解析的入口。

定位方式与查找内存中 PHT 时相同：遍历 phdr，找到 `p_type == PT_DYNAMIC` 的项，取 `load_bias + p_vaddr`。dynamic 段是一个 `ElfW(Dyn)` 数组，以 `ElfW(Dyn)*` 保存。

只取第一个，找到即停，与系统一致。

soinfo.h 新增一个方法声明，其后在 soinfo.cpp 中实现。

```c
bool find_dynamic();
```

soinfo.cpp 实现:

```c
bool soinfo::find_dynamic() {
    for (size_t i = 0; i < phnum; i++) {
        const ElfW(Phdr)* p = &phdr[i];
        if (p->p_type == PT_DYNAMIC) {
            dynamic = reinterpret_cast<ElfW(Dyn)*>(load_bias + p->p_vaddr);
            LOG("[find_dynamic] dynamic at %p (vaddr=0x%lx)",
                dynamic, (unsigned long)p->p_vaddr);
            return true;   
        }
    }
    LOG("[find_dynamic] no PT_DYNAMIC found");
    return false;
}

```

调用放在 parse\_dynamic 开头

```c
bool soinfo::parse_dynamic() {
    LOG("[parse_dynamic] entering");

if (!find_dynamic()) {
        return false;
    }

return true;
}

```

![image](upload/attach/202607/951483_ZTF7YKRTBP5VNQY.png)

### 遍历 d\_tag 的 switch-case

上一步已取得 dynamic 入口，即一个 ElfW(Dyn) 数组。本节从头遍历，每项是一组 <tag, value>，通过一个大 switch 按 tag 将元信息填入 soinfo，遇到 DT_NULL（tag 为 0）终止。

value 有两种含义，切勿混淆，这也是本节最主要的出错点。地址型的 tag（如 STRTAB、SYMTAB、RELA 等）需以 load_bias + d_ptr 换算为内存地址；数值型的 tag（如 RELASZ 及各类计数）则直接取用，不加 bias。

需要处理的 tag 按用途分为几组。字符串表与符号表，分别记录 strtab、symtab 的地址。gnu\_hash 此处只保存表的起点地址，各字段（bucket、chain、bloom）的拆解留到符号查找一节与查找逻辑一并说明；DT\_HASH 现代 SO 一般不含，忽略即可。

重定位相关，ARM64 使用 RELA 而非 32 位的 REL：RELA 为 .rela.dyn 地址，RELASZ 除以 24 得表项数；JMPREL 为 .rela.plt 地址，PLTRELSZ 除以 24 得表项数。PLTREL 的值必须为 DT\_RELA，若为 REL 则报错；dynamic 中一旦出现 DT\_REL、DT\_RELSZ 也报错——以此与 32 位划清界限。

初始化相关，INIT 为老式的单个初始化函数，INIT\_ARRAY 为构造函数数组，INIT\_ARRAYSZ 除以指针大小得表项数。依赖相关，NEEDED 的 value 是 strtab 中的偏移而非地址，须以 strtab + d_val 才能取到名字；由于遍历到 NEEDED 时 strtab 未必已确定，此处先攒下偏移，遍历结束后再统一翻译成名字。

soinfo.h 新增两个临时字段：一个保存 gnu\_hash 表起点，一个保存尚未翻译的 needed 偏移列表。随后在 soinfo.cpp 中实现完整的遍历逻辑，接在 find\_dynamic 之后：遍历时按上述分组填充各字段，遍历结束后将字节数换算为表项数、翻译 needed 名字，并打印各项结果以便核对。

```c
// 组二里加:先只存 gnu_hash 表起点,第五章再拆字段
ElfW(Addr) gnu_hash_base = 0;

// 组五附近加:先攒 needed 的 strtab 偏移,遍历完再翻译
std::vector<ElfW(Xword)> needed_offsets;
```

soinfo.cpp 实现(接在 find\_dynamic 之后):

```c
bool soinfo::parse_dynamic() {
    LOG("[parse_dynamic] entering");

if (!find_dynamic()) {
        return false;
    }

ElfW(Xword) relaent = 0;  
    ElfW(Xword) relasz  = 0;
    ElfW(Xword) pltrelsz = 0;
    ElfW(Xword) init_array_bytes = 0;

for (ElfW(Dyn)* d = dynamic; d->d_tag != DT_NULL; d++) {
        switch (d->d_tag) {

case DT_STRTAB:
                strtab = reinterpret_cast<const char*>(load_bias + d->d_un.d_ptr);
                break;
            case DT_SYMTAB:
                symtab = reinterpret_cast<ElfW(Sym)*>(load_bias + d->d_un.d_ptr);
                break;

case DT_GNU_HASH:
                gnu_hash_base = load_bias + d->d_un.d_ptr;
                break;
            case DT_HASH:
                LOG("[parse_dynamic] found DT_HASH (ignored, using gnu_hash)");
                break;

case DT_RELA:
                rela = reinterpret_cast<ElfW(Rela)*>(load_bias + d->d_un.d_ptr);
                break;
            case DT_RELASZ:
                relasz = d->d_un.d_val;
                break;
            case DT_RELAENT:
                relaent = d->d_un.d_val;
                break;

case DT_JMPREL:
                plt_rela = reinterpret_cast<ElfW(Rela)*>(load_bias + d->d_un.d_ptr);
                break;
            case DT_PLTRELSZ:
                pltrelsz = d->d_un.d_val;
                break;
            case DT_PLTREL:
                if (d->d_un.d_val != DT_RELA) {
                    LOG("[parse_dynamic] DT_PLTREL is not DT_RELA, abort");
                    return false;
                }
                break;

case DT_REL:
            case DT_RELSZ:
                LOG("[parse_dynamic] found REL (32-bit style) on ARM64, abort");
                return false;

case DT_INIT:
                init_func = reinterpret_cast<linker_ctor_function_t>(
                        load_bias + d->d_un.d_ptr);
                break;
            case DT_INIT_ARRAY:
                init_array = reinterpret_cast<linker_ctor_function_t*>(
                        load_bias + d->d_un.d_ptr);
                break;
            case DT_INIT_ARRAYSZ:
                init_array_bytes = d->d_un.d_val;
                break;

case DT_NEEDED:
                needed_offsets.push_back(d->d_un.d_val);
                break;

default:
                break;
        }
    }

if (relaent != 0 && relaent != sizeof(ElfW(Rela))) {
        LOG("[parse_dynamic] RELAENT mismatch: %lu", (unsigned long)relaent);
        return false;
    }
    rela_count      = relasz   / sizeof(ElfW(Rela));
    plt_rela_count  = pltrelsz / sizeof(ElfW(Rela));
    init_array_count = init_array_bytes / sizeof(ElfW(Addr));

if (strtab != nullptr) {
        for (ElfW(Xword) off : needed_offsets) {
            needed_names.push_back(std::string(strtab + off));
        }
    }

LOG("[parse_dynamic] strtab=%p symtab=%p", strtab, symtab);
    LOG("[parse_dynamic] rela=%p count=%zu | plt_rela=%p count=%zu",
        rela, rela_count, plt_rela, plt_rela_count);
    LOG("[parse_dynamic] init_func=%p init_array=%p count=%zu",
        (void*)init_func, (void*)init_array, init_array_count);
    LOG("[parse_dynamic] gnu_hash_base=0x%lx, needed=%zu",
        (unsigned long)gnu_hash_base, needed_names.size());
    for (auto& n : needed_names) {
        LOG("[parse_dynamic]   needed: %s", n.c_str());
    }

return true;
}

```

![image](upload/attach/202607/951483_UA36MK2Z3MF6Z23.png)

## **符号解析**

> 本节解决脱离 dlopen 后符号从何而来的问题：实现自己的符号查找函数，并厘清完全脱离系统的现实边界。

### 实现符号查找函数 my\_lookup\_symbol

先拆解 gnu\_hash 表的布局。从 gnu\_hash\_base 起，头部是 4 个 uint32，依次为 nbucket、symndx、bloom\_size（以 size−1 的形式保存，直接作掩码用）、shift2；其后依次是 bloom 数组、bucket 数组、chain 数组。保存 chain 指针时预先前移 symndx，如此查找时可直接以 gnu_chain[符号下标] 索引，省去一次减法。

查找分三步。第一步算出符号名的 hash，查 bloom 过滤器，只要有一位为 0 即可判定符号不存在，直接返回 0。第二步以 `b`ucket[h % nbucket] 取得起始符号下标，若为 0 表示空桶，返回 0。第三步从起始下标起连续加一遍历：先比较 (chain 值 | 1) == (h | 1)，即抹掉最低位后的高位是否匹配，匹配再用 strcmp 核对真实符号名；chain 值最低位为 1 表示到达链尾，比对完即结束。命中时返回 symtab[n].st_value + load_bias。

命中后必须拦截 SHN\_UNDEF。符号有两类：本 SO 定义的，其 st\_shndx 为正常段号，加 load\_bias 即得真实地址；外部未定义的，其 st\_shndx 等于 SHN\_UNDEF，如 printf，真身在 libc。即便名字匹配到一个 UNDEF 项，也返回 0，以便重定位阶段知晓该走外部兜底。也就是说，lookup\_symbol 只对本 SO 真正定义的符号返回有效地址。

弱符号在此不特殊处理。本实现只加载一个 SO，不存在同名符号的取舍问题，定义了就返回、未定义（含 UNDEF）则返回 0，了解即可。

验证方式：查 add 应得到 base 附近的非零地址；查 printf 应走到 found but UNDEF 分支返回 0，正好验证 UNDEF 逻辑，其真实地址由外部兜底一节解决。

实现分两部分。soinfo.h 新增 init\_gnu\_hash 声明，负责将 gnu\_hash\_base 拆解为各段字段，其实现接在 parse\_dynamic 末尾、gnu\_hash\_base 已确定之后调用。随后在 soinfo.cpp 中实现 gnu\_hash 值的计算函数（djb2 变体）与查找主体 lookup\_symbol。

```c
bool init_gnu_hash();   // 把 gnu_hash_base 拆成各段字段
```

soinfo.cpp,先实现 init\_gnu\_hash:

```c
bool soinfo::init_gnu_hash() {
    if (gnu_hash_base == 0) {
        LOG("[gnu_hash] no DT_GNU_HASH");
        return false;
    }

uint32_t* h = reinterpret_cast<uint32_t*>(gnu_hash_base);

gnu_nbucket   = h[0];          
    gnu_symndx    = h[1];         
    gnu_maskwords = h[2] - 1;      
    gnu_shift2    = h[3];

gnu_bloom_filter = reinterpret_cast<ElfW(Addr)*>(h + 4);

gnu_bucket = reinterpret_cast<uint32_t*>(
            gnu_bloom_filter + (gnu_maskwords + 1));

gnu_chain = gnu_bucket + gnu_nbucket - gnu_symndx;

LOG("[gnu_hash] nbucket=%zu symndx=%u maskwords=%u shift2=%u",
        gnu_nbucket, gnu_symndx, gnu_maskwords, gnu_shift2);
    return true;
}

```

把它接到 parse\_dynamic 结尾(dynamic 都解析完、gnu\_hash\_base 有了之后):

```c
    if (!init_gnu_hash()) {
        return false;
    }
    return true;
```

然后是 gnu\_hash 函数和查找主体:

```c
static uint32_t gnu_hash_calc(const char* name) {
    uint32_t h = 5381;
    for (const char* p = name; *p != '\0'; p++) {
        h = (h << 5) + h + static_cast<uint8_t>(*p); 
    }
    return h;
}

ElfW(Addr) soinfo::lookup_symbol(const char* name) {
    uint32_t h = gnu_hash_calc(name);

constexpr uint32_t kBits = 64;
    ElfW(Addr) word = gnu_bloom_filter[(h / kBits) & gnu_maskwords];
    uint32_t bit1 = h % kBits;
    uint32_t bit2 = (h >> gnu_shift2) % kBits;
    if (((word >> bit1) & 1) == 0 || ((word >> bit2) & 1) == 0) {
        LOG("[lookup] %s: bloom reject", name);
        return 0;
    }

uint32_t n = gnu_bucket[h % gnu_nbucket];
    if (n == 0) {
        LOG("[lookup] %s: empty bucket", name);
        return 0;   
    }

do {
        uint32_t chain_hash = gnu_chain[n];

if (((chain_hash | 1) == (h | 1))) {
            const ElfW(Sym)* sym = &symtab[n];
            const char* sym_name = strtab + sym->st_name;
            if (strcmp(sym_name, name) == 0) {
                if (sym->st_shndx == SHN_UNDEF) {
                    LOG("[lookup] %s: found but UNDEF (external)", name);
                    return 0;   
                }
                ElfW(Addr) addr = sym->st_value + load_bias;
                LOG("[lookup] %s: found at 0x%lx", name, (unsigned long)addr);
                return addr;
            }
        }

if (chain_hash & 1) {
            break;
        }
        n++;  
    } while (true);

LOG("[lookup] %s: not found", name);
    return 0;
}

```

单独测一下这个查找函数。可以在 parse\_dynamic 成功之后(重定位之前也行)临时加一行,查 add 看看:

```c
    ElfW(Addr) a = si->lookup_symbol("add");
    LOG("[test] lookup add = 0x%lx", (unsigned long)a);
```

![image](upload/attach/202607/951483_BRUM4SK2DBS5QJJ.png)

### 外部符号的边界与兜底

加载目标 SO 的全过程——装载、解析、符号处理、重定位、初始化——均由本实现手动完成，不调用系统加载器。但目标 SO 依赖 libc、libm 等系统基础库中的外部符号，如 printf，这类符号的地址需要另行获取。此处采用有限度的兜底：从系统中查询这些符号已有的地址。这些系统库本就存在于当前进程空间，此处只是查询其现成地址，并非重新加载它们。

获取外部符号地址有两种方案。其一，用 dlsym 在当前进程已加载的全部库中按序查找该符号。其二，读取 /proc/self/maps 找到目标库的基址，将其也视作一个内存中的 SO，套用前面查找 dynamic、拆解 gnu\_hash、lookup\_symbol 的整套流程，在它的符号表中查 printf。第二种方案更为繁琐，此处采用第一种。

需要说明，这一步是整个实现中唯一借助系统能力的地方，也是完全脱离 dlopen 的现实边界所在。若要做到彻底不依赖，须走第二种方案，把 libc 也当作一份内存镜像自行解析——本实现为求简洁选择了第一种。

soinfo.h 新增 resolve\_symbol 声明，soinfo.cpp 顶部补充 dlfcn.h 头文件。实现逻辑为：先用自写的 lookup\_symbol 在本 SO 内查找，命中即返回；本地没有（如 SHN\_UNDEF）时，再用 `dlsym(RTLD_DEFAULT, name)` 向系统兜底；两者皆无则判定符号无法解析。

```c
ElfW(Addr) resolve_symbol(const char* name);   
```

soinfo.cpp 顶部加头文件:

```c
#include <dlfcn.h>
```

soinfo.cpp实现：

```c
ElfW(Addr) soinfo::resolve_symbol(const char* name) {
    
    ElfW(Addr) local = lookup_symbol(name);
    if (local != 0) {
        return local;
    }

void* ext = dlsym(RTLD_DEFAULT, name);
    if (ext != nullptr) {
        LOG("[resolve] %s: external via dlsym = %p", name, ext);
        return reinterpret_cast<ElfW(Addr)>(ext);
    }

LOG("[resolve] %s: UNRESOLVED", name);
    return 0;
}

```

![image](upload/attach/202607/951483_CWDGJDRTNBUY7XV.png)

## **重定位：ARM64 RELA 修正**

### 重定位流程与 RELA 表项解析

重定位的作用在于：SO 加载到运行前才确定的基址（load\_bias），代码与数据中大量地址在编译期无法确定，需在加载时按表逐条修正为正确值。

重定位信息存于两张表。.rela.dyn（对应 rela）管数据类，如全局指针、GOT 数据项；.rela.plt（对应 plt\_rela）管 PLT 跳转，如 printf 这类外部函数。两表结构均为 Elf64\_Rela，处理逻辑相同，仅来源不同，因此实现一个处理单表的函数，relocate 对两表各调用一次。

Elf64\_Rela 有三个字段。r\_offset 是被修正的位置，为文件虚拟地址，实际内存地址为 r_offset + load_bias。r\_info 打包了类型与符号下标，用 ELF64_R_TYPE 取类型、ELF64_R_SYM 取符号表下标；64 位下类型在低 32 位、符号在高 32 位，而 32 位下类型占低 8 位、符号占高 24 位，这是与 32 位差异最大、最易出错之处，须使用 ELF64\_ 宏，不可手写位运算。r\_addend 是显式加数，也是 RELA 相对 REL 的本质区别所在——REL 没有此字段，须从被修改位置读取原值作为隐式加数，而 RELA 直接使用 r\_addend，无需读取原内存；ARM64 统一使用 RELA。

本节只搭骨架：遍历两表，拆出 type、sym\_index、addend，算出修正地址 r_offset + load_bias，进入 switch。各类型的具体公式在下一节实现，本节 switch 的分支暂时留空并打印日志。

soinfo.h 新增一个处理单张表的私有方法声明，其后在 soinfo.cpp 中实现 relocate 与 relocate\_table。

```c
bool relocate_table(ElfW(Rela)* table, size_t count);
```

soinfo.cpp 实现 relocate 与 relocate\_table:

```c
bool soinfo::relocate() {
    LOG("[relocate] entering");

if (rela != nullptr && rela_count > 0) {
        LOG("[relocate] .rela.dyn: %zu entries", rela_count);
        if (!relocate_table(rela, rela_count)) {
            return false;
        }
    }

if (plt_rela != nullptr && plt_rela_count > 0) {
        LOG("[relocate] .rela.plt: %zu entries", plt_rela_count);
        if (!relocate_table(plt_rela, plt_rela_count)) {
            return false;
        }
    }

LOG("[relocate] done");
    return true;
}

bool soinfo::relocate_table(ElfW(Rela)* table, size_t count) {
    for (size_t i = 0; i < count; i++) {
        ElfW(Rela)* r = &table[i];

uint32_t type      = ELF64_R_TYPE(r->r_info);   
        uint32_t sym_index = ELF64_R_SYM(r->r_info);    
        ElfW(Sxword) addend = r->r_addend;

ElfW(Addr)* reloc = reinterpret_cast<ElfW(Addr)*>(load_bias + r->r_offset);

LOG("[reloc] [%zu] type=%u sym=%u offset=0x%lx addend=%ld -> reloc=%p",
            i, type, sym_index,
            (unsigned long)r->r_offset, (long)addend, reloc);

switch (type) {
            // TODO
            default:
                LOG("[reloc] [%zu] type %u not handled yet", i, type);
                break;
        }
    }
    return true;
}
```

### 四类 ARM64 重定位的实现

本节填充上一节 switch 的四个分支，各按公式算出结果写入 reloc，完成后 SO 内的地址即全部修正到位。

其中 GLOB\_DAT、JUMP\_SLOT、ABS64 三类需要符号地址，处理前先以 sym\_index 在 symtab 中取出符号、取到符号名，调用 resolve\_symbol 得到 sym\_addr；RELATIVE 不涉及符号，跳过此步。

四种类型的公式与含义如下。R\_AARCH64\_RELATIVE 为 *reloc = load_bias + addend，修正指向本 SO 内部的指针，目标由基址决定，不查符号，对应 32 位的 R\_ARM\_RELATIVE（后者无 addend，须读原值），前面验证点中的 g\_msg 即属此类。R\_AARCH64\_GLOB\_DAT 为 *reloc = sym_addr + addend，用于 GOT 数据项，指向某符号，须先查出符号地址。R\_AARCH64\_JUMP\_SLOT 为 *reloc = sym_addr，用于 PLT 跳转，对应外部函数如 printf，addend 恒为 0。R\_AARCH64\_ABS64 为 *reloc = sym_addr + addend，写入符号的 64 位绝对地址。

RELATIVE 用 load\_bias、其余用 sym\_addr，原因在于：RELATIVE 的目标必在本 SO 内部，地址由 load\_bias 决定；其余指向具名符号，须查出其真实所在，可能位于 libc。addend 在各类型中统一表示基址之上的固定偏移。

失败处理上，JUMP\_SLOT 等外部符号在 resolve\_symbol 返回 0 时报错终止，绝不填 0——填 0 会在调用时崩溃且难以排查。弱符号允许为 0，但本实现不涉及，一律按查不到即报错处理。

在 soinfo.cpp 中将上一节 relocate\_table 的 switch 补全。

```c
bool soinfo::relocate_table(ElfW(Rela)* table, size_t count) {
    for (size_t i = 0; i < count; i++) {
        ElfW(Rela)* r = &table[i];

uint32_t type      = ELF64_R_TYPE(r->r_info);
        uint32_t sym_index = ELF64_R_SYM(r->r_info);
        ElfW(Sxword) addend = r->r_addend;

ElfW(Addr)* reloc = reinterpret_cast<ElfW(Addr)*>(load_bias + r->r_offset);

ElfW(Addr) sym_addr = 0;
        if (type == R_AARCH64_GLOB_DAT ||
            type == R_AARCH64_JUMP_SLOT ||
            type == R_AARCH64_ABS64) {
            const char* sym_name = strtab + symtab[sym_index].st_name;
            sym_addr = resolve_symbol(sym_name);
            if (sym_addr == 0) {
                LOG("[reloc] [%zu] cannot resolve symbol: %s", i, sym_name);
                return false;  
            }
        }

switch (type) {
            case R_AARCH64_RELATIVE:
                *reloc = load_bias + addend;
                break;

case R_AARCH64_GLOB_DAT:
                *reloc = sym_addr + addend;
                break;

case R_AARCH64_JUMP_SLOT:
                *reloc = sym_addr;
                break;

case R_AARCH64_ABS64:
                *reloc = sym_addr + addend;
                break;

default:
                LOG("[reloc] [%zu] unknown type %u, skip", i, type);
                break;
        }
    }
    return true;
}
```

## **初始化：手动触发构造函数**

### call\_constructors实现

至此 SO 已装载、解析、重定位完毕，本节手动触发它的构造函数，使其初始化逻辑真正执行。

构造函数有两个来源，须按固定顺序调用：先执行 DT\_INIT 指向的老式单个初始化函数，再执行 DT\_INIT\_ARRAY 数组中的各构造函数。call\_constructors 即负责这一流程，并以 constructors\_called 标志防止重复初始化。

soinfo.h 新增两个工具方法声明——call\_function 与 call\_array，其实现放在下一节。随后在 soinfo.cpp 中实现 call\_constructors，call\_function 与 call\_array 此处先留空。

```c
void call_function(linker_ctor_function_t func);
void call_array(linker_ctor_function_t* array, size_t count);
```

soinfo.cpp 实现 call\_constructors

```c
void soinfo::call_constructors() {
    if (constructors_called) {
        return;
    }
    constructors_called = true;

LOG("[call_constructors] start");

if (init_func != nullptr) {
        LOG("[call_constructors] calling DT_INIT %p", (void*)init_func);
        call_function(init_func);
    }

if (init_array != nullptr && init_array_count > 0) {
        LOG("[call_constructors] calling DT_INIT_ARRAY, count=%zu",
            init_array_count);
        call_array(init_array, init_array_count);
    }

LOG("[call_constructors] done");
}

void soinfo::call_function(linker_ctor_function_t func) {

}

void soinfo::call_array(linker_ctor_function_t *array, size_t count) {
    
}
```

### call\_function 与 call\_array 的实现

本节在 soinfo.cpp 中实现这两个函数。call\_function 调用单个函数，调用前先排除两个哨兵值——0（空）和 -1（全 1），二者都不是合法地址，遇到即跳过，其余视为合法地址直接调用。call\_array 正序遍历数组（从 0 到 count−1），对每一项调用 call\_function。

```c
void soinfo::call_function(linker_ctor_function_t func) {
    if (func == nullptr ||
        reinterpret_cast<ElfW(Addr)>(func) == static_cast<ElfW(Addr)>(-1)) {
        return;
    }

func();
}

void soinfo::call_array(linker_ctor_function_t* array, size_t count) {
    for (size_t i = 0; i < count; i++) {
        LOG("[call_array] [%zu] %p", i, (void*)array[i]);
        call_function(array[i]);
    }
}

```

至此 整个so已经加载完毕了 理论上来说是可以看得到`libtarget`init函数打印的日志的，但是你会发现日志无论怎么筛选都死活找不到init函数答应的那段日志。构造函数其实一直执行成功,只是原来的 printf 输出到了 stdout,而 Android app 的 stdout 默认不接入 logcat,所以看不见——换成 `__android_log_print` 后就显示了,加载器全程没有任何问题。

这里就需要对`libtarget`代码做小小的修改即可 把 libtarget.c 的 my\_constructor 改成用 `__android_log_print`

```c
#include <android/log.h>
__attribute__((constructor))
static void my_constructor(void) {
    __android_log_print(ANDROID_LOG_INFO, "target",
        "my_constructor called (init_array), g_msg=%s", g_msg);
}
```

将修改后的so重新编译，注意：需要在之前的编译命令基础上末尾新增一个-llog就行了

```c
& "D:\environment\_SDK\ndk\25.1.8937393\toolchains\llvm\prebuilt\windows-x86_64\bin\aarch64-linux-android31-clang.cmd" -shared -fPIC -o "$PWD\libtarget.so" "$PWD\libtarget.c" -llog
```

编译完把新的 libtarget.so 复制到 `app/src/main/jniLibs/arm64-v8a/` 覆盖旧的,然后照旧 Clean Project → Rebuild → 运行。

![image](upload/attach/202607/951483_JE4YEPUQEY9KN9C.png)

## **收官：自实现 dlsym 与函数调用**

### my\_dlsym 的实现

这一步实际无需新增代码。搭建 MyLinker 调用链框架时，MyLinker::dlsym 已写好这段转发——它打印查找日志，再调用 soinfo 的 lookup\_symbol 返回符号地址。因此此处日志中早已有相应输出。

```c
ElfW(Addr) Mylinker::dlsym(soinfo* si, const char* name) {
    LOG("[dlsym] lookup: %s", name);
    return si->lookup_symbol(name);
}
```

![image](upload/attach/202607/951483_7HA6Y3H7YUP8VP6.png)

### 函数指针转换与结果验证

```c
#include <jni.h>
#include <string>
#include <android/log.h>
#include "soinfo.h"
#include "mylinker.h"

#define LOG(...) __android_log_print(ANDROID_LOG_INFO, "myloader", __VA_ARGS__)

extern "C" JNIEXPORT void JNICALL
Java_com_example_myapplication_MainActivity_runLoaderRef(
        JNIEnv* env, jobject, jstring nativeLibDir) {

const char* dir = env->GetStringUTFChars(nativeLibDir, nullptr);
    std::string path = std::string(dir) + "/libtarget.so";
    env->ReleaseStringUTFChars(nativeLibDir, dir);

Mylinker linker;

soinfo* si = linker.dlopen(path.c_str());
    if (!si) {
        LOG("my dlopen failed");
        return;
    }

ElfW(Addr) add_addr = linker.dlsym(si, "add");
    if (add_addr == 0) {
        LOG("my dlsym(add) failed");
        return;
    }

typedef int (*add_t)(int, int);
    add_t add_fn = reinterpret_cast<add_t>(add_addr);

int r = add_fn(3, 4);
    LOG("[MVP] add(3,4) = %d (expect 7)", r);

if (r == 7) {
        LOG("[MVP] SUCCESS: custom linker works end-to-end!");
    } else {
        LOG("[MVP] FAILED: got %d", r);
    }
}

```

![image](upload/attach/202607/951483_SZ9KS556ZDJE6E4.png)

![image](upload/attach/202607/951483_HXKDQG4Q5AV6VDY.png)

## 结语

至此，一个不依赖系统 dlopen / dlsym 的 ARM64 加载器已完整跑通：从读文件头、映射段、解析 dynamic，到符号查找、重定位、触发构造，最终用自写的 dlsym 取到 add 的地址并调用成功，结果与系统 dlopen 一致。这套流程只覆盖了单个 SO 的加载与调用，析构、TLS、符号版本等一律略去，外部符号也仍借助系统查询兜底，算不上完全脱离。这份实现是后续理解加壳与脱壳的地基。匿名内存加载、抹除 ELF 头、运行时解密段等对抗手法，都建立在这条链路之上 留待下一篇 欢迎大佬对本文误述内容进行勘正与讨论。

## 参考

https://bbs.kanxue.com/thread-269891.htm#msg_header_h2_2

https://bbs.kanxue.com/thread-282316.htm#msg_header_h2_5

https://bbs.kanxue.com/thread-287254.htm#msg_header_h2_4

‍

回复或点赞可查看完整内容

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。

最后于 2026-7-17 16:04 被北袅编辑，原因：

#程序开发

收藏・21

点赞・100

打赏

赞赏记录

参与人

雪币

留言

时间

ONewTach

感谢你分享这么好的资源！

2天前

riversky

你的帖子非常有用，感谢分享！

3天前

mb_dvqqrcce

你的帖子非常有用，感谢分享！

2026-9-11 17:25

git_51951meggadf3df

非常支持你的观点！

2026-9-10 18:28

mb_imnrancw

感谢你的贡献，论坛因你而更加精彩！

2026-9-9 15:06

晨曦。

为你点赞！

2026-9-9 07:27

张楚岚.

为你点赞！

2026-9-8 14:01

fu11p7r

期待更多优质内容的分享，论坛有你更精彩！

2026-9-7 22:36

铭信

你的帖子非常有用，感谢分享！

2026-9-7 22:03

git_12503yowal2024

感谢你的积极参与，期待更多精彩内容！

2026-8-31 16:58

git_611581046733355

你的分享对大家帮助很大，非常感谢！

2026-8-31 00:38

aeolusw

这个讨论对我很有帮助，谢谢！

2026-8-30 21:43

Love 2016

感谢你的贡献，论坛因你而更加精彩！

2026-8-27 00:11

mb_lthgjpwj

为你点赞！

2026-8-20 16:27

mb_koruzmnv

感谢你的积极参与，期待更多精彩内容！

2026-8-17 20:00

wangzehua

期待更多优质内容的分享，论坛有你更精彩！

2026-8-13 09:28

R3v

你的分享对大家帮助很大，非常感谢！

2026-8-13 03:30

mb_wsoacceo

为你点赞！

2026-8-8 00:27

mb_hrfyprtl

非常支持你的观点！

2026-8-3 15:06

SX_DomOne

这个讨论对我很有帮助，谢谢！

2026-8-2 21:45

gongchuang

期待更多优质内容的分享，论坛有你更精彩！

2026-8-1 10:50

天地一逆旅

谢谢你的细致分析，受益匪浅！

2026-8-1 09:43

Wika

谢谢你的细致分析，受益匪浅！

2026-7-31 15:00

苦瓜.

为你点赞！

2026-7-31 14:14

U3D_Modder

谢谢你的细致分析，受益匪浅！

2026-7-31 13:19

mb_dbpeontu

你的分享对大家帮助很大，非常感谢！

2026-7-30 17:01

coNg叶

你的分享对大家帮助很大，非常感谢！

2026-7-30 16:27

cppasm

感谢你分享这么好的资源！

2026-7-29 10:41

haaYv

你的分享对大家帮助很大，非常感谢！

2026-7-29 08:39

wx_funcrever

非常支持你的观点！

2026-7-28 17:06

便胜晴天

这个讨论对我很有帮助，谢谢！

2026-7-27 21:45

mb_cwpkokuo

为你点赞！

2026-7-27 15:59

mb_unqkfdlq

感谢你的贡献，论坛因你而更加精彩！

2026-7-26 15:44

mb_mrjjcxgk

期待更多优质内容的分享，论坛有你更精彩！

2026-7-26 00:33

my_name

感谢你分享这么好的资源！

2026-7-25 11:36

Ally Switch

为你点赞！

2026-7-25 11:06

叶晓枫A

这个讨论对我很有帮助，谢谢！

2026-7-25 09:47

reserve_zhou

感谢你分享这么好的资源！

2026-7-24 22:06

focaccia

感谢你分享这么好的资源！

2026-7-24 17:05

镜中人24

谢谢你的细致分析，受益匪浅！

2026-7-24 14:34

taeyeon_ss

为你点赞！

2026-7-24 09:59

王叔叔

非常支持你的观点！

2026-7-24 09:31

wx_Q道长

为你点赞！

2026-7-23 23:29

mb_qecctkwn

非常支持你的观点！

2026-7-23 18:50

飞翔的猫咪

为你点赞！

2026-7-23 18:13

17340307464

期待更多优质内容的分享，论坛有你更精彩！

2026-7-23 17:10

MsScotch

非常支持你的观点！

2026-7-23 17:06

mb_noeuaplg

为你点赞！

2026-7-23 16:56

Seem_Black

感谢你分享这么好的资源！

2026-7-23 15:59

NPC2000

非常支持你的观点！

2026-7-23 13:52

EPs1l0h

为你点赞！

2026-7-22 22:20

学会规则

为你点赞！

2026-7-22 19:32

cydian

期待更多优质内容的分享，论坛有你更精彩！

2026-7-22 18:36

yhock

这个讨论对我很有帮助，谢谢！

2026-7-22 09:36

doamzo

谢谢你的细致分析，受益匪浅！

2026-7-22 08:25

git_65827AvailablFrom

谢谢你的细致分析，受益匪浅！

2026-7-22 01:09

寻影星尘

非常支持你的观点！

2026-7-21 20:54

hacker521

谢谢你的细致分析，受益匪浅！

2026-7-21 18:28

孤独的街

感谢你的贡献，论坛因你而更加精彩！

2026-7-21 16:51

dsr000

感谢你的贡献，论坛因你而更加精彩！

2026-7-21 13:53

AGSFGBKILO

你的分享对大家帮助很大，非常感谢！

2026-7-21 11:32

Red

感谢你分享这么好的资源！

2026-7-21 08:42

奇奇怪怪

期待更多优质内容的分享，论坛有你更精彩！

2026-7-20 17:33

灬哈密瓜

为你点赞！

2026-7-20 09:13

破执.

这个讨论对我很有帮助，谢谢！

2026-7-20 00:44

mb_icbgiifu

感谢你的积极参与，期待更多精彩内容！

2026-7-19 18:25

mb_kgfqphsx

为你点赞！

2026-7-19 10:57

zxhk

感谢你分享这么好的资源！

2026-7-19 06:28

saykao

你的分享对大家帮助很大，非常感谢！

2026-7-19 02:31

mb_uaoofzgb

这个讨论对我很有帮助，谢谢！

2026-7-19 01:28

by_Lin

你的分享对大家帮助很大，非常感谢！

2026-7-19 00:43

mb_bvvcoitr

感谢你的积极参与，期待更多精彩内容！

2026-7-18 23:30

xxxark

你的分享对大家帮助很大，非常感谢！

2026-7-18 22:28

墨穹呢

谢谢你的细致分析，受益匪浅！

2026-7-18 17:42

bluegatar

感谢你的积极参与，期待更多精彩内容！

2026-7-18 17:38

开胃小菜Wx

你的帖子非常有用，感谢分享！

2026-7-18 15:26

mb_pnrjfxiv

为你点赞！

2026-7-18 14:01

mb_rjdrqvpa

感谢你的积极参与，期待更多精彩内容！

2026-7-18 13:41

mb_liueenqt

感谢你分享这么好的资源！

2026-7-18 13:24

梧桐生

为你点赞！

2026-7-18 10:02

东方玻璃

感谢你的贡献，论坛因你而更加精彩！

2026-7-18 01:56

mb_cebxltxx

为你点赞！

2026-7-18 00:43

huangyalei

非常支持你的观点！

2026-7-18 00:34

x1a0f3n9

谢谢你的细致分析，受益匪浅！

2026-7-18 00:13

带带弟弟吧

非常支持你的观点！

2026-7-17 23:23

RedSand07

感谢你分享这么好的资源！

2026-7-17 22:40

mb_bppcorlj

感谢你分享这么好的资源！

2026-7-17 22:07

nxlite

这个讨论对我很有帮助，谢谢！

2026-7-17 21:51

mb_asiwnxyv

这个讨论对我很有帮助，谢谢！

2026-7-17 21:10

绿雪羚羊

感谢你的贡献，论坛因你而更加精彩！

2026-7-17 20:23

pexillove

为你点赞！

2026-7-17 19:47

mb_cfjwplfo

这个讨论对我很有帮助，谢谢！

2026-7-17 19:11

nuomida

你的帖子非常有用，感谢分享！

2026-7-17 17:39

醉染

期待更多优质内容的分享，论坛有你更精彩！

2026-7-17 17:35

mb_iesvmzqc

感谢你的积极参与，期待更多精彩内容！

2026-7-17 17:25

qqizai

期待更多优质内容的分享，论坛有你更精彩！

2026-7-17 17:10

你瞒我瞒

谢谢你的细致分析，受益匪浅！

2026-7-17 17:07

欲拭泪

你的分享对大家帮助很大，非常感谢！

2026-7-17 16:57

顽劣

这个讨论对我很有帮助，谢谢！

2026-7-17 16:44

wx_0.0_522

谢谢你的细致分析，受益匪浅！

2026-7-17 16:11

最新回复 (46) 1 2 ▶
你瞒我瞒雪币： 3421 活跃值： (12739) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 269 粉丝 8 关注私信	你瞒我瞒 2 楼厉害啊 2026-7-17 17:08 0
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 689 粉丝 7 关注私信	mb_ldbucrik 3 楼向大佬学习 2026-7-17 23:33 0
Zepp7289 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 137 粉丝 0 关注私信	Zepp7289 4 楼自实现linker最后再调用一次dlopen是为了啥，那不是又走了一遍系统link 2026-7-18 14:53 1
学计算机睡觉雪币： 779 活跃值： (1231) 能力值： ( LV3，RANK：30 ) 在线值：发帖 3 回帖 94 粉丝 4 关注私信	学计算机睡觉 5 楼看看 2026-7-18 17:31 0
SomeMx 雪币： 4156 活跃值： (5534) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 158 粉丝 1 关注私信	SomeMx 6 楼过来瞧瞧 2026-7-18 17:37 0
iBa0 雪币： 1560 活跃值： (5823) 能力值： ( LV4，RANK：40 ) 在线值：发帖 6 回帖 481 粉丝 37 关注私信	iBa0 7 楼去 2026-7-18 22:17 0
珍惜Any 雪币： 6737 活跃值： (17074) 能力值： ( LV9，RANK：270 ) 在线值：发帖 31 回帖 483 粉丝 1811 关注私信	珍惜Any 4 8 楼这个支持的版本是多少，我最近想搞一个，就是ptrace注入so文件不在目标进程调用dlopen打开，防止目标app hook dlopen被检测。 2026-7-19 00:31 0
mb_urzqsoer 雪币： 206 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 118 粉丝 0 关注私信	mb_urzqsoer 9 楼 66666666666 2026-7-19 00:45 0
北袅雪币： 2611 活跃值： (3111) 能力值： ( LV7，RANK：100 ) 在线值：发帖 5 回帖 45 粉丝 33 关注私信	北袅 2 10 楼 Mylinker linker; soinfo* si = linker.dlopen(path.c_str()); if (!si) { LOG("my dlopen failed"); return; }这里走的是自己申明的linker 2026-7-19 13:59 0
北袅雪币： 2611 活跃值： (3111) 能力值： ( LV7，RANK：100 ) 在线值：发帖 5 回帖 45 粉丝 33 关注私信	北袅 2 11 楼 Zepp7289 自实现linker最后再调用一次dlopen是为了啥，那不是又走了一遍系统link Mylinker linker; soinfo* si = linker.dlopen(path.c_str()); if (!si) { LOG("my dlopen failed"); return; }这里走的是自己申明的linker 2026-7-19 14:00 0
北袅雪币： 2611 活跃值： (3111) 能力值： ( LV7，RANK：100 ) 在线值：发帖 5 回帖 45 粉丝 33 关注私信	北袅 2 12 楼珍惜Any 这个支持的版本是多少，我最近想搞一个，就是ptrace注入so文件不在目标进程调用dlopen打开，防止目标app hook dlopen被检测。这套方案能跑安卓12,再高点版本（15、16）或者稍微复杂点so需要做一些细节上的调整，page size、soinfo结构、析构...... 唯一用到一个dlsym也可以用自解析maps去定位外部符号 2026-7-19 14:00 0
珍惜Any 雪币： 6737 活跃值： (17074) 能力值： ( LV9，RANK：270 ) 在线值：发帖 31 回帖 483 粉丝 1811 关注私信	珍惜Any 4 13 楼北袅这套方案能跑安卓12,再高点版本（15、16）或者稍微复杂点so需要做一些细节上的调整，page size、soinfo结构、析构...... 唯一用到一个dlsym也可以用自解析maps去定位外部符 ... 那不行，我需要一个12+都可以兼容的，你让AI看看源码，看看能不能兼容一下。 2026-7-19 14:23 0
mb_bvvcoitr 雪币： 30 活跃值： (1511) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 24 粉丝 6 关注私信	mb_bvvcoitr 14 楼珍惜Any 这个支持的版本是多少，我最近想搞一个，就是ptrace注入so文件不在目标进程调用dlopen打开，防止目标app hook dlopen被检测。你看下rezygisk有个远程的csoloader。zn也有，但是不能开源。主要就是自行重定位。最后于 2026-7-19 17:56 被mb_bvvcoitr编辑，原因： 2026-7-19 17:55 0
uni7corn 雪币： 0 活跃值： (2440) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 182 粉丝 0 关注私信	uni7corn 15 楼感谢分享 2026-7-20 23:31 0
mb_audxeeaj 雪币： 337 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 24 粉丝 6 关注私信	mb_audxeeaj 16 楼向大佬学习 2026-7-21 17:04 0
丶咖啡猫丶雪币： 2751 活跃值： (3951) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 177 粉丝 4 关注私信	丶咖啡猫丶 17 楼 666 2026-7-22 19:04 0
Thehepta 雪币： 3596 活跃值： (7395) 能力值： ( LV11，RANK：185 ) 在线值：发帖 23 回帖 235 粉丝 282 关注私信	Thehepta 3 18 楼 1 2026-7-22 19:35 0
koflfy 雪币： 102 活跃值： (4066) 能力值： ( LV4，RANK：50 ) 在线值：发帖 8 回帖 480 粉丝 5 关注私信	koflfy 1 19 楼 mark 2026-7-23 15:43 0
CheRevir 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 85 粉丝 0 关注私信	CheRevir 20 楼 666 2026-7-23 16:42 0
mb_euhyowpw 雪币： 2 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 149 粉丝 0 关注私信	mb_euhyowpw 21 楼 666 2026-7-23 17:35 0
mb_jhohnbzu 雪币： 28 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 82 粉丝 0 关注私信	mb_jhohnbzu 22 楼 666 2026-7-23 18:19 0
櫬木汐雪币： 360 活跃值： (937) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 35 粉丝 18 关注私信	櫬木汐 23 楼 111 2026-7-23 18:28 0
xxjj678 雪币： 4 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 83 粉丝 1 关注私信	xxjj678 24 楼 6666 2026-7-23 18:51 0
mb_cbgtaveo 雪币： 292 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 253 粉丝 0 关注私信	mb_cbgtaveo 25 楼 66666666 2026-7-23 21:38 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

北袅

发帖

回帖

100

RANK

关注

私信

他的文章

关于我们

联系我们

企业服务

看雪公众号

最新回复 (46) 1 2 ▶
你瞒我瞒雪币： 3421 活跃值： (12739) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 269 粉丝 8 关注私信	你瞒我瞒 2 楼厉害啊 2026-7-17 17:08 0
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 689 粉丝 7 关注私信	mb_ldbucrik 3 楼向大佬学习 2026-7-17 23:33 0
Zepp7289 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 137 粉丝 0 关注私信	Zepp7289 4 楼自实现linker最后再调用一次dlopen是为了啥，那不是又走了一遍系统link 2026-7-18 14:53 1
学计算机睡觉雪币： 779 活跃值： (1231) 能力值： ( LV3，RANK：30 ) 在线值：发帖 3 回帖 94 粉丝 4 关注私信	学计算机睡觉 5 楼看看 2026-7-18 17:31 0
SomeMx 雪币： 4156 活跃值： (5534) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 158 粉丝 1 关注私信	SomeMx 6 楼过来瞧瞧 2026-7-18 17:37 0
iBa0 雪币： 1560 活跃值： (5823) 能力值： ( LV4，RANK：40 ) 在线值：发帖 6 回帖 481 粉丝 37 关注私信	iBa0 7 楼去 2026-7-18 22:17 0
珍惜Any 雪币： 6737 活跃值： (17074) 能力值： ( LV9，RANK：270 ) 在线值：发帖 31 回帖 483 粉丝 1811 关注私信	珍惜Any 4 8 楼这个支持的版本是多少，我最近想搞一个，就是ptrace注入so文件不在目标进程调用dlopen打开，防止目标app hook dlopen被检测。 2026-7-19 00:31 0
mb_urzqsoer 雪币： 206 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 118 粉丝 0 关注私信	mb_urzqsoer 9 楼 66666666666 2026-7-19 00:45 0
北袅雪币： 2611 活跃值： (3111) 能力值： ( LV7，RANK：100 ) 在线值：发帖 5 回帖 45 粉丝 33 关注私信	北袅 2 10 楼 Mylinker linker; soinfo* si = linker.dlopen(path.c_str()); if (!si) { LOG("my dlopen failed"); return; }这里走的是自己申明的linker 2026-7-19 13:59 0
北袅雪币： 2611 活跃值： (3111) 能力值： ( LV7，RANK：100 ) 在线值：发帖 5 回帖 45 粉丝 33 关注私信	北袅 2 11 楼 Zepp7289 自实现linker最后再调用一次dlopen是为了啥，那不是又走了一遍系统link Mylinker linker; soinfo* si = linker.dlopen(path.c_str()); if (!si) { LOG("my dlopen failed"); return; }这里走的是自己申明的linker 2026-7-19 14:00 0
北袅雪币： 2611 活跃值： (3111) 能力值： ( LV7，RANK：100 ) 在线值：发帖 5 回帖 45 粉丝 33 关注私信	北袅 2 12 楼珍惜Any 这个支持的版本是多少，我最近想搞一个，就是ptrace注入so文件不在目标进程调用dlopen打开，防止目标app hook dlopen被检测。这套方案能跑安卓12,再高点版本（15、16）或者稍微复杂点so需要做一些细节上的调整，page size、soinfo结构、析构...... 唯一用到一个dlsym也可以用自解析maps去定位外部符号 2026-7-19 14:00 0
珍惜Any 雪币： 6737 活跃值： (17074) 能力值： ( LV9，RANK：270 ) 在线值：发帖 31 回帖 483 粉丝 1811 关注私信	珍惜Any 4 13 楼北袅这套方案能跑安卓12,再高点版本（15、16）或者稍微复杂点so需要做一些细节上的调整，page size、soinfo结构、析构...... 唯一用到一个dlsym也可以用自解析maps去定位外部符 ... 那不行，我需要一个12+都可以兼容的，你让AI看看源码，看看能不能兼容一下。 2026-7-19 14:23 0
mb_bvvcoitr 雪币： 30 活跃值： (1511) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 24 粉丝 6 关注私信	mb_bvvcoitr 14 楼珍惜Any 这个支持的版本是多少，我最近想搞一个，就是ptrace注入so文件不在目标进程调用dlopen打开，防止目标app hook dlopen被检测。你看下rezygisk有个远程的csoloader。zn也有，但是不能开源。主要就是自行重定位。最后于 2026-7-19 17:56 被mb_bvvcoitr编辑，原因： 2026-7-19 17:55 0
uni7corn 雪币： 0 活跃值： (2440) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 182 粉丝 0 关注私信	uni7corn 15 楼感谢分享 2026-7-20 23:31 0
mb_audxeeaj 雪币： 337 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 24 粉丝 6 关注私信	mb_audxeeaj 16 楼向大佬学习 2026-7-21 17:04 0
丶咖啡猫丶雪币： 2751 活跃值： (3951) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 177 粉丝 4 关注私信	丶咖啡猫丶 17 楼 666 2026-7-22 19:04 0
Thehepta 雪币： 3596 活跃值： (7395) 能力值： ( LV11，RANK：185 ) 在线值：发帖 23 回帖 235 粉丝 282 关注私信	Thehepta 3 18 楼 1 2026-7-22 19:35 0
koflfy 雪币： 102 活跃值： (4066) 能力值： ( LV4，RANK：50 ) 在线值：发帖 8 回帖 480 粉丝 5 关注私信	koflfy 1 19 楼 mark 2026-7-23 15:43 0
CheRevir 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 85 粉丝 0 关注私信	CheRevir 20 楼 666 2026-7-23 16:42 0
mb_euhyowpw 雪币： 2 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 149 粉丝 0 关注私信	mb_euhyowpw 21 楼 666 2026-7-23 17:35 0
mb_jhohnbzu 雪币： 28 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 82 粉丝 0 关注私信	mb_jhohnbzu 22 楼 666 2026-7-23 18:19 0
櫬木汐雪币： 360 活跃值： (937) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 35 粉丝 18 关注私信	櫬木汐 23 楼 111 2026-7-23 18:28 0
xxjj678 雪币： 4 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 83 粉丝 1 关注私信	xxjj678 24 楼 6666 2026-7-23 18:51 0
mb_cbgtaveo 雪币： 292 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 253 粉丝 0 关注私信	mb_cbgtaveo 25 楼 66666666 2026-7-23 21:38 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复