Network Code Changes for LoY Release. [Archive] - ShowEQ Open Source Project Message Forums

EnvyEyes

03-04-2003, 02:43 PM

Wow.... where to begin.

WTG to those few who have correct opcodes and are functioning. If I had the knowledge they do, I would probably be enjoying my pretty little colored dots along with them. I don't keep up with the IRC channel, so I don't know where the breakthrough originated. As far as a Java version, I'm not sure what prompted that or the inherent benefits of it, so I can't speak to that.

Now, as for the folks whose ranks at the devs for "not fixing their seq for xx days":mad: ..... all I can say is:
Thank you very fucking much for screwing the rest of us who rely on the hard work, generousity, and diligence of the SEQ devs to break us out of the darkness that SOE has placed us in. You have collectively done what even SOE couldn't do.... you have nerfed the development of such an awesome project and apparently pissed off the devs enough to delay (maybe even stop...time will only tell now) the release of their updated codes.
I'll be the first to admit that without the pioneers of SEQ and the subsequent development done to keep it working, I would not enjoy the game nearly as much as I did once I discovered SEQ.
I also don't possess the know-how to even begin writing such a piece of software, let alone fix it when it is broken by changes to opcodes/compression/encryption/etc. All I have to rely on is the work by the devs and various other regulars to the forums (esp. mvern) to get me working again. I have never had to ask for help, as the posts I found when searching (http://seq.sourceforge.net/search.php?s=) have always led me to a fix. Every time SOE has broken SEQ, I have waited patiently with everyone else while the devs were hard at work on a fix. I rejoiced when that fix came, and thanked them when I could. I have never lost confidence in their abilities, regardless of the 'nay-saying pricks' who were often quick to complain or down-play the efforts involved. I now see that some people have incorporated a fix, telling me that the information is out there, but for some reason it hasn't been released. I may be hasty in thinking that the devs have been (justly) irritated, but that is the first thing that comes to mind..... and I wouldn't blame them one bit. If I were in their shoes and had to read some of the comments made by the "fucktards", I'd have stopped sending updates a year ago... but that is just me.

/rant off

/applauds devs

/rude to the "fucktards"

/filter flames

Iam_Walrus

03-04-2003, 02:49 PM

Having been labelled "fucktard" by bubba, I'd rather you didn't use that term as I don't wish to be lumped into the same category as those people that are crying for their toy to be fixed immediately. Rather, terms such as "scatboy," "bottomfeeder," "knuckledragger," and "shitheel" would probably be sufficient for your purpose, and leave we legitimate "fucktards" out of this particular picture.

Thanks!

Dark

03-04-2003, 02:53 PM

EnvyEyes

well said. I agree completely.
I also wish i had some idea of what to do to get it going but i cant program my way of of a wet paper bag.

To the Dev’s, keep up the great work….. please

z26o

03-04-2003, 03:25 PM

EnvyEyes - /applaud ... well said

Crybabies - please STFU

Devs and all contributors - /bow

LordCrush

03-04-2003, 04:51 PM

/cheer EnvyEyes

/nod /nod /nod

you are saying what many people thought for quite a time, but perhaps not were able to express (due to lack off english skill (i.e. me))

/cheer Dev's keep up the fantastic work and all who dont like the way the project goes leave and don't come back again !!!

Jillian

03-05-2003, 03:33 AM

Originally posted by high_jeeves
Please see the attachment... Jeeves,

I'm not sure if I should be happy for you, or sad that you're taunting the open source community with your working ported version. :confused:

The natural question to ask you now that you have fixed it and are posting about it on the seq forums is: will you be releasing the Java source code for this? I'm just not sure why you are posting here about it otherwise.

In any case, nice work. Here's to hoping you hook up the dev team with your skills. :)

high_jeeves

03-05-2003, 09:43 AM

My intention was not to taunt the community here, it was simply to show that a fix is possible, and I'm sure is being worked on by the developers here... as has been stated in other places, it has already changed again on test... If I was the devs, I certainly wouldnt be busting my ass trying to get a fix out, when it will certainly be broken again in a few days... especially given the attitute of many of the people on these forums. If I were the devs on this team, I would have stopped releasing patches to this product years ago...

As for releasing my code, not a chance in hell. I swore off playing a large role in the open source community a long time ago... reading the posts by some of the users here should give a prety clear idea as to why... Its not worth the hassle, and name calling to me.. I have the utmost respect for the various devs on this team that put up with this crap, its just not my thing..

--Jeeves

EnvyEyes

03-05-2003, 09:57 AM

I'll probably get a few flames from this, but I *pray* that Jeeves doesn't release his Java-ported version of SEQ. From my understanding, Java is pretty much cross-platform.... meaning that nothing would prevent it from running on Win-doze.

Judging by the above post, I can see I don't have much to worry about there. =~)

/bows to Jeeves for respecting the sanctity of SEQ

Aurelius

03-05-2003, 08:40 PM

