perhaps i can describe the conceptual understanding first....

OS always not to let userspace stuff go into kernel without
check.....so anything u passed into the stack/registers.....after u
called the syscall (usually via sysenter or int 0x80 in assembly) the
parameters can entire reprocessed....it is not NOT the usual ESP or
registers values....instead....kernel have its own stack space....and
so is userspace.....

so for eg,  read() in userpace.....upon the "sysenter" will somehow
end up executing sys_read() in the kernel.......problem....HOW?

for details:

http://manugarg.appspot.com/systemcallinlinux2_6.html

and this link gave explanation for windows:

http://www.codeguru.com/cpp/w-p/system/devicedriverdevelopment/article.php/c8223/

so u can see that the whole thing is quite OS independent....

and u ask for parameters:

looking up arch/x86/kernel/entry_64.S:

/*
 * System call entry. Upto 6 arguments in registers are supported.
 *
 * SYSCALL does not save anything on the stack and does not change the
 * stack pointer.
 */

/*
 * Register setup:
 * rax  system call number
 * rdi  arg0
 * rcx  return address for syscall/sysret, C arg3
 * rsi  arg1
 * rdx  arg2
 * r10  arg3    (--> moved to rcx for C)
 * r8   arg4
 * r9   arg5
 * r11  eflags for syscall/sysret, temporary for C
 * r12-r15,rbp,rbx saved by C code, not touched.
 *
 * Interrupts are off on entry.
 * Only called from user space.
 *
 * XXX  if we had a free scratch register we could save the RSP into
the stack frame
 *      and report it properly in ps. Unfortunately we haven't.
 *
 * When user can change the frames always force IRET. That is because
 * it deals with uncanonical addresses better. SYSRET has trouble
 * with them due to bugs in both AMD and Intel CPUs.
 */

ENTRY(system_call)
       CFI_STARTPROC   simple
       CFI_SIGNAL_FRAME
       CFI_DEF_CFA     rsp,KERNEL_STACK_OFFSET
       CFI_REGISTER    rip,rcx
       /*CFI_REGISTER  rflags,r11*/
       SWAPGS_UNSAFE_STACK
       /*
        * A hypervisor implementation might want to use a label
        * after the swapgs, so that it can do the swapgs
        * for the guest and jump here on syscall.
        */


and if u don't understand the above, just do a "gdb vmlinux /proc/
kcore"
and then "x /20i system_call" to see the disassembly in intel
instruction.

(gdb) x /20i system_call
0xffffffff81014820 <system_call>:       swapgs
0xffffffff81014823 <system_call+3>:     nopw   %cs:0x0(%rax,%rax,1)
0xffffffff81014830 <system_call+16>:    mov    %rsp,%gs:0xc6c8
0xffffffff81014839 <system_call+25>:    mov    %gs:0xcbc8,%rsp
0xffffffff81014842 <system_call+34>:    sti
0xffffffff81014843 <system_call+35>:    nopl   0x0(%rax)
0xffffffff8101484a <system_call+42>:    sub    $0x50,%rsp
0xffffffff8101484e <system_call+46>:    mov    %rdi,0x40(%rsp)
0xffffffff81014853 <system_call+51>:    mov    %rsi,0x38(%rsp)
0xffffffff81014858 <system_call+56>:    mov    %rdx,0x30(%rsp)
0xffffffff8101485d <system_call+61>:    mov    %rax,0x20(%rsp)
0xffffffff81014862 <system_call+66>:    mov    %r8,0x18(%rsp)
0xffffffff81014867 <system_call+71>:    mov    %r9,0x10(%rsp)
0xffffffff8101486c <system_call+76>:    mov    %r10,0x8(%rsp)
0xffffffff81014871 <system_call+81>:    mov    %r11,(%rsp)
0xffffffff81014875 <system_call+85>:    mov    %rax,0x48(%rsp)
0xffffffff8101487a <system_call+90>:    mov    %rcx,0x50(%rsp)
0xffffffff8101487f <system_call+95>:    mov    %gs:0xcbc8,%rcx
0xffffffff81014888 <system_call+104>:   sub    $0x1fd8,%rcx
0xffffffff8101488f <system_call+111>:   testl  $0x100001d1,0x10(%rcx)

notice the "SWAPGS_UNSAFE_STACK" as the first instruction mapped to
disassembly above.

this is the key instruction in your understanding of passing
parameters between userspace and kernelspace.   u can look up here for
detailed explanation:

http://security.freebsd.org/advisories/FreeBSD-SA-08:07.amd64.asc

anyway if u need further.....just email.

On Dec 27 2009, 10:32 pm, perumal316 <[email protected]> wrote:
> Hi,
>
> I have read on inline hooking as specified, but am confused by it's
> purpose. What i understood from inline hooking is that it replaces
> functions within the respective systemcall definitions.
>
> I am trying to capture/intercept the parameters passed by applications
> in user-space. For this purpose I have hooked into systemcall table
> but not sure how to proceed as I am not sure how to use the system
> calls to capture the data.
>
> The purpose is just to show to users the parameters. Any idea how to
> proceed?
>
> Thanks in Advance,
> Perumal
>
> On Dec 23, 12:37 pm, Peter Teoh <[email protected]> wrote:
>
> > many examples in the web....keyword to search is "inline
> > hooking"....so for eg:
>
> >http://www.google.com/search?hl=en&num=100&q=inline+hooking+linux+ker...
>
> > and among the first few links:
>
> >http://www.hackbase.com/tech/2009-05-06/52605.html
>
> > or here (same article):
>
> >http://www.router.net.cn/Article/21289.html
>
> > (orhttp://www.neeao.com/pstzine/0x03/pdf/PSTZine_0x03_0x03.pdf)....commu...
> > is chinese...but C is universal language :-).
>
> > On Dec 22, 5:08 pm, perumal316 <[email protected]> wrote:
>
> > > Hi,
>
> > > I have hooked into the system call table in Linux v2.6 and replaced
> > > system calls with my own functions. What I am trying now is to capture
> > > the arguments/data/parameters passed by applications when they invoke
> > > the system calls. Any idea how do I capture these parameters?
>
> > > Thanks in Advance,
> > > Perumal
>
>

Reply via email to