Hacking, Old School

by chaz

Back in the mid-1980s I had a previous life as a software developer at a mid-sized company, about 500 employees, and I was the first direct hire in on the IT staff.

A year or so later we hired another individual, I'll call him Ed, a year younger than me, and also a bright programmer.  We split shifts so that he was in the first thing in the morning, 7:00 am or earlier, to verify backup completion, and that systems were running stable.  Once things were verified, he'd enable login for users.  I worked afternoon/evenings to put the computers into single-user mode, and start the backups.  Lucky for me, I was a night person, and Ed lived closer to the office, so the arrangement was perfect.

The systems we had were running TurboDOS, best described as a variant of MP/M.  The main system brand we were using was MuSys.  The computers were actually a chassis with a single bus and storage, and multiple processor cards with memory on-card.

At first they were just 8-bit Z80s, but later we moved to 16-bit processors.  We had some old Ohio Scientific systems, too, but those were going away as we migrated over to our "robust" TurboDOS systems.  We connected serial cables from our MuSys computers that extended to dumb terminals around the building.

I recall the connecting transceivers we used from each user card in the system mounted to the back panel of the chassis.  They were about $18 each, and converted the I/O of the card to serial bus, and had a DB-25 RS-232 connector.  The reason I recall these so vividly is that our office was in an area of the city called "tornado alley," and large storms often occurred with a lot of lightning.

We actually had another building across the street from the main building.  Under the street we had conduit with dozens of copper UTP cables.  Well, as you can guess, lightning striking the ground and copper play very well together - too well!  And whenever there was a big storm, we could go into the computer room and smell burning silicone.  We directed our attention to the connectors that were used for the terminals on the other side of the street, pulled out those transceivers, noted the burn marks, and replaced them.  Voilà, systems were back up!

To simplify, TurboDOS has a structure where there are multiple partitions, and the first was usually the OS, and the last was usually for security... which included the active password file.  Disallowing users from logging into the system was pretty simple.  We had three password files: one that had all the user accounts (multiuser as we called it), another that had only the admin account (single-user), and the active password file that the OS used to verify users when they attempted to log in.  We'd just copy either the single-user or multi-user file to the active file name, depending upon if we wanted to allow only the admin access or all users.

So in the morning, after Ed's verification, he'd copy over the multi-user file to the active file, and users could log in for the day and do their work.  People became accustomed to this process, and knew they could get signed in shortly after 7:00 am.

This went on for a few months and everything went smoothly.  But then I started getting comments from workers that they couldn't get logged in, sometimes until 8:30 am or later.  As I didn't come in until after this time, I did not witness this, and our TurboDOS systems at the time didn't log logins, and files didn't have time stamps.  But one of our systems that we managed was an electronic badge-reader/punch-card system, and we did track times and dates from that.

We had optical cards the size of a credit card that had small holes we used to slide into readers at employee entrances around the building.  The card data was verified by our TurboDOS systems, and this would trigger the solenoid to unlock the door.  The same style card readers were used to clock-in for the day, and these terminals were inside the building at various locations close to work areas.

The output of the system sent data to flat text files in chronological order of the punch.  We kept two files - one for door readers, the other for time-clock readers - and separate programs were used to parse the data, loading it into our database system.  They read in the card punches every hour and added them to the database.  So if you came in at 8:30 am, there was a 30 minute gap between your punch time and the time was entered in the database at 9:00 am.

Reports continued to come in about delays getting into systems.  I confronted Ed, and he came up with excuses, or even would deny the systems being turned up late, but never said he was coming in late.  My intuition told me he was arriving late, but I didn't have a clear way to prove it because the time systems said he was in by 7:00 am every day.

Recall I mentioned he was a bright programmer...  What I suspected was that he was logging into the punch reader system and changing his punch time on both the door and time-clock readers.  As they were just text files, it was not difficult to do.

But recall I stated that he was, "...also a bright programmer."  I wrote a subroutine and compiled it into a library.  I gave it a name that didn't make it stand out, something like text_Cleaning.  I included my library toward the top of the programs that performed the punch readings, but buried it with other included external libraries.  I hid my source... it wasn't on any system... I had it on a compact eight-inch floppy disk (does that date this?).

In the programs that "read" the card punches, I entered my subroutine immediately following the line that read in the punches.  I sent my subroutine the same text that would be written to the text file of punches logged.  If you read the punch card code, it looked like the data was just being "cleaned" before it was written to the text file.

Here's what my routine did.

I knew my badge number and I knew Ed's badge number, so it would watch for either his or my punches.  If it found either, it wrote the data to another file in the OS directory (there were a lot of files there, so it could be easily missed when scanning it).  The filename was something like ThreadOSCRV.com, so it looked like an executable.  If you tried to run it, it would just error, but would you ever delete a DLL file in Windows that looked like it might be part of the OS?

I wanted to cover my tracks, so my subroutine did more than just append the text.  I actually shifted the bits of every byte three to the left.  If you looked at the file with a text editor, it looked like gibberish, just as if you tried to look at an executable file with a text editor.

Just one more step: I had to write a translator program to translate the file back into human readable format.  I kept that program off the systems - on that same floppy disk noted previously.

I collected a couple of weeks of data, and then showed it to my supervisor.  Both mine and Ed's punches where there.  We actually had an outside contractor who had been supporting the company before I was hired, and I was asked to show him the code.  My supervisor asked to include her punch card number as well, so I updated my subroutine to include hers, and we collected data for a few more weeks.

By this time, I provided the translation program to her so she could run it and view the results.  For further evidence, since the text files were appended to chronologically, we could see Ed's punches and we could tell they were edited as he didn't change the position of entry in the text files.  They remained in the same chronological order that they actually occurred in.

One day, after I had arrived at work, several people had collected at my supervisor's office, including the contractor, HR, and another manager.  They called in Ed, the door closed.  I don't even recall the amount of time that passed while the door remained closed, but eventually it opened.

Ed came out, head down, and still red-faced.  HR followed him to his desk, he collected a few things, then was escorted out of the building.  I never talked to him during this time; I actually suspected he knew that I knew what was happening and why it was happening.  I wondered if he knew it was me due to my previous inquiries of him about late system access.

It wasn't over.

I was then called in to the office with the same personnel.  We went over some of what was discussed during Ed's meeting and, as it turned out, Ed was not fired.  Rather, he was put on a very severe probation.  And I was asked to start coming in at 7:00 am...  I had a 40 minute commute, and now I needed to arrive by 7:00 am to get systems up!  And because I was no longer second shift, I actually got a pay cut.

The moral I learned: no good deed goes unpunished!