Extra mystery bytes with some XModem CRC transfers

For reasons I won't get into here but are valid, I'm creating an "XModem CRC 1K" implementation of a receiver for transfers coming from Windows XP HyperTerminal.

Many files seem to transfer just fine... I get the 3 byte header (SOH/STX, Sequence, Sequence1C), the data (1024 or 128, depending on total file size), and the 2 bytes for the CRC16. The sequences are valid, the CRCs are valid, and all is well.

Yet, for some bizarre reason, HyperTerminal sends reproducibly malformed packets for some specific files. It's always malformed in the same way for the same files... some of the malformations I've seen include:

1. Several extra (non-control) bytes beyond the expected 1029 per packet. Eventually it does find a control byte again and can realign to the 1029 packet boundary with perhaps more added stray bytes further downstream.
2. An extra single byte after the very last packet of an otherwise fine transmission. Again, the malformation is reproducible but not explainable.

These transmissions are happening over a Winsock TCP HyperTerminal connection, so I don't think this is due to signal error like you'd see with real modems. The malformations are also always the same for a given file. I've looked over the specifications multiple times and these extra bytes aren't explained anywhere. Microsoft back in these days was known for not adhering to standards very well, so I'm wondering if this is the case perhaps?

Any tips are much appreciated.

Figured this out after some exhaustive testing. It looks as though HyperTerminal was replacing any occurrence of 0xFF in the packets with 0xFF,0xFF.

I suspect this is because HyperTerminal has its own control protocol which uses the 0xFF byte to begin the sequence. So is follows that an actual 0xFF byte would need to be escaped. It doesn't look like there's any way to disable this behavior in HyperTerminal, so the receiver just has to deal with the substitution (and take the efficiency hit, in my case).