[原创]基于eBPF的Android ART运行时DEX采集与方法字节码回填-Android安全-看雪安全社区

[原创]基于eBPF的Android ART运行时DEX采集与方法字节码回填

发表于: 2026-5-6 11:33 48650

[原创]基于eBPF的Android ART运行时DEX采集与方法字节码回填

PanzerT

2026-5-6 11:33

48650

> 关键词：Android、ART、eBPF、uprobe、DEX、Nterp、CodeItem、Rust、aya
>
> 项目地址：<09dK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6U0K9r3W2F1L8r3g2W2P5W2)9J5c8X3g2n7f1p5k6p5k6i4S2p5N6h3#2H3k6i4u0Q4x3X3c8J5M7H3`.`.>
>
>
> 适用环境：Android 13-17 / ARM64 / root / 支持 eBPF 的内核

---

## 摘要

Android 加固方案在高版本系统上逐渐从完整 DEX 加密演化为方法级抽取、运行时短暂回填、Nterp 路径覆盖以及 native buffer 中转等多种形态。传统依赖自定义 ROM、Frida inline hook 或 ptrace 的脱壳方式通常存在侵入性强、易被检测、跨 Android 版本维护成本高等问题。

本文以开源项目 `eBPFDexDumper-rs` 为例，介绍一种基于 Linux eBPF uprobe/uretprobe 的 Android ART 运行时 DEX 采集方案。该方案不向目标进程注入 so，也不修改目标进程中的用户态代码逻辑；它通过在内核侧观察 ART 解释器入口、DexFile 生命周期入口以及 libc native buffer 操作，捕获 DEX 起始地址、文件大小和执行过的方法字节码，再由 Rust 用户态完成分块拼装、缺页兜底读取、DEX 去重、CodeItem 反扫和方法字节码回填。

文章重点讨论四个工程问题：第一，如何在 Android 13-17 的 ART 变化中定位可用 hook 目标；第二，如何把 ART 私有对象布局以运行时参数注入 eBPF 程序，降低 ROM 差异带来的重编译成本；第三，如何在 BPF verifier 限制下传输大体积 DEX 与变长方法字节码；第四，如何把采集到的 `insns` 回填到 DEX 并重算 SHA-1 / Adler-32，使输出结果能被 jadx、baksmali 等工具继续处理。

需要说明的是，本文讨论的是授权设备、授权应用和安全研究场景下的动态观测技术。它不试图绕过所有反分析能力，也不保证覆盖完全 native 化或 VMP 化的极端样本。

---

## 1. 背景与问题

### 1.1 Android 高版本脱壳难点

近几年常见 Android 加固方案有几个明显趋势：

1. **方法级抽取**：原 DEX 中的 `class_data_item` 仍在，但部分方法的 `code_item.insns` 被清零、替换或延迟填充。方法真正执行前，壳在运行时短暂恢复字节码。
2. **Nterp 成为主路径**：Android 11 之后，ARM64 上的 Nterp 解释器覆盖了大量解释执行场景。只盯早期 `art::interpreter::Execute` 很容易漏方法。
3. **DexFile 生命周期被弱化**：高版本 ART 中部分构造函数会被内联，符号也可能被 strip。仅依赖 `DexFile::DexFile` 一类入口不够稳。
4. **native buffer 中转**：壳可能先在 native 层 `mmap` 一段内存，把解密后的 DEX 或片段拷贝进去，再交给 ART 或自定义加载逻辑。
5. **跨 ROM 布局漂移**：同为 Android 13+，不同 OEM ROM 中 `mirror::Class`、`DexCache` 等对象字段位置仍可能有细微变化。

因此，一个实用的运行时 DEX 采集工具不能只依赖单个 hook 点，也不能把 ART 私有布局写死在用户态或内核态逻辑里。

### 1.2 传统方案的局限

| 方案 | 典型做法 | 优点 | 局限 |
| --- | --- | --- | --- |
| 自定义 ROM | 修改 AOSP ART，在解释/调用路径中 dump | 覆盖面强，控制力高 | 一机一版本，维护成本高，ROM 指纹明显 |
| Frida hook | 注入 agent，hook ART/libc/native 函数 | 部署快，脚本化方便 | 注入痕迹明显，容易触发反 Frida / 反 hook |
| ptrace / 调试器 | 通过调试接口观察内存与调用 | 通用性较强 | 性能瓶颈明显，调试器存在本身可被检测 |
| maps 扫描 | 扫 `/proc/<pid>/maps` 中的可读区域 | 实现简单 | 对短暂解密、碎片化 DEX 覆盖不足 |
| eBPF uprobe | 内核侧挂用户态探针，ringbuf 输出事件 | 目标进程内无 so 注入，统一观测多进程 | 需要 root 和内核 eBPF 能力，仍可能被精细检测 uprobe |

eBPF 的价值在于把“观测点”放到内核侧：BPF 程序在 uprobe 命中时读取寄存器和用户态内存，然后把事件写入 ringbuf。用户态只负责加载程序、attach 探针、消费事件和落盘。

---

## 2. 项目结构与数据流

`eBPFDexDumper-rs` 是一个 Rust 项目，主二进制为 `eBPFDexDumper`。与本文相关的核心模块如下：

| 路径 | 作用 |
| --- | --- |
| `bpf/bpf.c` | eBPF 程序，定义 ART/libc uprobes、事件上报和内核侧缓存 |
| `bpf/header.h` | BPF map、事件结构、ART layout 结构定义 |
| `src/dump.rs` | 加载 BPF、attach 探针、消费 ringbuf、读取远程内存、落盘 |
| `src/art.rs` | 解析 `libart.so`，定位 hook 目标与 ART 默认布局 |
| `src/dex.rs` | DEX 基础解析、校验与方法信息读取 |
| `src/fix.rs` | 方法字节码回填、DEX checksum/signature 重算、`final/` 汇总 |
| `src/platform.rs` | Android 包名、UID、APK 路径和 oat 清理辅助 |

命令行分为三个子命令：

| 子命令 | 用途 |
| --- | --- |
| `dump` | attach eBPF 探针，采集 DEX 与方法字节码 |
| `fix` | 将 `_code.json` 中的方法字节码回填到已 dump 的 DEX |
| `offsets` | 单独解析 `libart.so`，输出 hook 目标和 ART layout，便于排查 |

整体数据流如下：

输出目录按目标自动分组：使用 `--name` 时以包名建目录；只指定 `--pid` 时尽量从 `/proc/<pid>/cmdline` 推断；只指定 `--uid` 时使用 `uid_<num>/`。

---

## 3. Hook 矩阵设计

### 3.1 ART 解释器入口

当前 `dump` 主流程默认 attach 的 ART 主入口包括：

