[question] UT packet formats

[blackalien62]

Hi all,
I'm looking for any documentation on AAO or Unreal Tournament UDP packet formats. In particular I'd like to know what player location packets look like and where their x,y,z coordinates are. I found a little info googling last night but not a lot. I'm hoping you guys that made the radars can help a bit. Did you do that with packet sniffing or an engine hook?

If nobody has info, could you post a few suggestions on what I need to do to figure them out? I've got a packetsniffer and know how to use it. I'm guessing connect to a locked server so I only see my player packets, spin around in place so only the heading(?) vector changes. Then maybe move due North or East to see how the x & y's change. Will these be integer or real values?

Thanks in advance
a new hacker/coder wannabe

[DelfinoM]

I have no idea but you look into the Evil hack mdofication thread, there should be an radar tutorial, which i dont think uses packets but an better way, cause packets always change.

[blackalien62]

True, but if I can get packets, I will be 100% undetectable. Forever. period.

[Picklelicious]

Making a UT packet sniffer is not easy. That is why you do not see many proxy hacks for the UT engine. The UT protocol is a bit stream, so nothing is aligned on byte boundaries.

In AAO, there are three types of channels that the UT protocol can set up – command, file, and actor. The command channel handles sending information about the game and joining that game. For example, when you first connect to a server, the server will send you a lot of packets describing all the UT package files you need to play on that server. When you have everything you need you send the server a JOIN command and it will spawn a player controller for you and then replicate all the actors to you.

The file channel handle transferring files from the server to the client. Although AAO does not do this, I am sure you have probably joined a server and then watched as you machine download UT Packages from the server. All that happens on the file channels.

The actor channels are the ones you are interested in. An actor is any object in the game (players, weapons, trucks, tents…). Each actor has its own channel. All the variable and function replication for that actor is transferred using the actor’s channel.

The UT protocol uses UDP. All the data that needs to be sent is packed into a buffer. Once all the data is put into the buffer (or the buffer reaches the maximum UDP packet size), the buffer is sent. The protocol is a bit stream.

First Bit:
0 – A Bunch Packet Follows
1 – An Ack Packet Follows

Ack Packet:
14 bits – Contains the Sequence number and 4 other bits.

Bunch Packets:
1 bit – Create/destroy present flag.
1 bit – Create flag.
1 bit – Destroy flag.
1 bit – Sequence number present flag
10 bits – Channel number.
10 bits – Sequence number
3 bits – Channel type
12 bits – Data length.
xx bits – Data

If the create/destroy present flag is 1, then both the create/destroy flags will be present.

If the Create flag is 1, then this is a new channel. The data will have all the information to initialize the channel.

If the Destroy flag is 1, then this channel is being destroyed.

If the Sequence number present flag is 1, then the Sequence number will be present.

Channel number lets you know what channel the data is for.

Sequence number is used for reliable data. UT can send data reliably (meaning it is guaranteed to get to the other side) or unreliably (meaning that it might get lost and not make it to the other side). The Ack packets are used for reliable channels.

Channel type is only present if Create flag is present and is a 1 and a Sequence number is present. Basically, when a channel is created, this lets you know what type of channel it is. There is a table in the engine that defines the channel types. I think it was:
0 – Command Channel
1 – File Channel
2 – Actor Channel

Here is an example of how it works. Let’s say you are running around and you get close to another player, the server will know that the other player is relevant to you and will start replicating that player’s pawn to you. So your machine will receive a bunch packet with the creation flag set and all the initial data for the pawn (location, animation, health…). Let’s say this came on channel number 43. The engine will then create a pawn on the client machine with all that initial data. It will remember that channel 43 is for the new pawn so that when more data comes down channel 43, it will know where it is suppose to go.

The data is even more complicated. The data will contain variables (like the location) and function calls (which can end up modifying the location). But the formatting of that data is dependent upon what type of actor the channel is for. For example, if the channel is for a player pawn, then maybe first 9 bits of the packet would indicate if the data was a variable or a function. If the channel is for a 203 round, then maybe only the first 5 bits of the packet would indicate if the data was a variable or a function.

