Segfaults (in liblog) when hooking

[wenq1]

When hooking malloc using the following code:

#define LOGP(...)   ((void) __android_log_print (ANDROID_LOG_ERROR, "HOOKERJB: ", __VA_ARGS__))
hook (&bhook_malloc, getpid (), "libc.", "malloc", NULL, hbimp_malloc);

typedef void    * (*func_malloc) (size_t size);
void * hbimp_malloc (size_t size)
{
    LOGP ("hbimp_malloc () called");

    static int      counter     = 10;
    func_malloc         imp_malloc  = (void *) bhook_malloc.orig;

    // hook_precall (&bhook_malloc);
    void      * mem  = imp_malloc (size);
    // hook_postcall (&bhook_malloc);
    return mem;
}

Segfaults occurs after multiple callings to hbimp_malloc () - well if one enables hook_precall and hook_postcall, segfaults take place immediately

E/HOOKERJB: ( 2415): hbimp_malloc () called
E/HOOKERJB: ( 2415): hbimp_malloc () called
E/HOOKERJB: ( 2415): hbimp_malloc () called
E/HOOKERJB: ( 2415): hbimp_malloc () called
E/HOOKERJB: ( 2415): hbimp_malloc () called
E/HOOKERJB: ( 2415): hbimp_malloc () called
I/ActivityManager(  592): Process com.xxx.xxx (pid 2415) has died.

Verbose kmsg shows address here:

    <1>[  868.312316] pgd = eac98000
    <1>[  868.312438] [740a1ff8] *pgd=aa94a831, *pte=00000000, *ppte=00000000
    <4>[  868.312683] 
    <4>[  868.312744] Pid: 2477, comm:           Thread-120
    <4>[  868.312835] CPU: 3    Not tainted  (3.4.0-cyanogenmod-gb7efce1-dirty #6)
    <4>[  868.312927] PC is at 0x40067e80
    <4>[  868.312988] LR is at 0x4006c651
    <4>[  868.313079] pc : [<40067e80>]    lr : [<4006c651>]    psr: 80000030
    <4>[  868.313079] sp : 740a2000  ip : 00000008  fp : 741a0b84
    <4>[  868.313262] r10: 00000000  r9 : 00000016  r8 : 740a20b8
    <4>[  868.313323] r7 : 740a20fc  r6 : 761434ea  r5 : 00000016  r4 : 740a270c
    <4>[  868.313446] r3 : 00000200  r2 : 00000016  r1 : 761434ea  r0 : 740a276c
    <4>[  868.313507] Flags: Nzcv  IRQs on  FIQs on  Mode USER_32  ISA Thumb  Segment user

The PC corresponds to libc.so it seems (maybe malloc..), according to the following 

4004b000-40091000 r-xp 00000000 b3:16 38543      /system/lib/libc.so
40091000-40093000 r--p 00045000 b3:16 38543      /system/lib/libc.so
40093000-40095000 rw-p 00047000 b3:16 38543      /system/lib/libc.so

Should adbi be used to hook functions such as malloc?

[jduck]

If I'm not mistaken, you're saying that hooking malloc causes a kernel panic? These issues seem very unrelated. It seems much more likely to be a some bug in the kernel.

[wenq1]

No the kernel does not panic, just a segfault. See line "Mode USER_32", which indicates the fault in user mode.

I just rebuilt a custom kernel with verbose Segfault logging, so as to locate the register status.

I wonder whether you have any luck hijacking system functions such as malloc, etc?

[jduck]

Ah. Sorry I missed that. I didn't expect such output from the kernel on a userspace crash, but your custom mods explain it.

I haven't had any issues hooking malloc here. Perhaps you're having a thumb vs. ARM mode problem? Are you able to get a tombstone or attach a debugger to the process to see definitively what's happening?

[wenq1]

Issue is the process seems to be denying debugger attach, and even if you managed to attach to it, the route it is taken is different from the one when you don't attach (it is calculating the breakpoint hash i'm afraid ...)

Can you share a concrete sample which attaches malloc - which will be so much appreciated?

I have built both ARM and THUMB in a single so, providing both to the hook () function. I'm sure of that as the first time when I only supply THUMB code, hook () seems to complain.

Oh btw.. hijacking sprintf also seem to produce the same issue... (segfauts in libc)...

[jduck]

I've always ran hijack as root, so there's no problem here with debugger attaching. Does that work for you? I don't have a sample I can share at the moment.