[solved] ptrace syscall fails, but call ptrace works

Index > Linux > [solved] ptrace syscall fails, but call ptrace works

Author

Thread

musl

Joined: 14 Jun 2025
Posts: 2

musl 14 Jun 2025, 21:35

Code:

mov rax, SYS_PTRACE
mov rdi, PTRACE_PEEKDATA
mov rsi, pid
mov rdx, rbx
mov r10, 0
syscall

mov rdi, PTRACE_PEEKDATA
mov rsi, pid
mov rdx, rbx
mov rcx, 0
call ptrace

The syscall fails and returns -14 (EFAULT) but the call ptrace version works completely fine.
I've been trying to figure this out for a while but I can't find the issue, I would be glad if someone could help with this.

Oh also in both cases I use syscalls for WAIT4, PTRACE_ATTACH, PTRACE_DETACH and even PTRACE_POKEDATA its just PTRACE_PEEKDATA that fails with the syscall.

14 Jun 2025, 21:35

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20689
Location: In your JS exploiting you and your system

revolution 14 Jun 2025, 23:47

https://manpages.debian.org/unstable/manpages-dev/ptrace.2.en.html#C_library/kernel_differences wrote:

C library/kernel differences

At the system call level, the PTRACE_PEEKTEXT, PTRACE_PEEKDATA, and PTRACE_PEEKUSER operations have a different API: they store the result at the address specified by the data parameter, and the return value is the error flag. The glibc wrapper function provides the API given in DESCRIPTION above, with the result being returned via the function return value.[

14 Jun 2025, 23:47

musl

Joined: 14 Jun 2025
Posts: 2

musl 15 Jun 2025, 08:53

revolution wrote:

https://manpages.debian.org/unstable/manpages-dev/ptrace.2.en.html#C_library/kernel_differences wrote:
C library/kernel differences

At the system call level, the PTRACE_PEEKTEXT, PTRACE_PEEKDATA, and PTRACE_PEEKUSER operations have a different API: they store the result at the address specified by the data parameter, and the return value is the error flag. The glibc wrapper function provides the API given in DESCRIPTION above, with the result being returned via the function return value.[

oh, thanks it worked

15 Jun 2025, 08:53

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20689
Location: In your JS exploiting you and your system

revolution 15 Jun 2025, 11:11

All of the syscall documentation is like that. It is all oriented towards the c-library interface, and occasionally contains notes to mention things that the c-library does to alter the values returned by the kernel.

The most common difference, that is never mentioned, is the return value from the c-library is either 0 or -1, and the error code can be read in the errno variable. But the kernel syscall returns the error code directly as a negative number between -4095 and -1, and doesn't have any errno variable to read.

15 Jun 2025, 11:11

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum