Patch Wednesday 1-26-05

[uRit1u2CBBA=]

With tomorrow's patch, the new networking code may be rolled out .. if it does, SEQ will be broken until someone can figure out how the new one works.

If it isn't rolled out tomorrow, expect it to be rolled out on 2-15-05 with DoN expansion release.

[quackrabbit]

I can indeed confirm that the new netcode was indeed rolled out today.

[UnGod]

Great, I picked the wrong time to have the urges to play EQ again.. Guess I get to pick through some packets rather than smack some dragons eh? *snickers* ;)

[uRit1u2CBBA=]

Sounds like someone needs to figure out the new networking code before packets can be resniffed.

[kaybek]

I wish I even knew where to start at that.

[ksmith]

Doodman from EQEmu was kind enough to share some code to handle the new EQ1 protocol, but it'll be quite an undertaking to merge it with showeq.

Interested parties who are able to contribute to the programming effort should stop by #showeq on irc.doomed.to port 8067.

[uRit1u2CBBA=]

Normally I'd love to help, but I've got fires in my real job that I have to put out :(

Maybe later this afternoon I can join in on the fun.

[tanner]

Doodman from EQEmu was kind enough to share some code to handle the new EQ1 protocol, but it'll be quite an undertaking to merge it with showeq.

Interested parties who are able to contribute to the programming effort should stop by #showeq on irc.doomed.to port 8067.

Looking at Z's todo list:
http://www.showeq.net/forums/showthread.php?t=5057

This item in particular:

Split packet capture front end into a seperate program that communicates with ShowEQ either via pipe (local packet capture) or TCP/SSL connection (to allow remote packet capture).

Is the undertaking extensive enough to that we could look at working the above item ?

[I<3EQ]

I've never contributed to the coding effort before but I do have linux programming experience and (minimal) network programming experience. I'll start lurking in the channel from work on a day-to-day basis to try and digest some of what's going on and and I'll actively participate in the evenings (though I will probably be concurrent with raiding).

EDIT: registered as dec on irc.doomed.to

[kmkm]

I'd love to help where I can, unfortunately I have minimal C++ programming experience, but I pick things up quickly :) ...already been reading over the current ShowEQ code.

I'll be around in the evenings (that could be the day for anyone in the US, I'm in the UK)... :)

[I<3EQ]

So I've spent some time with the sniffer (including debugging it when it repeatedly segfaulted... better tcpdump filters and a slight hack fixed that), looked at the output, and looked at the existing showeq code. As I said before, I only have minimal network programming experience -- I took a junior level networking course as part of my computer science curriculum approximately 2 years ago. That introduced me to the concepts surrounding networks. I'm comfortable with the layered architecture, the structure of packets, and how things get from point A to point B and I can write simple client and server applications using sockets.

I'm serious about helping with this project but I'm not sure where to go from here to learn more. I've googled around a bit and I've found a lot about using tcpdump and other utilities but really nothing helpful about analyzing the results. Everything I've found uses examples where the payload is in plaintext (i.e. monitoring a web browsing session (HTML pages) or a telnet session).

What tools are used in deciphering the payload? Where can I go to learn more? Any suggestions or advice would be most welcome.

[purple]

What does "deciphering the payload" mean? You're looking at a raw packet dump, right? What do you expect to see out of it in order to accomplish "deciphering the payload"? There isn't going to be some magic that makes the bits turn into sensible data. You have to know what the bits mean.

Most of each packet is obviously the same as it was before. The data that gets placed into the structs seems ok to me at least from what I can tell. The problem is the rest of it: given a packet, being able to tell what opcode it is for and to be able to assemble fragmented packets into a single meaningful EQ packet for the opcode. This is what the code in packet*.[cpp,h] files do for the old net stream. Right now, pcap delivers packets and when seq looks at them, they fail the crc32 check which used to be the first 2 bytes of the data segment of the UDP packet. That's why all you see are those messages in the console.

I'm suffering because I don't know what the old raw stream looked like, so I have nothing to compare things to. I always just looked at SEQ zone logs which were involved with taking the actual packet data and aligning structs properly to make it addressable, which is the step after putting together the packet-level data, and then helped align the structs properly after patches. This was a hell of a lot easier than staring at udp packet dumps and figuring out how to properly deal with it to fill in the gap.

It looks to me like we need to take the 10 bytes before the struct data and get out of it what is needed to unfragment packets and get an opcode. And maybe it's not always 10 bytes, but opcode or flag dependant, which is how it seems it used to be, from reading current source, but the packets I've been looking at are 10 bytes and start 00 0d.

Once someone deciphers the strategy for any necessary decoding, unfragmenting, and extracting opcodes then we'll need to rewrite the packet layer appropriately.

Of course all this is just my opinion. A lot of this is over my head and I'm just doing my best to grok it because seq is useful enough to me. I'm just hoping they didn't change too much.

I haven't yet figured out if folks are right when they talk about EQ now using EQ2 netcode, or if people are just making assumptions about things. I haven't seen anyone else's code snippets that have turned the light on for me yet.

As for tools, all I have is ethereal and a bunch of vim windows open myself *shrug*. It doesn't help that I really don't know what I'm doing either, but oh well!

[I<3EQ]

What I meant by deciphering the payload was looking at the data portion of the packets (i.e. what comes after the header) and making sense of what's in there. I understand there's no magic tool to make that into intelligible data. What I'm looking for are ideas of how to get started doing this kind of thing. What strategies should I be using to figure it out?

The way I figure it, there was a time before the EQ protocol was even semi-documented by the community. The folks who originally worked on SEQ didn't have a map telling them what the bits meant. Where did they start? What strategies did they use? How did they learn how to do that?

I normally wouldn't be asking questions like this but I haven't found any references that give me a good starting point. I'd seriously settle for a "hey idiot! try putting string_xyz into google!" or "try reading the following books!".

This is me acknowledging my ignorance, trying to find information on my own, failing miserably, and asking for a push (or shove) in the correct direction. That's all. :p

[KaL]

Well, the original stream was unencrypted.

ShowEQ was what made SOE use encryption. Or maybe they were still Verant back then, I don't remember.

[MacLeod22]

It looks like the myseq or whatever it is people have offsets or whatever for the patch, is there anyway that information can help the regular linux seq out? I am only an end user and can be of absolutely no use unfortunately. But I feel like I am blind now playing eq.

[Cryonic]

Memory offsets don't help with network code