I'm doing a small ctf and I have to send a null byte with netcat in my payload. To do it I've made an executable which generates the payload and fed it into netcat with pipe like this:
challenge1.exe arg1 arg2 arg3 | ncat.exe domain port
This, however for some reason terminated netcat shortly after the call. Because netcat was connecting to the echo server I've seen part of the input being send back, but the amount of characters was always between 2 to 5. However, since I was receiving response I assumed that the bytes made its way onto server (cant imagine server start echoing before it receives all the data).
I've then found this question, and changed my command into
(challenge1.exe arg1 arg2 arg3 ; sleep 1) | ncat.exe domain port
.
This resulted in slightly larger chunks of data being displayed before the ncat shuts down. It made me try to increase sleep time, but there were no visible changes with values like 20 or 40.
So at this point I want to know if:
Netcat receives all the input including and after the null byte from my executable (it never gets echoed past null, but that's cuz the server runs c code and while it matches on new line for input, for output it terminates by null).
Netcat terminates due to null byte or the way it is fed, and how to fix it
Related
For fun, I want to type something in Bash that will connect to an IRC server and automatically respond to PING messages
For example, I have the following output from telnet
Connected to irc.example.com.
Escape character is '^]'.
PING :12341234
If I pipe this to grep and then sed, I can easily turn this output into PONG :12341234, but how do I send it back to the standard input stream of telnet?
Additionally, I'd like to still being to manually send input using the keyboard
What you're trying to do is known as an "echo server". It is fairly easy to do with netcat and it's variants (nc or netcat, ncat, etc.).
For example:
ncat -l 2000 --keep-open --exec "/bin/cat"
In another shell
telnet localhost 2000
Whatever you send will be replied by ncat.
From myhost.mydomain.com, I start a nc listener. Then login to another host to start a netcat push to my host:
nc -l 9999 > data.gz &
ssh repo.mydomain.com "cat /path/to/file.gz | nc myhost.mydomain.com 9999"
These two commands are part of a script. Only 32K bytes are sent to the host and the ssh command terminates, the nc listener gets an EOF and it terminates as well.
When I run the ssh command on the command line (i.e. not as part of the script) on myhost.mydomain.com the complete file is downloaded. What's going on?
I think there is something else that happens in your script which causes this effect. For example, if you run the second command in the background as well and terminate the script, your OS might kill the background commands during script cleanup.
Also look for set -o pipebreak which terminates all the commands in a pipeline when one of them returns with != 0.
On a second note, the approach looks overly complex to me. Try to reduce it to
ssh repo.mydomain.com "cat /path/to/file.gz" > data.gz
(ssh connects stdout of the remote with the local). It's more clear when you write it like this:
ssh > data.gz repo.mydomain.com "cat /path/to/file.gz"
That way, you can get rid of nc. As far as I know, nc is synchronous, so the second invocation (which sends the data) should only return after all the data has been sent and flushed.
I work with a protocol that's easy to use simply with netcat. The protocol starts with a login message, so I thought I could bang out a little script which pipes the login message before stdin to netcat for me.
I was able to get close, but there's one problem I can't figure out. The following script works, in that it sends the login message and allows me to interact with netcat. But if netcat exits (because the server side closed the connection), the script just hangs there (presumably because cat is still reading stdin even though no one is reading stdout any more).
( echo "${LOGIN}"; cat ) | nc ${HOST} ${PORT}
It's a tricky problem, and you're right about the cause. Processes don't get a NOPIPE error and SIGPIPE until they actually try to write to the pipe.
If nothing else, you can use the interaction scripting tool expect:
expect <(echo '
spawn nc google.com 80
send "GET / HTTP/1.0\n"
send "Host: www.google.com\n"
interact
')
This will run nc, send some HTTP headers, and then gives control to you. When nc exits, so does the command.
I need to give the user ability to send/receive messages over the network (using netcat) while the connection is stablished (the user, in this case, is using nc as client). The problem is that I need to send a line before user starts interacting. My first attempt was:
echo 'my first line' | nc server port
The problem with this approach is that nc closes the connection when echo finishes its execution, so the user can't send commands via stdin because the shell is given back to him (and also the answer from server is not received because it delays some seconds to start answering and, as nc closes the connection, the answer is never received by the user).
I also tried grouping commands:
{ echo 'my first line'; cat -; } | nc server port
It works almost the way I need, but if server closes the connection, it will wait until I press <ENTER> to give me the shell again. I need to get the shell back when the server closes the connection (in this case, the client - my nc command - will never closes the connection, except if I press Ctrl+C).
I also tried named pipes, without success.
Do you have any tip on how to do it?
Note: I'm using openbsd-netcat.
You probably want to look into expect(1).
It is cat that wait for the 'enter'.
You may write a script execute after nc to kill the cat and it will return to shell automatically.
You can try this to see if it works for you.
perl -e "\$|=1;print \"my first line\\n\" ; while (<STDIN>) {print;}" | nc server port
This one should produce the behaviour you want:
echo "Here is your MOTD." | nc server port ; nc server port
I would suggest you use cat << EOF, but I think it will not work as you expect.
I don't know how you can send EOF when the connection is closed.
I want to make a script that starts a program and then sends it key input. In psuedo-script:
#!/bin/bash
./program << (PRESS CONTROL-Z)
The program is running so if there were additional commands in the script they will not be reached unless say control-z terminates the program.
Is this possible? From what I've found I thought it might require key codes but I could be wrong.
This I think is probably a better solution than "expect" since it can be executed in native bash script, I'll be interested to see what you think.
Use
`printf "character code here"`
note the backticks
So for instance I have written a script that controls a remote gnu screen session, the following line opens window 2 and issues the ctrl-c key combo
ssh -t user#$host screen -p 2 -X stuff `printf "\003"`
The -t option simulates terminal input on the remote machine
-p allows us to specify the name or number of the window we are connecting to within the screen session.
\003 is the bash format of character code 0x03
See here for a complete reference of codes.
To find the code of some key input you can use
printf "%#x\n" "'X"
0x58
Were X is the key you want to find the code of
To find codes of non literals you can use ctrl-v (makes bash append the next key to the command line rather than intepret it) and then type the key combo, so if I wanted to find the key code for ctrl-c I would delete the X press ctrl-v and then press ctrl-c.
One last thing the ascii code reference mentioned above lists 0x13 as the carriage return, but in the screen manual they list 0x15 as the enter key code, does anyone know why? Ive tested in a local screen and when I press enter 0x13 is produced, but when sending commands via ssh to a remote screen 0x13 doesn't work but 0x15 does.
Hope that helps
Piers
You might be looking for expect (from http://expect.nist.gov/). This deals with the complexities of pseudo-ttys that make it appear to the program that the input from the script (in this scenario, the expect program) is coming from a terminal.
Alternatively, you might be able to use echo or cat and pipe the output of that into the program - it depends on the program.
If you just want the program to start in the background, just do
#!/bin/bash
./program&
If your intent is to background the program, use:
./program & # The & sends the command to the background
echo commands here are executed while program is in the background
…
wait # Wait for the completion of background commands
echo commands here are executed after background program has completed
Edit: If your intent is to stop the program (as ctrl-Z often does in *nix shells), you can send it the STOP signal:
kill -STOP pid
To resume the execution, send it the CONT signal:
kill -CONT pid
In each of these examples pid is the process id of the program. If you launch it in a script, it's easy to get with the variable $!, e.g.
./prog &
echo prog started in the background
pid_of_prog=$!
kill -STOP $pid_of_prog
echo prog stopped
kill -CONT $pid_of_prog
echo prog continues
wait
echo prog finished
Edit 2: If your program is one that exits when it receives a ctrl-Z character, then remember that the control characters have the numerical value of the position letter in the alphabet (i.e. Ctrl-A is 1, Ctrl-B is 2, etc.). To send this character to a program you can:
echo -e "\032" | ./prog
(032 is 26, i.e. ^Z, in octal. Of course you can produce the same character by any means, perhaps adding it to the end of other input like ( cat inputfile ; echo -e "\032" ) | ./prog.
But this may not necessarily work; the program must be designed to recognise this character from the input (which it probably won't); usually the shell catches it. Then again, most programs reading input from stdin just exit when the input ends, so redirecting any finite input (even </dev/null) should cause it to terminate.
And, finally, if the intent was to stop the execution of the program when some other event (detected elsewhere in the script) has occurred, you can just kill it…