SWG Packets - Revision history

Snow: /* COMMON SWG DATA TYPES */

2006-12-24T08:45:54Z

‎COMMON SWG DATA TYPES

Snow at 07:35, 21 December 2006

2006-12-21T07:35:02Z

Snow at 07:34, 21 December 2006

2006-12-21T07:34:51Z

Snow at 07:32, 21 December 2006

2006-12-21T07:32:23Z

New page

SWG Packets are the actual packets of data that are within the SOE Protocol. They follow a general trend, and then have
their own specific breakdowns as to what data is where.

All SWG Packets consist of an opperand count, and an opcode. An opcode is a number to help identify what type of data the packet
contains, and the opperand count is to know how many variables are within the packet. The format is as follows:

[Opperand Count:Host Byte SHORT]
[Opcode:INT]
[DATA...]

Opcodes appear as very large integer, and there is no pattern between them, so
we recognize them as just an INT data type that is 4 bytes in size.

MULTIPLE SWG PACKETS

There is a special case within an SWG Packet which allows multiple SWG Packets to be combined into one. This can be identified
when there is an opperand count of 0x0019 (in a packet, you would see 00 19 versues 02 00 or some other host byte number that is a count).
The format then follows the same as the Multiple SOE Protocols Opcode.

[special opperand count of 00 19]

[Size1:Byte]
[Data1..]

[Size2:Byte]
[Data2..]

[Repeat..]

Again, if the packet must exceed 255, the same format is used as the SOE Multiple Protocols opcode.
The first byte is FF for 255, the next byte is how many bytes to add to that value (so 01) and the byte after that is the
actual number to add.

so 256 would appear as FF 01 01 or FF + 01 or 255 + 1.
265 would appear as FF 01 0A or FF + 0A or 255 + 10.

Because no packet can exceed 496 bytes (because that is the set buffer), at most 1 byte will be
added to 255, so FF 01 __ is the general format for every byte 255 and above.

NOTE: As stated in the SOE Protocol documentation, we have not seen a case for a size of 255.
There are a few ways that this MAY be done, but we believe FF 01 00 is the correct method, where FF + 00 or 255 + 0 is computed.

COMMON SWG DATA TYPES

The following data types are what commonly appear in SWG packets, and each count as 1 opperand.
Note: (HB) is short for (Host Byte) (NB) is short for (Net Byte). This is assumed throughout the rest of the packet documentation.

BYTE (a 1 byte integer number)
(HB)SHORT (a 2 byte integer number)
(HB)INT (a 4 byte integer number)
(HB)LONG (an 8 byte integer number)
(NB)FLOAT (a 4 byte floating point number)
A_STRING (an ASCII string)
U_STRING (a UNICODE string)

Note:
There are a few other ways an "opperand" can be counted. Lists that have a counter preceeding them is
also a common "opperand". So seeing something like this:

04 00 00 00 (HB)INT - a counter for some list
DATA1..
DATA2..
DATA3..
DATA4..

that would all count as a single opperand.
Opperand counting really helps when reversing a packet as you know how many data peices to break it into.
There is no real use to them beyond that. Also opperands will be marked in the packet breakdowns if needed.
They are more a reversing tool for the packet analyzer than neccesary in the server.

ASCII STRINGS

A_STRING data types have the following format. Instead of being null terminated, the string size
preceeds the data as a (HB)SHORT. So the string "ABC" in binary would be:

"ABC"
03 00 65 66 67

where 03 00 is the integer number 3, and each byte is a character of the string.

UNICODE STRINGS

U_STRING follow the same format as A_STRING, however, there are 2 bytes to each character,
instead of 1 like in Ascii. Each unicode character is represented as a (HB)SHORT so "ABC" as a U_STRING would be:

"ABC"
03 00 65 00 66 00 67 00

where 03 00 is the size, and each following (HB)SHORT is a character of the string.

@@ Line 44: / Line 44: @@
 ==COMMON SWG DATA TYPES==
-The following data types are what commonly appear in SWG packets, and each count as 1 opperand.
+The following data types are what commonly appear in SWG packets, and each count as 1 operand.
 Note: (HB) is short for (Host Byte) (NB) is short for (Net Byte). This is assumed throughout the rest of the packet documentation.
@@ Line 57: / Line 57: @@
 </pre>
-'''Note''':
+'''Note''': <font color=orange>''There are a few other ways an "operand" can be counted. Lists that have a counter preceding them is also a common "operand". So seeing something like this:''</font>
-There are a few other ways an "opperand" can be counted. Lists that have a counter preceeding them is also a common "opperand". So seeing something like this:
 <pre>
 00 00 00 (HB)INT - a counter for some list
@@ Line 67: / Line 67: @@
 </pre>
-that would all count as a single opperand.
+that would all count as a single operand.
-Opperand counting really helps when reversing a packet as you know how many data peices to break it into. There is no real use to them beyond that. Also opperands will be marked in the packet breakdowns if needed. They are more a reversing tool for the packet analyzer than neccesary in the server.
+Operand counting really helps when reversing a packet as you know how many data pieces to break it into. There is no real use to them beyond that. Also operands will be marked in the packet breakdowns if needed. They are more a reversing tool for the packet analyzer than necessary in the server.
 ==ASCII STRINGS==

