Crash Analysis of Inline Hook Implementation with Substrate on ARM Thumb

When using substrate to hook a function via an Inline HOOK on the ARM Thumb instruction set, a crash occurs at an unexpected address. After ruling out parameter and calling‑convention issues, the article first explains the principle of Inline HOOK, then analyzes the crash using logs and dynamic debugging, and finally summarizes the general cause.

Inline HOOK modifies the first N assembly instructions of a target function to jump to a HOOK function. In Thumb mode, Substrate replaces the first 12 bytes of the function with a sequence that jumps to address 0x0004 using BX PC , switches to ARM mode, and then loads the HOOK address with LDR PC, [PC, #-4] .

The second step copies the original first 12 bytes into a newly allocated memory region, executes them, and then jumps back to the original function after those bytes, completing the Inline HOOK process.

The crash log shows the faulting address 0x74daa000 , which lies outside the dynamic library containing the original function. The memory region allocated by Substrate for the HOOK starts at 0x74da9000 , so the crash occurs at an offset of +0x1000 within that region. By inspecting the original function’s pre‑hook bytes, the analysis reveals that an ADR instruction obtains a PC‑relative address that becomes incorrect when the execution environment changes, leading to a wrong address being stored in R1 and eventually causing the program to jump to 0x74da903b and crash.

Thus, the root cause is that a PC‑relative ADR instruction retrieves an address that is no longer valid after the hook modifies the control flow. When the first 12 bytes contain PC‑related instructions, they must be corrected during hooking.

The article concludes with a list of common PC‑related instructions that require special handling and notes that this is a Substrate bug rather than an inherent limitation of Inline HOOKs.