有几个实现细节想跟楼主交流确认一下，主要是“透明”和“转发”这块。

1. 文章里说的是透明代理，但我理解这里可能有两种完全不同的透明：
第一种是“对调用方App透明”。比如只针对某个App的某个Binder code，把 target.handle改到自己的代理服务，然后代理服务直接mock一个返回值，比如你说的签名校验直接返回通过。
这个场景我理解是成立的，因为App侧只看到这次 Binder调用返回了它期望的Parcel，确实没有标准办法知道到底是谁处理了这个transaction。

第二种是“对原始系统服务也透明”，链路就变成：
调用方 -> 代理服务 -> 原始系统服务 -> 代理服务 -> 调用方

这里我有个疑问：原始系统服务看到的caller不就变成代理服务了吗？比如getCallingUid/getCallingPid，应该都会变。如果没做处理，我理解就不能叫完整透明，只能说对调用方透明。

这里就明显跟你说的“不重新实现Binder协议栈，也不重新实现Parcel编解码”不一致了，如果代理服务要做转发、修改请求或修改返回，业务层还是要正确处理这些东西的，这个边界文章里感觉没说清楚。

2.基于上面这个问题，关于你的实现中，如果目标是system_server / PackageManagerService / 厂商自己的服务发起Binder请求，如果内部会检查 getCallingUid，这种怎么处理？
还是说这个方案的主要目标其实是App侧特定code的结果替换，比如签名校验、包信息查询这类，并不打算做通用透明转发？

PS：另外handle这块我理解应该是在目标进程内初始化时分别拿originalHandle和proxyHandle，因为Binder handle是进程独立的，如果不是目标进程内拿handle，就需要内核直接操作binder_ref，难度会高很多

月落之汀 有几个实现细节想跟楼主交流确认一下，主要是“透明”和“转发”这块。1. 文章里说的是透明代理，但我理解这里可能有两种完全不同的透明：第一种是“对调用方App透明”。比如只针对某个Ap ...

孤木落 请问你问的是ebpf方案还是seccomp方案?

月落之汀 我理解我应该问的是ebpf的方案，如果方便交流的话，还请解惑，谢谢