So when data is received, you use the channel number to find out which actor it is for. Then you look up the actor’s class and call a function that tells you how many bits to read. You read in that many bits. You then call another engine function with that value and it tells you which function to call to process the data. You then pass the rest of the data to that function and it will process the data.

[megawhey]

Nice post man

[gil]

Picklelicious, i read it all tho i have no clue about UT engine or anything related and i found it very interesting.

Thank you for sharing info with us.

[blackalien62]

Yeah, thanks. That really gave me something to think about. If I do this the way I wanna, my problem is I'm not going to have the engine available. I'll have to decode the bit stream myself. I don't have to worry about slowing down frame rates, just keeping up with the packets, so I ought to have ample processing power. Right now I'd be happy with knowing what team the player is on and his x,y,z. Might be nice later to get the player name and weapons, but I'll save that for version 2.

A few questions about the player channels. Once your client starts receiving data on player A on channel 43 - will player A always be on channel 43 even if he becomes irrelevent to my player? At least until the round is over? Anymore decode info on the data portion or a pointer to where to look?

Thanks man, hellava post.

[temp2]

Interesting.

[Picklelicious]

@blackalien62:
The information you are interested in is stored in two different objects. The UT engine makes a distinction between a player (the person sitting at the keyboard) and their pawn (the thing you see on the screen). Doing it this way makes a lot of sense because the player still exists (spectating) even when their pawn does not (it is dead and no longer exist in the engine).

Most things about the player (like their name, and the team they are on) are stored in an APlayerReplicationInfo object. This object always exists whenever a player is connected to a server. Most things about the pawn (where it is, how it looks, how healthy it is) is stored in the pawn (which is of type AAGP_Character).

To get the weapons their pawn is carrying is more complicated that you might think. UT makes a distinction between a weapon that is laying on the ground (a pickup), a weapon that someone is carrying (an attachment), and a weapon that your pawn can actually fire (a weapon). To tell what weapons other players are carrying you have to watch the ABaseWeaponAttachment objects. Each BWA has a field that tells you who it is attached to.

I think the channels get reused (so 43 might be a pawn now and 30 seconds from now might be a weapon pickup). The APlayerReplicationInfo obects will probably keep their channel numbers (because they are always relevant), but doubt their pawns will.

The classes the engine uses are FBitReader/FBitWriter to read/write bits to a buffer. FInBunch/FOutBunch to read/write bunches to buffers. UChannel to process the bunches. UNetChannel to actually send/recv data on the network. UPackageMap and FClassNetCache handle converting indexes into their corresponding variables/functions. And there are Serialize functions everywhere that converts objects to a bunch. FArchive is what glues it all together (an FArchive object get passed as a parameter to many of the functions).

[temp2]

Just to add the icing to Picklelicious' cake; the data in packets is compressed using the FCodec data compression sub classes. Check out the 432 headers to see.

[blackalien62]

Just to add the icing to Picklelicious' cake; the data in packets is compressed using the FCodec data compression sub classes. Check out the 432 headers to see.

I'm not a C++ programmer, so where are these 432 headers you are speaking of?

[temp2]

I'm not a C++ programmer, so where are these 432 headers you are speaking of?

You will need to be a c++ programmer to make any decent headway. Google ut432pubsrc.zip if http://unreal.epicgames.com/Downloads.htm does not satisfy. I doubt any radar uses packet sniffing given that an ObjectIterator on Pawns looking at their Location and team is so easy...

[blackalien62]

Thanks, I appreciate where to look for it. And I might have given the wrong impression - I'm not a C++ programmer, I'm a Delphi programmer. I hate the C++ syntax. So off I go to find those headers.

[blackalien62]

Thanks, I appreciate where to look for it. And I might have given the wrong impression - I'm not a C++ programmer, I'm a Delphi programmer. I hate the C++ syntax. So off I go to find those headers.

ok, first major problem. I can't get winpcap (packet sniffer driver) to work with Borland Delphi. Any suggestions? FAQ says you could change the .lib files to work with C++builder. And I'd rather find a driver that worked with Delphi than to switch to C++

****edit
Nevermind, I forgot I knew how to use google. But if anybody has boland code using winpcap, I'd love to see it.

****edit 2
FREE would be nice.