Comments on: Decoding a ’service’ call in Android http://www.macrobug.com/blog/2007/12/15/decoding-a-service-call-in-android/ Macrobug Blog Tue, 20 Jul 2010 21:22:49 -0400 http://wordpress.org/?v=2.8.4 hourly 1 By: birjodh tiwana http://www.macrobug.com/blog/2007/12/15/decoding-a-service-call-in-android/comment-page-1/#comment-80802 birjodh tiwana Mon, 08 Jun 2009 08:41:48 +0000 http://www.macrobug.com/blog/2007/12/15/decoding-a-service-call-in-android/#comment-80802 Hey Dude, Instead of using strace use printk in /drivers/android/binder.c . Now you can access /dev/binder. Then just run a simple app which performs ipc and use dmesg to see kernel logs. There you go ! You can see the data written by brREPLY. Your post helped me a hell lot ! thanks Hey Dude,

Instead of using strace use printk in /drivers/android/binder.c . Now you can access /dev/binder. Then just run a simple app which performs ipc and use dmesg to see kernel logs. There you go ! You can see the data written by brREPLY.

Your post helped me a hell lot !
thanks

]]> By: embedded http://www.macrobug.com/blog/2007/12/15/decoding-a-service-call-in-android/comment-page-1/#comment-19768 embedded Sun, 16 Dec 2007 13:55:22 +0000 http://www.macrobug.com/blog/2007/12/15/decoding-a-service-call-in-android/#comment-19768 Thank you, Adrian. Your other entries are interesting, too. Thank you, Adrian.
Your other entries are interesting, too.

]]> By: Adrian Taylor http://www.macrobug.com/blog/2007/12/15/decoding-a-service-call-in-android/comment-page-1/#comment-19763 Adrian Taylor Sun, 16 Dec 2007 10:10:19 +0000 http://www.macrobug.com/blog/2007/12/15/decoding-a-service-call-in-android/#comment-19763 OK, I've looked into them in arch/arm/kernel/calls.S in the Android source code. 281 is 'socket'. 283 is 'connect'. 297 is 'recvmsg'. Odd that they're not understood by strace for ARM. Looks like that can be fixed by altering the relevant syscallent.h in the strace source code, though. OK, I’ve looked into them in arch/arm/kernel/calls.S in the Android source code.

281 is ’socket’.
283 is ‘connect’.
297 is ‘recvmsg’.

Odd that they’re not understood by strace for ARM. Looks like that can be fixed by altering the relevant syscallent.h in the strace source code, though.

]]> By: Adrian Taylor http://www.macrobug.com/blog/2007/12/15/decoding-a-service-call-in-android/comment-page-1/#comment-19761 Adrian Taylor Sun, 16 Dec 2007 09:14:33 +0000 http://www.macrobug.com/blog/2007/12/15/decoding-a-service-call-in-android/#comment-19761 Hi, <a href="http://www.macrobug.com/blog/2007/12/10/syscall_983045/" rel="nofollow">syscall983045</a> seems to be setting the thread local storage... but if that's the case I don't know why it would have so many arguments. The SYS_281 etc. I don't know! But <a href="http://www.busybox.net/lists/uclibc-cvs/2007-April/011346.html" rel="nofollow">this</a> suggests they might be socket-related. Then again, I don't know if these numbers will differ between ucLinux and the Android kernel. Hi, syscall983045 seems to be setting the thread local storage… but if that’s the case I don’t know why it would have so many arguments.

The SYS_281 etc. I don’t know! But this suggests they might be socket-related. Then again, I don’t know if these numbers will differ between ucLinux and the Android kernel.

]]> By: embedded http://www.macrobug.com/blog/2007/12/15/decoding-a-service-call-in-android/comment-page-1/#comment-19752 embedded Sun, 16 Dec 2007 02:35:11 +0000 http://www.macrobug.com/blog/2007/12/15/decoding-a-service-call-in-android/#comment-19752 Do you have any idea about undefined syscalls which are the last several lines on "1. General process startup" ? # syscall_983045(0xbeef9d3c, 0, 0×20, 0, 0xbeeda000, 0xbeef9df0, 0xbeef9e30, 0xf0005, 0xbeef9e30, 0, 0×8858, 0×8854, 0, 0xbeef9d30, 0xafe20a53, 0xafe0949c, 0×60000010, 0xbeef9d3c, 0, 0, 0, 0xc8c8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0 # SYS_281(0×1, 0×1, 0, 0xafe40d20, 0xafe371bc) = 3 # SYS_283(0×3, 0xbeef9c9a, 0×13, 0, 0×3) = 0 # SYS_297(0×3, 0xbeef9cd4, 0, 0×1, 0xbeef9cd4) = 4 # mmap2(NULL, 32768, PROT_READ, MAP_SHARED, 4, 0) = 0×40000000 # close(4) = 0 # close(3) = 0 3 and 4 seem to be file descriptor created by undefined syscalls. It mmap'ed with PROT_READ and MAP_SHARED. Is this some kind of receive buffer from open binder driver?? Do you have any idea about undefined syscalls which are the last several lines
on “1. General process startup” ?

# syscall_983045(0xbeef9d3c, 0, 0×20, 0, 0xbeeda000, 0xbeef9df0, 0xbeef9e30, 0xf0005, 0xbeef9e30, 0, 0×8858, 0×8854, 0, 0xbeef9d30, 0xafe20a53, 0xafe0949c, 0×60000010, 0xbeef9d3c, 0, 0, 0, 0xc8c8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0
# SYS_281(0×1, 0×1, 0, 0xafe40d20, 0xafe371bc) = 3
# SYS_283(0×3, 0xbeef9c9a, 0×13, 0, 0×3) = 0
# SYS_297(0×3, 0xbeef9cd4, 0, 0×1, 0xbeef9cd4) = 4
# mmap2(NULL, 32768, PROT_READ, MAP_SHARED, 4, 0) = 0×40000000
# close(4) = 0
# close(3) = 0

3 and 4 seem to be file descriptor created by undefined syscalls.
It mmap’ed with PROT_READ and MAP_SHARED. Is this some kind of
receive buffer from open binder driver??

]]>