I'm just an old fart... I try to learn all this stuff but, hell, I feel accomplished just in getting the new CVS compiled. I guess I am not a programmer, no matter how much I try the concepts keep draggin my upper eyelids down.

So, I will, respectively like, wait until the patch is prepared, any fix-it-uppers come along, or release of specific step by step guidance to get the SEQ up and running. You go guys, rah rah rah. And for all the 'tards' bad mouthing developers on so many threads, go gargle with a bottle of reality. No payment for hard work equates to a passion for the project. The least that can be expected by anyone involved is moral support.

Go Team, Fight team, rah rah rah

Back to me cave now. ))

SeqTester

03-06-2003, 08:57 AM

I understand Jeeves...

I am not a Dev but have tried to help here and there where I could. When Mapfiends site was up I used to watch the maps and sent better ones to Rat to update CVS. I also helped organize some OpCodes after Luclin and a few other things here and there.

I do not consider myself "Part of the Dev team" but I do try when I can.

I understand completely why certain people do not want to help here with all the whining bastards here.

Also I NEVER want to see a NONLinux version released!!!!!
That would be a BAD thing.

I liked it when the Devs posted the opcodes for people to "Fix it themselfs" I know that's not really what was happening but it was nice for those that know enough to fix it but not enough to find the OpCodes themselfs.

LordCrush

03-06-2003, 10:20 AM

What i meant with my earlier post is that it would be nice to get the opcodes and structure changes so that a dev don't need to reinvent the weel :p

I did NOT mean that the Java Version shuould be released.

Hmm i understan Jeeves when he says he dont wants to post that, but perhaps he can put it in a little mail and send ti to Ratt or one of the Devs ... just to reduce their time to find the changes

just my 2cp

Ratt

03-06-2003, 11:42 AM

Correct me if I'm wrong, but doesn't Jeeves version take the info directly out of memory, as opposed to picking it out of the data stream?

If so, the methods are totally different and totally incompatible.

HOWEVER ... it's something to think about along with Keysniffers.

Pull out all the info in memory with a keysniffer like program and send it along to SEQ... so there'd be a 2 mode SEQ. Either using info directly from the windows box via a sniffer, or pulling it passively out of the stream.

high_jeeves

03-06-2003, 12:28 PM

Ratt:

Bah, you give away all my secrets :p!!

Yep, actually it is the hybrid version you describe... it does some things from the datastream (when possible), and others it takes directly from memory... When it has problems decoded the datastream, it just auto-disables those features (for example, the combat calculator section of the app), and uses only the information it gets out of memory.. I think it is a fairly elegant solution, since I generally dont have more than 5-30 minutes of downtime between patches (to find the new offsets that are appropriate, and to modify my structures as appropriate for any changes in memory).

The problem with this implementation (and one of the major reasons I have not released any code relating to it) is that the code for the memory resident program is much larger than a key-sniffer, and therefore much harder to obfuscate... the "write/obfuscate" your own idea that is used here with keysniffers would not be particularly appropriate (since they would have to get much more complicated data to the ShowEQ machine in a format/ordering that it expects..) So, I'm not sure how viable this solution will be for a larger community..

I switched to this solution when the decryption went to 64-bit.. dealing with 64-bit unsigned numbers in java is a total nightmare, and i figured it would be less of a headache to modify my keysniffer then it would be to re-figure and re-write the decryption code for the encrypted packets..

--Jeeves

Jillian

03-06-2003, 01:46 PM

Originally posted by high_jeeves
I generally dont have more than 5-30 minutes of downtime between patches (to find the new offsets that are appropriate, and to modify my structures as appropriate for any changes in memory).God that is awesome... it takes you less time to update your seq version than it does for me to update my UI files. /bow

... one of the major reasons I have not released any code relating to it is that the code for the memory resident program is much larger than a key-sniffer, and therefore much harder to obfuscate... I'm not sure how viable this solution will be for a larger community..
You have a good point there, mass releasing that kind of code is just asking for SOE to add some detection code for it... or would they... Lately it has seemed with their major compaign to get new users that they're off the banning bandwagon. Thoughts?

cryptorad

03-06-2003, 04:22 PM

Well.. My totally unrequested opinion of a non code contributing noob is....

I'd avoid the memory ripping technique.. unless absolutely necessary. That would put SEQ real close to Macroquest in functional design (even if application and intent is widely different) and would open the cross platform release nightmare many wish to avoid.

Plus.. the possibilities get rather interesting at that point leading to .. who knows what.

I'd call this my 1 coppa. Not even worth dos.

AlphaBeta

03-06-2003, 04:57 PM

Macroquest writes to memory.. two diffrent things. I don't see a big problem reading the memory. Then again I am not a coder so I may know nothing! :D

I would assume that anything Sony did to capture someone reading memory would be an invasion of privacy issue so I don’t think any checks will be added ever to see if your snooping memory or not. Then again I am not a lawyer! :p

high_jeeves

03-06-2003, 05:01 PM

