Oh Dumb Meter

This completely non-erotic tale is about one of the most fascinating (to me anyway) projects I was hired to do. It fits right into the "2020 Literotica Geek Pride Story Event". Thanks to Chloe Tzang for organizing this event.

For those of you who comment that my stories appear to have been written by a geek, you now have your confirmation. Guilty as charged.

I can't tell you the 'who', as I'm still bound by a non-disclosure agreement. However, in vague general terms, I can tell you what I found. It will you give some insight into the morals of a particular industry. And if you believe that industry is the only one impaired, I'm selling shares for a diamond mine in Leadville, which you can purchase rather inexpensively.

Recent comments and emails have suggested that I overuse certain words. Sadly, my give-a-shitter is still broken. Even if I use Scrabble as a cross reference, I get mixed results. Words likes gawd are legitimate, but ain't ain't. Ain't but a few of you who didn't understand that, so by gawd, I'm going to continue using both. So much for this year's O Henry.

Please read my profile for my stance on comments. Feel free to email suggestions or to start a conversation. Private messages work too.

I really wanted to use a Bob Seger lyric, but the NDA won out.

Bob Dylan: "When you ain't got nothing, you got nothing to lose. You're invisible now, you've got no secrets to conceal."

= = = =

At the dawn of the personal computer era, I wrote operating system software destined to be imbedded in products. Those products were almost entirely used in computer to computer integration. License fees from peripherals, such as disc drives and communications gear, allowed my company to grow. Although I owned the company, my employees actually thought I was one of them. My title was Manager of Software Development. I worked in my floorganized office. Stacks of printouts, and legal pads filled with horrible penmanship, were strategically placed on the floor. Don't you dare move anything.

A portion of one of my earliest software products is patented and was registered worldwide. Those that wished to use it, could license it for a fee. The license fees made for a nice living, even when I didn't bill a dime elsewhere. For legal and tax reasons, my patent was held in a trust, along with most of the accumulated license fees. The IRS still expected their pound of flesh, which I paid on time. I also had to pay quarterly patent annuity fees in about a bazillion countries. A good patent is valuable, and mine was worth protecting.

As I was one of the first on the market, and what I offered was easily adapted to the rapid introduction of better personal computer devices, business was brisk. As with many licensed hardware and software products, the fees spiked in the first few years and then rapidly collapsed. Shooting stars is all they are, but you only need to capture one, and I had. Once the incoming fees neared zero, I dropped annuity payments to all but the United States, which kept the door open in the rare case of resurrection. Over time, I drained the trust, trying to run and breed racehorses. It's called 'The Sport of Kings' for a reason.

My company transitioned to doing specialized software.

When one of my staff alerted me to possible software plagiarism, by one of my programmers, I took it seriously. My reputation, and in this case that of my company, was not something I took lightly. It didn't take long to prove that he had incorporated non-original and not-public domain software into one of our upcoming software releases. He was terminated, with cause.

When he landed a job doing similar work for a competitor, I followed his career. Once a cheater, always a cheater. When that company won a contract, I reversed engineered the chips. It took a few years, but eventually I found my patented code being used.

I first dealt with Pat Wagner (not his real name) in 1994. He was on the opposing legal team trying to derail another of my plagiarized software lawsuits. Although my software is available for a fee, this company used it without paying those fees. They balked at our out-of-court settlement offers, so we filed suit. From start to finish, the legal tango lasted four years. I won, but they immediately filed for bankruptcy. My legal team got what they could, but it amounted to little more than a moral victory.

For non-geeks, the following will make your eyes glaze over. If you're a woman, and this makes you tingle, wait for me in my truck where we can examine some ones and ohs.

