As I sat in my recliner in the living room, looking at the viral router microcode, I thought about what a data packet would have to contain in order to be affected by the viral router microcode. It took a few of Hilda's cookies to work through the possibilities.
Each defective packet would have had several things in common.
- a four bit code corresponded to a Julian date and time, down to minutes and seconds.
- A six bit code corresponded to a delay factor, from several seconds to several hours
- A ten bit code corresponded to a enable or go-active code
- A one bit code corresponded to the disable or go-dormant command
The code in the router would use these values to temporarily block data, and then copy and forward the data packet. The data header would contain the codes. When the Julian date/time code was equal to the current Julian date/time, the program would look at the delay factor. That factor would be used to determine when the data-stop command was enabled. That would start a little timer that would check for the go-dormant code. Once that time was reached, the router would return to normal.
Since these delay factors, and the start/stop codes, were part of the data packets, they were easily enabled. Data headers were typically 128 bits long, so it was very unlikely that most anyone would even pay attention to them. They were mostly interested in the address part of the header, which was towards the beginning of the header. The rest of the header was largely ignored when you were sniffing data packets.
These special headers were the key to the control of information. If the packet didn't have the special header, it wouldn't be delivered. Sometimes the router would just request a retransmission. Sometimes the data would be discarded. Either way, that caused extra traffic on the network. The result was just like adding extra cars to a rush hour traffic jam. More cars just made the traffic jam worse. If you added enough cars, you'd get gridlock. Nobody moves.
These headers allowed you to control data transmission. You can block data, throw it away, or add enough requests for retransmission that you get data gridlock.
And then there were the data packets that were copied and forwarded. This is the real "Problem": data packets that can be tracked. Where were these data packets going? And it looked like some data packets were sending back their final delivery location.
It was all a bit scary. Because of the size of the router company, these routers were probably everywhere. There were thousands of them, probably spread throughout the world. They were inside company's private networks, and in outside/public networks. If you looked at any company, you would probably find that brand of routers.
My analysis of infected data packets showed that they weren't really widespread. They seemed to be just test packets, using for testing the system. There weren't that many of them compared to the total number of packets being sent around every day.
Then I remembered back in 1998, there was the first widespread data outage. It affected one of the big systems for about 10 hours, with residual outage affecting other companies. That was a bit of luck, because one of the systems affected were one of my clients. And my packet grabber program found them. Normally, I'd get just a few dozen over a week's period of time. These were the test packets. During the big data outage, I had thousands of packets that I had captured with my sniffer.