```c
SEC("uprobe/libart_execute")          // art::interpreter::Execute
SEC("uprobe/libart_executeNterpImpl") // ExecuteNterpImpl / ExecuteNterpWithClinitImpl
SEC("uprobe/libart_nterpOpInvoke")    // nterp_op_invoke_* pattern targets
```

这组 hook 负责捕获“正在执行的方法”。入口参数根据 ABI 分为两类：

- `art::interpreter::Execute`：从寄存器参数中取得 `ShadowFrame*`，再读取其中的 `ArtMethod*`。
- `ExecuteNterpImpl`、`ExecuteNterpWithClinitImpl`、`nterp_op_invoke_*`：按当前实现假设 `x0` 中为 `ArtMethod*`。

拿到 `ArtMethod*` 后，BPF 程序尝试沿 ART 对象链解析 DEX：

```text
ArtMethod*
  -> declaring_class_
  -> mirror::Class.dex_cache_
  -> mirror::DexCache.dex_file_
  -> art::DexFile.begin_
  -> DexHeader.file_size
```

Android 64 位 ART 通常使用 32-bit `HeapReference`。因此实现中会先判断压缩引用，避免把低 32 位对象引用当作 64 位用户态地址直接读取。同时，ARM64 顶字节可能带 MTE/PAC tag，读取前会统一 `untag`。

### 3.2 DexFile 生命周期入口

仅靠解释器入口会漏掉尚未执行的方法和某些 DexFile 生命周期事件。因此项目还会根据 `src/art.rs` 的解析结果 attach：

```c
SEC("uprobe/libart_dexFileCtor")       // DexFile::DexFile / DexFileLoader::OpenOne
SEC("uprobe/libart_registerDexFile")   // ClassLinker::RegisterDexFile
```

`DexFile::DexFile` 和 Android 16/17 上常见的 `DexFileLoader::OpenOne` 都符合“`x1` 位置可取得 DEX begin”的形态，因此可以复用同一个 BPF handler。`RegisterDexFile` 则从 `DexFile*` 读取 `begin_`，再检查 DEX header。

仓库中也包含 `uprobe_libart_verifyClass` 的 BPF handler 和 `VerifyClass` 目标定位逻辑，但当前 `dump` 主流程没有默认 attach 该探针。文档和使用预期应以实际 attach 路径为准，不能把它算作默认采集链路。

### 3.3 libc native buffer 入口

为覆盖“DEX 先在 native buffer 中短暂出现”的场景，项目默认尝试 attach 以下 libc 探针：

```rust
("memcpy",   "uprobe_libc_memcpy",   Some("uretprobe_libc_memcpy"))
("memmove",  "uprobe_libc_memmove",  Some("uretprobe_libc_memmove"))
("mmap",     "uprobe_libc_mmap",     Some("uretprobe_libc_mmap"))
("mmap64",   "uprobe_libc_mmap",     Some("uretprobe_libc_mmap"))
("mprotect", "uprobe_libc_mprotect", None)
```

entry probe 记录参数，uretprobe 在函数返回后检查目标地址是否出现 `dex\n` magic 和合理的 `file_size`。BPF 侧只做轻量判断，完整 DEX header 校验、范围扫描和解析放到用户态完成，以减少 verifier 压力。

---

## 4. ART 目标定位与布局注入

### 4.1 Hook 目标定位

Android 高版本中 `libart.so` 的符号保留情况差异很大。`src/art.rs` 使用纯 ELF 解析定位目标，不依赖在目标进程中 `dlopen` 或执行 ART 代码。主要策略包括：

1. **符号匹配**：优先匹配 `art::interpreter::Execute`、`ExecuteNterpImpl`、`ExecuteNterpWithClinitImpl`、`DexFile::DexFile`、`DexFileLoader::OpenOne`、`ClassLinker::RegisterDexFile` 等符号。
2. **字节模式扫描**：在符号缺失时，用 Nterp 入口和 `nterp_op_invoke_*` 的 ARM64 指令特征定位候选地址。
3. **分支扫描**：围绕 `ExecuteNterpImpl` 查找直接跳转目标，推断 `ExecuteNterpWithClinitImpl` 一类变体。
4. **字符串引用反推**：通过 `.rodata` 中的 `"Interpreting "` 字符串和 `.text` 中的 ADR/ADRP+ADD 引用反推 `Execute` 附近入口。
5. **手工兜底**：通过 `--execute-offset`、`--nterp-offset` 和 `--art-layout` 接管自动定位失败的 ROM。

代码里的 `TargetSource` 目前分为 `manual`、`symbol`、`pattern`、`string-ref` 四类；分支扫描属于 pattern 路径的一种实现细节。

### 4.2 ART layout 动态注入

eBPF 程序通过 `art_layout_t` 描述读取 ART/DEX 关键字段所需的偏移：

```c
struct art_layout_t {
    u32 shadow_frame_method_offset;
    u32 art_method_declaring_class_offset;
    u32 art_method_dex_method_index_offset;
    u32 art_method_data_offset;
    u32 class_dex_cache_offset;
    u32 dex_cache_dex_file_offset;
    u32 dex_file_begin_offset;
    u32 dex_header_file_size_offset;
    u32 code_item_insns_size_offset;
    u32 code_item_insns_offset;
};
```

默认布局对应 Android 13+ AOSP 主线 ARM64 常见结构：

```text
ShadowFrame.method              = 0x08
ArtMethod.declaring_class       = 0x00
ArtMethod.dex_method_index      = 0x08
ArtMethod.data                  = 0x10
Class.dex_cache                 = 0x10
DexCache.dex_file               = 0x10
DexFile.begin                   = 0x08
DexHeader.file_size             = 0x20
CodeItem.insns_size             = 0x0c
CodeItem.insns                  = 0x10
```

用户态加载 BPF 后会把 layout 写入 `art_layout_map[0]`。这个 map 使用 `BPF_MAP_TYPE_HASH` 而不是单元素 array，是为了让 BPF 程序在用户态尚未写入时 `lookup` 返回 `NULL`，从而回退到内置的 `default_art_layout`，避免读到全 0 偏移。

### 4.3 ROM 偏移漂移处理

`Class.dex_cache_` 和 `DexCache.dex_file_` 在不同 ROM 上可能出现在相邻 slot。主路径失败时，BPF 会在有限范围内做 4x4 网格尝试：

```c
#pragma unroll
for (int class_slot = 0; class_slot < 4; class_slot++) {
 u32 class_dex_cache_offset = 0x10 + class_slot * 8;
 #pragma unroll
 for (int dex_cache_slot = 0; dex_cache_slot < 4; dex_cache_slot++) {
 u32 dex_cache_dex_file_offset = 0x10 + dex_cache_slot * 8;
 if (read_dex_from_art_method(...)) {
 return 1;
 }
 }
}
```

