shadowhook v1.0.10

[caikelun]

Announcements

1. Compatible with Android 15.

Support 16 KB page sizes.

Bugs fixed

1. Fixed the bug when querying the address of indirect function.

When querying the address of indirect function (STT_GNU_IFUNC), the correct address can now be returned. Previously, the address of the indirect function itself was incorrectly returned.

This will result in the following in previous versions: if you hook the indirect function through shadowhook_hook_sym_name() or shadowhook_hook_sym_name_callback(), the target function will not be hooked; if you use shadowhook_dlsym() or shadowhook_dlsym_dynsym() to query the indirect function, the wrong function address will be returned.

In most Android systems, memcpy is an indirect function.

Improvements

1. Improved the judgment logic of the starting character of the symbol name hash suffix.

Previously, it only contained ., and now $ is added.

In the shadowhook public API, if you need to enter a symbol name (function name) in string form, do not include the hash suffix generated by LLVM, which may change after recompilation. For example:

1. _ZNSt3__110__function6__funcIZN7android10uirenderer12renderthread13DrawFrameTask11postAndWaitEvE3$_0NS_9allocatorIS6_EEFvvEEclEv$c1671e787f244890c877724752face20: $c1671e787f244890c877724752face20 is a hash suffix, and the starting character of the suffix is ​​$. When entering the symbol name, you should enter _ZNSt3__110__function6__funcIZN7android10uirenderer12renderthread13DrawFrameTask11postAndWaitEvE3$_0NS_9allocatorIS6_EEFvvEEclEv.

2. _ZNSt3__110__function6__funcIZN7android10uirenderer10RenderNode15handleForceDarkEPNS3_8TreeInfoEE3$_0NS_9allocatorIS7_EEFvPS4_EE7destroyEv.__uniq.10397782060659495822194741288103189803.907f77e9b59bd29450c46d69c21b9e58: .__uniq.10397782060659495822194741288103189803.907f77e9b59bd29450c46d69c21b9e58 is a hash suffix, and the starting character of the suffix is .. When entering the symbol name, you should enter _ZNSt3__110__function6__funcIZN7android10uirenderer10RenderNode15handleForceDarkEPNS3_8TreeInfoEE3$_0NS_9allocatorIS7_EEFvPS4_EE7destroyEv.

2. Improved the execution speed of shadowhook_hook_func_addr().

During the execution of shadowhook_hook_func_addr(), the symbol information is no longer queried, only the program headers information of the corresponding ELF is queried. When hooking ELF files with many symbols, it can greatly shorten the time consumption.

公告

1. 兼容 Android 15。

支持 16 KB page sizes。

Bugs 修复

1. 修正了查询 indirect function 地址时的 bug。

查询 indirect function (STT_GNU_IFUNC) 地址时，现在能返回正确的地址了，之前错误的返回了 indirect function 本身的地址。

这会导致在之前的版本中：如果通过 shadowhook_hook_sym_name() 或 shadowhook_hook_sym_name_callback() hook indirect function，不会真正的 hook 目标函数；如果用 shadowhook_dlsym() 或 shadowhook_dlsym_dynsym() 查询 indirect function，返回错误的函数地址。

在大多数 Android 系统中，memcpy 就是一个 indirect function。

改进

1. 改进了符号名 hash 后缀起始符的判断逻辑。

之前只包含了 .，现在增加了 $。

在 shadowhook 的 public API 中，如果需要输入字符串形式的符号名（函数名）时，不用包含 LLVM 生成的 hash 后缀，这部分后缀重新编译后可能会改变。例如：

1. _ZNSt3__110__function6__funcIZN7android10uirenderer12renderthread13DrawFrameTask11postAndWaitEvE3$_0NS_9allocatorIS6_EEFvvEEclEv$c1671e787f244890c877724752face20：$c1671e787f244890c877724752face20 是 hash 后缀，后缀的起始符是 $。输入符号名时应该输入 _ZNSt3__110__function6__funcIZN7android10uirenderer12renderthread13DrawFrameTask11postAndWaitEvE3$_0NS_9allocatorIS6_EEFvvEEclEv。

2. _ZNSt3__110__function6__funcIZN7android10uirenderer10RenderNode15handleForceDarkEPNS3_8TreeInfoEE3$_0NS_9allocatorIS7_EEFvPS4_EE7destroyEv.__uniq.10397782060659495822194741288103189803.907f77e9b59bd29450c46d69c21b9e58：.__uniq.10397782060659495822194741288103189803.907f77e9b59bd29450c46d69c21b9e58 是 hash 后缀，后缀的起始符是 .。输入符号名时应该输入 _ZNSt3__110__function6__funcIZN7android10uirenderer10RenderNode15handleForceDarkEPNS3_8TreeInfoEE3$_0NS_9allocatorIS7_EEFvPS4_EE7destroyEv。

2. 改进了 shadowhook_hook_func_addr() 的执行速度。

在执行 shadowhook_hook_func_addr() 的过程中，不再查询符号信息，仅查询对应 ELF 的 program headers 信息。在 hook 有很多符号的 ELF 文件时，能极大的缩短耗时。

---

This discussion was created from the release shadowhook v1.0.10.