Network Code Changes for LoY Release.

[high_jeeves]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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