这里使用固定边界和 `#pragma unroll` 是为了满足 BPF verifier 对循环可证明性的要求。

---

## 5. 大体积 DEX 与方法字节码传输

### 5.1 DEX 分块续传

DEX 文件可能达到几十甚至上百 MiB，不能作为单条 ringbuf 记录输出。项目用 `dex_chunks` ringbuf 加 `dexProgress_map` 实现分块续传：

```text
dexProgress_map[begin] = next_offset
```

每次同一个 DEX 再次被 hook 命中时，BPF 从 `next_offset` 继续发送固定大小 chunk。当前 chunk 记录大小为 `RINGBUF_SIZE = 1 << 17`，也就是 128 KiB；单次 BPF 调用最多推进 `MAX_CHUNKS_PER_CALL = 128` 个 chunk。

当 `bpf_ringbuf_reserve` 失败或 `bpf_probe_read_user` 读页失败时，BPF 发送 `read_failures` 事件，交给用户态兜底。

### 5.2 `process_vm_readv` 缺页兜底

`bpf_probe_read_user` 是非阻塞读取，不会替目标进程触发缺页换入。如果目标页尚未驻留，BPF 侧读取会失败。用户态收到 `read_failures` 后调用 `process_vm_readv`：

```rust
libc::syscall(
    libc::SYS_process_vm_readv,
    pid as libc::pid_t,
    &mut local,
    1usize,
    &mut remote,
    1usize,
    0usize,
)
```

在 root 场景下，这一 fallback 能把 BPF 侧不适合完成的阻塞式大块读取转移到用户态，降低 BPF 程序复杂度。

### 5.3 方法字节码事件

方法级抽取场景中，原始 DEX 文件本身可能存在，但目标方法的 `insns` 被抹掉。项目在解释器入口解析到 `ArtMethod*` 后，会进一步通过 `ArtMethod.data_` 读取 `CodeItem`，采集：

- `dex begin`
- `method_idx`
- `ArtMethod*`
- `codeitem_size`
- `insns` 字节

BPF 中用 `methodCodeCache_map` 对 `ArtMethod*` 去重，避免同一方法重复发送。由于方法字节码是变长数据，项目使用 per-cpu 16 KiB 缓冲作为中转，再通过 `bpf_ringbuf_output` 输出到 `method_events`。

用户态会把这些记录累计到：

```text
dex_<begin>_<size>_code.json
```

记录中保存方法名、`method_idx` 和 hex 编码的字节码。方法名解析失败时，回退为 `method_idx_<n>`。

---

## 6. Fallback 采集链

实际样本里，任意单一路径都可能被绕开。因此项目把采集路径分成几层。

### 6.1 L0：ART 方法链

这是最准确的路径。解释器入口命中后，工具从 `ArtMethod*` 解析到 DEX begin/size，并同步采集当前方法的 `CodeItem.insns`。

适用场景：

- 普通解释执行
- 方法级抽取但执行前会恢复 `insns`
- 仍通过 ART/Nterp 分发的方法

### 6.2 L1：DexFile 注册/打开路径

`DexFile::DexFile`、`DexFileLoader::OpenOne`、`ClassLinker::RegisterDexFile` 用于捕获已经进入 ART DexFile 生命周期但尚未执行到具体方法的 DEX。

适用场景：

- DEX 被 ART 加载但方法还未触发
- 构造/注册阶段还能看到完整 DEX header

### 6.3 L2：CodeItem 反扫

当 ART 链路解 DEX 失败，但 `ArtMethod.data_` 仍像是 `CodeItem*` 时，BPF 发送 `layout_debug_events`。用户态从 `code_item_ptr` 所在页向前扫描 `dex\n` magic，最大回扫 64 MiB，并要求候选 DEX 范围包含该 `code_item_ptr`。

这条路径用于处理 `dex_cache` 链不稳定、字段偏移异常或部分 ART 私有路径失效的情况。

### 6.4 L3：maps / native buffer 扫描

`dump` 默认启动一次 `/proc/<pid>/maps` 扫描，跳过 `/apex/`、`/system/framework/`、`/data/dalvik-cache/` 等系统 DEX 路径，对可读 region 查找合法 DEX header。

native buffer 事件则来自 `mmap`、`mprotect`、`memcpy`、`memmove`。命中后，用户态会先尝试从事件地址读取 DEX；如果地址本身不是 DEX 起点，则在限定范围内继续扫描。

这两条路径覆盖率更宽，但精度低于 ART 链路，因此所有写盘前都要经过 DEX header 校验、`DexParser` 解析和 SHA-1 内容去重。

---

## 7. DEX 回填与输出整理

### 7.1 `method_idx -> code_off` 映射

`fix` 阶段不会依赖外部 dexlib，而是直接解析 DEX 的 `class_def_item` 和 `class_data_item`。核心过程如下：

1. 遍历 `class_defs`。
2. 读取每个类的 `class_data_off`。
3. 解 ULEB128，跳过 static/instance fields。
4. 读取 direct methods 与 virtual methods。
5. 按 DEX 规范累加 `method_idx_diff`，记录 `method_idx -> code_off`。

这样可以根据 dump 阶段记录的 `method_idx` 找回原 DEX 中对应 `code_item` 的位置。

### 7.2 回填 `insns`

标准 `code_item` 中：

```text
code_off + 0x0c = insns_size_in_code_units
code_off + 0x10 = insns
```

回填时，工具会根据原 DEX 声明的 `insns_size` 计算期望长度，将采集到的字节码写入 `insns` 区域。若采集长度短于声明长度，剩余部分清零；若长度不一致，会记录 `length_mismatch`，便于后续人工审计。

### 7.3 重算 DEX 校验链

DEX 修改后必须重算 header 中的 SHA-1 与 Adler-32：

```text
SHA-1   = sha1(dex[32..])
Adler32 = adler32(dex[12..])
```

项目会把修复版写入 `fix/`，再汇总到 `final/`：

- 有成功回填结果时，`final/` 使用修复版。
- 没有 `_code.json` 或修复失败时，`final/` 回退原始 DEX。

这种目录设计方便后续工具只消费 `final/`，同时保留原始采集结果用于对比。

---

## 8. 工程细节

### 8.1 关停状态机

运行中第一次收到 SIGINT/SIGTERM 时，工具停止主 ringbuf 循环，但仍允许 flush JSON 和 auto-fix；第二次信号会进入强制退出状态，跳过后处理。

这一设计解决的是大应用 dump 时的常见问题：用户希望 Ctrl-C 后尽快停止 attach，但又不希望已经采集的数据因为未 flush 而丢失。

### 8.2 先 detach 再 drain

