Chasing a Win32 bug in SetCommState

submited by

Style Pass

2024-10-14 02:30:02

For those (including myself) working on embedding systems, COM port is used day to day. sscom is a cute tool used widely. It’s small sized, fast, and reliable.

Icon of sscom tells us that it is built with an elder version of C++ Builder. Its size then tells us that it has been compressed by packer like upx.

Actually it is packed by ASPack. A quick search convinced me not to try to unpack it. Instead, we could load it into IDA Freeware. From the Names sub-view, we were sure that sscom is using ComPort-Library:

There are quite some printf(s) in [KissUART]. Enable them, and use it to open a newly connected probe and one accessed by sscom. Two values look strange:

What do these values mean? KissUART would not use flow-control, and these values are got them from GetCommState(). Modify several configurations, and feed the DCB back to SetCommState(). It is a best practice, isn’t it?

Why sscom always works? It does not use GetCommState(), and each field of DCB is filled before feeding to SetCommState(), where XonLim and XoffLim are both set to input buffer size divided by 4.