GDB attaching to a process where executable is deleted - linux

I have running process but it's executable file has got deleted.
If I try to attach gdb I got following error
/home/vivek/binary/releases/20120328101511/bin/app.exe (deleted): No such file or directory.
How can I attach gdb to this process ?
Sample Test case:
Source code:
#include<stdio.h>
#include<stdlib.h>
int main(){
for (;;){
printf("Sleeping");
sleep(1);
}
}
compile it
gcc main.cc -o a.out
gcc main.cc -o b.out
Run
./a.out
Now from different terminal delete a.out.
And fire gdb attach pgrep a.out file b.out
It doesn't work.
GDB shows following error:
/tmp/temp/a.out (deleted): No such file or directory.
A program is being debugged already. Kill it? (y or n) n
Program not killed.


Try using /proc/<pid>/exe as the executable. It appears as a symbolic link these days, however, in the past it was possible to extract the deleted executable from it.
See Detecting deleted executables.
We can use following command to attach gdb
gdb <path-to-binary> <pid>


You can't. GDB needs the symbol data that's in the executable and is not being loaded by the OS when running the program.

Related

Why argv[0] is ./a.out not a.out

I wrote simple program that prints out argv[0] and compiled by using gcc in terminal. Then i executed a.out file by writing ./a.out
I expected the outcome to be a.out but it was “./a.out”. Isnt argv[0] is a program name? Or program name includes the path??
Thanks a lot

The first argument (argv[0]) will include the path. You can see this by moving to another directory and executing your simple program from that location. You will need to do your own parsing to get just the program name.

Executables under Linux use special paths like /usr/bin/ to search for executables.
As security measure the current directory (.) is not sought through for executing.
But if you explicitly write ./my_own_batch_file.sh then that is executed.
Thus if you are in some directory with thousands of files, you still can type ls (Windows dir) without surprises.

GDB's "No symbol table is loaded" when trying to "strace"

I'm trying to strace a thread (or a process, for that matter) on the system through gdb, using strace -p <pid>.
I get the following message:
No symbol table is loaded. Use the "file" command.
Make static tracepoint pending on future shared library load? (y or [n])
I've seen solutions offering to use file <file-name>, but in my case, when I have no file to run, what do I have to do?
Thanks.

The strace you are looking for is a command-line tool, not a GDB command. Exit GDB to run it.

List command is not loading source code of assembly program in gdb

I am using gdb [7.11.1] kali linux 32-bit
when I use list command to lload the source of my assembly program in gdb it displays the following error message:
'No symbol table is loaded. Use the "file" command'
I have tried the command as:
list
list line_number
In both the cases the error is same.
Please help me
Thanks! in advance

I use list command to lload the source of my assembly
List command does nothing of the sort. Rather, it lists sources that GDB has already loaded.
as -o progname.o progname.s
In your case, GDB does not load any sources because you compiled your program without any debug info. You likely want:
as -g -o progname.o progname.s
From man as:
-g
--gen-debug
Generate debugging information for each assembler source line
using whichever debug format is preferred by the target. This
currently means either STABS, ECOFF or DWARF2.

I was incurring same problem while I was trying to debug my c code for buffer overflow stuffs.
That error rises because of clean compiling without generating any debug info.
For c program, rather than normal compiling as gcc program.c try to run gcc -g -fno-stack-protector -z exec stack -o buffer program.c.
-g tells GCC to add extra information for GDB
-fno-stack-protector flag to turn off stack protection mechanism
-z execstack, it makes stack executable
This command will create a buffer binary file of your c program and hence it will fulfil all the criteria for running the list command in gdb.
Start the gdb with gdb ./buffer then type list command. It will work!!

Debugging an ELF file

I've got this EFL file which I need to debug/step-through. It's a reverse engineering competition. All I need to do is to find out the value of a register at a particular point in time and in a particular place. I used Hopper Disassembler to find out the address of interest.
Here's the problem. I don't know how to debug an ELF file. It's my first time debugging in a Linux environment. Learning how to execute the ELF file itself took me a while. I execute by using
ld-linux.so.2 ./[EFLFILE] [arguments]
Is there a way I can atleast attach a debugger onto the proess? I can't even find it with the ps command. Also, I've heard that it's possible to have remote debugger; to have a debugger running on a windows machine and have the binary to be examined running on a linux.
Could anyone help me achieve just any of this?

