Target process killed by injection

[t0kt0ckus]

First, I'm very interested by this tool's possibilities, and would like to thank you for sharing your work.

I'm testing with a KitKat 4.4.4 device, kernel 3.4.42. Android NDK tools are the latest (r10, toolchains 4.6 and 4.8). GNU Make 3.81 et GCC 4.8.2.

I'm simply following the example included in the README.
Compilation and invocation go smooth:

root@falcon_umts:/data/local/tmp # ./hijack -d -p 1316 -l ./libexample.so      
mprotect: 0x400f0670
dlopen: 0x400a8f31
pc=400f190c lr=40159653 sp=beeda328 fp=beeda4bc
r0=fffffffc r1=beeda348
r2=10 r3=ffffffff
stack: 0xbeeba000-0xbeedb000 leng = 135168
executing injection code at 0xbeeda2d8
calling mprotect
library injection completed!

But, the adbi_example.log file is empty, and remains empty for ever.
Reading logcat, it seems that the target process (in this case com.android.phone, as suggested) is killed as soon as injected code begins execution:

F/libc    ( 1316): Fatal signal 11 (SIGSEGV) at 0x0000000c (code=1), thread 1316 (m.android.phone)
I/DEBUG   (  266): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   (  266): AM write failure (32 / Broken pipe)
I/DEBUG   (  266): Build fingerprint: 'motorola/falcon_retfr/falcon_umts:4.4.4/KXB21.14-L1.40/37:user/release-keys'
I/DEBUG   (  266): Revision: 'p3c0'
I/DEBUG   (  266): pid: 1316, tid: 1316, name: m.android.phone  >>> com.android.phone <<<
I/DEBUG   (  266): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000000c
I/DEBUG   (  266):     r0 00000000  r1 6128a561  r2 ffffff4c  r3 4011e394
I/DEBUG   (  266):     r4 beeda200  r5 40128334  r6 beeda200  r7 6128a561
I/DEBUG   (  266):     r8 00000002  r9 400b8678  sl 00000000  fp 6128be38
I/DEBUG   (  266):     ip 6128bf7c  sp beed9b20  lr 400f8125  pc 400f6f3c  cpsr 400d0030

