browser icon
You are using an insecure version of your web browser. Please update your browser!
Using an outdated browser makes your computer unsafe. For a safer, faster, more enjoyable user experience, please update your browser today or try a newer browser.

I wasn’t really a “hacker” per ce

Posted by on December 15, 2016

My friend Paul asked me if I could help him rip some CDs he’s had laying around. He didn’t have a CD drive as those are hard to come by these days. Having an old laptop laying around, I offered to do the ripping for him. So here I am, in my kitchen at the table, with a stack of CDs sitting here and going through them one at a time.

One thing I had forgotten about CD ripping, since it has been awhile, was how some CDs rip faster than others. Some are blowing through in no time flat while others seem to take forever. But in the process of ripping these CDs, I was reminded of when I first really started my ripping. Back in college.

In 1997 I was at EBCI here in Moncton. The college, as well as the building are long gone now. The internet was just starting to bubble up and MP3’s had just been introduced into colleges and people were ripping CDs like mad. I joined in on it during my IT classes back in those days.

I was studying to become a Network Engineer. It was a fancy class name for what was meant to be a Network Administrator job. But the real fun came when we learned about putting servers up and things we could do with them.

As a pet project me and Chris, a friend outside of college, opted to try and teach ourselves Linux. We had heard the best hacking tools were in Linux and had already been exposed to it via some web development work we tried to do as well. We spun up a copy of Slackware Linux and named the machine “dragonfly”.

Dragonfly would come to be a machine that would stand for some of the most interesting experiments of how young kids get access to tools maybe they shouldn’t have.

In those days, and to some extent still today, many of the better hacking or DDOS tools exist for the Linux platform. These tools usually involved sending specially formatted packet data from one system to a source. If the source doesn’t process the packet correctly, the end machine suffers. Like a basic reboot or blue screen of death or sometimes just the machine locking up completely.

Through a series of websites, research, and conversations with people we met online, we acquired a series of cool tools known for crashing computer systems or causing network havoc. They all had interesting names but here’s the ones I can remember: ssPring, WinNuke, boink, bonk, fraggle, land, nestea, teardrop, tear, newtear, syndrop, tentacle, smurf and sniffit. Many of these tools wouldn’t work today if compiled but if you dig hard enough on the web, you’ll find references to them.

ssPing was probably the first one of these that we ever really used to test what we could do. We’d have a user send us an email, or communicate with us for IRC chat. In those days, firewalls were few and far between and rarely used by home users. ssPing would send a large malformed packet of data and when the OS read the packet, it crashed. By crashing I mean the entire OS would just lock up. No ability to reboot. Just turn it off and start again. Blue screens of death were also common. When the system generated a BSOD, the computer would run but their access to the network would be dead until they rebooted.

Many of those other tools were variations of ssPing’s original concept just changed slightly for different ports, packet types, or in some cases changed to perform the same task after they fixed the patches.

None of the tools we ever used were capable of frying or wiping a computer remotely. 

In those days, the main online place for people to hang out was on IRC channels. #Moncton was a channel a lot of us hung out on. We had built up a small little community of people who hung out there. And like all communities, you had the people who annoyed you the most. Me and Chris got to the point where we wrote a script called ding.tcl which would detect the annoying individuals entering the channel and then fire off one of our tools to lock their machines up. We also had access to IRC botnets which with a “.flood” command would cause hundreds if not thousands of IRC users to just flood a specific user with junk data. When this happened, the user got kicked off the network. 

Outside of IRC, Infodog was quite big those days and it became a running joke to use the tools on Infodog and break their web servers every day. IIS on Windows NT4 was notoriously unstable and pretty much any Linux tool could crash that system.

But the height of our so called “hacker” days can be broken into two specific incidents I recall. We had one tool which we had been given called “smurf”. This tool was meant to take down networks, not just computers. If you smurfed a computer, it would reflect against every PC on that network and cause all of them to repeat the same attack against its self. By accident, I killed the entire manufacturing plant of Norampac by accidentally using smurf through their systems (I was an intern at the time) to cause what we used to call and IRC split. Worked really well but shut down a bit of production in the plant for a few hours. 

The second, and probably the most proof of how hard we insisted on respect came to a guy in a rival class. The “tech” vs “network” class rivalry was one that was pretty common at the school so we wanted to insure they had “respect” for us in the network class. He had also spun up a Linux box. We had made accounts for people in my class on dragonfly so they could explore. One person went exploring and found out where we kept all our goodies and gave his information to our rival class. Our rival logged into our system and found our scripts and attack code and made copies for himself.

At the time, we’d been told by a “real” hacker that there’s a sort of code they follow. Guys share code from time to time to help each other out. But there’s also an underlying respect in that if someone gives you something and says not to use it or distribute it, you do as was asked of you. By doing this, you earn the respect of the hacker community and it can open doors into other larger tools you would not have seen prior. At the same time, if a lesser hacker obtains something they shouldn’t have and the senior hacker tells you to destroy what you took, you do as your told or pay the consequences. If it sounds a bit mobster-ish, it’s because that’s kind of how it was. If the guy above you tells you to do something and you don’t, you get knocked down a peg or two.

We were by no means “real” hackers but certainly more so than a guy in the tech class who built a Linux box and copied some files. He had then given his root password out to a bunch of people in his own class as well as my class. He also told them about the tools he had got from my system and made sure everyone could make use of them on their own. It wasn’t long before a handful of others were crashing Windows PCs for something to do during class.

Chris came into the school one day and both of us approached Shane, the guy from the rival class. In an almost mobster like fashion, we “asked” that he remove the tools from his machine he had stolen from us. He said we left our stuff open and that it was our fault for not securing them better. We told him those didn’t belong to him and that he needed to remove them or there would be consequences. He shook his head and said there was nothing we could do and walked away.

Later that afternoon I was in class and spotted the guy next to me about to connect to the other Linux box. I quickly fired up my own connection and launched a packet sniffer. The packet sniffer allows you to see the raw data that is being transmitted across a network. In those days, the way networks were designed allowed for the transmission of anyone’s network traffic to be read by anyone else on the same segment. I was sitting right beside him so I was as close as I was going to get. And just my luck he happened to open a connection to the Linux machine in the tech lab and log in as root. I now had the root password and could teach Shane his lesson.

After logging in as root on Shane’s box, I immediately ran commands that wiped the drive completely clean. There was nothing left of his Linux box, including the tools he had copied from me. We had also secured our own box so no one but me and Chris could get to our tools again.

We never said anything to Shane about what happened but the next day it went through the school that “mysteriously” his Linux box had been wiped. He never did replace it.  I saw him in the halls later that day and he didn’t say anything to me. I guess his lesson was learned.

Good times 🙂

 

Leave a Reply

Your email address will not be published. Required fields are marked *