If you’re familiar with Windows runtime code injection you probably know the great API CreateRemoteThread which lets us force an arbitrary running process to call LoadLibrary and load a DLL into its address space, this technique called DLL Injection is often used to perform user space API hooking, you can find a good post about it on Gianluca Braga’s blog.
Unfortunately there’s no CreateRemoteThread equivalent on Linux system, therefore we can only rely on ptrace and our brain :D
In this post I’ll explain how to perform DLL Injection on Linux systems and more specifically on Android/ARM.
Part 2 of this post on “Android Native API Hooking with Library Injection and ELF Introspection.”
Fuck you, really! <3
I’m awesome, you’re a lazy scumbag … and the full source code can be found on the arminject repository on my github page.
Once we’re attached to the process with ptrace, the first task we have is to obtain the address of the functions we’re gonna need for our purpose, namely:
- dlopen for obvious reasons.
- dlsym if we want to remotely call a function of the injected library.
- calloc/malloc to allocate strings in the target process memory.
- free to release that memory.
The problem here is to somehow defeat/bypass the address space layout randomization, we know the address of these symbols in our own process but we surely don’t in the target process since ASLR screwed these up.
What we do know is that a given symbol will have the same exact offset from the library base address and we definitely can determine the library base address in the target process analyzing its /proc/-pid-/maps file:
Once we know the base address of a given library both in our process and in the target process, what we can do to resolve the remote function address is:
REMOTE_ADDRESS = LOCAL_ADDRESS + ( REMOTE_BASE - LOCAL_BASE )
Basically we take the local address of the function and apply to it the difference between the local library base address and the remote one, which is exactly what the following code does:
Finally we’ve bypassed the ASLR problem :)
Next, we need to figure out how to force the process to execute a call to an address controlled by us ( one of the previously mentioned functions ), in order to do that we need to understand the ARM calling convention which, fortunately, is quite easy.
The first four arguments for a function are put inside registers from R0 to R3 while any other argument ( if any of course ) are pushed onto the stack.
Eventually the function address is put on the PC ( R15 ) register and the return address into the LR ( R14 ) register, this will cause the effective call to that function. The return value will be found inside the RO register.
You can find a pretty good document about this, the “Practical ARM exploitation manual”, here.
What I did is the following:
- Use PTRACE_GETREGS to save the current process registers.
- Put the arguments of the function into R0-R3 and on the stack if needed.
- Set LR to 0, so we can catch the SIGSEGV after the call.
- Set PC to the function address.
- Mask PC and CPSR accordingly to the mode ( thumb or arm ).
- Update the registers with PTRACE_SETREGS.
- Trigger the call with PTRACE_CONT and wait for the process to SIGSEGV while returing to address 0 in LR.
- Get the function return value from RO.
- Restore the original registers.
The code, which uses variadic macros for convenience, is the following:
The next steps are basically putting all of this together:
- Get the needed functions addresses.
- Use the remote malloc/calloc to copy the library name string into the remote process.
- Use the remote dlopen with the previously allocated buffer to load the library.
- Use the remote dlsym if needed.
Once you have your library injected, you can do quite a few things, like dynamic API hooking/tracing/patching ( libandroid_runtime.so anyone ? :D ), process introspection, runtime memory patching and generally speaking …