RPI - 'Knowledge and Thoroughness'

RPI - "Knowledge and Thoroughness" - 1984 to 1988

Somehow I managed to have relevant life experience before I took coursework -- especially in electronics and software. Generally, with those classes, I would skip the lectures, and just show up for exams -- straight A's

Sometimes I would get in trouble for being too intuitive in math and physics -- at least one TA graded me down on my exam answers, even though correct, by stating "show all work, -20" ... whereas I had shown all of MY work. Question -> Answer -> Easy. Anyhow, I earned the points back by going to the professor for whom the TA worked, and solving a few more problems the same way at the professor's desk. The professor did suggest that I spend some more time trying to derive intermediate steps so that others could follow what I had done ... essentially I had to learn their language instead of just solving questions. So much for spending 10 minutes on a 90-minute exam and leaving the test room early.

The primary point of each class for me was to learn the lingo for that professional domain -- not to learn the material which I already had an intuitive grasp of.

Freshman year, I managed to tutor/mentor/coach graduate students in physics on the finer teachings of quantum physics.

Along the way, the required curriculum had such languages as: APL, Fortran, Snobol, IBM 360 Assembler, Lisp, C, ADA.

FORTH was a language I became familiar with on the TI-99/4A computer. One of its more interesting attributes is that the kernel of the language interpreter is only a handful or so machine instructions which can fit in a buffer less than 16 bytes long on a 16-bit processor.

p*wning my first mainframe

I decided to implement the FORTH language from scratch on the RPI mainframe, which was an IBM-3081 (named Sybil) at the time. When I completed the implementation of the rudimentary screen editor and interpreter, I wrote a benchmark test to see how fast it was running. To my surprise, it was running 8-10 times faster than I expected from knowing the speed of the system ram. I formed some theories and verified that the CPU(s) appeared to have a 32 byte line size for a level one cache, and for instructions in the cache, they ran 8-10 faster than they did if they were in the main memory of the mainframe. I also noticed from my experiments that writes to the cache were actually write-to instead of write-through and the mainframe would ultimately write the changed contents back to main memory. I also knew from my reading of the IBM-370 and IBM-3081 reference documentation that main memory was protected by a 4-bit execution context for each 4kb page of main memory, which only allowed programs with the correct context, or those with a supervisory context to access that page of memory for reads or writes. I formed a hypothesis from these observations, that perhaps the cache itself did not maintain the security context, or that there was a flaw in the operating system which allowed stale cache data from other processes to remain in the cache once my program started executing. I imagined that the code from the OS supervisory loader which had loaded my program would still be in the cache, I verified that it was, and that I could disassemble parts of the OS supervisory loader itself. I also verified that the cache was a single cache for both data and instructions. My next hypothesis was that the stale cache lines from the OS supervisory loader could be written by my program code -- I tried and there was no security exception! I then proceeded to fill the cache by reading other data, and forced the flush of those modified OS supervisory loader cache lines. In so doing I achieved complete ownership of the entire mainframe and all processes running on it. I did a quick POC that I could launch during a 1:1 meeting, and then met with one of the mainframe sysops I knew to show him the defect and its consequences. Over the next couple of weeks, IBM service techs came in and "refreshed" parts of the hardware and the exposure went away. I do not know if my school had early release hardware, or we had the actual commercial release hardware. I do not know if IBM had to "refresh" any or all of their other installations to fix the "bug". I do not know if the OS (we used MTS at RPI) had been patched to write-back and flush the cache when changing from a system context to a user context. What I do know is that the cache did not seem to cache nor honor the security context which was kept for main memory pages. In a sense, this was an early precursor to the modern "Spectre" class of attacks against CPU hardware.

Another hack -- accounting feature of mainframe.