退出主循环后，用户态会先 drop `ebpf`，让所有 uprobe detach，再做最后一轮 ringbuf drain。否则目标进程仍在运行时，ringbuf 可能一边 drain 一边继续增长，导致收尾阶段 livelock。

### 8.3 BTF 资源内嵌

部分 Android 内核没有暴露 `/sys/kernel/btf/vmlinux`。项目在 `assets/` 中内嵌了精简 BTF 资源：

```text
assets/a12-5.10-arm64_min.btf
assets/rock5b-5.10-arm64_min.btf
```

用户态检测不到系统 BTF 时，会根据内核 release 选择内置 BTF 解析，提升在 Android 设备和开发板上的加载成功率。

### 8.4 oat 清理与自动修复

`dump` 默认会根据包名查找 APK 路径并清理目标应用的 `oat` 目录，促使下次启动更多走解释器或重新加载路径。退出时默认执行 auto-fix，将可回填的 DEX 直接整理到 `final/`。

这些行为都提供了关闭开关：

```bash
--no-clean-oat
--no-auto-fix
--no-code-item-fallback
--no-maps-scan
--no-native-buffer-scan
```

---

## 9. 复现与验证建议

本文不把单次本地样本结果写成普适性能结论。不同设备的内核配置、ROM ART 编译方式、目标应用规模和壳行为都会显著影响命中率与开销。更稳妥的验证方式是按以下步骤复现。

### 9.1 构建

macOS 宿主机示例：

```bash
brew install llvm
export CLANG=/opt/homebrew/opt/llvm/bin/clang
sh build_android.sh
```

产物路径：

```text
target/aarch64-linux-android/release/eBPFDexDumper
```

### 9.2 目标定位检查

先在设备上检查 `libart.so` 的定位结果：

```bash
adb shell su -c '/data/local/tmp/eBPFDexDumper offsets \
  -l /apex/com.android.art/lib64/libart.so --json'
```

重点关注：

- 是否至少定位到 `ExecuteNterpImpl` 或其他主入口。
- `DexFile::DexFile` / `DexFileLoader::OpenOne` 是否命中。
- `ClassLinker::RegisterDexFile` 是否命中。
- ART layout 是否符合当前 ROM；不符合时用 `--art-layout` 覆盖。

### 9.3 dump 与 fix

```bash
adb push target/aarch64-linux-android/release/eBPFDexDumper /data/local/tmp/
adb shell su -c 'chmod +x /data/local/tmp/eBPFDexDumper'

adb shell su -c '/data/local/tmp/eBPFDexDumper dump \
  -n com.example.app \
  -o /data/local/tmp/dex_out'

adb shell su -c '/data/local/tmp/eBPFDexDumper fix \
  -d /data/local/tmp/dex_out/com.example.app'
```

建议验证：

- `dex_*.dex` 是否能被 `jadx` 或 `baksmali` 解析。
- `dex_*_code.json` 中是否出现目标业务方法。
- `fix/` 与 `final/` 中的 DEX 是否比原始 dump 多出有效方法体。
- 多次运行是否因 SHA-1 去重避免大量重复文件。

---

## 10. 局限性与威胁模型

### 10.1 平台限制

- 当前实现面向 Android ARM64。
- 需要 root 权限。
- 需要内核支持 eBPF、uprobe 和 ringbuf。
- ART 布局默认值面向 Android 13+ AOSP 常见布局，强定制 ROM 可能需要 `--art-layout`。

### 10.2 覆盖边界

以下场景可能无法完整恢复：

| 场景 | 影响 |
| --- | --- |
| 完全 native 化 / dex2c / VMP | 方法不再回到 ART 解释器，L0/L1 失效 |
| 指令级碎片化解密 | 内存中不出现连续合法 DEX 或完整 `insns` |
| 自定义 syscall 或绕过 libc wrapper | native buffer 探针可能漏掉分配/拷贝事件 |
| 强反 uprobe 检测 | 可通过探测断点、dirty page 或时序发现分析行为 |
| 非标准 ART 对象布局 | 需要人工 layout 或新增适配逻辑 |

### 10.3 可观测性与隐蔽性

uprobe 的实现会在目标 ELF 对应位置设置断点机制。虽然这不是 Frida 式 so 注入，也不需要改目标进程业务代码，但它并不是“不可检测”。具备精细自检能力的壳仍可能发现探针痕迹。

因此，本项目更适合定位为安全研究、取证分析和授权逆向环境中的低侵入采集工具，而不是对抗所有商业壳的隐蔽执行框架。

---

## 11. 结论

`eBPFDexDumper-rs` 展示了一条不同于 Frida 注入和 ROM 修改的 Android DEX 运行时采集路线：把 ART/libc 关键路径上的观测逻辑放在 eBPF uprobe 中，把复杂的 DEX 拼装、缺页读取、CodeItem 反扫和回填逻辑放在 Rust 用户态中完成。

这种分层让工具在 Android 13-17 ARM64 上具备较好的工程可维护性：BPF 侧只做短路径判断和事件输出，用户态负责高复杂度处理；ART 字段布局通过 map 注入，ROM 差异可以在运行时修正；DEX 和方法字节码分别通过分块续传和变长事件传输，最终再统一落盘、去重和修复。

它的边界同样明确：需要 root 和 eBPF-capable kernel，无法覆盖完全脱离 ART 的 native/VMP 方法，也可能被专门的反 uprobe 检测发现。只要在授权场景下使用，并把输出结果与样本行为、jadx/baksmali 解析结果结合验证，它可以作为 Android 高版本 DEX 采集与方法回填的一条实用工程路径。

---

## 参考资料

[1] LLeavesG. *eBPFDexDumper*. <c9fK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6x3e0r3g2S2N6X3g2K6c8#2)9J5c8X3g2n7f1p5k6p5k6i4S2p5N6h3#2H3k6i4t1`.>

[2] aya-rs. *aya: an eBPF library for Rust*. <23eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6S2P5h3q4Q4x3X3c8J5M7#2)9J5c8X3q4&6j5b7`.`.>

[3] Android Open Source Project. *ART runtime source*. <e2bK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6S2L8X3c8J5L8$3W2V1i4K6u0W2k6$3!0G2k6$3I4W2M7$3!0#2M7X3y4W2i4K6u0W2j5$3!0E0i4K6u0r3M7r3I4S2N6r3k6G2M7X3#2Q4x3V1k6S2M7Y4c8Q4x3V1j5`.>

[4] Android Developers. *Dalvik Executable format*. <a84K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6K6L8%4g2J5j5$3g2Q4x3X3g2S2L8X3c8J5L8$3W2V1i4K6u0W2j5$3!0E0i4K6u0r3k6r3!0U0M7#2)9J5c8X3y4G2M7X3g2Q4x3V1k6J5N6h3&6@1K9h3#2W2i4K6u0r3k6r3g2^5i4K6u0V1k6X3!0J5L8h3q4@1>