← Older revision		Revision as of 07:35, 21 December 2006
Line 1:		Line 1:
		+	__NOTOC__
		+
	SWG Packets are the actual packets of data that are within the SOE Protocol. They follow a general trend, and then have		SWG Packets are the actual packets of data that are within the SOE Protocol. They follow a general trend, and then have
	their own specific breakdowns as to what data is where.		their own specific breakdowns as to what data is where.

@@ Line 2: / Line 2: @@
 their own specific breakdowns as to what data is where.
-All SWG Packets consist of an opperand count, and an opcode. An opcode is a number to help identify what type of data the packet
+All SWG Packets consist of an opperand count, and an opcode. An opcode is a number to help identify what type of data the packet contains, and the opperand count is to know how many variables are within the packet. The format is as follows:
 contains, and the opperand count is to know how many variables are within the packet. The format is as follows:
 [Opperand Count:Host Byte SHORT]
 [Opcode:INT]
 [DATA...]
-Opcodes appear as very large integer, and there is no pattern between them, so
+Opcodes appear as very large integer, and there is no pattern between them, so we recognize them as just an INT data type that is 4 bytes in size.
 we recognize them as just an INT data type that is 4 bytes in size.
+==MULTIPLE SWG PACKETS==
-−
 MULTIPLE SWG PACKETS
 There is a special case within an SWG Packet which allows multiple SWG Packets to be combined into one. This can be identified
 when there is an opperand count of 0x0019 (in a packet, you would see 00 19 versues 02 00 or some other host byte number that is a count).
 [special opperand count of 00 19]
@@ Line 30: / Line 29: @@
 [Repeat..]
+</pre>
-Again, if the packet must exceed 255, the same format is used as the SOE Multiple Protocols opcode.
+Again, if the packet must exceed 255, the same format is used as the SOE Multiple Protocols opcode. The first byte is FF for 255, the next byte is how many bytes to add to that value (so 01) and the byte after that is the actual number to add.
-The first byte is FF for 255, the next byte is how many bytes to add to that value (so 01) and the byte after that is the
+<pre>
 actual number to add.
-−
 so 256 would appear as FF 01 01 or FF + 01 or 255 + 1.
 would appear as FF 01 0A or FF + 0A or 255 + 10.
+</pre>
-Because no packet can exceed 496 bytes (because that is the set buffer), at most 1 byte will be
+Because no packet can exceed 496 bytes (because that is the set buffer), at most 1 byte will be added to 255, so FF 01 __ is the general format for every byte 255 and above.
 added to 255, so FF 01 __ is the general format for every byte 255 and above.
 NOTE: As stated in the SOE Protocol documentation, we have not seen a case for a size of 255.
 There are a few ways that this MAY be done, but we believe FF 01 00 is the correct method, where FF + 00 or 255 + 0 is computed.
+==COMMON SWG DATA TYPES==
-−
 COMMON SWG DATA TYPES
 The following data types are what commonly appear in SWG packets, and each count as 1 opperand.
 Note: (HB) is short for (Host Byte) (NB) is short for (Net Byte). This is assumed throughout the rest of the packet documentation.
+<pre>
 BYTE			(a 1 byte integer number)
 (HB)SHORT		(a 2 byte integer number)
@@ Line 59: / Line 53: @@
 A_STRING		(an ASCII string)
 U_STRING		(a UNICODE string)
-Note:
+'''Note''':
-There are a few other ways an "opperand" can be counted. Lists that have a counter preceeding them is
+There are a few other ways an "opperand" can be counted. Lists that have a counter preceeding them is also a common "opperand". So seeing something like this:
- also a common "opperand". So seeing something like this:
+<pre>
-−
 00 00 00 (HB)INT - a counter for some list
 DATA1..
@@ Line 69: / Line 63: @@
 DATA3..
 DATA4..
 that would all count as a single opperand.
+==ASCII STRINGS==
 ASCII STRINGS
 A_STRING data types have the following format. Instead of being null terminated, the string size
 preceeds the data as a (HB)SHORT. So the string "ABC" in binary would be:
+<pre>
 "ABC"
 00 65 66 67
+</pre>
-−
 where 03 00 is the integer number 3, and each byte is a character of the string.
 U_STRING follow the same format as A_STRING, however, there are 2 bytes to each character, instead of 1 like in Ascii. Each unicode character is represented as a (HB)SHORT so "ABC" as a U_STRING would be:
-UNICODE STRINGS
+<pre>
-−
 U_STRING follow the same format as A_STRING, however, there are 2 bytes to each character,
 instead of 1 like in Ascii. Each unicode character is represented as a (HB)SHORT so "ABC" as a U_STRING would be:
-−
 "ABC"
 00 65 00 66 00 67 00
+</pre>
 where 03 00 is the size, and each following (HB)SHORT is a character of the string.