network radar segfault when closing the app

[gustavo-iniguez-goya]

I've seen this problem on previous versions, but this one is of the latest dev branch (07/10/2015 15:00:00):

10-07 11:13:15.482 86-86/? I/DEBUG﹕ * * * * * * * * * * * * * * * * 10-07 11:13:15.482 86-86/? I/DEBUG﹕ Build fingerprint: 'htc_wwe/htc_bravo/bravo:2.3.3/GRI40/96875.1:user/release-keys' 10-07 11:13:15.482 86-86/? I/DEBUG﹕ Revision: '129' 10-07 11:13:15.482 86-86/? I/DEBUG﹕ pid: 24563, tid: 24575, name: network-radar >>> tools/network-radar/network-radar <<< 10-07 11:13:15.482 86-86/? I/DEBUG﹕ signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 41414145 10-07 11:13:15.492 86-86/? I/DEBUG﹕ r0 40572c0c r1 40158384 r2 7ffb1e34 r3 00000322 10-07 11:13:15.492 86-86/? I/DEBUG﹕ r4 40fa44b0 r5 40572c50 r6 41414141 r7 00007f22 10-07 11:13:15.492 86-86/? I/DEBUG﹕ r8 41414141 r9 0000000c sl 40facbe0 fp 00000050 10-07 11:13:15.492 86-86/? I/DEBUG﹕ ip 4006aed8 sp 40572c38 lr 40066163 pc 40066438 cpsr 20030030

...

10-07 11:13:15.502 86-86/? I/DEBUG﹕ backtrace: 10-07 11:13:15.502 86-86/? I/DEBUG﹕ #00 pc 00005438 /data/data/org.csploit.android/files/tools/network-radar/network-radar 10-07 11:13:15.502 86-86/? I/DEBUG﹕ #01 pc 000054a7 /data/data/org.csploit.android/files/tools/network-radar/network-radar 10-07 11:13:15.502 86-86/? I/DEBUG﹕ #02 pc 000029e3 /data/data/org.csploit.android/files/tools/network-radar/network-radar 10-07 11:13:15.502 86-86/? I/DEBUG﹕ #03 pc 0000d280 /system/lib/libc.so (__thread_entry+72) 10-07 11:13:15.502 86-86/? I/DEBUG﹕ #04 pc 0000d418 /system/lib/libc.so (pthread_create+240)

full output: https://gist.github.com/gainan/d64a6869d362e66a532f

[tux-mind]

doceded stacktrace:

********** Crash dump: **********
Build fingerprint: 'htc_wwe/htc_bravo/bravo:2.3.3/GRI40/96875.1:user/release-keys'
pid: 24563, tid: 24575, name: network-radar  >>> tools/network-radar/network-radar <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 41414145
Stack frame #00  pc 00005438  /data/data/org.csploit.android/files/tools/network-radar/network-radar: Routine process_timeouts at /home/max/Documenti/cSploit/android/cSploit/jni/libcares/ares_process.c:515
Stack frame #01  pc 000054a7  /data/data/org.csploit.android/files/tools/network-radar/network-radar: Routine ares_process at /home/max/Documenti/cSploit/android/cSploit/jni/libcares/ares_process.c:149
Stack frame #02  pc 000029e3  /data/data/org.csploit.android/files/tools/network-radar/network-radar: Routine resolver at /home/max/Documenti/cSploit/android/cSploit/jni/network-radar/resolver.c:114
Stack frame #03  pc 0000d280  /system/lib/libc.so (__thread_entry+72)
Stack frame #04  pc 0000d418  /system/lib/libc.so (pthread_create+240)

[tux-mind]

registers:

• r6 => &query
• r8 => &list_node

SIGSEGV when dereferencing query to get timeout.

NOTE: tv_sec field of struct tv is the first field, 0 offset

fault instruction is query->timeout.tv_sec :

ldr     r3, [r6, #4]

in this case, register r6 aka &query contains the value 0x41414141 aka AAAA. reversing the assembly code r8 aka &list_node contains [sl, #4], in this case: 0x40fb0e40

the problem it's that someone wrote AAAA at address [r8, #8], which is 0x40fb0e48. sadly int the memory dump this location of memory is missing. it will be extremely useful to have a full memory dump, but I don't known if android took it.

some possible causes that comes into my mind is:

• NetBIOS packets contains something like KAAAAA
• IPv6 DNS responses contains AAAA as record type

this leads us to 2 possible scenarios:

• network-radar has an overflow and wrote a NetBIOS packet into ares private stuff.
• another part of the ares_library is modifying the list_node at the same time.

just now I saw that r6 and r8 contains continuous values from old r8. inferred memory dump is:

40fb0e44: 41414141 41414141 XXXXXX XXXXXX

looking at the nbns.c sources the NetBIOS requests has 30 bytes of "A".

this exclude the second scenario.

working on ...

EDIT:

the nbstat request is written directly to the socket, it's not possible for network-radar to write it somewhere else. this refine our search to received NetBIOS packets.

.data section ( which contains our NetBIOS packet ) is at logical address 0xa000, while r8 points to 0x40fb0e44 that fall into the heap according to the logcat 40fa4000-40fb3000 rw- [heap].