[5] Linux Kernel Documentation. *BPF Ring Buffer*. <7d2K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2C8k6i4u0F1k6h3I4Q4x3X3g2G2M7X3N6Q4x3V1k6V1L8$3y4Q4x3V1k6Z5N6r3#2D9i4K6u0r3L8r3q4@1k6i4y4@1i4K6u0r3j5Y4m8X3i4K6u0r3M7X3W2F1k6$3u0#2k6W2)9J5k6h3S2@1L8h3H3`.>

---

## 附录：使用速览

```bash
# 查看帮助
./eBPFDexDumper --help

# 按包名 dump，退出时默认 auto-fix
su -c './eBPFDexDumper dump \
  -n com.example.app \
  -o /data/local/tmp/dex_out'

# 按 UID dump
su -c './eBPFDexDumper dump \
  -u 10123 \
  -o /data/local/tmp/dex_out'

# 单独修复一个输出目录
su -c './eBPFDexDumper fix \
  -d /data/local/tmp/dex_out/com.example.app'

# 只解析 libart hook 目标
su -c './eBPFDexDumper offsets \
  -l /apex/com.android.art/lib64/libart.so --json'

# ROM layout 不匹配时手工覆盖
su -c './eBPFDexDumper dump \
  -n com.example.app \
  --art-layout 0x08,0x00,0x08,0x10,0x10,0x10,0x08,0x20,0x0c,0x10'
```

输出结构：

```text
/data/local/tmp/dex_out/com.example.app/
|-- dex_<begin>_<size>.dex
|-- dex_<begin>_<size>_code.json
|-- fix/
| `-- dex_<begin>_<size>_fix.dex
`-- final/
 `-- dex_<begin>_<size>.dex