For our classes that required mainframe usage, we were given accounts that had between $20 and $50 of "compute funds" which were charged for our use of CPU and DASD storage devices. If we ran out of funds, we would have to petition the professor to get more funds added to our accounts. One of my co-students noticed that he could overdraft his account (which wasn't normally possible) by submitting a print or plotter job that cost more than his available balance. He only overran by five dollars or so, but it was still interesting, we also determined that submitting another print job would decrement available funds, then fail before running the actual job due to insufficient balance. I formed another hypothesis given my observation that the accounting data seemed to be in a fixed point binary format with 16 bits to the left of the decimal (inclusive of a sign bit) -- the hypothesis was curiosity about how the accounting system dealt with numeric overflow. To test this hypothesis, I created a plot file with a lot of pen color changes mixed with pen-up and pen-down, each of which charged a fixed amount to the plot job. I was able to construct a plot job that cost over $32,768 dollars and submitted it. What happened next was simply amazing ... my account suddenly had over $32,000 in it, and the plot job starting running...I immediately cancelled the plot job, but my account balance remained at over $32,000. So much for modern math and accounting. An "unlimited" compute budget for the next semester. Anyhow, I was always more oriented toward ethical (white hat) hacking and shared the exploit with the sysop for the mainframe. The next version of MTS had a patch for its accounting that (1) refunded jobs which had not been able to run due to balance limits, and (2) caught the numeric overflow in the accounting software and rejected such transactions. The sysop let me keep my compute balance ;-)

Crashing the mainframe take #3:

Our school's mainframe, an IBM 3081, used MTS (the Michigan Terminal System) as its primary operating system. Among other features, the command line batch interpreter allow the use of "temporary files" which could be pre-allocated with a desired size to keep your jobs from running out of file space during the middle of their execution. I became curious about temporary files and noticed that the maximum size varied by time of day and other factors. What I eventually determined is that the maximum size of a temporary file was limited to one half of the file space currently available for temporary files, and if you allocated a temp file that took 50% of the total, that the next request would fail if larger than half of THAT (ie: 25%, then 12.5% ...) I wrote a recursive script to keep allocating temporary files at half the previous size until the script failed and my terminal screen locked up. What I later learned is that (1) the command line interpreter itself was using temporary files to buffer the lines of text submitted in the user's command line session, and (2) even the sysop terminal was subject to the same constraint of its command lines being buffered in the temporary file store. When I tracked down the sysop and told him what had happened, he shared that none of the other sysops could figure it out because the logging facilities had also failed, and that their terminals were frozen, and that they had to reboot the system by a complete shutdown and a microcode reload (for some reason, reboot of the MTS in memory did not work either -- perhaps due to "disk full" ??) Anyhow, the next drop of MTS put the sysop and system buffers into their own PRIVATE temporary file partition, separate from that of the users.

For one of my so-called "computer hardware design" classes, which was years behind my then experience level, I convinced the professor to give me class credit for helping one of his graduate students with their project. This particular graduate student was designing a DEC Unibus card which was to be a LISP accelerator for the VAX series of computers. In essence, the Lisp accelerator was actually a full-blow LISP interpreter implemented as a hardware CPU. As much of the other logic was completed when I started working with the team, my initial assignment was to implement test vectors and some LISP software to test all of the hardware functionality. After a few part-time weeks, I had achieved full test coverage of all of the chips and traces, as well as testing of the logic flow -- what I found though, was that the numeric operations were not working correctly and were scrambling bits and producing incorrect numeric results. When I dug deeper, I found that most of the ALU (arithmetic logic unit) was implemented with 4-bit bit slice AMD chips, and the design was completely goofy. I asked for permission, which was granted, and re-architected the entire ALU and had it working over the course of a 3-day weekend in a wire wrapped form. I updated the schematics for that part of the processor, and we shared the design and tools with DEC. (the graduate student's tuition and research was financed by DEC). A+

In my "senior" year at RPI, I took an elective course on "VLSI design". Given that I had already designed two separate ASICS for Myarc outside of school, and my experience with the LISP accelerator project, I asked the professor if I could get credit for this course by working on something more exciting. He was reluctant at the time, but said that if I could convince the Dean of the Engineering college, that he would accept that. The Dean was actually excited about my background and the next day read me in on another project staffed by PhD researchers funded by Tektronix. I signed some NDA (good for 5 years) in favor of Tektronix and commenced working with the PhD team. At this time I believe that the project was actually a funded military project. The basis of the project was to build a CPU using an entirely "new" to VLSI bipolar differential GaAS circuitry which had gate propagation delays 1000x faster than the then current generation of 3 micron CMOS I had worked with at MyArc. (5-10 pico seconds instead of 3-8 nanoseconds). The differential bipolar GaAs was novel in that it was bipolar instead of ECL like the Cray-3, it was also novel in that the bipolar signal essentially eliminated the parasitic capacitance to the substrate, allowing operation 10x than of the same ECL logic. After meeting with each member of the PhD team to discuss what they were working on I noticed a gap in their coverage of logistics needed for the completion of a chip. Those team members were all working on various aspects of lithography, etching and doping of the traces and transistors and characterizing their results. The gap which none of them had worked on was the actual place-and-route of the higher order components on the surface of the substrate. Although Tektronix wanted all team members to use Tektronix workstations, they conceded to my request for a Mentor Graphics workstation which gave me the capability to place and route using a VHDL toolset. My approach, which I have not seen since that time, was to use the place and route of the VHDL to route a 3 micron wide trace from the output of one logic element to the input of another logic element. I prevailed on the PhD team to place all of their bipolar interfaces on their logic elements 2 microns apart (center to center) so that they could be compatible with my tooling. Once the mentor graphic VHDL tools completed their routing, I automated performance of a post-processing step to "snip" the 3 micron trace into two separate 1 micron traces separated by 1 micron. I used the geometry of the vias to keep the traces the same length during longer runs across the substrate, and that same geometry could also be used to flip the polarity of the trace instead of using an inverter. After I post-processed the layout file and ingested it back into the graphical viewer, it was a thing of beauty with all bipolar lanes perfectly placed in geometric harmony. I completed my contribution to that project a month before graduation by designing an 8 bit ALU with full multiplier which was sent to Tektronix for a full tape out and test to validate my process and the gate design geometries from other team members. I got the impression, unconfirmed, that the overall goal of the project was to build a large scale DSP 100x faster than competitors, for use in encrypted communication channels. Another A+

Resonance -- a practical prank for VAXen

One of my classes required that I use an EDA system tied to a DEC VAX used for storage. The disk drives on the VAX were the size of a modern washing machine, stood on 4 legs, and used removable "Disk packs" which were about 18 inches in diameter and 8 inches tall. These disk packs were inserted by opening the top cover and placing the pack down onto the spindle. If I recall correctly, these were model RP06 which held slightly under 200MB of content. What I noticed one day is that the entire RP06 would rock noticeably when one of my jobs opened dozens of files at the same time for a merge-sort. Out of curiosity, I played with the file sizes and order of creation in order to modify the physical distance between the files on the disk surface. I also played with the merge chunk size to change the frequency of the head seek between different files during the sort process. By playing with the distance, the timing, and the rotational latency of the file access, I was able to rock the unit in a resonance pattern which cause the entire unit to walk across the floor of the lab to the limit of its connecting cables (perhaps 6 feet total into the room from its previous wall position). I ran the batch job on a couple of consecutive weekends, and the sysop of the lab equipment was puzzled and starting blaming the cleaning crew ... until I shared what I had done.

Freshman year -- RPI would, upon request, run a 9600 baud serial port into your dorm room. However, my personal computer at the time, a TI-99/4A, only had communication software that was reliable at only at 300 baud with a handset coupler. This motivated me to write "Fast-Term", in 100% assembler language, that was fully capable at 19200 baud. That's a story for another time. However, what is interesting for this story is the school's infrastructure is that the 9600 baud serial connection "to the school's mainframe", actually went to a PDP-11 rack full of serial ports, and the PDP-11 acted as a front-end-processor (the "FEP") for the school's mainframe. The FEP was designed from a software perspective as a load balancer, concentrator, and router for the mainframe. It was designed for the "dumb terminals of the day" but did support VT-220 and a couple of other terminal types for graphics output capabilities. What was not commonly known is that with a "smart terminal" one could, with special character codes unavailable on a dumb terminal, bypass the concentrator and drop into the PDP-11 command line on RSTS (DEC's "Resource Sharing Time-Sharing System"). From the command line, one could assemble and run new programs, as well as log and intercept any of the other active RS232 ports in the entire system ... which meant that there was a god mode where you could see the contents of everyone else's sessions. This, in and of itself was not interesting, but what was interesting is that a group of people who were members of the local ACM chapter had written a real-time chat application on the school's mainframe (early social media) that was lively between 11pm and 4am, at which point the group often broke up to go on IRL a "donut run". The school administration became aware and concerned of the resource utilization of the chat application on the mainframe ... at which point I shared my knowledge of the FEP architecture with other ACM members, and the entire Chat program was ported to run directly on the FEP over a weekend. By running on the FEP, no mainframe resources were utilized, the school's administration was none the wiser, and none of the sysops ever logged into the FEP directly or knew that it was being used for other purposes. The modern day equivalent would be someone running a website on your home router without your knowledge.

Training Pavlov's minions - Tesla coil door knob prank.

Freshman year in the dorm, many people had no respect whatsoever for a closed door to your room -- the entire dormitory often behaved as a communal space. I preferred my privacy sometimes and definitely preferred not to have people barging in when I was sleeping. I started placing signs on the door, to no avail ... nobody respected the signs either. My next solution, which was 100% effective after the first weekend, was that I built an 80,000 volt tesla coil from an old CRT beam coil...it was super low current at a very high frequency. I attached one end of the coil to the metal doorframe, and the other end of the coil to the metal doorknob which was grounded out to the doorframe when the door was closed. Having a closed circuit when the door was closed did not cause me concern -- the telsa coil simply became slightly warm to the touch from the continuous current running through it. However, the results were spectacular when someone (unauthorized) opened the door when the knob was energized -- they would receive a VERY UNPLEASANT electrical shock (overall harmless and non-lethal) -- people never tried that knob again without knocking. (and most people did not want to knock). Problem solved.

FORTH
LISP
SPECTRE execution
APL
Fortran
Snobol
IBM 360 Assembler
Lisp
C
ADA
VAX
C
LEXX
YACC
Pascal
GaAs - Gallium Arsenide
Differential bipolar
Place and Route - LSI
Place and Route - Circuit board
DEC
Unibus
QBUS
VAX
PDP-11
LSI-11
IBM-3080
IBM-3081
IBM-3090
IBM-360
IBM-370
BITNET
PL/1
Tesla Coil
RSTS
Chat Engine