identifing packets in wireshark [ ethereal ]

[nitroxs]

- ip (network byte order, opposite to intel). For some reason lua's built-in ipv4 uses inter order (lol?)

ips (or any other type) can be shown in both byte orders. For what I could learn, to show a field in the detailed view a dissector must,

1. Declare (?) the field type by adding it to its fields table. i.e.

Code Select Expand


-- The protocol object construction.
dis = Proto( ... )
-- The field construction
--             ipv4: an AF_INET address
--  short name: this is how you reference the field on wireshark filters
--         caption: this is the first part of the text showed in the detailed view
--             base: base for numeric types
-- value names: descriptive names for numeric values
--                ...  : other parameters i dont remember :P
field = ProtoField.ipv4(short name, caption, base, value names, ...)

-- Add the field to the fields table
dis.fields = { field }


2. Add the field to the tree.

Code Select Expand


-- root is the tree object sent by wireshar to the dissector entry point (dis.dissector)
-- buf is the buffer object sent by wireshar to the dissector entry point (dis.dissector)
-- This adds a field in little endian byte order associated with the given range of the buffer
root:add_le(field, buf(offset, len)
-- This adds a field in little endian byte order associated with the given range of the buffer
root:add_le(field, buf(offset, len))
-- This adds a field in big endian byte order associated with the given range of the buffer
root:add(field, buf(offset, len))


Conclusion: the problem is that dissect_packet function adds every field as little endian because I guessed that wuold be the most frequent order use in the packets and there is yet no way to tell from the packet descriptions what order to use.

- windows (?) file time, used in sid_getfiletime

I tried but I didn't understood the FILETIME structure. It has two DWORDS but no idea what are them. I have to read a bit more.

Stop decoding UDP!
Even war3 uses udptest? lol

I don't know War3 uses UDP for LAN game broadcasting packets.

Wow, you did tcp frames merging?
If many packets in 1 frame, only 1 is decoded.

When many packets are present in a tcp segment multiple "Battle.net Protocol" items should appear in the detailed view (btw. i don't know if i am calling it properly.. it's the panel at the middle of the window between the packet list and the hex dump)

Dont try to decode packets with wrong magic (not 0x01-0x03 or 0xff).

Its marked as a todo

You  need to find another way to handle fragmented packets, dont search for first 0xff.

The way of identifing packets is more or less
1. Read first byte value and display it as "Header Type"
2. Using that value, index the headers_by_type table and call the function
3. If no function is found reject the packet so other dissector can handle it. (Ideally :p) But now it is not rejected, so a bunch of "Header Type"'s appear till an FF value is found... oh oh

I had a weird problem. Syntactically correct dissector hangs wireshark, it freezes and consumes memory until there was nothing left.

I've just find out why that may happen 

printf ....
output strings in ""?

string.format should be like C printf but I don't know if it works exactly like it.

Is it possible to print short hex values (0x10 instead of 0x00000010)? Rounded to whole bytes.

If you want help, show me how to use lua in dissector. How can i display different data types?

It should be possible. When a field is added like shown above a description is automatically generated. But it can be overriden just like with the packet type

Code Select Expand


-- This adds a field in big endian byte order associated with the given range of the buffer.
-- It returns the node added to the tree.
node = root:add(field, buf(offset, len))
-- Lets set the text
-- read the value
value1 = buf(offset, len):uint() -- big endian
value2 = buf(offset, len):le_uint() -- little endian
text = string.format("The field value: %d %d", value1, value2)
node:set_text(text)


In this dissector, reads on the buffer are done through a State object so it can handle TCP segment merging. It has two methods for accessing the buffer

read(number of bytes): reads the requested number of bytes starting from the cursor position ( the state.used field) and advances the cursor
peek(number of bytes): as read but without advancing the cursor

Both return the same object as the corresponding buf(cursor, number of bytes) call.

Btw, what time zone do you have?

My time zone is GMT-3. (argentina)

Please upload my edit so we dont have version conflicts.
Is it generally possible to allow anyone to upload to SVN, but changes need to be commited by admin to appear?

I don't think so... hmm.. I don't know...

But I can add you to the committers list of the project so you can use the svn. I just need your

Instructions:
Specify each project participant by his or her Google Account email address. Each person must have already created a Google Account with that email address.

Separate addresses with commas and/or newlines

For now, I will upload the changes you sent.

[nitroxs]

Is it generally possible to allow anyone to upload to SVN, but changes need to be commited by admin to appear?

Maybe that could be possible with Mercurial but I never used it.

[xpeh]

Plugin is stable and works fine. All are welcome to test.

[Naki-BoT]

Hi,
I have this error:

"Lua: Error during loading:
C:\Program Files\Wireshark\packet-bnetp.lua:14: attempt to index global 'base' (a nil value)"

Windows XP 32bit, Wireshark version 1.2.1 (SVN Rev 29141)

[nitroxs]

Hi,
I have this error:

"Lua: Error during loading:
C:\Program Files\Wireshark\packet-bnetp.lua:14: attempt to index global 'base' (a nil value)"

Windows XP 32bit, Wireshark version 1.2.1 (SVN Rev 29141)

Did you comment out the line "disable_lua = true; do return end;" at init.lua?

[Naki-BoT]

Yes, sure.. and added line: " dofile("packet-bnetp.lua") " - same error with starting wireshark from command line: " -X lua_script:packet-bnetp.lua "

[nitroxs]

Hmm thats strange. init.lua should provide the global base. is it defined in that file?

[xpeh]

Btw,

someone just sucked a delicious dick

http://forum.valhallalegends.com/index.php?topic=17853.msg181898#msg181898

[Naki-BoT]

Hmm thats strange. init.lua should provide the global base. is it defined in that file?

Thanks it works on Windows 7 in home, and start working on XP after computer restart Oo.

[Jailout2000]

2. Add the field to the tree.

Code Select Expand


-- root is the tree object sent by wireshar to the dissector entry point (dis.dissector)
-- buf is the buffer object sent by wireshar to the dissector entry point (dis.dissector)
-- This adds a field in little endian byte order associated with the given range of the buffer
root:add_le(field, buf(offset, len)
-- This adds a field in little endian byte order associated with the given range of the buffer
root:add_le(field, buf(offset, len))
-- This adds a field in big endian byte order associated with the given range of the buffer
root:add(field, buf(offset, len))


Conclusion: the problem is that dissect_packet function adds every field as little endian because I guessed that wuold be the most frequent order use in the packets and there is yet no way to tell from the packet descriptions what order to use.

If bnetdocs is the problem, you can tell me which packets need to be updated. I have full privileges there, including database, so I can change almost anything there. Tell me which packets don't use Little-endian for everything, and I can note it in the description.

[rabbit]

All Battle.net packets use little-endian, so it doesn't matter.

[brew]

All Battle.net packets use little-endian, so it doesn't matter.

This is true. One 'exception' is any packet containing a sockaddr structure, since the port is in network byte order (big endian). It's simply memcpy'd from the packet and is ment to be read as the whole structure, so it's not really an issue.
Oops, I posted without reading the whole thread. What I just said was mentioned already.

[nitroxs]

If bnetdocs is the problem, you can tell me which packets need to be updated. I have full privileges there, including database, so I can change almost anything there. Tell me which packets don't use Little-endian for everything, and I can note it in the description.

I had a hard time trying to understand my own post. I would say I was referring to the way packets are described in the plugin.

bnetdocs is fine. (except for the "Download BNETDocs as Text" feature which is missing a lot of packets)

[Jailout2000]

bnetdocs is fine. (except for the "Download BNETDocs as Text" feature which is missing a lot of packets)

The download BnetDocs as text feature is a caching system.

There is a file on the server that has a last modified date on it, and the generator uses this for caching.

If the file is less than 12 hours old, it gives you the file, if the file is 12 hours or more old, then it'll give you a generated page along with writing to the file (updating it from 12 hours or more old to new). I don't see how this does not contain all of the packets, because I see all the packets in this text that I see on the main page of BnetDocs.

[nitroxs]

I don't see how this does not contain all of the packets, because I see all the packets in this text that I see on the main page of BnetDocs.

Look at this section of the file:

Code Select Expand


C > S [0x3C] SID_CHECKDATAFILE2
**************************************

Used By: Starcraft Shareware, Starcraft Broodwar, Warcraft II, Starcraft, Starcraft Japanese

Format:
(DWORD) File size in bytes
(DWORD) File hash [5]
(STRING) Filename

Remarks:
Verifies that a file is authentic, by producing a hash of that file and sending it to the server for comparison to the
original.

The hash is produced by hashing 64-byte chunks of the file. Each time after the first, the result of the previous hash
is used to initialize for example, "Orc Peon" is 'opeo') (BYTE) Number of ladder records to read; this will be between 0
and 3.   For each ladder record: (DWORD) Ladder type; valid types are 'SOLO', 'TEAM', or 'FFA ' (where the last
character of 'FFA ' is a space, 0x20). (WORD) Number of wins (WORD) Number of losses (BYTE) Level (BYTE) Hours until XP
decay, if applicable* (WORD) Experience (DWORD) Rank (will be 0 if unranked)   (BYTE) Number of race records to read;
this will be 5 for WAR3 and 6 for W3XP. For each race record: (WORD) Wins (WORD) Losses   (BYTE) Number of team records
to read.   For each team record: (DWORD) Type of team; valid types are '2VS2', '3VS3', and '4VS4'. (WORD) Number of wins
(WORD) Number of losses (BYTE) Level (BYTE) Hours until XP decay, if applicable* (WORD) Experience (DWORD) Rank (will be
0 if unranked) (FILETIME) Time of last game played (BYTE) Number of partners (STRING)[] Names of partners   
For subcommand 0x08 (Clan stats request): (DWORD) Cookie (BYTE) Number of ladder records to read; this will be between
0 and 3.   For each ladder record: (DWORD) Ladder type; valid types are 'SOLO', 'TEAM', or 'FFA ' (where the last
character of 'FFA ' is a space, 0x20). (WORD) Number of wins (WORD) Number of losses (BYTE) Level (BYTE) Hours until XP
decay, if applicable* (WORD) Experience (DWORD) Rank (will be 0 if unranked)   (BYTE) Number of race records to read;
this will be 5 for WAR3 and 6 for W3XP.   For each race record: (WORD) Wins (WORD) Losses   

For subcommand 0x09 (Icon list request): (DWORD) Cookie (DWORD) Unknown (BYTE) Tiers (BYTE) Count   For each Icon:
(DWORD) Icon (DWORD) Name (BYTE) Race (WORD) Wins required (BYTE) Unknown   

Remarks:
This message is still being researched!

This message is used for multiple purposes on Warcraft III. Known and validated purposes are listed here.

* The field "Hours until XP decay" is unconfirmed; however, testing numbers correspond to values expected within the
"Days until XP decay" displayed on the live Battle.net ladder website. It is also included but unused (ignored) in the
Clan Stats Request command (0x08).

~~~~~~~~~~~~~~~~

C > S [0x44] SID_WARCRAFTGENERAL
**************************************


Everything between C>S SID_CHECKDATAFILE2 and S>C SID_WARCRAFTGENERAL is not there. You can see part of the  S_WG description merged into S_CDF2 remarks section.