uncleubb
03-06-2003, 04:28 PM
I'm going to go ahead and post this realizing the possibility that much of it is probably wrong because I have EXTREMELY limited knowledge of the details of networking or programming. But this may encourage one of two things: 1) people will correct (read: flame?) me and/or contribute more information or 2) people may have a starting place to look to find answers. I think that, perhaps, so many of the people on this project are such high-level technical thinkers and have such high level expertise that they don't realize just how basic many users' understanding is.
Furthermore, this is just a summary of what I have gathered from paying attention to those who post on this board. I have no experience doing any of these things. I am relatively savvy with computer setup, networking and operation and have some C programming experience from being a developer for an LPC MUD for several years, but any knowledge in computers that I have was acquired either as (i) a hobby or (ii) a method to pay for the schooling required for my career.
So, fundamentally:
You could contribute to the SEQ project in three main ways. 1) Submit code modifications for the SEQ program, 2) Analyze packet data so that the developers know where to have SEQ look for important data, or 3) Appreciate/donate $$ to those who take on these tasks and share their work.
Question: How do I contribute to the program itself?
Answer: Well the answer to this is pretty simple. You’ll need to understand how to code to be able to contribute programming to the project. My understanding is that SEQ uses C++. Therefore, if you want to contribute code, you'll need to have some knowledge of C++. Next, you will need to target an area of interest and review the existing code. Once you understand how the code works, you can modify it. If you get the modifications working and think others might appreciate the changes or that it should be part of the base code, you would post it and let the active developers decide how to proceed. Starting here (http://seq.sourceforge.net/showthread.php?s=&threadid=3095) (http://seq.sourceforge.net/showthread.php?s=&threadid=3095)makes the most sense.
This type of person seems to be relatively abundant in connection with the SEQ project.
Question: How do I help with the network/data packets?
Background: EQ is an "online" game. It works through software on a client machine communicating with a remote server. In order to do this, data has to be sent back and forth between the client machine and the server machine. Without repeating, ad naseum, all the issues: 1) data has to go back and forth for the game to work, 2) SOE doesn't want this data to be easily interpreted, 3) with enough effort this data can be interpreted. One analogy made by a dev (I think it was ratt) was that this can be a lot like putting together a HUGE puzzle when all of the pieces are white. So, if you know about the packets, you know when certain data is being sent and you may know very specific details about that data (mob level, mob location, player information, etc...).
Answer: You need to capture data packets and analyze them.
Part I: I gather that the capture part is much easier than the analyze part. Linux has the capability to capture packets, I believe through “libpcap” or some other system/library. I know I could learn how to do this, but I presently don’t have the time (read: I lack the desire to learn this). Maybe someone could re-post how this is done (I am sure it has already been posted, but see the prior sentence).
Part II: The analysis portion of this requires (according to fester) “a rudimentary knowledge of disassembling, Intel assembly, and many ‘common’ compression and encryption methods”. I would suggest that you read this thread (http://seq.sourceforge.net/showthread.php?s=&threadid=3083) (http://seq.sourceforge.net/showthread.php?s=&threadid=3083) and do google searches on all of these terms. It also means to me that you need to have software that allows (at a minimum) for the disassembling of packets. Once you have located the portions of the packets that provide the necessary information, you could then (i) post your findings for the use of coders or (ii) code up some patches to SEQ that incorporate required changes.
My sense is that the type of person who can do this sort of analysis is less common.
I’d love to be able to say that all you have to do is capture some packets, download “x” disassembler and start looking, but I believe it takes more than that. If it was that simple, I might even consider doing some of it myself. I think that the more people on this project that are willing to do this, like mvern, the better for the project (and perhaps for people like mvern).
I do think that a more organized approach would be “better” for this sort of thing. By better I mean, get SEQ up and running quicker. I think that if those who have the know how to do this organized their efforts, they may save some time. Also, this may be the only way to have a functional SEQ if there is a specific effort on the part of SOE to break SEQ. In other words, it may be the only way to respond fast enough.
But I’ve not been on the IRC channel and I don’t really care to get on it, so my perceived lack of organized effort may be just that: perceived. However, I also recall that in the past public posts were made regarding progression with the packets. That seems to have changed because I haven’t seen similar posts. BUT, this could be due to a particular approach adopted by the developers as a countermeasure – if it is posted SOE knows what is happening. But I'm not going to speculate further on this...
In the end my reasoning for posting this is in hopes that it helps those with time and interest toward the answers they need so that they can contribute.
I'd just like to again express my thanks to the developers for their free work and for the fact that SEQ exists at all.
Furthermore, this is just a summary of what I have gathered from paying attention to those who post on this board. I have no experience doing any of these things. I am relatively savvy with computer setup, networking and operation and have some C programming experience from being a developer for an LPC MUD for several years, but any knowledge in computers that I have was acquired either as (i) a hobby or (ii) a method to pay for the schooling required for my career.
So, fundamentally:
You could contribute to the SEQ project in three main ways. 1) Submit code modifications for the SEQ program, 2) Analyze packet data so that the developers know where to have SEQ look for important data, or 3) Appreciate/donate $$ to those who take on these tasks and share their work.
Question: How do I contribute to the program itself?
Answer: Well the answer to this is pretty simple. You’ll need to understand how to code to be able to contribute programming to the project. My understanding is that SEQ uses C++. Therefore, if you want to contribute code, you'll need to have some knowledge of C++. Next, you will need to target an area of interest and review the existing code. Once you understand how the code works, you can modify it. If you get the modifications working and think others might appreciate the changes or that it should be part of the base code, you would post it and let the active developers decide how to proceed. Starting here (http://seq.sourceforge.net/showthread.php?s=&threadid=3095) (http://seq.sourceforge.net/showthread.php?s=&threadid=3095)makes the most sense.
This type of person seems to be relatively abundant in connection with the SEQ project.
Question: How do I help with the network/data packets?
Background: EQ is an "online" game. It works through software on a client machine communicating with a remote server. In order to do this, data has to be sent back and forth between the client machine and the server machine. Without repeating, ad naseum, all the issues: 1) data has to go back and forth for the game to work, 2) SOE doesn't want this data to be easily interpreted, 3) with enough effort this data can be interpreted. One analogy made by a dev (I think it was ratt) was that this can be a lot like putting together a HUGE puzzle when all of the pieces are white. So, if you know about the packets, you know when certain data is being sent and you may know very specific details about that data (mob level, mob location, player information, etc...).
Answer: You need to capture data packets and analyze them.
Part I: I gather that the capture part is much easier than the analyze part. Linux has the capability to capture packets, I believe through “libpcap” or some other system/library. I know I could learn how to do this, but I presently don’t have the time (read: I lack the desire to learn this). Maybe someone could re-post how this is done (I am sure it has already been posted, but see the prior sentence).
Part II: The analysis portion of this requires (according to fester) “a rudimentary knowledge of disassembling, Intel assembly, and many ‘common’ compression and encryption methods”. I would suggest that you read this thread (http://seq.sourceforge.net/showthread.php?s=&threadid=3083) (http://seq.sourceforge.net/showthread.php?s=&threadid=3083) and do google searches on all of these terms. It also means to me that you need to have software that allows (at a minimum) for the disassembling of packets. Once you have located the portions of the packets that provide the necessary information, you could then (i) post your findings for the use of coders or (ii) code up some patches to SEQ that incorporate required changes.
My sense is that the type of person who can do this sort of analysis is less common.
I’d love to be able to say that all you have to do is capture some packets, download “x” disassembler and start looking, but I believe it takes more than that. If it was that simple, I might even consider doing some of it myself. I think that the more people on this project that are willing to do this, like mvern, the better for the project (and perhaps for people like mvern).
I do think that a more organized approach would be “better” for this sort of thing. By better I mean, get SEQ up and running quicker. I think that if those who have the know how to do this organized their efforts, they may save some time. Also, this may be the only way to have a functional SEQ if there is a specific effort on the part of SOE to break SEQ. In other words, it may be the only way to respond fast enough.
But I’ve not been on the IRC channel and I don’t really care to get on it, so my perceived lack of organized effort may be just that: perceived. However, I also recall that in the past public posts were made regarding progression with the packets. That seems to have changed because I haven’t seen similar posts. BUT, this could be due to a particular approach adopted by the developers as a countermeasure – if it is posted SOE knows what is happening. But I'm not going to speculate further on this...
In the end my reasoning for posting this is in hopes that it helps those with time and interest toward the answers they need so that they can contribute.
I'd just like to again express my thanks to the developers for their free work and for the fact that SEQ exists at all.