Macroquest is 100% totally different... not only does it write to data memory, it also uses detours to take over certain calls within the app to execute macroquest code... totally different..

--Jeeves

Aurelius

03-07-2003, 08:45 AM

Originally posted by Jillian
Lately it has seemed with their major compaign to get new users that they're off the banning bandwagon. Thoughts?

As with all lessons that come with life, the ones that are learned by being lulled into a false sense of security are the hardest. )) I remember a time where EQ folks waited over two months before a fantastically big number of bannings went out all at one time.

It seems that the beast can remember who and when it wants to. Caution is always the best friend of valor. ))

Go Team, Fight Team, RAh Rah Rah

lostinspace

03-07-2003, 09:05 AM

Well, if people have already enough information where in EQ memory we can get info about mobs and other stuff, then what Ratt suggested would be very good idea: 2 mode SEQ.

Some time ago I was reading about Macroquest and was contemplating using their offsets to get info about mobs and other stuff, but then I decided it would be too much work, even if in MQ they have offsets for mobs. Whole user interface part would be needed, drawings, hunting for memory offset and structure changes.... and so I decided its not worth effort.

But if SEQ could be still used as user interface , and client (EQ) side work is limited to extracting data (mobs ...) and sending special packets that SEQ will recognize and use in that 2nd mode - that would not be too much work.

So if following things can be done, we could get SEQ version that is independent of decryption if working in "2nd mode":

1) SEQ devs to specify network packet structure that sniffer can send, something like : type of info, mob/item ID, position, data...
2) SEQ devs to read and interpret such packets and use data in same way as if normal EQ packet was decoded
3) description where in EQ sniffer need to look for data (as mob position ..). Since some people like high_jeeves already use this method, I presume they already have this info. And since it will be info about EQ, not about their programs, I hope someone of them will agree to post that info
4) people use that info to read data in existing sniffers and send info to SEQ, who still do all drawing, filtering and stuff

We would have more offsets needed to update after EQ patches (like Macroquest have now I believe), but we would have also SEQ version that can work in periods while devs are trying to solve new decryptions.

Jillian

03-07-2003, 03:44 PM

Originally posted by lostinspace
Well, if people have already enough information where in EQ memory we can get info about mobs and other stuff, then what Ratt suggested would be very good idea: 2 mode SEQ.

I'm all for this for the reasons you stated above, but then again I'm not a developer. yet...

Freakyuno

03-07-2003, 04:00 PM

It seems to me, that writing a whole second mode into SEQ would be the long way to do it.

Forgive me if I am wrong, but in the software development world, things tend to end up more complicated than they need to be. Prime example, look at my post under the EQIM Thread.

Projects, explanitions, reasons for things get skewed into way more work that really required.

If your going to go through all the trouble to write a sniffer that resides on the EQ machine and grabs the unencrypted data straight from memory, wouldnt it be alot easier to just write a small GUI that lined up with the output of your sniffer and display it visually?

I did a quick flow chart just to put it in perspective. I didnt even include all the programing steps involved in writing all the decision code into SEQ to determine what it should try, or not, and when it should, and shouldnt, and it seemed quite clear to me that once you have your Memory Sniffer built, your 80% done, build your GUI - plug and chug.

Please correct me if I am wrong.

Ratt

03-07-2003, 04:14 PM

It wouldn't be that much work to make SEQ work with data across the wire. You just write a parser that feeds the varios data into the appropriate SEQ functions to handle the given piece of data.

