I read through the code because I had an other problem and searched for all occurences of strcpy, strncpy, ..
I see the following problem with callsign, defined in JTEncode.h:
char callsign[12];
We know, compound calls in wspr type2 messages are 12 bytes long: <DL9/DL9SAU>, plus the terminating \0.
JTEncode.cpp does:
strncpy(callsign, call, 12);
-> No buffer overflow, but the copied 12 bytes long string is not terminated.
The operation further down,
char slash_avail = strchr(callsign, (int)'/');
may search for '/' beyond end of char[] callsign (if user had a wrong input). Same for
char bracket_avail = strchr(callsign, (int)'>');
Fix:
I see no reason to keep char callsign 12 bytes long.
-> Define in JTEncode.h
char callsign[13];
should solve the hypothetical problem.
I read through the code because I had an other problem and searched for all occurences of strcpy, strncpy, ..
I see the following problem with callsign, defined in JTEncode.h: char callsign[12];
We know, compound calls in wspr type2 messages are 12 bytes long: <DL9/DL9SAU>, plus the terminating \0.
JTEncode.cpp does: strncpy(callsign, call, 12); -> No buffer overflow, but the copied 12 bytes long string is not terminated. The operation further down, char slash_avail = strchr(callsign, (int)'/'); may search for '/' beyond end of char[] callsign (if user had a wrong input). Same for char bracket_avail = strchr(callsign, (int)'>');
Fix: I see no reason to keep char callsign 12 bytes long. -> Define in JTEncode.h char callsign[13]; should solve the hypothetical problem.