-
Notifications
You must be signed in to change notification settings - Fork 44
Packets
header
| Header | Article | Type | Name | Description |
| 0x00 | - | <-> | HandShake | Server handshake |
| 0x09 | - | C2S | Sell item. uint8 xy x is flag (8=normal, 0=recipe combine) y is inventory slot (always zero-indexed) | |
| 0x0B | - | S2C | Sell item response. uint8 inventory slot, uint8 quantity remaining | |
| 0x17 | - | C2S | QueryStatusReq | Query status request |
| 0x18 | - | S2C | SkillUp | Set skill level. uint8 zero-indexed skill, uint8 skill level, 00 |
| 0x19 | - | C2S | PingLoadInfo | Client loading progress |
| 0x23 | - | C2S | Move inventory item. uint8 from inventory slot, uint8 to inventory slot | |
| 0x2C | - | S2C | MasteryInfo | All mastery information |
| 0x3E | - | C2S | SkillUp | Put a point into an ability. uint8 zero-indexed ability (q=0, w=1, etc) |
| 0x23 | - | S2C | Move inventory item response. uint8 from inventory slot, uint8 to inventory slot | |
| 0x4C | - | S2C | - | Game announcement |
| 0x58 | - | C2S | StartGame | The client is ready to start the game |
| 0x5A | - | S2C | SynchVersion | An initial packet containing structs and what not, real purpose not defined yet |
| 0x64 | - | C2S | ClientReady | Client ready to continue |
| 0x65 | - | S2C | LoadHero | The hero info |
| 0x66 | - | S2C | LoadName | The summoners info |
| 0x67 | - | S2C | LoadScreenInfo | The loading screen information |
| 0x67 | Movement | S2C | MoveAns | The movement answer packet with the adjusted path |
| 0x75 | - | S2C | Buy item response. uint16 item id, 00 00, uint8 inventory slot, uint8 quantity, uint8 unknown | |
| 0x78 | Movement | C2S | MoveReq | The movement request packet with the complete path |
| 0x7D | Movement | C2S | MoveConfirm | Confirmation of the MoveAns packet |
| 0x89 | - | C2S | ReqBuyItem | Buy item. uint16 item id, 00 00 |
| 0x8F | - | S2C | QueryStatusAns | Query status answer |
| 0x9A | - | S2C | SendGameNumber | Send game number and summoners name |
| 0x9F | - | S2C | PingLoadInfo | Loading progress for a player |
| 0xAE | - | C2S | Surrender | Surrender request |
| 0xAF | - | S2C | Surrender response | |
| 0xA6 | - | C2S | GameNumberReq | Request game number and summoners name |
| 0xA6 | - | C2S | GameNumberReq | Request game number and summoners name |
| 0xB2 | - | C2S | ConfirmStats | Confirms the received stat change |
| 0xBB | - | C2S | Click | Mouse click |
| 0xC9 | - | C2S | SynchVersion | Client version and some other client information |
| 0xD0 | Stats | S2C | StatUpdate | Setting the stats for objects |
| 0xFF | - | S2C | Batch | Batch packet |
List updated for client 0.0.0.142 A list of headers can also been found in common.h
All packets in LoL start with a common header. This header is 5 bytes in size and has the following layout:
| Type | Name | Description |
| uint8 | cmd | denotes the type (id) of the packet |
| uint32 | netId | Id of the ingame-object to modify, every object has an unique id which is used to refer to it. For example, your champion appears to be 19 00 00 40 |
The size of normal packets is either constant/depending on the packet type or given within the packet.
Some packet that get send from server -> client are send with a tick counter and have overlapping cmd’s. We call these game packets and there header is like
| Type | Name | Description |
| uint8 | cmd | denotes the type (id) of the packet |
| uint32 | netId | Id of the ingame-object to modify, every object has an unique id which is used to refer to it |
| uint32 | ticks | An clock tick for the server (probably) and increasing counter with 1 should work fine to o. Appears to be 100 ticks per second. |
Batch packets always have first byte to 0xFF
| Type | Name | Description |
| uint8 | cmd | always 0xFF |
| uint8 | packetNo | The total amount of packets this batch contains |
| uint8 | firstSize | The size of the first packet |
See batch packets body for parsing the rest of the batch
The header is then followed by packet data with its size depending on the packet type. The channel to send the packet from also depends on its type. Note that batch packets are different.
The same story as normal packets
The rest of the batch is parsed differently. After the firstSize packet:
| Type | Name | Description |
| uint8 | lengthAndFlags | This contains the length (retrieve it by shift right 2) and 2 flags |
| uint8 | unk1 | If first bit of lengthAndFlags is 0, else this byte is not present |
| uint8 | unk2 | If second bit of lengthAndFlags is 0, else this byte is not present |
| uint32 | unkt2 | If second bit of lengthAndFlags is 1, else these bytes are not present |
| uint8 | length | If lengthAndFlags>>2 == 0x3F then the real length is this byte, else this byte is not present |
| uint8 | body[lengthAndFlags>>2] | the body of the packet |
Repeat this until you have parsed packetNo times (but always check for overflow)
…to be continued.