Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I found the canonical name for every packet type #52

Closed
chrivers opened this issue Sep 14, 2016 · 9 comments
Closed

I found the canonical name for every packet type #52

chrivers opened this issue Sep 14, 2016 · 9 comments

Comments

@chrivers
Copy link
Member

Going with @IvanSanchez's idea, I was able to build an intelligent brute-forcing script to search strings and substrings for matching hashes. The results can be seen below. These matches are quite obviously not random :)

0351a5ac: valueFloat
077e9f3c: shipSystemSync
19c6e2d4: clientConsoles
26faacb9: gmButton
3de66711: startGame
4c821d3c: valueInt
574c4c4b: commsMessage
69cc01d9: valueFourInts
6aadc57f: controlMessage
6d04b3da: plainTextGreeting
80803df9: objectBitStream
809305a7: gmText
9ad1f23b: carrierRecord
ae88e058: incomingMessage
b83fd2c4: attack
c2bee72e: beamRequest
cc5a3e30: objectDelete
d672c35f: commText
e548e74a: connected
ee665279: objectText
f5821226: heartbeat
f754c8fe: simpleEvent

To me, this explains quite a few things! For example, why are the major types sometimes related in terms of function, and sometimes not at all? For example, 0x0351a5ac covers both Helm, Eng and Game Master. Now we know it's simply because of convenience, since 0x0351a5ac is a packet with a single float. This also tells us that we can always expect 0x0351a5ac to have a single float, unless the name is incredibly misleading ;-)

My personal favorite: Packet f5821226, which we suspected to be a heartbeat packet, is now known for sure to be a heartbeat packet. Also, packets like "valueInt" and "valueFourInts" tell us quite a great deal about the expected format, and how unlikely it is to change in the future.

To be honest, I like the existing names better than these ones, but it's certainly very interesting to have found the source of the packet IDs :)

@rjwut
Copy link
Member

rjwut commented Sep 14, 2016

So I definitely think that this information needs to be in the documentation. The question is: should we replace the existing packet names with these, or should we simply add this to the existing packet information?

@IvanSanchez
Copy link
Member

Heh, valueFloat and valueFourInts, I never expected that :-D

Personally, I'd replace the existing packet names with these, while keeping the current name in a smaller font.

@chrivers
Copy link
Member Author

Actually, this kind of relates to the big question, ticket #50.

The problem is, the current documentation contains a list of "Logical Packets", whereas this is a list of "Real Packets" (the major types only). Previously, we haven't had any real mention of the major types by themselves. Only recently, when we sorted the packet list, did it become clearer that there are groupings of packets.

I'm hoping we can, in #50, include a simple description of the parser (0xaabbccdd => such-and-suchtype, etc) which would mean we could use those names there. But personally, I think they should be of secondary importance in the documentation.

@rjwut
Copy link
Member

rjwut commented Sep 14, 2016

I agree that there is a mismatch: our names are applied to subtypes, whereas these names only exist at the major packet type level. Personally, I think the packet names we have now are better, since they're more useful to the code that ultimately consumes this information. HelmRequestDockPacket is more meaningful than valueInt:0x07.

@chrivers
Copy link
Member Author

I think it be very helpful to show a simple 2-level parsing hierarchy, for the sake of overview. Something that looks like a set of nested switch statements. That could use these names, for clarity. I'll whip up an example when I get home

@JordanLongstaff
Copy link
Contributor

I can confirm that packet 0xf5821226 appears to be a heartbeat packet. What's currently stopping anyone from giving it a name in the docs?

@NoseyNick
Copy link
Collaborator

v2.6.0 has a packet type 0x902f0b1a. I've seen exactly ONE of them, server to client. Don't suppose your magical brute-forcing script can reverse-engineer that one? Happened approx 2.5mins into a 5-minute game, no idea who/what triggered it, might be some new-ish variation of a gmText? We DID have a GM in that game (clientConsoles packet tells me so).

1a0b2f902d000000570065006c0063006f006d006500200074006f002000740068006500200041007200740065006d0069007300000065006500650065006500650065006500650065006500650065006500650065006500650065006500650000000300000020000000000003000000200000000000 # 2.6.0 payload

Purely speculative guesses:
1a0b2f90 = packet type 0x902f0b1a
2d000000 = int 45, PROBABLY a string length, because if so...
570065006c0063006f006d006500200074006f002000740068006500200041007200740065006d006900730000006500650065006500650065006500650065006500650065006500650065006500650065006500650065000000 = "Welcome to the Artemis\0eeeeeeeeeeeeeeeeeeeee\0"
What follows might be a series of shorts (3,0,32,0,0,3,0,32,0,0) or 2 strings, both [len=3]"[space]\0\0"

@NoseyNick
Copy link
Collaborator

Update: 0x902f0b1a == JamCRC("bigMess") 🤣

@rjwut
Copy link
Member

rjwut commented Dec 15, 2017

Fixed by #82

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants