Thread: WinPCap - Packet data containing strings?

I am writing a program that uses winpcap to sniff packets. More specifically, packets from the game "Warcraft III." I have figured out the formatting of the game's chat messages as a test. It looks something like this:

Code:

typedef struct wc3_chat
{
//DWORD id; <-- these are handled in wc3_header.
DWORD event_id;
DWORD flags;
DWORD ping;
DWORD ip;  // defunct
DWORD account_number; // defunct
DWORD reg_auth; //defunct
char* username;
char* text;
}wc3_chat;

Testing in-game, I found that this structure works fine for everything except for the strings which give odd behavior.

Heres some bits from where I'm trying to use the structure:

Code:

const u_char *data = (sniffer.pkt_data + 14 + ip_len + tcp_len + 4);  //4 bytes for wc3_header struct
wc3_chat *chat = (wc3_chat*)data;

if (chat->event_id == 0x05)
     printf("%s: %s\n", &chat->username, &chat->text);

*Edit* The problem is that chat->text doesn't display correctly. Instead of displaying the message, it displays the username minus the first 4 letters. It would appear that chat->text is pointing 4 bytes after wherever chat->username is pointing to instead of pointing after the NULL. See below for more information and a sample packet capture from Wireshark.

Can anyone help me figure out what I'm doing wrong here?

Thanks,
Glorfindel

It looks like you are trying to skip parts of the packet that are irrelevant to you, which makes sense. However, if you are not getting the results you want, the first thing to try would be printing the entire packet, then print the entire packet "organized" in some way (including "irrelevant" fields) and then decide where the problem occurs. That might mean converting some ints, etc, so that you can make sense of the entire packet. If you can do that, then you won't be having this difficulty.

"baadf00d" is one of many "funny" things you can make with hex-numbers, and quite often used to indicate "don't use this" [particularly, if you set a pointer to that value, you know it's going to "explode" if you ever try to use that pointer, and it's not a NULL pointer].

--
Mats

Originally Posted by Glorfindel

What is happening is actually that chat->text is always pointing 4 bytes after wherever chat->username is pointing, which causes text to always display the username minus the first 4 letters. The screenshot I posted was actually the result of me trying to add some placeholder variables between the username and text in the structure. I forgot to remove it before I ran the program for the screenshot. The times that the thing displayed correctly or almost correctly were simply whenever the user had a short name.

I have absolutely no idea why that would happen... shouldn't it be pointing to the end of the string preceding it?

Probably because of this:

Code:

char* username;
char* text;
}wc3_chat;

username is a char pointer, so it takes up four bytes. "text" will have a variable offset.
If the real username in the packet ends at the first period, you can count the characters up to there and use that as the offset for the text -- using char *text from the struct will be useless.

I'd say either use a fixed size buffer for text and user-name, or allocate sufficient memory for them. You need to copy each byte out, so you could use strlen() to figure out the length, and then strcpy() to copy it. If you allocate memory, don't forget to add one for the zero at the end of the string.

--
Mats

Originally Posted by Glorfindel

Thanks to someone from #winprog on EFNet, I've remembered that char* doesn't reserve any actual memory space for the string, but only enough to store the memory address to which it points. (seemingly 4-bytes). That being said, it appears that this method will not work to parse the packet data.

A char* is 4 bytes long (on most systems), and it is four bytes long in the struct. It would be wrong to say that a pointer has no size.

Obviously you can use this method to find the beginning of username. Since username has a variable length the only way to proceed from there is to use a method which deals with this for each individual struct, which shouldn't be very hard.

An even easier way would be to take all the data starting at "username" and break it at the 00 byte (which appears as a period in wireshark).

Code:

0040  00 00 1f 00 00 00 00 00  00 00 0d f0 ad ba 0d f0   ........ ........
0050  ad ba 54 73 29 72 65 63  72 75 69 74 40 55 53 45   ..Ts)rec ruit@USE
0060  61 73 74 00 43 6c 61 6e  20 54 72 61 6e 73 63 65   ast.Clan  Transce

Remember '\0' is a line terminator. That's it.

Originally Posted by matsp

I'd say either use a fixed size buffer for text and user-name, or allocate sufficient memory for them. You need to copy each byte out, so you could use strlen() to figure out the length, and then strcpy() to copy it. If you allocate memory, don't forget to add one for the zero at the end of the string.

--
Mats

strlen will indeed work well since it counts up to a null terminator. So that will give you the offset.

Originally Posted by carrotcake1029

Instead of throwing your data straight into the struct, you are going to want to analyze the packet piece by piece. Since you know the first 6 pieces are DWORDs, you know that the size is static and it is safe to read into it. When you have null terminated strings, you need to have a function basically loop through the remaining chars until it hits a null value, allocate however many characters you stepped over (plus one for the null terminator), and then you copy it over. I guess you could have memcpy do this....

strlen() and strcpy() will do that perfectly fine. But memcpy() with known size may be a tiny bit faster [as strcpy() is often implemented as

Code:

char *strcpy(char *dest, char *src)
{
     size_t len = strlen(src);
     return memcpy(dest, src, len);
}

If you have already done strlen(), you don't need to do it again to copy the content. But strcpy() is a more obvious choice if performance isn't super-critical.

--
Mats