So we're here at the house after the trip down to Sacramento, after the short digression into alarm systems.
I brought in the router and laptop in from the car into the computer room. I connected the laptop to my network, and transferred the data files from the laptop into my test system. I then sat down at the test computer and took a look at the router's BIOS code file. I used my assembly language 'disassemble' mode, which took the BIOS code and put it into assembly language source code. I printed it out, and took the printout into the living room, stopping by the kitchen for some of Hilda's oatmeal raisin cookies and a glass of cold milk. I sat down in my old recliner in the living room, grabbed a cookie, and started looking at the source code.
It usually takes a bit of time just to break and de-compile a program out into it's various routines. So it was about 10:30pm (and a dozen cookies and three glasses of milk, and a short trip to the 'library') before I got it all figured out. Most of it was pretty standard code, but there was a very short routine that had me puzzled.
This routine was looking at the header of each packet for a specific sequence of byte values. Normally, a router looks at the packet header to determine the packets' destination, compute its checksum (to ensure the packet got there in one piece without being garbled). But there was that one routine that was testing for a specific byte value in the packet header.
I went through the code again, and then it jumped out at me. If the specific byte value was found, the router would 'declare' that the packet was garbled, so it would request a re-send. And there was a short delay before it would request the packet re-send.
I looked a bit deeper into the code, and saw that it looked for more than one kind of 'delay' byte value in the packet header. The delay byte was used for several purposes. One was to request a re-send, another would modify the data packet checksum to a 'wrong' value, so the next destination would request a resend, and another would change a few bits of data in the data packet (along with recommitting the checksum) so that the data wouldn't be delayed, but would arrive with slightly different data than what was originally sent.
And there was this other part of the microcode. With a specific flag set in the router's registers, the data packet would be copied, put in a separate packet 'envelope', and sent to a specific IP address.
None of these packets used the weird microcode in the router. But this microcode was commonly used in many routers. The microcode was easy to find, you could grab it from the company's web sites as updated or older microcode. Sometimes you would need to reload or update the router's microcode, so the vendors would make it easily available on their web site.
I needed to take a closer look at the microcode, and how it was affected by the viral data packets.