Hacker Perspective: Clutching Jester

My history with computers started in the early-1980s with a custom-built IBM PCjr (I was about seven years old).  It had cartridge BASIC, and I could play King's Quest, Ghostbusters, Shamus, Lode Runner, and a variety of other games that captivated my senses and imagination.  I also very much enjoyed writing code (and a few years later watching the code of others via the demoscene, downloaded from various BBSes over our single phone line), and loved programming my own Zork-style adventure games in BASIC.

Fast-forward to high school, with many more coded and played games under my belt, along with two or three custom computer builds, lots of BBS and ANSI-art experience, a huge collection of downloaded demoscene demos (we're talking a box full of floppies), and a shiny new computer lab at our school.  This would have been the mid-1990s, and we all loved finishing our classwork or homework in time to stick around the lab and play some Doom or Descent.  Things (life, computer system regulations, people's attitudes) were much different and more laid-back back then overall and, in fact, the school's own computer professor could often be found playing a medieval-themed strategy game during class if he had finished his things to do.  My friend Bill and I had gotten to know this professor pretty well (and he us) over our several years of computer classes, and we always enjoyed how he taught and what we learned.  Senior year we got into doing some more advanced coding, and did so via Turbo Pascal.  And, without further adieu, our story becomes interesting.

The computers in our computer classroom were all DOS-based, and booted using some kind of custom DOS-based loader and then eventually Windows 3.11.  (I guess they didn't upgrade to Win95 by our senior year, but I honestly can't remember - ye olde memory does tend to fade over time.)  The custom DOS-based loader was interesting, as it loaded some required network drivers (IPX/SPX) and then required one to log in with a username and password that authenticated to a central server somewhere (we didn't actually ever investigate exactly how it authenticated, but you'll see why), and then afterwards it loaded some other protocols and dumped the user into their custom Windows interface with all of their files and folders ready to go.

After my friend Bill and I had learned quite a bit of Turbo Pascal and had logged in to the system above enough times, we started to think it would be fun, since the login system was DOS-based, to see if we could use our Turbo Pascal knowledge to write a "clone" of the login program that actually captured passwords during the login process.  We really didn't care to log in as anyone else and do anything with their accounts; we just wanted to see if we could pull it off.

Enter Alvin, stage left.  Of particular note in this scenario is another gentleman in our computer class named Alvin.  We had absolutely nothing against Alvin and, in fact, he was a nice enough acquaintance but not someone we knew well since he was a grade below us.  At any rate, what we did know about Alvin was that he was super protective of his password, inasmuch as he would look around the room before typing, making sure nobody was watching, and then hunch over the keyboard so that nobody could see his keystrokes as he typed.  Every day.  In this day and age of shoulder-surfing being potentially even more costly, the value of this strategy certainly seems more reasonable, but back then it just made Alvin look like the ultimate challenge/target for our password-capturing login Trojan.

And so, we got to work.  There were several programmatic challenges during the process because the login program had certain characteristics that we needed to replicate very accurately.  For one of those features in particular, reaching the standard of accuracy we required would be - how can you say - obvious.  That is, one of the things the actual login program did was "beep" on an unsuccessful login.  Since we had decided that the behavior of our program would be to "fail" at logging in no matter what was typed by the user, the length, tone, and style of the beep needed to be "pitch perfect," if you will, so as to not raise any suspicions.  But, you can only test beeps in a quiet computer classroom so many times before everyone, head computer professor included, starts to wonder what you're up to.  So, that part of the project, as well as a few others, took some extra care, as well as some sacrificed Doom and Descent time after school in order to make sure we got everything just right.

