That Netcat in the Hat he'd showed us his tricks, he'd showed us the what and the what makes it ticks.
He'd given us knowledge, he'd given us plans, but he'd left us the work, that tall feline man.
Well, Netcat had packed up,
he'd indeed taken off,
but he'd left us two gifts
like furballs, which up he had coughed.
These things I had heard of,
though indeed never used.
Thing One was dd,
and netcat was Thing Two.
When Manish had seen this,
he shook with a shiver.
Of Thing One he approved,
but Thing Two made him quiver.
"Thing One, it is good,
with most *NIX it comes,
but Thing Two it is bad,"
squeaked our associate lad.
"It can shovel back shells,
when it provides -e,
and hackers they use this for evil with glee,"
said our college intern while turning to flee.
"Manish," I yelled, "please live up to your name,"
I said as I typed feeling quite game.
"We could use dd to split off the last bit of TPSDATA090106.zip.
And then use ftp with append,
if it is offered," said our querulous friend, "and if not, we could just cat the two pieces together again."
"Manish, oh Manish, please grow a spine.
Netcat is our friend, both yours and mine.
If we use it with wisdom and brains,
netcat is as good as green eggs on a train."
But Manish persisted in his tireless refrain, how bad netcat was to security's reign.
"It pokes and it prods. It even can scan.
For these things that it does, it should surely be banned.
But I wouldn't listen, not one little bit.
Manish was being a usual twit.
So on I marched with the Netcat's plan,
the knowledge he'd given growing as flames that were fanned.
First, I needed to access that unsecured WAP, so I fired up my wireless card just like that.
I then ran iwconfig to confirm my connection to that wide open rig.
Next I ran dhcpcd because I had need of a local IP.
I then set up a quick firewall,
because I didn't want to share my pc with all.
It had connected to the first signal it found, and just like that I was surfing around.
Then, I scp'ed netcat to horton.whoville.net.
That was a step we couldn't forget.
With secure shell, I then opened a line, so that I was on horton in next to no time.
Since through our firewalls there wasn't an open available port, ssh did provide us with the needed support.
We'll use it to redirect our horton netcat connection over a tunnel in lumbergh's direction.
Ssh -R did provide what we need,
a remoteforward connection redirectional feed.
So back on lumbergh I opened a shell,
so that netcat could listen there too as well.
It wasn't so hard this line that I typed, for netcat to watch for data to write by redirect to the end of our file, of which I'd a copy to make Manish smile.
But now on horton the real work began,
I used dd to finish this plan.
I needed to chop off many a byte,
so dd with skip should do that just right.
The Netcat in the Hat, he'd found the figure, so that data I sent didn't have to be bigger.
So after setting "if" to the name of the zip, I set the skip and then tugged at my lip.
The "of" I would leave to be standard out, and this I would pipe for netcat to send out.
I set the block size to be ten-twenty-four to allow dd and nc to move packets out of the door.
Had our bytes transferred not been so nice, tail -c would have sufficed, to trim off the front and make the size lower.
With a block size of 1, dd could have done this but only much slower.
On horton I'd set up nc just so right,
so when it was through with sending all bytes, it would terminate on both ends, and this I had done with a q, my friends.
The nc on horton was writing those bytes, that dd was chopping up for their flights in packets that over our tunnel they flew, to nc on lumbergh far away from Kalamazoo.
We waited, we watched, our stomachs aflutter, hoping those bytes didn't end up as clutter.
When finally our nc sessions came to an end, our file was whole from beginning to end.
This we confirmed and to this I avow,
by testing our zip was unaltered somehow.
Gzip -t (or zip -T) tested and proved this incontrovertibly.
And so as our story comes to its end,
I think even Manish counts netcat as a friend.
Its uses are many, its facets are too,
as we have proved by sending a file from Kalamazoo.
As with so many things in this life,
it's in how it's used for good or for strife.
So be not afraid of nc or dd,
just let them prove how useful they be.
1. Thing One is dd.
2. Thing Two is netcat.
3. lumbergh#ssh -R 3333:lumbergh.initech.com:4444 email@example.com This sets ssh to do a remoteforward. It will create an ssh tunnel to the designated host, in this case horton, and set it to listen for connections to a given port, in this case 3333. It then will forward those connection to the host and port designated, here that is lumbergh.initech.com on port 4444. This has the benefit of encrypting the traffic.
lumbergh#nc -l -p 4444 >> TPSDATA090106.zip Here netcat on lumbergh is listening on port 4444 for connections and appending any data sent to that port to the end of file TPSDATA090106.zip.
horton#dd if=TPSDATA090106.zip ibs=1024 obs=1024 skip=4113563 | nc localhost 3333 -q 10 Here horton is processing TPSDATA090106.zip using dd with input block
size(ibs) and output block size(obs) of 1024 bytes. It is skipping the first 4,113,563 blocks of 1024 bytes, and starts reading and writing immediately after these blocks. The output is standard out which is piped to netcat. Netcat is connecting to the localhost on port 3333.
The -q will cause the connection to terminate 10 seconds after seeing the EOF(end of file). Since ssh is listening on 3333, it will forward all packets sent here across the ssh tunnel back to lumbergh and port 4444.
Some versions of nc will terminate the connection as soon as EOF is seen, but others would require a Ctrl-C if -q or -w isn't set, and not all offer both -q and -w.
4. horton#tail -c 214748147 TPSDATA090106.zip > transfer.zip This will write the last 214,748,147 bytes of file TPSDATA090106.zip to transfer.zip. dd can also do this if you set the ibs and obs to 1 byte allowing you to skip the necessary blocks to start the write.