It's no longer working.

[ghost]

It is no longer working, I am willing to help you maintain this project, please let it work

[ncatlin]

It's quite a pain to keep on top of changes to game stream when they change it so often (each expansion in particular results in loads of new packet types), for a game I don't play that's a lot of work. I'll think about if there is anything I can do to speed it up.

[dudememer]

If you could update, it would be much appreciated! I'm a novice and still learning reverse engineering, so your tool was very helpful. I understand though if you can't.

[leethobbit]

Here's what I've been able to deduce through testing - Basically, once login is underway exileSniffer crashes. I did not see anything in the logs when running the 64 bit version of Path. I did manage to get exileSniffer thinking it had successfully decrypted traffic. This only occurs when you try logging in for the first time from a different IP and end up needing to unlock. As long as I left this unlock screen up I appeared to be connected and took screenshots of the Salsa key values and what not. I tested this several times with a VPN.

I'm not sure if those values are actually correct and you'll notice the huge log amount - it was continually spamming that it was waiting for the login to continue or something to that effect.

As soon as I went to login following this, exileSniffer would crash. I am planning to troubleshoot this myself but I have to take some time to download all of the dependencies for VS because I can't even compile exileSniffer currently.

This may be completely unrelated, but the second Client > Server packet with ID 0x03 was consistently 149 bytes as opposed to the 147 I saw in the blog.

I will update this further once I get the sniffer compiling so I can test changes.

[ghost]

@leethobbit ok

[leethobbit]

Quick update: Thanks to Nia, I have the compiler working and updated my exileSniffer. The sniffer is still losing track of the packets due to changed packet IDs, but here's where I'm at:

As you can see above, the Character List now carries what looks like a copy of UNK0x4 at the front of it, so it is no longer packet 0x10. I think I'll need to implement an if statement that looks at all 0x4 packets and if they == 42 bytes kicks them over to the UNK0x4 deserializer or otherwise processes as character list.

I'm still pretty new at C++ so give me some time and if I get it working I'll share the changes so you guys can use it.