When Greg was shopping for jobs at his college’s career fair, there was a whole lot of business as usual.
The larger banks were on-hand looking to swoon the upcoming Financial grads. Several representatives from a few big name manufacturing corporations were there to interview the Chemistry majors and a few IT firms were on the lookout for the soon-to-be CS grads, like Greg, to add to their ranks. However, amid the ocean of pamphlets and suits there was one aerospace corporation with one particular position that caught Greg’s attention. The position that he applied and was ultimately hired for could be summed up in one sentence:
“You’ll be testing laser tag games for the military.”
A Dream Come True!...kind of
Actually, Greg’s official title was “QA Analyst for Battlefield Training Simulation Systems” but the idea of the system being a great big laser tag game really wasn’t all that far off the mark.
The way the existing setup worked was that sensors on a soldier’s body vest would detect a “hit” during the simulation, and would then set off an annoying alarm that could only be turned off with a special key. Once deactivated, the solder was ‘dead’ for the rest of the training scenario. It all worked, but one big problem with the whole setup was that, to the displeasure of many, a few enterprising soldiers managed to get their hands on and started selling tester keys (also known as “God Keys”) that allowed soldiers to resurrect themselves and get back into the battle.
After a number of years of trying to prevent soldiers from exploiting the system and a host of other technical headaches, the military was finally able to replace their system with something a little newer.
New features like the addition of GPS tracking units, RF data modules reporting hits and their locations and a slew of backend upgrades meant that military trainers could execute more extensive and complex training scenarios and, over time, recoup the costs because the new system was designed to rely on “off the shelf” 3rd party solutions, but first, these solutions would need to be vetted by QA guys like Greg.
Like any new hire, Greg was completely pumped and ready to contribute and shake things up his first week, but as time went by, Greg’s excitement dwindled when he found that doing QA analysis didn’t really involve shooting co-workers with laser guns, but instead was a lot of tedious, hard work with project managers and piled on bureaucracy for good measure.
In one particular situation they received a firmware update for one of the GPS systems being used in the Player Unit modules.
While trying to figure out why the latest hardware revision was failing immediately after the first test he noticed that the GPS receiver would send out a burst of garbage every few seconds.
Puzzled by this he checked and re-checked the connections and tried one of the spare units only to find the same result. Everything seemed like it should fine and the supplier swore there was nothing wrong with their system. Not able to let something like this go, Greg spent many late-night hours pouring through raw dumps of the results and along the way, he began to notice a pattern of the same Hex data repeating in the noise. As he painstakingly translated the hexadecimal into ASCII, he was genuinely surprised upon being greeted with a curious snippet of text.
Your PC is now Stoned!
After a quick search on the message, it all made sense. Somehow, the firmware upgrade for the GPS system had become infected with a disk boot sector virus, which ran perfectly fine on the embedded processor. Since this virus couldn't write itself to a disk, as there were no floppy drives on the GPS card, it instead sent itself out through the RS-232 port once every 5 seconds in hopes of infecting another computer.
Greg wrote up his analysis and forwarded it off to the vendor, who quickly (and quietly) issued another update to their firmware, identical to the last except without the virus.
Upon loading of the updated firmware, Greg noticed the difference immediately and was pleased to see that the vendor's "fix" resolved the "data issue" that he'd reported, however, there was a small catch to this tiny update. You see, preliminary testing for military equipment is a long and detailed process that makes the most draconian corporate processes look positively streamlined. Also, since the magic keyword "virus" had been uttered, QA testing couldn't just pick up where it left off, and couldn't just be for the GPS module. In fact, Greg had to start over at step 1 with added "anti-virus" steps add in for good measure just to be sure.