I could write it up in about 30 minutes if someone wrote the Windows side application (Famous last words, yikes, maybe I shouldn't say that ;) )

The hard part, for me, would be to write the windows app (I have exactly zero experience with writing apps for windows) to access the data and send it out. I suppose most of the leg work has already been done by the MQ guys (and others), but I don't have the time nor inclination to track it down, decipher it and then work something up, nor do I have any desire to go mucking about in my EQ machines memory.

Make the application to pass the data to an arbitrary IP on an arbitrary port and the rest is fairly trivial.

To directly answer your question about the GUI, that's a fair amount of work, really, if you are displaying things in real time. If you were so inclined, you could get QT for Windows and port a good majority of the GUI code from SEQ to cut down on your development time.

A windows version of SEQ is coming, it's just a matter of time. Whether it's sooner, or later, doesn't much matter at this point, if what I suspect is happening, is indeed happening over at SOE. If it is the case, though, a Windows version of SEQ might be just what the doctor ordered to stop the insanity. :)

Jaerin

03-07-2003, 04:52 PM

Are you thinking that they might be building a SEQ-like interface into the mapper that came with LoY? Because after I saw the mapper and what everyone was saying about how the maps were so much like SEQ I got the thought that it sure looks like they might be going down that road...

Jaerin

Freakyuno

03-07-2003, 05:13 PM

In all honesty, that would be the best move SOE could make, regarding their stance to SEQ

Along the same lines as the modular development of EQIM, they could make a modular EQ Map feature, which included all the best parts of their maping system, and the "acceptable" features of SEQ, removing the "unacceptable" features and letting you run it on the spare windows machine you have next to you.

I dont think thats what Ratt was talking about though. What I got out of his post was geared towards the increasingly difficult task of keeping SEQ working, and the need to put more and more on the windows machine to obtain functionality.

wizard

03-07-2003, 05:14 PM

I read Ratt's post as more of a message to SOE.. That unless they want to deal with a widely proliferated any monkey can set it up windows version it would be in their best interest to tone it down a bit..

but i could be wrong..

Amadeus

03-07-2003, 05:50 PM

I'm just a simple guy...all I want is for SEQ to work exactly as it did before.

I don't even need CVS updates to be happy ...just a simple .diff file like Mvern did last time would be great.

I know, I know...it breaks a lot lately...but, from what I've gathered it's usually not that hard to fix for someone that knows their business well.

cryptorad

03-07-2003, 06:39 PM

My comparison of MQ and a SEQ that scans offsets.. was a bit of a look to the future. As is the thought of a SEQ that scans offsets also a look to the future.

But.. I will try to lead you to my look of the future a bit by asking these two questions.

What do you suppose a former MQ developer.. or savvy user.. with the source code for a program (an offset scanning EQ CVS)that contains listings of 'offsets' would want to DO with that??

Is it a huge problem to modify the code to not only SCAN the value.. but maybe.. modify it in some way?

That's what I was implying.

high_jeeves

03-07-2003, 11:00 PM

But modifying memory is what SOE just added new protections against (that is why macroquest is currently broken). Anybody who can write code to read from memory at a certain offset can also write to that memory.. but, they will now crash their EQ client upon doing so (and possible notify sony, although nobody has shown any hard evidence that this actually happens).

--Jeeves

cryptorad

03-07-2003, 11:21 PM

True.. that thought crossed my mind.

A truly spoof minded individual could probably come up with a way to discover the memory comparison scan trigger.. and spoof a readout to satisfy it.

I mean.. if you have all the tools except the spoof (the memory scanning funtional SEQ complete with offsets)... why not do that extra work to find THAT trigger.. and give it the dump it's looking for?

Now admittedly.. this is getting a bit far out for me and I may be totally wrong about the spoof potential. But.. all UP to this point seems quite reasonable.. and this seems likely to me IF it is not prohibitively difficult.

Either way.. none of it is reality anytime soon.. unless you're going to grandfather them in Jeeves. ;)

lostinspace

03-08-2003, 08:25 AM

In order not to go too deep in theory about future and MQ and SEQ and sony and stuff, let me repeat one simple practical question:

Q: Can ANYONE who already read memory from EQ post some basic info about data structure and offsets?

After that, writing that windows part of 2 mode SEQ would be easy. Of course, I did not just sit and wait for someone to post those offsets - I went to Macroquest board and downloaded their source and found it all in there .... everything we need:
typedef struct _SPAWNINFO - data structure about spawns
eqgame.ini (SpawnHeader) = offset for EQADDR_SPAWNLIST

Unfortunatelly, I did this about one month too late ... since it appears that Macroquest also has its own "not working" period. And offsets in INI file ( and probably structures in header files) are not correct.

Now, I could find new offset and even structure for spawninfo if i only have one pair of EQgame.exe and Macroquests eqgame.ini that used to work correctly (eg. in JAN 2003 or DEC 2002). Finding them without that is also possible, but would require noticeable more work.

So again:
- if you can post offset and basic structure of spawninfo, please do so ( this is specifically question for people like high_jeeves, who said that they already have that info)
- if you can post working MQ pair of eqgame.exe/eqgame.ini, that would also help (to find that above info, if noone want to post it)

Amadeus

03-08-2003, 10:10 AM

Macroquest is BROKEN. Why are you asking for executables here when the MQ has stated bluntly that it is broken?

lostinspace

03-08-2003, 10:58 AM

Amadeus, I was not asking for Macroquest executable, but for Everquest executable (eqgame.exe) that was current while Macroquest WAS working, along with Macroquests file with offsets (eqgame.ini) that worked for that version of eqgame.

That would help me to find new offsets without going thru complete from-the-zero analysis of EQ code.

Anyway, I did not find such ini/exe pair, but used some other info and was able to find information that i need.

And since I do believe in sharing info with community, here is that information :

- offset of SpawnHeader (EQADDR_SPAWNLIST ) = 00728484
- SPAWNINFO is changed, but I decoded offsets for few fields that I will need. Offsets are relative to start of structure, decimal:
.......Name: same offset
.......X,Y,Z,Direction: same offset
....... next/prev links: same offset
.......Type: new offset at 172 (PC,NPC,corpse..)
.......Level: new offset at 181
.......LastName: new offset at 300

That is enough info for anyone that was able to make keysniffer program, to also make list of mobs, positions etc... I had that list in 5 min in my keysniffer after I found new offsets.

Now, I would greatly preferr if SEQ devs include option for us to send packets with mob info, so I could use all SEQ functionalities like drawing maps, mobs, lists of PC/NPS, filters, alerts.

But in meantime I will make my own crude version of SEQ - just map, mob/PC positions and mob/PC list with ability to target mob. And will use that one untill SEQ devs either add support for sniffer mob info packets or they solve new decryption/structure.

cryptorad

03-08-2003, 02:04 PM

I may be forced to retract my "won't be reality anytime soon" statement.

outthere

03-09-2003, 09:31 AM

I exported my SEQ to Dos 6.22 (Up and running fine for weeks now). I even tweaked it so it runs perfectly on an old 486SX2 50.

Later this week I think I will export it to good old OS2 just for fun. I guess I was just really bored but what else am I supposed to do with my free time.

Anyone else have any luck exporting it to any other platforms?

Fenceman

03-09-2003, 09:58 AM

heh, you picked the easy stuff I see...

I started with porting it to my Atari 800XL in Atari basic. Then I ported to Logo, also on the Atari 800 XL. Logo was much easier, btw.

After that, I knocked out a version foe my Comodore (sic) 64 and am almost done with my Vic20 port.

The hard part wasn't porting it to another language, but designing & building network adapters for those suckers :cool:

After the vic20, I was thinking maybe a port to OS/2, but I see you'll have that covered ;)

Vertigo1

03-09-2003, 01:54 PM

Actually as of last night, MQ works fine. :)

