看名字，好像是 xHook 作者跳到字节搞的，跟 xHook 相比有啥改进吗？

跟xhook不能说完全一样，只能说一模一样，恭喜跳槽加薪啊

twsxtd 看名字，好像是 xHook 作者跳到字节搞的，跟 xHook 相比有啥改进吗？

很显然就是xhook加了个dlopen的hook功能，别的实际上是一样的

lhxdiao 跟xhook不能说完全一样，只能说一模一样，恭喜跳槽加薪啊

下个月跳去企鹅, 没来个thook

我是作者。

先简单列一下 xHook 的不足之处：

* native 崩溃兜底机制有缺陷，导致线上崩溃无法完全避免。
* 无法自动对新加载的 ELF 执行 hook。（需要外部反复调用 `refresh` 来“发现”新加载的 ELF。但是在什么时机调用 `refresh` 呢？频率太高会影响性能，频率太低会导致 hook 不及时）
* 由于依赖于链式调用的机制。如果一个调用点被多次 hook，在对某个 proxy 函数执行 unhook 后，链中后续的 proxy 函数就会丢失。
* 只使用了读 maps 的方式来遍历 ELF。在高版本 Android 系统和部分机型中兼容性不好，经常会发生 hook 不到的情况。
* API 设计中使用了正则来指定 hook 哪些目标 ELF，运行效率不佳。
* 需要在真正执行 hook 前，注册完所有的 hook 点，一旦开始执行 hook（调用 `refresh` 后），不能再添加 hook 点。这种设计是很不友好的。
* 无法适配 Android 8.0 引入 Linker Namespace 机制（同一个函数符号，在进程中可能存在多个实现）。
* 无法自动避免 proxy 函数之间的环形调用（比如：`open` 的 proxy 函数中调用了 `read`，然后 `read` 的 proxy 函数中又调用了 `open`。如果这两个 proxy 存在于两个独立的 SDK 中，此时形成的环形调用将很难在 SDK 开发阶段被发现。如果在更多的 SDK 之间形成了一个更大的 proxy 函数调用环，情况将会失去控制。）

bhook 把上面这些问题都解决了。而且 bhook 是目前字节用于线上的 plt hook 方案，主要的几个app都在用。线上稳定性、功能性、性能这几个方面都达到了预期。

nomagic 我是作者。 先简单列一下 xHook 的不足之处： * native 崩溃兜底机制有缺陷，导致线上崩溃无法完全避免。 * 无法自动对新加载的 ELF 执行 hook。（需要外部反复调用 ...

666

ELF, 试过memcpy系列基本的libc函数吗？会不会死循环？

xhook 爱奇艺的吧

首先，感谢作者开源，这么牛逼的开源，感谢分享。
然后，还是字节工资高，所以xhook多解决几个问题；至于楼上说的，下个月跳槽去企鹅，来个thook也是不错的方案嘛，咱们可以多来几个开源库对比以下~~~

问个小问题，如下：
static int read_proxy_auto(...){
    int fd = BYTEHOOK_CALL_PREV(read_proxy_auto,...);
    BYTEHOOK_POP_STACK();
    return fd;
}
static int open_real_proxy_auto(...){
    int fd = BYTEHOOK_CALL_PREV(open_real_proxy_auto,...);

    //1.在这个位置需要调用read函数，是调用read_proxy_auto，还是调用read?
    //2.如果想直接调用原函数read，不经过proxy，应该怎么调？

    BYTEHOOK_POP_STACK();
    return fd;
}