Skip to content

Commit

Permalink
Fix bug: when callee_path_name is specified when hooking, the unhook …
Browse files Browse the repository at this point in the history 
…will fail.
  • Loading branch information
@caikelun
caikelun committed Sep 26, 2022
1 parent 81967e7 commit 5c74c1a
Showing 1 changed file with 2 additions and 2 deletions.
4 changes: 2 additions & 2 deletions bytehook/src/main/cpp/bh_hook_manager.c
View file
Original file line number Diff line number Diff line change
Expand Up @@ -524,8 +524,8 @@ void bh_hook_manager_hook(bh_hook_manager_t *self, bh_task_t *task, bh_elf_t *ca
void bh_hook_manager_unhook(bh_hook_manager_t *self, bh_task_t *task, bh_elf_t *caller_elf) {
// get all GOT entries
void *addr_array[BH_HOOK_MANAGER_GOT_MAX_CAP];
size_t addr_array_sz =
bh_hook_manager_find_all_got(caller_elf, task, addr_array, BH_HOOK_MANAGER_GOT_MAX_CAP);
size_t addr_array_sz = bh_elf_find_import_func_addr_by_symbol_name(caller_elf, task->sym_name, addr_array,
BH_HOOK_MANAGER_GOT_MAX_CAP);
if (0 == addr_array_sz) return;

// unhook
Expand Down

6 comments on commit 5c74c1a

@zhbzhbzhbz
Copy link

@zhbzhbzhbz zhbzhbzhbz commented on 5c74c1a Oct 12, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

太感谢了~~~ @caikelun
我的项目之前一直有个bug，就是unhook不稳定的情况。项目就是做文件加解密，Demo里Java层读写txt并用snackbar展示，用这个库启用hook时，libc.so的read/write方法会被hook，实现逐字符的解密(read()时)或加密(write()时)，unhook时会则不会。核心函数是这个：
read_stub = bytehook_hook_all("libc.so", "read", (void *) read_proxy, NULL, NULL);
write_stub = bytehook_hook_all("libc.so", "write", (void *) write_proxy, NULL, NULL);
不稳定的情况在于，如果启用hook后读取txt并弹出了snackbar（此时hook了read()，文字被解密），然后——在snackbar没有消失时立刻unhook再读取txt，正常来说应该读取到乱码（因为unhook后read()不再经过解密），然而，还是会显示解密后的文字；如果想避免这个问题，一般需要hook并读取txt后，等snackbar消失2秒后再unhook，此时读取到的大概率才是未解密的文字。
我一直以为是我自己的问题，同事分析说可能是“整个调用链路的符号表，不知因为什么原因，还是使用的上次的”。
我这次更新版本之后，这个bug没再出现，请问不知道是不是解决了？

@caikelun
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

嗯嗯，那应该就是这个问题了，要100%确认的话，可以对比下两个版本unhook时的bytehook logcat调试信息，看看是不是旧版本unhook是失败的。

@zhbzhbzhbz
Copy link

@zhbzhbzhbz zhbzhbzhbz commented on 5c74c1a Oct 12, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

嗯嗯，那应该就是这个问题了，要100%确认的话，可以对比下两个版本unhook时的bytehook logcat调试信息，看看是不是旧版本unhook是失败的。

这方面的话，我之前测试时，旧版本的unhook函数的返回值倒是正常的hhh，也没有任何报错，包括对比了##_stub的地址也都匹配，所以当时比较烦恼
如果之前触发这个bug的话，返回值会是有问题的么？

@caikelun
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

是的，这个bug unhook时并不会返回失败。另外，在旧版本中，把hook all的第一个参数从libc.so改成NULL也可以规避这个bug。

@zhbzhbzhbz
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

是的，这个bug unhook时并不会返回失败。另外，在旧版本中，把hook all的第一个参数从libc.so改成NULL也可以规避这个bug。

哇感谢~~好的！非常感谢哈哈哈~ 解决了一个心病

@caikelun
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

不用客气哈

Please sign in to comment.