// ========================================

// 开始: builtin-plugin\BionicLinkerRestriction\bionic_linker_restriction.h

// 这是一个"头文件"（可以理解为一份说明书或目录，告诉其他代码文件这里有哪些功能可以使用）。头文件的内容通过预处理指令被复制进源文件，其中仅包含声明的部分不产生目标代码，但其中包含的实现（内联/模板/类内定义）会产生代码并最终进入可执行文件。

// 主要功能：提供了一系列用于操作Android系统中已加载库文件的工具函数

// 例如：打开一个库文件、获取库文件的路径、禁用某些限制等

// ========================================

#ifndef LINKER_RESTRICTION_H   //通过自定义宏，"防重复包含"的保护措施， 保证只包含一次，一般都可以这么定义。想象一下：如果同一份说明书被复印了很多份分发出去，但我们只需要一份， #ifndef 的意思是"如果还没有定义过 LINKER_RESTRICTION_H 这个名字"。 如果这份说明书已经被读取过一次了，就跳过，避免重复处理。这句话不会被编译到行文件中。

#define LINKER_RESTRICTION_H   // 定义 LINKER_RESTRICTION_H 这个名字，相当于盖一个"已读取"的戳

#include <stdint.h>     // 引入标准整数类型头文件，提供 uintptr_t、int32_t、uint64_t 等跨平台固定宽度类型。例如，int32_t 编译时，通过 typedef 将 int32_t 映射到目标平台上能满足 32 位宽度的机器上的“本地类型”。运行时，如果硬件本身不支持该“本地类型”的运算，则由编译器生成多指令序列来软件模拟其行为。这句话不会被编译到可执行文件中，但是会体现在数据类型的使用上。

#ifdef __cplusplus      // 判断当前是否为 C++ 编译环境， C++编译器会定义这个宏

extern "C" {            // 若是 C++，则告知编译器以 C 方式链接，防止 C++ 名称修饰（Name Mangling）。C++ 在处理函数名时会做特殊变形（专业叫法是"名字修饰"），而 C 语言不会这样做。比如  # C编译器生成目标文件，符号名是 "add"， # C++编译器看到声明 int add(int,int)，会将其修饰为 "_Z3addii"

#endif

typedef void *soinfo_t;   // 定义一个新的类型名称 soinfo_t，void* 本来表示"一个可以指向任何东西的内存地址"，这里把它重命名为 soinfo_t，代表"一个已加载的库文件的信息" 就像给一个通用容器贴上标签，说明它装的是"库文件信息"， 举例：当你打开一个库文件时，系统会返回这样一个"信息包"给你。也就是说代码中定义的soinfo_t本质就是一个空指针。这句话不会被编译到可执行文件中，但是会体现在使用上。

soinfo_t linker_dlopen(const char *filename, int flag);  // 声明自定义的 dlopen 函数，用于绕过 Android 链接器限制打开动态库

char *linker_soinfo_get_realpath(soinfo_t soinfo);  // 声明函数：通过 soinfo 获取动态库的真实路径字符串

uintptr_t linker_soinfo_to_handle(soinfo_t soinfo);  // 声明函数：将 soinfo 转换为动态库的句柄（handle），"句柄"可以理解为一个"门牌号"或"编号"，用来唯一标识一个已加载的库文件， uintptr_t 是一种特殊的数字类型，大小刚好能装下一个内存地址

void linker_iterate_soinfo(int (*cb)(soinfo_t soinfo));  // 声明函数：遍历所有已加载的 soinfo，对每个调用回调函数 cb，对当前系统中每一个已加载的库文件，都执行一次你指定的操作。举例：就像对一个书架上的每本书，都执行"检查书名"这个操作

void linker_disable_namespace_restriction();  // 声明函数：禁用 Android 链接器的命名空间访问限制。 在Android系统中，不同的应用或系统组件被放在不同的"命名空间"中， 可以把"命名空间"理解为不同的房间，默认情况下房间之间不能随意访问对方的库文件， 这个函数的作用就是"打开所有房间之间的门"，让库文件可以自由访问

#ifdef __cplusplus  // 判断当前是否为 C++ 编译环境

}                   // 结束 extern "C" 块

#endif

#endif  // 与最开始的 #ifndef LINKER_RESTRICTION_H 配对，结束头文件保护宏

// ========================================

// 结束: builtin-plugin\BionicLinkerRestriction\bionic_linker_restriction.h

// ========================================

// ========================================

// 开始: source\dobby.cpp

// 这是一个"源文件"（可以理解为真正干活的工人，而不是说明书）。

// 它实现了 Dobby Hook 框架对外暴露的公共接口，是用户调用 Dobby 功能的入口。

// 主要功能：

//   1. 库加载时自动打印初始化日志（告诉你 Dobby 启动了）

//   2. 查询 Dobby 的构建版本号

//   3. 销毁（移除）一个已安装的 Hook，将函数恢复原样

// 举例：就像一家餐厅的前台，DobbyDestroy 负责"撤销点单"，把厨房（被Hook的函数）恢复到没有接单之前的状态

// ========================================

// 平台限制：以下代码仅在 Linux 和 Apple（macOS/iOS）平台上参与编译

