I'm writing a client/server program in C.
My client has a thread reading input from stdin, it's just a while(1) loop to read input from stdin. Whenever it reads a line, it deliver it to another thread that handles message parsing and framing.
As I enter gdb, the command line is occupied by gdb prompt and I can no longer input lines into stdin.
Is there a way to do it? (I don't want to redirect stdin to an input file because I've tried this method and it didn't work)
Run your program in one terminal and attach to it from gdb in another terminal.
To attach to a running program, find the process ID (PID) of the program you want to attach to, then execute gdb <executable> <PID>.
As an addition to Jonathan Reinhart's answer, here is a oneliner to attach to a running program by name:
gdb -p $(pgrep <executable-name>)
As a clarification you don't need the executable name if you do know the process id of the program. This will allow you to attach a program directly.
gdb -p PID
Related
I am trying to make a program that can process sentences in C in the POSIX environment. Assume that my program's name is "test". If the user entered just "./test", then my program will ask the user to enter some sentences. This one so far is easy.
However, if the user entered "./test < file.txt", the program should get the characters from that txt file. I do not know how I can get the characters of the file in C. I tried something like file = open(argv[2]);, but it did not work.
I will really appreciate it if you give me the answer to this question.
TL;DR: If you start your program like
./test
and you have to type in the input, then exactly the same program will read from file.txt if you start it as
./test < file.txt
Longer explanation starts here. (The following explanation is not 100% precise, but shall help to get an understanding what is going on in principle.)
In a C program you can open files with fopen. As a return value, fopen gives you a FILE pointer. However, when you start a program under Unix, three FILE pointers are already available. These default FILE pointers are stored in variables named stdin, stdout and stderr.
Of these, stdin can be used to read from, stdout and stderr can be written to. And, stdin is used as default in several C library calls, like, gets or scanf. Similarly, stdout is used by default for calls like printf.
Now, although they are called FILE pointers, they can in fact represent other things than just files. stdin could be a file, but it can also be a console where you can type in stuff.
This latter scenario is what you observe when you start your test program from the shell with the command
./test
In this case, the test process will be started with stdin just using the console from the shell from which you started the test program. Therefore, if in your test program you call, say, gets(), then your program will implicitly read from stdin, which represents the console input that was inherited from the shell. Consequently, in this case the user has to provide input by typing it in.
Now let's look at what happens if you start your process from the shell in the following way:
./test < file.txt
Here, the shell does a bit of extra work before it actually creates your test process. This is because the < file.txt part of your command line is interpreted by the shell - this is not passed as arguments to your program. Instead, what the shell does is, to open the file.txt and, when the test process is started, hand the opened file.txt over to the process such that in your test process stdin is connected to file.txt.
Then, the call to gets() in your program will again read from stdin, but this time stdin is not the console. This time stdin really corresponds to a file, that is, file.txt.
I'm trying to perform a privilege escalation attack using a binary which performs the call:
system("/bin/sh");
Is there a way to pass commands as "arguments" or such with the opened shell?
(I don't see it opening, I guess it runs and dies as soon as it has nothing to do which is immediately).
Edit: I Cannot edit the code. It's compiled already.
If you execute
system("/bin/bash");
the shell enters into interactive mode. It reads commands from standard input and writes answers to standard output. The standard input and output is inherited from the calling (your) program. Your program will wait until the shell finishes (i.e. until you enter the command exit or you type ^D at the beginning of line). The shell will run with the same privileges as the calling program.
If you control stdin
What you'll need to do is connect stdin to something that will, when read, provide a source of commands before invoking that code.
I'm writing the below in bash, but you can convert it to whatever language you actually intend to do this in:
# create a file with the commands you want to run
cat >/tmp/commands <<'EOF'
echo "Hello world"
EOF
# open that file and copy its file descriptor to FD 0 (stdin)
exec </tmp/commands
# then invoke your compiled executable that starts a shell.
run-your-command-that-starts-a-shell
If the program controls or overrides its stdin
Another option is to pass ENV with the name of a file to source:
cat >/tmp/commands <<'EOF'
echo "Hello world"
EOF
ENV=/tmp/commands run-your-command-that-starts-a-shell
I am debugging a C program with gdb. I have used the tty command to send the output to a new terminal window but am unable to enter input while the program is running.
If I debug in the same window it works fine, but when using a separate terminal window, input doesn't do anything.
I can still kill the process with ctr-c but once I hit the input line, it waits for input and doesn't do anything when I press return.
I have looked around but am haven't found the same problem online. Any ideas?
Start your program in one window. While your program is waiting for input, start gdb in another window. Use the gdb attach command to attach to and debug your program.
I am trying to write a program , which does a fork and exec a child process and executes it in the back ground .
One approach I would see is to redirect the output to /dev/NULL file and come back to my main program . Any other ideas ?
After a process is started, shell has no more control on process file descriptors so you can not silence it by a shell command i.e. terminal has its stdin, stdout and stderr bound to the terminal and you cannot do anything about it without re-gaining control over that terminal.
There is a tool called retty how you can use it can be seen at this link retty this tool is used to attach processes running on terminals
Beside you can also use the built in disown command to disown the process which will prevent from sending a SIGHUP signal to the program when the shell exits
This link can be helpful Link to a similar problem
I'm now working on a small C program in Linux. Let me explain you what I want to do with a sample Linux command below
ls | grep hello
The above command is executed in the below passion (Let me know if I've got this wrong)
ls command will be executed first
Output will be given to grep command which will again generate output by matching "hello"
Now I would like to write a C program which takes the piped output of one command as input. Means, In the similar passion of how "grep" program was able to get the input from ls command (in my example above).
Similar question has been asked by another user here, but for some reason this thread has been marked as "Not a valid question"
I initially thought we can get this as a command line argument to C program. But this is not the case.
If you pipe the output from one command into another, that output will be available on the receiving process's standard input (stdin).
You can access it using the usual scanf or fread functions. scanf and the like operate on stdin by default (in the same way that printf operates on stdout by default; in the absence of a pipe, stdin is attached to the terminal), and the C standard library provides a FILE *stdin for functions like fread that read from a FILE stream.
POSIX also provides a STDIN_FILENO macro in unistd.h, for functions that operate one file descriptors instead. This will essentially always be 0, but it's bad form to rely on that being the case.
If fact, ls and grep starts at the same time.
ls | grep hello means, use ls's standard output as grep's standard input. ls write results to standard output, grep waits and reads any output from standard input at once.
Still have doubts? Do an experiment. run
find / | grep usr
find / will list all files on the computer, it should take a lot of time.
If ls runs first, then OS gives the output to grep, we should wait a long time with blank screen until find finished and grep started. But, we can see the results at once, that's a proof for that.