Magao

03-11-2003, 10:07 PM

Anyone got it working on an HP-48SX? Any help would be appreciated thanks in advance

mahalo and aloha you very much

Magao

LordCrush

03-12-2003, 01:10 AM

I could try to do a port to my good old ZX81

hmm no the 1KB memory is not enough :p

Hendrix_Morton

03-12-2003, 09:40 AM

Originally posted by LordCrush
I could try to do a port to my good old ZX81

hmm no the 1KB memory is not enough :p

hehehe..I bought the 16K expander for mine...I was fly at the time!

Gilson

03-12-2003, 10:04 AM

So is what you're doing an effort to get Linux SEQ working, or an effort to get a Windows version of SEQ created? From the looks of it, what you're talking about right now is more generic packet information that'd apply cross-platform. I just saw someone mention "Windows" and "ShowEQ" in the same sentence a few posts back, and thought that was supposed to be some kind of heresy.

LordCrush

03-12-2003, 10:50 AM

Originally posted by Hendrix_Morton
hehehe..I bought the 16K expander for mine...I was fly at the time!

I ordered the 64 KB expansion, but after 4 month waiting my Dad bought an Apple IIe for his office :) That was the much better choice :D

Poncho

03-12-2003, 11:53 AM

Gilson -- I'd wager that you are going to see ShowEQ and Windows in the same sentence much more in the future. If SOE keeps dickin with the data the way they have been, that will probably be the only sane way to go. The question remains...how hard is SOE going to push this? I'd hope they would back off a bit because a Windows version isnt what I'd suspect they are wanting on their hands....I know I dont want it to happen either. I cant stand the fact of every nit-wit being able to run SEQ. This has all been overdone in previous threads - thing is, alot has happened since those threads.

Poncho

Jaerin

03-12-2003, 12:38 PM

It's that elist attitude that annoys the hell outta me. Why is it that network admins, advanced programmers, ect. all seem to develop an arrogance of power?

It's one thing to not want to help people because you've been asked hundreds of times it's totally another to bash someone just because they don't know as much as you.

People have to realize this is an open source project. The visibility is already there. SOE knows about it and will either do something about it or won't. So if 10,000 people are using it or 100 people are using it Sony is either targeting it or not.

I don't buy the obfuscation arguement because it never works once the project is visible. Take a bug or exploit for example. A few people will use it....then it gets leaked and a bunch of people start doing it. SOE sees what's going on and either takes action or doesn't. If SOE decides that SEQ or MQ or whatever is a violation then they will take action on it or they won't.

As many many many security analysts will tell you. Obfuscation is not security.

Jaerin

ether

03-12-2003, 12:56 PM

Power? Huh?

I had never used Linux before I set up SEQ. Now I have a nice Linux box running as my router, and understand how it all works. Setup a local SMTP and DNS server for myself on it too. It wasn't hard at all. If someone wants to run SEQ, they can. There aren't any "elitists" deciding who can and can't use it. Quite the opposite. There are LOADS of very helpful, step by step guides on how to get from a fresh install to running SEQ.

It amazes me how much people complain about being given such a powerful tool, for FREE that runs on a FREE operating system.

Ratt

03-12-2003, 02:08 PM

I'm going to dispell some common misconceptions...

Originally posted by Jaerin
It's that elist attitude that annoys the hell outta me. Why is it that network admins, advanced programmers, ect. all seem to develop an arrogance of power?

Mainly, it boils down to: "I spent the time to learn all this, why can't you?" Rightly or wrongly, that's why.