// 原因：unistd.h 和 syslog.h 是 POSIX 标准头文件，Windows 平台不支持

#include <unistd.h>         // 引入 POSIX 标准系统调用头文件，提供 getpid()、read()、write() 等底层系统操作接口。可以理解为"操作系统提供给程序员的遥控器按钮说明书"

#include <syslog.h>         // 引入系统日志头文件，提供 syslog() 函数，用于把日志写入操作系统的日志系统（类似写进系统的"黑匣子"）

#include "dobby_internal.h" // 引入 Dobby 内部头文件，包含 HookEntry（Hook记录条目）、CodePatch（指令写入）等内部数据结构和函数，相当于引入"内部员工手册"

#include "Interceptor.h"    // 引入拦截器头文件，包含 Interceptor 类，负责管理所有 Hook 的增删查，相当于引入"Hook 管理员"的定义

// ----------------------------------------

// 函数：ctor（构造函数，库初始化入口）

// 触发时机：动态库被加载进内存时，在 main() 执行之前自动调用，无需手动调用

// 主要功能：打印 Dobby 框架的启动横幅日志，告知开发者框架已成功加载

// 举例：就像餐厅开门时服务员喊一声"欢迎光临"，表示系统已就绪

// ----------------------------------------

__attribute__((constructor)) static void ctor() { // __attribute__((constructor))：GCC/Clang 编译器扩展语法，标记该函数为"构造函数"，动态库加载时由运行时自动调用，就像设置了一个"开机自启动"程序；static 表示该函数仅在本文件内可见，外部无法调用

DLOG(-1, "================================"); // 调用调试日志宏，打印分隔线，-1 通常表示默认日志级别或不指定模块

DLOG(-1, "Dobby");                            // 打印框架名称，标识这是 Dobby 框架的日志

DLOG(-1, "================================"); // 再次打印分隔线，形成视觉上的横幅包围效果

DLOG(-1, "dobby in debug log mode, disable with cmake flag \"-DDOBBY_DEBUG=OFF\""); // 提示开发者：当前处于调试日志模式，若需关闭可在 CMake 构建时传入 -DDOBBY_DEBUG=OFF 参数

}

// ----------------------------------------

// 函数：DobbyBuildVersion

// 功能：返回 Dobby 框架的构建版本字符串，供外部查询版本信息

// 举例：就像查看软件的"关于"页面，告诉你当前装的是哪个版本

// ----------------------------------------

PUBLIC const char *DobbyBuildVersion() {        // PUBLIC：宏定义的导出标记，表示该函数对外可见（动态库使用者可以调用）；const char* 表示返回一个只读的字符串指针

return __DOBBY_BUILD_VERSION__;               // 返回由编译系统（CMake）在编译期注入的版本字符串宏，例如 "2.1.0-beta"，这个值在编译时就已经确定，运行时不会变化

}

// ----------------------------------------

// 函数：DobbyDestroy

// 功能：移除指定地址上已安装的 Hook，将该函数的机器指令恢复为 Hook 之前的原始状态

// 参数：address —— 当初安装 Hook 时传入的目标函数地址

// 返回：RT_SUCCESS（成功移除）或 RT_FAILED（未找到对应 Hook 记录）

// 举例：就像撕掉贴在门上的便利贴，把门恢复成原来没贴纸条的样子

// ----------------------------------------

PUBLIC int DobbyDestroy(void *address) {        // PUBLIC：导出函数标记；void* address：目标函数的内存地址，void* 表示"不限类型的内存地址"，可以传入任意函数指针

HookEntry *entry = Interceptor::SharedInstance()->FindHookEntry(address); // 通过 Interceptor 单例（全局唯一的 Hook 管理员）查找该地址对应的 HookEntry（Hook记录），就像在档案室按地址查找对应的案卷

if (entry) {                                  // 如果找到了对应的 Hook 记录，说明该地址确实被 Hook 过，可以执行恢复操作

uint8_t *buffer = entry->origin_chunk_.chunk_buffer; // 取出 HookEntry 中保存的原始机器指令备份缓冲区，这是当初 Hook 时提前保存的"原版指令快照"；uint8_t 表示每个元素占 1 字节，机器指令就是一串字节序列

uint32_t buffer_size = entry->origin_chunk_.chunk.length; // 取出原始指令的字节长度，用于后续写回时知道要写多少字节；uint32_t 表示 32 位无符号整数

CodePatch(address, buffer, buffer_size);    // 将备份的原始机器指令写回到目标地址，覆盖掉 Hook 时写入的跳转指令，完成"恢复"操作。就像把改过的文件用备份版本覆盖还原

Interceptor::SharedInstance()->RemoveHookEntry(address); // 从 Interceptor 的 Hook 管理列表中删除该条记录，清理内存，避免残留"幽灵记录"

return RT_SUCCESS;                          // 返回成功状态码，告知调用者 Hook 已成功移除

}

return RT_FAILED;                             // 走到这里说明没有找到对应的 Hook 记录，该地址可能从未被 Hook 过，返回失败状态码

}

// ========================================

// 结束: source\dobby.cpp

// ========================================