Sunday 27 November 2011

Data Capture

Your terminal program should have a data cap-ture feature. This means that as information gets sent through your modem and put onto the screen, you should be able to capture it in a disk file.

It's important for you to keep the data capture feature on whenever you're using your modem. You do this for several reasons. When I'm logged in somewhere, I like to poke into all the text files I can find, but I don't like to waste my time on the sys-tem by actually reading them while on-line. In-stead, I turn on my data capture, store what can be hundreds of pages of text in separate files, then sort through the data later, offline, at my leisure. (At other times it is more appropriate to simply transfer the files; what one does depends on circum-stances.) Data capture is also handy to pick up control codes and text that scrolls off the screen too fast for you to read. And sometimes text is immediately erased after it's put on the screen, either for security reasons or due to faulty software. With data cap-ture you retain a permanent record of that text. In any event, it's nice to have an official record of your hacking activities that you can use for reference and research. One time I called up a bulletin board (BBS) that was run by a local company, mostly for the pur-pose of advertising its products. The modems con-nected, I pressed Enter a couple times, and I got the usual random characters on the screen, then the login prompt came on. It took a little longer than usual to get to the login prompt, and I was wonder-ing about that, but nothing seemed really unusual so I went about my business.

Later, I was going over the print outs I made of the break-in and I took a second look at what at the time seemed to be just normal login garbage. In the middle of the nonsense symbols was this: "d-b". And on the next line, sandwiched between two plus signs, this: "ye!". On the surface this doesn't look too interesting, but
think about it: put "d-b" and "ye!" together and you get "d-bye!". What I was looking at was the last half of the word "good-bye!".

From using the BBS I knew that "good-bye!" was the last thing one sees before logging off. In other words, I had called the system just after someone else had logged off, and I had gotten the tail end of their log-off message. This meant there was something wrong with the way the remote software handled disconnections.
This meant there was a bug that could be exploited.

I logged onto the system again, and the first thing I did was go to the "User Log" to find the re-cord of my last login to the system. The person who had been using the BBS before me was a regular User of the system and, sure enough, according to the log she had logged off just seconds before I was recorded as having logged in.

Later I was able to incorporate my knowledge of this flaw to make myself a system operator by calling up and connecting soon after the real sys-tem operator had finished a scheduled mainte-nance check. I wrote a letter explaining to him what I had done, and how. Over the next few days we corrected the problem. So you see, sometimes weird things happen while you're logging on or off, but anomalies can occur at any time. The moral of this story is be pre-pared to capture this weirdness, and be prepared to analyze it when you find it. You never know when something out-of-the-ordinary is going to happen, like the sys-tem operator (sysop) coming on and doing system maintenance while you watch. I've had that hap-pen to me more than once. In fact, there was one week in which it happened twice.

When I was in high school there was one day near the end of September that I was sick, so I was staying home from school. Instead of rushing off to the bus stop, I was on my computer, dialing BBSs. The first day I was sick, I had just finished logging onto a system and was about to read my e-mail when the sysop
interrupted. "I have to do some-thing real fast," he typed, "and I'm late for school." Then he went about doing whatever it was he had to do. He went into the back screens of the bulletin board system program, then shelled out to his hard drive, and came back in again. He was doing every-thing so fast I couldn't keep
track of what was go-ing on, but later, after I'd logged off, I was able to go through the file I'd made of the event, and ana-lyze it thoroughly. The information I learned from watching that sysop fix his system did not help me break in anywhere, but it taught me more about how telecommunication systems work. And that's the
whole purpose of hacking.

A few mornings later, I was on another system and almost the same thing happened. Another sy-sop was late to an appointment, but before he went he just had to do some last minute rearranging. This time I was able to understand as I watched what was going on: one of the things the sysop did was to validate a new user's password (a dumb thing to do in front of somebody, but maybe he didn't realize I could see what he was typing). Since I was capturing the event in a text file as I watched it, there was no need for me to scramble for a pen to write down the passwords as I saw them scroll across my screen.

An alternative to data capture is to have your printer running continuously. There are people who do this, but it's always seemed to me to be a complete waste of ink, paper, time (especially if you have a slow printer) and electricity. Also, a printer won't be as efficient as your communica-tions program at capturing strange control codes and foreign symbols. You're better off capturing data in files, then using a word processor to sort through those files, erase what you don't need, and then perhaps print out the rest.