Stoned!

Besides contributing at @TheDailyWTF, I write DevDisasters for Visual Studio Magazine, and involved in various side projects including child rearing and marriage.

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.

Getting Stoned

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.

Featured Comments

Hey, I remember Stoned! Good times, good times. Back then we wrote viruses just because we could, not to fu*k people over. We'd regularly have competitions to see who could write the "best" viruses but we championed subterfuge over vandalism. The "best" viruses would be the hardest to detect and the fastest to spread; needless to say, a virus that zero filled your hard disk was not going to win you any prizes.

I'll forward this on to the guy who wrote Stoned, we still keep in touch and he'll just love to hear that one of his creations is still out there in the wild. If you're reading this just let me say well done, you obviously won that round you sly Aussie waster!

Greg's harsh introduction to the realities of QA is the same one lots of folks in the computer game industry go through. "Online game tester" sounds like a cool job, but it's 95% testing mundane crud like the game install/uninstall process, 4% completely scripted in-game tests ("go here and see if you can still walk through the wall"), and about 1% (or less) anything that resembles "playing video games".

The system is called MILES... you can look up the acronym. Some of us actually got to use it. Being in an OPFOR unit, I got to use it a lot. There's really nothing like watching people scatter from your RPG or being chased by tanks and choppers.

The idea is good: a microphone detects the sound of the blank firing, and the laser sends a coded burst to the target's sensors. So you actually have to have a working rifle, and not get shot. It also really is integrated, in that vehicles use the same system.

The original implementation (which is the one with the "keys") was shit. The sensors couldn't get wet, of course, so we'd sometimes try to wrap them in plastic. And, as per standard Army ergonomics, there was a big metal box jamming into the small of your back.

The laser was a big heavy box mounted at the end of the rifle. You had to zero (make everything point in the same direction) your laser to the rifle, and zeroing a platoon's rifles was an all day affair. Someone had to wear the sensors and stand out and be "shot" at.

The worst part was the mounting system for the laser. The (fairly heavy) box mounted just a few inches behind the muzzle. Without a fairly complicated arrangement of duct tape and zip ties, you'd lose your zero.

This was great for us. Once you got used to zeroing, it was just a hassle, but BLUFOR usually had no clue and knew none of the tricks. So they usually couldn't hit shit.

MILES 2000 changed most of that, (in 2007) the much smaller laser clamped down on the muzzle with a torque wrench and a finicky but workable device that made zeroing take about 5 minutes.