x86-64汇编Shellcode开发：系统调用栈指针及寄存器恢复问题

Great question—let’s break this down so you can see exactly what’s happening with your shellcode.

First, let’s clarify the core point about system calls and the stack pointer (rsp):

• The syscall instruction itself does not modify rsp from a user-space perspective. When you trigger a system call, the kernel switches to its own kernel stack to handle the request, but when it returns to user-space, your original rsp is restored exactly as it was before the syscall instruction ran. So if execve fails and returns to your code, your stack pointer is still pointing to the right place for your pop instructions.

The problem you’re hitting comes down to how execve works when it succeeds:

execve replaces the entire address space of the current process with the new program you’re executing. That includes your original stack—all the registers you pushed onto the stack (rdi, rsi, rdx, rcx) get overwritten or discarded entirely when the new program loads its own stack.

In other words:

• If execve runs successfully, your shellcode’s code (including the pop instructions you wrote to restore registers) is no longer in memory. The new program’s code starts executing instead, so those pops never run at all.
• Only if execve fails (e.g., invalid path, permission issues) will it return to your shellcode. In that case, rsp is still where you left it, and you can safely execute your pop rcx; pop rdx; pop rsi; pop rdi sequence to restore the original register values (including your rdi=123 test value).

Quick Recommendation for Your Shellcode #

If your shellcode’s goal is just to execute the new program and exit, you don’t need to worry about restoring registers at all—since the successful execve will replace your code anyway. If you want to handle errors (e.g., retry if execve fails), make sure your error-handling path comes after the syscall and uses the intact stack to restore registers before trying again.

内容的提问来源于stack exchange，提问作者Topper Harley