Protocol 15

[Barbosik]

May be it will be interesting for someone.
Here is the latest protocol 15:

1) Cell Update message 0x10

A little change in the structure of cell update message:

Offset	Value	Type	Description
0	0x10	byte	Cell Update message code
1	xx	uint16	Eat Record Count
3	xx	record list	Eat Records
xx	xx	record list	Cell Update Records. Ends with 4-zero bytes
xx	xx	uint16	Remove Record Count
xx	xx	record list	Remove Records

Structure of Eat Record:

Offset	Type	Description
0	uint32	Hunter Cell Id
4	uint32	Prey Cell Id

Structure of Cell Update Record:

Offset	Value	Type	Description
0	xx	uint32	Cell ID (0x00000000 is used as terminator)
4	xx	int32	Coordinate X
8	xx	int32	Coordinate Y
12	xx	uint16	Cell size
14	xx	byte	Flags
xx	xx	byte	(optional) Extended Flags (Present when bit 7 of Flags is set to 1)
xx	xx	3 byte	(optional) Color (r,g,b components)
xx	xx	string	(optional) Skin name (zero-terminated string)
xx	xx	string	(optional) Cell name (zero-terminated string, UTF8 encoding)
xx	xx	uint32	(optional) PlayerId - it is resent when bit isPlayerIdPresent of Extended Flags is set to 1. It contains pleayer ID (do not confuse with cell ID, this is player ID)

Structure of Remove Record:

Offset	Type	Description
0	uint32	Cell ID (which should be removed)

The Flags:

Bit	Hex Mask	Description
0	0x01	isVirus
1	0x02	isColorPresent (3 bytes with R,G,B components included into update)
2	0x04	isSkinPresent (zero terminated string with skin name included into update)
3	0x08	isNamePresent (zero terminated string with skin name included into update, UTF8 encoding)
4	0x10	isAgitated (if 1 then increases the amplitude of the waves on a blob outline)
5	0x20	isEject (if 1 then this is not a player cell, just W ejected blob)
6	0x40	isEjectEnemy (if 1 then this is W ejected blob, but it's set to 0 for self ejected blobs)
7	0x80	isExtendedFlags (if 1 then Extended Flags field is present)

The Extended Flags:

Bit	Hex Mask	Description
0	0x01	isPellet (if 1 then this is pellet cell)
1	0x02
2	0x04	isPlayerIdPresent (if 1 then PlayerId field is present in the record)
3	0x08
4	0x10
5	0x20
6	0x40
7	0x80

If someone knows some more details, please let me know,
I will update the table.

2) Leaderboard FFA message 0x35

Offset	Value	Type	Description
0	0x35	byte	Leaderboard FFA message code
3	xx	record list	FFA Records

3) Leaderboard FFA teams message 0x36

Offset	Value	Type	Description
0	0x36	byte	Leaderboard FFA message code
1	xx	uint16	?? probably the count of facebook friends
3	xx	record list	FFA Records

The structure of FFA Record is the following:

Offset	Type	Description
0	byte	RecordFlags
xx	utf8 zero string	(optional) Cell Name (present when isNamePresent is set)
xx	uint32	(optional) Player ID (present when isPlayerIdPresent is set)

RecordFlags description:

Bit	Hex Mask	Description
0	0x01	(not used) ?probably isOrderPresent?
1	0x02	(optional) isNamePresent
2	0x04	(optional) isPlayerIdPresent (usually appears with isNamePresent)
3	0x08	(optional) isMe (usually appears without isNamePresent and without isPlayerIdPresent, because it's already known for the client )
4	0x10	(optional) ?probably isFriend?
5	0x20
6	0x40
7	0x80

That's it :)
Please let me know if you know more details.

History:
26.05.2018: updated description for Extended flags and leaderboard RecordFlags description

[Barbosik]

Protocol 16 is rolled out. At a glance there is no significant change with protocol 15.

[NuclearC]

extended flags 0x02 is for friends only
0x04 is used only for logged in players maybe to connect player cells with leaderboard

also for leaderboard record flags:
0x01 = player position right after flags present
0x02 = player name present
0x04 = the player id used to connect cells with leaderboard
0x08 = its me
0x10 = its friend

[Barbosik]

NuclearC, do you know what means packet 5? (from server to the client, it has just one byte 0x05).
All other packets is pretty clear for me. But this one is a real puzzle :)

[NuclearC]

looks like its not always sent, tried to debug in corejs but never got it again :(

[Barbosik]

protocol 17 is released. There are no significant changes.
Just a little change in protocol id and secret key hiding.
Parser for secret key can be easy fixed - just last function in a sequence has been changed for a little.
Parser for protocol id is the same, but some variable names were changed, needs pattern search.

[SuperOP535]

Ok. You should make a repo for this tbh

[issy123]

feel free to do a pull request

[Barbosik]

some info about message list supported by current client implementation.
Client version: 2.11.8
Protocol: 17
Secret: 0x00005274

Full list of supported server to client messages:

0x05 - ?
0x10 - cell update
0x11 - camera update
0x12 - clear full+update cipher key
0x14 - clear
0x20 - owned

0x32 - lb team
0x35 - lb ffa v14
0x36 - lb ffa+fb v14

0x40 - border update
0x55 - captcha request (requires #56 response with captcha result)
0x66 - proto message (serialized requests for shop, xp, etc)
0x67 - got login
0x68 - logout request (requires disconnect)
0x80 - show message "A new Agar.io version is available."
0x82 - ?
0x83 - show message "The server are going to be rebooted in a while"
0xa0 - ?show player direction arrow (not tested deep)
0xa1 - ?hide player direction arrow (not tested deep)
0xe2 - ping (requires #e3 pong response)
0xf0 - ?server restart notification
0xf1 - cipher key
0xff - compressed message (uint32 unpackedSize, LZ4 compressed block)

There are some changes in the client, so it doesn't support private servers. Hope it will be fixed.

[NuclearC]

I don't think anyone is interested in this anymore. There is no point in doing this anymore.

[Barbosik]

it is useful for custom client implementation. I'm using it in my client and it works pretty good.

[SuperOP535]

@Barbosik Did you abandon MultiOgar?

[SuperOP535]

Also, does anyone know the latest protocol version agar.io uses, is it still 17?

[Barbosik]

I'm not interested in MultiOgar anymore, but there are some forks, you can use it.

[Barbosik]

yes, it uses protocol 17 and secret 0x00005274 at this moment.
The message list above is taken from the latest version.
Actually all information required to implement current protocol is available on github.
The small exception is a new procedure to obtain the server.
It uses proto message serializer and request to http://bouncer.agar.io.
It's not big deal to reverse it.

[Barbosik]

I tried to implement private server for the latest client, but it seems they changed something, so it crashes on join command (out of memory). Probably it's due to border size. So, there is need to investigate what is going on. But spectate mode works ok.