People have to realize this is an open source project. The visibility is already there. SOE knows about it and will either do something about it or won't. So if 10,000 people are using it or 100 people are using it Sony is either targeting it or not.

This is totally and utterly false. There's a little thing called cost/benefit analysis. It's not financially worthwhile to target 100 users, whereas it would be to target 10,000 in a lot of cases. SEQ is no different. If only 100 people were using it, it would not be financially viable to make regular changes to EQ to thwart SEQ... while it would be to thwart 40,000. So no, Sony "Will do something or they won't," is totally wrong. They wil do something when it becomes financially logical, and not until then.

I don't buy the obfuscation arguement because it never works once the project is visible. Take a bug or exploit for example. A few people will use it....then it gets leaked and a bunch of people start doing it. SOE sees what's going on and either takes action or doesn't. If SOE decides that SEQ or MQ or whatever is a violation then they will take action on it or they won't.

I'm not sure what you even mean by this. What obfuscation are you talking about? SEQ has never been obfuscated as a project. But again, as for SOE taking action, see the cost/benefit analysis above.

As many many many security analysts will tell you. Obfuscation is not security.

And every one of those that tells you that should be summarily fired for being a moron and not knowing his or her business.

Obfuscation is a perfectly valid, well known and accepted security method. As a nice, bright example of obfuscation being totally effective and preferred:

The US Presidents nuclear arsenal activation codes... they are contained on a card of (I believe) 6 other codes, 5 of which are invalid, only one works. If you enter the wrong one from that list, all become invalid. That's obfuscation. Of course, you first have to get the list... but once you do, you have a 1 in six chance of picking the right one.

Why do they do it this way? Because you are dealing with humans, and asking the President to memorize outright a sequence of numbers and recall them under a possibly stressful situation is a recipe for disaster. Putting that single number on a list of six, allowing him to pick out (and thereby using that as a memory aid) the proper sequence, you reduce the chance of error by several orders of magnitude.

There are other examples of where obfuscation is perfectly valid and in fact is the preferred method of "security."

Security is a matter of using the proper strength and type for the proper application. Obfuscation can be used very effectively in many types of applications and is a perfectly legitimate solution to security issues.

Aurelius

03-12-2003, 02:17 PM

Originally posted by Jaerin
It's that elist attitude that annoys the hell outta me. Why is it that network admins, advanced programmers, ect. all seem to develop an arrogance of power?

Jaerin

Because they can and most can't. I'm one of the ones that can't (at the moment). In the military police we had such an element in the Military Working Dog's section. The handlers were of same mind. But it isn't all that easy to just switch them out and put someone else in . . . unless they underwent the same intensive training of specialization.

Prima Donna's? Maybe. Arrogance of Power? Could be. But I'd still like to be able to do what they have done. Just gonna take me a lot longer to get headed in that same direction. I'm not fooling myself to believe I will ever obtain the expertise they have, after all the doc tells me I'm not producing so many brain cells anymore. My synaptic relays are pretty well spent. But someday I'd like to be able to consider myself with a developed arrogance of power. ))

nuff said
<rant off>

Proxeneta

03-12-2003, 04:39 PM

If anyone needs an old eqgame.exe that can work with SEQ or MQ, to find offsets, ect. Go to

http://prdownloads.sourceforge.net/eqemu/EQEmuPatcher.exe?download

Download the EQemu patcher, and If you dont want your EQ files to be outdated, copy your everquest dir into another dir.

Run the patcher to get an old Eqgame.exe that you can work with.

