Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic analysis: "Tracing system call error: ESRCH: No such process" #43

Open
godzie44 opened this issue Sep 19, 2024 · 17 comments · Fixed by #48
Open

Dynamic analysis: "Tracing system call error: ESRCH: No such process" #43

godzie44 opened this issue Sep 19, 2024 · 17 comments · Fixed by #48
Labels
bug Something isn't working effort: difficult This will take some time help wanted Extra attention is needed

Comments

@godzie44
Copy link
Contributor

Describe the bug

For some of binaries, after press enter at "Dynamic" tab, i see a "ESRCH: No such process" error.

To reproduce

cargo new hello
cd hello
cargo build
binsider ./target/debug/hello

Screenshots / Logs

image

Software information

  • Operating system: Ubuntu 24.04.1 LTS
  • Rust version: rustc 1.81.0 (eeb90cda1 2024-09-04)
  • Project version: binsider 0.1.0
@godzie44 godzie44 added the bug Something isn't working label Sep 19, 2024
@orhun
Copy link
Owner

orhun commented Sep 20, 2024

Yeah, not sure why it happens yet. Also reported here: JakWai01/lurk#48

Maybe try without leading slash 👀

@godzie44
Copy link
Contributor Author

Unfortunately it dont help for me

@orhun
Copy link
Owner

orhun commented Sep 22, 2024

This will be fixed in #48 :)

@orhun orhun closed this as completed in #48 Sep 24, 2024
@algomaster99
Copy link

algomaster99 commented Sep 25, 2024

@godzie44 ! did it fix for you? I have the same issue with a simple hello world program in C. I simply ran cargo run install --force after pulling the latest changes. Then I ran binsider hello.elf and it did not work. I also tried absolute paths, but I get the same error. I am assuming the changes are incorporated in the binary.

@orhun orhun reopened this Sep 25, 2024
@orhun
Copy link
Owner

orhun commented Sep 25, 2024

I was too confident about the fix 😅 The issue seems to be still there and I'm even more puzzled by it now. It apparently works for some files and not for others. Can you share the file you are trying this with?

@orhun
Copy link
Owner

orhun commented Sep 25, 2024

Btw it fails for this function:

pub fn ptrace_init_options(pid: Pid) -> nix::Result<()> {
    ptrace::setoptions(
        pid,
        Options::PTRACE_O_TRACESYSGOOD | Options::PTRACE_O_TRACEEXIT | Options::PTRACE_O_TRACEEXEC,
    )
}

I guess either the pid is not available at that time or something wrong with the permissions / file type. Still investigating...

@algomaster99
Copy link

algomaster99 commented Sep 25, 2024

@orhun I am on phone right now, but this was the source code.

#include <stdio.h>
int main() {
   // printf() displays the string inside quotation
   printf("Hello, World!");
   return 0;
}

I then compiled it with gcc -o hello.elf hello.c. My computer details - Ubuntu 22.04 amd64.
Finally, binsider hello.elf.

Thank you for looking into it!

@godzie44
Copy link
Contributor Author

