arecord -f cd -c 2 | lame -b128 - - | netcat -u your-ip 6881 | mpg123 -
arecord -f cd -c 2 | lame -b128 - - | netcat -u -l 6881 | mpg123 -
ncat -lkp 8080 --sh-exec 'echo -ne "HTTP/1.0 200 OK\r\n\r\nThe date is "; date;'
ssh -oProxyCommand="ssh host1 nc host2 22" host2
This made all the time I've spent on HN in the past week worthwhile! :)
To get around that I just added the following to my bashrc
alias remote_host="ssh -t bastion ssh -t host1 ssh host2"
user@host3# ssh-keygen -t rsa -f ~/.ssh/id_rsa_hopping
user@host3# echo command=\"nc host2 22\" `cat ~/.ssh/id_rsa_hopping.pub` | ssh user@host1 "cat >> ~/.ssh/authorized_keys"
user@host3# scp ~/.ssh/id_rsa_hopping* user@host4:~/.ssh/
The point of all of this being that host4 should be able to do anything on host2, but only be able to use host1 as a hop:
user@host4# ssh -oProxyCommand="ssh -i ~/.ssh/id_rsa_hopping host1" host2
- creating quick and dirty proxies (nc > fifo > nc). (edit: you can also bridge udp->tcp this way, which makes proxying UDP through an ssh tunnel possible)
- making simple GET requests (printf "GET / HTTP/1.0\r\nHost: www\r\n\r\n" | nc host 80, or save the full request and pipe that to netcat)
- checking if a port is open (nc -p 8080 host, tends to be quicker than nmap and less to type)
- dumb file transfers ('nc -l port > file' on one machine, 'file | nc host2 port') on another (or using tar for directories). Usually I use ssh/scp, but sometimes that nc trick works just fine..
For instance, if server:port 1000 is the normal host and port my application would connect to, I set up a forward from port 2000:
nc -L server:1000 2000
my_application --server=localhost --port=2000
host1$ dd if=/dev/zero | nc host2 5432
host2$ nc -l 5432 > /dev/null
Like others in this thread, I too received a few bureaucratic slaps on the wrist for doing unauthorized port-scanning during the development process (we were trying to find a set of suitable unused ports for the package). Apparently it was worth the trouble, though--it was nearly 10 years ago that I built the package, and the software's still in use!
On the target host, run the following:
nc -l 31337 | bzip2 -d | dd bs=16M of=/dev/sda
On the host you're copying from, do this:
dd bs=16M if=/dev/sda | bzip2 -c |nc dest.host.com 31337
Bear in mind that this isn't secure (everything goes over the wire in clear and there's no auth) and that for best results you should only do this from a live cd (if you're dd'ing from or to the live drive you've mounted there's a high risk that you'll change the filesystem mid-copy, depending on source FS used, this could corrupt the destination).
dd bs=16M if=/dev/sda | ssh dest.host.com 'bzip2 -d >/dev/sda'
## On the destination machine:
losetup -e aes $LOD /dev/sda
# You'll be prompted for a password for the encryption.
nc -l 31337 | bzip2 -d | dd bs=16M of=$LOD
## On the source machine:
losetup -e aes $LOD /dev/sda
# You'll be prompted for a password; use the same one.
dd bs=16M if=$LOD | bzip2 -c |nc dest.host.com 31337
(Edited twice due to formatting sadness.)
We've used this for forensic imaging in the past and have relied upon digital signatures as integrity checks. It's not great I know, but it's the best way to get disk images from a big server onto a NAS (when you can't plug the NAS into the server).
Have you tried using the -C (compression) option to ssh instead of the bzip2 pipe? I don't often have occasion to do this sort of thing, so if you've tried that already, it would be interesting to know relative timing. pbzip2 ( compression.ca/pbzip2/ ) might be helpful sometimes, but I don't suspect that it's carried on most live CDs (unless you guys are rolling your own) and the CPU probably isn't the bottleneck anyway.
9P2000 has recently made it into the Linux kernel and it gets way better throughput than NFS, but (and I'm not too familiar with NAS hardware or software, so I may be saying something foolish) I don't suspect it's a supported protocol on those things. Either way, I also don't suspect that adding the overhead of an FS protocol could be helpful in cases where netcat would do, but it's a nice tool to have in the box.
nc -l -p 80 -e /bin/sh
And then just telnet or netcat to that port and you get yourself a shell.
nc -l $ARBITRARY_PORT | tar vzxf -
tar vzcf - files_or_directories | nc computer_a $ARBITRARY_PORT
cat canned_request | nc server 80
What about using rsync instead ?
echo "STATS" | nc localhost 11211
STATS can be replaced w/ other memcached-accepted arguments
echo -n "Sending SHUTDOWN\r\n" | nc localhost $REDISPORT &
At my current place of employment, "hacking tools" are banned. On that list is netcat. It is installed on every unix desktop and server, and I use it daily. I have decided to just not point out the stupidity of this -- they might do something that's even more stupid as a response.
"If you want me to defend you from the bad people on the net, then don't send me to a gun fight with only a knife."
Yes, that Randall Schwartz.
And no blame, but it's probably a good idea to say, "We're scanning for weak passwords" first. The sysadmin at the library I used to work at ran password crackers occasionally, and sent out an e-mail once saying that he suddenly knew a lot of staffs' boyfriends names. It's a delicate issue.
"hacking tools" are banned.
If you are asked about it. The best way is to respond that you use it as a a diagnostic tool or analysis tool.
As for arguing it's not a hacking tool - A person could take something as innocent as VBScript for Office and write viruses with it. Nothing you can do about your tools ability to be abused.