Usually an ELF file can be executed as follows:
$ /path/to/elffile [arguments]
To debug it using GDB you can do:
$ gdb /path/to/elffile
Or passing arguments:
$ gdb --args /path/to/elffile arguments...
In your case:
$ gdb --args ./[EFLFILE] [arguments]
Then type run or simly r and press < Enter >.
Type help to get help on the gdb commands.
Note: if your program needs some external libs, before running it, you should define LD_LIBRARY_PATH pointing on the folder containing those libs (export LD_LIBRARY_PATH=/the/path/to/libs)

How to run binary file in Linux

I have a file called commanKT and want to run it in a Linux terminal. Can someone help by giving the command to run this file? I tried ./commonRT but I'm getting the error:
"bash: ./commonrt: cannot execute binary file"
[blackberry#BuildMc MainApp]$ ls -al commonKT
-rwxrwxr-x. 1 sijith sijith 10314053 Feb 27 16:49 commonKT

To execute a binary, use: ./binary_name.
If you get an error:
bash: ./binary_name: cannot execute binary file
it'll be because it was compiled using a tool chain that was for a different target to that which you're attempting to run the binary on.
For example, if you compile 'binary_name.c' with arm-none-linux-gnueabi-gcc and try run the generated binary on an x86 machine, you will get the aforementioned error.

To execute a binary or .run file in Linux from the shell, use the dot forward slash friend
./binary_file_name
and if it fails say because of permissions, you could try this before executing it
chmod +x binary_file_name
# then execute it
./binary_file_name
Hope it helps

The volume it's on is mounted noexec.

:-) If not typo, why are you using ./commonRT instead of ./commonKT ??

It is possible that you compiled your binary with incompatible architecture settings on your build host vs. your execution host.
Can you please have a look at the enabled target settings via
g++ {all-your-build-flags-here} -Q -v --help=target
on your build host? In particular, the COLLECT_GCC_OPTIONS variable may give you valuable debug info. Then have a look at the CPU capabilities on your execution host via
cat /proc/cpuinfo | grep -m1 flags
Look out for mismatches such as -msse4.2 [enabled] on your build host but a missing sse4_2 flag in the CPU capabilities.
If that doesn't help, please provide the output of ldd commonKT on both build and execution host.

This is an answer to #craq :
I just compiled the file from C source and set it to be executable with chmod. There were no warning or error messages from gcc.
I'm a bit surprised that you had to 'set it to executable' -- my gcc always sets the executable flag itself. This suggests to me that gcc didn't expect this to be the final executable file, or that it didn't expect it to be executable on this system.
Now I've tried to just create the object file, like so:
$ gcc -c -o hello hello.c
$ chmod +x hello
(hello.c is a typical "Hello World" program.) But my error message is a bit different:
$ ./hello
bash: ./hello: cannot execute binary file: Exec format error`
On the other hand, this way, the output of the file command is identical to yours:
$ file hello
hello: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
Whereas if I compile correctly, its output is much longer.
$ gcc -o hello hello.c
$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=131bb123a67dd3089d23d5aaaa65a79c4c6a0ef7, not stripped
What I am saying is: I suspect it has something to do with the way you compile and link your code. Maybe you can shed some light on how you do that?

The only way that works for me (extracted from here):
chmod a+x name_of_file.bin
Then run it by writing
./name_of_file.bin
If you get a permission error you might have to launch your application with root privileges:
sudo ./name_of_file.bin

Or, the file is of a filetype and/or architecture that you just cannot run with your hardware and/or there is also no fallback binfmt_misc entry to handle the particular format in some other way. Use file(1) to determine.

your compilation option -c makes your compiling just compilation and assembly, but no link.

If it is not a typo, as pointed out earlier, it could be wrong compiler options like compiling 64 bit under 32 bit. It must not be a toolchain.

full path for binary file. For example: /home/vitaliy2034/binary_file_name. Or
use directive "./+binary_file_name".
'./' in unix system it return full path to directory, in which you open terminal(shell).
I hope it helps.
Sorry, for my english language)

1st login with su
su <user-name>
enter password
Password: xxxxxx
Then executer command/file, it should run.

Resources