Looks like this dont fix for me too :(

@orhun orhun removed their assignment Sep 27, 2024
@orhun orhun added help wanted Extra attention is needed effort: difficult This will take some time labels Sep 27, 2024
@orhun
Copy link
Owner

orhun commented Sep 27, 2024

I'm quite puzzled by this, @JakWai01 any ideas? 👀

@JakWai01
Copy link

@orhun I just tried to replicate in in lurk. On this side, it seems to work:

$ lurk ./hello.elf
[7414] execve("", "", "") = 0
[7414] brk(0x0) = 0x555555559000
[7414] arch_prctl(12289, 0x7FFFFFFFDDB0) = -22
[7414] mmap(0x0, 8192, 3, 34, 4294967295, 0) = 0x7FFFF7FBB000
[7414] access("/etc/ld.so.preload", 4) = -2
[7414] openat(4294967196, "/etc/ld.so.cache", 524288) = 3
[7414] newfstatat(3, "", 0x7FFFFFFFCF00, 4096) = 0
[7414] mmap(0x0, 100467, 1, 2, 3, 0) = 0x7FFFF7FA2000
[7414] close(3) = 0
[7414] openat(4294967196, "/lib/x86_64-linux-gnu/libc.so.6", 524288) = 3
[7414] read(3, "ELF\u0002\u0001\u0001\u0003", 832) = 832
[7414] pread64(3, "\u0006", 784, 64) = 784
[7414] pread64(3, "\u0004", 48, 848) = 48
[7414] pread64(3, "\u0004", 68, 896) = 68
[7414] newfstatat(3, "", 0x7FFFFFFFCFD0, 4096) = 0
[7414] pread64(3, "\u0006", 784, 64) = 784
[7414] mmap(0x0, 2264656, 1, 2050, 3, 0) = 0x7FFFF7D79000
[7414] mprotect(0x7FFFF7DA1000, 2023424, 0) = 0
[7414] mmap(0x7FFFF7DA1000, 1658880, 5, 2066, 3, 163840) = 0x7FFFF7DA1000
[7414] mmap(0x7FFFF7F36000, 360448, 1, 2066, 3, 1822720) = 0x7FFFF7F36000
[7414] mmap(0x7FFFF7F8F000, 24576, 3, 2066, 3, 2183168) = 0x7FFFF7F8F000
[7414] mmap(0x7FFFF7F95000, 52816, 3, 50, 4294967295, 0) = 0x7FFFF7F95000
[7414] close(3) = 0
[7414] mmap(0x0, 12288, 3, 34, 4294967295, 0) = 0x7FFFF7D76000
[7414] arch_prctl(4098, 0x7FFFF7D76740) = 0
[7414] set_tid_address(0x7FFFF7D76A10) = 7414
[7414] set_robust_list(0x7FFFF7D76A20, 24) = 0
[7414] rseq() = 0
[7414] mprotect(0x7FFFF7F8F000, 16384, 1) = 0
[7414] mprotect(0x555555557000, 4096, 1) = 0
[7414] mprotect(0x7FFFF7FFB000, 8192, 1) = 0
[7414] prlimit64(0, 3, 0x0, 0x7FFFFFFFDB10) = 0
[7414] munmap(0x7FFFF7FA2000, 100467) = 0
[7414] newfstatat(1, "", 0x7FFFFFFFD6C0, 4096) = 0
[7414] ioctl(1, 21505, 0x7FFFFFFFD620) = -25
[7414] getrandom(";EÐ\u0007", 8, 1) = 8
[7414] brk(0x0) = 0x555555559000
[7414] brk(0x55555557A000) = 0x55555557A000
[7414] write(1, "Hello, World!", 13) = 13
[7414] exit_group(0) = ?

@orhun
Copy link
Owner

orhun commented Sep 29, 2024

Yeah, it works fine in lurk for me as well. I guess I'm doing something wrong in tracer.rs, can you take a look at that file as well?

Most notably, I'm spawning a new thread for executing the binary and I wait for the execution to complete via waitpid. When I remove the thread, the whole thing just gets stuck in wait() call in lurk. Otherwise I fail to get the pid of the child process I guess.

@orhun
Copy link
Owner

orhun commented Sep 30, 2024

I realized something weird, it works when I move the local binary to /bin or update the file owner/group to root via chown root:root test.elf 🤔

@orhun
Copy link
Owner

orhun commented Sep 30, 2024

I think fork(2) is failing to create the child process in a multithreaded context...
https://man7.org/linux/man-pages/man7/signal-safety.7.html

@orhun
Copy link
Owner

orhun commented Sep 30, 2024

@JakWai01 to replicate this, you can try moving the binary outside of $PWD and running that way:

$ lurk /home/orhun/gh/binsider/test.elf
Error: ESRCH: No such process

@SwiftSecur
Copy link

SwiftSecur commented Oct 2, 2024

So - when I got this I ran it with a few small test binaries written in C....seems to happen when using small bins that exit quickly for me? might be barking up the wrong tree, but I can get it working when I use something a bit more substantial...

EDIT - actually seems to be a bit hit and miss even with larger files...weird.

@dmgolembiowski
Copy link

dmgolembiowski commented Nov 16, 2024

So - when I got this I ran it with a few small test binaries written in C....seems to happen when using small bins that exit quickly for me? might be barking up the wrong tree, but I can get it working when I use something a bit more substantial...

EDIT - actually seems to be a bit hit and miss even with larger files...weird.

I think I have reproducible recreation steps because this also occurs when running a tiny 32-bit program on my 64-bit machine that guarantees a segfault after printing "Hello world!".

The assembly:

section .text
global _start
_start:
    mov edx, len
    mov ecx, msg
    mov ebx, 1
    mov eax, 4
    int 0x80

section .data
    msg db "Hello world!"
    len equ $ -msg

Then prepared with:

nasm -f elf32 -o hello.o hello.asm && ld -m elf_i386 -o hello hello.o

Invoking ./hello yields:

./hello
Hello world![1]    550486 segmentation fault (core dumped)  ./hello

and then binsider hello gives Tracing system call error: ESRCH: No such process when I run it under the dynamic table.

@orhun
Copy link
Owner

orhun commented Nov 18, 2024

Thanks for looking into it. I'm not sure how that reproduce steps help here though. At this point it is failing for any local executable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working effort: difficult This will take some time help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants