Educated opinions on new Test server anti-MQ code

insanitywiz · Post by **insanitywiz** » Sat Feb 22, 2003 7:06 am

Just thought I would drop this in here, breaking MQ was an accident on SOE's part, a happy one for them to be sure, but it was an accident. Hell, the only way they found out it broke MQ was when some dumb slob called tech support when he couldn't stay on, and when they got around to asking if he had anything running in the background, he told them....that he was running MQ.

Shortly after a very happy dev GM broadcasted the now famous message.

Vendor001 · Post by **Vendor001** » Sat Feb 22, 2003 4:38 pm

hmm...making me think this was all offfset monkying that did it...

mechntosh · Post by **mechntosh** » Tue Feb 25, 2003 3:51 pm

Just curious as to how you know that's how they found out ?

insanitywiz · Post by **insanitywiz** » Tue Feb 25, 2003 4:28 pm

Because I know people, and those people love to share funny stories about people calling in and saying they run MQ, or doing /reports about harrasment, with their MQ code showing.

Gooberball · Post by **Gooberball** » Wed Feb 26, 2003 11:27 pm

Not that any of that helps...

What we NEED is an MQ that overides the memory checking and always sends back the correct checksum (or whatever verification they're using) and the proper offsets to restore us to a pre 2/24 level of functionality. NewUI /click isn't really a priority when we don't even have a functioning program, much less one that evades detection.

I may be able to help with some of the coding and I am not sure how offsets are hunted down, but if I knew the proceedure, I would be more than willing to help. BTW, I'm not really worried about losing my account as EQ with MQ isn't really fun to play anyway.

Valerian · Post by **Valerian** » Thu Feb 27, 2003 8:25 am

I completely agree.. instead of thinking of ways around the offset checking function by eliminating detours, think of a way to detour the offset checking function. I'm very VERY short on personal time right now, or I'd be seeing what I could see about doing just that...

Domosan · Post by **Domosan** » Thu Feb 27, 2003 12:24 pm

Just an FYI -- breaking MQ was NOT a "happy accident" -- I'm not passing this on through hear-say from people who tell funny stories, this is first hand.

Before they implemented the changes on test, they informed the Test Server Guides that "We know that you all know better, but should any of you be running any 3rd party programs that effect Everquest gameplay, we would HIGHLY recommend you shut them down before logging in next."

If that doesn't show planning, I don't know what does.

Just my 2-cents.

mechntosh · Post by **mechntosh** » Thu Feb 27, 2003 2:32 pm

vanessa · Post by **vanessa** » Thu Feb 27, 2003 2:43 pm

insanitywiz · Post by **insanitywiz** » Thu Feb 27, 2003 4:24 pm

Domosan wrote:Just an FYI -- breaking MQ was NOT a "happy accident" -- I'm not passing this on through hear-say from people who tell funny stories, this is first hand.

Before they implemented the changes on test, they informed the Test Server Guides that "We know that you all know better, but should any of you be running any 3rd party programs that effect Everquest gameplay, we would HIGHLY recommend you shut them down before logging in next."

If that doesn't show planning, I don't know what does.

Just my 2-cents.

So, what you are trying to say is you are a test server guide that was told this?

The offset checking code wasn't designed, nor was it tested, nor was it targeted, towards MQ. It was a broad stroke to try to put a stop to all offset hacking, and if you can't figure that out there isn't much hope for you.

Vendor001 · Post by **Vendor001** » Thu Feb 27, 2003 4:56 pm

I agree, you don't see any specific statements in there about macroing, or "applications with quest in the title".

The quote simply states "3rd part programs" which, if you have browsed the FH boards, would know includes tuxracer's(and others) "trainers". (side note: some of the talk on those boards is kinda scary...like clicking off root/snare and such....feel sorry for those pvp peeps w/o a trainer).

I think it would be cool if we could just get MQ going again as a keyboard filter, which didn't insert itself as a thread in EQ's process, we'd still have alot of macro ability left(albeit, without /face, char information, text output in the chat window, etc).

We'd still be able to see the logs and such since EQ supports windowed mode(or EQW), but maybe not be able to run 2 chars on the same machine(which didn't work for me anyhow, MQ would "pause" when the window lost focus).

There's a good prossibility we'd still be able to "look" into all of the offsets we needed to support our "Super Duper Cleric Bot.mac" and "Uber Leveling Hunter.mac" scripts.

dont_know_at_all · Post by **dont_know_at_all** » Thu Feb 27, 2003 6:18 pm

eqjoe wrote:However, with a debugger installed I can see that client memory is being checked and compared to something remote and a disconnect command is being sent from the server. This check seems to be some kind of checksum or value validation.

Joe, do you have the offset of the routine doing the memory check?

If we can subvert this routine and provide the "correct" answer to the server, we should be able to get around this.

kaz · Post by **kaz** » Thu Feb 27, 2003 7:39 pm

kaz · Post by **kaz** » Thu Feb 27, 2003 8:02 pm

lifewolf · Post by **lifewolf** » Thu Feb 27, 2003 10:38 pm

Ok now kaz, does the server specify in this 'random' packet what range to scan and how large it is? Or does EQ know what locations to check and it just checks them when sent some weird packet that starts with.. say... 0x32 and the rest is evenly divisible by 67?

If its the client that knows what/where to check, then we could seemingly detour the function to some place in MQ, and modify the MQ one to generate its CRC or whatever based on what memory block we specify it came from..

Like say their detour function is at 0x01164238, we could have MQ pretend in its EQ memory check detour that the memory its checking versus its location is actually in that location instead of the real one.. It might be 0x742970 further down in memory but if you take into account for it before any calculating goes on, then I dont see why it wont work..

If they specify the offset/byte range in the packet, well, we're screwed unless someone has the time to re-write EQ to load a clone of itself in the background that works the exact same way as the new EQ client so it will always have the right answer to the servers modified code requests...