它的定位#

设计上非常克制，先把边界划清楚：

• 只处理单个目标 PID；
• 只做读取，不做写入；
• 支持模块基址解析（libc.so+0x1234 这种）；
• 支持单地址 / 小范围读取；
• 支持一次性批量读取多个地址范围；
• 提供设备侧常驻 helper、TCP 服务和 Python 长连接客户端。

换句话说，它更像是一条「把单进程读取路径工程化」的基线，而不是一个什么都能干的万能内存工具。后续优化重点也明确放在读取延迟、批量效率、连接复用和 helper 稳定性上。

整体架构#

代码分成设备侧 C helper 和上层 Python 工具两半，中间用 TCP 通信。

核心读取链路：怎么读「另一个进程」的内存#

这是整个项目最值得讲的部分。要读目标进程的用户态虚拟地址，难点在于——页表本身在内核里。所以读取分两步走。

1
/* mem.ebpf.c 节选：拒绝非内核地址，再 probe read */
2
#ifdef __TARGET_ARCH_arm64
3
    if (address < 0xfff0000000000000ULL) {   /* 不像内核指针，拒绝 */
4
        read_mem_result->ret_code = -EINVAL;
5
        return 0;
6
    }
7
#endif
8
read_mem_result->ret_code =
9
    bpf_probe_read_kernel((void *)(&read_mem_result->buf), dump_size, (void *)address);

模块基址解析#

pid_modules.c 负责枚举目标进程的映射（/proc/<pid>/maps 风格的 VMA），给出模块列表和基址。CLI 上对应：

• --list-modules：列出目标 PID 当前映射到的模块；
• --module-base <name-or-path>：只返回模块基址（不顺便读数据）；
• 读取表达式支持 libc.so+0x0:16、libc.so!0x0:16 这种「模块 + 偏移」，批量用逗号 / 分号分隔。

如果模块 basename 有歧义，就传完整映射路径。

设备侧 helper 与协议#

构建出来的 pidread.ebpf.android 支持这些模式：

• --read-virt <expr>：读一个地址范围；
• --read-batch <file|inline>：一次读多个范围（一请求一结果，不会偷偷折成一个大块）；
• --bench-read <expr>：在 helper 进程内重复读同一目标，测读取路径本身；
• --session-stdin：常驻会话，从 stdin 连续收命令；
• --tcp-server <port>：启动 TCP helper 给上层 Python 复用；--tcp-server-public 绑定 0.0.0.0 用于局域网直连。

session 和 TCP 共用一套紧凑命令语义。短命令：r <expr> / rb <expr1,expr2> / m <module> / lm / stats / group-reads on|off / shutdown / q；长命令：read-virt / read-batch / module-base / list-modules / out-format。响应是 OK READ ... / OK BATCH ... / OK MODULE ... / ERR <code> <message> 这种。TCP helper 同时支持文本行协议和二进制协议，Python 侧优先走二进制。

Python 工具链#

上层工具已经统一成 Python，方便嵌到自己的分析脚本里：

• pidread_proxy.py：用 adb 启动设备侧 TCP helper，管理 adb-forward 或局域网直连（--transport adb-forward|direct，推荐 direct，数据直走手机局域网地址）。
• pidread_client.py：长连接 TCP 客户端，适合反复下发文本命令、做重复读测试、手动验状态，默认复用同一连接。
• pidread_reader.py：面向嵌入调用的 API，提供 get_module_base() / get_module_info() / read() / read_bytes() / read_many() / read_many_batch() / read_many_individual() / iter_read_many() / set_group_reads() / get_stats_line()，以及类型化 helper read_u8/u16/u32/u64/i32/i64/ptr/cstring()。请求支持字符串表达式、(address, size)、(module, offset, size) 三种写法。
• pidread_session.py：--session-stdin 的 Python 启动器，临时起会话、复用设备侧缓存做交互式读取。

构建#

1
powershell -ExecutionPolicy Bypass -File .\build-android.ps1 -Strip

1
make MODE=nocoreuni

一个最小工作流#

1
# 1. 设备侧直接读模块基址
2
.\build-android\pidread.ebpf.android -t --pid 26389 --module-base /lib64/bionic/libc.so --out-format json
3

4
# 2. 设备侧读一个地址范围
5
.\build-android\pidread.ebpf.android -t --pid 26389 --read-virt libc.so+0x0:16 --out-format json
6

7
# 3. 批量读 + 邻近合并抓取
8
.\build-android\pidread.ebpf.android -t --pid 26389 --read-batch "libc.so+0x0:16,libc.so+0x10:16" --group-reads --out-format json
9

10
# 4. 局域网直连代理（推荐）
11
python .\pidread_proxy.py --target-pid 26389 --trigger test_run --transport direct --push

用 Python API 读取则更简洁：

1
from pidread_reader import PidReadReader
2

3
with PidReadReader(host="192.168.1.50", port=31337) as reader:
4
    libc_base = reader.get_module_base("/lib64/bionic/libc.so")
5
    header = reader.read(("libc.so", 0, 16))
6
    values = reader.read_many([
7
        ("libc.so", 0x0, 16),
8
        ("libc.so", 0x10, 16),
9
    ])
10
    print(hex(libc_base), header.hex(), len(values))

明确不做什么#

项目边界划得很清楚，避免被误用或膨胀：

• 不做写内存；
• 不做全内存 dump；
• 不把 --module-base 混入读数据接口；
• 不把 --read-batch 的多个结果偷偷折成单块输出。

⚠️ 它是 root / 内核级的只读调试实验代码，只建议在自己拥有且可控的设备上做研究。读取的是进程内存，请务必只针对你有权分析的目标，遵守相关安全与法律边界。

pidread-ebpf 是我把「eBPF 安全读内核 + 页表翻译 + 用户态读取」这套组合在 Android 上跑通的一次实践。最让我满意的点是那个三级触发自动降级（uprobe → XDP → PROG_TEST_RUN）——在不同内核 / 不同权限环境下都能尽量把读取链路建立起来。如果有人感兴趣，后面可以单独写一篇讲讲 ARM64 页表遍历里 va_bits 探测和 phys_to_virt 换算的那些坑。

项目源码与构建脚本在本地工程 30_Android_EBPF_PID_Read 中。