(you can't use this eqgame.exe to play...you know that)

Jaerin

03-12-2003, 09:53 PM

Originally posted by Ratt
I'm going to dispell some common misconceptions...

And every one of those that tells you that should be summarily fired for being a moron and not knowing his or her business.

Obfuscation is a perfectly valid, well known and accepted security method.

Yes it is a valid form of security, but should not be the only form. That's all I'm saying. No SEQ hasn't been intentionally hidden from view to avoid visibility. SOE knows about it and won't forget about it just because a handful of people are still using it. No it might not be cost effective to directly change things to cause SEQ to break, but if they notice changes that would break SEQ all the better.

All I'm saying is taking an arrogant "Your too stupid to run SEQ" or "Only the leet will be able to use it" attitude is unneeded and annoying. I'm reading the exact same thing over on the MQ boards.

Thier project was created in Visual C++ 7 and has problems compiling under Visual C++ 6. At least one particular mod on the boards over there has been intentionally trashing all threads that give any kind of guide on how to make it work. Why? Because he's abusing his power and has that "You're too lazy attitude"

Yes there are lazy people that want to be spoon fed, but for those that are actually trying to do it themselves, they don't need to get flak everytime they ask a question.

So you could say that he's not deleting the question threads, just the guide threads. What's the difference? If your going to allow people to answer the same question over and over again why not allow a guide?

I don't see that attitude quite so bad over here, but it has been a lot more evident lately and it just continues to go unchecked. It's one thing for an angst ridden admin that's answered every question imagineable 100 times to be pissy, but lately it's been spreading to the new people. There seems to be rarely a post lately that doesn't have at least one flame, if not many, in it.

So take few days and cool off a bit. Life will go on with or without SEQ working. Being pissy and flaming isn't going to get it fixed any faster.

Jaerin

uncleubb

03-13-2003, 12:55 PM

Originally posted by Jaerin

All I'm saying is taking an arrogant "Your too stupid to run SEQ" or "Only the leet will be able to use it" attitude is unneeded and annoying. I'm reading the exact same thing over on the MQ boards.

Don't take this as a flame, but the elitist stance can be useful.

For example, my understanding is that this was part of the "social contract" between SEQ and the SOE EQ developers. SEQ's side of this was to make it somewhat difficult to get the program up and running. This was a conscious decision by the developers and definitely elitist. In return, SOE developers were to allow SEQ to exist as it was.

However, per Ratt (and as is obvious to all) this contract was broken by SOE. The contract has been argued ad naseum elsewhere. Because of this, and other reasons, it has been argued that the elitist position is no longer needed (ie, bring on the WinSEQ).

The elitist position gave some protection to SOE by limiting quantity of SEQ users, so while the contract was in force, it was needed.

In any event, I don't think long downtimes like this last one will continue for very much longer. Longer term solutions are brimming... Whether said solutions are elitist or available at a click will likely be up to developer of the solution.

Amadeus

03-13-2003, 04:19 PM

I'm just glad that the application is available period. I don't have time to develop it myself because I actually enjoy playing the game (with SEQ anyway).

I'd pay for SEQ, np...especially if it were a lifetime lisence for upgrades, etc... Hell, it might motivate them to develop for EQ2 as well. :)

CybMax

03-14-2003, 07:37 AM

For example, my understanding is that this was part of the "social contract" between SEQ and the SOE EQ developers. SEQ's side of this was to make it somewhat difficult to get the program up and running. This was a conscious decision by the developers and definitely elitist. In return, SOE developers were to allow SEQ to exist as it was

A "real" thing? Or just another suspicion?

uncleubb

03-14-2003, 10:53 AM

Originally posted by CybMax

A "real" thing? Or just another suspicion?

I'll let you decide for yourself by reading this (http://seq.sourceforge.net/showthread.php?s=&threadid=2523) thread. (http://seq.sourceforge.net/showthread.php?s=&threadid=2523).

-uu

baelang

03-14-2003, 11:38 AM

Originally posted by Magao
Anyone got it working on an HP-48SX? Any help would be appreciated thanks in advance

mahalo and aloha you very much

Magao

I just sold my 28s, or i would have gladly helped in that effort.

SilentVoice

03-14-2003, 04:31 PM

This is in reference to Ratt's post about a window's program. I am familiar with windows programming and socket programming. I am not however familiar enough with the SEQ source to attempt writing a program that sends this data to the SEQ machine.

Could someone outline a few cases as to what you would be looking for and what would trigger it (i.e. need to send the zone name to SEQ when a player zones)? Also if I were to do this, it would be best to figure out some kind of method to send the data across since we are doing much more here than just sending the decryption key.

Jillian

03-14-2003, 07:12 PM

Originally posted by SilentVoice
it would be best to figure out some kind of method to send the data across since we are doing much more here than just sending the decryption key.
let's encrypt compressed encrypted data sent to our seq boxes that way SOE will have a hard time in case they decide to sniff our outgoing packets

lostinspace

03-17-2003, 09:51 AM

SilentVoice, as you already noticed, what you need is that someone who is familiar with SEQ source change SEQ so that it can accept and use packets sent from win sniffer program for more than just key.

After that theoretical change in SEQ, whoever did it should detail what packet structure SEQ expects from snifer, something like:
- structure for zone and/or player info
- structure for spawn info
- structure for spawn position change
- structure for optional info (spawnID of active target etc...)

That would be starting point for any windows programer to use in their sniffer program. I already mentioned that few posts back ... but I did not expect any fast response, so I said I will make my own win version of seq (memory reading, not packet sniffing) untill real SEQ is back - which I did.

While such program did not need at all sending packets over network, I made option for packets to be sent to second instance of same program on second PC - just to see what would be really needed in any sniffer/SEQ communication ( well, and becouse some ppl used to 2nd PC asked for it :)

In doing that network option, I realised that it is not so simple as I originally thought. I met same problems that EQ developers probably had - how to efficiently transfer data about all spawns from server (PC1) to client (PC2) over bandwith limited network.

And it is limited, even if you are on 100MB LAN, because if you send more than 12 KB/sec of UDP data , receiving widows socket will start missing that data.

So I did following:

1) defined minimum length packet of 22 bytes, containing updateType, spawnID, dataType and data. Data structure depends on dataType, and i use 3 so far: 0= I send name in data bytes, 1= I send x/y/z/direction/speed in data bytes, 2= I send level, guild, class and few other info about spawn