Could you confirm that this is supposed to work on KitKat 4.4.4, or should I look for some recent Android OS changes that may affect this software behavior ?
(I've already tried setenforce 0 before launching the hijack tool, but result is identical)

Am I missing something ?

Thank you for your help.

[crmulliner]

I have not tried Android 4.4.4 but I don't see a reason why this should
not work on new Android versions.

the empty log file is strange. did you try the strmon example? the log
file here is /data/local/tmp/strmon.log

Collin

On 09/18/2014 06:47 PM, t0kt0ckus wrote:

First, I'm very interested by this tool's possibilities, and would like to thank you for sharing your work.

I'm testing with a KitKat 4.4.4 device, kernel 3.4.42. Android NDK tools are the latest (r10, toolchains 4.6 and 4.8). GNU Make 3.81 et GCC 4.8.2.

I'm simply following the example included in the README.
Compilation and invocation go smooth:

root@falcon_umts:/data/local/tmp # ./hijack -d -p 1316 -l ./libexample.so      
mprotect: 0x400f0670
dlopen: 0x400a8f31
pc=400f190c lr=40159653 sp=beeda328 fp=beeda4bc
r0=fffffffc r1=beeda348
r2=10 r3=ffffffff
stack: 0xbeeba000-0xbeedb000 leng = 135168
executing injection code at 0xbeeda2d8
calling mprotect
library injection completed!

But, the adbi_example.log file is empty, and remains empty for ever.
Reading logcat, it seems that the target process (in this case com.android.phone, as suggested) is killed as soon as injected code begins execution:

F/libc    ( 1316): Fatal signal 11 (SIGSEGV) at 0x0000000c (code=1), thread 1316 (m.android.phone)
I/DEBUG   (  266): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   (  266): AM write failure (32 / Broken pipe)
I/DEBUG   (  266): Build fingerprint: 'motorola/falcon_retfr/falcon_umts:4.4.4/KXB21.14-L1.40/37:user/release-keys'
I/DEBUG   (  266): Revision: 'p3c0'
I/DEBUG   (  266): pid: 1316, tid: 1316, name: m.android.phone  >>> com.android.phone <<<
I/DEBUG   (  266): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000000c
I/DEBUG   (  266):     r0 00000000  r1 6128a561  r2 ffffff4c  r3 4011e394
I/DEBUG   (  266):     r4 beeda200  r5 40128334  r6 beeda200  r7 6128a561
I/DEBUG   (  266):     r8 00000002  r9 400b8678  sl 00000000  fp 6128be38
I/DEBUG   (  266):     ip 6128bf7c  sp beed9b20  lr 400f8125  pc 400f6f3c  cpsr 400d0030

Could you confirm that this is supposed to work on KitKat 4.4.4, or should I look for some recent Android OS changes that may affect this software behavior ?
(I've already tried setenforce 0 before launching the hijack tool, but result is identical)

Am I missing something ?

Thank you for your help.

---

Reply to this email directly or view it on GitHub:
#4

Collin R. Mulliner [email protected] KeyID 0x5D89EEED
jabber: [email protected] skype: crmcrm
web:www.mulliner.org finger:[email protected]
RAID is no backup! --Frank Meerkoetter

[t0kt0ckus]

I think I've eventually figured this out: it's now required to chmod 666 /data/local/tmp/adbi_example.log before injection.

This is because the injected code runs in the code.android.phone process, with the corresonding UID, which is radio in KitKat 4.4.4, and does not have the appropriate permissions to write to /data/local/tmp/adbi_example.log (which is owned by root with permissions 600). I think that in previous Android OS versions, the code.android.phone application may run as root, thus obviously having the permissions required to open the log file.

As this issue causes a segmentation violation during the libexample.so shared library initialization, I would suggest to update the README to include something like:

adb shell
su
cd /data/local/tmp
>/data/local/tmp/adbi_example.log
# allows any UID (so any target process) to open the log file
chmod 666 /data/local/tmp/adbi_example.log
# GET PID from com.android.phone
./hijack -d -p PID -l /data/local/tmp/libexample.so
cat adbi_example.log

As a side note, recent NDK toolchains use by default -Werror=format-security, which makes epoll.c compilation fail:

jni/../epoll.c: In function 'my_log':
jni/../epoll.c:59:2: error: format not a string literal and no format arguments [-Werror=format-security]
cc1: some warnings being treated as errors
make: *** [obj/local/armeabi/objs/example/__/epoll.o] Error 1 

This is easily solved by adding the following line to the module's Android.mk:

LOCAL_DISABLE_FORMAT_STRING_CHECKS := true

Again, I thank you for sharing your work.

Regards,
Chris

[jduck]

Fixed!

Original issue fixed in cb1f71b
Format string compilation error fixed in 7ed67ab

If this doesn't address your problems, let us know. If it does, please close this bug out =)

Fixing the logging properly is a bit tricky. I think we could open the log file at injection time (using the hijack program)...

Thanks for your bug reports!

[t0kt0ckus]

Thank you for your quick answers.

Commit 7ed67ab solves the compilation error, and is far better than my suggestion, as you fixed it in the code rather than working around with compiler flags.

Commit cb1f71b actually fixes the segmentation violation, as the code now does no more try to log things using an invalid file pointer. And thus prevent the com.android.phone application (or any target process) to crash/respawn, which is a good thing.
Though, this does not solve the adbi/REAME example on any Android OS version where the com.android.phone process does not run with UID root (it's radio on KitKat 4.4.4): there's no more segmentation violation, but the injected code silently fails to log because of unsufficient permissions, which may puzzle some peoples. At least that could have puzzled me, may be even more than before, when I at least could see that the target process was SIGSEGV killed.
[rem: I agree that fixing the log properly requires some more work, but I think you're not here to teach us POSIX system programming, but rather Android dynamic binary injection =]

For this reason, I still think it's worth adding a chmod 666 /data/local/tmp/adbi_example.log command to the adbi/README section How to Run.
Yesterday evening, I've started working with the related ddi project, and noticed that the ddi/README strmon example (that I hadn't found before,) actually sets the log file world writable:
chmod 777 /data/local/tmp/strmon.log

I do not close the issue right now, just to let you think about whether to update the adbi/README or not.

Thank you for your work and support.

Regards,
Chris.

[jduck]

I'll leave this part for the ever busy @crmulliner. I think there's a formatting issue with the README too. Looks like not so good markdown.