Server to Client Communication
Opened this issue · 15 comments
We have only touched the surface in terms of parsing clientbound communication, and this project will not truly be complete without that. Here, we can discuss our progress on deciphering that facet of the protocol and on de-obfuscating d.js like in #7.
Why is there a d.js.mem file?
I found a link to that file lurking in the d.js code, and it appears to be a binary file containing some pre-Emiscripten code and a syntax error. It might be useful later. The developers used Emiscripten to convert their C++ client code to Javascript, then to optimized asm.js (a subset of JS meant to execute very quickly).
It seems that packets sent by the server that have a first 8-bit sequence of 0 might have some purpose. The second 8-bit seems to go from 128 to 255, then go back to 128, where it does this over and over. The third sequence seems to stay as the same number until the second sequence "resets" to 130, when this happens, the third sequence seems to "refresh" and change to a different number.
The third sequence might be something like the player count?
The player count is handled separately by a regular GET/POST request (you can see that in the Network pane in the console).
Progress!
I've managed to decipher some of the leaderboard packets sent by the server, and have updated the extension and wiki accordingly. (791423b)
I'm gonna use Wireshark to look at server-to-client packets more closely. So far, the only thing I've found out is that the server seems to send your name back to you after you join the game, and it is always sent in a packet starting with 2.
Why use Wireshark? Just use the chrome extension. You can even modify
packets en-route, both server to client and client to server.
We might need more than three people working on this project. Do you know anyone else who could help?
I suspect some of the devs who contributed to agar.io or slither.io projects could be persuaded to help. I'll reach out to them, see if we can get a few on board.
I'll see if I can call some of the "tech nerds" in my class. In fact, they're probably reading this right now.
The server-to-client packets starting with 0 are not only counters, they also seem to send the server uptime, although this still requires verification. I'll look into that.
I think it might be a good idea to start building an API for reading and managing communications to and from the game. The extension is good, but we, and other people, might want to integrate this project into something.
All I figured out is that packet [2, x] doesn't update current game, but it creates leaderboard and new objects in game, so i guess packet [0, x] updates what packet [2, x] created.