```

请仅在你有权分析的设备、应用和数据上使用本项目。

注：本项目代码与本文内容均在 AI 辅助下完成。

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

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

最后于 2026-5-6 11:34 被PanzerT编辑，原因：

#基础理论 #脱壳反混淆 #系统相关 #工具脚本

收藏・17

点赞・118

打赏

赞赏记录

参与人

雪币

留言

时间

微笑:)

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

5小时前

nuomida

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

5小时前

mb_dvqqrcce

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

2026-9-11 17:21

mb_zqiaqxlg

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

2026-9-10 21:55

Freax

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

2026-9-9 14:45

张楚岚.

为你点赞！

2026-9-8 14:03

铭信

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

2026-9-7 22:03

wx_Kiyose

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

2026-9-7 11:39

console_

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

2026-9-5 21:40

付诸笑谈

为你点赞！

2026-9-5 08:18

mb_lthgjpwj

为你点赞！

2026-8-20 16:56

wx_Mark_449

为你点赞！

2026-8-18 18:36

mb_evapxmjh

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

2026-8-17 17:11

mb_wsoacceo

为你点赞！

2026-8-8 01:01

Wika

为你点赞！

2026-7-31 15:07

wx_funcrever

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

2026-7-27 15:37

优质胖虎

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

2026-7-27 15:33

mb_ovmxbmhd

非常支持你的观点！

2026-7-20 19:19

wx_晨梦

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

2026-7-16 06:06

afishlong

非常支持你的观点！

2026-7-14 00:31

xhan8

为你点赞！

2026-7-5 20:17

智童

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

2026-6-30 23:20

mb_djytmgxy

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

2026-6-26 21:13

ycdear

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

2026-6-22 00:15

WsttXm

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

2026-6-19 21:14

Red

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

2026-6-19 15:13

zhongdong

为你点赞！

2026-6-18 18:07

mb_cebxltxx

为你点赞！

2026-6-18 14:40

mb_frqqbsuy

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

2026-6-17 21:55

mb_hsscwjpz

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

2026-6-17 14:12

fzyspark

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

2026-6-16 20:48

左眼憔悴

为你点赞！

2026-6-11 15:56

zzzhangyu

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

2026-6-10 16:47

北墙

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

2026-6-8 10:12

橙_

非常支持你的观点！

2026-6-5 17:42

pushmop

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

2026-6-4 11:46

叶晓枫A

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

2026-6-4 11:32

g-yan

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

2026-6-3 21:38

git_65034kaceetce1

请注意发帖规范，保持良好的讨论环境！

2026-6-3 16:33

北袅

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

2026-6-3 14:17

git_82094mark1337g3a-netizen

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

2026-6-2 22:13

x1a0f3n9

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

2026-6-2 17:26

slurse_212010

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

2026-6-1 03:44

mb_coqbxbgr

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

2026-5-29 10:18

xiaohongmao

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

2026-5-28 19:08

mb_koixqizd

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

2026-5-26 20:42

南行

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

2026-5-25 19:48

pianpu

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

2026-5-21 21:09

git_91357jnabnsn

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

2026-5-15 16:15

saykao

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

2026-5-14 17:03

mb_rirvdrlh

为你点赞！

2026-5-14 15:59

wjdidi

为你点赞！

2026-5-13 16:51

mb_ghcouuzx

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

2026-5-12 22:01

王叔叔

为你点赞！

2026-5-12 18:28

不吃早饭

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

2026-5-12 15:22

sk97

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

2026-5-12 15:01

mb_icbgiifu

为你点赞！

2026-5-12 01:15

sinker_

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

2026-5-11 02:30

GoKu123

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

2026-5-9 14:55

X66iaM

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

2026-5-9 13:51

CCC_

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

2026-5-9 11:39

lrhtony

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

2026-5-9 11:17

NPC2000

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

2026-5-9 00:59

mb_bppcorlj

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

2026-5-8 22:06

ROSE0

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

2026-5-8 20:19

git_21210wzzzh2025

非常支持你的观点！

2026-5-8 18:15

清风jw

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

2026-5-8 17:26

linchuan0

为你点赞！

2026-5-8 13:37

岁月。

为你点赞！

2026-5-8 13:27

mb_bzlxewmx

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

2026-5-8 11:39

ONewTach

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

2026-5-8 09:09

LooKoo

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

2026-5-8 00:21

lingyi223

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

2026-5-7 21:42

孤独的街

非常支持你的观点！

2026-5-7 20:52

wx_不愿入赘老板郎

非常支持你的观点！

2026-5-7 18:39

nonovo

为你点赞！

2026-5-7 17:12

Yu4n

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

2026-5-7 17:11

xjohjrdy

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

2026-5-7 16:52

零_721409

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

2026-5-7 15:17

mb_thmdyxrm

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

2026-5-7 14:19

shutterbug

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

2026-5-7 13:53

北辰制作

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

2026-5-7 11:38

wx_cccccccccccccccc

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

2026-5-7 10:55

qqizai

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

2026-5-7 10:51

mb_rrvlrvbk

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

2026-5-7 10:43

mb_wpitiize

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

2026-5-7 10:41

wx_浓情淡如你

为你点赞！

2026-5-7 09:24

mb_kgfqphsx

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

2026-5-7 08:39

SGSGsama

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

2026-5-7 07:54

by_Lin

为你点赞！

2026-5-7 07:17

zxhk

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

2026-5-6 23:27

LGD丶ynlyxy

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

2026-5-6 20:47

Cure.

非常支持你的观点！

2026-5-6 20:39

路过1

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

2026-5-6 18:47

dsfa

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

2026-5-6 17:50

东方玻璃

为你点赞！

2026-5-6 17:36

GhHei

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

2026-5-6 17:31

曰你

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

2026-5-6 17:30

Ms135

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

2026-5-6 17:09

伟叔叔

为你点赞！

2026-5-6 16:19

梧桐生

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

2026-5-6 15:21

mb_asiwnxyv

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

2026-5-6 15:18

neilwu

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

2026-5-6 14:47

mb_cfjwplfo

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

2026-5-6 14:34

mb_pnrjfxiv

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

2026-5-6 14:24

下雨天sana

为你点赞！

2026-5-6 14:03

oMasko

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

2026-5-6 13:39

bluegatar

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

2026-5-6 13:37

wx_ㅤ_683

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

2026-5-6 13:01

mb_kflrccfl

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

2026-5-6 12:58

风兮木晓

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

2026-5-6 12:16

k423

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

2026-5-6 12:11

huangyalei

为你点赞！

2026-5-6 12:09

aut0run

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

2026-5-6 12:06

pexillove

为你点赞！

2026-5-6 11:58

顽劣

非常支持你的观点！

2026-5-6 11:56

mb_iekomvyy

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

2026-5-6 11:54

doduhuang

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

2026-5-6 11:39

最新回复 (69) 1 2 3 ▶
aut0run 雪币： 2220 活跃值： (702) 能力值： ( LV5，RANK：60 ) 在线值：发帖 5 回帖 11 粉丝 13 关注私信	aut0run 1 2 楼感觉有点东西啊 2026-5-6 12:06 0
墨穹呢雪币： 4704 活跃值： (8122) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 224 粉丝 18 关注私信	墨穹呢 3 楼感谢分享 2026-5-6 12:47 0
温泉划水鱼雪币： 84 能力值： ( LV1，RANK：0 ) 在线值：发帖 6 回帖 224 粉丝 28 关注私信	温泉划水鱼 4 楼 6 2026-5-6 13:46 0
xianhuimin 雪币： 9281 活跃值： (6143) 能力值： ( LV2，RANK：10 ) 在线值：发帖 5 回帖 226 粉丝 2 关注私信	xianhuimin 5 楼 666 2026-5-6 14:39 0
xingbing 雪币： 158 活跃值： (5651) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 1373 粉丝 2 关注私信	xingbing 6 楼谢谢分享 2026-5-6 16:50 0
Zepp7289 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 137 粉丝 0 关注私信	Zepp7289 7 楼 tql 2026-5-6 17:23 0
mb_ssjlfpnk 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 10 粉丝 0 关注私信	mb_ssjlfpnk 8 楼 2026-5-6 20:20 0
Viseris 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 70 粉丝 0 关注私信	Viseris 9 楼谢谢分享 2026-5-6 22:25 0
jyotidwi 雪币： 1278 能力值： ( LV1，RANK：0 ) 在线值：发帖 3 回帖 121 粉丝 3 关注私信	jyotidwi 10 楼 tql 2026-5-7 00:16 0
cecini 雪币： 11 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 34 粉丝 0 关注私信	cecini 11 楼这已经在生产上使用了吗 2026-5-7 04:59 0
cecini 雪币： 11 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 34 粉丝 0 关注私信	cecini 12 楼 1. [但是由于eBPF的局限性，其无法替代FART等基于主动调用的脱壳工具](7d9K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6T1L8r3!0Y4i4K6u0W2L8r3I4W2j5i4k6W2M7$3N6Q4x3X3g2@1L8%4m8Q4x3V1k6S2M7Y4c8A6j5$3I4W2i4K6u0r3k6f1u0b7c8V1c8W2P5p5c8#2L8i4m8W2M7W2)9J5z5b7`.`. 有什么局限，导致功能上有什么区别吗 2 它不试图绕过所有反分析能力，也不保证覆盖完全 native 化或 VMP 化的极端样本。能具体详述吗？ 2026-5-7 05:27 0
PanzerT 雪币： 6305 活跃值： (2760) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 55 粉丝 9 关注私信	PanzerT 13 楼 cecini 1. [但是由于eBPF的局限性，其无法替代FART等基于主动调用的脱壳工具](c1eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6T1L8r3!0Y4i4K6u0W2L8r3I4W2j5i4k6W2M7$3N6Q4x3X3g2@1L8%4m8Q4x3V1k6S2M7Y4c8A6j5$3I4W2i4K6u0r3k6f1u0b7c8V1c8W2P5p5c8#2L8i4m8W2M7W2)9J5z5b7`.`. 有什么局限，导致功能 ... 1. eBPF 局限带来的功能区别 eBPF/uProbe 方案的限制主要在“只能看到发生过的事”： - 没执行到的方法，不一定能拿到真实 CodeItem。壳如果按需解密方法体，只有方法真正进入解释器/ART 路径时，eBPF 才有机会记录。 - 它不能主动枚举类和方法，也不能替你调用每个方法。FART 的强项正是主动遍历类方法、触发方法解密，再 dump CodeItem 并回填。 - 如果代码走 AOT/JIT/native 快路径，绕开你挂的 ART 解释器点，eBPF 可能只能拿到整体 DEX，拿不到执行时还原的方法体。 - 如果内存中没有连续合法 DEX，只是 native 层临时拼出碎片、解密后马上擦除，通用 eBPF DEX 扫描也不一定能拼回完整文件。 - eBPF 内核侧不能随意做复杂逻辑，受 verifier、栈大小、ring buffer、用户内存读取限制影响。文章里也提到过内核侧分片传 DEX 容易丢数据，后来才转向用户态 process_vm_readv 读取。所以功能上可以这么理解： - eBPFDexDumper-rs 更适合：低侵入、被动捕获、拿运行时已加载的 DEX、记录已执行方法字节码、适合常规壳和动态加载场景。 - FART 更适合：代码抽取壳、方法体被 nop/占位替换、需要主动触发每个方法恢复真实 CodeItem 的场景。 - eBPF 的优势是隐蔽和部署轻；FART 的优势是覆盖率和主动性，但侵入更强，通常依赖 ART/系统改造或更重的运行时控制。 2. “不绕过所有反分析，不保证 native/VMP 极端样本”具体指什么 “反分析能力”这里不是一句泛泛而谈，具体包括这些： - 目标可以检测 root、调试环境、异常系统属性、可疑文件、SELinux 状态、Magisk 痕迹等。这个项目不会帮你隐藏这些环境特征。 - uProbe 不是完全无痕。它通常会在目标映射上留下可检测的断点式痕迹，强对抗样本可以校验 libart.so 代码页、扫描异常指令、检测性能/时序异常。 - 目标可以检测 BPF/tracing 相关状态，比如内核 tracing、perf/uProbe 行为、BPF program/map 痕迹。当前项目提供 --probe-mode lifecycle\|maps-only 降低探针面，但不是“反检测框架”。 - 目标可以不让敏感代码进入 ART 字节码路径，例如把核心逻辑搬到 native .so，Java 层只剩 JNI 壳或空方法。这种情况下 dump 出 DEX 也看不到核心算法。 - “完全 native 化”指业务逻辑已经变成 ARM64 机器码，DEX 里只有声明、桥接、加载器或少量壳代码。eBPF 盯 ART/DexFile 只能拿 Java 层结构，不能自动还原 native 算法。 - “VMP 化”指原始字节码被翻译成壳自定义虚拟机指令，运行时由 native VM 解释器执行。此时 DEX 里可能只剩 VM 入口和字节码 blob，真实语义在 native VM 指令集中，dump DEX 不等于还原源码。 - “代码抽取”指 DEX 方法体被 nop、空实现或占位结构替代，真实 CodeItem 在执行前才临时恢复。被动方案只能覆盖触发过的部分；没触发的仍然缺失。 2026-5-7 10:35 2
Gryffindoss 雪币： 635 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 124 粉丝 0 关注私信	Gryffindoss 14 楼 666 2026-5-7 16:42 0
cecini 雪币： 11 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 34 粉丝 0 关注私信	cecini 15 楼 PanzerT 1. eBPF 局限带来的功能区别 eBPF/uProbe 方案的限制主要在“只能看到发生过的事”： - 没执行到的方法，不一定能拿到真实 CodeItem。壳如果按需解密方法体，只有 ... 多谢详尽的解释 2026-5-7 19:49 0
mb_eumnbkwy 雪币： 22 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 20 粉丝 0 关注私信	mb_eumnbkwy 16 楼看看 2026-5-7 20:35 0
Imxz 雪币： 112 活跃值： (9405) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 750 粉丝 9 关注私信	Imxz 17 楼 tql 2026-5-8 11:16 0
bujianshi 雪币： 48 活跃值： (278) 能力值： ( LV2，RANK：15 ) 在线值：发帖 0 回帖 18 粉丝 0 关注私信	bujianshi 18 楼 tql 2026-5-8 14:37 0
artake 雪币： 10 活跃值： (2681) 能力值： ( LV4，RANK：40 ) 在线值：发帖 13 回帖 185 粉丝 1 关注私信	artake 19 楼 666 2026-5-8 17:51 0
mb_tciajwop 雪币： 190 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 11 粉丝 0 关注私信	mb_tciajwop 20 楼 666 2026-5-9 11:20 0
uni7corn 雪币： 0 活跃值： (2445) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 182 粉丝 0 关注私信	uni7corn 21 楼感谢分享。学习了 2026-5-9 13:52 0
Thehepta 雪币： 3596 活跃值： (7395) 能力值： ( LV11，RANK：185 ) 在线值：发帖 23 回帖 235 粉丝 282 关注私信	Thehepta 3 22 楼 1 2026-5-9 14:00 0
mb_lfwgtxdb 雪币： 8 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 61 粉丝 0 关注私信	mb_lfwgtxdb 23 楼感谢分享 2026-5-9 14:47 0
mb_rbvykvqm 雪币： 11 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 10 粉丝 0 关注私信	mb_rbvykvqm 24 楼感谢老铁 2026-5-9 16:17 0
小木马雪币： 241 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 31 粉丝 3 关注私信	小木马 25 楼 6666 2026-5-11 10:55 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

PanzerT

发帖

回帖

RANK

关注

私信

他的文章

关于我们

联系我们

企业服务

看雪公众号

最新回复 (69) 1 2 3 ▶
aut0run 雪币： 2220 活跃值： (702) 能力值： ( LV5，RANK：60 ) 在线值：发帖 5 回帖 11 粉丝 13 关注私信	aut0run 1 2 楼感觉有点东西啊 2026-5-6 12:06 0
墨穹呢雪币： 4704 活跃值： (8122) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 224 粉丝 18 关注私信	墨穹呢 3 楼感谢分享 2026-5-6 12:47 0
温泉划水鱼雪币： 84 能力值： ( LV1，RANK：0 ) 在线值：发帖 6 回帖 224 粉丝 28 关注私信	温泉划水鱼 4 楼 6 2026-5-6 13:46 0
xianhuimin 雪币： 9281 活跃值： (6143) 能力值： ( LV2，RANK：10 ) 在线值：发帖 5 回帖 226 粉丝 2 关注私信	xianhuimin 5 楼 666 2026-5-6 14:39 0
xingbing 雪币： 158 活跃值： (5651) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 1373 粉丝 2 关注私信	xingbing 6 楼谢谢分享 2026-5-6 16:50 0
Zepp7289 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 137 粉丝 0 关注私信	Zepp7289 7 楼 tql 2026-5-6 17:23 0
mb_ssjlfpnk 雪币： 200 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 10 粉丝 0 关注私信	mb_ssjlfpnk 8 楼 2026-5-6 20:20 0
Viseris 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 70 粉丝 0 关注私信	Viseris 9 楼谢谢分享 2026-5-6 22:25 0
jyotidwi 雪币： 1278 能力值： ( LV1，RANK：0 ) 在线值：发帖 3 回帖 121 粉丝 3 关注私信	jyotidwi 10 楼 tql 2026-5-7 00:16 0
cecini 雪币： 11 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 34 粉丝 0 关注私信	cecini 11 楼这已经在生产上使用了吗 2026-5-7 04:59 0
cecini 雪币： 11 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 34 粉丝 0 关注私信	cecini 12 楼 1. [但是由于eBPF的局限性，其无法替代FART等基于主动调用的脱壳工具](7d9K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6T1L8r3!0Y4i4K6u0W2L8r3I4W2j5i4k6W2M7$3N6Q4x3X3g2@1L8%4m8Q4x3V1k6S2M7Y4c8A6j5$3I4W2i4K6u0r3k6f1u0b7c8V1c8W2P5p5c8#2L8i4m8W2M7W2)9J5z5b7`.`. 有什么局限，导致功能上有什么区别吗 2 它不试图绕过所有反分析能力，也不保证覆盖完全 native 化或 VMP 化的极端样本。能具体详述吗？ 2026-5-7 05:27 0
PanzerT 雪币： 6305 活跃值： (2760) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 55 粉丝 9 关注私信	PanzerT 13 楼 cecini 1. [但是由于eBPF的局限性，其无法替代FART等基于主动调用的脱壳工具](c1eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6T1L8r3!0Y4i4K6u0W2L8r3I4W2j5i4k6W2M7$3N6Q4x3X3g2@1L8%4m8Q4x3V1k6S2M7Y4c8A6j5$3I4W2i4K6u0r3k6f1u0b7c8V1c8W2P5p5c8#2L8i4m8W2M7W2)9J5z5b7`.`. 有什么局限，导致功能 ... 1. eBPF 局限带来的功能区别 eBPF/uProbe 方案的限制主要在“只能看到发生过的事”： - 没执行到的方法，不一定能拿到真实 CodeItem。壳如果按需解密方法体，只有方法真正进入解释器/ART 路径时，eBPF 才有机会记录。 - 它不能主动枚举类和方法，也不能替你调用每个方法。FART 的强项正是主动遍历类方法、触发方法解密，再 dump CodeItem 并回填。 - 如果代码走 AOT/JIT/native 快路径，绕开你挂的 ART 解释器点，eBPF 可能只能拿到整体 DEX，拿不到执行时还原的方法体。 - 如果内存中没有连续合法 DEX，只是 native 层临时拼出碎片、解密后马上擦除，通用 eBPF DEX 扫描也不一定能拼回完整文件。 - eBPF 内核侧不能随意做复杂逻辑，受 verifier、栈大小、ring buffer、用户内存读取限制影响。文章里也提到过内核侧分片传 DEX 容易丢数据，后来才转向用户态 process_vm_readv 读取。所以功能上可以这么理解： - eBPFDexDumper-rs 更适合：低侵入、被动捕获、拿运行时已加载的 DEX、记录已执行方法字节码、适合常规壳和动态加载场景。 - FART 更适合：代码抽取壳、方法体被 nop/占位替换、需要主动触发每个方法恢复真实 CodeItem 的场景。 - eBPF 的优势是隐蔽和部署轻；FART 的优势是覆盖率和主动性，但侵入更强，通常依赖 ART/系统改造或更重的运行时控制。 2. “不绕过所有反分析，不保证 native/VMP 极端样本”具体指什么 “反分析能力”这里不是一句泛泛而谈，具体包括这些： - 目标可以检测 root、调试环境、异常系统属性、可疑文件、SELinux 状态、Magisk 痕迹等。这个项目不会帮你隐藏这些环境特征。 - uProbe 不是完全无痕。它通常会在目标映射上留下可检测的断点式痕迹，强对抗样本可以校验 libart.so 代码页、扫描异常指令、检测性能/时序异常。 - 目标可以检测 BPF/tracing 相关状态，比如内核 tracing、perf/uProbe 行为、BPF program/map 痕迹。当前项目提供 --probe-mode lifecycle\|maps-only 降低探针面，但不是“反检测框架”。 - 目标可以不让敏感代码进入 ART 字节码路径，例如把核心逻辑搬到 native .so，Java 层只剩 JNI 壳或空方法。这种情况下 dump 出 DEX 也看不到核心算法。 - “完全 native 化”指业务逻辑已经变成 ARM64 机器码，DEX 里只有声明、桥接、加载器或少量壳代码。eBPF 盯 ART/DexFile 只能拿 Java 层结构，不能自动还原 native 算法。 - “VMP 化”指原始字节码被翻译成壳自定义虚拟机指令，运行时由 native VM 解释器执行。此时 DEX 里可能只剩 VM 入口和字节码 blob，真实语义在 native VM 指令集中，dump DEX 不等于还原源码。 - “代码抽取”指 DEX 方法体被 nop、空实现或占位结构替代，真实 CodeItem 在执行前才临时恢复。被动方案只能覆盖触发过的部分；没触发的仍然缺失。 2026-5-7 10:35 2
Gryffindoss 雪币： 635 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 124 粉丝 0 关注私信	Gryffindoss 14 楼 666 2026-5-7 16:42 0
cecini 雪币： 11 能力值： ( LV1，RANK：0 ) 在线值：发帖 2 回帖 34 粉丝 0 关注私信	cecini 15 楼 PanzerT 1. eBPF 局限带来的功能区别 eBPF/uProbe 方案的限制主要在“只能看到发生过的事”： - 没执行到的方法，不一定能拿到真实 CodeItem。壳如果按需解密方法体，只有 ... 多谢详尽的解释 2026-5-7 19:49 0
mb_eumnbkwy 雪币： 22 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 20 粉丝 0 关注私信	mb_eumnbkwy 16 楼看看 2026-5-7 20:35 0
Imxz 雪币： 112 活跃值： (9405) 能力值： ( LV2，RANK：10 ) 在线值：发帖 6 回帖 750 粉丝 9 关注私信	Imxz 17 楼 tql 2026-5-8 11:16 0
bujianshi 雪币： 48 活跃值： (278) 能力值： ( LV2，RANK：15 ) 在线值：发帖 0 回帖 18 粉丝 0 关注私信	bujianshi 18 楼 tql 2026-5-8 14:37 0
artake 雪币： 10 活跃值： (2681) 能力值： ( LV4，RANK：40 ) 在线值：发帖 13 回帖 185 粉丝 1 关注私信	artake 19 楼 666 2026-5-8 17:51 0
mb_tciajwop 雪币： 190 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 11 粉丝 0 关注私信	mb_tciajwop 20 楼 666 2026-5-9 11:20 0
uni7corn 雪币： 0 活跃值： (2445) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 182 粉丝 0 关注私信	uni7corn 21 楼感谢分享。学习了 2026-5-9 13:52 0
Thehepta 雪币： 3596 活跃值： (7395) 能力值： ( LV11，RANK：185 ) 在线值：发帖 23 回帖 235 粉丝 282 关注私信	Thehepta 3 22 楼 1 2026-5-9 14:00 0
mb_lfwgtxdb 雪币： 8 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 61 粉丝 0 关注私信	mb_lfwgtxdb 23 楼感谢分享 2026-5-9 14:47 0
mb_rbvykvqm 雪币： 11 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 10 粉丝 0 关注私信	mb_rbvykvqm 24 楼感谢老铁 2026-5-9 16:17 0
小木马雪币： 241 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 31 粉丝 3 关注私信	小木马 25 楼 6666 2026-5-11 10:55 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复