Section 1. Foreword
Disclaimer #1: This is in no way a violation of the Game Abuse Policy. I am not hacking nor cracking, nor am I encouraging these activities. I was simply curious as to how the DN client handled networking, as this information can be used to better understand various in-game phenomena and such, and help us understand how private / secure communications are between client and server.
Disclaimer #2: I filtered out all TCP packets that contain no data. Thus, when I say, for instance, "I received no TCP packets", it means that I received no TCP packets with data in them.
Disclaimer #3: The game server IPs will most likely be different depending on your character's server. I am from HW/SW, so keep that in mind.
Disclaimer #4: I use the term "packet header" and "packet identifier code" almost interchangeably. The latter refers strictly to the first three bytes of data in a packet, and the former referring to the same thing with or without including several bytes afterwards, however much constitutes the "packet header". I am not referring to the TCP packet header when I say "packet header".
I do not intend for there to be serious discussion nor replies to this thread. These are just some of my findings. I will update these list of findings should I find something interesting, however understand that studying packets from a client whose source code you don't even know isn't necessarily the most entertaining thing to do, for me at least. If I have the urge to do it, I will. Otherwise, I will not. Without further ado:
Section 2. The Findings
1) This game is dual TCP/UDP. In town, it is entirely TCP. Upon entering a combat / instanced zone (e.g. GTS), I start to receive UDP packets, however the TCP packets still pour in. I believe these TCP packets are mostly chat (general chat, world chat, world notices) packets. It's a bit of an interesting find as I am also using a dual TCP/UDP setup for Project S, with the TCP connection handling the chat mostly.
2) TCP packets are sent to and received from "126.96.36.199". UDP packets are sent to and received from "188.8.131.52". Thus, if you wish to do your own DN SEA packet capture using Wireshark, I suggest you use the filter (ip.host matches "203\.116\.155").
3) (A criticism) I shouted the exact same chat message multiple times, yet the packet data was exactly the same. Assuming DN implements TLS (preferably with AES-128/256), this signals the lack of an IV. In layman terms, an IV basically makes encrypting two identical packets produce different results. Without it, an attacker (packet sniffer, what have you) is able to know that you sent two identical packets to the server (even though he may not be able to read the message contents themselves), which compromises your chat privacy to a certain extent. (If you want a longer post about IVs (since I don't have all day to write about basic cryptography), this answer seems to explain it rather well. This is just from a quick Google search and glance-through, though).
4) (Also a[n even bigger] criticism) The TCP packets - the chat ones at least - seem to lack a MAC. Literally, I sent out chat messages going "5 4 3 2 1 0", with each message containing only one number, and the only thing that was different in each message packet was the second-to-last byte. This is very much an appropriate time for the Jean Luc Picard face palm meme. A MAC is something that you add to a packet in order for the receiver of the packet to verify that its contents have not been altered by an attacker. A MAC is generated in part by the actual packet contents, thus it should be different for non-identical packets. Since the only difference is the second-to-last byte, which we know must be the actual message content itself, what this tells us is that there is no MAC for chat packets, at least. What this basically means is that an attacker can alter your chat message to a certain extent and the server is unable to verify that it has been changed. Though, the attacker still does not necessarily know how to alter your message data to form a specific message that he wants as the communication is encrypted. What will realistically end up happening is that the attacker alters your message to complete gibberish.
5) The launcher employs dual HTTP/TCP. Both protocols are sent to and received from "184.108.40.206" and "220.127.116.11". Most of it is HTML. ".141" seems to handle version info / patch requests while ".132" handles everything else (e.g. launcher images), it seems.
6) DN SEA's login server is "18.104.22.168". I do see what seems to be a TLS handshake taking place. This handshake takes place after the opening cinematic is finished. Some time between logging in and loading to town, some packets are sent to and received from the TCP game server ("22.214.171.124"; see point #2).
7) You start to receive a flood of packets from "126.96.36.199" during the initial load to town. The protocol is TCP. Some HTTP requests are also sent to this IP for the event / cash shop banners.
8) (A huge criticism) There is some weird behavior regarding encryption, at least for chat packets. The encryption of two identical chat packets does not change upon logging out and logging in again. However, the chat message was encrypted differently compared to my initial test 2 days ago. Either their TLS implementation has some weird session resumption behavior (this is a bad implementation if this is the case; logging in again should generate a new pair of symmetric keys even if it is a session resumption, I'm not going to go into detail regarding how to properly implement TLS, however this answer seems to explain it quite well yet again.), or they randomize the symmetric key generation every few hours (3, 6, 12, 24, et cetera) or so. This seems to be pointing towards a botched TLS implementation. The cipher suite is unknown as of now.
9) (Another huge criticism) I am fairly sure that the header of the chat packets did not change compared to two days ago. I am 100% certain, however, that the actual message content bytes (the last 2 bytes) have been changed compared to two days ago, signalling that a new symmetric key has been used. To be clear, the message contents themselves were exactly the same. What I am deducing from this is that encryption isn't applied to the entire packet, but rather to just the message contents or everything except the packet header. This is simply unacceptable to me. An attacker knows exactly what type of packet you sent (in this case, a chat packet) just by looking at the packet header.
Section 3. Packet Identifier Code Map
Section 4. Conclusion
I've done quite a bit more regarding packet structure analysis, however I will need conduct a few more tests in the future in order to verify. The packets (the chat ones at least) are encrypted, as expected.
Needless to say, I take networking and security very seriously for Project S. Discoveries such as #3 and #4 made me rather disappointed in Eyedentity as my standard for player privacy is much higher than Eyedentity's, it seems. Having said that, Eyedentity has always disappointed me, just that now, they disappoint me even more since they are not meeting my standard for player privacy.
Edited by Riuga, Yesterday, 05:10 PM.