My patented software was written to be burned into WORM chips (Write Once Read Many). The processor was initially an Intel 8086 but adapted easily to the 80286 in the early 80s. This software was for the 'machine level', or the most primitive level of programming, and was used to sequence interrupts. Computers are interrupt driven. There are interrupts you expect, such as the results of 'read this'. There are interrupts that are spurious, such as someone pushing a 'Start' button. Even among spurious interrupts, some are understandable (Start) and some will forever remain unknown (short circuit). You aren't expecting them, so how should they be handled? My methodology of handling spurious interrupts was something that, at the time, could be patented. Later court challenges, to the patent, would claim that you can't patent the obvious. If it was obvious, why was I the first one to do it that way?

Each section of an operating system is assigned a priority level. The lower the level, the higher the priority. In easy to understand terms, level zero gets worked on before level 1, which gets worked on before level 2, and so on. When a lower level wants to do something, the computer stops what it's doing, at the higher level, and initiates the software for that lower level. Once done there, the computer works on the nearest higher level needing attention. An example would be that level sixty asks level fifty to do something. Level fifty then asks level forty to do something. When level forty is done, level fifty continues. When level fifty is done, level sixty continues working.

Early processor chips had very few interrupt levels, which increased with each new generation. From sixteen, to thirty two, and so on.

When a hardware device is included in the overall design, it is assigned to an interrupt level. When the software is running, if more than one piece of hardware needs attention, the one assigned to the lower level gets worked on first. Not all levels have hardware devices. The lowest levels are usually memory management or task queueing. The thing you have to avoid is what's called a deadly embrace. That happens when a lower level is 'waiting' on something that a higher level needs to do. Since the lower level won't give up control, the higher level never gets to respond. At that point you are locked up, and back to the drawing board. A single programmer rarely makes that design flaw, but once multiple programmers get involved, it happens.

+ + + +

Although I no longer needed to work, I kept at it until I turned fifty, then cashed out.

A few years into the new millennium Pat Wagner had moved to greener pastures. He was with the Department of Justice when he reached out to see if I'd be interested in analyzing some computer chips at the heart of his investigation. I was a few years into my retirement, and not working rendered me bored silly, so I jumped at the opportunity. Over the years, I've had to sign dozens of non-disclosure agreements, so my lawyer knew the outs that I wanted. One of those outs allows me to 'theoretically' talk about how I discovered things. If the NDA involved a legal challenge, and the 'other party' pled guilty without admitting to any wrongdoing, I had a little more leeway. Since I'm telling you, that's exactly how this story played out.

After the paperwork was executed, I started reviewing the volumes of notes gathered on the case. There was a gushing review in an auto industry journal. Better mileage and lower maintenance costs were a few of the sales hooks.

The review was extolling the accomplishments of a certain automaker's line of sedans. These vehicles had lower 'cost to maintain' figures than any of their competitors. Quite an accomplishment. They attributed some of their success to expanded monitoring by their state-of-art electronic devices.

Then I read the government's accusation, that the odometer in those models were inaccurate. We were in the digital era (electronic display vs mechanical numeric wheels), and there were dozens of examples where the odometer seemed to be creeping upwards. My task was to see if there was any reason for the inconsistent behavior. To my dismay, odometers only need to be accurate to plus or minus ten percent. W TF? So why was the DOJ concerned? Intentional fraud isn't a valid reason for odometer variance.

Reverse engineering, done by another of my programs, had little problem recreating the code embedded in their chips. It is a painstakingly slow process to turn a bunch of ones and zeroes into something readable. I was retired, so it kept me from going crazy. Where to start? Dynamic Link Libraries, or DLLs. Dynamic Link Libraries are there to take away the temptation to re-invent the wheel with every project. For example, in a Windows operating systems, the Comdlg32 DLL performs common dialog box related functions. Once you've identified the DLLs woven into the final product, you not only know the programming language used, but you can also turn those ones and zeroes into readable code. Given enough time, you could almost recreate the original source code. That however, wasn't what this project was about.

The processor involved was a custom creation for the auto industry, which made it one I'd never worked with. That really didn't matter, since internet searches allowed me to learn quickly. Upgrades in processors usually involved speed and memory changes. The actual machine level programming language commands haven't varied much in fifty years (load, examine, manipulate, store).

My approach was to isolate each of the interrupt levels. The offending processor chip was several generations old which reduced the number of interrupt levels I'd need to research. Trying to find reasons behind each branch of a flow chart was challenging, but soon a pattern appeared. The software for many unrelated hardware devices would make a courtesy call to another hardware device handler.

That particular device handler sent some hardware fetch (read) commands, and then used those results to do some math. If some conditions were met, put (write) commands were initiated. It took me a few months to stitch the pieces together. Digging through schematics, as the accused automaker had priorities other than helping me, I soon learned that I didn't know shit about schematics. The weight of the software evidence would disclose what was connected at each level.

The motto of any successful investigator is 'Know What You Don't Know'. Over the years I made a lot of money picking up the pieces from some programmer who refused to admit 'they didn't know'. By the time I got called in, EVERYBODY knew that they didn't know. That being said, my basic approach is always the same. You know what you are seeing. Why are you seeing that? Why aren't you seeing this? What would happen if you saw these? Curiosity and imagination can unravel most mysteries.

So, what did I know? The feds suspected odometer fraud, and the whole point of one big targeted section of software was to issue one hardware put (write) command. I searched other software levels hoping to find similar interactions with common hardware. It was a never ending thread. I'd find the matching hardware commands, then reverse engineer that code. Like a family tree, the new code would tap a few other hardware devices.

The search was like solving a murder mystery. This does that, and then that does this. X is involved, but Y does more. I kept at it, or it kept at me. Eventually I struck gold in one piece of coding. Based on the value returned from THE key piece of hardware, this chunk of software would issue hardware commands whenever the value encounter increments of seven thousand five hundred.

That was pretty easy to deduce. Warranty maintenance reminders every seventy five hundred miles. When triggered, they would display various forms of 'Service Needed' lights. Knowing that the odometer was involved, it was pretty easy to prove that they were fudging the reading. Now it was time to figure out the 'When' would they tweak the counter.

After another few weeks of digging, I was convinced I knew what they were doing. While moving, every time you touched a button, whether it's the turn signal, side mirrors, or radio volume, the odometer bumped one tenth of a mile. You are distracted when touching buttons, so you never see it. Internally the chip kept track of the bumps and limited the lifetime bumping to a 3/32nd increase, or just under ten percent (in geek speak: five shift-right one-bit commands which divides by 32, store it, then add it back in twice and you have your result).

What difference does that make? You get supposedly better gas mileage. Your warranty work is needed sooner. Your warranty expires sooner. It makes a lot of money for the auto manufacturer. Every time your odometer racks up a thousand miles, you've only driven slightly above nine hundred.

The kicker was how they schemed to detect independent validation of the digital odometer. Due to head winds, when a car is in motion, the downward pressure on the shock absorbers are different on the front versus the rear. If a car is jacked up, and put into drive, the wheels spin but the shock absorbers 'know' that you are going nowhere. Not only do the shock absorbers tip you off, gravity forces create friction which causes tires to heat up in actual driving conditions. If all four tires aren't heating up, then you're going nowhere, and somebody must be running a test. When testing was detected, the bumping software stands down.

+ + + +

Epilogue:

As I was keeping Pat informed of my progress, the outcome was becoming evident to the DOJ. While preparing my final report, the automaker issued a recall to 'update' their control panel software. As you might guess, their new software had removed any trace of bumping logic. Let that be a reminder that, sometimes, a factory recall might be in your best interests.

Once the Justice Department had my report, the automaker agreed to pay a small fine while admitting no wrongdoing. Problem already found internally, they claimed.

I firmly believe that the auto industry has never tried anything like this again. And if you believe that, my oceanfront property in Arizona is available for a very reasonable down payment.

It does appear that some of those involved may have found employment at Volkswagen.