Kelun Cai

> native崩溃是怎么做到不闪退的，大佬 不能做到

@xuqnqn 帮忙看看吧～

@yimun 是的，目前执行hook的时机是dlopen完成之后，所以.init和.init_array中的逻辑在执行时还没有hook。我有空想想怎么提前一下hook时机，有什么好的建议和想法欢迎一起探讨哈～

> 手机：Xiaomi MI NOTE Pro 系统：Android 5.1.1 bhook： 1.0.3 > > ``` > bytehook_init(BYTEHOOK_MODE_AUTOMATIC, true); > bytehook_hook_all(nullptr, "getaddrinfo", (void*)MY_getaddrinfo, hookCallbac, nullptr); > ``` > > 以上代码执行完后再加载webview，无法hook libwebviewchromium.so 但是，先在加载webview后再执行以上代码，则可以hook到libwebviewchromium.so 收到，感谢反馈，我调试一下。

@0x6666 我没找到和你一样的机型。我在 nexus5(Android 5.1.1) 上试了，无论在 `bytehook_hook_all` 之前或之后加载 libwebviewchromium.so，都可以 hook 到 libwebviewchromium.so 中的 `getaddrinfo`。你可以把 bytehook 的日志打开，观察下 hook 之前和之后加载libwebviewchromium.so的执行流程区别，或者把日志在这里贴一下。

Android 5.x 应该只可能走`dlopen` 和 `android_dlopen_ext`。bytehook 内部对这两个函数做了 hook_all（hook 到 `bh_dl_monitor_proxy_dlopen` 和 `bh_dl_monitor_proxy_android_dlopen_ext`）。可以看下日志，判断下这两个函数都hook到哪些 caller so 上了。 另外，你本地代码是否修改过其他地方？换个其他5.1.1的设备也能重现问题吗？

嗯，确实存在这个问题，感谢指出。这个其实是“首次refresh”和“dlopen监听机制完成启动之前”的间隙。也许可以在bytehook初始化的最后阶段调用一下`bh_task_manager_init_dl_monitor`，然后再调用一次refresh，这样在初始化完成后就不会出现这个问题了。 bytehook比较早的内部版本是在初始化时就执行dlopen监听和refresh的，后来为了加快初始化速度，才这样调整的。后续版本我研究下怎么弥补这个问题。。。

> 还有个疑问是 dl_iterate_phdr 和 /proc/self/maps 可以拿到当前进程已经加载的所有共享对象，是不是也有可能不是最新的？比如我遍历 /proc/self/maps 的每一行，假如遍历的中途有个新的动态库加载，会出现遍历不到这个动态库的情况吗 是的，单纯遍历maps是有可能有这种问题。bytehook在dlopen监听机制启动后应该就不会有这个问题了。

@AlphaHans 编译警告的问题我有空改一下，暂时请先使用readme中的方法用 NDK r16b 编译吧。 可以用 `xhook_register` 函数的最后一次参数，保留原 malloc 函数的地址，myMalloc 中使用这个函数地址来调用原 malloc。

@fr0zenrain r16b是最后一个官方支持 armeabi 的版本，ndk版本太低的话bug比较多，建议升级哦。需要 flush cache，你可以把 flush 的逻辑临时去掉对比试一下。