[原创] Android 内核无痕 Hook 框架设计思路和避坑指北-Android安全-看雪安全社区

[原创] Android 内核无痕 Hook 框架设计思路和避坑指北

发表于: 2026-7-18 23:09 59650

[原创] Android 内核无痕 Hook 框架设计思路和避坑指北

SharkFall

2026-7-18 23:09

59650

## 写在前面

拜读完珍惜佬写的 [Android内核无痕Hook理解和感悟](https://bbs.kanxue.com/thread-290718.htm) 文章以后, 受益匪浅 !!!

非常感谢珍惜佬的文章, 解释的非常清楚, 并且给出了很多实现细节, 非常值得学习和借鉴 !!!

经段一段时间的摸索, 终于完整实现了珍惜佬文章中的无痕 Hook 框架, 这篇文章记录一下整体的设计思路和技术方向，顺便聊点踩坑经历。

整个框架的所有无痕能力都是基于 APatch 模块提供的内核 Hook 能力实现, 感谢 <a href="elink@642K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6T1L8h3q4^5x3e0t1I4i4K6u0r3b7g2m8S2N6r3y4Z5">APatch</a> !!!

还要感谢 GitRoy 大佬提供的技术支持 !!!

传统 Hook 能力的弊端这里就不提及了, 珍惜佬已经讲的很清楚了, 在现在的高强度对抗中, 传统 Hook 能力已经有些不足了, 所以我们需要一种新的 Hook 能力来对抗现在的各种高强度检测手段.

所以 **无痕 Hook** 诞生了 !!!

## 框架能力 & 架构

### Hook & Trace & MemRW & ?

既然从头造轮子, 那就一次搞定目前的需求吧, 所以框架覆盖了以下方向, 下面会附上原理和一些方案

- 模块化注入库
- Zygote 注入 (用于在 App 启动后分发 Hook)
- Inline Hook (基于 Shadow Page 方案)
- 基于指令插桩的寄存器快照记录 (基于 Shadow Page 方案)
- 指令插桩支持 Before & After 回调 (基于 Shadow Page 方案)
- HWBP 断点 (基于直接操作 ARM64 调试寄存器, 绕过 perf_event 子系统)
- VMA Less 内存分配 (Maps 不可见)
- Art Hook (基于 Shadow Data Page 方案)
- VMA Dump (内核直接遍历目标进程 VMA 链表, 不经 `/proc/maps`, 无痕读取)
- 内存读写 (内核侧走目标页表, 不经 ptrace/procfs, 支持跨进程)
- 内核态 Trace (基于 CPU 硬件单步 `MDSCR_EL1.SS` + `SPSR.SS`, 每条指令触发 SS 异常采集全量寄存器)
- 用户态指令模拟 Trace (基于 dbi 引擎全部走幽灵内存隐藏)
- 符号解析 (直接解析ELF 符号表, 不经 `dl_iterate_phdr`, 用于 Trace 反查符号 / Hook 定位)
- 反调试对抗 (内核层拦截 `ptrace`, 硬件调试寄存器假账本欺骗)
- PC 管控台 (ghost-console + agent 翻译适配层, 设备侧事件 push + 控制 RPC 多路复用)
- DEX 动态加载 (内存字节注入 Java 类, 不落盘)
- Binder / Linker 拦截 (Shadow Hook 拦截 Binder 事务与 dlopen, 零 ArtMethod 改动)
- SO 早期生命周期 & JNI Trace (解决 SO 构造函数早于模块 hook 的时序矛盾)
- 花指令对抗 (仿真跟随间接分支, trace 日志还原真实执行路径)
- Daemon 热重载 (不重启 Zygote 热替换 Daemon)
- 跨 Fork 子进程继承 (VMA-less PTE 不被 fork 复制, 需手动克隆)
- 模块版本兼容 (编译期声明 API 版本约束)
- Dex Dump (感谢 FART 的脱壳思路)
- and more ...

### GhostHook 架构全景

先上一张整体架构图，感受一下模块关系:

```
┌─────────────────────────────────────────────────┐
│              Manager App (EL0)                   │
│   KPM 加载 / 模块管理 / 注入配置 / 事件日志       │
└──────────────────────┬──────────────────────────┘
                       │ syscall (注入配置同步 / 事件轮询)
═══════════════════════╪═══════════════════════════ EL0/EL1
                       ▼
┌─────────────────────────────────────────────────┐
│            KPM 内核模块 (EL1)                     │
│  ┌─────────┬────────┬────────┬──────────────┐  │
│  │  HWBP   │ Shadow │ Ghost  │ Anti-Debug   │  │
│  │ Manager │  Page  │ Memory │ (假账本)      │  │
│  └─────────┴────────┴────────┴──────────────┘  │
│  ┌──────────┬──────────┬───────────────────┐    │
│  │ Mem R/W  │VMA Dump  │  CPU Trace (SS)   │    │
│  │(页表遍历) │(VMA链表) │  (MDSCR.SS+ring)  │    │
│  └──────────┴──────────┴───────────────────┘    │
└──────────────────────┬──────────────────────────┘
                       ▲ syscall（SDK 命令）
═══════════════════════╪═══════════════════════════ EL0/EL1
                       ▼ 返回值 / 事件（daemon 代理）
┌─────────────────────────────────────────────────┐
│              目标进程 (EL0)                       │
│                                                   │
│  Daemon SO (先加载, 幽灵内存中, 全局单例)          │
│  ┌─────────────────────────────────────────┐     │
│  │  GhostApi 函数表实现                     │     │
│  │  syscall 桥接 / 符号解析 / 用户 SO 加载   │     │
│  │  mako (ART Hook) / gtrace (仿真 Trace)   │     │
│  │  dex loader / binder & linker 拦截器     │     │
│  └──────────────────┬──────────────────────┘     │
│                     │ 传入 GhostApi*              │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐         │
│  │ 用户 SO A│ │ 用户 SO B│ │ 用户 SO C│ ← 幽灵内存│
│  │ghostEntry│ │ghostEntry│ │ghostEntry│          │
│  └──────────┘ └──────────┘ └──────────┘         │
└─────────────────────────────────────────────────┘
```

几个关键设计决策:

**Daemon 代理模式**：KPM 先往 Zygote 注入一个 Daemon SO，由它实现所有 SDK 逻辑并通过 syscall 与内核通信。用户模块只需要 include 一个纯声明头文件，通过 Daemon 传入的函数指针表调用能力。这样用户模块极轻量，多模块零代码重复，符号解析和 Hook 句柄管理都集中在 Daemon 一处。

**Zygote 注入**：Daemon SO 先注入到 Zygote 常驻，子进程 fork 后再按包名按需加载用户模块。常规 Zygote 状态随 fork 延续；VMA-less 映射及其运行状态由 fork 路径显式恢复，确保子进程得到独立、完整的运行环境。

**鉴权**：KPM 启动时生成 32 字节随机 session key，所有命令必须携带。Manager 端通过签名锚定自动获取 key——KPM 编译期内置 Manager 签名证书摘要，鉴权请求到达时在内核态校验调用者 APK 签名是否匹配，命中则缓存 uid 走 fast-path，整个过程无需提权。非 Manager 链路（agent / PC 调试）走人工配对码 fallback：一次性短码，限时消费，防止被测信道检测

## 核心技术方向

### 模块化注入 & Zygote 注入

整个注入链路完全在内核态完成：KPM 读取 Daemon SO 的 ELF 文件、解析重定位、通过页表操作映射幽灵内存、生成 bootstrap 跳板劫持 Zygote 执行流。Daemon 驻留 Zygote 后，fork 出的子进程按包名匹配配置，按需加载用户模块。

注入编排流程大致是：发现 Zygote PID → 读取 ELF → 内核态 ELF 链接器解析 PT_LOAD 段 → 幽灵内存映射到 Zygote 用户态地址空间 → 注册 NEEDED 库到符号解析器 → 重定位（IFUNC 自修复）→ 生成 ARM64 bootstrap 跳板 → `task_work_add` 劫持执行流。

用户模块（`.ghm` 文件）由 Manager App 管理，Daemon 通过自带的 ELF 链接器在幽灵内存中加载，调用 `ghostEntry(GhostApi*)` 入口。模块开发者只需 include 一个纯声明头文件，不链接任何 SDK 库。

Daemon 热重载的设计思路是"清场再进场"：先清除 Zygote 上所有已注册的 hook 状态、拆除旧 daemon 幽灵内存映射（含用户态残留 PTE 清理），再重新注入新版本。整个过程不重启 Zygote，开发期迭代效率高。

内核 linker 有个很坑的点, 是 ifunc 的处理, 要么daemon全自实现函数, 要么就模块入口做一下ifunc的修复, 再进行其它操作

### Shadow Hook (影子页)

这里要感谢 WX 大佬提出的 [Shadow Page 方案](https://bbs.kanxue.com/thread-290304.htm)。下面 Art Hook 使用的 Shadow Data Page 也是由这一思路延伸而来。

这是框架 **Inline Hook** 和 **指令插桩** 的核心方案。它为同一 VA 维护两份内容视图：original PFN 保存原始字节，shadow PFN 保存 hook 或插桩后的指令。执行与读取通过页权限和异常路由选择各自的视图：

- 执行态映射到 shadow PFN，权限为 `--x`（执行不可读）
- 普通数据读取触发 DABT 后，PTE 临时指向 original PFN，权限为 `r--`
- 读取完成后的下一次执行触发 IABT，PTE 恢复指向 shadow PFN

这种双视图设计将原始代码内容、实际执行内容和读取结果分开管理。常规代码读取路径基于 original PFN 计算校验值，执行路径则进入 shadow PFN；完整性观察的结果由观察路径及其可见范围共同决定。

页表切换以 `mm_struct` 为作用域。Shadow Page 管理器为同一地址空间内的线程和 CPU 统一维护 PTE 状态、TLB/cache 同步及异常上下文，使执行视图和读取视图在并发访问下保持一致。

关键前提是目标运行内核已启用并支持 FEAT_EPAN（PAN3），从而允许 EL0 使用 execute-only 映射（执行不可读的 PTE 权限组合）。设备能力由 KPM 在内核侧统一探测；用户态 feature ID 寄存器的可见字段随内核 ABI、版本和配置变化。

没有 EPAN 的设备使用单页 `---` 仿真路径：原页完全阻断，KPM 在 fault handler 中软件仿真执行指令。仿真器按层级覆盖：PC-relative 指令使用原始 PC 计算，普通 ALU 和访存指令由软件执行，SIMD/FP 等低频指令通过 backup 页单步兜底。

> [!WARNING]
> - EPAN 设备可使用执行/读取双视图；非 EPAN 设备需要评估内核侧指令仿真的覆盖范围和性能成本。
> - 能力探测、PTE 属性组合及异常处理路径均以目标内核的实际实现为准。

除了 Inline REPLACE，Shadow Page 还支持三种指令插桩模式：

- **LISTEN**：命中时发 PRE 事件（寄存器快照），单步原指令，SS 后发 POST 事件。纯监听，不阻断用户回调
- **INTERCEPT**：原指令执行后进入用户态 callback，回调通过调用线程栈帧中的寄存器上下文修改寄存器和续算 PC；回调上下文按线程保存，页表视图仍由 mm 级 Shadow Page 管理器协调
- **BEFORE_AFTER**：before callback 在原指令前执行，after callback 在原指令后执行，中间靠特定的内核通知机制协调原指令单步

插桩命中靠特定的未定义指令编码触发异常，handler 内根据 PC 偏移查表判断归属，不需要读取目标 VA 字节。

### 幽灵内存 (Ghost Mem)

这是整个框架隐身能力的根基。

常规 `mmap` 会在进程地址空间中创建 VMA 元数据，`/proc/self/maps` 按这些元数据枚举映射。仅过滤 `show_map_vma` 仍会留下可由 `mincore` 等路径观察到的映射行为。

幽灵内存的思路是绕过操作系统管理层，直接操作底层页表:

```
function allocGhostMemory(pid, size):
    kernelPage = kernelVmalloc(size)          // 内核态分配物理页
    userVA = findUnusedVASpace(pid)           // 在用户态找一个 VMA 空洞
    // 直接修改目标进程页表，把 kernelPage 的 PFN 挂到 userVA
    // 手工拼装 PTE 属性位
    injectPte(pid->mm, userVA, kernelPage.pfn)
    flushTLB()                                 // 强制 CPU 认下这张"伪造地契"
    return userVA  // CPU 硬件认可，但 OS 管理层查无此 VMA
```

Ghost Mem 将映射信息分为硬件页表和 VMA 元数据两层：CPU 的 MMU 依据 PTE 完成访问，常规 VMA 链表枚举则不会返回这段地址。它的设计目标是收敛常规 VMA 枚举面；页表检查、映射一致性检查和内核态观察属于另一条可见性边界，需要在威胁模型中单独评估。

VMA-less PTE 还需要地址空间保护。`get_unmapped_area`/`mmap_region` 的选址依据 VMA，后续普通 mmap 可能选中已由 ghost PTE 占用的 VA。框架在 `mmap_region` 路径检查重叠，命中时返回 `-ENOMEM`（fail-closed）；其余会改变地址空间布局的路径也纳入目标内核的兼容性清单。

### HWBP 硬件断点

ARM64 CPU 内置了调试寄存器，你把目标地址写进去，CPU 每次执行时硬件比较器自动比对，命中就触发异常。整个过程不改一个字节的内存。

GhostHook 的 HWBP **不经过 perf_event 子系统**，而是在内核态直接操作 ARM64 调试寄存器并接管 debug 异常处理路径。这样做的好处是绕过了 perf_event 路径的检测面

**HWBP注册**。Linux 内核里进程和线程都是 `task_struct`，HWBP 绑定的是 TID 而非 TGID。只给主线程下断点，子线程走到目标地址根本不会报警。

**数量限制是个硬约束**：HWBP Manager 在初始化阶段读取目标 CPU 的调试能力，并结合内核已占用的槽位计算可分配断点数。执行断点数量随设备和运行环境变化，适合承载数量有限、需要低侵入监听的热点规则；大规模 Hook 由 Shadow Page 等页级机制承担。单条 HWBP 规则可用于追踪入参与返回值：

```
// 概念：按 TID 维护的断点状态
function hwbpHandler(regs):
    state = stateFor(currentTid)
    if state.mode == ENTRY:
        captureArgs(regs)                 // 抓入参
        state.returnStack.push(returnAddr)
        moveBreakpoint(state.returnStack.top())
        state.mode = RETURN
    elif state.mode == RETURN:
        captureReturnValue(regs)          // 抓返回值
        state.returnStack.pop()
        moveBreakpoint(origAddr)
        state.mode = ENTRY
```

HWBP 状态和返回地址栈按 TID 隔离。递归与重入场景通过可用断点槽位或辅助机制维护嵌套层次；函数体中的普通指令保持原生执行，入口、返回及状态转换点由异常处理接管。

如果需要替换执行流（不只是监听），就得引入用户态跳板。跳板里有一个"关闸→调原函数→开闸"的流程，避免调原函数时重复触发断点死循环。LR 寄存器的保护是个极易踩坑的点——`BLR` 指令会覆盖 X30，得找个 callee-saved 寄存器（比如 X20）当"安全屋"暂存原始 LR。

### 指令重定位 (DBI)

有了 DBI 引擎以后就可以模拟执行指令实现 trace 了, 这里参考了 Frida Gum 的实现, 重构了一下, 感谢 Firda, 感谢开源 !!!

DBI 主要用于hook跳板的指令重定位和用户态指令模拟, DBI + PTE hook实现起来发现有很多坑, 我就改用shadow page 实现 hook了

把指令搬到新内存（shadow 页 / 跳板）后，所有 PC 相对寻址指令会算错地址。ARM64 指令 32 位塞不下完整 64 位地址，编译器大量使用相对寻址（`B`/`BL`/`CBZ`/`ADRP`/`LDR literal`）。搬到新地址后"向前跳 50 步"会跳到完全错误的地方。

重定位引擎需要逐条扫描，分类处理:

| 指令类型 | 处理方式 |
|---------|---------|
| `B`/`BL` (无条件跳转) | 超出射程时展开为间接跳转序列，64 位绝对地址硬编码在指令后 |
| `B.cond`/`CBZ`/`TBZ` (条件跳转) | 射程短必越界，需反转条件 + 远跳序列 |
| `ADRP`+`ADD` (PC 相对数据寻址) | 算出原始绝对地址，改写为 PC-relative 字面量加载 |
| `BLR` 系列 (带 PAC 的分支) | ARMv8.3 PAC 指令需特殊处理，避免污染 LR |
| 普通算术/访存 | 安全，原样拷贝 |

```
// 概念：远跳展开
// 原始: B target  (4 字节, 射程有限)
// 展开为间接跳转序列:
//   保存暂存寄存器
//   从字面量池加载 64 位绝对地址
//   绝对跳转
//   .quad target    // 地址数据贴在后面
// 4 字节 → 多个指令槽，需要提前预算膨胀空间
```

指令膨胀后需要提前计算 `offset_map`（原始指令索引 → 克隆页偏移），这也是缺页异常路由时"传送地图"的数据来源。

### ART Java 方法 Hook

ART 虚拟机里每个 Java 方法对应一个 `ArtMethod` 结构体，其中 `entry_point` 指针指向编译后的机器码入口。传统 LSPlant 方案是替换这个指针指向自定义跳板，但反作弊会扫描所有 `ArtMethod` 的 `entry_point`，检查指针是否指向合法的 `boot.art` 或 OAT 文件区域。

GhostHook 的 ART 路径采用 **Shadow Data Page** 管理 `entry_point`。原始 ArtMethod 数据页保留原始字段，shadow 副本保存 hook 后的入口；DABT 发生后，访问来源决定本次访问看到的页视图，ART 运行时代码读取 shadow 页，其余读取路径读取原始页。

同页多条 ArtMethod 共享一张 shadow 页，并由增量 patch 管理。页内写入通过差分同步合并：hook 字段保持目标入口，其他字段跟随原始页更新。Shadow Data Page 复用 mm 级页表协调、并发访问和 TLB 一致性机制。

ART hook 引擎（mako）是独立 SHARED lib，不静态链入 Daemon SO。Manager 开关启用时把路径推到 KPM 缓存，Daemon 首次调用 `artHook` 时 lazy load 进幽灵内存。mako 的跳板池也走幽灵内存（经适配层注入 `ghostMalloc(RWX)`），不引入常规 maps 区段。shorty 取值用反射 `Method.getReturnType` + `getParameterTypes` 自拼，不依赖 libart 内部符号。ArtMethod 字段布局、偏移和可用入口由 Android/ART 版本适配层管理，未匹配版本走失败降级。

定位 Java 方法有两条路径：按 className + methodName + sig 走标准反射，或直接拿反射 `Method` 对象——后者跳过符号解析，适合 hook 隐藏 API 等不可经标准路径定位的方法。两条路径殊途同归，最终都落到 mako 的 ArtMethod 入口替换上。

反射类加载的设计思路是预解析：在 daemon 初始化时把反射链句柄全部解析为全局缓存，fork 继承，后续调用时不再触发 JNI 查找，把开销压到最小。

这里 mako hook 是我之前写的 art hook 框架, 选择用外挂加载的方式主要是考虑到两个原因:

- 1.内核态 linker 实现限制较多, 还有奇奇怪怪的问题, 所以换到 daemon 动态加载
- 2.按需加载, 节省内存, 提高效率, 不需要 hook 就可以不加载, 用户态 trace 加载模式也是这样设计的

### 无痕内存读写

跨进程内存读写支持无痕模式。内核侧直接走目标进程页表遍历，不经 `ptrace`、不经 `/proc/pid/mem`、不设 `TracerPid`。

```
// 概念：跨进程内存读写
function readMem(pid, addr, buf, len):
    mm = getTaskMm(pid)        // 拿目标进程 mm
    walkPageTable(mm, addr)    // 遍历页表取物理页
    copyPageToBuf(buf, ...)   // 读页内容
    mmput(mm)                  // 释放 mm 引用（必须配对！）
    return 0
```

这条路径也用于 Shadow Page 的跨进程读取：读事务在页表锁、mm 级同步和多 CPU 可见性协议保护下，临时将 PTE 指向 original PFN，完成 GUP 取页后恢复执行视图。TLB 刷新与保留策略由后端按目标内核、CPU 拓扑和访问时序实现。

### VMA Dump

思路是让内核直接遍历目标进程的 VMA 链表，把结果写到调用方 buffer。整个过程不经 `/proc/maps`、不设 `TracerPid`、不创建文件。agent 用它构建 per-pid VMA 缓存，配合 ELF 符号表缓存做地址→符号的反查。

### 内核态 Trace (CPU 单步)

这是 Trace 的记录模式：在 debug 异常处理的 Software Step 分支中加入 trace 步进处理，对目标线程设置单步标志进入连续单步。每条用户态指令触发一次 SS 异常，handler 在异常上下文里采集 PC + 全量 GPR + SP + PSTATE + 时间戳，写入专用 trace ring buffer（覆盖最旧 + 丢弃计数），消费者分批取走。

```
// 概念：CPU 单步 trace
function traceHandleStep(regs, session):
    if not inRange(regs.pc, session):
        return                  // 不在目标范围，跳过
    entry = { pc, x0..x30, sp, pstate, timestamp }
    ringWrite(session.ring, entry)
    if session.steps >= session.maxSteps:
        traceStop(session)      // 达到上限，停止
    else:
        rearmSingleStep()      // 重新 arm 单步
```

关键约束：`MDSCR_EL1.SS` 是 per-CPU 寄存器，目标线程被调度到其他 CPU 时 SS 会丢失。trace 期间必须把目标线程钉在单个 CPU 上（`set_cpus_allowed_ptr`），trace 结束后恢复原亲和性。

trace 的连续单步与框架其他单步消费者（HWBP 恢复单步、shadow BRK 单步、shadow read 单步、simulate backup 单步）共享同一个 `MDSCR.SS` 位。trace 在 SS 分发链中具有最高优先级，但不破坏其他机制的 one-shot 单步恢复。

### 符号解析

Daemon 内置符号解析器，读 ELF `.dynsym` 解析符号地址。不走 `dl_iterate_phdr`——幽灵内存中的 SO 不在动态链接器维护的 `link_map` 中，常规枚举不会包含它；因此需要自行维护加载模块与符号表信息。

符号解析用于两条路径：Hook 定位（按 SO 名 + 符号名找地址）和 Trace 符号化（批量解析 PC 对应的 `{soName, sym, offset}` 映射表，随 trace 帧推送到 PC）。

VMA 缓存经内核无痕读取，ELF 符号表缓存从磁盘文件解析一次后复用（优先全量符号表），排序后二分查找。

### 反调试对抗

反作弊检测 HWBP 的手段已经非常成熟，主要通过 `ptrace` 和 `perf_event_open` 施展"连环五步杀"：读寄存器查空位、满载占坑测试、读写一致性校验、越界诱导陷阱（故意设 7 个断点看是否返回 `-ENOSPC`）、主动触发测试。

应对思路是在内核层实现硬件调试寄存器的"假账本"：拦截 `ptrace` 对调试寄存器的读写请求，反作弊全程跟假账本交互，真实 CPU 物理寄存器不受干扰。假账本需要精确模拟内核行为——包括越界报错、读写一致性等，细节不到位反而暴露。

### 跨 Fork 子进程继承

Zygote 注入的 Daemon、跳板和 Shadow Page 使用 VMA-less PTE。Fork 处理器将它们视为显式继承对象：在目标内核验证过的 fork 窗口内，为子进程恢复所需映射、运行状态和元数据。

```
kernel_clone
  └─ copy_process        ← 子进程 mm/页表已构造（VMA 复制完，但 VMA-less PTE 丢失）
     └─ wake_up_new_task(child)  ← KP hook 在此窗口安装子进程的 ghost PTE
```

四类对象的继承策略各不相同：

- **Ghost Mem**：给子进程分配独立物理页 + 私有拷贝 + 逐页独立 PTE。必须私有——直接共享父进程物理页会导致子进程写 daemon 静态数据污染父进程。
- **Shadow Page**：标记了 fork 传播的 hook 页克隆继承 shadow PTE；未标记的需暂停。
- **HWBP 规则**：按子进程的线程生命周期注册断点，并为每个 TID 维护独立状态和返回地址栈。
- **Instrument / Hook 元数据**：拷贝页内 hook/instrument 元数据（受 fork 传播标志门控）。

线程 clone（共享 mm）不需要克隆——只有新进程才需要安装 ghost 内存。

### DEX 动态加载

有时模块需要在目标进程注入自定义 Java 类——比如运行时生成的代理类或 Hook 回调类。设计上走内存 DEX 加载路线：dex 字节不落盘，直接在幽灵内存中包装为 ByteBuffer，反射构造 ClassLoader。

```
// 概念：DEX 内存加载
function loadDex(dexBytes, size, useAppParent):
    ghostBuf = ghostMalloc(size, RW)     // 拷贝到独立幽灵内存
    byteBuffer = newDirectByteBuffer(ghostBuf, size)
    parent = useAppParent ? appClassLoader : null
    classLoader = new InMemoryDexClassLoader(byteBuffer, parent)
    return handle  // 后续 findClassFromDex / unloadDex
```

关键设计点：dex 字节先拷贝到独立的幽灵内存分配，使数据生命周期与用户 SO 的 ELF 映射解耦——直接包装指针会让 buffer 生命周期耦合 SO 映射，拷贝后 dex loader 自主管理，卸载时确定释放。

parent ClassLoader 的选择影响可见范围：挂载 App ClassLoader 可经委托解析 App/framework 类；隔离加载则只有 bootstrap 类 + 自身 dex 类可见。这条路径完全在 daemon 侧实现，与 ART hook 引擎是否启用无关。

### Binder / Linker 拦截器

这两类拦截器都基于 Shadow Hook 实现，不引入 GOT trampoline。Binder 路径直接拦截 `transactNative` 的 native 入口；Linker 路径通过 Bionic 版本适配层解析可用 dlopen 入口。两者的映射可见性以常规 VMA 枚举为边界，页表及内核态观察路径纳入独立的安全评估。

**Binder Transact 拦截**：shadow hook `transactNative` 的 native 函数地址，在 transact 前后按 interface token 分发 before/after 回调。ART 适配层负责按版本定位 ArtMethod 与 native 入口，不将任何字段偏移视为稳定 ABI。读取 interface token 依赖 libbinder.so / libutils.so 的 native 函数，因此由一层 Parcel 工具桥接。

```
// 概念：Binder 事务拦截
function fakeTransactNative(data, reply, flags):
    token = readInterfaceToken(data)    // 经 Parcel 工具读取
    dispatchBefore(token, data, reply)  // 按 token 匹配 before 回调
    result = origTransact(data, reply, flags)
    result = dispatchAfter(token, result, data, reply)  // 可覆盖返回值
    return result
```

Binder 拦截当前覆盖 client 侧。服务端采用 C++ 虚函数分派，扩展服务端覆盖时需要解析具体实现目标或设置独立拦截点。binder call log 作为可选开关，默认关闭，避免热路径开销。

**Linker dlopen 拦截**：shadow hook linker 的可用 dlopen 入口，在 SO 加载前后按 lib name 子串匹配分发回调。内部符号名和调用链由 Bionic 版本适配层维护，未命中入口时该能力保持关闭。

两项能力均懒加载：首次调用才触发 init，per-process 独立，fork 后由映射继承处理器恢复。

### SO 早期生命周期 & JNI Trace

用户模块的 `ghostEntry` 在进程启动早期执行，目标 SO 则可能在后续才加载。SO 生命周期分为两段：ELF 的 `.init`/`.init_array` 由 linker 构造函数路径执行，`JNI_OnLoad` 由 ART 在 `dlopen` 返回后查找并调用。两段都位于 `System.loadLibrary` 的返回之前，框架为它们分别设置拦截点。

```
进程启动
  -> daemon 加载用户 SO -> ghostEntry(api)     ← simTraceStart 只能在这里或之后
  -> App 代码执行
    -> System.loadLibrary("libfoo.so")
      -> dlopen -> link -> relocate
      -> call_constructors                       ← .init / .init_array 在此执行
      -> dlopen 返回
      -> ART 查找并调用 JNI_OnLoad
    -> App 后续调用 libfoo.so 的函数             ← simTraceStart 在这里才能 findSymbol
```

Linker 构造函数路径和 ART 的 `JNI_OnLoad` 路径各自建立拦截点。linker/ART 内部符号及调用链由版本特征识别；幽灵内存中的 SO 不在 `dl_iterate_phdr` 的常规枚举范围内，符号解析器据此维护独立的模块记录，并在需要时回退到完整 ELF 符号表。

JNI 动态注册的 trace 同理：JNIEnv 函数表中的 native 方法注册入口按固定偏移就能取到，无需解析 ART 内部符号，在注册时拦截匹配的方法即可 trace 其函数指针。

### 花指令对抗

目标 SO 使用花指令混淆控制流：在真实指令间插入 junk bytes，通过 `br x_reg`（间接分支寄存器）跳转到 SO 内部的真实代码地址。静态反汇编器看到 `br` 时无法解析目标地址，从 junk bytes 起点反汇编会产生错误指令序列。

GTrace 采用动态仿真执行的方案，天然跟随 `br` 跳转——trace 日志中的指令序列已经是去花后的真实执行路径。trace 日志通过标注内部分支目标和 PC 间断区间，使自动化分析工具可直接提取去花后的真实执行路径，无需从 PC 非连续推断。

### 多 Trace 并发

同一 SO 中不同函数的 trace 场景：先 `traceStart(funcA)` 再 `traceStart(funcB)`，之后 A 和 B 可能在不同时刻被调用。如果 per-trace 配置（writer、traceMode、memReadMode 等）存在全局变量中，第二次调用会覆盖前者的配置，导致 trace 数据写错文件。

解法是将 code handler 的 per-trace 配置从全局变量重构为 per-handle 上下文，通过仿真引擎的 userData 传递给所有 hook 回调，实现多 handle 独立运行。由于仿真执行是同步阻塞的，两个 trace 不可能真正并发，但 shadow hook 是异步触发的——per-handle 化后各自独立，互不干扰。

## 踩坑杂谈

这部分聊几个让人头疼的细节，给各位大佬省点时间。

**多页 `vmap` 的页数组构造**

多页幽灵内存使用 `alloc_pages` + `vmap` 时，页数组必须包含每一页对应的 `struct page`。`vmap` 按数组逐页建立内核虚拟映射；连续页分配需要正确展开每个 page 并逐页校验 PFN。一次 ELF 加载出现的 PFN 重复和 `missing DT_GNU_HASH`，最终定位为页数组/PFN 展开环节错误。当前实现使用 `vmalloc` 简化多页分配，并继续以 `vmalloc_to_pfn` 逐页校验映射结果。

**跳板池化后的 cache 维护范围**

早期每条跳板独占一整页 ghost 映射，浪费 87.5%~94% 物理页。改成每页 256B 切 16 槽的跳板池后，跳板 VA 不再页对齐。原有"整页 DC CIVAC + IC IVAU"如果以槽基为起点会越界刷到相邻映射。解法是所有 cache flush 范围改为按页对齐（刷整张池页，over-flush 相邻槽，注册非高频路径可接受）。

**异常上下文中的锁**

Hook 回调运行在异常上下文中，不能用 `spin_lock_irqsave`——它会操作 DAIF 寄存器，破坏 KP 跳板状态。必须用自定义的 LDAXR/STXR 原子锁来保护共享数据。

**`mm_users` 引用泄漏**

临时持有目标进程 `mm`（通过 `get_task_mm` 或等价内核符号）的代码，所有返回路径都必须 `mmput`。泄漏一个 `mm_users` 引用会阻止进程进入 `exit_mmap`，导致 ghost 映射无法清理，Android framework 在 SIGKILL 后仍认为旧 ProcessRecord 未死亡，后续启动被拒绝或卡 splash。这个排查起来非常非常非常非常非常非常非常痛苦...

**Fork 克隆必须私有拷贝**

子进程 fork 时，ghost 映射使用独立的 `vmalloc` + `memcpy` + 逐页 PTE，避免 daemon 静态数据跨进程共享。资源生命周期同时覆盖 fork、退出和 execve 的旧 mm 回收路径，并按目标 Android/Linux 内核调用链注册清理处理。

## 与传统方案的对比

下表比较三类方案的实现路径与工程约束。可见性、完整性和并发性均由具体观察路径、目标内核及运行时版本共同决定。

| 维度 | 传统 Inline Hook | 纯 HWBP | GhostHook 架构 |
|------|-----------------|---------|---------------|
| 代码页处理 | 原始 `.text` 直接改写 | 保留原始代码页 | original 页保留，shadow 页承载替换内容 |
| 完整性视图 | 读取和执行均为改写结果 | 读取和执行均为原始结果 | 读取视图为 original，执行视图为 shadow |
| Hook 数量 | 通常不受硬件槽位限制 | 由可用断点槽位决定 | 由页与元数据管理能力决定 |
| 映射元数据 | 跳板映射可见 | 通常无额外映射 | 常规 VMA 枚举不包含 ghost 映射 |
| 并发模型 | 修改窗口同步 | TID 状态隔离 | mm 级 PTE、TLB/cache 与异常状态协调 |
| 工程门槛 | 低 | 中 | 高（内核 + ARM64 指令集功底） |
| 调试寄存器 | 不依赖 | 受调试设施与检测面影响 | 按目标内核维护调试寄存器状态 |
| ART Hook 入口 | 改 `entry_point` 指针 | 可用性取决于实现 | Shadow Data Page 提供受控的入口视图 |
| Trace 能力 | 无 | 有限的断点事件 | CPU 单步 + 仿真双模式 |
| 跨进程读写 | 常见实现使用 ptrace | 无 | 内核页表遍历，不经 ptrace |
| DEX 动态加载 | 取决于实现 | 取决于实现 | 内存字节加载 DEX，不落盘 |
| Binder 拦截 | 常见实现使用 GOT hook | 不适用 | Shadow Hook `transactNative`，版本适配 |
| Linker 拦截 | 常见实现使用 PLT hook | 不适用 | Shadow Hook dlopen 入口，版本适配 |
| SO 早期 Trace | 取决于注入时机 | 不适用 | 分别覆盖构造函数与 `JNI_OnLoad` 路径 |
| 花指令对抗 | 不支持 | 不支持 | 仿真跟随 `br` 跳转 + junk bytes 标注 |
| Fork 继承 | 手动处理 | 不自动继承规则状态 | fork 路径恢复映射和状态 |
| Daemon 热重载 | 需重启 | 需重启 | 清 hook → 卸载 → 重新注入，不重启 Zygote |
| 性能 | 极快 | 快 | 异常与同步路径有额外开销，后续取决于实现 |

## 模块开发体验

对于写 Hook 模块的人来说，设计目标只有一个：极简。模块开发者只需 include 一个纯声明头文件，不链接任何 SDK 库，拿到一个函数指针表就能用全部能力。

```cpp
// 概念：用户模块入口
#include "ghosthook_sdk.h"

void ghostEntry(const GhostApi *api) {
    // Shadow Hook
    api->shadowHook("libc.so", "open", myOpen, &origOpen);

// ART Hook / DEX 加载 / Binder 拦截 / trace ...
    // —— 全部通过同一个 api 指针表调用
}
```

所有 DBI/跳板/内存隐藏等底层细节全部由 Daemon + KPM 透明处理。模块编译为独立 `.ghm` 文件，由 Manager App 管理和分发。

## 写在最后

这个项目从设计到实现断断续续搞了挺久，踩的坑远比上面写的多。

内核态开发最大的痛苦不是逻辑复杂，而是调试成本——一个 PTE 属性位拼错了，手机直接黑屏重启，有时候 dmesg 提供的崩溃日志甚至无法定位

这套架构的价值在于把原始页、shadow 页和访问路径分层管理。传统 Inline Hook 直接改写目标代码；Shadow Page 则以双页视图承载执行和读取。围绕页表同步、运行时版本适配与资源生命周期建立完整约束后，这种分层能够为 Hook、插桩和 Trace 提供统一的内核侧基础设施。

项目还在持续迭代，后面有机会再聊聊更多细节。文中如果有描述不准确的地方，欢迎交流指正。

最后配几张图, 祝各位大佬实现顺利 !!!

![图片描述](upload/attach/202607/954363_ZPQ8BXY46QUD2ZM.webp)

![图片描述](upload/attach/202607/954363_C6N788GHXBS3Q7C.webp)

![图片描述](upload/attach/202607/954363_RCUSGHW7MWSSJPH.webp)

![图片描述](upload/attach/202607/954363_ZQ7CY9DZK387BUN.webp)

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

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！

最后于 2026-8-2 12:32 被SharkFall编辑，原因：

#基础理论 #逆向分析 #程序开发 #源码框架 #工具脚本 #其他

收藏・71

点赞・359

打赏

赞赏记录

参与人

雪币

留言

时间

zhczf

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

53分钟前

王叔叔

非常支持你的观点！

4小时前

千音丶

非常支持你的观点！

3天前

Linwenxuan04

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

4天前

lingyi223

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

6天前

WsttXm

非常支持你的观点！

6天前

git_32511mrBLACKl

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

2026-9-29 13:02

qig

为你点赞！

2026-9-29 09:42

longneckfish

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

2026-9-27 17:13

git_52294AnsaryTanvir

为你点赞！

2026-9-26 02:06

tuosen

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

2026-9-24 09:46

mb_ckbethxx

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

2026-9-24 06:17

git_99440qimingminimax

为你点赞！

2026-9-23 11:45

软乐科技

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

2026-9-22 18:28

git_80720ws100

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

2026-9-21 10:11

x1a0f3n9

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

2026-9-20 17:44

我叫KK

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

2026-9-19 11:35

cr_lgdx

为你点赞！

2026-9-18 23:50

mb_xpdephnu

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

2026-9-18 19:23

xjohjrdy

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

2026-9-18 06:24

mb_nazbvxff

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

2026-9-17 07:50

wx_霿凇

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

2026-9-15 11:03

GoKu123

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

2026-9-14 11:58

mb_gzurdrzs

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

2026-9-13 23:09

熊猫人大A

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

2026-9-13 14:04

mb_cccgiudm

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

2026-9-12 14:09

mb_oyxrnlsv

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

2026-9-12 10:58

mb_dvqqrcce

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

2026-9-11 17:25

git_12503yowal2024

非常支持你的观点！

2026-9-11 09:54

深沉

为你点赞！

2026-9-11 02:13

huaerxiela

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

2026-9-10 20:15

mb_coqbxbgr

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

2026-9-10 18:44

git_51951meggadf3df

非常支持你的观点！

2026-9-10 18:24

mb_whandzxl

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

2026-9-10 15:48

晨曦。

为你点赞！

2026-9-9 07:27

mb_dmjoqlov

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

2026-9-9 03:36

老弟来了

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

2026-9-9 00:50

mb_imnrancw

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

2026-9-8 17:12

张楚岚.

为你点赞！

2026-9-8 14:01

mb_jeplbefy

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

2026-9-7 23:59

铭信

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

2026-9-7 22:03

星野安全

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

2026-9-7 19:20

wushuang双

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

2026-9-7 15:42

huaqqdu

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

2026-9-6 20:04

mb_zfqvurgb

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

2026-9-6 18:20

lanxikx

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

2026-9-4 15:32

trackL

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

2026-9-4 11:13

SecurityEye

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

2026-9-4 09:49

mb_koixqizd

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

2026-9-3 15:12

git_30830z2field

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

2026-9-3 11:58

blue_sky

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

2026-9-3 10:37

七星舞月

非常支持你的观点！

2026-9-3 09:50

Splite_1130

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

2026-9-2 23:39

mb_ocvladbj

为你点赞！

2026-9-2 21:33

mb_hdiusdyf

非常支持你的观点！

2026-9-2 02:45

nuomida

非常支持你的观点！

2026-9-1 10:44

mb_mgxzyxdn

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

2026-8-31 10:08

wx_午后柠檬树下的阳光

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

2026-8-30 08:50

gongchuang

为你点赞！

2026-8-30 08:04

zhengyuqin

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

2026-8-29 02:09

mb_obrkxtbn

为你点赞！

2026-8-28 15:16

青衫不负雪

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

2026-8-28 09:41

曦曦大牛子

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

2026-8-27 19:25

wx_kx92911

为你点赞！

2026-8-27 10:45

luckbbs

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

2026-8-27 08:30

SGSGsama

为你点赞！

2026-8-26 15:47

mb_jgiwszwn

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

2026-8-26 14:49

LeoChen..

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

2026-8-26 12:55

Kr1s

非常支持你的观点！

2026-8-25 17:53

bj777

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

2026-8-24 16:55

Lucaks

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

2026-8-23 23:36

gal2xy

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

2026-8-23 19:12

wx_1_659

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

2026-8-23 18:05

mb_enxxgjoh

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

2026-8-21 11:44

zz1syyd

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

2026-8-21 09:37

mb_lthgjpwj

为你点赞！

2026-8-20 16:27

麻大拉

为你点赞！

2026-8-20 10:58

wx_Mark_449

为你点赞！

2026-8-18 18:58

mb_koruzmnv

为你点赞！

2026-8-17 20:03

beierer

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

2026-8-17 15:23

xiispace

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

2026-8-16 10:25

Fanoteria

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

2026-8-16 09:41

mb_cebxltxx

为你点赞！

2026-8-16 00:50

wuli鸭蛋君

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

2026-8-15 18:51

8ac9a57f33e5

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

2026-8-14 20:45

Wblank

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

2026-8-13 14:58

mb_ggjdazcp

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

2026-8-13 13:06

mb_pajvlyxs

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

2026-8-13 11:07

mb_kjzusjxu

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

2026-8-12 19:46

git_52448generalmokka

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

2026-8-12 13:32

上网鱼

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

2026-8-12 10:31

博士9999

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

2026-8-12 09:29

墨儒蛮君

为你点赞！

2026-8-12 03:13

蒙奇·D

为你点赞！

2026-8-11 23:10

mb_ozvppril

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

2026-8-11 07:56

xhan8

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

2026-8-10 18:09

fban

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

2026-8-10 15:44

周游列国

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

2026-8-10 09:52

思卓

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

2026-8-10 08:24

wx_An.

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

2026-8-9 20:46

mb_egiwnofc

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

2026-8-9 12:04

新新新新新

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

2026-8-8 18:08

git_29575booksnature

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

2026-8-8 18:03

z221x

非常支持你的观点！

2026-8-8 11:46

JZegost

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

2026-8-8 10:26

git_85601yruh

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

2026-8-8 04:06

mb_wsoacceo

为你点赞！

2026-8-7 23:07

Iam0x17

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

2026-8-7 12:42

Ujhhgtg

为你点赞！

2026-8-7 08:37

yu1975

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

2026-8-5 18:19

Our_OT

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

2026-8-4 23:00

wx_Kiyose

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

2026-8-4 19:37

SharsDela

非常支持你的观点！

2026-8-4 16:11

wx_Long_583904

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

2026-8-4 11:01

mb_mvlsebeq

为你点赞！

2026-8-3 14:44

wx_渊_430

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

2026-8-3 14:38

自己能

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

2026-8-3 13:40

SX_DomOne

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

2026-8-2 21:50

git_368043724vk-ui

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

2026-8-2 13:06

eeeeekko

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

2026-8-2 08:02

奇奇怪怪

非常支持你的观点！

2026-8-1 15:21

wx_xiao强

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

2026-8-1 10:32

sudami

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

2026-8-1 09:41

mb_xcxzqumw

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

2026-8-1 08:07

Wika

非常支持你的观点！

2026-7-31 14:59

7owe2

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

2026-7-31 14:39

mb_uepdckud

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

2026-7-30 23:40

wangzehua

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

2026-7-30 19:51

mull

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

2026-7-30 15:25

临时test

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

2026-7-30 13:09

hexdump

为你点赞！

2026-7-30 11:13

git_53318moqiyyds

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

2026-7-30 10:29

JaniQuiz

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

2026-7-30 08:57

YiGod

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

2026-7-30 08:53

Bean3ai

为你点赞！

2026-7-29 19:43

er胡

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

2026-7-29 19:35

mb_xunhjjgo

为你点赞！

2026-7-29 16:00

eummmm

非常支持你的观点！

2026-7-29 14:47

sk97

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

2026-7-28 16:31

问南山

为你点赞！

2026-7-28 15:50

mb_kdrgqpmc

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

2026-7-28 15:34

mb_uimsagvt

为你点赞！

2026-7-28 15:25

mb_hzzndkns

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

2026-7-28 10:49

sun-shine

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

2026-7-28 10:39

LovelyWei

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

2026-7-28 10:26

天地一逆旅

非常支持你的观点！

2026-7-28 10:18

优质胖虎

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

2026-7-28 09:41

dreameriii

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

2026-7-28 09:08

lanoche

为你点赞！

2026-7-27 23:42

mb_kyozxkiz

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

2026-7-27 20:30

wx_李光辉

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

2026-7-27 19:44

mb_xcdrmleb

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

2026-7-27 19:17

零_721409

非常支持你的观点！

2026-7-27 17:14

非法用户名

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

2026-7-27 16:33

12321

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

2026-7-27 16:04

yezheyu

非常支持你的观点！

2026-7-27 14:42

clz3216

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

2026-7-27 01:08

gtict

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

2026-7-26 21:44

mb_bppcorlj

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

2026-7-26 20:02

carlcurist

为你点赞！

2026-7-26 16:06

PPTV

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

2026-7-26 16:03

点中你的心

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

2026-7-26 15:52

mb_gvuuaksh

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

2026-7-26 15:51

hk1020

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

2026-7-26 11:36

mb_cantkdlj

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

2026-7-26 02:42

mb_ncfeitiw

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

2026-7-26 02:05

菱志漪

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

2026-7-25 19:00

Umiade

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

2026-7-25 16:36

大舊饭

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

2026-7-25 16:30

mb_ndmoqzht

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

2026-7-25 15:30

mb_ypgiyonb

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

2026-7-25 08:14

Yiiran

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

2026-7-25 02:43

a0yark

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

2026-7-25 01:21

doduhuang

为你点赞！

2026-7-24 20:54

Majh

非常支持你的观点！

2026-7-24 19:01

wx_kx71647

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

2026-7-24 18:42

虎斑猫

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

2026-7-24 18:34

Yu4n

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

2026-7-24 18:24

咸鱼……

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

2026-7-24 18:15

wx_　　　　　　　　_937851

为你点赞！

2026-7-24 18:11

xiahua233

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

2026-7-24 18:04

bananaships

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

2026-7-24 17:13

cdline

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

2026-7-24 17:09

focaccia

非常支持你的观点！

2026-7-24 16:47

GhHei

非常支持你的观点！

2026-7-24 15:55

陈可牛

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

2026-7-24 15:14

镜中人24

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

2026-7-24 14:14

wx_Q道长

为你点赞！

2026-7-24 10:23

对你何止爱

非常支持你的观点！

2026-7-24 10:06

ycdear

为你点赞！

2026-7-24 08:30

Ylarod

为你点赞！

2026-7-24 07:42

我的小拇指啊

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

2026-7-24 05:04

mb_nkvusbql

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

2026-7-23 21:32

StriveMario

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

2026-7-23 20:40

Xhani

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

2026-7-23 19:30

mb_qecctkwn

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

2026-7-23 17:58

JGwebre

为你点赞！

2026-7-23 15:53

git_31027Sadazbia

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

2026-7-23 15:41

git_49874magicerF

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

2026-7-23 15:38

mb_qqnashwi

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

2026-7-23 15:22

zhuzhu_biu

为你点赞！

2026-7-23 13:47

git_32945LoveArrowShoot

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

2026-7-23 12:22

jygzyc

为你点赞！

2026-7-23 11:23

mb_fhpfcoqp

为你点赞！

2026-7-23 11:05

一只鸭子

为你点赞！

2026-7-23 10:01

Forgo7ten

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

2026-7-23 00:25

mb_cqfprqcr

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

2026-7-23 00:10

git_56009war9

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

2026-7-22 23:00

冲冲冲

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

2026-7-22 22:44

清风jw

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

2026-7-22 22:31

aut0run

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

2026-7-22 21:33

Magic丶

为你点赞！

2026-7-22 20:28

MsScotch

非常支持你的观点！

2026-7-22 18:35

cydian

为你点赞！

2026-7-22 18:33

学会规则

为你点赞！

2026-7-22 18:25

git_63825x2d1

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

2026-7-22 17:45

小李08

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

2026-7-22 16:18

JoshuaC

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

2026-7-22 16:16

musktime

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

2026-7-22 16:15

浮夸进进

非常支持你的观点！

2026-7-22 15:58

Ally Switch

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

2026-7-22 13:45

riversky

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

2026-7-22 13:20

creek_

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

2026-7-22 10:40

king少

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

2026-7-22 09:55

Ivory0

非常支持你的观点！

2026-7-22 08:57

doamzo

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

2026-7-22 08:11

ONewTach

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

2026-7-22 08:02

零曦

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

2026-7-22 02:27

git_65827AvailablFrom

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

2026-7-22 01:28

秋小梦

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

2026-7-22 00:59

渐渐72

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

2026-7-22 00:39

无事不觉

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

2026-7-21 22:33

hanhaochi

为你点赞！

2026-7-21 22:30

mb_ztuznpua

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

2026-7-21 21:21

寻影星尘

为你点赞！

2026-7-21 20:58

Ankeys

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

2026-7-21 20:18

mb_zknjgprg

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

2026-7-21 20:09

LLeaves

为你点赞！

2026-7-21 17:17

feng504x

为你点赞！

2026-7-21 17:09

太岁又沐风

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

2026-7-21 16:59

北袅

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

2026-7-21 16:32

ggggg

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

2026-7-21 15:48

悲殇落幕

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

2026-7-21 15:45

wx_嗨

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

2026-7-21 15:34

wx_青竹

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

2026-7-21 15:29

oMasko

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

2026-7-21 15:21

dream的梦

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

2026-7-21 15:08

n_1ng

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

2026-7-21 14:52

chenzhouch

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

2026-7-21 14:19

Dy1an

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

2026-7-21 14:18

Nermor

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

2026-7-21 14:15

zpazz

为你点赞！

2026-7-21 13:29

vVv一

为你点赞！

2026-7-21 11:53

mb_bgpbobvq

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

2026-7-21 11:33

漫雾.

为你点赞！

2026-7-21 11:13

qianlan

非常支持你的观点！

2026-7-21 11:06

Ms135

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

2026-7-21 09:53

mb_eeiaotyg

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

2026-7-21 09:48

blackr0ck

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

2026-7-21 09:30

unxeer

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

2026-7-21 07:17

mb_khtldvni

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

2026-7-21 02:18

像风一样呢

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

2026-7-20 23:29

friendanx

非常支持你的观点！

2026-7-20 23:00

fujing

非常支持你的观点！

2026-7-20 21:38

Aar0n

非常支持你的观点！

2026-7-20 19:55

wake0p

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

2026-7-20 19:31

方子敬xiao

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

2026-7-20 19:10

FANGG3

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

2026-7-20 18:14

小傲骨

为你点赞！

2026-7-20 18:03

wx_funcrever

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

2026-7-20 17:55

螺丝兔

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

2026-7-20 17:38

Cherzsh

为你点赞！

2026-7-20 17:32

alienhe

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

2026-7-20 17:28

xianyuuuan

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

2026-7-20 17:24

neilwu

为你点赞！

2026-7-20 17:14

Max_hhg

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

2026-7-20 16:39

迷茫_720464

为你点赞！

2026-7-20 16:32

_0xA1pha

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

2026-7-20 16:25

DannysMask

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

2026-7-20 16:21

mb_jcwakofc

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

2026-7-20 16:20

mb_yzoctjcb

为你点赞！

2026-7-20 16:05

Gift1a

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

2026-7-20 16:05

逆天而行

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

2026-7-20 15:57

mb_fdjpohol

为你点赞！

2026-7-20 15:48

mb_wpitiize

为你点赞！

2026-7-20 15:13

mb_xultgqpf

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

2026-7-20 15:07

internnal_q

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

2026-7-20 14:58

马先越

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

2026-7-20 14:39

mb_tiffzfjm

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

2026-7-20 14:37

风兮木晓

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

2026-7-20 14:30

nxlite

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

2026-7-20 14:26

qqizai

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

2026-7-20 14:15

只会逆一点点

非常支持你的观点！

2026-7-20 13:58

lidongyooo

非常支持你的观点！

2026-7-20 13:46

mb_rrvlrvbk

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

2026-7-20 13:37

teble

非常支持你的观点！

2026-7-20 13:31

我只是没人要

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

2026-7-20 13:20

userapp

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

2026-7-20 12:55

mb_kamhgqsu

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

2026-7-20 11:34

mb_iesvmzqc

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

2026-7-20 11:31

torrent选手

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

2026-7-20 11:18

ChuXinﻬ.

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

2026-7-20 11:06

mb_thmdyxrm

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

2026-7-20 11:00

Cure.

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

2026-7-20 10:43

Evan_422

为你点赞！

2026-7-20 10:21

梧桐生

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

2026-7-20 10:09

啦啦啦哈哈

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

2026-7-20 10:07

juice4fun

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

2026-7-20 10:04

Je2em1ah

为你点赞！

2026-7-20 10:02

Yangser

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

2026-7-20 09:46

mb_npylpnpl

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

2026-7-20 09:45

醉染

为你点赞！

2026-7-20 09:37

mb_dtidoewd

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

2026-7-20 09:36

皮皮虾啊

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

2026-7-20 09:13

微笑:)

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

2026-7-20 09:09

mb_liueenqt

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

2026-7-20 06:55

孤独的街

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

2026-7-20 00:41

lpyqwq

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

2026-7-19 23:46

mb_crcvruia

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

2026-7-19 22:57

bluegatar

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

2026-7-19 21:59

陈某人

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

2026-7-19 20:13

mb_icbgiifu

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

2026-7-19 19:00

墨穹呢

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

2026-7-19 16:37

jpacg

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

2026-7-19 16:10

mb_uaoofzgb

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

2026-7-19 15:06

LXIN_520

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

2026-7-19 14:47

Red

非常支持你的观点！

2026-7-19 14:31

Sigil

非常支持你的观点！

2026-7-19 13:55

欲拭泪

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

2026-7-19 12:30

伟叔叔

为你点赞！

2026-7-19 11:54

Yves Luo

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

2026-7-19 11:05

mb_kgfqphsx

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

2026-7-19 10:55

pexillove

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

2026-7-19 10:41

ngiokweng

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

2026-7-19 10:29

令狐双

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

2026-7-19 10:21

NPC2000

为你点赞！

2026-7-19 10:07

mb_cfjwplfo

非常支持你的观点！

2026-7-19 08:29

wjwujian

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

2026-7-19 07:49

巷口的那只猫

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

2026-7-19 07:05

.KK

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

2026-7-19 06:32

zxhk

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

2026-7-19 06:27

mb_rjdrqvpa

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

2026-7-19 04:21

山间清爽的风

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

2026-7-19 03:48

东方玻璃

为你点赞！

2026-7-19 03:23

顽劣

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

2026-7-19 02:32

PPKun

为你点赞！

2026-7-19 02:27

mb_fsoesckx

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

2026-7-19 02:27

mb_ooliergk

为你点赞！

2026-7-19 02:16

mb_mmodulik

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

2026-7-19 01:36

mb_bzztlmaj

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

2026-7-19 01:24

逆向小玖

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

2026-7-19 01:12

钟白

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

2026-7-19 01:06

by_Lin

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

2026-7-19 01:01

huangyalei

为你点赞！

2026-7-19 00:40

nonovo

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

2026-7-19 00:08

mb_ttaweivy

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

2026-7-18 23:43

mb_asiwnxyv

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

2026-7-18 23:40

mb_bvvcoitr

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

2026-7-18 23:29

wx_0.0_522

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

2026-7-18 23:24

最新回复 (323) 1 2 3 4 5 6 7 8 9 10 ...13 ▶
珍惜Any 雪币： 6762 活跃值： (17164) 能力值： ( LV9，RANK：270 ) 在线值：发帖 31 回帖 484 粉丝 1818 关注私信	珍惜Any 4 2 楼火钳刘明 2026-7-19 00:10 0
SharkFall 雪币： 600 活跃值： (859) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 19 粉丝 50 关注私信	SharkFall 3 楼珍惜Any 火钳刘明欢迎珍惜佬！ 2026-7-19 00:18 0
fuqiuluo73 雪币： 141 活跃值： (1021) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 20 粉丝 21 关注私信	fuqiuluo73 4 楼火钳刘明 2026-7-19 00:26 2
钟白雪币： 34 活跃值： (703) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 20 粉丝 0 关注私信	钟白 5 楼牛牛牛牛，学习了！！ 2026-7-19 00:39 0
merryfish 雪币： 489 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 22 粉丝 0 关注私信	merryfish 6 楼 cool 2026-7-19 00:44 0
xianhuimin 雪币： 9317 活跃值： (6213) 能力值： ( LV2，RANK：10 ) 在线值：发帖 5 回帖 231 粉丝 2 关注私信	xianhuimin 7 楼 666 2026-7-19 00:45 0
mb_nkjfyhkg 雪币： 308 活跃值： (180) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 78 粉丝 10 关注私信	mb_nkjfyhkg 8 楼 mark 2026-7-19 01:51 0
SomeMx 雪币： 4204 活跃值： (5604) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 158 粉丝 1 关注私信	SomeMx 9 楼过来学习一下 2026-7-19 01:53 0
PPKun 雪币： 43 活跃值： (666) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 6 粉丝 6 关注私信	PPKun 10 楼大佬想问一下，你的实现支持art热页hook吗 2026-7-19 02:29 0
FMNS 雪币： 9 活跃值： (2011) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 121 粉丝 1 关注私信	FMNS 11 楼 666 2026-7-19 05:38 0
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 707 粉丝 7 关注私信	mb_ldbucrik 12 楼感谢分享 2026-7-19 06:46 0
KerryS 雪币： 4228 活跃值： (8099) 能力值： ( LV5，RANK：60 ) 在线值：发帖 15 回帖 85 粉丝 61 关注私信	KerryS 13 楼真狠啊 2026-7-19 07:11 0
mb_qimctavn 雪币： 5316 活跃值： (6765) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 400 粉丝 1 关注私信	mb_qimctavn 14 楼 6 2026-7-19 07:38 0
mb_cfjwplfo 雪币： 319 能力值： ( LV1，RANK：0 ) 在线值：发帖 6 回帖 95 粉丝 20 关注私信	mb_cfjwplfo 15 楼 111 最后于 2026-7-19 08:36 被mb_cfjwplfo编辑，原因： 2026-7-19 08:36 0
mb_cfjwplfo 雪币： 319 能力值： ( LV1，RANK：0 ) 在线值：发帖 6 回帖 95 粉丝 20 关注私信	mb_cfjwplfo 16 楼 PPKun 大佬想问一下，你的实现支持art热页hook吗应该不可以，大佬可以加个好友交流一下，我也是卡在了libart上，感觉不能dbi只能通过pte页表rw/x切换实现 2026-7-19 08:37 0
SharkFall 雪币： 600 活跃值： (859) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 19 粉丝 50 关注私信	SharkFall 17 楼 PPKun 大佬想问一下，你的实现支持art热页hook吗用shadow page实现的hook，目前测试起来没什么问题 2026-7-19 09:18 0
SharkFall 雪币： 600 活跃值： (859) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 19 粉丝 50 关注私信	SharkFall 18 楼 mb_cfjwplfo 应该不可以，大佬可以加个好友交流一下，我也是卡在了libart上，感觉不能dbi只能通过pte页表rw/x切换实现 dbi hook实现起来坑太多了，我放弃了，改用shadow hook实现的 2026-7-19 09:19 0
mb_cfjwplfo 雪币： 319 能力值： ( LV1，RANK：0 ) 在线值：发帖 6 回帖 95 粉丝 20 关注私信	mb_cfjwplfo 19 楼 SharkFall dbi hook实现起来坑太多了[em_055]，我放弃了，改用shadow hook实现的理想化情况下dbi很牛比，但现实很骨感 2026-7-19 10:40 0
mb_kjzusjxu 雪币： 66 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 6 粉丝 0 关注私信	mb_kjzusjxu 20 楼 666666666666666 2026-7-19 10:55 0
SharkFall 雪币： 600 活跃值： (859) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 19 粉丝 50 关注私信	SharkFall 21 楼 mb_cfjwplfo 理想化情况下dbi很牛比，但现实很骨感 2026-7-19 10:58 0
mb_yvuzbfvo 雪币： 209 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 20 粉丝 0 关注私信	mb_yvuzbfvo 22 楼 666 2026-7-19 11:11 0
mb_pesxllvn 雪币： 378 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 122 粉丝 2 关注私信	mb_pesxllvn 23 楼 666 2026-7-19 13:36 0
尤瑟努雪币： 58 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 7 粉丝 1 关注私信	尤瑟努 24 楼 2026-7-19 13:46 0
wx_插曲雪币： 411 活跃值： (981) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 323 粉丝 24 关注私信	wx_插曲 25 楼 66 2026-7-19 16:17 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

SharkFall

发帖

回帖

RANK

关注

私信

他的文章

关于我们

联系我们

企业服务

看雪公众号

最新回复 (323) 1 2 3 4 5 6 7 8 9 10 ...13 ▶
珍惜Any 雪币： 6762 活跃值： (17164) 能力值： ( LV9，RANK：270 ) 在线值：发帖 31 回帖 484 粉丝 1818 关注私信	珍惜Any 4 2 楼火钳刘明 2026-7-19 00:10 0
SharkFall 雪币： 600 活跃值： (859) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 19 粉丝 50 关注私信	SharkFall 3 楼珍惜Any 火钳刘明欢迎珍惜佬！ 2026-7-19 00:18 0
fuqiuluo73 雪币： 141 活跃值： (1021) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 20 粉丝 21 关注私信	fuqiuluo73 4 楼火钳刘明 2026-7-19 00:26 2
钟白雪币： 34 活跃值： (703) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 20 粉丝 0 关注私信	钟白 5 楼牛牛牛牛，学习了！！ 2026-7-19 00:39 0
merryfish 雪币： 489 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 22 粉丝 0 关注私信	merryfish 6 楼 cool 2026-7-19 00:44 0
xianhuimin 雪币： 9317 活跃值： (6213) 能力值： ( LV2，RANK：10 ) 在线值：发帖 5 回帖 231 粉丝 2 关注私信	xianhuimin 7 楼 666 2026-7-19 00:45 0
mb_nkjfyhkg 雪币： 308 活跃值： (180) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 78 粉丝 10 关注私信	mb_nkjfyhkg 8 楼 mark 2026-7-19 01:51 0
SomeMx 雪币： 4204 活跃值： (5604) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 158 粉丝 1 关注私信	SomeMx 9 楼过来学习一下 2026-7-19 01:53 0
PPKun 雪币： 43 活跃值： (666) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 6 粉丝 6 关注私信	PPKun 10 楼大佬想问一下，你的实现支持art热页hook吗 2026-7-19 02:29 0
FMNS 雪币： 9 活跃值： (2011) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 121 粉丝 1 关注私信	FMNS 11 楼 666 2026-7-19 05:38 0
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 707 粉丝 7 关注私信	mb_ldbucrik 12 楼感谢分享 2026-7-19 06:46 0
KerryS 雪币： 4228 活跃值： (8099) 能力值： ( LV5，RANK：60 ) 在线值：发帖 15 回帖 85 粉丝 61 关注私信	KerryS 13 楼真狠啊 2026-7-19 07:11 0
mb_qimctavn 雪币： 5316 活跃值： (6765) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 400 粉丝 1 关注私信	mb_qimctavn 14 楼 6 2026-7-19 07:38 0
mb_cfjwplfo 雪币： 319 能力值： ( LV1，RANK：0 ) 在线值：发帖 6 回帖 95 粉丝 20 关注私信	mb_cfjwplfo 15 楼 111 最后于 2026-7-19 08:36 被mb_cfjwplfo编辑，原因： 2026-7-19 08:36 0
mb_cfjwplfo 雪币： 319 能力值： ( LV1，RANK：0 ) 在线值：发帖 6 回帖 95 粉丝 20 关注私信	mb_cfjwplfo 16 楼 PPKun 大佬想问一下，你的实现支持art热页hook吗应该不可以，大佬可以加个好友交流一下，我也是卡在了libart上，感觉不能dbi只能通过pte页表rw/x切换实现 2026-7-19 08:37 0
SharkFall 雪币： 600 活跃值： (859) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 19 粉丝 50 关注私信	SharkFall 17 楼 PPKun 大佬想问一下，你的实现支持art热页hook吗用shadow page实现的hook，目前测试起来没什么问题 2026-7-19 09:18 0
SharkFall 雪币： 600 活跃值： (859) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 19 粉丝 50 关注私信	SharkFall 18 楼 mb_cfjwplfo 应该不可以，大佬可以加个好友交流一下，我也是卡在了libart上，感觉不能dbi只能通过pte页表rw/x切换实现 dbi hook实现起来坑太多了，我放弃了，改用shadow hook实现的 2026-7-19 09:19 0
mb_cfjwplfo 雪币： 319 能力值： ( LV1，RANK：0 ) 在线值：发帖 6 回帖 95 粉丝 20 关注私信	mb_cfjwplfo 19 楼 SharkFall dbi hook实现起来坑太多了[em_055]，我放弃了，改用shadow hook实现的理想化情况下dbi很牛比，但现实很骨感 2026-7-19 10:40 0
mb_kjzusjxu 雪币： 66 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 6 粉丝 0 关注私信	mb_kjzusjxu 20 楼 666666666666666 2026-7-19 10:55 0
SharkFall 雪币： 600 活跃值： (859) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 19 粉丝 50 关注私信	SharkFall 21 楼 mb_cfjwplfo 理想化情况下dbi很牛比，但现实很骨感 2026-7-19 10:58 0
mb_yvuzbfvo 雪币： 209 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 20 粉丝 0 关注私信	mb_yvuzbfvo 22 楼 666 2026-7-19 11:11 0
mb_pesxllvn 雪币： 378 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 122 粉丝 2 关注私信	mb_pesxllvn 23 楼 666 2026-7-19 13:36 0
尤瑟努雪币： 58 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 7 粉丝 1 关注私信	尤瑟努 24 楼 2026-7-19 13:46 0
wx_插曲雪币： 411 活跃值： (981) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 323 粉丝 24 关注私信	wx_插曲 25 楼 66 2026-7-19 16:17 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复