Some more detail regarding the program itself: as alluded to in the paragraphs above, our main strategy was to write a program that would capture the passwords, and would do so by simulating the login prompt and then "pretending to fail" when the user logged in.  We would capture whatever the user typed in the username and password fields, record them to two different text files in the Windows folder (with very convincing system-sounding names like NETWORK.SYS or IPXSTACK.DLL, or things along those lines), and we would encrypt that information with a straight-substitute cypher, just in case somebody happened upon one or both of the files before we were able to remove them to our external media (i.e., a 3½" floppy disk).  If I remember correctly, we did something like "two characters to the right" on the keyboard for our substitution, which certainly at least made the files not very readable!

So, after some care, time, and testing, our program was looking good!  We were ready to deploy.  But, at the same time, we were also paranoid.  What if we put our program on one of the computers, and some random thing happened and we lost the ability to physically control the situation, and our planted code was discovered?  That would certainly lead to some site-wide restrictions for everyone, and the perpetrators would be asked to come forward and definitely be sought after.  We certainly didn't want the story to end like that.  So, we decided to make our software "self-deleting."  That is, it would run itself, and once finished would remove all traces of itself (besides the incredibly clever encrypted "system" files) and it would be like nothing ever happened.  Yes, that seemed good.   But... we were still paranoid.  What if, before it could delete itself, the program was discovered?  What if, knowing that a program like ours was floating around, our head computer professor went around and pulled power plugs on the computers and thus rendered our program unable to delete itself before the machine was examined?  You see, the systems started with a series of batch files... the main one started the IPX/SPX stuff as mentioned before, and then called another batch file named LOGIN(.BAT) that was on a network drive and completed the actual network login.  We needed our program to be called instead of the LOGIN script and, being on the network, LOGIN.BAT was sitting somewhere it couldn't/shouldn't be modified without great risk of project exposure.  But the main system batch file, that one was generic and was running as a distinct (although duplicated) instance on every system... and it ran before the network was up.  But still, even if that file was examined, we wanted our software to somehow remain "hidden" even through a thorough inspection.

It was here we took advantage of two characteristics of DOS: 1.) we used the fact that DOS displayed everything in "ALL CAPITAL LETTERS" (and was case-agnostic) to hide our program in plain sight, and 2.) (less interesting, I know) we used DOS' system path functionality to cause the system to execute our fake program instead of the real one.

Regarding 1.), we decided to call our batch file logln(.bat).  L-O-G-LN dot BAT.  Because we discovered that, after some careful examination of a capital "i" and a lowercase "L" (see what I did there?), there was literally one pixel of difference.  The upper-right pixel was the only difference between the big "I" and the little "l".  So, we could effectively "hide in plain sight" and change the main login batch file of the particular machine to run our program, LOGlN, and not LOGIN like it was supposed to; and even upon close examination, the presence of our program - ready to execute in the main startup file of the "infected' machine - would very likely go unnoticed.

Regarding 2.), each system's startup batch file already set the PATH to include the root of C: (along with a few other local directories) in the system path.  Since our filename was named slightly differently than the real LOGIN script, LOGlN (with a little "L") would not be found in the current directory and the system would then search the path for it.  It would, of course, find it, and the magic would begin!

So, the simulated login program was looking good.  It was highly accurate to the original - it beeped the same way, paused the same way, refreshed the same way, looked the same way; to anyone using it, it was absolutely impossible to tell any sort of difference between the real login prompt and ours.  And now, everything else was good as well - we could install our program (using a custom-built boot floppy) on any machine in the computer lab in just a few seconds, it only made one tiny, virtually undetectable modification to the login scripts - it copied only two new files to the target system in a place that was unrelated to the other startup scripts, and it completely deleted all traces of itself (besides the encrypted payload) once it was finished.  Now it was time for a real-world, real-person, non-test run of our program.

I don't think either of us had ever been so nervous.  We had tested our program thoroughly and done many test runs on different machines in the lab, but putting it out there for a "real person" to try seemed so daunting.  But, nerves or not, it was crunch time.  So, during lunch break one day, we rapidly finished our food and headed back to the lab.  We quickly and quietly booted up one of the machines with our disk, and a few seconds later the magic was done, and we walked into an adjacent room for study hall and breathed a huge sigh of relief.  Phase 1 was complete.  But back came the nerves as we anxiously peered back into the lab to see how Phase 2 would go.