2) defined several updateTypes:
INSERT: send all 3 dataType packets, with name, x/y/z and other info
UPDATE: send only dataType=1 packet, with new x/y/z
DELETE: send only dataType=0 packet, where i use spawnID only
KEYFRAME_ZONE: send only dataType=0 packet, where name is actually zone name
KEYFRAME_PLAYER: send dataType=0 packet, where name is player name

3) Insert packet is sent when i detect new spawn. UPDATE is sent only when x/y/z/dir changed, DELETE is sent when i detect that spawn dissapeared. All are reffering to spawnID

4) when KEYFRAME packet is received on PC2, I mark all existing spawns for deletion. When several keyframes are received without spawn info being updated with any normal Insert/Update packet, i delete that spawn on PC2. That is to ensure that even if one DELETE packet is missed, i will evelntually delete spawn

5) after KEYFRAME packet is sent on PC1 (which is done every 10sec for example, may be longer or never), I send INSERT packets for all spawns. That insures that even if some INSERT packets were missed, new spawns will eventually get sent to PC2. Steps 4&5 are optional, and just safeguard against missed UDP packets

6) I group up to 10 data packets of any type into one UDP network packet ... so optimising bandwith usage ( with 50ish byte header, sending 200 bytes is better than sending 20 bytes ).

7) algorithm for sending packets take into consideration not to exceed 10KB/s throughput , by calling step 7 no faster than 20ms apart.

Now, not everything of above needed to be done for data to be sent from server to client , but with above principle I got best results. I detailed this here so anyone willing to make SEQ side change can possibly use some of this info as help to decide what structures could be sent.... although I believe whoever decide to do it on SEQ side may model his packet types according to actual EQ packets types.

baelang

03-17-2003, 12:54 PM

Originally posted by lostinspace

In doing that network option, I realised that it is not so simple as I originally thought. I met same problems that EQ developers probably had - how to efficiently transfer data about all spawns from server (PC1) to client (PC2) over bandwith limited network.

And it is limited, even if you are on 100MB LAN, because if you send more than 12 KB/sec of UDP data , receiving widows socket will start missing that data.

so why not use some form of TCP if you are worried abgout data loss? sure, the overhead is more with TCP than UDP but you should be able to optimize windowing and such to meet your performance requirements.

even at 10mbps you ought to keep up with EQ data easily without performance hits.

Logic_Dingo

03-17-2003, 01:56 PM

TCP is strictly two way though isnt it? So the Showeq linux box would have to send data back to the windows box for confirmation of packets sent. That doesnt sound good :/

high_jeeves

03-17-2003, 02:01 PM

Might want to recheck your code... I am sending zone info, item info, spawn info (new, update, delete, death packets are all seperate)... I run at less than 2KBps doing all of this (using UDP)... not exactly a drain on a 100Mbit network (or even a 10MBit network, for that matter)

I havnt had any real dataloss issues (I sequence my packets, and report any dropped packets). Generally, it is less than 1% packet loss...

--Jeeves

KaL

03-18-2003, 10:16 AM

You guys with your workarounds, I bet everyone would love to get copies of what you're running.

Throw us a bone!

baelang

03-18-2003, 12:11 PM

Originally posted by Logic_Dingo
TCP is strictly two way though isnt it? So the Showeq linux box would have to send data back to the windows box for confirmation of packets sent. That doesnt sound good :/

Yes, TCP sends acknowledgements back. that is the point of it. it does not send one ack per packet, it sends one ack per window.

but that is a good thing and it is what you want to do IF (and that is a very big if) you are worried about dropped packets.

if all you are running is EQ and SEQ and a router, you shouldn't be seeing enough of a load to have signifigant packet loss. if you are getting more than 1% packet loss, you may have bad cables or some sort of interference with your cables, or a malfunctioning hub or nic or some such. if that is the case make sure you aren't running ethernet cables close to power transformers, power cords, CRT monitors, or anything that produces a shifting EM field.

lostinspace

03-19-2003, 04:12 AM

Aside from TCP being connection oriented protocol ( meaning you connect IP1/Port1 with IP2/Port2, and that 4 member pair must be unique), other stuff is fairly similar to UDP when viewed from application standpoint. TCP can be used to transfer payload data only in one direction, if you wish. Unvisible to application, TCP stack will also transfer acknoledge packets and that will slightly increase bandwith usage, but it will be included in payload packet headers whenever possible, and on LAN that can be disregarded. Also, TCP has advantage to have 'ensured' delivery, with retransmition and fragmenting and other stuff UDP lack. But nothing really necessary for this usage.

Back to that bandwith issue - my solution use 10kbs when I send keyframes every 10sec. Those are not required as I stated, and without them it is ten times lower bandwidth usage, with ~0% packet loss on 100MBs LAN. But i use keyframes for another important feature, so I keep them there :)

And to someone who mentioned workarounds... this is not workaround to make SEQ working, its separate solution. I would like to see workaround solution for SEQ, but that was already posted in previous post.