Packet 255 > 16

[xzfc]

World update

[xzfc]

This recalls the old 16 (Wolrd Update) packet, but the updates part is different.

@mb1969 https://github.com/issy123/agario-protocol/issues/11#issuecomment-219215105

Here is my attempt:

FF
20 00 00 00 // packet length
F0 11 // I dunno No.1
10 // 16 == world update opcode

00 00 // cnt_eats == 0

04 E9 3F E9 // cell_id
99 ED FF FF // x_coordinate
98 07 00 00 // y_coordinate
20 00 08 // I dunno No.2
6E 61 6D 65 31 32 33 00 // null-terminated cell name: 'name123'

00 00 00 00 // cell_id == 0

00 00 // cnt_removals == 0

If y_coordinate does not ends with FF FF, then the next few bytes («I dunno No.2») is screwed up or even missing. I don't get it yet.

[xzfc]

Here is more complex message: http://pastebin.com/raw/4Z0nYjJR

It seems that cell structure have following fields:

• uint32 id
• uint32 x
• uint32 y (if last two bytes is not FF FF, then strange things happens; i.e. some of the fields are missing)
• uint16 radius
• uint8 flags
• uint8 r, g, b
• optional utf8 string name (if flags&4)
• optional utf8 string skin (if flags&8)

[mb1969]

Any news about this?

I'm still looking at the 0xFF header but have no clue? I even saw an 8 byte header.

Whats going on with that packet?

Protocol obfusciation - I don't think so, cause that could be done better Some kind of simple compression - perhaps, would explain your results

Ideas?

[xzfc]

There are interesting research here: https://github.com/OgarProject/Ogar/issues/569

[mb1969]

@xzfc: Looked promising but now it seems that we have to start from scratch

[terjanq]

Good luck, All we tried to do was starting from scratch. Now since data is encrypted you need updating encrypting key and whats more important figure out algorithm for encrypting. I give up.