A little bit later, after the bell rang, another student walked into the lab after lunch for her computer class.  As luck would have it (she always sat towards the back), she happened to sit right down at our infected machine.  We could see her eyes over the top of the monitor, and we watched as she set her bag down, got out some papers, and then proceeded to type in her username and password.  She didn't type super-fast (and was thus pretty accurate), but when she pressed Enter she was met with an unfamiliar "beep" informing her that her password was typed incorrectly.  She looked confused, and typed in everything again (in what was now the real login prompt), and was logged right in.  She shrugged, didn't give it another thought, and began doing her work.  With a huge sigh of relief, we looked at each other with big smiles on our faces - it had worked!

Later that day, we came back to check our payload.  Sure enough, there were our two encrypted files, and there was no other trace of our program ever existing.  We moved them to a floppy, "decrypted" the username and password, and then attempted to login with those credentials, and lo and behold - mission success.  Over the next few days, we tested it a few more times on a few other computers with a few other accounts, and it worked like a champ every time.

Now... with real world success under our belts, we knew it was time for our main target: Alvin.  Now Alvin, while highly protective and careful, had one fatal flaw: he always logged in to the same computer.  Every day.  So we knew exactly where he'd be.  We prepped his station before class one day, and moments later sat back and watched Alvin's own puzzled expression as the computer informed him he had typed his password incorrectly.  After another scan of the room and another full-body keyboard covering, he tried again, logged in successfully, and carried on without a second thought.

Recovering Alvin's password later that day was like finding a pot of gold or discovering a long-lost ancient artifact or something, and was super-satisfying because of the overall process and challenge.  Once we knew we had Alvin's correct password, we walked up to him one day after class as he was packing up his things.  We each stood on either side of him, and when he looked back at me and asked what was going on, I just leaned in and quietly said, "Hey Alvin... kingdoma."  His eyes met mine, and they were huge.  He knew how protective he was of his credentials; the fact that they were known, and by only an acquaintance, seemed inconceivable.  Then we just walked away (I guess we were trying to be cool, or really didn't know what else to say!  Ha.).  Mission accomplished.  Alvin learned that sometimes things are not safe no matter how careful you are or how hard you try to keep them that way.

To end this story, I'll point out that we also learned about controlling the group with which you share this type of information.  We told some of our LAN party friends from two grades below us about the software and they, of course, wanted a copy to examine.  Bill and I discussed it, and hesitantly gave a copy to a couple of close trusted friends.  But they, of course, had trusted friends who had trusted friends who had trusted friends... you get the picture.  The next thing you know, somebody had used our program to capture the head computer teacher's password from his main machine.  He was, of course, very unhappy, and Bill and I went up after class one day and confessed that we were the original source of the code.  We explained our intent (which was simply to see if it could be done, not actually log in and use anybody else's accounts or damage or change their files) and how we had lost control of the code.  Our teacher looked intently at each of our eyes for a few moments, nodded, said "O.K.," and went back to his desk and sat down.  We never heard anything else about it until he joked with me, while shaking my hand at an awards presentation at the end of the school year, about almost giving me a blank sheet of paper for the computer science award he was handing me, because of the code incident.

What did I learn from the whole experience?  The value of great friends is incalculable (Bill and I are still great friends to this day).  Be careful who you trust.  Self-examine and look for your own "fatal flaws."  Be honest.  Get to know people well enough to know their hearts, and not just their actions, because you might treat them differently if you do.

Kd]]i kdb;p,j/ tntyi[,t#

Clutching Jester is currently enjoying and living life with his wife and kids, and continuing pursuit of the notion that science, while awesome and important, just may not be able to explain everything... [383133]